Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 38.300  Word version:  18.0.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.2.5…   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.2…   16.3…   16.4…   16.8…   16.9…   16.10…   16.12…   16.12.5…   16.12.6…   16.12.6.3   16.12.7   16.13…   16.14…   16.15…   16.18…   16.19…   16.21…   16.21.3…   17…   18…   19   20…   21…   A…   B…   C…   G…

 

9.2.3  Mobility in RRC_CONNECTEDp. 85

9.2.3.1  Overviewp. 85

Network controlled mobility applies to UEs in RRC_CONNECTED and is categorized into two types of mobility: cell level mobility and beam level mobility. Beam level mobility includes intra-cell beam level mobility and inter-cell 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, Fig. 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.
Only source and target PCell are used during DAPS handover. CA, DC, SUL, multi-TRP, EHC, CHO, UDC, NR sidelink configurations and V2X sidelink configurations are released by the source gNB before the handover command is sent to the UE and are not configured by the target gNB until the DAPS handover has completed (i.e. at earliest in the same message that releases the source PCell).
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 each 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.
The cell switch mechanism triggered by MAC, (i.e., LTM cell switch) requires the UE at least to reset the MAC entity. RLC handling depends on the network configuration.
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, PDCP can either be re-established together with a security key change or remain as it is without a key change. For SRBs, PDCP can either remain as it is, discard its stored PDCP PDUs/SDUs without a key change or be re-established together with a security 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, DAPS handover or LTM cell switch scenarios:
  • When DAPS handover fails, the UE falls back to the source cell configuration, resumes the connection with the source cell, and reports DAPS handover 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 handover/CHO failure, then the UE attempts CHO execution once, otherwise re-establishment is performed.
  • When initial LTM execution attempt fails or HO fails, the UE performs cell selection and if the selected cell is an LTM candidate cell and if network configured the UE to try LTM after LTM execution failure, then the UE attempts LTM 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 or inter-CU topology adaptation procedures 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.
The handover of the mobile IAB-MT follows the same procedure as described for the UE. After the backhaul has been established, the handover of the mobile IAB-MT is part of the mobile IAB-MT migration procedure defined in TS 38.401.
Beam Level Mobility does not require explicit RRC signalling to be triggered. Beam level mobility can be within a cell, or between cells, the latter is referred to as inter-cell beam management (ICBM). For ICBM, a UE can receive or transmit UE dedicated channels/signals via a TRP associated with a PCI different from the PCI of a serving cell, while non-UE-dedicated channels/signals can only be received via a TRP associated with a PCI of the serving cell. 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. In case of ICBM, a measurement configuration includes SSB resources associated with PCIs different from the PCI of a serving cell. 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 CD-SSB associated to the initial DL BWP and can be configured for the initial DL BWPs, for DL BWPs containing the CD-SSB associated to the initial DL BWP, and if supported, for DL BWPs not containing the CD-SSB associated to the initial DL BWP. SSB-based Beam Level Mobility can be also performed based on an NCD-SSB, if configured for the active DL BWP. For other DL BWPs, Beam Level Mobility can only be performed based on CSI-RS, if configured for the active DL BWP.
Up

Up   Top   ToC