Section: 5.5.2.3.3 Execution phase
Content: Figure 5.5.2.3.3-1: E-UTRAN to GERAN A/Gb mode Inter RAT HO, execution phase NOTE 1: 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 10 and 10a concern GTP based S5/S8 The source eNodeB continues to receive downlink and uplink user plane PDUs. 1. The Source MME completes the preparation phase towards Source eNodeB by sending the message Handover Command (Target to Source Transparent Container (PS Handover Command with RN part and EPC part), E-RABs to Release List, Bearers Subject to Data Forwarding List), S1AP Cause. The "Bearers Subject to Data forwarding list" 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 the preparation phase (Step 7 of the preparation phase for Direct Forwarding, else parameters received in Step 8a of the preparation phase). S1AP Cause indicates the RAN Cause as received from the target SGSN. Source eNodeB initiate data forwarding for the bearers specified in the "Bearers Subject to Data Forwarding List". The data forwarding may go directly i.e. to target SGSN or alternatively go via the Serving GW if so decided by source MME and/or target SGSN in the preparation phase. 2. The Source eNodeB will give a command to the UE to handover to the Target Access System via the message HO from E-UTRAN Command. This message includes a transparent container including radio aspect parameters that the Target BSS has set-up in the preparation phase (RN part). This message also includes the XID and IOV-UI parameters received from the Target SGSN (EPC part). Upon the reception of the HO from E-UTRAN Command message containing the Handover Command message, the UE shall associate its bearer IDs to the respective PFIs based on the relation with the NSAPI and shall suspend the uplink transmission of the user plane data. 3. If the PLMN has configured Secondary RAT usage data reporting and the source eNodeB has Secondary RAT usage data to report, the eNodeB sends the RAN Usage data report message (Secondary RAT usage data) to the MME. Since the handover is an inter-RAT handover, the MME continues with the Secondary RAT usage data reporting procedure as in clause 5.7A.3. The reporting procedure in clause 5.7A.3 is only performed if PGW secondary RAT usage reporting is active. 4. The UE moves to the Target GERAN A/Gb (2G) system and performs executes the handover according to the parameters provided in the message delivered in step 2. The procedure is the same as in step 6 in clause 5.3.2.2 in TS 43.129[ None ]  [8] with the additional function of association of the received PFI and existing Bearer Id related to the particular NSAPI. 5. After accessing the cell using access bursts and receiving timing advance information from the BSS in step 4, the UE processes the NAS container and then sends one XID response message to the target SGSN via target BSS. The UE sends this message immediately after receiving the Packet Physical Information message containing the timing advance or, in the synchronised network case, immediately if the PS Handover Access message is not required to be sent. Upon sending the XID Response message, the UE shall resume the user data transfer only for those NSAPIs for which there are radio resources allocated in the target cell. For NSAPIs using LLC ADM, for which radio resources were not allocated in the target cell, the UE may request for radio resources using the legacy procedures. If the Target SGSN indicated XID Reset (i.e. reset to default XID parameters) in the NAS container included in the HO from E-UTRAN Command message, and to avoid collision cases the mobile station may avoid triggering XID negotiation for any LLC SAPI used in LLC ADM, but wait for the SGSN to do so (see step 12). In any case the mobile station may avoid triggering XID negotiation for any LLC SAPI used in LLC ABM, but wait for the SGSN to do so (see step 12a). This step is the same as specified in clause 5.3.2.2 in TS 43.129[ None ]  [8]. 6. Upon reception of the first correct RLC/MAC block (sent in normal burst format) from the UE to the Target BSS, the Target BSS informs the Target SGSN by sending the message PS Handover Complete (IMSI, and Local TLLI, Request for Inter RAT Handover Info). The target BSS that supports inter-RAT PS handover to UTRAN shall, when the INTER RAT HANDOVER INFO was not included in the Source BSS to Target BSS transparent container received in the PS HANDOVER REQUEST message as specified in TS 48.018[ None ]  [42], request the INTER RAT HANDOVER INFO from the target SGSN by setting the 'Request for Inter RAT Handover Info' to '1'. 7. The Target BSS also relays the message XID Response to the Target SGSN. Note, the message in step 6 and 7 may arrive in any order in the Target SGSN. 8. Then the Target SGSN knows that the UE has arrived to the target side and Target SGSN informs the Source MME by sending the Forward Relocation Complete Notification (ISR Activated, Serving GW change) message. If ISR Activated is indicated, the source MME shall maintain the UE's contexts and activate ISR, which is only possible when the S-GW is not changed. The Source MME will also acknowledge that information. A timer in source MME is started to supervise when resources in Source eNodeB and Source Serving GW (for Serving GW relocation) shall be released. Upon receipt of the Forward Relocation Complete Acknowledge message the target SGSN starts a timer if the target SGSN allocated S-GW resources for indirect forwarding. For all bearers that were not included in the Forward Relocation Request message sent in step 3, the MME now releases them by sending a Delete Bearer Command to the SGW, or, the appropriate message to the SCEF. 9. The Target SGSN 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 SGSN is now responsible for all the EPS Bearer Context(s) the UE has established. This is performed in the message Modify Bearer Request (SGSN Tunnel Endpoint Identifier for Control Plane, NSAPI(s), SGSN Address for Control Plane, SGSN 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 E-UTRAN, if the target SGSN supports location information change reporting, the target SGSN 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 SGSN also includes the User CSG Information IE in this message. If the UE Time Zone has changed, the SGSN includes the UE Time Zone IE in this message. If Serving GW is not relocated but the Serving Network has changed or if the SGSN has not received any old Serving Network information from the old MME, the SGSN includes the new Serving Network IE in this message. In network sharing scenarios Serving Network denotes the serving core network. If indicated, 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 SGSN releases the non-accepted EPS Bearer contexts by triggering the EPS Bearer context deactivation procedure. 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 SGSN. 10. 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 9. Serving Network should be included if it is received in step 9 or in step 4 in clause 5.5.2.3.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 Supported 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 SGSN, 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. The source Serving GW shall forward the "end marker" packets to the source eNodeB. 11. The Serving GW (for Serving GW relocation this will be the Target Serving GW) acknowledges the user plane switch to the Target SGSN 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 EPS Bearer contexts between the UE, Target BSS, Target SGSN, 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. 12. If the Target SGSN indicated XID Reset (i.e. reset to default XID parameters) in the NAS container included in the HO from E-UTRAN Command message, then on receipt of the PS Handover Complete the Target SGSN initiates an LLC/SNDCP XID negotiation for each LLC SAPI used in LLC ADM. In this case if the Target SGSN wants to use the default XID parameters, it shall send an empty XID Command. If the Target SGSN indicated 'Reset to the old XID parameters' in the NAS container, no further XID negotiation is required for LLC SAPIs used in LLC ADM only. 12a. The Target SGSN (re-)establishes LLC ABM for the EPS Bearer contexts which use acknowledged information transfer. During the exchange of SABM and UA the SGSN shall perform LLC/SNDCP XID negotiation. These steps (12 and 12a) are the same as specified in clause 5.3.2.2 in TS 43.129[ None ]  [8]. 13. After the UE has finished the reconfiguration procedure the UE shall initiate the Routing Area Update procedure. NOTE 2: The RAU procedure is performed regardless if the UE has this routing area registered or not, as specified by TS 43.129[ None ]  [8]. This is needed e.g. to update the START-PS value stored in the 2G-SGSN. The START_PS is delivered to SGSN in INTER RAT HANDOVER INFO parameter of RAU Complete message when requested by SGSN in RAU Accepted. The target SGSN 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 SGSN performs only a subset of the RAU procedure, specifically it excludes the context transfer procedures between source MME and target SGSN. For a UE supporting CIoT EPS Optimisations, the UE uses the bearer status information in the RAU Accept to identify any non-transferred bearers that it shall locally release. 13a. Upon reception of the PS Handover Complete message with the 'Request for Inter RAT Handover Info' set to '1', the SGSN should send then PS Handover Complete Acknowledge (TLLI, INTER RAT HANDOVER INFO) to the target BSS. NOTE 3: An SGSN that does not recognize the "Request for Inter RAT Handover Info" in the PS Handover Complete message will not send the PS Handover Complete Acknowledge message back to the BSS. The target BSS receiving the PS Handover Complete Acknowledge message shall set the 'Reliable INTER RAT HANDOVER' to '1' in the PS Handover Required message in any subsequent PS handover to GERAN A/Gb mode. The target BSS failing to receive the PS Handover Complete Acknowledge message shall set the 'Reliable INTER RAT HANDOVER' to '0' in the PS Handover Required message in any subsequent PS handover to GERAN A/Gb mode. The Target BSS shall, upon receipt of the INTER RAT HANDOVER INFO in the PS Handover Complete Acknowledge message, overwrite its current INTER RAT HANDOVER INFO with this new one. 14. When the timer started at step 8 expires, the source MME sends a Release Resources message to the source eNodeB. The Source eNodeB releases its resources related to the UE. When the timer started in step 8 expires and if the source MME 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, Secondary RAT usage data) messages to the Source Serving GW. The operation Indication flag is not set, that indicates to the Source Serving GW that the Serving GW changes and the Source Serving GW shall not initiate a delete procedure towards the PDN GW. Secondary RAT usage data is included if it was received in step 3. 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. 15. If indirect forwarding was used then the expiry of the timer at source MME started at step 8 triggers the source MME to send a Delete Indirect Data Forwarding Tunnel Request message to the S-GW to release the temporary resources used for indirect forwarding. 16. If indirect forwarding was used and the Serving GW is relocated, then the expiry of the timer at target SGSN started at step 8 triggers the target SGSN to send a Delete Indirect Data Forwarding Tunnel Request message to the target S-GW to release temporary resources used for indirect forwarding.