Content for  TS 38.300  Word version:  18.4.0

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:

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:

1. Common RACH configuration;
2. Common RACH configuration + Dedicated RACH configuration associated with SSB;
3. 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.

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.
• 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;
• 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 clause 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.

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

If the data forwarding is performed and the source NG-RAN node receives SDAP SDUs with PDU Set Information Container in the GTP-U extension header on NG-U from the UPF and the target NG-RAN node supports PDU Set based handling, the source NG-RAN node forwards either the PDCP SDUs for DRB-level data forwarding or the SDAP SDUs for PDU-session-level data forwarding with the corresponding PDU Set Information Container in the GTP-U extension header to the target NG-RAN node. 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 behaviours 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.