Section: 5.5.1.2 S1-based handover 5.5.1.2.1 General
Content: 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[ Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 ]  [5]; 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[ Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 ]  [5]), 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. NOTE 1: Inter-PLMN handover to a CSG cell in a PLMN which is not an equivalent PLMN for the UE is not supported. 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[ Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP) ]  [36] 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[ Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 ]  [5]), then the target eNodeB shall trigger retrieval of the radio capability information again from the UE. NOTE 2: In order to support handover from an E-UTRA eNodeB that supports the NTN enhancements as defined in TS 36.300[ Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 ]  [5] the target eNodeB needs to be upgraded to support the above behaviour. The Inter eNodeB S1 based handover procedure specified in clause 5.5.1.2.2 may also be used for intra-eNodeB handover. NOTE 3: One use case for intra-eNodeB handover to be performed by the Inter eNodeB S1 based handover procedure is when an eNodeB serves a satellite access system that covers more than one country. In such a situation, the UE might move from a "cell" in one country into a "cell" in another country, and the eNodeB may need to cause the MME to change to an MME serving the UE's new country.