5.3 Inter-RAT/mode Handover (UTRAN/GERAN Iu mode  GERAN A/Gb mode)

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

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

5.3.1 Intra SGSN

5.3.1.1 Inter RAT/mode UTRAN/GERAN Iu mode to GERAN A/Gb mode PS HO; Preparation phase

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

1. Based on measurement results and knowledge of the RAN topology, the source RNC/BSS decides to initiate an inter RAT/mode PS handover towards the GERAN A/Gb mode. At this point both uplink and downlink user data flows via the tunnel(s): Radio Bearer between the MS and the source RNC/BSS; GTP-U tunnel(s) between the source RNC/BSS and the 3G/2G SGSN; GTP-U tunnel(s) between the 3G/2G SGSN and the GGSN.

NOTE 1: The process leading to the handover decision is outside of the scope of this paper.

2. The source RNC/BSS sends a Relocation Required (Relocation Type, Cause, Source ID, Target ID, Source BSS To Target BSS Transparent Container (RN part)) message to the 3G/2G SGSN. The source RNC/BSS shall set Relocation Type to "UE Involved in relocation of SRNS".

Target ID contains the identity of the target cell.

3. The 3G/2G SGSN determines from the Target Cell Identifier that the type of handover is inter‑RAT/mode handover. The 3G/2G 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 3G/2G SGSN shall only request resources for PFCs for which, based on source side information, resources should be allocated in the target cell during the PS Handover preparation phase.

If the 3G/2G SGSN has negotiated XID parameters with the MS when the MS was in A/Gb mode before, or if the 3G/2G SGSN can accept all XID parameters as indicated by the old SGSN during a previous inter-SGSN PS handover, the 3G/2G SGSN shall create a NAS container for PS HO indicating ‘Reset to the old XID parameters’. Otherwise the 3G/2G SGSN shall create a NAS container for PS HO indicating Reset (i.e. reset to default parameters).

4. 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 can be accommodated by the target BSS.

After allocating radio resources the target BSS shall prepare the Target BSS to Source BSS Transparent Container for the set up BSS PFCs.

5. 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).

6. The 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 3G/2G SGSN. Upon sending the PS Handover Request Acknowledge message the target BSS shall be prepared to receive downlink LLC PDUs from the 3G/2G SGSN for the accepted PFCs.

Any PDP contexts for which a PFC was not established are maintained in the 3G/2G SGSN and the related SAPIs and PFIs are kept. These PDP contexts may be modified or deactivated by the 3G/2G SGSN via explicit SM procedures upon the completion of the routing area update (RAU) procedure.

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

5.3.1.2 Inter RAT/mode UTRAN/GERAN Iu mode to GERAN A/Gb mode PS HO; Execution phase

Figure 16: PS Handover Execution Phase; Inter-RAT/mode,
Intra-SGSN case (UTRAN/GERAN Iu mode  GERAN A/Gb 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 RNC/BSS. In case of Direct Tunnel, the GGSN sends IP packets directly to the source RNC.

2. The 3G/2G SGSN continues the PS handover by sending a Relocation Command (Target BSS to Source BSS Transparent Container (PS Handover Command with RN part and CN part), RABs to be Released List, RABs Subject to Data Forwarding List) message to the source RNC/BSS. "RABs to be released list" will be the list of all NSAPIs (RAB Ids) for which a PFC was not established "RABs Subject to Data forwarding list" will be the list of all NSAPIs (RAB Ids) for which a PFC was established.

3. When receiving the Relocation Command message the source RNC may, based on QoS, begin the forwarding of data for the RABs subject to data forwarding to the 3G/2G SGSN according to the definition in 3GPP TS 23.060 [19]. The GTP-U sequence numbers are only sent by the source RNC 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).

The 3G/2G SGSN may, based on QoS, proceed with the packet handling as follows:

– For PDP contexts which use LLC ADM the 3G/2G SGSN either:

a. forwards the received downlink N-PDUs to the target BSS;

b. stores the received data into the SNDCP queue for e.g. the PDU lifetime;

c. discards the received data until e.g. reception of the PS Handover Complete message.

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

4. The RNC/BSS sends the Handover from UTRAN Command message (UTRAN) or the Handover from GERAN Iu Command message to the MS where each message includes a PS Handover Command (RN part and CN part) message. Before sending the message the uplink and downlink data transfer shall be suspended in the source RNC for the RABs that require delivery order.

Upon reception of the Handover from UTRAN Command message (UTRAN) or the Handover from GERAN Iu Command the MS shall suspend the uplink transmission of user plane data.

5. The source RNC/BSS continues the handover by sending a Forward SRNS Context (RAB contexts) message to the 3G/2G SGSN.

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

6. The MS executes the handover according to the parameters provided in the message delivered in step 4. The procedure is the same as in step 6 in subclause 5.1.4.2.

7./7a. After accessing the cell using access bursts and receiving timing advance information from the BSS in step 6, the MS processes the NAS container and then sends one XID Response message to the 3G/2G SGSN The MS 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 (see Section 6.2).

The MS 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 MS may request for radio resources using the legacy procedures.

NOTE: If the 3G/2G SGSN indicated Reset (i.e. reset to default parameters) in the NAS container for PS HO included in the Handover from UTRAN Command message (UTRAN) or the Handover from GERAN Iu Command message, in order 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 bullet 9). 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 bullet 10).

8. Upon reception of the first correct RLC/MAC block (sent in normal burst format) from the MS the target BSS sends a PS Handover Complete (Local TLLI, IMSI, Request for Inter RAT Handover Info) message to inform the 3G/2G SGSN that the MS has arrived in the target cell. Each uplink N-PDU received by the 3G/2G SGSN via the target BSS is then forwarded directly to the GGSN. The target BSS shall request the INTER RAT HANDOVER INFO from the SGSN by setting the "Request for INTER RAT HANDOVER INFO" to "1".

9. If a Direct Tunnel was established for Iu mode, the SGSN sends an Update PDP Context Request (new SGSN Address, TEID, QoS Negotiated) message to the GGSN with the indication for not re-negotiating the QoS and to establish a tunnel between the SGSN and the GGSN. The GGSN updates the PDP context and returns an Update PDP Context Response (TEID) message. From now on the GGSN sends new incoming downlink IP packets to the SGSN.

10. If the 3G/2G SGSN indicated Reset (i.e. reset to default parameters) in the NAS container for PS HO included in the Handover from UTRAN Command message (UTRAN) or the Handover from GERAN Iu Command message, then on receipt of the PS Handover Complete message the SGSN initiates an LLC/SNDCP XID negotiation for each LLC SAPI used in LLC ADM. In this case if the SGSN wants to use the default parameters, it shall send an empty XID Command. If the SGSN indicated ‘Reset to the old XID parameters’ in the NAS container for PS HO, no further XID negotiation is required for LLC SAPIs used in LLC ADM only.

11. The 3G/2G SGSN (re-)establishes LLC ABM for the PDP contexts which use acknowledged information transfer. During the exchange of SABM and UA the SGSN shall perform LLC/SNDCP XID negotiation.

12. After the reception of the PS Handover Complete message the 3G/2G SGSN sends an Iu Release Command message to the source RNC/BSS commanding the source RNC/BSS to release all resources related to the Iu connection. When the RNC/BSS data forwarding timer has expired the source RNC/BSS responds with an Iu Release Complete (RAB Data Volume report list, RABs released list) message.

13. The MS sends a Routing Area Update Request (Old P-TMSI, 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 7, see 3GPP TS 23.060 [19].

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.

14. 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 (P-TMSI, TMSI, P‑TMSI signature, Receive N-PDU number) message to the MS. The Receive N‑PDU Number contains the acknowledgements for each acknowledged-mode NSAPI used by the 3G/2G SGSN, thereby confirming all mobile originated N‑PDUs successfully transferred before the start of the PS handover procedure.

15. The MS confirms the re-allocation of the new P-TMSI by responding to the 3G/2G SGSN with a Routing Area Update Complete (Receive N-PDU number). The MS derives the TLLI from the new P-TMSI using the current MM procedures. The Receive N‑PDU Number contains the acknowledgements for each acknowledged mode NSAPI used by the MS, thereby confirming all mobile terminated N‑PDUs successfully transferred before the start of the handover procedure. If Receive N‑PDU Number confirms reception of N‑PDUs that were forwarded from the 3G/2G SGSN, these N‑PDUs shall be discarded by the 3G/2G SGSN.

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.

16. Upon reception of the PS Handover Complete message with the "Request for Inter RAT Handover Info" set to "1" for UTRAN, the SGSN shall send PS Handover Complete Acknowledge (TLLI, Inter RAT Handover Info) message to the target BSS.

17. 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, discard the INTER RAT HANDOVER INFO received from the source RNC during the preparation phase.

5.3.2 Inter SGSN

5.3.2.1 Inter RAT/mode UTRAN/GERAN Iu mode to GERAN A/Gb mode PS HO; Preparation phase

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

1. Based on measurement results and knowledge of the RAN topology, the source RNC/BSS decides to initiate an inter RAT/mode PS handover towards the GERAN A/Gb mode. At this point both uplink and downlink user data flows via the tunnel(s): Radio Bearer between the MS and the source RNC/BSS; GTP-U tunnel(s) between the source RNC/BSS and the old SGSN; GTP-U tunnel(s) between the old SGSN and the GGSN.

NOTE 1: The process leading to the handover decision is outside of the scope of this paper.

2. The source RNC/BSS sends a Relocation Required (Relocation Type, Cause, Source ID, Target ID, Source BSS To Target BSS Transparent Container (RN part)) message to the old SGSN. The source RNC/BSS shall set Relocation Type to "UE Involved in relocation of SRNS".

Target ID contains the identity of the target cell.

3. The old SGSN determines from the Target Cell Identifier that the type of handover is inter-RAT/mode handover. In 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 subclause 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 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],

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 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).

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

The new SGSN activates the allocated LLC/SNDCP engines as specified in 3GPP TS 44.064 [21] 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.

5.3.2.2 Inter RAT UTRAN/GERAN Iu mode to GERAN A/Gb mode PS HO; Execution phase

Figure 18: PS Handover Execution Phase; Inter-RAT/mode,
Inter-SGSN case (UTRAN/GERAN Iu mode  GERAN A/Gb 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 RNC/BSS.

2. The old SGSN continues the PS handover by sending a Relocation Command (Target BSS to Source BSS Transparent Container (PS Handover Command with RN part and CN part), RABs to be Released List, RABs Subject to Data Forwarding List) message to the source RNC/BSS. "RABs to be released list" will be the list of all NSAPIs (RAB Ids) for which a PFC was not established "RABs Subject to Data forwarding list" will be the list of all NSAPIs (RAB Ids) for which a PFC was established.

3. When receiving the Relocation Command message the source RNC/BSS may, based on QoS, begin the forwarding of data for the RABs subject to data forwarding to the new SGSN via the old SGSN (if a Tunnel Endpoint is available) according to the definition in 3GPP TS 23.060 [19]. The GTP-U sequence numbers are only sent by the source RNC 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).

The new SGSN may, based on QoS, proceed with the packet handling as follows:

– For PDP contexts which use LLC ADM the new SGSN either:

a. forwards the received downlink N-PDUs to the target BSS;

b. stores the received data into the SNDCP queue for e.g. the PDU lifetime;

c. discards the received data until e.g. reception of the PS Handover Complete message.

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

NOTE 1: The order of steps, starting from step 3 onwards, does not necessarily reflect the order of events. For instance the source RNC may start data forwarding (step 3), send the RRC message (step 4) and send the Forward SRNS Context message (step 5) almost simultaneously.

4. The source RNC/BSS sends the Handover from UTRAN Command message (UTRAN) or the Handover from GERAN Iu Command message to the MS where each message includes a PS Handover Command (RN part and CN part). Before sending the message the uplink and downlink data transfer shall be suspended in the source RNC for the RABs that require delivery order.

Upon the reception of the HANDOVER from UTRAN Command message (UTRAN) or the HANDOVER from GERAN Iu Command message containing the PS Handover Command message, the MS shall associate its RAB IDs to the respective PFIs based on the relation with the NSAPI and shall suspend the uplink transmission of the user plane data.

5. The source RNC continues the handover by sending a Forward SRNS Context (RAB contexts) message to the new SGSN, via the old SGSN. The Forward SRNS Context message is acknowledged by the new SGSN with the Forward SRNS Context Acknowledge message to the old SGSN.

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

6. The MS executes the handover according to the parameters provided in the message delivered in step 4. The procedure is the same as in step 6 in subclause 5.1.4.2 with the additional function of association of the received PFI and existing RAB Id related to the particular NSAPI as described in clause 4.4.1.

7./7a. After accessing the cell using access bursts and receiving timing advance information from the BSS in step 6, the MS processes the NAS container and then sends one XID Response message to the new SGSN . The MS 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 (see Section 6.2).

Upon sending the XID Response message, the MS 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 MS may request for radio resources using the legacy procedures.

NOTE 2: If the new SGSN indicated Reset (i.e. reset to default parameters) in the NAS container for PS HO included in the the Handover from UTRAN Command message (UTRAN) or the Handover from GERAN Iu Command message, in order 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 bullet 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 bullet 12a).

8. Upon reception of the first correct RLC/MAC block (sent in normal burst format) from the MS the target BSS sends a PS Handover Complete (Local TLLI, Handover Complete Status, Request for Inter RAT Handover Info) message to inform the new SGSN that the MS has arrived in the target cell. Each uplink N-PDU received by the new SGSN via the target BSS is then forwarded directly to the GGSN. The target BSS shall request the INTER RAT HANDOVER INFO from the SGSN by setting the ‘Request for Inter RAT Handover Info’ to ‘1’.

9. Upon receiving the PS Handover Complete message, the new SGSN send a Forward Relocation Complete message to the old SGSN to indicate completion of the PS handover procedures. The old SGSN responds with a Forward Relocation Complete Acknowledge message.

10. The new SGSN sends an Update PDP Context Request (new SGSN Address, TEID, QoS Negotiated) message to the GGSN concerned. 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.

11. The old SGSN sends an Iu Release Command message to the source RNC/BSS commanding the source RNC/BSS to release all resources related to the Iu connection. When the RNC/BSS data forwarding timer has expired the source RNC/BSS responds with an Iu Release Complete (RAB Data Volume report list, RABs released list) message.

12. If the new SGSN indicated Reset (i.e. reset to default parameters) in the NAS container for PS HO included in the Handover from UTRAN Command message (UTRAN) or the Handover from GERAN Iu Command message, then on receipt of the PS Handover Complete the new SGSN initiates an LLC/SNDCP XID negotiation for each LLC SAPI used in LLC ADM. In this case if the SGSN wants to use the default parameters, it shall send an empty XID Command. If the new SGSN indicated ‘Reset to the old XID parameters’ in the NAS container for PS HO, no further XID negotiation is required for LLC SAPIs used in LLC ADM only.

12a. The new SGSN (re-)establishes LLC ABM for the PDP contexts which use acknowledged information transfer. During the exchange of SABM and UA the SGSN shall perform LLC/SNDCP XID negotiation.

13. The MS sends a Routing Area Update Request (Old P-TMSI, Old RAI, Old P-TMSI signature, Update Type) message to the new SGSN informing it that the source cell belongs to a new routing area. The MS shall send this message immediately after message 7, see 3GPP TS 23.060 [19].

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 a Cancel Location (IMSI, Cancellation Type) message to the old SGSN with Cancellation Type set to Update Procedure. 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.

17. 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. 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.

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

19. 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 (P-TMSI, TMSI, P-TMSI signature, Receive N-PDU number) message to the MS. The Receive N‑PDU Number contains the acknowledgements for each acknowledged-mode NSAPI used by the SGSN, thereby confirming all mobile originated N‑PDUs successfully transferred before the start of the PS handover procedure.

20. The MS confirms the re-allocation of the new P-TMSI by responding to the SGSN with a Routing Area Update Complete (Receive N-PDU number) message. The MS derives the Local TLLI from the new P-TMSI using the current MM procedures. The Receive N‑PDU Number contains the acknowledgements for each acknowledged mode NSAPI used by the MS, thereby confirming all mobile terminated N‑PDUs successfully transferred before the start of the handover procedure. If Receive N‑PDU Number confirms reception of N‑PDUs that were forwarded from the old SGSN, these N‑PDUs shall be discarded by the new SGSN.

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.

21. Upon reception of the PS Handover Complete message with the "Request for Inter RAT Handover Info" set to "1" for UTRAN, the SGSN shall send PS Handover Complete Acknowledge (TLLI, Inter RAT Handover Info) message to the target BSS.

22. 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, discard the INTER RAT HANDOVER INFO received from the source RNC during the preparation phase.