8.4 Handover Signalling

36.4133GPPEvolved Universal Terrestrial Radio Access Network (E-UTRAN)Release 17S1 Application Protocol (S1AP)TS

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

8.4.1 Handover Preparation

8.4.1.1 General

The purpose of the Handover Preparation procedure is to request the preparation of resources at the target side via the EPC. There is only one Handover Preparation procedure ongoing at the same time for a certain UE.

8.4.1.2 Successful Operation

Figure 8.4.1.2-1: Handover preparation: successful operation

The source eNB initiates the handover preparation by sending the HANDOVER REQUIRED message to the serving MME. When the source eNB sends the HANDOVER REQUIRED message, it shall start the timer TS1_RELOCprep.The source eNB shall indicate the appropriate cause value for the handover in the Cause IE.

The source eNB shall include the Source to Target Transparent Container IE in the HANDOVER REQUIRED message.

In case of intra-system handover, the information in the Source to Target Transparent Container IE shall be encoded according to the definition of the Source eNB to Target eNB Transparent Container IE. In case of handover to UTRAN, the information in the Source to Target Transparent Container IE shall be encoded according to the Source RNC to Target RNC Transparent Container IE definition as specified in TS 25.413 [19] and the source eNB shall include the UE History Information IE in the Source RNC to Target RNC Transparent Container IE. If the handover is to GERAN A/Gb mode then the information in the Source to Target Transparent Container IE shall be encoded according to the definition of the Source BSS to Target BSS Transparent Container IE as described in TS 48.018 [18]. If the handover is to NG-RAN, the information in the Source to Target Transparent Container IE shall be encoded according to the Source NG-RAN Node to Target NG-RAN Node Transparent ContainerIE definition as specified in TS 38.413 [44].

When the preparation, including the reservation of resources at the target side is ready, the MME responds with the HANDOVER COMMAND message to the source eNB.

If the Target to Source Transparent Container IE has been received by the MME from the handover target then the transparent container shall be included in the HANDOVER COMMAND message.

Upon reception of the HANDOVER COMMAND message the source eNB shall stop the timer TS1_RELOCprep and start the timer TS1_RELOCOverall.

In case of intra-system handover, the information in the Target to Source Transparent Container IE shall be encoded according to the definition of the Target eNB to Source eNB Transparent Container IE. In case of inter-system handover to UTRAN, the information in the Target to Source Transparent Container IE shall be encoded according to the Target RNC to Source RNC Transparent Container IE definition as specified in TS 25.413 [19]. In case of inter-system handover to GERAN A/Gb mode, the information in the Target to Source Transparent Container IE shall be encoded according to the Target BSS to Source BSS Transparent Container IE definition as described in TS 48.018 [18]. In case of inter-system handover to NG-RAN, the information in the Target to Source Transparent Container IE shall be encoded according to the Target NG-RAN Node to Source NG-RAN Node Transparent Container IE definition as specified in TS 38.413 [44].

If the Direct Forwarding Path Availability IE is included in the Target NG-RAN Node to Source NG-RAN Node Transparent Container IE within the HANDOVER COMMAND message, the source eNB shall, if supported, use it for direct data forwarding between the source SN and the target NG-RAN node.

If there are any E-RABs that could not be admitted in the target, they shall be indicated in the E-RABs to Release List IE.

If the DL forwarding IE is included within the Source eNB to Target eNB Transparent Container IE of the HANDOVER REQUIRED message and it is set to “DL forwarding proposed”, it indicates that the source eNB proposes forwarding of downlink data.

If the Security Indication IE is included within the Source eNB to Target eNB Transparent Container IE of the HANDOVER REQUIRED message, it indicates the security policy stored in the source eNB for the concerned E-RAB, as specified in TS 33.401 [15].

If the Security Result IE is included within the Target eNB to Source eNB Transparent Container IE of the HANDOVER COMMAND message, the source eNB shall take it into account as the status of integrity protection configured by the target eNB for the concerned E-RAB.

If the MME receives the Direct Forwarding Path Availability IE in the HANDOVER REQUIRED message indicating that a direct data path is available, it shall handle it as specified in TS 23.401 [11].

If the CSG Id IE and no Cell Access Mode IE are received in the HANDOVER REQUIRED message, the MME shall perform the access control according to the CSG Subscription Data of that UE and, if the access control is successful or if at least one of the E-RABs has a particular ARP value (see TS 23.401 [11]), it shall continue the handover and propagate the CSG Id IE to the target side. If the access control is unsuccessful but at least one of the E-RABs has a particular ARP value (see TS 23.401 [11]) the MME shall also provide the CSG Membership Status IE set to “non member” to the target side.

If the CSG Id IE and the Cell Access Mode IE set to “hybrid” are received in the HANDOVER REQUIRED message, the MME shall provide the membership status of the UE and the CSG Id to the target side.

The source eNB shall include the SRVCC HO Indication IE in the HANDOVER REQUIRED message if the SRVCC operation is needed as defined in TS 23.216 [9]. The source eNB shall indicate to the MME in the SRVCC HO Indication IE if the handover shall be prepared for PS and CS domain or only for CS domain. The SRVCC HO Indication IE is set according to the target cell capability and UE capability. In case the target system is GERAN without DTM support or the UE is without DTM support, the source eNB shall indicate “CS only” in the SRVCC HO Indication IE and “PS service not available” in PS Service Not Available IE. In case the target system is either GERAN with DTM but without DTM HO support and the UE is supporting DTM or the target system is UTRAN without PS HO support, the source eNB shall indicate “CS only” in the SRVCC HO Indication IE. Otherwise, the source eNB shall indicate “PS and CS” in the SRVCC HO Indication IE.

In case of inter-system handover from E-UTRAN, the source eNB shall indicate in the Target ID IE, in case the target system is UTRAN, the Target RNC-ID of the RNC (including the Routing Area Code only in case the UTRAN PS domain is involved), in case the target system is GERAN the Cell Global Identity (including the Routing Area Code only in case the GERAN PS domain is involved) of the cell, and in case the target system is NG-RAN the Target NG-RAN Node ID of the NG-RAN node in the target system.

In case of inter-system handover from E-UTRAN to UTRAN, the source eNB shall, if supported, include the HO Cause Value IE in the UE History Information IE of the HANDOVER REQUIRED message.

In case the SRVCC operation is performed and the SRVCC HO Indication IE indicates that handover shall be prepared only for CS domain, and if

– the target system is GERAN, then the source eNB

– shall encode the information in the Source to Target Transparent Container IE within the HANDOVER REQUIRED message, according to the definition of the Old BSS to New BSS information IE as specified in TS 48.008 [23], and

– shall not include the Source to Target Transparent Container Secondary IE in the HANDOVER REQUIRED message;

– the target system is UTRAN, then the source eNB

– shall encode the information in the Source to Target Transparent Container IE within the HANDOVER REQUIRED message according to the definition of the Source RNC to Target RNC Transparent Container IE as specified in TS 25.413 [19],

– shall include the UE History Information IE in the Source RNC to Target RNC Transparent Container IE, and

– shall not include the Source to Target Transparent Container Secondary IE in the HANDOVER REQUIRED message.

In case the SRVCC operation is performed, the SRVCC HO Indication IE in the HANDOVER REQUIRED message indicates that handover shall be prepared for PS and CS domain, and if

– the target system is GERAN with DTM HO support, then the source eNB

– shall encode the information in the Source to Target Transparent Container IE within the HANDOVER REQUIRED message according to the definition of the Source BSS to Target BSS Transparent Container IE as described in TS 48.018 [18],and

– shall include the Source to Target Transparent Container Secondary IE in the HANDOVER REQUIRED message and encode information in it according to the definition of the Old BSS to New BSS information IE as specified in TS 48.008 [23];

– the target system is UTRAN, then the source eNB

– shall encode the information in the Source to Target Transparent Container IE within the HANDOVER REQUIRED message according to the definition of the Source RNC to Target RNC Transparent Container IE as specified in TS 25.413 [19],

– shall include the UE History Information IE in the Source RNC to Target RNC Transparent Container IE, and

– shall not include the Source to Target Transparent Container Secondary IE in the HANDOVER REQUIRED message.

In case the SRVCC operation is performed, the SRVCC HO Indication IE in the HANDOVER REQUIRED message indicates that handover shall be prepared only for CS domain, and if

– the target system is GERAN, then the MME

– shall encode the information in the Target to Source Transparent Container IE within the HANDOVER COMMAND message according to the definition of the Layer 3 Information IE as specified in TS 48.008 [23], and

– shall not include the Target to Source Transparent Container Secondary IE in the HANDOVER COMMAND message;

– the target system is UTRAN, then the MME

– shall encode the information in the Target to Source Transparent Container IE within the HANDOVER COMMAND message according to the definition of the Target RNC to Source RNC Transparent Container IE as specified in TS 25.413 [19], and

– shall not include the Target to Source Transparent Container Secondary IE in the HANDOVER COMMAND message.

In case the SRVCC operation is performed, the SRVCC HO Indication IE in the HANDOVER REQUIRED message indicates that handover shall be prepared for PS and CS domain,

– the target system is GERAN with DTM HO support, and if

– the Handover Preparation procedure has succeeded in the CS and PS domain, then the MME

– shall encode the information in the Target to Source Transparent Container IE within the HANDOVER COMMAND message according to the definition of the Layer 3 Information IE as specified in TS 48.008 [23], and

– shall include the Target to Source Transparent Container Secondary IE in the HANDOVER COMMAND message and encode information in it according to the definition of the Target BSS to Source BSS Transparent Container IE as specified in TS 48.018 [18];

– the Handover Preparation procedure has succeeded in the CS domain only, then the MME

– shall not include the Target to Source Transparent Container Secondary IE in the HANDOVER COMMAND message;

– the target system is UTRAN, then the Handover Preparation procedure shall be considered successful if the Handover Preparation procedure has succeeded in the CS domain, and the MME

– shall not include the Target to Source Transparent Container Secondary IE in the HANDOVER COMMAND message.

If the HANDOVER COMMAND message contains the DL GTP-TEID IE and the DL Transport Layer Address IE for a given bearer in the E-RABs Subject to Forwarding List IE, then the source eNB shall consider that the forwarding of downlink data for this given bearer is possible.

If the HANDOVER COMMAND message contains the UL GTP-TEID IE and the UL Transport Layer Address IE for a given bearer in the E-RABs Subject to Forwarding List IE, then it means the target eNB has requested the forwarding of uplink data for this given bearer.

If the DAPS Request Information IE is included for an E-RAB in the Source eNB to Target eNB Transparent Container IE within the HANDOVER REQUIRED message, it indicates that the request concerns a DAPS Handover for that E-RAB, as described in TS 36.300 [14].

If the Direct Forwarding Path Availability IE is included in the Target eNB to Source eNB Transparent Container IE, the source eNB shall, if supported, use it for direct data forwarding between the source SN and the target eNB as specified in TS 37.340 [32].

Interactions with E-RAB Management procedures:

If, after a HANDOVER REQUIRED message is sent and before the Handover Preparation procedure is terminated, the source eNB receives an MME initiated E-RAB Management procedure on the same UE associated signalling connection, the source eNB shall either:

1. cancel the Handover Preparation procedure by executing the Handover Cancel procedure with an appropriate cause value. After successful completion of the Handover Cancel procedure, the source eNB shall continue the MME initiated E-RAB Management procedure

2. terminate the MME initiated E-RAB Management procedure by sending the appropriate response message with an appropriate cause value, e.g., “S1 intra system Handover Triggered”, “S1 inter system Handover Triggered” to the MME and then the source eNB shall continue with the handover procedure.

Interaction with Handover Cancel procedures:

If the Security Result IE is not included in the Target eNB to Source eNB Transparent Container IE of the HANDOVER COMMAND message, and the Security Indication IE in the Source eNB to Target eNB Transparent Container IE indicated that some of the E-RABs required User Plane Integrity Protection, the source eNB shall initiate the Handover Cancel procedure. The source eNB may reattempt the handover but only for the E-RABs that do not require User Plane Integrity Protection.

8.4.1.3 Unsuccessful Operation

Figure 8.4.1.3-1: Handover preparation: unsuccessful operation

If the EPC or the target system is not able to accept any of the bearers or a failure occurs during the Handover Preparation, the MME sends the HANDOVER PREPARATION FAILURE message with an appropriate cause value to the source eNB.

If the CSG Id IE and no Cell Access Mode IE are received in the HANDOVER REQUIRED message and the access control is unsuccessful and none of the E-RABs has a particular ARP value (see TS 23.401 [11]) the MME shall send the HANDOVER PREPARATION FAILURE message with an appropriate cause value to the source eNB, except when one of the E-RABs has a particular ARP value (see TS 23.401 [11]). Upon reception, the source eNB may decide to prevent handover for that UE towards CSG (Closed Access Mode) cells with corresponding CSG Id.

Interaction with Handover Cancel procedure:

If there is no response from the EPC to the HANDOVER REQUIRED message before timer TS1_RELOCprep expires in the source eNB, the source eNB should cancel the Handover Preparation procedure by initiating the Handover Cancel procedure with the appropriate value for the Cause IE. The source eNB shall ignore any HANDOVER COMMAND message or HANDOVER PREPARATION FAILURE message received after the initiation of the Handover Cancel procedure.

8.4.1.4 Abnormal Conditions

If the eNB receives at least one E-RAB ID included in the E-RABs Subject to Forwarding List IE without at least one valid associated tunnel address pair (in either UL or DL), then the eNB shall consider it as a logical error and act as described in subclause 10.4. A GTP tunnel address pair is considered valid if both the GTP-TEID IE and the Transport Layer Address IE are present.

8.4.2 Handover Resource Allocation

8.4.2.1 General

The purpose of the Handover Resource Allocation procedure is to reserve resources at the target eNB for the handover of a UE.

8.4.2.2 Successful Operation

Figure 8.4.2.2-1: Handover resource allocation: successful operation

The MME initiates the procedure by sending the HANDOVER REQUEST message to the target eNB. The HANDOVER REQUEST message may contain the Handover Restriction List IE, which contains roaming or access restrictions.

If the Handover Restriction List IE is contained in the HANDOVER REQUEST message, the target eNB shall store this information in the UE context. This information shall however not be considered whenever one of the handed over E-RABs has a particular ARP value (TS 23.401 [11]).

The target eNB shall use the information in Handover Restriction List IE if present in the HANDOVER REQUEST message to

– determine a target for subsequent mobility action for which the eNB provides information about the target of the mobility action towards the UE;

– select a proper SCG during dual connectivity operation.

If the Handover Restriction List IE is not contained in the HANDOVER REQUEST message, the target eNB shall consider that no roaming and no access restriction apply to the UE.

Upon reception of the HANDOVER REQUEST message, the eNB shall store the received UE Security Capabilities IE in the UE context and use it to prepare the configuration of the AS security relation with the UE.

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

Upon reception of the HANDOVER REQUEST message, the eNB shall store the received Security Context IE in the UE context and the eNB shall use it to derive the security configuration as specified in TS 33.401 [15].

If the Trace Activation IE is included in the HANDOVER REQUEST message, the target eNB shall if supported, initiate the requested trace function as described in TS 32.422 [10]. In particular, the 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 [10];

– 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 [10];

– if the Trace Activation IE includes the MDT Activation IE, within the MDT Configuration IE, set to “Immediate MDT Only”, “Logged MDT only” or “Logged MBSFN MDT”, initiate the requested MDT session as described in TS 32.422 [10] 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 MBSFN-ResultToLog 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 MBSFN-AreaId IE in the MBSFN-ResultToLog 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 UE Application layer measurement configuration IE, initiate the requested trace session and QoE Measurement Collection function as described in TS 36.300 [14].

– 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 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 CSG Id IE is received in the HANDOVER REQUEST message, the eNB shall compare the received value with the CSG Id broadcast by the target cell.

If the CSG Membership Status IE is received in the HANDOVER REQUEST message and the CSG Membership Status is set to “member”, the eNB may provide the QoS to the UE as for member provided that the CSG Id received in the HANDOVER REQUEST messages corresponds to the CSG Id broadcast by the target cell.

If the CSG Membership Status IE and the CSG Id IE are received in the HANDOVER REQUEST message and the CSG Id does not correspond to the CSG Id broadcast by the target cell, the eNB may provide the QoS to the UE as for a non member and shall send back in the HANDOVER REQUEST ACKNOWLEDGE message the actual CSG Id broadcast by the target cell.

If the target cell is CSG cell or hybrid cell, the target eNB shall include the CSG ID IE in the HANDOVER REQUEST ACKNOWLEDGE message.

If the target eNB receives the CSG Id IE and the CSG Membership Status IE is set to “non member” in the HANDOVER REQUEST message and the target cell is a closed cell and at least one of the E-RABs has a particular ARP value (see TS 23.401 [11]), the eNB shall send back the HANDOVER REQUEST ACKNOWLEDGE message to the MME accepting those E-RABs and failing the other E-RABs.

If the Subscriber Profile ID for RAT/Frequency priority IE is contained in the Source eNB to Target eNB Transparent Container IE, the target eNB shall store the content of the received Subscriber Profile ID for RAT/Frequency priority IE in the UE context and use it as defined in TS 36.300 [14].

If the Additional RRM Policy Index IE is contained in the Source eNB to Target eNB Transparent Container IE, the target eNB shall, if supported, store it and use it as defined in TS 36.300 [14].

Upon reception of the UE History Information IE, which is included within the Source eNB to Target eNB Transparent Container 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, which is included within the Source eNB to Target eNB Transparent Container 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 included within the Source eNB to Target eNB Transparent Container IE in the HANDOVER REQUEST message, the target eNB shall, if supported, store this information and use it as defined in TS 36.300 [14].

If the Emergency Indicator IE is included within the Source eNB to Target eNB Transparent Container IE in the HANDOVER REQUEST message, the target eNB shall, if supported, use it to allocate radio bearer resources as specified in TS 23.502 [51].

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

If the Bearer Type IE is included in the HANDOVER REQUEST message and is set to "non IP", then the 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 eNB shall, if supported, take this into account to perform header compression appropriately for the concerned E-RAB.

In case of inter-system handover from gNB with direct forwarding, if the target eNB receives the UE Context Reference at Source IE in the Source eNB to Target eNB Transparent Container IE, it may use it for internal forwarding as specified in TS 37.340 [47].

After all necessary resources for the admitted E-RABs have been allocated, the target eNB shall generate the HANDOVER REQUEST ACKNOWLEDGE message. The target eNB shall include in the E-RABs Admitted List IE the E-RABs for which resources have been prepared at the target cell. The E-RABs that have not been admitted in the target cell, if any, shall be included in the E-RABs Failed to Setup List IE.

If the HANDOVER REQUEST message contains the Data Forwarding Not Possible IE associated with a given E-RAB within the E-RABs To Be Setup List IE set to “Data forwarding not possible”, then the target eNB may decide not to include the DL Transport Layer Address IE and the DL GTP-TEID IE and for intra LTE handover the UL Transport Layer Address IE and the UL GTP-TEID IE within the E-RABs Admitted List IE of the HANDOVER REQUEST ACKNOWLEDGE message for that E-RAB.

For each bearer that target eNB has decided to admit and for which DL forwarding IE is set to “DL forwarding proposed”, the target eNB may include the DL GTP-TEID IE and the DL Transport Layer Address IE within the E-RABs Admitted List IE of the HANDOVER REQUEST ACKNOWLEDGE message indicating that it accepts the proposed forwarding of downlink data for this bearer.

If the HANDOVER REQUEST ACKNOWLEDGE message contains the UL GTP-TEID IE and the UL Transport Layer Address IE for a given bearer in the E-RABs Admitted List IE, then it means the target eNB has requested the forwarding of uplink data for this given bearer.

If the Request Type IE is included in the HANDOVER REQUEST message, then the target eNB should perform the requested location reporting functionality for the UE as described in subclause 8.11.

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

The GUMMEI IE shall only be contained in the HANDOVER REQUEST message according to subclauses 4.6.2 and 4.7.6.6 of TS 36.300 [14]. If the GUMMEI IE is present, the target eNB shall store this information in the UE context and use it for subsequent X2 handovers.

The MME UE S1AP ID 2 IE shall only be contained in the HANDOVER REQUEST message according to subclause 4.6.2 of TS 36.300 [14].If the MME UE S1AP ID 2 IE is present, the target eNB shall store this information in the UE context and use it for subsequent X2 handovers.

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 selections of the UE for management based MDT defined in TS 32.422 [10].

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.

If the HANDOVER REQUEST contains a Target Cell ID IE, as part of the Source eNB to Target eNB Transparent Container IE, for a cell which is no longer active, the eNB may respond with an HANDOVER REQUEST ACKNOWLEDGE in case the PCI of the deactivated cell is in use by another active cell.

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 UE User Plane CIoT Support Indicator IE is included in the HANDOVER REQUEST message and is set to "supported", the eNB shall, if supported, consider that User Plane CIoT EPS Optimisation as specified in TS 23.401 [11] is supported for the UE.

If the CE-mode-B Support Indicator IE is included in the HANDOVER REQUEST ACKNOWLEDGE message and set to "supported", the MME shall, if supported, take this information into account when setting NAS timer values for the UE as specified in TS 24.301[24].

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 Sidelink Aggregate Maximum Bit Rate IE is included in the HANDOVER REQUEST message, the eNB shall, if supported, use the received value for the concerned UE’s sidelink communication in network scheduled mode for V2X services.

If the Enhanced Coverage Restricted IE is included in the HANDOVER REQUEST message, the eNB shall store this information in the UE context and use it as defined in TS 23.401 [11].

If the CE-Mode-B Restricted IE is included in the HANDOVER REQUEST message and the Enhanced Coverage Restricted IE is not set to restricted and the Enhanced Coverage Restricted information stored in the UE context is not set to restricted, the eNB shall store this information in the UE context and use it as defined in TS 23.401 [11].

If the NR UE Security Capabilities IE is included in the HANDOVER REQUEST message, the eNB shall, if supported, store this information in the UE context and use it as defined in TS 33.401 [15].

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

If the Pending Data Indication IE is included in the HANDOVER REQUEST message, the eNB shall use it as defined in TS 23.401 [11].

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 [11].

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

If the HANDOVER REQUEST message is received for an handover originating from a source NG-RAN node, the list of E-RABs contained in the source eNB to target eNB Transparent Container which are not included in the HANDOVER REQUEST message shall be considered as not to be handed over and ignored.

If the IAB Authorized IE is contained in the HANDOVER REQUEST message, the target eNB shall, if supported, consider that the handover is for an IAB-node.

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 included in the HANDOVER REQUEST message, the eNB shall, if supported, use the received value for the concerned UE’s sidelink communication in network scheduled mode for NR V2X services.

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

If the Inter-system measurement Configuration IE is included within the Source eNB to Target eNB Transparent Container IE in the HANDOVER REQUEST message, the target eNB shall, if supported, use it as defined in TS 38.300 [45]. The Inter System Measurement Configuration IE shall contain at least one of the RSRP, RSRQ or SINR thresholds. If only one of the thresholds is present, the LTE eNB shall use the present threshold to compare against the measurement results received from the UE. If more than one thresholds are present, the received radio measurements must exceed all thresholds in order to satisfy the indicated radio conditions. The target eNB shall, if supported, report the measurement results to the source NR node by including the Inter-System Handover Report IE (defined in TS 38. 413 [44]) in the eNB CONFIGURATION TRANSFER message only if:

– there is either a single source NR related cell whose measurement results exceed the threshold(s) for the whole measurement duration, or a group of source NR associated cells which together provide such coverage; and

– the above is fulfilled for the whole measurement duration, in which case the Early IRAT HO IE contained in the Inter-System Handover Report IE (defined in TS 38. 413 [44]) shall be set to "false", or the above is fulfilled until the UE is handed over back to NR within the measurement duration, in which case the Early IRAT HO IE contained in the Inter-System Handover Report IE (defined in TS 38. 413 [44]) shall be set to "true".

The cells that exceed the threshold in the first UE measurement report are included in the Inter-system Handover Report.

If the UE Radio Capability ID IE is included in the HANDOVER REQUEST message, the eNB shall, if supported, use it as defined in TS 23.401 [11].

If the DAPS Request Information IE is included for an E-RAB in the Source eNB to Target eNB Transparent Container IE within 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 [14]. The target eNB shall include the DAPS Response information List IE in the Target eNB to Source eNB Transparent Container IE within the HANDOVER REQUEST ACKNOWLEDGE message, containing the DAPS Response Information IE for each E-RAB requested to be configured with DAPS Handover.

If the IMS voice EPS fallback from 5G IE is included in the Source eNB to Target eNB Transparent Container IE within the HANDOVER REQUEST message, the target eNB shall, if supported, store the information in the UE context and consider that the UE is handed over from NG-RAN to E-UTRAN due to an IMS voice fallback.

If the Security Indication IE is contained in the HANDOVER REQUEST message, the target eNB shall, if supported, act as defined in the E-RAB Setup procedure for the concerned E-RAB.

If the Security Indication IE is included in the Source eNB to Target eNB Transparent Container IE within the HANDOVER REQUEST message, the target eNB shall, if supported, use it as specified in TS 33.401 [15] and include the Security Result IE in the Target eNB to Source eNB Transparent Container IE of the HANDOVER REQUEST ACKNOWLEDGE message.

If the UE Context Reference at Source eNB IE is included in the Source eNB to Target eNB Transparent Container IE within the HANDOVER REQUEST message, the target eNB may use it to identify an existing UE.

If for a given E-RAB flow the Source Transport Layer Address IE is included within the Source eNB to Target eNB Transparent Container IE in the HANDOVER REQUEST message, the target eNB shall, if supported, store this information and use it as part of its ACL functionality configuration actions for direct data forwarding, if such ACL functionality is deployed.

If the UE Radio Capability ID IE is contained in the HANDOVER REQUEST message, the target eNB may include the RACS Indication IE in the Target eNB to Source eNB Transparent Container IE within the HANDOVER REQUEST ACKNOWLEDGE message, to indicate that it is able to acquire the UE radio capabilities through reception of the UE Radio Capability ID in future mobility actions as described in TS 23.401 [11].

If for a given E-RAB the Source Node Transport Layer Address IE is included within the Source eNB to Target eNB Transparent Container IE in the HANDOVER REQUEST message, the target eNB shall, if supported, store this information and use it as part of its ACL functionality configuration actions for direct data forwarding, if such ACL functionality is deployed.

If the Source SN ID IE is included in the Source eNB to Target eNB Transparent Container IE within the HANDOVER REQUEST message, the target eNB shall, if supported, use it to decide whether direct forwarding path is available between the target eNB and this source RAN node. If the direct forwarding path is available, the target eNB shall include the Direct Forwarding Path Availability IE in the Target eNB to Source eNB Transparent Container IE within the HANDOVER REQUEST ACKNOWLEDGE message.

If the Direct Forwarding Path Availability IE is included in the Source eNB to Target eNB Transparent Container IE within the HANDOVER REQUEST message, the target eNB may use the information to assign tunnel endpoints in case of inter-system handover.

8.4.2.3 Unsuccessful Operation

Figure 8.4.2.3-1: Handover resource allocation: unsuccessful operation

If the target eNB does not admit at least one non-GBR E-RAB, or a failure occurs during the Handover Preparation, it shall send the HANDOVER FAILURE message to the MME with an appropriate cause value.

If the target eNB does not receive the CSG Membership Status IE but does receive the CSG Id IE in the HANDOVER REQUEST message and the CSG Id does not correspond to the CSG Id of the target cell, the target eNB shall send the HANDOVER FAILURE message to the MME with an appropriate cause value.

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

8.4.2.4 Abnormal Conditions

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 target eNB receives a HANDOVER REQUEST message containing several 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 Subscriber Profile ID for RAT/Frequency priority IE is not contained in the Source eNB to Target eNB Transparent Container IE whereas available in the source eNB, the target eNB shall trigger a local error handling.

NOTE: It is assumed that the information needed to verify this condition is visible within the system, see subclause 4.1.

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

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

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

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

8.4.3 Handover Notification

8.4.3.1 General

The purpose of the Handover Notification procedure is to indicate to the MME that the UE has arrived to the target cell and the S1 handover has been successfully completed.

8.4.3.2 Successful Operation

Figure 8.4.3.2-1: Handover notification

The target eNB shall send the HANDOVER NOTIFY message to the MME when the UE has been identified in the target cell and the S1 handover has been successfully completed.

If the Tunnel Information for BBF IE is received in the HANDOVER NOTIFY message, the MME shall, if supported, use it in the core network as specified in TS 23.139 [37].

If the LHN ID IE is included in the HANDOVER NOTIFY message, the MME shall, if supported, use it as specified in TS 23.401 [11].

If the UE is configured with EN-DC radio resources and the PSCell information is available, the PSCell Information IE shall be included in the HANDOVER NOTIFY message.

Interactions with Handover Success procedure:

If the Notify Source eNB IE is included in the HANDOVER NOTIFY message, the MME shall, if supported, notify the source eNB that the UE has successfully accessed the target eNB by sending the HANDOVER SUCCESS message.

8.4.3.3 Abnormal Conditions

Not applicable.

8.4.4 Path Switch Request

8.4.4.1 General

The purpose of the Path Switch Request procedure is to establish a UE associated signalling connection to the EPC and, if applicable, to request the switch of a downlink GTP tunnel towards a new GTP tunnel endpoint.

8.4.4.2 Successful Operation

Figure 8.4.4.2-1: Path switch request: successful operation

The eNB initiates the procedure by sending the PATH SWITCH REQUEST message to the MME.

If the ‎E-RAB To Be Switched in Downlink List IE in the PATH SWITCH REQUEST message does not include all E-RABs previously included in the UE Context, the MME shall consider the non included E-RABs as implicitly released by the eNB.

When the eNB has received from the radio interface the RRC Resume Cause IE, it shall include it in the PATH SWITCH REQUEST message.

After all necessary updates including the UP path switch have been successfully completed in the EPC for at least one of the E-RABs included in the PATH SWITCH REQUEST E-RAB To Be Switched in Downlink List IE, the MME shall send the PATH SWITCH REQUEST ACKNOWLEDGE message to the eNB and the procedure ends. The UE-associated logical S1-connection shall be established at reception of the PATH SWITCH REQUEST ACKNOWLEDGE message.

In case the EPC failed to perform the UP path switch for at least one, but not all, of the E-RABs included in the PATH SWITCH REQUEST E-RAB To Be Switched in Downlink List IE, the MME shall include the E-RABs it failed to perform UP path switch in the PATH SWITCH REQUEST ACKNOWLEDGE E-RAB To Be Released List IE. In this case, the eNB shall release the corresponding data radio bearers, and the eNB shall regard the E-RABs indicated in the E-RAB To Be Released List IE as being fully released.

If the CSG Id IE and no Cell Access Mode IE are received in the PATH SWITCH REQUEST message, the MME shall use it in the core network as specified in TS 23.401 [11]. If the CSG Id IE and the Cell Access Mode IE set to “hybrid” are received in the PATH SWITCH REQUEST message, the MME shall decide the membership status of the UE and use it in the core network as specified in TS 23.401 [11]. If no CSG Id IE and no Cell Access Mode IE are received in the PATH SWITCH REQUEST message and the UE was previously either in a CSG cell or in a hybrid cell, the MME shall consider that the UE has moved into a cell that is neither a CSG cell nor a hybrid cell and use this as specified in TS 23.401 [11].

If the GUMMEI of the MME currently serving the UE is available at the eNB (see TS 36.300 [14]) the eNB shall include the Source MME GUMMEI IE within the PATH SWITCH REQUEST message.

Upon reception of the PATH SWITCH REQUEST ACKNOWLEDGE message, the eNB shall store the received Security Context IE in the UE context and the eNB shall use it for the next X2 handover or Intra eNB handovers as specified in TS 33.401 [15].

The PATH SWITCH REQUEST ACKNOWLEDGE message may contain

– the UE Aggregate Maximum Bit Rate IE.

– the MME UE S1AP ID 2 IE, which indicates the MME UE S1AP ID assigned by the MME.

If the UE Aggregate Maximum Bit Rate IE is included in the PATH SWITCH REQUEST ACKNOWLEDGE message, the eNB shall

– replace the previously provided UE Aggregate Maximum Bit Rate by the received UE Aggregate Maximum Bit Rate in the UE context; the eNB shall use the received UE Aggregate Maximum Bit Rate for non-GBR Bearers for the concerned UE.

If the UE Aggregate Maximum Bit Rate IE is not contained in the PATH SWITCH REQUEST ACKNOWLEDGE message, the eNB shall use the previously provided UE Aggregate Maximum Bit Rate which is stored in the UE context.

In case the EPC decides to change the uplink termination point of the tunnels, it may include the E-RAB To Be Switched in Uplink List IE in the PATH SWITCH REQUEST ACKNOWLEDGE message to specify a new uplink transport layer address and uplink GTP-TEID for each respective E-RAB for which it wants to change the uplink tunnel termination point.

When the eNB receives the PATH SWITCH REQUEST ACKNOWLEDGE message and if this message includes the E-RAB To Be Switched in Uplink List IE, the eNB shall start delivering the uplink packets of the concerned E-RABs to the new uplink tunnel endpoints as indicated in the message.

When the eNB receives the PATH SWITCH REQUEST ACKNOWLEDGE message including the CSG Membership Status IE, and if the cell that serves the UE is a hybrid cell, the eNB shall use it as defined in TS 36.300 [14].

If the MME UE S1AP ID 2 IE is contained in the PATH SWITCH REQUEST ACKNOWLEDGE message, the eNB shall store this information in the UE context and use it for subsequent X2 handovers.

If the Tunnel Information for BBF IE is received in the PATH SWITCH REQUEST message, the MME shall, if supported, use it in the core network as specified in TS 23.139 [37].

If the LHN ID IE is included in the PATH SWITCH REQUEST message, the MME shall, if supported, use it as specified in TS 23.401 [11].

If the ProSe Authorized IE is contained in the PATH SWITCH REQUEST ACKNOWLEDGE message, the eNB shall, if supported, update its ProSe authorization information for the UE accordingly. If the ProSe Authorized IE includes one or more IEs set to “not authorized”, the eNB shall, if supported, initiate actions to ensure that the UE is no longer accessing the relevant ProSe service(s).

If the UE User Plane CIoT Support Indicator IE is included in the PATH SWITCH REQUEST ACKNOWLEDGE message and is set to "supported", the eNB shall, if supported, consider that User Plane CIoT EPS Optimisation as specified in TS 23.401 [11] is supported for the UE.

If the V2X Services Authorized IE is contained in the PATH SWITCH REQUEST ACKNOWLEDGE message, the eNB shall, if supported, update its V2X services authorization information for the UE accordingly. If the V2X Services Authorized IE includes one or more IEs set to “not authorized”, the eNB shall, if supported, initiate actions to ensure that the UE is no longer accessing the relevant service(s).

If the UE Sidelink Aggregate Maximum Bit Rate IE is included in the PATH SWITCH REQUEST ACKNOWLEDGE message, the eNB shall, if supported:

– replace the previously provided UE Sidelink Aggregate Maximum Bit Rate, if available in the UE context, with the received value;

– use the received value for the concerned UE’s sidelink communication in network scheduled mode for V2X services.

If the Enhanced Coverage Restricted IE is included in the PATH SWITCH REQUEST ACKNOWLEDGE message, the eNB shall store this information in the UE context and use it as defined in TS 23.401 [11].

If the CE-Mode-B Restricted IE is included in the PATH SWITCH REQUEST ACKNOWLEDGE message and the Enhanced Coverage Restricted IE is not set to restricted and the Enhanced Coverage Restricted information stored in the UE context is not set to restricted, the eNB shall store this information in the UE context and use it as defined in TS 23.401 [11].

If information on the UE’s NR security capabilities is available at the eNB (see TS 33.401 [15]) the eNB shall include the NR UE Security Capabilities IE within the PATH SWITCH REQUEST message.

If the NR UE Security Capabilities IE is included in the PATH SWITCH REQUEST message, the MME shall, if supported, consider that the eNB has stored the respective information in the UE context, and proceed as defined in TS 33.401 [15].

If the NR UE Security Capabilities IE is included in the PATH SWITCH REQUEST ACKNOWLEDGE message, the eNB shall, if supported, store this information in the UE context and use it as defined in TS 33.401 [15].

If the UE Security Capabilities IE is included in the PATH SWITCH REQUEST ACKNOWLEDGE message, the eNB shall, if supported, store this information in the UE context and use it as defined in TS 33.401 [15].

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

If the Pending Data Indication IE is included in the PATH SWITCH REQUEST ACKNOWLEDGE message, the eNB shall use it as defined in TS 23.401 [11].

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

If the Handover Restriction List IE is contained in the PATH SWITCH REQUEST ACKNOWLEDGE message, the eNB shall, if supported, overwrite any previously stored handover restriction information in the UE context and use the information in the Handover Restriction List IE to:

– determine a target for subsequent mobility action for which the eNB provides information about the target of the mobility action towards the UE;

– select a proper SCG during dual connectivity operation;

The PATH SWITCH REQUEST ACKNOWLEDGE message may contain the Additional RRM Policy Index IE, if available in the MME for cases specified in TS 23.401 [11]. The eNB shall, if supported, store it and use it as specified in TS 36.300 [14].

If the UE Radio Capability ID IE is included in the PATH SWITCH REQUEST ACKNOWLEDGE message, the eNB shall, if supported, use it as defined in TS 23.401 [11].

If the UE is configured with EN-DC radio resources and the PSCell information is available, the PSCell Information IE shall be included in the PATH SWITCH REQUEST message.

If the NR V2X Services Authorized IE is contained in the PATH SWITCH REQUEST ACKNOWLEDGE message, the eNB shall, if supported, update its V2X services authorization information for the UE accordingly. If the NR V2X Services Authorized IE includes one or more IEs set to "not authorized", the eNB shall, if supported, initiate actions to ensure that the UE is no longer accessing the relevant service(s).

If the NR UE Sidelink Aggregate Maximum Bit Rate IE is included in the PATH SWITCH REQUEST ACKNOWLEDGE message, the eNB shall, if supported:

– replace the previously provided NR UE Sidelink Aggregate Maximum Bit Rate, if available in the UE context, with the received value;

– use the received value for the concerned UE’s sidelink communication in network scheduled mode for NR V2X services.

If the PC5 QoS Parameters IE is included in the PATH SWITCH REQUEST ACKNOWLEDGE message, the eNB shall, if supported, use it for the concerned UE’s NR sidelink communication as specified in TS 23.285 [49].

For each E-RAB for which the Security Indication IE is included in the E-RABs Switched in Downlink Item IE of the PATH SWITCH REQUEST message, the MME shall, if supported, behave as specified in TS 33.401 [15] and may send back the Security Indication IE within the E-RAB To Be Updated Item IE of the PATH SWITCH REQUEST ACKNOWLEDGE message.

If the Security Indication IE is included within the E-RAB To Be Updated Item IE of the PATH SWITCH REQUEST ACKNOWLEDGE message, the eNB shall, if supported, behave as specified in TS 33.401 [15].

8.4.4.3 Unsuccessful Operation

Figure 8.4.4.3-1: Path switch request: unsuccessful operation

If the EPC fails to switch the downlink GTP tunnel endpoint towards a new GTP tunnel endpoint for all E-RABs included in the E-RAB To Be Switched in Downlink List IE during the execution of the Path Switch Request procedure, the MME shall send the PATH SWITCH REQUEST FAILURE message to the eNB with an appropriate cause value. In this case, the eNB should decide its subsequent actions and the MME should behave as described in TS 23.401 [11].

8.4.4.4 Abnormal Conditions

If the MME receives a PATH SWITCH REQUEST message containing several E-RAB ID IEs (in the E-RAB To Be Switched in Downlink List IE) set to the same value, the MME shall send the PATH SWITCH REQUEST FAILURE message to the eNB.

If the MME receives a PATH SWITCH REQUEST message without the CSG Membership Status IE, and the cell accessed by the UE is a hybrid cell with a different CSG from the source cell or the source cell does not have a CSG ID, the MME shall send the PATH SWITCH REQUEST FAILURE message to the eNB.

If the CSG Membership Status IE is not included in the PATH SWITCH REQUEST ACKNOWLEDGE message and the cell accessed by the UE is a hybrid cell with a different CSG from the source cell or the source cell does not have a CSG ID, the eNB shall consider the procedure as unsuccessfully terminated and initiate local error handling.

8.4.5 Handover Cancellation

8.4.5.1 General

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

The procedure uses UE-associated signalling.

8.4.5.2 Successful Operation

Figure 8.4.5.2-1: Handover Cancel procedure. Successful operation.

The source eNB initiates the procedure by sending a HANDOVER CANCEL message to the EPC.

The HANDOVER CANCEL message shall indicate the reason for cancelling the handover with the appropriate value of the Cause IE.

Upon reception of a HANDOVER CANCEL message, the EPC shall terminate the ongoing Handover Preparation procedure, release any resources associated with the handover preparation and send a HANDOVER CANCEL ACKNOWLEDGE message to the source eNB.

Transmission and reception of a HANDOVER CANCEL ACKNOWLEDGE message terminate the procedure in the EPC and in the source eNB. After this, the source eNB does not have a prepared handover for that UE-associated logical S1-connection.

8.4.5.3 Unsuccessful Operation

Not applicable.

8.4.5.4 Abnormal Conditions

If the source eNB becomes aware of the fact that an expected HANDOVER CANCEL ACKNOWLEDGE message is missing, the source eNB shall consider the Handover Cancellation as successfully terminated.

8.4.6 eNB Status Transfer

8.4.6.1 General

The purpose of the eNB Status Transfer procedure is to transfer the uplink PDCP-SN and HFN receiver status and the downlink PDCP-SN and HFN transmitter status from the source to the target eNB via the MME during an intra LTE S1 handover for each respective E-RAB for which PDCP-SN and HFN status preservation applies.

8.4.6.2 Successful Operation

Figure 8.4.6.2-1: eNB Status Transfer procedure

The source eNB initiates the procedure by stopping assigning PDCP-SNs to downlink SDUs and sending the eNB STATUS TRANSFER message to the MME at the point in time when it considers the transmitter/receiver status to be frozen.

– For each E-RAB for which PDCP-SN and HFN status preservation applies the source eNB shall include the E-RAB ID IE, the UL COUNT value IE and the DL COUNT value IE within the E-RABs Subject to Status Transfer Item IE in the eNB Status Transfer Transparent Container IE of the eNB STATUS TRANSFER message.

– In case of 15 bit long PDCP-SN, for each E-RAB for which PDCP-SN and HFN status preservation applies, the source eNB shall additionally include the UL COUNT Value Extended IE and the DL COUNT Value Extended IE within the E-RABs Subject to Status Transfer Item IE.

– In case of 18 bit long PDCP-SN, for each E-RAB for which PDCP-SN and HFN status preservation applies, the source eNB shall additionally include the UL COUNT Value for PDCP SN Length 18 IE and the DL COUNT Value for PDCP SN Length 18 IE within the E-RABs Subject to Status Transfer Item IE.

The source eNB may also include in the eNB STATUS TRANSFER message the missing and the received uplink SDUs in the Receive Status Of UL PDCP SDUs IE, or in the Receive Status Of UL PDCP SDUs Extended IE in case of 15 bit long PDCP-SN, or in the Receive Status Of UL PDCP SDUs for PDCP SN Length 18 IE in case of 18 bit long PDCP-SN, for each bearer for which the source eNB has accepted the request from the target eNB for uplink forwarding.

8.4.6.3 Unsuccessful Operation

Not applicable.

8.4.6.4 Abnormal Conditions

Not applicable.

8.4.7 MME Status Transfer

8.4.7.1 General

The purpose of the MME Status Transfer procedure is to transfer the uplink PDCP-SN and HFN receiver status and the downlink PDCP-SN and HFN transmitter status from the source to the target eNB via the MME during an S1 handover for each respective E-RAB for which PDCP-SN and HFN status preservation applies.

8.4.7.2 Successful Operation

Figure 8.4.7.2-1: MME Status Transfer procedure

The MME initiates the procedure by sending the MME STATUS TRANSFER message to the eNB. The target eNB using Full Configuration for this handover as per TS 36.300 [14] shall ignore the information received in this message.

For each bearer within the E-RABs Subject to Status Transfer List IE within the eNB Status Transfer Transparent Container IE for which the UL COUNT value IE is received in the MME STATUS TRANSFER message, the target eNB shall apply the contained information and 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 in 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.

For each bearer in E-RABs Subject to Status Transfer List IE within the eNB Status Transfer Transparent Container IE received in the MME STATUS TRANSFER message, the target eNB shall use DL COUNT value IE for 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 DL COUNT Value Extended IE or DL COUNT Value for PDCP SN Length 18 IE instead of the DL COUNT value IE.

If the Receive Status Of UL PDCP SDUs IE or the Receive Status Of UL PDCP SDUs Extended IE or the Receive Status Of UL PDCP SDUs for PDCP SN Length 18 IE is included for at least one bearer in the eNB Status Transfer Transparent Container IE of the MME STATUS TRANSFER message, the target eNB may use it in a Status Report message sent to the UE over the radio interface.

8.4.7.3 Unsuccessful Operation

Not applicable.

8.4.7.4 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.4.8 Handover Success

8.4.8.1 General

The Handover Success procedure is used during a DAPS Handover, to inform the source eNB that the UE has successfully accessed the target eNB. The procedure uses UE-associated signalling.

8.4.8.2 Successful Operation

Figure 8.4.8.2-1: Handover Success

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

8.4.8.3 Abnormal Conditions

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

8.4.9 eNB Early Status Transfer

8.4.9.1 General

The purpose of the eNB Early Status Transfer procedure is to transfer the COUNT of the first downlink SDU that the source eNB forwards to the target eNB, for each respective E-RAB for which DAPS Handover applies, from the source eNB to the target eNB via the MME during an intra LTE S1 handover.

8.4.9.2 Successful Operation

Figure 8.4.9.2-1: eNB Early Status Transfer procedure

The source eNB initiates the procedure by sending the eNB EARLY STATUS TRANSFER message to the MME at the point in time when it considers starting early data forwarding to the target eNB.

For each E-RAB for which DAPS Handover applies, the source eNB shall include the E-RAB ID IE and the COUNT of the first downlink SDU that the source eNB forwards to the target eNB within the E-RABs Subject to Early Status Transfer Item IE in the eNB Early Status Transfer Transparent Container IE of the eNB EARLY STATUS TRANSFER message.

8.4.9.3 Unsuccessful Operation

Not applicable.

8.4.9.4 Abnormal Conditions

Not applicable.

8.4.10 MME Early Status Transfer

8.4.10.1 General

The purpose of the MME Early Status Transfer procedure is to transfer the COUNT of the first downlink SDU that the source eNB forwards to the target eNB, for each respective E-RAB for which DAPS Handover applies, from the source eNB to the target eNB via the MME during an S1 handover.

8.4.10.2 Successful Operation

Figure 8.4.10.2-1: MME Early Status Transfer procedure

The MME initiates the procedure by sending the MME EARLY STATUS TRANSFER message to the eNB.

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

For each E-RAB in the E-RABs Subject to Early Status Transfer List IE, the target eNB shall use the information contained in the DL COUNT PDCP-SN length IE as the COUNT of the first downlink SDU that the source eNB forwards to the target eNB.

8.4.10.3 Unsuccessful Operation

Not applicable.

8.4.10.4 Abnormal Conditions

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