MME to 3G SGSN combined hard handover and SRNS relocation procedure

The MME to 3G Gn/Gp SGSN Combined Hard Handover and SRNS Relocation procedure is illustrated in Figure D.3.3-1.

Any steps descriptions that are from inter Gn/Gp SGSNs procedures of TS 23.060 [7] are shown as italic text and remain unmodified. In those step descriptions an MS stands for UE, old SGSN for old MME and GGSN for P‑GW.

The procedure parts between E-UTRAN eNodeB and UE, and between E-UTRAN eNodeB and MME are compliant with the equivalent procedure parts in clause "5.5 Handover".

If emergency bearer services are ongoing for the 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 as specified in TS 23.060 [7], clause 9.2.4.2.

                                                                  D.3.3-1

Figure D.3.3-1: MME to 3G SGSN combined hard handover and SRNS relocation procedure

1.   The source eNodeB decides to initiate a 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.

2.   The source eNodeB sends a Handover Required (S1AP Cause, Target RNC Identifier, Source to Target Transparent Container) message to the source MME to request the CN to establish resources in the target RNC and the target SGSN. The bearers that will be subject to data forwarding (if any) are identified by the new SGSN in a later step (see step 5 below).

3.   The old MME sends a Forward Relocation Request message (IMSI, Tunnel Endpoint Identifier Signalling, MM Context, PDP Context, Target Identification, RAN Transparent Container, RANAP Cause, GCSI) to the new SGSN. For relocation to an area where Intra Domain Connection of RAN Nodes to Multiple CN Nodes is used, the old MME may have multiple new Gn/Gp SGSNs for each relocation target in a pool area, in which case the old MME will select one of them to become the new Gn/Gp SGSN, as specified in TS 23.236 [30]. PDP context contains GGSN Address for User Plane and Uplink TEID for Data (to this GGSN Address and Uplink TEID for Data, the Serving GW and the new SGSN send uplink packets). At the same time a timer is started on the MM and PDP contexts in the old MME (see Routing Area Update procedure in clause "Location Management Procedures (Iu mode)"). The old MME does not set any GCSI flag as the MME has no GPRS CAMEL Subscription Information. The S1AP Cause received from eNodeB is indicated as RANAP Cause. The Source to Target Transparent Container received from eNodeB is indicated as RAN Transparent Container.

NOTE 1:   The GGSN user plane address and uplink TEID are the old P‑GW user plane address and TEID. The MME maps the EPS bearer parameters to PDP contexts.

4.   The new SGSN sends a Relocation Request message (Permanent NAS UE Identity, Cause, CN Domain Indicator, Source RNC To Target RNC Transparent Container, RAB To Be Setup) to the target RNC. 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. SGSN shall not establish RABs for PDP contexts with maximum bitrate for uplink and downlink of 0 kbit/s. The list of RABs requested by the new SGSN may differ from list of RABs established in the Source RNC contained in the Source-RNC to target RNC transparent container. The target RNC should not establish the RABs (as identified from the Source-RNC to target RNC transparent container, Service Handover related information) that did not exist in the source RNC prior to the relocation. 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 SGSN Address for user data, and the Iu Transport Association corresponds to the uplink Tunnel Endpoint Identifier Data. The new SGSN may decide to establish Direct Tunnel unless it has received a 'set' GCSI flag from the old SGSN. If the new SGSN decides to establish Direct Tunnel, it provides to the target RNC the GGSN's Address for User Plane and TEID for Uplink data. 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.

      After all the necessary resources for accepted RABs including the Iu user plane are successfully allocated, the target RNC shall send the Relocation Request Acknowledge message (Target RNC To Source RNC Transparent Container, RABs Setup, RABs Failed To Setup) to the new SGSN. Each RAB to be setup 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. The transparent container contains all radio-related information that the MS needs for the handover, i.e. a complete RRC message (e.g., Physical Channel Reconfiguration in UTRAN case, or Handover From UTRAN, or Handover Command in GERAN Iu mode case) to be sent transparently via CN and source SRNC to the MS. For each RAB to be set up, the target RNC may receive simultaneously downlink user packets both from the source SRNC and from the new SGSN.

NOTE 2:   This step for the new SGSN is unmodified compared to pre-Rel-8. If the new SGSN decides to establish Direct Tunnel, it provides to the target RNC the P‑GW Address for User Plane and TEID for Uplink data. The UE acts as the MS; the old eNodeB acts as the source SRNC.

5.   When resources for the transmission of user data between target RNC and new SGSN have been allocated and the new SGSN is ready for relocation of SRNS, the Forward Relocation Response (Cause, RAN Transparent Container, RANAP Cause, Target-RNC Information) message is sent from the new SGSN to the old SGSN. This message indicates that the target RNC is ready to receive from source SRNC the forwarded downlink PDUs, i.e., the relocation resource allocation procedure is terminated successfully. RAN transparent container and RANAP Cause are information from the target RNC to be forwarded to the source SRNC. The Target RNC Information, one information element for each RAB to be set up, contains the RNC Tunnel Endpoint Identifier and RNC IP address for data forwarding from the source SRNC to the target RNC. The Forward Relocation Response message is applicable only in case of inter-SGSN SRNS relocation.

NOTE 3:   This step is unmodified compared to pre-Rel-8. The old MME acts as the old SGSN, and the source eNodeB as the source SRNC.

6.   If 'Indirect Forwarding' applies the source MME sends a Create Indirect Data Forwarding Tunnel Request message (IMSI, MME Tunnel Endpoint Identifier for Control Plane, MME Address for Control plane, Target RNC Address and TEID(s) for DL user plane) to the Serving GW.

7.   The Serving GW returns a Create Indirect Data Forwarding Tunnel Response (Cause, Serving GW DL TEID(s)) message to the source MME. If the Serving GW doesn't support data forwarding, an appropriate cause value shall be returned.

8.   The source MME completes the preparation phase towards source eNodeB by sending the message Handover Command (Target to Source Transparent Container, Bearers Subject to Data Forwarding List, S1AP Cause). "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 5) in the case of direct forwarding or received from the Serving GW in the preparation phase (Step 7) in the case of indirect forwarding. RANAP Cause as received from new SGSN is indicated as S1AP Cause. RAN Transparent Container as received from new SGSN is indicated as Target to Source Transparent Container.

9.   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 in the preparation phase.

10. 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. The details of this E-UTRAN specific signalling are described in TS 36.300 [5].

11  Void.

NOTE 4:   The source eNodeB does not send any RAN contexts towards the target RNC.

12. The target RNC shall send a Relocation Detect message to the new SGSN when the relocation execution trigger is received. For SRNS relocation type "UE Involved", the relocation execution trigger may be received from the Uu interface; i.e., when target RNC detects the MS on the lower layers. When the Relocation Detect message is sent, the target RNC shall start SRNC operation.

NOTE 5:   This step is unmodified compared to pre-Rel-8.

13. When the MS has reconfigured itself, it sends an RRC message e.g., a Physical Channel Reconfiguration Complete message to the target SRNC.

      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.

14. When the target SRNC receives the appropriate RRC message, e.g. Physical Channel Reconfiguration Complete message or the Radio Bearer Release Complete message in UTRAN case, or the Handover To UTRAN Complete message or Handover Complete message in GERAN case, i.e. the new SRNC‑ID + S‑RNTI are successfully exchanged with the MS by the radio protocols, the target SRNC shall initiate a Relocation Complete procedure by sending the Relocation Complete message to the new SGSN. The purpose of the Relocation Complete procedure is to indicate by the target SRNC the completion of the relocation of the SRNS to the CN.

NOTE 6:   This step is unmodified compared to pre-Rel-8. The UE acts as the MS.

15. Upon receipt of Relocation Complete message, if the SRNS Relocation is an inter SGSN SRNS relocation, the new SGSN signals to the old SGSN the completion of the SRNS relocation procedure by sending a Forward Relocation Complete message.

      A timer in source MME is started to supervise when resources in Source eNodeB and Source Serving GW shall be released.

NOTE 7:   For the SGSN this step is unmodified compared to pre-Rel-8. The old MME acts as the old SGSN, and the source eNodeB as the source SRNC.

16. Upon receipt of the Relocation Complete message, the CN shall switch the user plane from the source RNC to the target SRNC. If the SRNS Relocation is an inter-SGSN SRNS relocation or if Direct Tunnel was established in intra-SGSN SRNS relocation, the new SGSN sends Update PDP Context Request messages (new SGSN Address, SGSN Tunnel Endpoint Identifier, QoS Negotiated, serving network identity, CGI/SAI, User CSG Information, RAT type, MS Info Change Reporting support indication, NRSN, DTI) to the GGSNs concerned. The SGSN shall send the serving network identity to the GGSN. If Direct Tunnel is established the SGSN provides to GGSN the RNC's Address for User Plane and TEID for Downlink data and shall include the DTI to instruct the GGSN to apply Direct Tunnel specific error handling procedure as described in clause 13.8. NRSN indicates SGSN support of the network requested bearer control. The GGSNs update their PDP context fields and return an Update PDP Context Response (GGSN Tunnel Endpoint Identifier, Prohibit Payload Compression, APN Restriction, MS Info Change Reporting Action, CSG Information Reporting Action, BCM) message. The Prohibit Payload Compression indicates that the SGSN should negotiate no data compression for this PDP context.

      The PDN GW shall include a Charging Id to be used at the SGSN as the Charging Id for reporting usage for this PDP context. The PDN GW shall include the Charging Id in the offline charging data.

NOTE 8:   This step is unmodified compared to pre-Rel-8. The P‑GW acts as the GGSN.

17. After the MS has finished the reconfiguration procedure and if the new Routing Area Identification is different from the old one or if the MS' TIN indicates "GUTI", the MS initiates the Routing Area Update procedure. See clause "Location Management Procedures (Iu mode)".

NOTE 9:   It is only a subset of the RA update procedure that is performed, since the MS is in PMM‑CONNECTED state.

NOTE 10: This step is unmodified compared to pre-Rel-8. The UE acts as the MS. The old EPS bearer information in old MME and Serving GW is removed as part of the Routing Area Update procedure.

18. When the timer started in step 15 expires, the source MME deletes the EPS bearer resources by sending Delete Session Request (Cause, Operation Indication) messages to the Serving GW because the new SGSN is a Gn/Gp SGSN, which is derived from using GTPv1 for relocation signalling between new Gn/Gp SGSN and old MME. The new Gn/Gp SGSN does not signal any Serving GW change. The operation Indication flag is not set, that indicates to the Serving GW that the 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 is activated the cause indicates to the old S‑GW that the old S‑GW shall delete the bearer resources on the other old CN node by sending Delete Bearer Request message(s) to that CN node. If resources for indirect forwarding have been allocated then these are released.

      When the timer started in step 15 expires, the source MME sends a Release Resources message to the source eNodeB. When the Release Resources message has been received and there is no longer any need for the eNodeB to forward data, the source eNodeB releases its resources.

If the SRNS Relocation is inter-SGSN, then the following CAMEL procedure calls shall be performed (see referenced procedures in TS 23.078 [29])

NOTE 11: The C1 CAMEL procedure call was omitted intentionally from this procedure since EPS does not support CAMEL procedure calls. The other CAMEL procedure calls are unmodified compared to pre-Rel‑8.

The new SGSN shall determine the Maximum APN restriction based on the received APN Restriction of each PDP context from the GGSN and then store the new Maximum APN restriction value.

If the SRNS Relocation is intra-SGSN, then the above mentioned CAMEL procedures calls shall not be performed.

If Routing Area Update occurs, the SGSN shall determine whether Direct Tunnel can be used based on the received GPRS CAMEL Subscription Information. If Direct Tunnel can not be maintained the SGSN shall re-establish RABs and initiate the Update PDP Context procedure to update the IP Address and TEID for Uplink and Downlink data.

If Routing Area Update occurs, then the following CAMEL procedure calls shall be performed (see referenced procedures in TS 23.078 [29]):

C2)   CAMEL_GPRS_Routing_Area_Update_Session and CAMEL_PS_Notification.

      They are called in the following order:

-     The CAMEL_GPRS_Routing_Area_Update_Session procedure is called. The procedure returns as result "Continue".

-     Then the CAMEL_PS_Notification procedure is called. The procedure returns as result "Continue".

C3)   CAMEL_GPRS_Routing_Area_Update_Context.

This procedure is called several times: once per PDP context. It returns as result "Continue".

For C2 and C3: refer to Routing Area Update procedure description for detailed message flow.