Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 38.300  Word version:  16.3.0

Top   Top   Up   Prev   Next
1…   4…   4.7…   5…   5.3…   5.4…   6…   6.2…   6.6…   7…   8…   9…   9.2.2…   9.2.3…   9.2.3.2   9.2.3.3…   9.2.4…   9.2.6…   9.3…   10…   11…   15…   15.5…   16…   16.3   16.4…   17…   A…   B…

 

9.2.3  Mobility in RRC_CONNECTEDWord‑p. 68

9.2.3.1  Overview

Network controlled mobility applies to UEs in RRC_CONNECTED and is categorized into two types of mobility: cell level mobility and beam level mobility.
Cell Level Mobility requires explicit RRC signalling to be triggered, i.e. handover. For inter-gNB handover, the signalling procedures consist of at least the following elemental components illustrated in Figure 9.2.3.1-1:
Reproduction of 3GPP TS 38.300, Figure 9.2.3.1-1: Inter-gNB handover procedures
Up
Step 1.
The source gNB initiates handover and issues a HANDOVER REQUEST over the Xn interface.
Step 2.
The target gNB performs admission control and provides the new RRC configuration as part of the HANDOVER REQUEST ACKNOWLEDGE.
Step 3.
The source gNB provides the RRC configuration to the UE by forwarding the RRCReconfiguration message received in the HANDOVER REQUEST ACKNOWLEDGE. The RRCReconfiguration message includes at least cell ID and all information required to access the target cell so that the UE can access the target cell without reading system information. For some cases, the information required for contention-based and contention-free random access can be included in the RRCReconfiguration message. The access information to the target cell may include beam specific information, if any.
Step 4.
The UE moves the RRC connection to the target gNB and replies with the RRCReconfigurationComplete.
In case of DAPS handover, the UE continues the downlink user data reception from the source gNB until releasing the source cell and continues the uplink user data transmission to the source gNB until successful random access procedure to the target gNB.
The handover mechanism triggered by RRC requires the UE at least to reset the MAC entity and re-establish RLC, except for DAPS handover, where upon reception of the handover command, the UE:
  • Creates a MAC entity for target;
  • Establishes the RLC entity and an associated DTCH logical channel for target for each DRB configured with DAPS;
  • For the DRB configured with DAPS, reconfigures the PDCP entity with separate security and ROHC functions for source and target and associates them with the RLC entities configured by source and target respectively;
  • Retains the rest of the source configurations until release of the source.
RRC managed handovers with and without PDCP entity re-establishment are both supported. For DRBs using RLC AM mode, PDCP can either be re-established together with a security key change or initiate a data recovery procedure without a key change. For DRBs using RLC UM mode and for SRBs, PDCP can either be re-established together with a security key change or remain as it is without a key change.
Data forwarding, in-sequence delivery and duplication avoidance at handover can be guaranteed when the target gNB uses the same DRB configuration as the source gNB.
Timer based handover failure procedure is supported in NR. RRC connection re-establishment procedure is used for recovering from handover failure except in certain CHO or DAPS scenarios:
  • When DAPS HO fails, the UE falls back to source cell configuration, resumes the connection with source cell, and reports DAPS HO failure via the source without triggering RRC connection re-establishment if the source link has not been released.
  • When initial CHO execution attempt fails or HO fails, the UE performs cell selection, and if the selected cell is a CHO candidate and if network configured the UE to try CHO after HO/CHO failure, then the UE attempts CHO execution once, otherwise re-establishment is performed.
DAPS handover for FR2 to FR2 case is not supported in this release of the specification.
The handover of the IAB-MT in SA mode follows the same procedure as described for the UE. After the backhaul has been established, the handover of the IAB-MT is part of the intra-CU topology adaptation procedure defined in TS 38.401. Modifications to the configuration of BAP sublayer and higher protocol layers above the BAP sublayer are described in TS 38.401.
Beam Level Mobility does not require explicit RRC signalling to be triggered. The gNB provides via RRC signalling the UE with measurement configuration containing configurations of SSB/CSI resources and resource sets, reports and trigger states for triggering channel and interference measurements and reports. Beam Level Mobility is then dealt with at lower layers by means of physical layer and MAC layer control signalling, and RRC is not required to know which beam is being used at a given point in time.
SSB-based Beam Level Mobility is based on the SSB associated to the initial DL BWP and can only be configured for the initial DL BWPs and for DL BWPs containing the SSB associated to the initial DL BWP. For other DL BWPs, Beam Level Mobility can only be performed based on CSI-RS.
Up


Up   Top   ToC