12 Detailed procedures in 3G_MSC‑B

23.0093GPPHandover proceduresRelease 17TS

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

For detailed procedures in 3G_MSC‑B at handover within the GSM network, please see clause 10 ‘Detailed procedures in MSC‑B’.

12.1 RNC/BSC/3G_MSC (UE/MS/RNC/BSC) procedures in 3G_MSC‑B (functional unit 1)

The Intra and Inter-3G_MSC handover/relocation procedures in this functional unit consist of:

i) signalling between the UE/MS and the 3G_MSC;

ii) signalling between the RNS/BSS and the 3G_MSC for access management.

Signals exchanged with functional unit 3 are indicated in clause 12.3.

12.2 Call control procedures 3G_MSC‑B (functional unit 2)

These procedures relate to the call control in 3G_MSC‑B of the "3G_MSC handover/relocation" connection with 3G_MSC‑A. For these procedures the following apply:

Call set-up:

– the connection is set up by 3G_MSC‑A. 3G_MSC‑B should provide, if possible, the following backward signals:

– signals indicating unsuccessful call set-up and, if possible, the cause of call failure;

– address complete signal;

– answer signal (see note).

NOTE: The answer signal is not related to answering by the UE/MS and it has no meaning in the 3G_MSC handover/relocation procedure between 3G_MSC‑A and 3G_MSC‑B. But after successful handover/relocation or successful subsequent channel assignment using a circuit connection between 3G_MSC‑A and 3G_MSC‑B this signal is needed for bringing the connection in the answered state in the intermediate PSTN/ISDN exchanges.

– there will be no indication that the call applies to a 3G_MSC handover/relocation. This information has to be derived from the UE/MS Handover Number received during call set-up in relation to the earlier MAP-PREPARE-HANDOVER request/MAP-PREPARE-HANDOVER response procedure between 3G_MSC‑A and 3G_MSC‑B.

Call clearing:

– call clearing consists of two parts after inter-3G_MSC handover/relocation: clearing of the RNS-UE/MS or the BSS-UE/MS connection and clearing of the inter-3G_MSC connection, these cases are only applicable to calls successfully handed over or relocated. If a request to release the call is generated by the network while the UE/MS is re-tuning from one RNS/BSS to another RNS/BSS, then 3G_MSC‑B shall begin clearing the call to the network and queue the call release to the UE/MS until the UE/MS has resumed communication;

– the MAP is used to transfer information between 3G_MSC‑A and 3G_MSC‑B in order to make it possible for 3G_MSC‑B to send the appropriate signals to the UE/MS, specified in 3GPP TS 24.008 [10], and still leave the call control to 3G_MSC‑A. 3G_MSC‑A normally initiates release of the connection between 3G_MSC‑A and 3G_MSC‑B. Exceptionally 3G_MSC‑B is allowed to release the connection if no MAP-SEND-END-SIGNAL response is received, or if the 3G_MSC Handover/Relocation is to be aborted;

– when the Signalling System no 7 ISDN User Part is used, the normal symmetric release procedures apply. When a signalling system is used without a symmetric release possibility or a fault condition occurs, the following may apply:

– when 3G_MSC‑B receives a clear-forward signal from 3G_MSC‑A, it shall release the radio resources;

– in fault situation e.g. machine malfunction or loss of the connection on interface Iu or interface A, 3G_MSC‑B may send a clear-back signal to 3G_MSC‑A.

12.3 Handover/Relocation control procedures in 3G_MSC‑B (functional unit 3)

The procedures of functional unit 3 are given in form of SDL diagrams in figure 44. To easily distinguish the interface concerned the messages received or sent from this unit are prefixed with either ‘MAP’ for a MAP message, ‘A’ for an A‑Interface message, ‘Iu’ for an Iu-Interface message or ‘I’ for an ISDN/PSTN message. The procedure in functional unit 3 include:

i) inter 3G_MSC handover/relocation from 3G_MSC‑A;

This case is initiated by 3G_MSC‑A, and includes allocation and establishment of the new radio resources. The procedure is outlined in clauses 8.1.1 and 8.1.2. for UMTS to GSM handover, clauses 8.2.1 and 8.2.2 for GSM to UMTS handover and clauses 8.3.1 and 8.3.2 for relocation.

ii) intra-3G_MSC UMTS to GSM handovers within the area controlled by 3G_MSC‑B;

This procedure is the same as that of ii) in clause 11.3, except that the Iu-RELOCATION-REQUIRED is received by 3G_MSC‑B. After successful completion of the intra-3G_MSC handover, 3G_MSC-B shall notify 3G_MSC-A by sending an A-HANDOVER-PERFORMED message.

iii) intra-3G_MSC GSM to UMTS handovers within the area controlled by 3G_MSC‑B;

This procedure is the same as that of ii) in clause 11.3, except that the A-HANDOVER-REQUIRED is received by 3G_MSC‑B. After successful completion of the intra-3G_MSC handover, 3G_MSC-B shall notify 3G_MSC-A by sending an A-HANDOVER-PERFORMED message.

iv) intra-3G_MSC SRNS Relocation within the area controlled by 3G_MSC‑B;

This procedure is the same as that of ii) in clause 11.3, except that the Iu-RELOCATION-REQUIRED is received by 3G_MSC‑B. After successful completion of the intra-3G_MSC SRNS relocation, if security algorithms have been changed, 3G_MSC-B shall notify 3G_MSC-A by sending an A-HANDOVER-PERFORMED or an Iu-LOCATION-REPORT message, depending on the access network protocol used encapsulated on the E-interface (see clauses 4.4.1 and 6.2.3).

v) subsequent handover/relocation to another 3G_MSC (3G_MSC‑A or 3G_MSC‑B’);

The initiation procedure is essentially the same as that of i) of clause 11.3. The Handover Command to the BSS or the Relocation Command to the RNS is now generated by 3G_MSC‑B after the A-HO-REQUEST-ACKNOWLEDGE or Iu-RELOCATION-REQUEST-ACKNOWLEDGE is received from 3G_MSC‑A (via functional unit 4). The procedure is terminated in 3G_MSC‑B when 3G_MSC‑B receives a terminate procedure indication from functional unit 4.

NOTE: The procedures iii), iv) and, in case of a subsequent handover back to 3G_MSC-A, the procedure v) may be applied also in case of a handover/relocation to an RNC which is controlled by 3G_MSC-B or 3G_MSC-A respectively by using the "Flexible Iu interface for handover/relocation" option.

Timers in 3G_MSC‑B.

The following procedures are supervised by timers in order to avoid a deadlock when responses are not received or the procedures fail.

The following timers are defined for UMTS to GSM handover:

T401: this timer supervises the queuing time for a free channel. T401 is set by O&M;

T402: this timer supervises the time for handover completion for UMTS to GSM handover from RNS to BSS in 3G_MSC‑B. If T402 expires, the radio path and the connection on interface B’ are released. T402 is set by O&M;

T404: this timer supervises the time between sending of address complete message to 3G_MSC‑A and receiving the A-HANDOVER-COMPLETE from BSS-B on 3G_MSC‑B. This timer also supervises the time between issuing the handover command to the UE/MS and receiving the MAP-SEND-END-SIGNAL response from 3G_MSC‑A, for a subsequent handover from UMTS to GSM. In the case of a UMTS to GSM handover without circuit connection between 3G_MSC‑A and 3G_MSC‑B this timer supervises the time between issuing the A-HO-REQUEST-ACKNOWLEDGE to the 3G_MSC‑A and receiving the A-HANDOVER-COMPLETE from BSS-B on 3G_MSC‑B. If the timer expires, then any new radio channel is released. T404 is set by O&M;

T410: this timer is used to supervise the time for establishing a circuit connection from 3G_MSC‑A to 3G_MSC‑B. When T410 expires, the allocated channel in 3G_MSC‑B is released. T410 is set by O&M. This timer is not started when 3G_MSC‑A explicitly indicates that no handover number is needed;

T411: this timer is used to control the time between requesting a subsequent UMTS to GSM handover (A‑HO‑REQUEST to the 3G_MSC‑A) and receiving the response from 3G_MSC‑A (A-HO-REQUEST-ACKNOWLEDGE/A-HO-FAILURE). If T411 expires, the existing connection with the UE/MS is maintained. T411 is set by O&M.

The following timers are defined for GSM to UMTS handover:

T601: this timer supervises the queuing time for a free radio resource. T601 is set by O&M;

T602: this timer supervises the time for handover completion for GSM to UMTS handover from BSS to RNS in 3G_MSC‑B. If T602 expires, the radio path and the connection on interface B’ are released. T602 is set by O&M;

T604: this timer supervises the time between sending of address complete message to 3G_MSC‑A and receiving the Iu-RELOCATION-COMPLETE from RNS-B on 3G_MSC‑B. This timer also supervises the time between issuing the handover command to the UE/MS and receiving the MAP-SEND-END-SIGNAL response from 3G_MSC‑A, for a subsequent handover from GSM to UMTS. In the case of a GSM to UMTS handover without circuit connection between 3G_MSC‑A and 3G_MSC‑B this timer supervises the time between issuing the A-HO-REQUEST-ACKNOWLEDGE to the 3G_MSC‑A and receiving the Iu-RELOCATION-COMPLETE from RNS-B on 3G_MSC‑B. If the timer expires, then any new radio resource is released. T604 is set by O&M;

T610: this timer is used to supervise the time for establishing a circuit connection from 3G_MSC‑A to 3G_MSC‑B. When T610 expires, the allocated radio resource in 3G_MSC‑B is released. T610 is set by O&M. This timer is not started when 3G_MSC‑A explicitly indicates that no handover number is needed;

T611: this timer is used to control the time between requesting a subsequent GSM to UMTS handover (A‑HO‑REQUEST to the 3G_MSC‑A) and receiving the response from 3G_MSC‑A (A-HO-REQUEST-ACKNOWLEDGE/A-HO-FAILURE). If T611 expires, the existing connection with the UE/MS is maintained. T611 is set by O&M.

The following timers are defined for SRNS Relocation:

T801: this timer supervises the queuing time for a free radio resource. T801 is set by O&M;

T802: this timer supervises the time for relocation completion for relocation between RNSs in 3G_MSC‑B. If T802 expires, the radio path and the connection on interface B’ are released. T802 is set by O&M;

T804: this timer supervises the time between sending of address complete message to 3G_MSC‑A and receiving the Iu-RELOCATION-COMPLETE from RNS-B on 3G_MSC‑B. This timer also supervises the time between issuing the handover command to the UE and receiving the MAP-SEND-END-SIGNAL response from 3G_MSC‑A, for a subsequent relocation. In the case of a relocation without circuit connection between 3G_MSC‑A and 3G_MSC‑B this timer supervises the time between issuing the Iu‑RELOCATION-REQUEST-ACKNOWLEDGE to the 3G_MSC‑A and receiving the Iu‑RELOCATION-COMPLETE from RNS-B on 3G_MSC‑B. If the timer expires, then any new radio resource is released. T804 is set by O&M;

T810: this timer is used to supervise the time for establishing a circuit connection from 3G_MSC‑A to 3G_MSC‑B. When T810 expires, the allocated channel in 3G_MSC‑B is released. T810 is set by O&M. This timer is not started when 3G_MSC‑A explicitly indicates that no handover number is needed;

T811: this timer is used to control the time between requesting a subsequent relocation (Iu-RELOCATION-REQUEST to the 3G_MSC‑A) and receiving the response from 3G_MSC‑A (Iu-RELOCATION-REQUEST-ACKNOWLEDGE/ Iu-RELOCATION-FAILURE). If T811 expires, the existing connection with the UE is maintained. T811 is set by O&M.

12.4 MAP procedures in 3G_MSC‑B (functional unit 4)

The MAP procedures for handover/relocation are defined in 3GPP TS 29.002 [12]. They include:

– procedures for basic handover/relocation;

– procedures for subsequent handover/relocation;

– procedures for obtaining the handover number from the VLR.

These procedures are outlined in clause 8.

12.5 Interworking between Handover/Relocation control procedures and MAP procedures in 3G_MSC‑B

The interworking between the Handover/Relocation control procedures and the MAP procedures for handover/relocation is defined in 3GPP TS 29.010 [8]. It includes:

– interworking at basic handover/relocation completion;

– interworking at subsequent handover/relocation initiation.

This interworking is not described in the present document.

12.6 Compatibility with GSM Phase 1

GSM phase 1 is not supported.

12.7 Protocol interworking

If the 3G_MSC‑B accepts an Inter-3G_MSC GSM to UMTS handover procedure according to MAP and BSSMAP protocols while using a RANAP protocol towards RNS-B, 3G_MSC‑B has to perform the protocol interworking between RANAP on the Iu-Interface and encapsulated BSSMAP on the E-interface.

The same holds if 3G_MSC‑B initiates a subsequent inter-MSC UMTS to GSM handover while using a RANAP protocol towards RNS-A.

If during the supervision, i.e. while the UE/MS is not in the area of MSC-A or 3G_MSC-A, the protocol used encapsulated on the E-interface and the protocol used between 3G_MSC-B and the serving BSS or RNS are different, then 3G_MSC‑B has to perform the protocol interworking between BSSAP and RANAP.

NOTE: The two protocols are different, e.g., after an inter-MSC GSM to UMTS inter-system handover, or after an inter-MSC SRNS relocation to 3G_MSC-B followed by a subsequent intra-3G_MSC-B UMTS to GSM inter-system handover.

12.8 Interactions between handover/relocation control procedures and other RANAP procedures

This clause gives an overview of the procedures that shall be followed when handover/relocation control procedures interact with other RANAP procedures on 3G_MSC-B.

12.8.1 Interactions between handover/relocation control procedures and the security mode procedure

12.8.1.1 Intra-3G_MSC-B handover/relocation

A security mode control procedure may be requested by MSC-A/3G_MSC-A after an Inter-MSC GSM to UMTS handover or Inter-MSC SRNS relocation. If RNS-A replies with an Iu-SECURITY-MODE-REJECT containing the cause value ‘Relocation Triggered’ due to an already initiated Intra-3G_MSC-B UMTS to GSM handover or Intra-3G_MSC-BSRNS relocation, the 3G_MSC-B shall not forward the result of the security mode control procedure to MSC-A/3G_MSC-A, but wait for the outcome of the handover/relocation procedure. If the relocation procedure is completed successfully, the 3G_MSC-B shall reattempt the security mode control procedure towards the new serving radio network. If the handover procedure is completed successfully, the 3G_MSC-B shall reattempt the cipher mode control procedure towards the new serving radio network, if ciphering is to be activated.

NOTE: The message flow is shown in the perspective of 3G_MSC-B. It is assumed that RNS-A has sent the Iu-RELOCATION-REQUIRED before it received the Iu-SECURITY-MODE-COMMAND.

Figure 35a: Collision between a subsequent Intra-3G_MSC-B handover/relocation and a security mode control procedure i): successful handover/relocation

If the handover/relocation procedure is unsuccessful and the UE is still served by RNS-A, the 3G_MSC-B shall reattempt the security mode procedure towards RNS-A.

NOTE: The message flow is shown in the perspective of 3G_MSC-B. It is assumed that RNS-A has sent the Iu-RELOCATION-REQUIRED before it received the Iu-SECURITY-MODE-COMMAND.

Figure 35b: Collision between a subsequent Intra-3G_MSC-B handover/relocation and a security mode control procedure ii): unsuccessful handover/relocation

12.8.1.2 Subsequent Inter-MSC handover/relocation

A security mode control procedure may be requested by MSC-A/3G_MSC-A after an Inter-MSC GSM to UMTS handover or Inter-MSC SRNS relocation. If RNS-A replies with an Iu-SECURITY-MODE-REJECT containing the cause value ‘Relocation Triggered’ due to an already initiated subsequent Inter-MSC handover/relocation, the 3G_MSC-B shall not forward the result of the security mode procedure to MSC-A/3G_MSC-A, but wait for the outcome of the handover/relocation procedure. If the subsequent Inter-MSC relocation procedure is completed successfully, the 3G_MSC-A shall reattempt the security mode control procedure towards the new serving radio network or MSC-B’/3G_MSC-B’. If the subsequent Inter-MSC handover procedure is completed successfully, the MSC-A/3G_MSC-A shall reattempt the cipher mode control procedure towards the new serving radio network or MSC-B’/3G_MSC-B, if ciphering is to be activated.

NOTE: The message flow is shown in the perspective of 3G_MSC-B. It is assumed that RNS-A has sent the Iu-RELOCATION-REQUIRED before it received the Iu-SECURITY-MODE-COMMAND.

Figure 35ba: Collision between a subsequent Inter-MSC handover/relocation and a security mode control procedure i): successful handover/relocation

If the subsequent Inter-MSC handover/relocation procedure is unsuccessful and the UE is still served by 3G_MSC-B, the 3G_MSC-B shall reattempt the security mode procedure towards RNS-A.

NOTE: The message flow is shown in the perspective of 3G_MSC-B. It is assumed that RNS-A has sent the Iu-RELOCATION-REQUIRED before it received the Iu-SECURITY-MODE-COMMAND.

Figure 35bb: Collision between a subsequent Intra-3G_MSC-B handover/relocation and a security mode control procedure ii): unsuccessful handover/relocation

12.8.2 Interactions between handover/relocation control procedures and the RAB assignment procedure

12.8.2.1 Intra-3G_MSC-B handover/relocation

A subsequent channel assignment procedure may be requested by MSC-A/3G_MSC-A after an Inter-MSC GSM to UMTS handover or Inter-MSC SRNS relocation without circuit connection (see clauses 13.2 and 13.4). If RNS-A replies with an Iu-RAB-ASSIGNMENT-RESPONSE containing the cause value ‘Relocation Triggered’ due to an already initiated Intra-3G_MSC-B UMTS to GSM handover or Intra-3G_MSC-B SRNS relocation, the 3G_MSC-B shall not forward the result of the RAB assignment procedure to MSC-A/3G_MSC-A, but wait for the outcome of the handover/relocation procedure. If the handover/relocation procedure is completed successfully, the 3G_MSC-B shall construct an A-ASSIGNMENT-COMPLETE or Iu-RAB-ASSIGNMENT-RESPONSE message, dependent on the encapsulated protocol used on the E-interface, and forward this message to MSC-A/3G_MSC-A in the MAP-PREPARE-HANDOVER response.

NOTE: The message flow is shown in the perspective of 3G_MSC-B. It is assumed that RNS-A has sent the Iu-RELOCATION-REQUIRED before it received the Iu-RAB-ASSIGNMENT-REQUEST.

Figure 35c: Collision between a subsequent Intra-3G_MSC-B handover/relocation and a RAB assignment procedure i): successful handover/relocation

If the handover/relocation procedure is unsuccessful and the UE is still served by RNS-A, the 3G_MSC-B shall reattempt the RAB assignment procedure towards RNS-A.

NOTE: The message flow is shown in the perspective of 3G_MSC-B. It is assumed that RNS-A has sent the Iu-RELOCATION-REQUIRED before it received the Iu-RAB-ASSIGNMENT-REQUEST.

Figure 35d: Collision between a subsequent Intra-3G_MSC-B handover/relocation and a RAB assignment procedure ii): unsuccessful handover/relocation

12.8.2.2 Subsequent Inter-MSC handover/relocation

NOTE: The message flow is shown in the perspective of 3G_MSC-B. It is assumed that RNS-A has sent the Iu-RELOCATION-REQUIRED before it received the Iu-RAB-ASSIGNMENT-REQUEST.

Figure 35da: Collision between a subsequent Inter-MSC handover/relocation and a RAB assignment procedure i): successful handover/relocation

If the subsequent Inter-MSC handover/relocation procedure is unsuccessful and the UE is still served by 3G_MSC-B, the 3G_MSC-B shall reattempt the subsequent channel assignment procedure towards RNS-A.

NOTE: The message flow is shown in the perspective of 3G_MSC-B. It is assumed that RNS-A has sent the Iu-RELOCATION-REQUIRED before it received the Iu-RAB-ASSIGNMENT-REQUEST.

Figure 35db: Collision between a subsequent Inter-MSC handover/relocation and a RAB assignment procedure ii): unsuccessful handover/relocation

12.8.3 Interactions between directed retry handover procedures and the RAB assignment procedure

12.8.3.1 Intra-3G_MSC-B directed retry handover

For a description of the directed retry handover procedure see clause 14.3.

A subsequent channel assignment procedure may be requested by MSC-A/3G_MSC-A after an Inter-MSC GSM to UMTS handover or Inter-MSC SRNS relocation without circuit connection (see clauses 13.2 and 13.4). If RNS-A replies with an Iu-RAB-ASSIGNMENT-RESPONSE containing the cause value ‘Directed Retry’ and the subsequent Iu-RELOCATION-REQUIRED indicates that an Intra-3G_MSC-B directed retry handover is required, the 3G_MSC-B shall not forward the result of the RAB assignment procedure to MSC-A/3G_MSC-A, but wait for the outcome of the directed retry handover procedure. If the directed retry handover procedure is completed successfully, the 3G_MSC-B shall construct an A-ASSIGNMENT-COMPLETE or Iu-RAB-ASSIGNMENT-RESPONSE message, dependent on the encapsulated protocol used on the E-interface, and forward this message to MSC-A/3G_MSC-A in the MAP-PREPARE-HANDOVER response.

Figure 35e: Interaction between a RAB assignment procedure and a subsequent Intra-3G_MSC-B directed retry handover i): successful directed retry handover

If the directed retry handover procedure is unsuccessful and the UE is still served by RNS-A, the 3G_MSC-B may optionally take one of a number of actions:

i) send an Iu-RELOCATION-PREPARATION FAILURE to RNS-A, if an Iu-RELOCATION-COMMAND has not already been sent. Additionally 3G_MSC-B may retry the assignment procedure to RNS-A;

ii) retry the assignment procedure to RNS-A, if the failure message was returned from RNS-A. This option is additional to those for normal handover;

iii) construct an A-ASSIGNMENT-FAILURE message containing the cause value ‘Radio interface failure, reversion to old channel’ or Iu-RAB-ASSIGNMENT-RESPONSE message containing the cause value ‘Failure In The Radio Interface Procedure’, dependent on the encapsulated protocol used on the E-interface, and forward this message to MSC-A/3G_MSC-A.

12.8.3.2 Subsequent Inter-MSC directed retry handover

A subsequent channel assignment procedure may be requested by MSC-A/3G_MSC-A after an Inter-MSC GSM to UMTS handover or SRNS relocation without circuit connection (see clauses 13.2 and 13.4). If RNS-A replies with an Iu-RAB-ASSIGNMENT-RESPONSE containing the cause value ‘Directed Retry’ and the subsequent Iu-RELOCATION-REQUIRED indicates that a subsequent Inter-MSC directed retry handover is required, the 3G_MSC-B shall not forward the result of the RAB Assignment procedure to MSC-A/3G_MSC-A, but wait for the outcome of the directed retry handover procedure. 3G_MSC-B shall continue with the directed retry handover procedure as described in clause 14.3.

Figure 35f: Interaction between a RAB assignment procedure and a subsequent Inter-MSC directed retry handover i): successful directed retry handover

If the directed retry handover procedure is unsuccessful and the UE is still served by 3G_MSC-B, the 3G_MSC-B may optionally take one of a number of actions:

i) send an Iu-RELOCATION-PREPARATION FAILURE to RNS-A, if an Iu-RELOCATION-COMMAND has not already been sen. Additionally 3G_MSC-B may retry the assignment procedure to RNS-A t;

ii) retry the assignment procedure to RNS-A, if the failure message was returned from RNS-A. This option is additional to those for normal handover;