eUTRAN to UTRAN (4G to 3G) Iu mode handover

Few last articles were about Handover in LTE network. From old eNB to new eNB, with or without using new MME/SGW, with or without using X2 interface, and so on.
Today we will be talking about handovers from eUTRAN to UTRAN, from 4G to 3G.

Sorry guys, today I don't have time to create abstract picture which we could use to start from.
But it should be easy for you to imagine.
UE is moving from area where is 4g coverage to area where is only 3g coverage.
eNBs change to RNCs, MME to SGSN, only the mobility anchor (PGW) stays the same.

More about this you can find in 3GPP TS 23.401.

Inter RAT handover - general information

During Inter RAT handover indirect forwarding may apply for the dowlink data forwarding performed as part of the handover. From its configuration data the MME knows whether indirect forwarding applies and it allocates a dowlink data forwarding path on a Serving GWs for indirect forwarding. From its configuration data the S4 SGSN knows whether indirect forwarding applies and it allocates dowlink data forwarding paths on Serving GWs for indirect forwarding. It is configured on MME and S4 SGSN whether indirect dowlink data forwarding does not apply, applies always or applies only for inter PLMN inter RAT handovers.

eUTRAN to UTRAN Iu mode Inter RAT handover

General information

Pre-conditions:

• The UE is in ECM-CONNECTED state (E-UTRAN mode).

If emergency bearer services are ongoing for an UE, handover to the target RNC is performed independent of the Handover Restriction List. The SGSN checks, as part of the Routing Area Update in the execution phase, if the handover is to a restricted area and if so SGSN deactivate the non-emergency PDP context.

Preparation phase

Fig. 1. E-UTRAN to UTRAN Iu mode Inter RAT HO preparation phase.

Step 1. The source eNodeB decides to initiate an Inter-RAT handover to the target access network, UTRAN Iu mode. 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 a UTRAN cell that is not IMS voice capable.
Step 2. The source eNodeB sends a Handover Required (S1AP Cause, Target RNC Identifier, CSG ID, CSG access mode, Source eNodeB Identifier, Source to Target Transparent Container) message to the source MME to request the CN to establish resources in the target RNC, target SGSN and the Serving GW. The bearers that will be subject to data forwarding (if any) are identified by the target SGSN in a later step (see step 7 below). When the target cell is a CSG cell or a hybrid cell, the source eNodeB shall include the CSG ID of the target cell. If the target cell is a hybrid cell, the CSG access mode shall be indicated.
Step 3. The source MME determines from the 'Target RNC Identifier' IE that the type of handover is IRAT Handover to UTRAN Iu mode. The Source MME initiates the Handover resource allocation procedure by sending a Forward Relocation Request (IMSI, Target Identification, CSG ID, CSG Membership Indication, MM Context, PDN Connections, MME Tunnel Endpoint Identifier for Control Plane, MME Address for Control plane, Source to Target Transparent Container, RAN Cause, MS Info Change Reporting Action (if available), CSG Information Reporting Action (if available), UE Time Zone, ISR Supported) message to the target SGSN. The information ISR Supported is indicated if the source MME and associated Serving GW are capable to activate ISR for the UE. When ISR is activated the message should be sent to the SGSN that maintains ISR for the UE when this SGSN is serving the target identified by the Target Identification. This message includes all PDN Connections active in the source system and for each PDN Connection includes the associated APN, the address and the uplink Tunnel endpoint parameters of the Serving GW for control plane, and a list of EPS Bearer Contexts. RAN Cause indicates the S1AP Cause as received from source eNodeB.
The source MME shall perform access control by checking the UE's CSG subscription when CSG ID is provided by the source eNodeB. If there is no subscription data for this CSG ID or the CSG subscription is expired, and the target cell is a CSG cell, the source MME shall reject the handover with an appropriate cause.
The source MME includes the CSG ID in the Forward Relocation Request when the target cell is a CSG cell or hybrid cell. When the target cell is a hybrid cell, the CSG Membership Indication indicating whether the UE is a CSG member shall be included in the Forward Relocation Request message.
The target SGSN maps the EPS bearers to PDP contexts 1-to-1 and maps the EPS Bearer QoS parameter values of an EPS bearer to the Release 99 QoS parameter values of a bearer context.
Prioritization of PDP Contexts is performed by the target core network node, i.e. target SGSN.
The MM context contains security related information, e.g. supported ciphering algorithms
The target SGSN shall determine the Maximum APN restriction based on the APN Restriction of each bearer context in the Forward Relocation Request, and shall subsequently store the new Maximum APN restriction value.
Step 4. The target SGSN determines if the Serving GW is to be relocated, e.g., due to PLMN change. If the Serving GW is to be relocated, the target SGSN selects the target Serving GW, and sends a Create Session Request message (IMSI, SGSN Tunnel Endpoint Identifier for Control Plane, SGSN Address for Control plane, PDN GW address(es) for user plane, PDN GW UL TEID(s) for user plane, PDN GW address(es) for control plane, and PDN GW TEID(s) for control plane, the Protocol Type over S5/S8, Serving Network) per PDN connection to the target Serving GW. The Protocol Type over S5/S8 is provided to Serving GW which protocol should be used over S5/S8 interface.
The target SGSN establishes the EPS Bearer context(s) in the indicated order. The SGSN deactivates, as provided in step 7 of the execution phase, the EPS Bearer contexts which cannot be established.
Step 4a. The target Serving GW allocates its local resources and returns 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 SGSN.
Step 5. The target SGSN requests the target RNC to establish the radio network resources (RABs) by sending the message Relocation Request (UE Identifier, Cause, CN Domain Indicator, Integrity protection information (i.e. IK and allowed Integrity Protection algorithms), Encryption information (i.e. CK and allowed Ciphering algorithms), RAB (Radio Access Bearer) to be setup list, CSG ID, CSG Membership Indication, Source RNC to Target RNC Transparent Container, Service Handover related information). If the Access Restriction is present in the MM context, the Service Handover related information shall be included by the target SGSN for the Relocation Request message in order for RNC to restrict the UE in connected mode to handover to the RAT prohibited by the Access Restriction.
For each RAB requested to be established, RABs To Be Setup shall contain information such as RAB ID, RAB parameters, Transport Layer Address, and Iu Transport Association. The RAB ID information element contains the NSAPI value, and the RAB parameters information element gives the QoS profile. The Transport Layer Address is the Serving GW Address for user plane (if Direct Tunnel is used) or the SGSN Address for user plane (if Direct Tunnel is not used), and the Iu Transport Association corresponds to the uplink Tunnel Endpoint Identifier Data in Serving GW or SGSN respectively.
Ciphering and integrity protection keys are sent to the target RNC to allow data transfer to continue in the new RAT/mode target cell without requiring a new AKA (Authentication and Key Agreement) procedure. Information that is required to be sent to the UE (either in the Relocation Command message or after the handover completion message) from RRC in the target RNC shall be included in the RRC message sent from the target RNC to the UE via the transparent container.
The Target SGSN shall include the CSG ID and CSG Membership Indication when provided by the source MME in the Forward Relocation Request message.
In the target RNC radio and Iu user plane resources are reserved for the accepted RABs. Cause indicates the RAN Cause as received from source MME. The Source RNC to Target RNC Transparent Container includes the value from the Source to Target Transparent Container received from the source eNodeB.
If the target cell is a CSG cell, the target RNC shall verify the CSG ID provided by the target SGSN, and reject the handover with an appropriate cause if it does not match the CSG ID for the target cell. If the target cell is in hybrid mode, the target RNC may use the CSG Membership Indication to perform differentiated treatment for CSG and non-CSG members.
Step 5a. The target RNC allocates the resources and returns the applicable parameters to the target SGSN in the message Relocation Request Acknowledge (Target RNC to Source RNC Transparent Container, RABs setup list, RABs failed to setup list).
Upon sending the Relocation Request Acknowledge message the target RNC shall be prepared to receive downlink GTP PDUs from the Serving GW, or Target SGSN if Direct Tunnel is not used, for the accepted RABs.
Each RABs setup list is defined by a Transport Layer Address, which is the target RNC Address for user data, and the Iu Transport Association, which corresponds to the downlink Tunnel Endpoint Identifier for user data.
Any EPS Bearer contexts for which a RAB was not established are maintained in the target SGSN and the UE. These EPS Bearer contexts shall be deactivated by the target SGSN via explicit SM procedures upon the completion of the routing area update (RAU) procedure.
Step 6. If 'Indirect Forwarding' and relocation of Serving GW apply and Direct Tunnel is used the target SGSN sends a Create Indirect Data Forwarding Tunnel Request message (Target RNC Address and TEID(s) for DL data forwarding) to the Serving GW. If 'Indirect Forwarding' and relocation of Serving GW apply and Direct Tunnel is not used, then the target SGSNSGSN Address and TEID(s) for DL data forwarding) to the Serving GW.
Indirect forwarding may be performed via a Serving GW which is different from the Serving GW used as the anchor point for the UE.
Step 6a. The Serving GW returns a Create Indirect Data Forwarding Tunnel Response (Cause, Serving GW Address(es) and Serving GW DL TEID(s) for data forwarding) message to the target SGSN.
Step 7. The target SGSN sends the message Forward Relocation Response (Cause, SGSN Tunnel Endpoint Identifier for Control Plane, SGSN Address for Control Plane, Target to Source Transparent Container, Cause, RAB Setup Information, Additional RAB Setup Information, Address(es) and TEID(s) for User Traffic Data Forwarding, Serving GW change indication) to the source MME. Serving GW change indication indicates a new Serving GW has been selected. The Target to Source Transparent Container contains the value from the Target RNC to Source RNC Transparent Container received from the target RNC.
The IE 'Address(es) and TEID(s) for User Traffic Data Forwarding' defines the destination tunnelling endpoint for data forwarding in target system, and it is set as follows:

• If 'Direct Forwarding' applies, or if 'Indirect Forwarding' and no relocation of Serving GW apply and Direct Tunnel is used, then the IE 'Address(es) and TEID(s) for User Traffic Data Forwarding' contains the addresses and GTP-U tunnel endpoint parameters to the Target RNC received in step 5a.
• If 'Indirect Forwarding' and relocation of Serving GW apply, then the IE 'Address(es) and TEID(s) for User Traffic Data Forwarding' contains the addresses and DL GTP-U tunnel endpoint parameters to the Serving GW received in step 6. This is independent from using Direct Tunnel or not.
• If 'Indirect Forwarding' applies and Direct Tunnel is not used and relocation of Serving GW does not apply, then the IE 'Address(es) and TEID(s) for User Traffic Data Forwarding' contains the DL GTP-U tunnel endpoint parameters to the Target SGSN.

Step 8. If "Indirect Forwarding" applies, the Source MME sends the message Create Indirect Data Forwarding Tunnel Request (Address(es) and TEID(s) for Data Forwarding (received in step 7)), EPS Bearer ID(s)) to the Serving GW used for indirect 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.
Step 8a. The Serving GW returns the forwarding parameters by sending the message Create Indirect Data Forwarding Tunnel Response (Cause, Serving GW Address(es) and TEID(s) for Data Forwarding). 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.

Execution phase

Fig. 2. E-UTRAN to UTRAN Iu mode Inter RAT HO execution phase.

The source eNodeB continues to receive downlink and uplink user plane PDUs.
Step 1. The source MME completes the preparation phase towards source eNodeB by sending the message Handover Command (Target to Source Transparent Container, E-RABs to Release List, Bearers Subject to Data Forwarding List). The "Bearers 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 the preparation phase (Step 7 of the preparation phase) when 'Direct Forwarding' applies, or the parameters received in Step 8a of the preparation phase when 'Indirect Forwarding' applies.
The source eNodeB initiates data forwarding for bearers specified in the "Bearers Subject to Data Forwarding List". The data forwarding may go directly to target RNC or alternatively go via the Serving GW if so decided by source MME and or/ target SGSN in the preparation phase.
Step 2. The source eNodeB will give a command to the UE to handover to the target access network via the message HO from E-UTRAN Command. This message includes a transparent container including radio aspect parameters that the target RNC has set-up in the preparation phase.
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 RABs based on the relation with the NSAPI and shall suspend the uplink transmission of the user plane data.
Step 3. Void.
Step 4. The UE moves to the target UTRAN Iu (3G) system and executes the handover according to the parameters provided in the message delivered in step 2. The procedure is the same as in step 6 and 8, with the additional function of association of the received RABs and existing Bearer Id related to the particular NSAPI.
The UE may resume the user data transfer only for those NSAPIs for which there are radio resources allocated in the target RNC.
The UE locally deactivates ISR by setting its TIN from "RAT-related TMSI" to "GUTI", if any EPS bearer context activated after the ISR was activated in the UE exists.
Step 5. When the new source RNC-ID + S-RNTI are successfully exchanged with the UE, the target RNC shall send the Relocation Complete message to the target SGSN. The purpose of the Relocation Complete procedure is to indicate by the target RNC the completion of the relocation from the source E-UTRAN to the RNC. After the reception of the Relocation Complete message the target SGSN shall be prepared to receive data from the target RNC. Each uplink N-PDU received by the target SGSN is forwarded directly to the Serving GW.
Step 6. 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 indicated, ISR Activated indicates to the source MME that it shall maintain the UE's context and that it shall 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.
When the timer expires and ISR Activated is not indicated by the target SGSN the source MME releases all bearer resources of the UE. If Serving GW change is indicated and this timer expires the source MME deletes the EPS bearer resources by sending Delete Session Request (Cause) messages to the Source Serving GW. Cause 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. If Serving GW change is indicated and has been activated before this procedure, the cause also 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.
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.
Step 7. 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 Contexts 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 (if Direct Tunnel is not used) or RNC Address(es) and TEID(s) for User Traffic for the accepted EPS bearers (if Direct Tunnel is used) and RAT type, ISR Activated) per PDN connection. If the PDN GW requested UE's location and/or User CSG information (determined from the UE context), the SGSN also includes the User Location Information IE and/or 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 indicated, the information ISR Activated indicates that ISR is activated, which is only possible when the S GW is 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 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.
Step 8. The Serving GW (for Serving GW relocation this will be the Target Serving GW) may inform 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. 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 7. Serving Network should be included 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. In the case of Serving GW relocation, the PDN GW updates its context field and returns a Modify Bearer Response (Charging Id, MSISDN, etc.) message to the Serving GW. The MSISDN is included if the PDN GW has it stored in its UE context.
If PCC infrastructure is used, the PDN GW informs the PCRF about the change of, for example, the RAT type.
Step 9. 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). At this stage the user plane path is established for all EPS Bearer contexts between the UE, target RNC, target SGSN if Direct Tunnel is not used, 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.
Step 10. When the UE recognises that its current Routing Area is not registered with the network, or when the UE's TIN indicates "GUTI", the UE initiates a Routing Area Update procedure with the target SGSN informing it that the UE is located in a new routing area. It is RAN functionality to provide the PMM-CONNECTED UE with Routing Area information.
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.
Step 11. When the timer started at step 6 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 6 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) messages to the Source Serving GW. Cause 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 also 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.
Step 12. If indirect forwarding was used then the expiry of the timer at source MME started at step 6 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.
Step 13. If indirect forwarding was used and the Serving GW is relocated, then the expiry of the timer at target SGSN started at step 6 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.

Source(s):

3GPP TS 23.401