4.6 Support of HeNBs

36.3003GPPEvolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN)Overall descriptionRelease 17Stage 2TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

4.6.1 Architecture

Figure 4.6.1-1 shows a logical architecture for the HeNB that has a set of S1 interfaces to connect the HeNB to the EPC.

The configuration and authentication entities as shown here should be common to HeNBs and HNBs.

Figure 4.6.1-1: E-UTRAN HeNB Logical Architecture

The E-UTRAN architecture may deploy a Home eNB Gateway (HeNB GW) to allow the S1 interface between the HeNB and the EPC to support a large number of HeNBs in a scalable manner. The HeNB GW serves as a concentrator for the C-Plane, specifically the S1-MME interface. The S1-U interface from the HeNB may be terminated at the HeNB GW, or a direct logical U-Plane connection between HeNB and S-GW may be used (as shown in Figure 4.6.1-1).

The S1 interface is defined as the interface:

– Between the HeNB GW and the Core Network;

– Between the HeNB and the HeNB GW;

– Between the HeNB and the Core Network;

– Between the eNB and the Core Network.

The HeNB GW appears to the MME as an eNB. The HeNB GW appears to the HeNB as an MME. The S1 interface between the HeNB and the EPC is the same, regardless whether the HeNB is connected to the EPC via a HeNB GW or not.

The HeNB GW shall connect to the EPC in a way that inbound and outbound mobility to cells served by the HeNB GW shall not necessarily require inter MME handovers. One HeNB serves only one cell.

The functions supported by the HeNB shall be the same as those supported by an eNB (with possible exceptions e.g. NNSF) and the procedures run between a HeNB and the EPC shall be the same as those between an eNB and the EPC (with possible exceptions e.g. S5 procedures in case of LIPA support).

X2-based HO involving HeNBs is allowed as shown in Table 4.6.1-1.

Table 4.6.1-1: X2-based HO support

Source	Target	Notes
eNB or any HeNB	open access HeNB
eNB, or any HeNB	hybrid access HeNB
hybrid access HeNB or closed access HeNB	closed access HeNB	Only applies for same CSG ID and PLMN, and if the UE is a member of the CSG cell.
Any HeNB	eNB

This version of the specification supports X2-connectivity between HeNBs, independent of whether any of the involved HeNBs is connected to a HeNB GW.

The overall E-UTRAN architecture with deployed HeNB GW and X2 GW is shown below.

Figure 4.6.1-2: Overall E-UTRAN Architecture with deployed HeNB GW and X2 GW.

NOTE: In the figure above, a HeNB operating in LIPA mode has been represented with its S5 interface. X2-based HO involving HeNBs is supported according to Table 4.6.1-1.

If the HeNB supports the LIPA function, it shall support an S5 interface towards the S-GW and an SGi interface towards the residential/IP network. See clause 4.6.5 for the details of the architecture and functions in case of LIPA support.

If the HeNB supports SIPTO@LN with collocated L-GW, it shall support an S5 interface towards the S-GW and an SGi interface towards the IP network. The S5 interface does not go via the HeNB GW, even when present. All other functions are described in clause 4.8.2.

4.6.2 Functional Split

A HeNB hosts the same functions as an eNB as described in clause 4.1, with the following additional specifics in case of connection to the HeNB GW:

– Discovery of a suitable Serving HeNB GW;

– A HeNB shall only connect to a single HeNB GW at one time, namely no S1 Flex function shall be used at the HeNB:

– The HeNB will not simultaneously connect to another HeNB GW, or another MME.

– The TAC and PLMN ID used by the HeNB shall also be supported by the HeNB GW;

– Selection of an MME at UE attachment is hosted by the HeNB GW instead of the HeNB. Upon reception of the GUMMEI from a UE, the HeNB shall include it in the INITIAL UE MESSAGE message; upon reception of the GUMMEI Type from the UE, the HeNB shall also include it in the message if supported and supported by the HeNB GW.

– HeNBs may be deployed without network planning. A HeNB may be moved from one geographical area to another and therefore it may need to connect to different HeNB GWs depending on its location;

– Signalling the GUMMEI of the Source MME to the HeNB GW in the S1 PATH SWITCH REQUEST message.

Regardless of HeNB GW connection:

– The HeNB may support the LIPA function. See clause 4.6.5 for details.

– The HeNB may support Fixed Broadband Access network interworking function to signal Tunnel Information to the MME via INITIAL UE MESSAGE message, PATH SWITCH REQUEST message and HANDOVER NOTIFY message as specified in TS 23.139 [55]. The HeNB may also signal Tunnel Information to the MeNB via SENB ADDITION REQUEST ACKNOWLEDGE message when the HeNB provide SeNB function and the MeNB signal to MME via E-RAB MODIFICATION INDICATION message The Tunnel Information includes the HeNB IP address, the UDP port if NAT/NAPT is detected.

– In case an X2 GW is used, the HeNB registers with the X2 GW at power on or after any change of TNL address(es).

The HeNB GW hosts the following functions:

– Relaying UE-associated S1 application part messages between the MME serving the UE and the HeNB serving the UE, except the UE CONTEXT RELEASE REQUEST message received from the HeNB with an explicit GW Context Release Indication. In that case, the HeNB GW terminates the S1 UE Context Release Request procedure and releases the UE context if it determines that the UE identified by the received UE S1AP IDs is no longer served by an HeNB attached to it. Otherwise it ignores the message.

– In case of S1 INITIAL CONTEXT SETUP REQUEST message and S1 HANDOVER REQUEST message, informing the HeNB about any GUMMEI corresponding to the serving MME, the MME UE S1AP ID assigned by the MME and the MME UE S1AP ID assigned by the HeNB GW for the UE. In case of S1 PATH SWITCH REQUEST ACKNOWLEDGE message, informing the HeNB about the MME UE S1AP ID assigned by the MME and the MME UE S1AP ID assigned by the HeNB GW for the UE.

– In case of S1 INITIAL UE MESSAGE message, S1 PATH SWITCH REQUEST and S1 HANDOVER REQUEST ACKNOWLEDGE message, verifying, as defined in TS 33.320 [53], for a closed HeNB, that the indicated cell access mode and CSG ID are valid for that HeNB.

– Terminating non-UE associated S1 application part procedures towards the HeNB and towards the MME. In case of S1 SETUP REQUEST message, verifying, as defined in TS 33.320 [53], that the identity used by the HeNB is valid and determining whether the access mode of the HeNB is closed or not. In case of S1 PWS RESTART INDICATION message and PWS FAILURE INDICATION message, verifying, as defined in TS 33.320 [53], that the indicated cell identity is valid and replacing the HeNB ID by the HeNB GW ID before sending the PWS RESTART INDICATION message (respectively the PWS FAILURE INDICATION message) to the MME.

– Upon receiving an OVERLOAD START/STOP message, the HeNB GW should send the OVERLOAD START/STOP message towards the HeNB(s) including in the message the identities of the affected MME node. The HeNB uses this information received from the OVERLOAD START message to identify to which traffic the above defined rejections shall be applied. The HeNB shall apply the defined rejections until reception of an OVERLOAD STOP message applicable to this traffic, or until the HeNB receives a further OVERLOAD START message applicable to the same traffic, in which case it shall replace the ongoing overload action with the newly requested one.

NOTE: If a HeNB GW is deployed, non-UE associated procedures shall be run between HeNBs and the HeNB GW and between the HeNB GW and the MME.

– Optionally terminating S1-U interface with the HeNB and with the S-GW.

– Supporting TAC and PLMN ID used by the HeNB.

– X2 interfaces shall not be established between the HeNB GW and other nodes.

– Routing the S1 PATH SWITCH REQUEST message towards the MME based on the GUMMEI of the source MME received from the HeNB.

– Selection of an IP version to be used for S1-U, if a requested ERAB configuration contains two transport layer addresses of different versions.

A list of CSG IDs may be included in the PAGING message. If included, the HeNB GW may use the list of CSG IDs for paging optimisation.

The X2 GW hosts the following functions:

– routing the X2AP X2 MESSAGE TRANSFER message to target eNB or HeNB based on the routing information received in the X2AP X2 MESSAGE TRANSFER message.

– informing the relevant (H)eNBs upon detecting that the signalling (i.e. SCTP) connection to a (H)eNB is unavailable. The relevant (H)eNBs are the ones which had an "X2AP association" with this (H)eNB via the X2 GW when the signalling connection became unavailable.

– Mapping the TNL address(es) of a (H)eNB to its corresponding Global (H)eNB ID and maintaining the association.

In addition to functions specified in clause 4.1, the MME hosts the following functions:

– Access control for UEs that are members of Closed Subscriber Groups (CSG):

– In case of handovers to CSG cells, access control is based on the target CSG ID of the selected target PLMN provided to the MME by the serving E-UTRAN (see TS 23.401 [17]).

– Membership Verification for UEs handing over to hybrid cells:

– In case of handovers to hybrid cells the MME performs Membership Verification based on UE’s selected target PLMN, cell access mode related information and the CSG ID of the target cell provided by the source E-UTRAN in S1 handover, or provided by the target E-UTRAN in X2 handover (see TS 23.401 [17]).

– Membership Verification for UEs for which the hybrid cell is served by an SeNB is described in clause 4.9.3.3.

– CSG membership status signalling to the E-UTRAN in case of attachment/handover to hybrid cells and in case of the change of membership status when a UE is served by a CSG cell or a hybrid cell.

– Supervising the E-UTRAN action after the change in the membership status of a UE.

– In case of a HeNB directly connected:

– verifying as defined in TS 33.320 [53], that the identity used by the HeNB is valid when receiving the S1 SETUP REQUEST message and determining whether the access mode of the HeNB is closed or not;

– verifying as defined in TS 33.320 [53], for a closed HeNB, that the indicated cell access mode and CSG ID are valid when receiving the S1 INITIAL UE MESSAGE message, the S1 PATH SWITCH REQUEST and the S1 HANDOVER REQUEST ACKNOWLEDGE message;

– and verifying, as defined in TS 33.320 [53], that the indicated HeNB identity is valid when receiving the S1 PWS RESTART INDICATION message and the S1 PWS FAILURE INDICATION message.

– Routing of handover messages, MME configuration transfer messages and MME Direct Information Transfer messages towards HeNB GWs based on the TAI contained in these messages.

NOTE: If routing ambiguities are to be avoided, a TAI used in a HeNB GW should not be reused in another HeNB GW.

NOTE: The MME or HeNB GW should not include the list of CSG IDs for paging when sending the paging message directly to an un-trusted HeNB or eNB.

– The MME may support the LIPA function with HeNB. See details of this support in clause 4.6.5.

– The MME may support fixed Broadband Access network interworking with HeNB as specified in TS 23.139 [55].

– The MME may send two transport layer addresses of different versions only in case of HeNB GW which does not terminate user plane.

4.6.3 Interfaces

4.6.3.1 Protocol Stack for S1 User Plane

The S1-U data plane is defined between the HeNB, HeNB GW and the S-GW. The figures below show the S1-U protocol stack with and without the HeNB GW.

Figure 4.6.3.1-1: User plane for S1-U interface for HeNB without HeNB GW

Figure 4.6.3.1-2: User plane for S1-U interface for HeNB with HeNB GW

The HeNB GW may optionally terminate the user plane towards the HeNB and towards the S-GW, and relay User Plane data between the HeNB and the S-GW.

4.6.3.2 Protocol Stacks for S1 Control Plane

The two figures below show the S1-MME protocol stacks with and without the HeNB GW.

When the HeNB GW is not present (Fig. 4.6.3.2-1), all the S1-AP procedures are terminated at the HeNB and the MME.

When present (Fig. 4.6.3.2-2), the HeNB GW shall terminate the non-UE-dedicated procedures – both with the HeNB, and with the MME. The HeNB GW relays Control Plane data between the HeNB and the MME. The scope of any protocol function associated to a non-UE-dedicated procedure shall be between HeNB and HeNB GW and/or between HeNB GW and MME.

Any protocol function associated to an UE-dedicated-procedure shall reside within the HeNB and the MME only.

Figure 4.6.3.2-1: Control plane for S1-MME Interface for HeNB to MME without the HeNB GW

Figure 4.6.3.2-2: Control plane for S1-MME Interface for HeNB to MME with the HeNB GW

4.6.3.3 Protocol Stack for S5 interface

The protocol stack for the S5 interface can be found in TS 29.281 [47] for the user plane and in TS 29.274 [40] for the control plane.

4.6.3.4 Protocol Stack for SGi interface

The protocol stack for the SGi interface can be found in TS 29.061 [41].

4.6.3.5 Protocol Stack for X2 User Plane and X2 Control Plane

The protocol stack for X2 User Plane and X2 Control Plane is reported in clause 6.4 of TS 36.420 [46].

4.6.4 Void

4.6.5 Support of LIPA with HeNB

Figure 4.6.5-1 shows the logical architecture for the HeNB when it supports the LIPA function.

Figure 4.6.5-1: E-UTRAN – HeNB operating in LIPA mode – Logical Architecture

For a LIPA PDN connection, the HeNB sets up and maintains an S5 connection to the EPC.

The S5 interface does not go via the HeNB GW, even when present.

Requirements on the secure backhaul link for the S5 interface are specified in TS 33.320 [53].

The mobility of the LIPA PDN connection is not supported in this release of the specification. The LIPA connection is always released at outgoing handover as described in TS 23.401 [17]. The L-GW function in the HeNB triggers this release over the S5 interface.

In case of LIPA support, the HeNB supports the following additional functions, regardless of the presence of a HeNB GW:

– transfer of the collocated L-GW IP address of the HeNB over S1-MME to the EPC at every idle-active transition;

– transfer of the collocated L-GW IP address of the HeNB over S1-MME to the EPC within every Uplink NAS Transport procedure;

– support of basic P-GW functions in the collocated L-GW function such as support of the SGi interface corresponding to LIPA;

– additional support of first packet sending, buffering of subsequent packets, internal direct L-GW – HeNB user path management and in sequence packet delivery to the UE;

– support of the necessary restricted set of S5 procedures corresponding to the strict support of LIPA function as specified in TS 23.401 [17];

– notification to the EPC of the collocated L-GW uplink TEID(s) or GRE key(s) for the LIPA bearer(s) over S5 interface within the restricted set of procedures to be forwarded over S1-MME and further used by the HeNB as "correlation id" for correlation purposes between the collocated L-GW function and the HeNB;

– in case of outgoing handover triggering the L-GW function to release the LIPA PDN connection and only handing over the non-LIPA E-RABs.

In case of LIPA support, the MME may support the following additional functions:

– verification of UE authorization to request LIPA activation for the requested APN at this CSG and transfer of the received collocated L-GW IP address;

– transfer of the "correlation id" i.e. collocated L-GW uplink TEID or GRE key to the HeNB within the UE context setup procedure and E-RAB setup procedure;

– verification of whether the LIPA PDN connection has been released during the handover procedure, as specified in TS 23.401 [17];

– deactivation of the LIPA PDN connection of an idle-mode UE if it detects that the UE has moved out of the coverage area of the HeNB collocated with L-GW function, as specified in TS 23.401 [17].

4.6.6 Support of X2 GW

Figure 4.6.6-1 shows the logical architecture when X2-connectivity via the X2 GW is supported.

Figure 4.6.6-1: E-UTRAN operating with X2 GW – Logical Architecture

Support for the X2 GW relies on following principles:

– A HeNB connects to a single X2 GW only. Each HeNB is preconfigured with information about which X2 GW it connects to, e.g. an IP address of the X2 GW.

– There is no limitation on the number of X2 GWs an eNB may connect to.

– The X2 GW does not terminate X2AP procedures except for the X2AP Message Transfer procedure, but it initiates the X2 Release procedure and the X2 Error Indication procedure.

– This version of the specification does not support an interface between two X2 GWs. The routing of X2AP messages via more than one X2 GW (i.e. more than two SCTP hops) is not allowed.

– X2AP contexts only exist in the two peer (H)eNBs (same as without X2 GW). The peer X2AP contexts define an "X2AP association" between peer (H)eNBs which spans over two SCTP associations (one per each hop).

– The X2 GW puts no constraints on the X2 user plane interface (X2-U).

– For each (H)eNB connected to the X2 GW, the X2 GW maintains the association information, i.e. the mapping of the Global eNB ID to the TNL address(es). The registration procedure, described in Sec. 4.6.6.4, is used to update the association information in the X2 GW.

4.6.6.1 Enhanced TNL Address Discovery

In case of Enhanced TNL Address Discovery is used with the X2 GW, in addition to the procedures specified in clause 22.3.6.1, the following also applies.

– During HeNB initiated Enhanced TNL address discovery procedure, the HeNB may include the IP address of the X2 GW to which the HeNB connected in the eNB CONFIGURATION TRANSFER message thus indicating its X2 GW support capability. Upon the reception of the IP address of the X2 GW, the candidate eNB may include in its reply the received IP address of the X2 GW thus indicating the support of indirect X2 via the indicated X2 GW.

– During the eNB or HeNB initiated Enhanced TNL address discovery procedure towards an HeNB, the candidate HeNB may include in its reply the IP address of the X2 GW to which the candidate HeNB connected thus indicating the support of indirect X2 via the indicated X2 GW.

4.6.6.2 Routing of X2AP messages

When a (H)eNB sends an X2AP message (except the X2AP X2 MESSAGE TRANSFER message) to a peer node via the X2 GW, the (H)eNB encapsulates the X2AP message in an X2AP X2 MESSAGE TRANSFER message, adds the routing information, then sends the X2AP X2 MESSAGE TRANSFER message to the X2 GW. The routing information includes both Target (H)eNB ID and source (H)eNB ID. The X2 GW routes the message based on the target (H)eNB ID. The source (H)eNB ID is used by the destination (H)eNB node to reply.

4.6.6.3 (H)eNB unavailability

Upon the detection that the signalling (i.e. SCTP) connection to a (H)eNB is unavailable, the X2 GW initiates the X2 Release procedure to inform the relevant (H)eNBs. The relevant (H)eNBs are the ones which had an "X2AP association" with this (H)eNB via the X2 GW when the signalling connection became unavailable.

4.6.6.4 (H)eNB registration

Registration of a (H)eNB is performed by initiating the X2AP Message Transfer procedure towards the X2 GW signalling a Source (H)eNB ID, no Target (H)eNB ID, and no X2AP Message in the X2AP MESSAGE TRANSFER message. Upon receipt of this message, the X2 GW saves the association information, i.e. the mapping of the received Global eNB ID to the TNL address(es) of the originating (H)eNB.