9.2.3 Mobility in RRC_CONNECTED

38.3003GPPNRNR and NG-RAN Overall descriptionRelease 17Stage 2TS

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

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. 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:

Figure 9.2.3.1-1: Inter-gNB handover procedures

1. The source gNB initiates handover and issues a HANDOVER REQUEST over the Xn interface.

2. The target gNB performs admission control and provides the new RRC configuration as part of the HANDOVER REQUEST ACKNOWLEDGE.

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.

4. The UE moves the RRC connection to the target gNB and replies with the RRCReconfigurationComplete.

NOTE 1: User Data can also be sent in step 4 if the grant allows.

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.

NOTE 2: Void.

NOTE 3: Void.

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 or DAPS handover 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.

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 [4]. Modifications to the configuration of BAP sublayer and higher protocol layers above the BAP sublayer are described in TS 38.401 [4].

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 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.

9.2.3.2 Handover

9.2.3.2.1 C-Plane Handling

The intra-NR RAN handover performs the preparation and execution phase of the handover procedure performed without involvement of the 5GC, i.e. preparation messages are directly exchanged between the gNBs. The release of the resources at the source gNB during the handover completion phase is triggered by the target gNB. The figure below depicts the basic handover scenario where neither the AMF nor the UPF changes:

Figure 9.2.3.2.1-1: Intra-AMF/UPF Handover

0. The UE context within the source gNB contains information regarding roaming and access restrictions which were provided either at connection establishment or at the last TA update.

1. The source gNB configures the UE measurement procedures and the UE reports according to the measurement configuration.

2. The source gNB decides to handover the UE, based on MeasurementReport and RRM information.

3. The source gNB issues a Handover Request message to the target gNB passing a transparent RRC container with necessary information to prepare the handover at the target side. The information includes at least the target cell ID, KgNB*, the C-RNTI of the UE in the source gNB, RRM-configuration including UE inactive time, basic AS-configuration including antenna Info and DL Carrier Frequency, the current QoS flow to DRB mapping rules applied to the UE, the SIB1 from source gNB, the UE capabilities for different RATs, PDU session related information, and can include the UE reported measurement information including beam-related information if available. The PDU session related information includes the slice information and QoS flow level QoS profile(s). The source gNB may also request a DAPS handover for one or more DRBs.

NOTE 1: After issuing a Handover Request, the source gNB should not reconfigure the UE, including performing Reflective QoS flow to DRB mapping.

4. Admission Control may be performed by the target gNB. Slice-aware admission control shall be performed if the slice information is sent to the target gNB. If the PDU sessions are associated with non-supported slices the target gNB shall reject such PDU Sessions.

5. The target gNB prepares the handover with L1/L2 and sends the HANDOVER REQUEST ACKNOWLEDGE to the source gNB, which includes a transparent container to be sent to the UE as an RRC message to perform the handover. The target gNB also indicates if a DAPS handover is accepted.

NOTE 2: As soon as the source gNB receives the HANDOVER REQUEST ACKNOWLEDGE, or as soon as the transmission of the handover command is initiated in the downlink, data forwarding may be initiated.

NOTE 3: For DRBs configured with DAPS, downlink PDCP SDUs are forwarded with SN assigned by the source gNB, until SN assignment is handed over to the target gNB in step 8b, for which the normal data forwarding follows as defined in 9.2.3.2.3.

6. The source gNB triggers the Uu handover by sending an RRCReconfiguration message to the UE, containing the information required to access the target cell: at least the target cell ID, the new C-RNTI, the target gNB security algorithm identifiers for the selected security algorithms. It can also include a set of dedicated RACH resources, the association between RACH resources and SSB(s), the association between RACH resources and UE-specific CSI-RS configuration(s), common RACH resources, and system information of the target cell, etc.

NOTE 4: For DRBs configured with DAPS, the source gNB does not stop transmitting downlink packets until it receives the HANDOVER SUCCESS message from the target gNB in step 8a.

NOTE 4a: CHO cannot be configured simultaneously with DAPS handover.

7a. For DRBs configured with DAPS, the source gNB sends the EARLY STATUS TRANSFER message. The DL COUNT value conveyed in the EARLY STATUS TRANSFER message indicates PDCP SN and HFN of the first PDCP SDU that the source gNB forwards to the target gNB. The source gNB does not stop assigning SNs to downlink PDCP SDUs until it sends the SN STATUS TRANSFER message to the target gNB in step 8b.

7. For DRBs not configured with DAPS, the source gNB sends the SN STATUS TRANSFER message to the target gNB to convey the uplink PDCP SN receiver status and the downlink PDCP SN transmitter status of DRBs for which PDCP status preservation applies (i.e. for RLC AM). The uplink PDCP SN receiver status includes at least the PDCP SN of the first missing UL PDCP SDU and may include a bit map of the receive status of the out of sequence UL PDCP SDUs that the UE needs to retransmit in the target cell, if any. The downlink PDCP SN transmitter status indicates the next PDCP SN that the target gNB shall assign to new PDCP SDUs, not having a PDCP SN yet.

NOTE 5: In case of DAPS handover, the uplink PDCP SN receiver status and the downlink PDCP SN transmitter status for a DRB with RLC-AM and not configured with DAPS may be transferred by the SN STATUS TRANSFER message in step 8b instead of step 7.

NOTE 6: For DRBs configured with DAPS, the source gNB may additionally send the EARLY STATUS TRANSFER message(s) between step 7 and step 8b, to inform discarding of already forwarded PDCP SDUs. The target gNB does not transmit forwarded downlink PDCP SDUs to the UE, whose COUNT is less than the conveyed DL COUNT value and discards them if transmission has not been attempted already.

8. The UE synchronises to the target cell and completes the RRC handover procedure by sending RRCReconfigurationComplete message to target gNB. In case of DAPS handover, the UE does not detach from the source cell upon receiving the RRCReconfiguration message. The UE releases the source resources and configurations and stops DL/UL reception/transmission with the source upon receiving an explicit release from the target node.

NOTE 6a: From RAN point of view, the DAPS handover is considered to only be completed after the UE has released the source cell as explicitly requested from the target node. RRC suspend, a subsequent handover or inter-RAT handover cannot be initiated until the source cell has been released.

8a/b In case of DAPS handover, the target gNB sends the HANDOVER SUCCESS message to the source gNB to inform that the UE has successfully accessed the target cell. In return, the source gNB sends the SN STATUS TRANSFER message for DRBs configured with DAPS for which the description in step 7 applies, and the normal data forwarding follows as defined in 9.2.3.2.3.

NOTE 7: The uplink PDCP SN receiver status and the downlink PDCP SN transmitter status are also conveyed for DRBs with RLC-UM in the SN STATUS TRANSFER message in step 8b, if configured with DAPS.

NOTE 8: For DRBs configured with DAPS, the source gNB does not stop delivering uplink QoS flows to the UPF until it sends the SN STATUS TRANSFER message in step 8b. The target gNB does not forward QoS flows of the uplink PDCP SDUs successfully received in-sequence to the UPF until it receives the SN STATUS TRANSFER message, in which UL HFN and the first missing SN in the uplink PDCP SN receiver status indicates the start of uplink PDCP SDUs to be delivered to the UPF. The target gNB does not deliver any uplink PDCP SDUs which has an UL COUNT lower than the provided.

NOTE 9: Void.

9. The target gNB sends a PATH SWITCH REQUEST message to AMF to trigger 5GC to switch the DL data path towards the target gNB and to establish an NG-C interface instance towards the target gNB.

10. 5GC switches the DL data path towards the target gNB. The UPF sends one or more "end marker" packets on the old path to the source gNB per PDU session/tunnel and then can release any U-plane/TNL resources towards the source gNB.

11. The AMF confirms the PATH SWITCH REQUEST message with the PATH SWITCH REQUEST ACKNOWLEDGE message.

12. Upon reception of the PATH SWITCH REQUEST ACKNOWLEDGE message from the AMF, the target gNB sends the UE CONTEXT RELEASE to inform the source gNB about the success of the handover. The source gNB can then release radio and C-plane related resources associated to the UE context. Any ongoing data forwarding may continue.

The RRM configuration can include both beam measurement information (for layer 3 mobility) associated to SSB(s) and CSI-RS(s) for the reported cell(s) if both types of measurements are available. Also, if CA is configured, the RRM configuration can include the list of best cells on each frequency for which measurement information is available. And the RRM measurement information can also include the beam measurement for the listed cells that belong to the target gNB.

The common RACH configuration for beams in the target cell is only associated to the SSB(s). The network can have dedicated RACH configurations associated to the SSB(s) and/or have dedicated RACH configurations associated to CSI-RS(s) within a cell. The target gNB can only include one of the following RACH configurations in the Handover Command to enable the UE to access the target cell:

i) Common RACH configuration;

ii) Common RACH configuration + Dedicated RACH configuration associated with SSB;

iii) Common RACH configuration + Dedicated RACH configuration associated with CSI-RS.

The dedicated RACH configuration allocates RACH resource(s) together with a quality threshold to use them. When dedicated RACH resources are provided, they are prioritized by the UE and the UE shall not switch to contention-based RACH resources as long as the quality threshold of those dedicated resources is met. The order to access the dedicated RACH resources is up to UE implementation.

Upon receiving a handover command requesting DAPS handover, the UE suspends source cell SRBs, stops sending and receiving any RRC control plane signalling toward the source cell, and establishes SRBs for the target cell. The UE releases the source cell SRBs configuration upon receiving source cell release indication from the target cell after successful DAPS handover execution. When DAPS handover to the target cell fails and if the source cell link is available, then the UE reverts back to the source cell configuration and resumes source cell SRBs for control plane signalling transmission.

9.2.3.2.2 U-Plane Handling

The U-plane handling during the Intra-NR-Access mobility activity for UEs in RRC_CONNECTED takes the following principles into account to avoid data loss during HO:

– During HO preparation, U-plane tunnels can be established between the source gNB and the target gNB;

– During HO execution, user data can be forwarded from the source gNB to the target gNB;

– Forwarding should take place in order as long as packets are received at the source gNB from the UPF or the source gNB buffer has not been emptied.

– During HO completion:

– The target gNB sends a path switch request message to the AMF to inform that the UE has gained access and the AMF then triggers path switch related 5GC internal signalling and actual path switch of the source gNB to the target gNB in UPF;

– The source gNB should continue forwarding data as long as packets are received at the source gNB from the UPF or the source gNB buffer has not been emptied.

For RLC-AM bearers:

– For in-sequence delivery and duplication avoidance, PDCP SN is maintained on a per DRB basis and the source gNB informs the target gNB about the next DL PDCP SN to allocate to a packet which does not have a PDCP sequence number yet (either from source gNB or from the UPF).

– For security synchronisation, HFN is also maintained and the source gNB provides to the target one reference HFN for the UL and one for the DL i.e. HFN and corresponding SN.

– In both the UE and the target gNB, a window-based mechanism is used for duplication detection and reordering.

– The occurrence of duplicates over the air interface in the target gNB is minimised by means of PDCP SN based reporting at the target gNB by the UE. In uplink, the reporting is optionally configured on a per DRB basis by the gNB and the UE should first start by transmitting those reports when granted resources are in the target gNB. In downlink, the gNB is free to decide when and for which bearers a report is sent and the UE does not wait for the report to resume uplink transmission.

– The target gNB re-transmits and prioritizes all downlink data forwarded by the source gNB (i.e. the target gNB should first send all forwarded PDCP SDUs with PDCP SNs, then all forwarded downlink PDCP SDUs without SNs before sending new data from 5GC), excluding PDCP SDUs for which the reception was acknowledged through PDCP SN based reporting by the UE.

NOTE 1: Lossless delivery when a QoS flow is mapped to a different DRB at handover, requires the old DRB to be configured in the target cell. For in-order delivery in the DL, the target gNB should first transmit the forwarded PDCP SDUs on the old DRB before transmitting new data from 5GC on the new DRB. In the UL, the target gNB should not deliver data of the QoS flow from the new DRB to 5GC before receiving the end marker on the old DRB from the UE.

– The UE re-transmits in the target gNB all uplink PDCP SDUs starting from the oldest PDCP SDU that has not been acknowledged at RLC in the source, excluding PDCP SDUs for which the reception was acknowledged through PDCP SN based reporting by the target.

– In case of handovers involving Full Configuration, the following description below for RLC-UM bearers applies for RLC-AM bearers instead. Data loss may happen.

For RLC-UM bearers:

– The PDCP SN and HFN are reset in the target gNB, unless the bearer is configured with DAPS handover;

– No PDCP SDUs are retransmitted in the target gNB;

– The target gNB prioritises all downlink SDAP SDUs forwarded by the source gNB over the data from the core network;

NOTE 2: To minimise losses when a QoS flow is mapped to a different DRB at handover, the old DRB needs to be configured in the target cell. For in-order delivery in the DL, the target gNB should first transmit the forwarded PDCP SDUs on the old DRB before transmitting new data from 5GC on the new DRB. In the UL, the target gNB should not deliver data of the QoS flow from the new DRB to 5GC before receiving the end marker on the old DRB from the UE.

– The UE does not retransmit any PDCP SDU in the target cell for which transmission had been completed in the source cell.

For DAPS handover:

A DAPS handover can be used for an RLC-AM or RLC-UM bearer. For a DRB configured with DAPS, the following principles are additionally applied.

Downlink:

– During HO preparation, a forwarding tunnel is always established.

– The source gNB is responsible for allocating downlink PDCP SNs until the SN assignment is handed over to the target gNB and data forwarding in 9.2.3.2.3 takes place. That is, the source gNB does not stop assigning PDCP SNs to downlink packets until it receives the HANDOVER SUCCESS message and sends the SN STATUS TRANSFER message to the target gNB.

– Upon allocation of downlink PDCP SNs by the source gNB, it starts scheduling downlink data on the source radio link and also starts forwarding downlink PDCP SDUs along with assigned PDCP SNs to the target gNB.

– For security synchronisation, HFN is maintained for the forwarded downlink SDUs with PDCP SNs assigned by the source gNB. The source gNB sends the EARLY STATUS TRANSFER message to convey the DL COUNT value, indicating PDCP SN and HFN of the first PDCP SDU that the source gNB forwards to the target gNB.

– HFN and PDCP SN are maintained after the SN assignment is handed over to the target gNB. The SN STATUS TRANSFER message indicates the next DL PDCP SN to allocate to a packet which does not have a PDCP sequence number yet, even for RLC-UM.

– During handover execution period, the source and target gNBs separately perform ROHC header compression, ciphering, and adding PDCP header.

– During handover execution period, the UE continues to receive downlink data from both source and target gNBs until the source gNB connection is released by an explicit release command from the target gNB.

– During handover execution period, the UE PDCP entity configured with DAPS maintains separate security and ROHC header decompression functions associated with each gNB, while maintaining common functions for reordering, duplicate detection and discard, and PDCP SDUs in-sequence delivery to upper layers. PDCP SN continuity is supported for both RLC AM and UM DRBs configured with DAPS.

Uplink:

– The UE transmits UL data to the source gNB until the random access procedure toward the target gNB has been successfully completed. Afterwards the UE switches its UL data transmission to the target gNB.

– Even after switching its UL data transmissions towards the target gNB, the UE continues to send UL layer 1 CSI feedback, HARQ feedback, layer 2 RLC feedback, ROHC feedback, HARQ data (re-)transmissions, and RLC data (re-)transmissions to the source gNB.

– During handover execution period, the UE maintains separate security context and ROHC header compressor context for uplink transmissions towards the source and target gNBs. The UE maintains common UL PDCP SN allocation. PDCP SN continuity is supported for both RLC AM and UM DRBs configured with DAPS.

– During handover execution period, the source and target gNBs maintain their own security and ROHC header decompressor contexts to process UL data received from the UE.

– The establishment of a forwarding tunnel is optional.

– HFN and PDCP SN are maintained in the target gNB. The SN STATUS TRANSFER message indicates the COUNT of the first missing PDCP SDU that the target should start delivering to the 5GC, even for RLC-UM.

9.2.3.2.3 Data Forwarding

The following description depicts the data forwarding principles for intra-system handover.

The source NG-RAN node may suggest downlink data forwarding per QoS flow established for a PDU session and may provide information how it maps QoS flows to DRBs. The target NG-RAN node decides data forwarding per QoS flow established for a PDU Session.

If "lossless handover" is required and the QoS flows to DRB mapping applied at the target NG-RAN node allows applying for data forwarding the same QoS flows to DRB mapping as applied at the source NG-RAN node for a DRB and if all QoS flows mapped to that DRB are accepted for data forwarding, the target NG-RAN node establishes a downlink forwarding tunnel for that DRB.

For a DRB for which preservation of SN status applies, the target NG-RAN node may decide to establish an UL data forwarding tunnel.

The target NG-RAN node may also decide to establish a downlink forwarding tunnel for each PDU session. In this case the target NG-RAN node provides information for which QoS flows data forwarding has been accepted and corresponding UP TNL information for data forwarding tunnels to be established between the source NG-RAN node and the target NG-RAN node.

If QoS flows have been re-mapped at the source NG-RAN node and user packets along the old source mapping are still being processed at handover preparation, and if the source NG-RAN node has not yet received the SDAP end marker for certain QoS flows when providing the SN status to the target NG-RAN node, the source NG-RAN node provides the old side QoS mapping information for UL QoS flows to the target NG-RAN node for which no SDAP end marker was yet received. The target NG-RAN will receive for those QoS flows the end marker when the UE finalises to send UL user data according to the old source side mapping.

The source NG-RAN node may also propose to establish uplink forwarding tunnels for some PDU sessions in order to transfer SDAP SDUs corresponding to QoS flows for which flow re-mapping happened before the handover and the SDAP end marker has not yet been received, and for which user data was received at the source NG-RAN node via the DRB to which the QoS flow was remapped. If accepted the target NG-RAN node shall provide the corresponding UP TNL information for data forwarding tunnels to be established between the source NG-RAN node and the target NG-RAN node.

As long as data forwarding of DL user data packets takes place, the source NG-RAN node shall forward user data in the same forwarding tunnel, i.e.

– for any QoS flow accepted for data forwarding by the target NG-RAN node and for which a DRB DL forwarding tunnel was established for a DRB to which this QoS flow was mapped at the source NG-RAN node, any fresh packets of this QoS flow shall be forwarded as PDCP SDUs via the mapped DRB DL forwarding tunnel.

– for DRBs for which preservation of SN status applies, the source NG-RAN node may forward in order to the target NG-RAN node via the DRB DL forwarding tunnel all downlink PDCP SDUs with their SN corresponding to PDCP PDUs which have not been acknowledged by the UE.

NOTE: The SN of forwarded PDCP SDUs is carried in the "PDCP PDU number" field of the GTP-U extension header.

– for any QoS flow accepted for data forwarding by the target NG-RAN node for which a DL PDU session forwarding tunnel was established, the source NG-RAN node forwards SDAP SDUs as received on NG-U from the UPF.

For handovers involving Full Configuration, the source NG-RAN node behaviour is unchanged from the description above. In case a DRB DL forwarding tunnel was established, the target NG-RAN node may identify the PDCP SDUs for which delivery was attempted by the source NG-RAN node, by the presence of the PDCP SN in the forwarded GTP-U packet and may discard them.

As long as data forwarding of UL user data packets takes place for DRBs for which preservation of SN status applies the source NG-RAN node either:

– discards the uplink PDCP PDUs received out of sequence if the source NG-RAN node has not accepted the request from the target NG-RAN node for uplink forwarding or if the target NG-RAN node has not requested uplink forwarding for the bearer during the Handover Preparation procedure; or

– forwards to the target NG-RAN node via the corresponding DRB UL forwarding tunnel, the uplink PDCP SDUs with their SN corresponding to PDCP PDUs received out of sequence if the source NG-RAN node has accepted the request from the target NG-RAN node for uplink forwarding for the bearer during the Handover Preparation procedure, including PDCP SDUs corresponding to user data of those QoS flows, for which re-mapping happened for a QoS flow before the handover and the SDAP end marker has not yet been received at the source NG-RAN node.

As long as data forwarding of UL user data packets takes place for a PDU session, the source NG-RAN node forwards via the corresponding PDU session UL forwarding tunnel, the uplink SDAP SDUs corresponding to QoS flows for which flow re-mapping happened before the handover and the SDAP end marker has not yet been received at the source NG-RAN node, and which were received at the source NG-RAN node via the DRB to which the QoS flow was remapped.

For DRBs configured with DAPS handover, data forwarding after the source gNB receives the HANDOVER SUCCESS message from the target gNB follows the same behaviors as described above.

For DRBs configured with DAPS handover, before the source gNB receives the HANDOVER SUCCESS message:

– The source gNB may forward to the target gNB downlink PDCP SDUs with SNs assigned by the source gNB. No downlink PDCP SDU without a SN assigned or SDAP SDU is forwarded. No uplink PDCP SDU or SDAP SDU is forwarded.

– The source gNB sends the EARLY STATUS TRANSFER message to maintain HFN continuity by indicating PDCP SN and HFN of the first PDCP SDU that the source gNB forwards to the target gNB. The subsequent messages may be sent for discarding of already forwarded downlink PDCP SDUs in the target gNB.

– The source gNB does not stop transmitting downlink packets to the UE. The source gNB keeps forwarding to the 5GC the uplink SDAP SDUs successfully received in-sequence from the UE.

Handling of end marker packets:

– The source NG-RAN node receives one or several GTP-U end marker packets per PDU session from the UPF and replicates the end marker packets into each data forwarding tunnel when no more user data packets are to be forwarded over that tunnel.

– End marker packets sent via a data forwarding tunnel are applicable to all QoS flows forwarded via that tunnel. After end marker packets have been received over a forwarding tunnel, the target NG-RAN node can start taking into account the packets of QoS flows associated with that forwarding tunnel received at the target NG-RAN node from the NG-U PDU session tunnel.

9.2.3.3 Re-establishment procedure

A UE in RRC_CONNECTED may initiate the re-establishment procedure to continue the RRC connection when a failure condition occurs (e.g. radio link failure, reconfiguration failure, integrity check failure…).

The following figure describes the re-establishment procedure started by the UE:

Figure 9.2.3.3-1: Re-establishment procedure

1. The UE re-establishes the connection, providing the UE Identity (PCI+C-RNTI) to the gNB where the trigger for the re-establishment occurred.

2. If the UE Context is not locally available, the gNB, requests the last serving gNB to provide UE Context data.

3. The last serving gNB provides UE context data.

4/4a. The gNB continues the re-establishment of the RRC connection. The message is sent on SRB1.

5/5a. The gNB may perform the reconfiguration to re-establish SRB2 and DRBs when the re-establishment procedure is ongoing.

6/7. If loss of user data buffered in the last serving gNB shall be prevented, the gNB provides forwarding addresses, and the last serving gNB provides the SN status to the gNB.

8/9. The gNB performs path switch.

10. The gNB triggers the release of the UE resources at the last serving gNB.

The IAB-MT in SA mode follows the same re-establishment procedure as described for the UE. After the backhaul has been established, the re-establishment procedure of the IAB-MT is part of the intra-CU backhaul RLF recovery procedure for IAB-nodes defined in TS 38.401 [4]. Modifications to the configuration of BAP sublayer and higher protocol layers above the BAP sublayer are described in TS 38.401 [4].

9.2.3.4 Conditional Handover

9.2.3.4.1 General

A Conditional Handover (CHO) is defined as a handover that is executed by the UE when one or more handover execution conditions are met. The UE starts evaluating the execution condition(s) upon receiving the CHO configuration, and stops evaluating the execution condition(s) once a handover is executed.

The following principles apply to CHO:

– The CHO configuration contains the configuration of CHO candidate cell(s) generated by the candidate gNB(s) and execution condition(s) generated by the source gNB.

– An execution condition may consist of one or two trigger condition(s) (CHO events A3/A5, as defined in [12]). Only single RS type is supported and at most two different trigger quantities (e.g. RSRP and RSRQ, RSRP and SINR, etc.) can be configured simultaneously for the evalution of CHO execution condition of a single candidate cell.

– Before any CHO execution condition is satisfied, upon reception of HO command (without CHO configuration), the UE executes the HO procedure as described in clause 9.2.3.2, regardless of any previously received CHO configuration.

– While executing CHO, i.e. from the time when the UE starts synchronization with target cell, UE does not monitor source cell.

CHO is also supported for the IAB-MT in context of intra- and inter-donor IAB-node migration and BH RLF recovery.

CHO is not supported for NG-C based handover in this release of the specification.

9.2.3.4.2 C-plane handling

As in intra-NR RAN handover, in intra-NR RAN CHO, the preparation and execution phase of the conditional handover procedure is performed without involvement of the 5GC; i.e. preparation messages are directly exchanged between gNBs. The release of the resources at the source gNB during the conditional handover completion phase is triggered by the target gNB. The figure below depicts the basic conditional handover scenario where neither the AMF nor the UPF changes:

Figure 9.2.3.4.2-1: Intra-AMF/UPF Conditional Handover

0/1. Same as step 0, 1 in Figure 9.2.3.2.1-1 of clause 9.2.3.2.1.

2. The source gNB decides to use CHO.

3. The source gNB requests CHO for one or more candidate cells belonging to one or more candidate gNBs. A CHO request message is sent for each candidate cell.

4. Same as step 4 in Figure 9.2.3.2.1-1 of clause 9.2.3.2.1.

5. The candidate gNB(s) sends CHO response (HO REQUEST ACKNOWLEDGE) including configuration of CHO candidate cell(s) to the source gNB. The CHO response message is sent for each candidate cell.

6. The source gNB sends an RRCReconfiguration message to the UE, containing the configuration of CHO candidate cell(s) and CHO execution condition(s).

NOTE 1: CHO configuration of candidate cells can be followed by other reconfiguration from the source gNB.

NOTE 1a: A configuration of a CHO candidate cell cannot contain a DAPS handover configuration.

7. The UE sends an RRCReconfigurationComplete message to the source gNB.

7a If early data forwarding is applied, the source gNB sends the EARLY STATUS TRANSFER message.

8. The UE maintains connection with the source gNB after receiving CHO configuration, and starts evaluating the CHO execution conditions for the candidate cell(s). If at least one CHO candidate cell satisfies the corresponding CHO execution condition, the UE detaches from the source gNB, applies the stored corresponding configuration for that selected candidate cell, synchronises to that candidate cell and completes the RRC handover procedure by sending RRCReconfigurationComplete message to the target gNB. The UE releases stored CHO configurations after successful completion of RRC handover procedure.

8a/b The target gNB sends the HANDOVER SUCCESS message to the source gNB to inform that the UE has successfully accessed the target cell. In return, the source gNB sends the SN STATUS TRANSFER message following the principles described in step 7 of Intra-AMF/UPF Handover in clause 9.2.3.2.1.

NOTE 2: Late data forwarding may be initiated as soon as the source gNB receives the HANDOVER SUCCESS message.

8c. The source gNB sends the HANDOVER CANCEL message toward the other signalling connections or other candidate target gNBs, if any, to cancel CHO for the UE.

9.2.3.4.3 U-plane handling

The U-plane handling for Conditional Handover follows the same principles for DAPS handover in 9.2.3.2.2, if early data forwarding is applied, except that, in case of Full Configuration, HFN and PDCP SN are reset in the target gNB after the SN assignment is handed over to the target gNB. If late data forwarding is applied, the U-plane handling follows the RLC-AM or RLC-UM bearer principles defined in 9.2.3.2.2.

9.2.3.4.4 Data Forwarding

If late data forwarding is applied, the source NG-RAN node initiates data forwarding once it knows which target NG-RAN node the UE has successfully accessed. In that case the behavior of the Conditional Handover data forwarding follows the same behavior as defined in 9.2.3.2.3 for the intra-system handover data forwarding, except the behavior for DRBs configured with DAPS handover.

If early data forwarding is applied instead, the source NG-RAN node initiates data forwarding before the UE executes the handover, to a candidate target node of interest. The behavior of early data forwarding for the Conditional Handover follows the same principles for DRBs configured with DAPS handover in the intra-system handover as defined in 9.2.3.2.3.