Section: D.3.8.3 Execution phase
Content: Figure D.3.8.3-1: GERAN A/Gb mode to E-UTRAN Inter RAT HO, execution phase NOTE 1: For a PMIP-based S5/S8, procedure steps (A) are defined in TS 23.402[ Architecture enhancements for non-3GPP accesses ]  [2]. Steps 9 and 9a concern GTP based S5/S8. The old SGSN continues to receive downlink and uplink user plane PDUs. When old SGSN receives the Forward Relocation Response message it may start downlink N-PDU relay and duplication to the target eNodeB, and the target eNodeB may start blind transmission of downlink user data towards the UE over the allocated radio channels. 1. 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. NOTE 2: The Source SGSN acts as the old SGSN. 2. 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. 3. 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. 4. The UE moves to the E-UTRAN and performs access procedures toward Target eNodeB. 5. 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. 6. 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. 7. 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. 8. 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. NOTE 3: The text regarding "Target Serving GW" shall be ignored. 9. 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. NOTE 4: The text regarding "Target Serving GW" shall be ignored. 10. 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. 11. 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. NOTE 5: The text regarding "Target Serving GW" shall be ignored. 12. 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. 13. 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