Content for  TS 23.401  Word version:  19.0.0

The S1-based handover procedure is used when the X2-based handover cannot be used. The source eNodeB initiates a handover by sending Handover Required message over the S1-MME reference point. This procedure may relocate the MME and/or the Serving-GW. The source MME selects the target MME. The MME should not be relocated during inter-eNodeB handover unless the UE leaves the MME Pool Area where the UE is served. The MME (target MME for MME relocation) determines if the Serving-GW needs to be relocated. If the Serving-GW needs to be relocated the MME selects the target Serving-GW, as specified in clause 4.3.8.2 on Serving-GW selection function. The source eNodeB decides which of the EPS bearers are subject for forwarding of downlink and optionally also uplink data packets from the source eNodeB to the target eNodeB. The EPC does not change the decisions taken by the RAN node. Packet forwarding can take place either directly from the source eNodeB to the target eNodeB, or indirectly from the source eNodeB to the target eNodeB via the source and target Serving-GWs (or if the Serving-GW is not relocated, only the single Serving-GW). The availability of a direct forwarding path is determined in the source eNodeB and indicated to the source MME. If X2 connectivity is available between the source and target eNodeBs, a direct forwarding path is available. If a direct forwarding path is not available, indirect forwarding may be used. The source MME uses the indication from the source eNodeB to determine whether to apply indirect forwarding. The source MME indicates to the target MME whether indirect forwarding should apply. Based on this indication, the target MME determines whether it applies indirect forwarding. If both source eNodeB and source MME support DAPS the source eNodeB may decide that some of the E-RABs are subject for DAPS handover as defined in TS 36.300; in this case, the source eNodeB provides the DAPS information indicating the request concerns a DAPS handover for that E-RAB as part of the Source to Target eNodeB Transparent Container. If the Target eNodeB accepts that the request concerns of DAPS handover and both Target eNodeB and Target MME support DAPS, the S1-based DAPS handover will be performed and the target eNodeB provides DAPS response information as part of the Target to Source eNodeB Transparent Container. If the MME receives a rejection to an S1 interface procedure (e.g. dedicated bearer establishment/ modification/ release; location reporting control; NAS message transfer; etc.) from the eNodeB with an indication that an S1 handover is in progress (see TS 36.300), the MME shall reattempt the same S1 interface procedure when either the handover is complete or is deemed to have failed if the MME is still the serving MME, except in the case of Serving-GW relocation. If the S1 handover changes the serving MME, the source MME shall terminate any other ongoing S1 interface procedures except the handover procedure. If the S1 handover includes the Serving-GW relocation, and if the MME receives a rejection to a NAS message transfer for a Downlink NAS Transport or Downlink Generic NAS Transport message from the eNodeB with an indication that an S1 handover is in progress, the MME should resend the corresponding message to the target eNodeB when either the handover is complete or to the source eNodeB when the handover is deemed to have failed if the MME is still the serving MME. If the MME receives a rejection to a NAS message transfer for a CS Service Notification or to a UE Context modification Request message with a CS Fallback indication from the eNodeB with an indication that an S1 handover is in progress, the MME shall resend the corresponding message to the target eNodeB when either the handover is complete or to the source eNodeB when the handover is deemed to have failed if the MME is still the serving MME. In order to minimise the number of procedures rejected by the eNodeB, the MME should pause non-handover related S1 interface procedures (e.g. downlink NAS message transfer, E-RAB Setup /Modify/ Release, etc.) while a handover is ongoing (i.e. from the time that a Handover Required has been received until either the Handover procedure has succeeded (Handover Notify) or failed (Handover Failure)) and continue them once the Handover procedure has completed if the MME is still the serving MME, except in the case of Serving-GW relocation. If during the handover procedure the MME detects that the Serving-GW or/and the MME needs be relocated, the MME shall reject any PDN-GW initiated EPS bearer(s) request received since handover procedure started and shall include an indication that the request has been temporarily rejected due to handover procedure in progress. The rejection is forwarded by the Serving-GW to the PDN-GW, with the indication that the request has been temporarily rejected. Upon reception of a rejection for an EPS bearer(s) PDN-GW initiated procedure with an indication that the request has been temporarily rejected due to handover procedure in progress, the PDN-GW start a locally configured guard timer. The PDN-GW shall re-attempt, up to a pre-configured number of times, when either it detects that the handover is completed or has failed using message reception or at expiry of the guard timer. If emergency bearer services are ongoing for the UE, handover to the target eNodeB is performed independent of the Handover Restriction List. The MME checks, as part of the Tracking Area Update in the execution phase, if the handover is to a restricted area and if so MME releases the non-emergency bearers as specified in clause 5.10.3. If emergency bearer services are ongoing for the UE, handover to the target CSG cell is performed independent of the UE's CSG subscription. If the handover is to a CSG cell that the UE is not subscribed, the target eNodeB only accepts the emergency bearers and the target MME releases the non-emergency PDN connections that were not accepted by the target eNodeB as specified in clause 5.10.3. For inter-PLMN handover to a CSG cell, if the source MME has the CSG-ID list of the target PLMN, the source MME shall use it to validate the CSG membership of the UE in the target CSG cell. Otherwise, based on operator's configuration the source MME may allow the handover by validating the CSG membership of the UE in the target CSG cell using the CSG-ID list of the registered PLMN-ID. If neither the CSG-ID list of the target PLMN nor the operator's configuration permits the handover, the source MME shall reject the handover due to no CSG membership information of the target PLMN-ID. As specified in clause 4.3.8.3, with regard to CIoT EPS Optimisations, the source MME attempts to perform handover to a target MME that can support the UE's Preferred Network Behaviour. For a UE that is using a Non-IP connection to a PDN Gateway, or a PDN connection to a SCEF, if these bearers cannot be supported by the target MME, the source MME does not attempt to handover those bearers, but instead releases them upon successful completion of the handover. If the MME does not have any bearer for the UE that can be transferred, then the MME sends an S1-AP Handover Preparation Failure message to the source eNodeB. For PDN connection of Ethernet Type, if the target MME does not support Ethernet PDN Type, the source MME does not attempt to handover those bearers, but instead releases them upon successful completion of the handover. For handover the following applies related to handling of radio capabilities:

• If the source eNodeB and target eNodeB support RACS as defined in clause 5.11.3a, the Source to Target transparent container need not carry the UE radio capabilities (instead the UE Radio Capability ID is supplied from the CN to the target eNodeB). However, if the source eNodeB has knowledge that the target eNodeB might not have a local copy of the Radio Capability corresponding to the UE Radio Capability ID (i.e. because the source eNodeB had itself to retrieve the UE's Radio Capability from the MME) then the source eNodeB may send some (or all) of the UE's Radio Capability to the target eNodeB (the size limit based on local configuration. In the case of inter-PLMN handover, when the source and target eNodeB support RACS as defined in clause 5.11.3a and the source eNodeB determines based on local configuration that the target PLMN does not support the UE Radio Capability ID assigned by the source PLMN, then the source eNodeB shall include the UE radio capabilities in the Source to Target transparent container. At such an inter-PLMN handover, the source CN node shall not provide the UE Radio Capability ID to the target CN node (or in intra-CN node case not to the target eNodeB). If the target eNodeB does not have a mapping between the UE Radio Capability ID received from the MME and the UE radio capabilities and no UE radio capability is provided in the Source to Target transparent container, it shall use the procedure described in TS 36.413 to retrieve the mapping from the Core Network. If the target eNodeB received both the UE radio capabilities (in the Source to Target transparent container) and the UE Radio Capability ID (from the MME), then the target eNodeB shall use any locally stored UE radio capability information corresponding to the UE Radio Capability ID. If none are stored locally, the target eNodeB may request the full UE radio capability information from the core network. If the full UE radio capability information is not promptly received from the core network, or the target eNodeB chooses not to request it, then the target eNodeB shall proceed with the UE radio capabilities sent by the source RAN node. The target eNodeB shall not use the UE radio capability information received from the source RAN node for any other UE with the same UE Radio Capability ID.
• If the target eNodeB knows (e.g. by configuration) that the UE's E-UTRA radio capabilities applicable to the target eNB may be different to the E-UTRA radio capabilities stored in the source eNodeB (e.g. for handover to/from an E-UTRA eNodeB that supports the NTN enhancements as defined in TS 36.300), then the target eNodeB shall trigger retrieval of the radio capability information again from the UE.

The Inter eNodeB S1 based handover procedure specified in clause 5.5.1.2.2 may also be used for intra-eNodeB handover.

This procedure describes the S1-based handover in the normal case, clause 5.5.1.2.3 describes it when the procedure is rejected by the target eNodeB or the target MME and clause 5.5.1.2.4 describes when the procedure is canceled by the source eNodeB.

This procedure describes the S1-based DAPS handover in the normal case.

The Target eNodeB rejects the use of the Handover procedure if none of the requested bearers in the Handover Request message could be established. In this case no UE context is established in the target MME/eNodeB and no resources are allocated. Further, the Target MME rejects the handover request and clears all resource in Target eNodeB and Target MME if the Target eNodeB accepts the handover request but none of the default EPS bearers gets resources allocated. In both cases, the UE remains in the Source eNodeB/MME.

Instead of completing the handover procedure, the source eNodeB may at any time during the handover procedure, up to the time when a handover command message is sent to the UE cancel the handover. The MME shall cancel the handover resources as defined in clause 5.5.2.5.1 for case the source RAN is eNodeB.