8.2 Basic mobility procedures

36.4233GPPEvolved Universal Terrestrial Radio Access Network (E-UTRAN)Release 17TSX2 Application Protocol (X2AP)

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

8.2.1 Handover Preparation

8.2.1.1 General

This procedure is used to establish necessary resources in an eNB 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 eNB initiates the procedure by sending the HANDOVER REQUEST message to the target eNB. When the source eNB sends the HANDOVER REQUEST message, it shall start the timer T_RELOCprep.

If the Conditional Handover Information Request IE is contained in the HANDOVER REQUEST message, the target eNB 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 New eNB UE X2AP ID IE is contained in the Conditional Handover Information Request IE included in the HANDOVER REQUEST message, then the target eNB shall remove the existing prepared conditional HO identified by the New eNB UE X2AP ID IE and the Target Cell ID IE. It is up to the implementation of the target eNB when to remove the HO information.

The allocation of resources according to the values of the Allocation and Retention Priority IE included in the E-RAB Level QoS Parameters IE shall follow the principles described for the E-RAB Setup procedure in TS 36.413 [4].

The source eNB may include in the GUMMEI IE any GUMMEI corresponding to the source MME node.

If at least one of the requested non-GBR E-RABs is admitted to the cell indicated by the Target Cell ID IE, the target eNB shall reserve necessary resources, and send the HANDOVER REQUEST ACKNOWLEDGE message back to the source eNB. The target eNB shall include the E-RABs for which resources have been prepared at the target cell in the E-RABs Admitted List IE. The target eNB shall include the E-RABs that have not been admitted in the E-RABs Not Admitted List IE with an appropriate cause value.

At reception of the HANDOVER REQUEST message the target eNB shall:

– prepare the configuration of the AS security relation between the UE and the target eNB by using the information in the UE Security Capabilities IE and the AS Security Information IE in the UE Context Information IE.

For each E-RAB for which the source eNB proposes to do forwarding of downlink data, the source eNB shall include the DL Forwarding IE within the E-RABs To be Setup Item IE of the HANDOVER REQUEST message. The source eNB shall include the DL Forwarding IE if it requests a DAPS handover for that E-RAB. For each E-RAB that it has decided to admit, the target eNB may include the DL GTP Tunnel Endpoint IE within the E-RABs Admitted Item IE of the HANDOVER REQUEST ACKNOWLEDGE message to indicate that it accepts the proposed forwarding of downlink data for this bearer. This GTP tunnel endpoint may be different from the corresponding GTP tunnel endpoint, i.e. the information contained in the Transport Layer address IE and GTP TEID IE in the E-RAB To Be Switched in Downlink List IE of the PATH SWITCH REQUEST message (see TS 36.413 [4]) depending on implementation choice.

For each bearer in the E-RABs Admitted List IE, the target eNB may include the UL GTP Tunnel Endpoint IE to indicate that it requests data forwarding of uplink packets to be performed for that bearer.

Upon reception of the HANDOVER REQUEST ACKNOWLEDGE message the source eNB shall stop the timer T_RELOCprepand terminate the Handover Preparation procedure. If the procedure was initiated for an immediate handover, the source eNB shall start the timer TX2RELOCoverall. The source eNB is then defined to have a Prepared Handover for that X2 UE-associated signalling.

If the Trace Activation IE is included in the HANDOVER REQUEST message then the target eNB shall, if supported, initiate the requested trace function as described in TS 32.422 [6]. In particular, the target eNB shall, if supported:

– if the Trace Activation IE does not include the MDT Configuration IE, initiate the requested trace session as described in TS 32.422 [6];

– if the Trace Activation IE includes the MDT Activation IE, within the MDT Configuration IE, set to "Immediate MDT and Trace" initiate the requested trace session and MDT session as described in TS 32.422 [6];

– if the Trace Activation IE includes the MDT Activation IE, within the MDT Configuration IE, set to "Immediate MDT Only" initiate the requested MDT session as described in TS 32.422 [6] and the target eNB shall ignore Interfaces To Trace IE, and Trace Depth IE;

– if the Trace Activation IE includes the MDT Location Information IE, within the MDT Configuration IE, store this information and take it into account in the requested MDT session;

– if the Trace Activation IE includes the Signalling based MDT PLMN List IE, within the MDT Configuration IE, the eNB may use it to propagate the MDT Configuration as described in TS 37.320 [31];

– if the Trace Activation IE includes the UE Application layer measurement configuration IE, initiate the requested trace session and QoE Measurement Collection function as described in TS 36.300 [15].

– if the Trace Activation IE includes the Bluetooth Measurement Configuration IE, within the MDT Configuration IE, take it into account for MDT Configuration as described in TS 37.320 [31].

– if the Trace Activation IE includes the WLAN Measurement Configuration IE, within the MDT Configuration IE, take it into account for MDT Configuration as described in TS 37.320 [31].

– if the Trace Activation IE includes the MDT Configuration NR IE, store and forward the MDT Configuration NR IE to the SgNB, if the target eNB has configured EN-DC for the UE.

– if the Trace Activation IE includes the Sensor Measurement Configuration IE within the MDT Configuration IE, take it into account for MDT Configuration as described in TS 37.320 [31].

If the Management Based MDT Allowed IE only or the Management Based MDT Allowed IE and the Management Based MDT PLMN List IE is contained in the HANDOVER REQUEST message, the target eNB 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 [6].

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

The source eNB shall, if supported and available in the UE context, include the Management Based MDT Allowed IE and the Management Based MDT PLMN List IE in the HANDOVER REQUEST message, except if the source eNB selects a serving PLMN in the target eNB which is not included in the Management Based MDT PLMN List. If the Management Based MDT PLMN List IE is not present, the source eNB shall, if supported, include the Management Based MDT Allowed IE, if this information is available in the UE context, in the HANDOVER REQUEST message, except if the source eNB selects a serving PLMN in the target eNB different from the serving PLMN in the source eNB.

If the Handover Restriction List IE is

– contained in the HANDOVER REQUEST message, the target eNB shall

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

– use this information to determine a target for the UE during subsequent mobility action for which the eNB provides information about the target of the mobility action towards the UE, except when one of the E-RABs has a particular ARP value (TS 23.401 [12]) in which case the information shall not apply;

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

– not contained in the HANDOVER REQUEST message, the target eNB shall consider that no roaming and no access restriction apply to the UE.

If the Location Reporting Information IE is included in the HANDOVER REQUEST message then the target eNB should initiate the requested location reporting functionality as defined in TS 36.413 [4].

If the SRVCC Operation Possible IE is included in the HANDOVER REQUEST message, the target eNB shall store the content of such IE in the UE context and use it as defined in TS 23.216 [20].

If the UE Security Capabilities IE included in the HANDOVER REQUEST message only contains the EIA0 algorithm as defined in TS 33.401 [18] and if this EIA0 algorithm is defined in the configured list of allowed integrity protection algorithms in the eNB (TS 33.401 [18]), the eNB shall take it into use and ignore the keys received in the AS Security Information IE.

The HANDOVER REQUEST message shall contain the Subscriber Profile ID for RAT/Frequency priority IE, if available.

If the Subscriber Profile ID for RAT/Frequency priority IE is contained in the HANDOVER REQUEST message, the target eNB shall store this information and the target eNB should use the information as defined in TS 36.300 [15].

If the Additional RRM Policy Index IE is contained in the HANDOVER REQUEST message, the target eNB shall, if supported, store this information and the target eNB should use the information as defined in TS 36.300 [15].

Upon reception of UE History Information IE in the HANDOVER REQUEST message, the target eNB 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.

Upon reception of the UE History Information from the UE IE in the HANDOVER REQUEST message, the target eNB shall, if supported, store the collected information to be used for future handover preparations.

If the Mobility Information IE is provided in the HANDOVER REQUEST message, the target eNB shall, if supported, store this information and use it as defined in TS 36.300 [15]. The target eNB shall, if supported, store the C-RNTI of the source cell received in the HANDOVER REQUEST message.

If the Expected UE Behaviour IE is provided in the HANDOVER REQUEST message, the target eNB shall, if supported, store this information and may use it to determine the RRC connection time.

If the ProSe Authorized IE is contained in the HANDOVER REQUEST message and it contains one or more IEs set to "authorized", the eNB shall, if supported, consider that the UE is authorized for the relevant ProSe service(s).

If the V2X Services Authorized IE is contained in the HANDOVER REQUEST message and it contains one or more IEs set to "authorized", the eNB shall, if supported, consider that the UE is authorized for the relevant service(s).

If the UE Context Reference at the SeNB IE is contained in the HANDOVER REQUEST message the target eNB may use it as specified in TS 36.300 [15]. In this case, the source eNB may expect the target eNB 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 36.300 [15]. If the UE Context Reference at the WT IE is contained in the HANDOVER REQUEST message, the target eNB may use it as specified in TS 36.300 [15]. In this case, the source eNB may expect the target eNB to include the WT UE Context Kept Indicator IE set to "True" in the HANDOVER REQUEST ACKNOWLEDGE message; the source eNB shall use this information as specified in TS 36.300 [15].

If the UE Context Reference at the SgNB IE is contained in the HANDOVER REQUEST message the target eNB may use it as specified in TS 37.340 [32]. In this case, the source eNB may expect the target eNB 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 [32].

If the Bearer Type IE is included in the HANDOVER REQUEST message and is set to "non IP", then the target eNB shall not perform IP header compression for the concerned E-RAB.

If the Ethernet Type IE is included in the HANDOVER REQUEST message and is set to "True", then the target eNB shall, if supported, take this into account to perform header compression appropriately for the concerned E-RAB.

If the UE Sidelink Aggregate Maximum Bit Rate IE is contained in the HANDOVER REQUEST message, the target eNB shall, if supported, use it for the concerned UE’s sidelink communication in network scheduled mode for V2X services.

If the NR UE Security Capabilities IE is included in the HANDOVER REQUEST message, the target eNB shall, if supported, store this information in the UE context and send it to the respective peer node during subsequent handover preparations and/or EN-DC operations for the UE as defined in TS 33.401 [18].

If the Aerial UE subscription information IE is included in the HANDOVER REQUEST message, the target eNB shall, if supported, store this information in the UE context and use it as defined in TS 36.300 [15].

If the Subscription Based UE Differentiation Information IE is included in the HANDOVER REQUEST message, the eNB shall, if supported, store this information in the UE context for further use according to TS 23.401 [12].

If the DAPS Request Information IE is included for an E-RAB to be setup in the HANDOVER REQUEST message, the target eNB shall consider that the request concerns a DAPS handover for that E-RAB, as described in TS 36.300 [15]. Accordingly, the target eNB shall include the DAPS Response Information IE in the HANDOVER REQUEST ACKNOWLEDGE message.

If the Maximum Number of CHO Preparations IE is included in Conditional Handover Information Acknowledge IE contained in the the HANDOVER REQUEST ACKNOWLEDGE message, then the source eNB should not prepare more candidate target cells for a CHO for the same UE towards the target eNB than the number indicated in the Maximum Number of CHO Preparations 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 eNB may use the information to allocate necessary resources for the incoming CHO.

If the EPC Handover Restriction List Container IE is included in the HANDOVER REQUEST message, the target eNB shall, if supported, store this information in the UE context and shall use it as specified in TS 36.300 [15].

If the NR V2X Services Authorized IE is contained in the HANDOVER REQUEST message and it contains one or more IEs set to "authorized", the eNB 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 contained in the HANDOVER REQUEST message, the target eNB shall, if supported, use it for the concerned UE’s sidelink communication in network scheduled mode for NR V2X services.

If the PC5 QoS Parameters IE is contained in the HANDOVER REQUEST message, the target eNB shall, if supported, use it for the concerned UE’s NR sidelink communication as specified in TS 23.285 [41].

If the UE Radio Capability ID IE is contained in the HANDOVER REQUEST message, the target eNB shall, if supported, store this information in the UE context and use it as specified in TS 23.401 [12].

If the IAB Node Indication IE is contained in the HANDOVER REQUEST message, the target eNB shall, if supported, consider that the request is for an IAB node.

If the IMS Voice EPS Fallback from 5G IE is contained in the HANDOVER REQUEST message, the target eNB shall, if supported, store this information in the UE context and consider that the UE was previously handed over from NG-RAN to E-UTRAN due to an IMS voice fallback.

If the target eNB receives a HANDOVER REQUEST message containing the Source DL Forwarding IP Address IE as part of the E-RABs To Be Setup Item IE, the target eNB shall, if supported, store this information and use it as part of its ACL functionality configuration actions, if such ACL functionality is deployed.

For each E-RAB for which the Security Indication IE is included in the E-RABs To Be Setup Item IEs IE of the HANDOVER REQUEST message, and the EIA7 bit in the Integrity Protection Algorithms IE contained in UE Security Capabilities IE is set to "1":

– if the Integrity Protection Indication IE is set to "required", the target eNB shall, if supported, perform user plane integrity protection for the concerned E-RAB as specified in TS 33.401 [18], otherwise it shall reject the establishment of the concerned E-RAB with an appropriate cause value.

– if the Integrity Protection Indication IE is set to "preferred", the target eNB should perform user plane integrity protection for the concerned E-RAB as specified in TS 33.401 [18].

– if the Integrity Protection Indication IE is set to "not needed", the target eNB shall not perform user plane integrity protection for the concerned E-RAB.

Interaction with SN Status Transfer procedure:

If the UE Context Kept Indicator IE set to "True" and the E-RABs transferred to MeNB IE are included in the HANDOVER REQUEST ACKNOWLEDGE message, then the source eNB shall, if supported, include the uplink/downlink PDCP SN and HFN status received from the SgNB in the SN Status Transfer procedure towards the target eNB, as specified in TS 37.340 [32].

8.2.1.3 Unsuccessful Operation

Figure 8.2.1.3-1: Handover Preparation, unsuccessful operation

If the target eNB does not admit at least one non-GBR E-RAB, or a failure occurs during the Handover Preparation, the target eNB shall send the HANDOVER PREPARATION FAILURE message to the source eNB. The message shall contain the Cause IE with an appropriate value.

If the target eNB receives a HANDOVER REQUEST message containing RRC Context IE that does not include required information as specified in TS 36.331 [9], the target eNB shall send the HANDOVER PREPARATION FAILURE message to the source eNB.

If the Conditional Handover Information Request IE is contained in the HANDOVER REQUEST message and the target eNB rejects the handover or a failure occurs during the Handover Preparation, the target eNB 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 eNB to the HANDOVER REQUEST message before timer T_RELOCprep expires in the source eNB, the source eNB should cancel the Handover Preparation procedure towards the target eNB by initiating the Handover Cancel procedure with the appropriate value for the Cause IE. The source eNB 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 X2 UE-associated signalling.

8.2.1.4 Abnormal Conditions

If the target eNB receives a HANDOVER REQUEST message containing multiple E-RAB ID IEs (in the E-RABs To Be Setup List IE) set to the same value, the target eNB shall not admit the corresponding E-RABs.

If the target eNB receives a HANDOVER REQUEST message containing a E-RAB Level QoS Parameters IE which contains a QCI IE indicating a GBR bearer (as defined in TS 23.203 [13]), and which does not contain the GBR QoS Information IE, the target eNB shall not admit the corresponding E-RAB.

If the supported algorithms for encryption defined in the Encryption Algorithms IE in the UE Security Capabilities IE in the UE Context Information IE, plus the mandated support of EEA0 in all UEs (TS 33.401 [18]), do not match any algorithms defined in the configured list of allowed encryption algorithms in the target eNB (TS 33.401 [18]), the target eNB shall reject the procedure using the HANDOVER PREPARATION FAILURE message.

If the supported algorithms for integrity defined in the Integrity Protection Algorithms IE in the UE Security Capabilities IE in the UE Context Information IE, plus the mandated support of the EIA0 algorithm in all UEs (TS 33.401 [18]), do not match any algorithms defined in the configured list of allowed integrity protection algorithms in the eNB (TS 33.401 [18]), the eNB shall reject the procedure using the HANDOVER PREPARATION FAILURE message.

If the target eNB receives a HANDOVER REQUEST message which does not contain the Handover Restriction List IE, and the PLMN to be used cannot be determined otherwise, the target eNB shall reject the procedure using the HANDOVER PREPARATION FAILURE message.

If the target eNB receives a HANDOVER REQUEST message containing the Handover Restriction List IE, and the serving PLMN is not supported by the target cell, the target eNB shall reject the procedure using the HANDOVER PREPARATION FAILURE message.

If the target eNB receives a HANDOVER REQUEST message which does not contain the CSG Membership Status IE, and the target cell is a hybrid cell, the target eNB shall reject the procedure using the HANDOVER PREPARATION FAILURE message.

If the target cell is a CSG cell and the target eNB has not received any CSG ID of the source cell, the target eNB shall reject the procedure using the HANDOVER PREPARATION FAILURE message.

If the target cell is a CSG cell with a different CSG from the source cell, the target eNB 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 New eNB UE X2AP ID IE, or the candidate cell in the Target Cell ID IE was not prepared using the same UE-associated signaling connection, the target eNB shall reject the procedure using the HANDOVER PREPARATION FAILURE message.

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 eNB during an X2 handover, between the eNBs involved in dual connectivity and/or LWA, or between MeNB and en-gNB involved in EN-DC, for each respective E-RAB for which PDCP SN and HFN status preservation applies.

In case that the X2 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 an E-RAB associated with RLC-UM and configured with DAPS as described in TS 36.300 [15].

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

– the behaviour of the eNB from which the E-RAB context is transferred, i.e., the eNB involved in dual connectivity, LWA, RRC connection re-establishment from which data forwarding, is specified by the behaviour of the "source eNB",

– the behaviour of the eNB to which the E-RAB context is transferred, i.e., the eNB involved in dual connectivity, LWA, RRC connection re-establishment to which data is forwarded, is specified by the behaviour of the "target eNB".

– in case of EN-DC, the behaviour of the node from which the E-RAB context is transferred, i.e., either the en-gNB or the MeNB from which data is forwarded, is specified by the behaviour of the "source eNB",

– in case of EN-DC, the behaviour of the node to which the E-RAB context is transferred, i.e., either the en-gNB or the MeNB to which data is forwarded, is specified by the behaviour of the "target eNB".

The procedure uses UE-associated signalling.

8.2.2.2 Successful Operation

Figure 8.2.2.2-1: SN Status Transfer, successful operation

Figure 8.2.2.2-2: MeNB initiated SN Status Transfer for EN-DC, successful operation

Figure 8.2.2.2-3: en-gNB initiated SN Status Transfer for EN-DC, successful operation

The source eNB initiates the procedure by stop assigning PDCP SNs to downlink SDUs and stop delivering UL SDUs towards the EPC and sending the SN STATUS TRANSFER message to the target eNB at the time point when it considers the transmitter/receiver status to be frozen. The target eNB using Full Configuration for this handover as per TS 36.300 [15] or for the EN-DC operations as per TS 37.340 [32] shall ignore the information received in this message. In case of EN-DC, if the target eNB performs PDCP version change or PDCP SN length change or RLC mode change for an E-RAB as specified in TS 37.340 [32], it shall ignore the information received for that E-RAB in this message.

In case that the X2 handover is a DAPS handover, the source eNB may continue assigning PDCP SNs to downlink SDUs and delivering uplink SDUs toward the EPC when initiating this procedure for E-RABs not configured with DAPS as in TS 36.300 [15].

The E-RABs Subject To Status Transfer List IE included in the SN STATUS TRANSFER message contains the E-RAB ID(s) corresponding to the E-RAB(s) for which PDCP SN and HFN status preservation shall be applied. In case that the X2 handover is a DAPS handover, this IE may contain the E-RAB ID(s) corresponding to the E-RAB(s) associated with RLC-UM.

If the source eNB includes in the SN STATUS TRANSFER message, the information on the missing and received uplink SDUs in the Receive Status Of UL PDCP SDUs IE or Receive Status Of UL PDCP SDUs Extended IE or Receive Status Of UL PDCP SDUs for PDCP SN Length 18 IE for each E-RAB for which the source eNB has accepted the request from the target eNB for uplink forwarding, then the target eNB may use it in a Status Report message sent to the UE over the radio.

For each E-RAB for which the DL COUNT Value IE is received in the SN STATUS TRANSFER message, the target eNB shall use it to mark with the value contained in the PDCP-SN IE of this IE the first downlink packet for which there is no PDCP SN yet assigned. If the DL COUNT Value Extended IE or DL COUNT Value for PDCP SN Length 18 IE is included in the E-RABs Subject To Status Transfer Item IE, the target eNB shall, if supported, use the value contained in the PDCP-SN Extended IE of the DL COUNT Value Extended IE or PDCP-SN Length 18 IE of the DL COUNT Value for PDCP SN Length 18 IE instead of the value contained in the PDCP-SN IE of the DL COUNT Value IE.

For each E-RAB for which the UL COUNT Value IE is received in the SN STATUS TRANSFER message, the target eNB shall not deliver any uplink packet which has a PDCP SN lower than the value contained in the PDCP-SN IE of this IE. If the UL COUNT Value Extended IE or UL COUNT Value for PDCP SN Length 18 IE is included in the E-RABs Subject To Status Transfer Item IE, the target eNB shall, if supported, use the value contained in the PDCP-SN Extended IE of the UL COUNT Value Extended IE or PDCP-SN Length 18 IE of the UL COUNT Value for PDCP SN Length 18 IE instead of the value contained in the PDCP-SN IE of the UL COUNT Value IE.

EN-DC

If the en-gNB sends the message to the MeNB, then the SgNB UE X2AP ID IE shall be included in the SN STATUS TRANSFER message, while the Old eNB UE X2AP ID IE is ignored. The SgNB UE X2AP ID IE is used as the old UE ID.

If the MeNB sends the message to the en-gNB, then the SgNB UE X2AP ID IE shall be included in the SN STATUS TRANSFER message, while the New eNB UE X2AP ID IE is ignored. The SgNB UE X2AP ID IE is used as the new UE ID.

8.2.2.3 Abnormal Conditions

If the target eNB receives this message for a UE for which no prepared handover exists at the target eNB, the target eNB shall ignore the message.

8.2.3 UE Context Release

8.2.3.1 General

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

For dual connectivity, UE Context Release procedure is initiated by the MeNB to finally release the UE context at the SeNB. For dual connectivity specific mobility scenarios specified in TS 36.300 [15] only resources related to the UE-associated signalling connection between the MeNB and the SeNB are released. For EN-DC, the UE Context Release procedure is initiated by the MeNB to finally release the UE context at the en-gNB. For EN-DC specific mobility scenarios specified in TS 37.340 [32] where SCG radio resources in the en-gNB are kept, only resources related to the UE-associated signalling connection between the MeNB and the en-gNB are released.

The procedure uses UE-associated signalling.

8.2.3.2 Successful Operation

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

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

Figure 8.2.3.2-3: UE Context Release, successful operation for EN-DC

Handover

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

Upon reception of the UE CONTEXT RELEASE message, the source eNB may release radio and control plane related resources associated to the UE context. For E-RABs for which data forwarding has been performed, the source eNB should continue forwarding of U-plane data as long as packets are received at the source eNB from the EPC or the source eNB buffer has not been emptied (an implementation dependent mechanism decides that data forwarding can be stopped). When the eNB supporting L-GW function for SIPTO@LN operation releases radio and control plane related resources associated to the UE context, it shall also request using intra-node signalling the collocated L-GW to release the SIPTO@LN PDN connection as defined in TS 23.401 [12].

Dual Connectivity

The UE Context Release procedure is initiated by the MeNB. By sending the UE CONTEXT RELEASE message the MeNB informs the SeNB that the UE Context can be removed.

Upon reception of the UE CONTEXT RELEASE message, the SeNB may release radio and control plane related resources associated to the UE context. For E-RABs for which data forwarding has been performed, the SeNB should continue forwarding of U-plane data as long as packets are received at the SeNB from the EPC or the SeNB buffer has not been emptied (an implementation dependent mechanism decides that data forwarding can be stopped). The SeNB supporting L-GW function for LIPA operation shall also request using intra-node signalling the collocated L-GW to release the LIPA PDN connection as defined in TS 23.401 [12]. If the SIPTO Bearer Deactivation Indication IE is received in the UE CONTEXT RELEASE message, the SeNB supporting L-GW function for SIPTO@LN operation shall also request using intra-node signalling the collocated L-GW to release the SIPTO@LN PDN connection as defined in TS 23.401 [12].

EN-DC

The UE Context Release procedure is initiated by the MeNB. By sending the UE CONTEXT RELEASE message the MeNB informs the en-gNB that the UE Context can be removed.

Upon reception of the UE CONTEXT RELEASE message, the en-gNB may release radio and control plane related resources associated to the UE context. For E-RABs for which data forwarding has been performed, the en-gNB should continue forwarding of U-plane data as long as packets are received at the en-gNB from the EPC or the en-gNB buffer has not been emptied (an implementation dependent mechanism decides that data forwarding can be stopped).

In the course of signalling for EN-DC, the SgNB UE X2AP ID IE shall be included in the UE CONTEXT RELEASE message, while the Old eNB UE X2AP ID IE is ignored. The SgNB UE X2AP ID IE is used as the new UE ID.

Interaction with the MeNB initiated SeNB Release procedure:

The SeNB may receive the SENB RELEASE REQUEST message including the UE Context Kept Indicator IE set to "True", upon which the SeNB shall, if supported, only release the resources related to the UE-associated signalling connection between the MeNB and the SeNB, as specified in TS 36.300 [15].

Interaction with the MeNB initiated SgNB Release procedure:

The en-gNB may receive the SGNB RELEASE REQUEST message including the UE Context Kept Indicator IE set to "True", upon which the en-gNB shall, if supported, only release the resources related to the UE-associated signalling connection between the MeNB and the en-gNB, as specified in TS 37.340 [32].

8.2.3.3 Unsuccessful Operation

Not applicable.

8.2.3.4 Abnormal Conditions

If the UE Context Release procedure is not initiated towards the source eNB from any prepared eNB before the expiry of the timer TX2_RELOCoverall, the source eNB shall request the MME to release the UE context.

If the UE returns to source eNB before the reception of the UE CONTEXT RELEASE message or the expiry of the timer TX2_RELOCoverall, the source eNB shall stop the TX2_RELOCoverall and continue to serve the UE.

8.2.4 Handover Cancel

8.2.4.1 General

The Handover Cancel procedure is used to enable a source eNB to cancel an ongoing handover preparation or an already prepared handover.

The procedure uses UE-associated signalling.

8.2.4.2 Successful Operation

Figure 8.2.4.2-1: Handover Cancel, successful operation

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

At the reception of the HANDOVER CANCEL message, the target eNB shall remove any reference to, and release any resources previously reserved to the concerned UE context.

The New eNB UE X2AP ID IE and, if available, the New eNB UE X2AP ID Extension IE shall be included if it has been obtained from the target eNB.

If the Candidate Cells To Be Cancelled List IE is included in the HANDOVER CANCEL message, the target eNB shall consider that the source eNB is cancelling only the handover associated to the candidate cells identified by the included ECGI and associated to the UE-associated signaling connection identified by the Old eNB UE X2AP ID IE (or the Old eNB UE X2AP ID Extension IE if included) and, if included , also by the New eNB UE X2AP ID IE (or the New eNB UE X2AP ID Extension IE if included).

8.2.4.3 Unsuccessful Operation

Not applicable.

8.2.4.4 Abnormal Conditions

Should the HANDOVER CANCEL message refer to a context that does not exist, the target eNB 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 eNB 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 eNB shall ignore those non-associated candidate cells.

8.2.5 Handover Success

8.2.5.1 General

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

The procedure uses UE-associated signalling.

8.2.5.2 Successful Operation

Figure 8.2.5.2-1: Handover Success, successful operation

The target eNB initiates the procedure by sending the HANDOVER SUCCESS message to the source eNB.

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

When the source eNB 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 eNB 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 eNB node shall consider that the UE successfully executed the handover. The source eNB may initiate Handover Cancel procedure towards the other signaling connections or other candidate target eNBs for this UE, if any.

8.2.5.3 Unsuccessful Operation

Not applicable.

8.2.5.4 Abnormal Conditions

If the HANDOVER SUCCESS message refers to a context that does not exist, the source eNB shall ignore the message.

8.2.6 Conditional Handover Cancel

8.2.6.1 General

The Conditional Handover Cancel procedure is used to enable a target eNB to cancel an already prepared conditional handover.

The procedure uses UE-associated signalling.

8.2.6.2 Successful Operation

Figure 8.2.6.2-1: Conditional Handover Cancel, successful operation

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

The New eNB UE X2AP ID IE and, if available, the New eNB UE X2AP ID Extension IE shall be included.

At the reception of the CONDITIONAL HANDOVER CANCEL message, the source eNB shall consider that the target eNB 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 Old eNB UE X2AP ID IE (or the Old eNB UE X2AP ID Extension IE if included) and the New eNB UE X2AP ID IE (or the New eNB UE X2AP ID Extension IE if included).

If the Candidate Cells To Be Cancelled List IE is also included, the source eNB shall consider that only the resources reserved for the cells identified by the included ECGI are about to be released.

8.2.6.3 Unsuccessful Operation

Not applicable.

8.2.6.4 Abnormal Conditions

Should the CONDITIONAL HANDOVER CANCEL message refer to a context that does not exist, the source eNB 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 eNB shall ignore those non-associated candidate cells.

8.2.7 Early Status Transfer

8.2.7.1 General

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

For Dual Connectivity or EN-DC, the Early Status Transfer procedure is also used, during a Conditional Handover, from the SeNB to the MeNB as specified in TS 36.300 [15], or from the en-gNB to the MeNB as specified in TS 37.340 [32].

For Conditional PSCell Addition in EN-DC, the Early Status Transfer procedure is also used, from the MeNB to the en-gNB as specified in TS 37.340 [32].

For Conditional PSCell Change in EN-DC, the Early Status Transfer procedure is also used, from the source en-gNB to the MeNB, and from the MeNB to the target en-gNB, as specified in TS 37.340 [32].

The procedure uses UE-associated signalling.

8.2.7.2 Successful Operation

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

Figure 8.2.7.2-2: Early Status Transfer during Conditional Handover in dual connectivity or EN-DC operation, successful operation

Figure 8.2.7.2-3: Early Status Transfer during CPAC in EN-DC operation, successful operation

From source eNB to target eNB

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

For each E-RAB for which the FIRST DL COUNT Value IE is received in the EARLY STATUS TRANSFER message, the target eNB shall use it as the COUNT of the first downlink SDU that the source eNB forwards to the target eNB. If the FIRST DL COUNT Value Extended IE or FIRST DL COUNT Value for PDCP SN Length 18 IE is included in the E-RABs Subject To Early Status Transfer Item IE, the target eNB shall, if supported, use this value instead of the value contained in the FIRST DL COUNT Value IE.

For each E-RAB for which the DISCARD DL COUNT Value IE is received in the EARLY STATUS TRANSFER message, the target eNB 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. If the DISCARD DL COUNT Value Extended IE or DISCARD DL COUNT Value for PDCP SN Length 18 IE is included in the E-RABs Subject To Early Status Transfer Item IE, the target eNB shall, if supported, use this value instead of the value contained in the DISCARD DL COUNT Value IE.

From SeNB (respectively, en-gNB) to MeNB, the source eNB for Conditional Handover

From MeNB to en-gNB for CPA

From source en-gNB to MeNB, and from MeNB to target en-gNB, for CPC

The E-RABs Subject To Early Status Transfer List IE included in the EARLY STATUS TRANSFER message contains the E-RAB ID(s) corresponding to the E-RAB(s) transferred during Conditional Handover or during CPAC.

For each E-RAB in the E-RABs Subject To Early Status Transfer List IE, the source eNB shall forward to the target during Conditional Handover, or the sending node shall forward to the receiving node during CPAC, the value of the received FIRST DL COUNT Value IE or DISCARD DL COUNT Value IE. If the FIRST DL COUNT Value Extended IE or FIRST DL COUNT Value for PDCP SN Length 18 IE is included, if supported, this value is forwarded instead of the value contained in the FIRST DL COUNT Value IE. If the DISCARD DL COUNT Value Extended IE or DISCARD DL COUNT Value for PDCP SN Length 18 IE is included, if supported, this value is forwarded instead of the value contained in the DISCARD DL COUNT Value IE.

If the en-gNB sends the message to the MeNB, then the SgNB UE X2AP ID IE shall be included in the EARLY STATUS TRANSFER message, while the Old eNB UE X2AP ID IE is ignored. The SgNB UE X2AP ID IE is used as the old UE ID.

8.2.7.3 Abnormal Conditions

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