8.2 Basic mobility procedures

38.4233GPPNG-RANRelease 17TSXn Application Protocol (XnAP)

8.2.1 Handover Preparation

8.2.1.1 General

This procedure is used to establish necessary resources in an NG-RAN node for an incoming handover. If the procedure concerns a conditional handover, parallel transactions are allowed. Possible parallel requests are identified by the target cell ID when the source UE AP IDs are the same.

The procedure uses UE-associated signalling.

8.2.1.2 Successful Operation

Figure 8.2.1.2-1: Handover Preparation, successful operation

The source NG-RAN node initiates the procedure by sending the HANDOVER REQUEST message to the target NG-RAN node. When the source NG-RAN node sends the HANDOVER REQUEST message, it shall start the timer TXnRELOCprep.

If the Conditional Handover Information Request IE is contained in the HANDOVER REQUEST message, the target NG-RAN node shall consider that the request concerns a conditional handover and shall include the Conditional Handover Information Acknowledge IE in the HANDOVER REQUEST ACKNOWLEDGE message.

If the Target NG-RAN node UE XnAP ID IE is contained in the Conditional Handover Information Request IE included in the HANDOVER REQUEST message, then the target NG-RAN node shall remove the existing prepared conditional HO identified by the Target NG-RAN node UE XnAP ID IE and the Target Cell Global ID IE. It is up to the implementation of the target NG-RAN node when to remove the HO information.

Upon reception of the HANDOVER REQUEST ACKNOWLEDGE message, the source NG-RAN node shall stop the timer TXnRELOCprep and terminate the Handover Preparation procedure. If the procedure was initiated for an immediate handover, the source NG-RAN node shall start the timer TXnRELOCoverall. The source NG-RAN node is then defined to have a Prepared Handover for that Xn UE-associated signalling.

For each E-RAB ID IE included in the QoS Flow To Be Setup List IE in the HANDOVER REQUEST message, the target NG-RAN node shall, if supported, store the content of the IE in the UE context and use it for subsequent inter-system handover.

If the Masked IMEISV IE is contained in the HANDOVER REQUEST message the target NG-RAN node shall, if supported, use it to determine the characteristics of the UE for subsequent handling.

At reception of the HANDOVER REQUEST message the target NG-RAN node shall prepare the configuration of the AS security relation between the UE and the target NG-RAN node by using the information in the UE Security Capabilities IE and the AS Security Information IE in the UE Context Information IE, as specified in TS 33.501 [28].

Upon reception of the PDU Session Resource Setup List IE, contained in the HANDOVER REQUEST message, the target NG-RAN node shall behave the same as specified in TS 38.413 [5] for the PDU Session Resource Setup procedure. The target NG-RAN node shall report in the HANDOVER REQUEST ACKNOWLEDGE message the successful establishment of the result for all the requested PDU session resources. When the target NG-RAN node reports the unsuccessful establishment of a PDU session resource, the cause value should be precise enough to enable the source NG-RAN node to know the reason for the unsuccessful establishment.

For each PDU session if the PDU Session Aggregate Maximum Bit Rate IE is included in the PDU Session Resources To Be Setup List IE contained in the HANDOVER REQUEST message, the target NG-RAN node shall store the received PDU Session Aggregate Maximum Bit Rate in the UE context and use it when enforcing traffic policing for Non-GBR QoS flows for the concerned UE as specified in TS 23.501 [7].

For each QoS flow for which the source NG-RAN node proposes to perform forwarding of downlink data, the source NG-RAN node shall include the DL Forwarding IE set to "DL forwarding proposed" within the Data Forwarding and Offloading Info from source NG-RAN node IE in the PDU Session Resources To Be Setup List IE in the HANDOVER REQUEST message. The source NG-RAN node shall include the DL Forwarding IE set to "DL forwarding proposed" for all the QoS flows mapped to a DRB, if it requests a DAPS handover for that DRB.

For each PDU session for which the target NG-RAN node decides to admit the data forwarding for at least one QoS flow, the target NG-RAN node may include the PDU Session level DL data forwarding UP TNL Information IE within the Data Forwarding Info from target NG-RAN node IE in the PDU Session Resource Admitted Info IE contained in the PDU Session Resources Admitted List IE in the HANDOVER REQUEST ACKNOWLEDGE message.

For each QoS flow for which the source NG-RAN node has not yet received the SDAP end marker packet if QoS flow re-mapping happened before handover, the source NG-RAN node shall include the UL Forwarding Proposal IE within the Data Forwarding and Offloading Info from source NG-RAN node IE in the HANDOVER REQUEST message, and if the target NG-RAN node decides to admit uplink data forwarding for at least one QoS flow, the target NG-RAN node may include the PDU Session Level UL Data Forwarding UP TNL Information IE in the Data Forwarding Info from target NG-RAN node IE in the PDU Session Resources Admitted Item IE contained in the PDU Session Resources Admitted List IE in the HANDOVER REQUEST ACKNOWLEDGE message to indicate that it accepts the uplink data forwarding.

For each PDU session resource successfully setup at the target NG-RAN, the target NG-RAN node may allocate resources for additional Xn-U PDU session resource GTP-U tunnels, indicated in the Secondary Data Forwarding Info from target NG-RAN node List IE.

For each PDU session in the HANDOVER REQUEST message, if the Alternative QoS Parameters Set List IE is included in the GBR QoS Flow Information IE in the PDU Session Resources To Be Setup List IE, the target NG-RAN node may accept the setup of the involved QoS flow when notification control has been enabled if the requested QoS parameters set or at least one of the alternative QoS parameters sets can be fulfilled at the time of handover as specified in TS 23.501 [7]. In case the target NG-RAN node accepts the handover fulfilling one of the alternative QoS parameters it shall indicate the alternative QoS parameters set which it can currently fulfil in the Current QoS Parameters Set Index IE within the PDU Session Resources Admitted List IE of the HANDOVER REQUEST ACKNOWLEDGE message while setting the QoS parameters towards the UE according to the requested QoS parameters set as specified in TS 23.501 [7].

For each DRB for which the source NG-RAN node proposes to perform forwarding of downlink data, the source NG-RAN node shall include the DRB ID IE and the mapped QoS Flows List IE within the Source DRB to QoS Flow Mapping List IE contained in the PDU Session Resources To Be Setup List IE in the HANDOVER REQUEST message. The source NG-RAN node may include the QoS Flow Mapping Indication IE in the Source DRB to QoS Flow Mapping List IE to indicate that only the uplink or downlink QoS flow is mapped to the DRB. If the target NG-RAN node decides to use the same DRB configuration and to map the same QoS flows as the source NG-RAN node, the target NG-RAN node includes the DL Forwarding GTP Tunnel Endpoint IE within the Data Forwarding Response DRB List IE in the HANDOVER REQUEST ACKNOWLEDGE message to indicate that it accepts the proposed forwarding of downlink data for this DRB.

The target NG-RAN node may additionally include the Redundant DL Forwarding UP TNL Information IE if at least one of the QoS flow mapped to the DRB is eligible to the redundant transmission feature as indicated in the Redundant QoS Flow Indicator IE within the PDU Session Resource To Be Setup List IE received in the HANDOVER REQUEST message for the QoS flow.

If the HANDOVER REQUEST ACKNOWLEDGE message contains the UL Forwarding UP TNL Information IE for a given DRB in the Data Forwarding Response DRB List IE within Data Forwarding Info from target NG-RAN node IE in the PDU Session Resources Admitted List IE and the source NG-RAN node accepts the data forwarding proposed by the target NG-RAN node, the source NG-RAN node shall perform forwarding of uplink data for the DRB.

If the HANDOVER REQUEST includes PDU session resources for PDU sessions associated to S-NSSAIs not supported by target NG-RAN, the target NG-RAN node shall reject such PDU session resources. In this case, and if at least one PDU Session Resource To Be Setup Item IE is admitted, the target NG-RAN node shall send the HANDOVER REQUEST ACKNOWLEDGE message including the PDU Session Resources Not Admitted List IE listing corresponding PDU sessions rejected at the target NG-RAN.

If the Mobility Restriction List IE is

– contained in the HANDOVER REQUEST message, the target NG-RAN node shall

– store the information received in the Mobility Restriction List IE in the UE context;

– use this information to determine a target for the UE during subsequent mobility action for which the NG-RAN node provides information about the target of the mobility action towards the UE, except when one of the PDU sessions has a particular ARP value (TS 23.501 [7]) in which case the information shall not apply;

– use this information to select a proper SCG during dual connectivity operation.

– use this information to select proper RNA(s) for the UE when moving the UE to RRC_INACTIVE.

– not contained in the HANDOVER REQUEST message, the target NG-RAN node shall

– consider that no roaming and no access restriction apply to the UE except for the PNI-NPN mobility as described in TS 23.501 [7].

The target NG-RAN node shall consider that roaming or access to CAG cells is only allowed if the Allowed PNI-NPN ID List IE is contained in the HANDOVER REQUEST message, as described in TS 23.501 [7].

If the Trace Activation IE is included in the HANDOVER REQUEST message the target NG-RAN node shall, if supported, initiate the requested trace function as specified in TS 32.422 [23].

If the Index to RAT/Frequency Selection Priority IE is contained in the HANDOVER REQUEST message, the target NG-RAN node shall store this information and use it as defined in TS 23.501 [7].

If the UE Context Reference at the S-NG-RAN IE is contained in the HANDOVER REQUEST message the target NG-RAN node may use it as specified in TS 37.340 [8]. In this case, the source NG-RAN node may expect the target NG-RAN node to include the UE Context Kept Indicator IE set to "True" in the HANDOVER REQUEST ACKNOWLEDGE message, which shall use this information as specified in TS 37.340 [8].

For each PDU session, if the Network Instance IE is included in the PDU Session Resource To Be Setup List IE and the Common Network Instance IE is not present, the target NG-RAN node shall, if supported, use it when selecting transport network resource as specified in TS 23.501 [7].

Redundant transmission:

– For each PDU session, if the Redundant UL NG-U UP TNL Information at UPF IE is included in the PDU Session Resource To Be Setup List IE, the target NG-RAN node shall, if supported, use it as the uplink termination point for the user plane data for the redundant transmission for the concerned PDU session.

– For each PDU session, if the Additional Redundant UL NG-U UP TNL Information at UPF List IE is included in the PDU Session Resource To Be Setup List IE, the target NG-RAN node shall, if supported, use them as the uplink termination points for the user plane data for the redundant transmission for the concerned PDU session.

– For each PDU session, if the Redundant Common Network Instance IE is included in the PDU Session Resource To Be Setup List IE, the target NG-RAN node shall, if supported, use it when selecting transport network resource for the redundant transmission as specified in TS 23.501 [7].

– For each PDU session, if the Redundant PDU Session Information IE is included in the PDU Session Resource To Be Setup List IE contained in the HANDOVER REQUEST message, the target NG-RAN node shall, if supported, store the received information in the UE context and set up the redundant user plane for the concerned PDU session, as specified in TS 23.501 [7]. If the PDU Session Pair ID IE is included in the Redundant PDU Session Information IE, the target NG-RAN node may store and use it to identify the paired PDU sessions.

If the TSC Traffic Characteristics IE is included in the QoS Flows To Be Setup List in the PDU Session Resource To Be Setup List IE, the target NG-RAN node shall, if supported, use it as specified in TS 23.501 [7].

For each PDU session, if the Common Network Instance IE is included in the PDU Session Resource To Be Setup List IE or in the Additional UL NG-U UP TNL Information at UPF List IE, or in the Additional Redundant UL NG-U UP TNL Information at UPF List IE, the target NG-RAN node shall, if supported, use it when selecting transport network resource for the concerned NG-U transport bearer as specified in TS 23.501 [7].

For each PDU session for which the Security Indication IE is included in the PDU Session Resource To Be Setup List IE and the Integrity Protection Indication IE or Confidentiality Protection Indication IE is set to "required", the target NG-RAN node shall perform user plane integrity protection or ciphering, respectively. If the NG-RAN node is not able to perform the user plane integrity protection or ciphering, it shall reject the setup of the PDU Session Resources with an appropriate cause value.

If the NG-RAN node is an ng-eNB, it shall reject all PDU sessions for which the Integrity Protection Indication IE is set to "required".

For each PDU session for which the Security Indication IE is included in the PDU Session Resource To Be Setup List IE and the Integrity Protection Indication IE or the Confidentiality Protection Indication IE is set to "preferred", the target NG-RAN node should, if supported, perform user plane integrity protection or ciphering, respectively and shall notify the SMF whether it succeeded the user plane integrity protection or ciphering or not for the concerned security policy.

For each PDU session for which the Maximum Integrity Protected Data Rate IE is included in the Security Indication IE in the PDU Session Resources To Be Setup List IE, the NG-RAN node shall store the respective information and, if integrity protection is to be performed for the PDU session, it shall enforce the traffic corresponding to the received Maximum Integrity Protected Data Rate IE, for the concerned PDU session and concerned UE, as specified in TS 23.501 [7].

For each PDU session for which the Security Indication IE is included in the PDU Session Resource To Be Setup List IE and the Integrity Protection Indication IE or Confidentiality Protection Indication IE is set to "not needed", the target NG-RAN node shall not perform user plane integrity protection or ciphering, respectively, for the concerned PDU session.

For each PDU session, if the Additional UL NG-U UP TNL Information List IE is included in the PDU Session Resources To Be Setup List IE contained in the HANDOVER REQUEST message, the target NG-RAN node may forward the UP transport layer information to the target S-NG-RAN node as the uplink termination point for the user plane data for this PDU session split in different tunnel.

If the Location Reporting Information IE is included in the HANDOVER REQUEST message, then the target NG-RAN node should initiate the requested location reporting functionality as defined in TS 38.413 [5].

Upon reception of UE History Information IE in the HANDOVER REQUEST message, the target NG-RAN node shall collect the information defined as mandatory in the UE History Information IE and shall, if supported, collect the information defined as optional in the UE History Information IE, for as long as the UE stays in one of its cells, and store the collected information to be used for future handover preparations.

If the Trace Activation IE is included in the HANDOVER REQUEST message which includes

– the MDT Activation IE set to "Immediate MDT and Trace", then the target NG-RAN node shall if supported, initiate the requested trace session and MDT session as described in TS 32.422 [23].

– the MDT Activation IE set to "Immediate MDT Only" or "Logged MDT only", the target NG-RAN node shall, if supported, initiate the requested MDT session as described in TS 32.422 [23] and the target NG-RAN node shall ignore the Interfaces To Trace IE, and the Trace Depth IE.

– the MDT Location Information IE, within the MDT Configuration IE, the target NG-RAN node shall, if supported, store this information and take it into account in the requested MDT session.

– the MDT Activation IE set to "Immediate MDT Only" or "Logged MDT only", and if the Signalling based MDT PLMN List IE is included in the MDT Configuration IE, the target NG-RAN node may use it to propagate the MDT Configuration as described in TS 37.320 [43].

– the Bluetooth Measurement Configuration IE, within the MDT Configuration IE, the target NG-RAN node shall, if supported, take it into account for MDT Configuration as described in TS 37.320 [43].

– the WLAN Measurement Configuration IE, within the MDT Configuration IE, the target NG-RAN node shall, if supported, take it into account for MDT Configuration as described in TS 37.320 [43].

– the Sensor Measurement Configuration IE, within the MDT Configuration IE, the target NG-RAN node shall take it into account for MDT Configuration as described in TS 37.320 [43].

– the MDT Configuration IE and if the target NG-RAN node is a gNB receiving a MDT Configuration-EUTRA IE, or the target NG-RAN node is a ng-eNB receiving a MDT Configuration-NR IE, the target NG-RAN node shall store it as part of the UE context, and use it as described in TS 37.320 [43].

If the Management Based MDT PLMN List IE is contained in the HANDOVER REQUEST message, the target NG-RAN node shall, if supported, store the received information in the UE context, and use this information to allow subsequent selection of the UE for management based MDT defined in TS 32.422 [23].

If the HANDOVER REQUEST message includes the Management Based MDT PLMN List IE, the target NG-RAN node shall, if supported, store it in the UE context, and take it into account if it includes information regarding the PLMN serving the UE in the target NG-RAN node.

If the Mobility Information IE is provided in the HANDOVER REQUEST message, the target NG-RAN node shall, if supported, store this information. The target NG-RAN shall, if supported, store the C-RNTI assigned at the source cell as received in the HANDOVER REQUEST message.

Upon reception of the UE History Information from the UE IE in the HANDOVER REQUEST message, the target NG-RAN node shall, if supported, store the collected information and use it for future handover preparations.

For each QoS flow which has been successfully established in the target NG-RAN node, if the QoS Monitoring Request IE was included in the QoS Flow Level QoS Parameters IE contained in the HANDOVER REQUEST message, the target NG-RAN node shall store this information, and shall, if supported, perform delay measurement and QoS monitoring, as specified in TS 23.501 [7]. If the QoS Monitoring Reporting Frequency IE was included in the QoS Flow Level QoS Parameters IE contained in the HANDOVER REQUEST message, the target NG-RAN node shall store this information, and shall, if supported, use it for RAN part delay reporting.

If the 5GC Mobility Restriction List Container IE is included in the HANDOVER REQUEST message, the target NG-RAN node shall, if supported, store this information in the UE context and use it as specified in TS 38.300 [9].

V2X:

– If the NR V2X Services Authorized IE is included in the HANDOVER REQUEST message and it contains one or more IEs set to "authorized", the target NG-RAN node shall, if supported, consider that the UE is authorized for the relevant service(s).

– If the LTE V2X Services Authorized IE is included in the HANDOVER REQUEST message and it contains one or more IEs set to "authorized", the target NG-RAN node shall, if supported, consider that the UE is authorized for the relevant service(s).

– If the NR UE Sidelink Aggregate Maximum Bit Rate IE is included in the HANDOVER REQUEST message, the target NG-RAN node shall, if supported, use the received value for the concerned UE’s sidelink communication in network scheduled mode for NR V2X services.

– If the LTE UE Sidelink Aggregate Maximum Bit Rate IE is included in the HANDOVER REQUEST message, the target NG-RAN node shall, if supported, use the received value for the concerned UE’s sidelink communication in network scheduled mode for LTE V2X services.

5G ProSe:

– If the 5G ProSe Authorized IE is included in the HANDOVER REQUEST message and it contains one or more IEs set to "authorized", the target NG-RAN node shall, if supported, consider that the UE is authorized for the relevant service(s).

– If the 5G ProSe UE PC5 Aggregate Maximum Bit Rate IE is included in the HANDOVER REQUEST message, the target NG-RAN node shall, if supported, use the received value for the concerned UE’s sidelink communication in network scheduled mode for 5G ProSe services.

– If the 5G ProSe PC5 QoS Parameters IE is included in the HANDOVER REQUEST message, the target NG-RAN node shall, if supported, use it as defined in TS 23.304 [48].

If the PC5 QoS Parameters IE is included in the HANDOVER REQUEST message, the target NG-RAN node shall, if supported, use it as defined in TS 23.287 [38].

If the DAPS Request Information IE is included for a given DRB in the HANDOVER REQUEST message, the target NG-RAN node shall consider that the request concerns a DAPS handover for that DRB, as described in TS 38.300 [9]. Accordingly, the target NG-RAN node shall include the DAPS Response Information IE in the HANDOVER REQUEST ACKNOWLEDGE message.

If the Maximum Number of CHO Preparations IE is included in the Conditional Handover Information Acknowledge IE contained in the HANDOVER REQUEST ACKNOWLEDGE message, then the source NG-RAN node should not prepare more candidate target cells for a CHO for the same UE towards the target NG-RAN node than the number indicated in the IE.

If the Estimated Arrival Probability IE is contained in the Conditional Handover Information Request IE included in the HANDOVER REQUEST message, then the target NG-RAN node may use the information to allocate necessary resources for the incoming CHO.

If the IAB Node Indication IE is contained in the HANDOVER REQUEST message, the target NG-RAN node shall, if supported, consider that the handover is for an IAB node. In addition:

– If the No PDU Session Indication IE is contained in the HANDOVER REQUEST message, the target NG-RAN node shall, if supported, consider the UE as an IAB-node which does not have any PDU sessions activated, and ignore the PDU Session Resources To Be Setup List IE, and shall not take any action with respect to PDU session setup. Subsequently, the source NG-RAN node shall, if supported, ignore the PDU Session Resources Admitted To Be Added List IE in the HANDOVER REQUEST ACKNOWLEDGE message.

If the UE Radio Capability ID IE is contained in the HANDOVER REQUEST message, the target NG-RAN node shall, if supported, store this information in the UE context and use it as defined in TS 23.501 [7] and TS 23.502 [13].

If for a given QoS Flow the Source DL Forwarding IP Address IE is included within the Data Forwarding and Offloading Info from source NG-RAN node IE in the PDU Session Resources To Be Setup List IE contained in the HANDOVER REQUEST message, the target NG-RAN node shall, if supported, store this information and use it as part of its ACL functionality configuration actions, if such ACL functionality is deployed.

If the MBS Session Information List IE is contained in the HANDOVER REQUEST message, the target NG-RAN node shall, if supported, establish an NG-RAN MBS session resources context as specified in TS 23.247 [46] and TS 38.300 [9], if applicable.

If the HANDOVER REQUEST message includes the MBS Area Session ID IE, the target NG-RAN, if supported, shall use this information as an indication from which MBS Area Session ID the UE is handed over. For each MBS session for which the Active MBS Session Information IE is included in the MBS Session Information Item List IE, the target NG-RAN shall, if supported, use this information to setup respective MBS session resources. The target NG-RAN node shall, if supported, consider that the MBS sessions for which the Active MBS Session Information IE is not included are inactive.

If the HANDOVER REQUEST ACKNOWLEDGE message contains in the MBS Session Information Response List IE the MBS Data Forwarding Response Info IE that the source NG-RAN node shall use the information for forwarding MBS traffic to the target NG-RAN node.

If the MBS Session Associated Information List IE is included in the PDU Session Resources To Be Setup List IE in the HANDOVER REQUEST message, the target NG-RAN node shall, if supported, use the information contained in the Associated QoS Flows Information List IE as specified in TS 23.247 [46].

For each MRB indicated in the MBS Mapping and Data Forwarding Request Info from source NG-RAN node IE, the target NG-RAN node shall use the MRB ID IE and, if included, the MRB Progress Information IE which includes the highest PDCP SN of the packet which has already been delivered to the UE for the MRB, to decide whether to apply data forwarding for that MRB and to establish respective resources.

The source NG-RAN shall, for each MRB in the MBS Data Forwarding Response Info from target NG-RAN node IE in the HANDOVER REQUEST ACKNOWLEDGE message, start data forwarding to the indicated DL Forwarding UP TNL Information. If the MRB Progress Information IE is included the source NG-RAN node may use the information to determine when to stop data forwarding.

If the Time Synchronisation Assistance Information IE is contained in the HANDOVER REQUEST message, the target NG-RAN node shall, if supported, store this information in the UE context and use it as defined in TS 23.501 [7].

If the QMC Configuration Information IE is contained in the HANDOVER REQUEST message, the target NG-RAN node shall, if supported, take it into account for QoE measurements handling, as described in TS 38.300 [9].

If the UE Slice-Maximum Bit Rate List IE is contained in HANDOVER REQUEST message, the target NG-RAN node shall, if supported, store the received UE Slice Maximum Bit Rate List in the UE context, and use the received UE Slice Maximum Bit Rate value for each S-NSSAI for the concerned UE as specified in TS 23.501 [7].

Interaction with SN Status Transfer procedure:

If the UE Context Kept Indicator IE set to "True" and the DRBs transferred to MN IE are included in the HANDOVER REQUEST ACKNOWLEDGE message, the source NG-RAN node shall, if supported, include the uplink/downlink PDCP SN and HFN status received from the S-NG-RAN node in the SN Status Transfer procedure towards the target NG-RAN node, as specified in TS 37.340 [8].

8.2.1.3 Unsuccessful Operation

Figure 8.2.1.3-1: Handover Preparation, unsuccessful operation

If the target NG-RAN node does not admit at least one PDU session resource, or a failure occurs during the Handover Preparation, the target NG-RAN node shall send the HANDOVER PREPARATION FAILURE message to the source NG-RAN node. The message shall contain the Cause IE with an appropriate value.

If the Conditional Handover Information Request IE is contained in the HANDOVER REQUEST message and the target NG-RAN node rejects the handover or a failure occurs during the Handover Preparation, the target NG-RAN node shall include the Requested Target Cell ID IE in the HANDOVER PREPARATION FAILURE message.

Interactions with Handover Cancel procedure:

If there is no response from the target NG-RAN node to the HANDOVER REQUEST message before timer TXnRELOCprep expires in the source NG-RAN node, the source NG-RAN node should cancel the Handover Preparation procedure towards the target NG-RAN node by initiating the Handover Cancel procedure with the appropriate value for the Cause IE. The source NG-RAN node shall ignore any HANDOVER REQUEST ACKNOWLEDGE or HANDOVER PREPARATION FAILURE message received after the initiation of the Handover Cancel procedure and remove any reference and release any resources related to the concerned Xn UE-associated signalling.

8.2.1.4 Abnormal Conditions

If the supported algorithms for encryption defined in the UE Security Capabilities IE in the UE Context Information IE, plus the mandated support of the EEA0 and NEA0 algorithms in all UEs (TS 33.501 [28]), do not match any allowed algorithms defined in the configured list of allowed encryption algorithms in the NG-RAN node (TS 33.501 [28]), the NG-RAN node shall reject the procedure using the HANDOVER PREPARATION FAILURE message.

If the supported algorithms for integrity defined in the UE Security Capabilities IE in the UE Context Information IE, plus the mandated support of the EIA0 and NIA0 algorithms in all UEs (TS 33.501 [28]), do not match any allowed algorithms defined in the configured list of allowed integrity protection algorithms in the NG-RAN node (TS 33.501 [28]), the NG-RAN node shall reject the procedure using the HANDOVER PREPARATION FAILURE message.

If the CHO trigger IE is set to "CHO-replace" in the HANDOVER REQUEST message, but there is no CHO prepared for the included Target NG-RAN node UE XnAP ID, or the candidate cell in the Target Cell ID IE was not prepared using the same UE-associated signaling connection, the NG-RAN node shall reject the procedure using the HANDOVER PREPARATION FAILURE message.

If the HANDOVER REQUEST message includes information for a PLMN not serving the UE in the target NG-RAN node in the Management Based MDT PLMN List IE, the target NG-RAN node shall ignore information for that PLMN within the Management Based MDT PLMN List.

8.2.2 SN Status Transfer

8.2.2.1 General

The purpose of the SN Status Transfer procedure is to transfer the uplink PDCP SN and HFN receiver status and the downlink PDCP SN and HFN transmitter status either, from the source to the target NG-RAN node during an Xn handover, between the NG-RAN nodes involved in dual connectivity, or after retrieval of a UE context for RRC reestablishment, for each respective DRB of the source DRB configuration for which PDCP SN and HFN status preservation applies.

In case that the Xn handover is a DAPS handover, the SN Status Transfer procedure may also be used to transfer the uplink PDCP SN and HFN receiver status, and the downlink PDCP SN and HFN transmitter status for a DRB associated with RLC-UM and configured with DAPS as described in TS 38.300 [9].

In case that the Xn handover is a CHO, the SN Status Transfer procedure may also be used to transfer handover related information.

If the SN Status Transfer procedure is applied in the course of dual connectivity or RRC connection re-establishment in the subsequent specification text

– the behaviour of the NG-RAN node from which the DRB context is transferred, i.e. the NG-RAN node involved in dual connectivity or RRC connection re-establishment, from which data is forwarded, is specified by the behaviour of the "source NG-RAN node",

– the behaviour of the NG-RAN node to which the DRB context is transferred, i.e., the NG-RAN node involved in dual connectivity or RRC connection re-establishment, to which data is forwarded, is specified by the behaviour of the "target NG-RAN node".

The procedure uses UE-associated signalling.

8.2.2.2 Successful Operation

Figure 8.2.2.2-1: SN Status Transfer, successful operation

The source NG-RAN node initiates the procedure by stop assigning PDCP SNs to downlink SDUs and stop delivering UL SDUs towards the 5GC and sending the SN STATUS TRANSFER message to the target NG-RAN node at the time point when it considers the transmitter/receiver status to be frozen. The target NG-RAN node using full configuration for this handover as per TS 38.300 [9] or for the MR-DC operations as per TS 37.340 [8] shall ignore the information received in this message. In case of MR-DC, if the target NG-RAN node performs PDCP SN length change or RLC mode change for a DRB as specified in TS 37.340 [8], it shall ignore the information received for that DRB in this message.

In case that the Xn handover is a DAPS handover, the source NG-RAN node may continue assigning PDCP SNs to downlink SDUs and delivering uplink SDUs toward the 5GC when initiating this procedure for DRBs not configured with DAPS as in TS 38.300 [9].

For each DRB in the DRBs Subject to Status Transfer List IE, the source NG-RAN node shall include the DRB ID IE, the UL COUNT Value IE and the DL COUNT Value IE.

The source NG-RAN node may also include in the SN STATUS TRANSFER message the missing and the received uplink SDUs in the Receive Status of UL PDCP SDUs IE for each DRB for which the source NG-RAN node has accepted the request from the target NG-RAN node for uplink forwarding.

For each DRB in the DRBs Subject to Status Transfer List IE, the target NG-RAN node shall not deliver any uplink packet which has a PDCP-SN lower than the value contained within the UL COUNT Value IE.

For each DRB in the DRBs Subject to Status Transfer List IE, the target NG-RAN node shall use the value of the PDCP SN contained within the DL COUNT Value IE for the first downlink packet for which there is no PDCP-SN yet assigned.

If the Receive Status of UL PDCP SDUs IE is included for at least one DRB in the SN STATUS TRANSFER message, the target NG-RAN node may use it in a Status Report message sent to the UE over the radio interface.

If the SN STATUS TRANSFER message contains in the DRBs Subject To Status Transfer List IE the Old QoS Flow List – UL End Marker expected IE, the target NG-RAN node shall be prepared to receive the SDAP end marker for the QoS flow via the corresponding DRB, as specified in TS 38.300 [9].

If the CHO Configuration IE is included in the SN STATUS TRANSFER message, the target NG-RAN node shall, if supported, store this information in the UE context and use it as specified in TS 38.300 [9].

If the Mobility Information IE is included in the SN STATUS TRANSFER message, the target NG-RAN node shall, if supported, store this information in the UE context and use it as specified in TS 38.300 [9].

8.2.2.3 Unsuccessful Operation

Not applicable.

8.2.2.4 Abnormal Conditions

If the target NG-RAN node receives this message for a UE for which no prepared handover exists at the target NG-RAN node, the target NG-RAN node shall ignore the message.

8.2.3 Handover Cancel

8.2.3.1 General

The Handover Cancel procedure is used to enable a source NG-RAN node to cancel an ongoing handover preparation or an already prepared handover.

The procedure uses UE-associated signalling.

8.2.3.2 Successful Operation

Figure 8.2.3.2-1: Handover Cancel, successful operation

The source NG-RAN node initiates the procedure by sending the HANDOVER CANCEL message to the target NG-RAN node. The source NG-RAN node shall indicate the reason for cancelling the handover by means of an appropriate cause value.

If the Candidate Cells To Be Cancelled List IE is included in the HANDOVER CANCEL message, the target NG-RAN node shall consider that the source NG-RAN node is cancelling only the handover associated to the candidate cells identified by the included NG-RAN CGI and associated to the same UE-associated signaling connection identified by the Source NG-RAN node UE XnAP ID IE and, if included, also by the Target NG-RAN node UE XnAP ID IE.

8.2.3.3 Unsuccessful Operation

Not applicable.

8.2.3.4 Abnormal Conditions

If the HANDOVER CANCEL message refers to a context that does not exist, the target NG-RAN node shall ignore the message.

If the Candidate Cells To Be Cancelled List IE is included in the HANDOVER CANCEL message and the handover is not associated to a conditional handover, the target NG-RAN node shall ignore the Candidate Cells To Be Cancelled List IE.

If one or more candidate cells in the Candidate Cells To Be Cancelled List IE included in the HANDOVER CANCEL message were not prepared using the same UE-associated signaling connection, the target NG-RAN node shall ignore those non-associated candidate cells.

8.2.4 Retrieve UE Context

8.2.4.1 General

The purpose of the Retrieve UE Context procedure is to either retrieve the UE context from the old NG-RAN node and transfer it to the NG-RAN node where the UE RRC Connection has been requested to be established, or to enable the old NG-RAN node to forward an RRC message to the UE via the new NG-RAN node without context transfer, or to request for small data transmission.

The procedure uses UE-associated signalling.

8.2.4.2 Successful Operation

Figure 8.2.4.2-1: Retrieve UE Context, successful operation

The new NG-RAN node initiates the procedure by sending the RETRIEVE UE CONTEXT REQUEST message to the old NG-RAN node.

If the old NG-RAN node is able to identify the UE context by means of the UE Context ID, and to successfully verify the UE by means of the integrity protection contained in the RETRIEVE UE CONTEXT REQUEST message, and decides to provide the UE context to the new NG-RAN node, it shall respond to the new NG-RAN node with the RETRIEVE UE CONTEXT RESPONSE message.

If the Trace Activation IE is included in the RETRIEVE UE CONTEXT RESPONSE message, the new NG-RAN node shall, if supported, initiate the requested trace function as specified in TS 32.422 [23].

If the Index to RAT/Frequency Selection Priority IE is contained in the RETRIEVE UE CONTEXT RESPONSE message, the new NG-RAN node shall store this information and use it as defined in TS 23.501 [7].

If the Location Reporting Information IE is included in the RETRIEVE UE CONTEXT RESPONSE message, then the new NG-RAN node should initiate the requested location reporting functionality as defined in TS 38.413 [5].

If the Trace Activation IE is included in the RETRIEVE UE CONTEXT RESPONSE message which includes

– the MDT Activation IE set to "Immediate MDT and Trace", then the new NG-RAN node shall if supported, initiate the requested trace session and MDT session as described in TS 32.422 [23].

– the MDT Activation IE set to "Immediate MDT Only" or "Logged MDT only", the new NG-RAN node shall, if supported, initiate the requested MDT session as described in TS 32.422 [23] and the target NG-RAN node shall ignore the Interfaces To Trace IE, and the Trace Depth IE.

– the MDT Location Information IE, within the MDT Configuration IE, the new NG-RAN node shall, if supported, store this information and take it into account in the requested MDT session.

– the MDT Activation IE set to "Immediate MDT Only" or "Logged MDT only", and if the Signalling based MDT PLMN List IE is included in the MDT Configuration IE, the new NG-RAN node may use it to propagate the MDT Configuration as described in TS 37.320 [43].

– the Bluetooth Measurement Configuration IE, within the MDT Configuration IE, the new NG-RAN node shall, if supported, take it into account for MDT Configuration as described in TS 37.320 [43].

– the WLAN Measurement Configuration IE, within the MDT Configuration IE, the new NG-RAN node shall, if supported, take it into account for MDT Configuration as described in TS 37.320 [43].

– the Sensor Measurement Configuration IE, within the MDT Configuration IE, take it into account for MDT Configuration as described in TS 37.320 [43].

– the MDT Configuration and if the new NG-RAN node is a gNB receiving a MDT Configuration-EUTRA IE, or the target NG-RAN node is a ng-eNB receiving a MDT Configuration-NR IE, the new NG-RAN node shall store it as part of the UE context, and use it as described in TS 37.320 [43].

For each QoS flow in the RETRIEVE UE CONTEXT RESPONSE message, if the QoS Monitoring Request IE is included in the QoS Flow Level QoS Parameters IE in the PDU Session Resources To Be Setup List IE, the new NG-RAN node shall store this information, and shall, if supported, perform delay measurement and QoS monitoring, as specified in TS 23.501 [7]. If the QoS Monitoring Reporting Frequency IE is included in the QoS Flow Level QoS Parameters IE in the PDU Session Resources To Be Setup List IE, the new NG-RAN node shall store this information, and shall, if supported, use it for RAN part delay reporting.

If the 5GC Mobility Restriction List Container IE is included in the RETRIEVE UE CONTEXT RESPONSE message, the new NG-RAN node shall, if supported, store this information in the UE context and use it as specified in TS 38.300 [9].

V2X:

– If the NR V2X Services Authorized IE is included in the RETRIEVE UE CONTEXT RESPONSE message and it contains one or more IEs set to "authorized", the new NG-RAN node shall, if supported, consider that the UE is authorized for the relevant service(s).

– If the LTE V2X Services Authorized IE is included in the RETRIEVE UE CONTEXT RESPONSE message and it contains one or more IEs set to "authorized", the new NG-RAN node shall, if supported, consider that the UE is authorized for the relevant service(s).

– If the NR UE Sidelink Aggregate Maximum Bit Rate IE is included in the UE Context Information Retrieve UE Context Response IE in the RETRIEVE UE CONTEXT RESPONSE message, the new NG-RAN node shall, if supported, use the received value for the concerned UE’s sidelink communication in network scheduled mode for NR V2X services.

– If the LTE UE Sidelink Aggregate Maximum Bit Rate IE is included in the UE Context Information Retrieve UE Context Response IE in the RETRIEVE UE CONTEXT RESPONSE message, the new NG-RAN node shall, if supported, use the received value for the concerned UE’s sidelink communication in network scheduled mode for LTE V2X services.

5G ProSe:

– If the 5G ProSe Authorized IE is included in the RETRIEVE UE CONTEXT RESPONSE message and it contains one or more IEs set to "authorized", the new NG-RAN node shall, if supported, consider that the UE is authorized for the relevant service(s).

– If the 5G ProSe UE PC5 Aggregate Maximum Bit Rate IE is included in the UE Context Information – Retrieve UE Context Response IE in the RETRIEVE UE CONTEXT RESPONSE message, the new NG-RAN node shall, if supported, use the received value for the concerned UE’s sidelink communication in network scheduled mode for 5G ProSe services.

– If the 5G ProSe PC5 QoS Parameters IE is included in the RETRIEVE UE CONTEXT RESPONSE message, the new NG-RAN node shall, if supported, use it as defined in TS 23.304 [48].

If the PC5 QoS Parameters IE is included in the RETRIEVE UE CONTEXT RESPONSE message, the new NG-RAN node shall, if supported, use it as defined in TS 23.287[38].

In case of RRC Re-establishment, the old NG-RAN may include the UE History Information IE or the UE History Information from the UE IE in the RETRIEVE UE CONTEXT RESPONSE message. Upon reception of the UE History Information IE or the UE History Information from the UE IE in the RETRIEVE UE CONTEXT RESPONSE message, the new NG-RAN node shall, if supported, store the collected information and use it for future handover preparations.

If the UE Radio Capability ID IE is contained in the RETRIEVE UE CONTEXT RESPONSE message, the new NG- RAN node shall, if supported store this information in the UE context and use it as defined in TS 23.501 [7] and TS 23.502 [13].

If the Management Based MDT PLMN List IE is contained in the RETRIEVE UE CONTEXT RESPONSE message, the new NG-RAN node shall, if supported, store it in the UE context, and use this information to allow subsequent selection of the UE for management based MDT defined in TS 32.422 [23].

If the MBS Session Information List IE is included in the UE Context Information – Retrieve UE Context Response IE contained in the RETRIEVE UE CONTEXT RESPONSE message, the new NG-RAN node shall, if supported, use this information to establish an NG-RAN MBS session resources context, if applicable.

If the RETRIEVE UE CONTEXT RESPONSE message includes the MBS Area Session ID IE, the new NG-RAN node shall, if supported, use this information as an indication in which MBS Area Session ID the UE has been suspended. For each MBS session for which the Active MBS Session Information IE is included in the MBS Session Information Item IE, the new NG-RAN node shall, if supported, use this information to setup respective MBS session resources. The new NG-RAN node shall, if supported, consider that the MBS sessions for which the Active MBS Session Information IE is not included are inactive.

If the IAB Node Indication IE is contained in the RETRIEVE UE CONTEXT RESPONSE message, the new NG-RAN node shall, if supported, consider that the procedure is performed for an IAB-node. In addition:

– If the No PDU Session Indication IE is contained in the UE Context Information – Retrieve UE Context Response IE of the RETRIEVE UE CONTEXT RESPONSE message, the new NG-RAN node shall, if supported, consider the UE as an IAB-node which does not have any PDU sessions activated, and ignore the PDU Session Resources To Be Setup List IE in the UE Context Information – Retrieve UE Context Response IE, and shall not take any action with respect to PDU session setup.

If the Time Synchronisation Assistance Information IE is contained in the RETRIEVE UE CONTEXT RESPONSE message, the new NG-RAN node shall, if supported, store this information in the UE context and use it as defined in TS 23.501 [7].

If the QMC Configuration Information IE is contained in the RETRIEVE UE CONTEXT RESPONSE message, the new NG-RAN node shall, if supported, take it into account for QoE measurements handling, as described in TS 38.300 [9].

If the SDT Support Request IE is included in the RETRIEVE UE CONTEXT REQUEST message, the old NG-RAN node shall, if supported, consider that the UE has requested for SDT as defined in TS 38.300 [9].

If the UE Slice-Maximum Bit Rate List IE is contained in RETRIEVE UE CONTEXT RESPONSE message, the new NG-RAN node shall, if supported, store the received UE Slice Maximum Bit Rate List in the UE context, and use the received UE Slice Maximum Bit Rate value for each S-NSSAI for the concerned UE as specified in TS 23.501 [7].

If the Positioning Information IE is contained in the RETRIEVE UE CONTEXT RESPONSE message, the new NG-RAN node shall, if supported, take it into account to allocate proper SRS resources and make corresponding response to LMF when positioning a UE.

Interaction with the Retrieve UE Context Confirm procedure

If the UE Context Reference at the S-NG-RAN IE is contained in the RETRIEVE UE CONTEXT RESPONSE message, the new NG-RAN node may use it to establish dual connectivity with the S-NG-RAN node and shall trigger the Retrieve UE Context Confirm procedure to the old NG-RAN node when the UE successfully resumes on the new NG-RAN node.

8.2.4.3 Unsuccessful Operation

Figure 8.2.4.3-1: Retrieve UE Context, unsuccessful operation

If the old NG-RAN node is not able to identify the UE context by means of the UE Context ID, or if the integrity protection contained in the RETRIEVE UE CONTEXT REQUEST message is not valid, or, if it decides not to provide the UE context to the new NG-RAN node, it shall respond to the new NG-RAN node with the RETRIEVE UE CONTEXT FAILURE message.

If the old NG-RAN node decides to keep the UE context in case of periodic RNAU or in case of RACH based SDT, it shall store the Allocated C-RNTI IE and the Access PCI IE in the UE Context ID IE, as described in TS 38.300 [9].

If the Old NG-RAN node to New NG-RAN node Resume Container IE is included in the RETRIEVE UE CONTEXT FAILURE message, the new NG-RAN node should transparently forward the content of this IE to the UE as described in TS 38.300 [9].

8.2.4.4 Abnormal Conditions

Void.

8.2.5 RAN Paging

8.2.5.1 General

The purpose of the RAN Paging procedure is to enable the NG-RAN node1 to request paging of a UE in the NG-RAN node2.

The procedure uses non UE-associated signalling.

8.2.5.2 Successful operation

Figure 8.2.5.2-1: RAN Paging: successful operation

The RAN Paging procedure is triggered by the NG-RAN node1 by sending the RAN PAGING message to the NG-RAN node2, in which the necessary information e.g. UE RAN Paging Identity should be provided.

If the Paging Priority IE is included in the RAN PAGING message, the NG-RAN node2 may use it to prioritize paging.

If the Assistance Data for RAN Paging IE is included in the RAN PAGING message, the NG-RAN node2 may use it according to TS 38.300 [9].

If the UE Radio Capability for Paging IE is included in the RAN PAGING message, the NG-RAN node2 may use it to apply specific paging schemes.

If the Extended UE Identity Index Value IE is included in the RAN PAGING message, the NG-RAN node2 may use it according to TS 36.304 [34]. When available, NG-RAN node1 may include the Extended UE Identity Index Value IE in the RAN PAGING message towards an ng-eNB (e.g. NG-RAN node2).

When available, the NG-RAN node1 shall include the E-UTRA Paging eDRX Information IE in the RAN PAGING message towards the NG-RAN node2. If the E-UTRA Paging eDRX Information IE is included in the RAN PAGING message, the NG-RAN node2 shall, if supported, use it according to TS 36.304 [34].

When available, the NG-RAN node1 shall include the UE Specific DRX IE in the RAN PAGING message towards the NG-RAN node2. If the UE specific DRX IE is included in the RAN PAGING message, the NG-RAN node2 shall, if supported, use it according to TS 36.304 [34].

When available, the NG-RAN node1 shall include the NR Paging eDRX Information IE in the RAN PAGING message towards the NG-RAN node2. If the NR Paging eDRX Information IE is included in the RAN PAGING message, the NG-RAN node2 shall, if supported, use it according to TS 38.304 [33].

If the NR Paging eDRX Information for RRC INACTIVE IE is included in the RAN PAGING message, the NG-RAN node2 shall, if supported, use it according to TS 38.304 [33].

When available, the NG-RAN node1 shall include the Paging Cause IE in the RAN PAGING message towards the NG-RAN node2. If the Paging Cause IE is included in the RAN PAGING message, the NG-RAN node2 shall, if supported, use it according to TS 38.331 [10].

If the PEIPS Assistance Information IE is included in the RAN PAGING message, the NG-RAN node2 shall, if supported, use it according to TS 38.300 [9].

8.2.5.3 Unsuccessful Operation

Not applicable.

8.2.5.4 Abnormal Condition

Void.

8.2.6 XN-U Address Indication

8.2.6.1 General

For the retrieval of a UE context, the Xn-U Address Indication procedure is used to provide forwarding addresses from the new NG-RAN node to the old NG-RAN node for all PDU session resources successfully established at the new NG-RAN node for which forwarding was requested.

For MR-DC with 5GC, the Xn-U Address Indication procedure is used to provide data forwarding related information, and Xn-U bearer address information for completion of setup of SN terminated bearers from the M-NG-RAN node to the S-NG-RAN node as specified in TS 37.340 [8],

The procedure uses UE-associated signalling.

8.2.6.2 Successful Operation

Figure 8.2.6.2-1: Xn-U Address Indication, successful operation for UE context retrieval

Figure 8.2.6.2-2: Xn-U Address Indication, successful operation for MR-DC with 5GC

UE Context Retrieval

The Xn-U Address Indication procedure is initiated by the new NG-RAN node. Sending the XN-U ADDRESS INDICATION message, the new NG-RAN node informs the old NG-RAN node of successfully established PDU Session Resource contexts to which user data pending at the old NG-RAN node can be forwarded.

The new NG-RAN node may include Secondary Data Forwarding Info from target NG-RAN node List IE for an additional Xn-U tunnel for data forwarding.

Upon reception of the XN-U ADDRESS INDICATION message, the old NG-RAN node should forward pending user data to the indicated TNL addresses.

MR-DC with 5GC

The Xn-U Address Indication procedure is initiated by the M-NG-RAN node.

Upon reception of the XN-U ADDRESS INDICATION message, in case of data forwarding, the S-NG-RAN node should forward pending DL user data to the indicated TNL addresses; in case Data Forwarding Info from target E-UTRAN node IE is received, the S-NG-RAN node should perform inter-system direct data forwarding to the indicated TNL addresses as specified in TS38.300 [9]; in case of completion of Xn-U bearer establishment for SN terminated bearers, the S-NG-RAN node may start delivery of user data to the indicated TNL address, and shall, if supported, use the received QoS Mapping Information IE within the DRBs to Be Setup List IE in the PDU Session Resource Setup Complete Info – SN terminated IE to set DSCP and/or IPv6 flow label fields for the delivery of user data to the indicated TNL address.

If the XN-U ADDRESS INDICATION message includes the DRB IDs taken into use IE, the S-NG-RAN node shall, if applicable, act as specified in TS 37.340 [8].

If the XN-U ADDRESS INDICATION message includes the CHO MR-DC Indicator IE, the S-NG-RAN node shall, if supported, consider that the XN-U ADDRESS INDICATION message concerns a Conditional Handover, and act as specified in TS 37.340 [8].

If the XN-U ADDRESS INDICATION message includes the CHO MR-DC Early Data Forwarding Indicator IE set to "stop", the S-NG-RAN node shall, if supported and if already initiated, stop early data forwarding for the provided Data Forwarding Address information.

If the XN-U ADDRESS INDICATION message includes the CPC Data Forwarding indicator IE set to "triggered", the S-NG-RAN node shall, if supported, consider that the XN-U ADDRESS INDICATION message concerns a Conditional PSCell Change, and act as specified in TS 37.340 [8]. If the CPC Data Forwarding Indicator IE is present and value set to "“early data transmission stop", the S-NG-RAN node shall, if supported and if already initiated, stop early data forwarding for the provided Data Forwarding Address information.

8.2.6.3 Unsuccessful Operation

Not applicable.

8.2.6.4 Abnormal Conditions

Void.

8.2.7 UE Context Release

8.2.7.1 General

For handover, the UE Context Release procedure is initiated by the target NG-RAN node to indicate to the source NG-RAN node that radio and control plane resources for the associated UE context are allowed to be released.

For dual connectivity, the UE Context Release procedure is initiated by the M-NG-RAN node to initiate the release the UE context at the S-NG-RAN node. For dual connectivity specific mobility scenarios specified in TS 37.340 [8], where SCG radio resources in the S-NG-RAN node are kept, only resources related to the UE-associated signalling connection between the M-NG-RAN node and the S-NG-RAN node are released.

For UE context retrieval, the UE Context Release procedure is initiated by the new NG-RAN node to indicate to the old NG-RAN node that radio and control plane resources for the associated UE context are allowed to be released.

The procedure uses UE-associated signalling.

8.2.7.2 Successful Operation

Figure 8.2.7.2-1: UE Context Release, successful operation for handover

Figure 8.2.7.2-2: UE Context Release, successful operation for dual connectivity

Figure 8.2.7.2-3: UE Context Release, successful operation for UE context retrieval

Handover

The UE Context Release procedure is initiated by the target NG-RAN node. By sending the UE CONTEXT RELEASE message the target NG-RAN node informs the source NG-RAN node of Handover success and triggers the release of resources.

Upon reception of the UE CONTEXT RELEASE message, the source NG-RAN node may release radio and control plane related resources associated to the UE context. If data forwarding has been performed, the source NG-RAN node should continue forwarding of user plane data as long as packets are received at the source NG-RAN node.

Dual Connectivity

The UE Context Release procedure is initiated by the M-NG-RAN node. By sending the UE CONTEXT RELEASE message the M-NG-RAN node informs the S-NG-RAN node that the UE Context can be removed.

Upon reception of the UE CONTEXT RELEASE message, the S-NG-RAN node may release radio and control plane related resources associated to the UE context. If data forwarding has been performed, the S-NG-RAN node should continue forwarding of user plane data as long as packets are received at the S-NG-RAN node.

UE Context Retrieval

The UE Context Release procedure is initiated by the new NG-RAN node. By sending the UE CONTEXT RELEASE message the new NG-RAN node informs the old NG-RAN node of RRC connection reestablishment success or RRC connection resumption success and triggers the release of resources.

Interaction with the M-NG-RAN node initiated S-NG-RAN node Release procedure:

The S-NG-RAN node may receive the S-NODE RELEASE REQUEST message including the UE Context Kept Indicator IE set to "True", upon which the S-NG-RAN node shall, if supported, only release the resources related to the UE-associated signalling connection between the M-NG-RAN node and the S-NG-RAN node, as specified in TS 37.340 [8].

8.2.7.3 Unsuccessful Operation

Not applicable.

8.2.7.4 Abnormal Conditions

If the UE Context Release procedure is not initiated towards the source NG-RAN node from any prepared NG-RAN node before the expiry of the timer TXnRELOCoverall, the source NG-RAN node shall request the AMF to release the UE context.

If the UE returns to source NG-RAN node before the reception of the UE CONTEXT RELEASE message or the expiry of the timer TXnRELOCoverall, the source NG-RAN node shall stop the TXnRELOCoverall and continue to serve the UE.

8.2.8 Handover Success

8.2.8.1 General

The Handover Success procedure is used during a conditional handover or a DAPS handover to enable a target NG-RAN node to inform the source NG-RAN node that the UE has successfully accessed the target NG-RAN node.

The procedure uses UE-associated signalling.

8.2.8.2 Successful Operation

Figure 8.2.8.2-1: Handover Success, successful operation

The target NG-RAN node initiates the procedure by sending the HANDOVER SUCCESS message to the source NG-RAN node.

If late data forwarding was configured for this UE, the source NG-RAN node shall start data forwarding using the tunnel information related to the global target cell ID provided in the HANDOVER SUCCESS message.

When the source NG-RAN node receives the HANDOVER SUCCESS message, it shall consider all other CHO preparations accepted for this UE under the same UE-associated signalling connection in the target NG-RAN node as cancelled.

Interactions with other procedures

If a CONDITIONAL HANDOVER CANCEL message was received for this UE prior the reception of the HANDOVER SUCCESS message, the source NG-RAN node shall consider that the UE successfully executed the handover.

The source NG-RAN node may initiate Handover Cancel procedure towards the other signalling connections or other candidate target NG-RAN nodes for this UE, if any.

8.2.8.3 Unsuccessful Operation

Not applicable.

8.2.8.4 Abnormal Conditions

If the HANDOVER SUCCESS message refers to a context that does not exist, the source NG-RAN node shall ignore the message.

8.2.9 Conditional Handover Cancel

8.2.9.1 General

The Conditional Handover Cancel procedure is used to enable a target NG-RAN node to cancel an already prepared conditional handover.

The procedure uses UE-associated signalling.

8.2.9.2 Successful Operation

Figure 8.2.9.2-1: Conditional Handover Cancel, successful operation

The target NG-RAN node initiates the procedure by sending the CONDITIONAL HANDOVER CANCEL message to the source NG-RAN node. The target NG-RAN node shall indicate the reason for cancelling the conditional handover by means of an appropriate cause value.

At the reception of the CONDITIONAL HANDOVER CANCEL message, the source NG-RAN node shall consider that the target NG-RAN node is about to remove any reference to, and release any resources previously reserved for candidate cells associated to the UE-associated signalling identified by the Source NG-RAN node UE XnAP ID IE and the Target NG-RAN node UE XnAP ID IE. If the Candidate Cells To Be Cancelled List IE is included in CONDITIONAL HANDOVER CANCEL message, the source NG-RAN node shall consider that only the resources reserved for the cells identified by the included NG-RAN CGI are about to be released.

8.2.9.3 Unsuccessful Operation

Not applicable.

8.2.9.4 Abnormal Conditions

If the CONDITIONAL HANDOVER CANCEL message refers to a context that does not exist, the source NG-RAN node shall ignore the message.

If one or more candidate cells in the Candidate Cells To Be Cancelled List IE included in the CONDITIONAL HANDOVER CANCEL message were not prepared using the same UE-associated signaling connection, the source NG-RAN node shall ignore those non-associated candidate cells.

8.2.10 Early Status Transfer

8.2.10.1 General

The purpose of the Early Status Transfer procedure is to transfer the COUNT of the first downlink SDU that the source NG-RAN node forwards to the target NG-RAN node or the COUNT for discarding of already forwarded downlink SDUs for respective DRB during DAPS Handover or Conditional Handover.

For MR-DC with 5GC, the Early Status Transfer procedure is also used from the source S-NG-RAN node to the source M-NG-RAN node during a Conditional Handover as specified in TS 37.340 [8].

For Conditional PSCell Addition in MR-DC with NR SCG, the Early Status Transfer procedure is also used, from the M-NG-RAN node to the S-NG-RAN node as specified in TS 37.340 [8].

For Conditional PSCell Change in MR-DC with NR SCG, the Early Status Transfer procedure is also used from the source S-NG-RAN node to the M-NG-RAN node, and from the M-NG-RAN node to the target S-NG-RAN node as specified in TS 37.340 [8].

The procedure uses UE-associated signalling.

8.2.10.2 Successful Operation

Figure 8.2.10.2-1: Early Status Transfer during DAPS Handover or Conditional Handover, successful operation

Figure 8.2.10.2-2: Early Status Transfer during Conditional Handover in MR-DC operation, successful operation

Figure 8.2.10.2-3: Early Status Transfer during CPAC, successful operation

From source NG-RAN node to target NG-RAN node

The DRBs Subject To Early Status Transfer List IE included in the EARLY STATUS TRANSFER message contains the DRB ID(s) corresponding to the DRB(s) subject to be simultaneously served by the source and the target NG-RAN nodes during DAPS Handover or the DRB(s) transferred during Conditional Handover.

For each DRB in the DRBs Subject To Early Status Transfer List IE, the target NG-RAN node shall use the value of the FIRST DL COUNT Value IE as the COUNT of the first downlink SDU that the source NG-RAN node forwards to the target NG-RAN node.

For each DRB in the DRBs Subject To Early Status Transfer List IE for which the DISCARD DL COUNT Value IE is received in the EARLY STATUS TRANSFER message, the target NG-RAN node does not transmit forwarded downlink SDUs to the UE whose COUNT is less than the provided and discards them if transmission has not been attempted.

From source S-NG-RAN node to source M-NG-RAN node, the source NG-RAN node for Conditional Handover

The DRBs Subject To Early Status Transfer List IE included in the EARLY STATUS TRANSFER message contains the DRB ID(s) corresponding to the DRB(s) transferred during Conditional Handover.

For each DRB in the DRBs Subject To Early Status Transfer List IE, the source M-NG-RAN node shall forward to the target, the value of the received FIRST DL COUNT Value IE or DISCARD DL COUNT Value IE.

From M-NG-RAN node to S-NG-RAN node, for Conditional PSCell Addition

The DRBs Subject To Early Status Transfer List IE included in the EARLY STATUS TRANSFER message contains the DRB ID(s) corresponding to the DRB(s) transferred during Conditional PSCell Addition.

For each DRB in the DRBs Subject To Early Status Transfer List IE, the M-NG-RAN node shall forward to the S-NG-RAN node, the value of the received FIRST DL COUNT Value IE or DISCARD DL COUNT Value IE.

From source S-NG-RAN node to M-NG-RAN node, and from M-NG-RAN node to target S-NG-RAN node, for Conditional PSCell Change

The DRBs Subject To Early Status Transfer List IE included in the EARLY STATUS TRANSFER message contains the DRB ID(s) corresponding to the DRB(s) transferred during Conditional PSCell Change.

For each DRB in the DRBs Subject To Early Status Transfer List IE, the source S-NG-RAN node shall forward to the M-NG-RAN node and the M-NG-RAN node shall forward to the target S-NG-RAN node, during Conditional PSCell Change, the value of the received FIRST DL COUNT Value IE or DISCARD DL COUNT Value IE.

8.2.10.3 Unsuccessful Operation

Not applicable.

8.2.10.4 Abnormal Conditions

If the target NG-RAN node receives this message for a UE for which no prepared DAPS Handover or Conditional Handover exists at the target NG-RAN node, the target NG-RAN node shall ignore the message.

8.2.11 RAN Multicast Group Paging

8.2.11.1 General

The purpose of the RAN Multicast Group Paging procedure is to enable the NG-RAN node1 to request paging of UEs that have joined an MBS Session in the NG-RAN node2.

The procedure uses non UE-associated signalling.

8.2.11.2 Successful operation

Figure 8.2.11.2-1: RAN Multicast Group Paging, successful operation

The RAN Multicast Group Paging procedure is triggered by the NG-RAN node1 by sending the RAN MULTICAST GROUP PAGING message to the NG-RAN node2.

If the RAN MULTICAST GROUP PAGING message includes the Paging DRX IE, the NG-RAN node2.shall, if supported, use it according to TS 38.304 [33].

8.2.12 Retrieve UE Context Confirm

8.2.12.1 General

The Retrieve UE Context Confirm procedure is used by the new NG-RAN node to inform the old NG-RAN node whether the S-NG-RAN node associated with the old NG-RAN node for the UE that was indicated during UE context retrieval is kept or not by the new NG-RAN node during RRC resumption.

In case of RACH based SDT without UE context relocation, the Retrieve UE Context Confirm procedure is also used to request the termination of SDT session from the new NG-RAN node to the old NG-RAN node.

The procedure uses UE-associated signalling.

8.2.12.2 Successful Operation

Figure 8.2.12.2-1: Retrieve UE Context Confirm, successful operation

The new NG-RAN node initiates the procedure by sending the RETRIEVE UE CONTEXT CONFIRM message to the old NG-RAN node.

Upon reception of the RETRIEVE UE CONTEXT CONFIRM message, the old NG-RAN node shall release the resources related to the UE-associated signalling connection between the old NG-RAN node and the new NG-RAN node, as specified in TS 37.340 [8].

If the UE Context Kept Indicator IE is included and set to "True", the old NG-RAN node shall consider that the S-NG-RAN node was kept by the new NG-RAN node and use this information as specified in TS 37.340 [8].

If the old NG-RAN node receives the SDT Termination Request IE in the RETRIEVE UE CONTEXT CONFIRM message, the old NG-RAN node shall, if supported, consider that the termination of the ongoing SDT session is requested from the new NG-RAN node for this UE and act as specified in TS 38.300 [9].

8.2.12.3 Unsuccessful Operation

Not applicable.

8.2.12.4 Abnormal Conditions

If the RETRIEVE UE CONTEXT CONFIRM message refers to a context that does not exist, the old NG-RAN node shall ignore the message.

8.2.13 Partial UE Context Transfer

8.2.13.1 General

The purpose of the Partial UE Context Transfer procedure is to partially transfer the UE context from the old NG-RAN node to the new NG-RAN node.

The procedure uses UE-associated signalling.

8.2.13.2 Successful Operation

Figure 8.2.13.2-1: Partial UE Context Transfer, successful operation

The old NG-RAN node initiates the procedure by sending the PARTIAL UE CONTEXT TRANSFER message to the new NG-RAN node.

If the new NG-RAN node is able to accept the SDT session without anchor relocation, it shall, if supported, respond to the old NG-RAN node with the PARTIAL UE CONTEXT TRANSFER ACKNOWLEDGE message.

If the Partial UE Context Information for SDT IE is included in the PARTIAL UE CONTEXT TRANSFER message, the new NG-RAN node may include data forwarding related information in the SDT Data Forwarding DRB List IE in the PARTIAL UE CONTEXT TRANSFER ACKNOWLEDGE message.

8.2.13.3 Unsuccessful Operation

Figure 8.2.13.3-1: Partial UE Context Transfer, unsuccessful operation

If the new NG-RAN is not able to accept the SDT session without anchor relocation, it shall respond to the old NG-RAN node with the PARTIAL UE CONTEXT TRANSFER FAILURE message.

8.2.13.4 Abnormal Condition

Void.