5.2 Inter-RAT/mode handover (GERAN A/Gb mode  UTRAN/ GERAN Iu mode)

3GPP43.129Packet-switched handover for GERAN A/Gb modeRelease 17Stage 2TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.2.1 Intra SGSN

5.2.1.1 Intra-SGSN GERAN A/Gb mode to UTRAN/GERAN Iu mode HO; Preparation phase

Figure 11: PS Handover Preparation Phase; Inter-RAT/mode,
Intra-SGSN case (GERAN A/Gb mode  UTRAN, GERAN Iu mode)

1. The source BSS decides to initiate a PS handover. At this point both uplink and downlink user data is transmitted via the following: TBFs between MS and source BSS, BSSGP PFCs tunnel(s) between the source BSS and 3G/2G SGSN, GTP tunnel(s) between the 3G/2G SGSN and GGSN.

2. The source BSS sends a PS Handover Required (TLLI, Cause, Source Cell Identifier, Target RNC Identifier, Source to Target Transparent Container, Active PFCs List) message to the SGSN.

If PS handover to a UTRAN CSG cell or Hybrid cell is required, the source BSS includes in addition to the Target RNC Identifier also the CSG Identifier in the PS Handover Required message to the SGSN. In case of PS handover to an UTRAN CSG cell the source BSS sets the Cell Access Mode field to "CSG Cell" in the CSG Identifier. In case of PS handover to an UTRAN hybrid cell the source BSS sets the Cell Access Mode field to "Hybrid Cell" in the CSG Identifier.

Upon reception of the PS Handover Required message containing a CSG Identifier with the Cell Access Mode field set to "CSG cell", the 3G/2G SGSN performs the access control according to the CSG Subscription List of that MS. If the MS is allowed to access the target cell, the 3G/2G SGSN continues the PS handover to the target RNC. If the MS is not allowed to access the target cell, the 3G/2G SGSN sends the PS Handover Required Negative Acknowledge message with an appropriate cause value indicating invalid CSG cell to the source BSS. If the PS Handover Required message contains a CSG Identifier with the Cell Access Mode field set to "Hybrid Cell", the 3G/2G SGSN provides the membership status of the MS and the CSG Id to the target RNC (see 3GPP TS25.413).

3. The 3G/2G SGSN determines from the Target RNC Identifier that the type of handover is inter‑RAT/mode handover. In case of Inter-RAT/Intra-SGSN PS handover, the 3G/2G SGSN constructs a Relocation Request (Permanent NAS Identity, Cause, CN Domain Indicator, Integrity protection information (i.e. IK and allowed Integrity Protection algorithms, Encryption information (i.e. CK and allowed Ciphering algorithms), RABs To Be Set Up List, Source to Target Transparent Container, Iu Signalling connection identifier, Global CN-ID, SNA Access Information, UESBI-Iu) message to the target RNC/BSS.

For each RAB requested to be established, the RABs To Be Set Up List shall contain information such as RAB ID, RAB parameters, Transport Layer Address, and Iu Transport Association. The 3G/2G SGSN shall only request resources for RABs for which the corresponding PFC is included in the Active PFCs List. 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 SGSN may decide to establish a Direct Tunnel. In this case the SGSN provides to the target RNC the GGSN Address for User Plane and Uplink TEID for data.

Ciphering and integrity protection keys are sent to the target RNC/BSS 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 MS (either in the PS Handover Command message or after the handover completion message) from RRC in the target RNC/BSS shall be included in the RRC message sent from the target RNC/BSS to the MS via the transparent container.

In the target RNC/BSS radio and Iu user plane resources are reserved for the accepted RABs.

In case of PS handover to a CSG cell, the 3G/2G SGSN includes also the CSG ID in the Relocation Request message to the target RNC.

In case of PS handover to a Hybrid cell, the 3G/2G SGSN includes also the CSG ID and CSG Membership Status in the Relocation Request message to the target RNC. The target RNC may use the CSG Membership Status to perform differentiated treatment for CSG and non-CSG members (see 3GPP TS25.413).

4. The target RNC/BSS sends the Relocation Request Acknowledge (Target to Source Transparent Container, RABs setup list, RABs failed to setup list) message to the 3G/2G SGSN. Upon sending the Relocation Request Acknowledge message the target RNC/BSS shall be prepared to receive downlink GTP PDUs from the 3G/2G SGSN for the accepted RABs.

Each RAB to be setup is defined by a Transport Layer Address, which is the target RNC/BSS Address for user data, and the Iu Transport Association, which corresponds to the downlink Tunnel Endpoint Identifier for user data.

NOTE: The information to be included in the containers differs for UTRAN and GERAN Iu mode. For UTRAN, the information included in the container is related to RAB setup and other IE similar to those in the Handover to UTRAN message defined in 3GPP TS 25.331 [17]. For GERAN Iu mode the Radio Bearer Reconfiguration message is the RRC message to be included.

When the 3G/2G SGSN receives the Relocation Request Acknowledge message and it decides to proceed with the handover, the preparation phase is finished and the execution phase will follow.

5.2.1.2 Intra-SGSN GERAN A/Gb mode to UTRAN/GERAN Iu mode HO; Execution phase

Figure 12: PS Handover Execution Phase; Inter-RAT/mode,
Intra-SGSN case (GERAN A/Gb mode  UTRAN, GERAN Iu mode)

1. The 3G/2G SGSN continues to receive IP packets from the GGSN (via GTP) and forwards the associated PDU payload to the MS via the source BSS.

2. When receiving the Relocation Request Acknowledge message the 3G/2G SGSN may, based on QoS, start downlink N-PDU relay and duplication to the target RNC/BSS if a Tunnel Endpoint is available as follows:

– For PDP context, which uses LLC ADM, all new downlink N-PDUs received after completion of the PS handover preparation phase are relayed to the target RNC. All such N-PDUs are encapsulated in a GTP-PDU when transmitted to the target RNC/BSS.

– If the 3G/2G SGSN forwards downlink packets to the target RNC/BSS, the target RNC/BSS may start blind transmission of downlink user data towards the MS over the allocated radio channels.

3. The 3G/2G SGSN continues the PS Handover by sending a PS Handover Required Acknowledge (TLLI, List of Set Up PFCs, Target to Source Transparent Container) message to the source BSS.

Before sending the PS Handover Required Acknowledge message, the 3G/2G SGSN, based on QoS, may suspend downlink data transfer for any PDP contexts.

Before sending the PS Handover Command message to the MS the source BSS, based on QoS, may try to empty the downlink BSS buffer for any BSS PFCs.

4. The 3G/2G SGSN shall send the Forward SRNS Context (NSAPIDL GTP-U number, UL GTP-U number) message to the target RNC/BSS if there is at least one PDP context which requires "delivery order" to be preserved..NSAPI identifies the PDP context to which the GTP-U numbers apply The Forward SRNS Context message contains the sequence numbers of the GTP-PDU next to be transmitted in the uplink and downlink direction. After the Forward SRNS Context message is sent, further uplink N-PDUs received by the 3G/2G SGSN from the source BSS, relative to a PDP context which requires "delivery order" to be preserved, shall not be forwarded to the GGSN.

The GTP-U numbers are only sent by the 3G/2G SGSN for PDP context(s) requiring delivery order (QoS profile) to be preserved. If delivery order is to be preserved (QoS) profile), consecutive GTP-PDU sequence numbering shall be maintained through the lifetime of the PDP context(s).

Therefore, during the entire PS Handover procedure for the PDP context(s) using delivery order required (QoS profile), the responsible GTP-U entities (3G/2G SGSN, target RNC/BSS and GGSN) shall assign consecutive GTP-PDU sequence numbers to user packets belonging to the same PDP context uplink and downlink, respectively.

The target RNC/BSS proceed as follows:

– For RABs not requiring lossless PDCP the target RNC/BSS may, according the QoS profile of the PDP context, store the received data until it receives confirmation of MS presence in the target cell.

– The further target RNC/BSS behaviour is as specified in 3GPP TS 23.060 [19] (Combined Hard Handover and SRNS Relocation).

5. The source BSS sends the PS Handover Command message containing the Handover to UTRAN Command message (as it is specified in 3GPP TS 25.331 [17]) or Radio Bearer Reconfiguration message to the MS by interrupting the transmission of LLC PDUs on any of the downlink TBFs. Following the transmission of this signalling message the source BSS may resume LLC PDU transmission until it either has no more LLC PDUs to send or the PFC is released. Upon reception of the PS Handover Command the MS is not required to continue data reception in the source cell. Upon reception of the PS Handover Command the MS shall suspend the uplink transmission of user plane data. MS management of uplink N-PDUs following the reception of the PS Handover Command message is as follows:

– All N-PDUs associated with a PFC receiving handover treatment that have not yet been fully transmitted might be buffered depending on the QoS class.

– Subsequent uplink N-PDUs that become available for transmission following the reception of the PS Handover Command message might also be buffered depending on the QoS class.

– For real time services uplink N-PDUs may be discarded by the MS during the link interruption.

NOTE: Any buffering should be performed before the data is passed to SNDCP in order to avoid header compression on N-PDUs such that data delivery in the target cell may begin from the correct point in the sequence.

6. MS is in the target cell and performs access to UTRAN as defined in 3GPP TS 25.331 [17] and to GERAN Iu mode.

7. The target RNC/BSS sends a Relocation Detect message to the 3G/2G SGSN to indicate that the MS is in the target cell. The message shall be sent 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 the target RNC detects the MS on the lower layers. When the Relocation Detect message is sent, the target RNC shall start serving RNC operation.

8. In UTRAN, the MS sends Handover to UTRAN Complete {Message Type, UE Information elements (Start List, CN Domain Identity, Start), RB Information Elements (Count-C Activation Time)} message to the target RNC (see 3GPP TS 25.331 [17]).

In GERAN Iu, the MS sends Radio Bearer Reconfiguration Complete {RRC Transaction Identifier, Integrity Check Info, Uplink Integrity Protection Activation Info, COUNT-C Activation Time, Radio Bearer Uplink Ciphering Activation Time Info, Mobile Observed Time Difference, Uplink Counter Synchronisation Info struct, START List, CN Domain Identity, START, RB with PDCP Information List, RB with PDCP Information} message to target BSS.

9. When the new source RNC-ID + S-RNTI are successfully exchanged with the MS, the target RNC/BSS shall send the Relocation Complete message to the new SGSN. The purpose of the Relocation Complete procedure is to indicate by the target RNC/BSS the completion of the relocation of the source BSS to the CN. After the reception of the Relocation Complete message the 3G/2G SGSN shall be prepared to receive data from the target RNC/BSS.

10. If the SGSN has established Direct Tunnel, the SGSN sends an Update PDP Context Request (RNC Address, TEID, QoS Negotiated, DTI) message to the GGSN concerned. The SGSN provides to the GGSN the RNC address for the 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 defined in 3GPP TS 23.060 [19]. The GGSN updates the PDP context fields and returns an Update PDP Context Response (TEID) message. From now on the GGSN sends new incoming downlink IP packets to the target RNC instead of the SGSN.

11. The 3G/2G SGSN shall initiate PFC Management procedures towards the source cell in order to trigger the release of resources in the source cell.

12. The MS sends a Routing Area Update Request (Old RAI, Old P-TMSI signature, Update Type) message to the 3G/2G SGSN. This is done even if the target cell belongs to the same routing area as the source cell. The MS shall send this message immediately after message 8. The 3G/2G SGSN knows that a handover has been performed for this MS and can therefore exclude the SGSN context procedures which normally are used within the RA Update procedure.

13. The 3G/2G SGSN validates the MS presence in the new RA. If the MS is allowed to be attached in this RA, the 3G/2G SGSN updates the MM context for and sends a Routing Area Update Accept message to the MS.

14. The MS may respond to the SGSN with a Routing Area Update Complete message.

The following CAMEL procedure calls shall be performed (see referenced procedures in TS 23.078 [8b]):

C2) CAMEL_GPRS_Routeing_Area_Update_Session and CAMEL_PS_Notification.

They are called in the following order:

– The CAMEL_GPRS_Routeing_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_Routeing_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 in 3GPP TS 23.060.

5.2.2 Inter SGSN

5.2.2.1 Inter-SGSN GERAN A/Gb mode to UTRAN/GERAN Iu mode HO; Preparation phase

Figure 13: PS Handover Preparation Phase; Inter-RAT/mode,
Inter-SGSN case (GERAN A/Gb mode  UTRAN, GERAN Iu mode)

1. The source BSS decides to initiate a PS handover. At this point both uplink and downlink user data is transmitted via the following: TBFs between MS and source BSS, BSSGP PFCs tunnel(s) between source BSS and old SGSN, GTP tunnel(s) between old SGSN and GGSN.

2. The source BSS sends a PS Handover Required (TLLI, Cause, Source Cell Identifier, Target RNC Identifier, Source to Target Transparent Container, Active PFCs List) message to the old SGSN.

If PS handover to a UTRAN CSG or Hybrid cell is required, the source BSS includes in addition to Target RNC Identifer also the CSG Identifier in the PS Handover Required message to the SGSN. In case of PS handover to an UTRAN CSG cell the source BSS sets the Cell Access Mode field to "CSG Cell" in the CSG Identifier. In case of PS handover to an UTRAN hybrid cell the source BSS sets the Cell Access Mode field to "Hybrid Cell" in the CSG Identifier.

Upon reception of the PS Handover Required message containing a CSG Identifier with the Cell Access Mode field set to "CSG cell", the old SGSN performs the access control according to the CSG Subscription List of that MS. If the MS is allowed to access the target cell, the old SGSN continues the PS handover to the target side. If the MS is not allowed to access the target cell, the old SGSN sends the PS Handover Required Negative Acknowledge message with an appropriate cause value indicating invalid CSG cell to the source BSS. If the PS Handover Required message contains a CSG Identifier with the Cell Access Mode field set to "Hybrid Cell", the old SGSN provides the membership status of the MS and the CSG Id to the target side (see 3GPP TS 25.413).

3. The old SGSN determines from the Target RNC Identifier that the type of handover is inter-RAT/mode handover. In case of inter-SGSN inter-RAT/mode PS handover the old SGSN initiates the relocation resource allocation procedure by sending a Forward Relocation Request (IMSI, Target Identification, MM Context, PDP Context, PDP Context Prioritisation, Tunnel Endpoint Identifier Control Plane, SGSN Address for Control plane, Source to Target Transparent Container in the UTRAN Transparent Container, RANAP Cause, Packet Flow ID, SNDCP XID parameters, LLC XID parameters, GCSI) message to the new SGSN.

The old SGSN sends all active PDP Contexts to the new SGSN indicating the PFIs and the XID parameters related to those PDP Contexts. Each PDP context contains the GGSN Address for the 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 contains security related information, e.g. supported ciphering algorithms as described in 3GPP TS 29.060 [11]. The relation between GSM and UMTS security parameters is defined in 3GPP TS 33.102 [27]. Optionally the old SGSN sets the GCSI flag if the MM context contains GPRS CAMEL Subscription Information.

NOTE 1: For relocation to an area where Intra Domain Connection of RAN Nodes to Multiple CN Nodes is used, the old SGSN may – if it provides Intra Domain Connection of RAN Nodes to Multiple CN Nodes -have multiple new SGSNs for each handover target in a pool area, in which case the old SGSN will select one of them to become the new SGSN, as specified in 3GPP TS 23.236 [22].

Upon receipt of the message, the new SGSN establishes all MM and PDP contexts and initiates the RAB setup procedures for all PDP contexts received.

4. The new SGSN sends a Relocation Request (Permanent NAS Identity, Cause, CN Domain Indicator, Integrity protection information (i.e. IK and allowed Integrity Protection algorithms), Encryption information (i.e. CK and allowed Ciphering algorithms), RABs to be setup list, Source to Target Transparent Container, Iu Signalling connection identifier, Global CN-ID, SNA Access Information, UESBI-Iu) message to the target RNC/BSS.

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 new SGSN shall not request resources for RABs associated with PDP contexts with a 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 PFC exists on the source side. 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 SGSN may decide to establish a 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 Address for User Plane and TEID for Uplink data.

In the target RNC/BSS radio and Iu user plane resources are reserved for the accepted RABs.

In case of PS handover to a CSG cell, the 3G SGSN includes also the CSG ID in the Relocation Request message to the target RNC.

In case of PS handover to a Hybrid cell, the 3G SGSN includes also the CSG ID and CSG Membership Status in the Relocation Request message to the target RNC. The target RNC may use the CSG Membership Status to perform differentiated treatment for CSG and non-CSG members (see 3GPP TS 25.413).

5. The target RNC/BSS sends the Relocation Request Acknowledge (Source to Target Transparent Container, RABs setup list, RABS failed to setup list) message to the new SGSN. Upon sending the Relocation Request Acknowledge message the target RNC/BSS shall be prepared to receive downlink GTP PDUs from the new SGSN for the accepted RABs.

NOTE 2: The information to be included in the containers differs for UTRAN and GERAN Iu mode. For UTRAN, the information included in the container is related to RAB setup and other IE similar to those in the Handover to UTRAN message defined in 3GPP TS 25.331 [17]. For GERAN Iu mode the Radio Bearer Reconfiguration message is the RRC message to be included.

6. When resources for the transmission of user data between target RNC/BSS and new SGSN have been allocated and the new SGSN is ready for the PS handover, the Forward Relocation Response (Cause, List of Set Up PFCs, Tunnel Endpoint Identifier Control Plane, SGSN Address for User Traffic, Tunnel Endpoint Identifier Data II, RANAP cause, SGSN Address for control plane, Source to Target Transparent Container in the UTRAN Transparent Container) message is sent from the new SGSN to the old SGSN. RAN Transparent Container and RANAP Cause contain information from the target RNC/BSS to be forwarded to the source BSS.

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 old SGSN, via the new SGSN, to the target RNC.

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.

5.2.2.2 Inter-SGSN GERAN A/Gb mode to UTRAN/GERAN Iu mode HO; Execution phase

Figure 14: PS Handover Execution Phase; Inter-RAT/mode,
Inter-SGSN case (GERAN A/Gb mode  UTRAN/GERAN Iu mode)

1. The old SGSN continues to receive IP packets from the GGSN (via GTP) and forwards the associated PDU payload to the MS via the source BSS.

2. When receiving the Forward Relocation Response message the old SGSN may, based on QoS, start downlink N-PDU relay and duplication to the target RNC/BSS via the new SGSN (if a Tunnel Endpoint is available) as follows:

– For PDP context, which uses LLC ADM in the old SGSN all new downlink N-PDUs received after completion of the PS handover preparation phase are relayed to the target RNC/BSS via the new SGSN. All such N-PDUs are encapsulated in a GTP-PDU when transmitted to the new SGSN.

– If the old SGSN forwards downlink packets to the target RNC/BSS via the new SGSN, the target RNC/BSS may start blind transmission of downlink user data towards the MS over the allocated radio channels.

NOTE 1: The order of steps, starting from step 2 onwards, does not necessarily reflect the order of events. For instance the old SGSN may start data forwarding (step 2), send the PS Handover Required Acknowledge message (step 4) and send the Forward SRNS context message (step 4a) almost simultaneously.

3. Void

4. The old SGSN continues the PS Handover by sending a PS Handover Required Acknowledge (TLLI, List of Set Up PFCs, Source to Target Transparent Container) message to the source BSS.

Before sending the PS Handover Required Acknowledge message, the old SGSN, based on QoS, may suspend downlink data transfer for any PDP contexts.

Before sending the PS Handover Command message to the MS the source BSS, based on QoS, may try to empty the downlink BSS buffer for any BSS PFCs.

4a. The old SGSN shall send the Forward SRNS Context message (NSAPI, DL GTP-U number, UL GTP-U number) to the new SGSN if there is at least one PDP context which requires "delivery order" to be preserved.NSAPI identifies the PDP context to which the GTP-U numbers apply. The Forward SRNS Context message is then acknowledged by the Forward SRNS Context Acknowledge message. The Forward SRNS Context message contains the sequence numbers of the GTP-PDU next to be transmitted in the uplink and downlink direction. After the Forward SRNS Context message is sent, further uplink N-PDUs received by the old SGSN from the source BSS, relative to a PDP context which requires "delivery order" to be preserved, shall not be forwarded to the GGSN.

The GTP-U numbers are only sent by the old SGSN for PDP context(s) requiring delivery order (QoS profile) to be preserved. If delivery order is to be preserved (QoS) profile), consecutive GTP-PDU sequence numbering shall be maintained through the lifetime of the PDP context(s).

Therefore, during the entire PS Handover procedure for the PDP context(s) using delivery order required (QoS profile), the responsible GTP-U entities (old SGSN, target RNC and GGSN) shall assign consecutive GTP‑PDU sequence numbers to user packets belonging to the same PDP context uplink and downlink, respectively.

The target RNC proceed as follows:

– For RABs not requiring lossless PDCP the target RNC may, according the QoS profile of the PDP context, store the received data until it receives confirmation of MS presence in the target cell.

– The further target RNC/BSS behaviour is as specified in 3GPP TS 23.060 [19] (Combined Hard Handover and SRNS Relocation).

5. The source BSS sends the PS Handover Command message containing the Handover to UTRAN Command message (as specified in 3GPP TS 25.331 [17]) or Radio Bearer Reconfiguration message to the MS by interrupting the transmission of LLC PDUs on any of the downlink TBFs. Following the transmission of this signalling message the source BSS may resume LLC PDU transmission until it either has no more LLC PDUs to send or the PFC is released. Upon reception of the PS Handover Command message the MS is not required to continue data reception in the source cell. Upon reception of the PS Handover Command message the MS shall suspend the uplink transmission of user plane data. MS management of uplink N-PDUs following the reception of the PS Handover Command message is as follows:

– All N-PDUs associated with a PFC receiving handover treatment that have not yet been fully transmitted might be buffered depending on the QoS class.

– Subsequent uplink N-PDUs that become available for transmission following the reception of the PS Handover Command message might also be buffered depending on the QoS class.

– For real time services uplink N-PDUs may be discarded by the MS during the link interruption.

NOTE 2: Any buffering should be performed before the data is passed to SNDCP in order to avoid header compression on N-PDUs such that data delivery in the target cell may begin from the correct point in the sequence.

6. MS is in the target cell and performs access to UTRAN as defined in 3GPP TS 25.331 [17] and to GERAN Iu mode.

7. Target RNC/BSS sends a Relocation Detect message to the new SGSN to indicate that the MS is in the target cell. The message shall be sent 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 the target RNC detects the MS on the lower layers. When the Relocation Detect message is sent, the target RNC shall start serving RNC operation.

8. In UTRAN, MS sends Handover to UTRAN Complete {Message Type, UE Information elements (Start List, CN Domain Identity, Start), RB Information Elements (Count-C Activation Time)} message to the target RNC (see 3GPP TS 25.331 [17]).

In GERAN Iu, MS sends Radio Bearer Reconfiguration Complete {RRC Transaction Identifier, Integrity Check Info, Uplink Integrity Protection Activation Info, COUNT-C Activation Time, Radio Bearer Uplink Ciphering Activation Time Info, Mobile Observed Time Difference, Uplink Counter Synchronisation Info struct, START List, CN Domain Identity, START, RB with PDCP Information List, RB with PDCP Information} message to target BSS.

9. When the new source RNC-ID + S-RNTI are successfully exchanged with the MS, the target RNC/BSS shall send the Relocation Complete message to the new SGSN. The purpose of the Relocation Complete procedure is to indicate by the target RNC/BSS the completion of the relocation of the source BSS to the CN. After the reception of the Relocation Complete message the new SGSN shall be prepared to receive data from the target RNC/BSS. Each uplink N-PDU received by the new SGSN is forwarded directly to the GGSN.

10. For inter-SGSN PS handover, the new SGSN sends a Forward Relocation Complete message to the old SGSN to indicate the success of the handover procedure. The old SGSN acknowledges this with a Forward Relocation Complete Acknowledge message. Upon the reception of the Forward Relocation Complete message the old SGSN starts a packet forwarding timer. The old SGSN stops forwarding of data to the new SGSN after the packet forwarding timer expires.

11. The new SGSN sends an Update PDP Context Request (new SGSN Address, TEID, QoS Negotiated) message to the GGSN concerned. If a Direct Tunnel is established the SGSN provides to the GGSN instead of the new SGSN Address and TEID, the RNC 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 defined in 3GPP TS 23.060 [19]. The GGSN updates the PDP context fields and returns an Update PDP Context Response (TEID) message. From now on the GGSN sends new incoming downlink IP packets to the new SGSN instead of to the old SGSN.

12. The old SGSN shall initiate PFC Management procedures towards the source cell in order to trigger the release of resources in the source cell.

13. The MS sends a Routing Area Update Request (Old RAI, Old P-TMSI signature, Update Type) message to the new SGSN informing it that the target cell belongs to a new routing area. The MS shall send this message immediately after message 7. The new SGSN knows that a handover has been performed for this MS and can therefore exclude the SGSN context procedures which normally are used within the RA Update procedure.

14. At this point the new SGSN may optionally invoke MS authentication (security function). The security function can be deferred and performed at any later time as well.

NOTE 3: During an authentication procedure the SGSN has to suspend the downlink transmission of user data.

15. The new SGSN informs the HLR of the change of SGSN by sending Update Location (SGSN Number, SGSN Address, IMSI) message to the HLR.

16. The HLR sends Cancel Location (IMSI, Cancellation Type) message to the old SGSN with Cancellation Type set to Update Procedure.

17. The old SGSN acknowledges with a Cancel Location Acknowledge (IMSI) message. This message allows the old SGSN to know when to release the inter-SGSN tunnel.

18. The HLR sends Insert Subscriber Data (IMSI, GPRS subscription data) message to the new SGSN. The new SGSN validates the MS presence in the (new) RA.

19. If all checks are successful then the new SGSN constructs an MM context for the MS and returns an Insert Subscriber Data Acknowledge (IMSI) message to the HLR. This message allows the new SGSN to know when to release the inter-SGSN tunnel.

20. The HLR acknowledges the Update Location by sending an Update Location Acknowledge (IMSI) message to the new SGSN.

21. The new SGSN validates the MS presence in the new RA. If the MS is allowed to be attached in this RA, the SGSN updates the MM context for and sends a Routing Area Update Accept message to the MS.

22. The MS may respond to the SGSN with a Routing Area Update Complete message.

The following CAMEL procedure calls shall be performed (see referenced procedures in TS 23.078 [8b])

C1) CAMEL_GPRS_PDP_Context_Disconnection, CAMEL_GPRS_Detach and CAMEL_PS_Notification.

They are called in the following order:

– The CAMEL_GPRS_PDP_Context_Disconnection procedure is called several times: once per PDP context. The procedure returns as result "Continue".

– Then the CAMEL_GPRS_Detach procedure is called once. The procedure returns as result "Continue".

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

C2) CAMEL_GPRS_Routeing_Area_Update_Session and CAMEL_PS_Notification.

They are called in the following order:

– The CAMEL_GPRS_Routeing_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_Routeing_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 in 3GPP TS 23.060.