6 General description of the procedures for intra – MSC handovers

23.0093GPPHandover proceduresRelease 17TS

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

This clause gives a brief overview of the procedures that shall be followed when performing Intra-MSC handovers. Detailed explanation of these procedures can be found in 3GPP TS 48.008 [5] and 3GPP TS 24.008 [10].

There are three types of GSM handover that involve a single BSS and a single MSC. These are "Internal Handover", "BSS Internal Handover with MSC Support" and" External Handover".

An "Internal Handover" takes place between channels on a cell or cells controlled by a single BSS, without reference to the MSC, although the MSC maybe informed of its occurrence after completion. This typical case can be used by the BSS e.g. if the A-Interface User Plane is not to be modified. This "Internal Handover" may take place with AoTDM or with AoIP and is not considered in the present document.

A "BSS Internal Handover with MSC Support" shall only be used if AoIP is supported by both MSC and BSS and if the A-Interface User Plane has to be modified. In that case the BSS or the MSC may initiate a "BSS Internal Handover with MSC Support" procedure as described in detail in clause 6.3 in this document.

NOTE: From Core Network perspective this "BSS Internal Handover with MSC Support" is an "External Handover", because the MSC is actively involved, although it is called "Internal Handover" in 3GPP TS 48.008, because the call stays within one BSS.

Handovers between channels on the same cell or between cells on the same BSS which are controlled by the MSC (as defined prior to the introduction of AoIP) are termed "External Handovers" and use identical procedures to those for Inter-BSS-Intra-MSC handovers. "External Handovers" are also specified with AoIP User Plane transport, for example the handover from speech to data services.Handovers from a BSS to an RNS controlled by the same 3G_MSC are intra-3G_MSC GSM to UMTS handovers. Handovers from an RNS to a BSS controlled by the same 3G_MSC are intra-3G_MSC UMTS to GSM handovers.

There are two types of handover in UMTS: soft handover and hard handover. The first one is fully performed within UTRAN, without involving the core network. The second one may be also performed within UTRAN or GERAN, or between GERAN and UTRAN, or the core network may be involved if the Iur or Iur-g interface between RNSs does not exist. This case of hard handover involving the core network is covered in the present document, together with SRNS relocation with Iur or Iur-g interface.

6.1 Procedure for Intra-MSC Handovers

The procedure for a successful External Intra-MSC handover is shown in figure 7. It is assumed that selection of a candidate MS has already taken place within the BSS based upon the criteria presented in clause 5. The exact algorithm, in the BSS, for determining a candidate MS is not addressed in the present document. The procedures discussed do not make use of the Mobile Application Part (MAP), represented by signalling function 4 in figure 2 and figure 3. The procedure described in this clause covers case i).

Figure 7: Basic External Intra-MSC Handover Procedure

The successful operation of the procedure is as follows. When the BSS (BSS-A), currently supporting the MS, determines that the MS requires to be handed over it will send an A‑HANDOVER-REQUIRED message to the MSC (MSC‑A). The A-HANDOVER-REQUIRED message shall contain a list of cells, or a single cell, to which the MS can be handed over. The list of cells shall be given in order of preference based upon operator determined criteria (These criteria are not addressed within the present document and are operator dependent). When the MSC‑A receives the A-HANDOVER-REQUIRED message it shall begin the process of handing over the MS to a new BSS (BSS-B). (NOTE: BSS-A and BSS-B maybe the same BSS). The MSC‑A shall generate an A-HANDOVER-REQUEST message to the selected BSS (BSS-B). When BSS-B receives the A‑HANDOVER-REQUEST message it shall take the necessary action to allow the MS to access the radio resource of BSS-B, this is detailed in 3GPP TS 48.058 [6] and in 3GPP TS 45.008 [4]. The switching of the radio resource through the necessary terrestrial resources is detailed in 3GPP TS 24.008 [10] and 3GPP TS 48.008 [5].

Once resource allocation has been completed by BSS-B it shall return an A-HANDOVER-REQUEST-ACK. to MSC‑A. When this message is received by MSC‑A it shall begin the process of instructing the MS to tune to a new dedicated radio resource. An A-HANDOVER-COMMAND will be sent by the MSC‑A to BSS-A. On receipt of the A-HANDOVER-COMMAND message BSS-A will send the radio interface message RI-HANDOVER-COMMAND, containing a Handover Reference number previously allocated by BSS-B, to the MS. The MS will then access the new radio resource using the Handover Reference number contained in the RI-HANDOVER-ACCESS message. The number will be checked by BSS-B to ensure it is as expected and the correct MS has been captured. If this is the correct MS then the BSS-B shall send an A-HANDOVER-DETECT to MSC‑A. When the MS is successfully communicating with the BSS-B a RI-HANDOVER-COMPLETE message will be sent by the MS to BSS-B. The BSS-B will then send an A-HANDOVER-COMPLETE message to MSC‑A.

NOTE: The A-HANDOVER-REQUEST-ACK from BSS-B contains the complete Radio Interface message that shall be sent by BSS-A to the MS in the RI-HANDOVER-COMMAND, MSC‑A transparently passes this radio interface message onto BSS‑A.

After MSC‑A has received the A-HANDOVER-COMPLETE message from BSS-B it shall begin to release the resources allocated on BSS-A. In figure 7 the resource is released by using the A‑CLEAR-COMMAND sequence.

In the case of ongoing GSM voice group calls the clearing of resources on BSS-A shall not be used if the resources are still be used on the down link.

If a failure occurs during the handover attempt, for example A-HANDOVER-FAILURE returned from BSS-A or BSS-B, then MSC‑A will terminate the handover to BSS-B. Under these conditions MSC‑A may optionally take one of a number of actions:

i) retry the handover to the same cell;

ii) select the next cell from the list contained in the A-HANDOVER-REQUIRED message and attempt a handover to the new cell;

iii) await the next A-HANDOVER-REQUIRED message;

iv) send an A-HANDOVER-REQUIRED-REJECT to BSS-A, if an A-HANDOVER-COMMAND has not already been sent.

The exact action taken is dependent on whether the failure occurs before or after the A-HANDOVER-COMMAND has been sent.

In all cases the existing connection to the MS shall not be cleared except in the case of expiry of the timer for receipt of A-HANDOVER-COMPLETE.

During the period that the MS is not in communication with the network MSC‑A shall queue all appropriate messages. All messages shall be delivered to the MS once communication is resumed . In the case of an Intra-MSC handover on MSC‑B then the messages shall be queued by MSC‑B.

In the case of ongoing GSM voice group calls if a failure occurs when handing over a user on a dedicated channel then the procedures described above may optionally be applied.

For the case of subsequent Inter-BSS Intra-MSC-B or Inter-BSS Intra-3G_MSC-B handover the following applies:

If handover to an A over IP capable BSS-B is performed, MSC-B/3G_MSC-B includes a Codec List (MSC preferred) in the A-HANDOVER-REQUEST message to BSS-B. MSC-B/3G_MSC-B may select the codecs for the Codec List (MSC preferred) from the channel type information and the AoIP-Supported Codecs List (Anchor), if this list was provided by MSC-A/3G_MSC-A in the MAP-PREPARE-HANDOVER request. For a detailed description of the handling of these codec lists by MSC-A/3G_MSC-A and MSC-B/3G_MSC-B see 3GPP TS 23.153 [25]. If the AoIP-Supported Codecs List (Anchor) was not provided or MSC‑B/3G_MSC-B does not support the selection of codecs from the AoIP-Supported Codecs List (Anchor), then MSC‑B/3G_MSC-B shall create the Codec List (MSC preferred) using the channel type information received from MSC‑A/3G_MSC-A in the A-HANDOVER-REQUEST message included in the MAP-PREPARE-HANDOVER request.

After successful completion of the Intra-MSC-B handover or Intra-3G_MSC-B handover, if MSC-B/3G_MSC-B received the AoIP-Supported Codecs List (Anchor), MSC-B/3G_MSC-B may send the new AoIP-Selected Codec (Target) and AoIP-Available Codecs List (MAP) to MSC-A/3G_MSC-A in the MAP-PROCESS-ACCESS-SIGNALLING request transporting the A‑HANDOVER-PERFORMED message, if the following conditions are fulfilled: MSC-B/3G_MSC-B created a Codec List (MSC preferred) from the AoIP-Supported Codecs List (Anchor) received from MSC-A/3G_MSC-A, the target BSS-B uses A interface over IP and BSS-B does not insert a transcoder.

6.2 Procedure for Intra-3G_MSC Handovers

6.2.1 Intra-3G_MSC Handover from UMTS to GSM

The procedure for a successful Intra-3G_MSC handover from UMTS to GSM is shown in figure 8. It is assumed that selection of a candidate UE/MS has already taken place within the RNS based upon the criteria presented in clause 5. The exact algorithm, in the RNS, for determining a candidate UE/MS is not addressed in the present document. The procedures discussed do not make use of the Mobile Application Part (MAP), represented by signalling function 4 in figures 4 and 6. The procedure described in this clause covers case ii).

Figure 8: Basic Intra-3G_MSC Handover from UMTS to GSM Procedure

6.2.1.1 With no bearer or one bearer

The successful operation of the procedure is as follows. When the RNS (RNS-A), currently supporting the UE/MS, determines that the UE/MS requires to be handed over to GSM it will send an IU-RELOCATION-REQUIRED message to the 3G_MSC (3G_MSC‑A). The IU-RELOCATION-REQUIRED message shall contain a single cell, to which the UE/MS can be handed over. When the 3G_MSC‑A receives the IU-RELOCATION-REQUIRED message it shall begin the process of handing over the UE/MS to a BSS (BSS-B). The 3G_MSC‑A shall generate an A-HANDOVER-REQUEST message to the selected BSS (BSS-B). When BSS-B receives the A‑HANDOVER-REQUEST message it shall take the necessary action to allow the UE/MS to access the radio resource of BSS-B, this is detailed in 3GPP TS 48.058 [6] and in 3GPP TS 45.008 [4]. The switching of the radio resource through the necessary terrestrial resources is detailed in 3GPP TS 24.008 [10] and 3GPP TS 08.08 [5].

Once resource allocation has been completed by BSS-B it shall return an A-HANDOVER-REQUEST-ACK. to 3G_MSC‑A. When this message is received by 3G_MSC‑A it shall begin the process of instructing the UE/MS to tune to a new dedicated radio resource. An IU-RELOCATION-COMMAND will be sent by the 3G_MSC‑A to RNS-A. On receipt of the IU-RELOCATION-COMMAND message RNS-A will send the radio resource control message RRC-HANDOVER-COMMAND, containing a Handover Reference number previously allocated by BSS-B, to the UE/MS. The UE/MS will then access the new radio resource using the Handover Reference number contained in the RI-HANDOVER-ACCESS message. The number will be checked by BSS-B to ensure it is as expected and the correct UE/MS has been captured. If this is the correct UE/MS then the BSS-B shall send an A-HANDOVER-DETECT to 3G_MSC‑A. When the UE/MS is successfully communicating with the BSS-B a RI-HANDOVER-COMPLETE message will be sent by the UE/MS to BSS-B. The BSS-B will then send an A-HANDOVER-COMPLETE message to 3G_MSC‑A.

NOTE: The A-HANDOVER-REQUEST-ACK from BSS-B contains the complete radio resource control message that shall be sent by RNS-A to the UE/MS in the RRC-HANDOVER-COMMAND, 3G_MSC‑A transparently passes this radio interface message onto RNS‑A.

After 3G_MSC‑A has received the A-HANDOVER-COMPLETE message from BSS-B it shall begin to release the resources allocated on RNS-A. In figure 8 the resource is released by using the IU-RELEASE-COMMAND sequence.

If a failure occurs during the handover attempt, for example A-HANDOVER-FAILURE returned from BSS-B, then 3G_MSC‑A will terminate the handover to BSS-B and send an IU-RELOCATION-PREPARATION-FAILURE message to RNS-A.

If RNS-A has decided to cancel the handover, it sends IU-RELOCATION-CANCEL message to 3G_MSC‑A. The 3G_MSC‑A will then terminate the handover towards BSS-B (if initiated) and send IU-RELOCATION-CANCEL- ACKNOWLEDGE message to RNS-A.

In all cases the existing connection to the UE/MS shall not be cleared except in the case of expiry of the timer for receipt of A-HANDOVER-COMPLETE.

During the period that the UE/MS is not in communication with the network 3G_MSC‑A shall queue all appropriate messages. All messages shall be delivered to the UE/MS once communication is resumed. In the case of an Intra-3G_MSC handover from UMTS to GSM on 3G_MSC‑B then the messages shall be queued by 3G_MSC‑B.

For the case of subsequent Inter-system UMTS to GSM Intra-3G_MSC-B handover the following applies:

If handover to an A over IP capable BSS-B is performed, 3G_MSC-B includes a Codec List (MSC preferred) in the A-HANDOVER-REQUEST message to BSS-B. 3G_MSC-B may select the codecs for the Codec List (MSC preferred) from the channel type information and the AoIP-Supported Codecs List (Anchor), if this list was provided by MSC-A/3G_MSC-A in the MAP-PREPARE-HANDOVER request. For a detailed description of the handling of these codec lists by MSC-A/3G_MSC-A and 3G_MSC-B see 3GPP TS 23.153 [25]. If the AoIP-Supported Codecs List (Anchor) was not provided or 3G_MSC-B does not support the selection of codecs from the AoIP-Supported Codecs List(Anchor), then 3G_MSC-B shall create the Codec List (MSC preferred) using the channel type information received from MSC-A/3G_MSC-A in the A‑HANDOVER-REQUEST message included in the MAP-PREPARE-HANDOVER request.

After successful completion of the Inter-system UMTS to GSM Intra-3G_MSC-B handover, if 3G_MSC-B received the AoIP-Supported Codecs List (Anchor), MSC-B/3G_MSC-B may send the new AoIP-Selected Codec (Target) and AoIP-Available Codecs List (MAP) to MSC-A/3G_MSC-A in the MAP-PROCESS-ACCESS-SIGNALLING request transporting the A‑HANDOVER-PERFORMED message, if the following conditions are fulfilled: 3G_MSC-B created a Codec List (MSC preferred) from the AoIP-Supported Codecs List (Anchor), the target BSS-B uses A interface over IP and BSS-B does not insert a transcoder.

6.2.1.2 With multiple bearers (Optional functionality)

If 3G_MSC-A supports the optional supplementary service Multicall (See 3GPP TS 23.135 [17]), 3G_MSC-A shall have the following functionality additionally to the description in clause 6.2.1.1.

Upon receipt of the IU-RELOCATION-REQUIRED from RNS-A 3G_MSC-A shall select one bearer to be handed over if the UE is engaged with multiple bearers. After that, 3G_MSC-A generates an A-HO-REQUEST message for the selected bearer to BSS-B.

When an A-HO-REQUEST-ACK is received from BSS-B, 3G_MSC-A sends IU-RELOCATION-COMMAND, which indicates the bearers not to be handed over as bearers to be released, to RNS-A.

After 3G_MSC-A receives A-HO-COMPLETE message from BSS-B, 3G_MSC-A shall release calls via BSS-B, which has been carried by the bearers not to be handed over, and then sends IU-RELEASE-COMMAND to RNS-A.

6.2.2 Intra-3G_MSC GSM to UMTS Handover

The procedure for a successful Intra-3G_MSC handover is shown in figure 9. It is assumed that selection of a candidate UE/MS has already taken place within the BSC based upon the criteria presented in clause 5. The exact algorithm, in the BSC, for determining a candidate UE/MS is not addressed in the present document. The procedures discussed do not make use of the Mobile Application Part (MAP), represented by signalling function 4 in figures 4 and 6. The procedure described in this clause covers case ii).

In case of subsequent handover the following applies. If 3G_MSC-B supports location reporting at change of Service Area and if encapsulated BSSAP signalling is used on the E-interface, 3G_MSC-B shall always initiate the Location Reporting Control procedure at change of Service Area towards the target RNS since no request for Location Reporting can be received from MSC-A. In that case, the Location Reporting Control procedure shall be initiated by 3G_MSC-B after the Relocation Resource Allocation procedure has been executed successfully.

The change of Service Area shall be reported to MSC-A within an A-HANDOVER-PERFORMED message.

In the case of ongoing voice group calls, the handover does not take place since voice group calls are not supported in UMTS.

Figure 9: Basic External Intra-3G_MSC GSM to UMTS Handover Procedure

The successful operation of the procedure is as follows. When the BSS (BSS-A), currently supporting the UE, determines that the UE requires to be handed over to UMTS it will send an A‑HANDOVER-REQUIRED message to the 3G_MSC (3G_MSC‑A). The A-HANDOVER-REQUIRED message shall contain a single cell, to which the UE can be handed over. When the 3G_MSC‑A receives the A-HANDOVER-REQUIRED message it shall begin the process of handing over the UE to a new RNS (RNS-B). The 3G_MSC‑A shall generate an Iu-RELOCATION-REQUEST message to the selected RNS (RNS-B). For handover of a speech call to UTRAN Iu mode, 3G_MSC-A shall include a NAS Synch Indicator in the Iu-RELOCATION-REQUEST message.

If 3G_MSC-A supports inter-system handover to a CSG cell and BSS-A includes a CSG ID for the target cell in the A-HANDOVER-REQUIRED message, then 3G_MSC-A shall check the CSG membership of the UE for the target cell as described in clause 4.3.1 before generating the Iu-RELOCATION-REQUEST message. If the UE fails the CSG membership check and the target cell is a CSG cell, 3G_MSC-A shall send an A-HANDOVER-REQUIRED-REJECT to BSS-A.

When RNS-B receives the Iu-RELOCATION-REQUEST message it shall take the necessary action to allow the UE to access the radio resource of RNS-B, this is detailed in the 3GPP TS 25.300 series and the 3GPP TS 25.200 series of 3GPP Technical Specifications. The switching of the radio resource through the necessary terrestrial resources is detailed in the 3GPP TS 25.430 series and 3GPP TS 25.413 [11].

Once resource allocation has been completed by RNS-B, it shall return an Iu-RELOCATION-REQUEST-ACK. to 3G_MSC‑A. When this message is received by 3G_MSC‑A it shall begin the process of instructing the UE to tune to a new dedicated radio resource. An A-HANDOVER-COMMAND will be sent by the 3G_MSC‑A to BSS-A. On receipt of the A-HANDOVER-COMMAND message BSS-A will send the radio interface message RI-HANDOVER-COMMAND. The UE will then access the new radio resource. On detection of the UE, the RNS-B shall send an Iu-RELOCATION-DETECT to 3G_MSC‑A. When the UE is successfully communicating with the RNS-B an RRC-HANDOVER-COMPLETE message will be sent by the UE to RNS-B. The RNS-B will then send an Iu-RELOCATION-COMPLETE message to 3G_MSC‑A.

NOTE: The Iu-RELOCATION-REQUEST-ACK from RNS-B contains the complete RRC message that shall be sent by BSS-A to the MS in the RI-HANDOVER-COMMAND, 3G_MSC‑A transparently passes this radio interface message onto BSS‑A.

After 3G_MSC‑A has received the Iu-RELOCATION-COMPLETE message from RNS-B, it shall begin to release the resources allocated on BSS-A. In figure 9 the resource is released by using the A‑CLEAR-COMMAND sequence.

If a failure occurs during the handover attempt, for example, A-HANDOVER-FAILURE returned from BSS-A or Iu‑RELOCATION FAILURE returned from RNS-B, then 3G_MSC‑A will terminate the handover to RNS-B. Under these conditions 3G_MSC‑A may optionally take one of a number of actions:

i) await the next A-HANDOVER-REQUIRED message;

ii) send an A-HANDOVER-REQUIRED-REJECT to BSS-A, if an A-HANDOVER-COMMAND has not already been sent.

The exact action taken is dependent on whether the failure occurs before or after the A-HANDOVER-COMMAND has been sent.

In all cases the existing connection to the UE shall not be cleared except in the case of expiry of the timer for receipt of Iu-RELOCATION-COMPLETE.

During the period that the UE is not in communication with the network 3G_MSC‑A shall queue all appropriate messages. All messages shall be delivered to the UE once communication is resumed. In the case of an Intra-3G_MSC GSM to UMTS handover on 3G_MSC‑B then the messages shall be queued by 3G_MSC‑B.

6.2.3 Procedure for Intra-3G_MSC SRNS Relocation

The procedure for a successful Intra-3G_MSC SRNS Relocation is shown in figures 10 and 11. For a successful Intra-3G_MSC Enhanced SRNS Relocation the procedure is shown in figures 11a and 11b. SRNS Relocation and Enhanced SRNS Relocation are used to relocate the serving RNS functionality from one RNS to another. The procedures may or may not involve change of the radio resources assigned for the corresponding UE. Whether or not the Relocation includes change of radio resources assigned for the UE does not affect the SRNS Relocation procedure or Enhanced SRNS Relocation procedure in the Core Network.

In case of subsequent Intra-3G_MSC-B SRNS relocation or Intra-3G_MSC-B Enhanced SRNS relocation the following applies:

– If 3G_MSC-B has previously received an order to perform location reporting at change of Service Area from 3G_MSC-A and if 3G_MSC-B also supports Location Reporting Control, it shall issue the Iu-LOCATION-REPORTING-CONTROL message towards the target RNS immediately after successful completion of relocation. Upon receipt of Iu-LOCATION-REPORT, 3G_MSC-B shall forward it towards 3G_MSC-A via E interface.

If 3G_MSC-B supports location reporting at change of Service Area and if encapsulated BSSAP signalling is used on the E-interface, 3G_MSC-B shall always initiate the Location Reporting Control procedure at change of Service Area towards the target RNS, since no request for Location Reporting can be received from MSC-A. In that case, if an SRNS relocation is used, the Location Reporting Control procedure shall be initiated by 3G_MSC-B after the Relocation Resource Allocation procedure has been executed successfully; otherwise 3G_MSC-B shall initiate the Location Reporting Control procedure when the completion of the Enhanced SRNS Relocation has been confirmed by the target RNS. The change of Service Area shall be reported to MSC-A within an A-HANDOVER-PERFORMED message.

It is assumed that selection of a candidate UE has already taken place within RNS based upon the criteria presenting in clause 5. The exact algorithm, in RNS, for determining a candidate UE is not addressed in the present document. The procedure discussed does not make use of the Mobile Application Part (MAP), represented by signalling function 4 in figures 4 and 6. The procedure described in this clause covers case ii).

Figure 10: Basic intra-3G_MSC SRNS Relocation Procedure

Figure 11: Basic intra-3G_MSC SRNS Relocation Procedure combined with hard change
of radio resources (Hard Handover with switch in the Core Network)

Figure 11a: Basic intra-3G_MSC Enhanced SRNS Relocation Procedure

Figure 11b: Basic intra-3G_MSC Enhanced SRNS Relocation Procedure combined with hard change
of radio resources (Hard Handover with switch in the Core Network)

6.2.3.1 With no bearer or one bearer

6.2.3.1.1 SRNS Relocation

The successful operation of the SRNS Relocation procedure is as follows. When the Serving RNS (RNS-A) makes the decision to perform the SRNS Relocation procedure it will send an IU-RELOCATION-REQUIRED message to the 3G_MSC (3G_MSC‑A). The IU-RELOCATION-REQUIRED message shall contain the identifier of the target RNS to which the Relocation is to be performed. When the 3G_MSC‑A receives the IU-RELOCATION-REQUIRED message it shall begin the process of relocating the serving RNS functionality to the new RNS (RNS-B). The 3G_MSC‑A shall generate an IU-RELOCATION-REQUEST message to the selected RNS (RNS-B). For the relocation of a speech call to UTRAN Iu mode, 3G_MSC‑A shall include the NAS Synch Indicator in the Iu-RELOCATION-REQUEST, if the Iu Selected codec to be used after the relocation is different from the Iu Currently used codec.

If 3G_MSC-A supports SRNS Relocation to a CSG cell and RNS-A includes a CSG ID for the target cell in the IU-RELOCATION-REQUIRED message, then 3G_MSC-A shall check the CSG membership of the UE for the target cell as described in clause 4.3.1 before generating the Iu-RELOCATION-REQUEST message. If the UE fails the CSG membership check and the target cell is a CSG cell, 3G_MSC-A shall send an IU-RELOCATION-PREPARATION-FAILURE to RNS-A.

When RNS-B receives the IU-RELOCATION-REQUEST message it shall take the necessary action to establish the new Iu transport bearers for each Radio Access Bearer related to 3G_MSC‑A for the UE in question, this is detailed in the 3GPP TS 25.430 series and 3GPP TS 25.413 [11].

Once resource allocation has been completed by RNS-B it shall return an IU-RELOCATION-REQUEST-ACKNOWLEDGE to 3G_MSC‑A. When this message is received by 3G_MSC‑A, and 3G_MSC‑A is ready for the move in Serving RNS functionality, it shall indicate the completion of the preparation phase on the core network side for the SRNS Relocation. An IU-RELOCATION-COMMAND message is sent by 3G_MSC‑A to RNS-A. RNS-A acts as follows:

i) if the procedure is a SRNS Relocation without change of radio resources, which means that the Iur interface between RNS-A and RNS-B can be used for the procedure, the RNS-A shall send IUR-SRNS-RELOCATION-COMMIT message to the RNS-B to trigger the Relocation execution. See figure 10.

ii) if the procedure is a SRNS Relocation with change of radio resources, which means that the Iur interface between RNS-A and RNS-B is not used for the procedure, the RNS-A shall trigger the handover procedure on the air interface by sending the RRC-HANDOVER-COMMAND to the UE. The UE will then access the new radio resources. See figure 11.

NOTE: The IU-RELOCATION-REQUEST-ACKNOWLEDGE from RNS-B may optionally contain a transparent container, which is transferred by 3G_MSC‑A to the RNS-A using the IU‑RELOCATION-COMMAND message.

When the relocation execution trigger is received, RNS-B shall then take the necessary action to assume the role of Serving RNS and shall send an IU-RELOCATION-DETECT message to 3G_MSC‑A. When the UE is successfully in communication with the RNS-B, then RNS-B shall send an IU-RELOCATION-COMPLETE message to 3G_MSC‑A.

After 3G_MSC‑A has received the IU-RELOCATION-COMPLETE message from RNS-B, it shall begin to release the resources associated to the RNS-A. In figures 10 and 11, the resources are released by using the IU‑RELEASE‑COMMAND sequence.

If a failure occurs during the SRNS Relocation attempt, then 3G_MSC‑A will terminate the relocation to RNS-B. For example, if IU-RELOCATION-FAILURE is returned from RNS-B then 3G_MSC‑A will terminate the relocation to RNS-B and send IU-RELOCATION-PREPARATION-FAILURE to RNS-A. If IU-RELOCATION-CANCEL is returned from RNS-A, then 3G_MSC‑A will terminate the relocation to RNS-B and send IU-RELOCATION-CANCEL-ACKNOWLEDGE to RNS-A.

In all cases the existing connection to the UE shall not be cleared except in the case of expiry of the timer for receipt of Iu-RELOCATION-COMPLETE.

During the period that the UE is not in communication with the network, 3G_MSC‑A shall queue all appropriate messages. All messages shall be delivered to the UE once communication is resumed. In the case of an Intra-3G_MSC SRNS Relocation (with or without change of radio resources) on 3G_MSC‑B, then the messages shall be queued by 3G_MSC‑B.

6.2.3.1.2 Enhanced SRNS Relocation

The successful operation of the Enhanced SRNS Relocation procedure is as follows. When the Serving RNS (RNS-A) makes the decision to perform the Enhanced SRNS Relocation procedure it will send an IUR-ENHANCED- RELOCATION-REQUEST message to the new RNS (RNS‑B). The IUR-ENHANCED RELOCATION-REQUEST message shall contain the necessary information to set up a CS Radio Access Bearer in RNS-B.

When RNS-B receives the IUR-ENHANCED-RELOCATION-REQUEST message it shall take the necessary actions to establish the new Iu transport bearers for the Radio Access Bearer related to 3G_MSC‑A for the UE in question, as described in detail in the 3GPP TS 25.430 series and 3GPP TS 25.413 [11], and the new transport bearers for the Radio Access Bearer related to RNS-A. to enable data forwarding. RNS-B shall initialize the Iu UP towards RNS A, if necessary.

Once resource allocation has been completed by RNS-B it shall return an IUR-ENHANCED-RELOCATION-RESPONSE message to RNC-A. If the resources cannot be allocated, RNS-B returns an IUR-ENHANCED-RELOCATION-FAILURE message to RNS-A, and RNS-A terminates the procedure.

After transmission of the IUR-ENHANCED-RELOCATION-RESPONSE message RNS-B and RNS-A act as follows:

i) If the procedure is an Enhanced SRNS Relocation without change of radio resources, RNS-B shall send an IU-ENHANCED RELOCATION-COMPLETE-REQUEST message to 3G_MSC‑A and start data fowarding towards RNS-A for UL data. After receipt of the IUR-ENHANCED-RELOCATION-RESPONSE message RNS-A shall start data forwarding towards RNS-B for DL data. See figure 11a.

ii) If the procedure is an Enhanced SRNS Relocation with change of radio resources, when RNS-A receives the IUR-ENHANCED-RELOCATION-RESPONSE message, it shall trigger the handover procedure on the air interface by sending the RRC-HANDOVER-COMMAND to the UE and start data forwarding towards RNS-B for DL data. The UE will then access the new radio resources. When the UE is successfully in communication with the RNS-B, then RNS-B shall start data forwarding towards RNS-A for UL data and send an IU-ENHANCED RELOCATION-COMPLETE-REQUEST message to 3G_MSC‑A. See figure 11b.

After 3G_MSC‑A has received the IU-ENHANCED-RELOCATION-COMPLETE-REQUEST message from RNS-B, it shall start to configure the necessary Iu resources for the RNS-B and send the IU-ENHANCED-RELOCATION-COMPLETE-RESPONSE message to RNS-B. If the necessary resources cannot be allocated or a failure occurs in 3G_MSC-A, it shall send an IU-ENHANCED-RELOCATION-COMPLETE-FAILURE message to RNS-B.

After RNC-B has received the IU-ENHANCED-RELOCATION-COMPLETE-RESPONSE message, it shall start to configure the Iu transport bearer for each Radio Access Bearer between the MSC-A and RNC-B and perform Iu UP initialization, if necessary. After the completion of the Iu UP initialization, RNS-B shall send an IU-ENHANCED-RELOCATION-COMPLETE-CONFIRM message to 3G_MSC-A.

After 3G_MSC-A has received the IU-ENHANCED-RELOCATION-COMPLETE-CONFIRM message from RNS-B, it shall begin to release the resources associated to the RNS-A. In figures 11a and 11b, the resources are released by using the IU‑RELEASE‑COMMAND sequence.

6.2.3.2 With multiple bearers (Optional functionality)

If 3G_MSC-A supports the optional supplementary service Multicall (See 3GPP TS 23.135 [17]), 3G_MSC-A shall have the following functionality additionally to the description in clause 6.2.3.1.

For SRNS Relocation, upon receipt of the IU-RELOCATION-REQUIRED from RNS-A, 3G_MSC-A generates an IU-RELOCATION-REQUEST message, which may include multiple bearers, to RNS-B.

When an IU-RELOCATION-REQUEST-ACK is received from RNS-B, 3G_MSC-A sends IU-RELOCATION-COMMAND, which indicates the bearers failed to set up in RNS-B as bearers to be released, to RNS-A.

After 3G_MSC-A receives a IU-RELOCATION-COMPLETE message from RNS-B, 3G_MSC-A shall release the calls via RNS-B, which have been carried by the bearers failed to set up in RNS-B, and then sends IU-RELEASE-COMMAND to RNS-A.

For Enhanced SRNS Relocation, RNC-A generates an IUR-ENHANCED-RELOCATION-REQUEST message, which may include multiple bearers, to RNS-B. If resources for at least one bearer are reserved in RNS-B, RNS-B shall return an IUR-ENHANCED-RELOCATION-RESPONSE message, which indicates the bearers failed to set up in RNS-B as bearers to be released, to RNC-A.

When the UE is successfully in communication with the RNS-B, then RNS-B shall send an IU-ENHANCED- RELOCATION-COMPLETE-REQUEST message, which indicates the bearers failed to set up in RNS-B as bearers to be released, to 3G_MSC‑A.

After 3G_MSC-A receives the IU-ENHANCED-RELOCATION-COMPLETE-REQUEST message from RNS-B, 3G_MSC-A shall release the calls via RNS-B, which have been carried by the bearers failed to set up in RNS-B, and then sends IU-RELEASE-COMMAND to RNS-A.

6.3 Internal Handover with MSC Support for Intra-BSS handover with AoIP

6.3.1 General Description of Internal Handover with MSC Support

If the A-Interface User Plane is carried over IP (or shall be handed over to IP) and one or more of the A-Interface User Plane parameters need to be modified, for example the Codec Type, or the Codec Configuration (BSS determines that no compatible Codec Type or Codec Configuration exists for the target cell), or the IP Transport Layer Address, or the UDP Port, or the CSData Redundancy Level, or the A-Interface Type itself (e.g. from TDM to IP or vice versa), then a "BSS Internal Handover with MSC support" shall be performed (see 3GPP TS 48.008 [5] clause 3.1.5c.1).

The "BSS Internal Handover with MSC support" for AoIP is performed by the MSC that is currently serving the connected BSS (in the following just termed "serving MSC"); it may be either MSC-A, MSC-B, 3G_MSC-A or 3G_MSC-B.

NOTE: The "BSS Internal Handover with MSC support" involves the serving MSC actively in the handover. It is therefore in average slower and more resource demanding than the BSS Internal Handover without MSC support. In order to guarantee a high radio network performance the MSC needs to react quickly and handle this handover with high priority.

The "BSS Internal Handover with MSC support" applies only if both BSS and Core Network support the AoIP procedures and messages, and an A-Interface User Plane connection has been established beforehand. The procedures and messages for this "BSS Internal Handover with MSC support" are described in 3GPP TS 48.008 [5].

The "BSS Internal Handover with MSC Support" can be initiated either:

a) by the BSS, by sending the A-INTERNAL-HANDOVER-REQUIRED message; or:

b) by the serving MSC, by sending the A-INTERNAL-HANDOVER-ENQUIRY message.

6.3.2 BSS-initiated Internal Handover with MSC Support

The BSS-initiated "BSS Internal Handover with MSC Support" starts with an A-INTERNAL-HANDOVER-REQUIRED message from the BSS to the serving MSC, for further details see 3GPP TS 48.008 [5], clause 3.1.5c. An example sequence is shown in figure 6.3.2.1

Figure 6.3.2.1: BSS-Initiated Internal Handover Execution

The A-INTERNAL-HANDOVER-REQUIRED message contains a reason for the required handover and the currently valid Codec List (BSS Supported). It shall also contain an AoIP Transport Layer Address and UDP Port, if the BSS requires an IP-based target User Plane. The Codec List (BSS supported) contains the key requirements from the BSS, like target Codec Type(s), target Codec Configuration(s) and target A-interface Type(s) (TDM and/or IP), and may contain the required Redundancy Level for CSData, etc.

When sending the A-INTERNAL-HANDOVER-REQUIRED message the BSS starts a timer "T25" (3GPP TS 48.008 [5]) and it expects an answer from the serving MSC within that timer period. If "T25" (3GPP TS 48.008 [5]) expires before the MSC has answered, then the BSS ignores any subsequent (late) answer from the serving MSC after expiry of timer "T25" (3GPP TS 48.008 [5]). The BSS will not send any new A-INTERNAL-HANDOVER-REQUIRED message before timer "T25" (3GPP TS 48.008 [5]) has expired or before the Internal Handover Preparation is terminated by other reasons.

When the serving MSC receives the A-INTERNAL-HANDOVER-REQUIRED message it shall start timer T105 (see clause 9.3A). The serving MSC shall not send any answer to the BSS after timer T105 has expired. Both timers ("T25" – 3GPP TS 48.008 [5] and T105) shall be configured (by O&M) to minimise the likelihood that the answer from serving MSC to BSS crosses with a new or repeated A-INTERNAL-HANDOVER-REQUIRED message from the BSS to the serving MSC, i.e. the timer T105 shall always expire before "T25" (3GPP TS 48.008 [5]) expires.

If the serving MSC is able to fulfil the required "BSS Internal Handover with MSC Support", then it shall generate and send an A-INTERNAL-HANDOVER-COMMAND message to the BSS and stop timer T105. This answer shall contain the exact new A-Interface User Plane parameters, e.g. Codec Type, Codec Configuration, A-Interface Type, either TDM Circuit Identity Code or IP Transport Layer Address and UDP Port (see 3GPP TS 48.008 [5]). While T25 is still running the BSS can either accept or reject the A-INTERNAL-HANDOVER-COMMAND.

When the BSS receives the A-INTERNAL-HANDOVER-COMMAND message it takes the necessary action to allow the MS to access the radio resource of the new cell in BSS, this is detailed in 3GPP TS 48.058 [6] and in 3GPP TS 45.008 [4]. The switching of the radio resource through the necessary terrestrial resources is detailed in 3GPP TS 44.018 [28] and 3GPP TS 48.008 [5]. On receipt of the A-INTERNAL-HANDOVER-COMMAND message the BSS will send e.g. the radio interface message RI-HANDOVER-COMMAND, containing a Handover Reference number previously allocated to the MS. The MS will then access the new radio resource using the Handover Reference number contained in the RI-HANDOVER-ACCESS message. The number will be checked by BSS to ensure it is as expected and the correct MS has been captured.

As BSS and MS proceed with the handover the BSS may send an A-HANDOVER-DETECT message to the serving MSC to enable fast User Plane switching on the Core Network side. As soon as the MS and BSS have completed the handover the BSS send an A-HANDOVER-COMPLETE message to serving MSC. Both BSS and serving MSC will then release the no longer needed BSS and Core Network resources.

If the serving MSC is unable to support the required Internal Handover due to whatever reason then it shall send an A-INTERNAL-HANDOVER-REQUIRED-REJECT message to the BSS (if T105 has not expired already). The serving MSC shall not send an A-INTERNAL-HANDOVER-REQUIRED-REJECT message after an A-INTERNAL-HANDOVER-COMMAND has been sent to the BSS.

If a failure occurs during the handover attempt and the BSS sends an A-HANDOVER-FAILURE message, then the serving MSC shall terminate the handover and shall revert back to using the resources used before the handover attempt was made.

The serving MSC shall supervise the "BSS Internal Handover with MSC Support" procedure after sending the A-INTERNAL-HANDOVER-COMMAND using the same timer (T102) as used for Intra-MSC handover, see clauses 9.3 and 11.3.

In all cases the existing connection to the MS shall not be cleared, except in the case of expiry of the timer T102 before receipt of A-HANDOVER-COMPLETE.

Whilst the MS is not in communication with the Core Network (i.e. in the time span between sending of A-INTERNAL-HANDOVER-COMMAND and the reception of A-HANDOVER-COMPLETE or an A-HANDOVER FAILURE) the serving MSC shall queue all appropriate messages towards the MS. All these messages shall be delivered to the MS once the communication is resumed.

For the case of subsequent Intra-BSS handover with support from MSC-B or 3G_MSC-B the following applies:

After successful completion of the Intra-BSS handover, if MSC-B/3G_MSC-B received the AoIP-Supported Codecs List (Anchor), MSC-B/3G_MSC-B may send the new AoIP-Selected Codec (Target) and AoIP-Available Codecs List (MAP) to MSC-A/3G_MSC-A in the MAP-PROCESS-ACCESS-SIGNALLING request transporting the A‑HANDOVER-PERFORMED message, if the following conditions are fulfilled: MSC-B/3G_MSC-B created a Codec List (MSC preferred) from the AoIP-Supported Codecs List (Anchor) received from MSC-A/3G_MSC-A, the BSS uses A interface over IP and the BSS does not insert a transcoder.

6.3.3 MSC-initiated BSS Internal Handover with MSC Support

During a call the MSC may request to modify the A-Interface User Plane, for example to change the Codec Type or Codec Configuration on the A-Interface to optimise end-to-end speech quality by avoiding transcoding.

The serving MSC may initiate a "BSS Internal Handover with MSC Support" by sending an A-INTERNAL-HANDOVER-ENQUIRY message to the BSS containing, within the Speech Codec (MSC Chosen) IE, the serving MSC’s preferred speech Codec Type and Codec Configuration and A-Interface Type.

If accepted by the BSS, the BSS responds with an A-INTERNAL-HANDOVER-REQUIRED message, as described in clause 6.3.2, with reason "Response to an INTERNAL HANDOVER ENQUIRY". Then the "BSS Internal Handover with MSC Support" may start.

If the BSS does not accept the A-INTERNAL-HANDOVER-ENQUIRY message, then it returns an A-HANDOVER-FAILURE message to the serving MSC.