Content for  TS 23.401  Word version:  19.0.0

The source BSS decides to initiate a PS handover. At this point both uplink and downlink user data is transmitted via the following: TBFs between MS and source BSS, BSSGP PFCs tunnel(s) between source BSS and old SGSN, GTP tunnel(s) between old SGSN and GGSN.

The source BSS sends the message PS handover Required (TLLI, Cause, Source Cell Identifier, Target eNodeB Identifier, Source to Target Transparent Container (RN part), and active PFCs list) to Source SGSN to request the CN to establish resources in the Target eNodeB, Target MME and the Serving-GW.

The Source SGSN determines from the 'Target eNodeB Identifier' IE that the type of handover is IRAT PS Handover to E-UTRAN. The Source SGSN initiates the Handover resource allocation procedure by sending message Forward Relocation Request (IMSI, Target Identification, MM Context, PDP Context, SGSN Tunnel Endpoint Identifier for Control Plane, SGSN Address for Control plane, Source to Target Transparent Container (RN part), Packet Flow ID, SNDCP XID parameters, LLC XID parameters) to the target MME. This message includes all PDP contexts that are established in the source system indicating the PFIs and the XID parameters related to those PDP Contexts, and the uplink Tunnel endpoint parameters of the Serving-GW. The PDP Contexts shall be sent in a prioritized order, i.e. the most important PDP Context first. The prioritization method is implementation dependent, but should be based on the current activity. The target MME maps the PDP contexts to the EPS bearers 1-to-1 and maps the Release 99 QoS parameter values of a PDP context to the EPS Bearer QoS parameter values of an EPS bearer as defined in Annex E. The MME establishes the EPS bearer(s) in the indicated order. The MME deactivates the EPS bearers which cannot be established. The MM context contains security related information, e.g. supported ciphering algorithms as described in TS 29.060. For the PDP Context with traffic class equals 'Background', the source SGSN shall indicate via the Activity Status Indicator IE that EPS bearers shall be established on the target side.

The target MME selects the Serving-GW as described under clause 4.3.8.2 on "Serving-GW selection function". The target MME sends a Create Session Request message (IMSI, MME Tunnel Endpoint Identifier for Control Plane, MME Address for Control plane, PDN-GW address(es) for user plane, PDN-GW UL TEID(s) for user plane, PDN-GW address for control plane, and PDN-GW TEID(s) for control plane, the Protocol Type over S5/S8, APN-AMBR, Serving Network) per PDN connection to the Serving-GW. The Protocol Type over S5/S8 is provided to Serving-GW which protocol should be used over S5/S8 interface. For relocation from Gn/Gp SGSN, the target MME provides the APN-AMBR if not received explicitly from the Gn/Gp SGSN based on the mapping from MBR (as specified in Annex E) to the Serving-GW

The Serving-GW allocates its local resources and returns them in a Create Session Response (Serving-GW address(es) for user plane, Serving-GW UL TEID(s) for user plane, Serving-GW Address for control plane, Serving-GW TEID for control plane) message to the target MME.

The Target MME will request the Target eNodeB to establish the Bearer(s) by sending the message Handover Request (UE Identifier, S1AP Cause, Integrity protection information (i.e. IK and allowed Integrity Protection algorithms), Encryption information (i.e. CK and allowed Ciphering algorithms), EPS Bearers to be setup list, Source to Target Transparent Container). The Target MME shall not request resources for which the Activity Status Indicator within a PDP Context indicates that no active bearer exists on the source side for that PDP Context. For each EPS bearer requested to be established, 'EPS Bearers To Be Setup' IE shall contain information such as ID, bearer parameters, Transport Layer Address, "Data forwarding not possible" indication and S1 Transport Association. The Transport Layer Address is the Serving-GW Address for user data, and the S1 Transport Association corresponds to the uplink Tunnel Endpoint Identifier Data. "Data forwarding not possible" indication shall be included if the target MME decides the corresponding bearer will not be subject to data forwarding. The target MME shall not request the target eNodeB to establish EPS GBR bearers with maximum bitrate set to 0 and those EPS bearers should not be included in the EPS Bearers to be setup list and should be deactivated by the MME. For the remaining EPS Bearer Contexts the MME ignores any Activity Status Indicator within an EPS Bearer Context and requests the target eNodeB to allocate resources for all the remaining EPS Bearer Contexts. The ciphering and integrity protection keys will be sent transparently from the target eNodeB to the UE in the Target to Source Transparent Container, and in the message PS Handover Command from source BSS to the UE. This will then allow data transfer to continue in the new RAT/mode target cell without requiring a new AKA (Authentication and Key Agreement) procedure. The MME shall compute the UE-AMBR, as per clause 4.7.3, based on explicit APN-AMBR values received from the Gn/Gp SGSN. If explicit APN-AMBR values are not received by the MME, a local UE-AMBR shall be included in the 'EPS Bearers be setup list' IE. The local UE-AMBR is described in Annex E.

The Target eNodeB allocates the request resources and returns the applicable parameters to the Target MME in the message Handover Request Acknowledge (Target to Source Transparent Container, EPS Bearers setup list, EPS Bearers failed to setup list). Upon sending the Handover Request Acknowledge message the target eNodeB shall be prepared to receive downlink GTP PDUs from the Serving-GW for the accepted EPS bearers. The target eNodeB shall ignore it if the number of radio bearers in the Source to Target Transparent container does not comply with the number of bearers requested by the MME and allocate bearers as requested by the MME.

If 'Indirect Forwarding' applies, the target MME sends a Create Indirect Data Forwarding Tunnel Request message (Cause, Target eNodeB Address(es), TEID(s) for DL user plane) to the Serving-GW. Cause indicates that the bearer(s) are subject to data forwarding.

The Serving-GW returns a Create Indirect Data Forwarding Tunnel Response (Cause, Serving-GW Address(es) and TEID(s) for Data Forwarding) message to the target MME. If the Serving-GW doesn't support data forwarding, an appropriate cause value shall be returned and the Serving-GW Address(es) and TEID(s) will not be included in the message.

The Target MME sends the message Forward Relocation Response (Cause, List of Set Up PFCs, MME Tunnel Endpoint Identifier for Control Plane, BSSGP cause, MME Address for control plane, Target to Source Transparent Container, Address(es) and TEID(s) for Data Forwarding) to the Source SGSN. If 'Direct Forwarding' is applicable, then the IEs 'Address(es) and TEID(s) for Data Forwarding' contains the DL GTP-U tunnel endpoint parameters to the eNodeB. If 'Indirect Forwarding' applies the IEs 'Address(es) and TEID(s) for Data Forwarding' contain the DL GTP-U tunnel endpoint parameters to the Serving-GW.

The Source SGSN completes the preparation phase towards Source BSS by sending the message PS HO Required Acknowledge (TLLI, List of Set Up PFCs, Target to Source Transparent Container). This message includes all PFIs that could be established on the Target side. Before sending the PS Handover Required Acknowledge message, the source SGSN may suspend downlink data transfer for any PDP contexts. Before sending the PS Handover Command message to the UE the source BSS, may try to empty the downlink BSS buffer for any BSS PFCs.

The Source BSS will command the UE to handover to the target eNodeB via the message PS Handover Command. The access system specific message to UE includes a transparent container including radio aspect parameters that the Target eNodeB has set-up in the preparation phase.

There is no RAN context transfer during inter RAT handovers with E-UTRAN. If the source SGSN originates any SRNS contexts the MME acknowledges the receipt towards the SGSN and ignores the message content.

The UE moves to the E-UTRAN and performs access procedures toward Target eNodeB.

When the UE has got access to Target eNodeB it sends the message HO to E-UTRAN Complete. The UE shall implicitly derive the EPS bearers for which an E-RAB was not established from the PS Handover Command and deactivate them locally without an explicit NAS message at this step.

When the UE has successfully accessed the Target eNodeB, the Target eNodeB informs the Target MME by sending the message Handover Notify. Upon receipt of the Handover Notify message the target MME starts a timer if the target MME applies indirect forwarding.

Then the Target MME knows that the UE has arrived to the target side and Target MME informs the old SGSN by sending the Forward Relocation Complete () message. The old SGSN will also acknowledge that information. When the Forward Relocation Complete message has been received and there is no longer any need for the Old SGSN to forward data, the old SGSN stops data forwarding. A timer in old SGSN is started to supervise when resources shall be released.

The Target MME will now complete the Handover procedure by informing the Serving-GW (for Serving-GW relocation this will be the Target Serving-GW) that the Target MME is now responsible for all the EPS bearers the UE have established. This is performed in the message Modify Bearer Request (Cause, MME Tunnel Endpoint Identifier for Control Plane, EPS Bearer ID(s), MME Address for Control Plane, eNodeB Address(es) and TEID(s) for User Traffic for the accepted EPS bearers, PDN-GW addresses and TEIDs (for GTP-based S5/S8) or GRE keys (for PMIP-based S5/S8) at the PDN-GW(s) for uplink traffic and RAT type) per PDN connection. If any EPS bearers are to be released the MME triggers the bearer release procedure as specified in clause 5.4.4.2. If the Serving-GW receives a DL packet for a non-accepted bearer, the Serving-GW drops the DL packet and does not send a Downlink Data Notification to the MME.

The Serving-GW (for Serving-GW relocation this will be the Target Serving-GW) informs the PDN-GW(s) the change of, for example, for Serving-GW relocation or the RAT type, that e.g. can be used for charging, by sending the message Modify Bearer Request per PDN connection. Serving Network should be included in this message if it is received in step 4. For Serving-GW relocation, the Serving-GW allocates DL TEIDs on S5/S8 even for non-accepted bearers. The PDN-GW must acknowledge the request with the message Modify Bearer Response (APN Restriction). When the UE moves from Gn/Gp SGSN to the MME, the PDN-GW shall send the APN restriction of each bearer context to the Serving-GW. If PCC infrastructure is used, the PDN-GW informs the PCRF about the change of, for example, the RAT type. The Modify Bearer Response also indicates the identity of the default bearer and the Charging Id towards the S-GW.

The Serving-GW (for Serving-GW relocation this will be the Target Serving-GW) acknowledges the user plane switch to the Target MME via the message Modify Bearer Response (Cause, Serving-GW Tunnel Endpoint Identifier for Control Plane, Serving-GW (for Serving-GW relocation this will be the Target Serving-GW) Address for Control Plane, Protocol Configuration Options, PDN-GW addresses and TEIDs (for GTP-based S5/S8) or GRE keys (for PMIP-based S5/S8) at the PDN-GW(s) for uplink traffic, APN Restriction).The Serving-GW shall forward the received APN Restriction to the MME. At this stage the user plane path is established for all bearers between the UE, Target eNodeB, Serving-GW (for Serving-GW relocation this will be the Target Serving-GW) and PDN-GW. In addition, the Modify Bearer Response indicates the identity of the default bearer towards the MME.

When the timer started in step 7 expires the Source SGSN will clean-up all its resources towards Source BSS by performing the BSS Packet Flow Delete procedure. When the timer started in step 6 expires the target MME releases the resources that have been allocated for indirect forwarding.

The RAN triggers the UE to initiate a Tracking Area Update procedure with the target MME. It is RAN functionality to provide the ECM-CONNECTED UE with the trigger information. The target MME knows that an IRAT Handover has been performed for this UE as it received the bearer context(s) by handover messages and therefore the target MME performs only a subset of the TA update procedure, specifically it excludes the context transfer procedures between source SGSN and target MME. The target MME gets the subscribed UE-AMBR value and the subscribed APN-AMBR value from the HSS during the TA update procedure. If the Subscription Data received from the HSS (during the TAU) contains information that is necessary for the E-UTRAN to be aware of (e.g. a restriction in the UE's permission to use NR as a secondary RAT, Unlicensed Spectrum in the form of LAA/LWA/LWIP/NR-U (as specified in clause 4.3.30) or a combination of them), or an existing UE context in the MME indicates that the UE is not permitted to use NR as a secondary RAT, Unlicensed Spectrum or a combination of them, and the MME has not provided this information to the target eNodeB during step 5 of the Handover preparation phase, then the MME sends an updated Handover Restriction List in the Downlink NAS Transport message that it sends to E-UTRAN.

The target MME calculates UE-AMBR as defined in clause 4.7.3. If this calculated value is different from the UE-AMBR computed during step 6, or the APN-AMBR mapped from the subscribed MBR is different from the subscribed APN-AMBR, or the mapped subscribed QoS profile (i.e. the subscribed QoS profile mapped according to Annex E) of the default bearer is different from the EPS Subscribed QoS profile received from the HSS, the new MME shall initiate Subscribed QoS Modification procedure as described in clause 5.4.2.2, Figure 5.4.2.2-1