Section: D.3.7.2 Preparation phase
Content: Figure D.3.7.2-1: E-UTRAN to GERAN A/Gb Inter RAT HO, preparation phase 1. The source eNodeB decides to initiate an Inter RAT Handover to the target GERAN A/Gb mode (2G) system. At this point both uplink and downlink user data is transmitted via the following: Bearer(s) between UE and Source eNodeB, GTP tunnel(s) between Source eNodeB, Serving GW and PDN GW. If the UE has an ongoing emergency bearer service the source eNodeB shall not initiate PS handover to GERAN. NOTE 1: The process leading to the handover decision is outside of the scope of this specification 2. The source eNodeB sends a Handover Required (Cause, Target System Identifier, Source BSS to Target BSS Transparent Container) message to the Source MME to request the CN to establish resources in the Target BSS, Target SGSN and the Serving GW. The bearers that will be subject to data forwarding (if any) are identified by the new SGSN in a later step (see step 8 below). The 'Target System Identifier' IE contains the identity of the target global cell Id. NOTE 2: This step is unmodified compared to clause 5.5.2.3.2. The target SGSN acts as the new SGSN. 3 The old SGSN determines from the Target Cell Identifier that the type of handover is inter-RAT/mode handover. In the case of Inter-RAT/ mode Inter-SGSN PS handover, the old SGSN initiates the PS Handover resource allocation procedure by sending a Forward Relocation Request (IMSI, Tunnel Endpoint Identifier Control Plane, RANAP Cause, Target Cell Identifier, MM Context, PDP Contexts, Packet Flow ID, SNDCP XID parameters, LLC XID parameters, PDP Context Prioritisation, Source BSS To Target BSS Transparent Container [RN part] in the BSS Container, Source RNC Id, SGSN Address for control plane) message to the new SGSN. If the old SGSN supports PS handover procedures then it has to allocate a valid PFI according to clause 4.4.1 during the PDP Context activation procedure. Each PDP context contains the GGSN Address for User Plane and the Uplink TEID for Data (to this GGSN Address and Uplink TEID for Data the old SGSN and the new SGSN send uplink packets). The MM context includes information on the EPS Bearer context(s). If none of the UE's EPS Bearers can be supported by the selected target SGSN, the old SGSN rejects the handover attempt by sending a Handover Preparation Failure (Cause) message to the Source eNodeB. NOTE 3: If the handover is successful, the old SGSN will signal to the SGW and/or SCEF to release any non-included EPS Bearers after step 8 of the Execution procedure. The non-included bearers are locally released by the MS following the PDP Context Status synchronisation that occurs during the Routing Area Update at step 13 of the Execution procedure. The MM context contains security related information, e.g. supported ciphering algorithms as described in TS 29.060[ General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface ]  [14]. The relation between GSM and UMTS security parameters is defined in TS 33.102[ 3G security; Security architecture ]  [40], The new SGSN selects the ciphering algorithm to use. This algorithm will be sent transparently from the new SGSN to the MS. The IOV-UI parameter generated in the new SGSN and used, as input to the ciphering procedure will also be transferred transparently from the new SGSN to the MS. When the new SGSN receives the Forward Relocation Request message the required PDP, MM, SNDCP and LLC contexts are established and a new P-TMSI is allocated for the MS. When this message is received by the new SGSN it begins the process of establishing PFCs for all PDP contexts. When the new SGSN receives the Forward Relocation Request message it extracts from the PDP Contexts the NSAPIs and SAPIs and PFIs to be used in the new SGSN. If for a given PDP Context the new SGSN does not receive a PFI from the old SGSN, it shall not request the target BSS to allocate TBF resources corresponding to that PDP Context. If none of the PDP Contexts forwarded from the old SGSN has a valid PFI allocated the new SGSN shall consider this as a failure case and the request for PS handover shall be rejected. In the case when an SAPI and PFI was available at the old SGSN but the new SGSN does not support the same SAPI and PFI for a certain NSAPI as the old SGSN, the new SGSN shall continue the PS handover procedure only for those NSAPIs for which it can support the same PFI and SAPI as the old SGSN. All PDP contexts for which no resources are allocated by the new SGSN or for which it cannot support the same SAPI and PFI (i.e. the corresponding NSAPIs are not addressed in the response message of the target SGSN), are maintained and the related SAPIs and PFIs are kept. These PDP contexts may be modified or deactivated by the new SGSN via explicit SM procedures upon RAU procedure. The old SGSN shall indicate the current XID parameter settings if available (i.e. those negotiated at the old SGSN when the MS was in A/Gb mode or received during a previous inter-SGSN PS handover) to the new SGSN. If the new SGSN can accept all XID parameters as indicated by the old SGSN, the new SGSN shall create a NAS container for PS HO indicating 'Reset to the old XID parameters'. Otherwise, if the new SGSN cannot accept all XID parameters indicated by the old SGSN or if no XID parameters were indicated by the old SGSN, the new SGSN shall create a NAS container for PS HO indicating Reset (i.e. reset to default parameters). NOTE 4: This step is unmodified compared to pre-Rel-8. The Source eNodeB acts as the source RNC, Source MME acts as the old SGSN, and the PDN GW acts as the GGSN. 4. The new SGSN sends a PS Handover Request (Local TLLI, IMSI, Cause, Target Cell Identifier, Source BSS to Target BSS Transparent Container (RN part), PFCs To Be Set Up List, NAS container for PS HO) message to the target BSS. The new SGSN shall not request resources for PFCs associated with PDP contexts with maximum bit rate for uplink and downlink of 0 kbit/s or for which the Activity Status Indicator within the PDP Context indicates that no active RAB exists on the source side. 5. Based upon the ABQP for each PFC the target BSS makes a decision about which PFCs to assign radio resources. The algorithm by which the BSS decides which PFCs that need resources is implementation specific. Due to resource limitations not all downloaded PFCs will necessarily receive resource allocation. The target BSS allocates TBFs for each PFC that it can accommodate. 6. The target BSS shall prepare the Target BSS to Source BSS Transparent Container which contains a PS Handover Command including the CN part (NAS container for PS HO) and the RN part (PS Handover Radio Resources). 7. Target BSS shall send the PS Handover Request Acknowledge message (Local TLLI, List of Set Up PFCs, Target BSS to Source BSS Transparent Container) message to the new SGSN. Upon sending the PS Handover Request Acknowledge message the target BSS shall be prepared to receive downlink LLC PDUs from the new SGSN for the accepted PFCs. Any PDP contexts for which a PFC was not established are maintained in the new SGSN and the related SAPIs and PFIs are kept. These PDP contexts may be modified or deactivated by the new SGSN via explicit SM procedures upon the completion of the routing area update (RAU) procedure. 8. The new SGSN passes the assigned list of TEIDs for each PDP context for which a PFC was assigned in the RAB setup information IE in the Forward Relocation Response (Cause, List of Set Up PFCs, Target BSS to Source BSS Transparent Container) in the BSS Container, Tunnel Endpoint Identifier Control Plane, SGSN Address for User Traffic, Tunnel Endpoint Identifier Data II) message to the old SGSN. The NSAPIs of the active PDP Contexts received in the Forward Relocation Request message for which the PS handover continues, i.e. for which resources are allocated for the PFCs in the target BSS, are indicated in this message. The Tunnel Endpoint Identifier Data II, one information for each PDP context, is the tunnel endpoint of the new SGSN and is used for data forwarding from the Source eNodeB, via the new SGSN, to the target BSS. The new SGSN activates the allocated LLC/SNDCP engines as specified in TS 44.064[ Mobile Station - Serving GPRS Support Node (MS-SGSN); Logical Link Control (LLC) Layer Specification ]  [23] for an SGSN originated Reset or 'Reset to the old XID parameters'. When the old SGSN receives the Forward Relocation Response message and it decides to proceed with the handover, the preparation phase is finished and the execution phase will follow. 9. If 'Indirect Forwarding' applies, the source MME sends a Create Indirect Data Forwarding Tunnel Request message (Cause, SGSN Address(es) and TEID(s) for Data Forwarding) to the Serving GW. Cause indicates that the bearer(s) are subject to data forwarding. Indirect forwarding may be performed via a Serving GW which is different from the Serving GW used as the anchor point for the UE. 9a. 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. NOTE 5: This step is mostly unmodified compared to pre-Rel-8. The Source MME acts as the old SGSN, and the PDN GW acts as the GGSN.