5.5 Handover cancel

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

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

5.5.1 General

Instead of performing the handover, the source BSS may at any time during the handover procedure, up to the time when the PS Handover Command message is sent to the mobile station cancel the handover. The reason for cancelling can be e.g. due to a timer expiration or due to other events within the source BSS and is initiated by sending a PS Handover Cancel PDU to the SGSN.

A PS Handover Cancel PDU shall also be sent by the source BSS after the PS Handover Command message is sent to the mobile station for the case where the PS Handover fails and the MS returns to the old cell or radio contact with the MS is lost. This is done in order to release the resources reserved for the PS Handover in the target system.

The radio contact with the MS is considered lost by the source BSS if, after transmission of the PS Handover Command message, for an implementation dependent period of time:

– the BSS does not receive a Packet Cell Change Failure message (see sub-clause 5.7.2) or any other RLC/MAC block (other than a Packet Control Acknowledgement message which acknowledges the receipt of the PS Handover Command) from the MS in the source cell, and either

the BSS does not receive any RLC/MAC block from the MS in the target cell, if the PS handover is an optimised intra-BSS handover, or

the BSS does not receive a DELETE-BSS-PFC PDU (including the TLLI of the MS) from the SGSN, if the PS handover is an inter-BSS handover, inter-RAT/mode or non-optimised intra-BSS handover.

The signalling procedures for the case when the handover is cancelled before the PS Handover Command message has been sent by the source BSS to the mobile station is shown in clause 5.5.2 below, as well as the case when the handover is cancelled in UTRAN/GERAN Iu mode by the source RNC/BSS. The signalling procedures for the cases that occur after the PS Handover Command message has been sent are shown in clause 5.7.2.1.

5.5.2 Signalling procedures

5.5.2.1 Inter-SGSN case, GERAN A/Gb mode GERAN A/Gb mode

Figure 20: PS Handover Cancel; Inter-SGSN case, GERAN A/Gb mode GERAN A/Gb mode

1. The source BSS decides to cancel the previously requested PS Handover. This may be due to initiation of a CS call during the preparation phase, not enough accepted PFCs, or any other reason.

2. The source BSS sends a PS Handover Cancel (TLLI, Cause, Source Cell Identifier, Target Cell Identifier) PDU to the old SGSN.

3. The old SGSN terminates the PS Handover to the target cell by sending a Relocation Cancel Request (IMSI) message to the new SGSN. The old SGSN also resumes operation on the resources in the source cell.

NOTE 1: If one new SGSN was chosen among a pool, then the Relocation Cancel Request message is sent to this SGSN.

4. The new SGSN triggers the release of resources in the target cell and also releases its own resources allocated for this handover.

5. The new SGSN acknowledges the release of all resources on the target side by returning a Relocation Cancel Response message to the old SGSN.

NOTE 2: In the intra-SGSN case, the messages Relocation Cancel Request and Relocation Cancel Response are not exchanged since the old and new SGSN are then the same node.

5.5.2.2 Inter-SGSN case, GERAN A/Gb mode UTRAN/GERAN Iu mode

Figure 20a: PS Handover Cancel; Inter-SGSN case, GERAN A/Gb mode UTRAN/GERAN Iu mode

1. The source BSS decides to cancel the previously requested PS handover. This may be due to initiation of a CS call during the preparation phase, not enough accepted PFCs, or any other reason.

2. The source BSS sends a PS Handover Cancel (TLLI, Cause, Source Cell Identifier, Target Cell Identifier) PDU to the old SGSN.

NOTE 1: If one new SGSN was chosen among a pool, then the Relocation Cancel Request message is sent to this SGSN.

4. The new SGSN triggers the release of resources in the target cell by sending an Iu Release Command message to the target RNC

5. The target RNC releases all resources allocated for this handover and returns an Iu Release Complete message to the new SGSN.

6. The new SGSN releases its own resources allocated for this handover and acknowledges the release of all resources on the target side by returning a Relocation Cancel Response message to the old SGSN.

NOTE 2: In the intra-SGSN case, the messages Relocation Cancel Request and Relocation Cancel Response are not exchanged since the old and new SGSN are then the same node.

5.5.2.3 Inter-SGSN case, UTRAN/GERAN Iu mode GERAN A/Gb mode

Figure 20b: Relocation Cancel; Inter-SGSN case, UTRAN/GERAN Iu mode GERAN A/Gb mode

1. The source RNC/BSS decides to cancel the previously requested relocation of PS resources. This may be due to
initiation of a CS call during the preparation phase, not enough accepted RABs, UE returned to source cell or any other reason.

2. The source RNC/BSS sends a Relocation Cancel (Cause) message to the old SGSN.

3. The old SGSN terminates the relocation to the target cell by sending a Relocation Cancel Request (IMSI) message to the new SGSN. The old SGSN also resumes operation on the resources in the source cell.

NOTE 1: If one new SGSN was chosen among a pool, then the Relocation Cancel Request message is sent to this SGSN.

4. The new SGSN triggers the release of resources in the target cell and also releases its own resources allocated for this handover.

5. The new SGSN acknowledges the release of all resources on the target side by returning a Relocation Cancel Response (Cause) message to the old SGSN.

6. The old SGSN returns a Relocation Cancel message to the source RNC/BSS.

NOTE 2: In the intra-SGSN case, the messages Relocation Cancel Request and Relocation Cancel Response are not exchanged since the old and new SGSN are then the same node.

5.5.2.4 Inter-SGSN, GERAN A/Gb mode  E-UTRAN

The detailed signalling flows are specified in 3GPP TS 23.401 [33] in sub-clause 5.5.2.X.2.

5.5.2.5 Inter-SGSN case, E – UTRAN GERAN A/Gb mode

The detailed signalling flows are specified in 3GPP TS 23.401 [33] in sub-clause 5.5.2.X.2.