5.1 GERAN (A/Gb mode)  GERAN (A/Gb mode) handover

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

5.1.1 Intra Cell

Intra Cell PS Handover will be needed in cases when a new channel is selected in the same cell to be used by the MS. This is handled by the BSS internally and if there are no changes in the new channel there is no need for BSS to notify the SGSN about the change of channel.

BSS/SGSN signalling will be needed in case the new channel has limited resources and cannot support the same QoS, for the BSS PFC as the old channel.

For these purpose existing modification procedures on the Um and Gb interface are used, e.g. PACKET TIMESLOT RECONFIGURE (3GPP TS 44.060 [7]) on the air interface and MODIFY BSS PFC (3GPP TS 48.018 [10]) procedure on the Gb interface.

If the modification procedures fail BSS may cancel the intra cell PS handover procedure.

5.1.2 Intra BSS

5.1.2.1 General

This clause is further split into two clauses. The first describes an intra-BSS handover procedure based largely on the inter-BSS handover procedure. The second section describes an optional optimised intra-BSS handover procedure. When the source and target cells are within the same BSS the handover can be either executed by the BSS itself (optimised handover) or by involving the SGSN in the preparation phase. In the latter case although handover is performed within one BSS the roles of source BSS and target BSS are the same as in Inter BSS Handover.

5.1.2.2 Intra BSS HO; Preparation phase

Figure 4: PS Handover Preparation Phase; Intra-BSS case (GERAN A/Gb mode  GERAN A/Gb mode)

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

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

3. The SGSN determines from the Target Cell Identifier the type of handover, i.e. intra-SGSN, inter-SGSN or inter-RAT/mode handover and whether the routing area has changed. In case of no change of routing area, the SGSN sends a PS Handover Request (TLLI, Cause, IMSI, Source Cell Identifier, Target Cell Identifier, PFCs To Be Set Up List, Source BSS to Target BSS Transparent Container (RN part)) message to the BSS. In case when the routing area changes the SGSN allocates a new P-TMSI for this MS and derives a local TLLI from this P-TMSI prior to the sending of the PS Handover Request message. The SGSN shall only request resources for PFCs that are included in the Active PFCs List.

NOTE: The BSS PFCs required to be set up are downloaded to the target BSS from the SGSN, i.e. all information required for PFC creation.

4. Based upon the ABQP for each PFC the 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 BSS allocates TBFs for each PFC that can be accommodated.

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 BSS shall send the PS Handover Request Acknowledge (TLLI, List of Set Up PFCs, Target BSS to Source BSS Transparent Container (PS Handover Command with RN part)) message to the SGSN. Upon sending the PS Handover Request Acknowledge message the BSS shall be prepared to receive downlink LLC PDUs directed to the new cell and associated with the accepted PFCs.

When the 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.1.2.3 Intra BSS HO; Execution phase

Figure 5: PS Handover Execution Phase; Intra-BSS case (GERAN A/Gb mode  GERAN A/Gb mode)

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

When receiving the PS Handover Request Acknowledge message the SGSN may, based on QoS, start duplication of LLC PDUs and forward those to the new cell in the BSS. If the SGSN forwards downlink packets to the new cell in the BSS, the BSS may start blind transmission of downlink user data towards the MS over the allocated radio channels.

2. The SGSN continues the PS Handover by sending a PS Handover Required Acknowledge (Old TLLI, List of Set Up PFCs, Target BSS to Source BSS Transparent Container (PS Handover Command with RN part)) message to the BSS.

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

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

NOTE 1: Only PFI(s) for PFCs accepted by the target cell are included in the message.

3. The BSS sends the PS Handover Command (RN part) 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 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. 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 uplink packets associated with a PFC receiving handover treatment that have not yet been fully transmitted might be buffered depending on the QoS class.

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

– The MS may discard uplink packets during the link interruption to preserve the real-time properties.

4. The MS tunes to the radio channel and the timeslot allocated in the target cell by the BSS and may send the PS Handover Access (Handover Reference) message in the form of four handover access bursts to the BSS on the allocated channel. The PS Handover Command message indicates whether or not the MS shall send PS Handover Access messages.

5. The BSS sends a Packet Physical information message to the MS containing update of the timing advance for the MS to synchronize.

NOTE 2: In the case of pre-synchronised handover the MS may receive the timing advance information to use in uplink in the target cell in the PS Handover Command message (if no timing advance information is included, the mobile station uses a default timing advance in the target cell). In a pre-synchronised or synchronised handover, the Packet Physical information message is not sent in the target cell.

6. The MS sends uplink LLC PDUs, e.g. a Routing Area Update Request message or uplink user data packets to the SGSN immediately after receiving the Packet Physical Information message or, in a synchronised or pre-synchronised handover, 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 radio resources are 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 radio resources using the legacy procedures.

7. Upon reception of the first correct RLC/MAC block (sent in normal burst format) from the MS the BSS sends a PS Handover Complete (TLLI, IMSI) message to inform the SGSN that the MS has arrived in the target cell. After the reception of the PS Handover Complete message the SGSN shall initiate the BSS PFC procedures to delete the BSS PFC in the BSS controlling the source cell and shall be prepared to receive data from the new cell. The source BSS initiates the release of the radio resources in the source cell after receiving the DELETE-BSS-PFC PDU from the SGSN.

If Routing Area Update occurs after completion of the execution phase, then the CAMEL procedure calls shall be performed according to 3GPP TS 23.060.

5.1.2.4 Intra BSS Handover – Optimised

This clause describes the optimised intra-BSS PS handover procedures applicable for the case where the source and target cells are associated with the same Network Service Entity (NSE) and the same Routing Area (RA). The optimisation involves the BSS providing the data forwarding function and does not require any explicit signalling with the SGSN except the sending of PS Handover Complete at the end of PS Handover. Support for this procedure is optional for the BSS.

Supporting this procedure requires that the BSS be able to determine whether or not it manages PS resources for the target cell, whether or not the target cell is associated with the same NSE, that it can internally forward LLC PDUs from the source to the target cell and whether or not both cells are part of the same RA (i.e. the SGSN is not required to make this determination and relay this information). If the BSS cannot make these determinations it shall use the non-optimised intra-BSS PS handover procedures described in clauses 5.1.2.2 and 5.1.2.3.

Figure 6: Optimised Intra-BSS PS Handover (same NSE and same RA)

1. The BSS decides that a handover is required based on e.g. received measurement reports.

2. The BSS determines that it manages resources for both cells and that they are associated with the same (NSE) and the same RA. The BSS applies data forwarding (from the old cell to the new cell) for PFCs that it determines are to receive PS handover treatment.

NOTE 1: The MS does not know if optimised or non-optimised intra-BSS PS handover procedures are used.

3. The BSS sends the PS Handover Command (RN part) 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 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 uplink packets associated with a PFC receiving handover treatment that have not yet been fully transmitted might be buffered depending on the QoS class.

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

– The MS may discard uplink packets during the link interruption to preserve the real-time properties.

4. The MS tunes to the radio channel and the timeslot allocated in the target cell by the BSS and if so required by the BSS (see sub-clause 6.2) sends the PS Handover Access (Handover Reference) message in the form of four handover access bursts to the BSS on the allocated channel. The PS Handover Command message indicates whether the PS Handover Access message shall be sent by the MS.

5. Upon receipt of the PS Handover Access message, based on the Handover Reference, the BSS sends the Packet Physical Information message, if needed (see sub-clause 6.2), with the timing advance to the MS for the MS to synchronise.

NOTE 2: In the case of pre-synchronised handover the MS may receive the timing advance information to use in uplink in the target cell in the PS Handover Command message (if no timing advance information is included, the mobile station uses a default timing advance in the target cell). In a pre-synchronised or synchronized handover the Packet Physical information message is not sent in the target cell.

6. The MS sends uplink LLC PDUs, e.g. uplink user data packets, in the allocated channel to the BSS.

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 radio resources using the legacy procedures.

7. Upon reception of the first correct RLC/MAC block (sent in normal burst format) from the MS, the BSS releases the radio resources in the source cell and sends, on the target cell BVCI, the PS Handover Complete (TLLI, IMSI, Target Cell Identifier) message to the SGSN in order to indicate that the BSS has performed an internal handover. In this case, the target cell is indicated in the PS Handover Complete message.

8. Once the BSS has correctly identified the MS, it sends a Packet Uplink Ack/Nack message (see 3GPP TS 44.060) indicating the status of the received RLC data blocks.

9. The reception of the PS Handover Complete message at the SGSN triggers the sending of downlink data to the new cell using a new BVCI. The first DL PDU received by the BSS with the new-BVCI allows the BSS to clear the relationship to the old BVCI.

The reception of the PS handover Complete message indicates to the SGSN that there is no need to wait for the Cell Update sent from the MS to the SGSN.

NOTE 3: It is assumed here that downlink flow control is carried out on a per PFC basis and that the PFC specific flow control parameters remain the same upon MS arrival in the target cell.

5.1.3 Intra SGSN

5.1.3.1 Intra SGSN/Inter BSS HO, Preparation phase

Figure 7: PS Handover Preparation Phase; Intra-SGSN/Inter-BSS case

(GERAN A/Gb mode  GERAN A/Gb 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 SGSN, GTP tunnel(s) between the SGSN and GGSN.

2. The source BSS sends a PS Handover Required (Old TLLI, Cause, Source Cell Identifier, Target Cell Identifier, Source BSS to Target BSS Transparent Container (RN part), Active PFCs List, Reliable INTER RAT HANDOVER INFO) message to the SGSN.

The source BSS shall always include the ‘Reliable INTER RAT HANDOVER INFO’ indicator set to ‘1’ in the PS Handover Required message if the INTER RAT HANDOVER INFO in the Source BSS to Target BSS Transparent Container was received from the SGSN in a PS Handover Complete Ack message or a PS Handover Request message with "Reliable INTER RAT HANDOVER INFO" set to "1" or a CREATE-BSS-PFC message. It shall be set to ‘0’ otherwise.

3. The SGSN determines from the Target Cell Identifier the type of handover, i.e. intra-SGSN, inter-SGSN or inter-RAT/mode handover and whether the routing area has changed. In case of no change of routing area, the SGSN sends a PS Handover Request (TLLI, Cause, IMSI, Source Cell Identifier, Target Cell Identifier, PFCs To Be Set Up List, Source BSS to Target BSS Transparent Container (RN part), Reliable Inter RAT HANDOVER INFO) message to the target BSS. In case of Intra-SGSN PS handover when the routing area changes, the SGSN shall assign a new P-TMSI for the MS and derive a local TLLI prior to the sending of the PS Handover Request message. The SGSN shall only request resources for PFCs that are included in the Active PFCs List. If received in a PS Handover Required message, the SGSN shall forward the ‘Reliable INTER RAT HANDOVER INFO’ indicator to the target BSS.

NOTE 1: The BSS PFCs required to be set up are downloaded to the target BSS from the SGSN, i.e. all information required for PFC creation.

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 sends the PS Handover Request Acknowledge (TLLI, List of Set Up PFCs, Target BSS to Source BSS Transparent Container (PS Handover Command with RN part)) message to the SGSN. Upon sending the PS Handover Request Acknowledge message the target BSS shall be prepared to receive downlink LLC PDUs from the SGSN for the accepted PFCs.

When the 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.1.3.2 Intra SGSN/Inter BSS HO, Execution phase

Figure 8: PS Handover Execution Phase; Intra-SGSN/Inter-BSS case

(GERAN A/Gb mode  GERAN A/Gb mode)

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

2. When receiving the PS Handover Request Acknowledge message the SGSN may, based on QoS, start duplication of LLC PDUs and forward those to the target BSS. If the SGSN forwards downlink packets to the target BSS, the target BSS may start blind transmission of downlink user data towards the MS over the allocated radio channels.

3. The SGSN continues the PS Handover by sending a PS Handover Required Acknowledge (Old TLLI, List of Set Up PFCs, Target BSS to Source BSS Transparent Container (PS Handover Command with RN part)) message to the source BSS.

Before sending the PS Handover Required Acknowledge message, the 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.

NOTE 1: Only PFI(s) for PFCs accepted by the target cell are included in the message.

4. The source BSS sends the PS Handover Command (RN part) 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 uplink packets associated with a PFC receiving handover treatment that have not yet been fully transmitted might be buffered depending on the QoS class.

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

– The MS may discard uplink packets during the link interruption to preserve the real-time properties.

5. The MS tunes to the radio channel and the timeslot allocated in the target cell by the BSS and may send the PS Handover Access (Handover Reference) message in the form of four handover access bursts to the BSS on the allocated channel. The PS Handover Command message indicates whether or not the MS shall send PS Handover Access messages.

6. The target BSS sends a Packet Physical information message to the MS containing the timing advance for the MS to synchronise.

NOTE 2: In the case of pre-synchronised handover the MS may receive the timing advance information to use in uplink in the target cell in the PS Handover Command message (if no timing advance information is included, the mobile station uses a default timing advance in the target cell). In a pre-synchronised or synchronized handover, the Packet Physical Information message is not sent in the target cell.

7. The MS sends uplink LLC PDUs, e.g. a Routing Area Update Request message or uplink user data packets to the SGSN immediately after receiving the Packet Physical Information message or, in a synchronised or pre-synchronised handover, 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.

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 (TLLI, IMSI, Request for Inter RAT Handover Info) message to inform the SGSN that the MS has arrived in the target cell. After the reception of the PS Handover Complete message the SGSN shall initiate the BSS PFC procedures to delete the BSS PFC in the BSS controlling the source cell and shall be prepared to receive data from the new cell. The source BSS initiates the release of the radio resources in the source cell after receiving the DELETE-BSS-PFC PDU from the SGSN. The target BSS that supports inter-RAT PS handover to UTRAN shall request the INTER RAT HANDOVER INFO from the SGSN if the ‘Reliable INTER RAT HANDOVER INFO’ is missing or set to ‘0’ in the PS Handover Request message or if it has not received the INTER RAT HANDOVER INFO as part of the Source BSS to Target BSS transparent container.

9. 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) to the target BSS.

10. 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 BSS during the preparation phase.

If Routing Area Update occurs after completion of the execution phase, then the CAMEL procedure calls shall be performed according to 3GPP TS 23.060.

5.1.4 Inter SGSN

5.1.4.1 Inter SGSN HO, Preparation phase

Figure 9: PS Handover Preparation Phase; Inter-SGSN case (GERAN A/Gb mode  GERAN A/Gb 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 (Old TLLI, Cause, Source Cell Identifier, Target Cell Identifier, Source BSS to Target BSS Transparent Container (RN part), Active PFCs List, Reliable Inter RAT HANDOVER INFO) message to the old SGSN. The source BSS shall always include the ‘Reliable INTER RAT HANDOVER INFO’ indicator set to ‘1’ in the PS Handover Required message if the INTER RAT HANDOVER INFO in the Source BSS to Target BSS Transparent Container was received from the SGSN in a PS Handover Complete Ack message or a PS Handover Request message with "Reliable INTER RAT HANDOVER INFO" set to "1" or a CREATE-BSS-PFC message. It shall be set to ‘0’ otherwise.

3. The old SGSN determines from the Target Cell Identifier that the type of handover is inter-SGSN. In case of inter-SGSN PS Handover, the old SGSN initiates the PS Handover resource allocation procedure by sending a Forward Relocation Request (IMSI, Cause, Source Cell Identifier, Target Cell Identifier, MM Context, PDP Contexts, Packet Flow ID, SNDCP XID parameters, LLC XID parameters, Tunnel Endpoint Identifier for the Control Plane, SGSN Address for the control plane, Source BSS to Target BSS Transparent Container (RN part) in the BSS container, PDP Context Prioritisation, Reliable INTER RAT HANDOVER INFO) 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. used ciphering algorithm and ciphering key as decribed in 3GPP TS 29.060 [11]. The relation between GSM and UMTS security parameters is defined in 3GPP TS 33.102 [27].

The Ciphering key used by the old SGSN is reused by the new SGSN until a new authentication procedure is performed (see clause 5.1.4.2, bullet 13).

If the new SGSN does not support the indicated ciphering algorithm, the new SGSN has to select a new ciphering algorithm. This new 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 it extracts from the PDP Contexts the associated NSAPIs, SAPIs and PFIs to be used in the new SGSN. In case when the new SGSN does not support the same SAPI and PFI indicated by the old SGSN for a certain NSAPI, 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 and for which it can allocate resources. 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 Forward Relocation Response message of the target SGSN), are maintained in the new SGSN and the related SAPIs and PFIs are kept. When this occurs the packet data transfer corresponding to PDP Contexts for which new SAPI and PFI values are needed are suspended. 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. When the required PDP, MM, SNDCP and LLC contexts are established and the mapping between NSAPI, SAPI and PFI for each of these PDP Contexts is established, the corresponding packet data transfer can continue.

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.

The old SGSN shall indicate the current XID parameter settings (i.e. those used at the old SGSN) 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’.

NOTE 1: ‘Reset to the old XID parameters’ means that the LLC and SNDCP layer are reset, except for the LLC XID parameters and SNDCP XID parameters which are re-initialized to the latest negotiated values, and the negotiated compression entities which are re-initialized.

NOTE 2: void

Otherwise the new SGSN shall create a NAS container for PS HO indicating Reset (i.e. reset to default parameters).

If received in a PS Handover Required message, the old SGSN shall forward the ‘Reliable INTER RAT HANDOVER INFO’ indicator to the new SGSN in the Forward Relocation Request message.

4. The new SGSN sends a PS Handover Request (Local TLLI, Cause, IMSI, Source Cell Identifier, Target Cell Identifier, Source BSS to Target BSS Transparent Container (RN part), PFCs To Be Set Up List, NAS container for PS HO, Reliable Inter RAT HANDOVER INFO) message to the target BSS. The new SGSN shall not request resources for PFCs 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.

NOTE 3: The BSS PFCs required to be set up are downloaded to the target BSS from the new SGSN, i.e. all information required for PFC creation.

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

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. The target BSS shall send the PS Handover Request Acknowledge (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.

8. When the new SGSN receives the PS Handover Request Acknowledge message 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 the control plane, Tunnel Endpoint Identifier Data II) message is sent from the new SGSN to the old SGSN. This message indicates that the new SGSN is ready to receive packets forwarded from the old SGSN. If the target BSS or the new SGSN failed to allocate resources this shall be indicated in the message. The Tunnel Endpoint Identifier Data II, one information for each PDP context, contains the tunnel endpoint of the new SGSN and the IP address of the new SGSN for data forwarding from the old to the new SGSN.

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.1.4.2 Inter SGSN HO, Execution phase

Figure 10: PS Handover Execution Phase; Inter-SGSN case (GERAN A/Gb mode  GERAN A/Gb mode)

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

2. If a Tunnel Endpoint is available the old SGSN may, based on QoS, start N-PDU relay and duplication to the new SGSN.

– 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 new SGSN. All such N-PDUs are encapsulated in a GTP-PDU when transmitted to the new SGSN.

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. The new SGSN may, based on QoS, proceed with the packet handling as follows:

– For PDP context(s) which uses LLC ABM the new SGSN stores the N-PDUs associated with their number into the SNDCP queue. Data transfer prior the exchange of N-PDU SNs is not possible.

– For PDP context(s) which uses 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 downlink 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 old SGSN continues the PS Handover procedure by sending a PS Handover Required Acknowledge (Old TLLI, PFCs Set Up List, Target BSS to Source BSS Transparent Container (PS Handover Command with RN part and CN part)) 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.

NOTE 2: Only PFI(s) for PFCs accepted by the target cell are included in the message.

4a. The old SGSN shall send the Forward SRNS Context (NSAPI, DL GTP-U number, UL GTP-U number) message 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 sequence 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 (SGSNs and GGSN) shall assign consecutive GTP-PDU sequence numbers to user packets belonging to the same PDP context uplink and downlink, respectively.

5. The source BSS sends the PS Handover Command (RN part, CN part) message to the MS by interrupting the transmission of LLC PDUs on any of the downlink TBFs. The RN part and the CN part are transparent information to the BSS. 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. The MS management of uplink N-PDUs following the reception of the PS Handover Command message is as follows:

– All uplink packets associated with a PFC receiving handover treatment that have not yet been fully transmitted may be buffered depending on the QoS class. If the buffered uplink packets are transmitted in the new cell, they need to be ciphered using the new IOV-UI after the handover.

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

– The MS may discard uplink packets during the link interruption to preserve the real-time properties.

6. The MS tunes to the radio channel and the timeslot allocated in the target cell by the target BSS and may send the PS Handover Access (Handover Reference) message in the form of four handover access bursts to the target BSS on the allocated channel. The PS Handover Command message indicates whether or not the MS shall send PS Handover Access message. The target BSS sends a Packet Physical information message to the MS containing the timing advance for the MS to synchronise.

NOTE 3: In the case of pre-synchronised handover the MS may receive the timing advance information to use in uplink in the target cell in the PS Handover Command message (if no timing advance information is included, the mobile station uses a default timing advance in the target cell). In a pre-synchronised or synchronised handover the Packet Physical Information message is not sent in the target cell.

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 or, in a synchronised or pre-synchronised handover, 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 4: If the new SGSN indicated Reset (i.e. reset to default parameters) in the NAS container for PS HO included in the PS Handover Command, 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, IMSI, 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 that supports inter-RAT PS handover to UTRAN shall request the INTER RAT HANDOVER INFO from the SGSN if the ‘Reliable INTER RAT HANDOVER INFO’ is missing or set to ‘0’ in the PS Handover Request message or if it has not received the INTER RAT HANDOVER INFO as part of the Source BSS to Target BSS transparent container.

9. Upon receiving the PS Handover Complete message, the new SGSN sends a Forward Relocation Complete message to the old SGSN. The old SGSN responds 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.

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. After the reception of the Forward Relocation Complete message the old SGSN deletes to BSS packet flow context towards the old cell. The source BSS initiates the release of the radio resources in the source cell.

12. If the new SGSN indicated Reset (i.e. reset to default parameters) in the NAS container for PS HO included in the PS Handover Command, then on receipt of the PS Handover Complete message 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 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 that 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 5: 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. 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 the SGSN with a Routing Area Update Complete (Receive N-PDU number) message. The MS derives a new local TLLI from the new P-TMSI using 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 BSS during the preparation phase.