5.7 HNB to HNB Mobility

25.4673GPPRelease 17Stage 2TSUTRAN architecture for 3G Home Node B (HNB)

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

5.7.1 General

The following sub-sections describe the mechanism for handling the intra HNB-GW mobility signalling via Iurh.

5.7.2 Connected mode mobility from one HNB to another HNB (Intra PLMN, Intra HNB-GW, Intra CSG)

5.7.2.1 C-Plane Handling

RNSAP Relocation utilises existing protocol functions specified for Enhanced Relocation between non-CSG cells within TS 25.413 [9] and TS 25.423 [18].

Additional information from the Source HNB to the Target HNB is provided within the RANAP Enhanced Relocation Information and the RANAP Relocation Information procedures as specified in subclause 5.10.

Figure 5.7.2.1-1 below depicts the case where the UE is involved in the RNSAP Relocation and the HNBs are directly Iurh-connected. In case of UE not being involved, an Iurh signalling connection (i.e. RNA signalling resources) already exists between the involved HNBs which can be utilised for RNSAP signalling. In case of Iurh-connectivity via the HNB-GW, RNA signalling terminates at the HNB-GW, whereas RNSAP signalling is still performed peer-to-peer.

Figure 5.7.2.1-1: HNB to HNB Handover via Iurh interface – UE involved.

1. The Source HNB evaluates the UE’s access rights against the available neighbour information. If the UE has access rights for the Target HNB the Source HNB may decide to send an RNA:CONNECT message (or an RNA:DIRECT TRANSFER message if already in SHO) containing an RNSAP:ENHANCED RELOCATION REQUEST message to the Target HNB to prepare the Target HNB for relocation.

2. The Target HNB updates the transport network layer information for any RABs that are to be relocated to it by sending an HNBAP:TNL UPDATE REQUEST message to the HNB-GW, the HNB-GW responds with an HNBAP:TNL UPDATE RESPONSE.

3. The Target HNB sends an RNA:DIRECT TRANSFER message containing an RNSAP:ENHANCED RELOCATION RESPONSE message back to the Source HNB to indicate that it has successfully prepared the relocation.

4. The Source HNB sends an RNA:DIRECT TRANSFER message containing an RNSAP:RELOCATION COMMIT message, to commit the relocation preparation on the Target HNB. This message includes information to aid the relocation procedure, these are described in subclause 5.10.

5. The Source HNB reconfigures the UE to commence the relocation procedure.

6. At some point later Layer 1 synchronisation is achieved between the UE and the Target HNB. The UE then completes the RRC Reconfiguration procedure by sending an RRC:RADIO BEARER RECONFIGURATION COMPLETE message to the Target HNB.

7. The Target HNB indicates to the HNB-GW that the UE has successfully relocated via the HNBAP:UE RELOCATION COMPLETE message. The HNB-GW also switches the U-plane to the Target HNB.

8. The Target HNB initiates the RAB Release Request Procedure to the CN to release unaccepted RABs, if any, with an appropriate cause value.

9. The HNB-GW sends the HNBAP:UE-DEREGISTER to the Source HNB indicating Successful RNSAP Relocation with an appropriate cause value.

10. The Source HNB sends an RNA:DISCONNECT message containing an RNSAP:ENHANCED RELOCATION SIGNALLING TRANSFER message to the Target HNB to transfer any L3 information that the Source HNB may have received during the relocation procedure and locally releases any resources it has for the UE.

NOTE: If the involved HNBs are Iurh connected via the HNB-GW, the RNA messages are routed via the HNB-GW.

5.7.2.2 User Plane Handling

In order to keep the CN unaware of any Intra-GW mobility for RABs operating in support mode (see TS 25.415 [17]), which would normally need an Iu-UP initialization procedure during relocation, the respective user plane configuration (RFCIs, etc.) has to be transferred to the Target HNB without actually carrying out the Iu-UP Initialisation procedure towards its peer node. Special handling of related control and user data frame sequence numbers has to be applied.

In order to avoid problems with Iu-UP version interworking, the Target HNB shall support at least the same versions of Iu UP and rate parameters used by the Source HNB.

In order to allow seamless Iu-UP operation from a CN perspective,

– the Source HNB:

– shall provide the Target HNB within RANAP ENHANCED RELOCATION INFORMATION REQUEST message with

– CS IuUP control information needed to allocate IuUP instances for those RABs operated in support mode.

– the latest CS Iu-UP user-data frame-numbers for UL and DL for all CS RABs operated in support mode for which user data frame numbering is based on time together with the time-difference between UL and DL packets as received/sent on the source side.

– shall provide the Target HNB within RANAP RELOCATION INFORMATION message (encapsulated within the RNSAP message RELOCATION COMMIT) with

– CS IuUP control information needed to allocate IuUP instances for those RABs operated in support mode, if the IuUP configuration of the RABs has changed.

– the latest CS Iu-UP control-data frame-numbers for UL and DL for all CS RABs operated in support mode.

– the last sent DL and last received and forwarded UL user-data frame number for those CS RABs for which user-data frame-numbering is based on sent Iu UP PDU.

– the latest PS Iu-UP user-data frame-numbers for UL and DL for all applicable PS RABs.

– may start to forward user plane packets towards the Target-HNB for those RABs for which it has decided to perform data forwarding, when triggering the execution of the RNSAP Relocation (exact sequence of actions is implementation specific).

– not initiate any Iu-UP procedure and ignore incoming Iu-UP control frames, after having sent the RNSAP message RELOCATION COMMIT.

– the Target-HNB shall

– after having received the RANAP ENHANCED RELOCATION INFORMATION REQUEST message

– use the information provided by the Source HNB to establish Iu-UP instances for receiving user Iu-UP frames from the Source HNB and may use the information of the last CS Iu-UP UL/DL user-data frame number as received from the source together with received DL user-data frames to re-install the timing and frame-numbering for UL/DL user-data frames once the first DL user data packet is received from the Source HNB.

– use the information provided by the Source HNB to establish Iu-UP instances.

– for each CS RAB operated in support mode, use the information of the last CS Iu-UP UL/DL user-data frame number as received from the source together with received DL user-data frames to re-install the timing and frame-numbering for UL/DL user-data frames once the first DL user data packet is received

– not initiate any Iu-UP procedure and ignore incoming Iu-UP control frames.

– after having received the HNBAP: TNL UPDATE RESPONSE message from the HNB-GW

– use the information provided by the Source HNB to establish Iu-UP instances for receiving user Iu-UP frames from the HNB-GW and use the information of the last CS Iu-UP UL/DL user-data frame number as received from the source together with received DL user-data frames to re-install the timing and frame-numbering for UL/DL user-data frames once the first DL user data packet is received from the HNB-GW.

– not initiate any Iu-UP procedure and ignore incoming Iu-UP control frames.

– after having received the RNSAP message RELOCATION COMMIT

– use the information of the last CS Iu-UP UL control-data frame number as received from the Source HNB for the next to be sent UL control-data frame.

– ignore any loss of DL control frames and start respective error handling after the first received DL control frame.

– use the information of the last CS Iu-UP UL/DL user-data frame number as received from the source together with received DL user-data frames to re-adjust the timing and frame-numbering for UL/DL user-data frames, if necessary.

– start Iu-UP procedures as necessary (e.g. downlink rate control (due to e.g. local congestion), Iu Time Alignment).

– the HNB-GW shall

– after receipt of the HNBAP:RELOCATION COMPLETE message

– switch the TNL part of the UP completly towards the Target HNB.

5.7.3 Soft Handover Initiation

Figure 5.7.3-1 below depicts Soft Handover Initiation in case HNBs are directly Iurh-connected. In case of Iurh-connectivity via the HNB-GW, RNA signalling terminates at the HNB-GW, whereas RNSAP signalling is still performed on a HNB-to-HNB basis.

Figure 5.7.3-1: Soft Handover Initiation HNB to HNB.

1. The Serving HNB (SHNB) receives an RRC measurement report indicating that Soft handover is possible and the SHNB decides to setup a RL to the Drift HNB (DHNB).

2. The SHNB evaluates the UE’s access rights against neighbour information available from the HNB Configuration Transfer function. If the UE has access rights for the DHNB, the SHNB may decide to setup a new RL and send an RNA:CONNECT message containing an RNSAP:RADIO LINK SETUP REQUEST message to the DHNB to set up a radio link at the DHNB.

3. The DHNB starts receiving from the UE and sends an RNSAP: RADIO LINK SETUP RESPONSE message.

4. When the radio link is established on the DHNB, the DHNB sends an RNSAP: RADIO LINK RESTORE INDICATION message.

5. The SHNB sends an RRC Active Set Update to the UE

6. The SHNB receives an RRC Active Set Update Complete from the UE.

5.7.4 Mobility Access Control

5.7.4.1 Limitations

The current version of the specification allows RNSAP relocation and SHO via Iurh only for the following scenarios:

– Intra-PLMN Intra-CSG Closed access cell to Closed access cell mobility

– Intra-PLMN Intra-CSG Hybrid access cell to Hybrid access cell mobility

– Open access cell to Open access cell mobility.

5.7.5 CELL_FACH, CELL_PCH and URA_PCH Iurh based mobility (Intra-GW)

Figure 5.7.5-1 below reports the message flow in case of CELL_FACH/CELL_PCH/URA_PCH mobility across HNBs.

Figure 5.7.5-1: HNB to HNB CELL_FACH/CELL_PCH/URA_PCH mobility

1. At initial RRC Connection Setup, the Source HNB assigns to the UE a U-RNTI value based on the S-RNTI-prefix previously assigned to the HNB by the HNB-GW.

2. Subsequently, when the UE performs Cell or URA Reselection to the target HNB, it sends an RRC: Cell Update message (in case of CELL_FACH or CELL_PCH) or an RRC: URA Update message (in case of URA_PCH) containing the U-RNTI value previously assigned by the Source HNB.

3. Based on the received U-RNTI, the Target HNB detects the UE is reselecting from one of its neighbour HNBs.

If, based on the received U-RNTI, the Target HNB cannot detect from which HNB the UE is reselecting from,

3a. it may trigger a query towards the HNB-GW for the U-RNTI and subsequently, if both HNBs support CELL_FACH mobility, establish an Iurh interface with the source HNB;

3b. alternatively, it may terminate the mobility procedure, re-establish the RRC connection for the UE and skip the subsequent steps.

4. The target HNB forwards the received RRC Cell/URA update message via a RNSAP Uplink Signalling Transfer Indication message encapsulated in a RNA CONNECT message to the source HNB.

5. The source HNB may now execute the SRNS Relocation/Enhanced SRNS Relocation procedure towards the target HNB to transfer the UE context or initialise the UE context in the target HNB via RNSAP Common Transport Channel Resources Initialisation procedure.

6. The Target HNB sends to the UE an RRC: Cell Update Confirm message (in case of CELL_FACH or CELL_PCH) or an RRC: URA Update Confirm message (in case of URA_PCH) to terminate the mobility procedure. Such message includes a new U-RNTI value, this time assigned by the Target HNB. If the SRNS relocation procedure is not used, the RRC: Cell Update Confirm message (in case of CELL_FACH or CELL_PCH) or the RRC: URA Update Confirm message (in case of URA_PCH) is sent by the serving HNB.