Section: 5.5.2.2.3 Execution phase
Content: Figure 5.5.2.2.3-1: UTRAN Iu mode to E-UTRAN Inter RAT HO, execution phase NOTE: For a PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402[ Architecture enhancements for non-3GPP accesses ]  [2]. Step (B) shows PCRF interaction in the case of PMIP-based S5/S8. Steps 9 and 9a concern GTP based S5/S8. The source RNC continues to receive downlink and uplink user plane PDUs. 1. The source SGSN completes the preparation phase towards source RNC by sending the message Relocation Command (Target RNC to Source RNC Transparent Container, RABs to be Released List, RABs Subject to Data Forwarding List). The "RABs to be Released list" IE will be the list of all NSAPIs (RAB Ids) for which a Bearer was not established in Target eNodeB. The "RABs Subject to Data forwarding list" IE may be included in the message and it shall be a list of 'Address(es) and TEID(s) for user traffic data forwarding' received from target side in step 7 of the preparation phase when 'Direct Forwarding' applies. If 'Indirect Forwarding' is applicable and Direct Tunnel is used the "RABs Subject to Data Forwarding List" IE includes the parameters received in Step 8a of the preparation phase. If 'Indirect Forwarding' is applicable and Direct Tunnel is not used the "RABs Subject to Data Forwarding List" IE includes the source SGSN address(es) and TEID(s) allocated for indirect data forwarding by Source SGSN. The Target RNC to Source RNC Transparent Container contains the value from the Target to Source Transparent Container received from the target MME. 2. The source RNC will command to the UE to handover to the target eNodeB via the message HO from UTRAN Command. The access network specific message to UE includes a transparent container including radio aspect parameters that the target eNodeB has set-up in the preparation phase. The source RNC may initiate data forwarding for the indicated RABs/EPS Bearer contexts specified in the "RABs Subject to Data Forwarding List". The data forwarding may go directly to target eNodeB, or alternatively go via the Serving GW if so decided by source SGSN and/or target MME in the preparation phase. Upon the reception of the HO from UTRAN Command message containing the Relocation Command message, the UE shall associate its RAB IDs to the respective bearers ID based on the relation with the NSAPI and shall suspend the uplink transmission of the user plane data. 3. Void. 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 HO from UTRAN 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 (TAI+ECGI, Local Home Network ID). For SIPTO at the Local Network with stand-alone GW architecture, the target eNodeB shall include the Local Home Network ID of the target cell in the Handover Notify message. 7. Then the target MME knows that the UE has arrived to the target side and target MME informs the source SGSN by sending the Forward Relocation Complete Notification (ISR Activated, Serving GW change) message. If ISR Activated is indicated, this indicates to the source SGSN that it shall maintain the UE's contexts and activate ISR, which is only possible when the S-GW is not changed. The source SGSN shall also acknowledge that information. A timer in source SGSN is started to supervise when resources in the in Source RNC and Source Serving GW (for Serving GW relocation) shall be released Upon receipt of the Forward Relocation Complete Acknowledge message the target MME starts a timer if the target MME applies indirect forwarding. 8. The target MME will now complete the Inter-RAT 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 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, MME Address for Control Plane, eNodeB Address(es) and TEID(s) for User Traffic for the accepted EPS bearers and RAT type, ISR Activated) per PDN connection. As it is a mobility from UTRAN, if the target MME supports location information change reporting, the target MME shall include the User Location Information (according to the supported granularity) in the Modify Bearer Request, regardless of whether location information change reporting had been requested in the previous RAT by the PDN GW. If the PDN GW requested User CSG information (determined from the UE context), the MME also includes the User CSG Information IE in this message. If either the UE Time Zone has changed or Forward Relocation Request message from source SGSN indicated pending UE Time Zone change reporting (via Change to Report flag), the MME includes the UE Time Zone IE in this message. If either Serving GW is not relocated but the Serving Network has changed or Forward Relocation Request message from source SGSN indicated pending Serving Network change reporting (via Change to Report flag), the MME includes the new Serving Network IE in this message. If indicated, the information ISR Activated indicates that ISR is activated, which is only possible when the S-GW was not changed. When the Modify Bearer Request does not indicate ISR Activated and S-GW is not changed, the S-GW deletes any ISR resources by sending a Delete Bearer Request to the other CN node that has bearer resources on the S-GW reserved. The MME releases the non-accepted dedicated bearers by triggering 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. If the default bearer of a PDN connection has not been accepted by the target eNodeB and there are other PDN connections active, the MME shall handle it in the same way as if all bearers of a PDN connection have not been accepted. The MME releases these PDN connections by triggering the MME requested PDN disconnection procedure specified in clause 5.10.3. 9. The Serving GW (for Serving GW relocation this will be the Target Serving GW) may inform the PDN GW 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. The S-GW also includes User Location Information IE and/or UE Time Zone IE and/or User CSG Information IE if they are present in step 8. Serving Network should be included if it is received in step 8 or in step 4 in clause 5.5.2.2.2. For Serving GW relocation, the Serving GW allocates DL TEIDs on S5/S8 even for non-accepted bearers and may include the PDN Charging Pause Support Indication. The PDN GW must acknowledge the request with the message Modify Bearer Response. In the case of Serving GW relocation, the PDN GW updates its context field and returns a Modify Bearer Response (Charging Id, MSISDN, PDN Charging Pause Enabled Indication (if PDN GW has chosen to enable the function), etc.) message to the Serving GW. The MSISDN is included if the PDN GW has it stored in its UE context. If location information change reporting is required and supported in the target MME, the PDN GW shall provide MS Info Change Reporting Action in the Modify Bearer Response. If PCC infrastructure is used, the PDN GW informs the PCRF about the change of, for example, the RAT type. If the Serving GW is relocated, the PDN GW shall send one or more "end marker" packets on the old path immediately after switching the path in order to assist the reordering function in the target eNodeB. The source Serving GW shall forward the "end marker" packets to the source SGSN or RNC. 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 Address for Control Plane, Protocol Configuration Options, MS Info Change Reporting Action). 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. If the Serving GW does not change, the Serving GW shall send one or more "end marker" packets on the old path immediately after switching the path in order to assist the reordering function in the target eNodeB. 11. The UE initiates a Tracking Area Update procedure when one of the conditions listed in clause "Triggers for tracking area update" applies. 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. If the Subscription Data received from the HSS (during the TAU in step 11) 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 or 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 RAN. If the UE is not allowed to use NR as Secondary RAT, the MME indicates that to the UE in TAU Accept message. 12. When the timer started in step 7 expires the source SGSN will clean-up all its resources towards source RNC by sending the Iu Release Command to the RNC. When there is no longer any need for the RNC to forward data, the source RNC responds with an Iu Release Complete message. When the timer started in step 7 expires and if the source SGSN received the Serving GW change indication in the Forward Relocation Response message, it deletes the EPS bearer resources by sending Delete Session Request (Cause, Operation Indication) messages to the Source Serving GW. The operation Indication flag is not set, that indicates to the Source Serving GW that the Source Serving GW shall not initiate a delete procedure towards the PDN GW. The Source Serving GW acknowledges with Delete Session Response (Cause) messages. If ISR has been activated before this procedure, the cause indicates to the Source S-GW that the Source S-GW shall delete the bearer resources on the other old CN node by sending Delete Bearer Request message(s) to that CN node. 13. If indirect forwarding was used then the expiry of the timer at source SGSN started at step 7 triggers the source SGSN to send a Delete Indirect Data Forwarding Tunnel Request message to the S-GW to release the temporary resources used for indirect forwarding. 14. If indirect forwarding was used and the Serving GW is relocated, then the expiry of the timer at target MME started at step 7 triggers the target MME to send a Delete Indirect Data Forwarding Tunnel Request message to the target S-GW to release temporary resources used for indirect forwarding.