5.7 PS Handover Failure

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

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

During the PS handover procedure several types of failures can be identified. The PS handover failures may be typical network and signalling failure occurrences such as failures related to the loss of signalling messages, incorrect information element in the signalling messages or failures due to network nodes failures or specific to abnormal cases occurring during PS handover procedures.

In general the PS handover failures can be divided into:

– Preparation Phase Failure Scenarios on the Um, Gb, Gn and Up interface.

– Execution Phase Failure Scenarios on the Um, Gb and Gn interface.

NOTE: RAU procedure failures will be handled as specified in 3GPP TS 24.008 [15].

A list of appropriate cause values should be chosen/defined to indicate to the source cell and target cell nodes the cause of the PS Handover Request Negative Acknowledge and the PS handover Cancel messages.

5.7.1 Preparations Phase Failure Scenarios

5.7.1.1 PS Handover preparation phase failure scenarios on the Um interface

– No Resource Reservation / Allocation:

– No radio resources available in the target cell.

5.7.1.2 PS Handover preparation phase failure scenarios on the Gb interface

– No Resource Reservation / Allocation on the target system:

– No radio resources available in the target cell (see clause 5.4). Appropriate cause values are needed in the PS Handover Request Negative Acknowledge message.

– Insufficient resource allocation by the target system:

– In case of insufficient resource allocation by the target side the source BSS may cancel the PS handover procedure (see clause 5.5).

– Feature "PS Handover" not supported:

– A new cause value is needed for the Gb interface if the target BSS/GANC does not support the PS Handover procedure.

– •Target CSG cell is not allowed for this MS:

– A new cause value is needed for the Gb interface to inform the source BSS that the target CSG cell is invalid whenever access control performed according to the CSG Subscription List is unsuccessful.

– Generic Causes:

– Generic causes for the Gb interface failures are defined in 3GPP TS 48.018 [10]. The same cause values are applicable to the PS handover procedure on the Gb interface.

5.7.1.3 PS Handover preparation phase failure scenarios on the Gn interface

– Context Transfer Failure:

– Context transfer failure may occur due to various causes defined in 3GPP TS 29.060 [11]. These cause values will be utilized during PS handover procedure. These values are to be utilized during PS handover procedure to indicate to the old SGSN the cause of the PS handover reject. Consequently an appropriate cause value should be chosen to allow the old SGSN to indicate to the source BSS the cause of failure.

– No Resource Reservation/ No Resource Allocation:

– Resource Reservation/Allocation failure occurs when no radio resources are available in the target cell. Consequently an appropriate cause value should be chosen to allow the old SGSN to indicate to the source BSS the cause of failure.

– Procedure "PS Handover" not supported:

– This occurs when the new SGSN does not support the PS Handover feature.

– Generic Causes:

– In 3GPP TS 29.060 [11] a set of cause values are defined. The same cause values are applicable to the PS handover procedure on the Gn interface.

5.7.1.4 PS Handover preparation phase failure scenarios on the Up interface

– Failure to allocate a GA-PSR Transport Channel

– This occurs when the GANC sends the MS a GA-PSR ACTIVATE UTC REQ message (GANC  MS) but fails to receive a GA-PSR ACTIVATE UTC ACK back from the MS.

– Generic Causes:

– Handled as defined in 3GPP TS 44.060 [7] for the case where no radio resources are available in the target cell.

5.7.2 Execution Phase Failure Scenarios

5.7.2.1 Execution phase failures on the Um interface

5.7.2.1.1 Initial Access Failure in the Target Cell during PS handover

In case of initial access failure in the target cell, including the case where the MS fails to acquire time alignment information (for the unsynchronised network case), the MS is allowed to revert to the old cell. As is defined currently in 3GPP TS 44.060 [7], the MS shall return to the old cell and send a Packet Cell Change Failure message with the appropriate cause.

If the MS was in packet transfer mode (or MAC-shared state) before the attempted handover it will, when going back to the old cell, send a Packet Cell Change Failure message and resume TBFs which were ongoing in the old cell. The source BSS will inform the old SGSN about this failure and consequently the old SGSN will inform the new SGSN about this failure, upon which the new SGSN will release the allocated resources and clear out any information and buffers related to this MS.

The signalling flows for this procedure are depicted in figure 21 and 21a.

Figure 21: MS returns to old cell; Inter-SGSN case, GERAN A/Gb mode GERAN A/Gb mode

1. The MS returns to the old cell and sends a Packet Cell Change Failure message to the source BSS.

2. The source BSS sends a PS Handover Cancel (TLLI, Cause = MS Back on old Channel, 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, and resumes forwarding of uplink N-PDUs to the GGSN for those PDP contexts for which forwarding was previously stopped.

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.

Figure 21a: MS returns to old cell; Inter-SGSN case, GERAN A/Gb mode UTRAN/GERAN Iu mode

1. The MS returns to the old cell and sends a Packet Cell Change Failure message to the source BSS.

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

NOTE 3: 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 4: 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.7.2.1.2 Radio contact with the MS is lost:

After sending a PS Handover Command message to the MS, if the source BSS detects that radio contact with the MS has been lost (see sub-clause 5.5.1):

– In case of optimised intra-BSS PS handover, the BSS shall release the assigned resource in both the source cell and target cell.

– In case of SGSN involved PS handover, the source BSS shall release the assigned resource in the source cell and initiate the PS Handover Cancel procedure to release the reserved resource in the target cell.

The signalling flows for this procedure are depicted in figures 21b and 21c.

Figure 21b: Radio Contact lost with MS; Inter-SGSN case, GERAN A/Gb mode GERAN A/Gb mode

1. The source BSS sends a PS Handover Command message to the MS.

2. The source BSS receives no indication that the MS has made access in the target cell, nor that it has returned to the source cell.

3. The source BSS sends a PS Handover Cancel (TLLI, Cause = Radio Contact Lost with MS, Source Cell Identifier, Target Cell Identifier) PDU to the old SGSN.

NOTE 5: If the old SGSN has already received a Forward Relocation Complete message when the PS Handover Cancel PDU is received , the old SGSN ignores the PS Handover Cancel PDU.

4. The old SGSN terminates the PS Handover to the target cell by sending a Relocation Cancel Request (IMSI) message to the new SGSN.

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

NOTE 7: If the MS has successfully made access on the target side when the Relocation Cancel Request message is received by the new SGSN, the new SGSN does not release any resources on the target side, but instead goes directly to step 6 below.

NOTE 8: If the resources on the target side have, due to some local decision on the target side, already been released when the Relocation Cancel Request message is received by the new SGSN, then the new SGSN goes directly to step 6 below.

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

6. The new SGSN returns a Relocation Cancel Response message to the old SGSN which then releases all its resources for this connection.

NOTE 9: 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.

Figure 21c: Radio Contact lost with MS; Inter-SGSN case, GERAN A/Gb mode UTRAN/GERAN Iu mode

1. The source BSS sends a PS Handover Command message to the MS.

2. The source BSS receives no indication that the MS has made access in the target cell, nor that it has returned to the source cell.

3. The source BSS sends a PS Handover Cancel (TLLI, Cause = Radio Contact Lost with MS, Source Cell Identifier, Target Cell Identifier) PDU to the old SGSN.

NOTE 10: If the old SGSN has already received a Forward Relocation Complete message when the PS Handover Cancel PDU is received , the old SGSN ignores the PS Handover Cancel PDU.

4. The old SGSN terminates the PS Handover to the target cell by sending a Relocation Cancel Request (IMSI) message to the new SGSN.

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

NOTE 12: If the MS has successfully made access on the target side when the Relocation Cancel Request message is received by the new SGSN, the new SGSN does not release any resources on the target side, but instead goes directly to step 7 below.

NOTE 13: If the resources on the target side have, due to some local decision on the target side, already been released when the Relocation Cancel Request message is received by the new SGSN, then the new SGSN goes directly to step 7 below.

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

6. The target RNC releases all resources allocated for this handover and returns an Iu Release Complete message to the new SGSN which then releases its own resources allocated for this handover.

7. The new SGSN returns a Relocation Cancel Response message to the old SGSN which then releases all its resources for this connection.

NOTE 14: 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.7.2.2 Execution phase failures on the Gb interface

– Generic Causes:

– Generic causes for the Gb interface failures are defined in 3GPP TS 48.018 [10]. The same cause values are applicable to the PS handover procedure.

5.7.2.3 Execution phase failures on the Gn interface

– Update PDP Context failure:

– As specified in 3GPP TS 29.060 [11] if the new SGSN receives an Update PDP Context Response message from the GGSN with a cause value other than ‘Request accepted’, it shall abort the update of the PDP context. Such a PDP context may be modified or deactivated by the new SGSN via explicit SM procedures upon the completion of the routing area update (RAU) procedure.