8.3 SRNS Relocation

23.0093GPPHandover proceduresRelease 17TS

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

The following clauses describe two options for the Basic and Subsequent Relocation procedures. The first, as described in clauses 8.3.1 and 8.3.3 respectively, provides for a circuit connection between 3G_MSC‑A and 3G_MSC‑B. The second, as described in clauses 8.3.2 and 8.3.4 respectively, provides for a Basic and Subsequent Relocation without the provision of a circuit connection between 3G_MSC‑A and 3G_MSC‑B.

In all the above mentioned clauses, the following principles apply:

a) during the relocation resource allocation, except for the messages explicitly indicated in b and c below, only the relocation related messages that are part of the applicable RANAP subset – as defined in 3GPP TS 29.108 [15] – shall be transferred on the E-interface;

b) the trace related messages that are part of the applicable RANAP subset – as defined in 3GPP TS 29.108 [15] – can be sent by the 3G_MSC‑A on the E-interface after successful relocation resource allocation. In the clauses 8.3.1 and 8.3.2, it is however allowed at basic relocation initiation on the E-Interface to transfer one trace invocation related message that is part of the applicable RANAP subset – as defined in 3GPP TS 29.108 [15] – together with the applicable relocation related message. The applicable relocation related message shall always appear as the first message;

c) during the relocation resource allocation for subsequent inter-MSC SRNS relocation according to clauses 8.3.3 and 8.3.4, it is allowed to transfer either DTAP or RANAP Direct Transfer messages on the E-Interface between 3G_MSC-A and 3G_MSC-B. RANAP Direct Transfer messages shall be used for this purpose if and only if the basic handover procedure was an inter MSC SRNS relocation;

d) the Iu-Location Reporting Control message which belongs to the applicable RANAP subset – as defined in 3GPP TS 29.108 [15] – can be sent by the 3G_MSC‑A on the E-interface after successful relocation resource allocation;

e) during the relocation execution, i.e. while the UE is not in communication with the network, the 3G_MSC‑A shall queue all outgoing RANAP or BSSAP messages until the communication with the UE is resumed;

f) during the execution of a basic inter-MSC SRNS relocation to 3G_MSC-B or a subsequent inter-MSC SRNS relocation to a third 3G-MSC-B’, only the relocation related messages and the Iu-Release-Request message that are part of the applicable RANAP subset – as defined in 3GPP TS 29.108 [15] – may be sent by the target MSC on the E-interface;

g) during a subsequent inter-MSC SRNS relocation back to 3G_MSC-A or to a third 3G_MSC-B’, 3G_MSC-B may initiate either an Iu-Release-Request procedure or an A-Clear-Request procedure on the E-interface. An Iu-Release-Request procedure shall be initiated only if the basic handover procedure was an inter-MSC SRNS relocation;

h) finally, during supervision, i.e. while the UE is not in the area of 3G_MSC‑A after a successful Inter-3G_MSC relocation, the subset of RANAP procedures and their related messages – as defined in 3GPP TS 29.108 [15] – shall apply on the E-Interface. As an exception to this rule, 3G_MSC-B shall notify 3G_MSC-A of a successfully completed subsequent intra-MSC-B intra GSM or inter-system handover by using the Internal Handover Indication procedure as specified in 3GPP TS 49.008 [7]. Furthermore, in case of a subsequent inter-MSC intra GSM or inter-system handover back to 3G_MSC-A or to a third 3G_MSC-B’, during the handover resource allocation, the handover and trace related messages that are part of the applicable BSSAP subset – as defined in 3GPP TS 49.008 [7] – shall be transferred on the E-interface (see list items a and b in clause 7, clauses 8.1 and 8.2, respectively).

If a subsequent inter-MSC handover/relocation back to 3G_MSC-A or to a third 3G_MSC-B’ is cancelled, then the supervision continues, and RANAP procedures and their related messages shall apply on the E-interface.

NOTE: A subsequent inter-MSC intra GSM or GSM to UMTS inter-system handover back to 3G_MSC-A or to a third 3G_MSC-B’ can occur, e.g., if after the basic inter-MSC SRNS relocation to 3G_MSC-B the MS performed a subsequent intra-3G_MSC-B UMTS to GSM inter-system handover;

i) during the intra-3G_MSC‑B relocation execution, if any, the 3G_MSC‑B shall queue all outgoing RANAP messages until the communication with the UE is resumed.

j) after successful completion of the Intra-3G_MSC-B relocation, if 3G_MSC-B or 3G-MSC-B’ has previously received an order to perform location reporting at change of Service Area from 3G_MSC-A, it shall act as specified in clause 6.2.3.

8.3.1 Basic relocation procedure requiring a circuit connection between 3G_MSC‑A and 3G_MSC‑B

The procedure used for successful Inter-3G_MSC SRNS relocation is shown in figure 30. Initiation of the relocation procedure is described in clause 5. The procedure described in this clause makes use of messages from the 3GPP TS 25.413 [11] and of the transport mechanism from the Mobile Application Part (MAP) (3GPP TS 29.002 [12]). After an Inter-3G_MSC SRNS relocation further Intra-3G_MSC relocations may occur on 3G_MSC‑B, these relocations will follow the procedures specified in a previous clause.

NOTE 1: Can be sent at any time after the reception of IAM.

Figure 30: Basic SRNS Relocation Procedure requiring a circuit connection

8.3.1.1 With one circuit connection

The relocation is initiated as described in clause 6.2.3. (This is represented by IU-RELOC-REQUIRED in figure 30). Upon receipt of the IU-RELOC-REQUIRED from RNS-A, 3G_MSC‑A shall send a MAP-PREPARE-HANDOVER request to 3G_MSC‑B including a complete IU-RELOC-REQUEST message. (NOTE: 3G_MSC‑A shall not send further MAP-PREPARE-HANDOVER requests while a MAP-PREPARE-HANDOVER response is pending or before any timeouts). The MAP-PREPARE-HANDOVER request shall carry in the IU-RELOC-REQUEST all information needed by 3G_MSC‑B for allocating radio resources in the case of SRNS relocation without Iur interface, see 3GPP TS 25.413 [11].

For speech calls, 3G_MSC-A shall include the Iu Currently used codec and the Iu Supported Codecs List in the MAP-PREPARE-HANDOVER request. 3G_MSC‑A shall configure the RANAP RAB parameters according to the appropriate default speech codec. For a relocation to UTRAN Iu mode, if this codec is different from the Iu Currently used codec, 3G_MSC‑A shall also include the NAS Synch Indicator for the default speech codec in the Iu-RELOCATION-REQUEST.

Alternatively, if 3G_MSC-B is known to support the use of the Iu Supported Codecs List, 3G_MSC-A may configure the RANAP RAB parameters according to the preferred codec and indicate this to 3G_MSC-B by including the RAB configuration indicator in the MAP-PREPARE-HANDOVER request. For a relocation to UTRAN Iu mode, if the preferred codec is different from the Iu Currently used codec, 3G_MSC‑A shall also include the NAS Synch Indicator for the preferred codec in the Iu-RELOCATION-REQUEST. The decision to use this option is based on internal configuration information in 3G_MSC-A.

MAP-PREPARE-HANDOVER request shall also carry the identity of the target RNS to which the call is to be relocated, see 3GPP TS 29.002 [12].

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 MAP-PREPARE-HANDOVER request. 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.

If 3G_MSC-A supports SRNS Relocation to a CSG cell, the target cell belongs to the registered PLMN or an equivalent PLMN, and the HLR or the CSS provided CSG subscription data, 3G_MSC-A shall include the CSG subscription data for the registered PLMN and, if available, for the equivalent PLMNs in the MAP-PREPARE-HANDOVER request.

3G_MSC‑B will return the MAP-PREPARE-HANDOVER response after having retrieved one or several Handover Numbers from its associated VLR (exchange of the messages MAP-allocate-handover-number request and MAP-send-handover-report request). The Handover Numbers shall be used for routing the connections of the calls from 3G_MSC‑A to 3G_MSC‑B.

If A over IP is supported by 3G_MSC-A, then for speech calls 3G_MSC-A may include the AoIP-Supported Codecs List (Anchor) in the MAP-PREPARE-HANDOVER request to be used by 3G_MSC-B for subsequent intra-3G_MSC-B intersystem handover to an A over IP capable BSS. For a detailed description of the handling of this codec list by 3G_MSC-A and 3G_MSC-B see 3GPP TS 23.153 [25].

For speech calls, if 3G_MSC-B supports the selection of codec based on the Iu-Supported Codecs List, 3G_MSC‑B shall select an Iu Selected codec from the Iu Supported Codecs List and connect a transcoder. If the Iu Supported Codecs List was not received or 3G_MSC-B does not support the selection of codec based on the Iu-Supported Codecs List, 3G_MSC‑B shall select the appropriate default speech codec.

3G_MSC-B shall reconfigure the RANAP RAB parameters according to the Iu Selected codec:

– if the RAB configuration indicator is included in the MAP-PREPARE-HANDOVER request and the codec selected by 3G_MSC-B is different from the preferred codec; or

– if the RAB configuration indicator is not included in the MAP-PREPARE-HANDOVER request and the codec selected by 3G_MSC-B is different from the appropriate default speech codec.

Additionally, for a relocation to UTRAN Iu mode, if the Iu Selected codec is different from the Iu Currently used codec, 3G_MSC-B shall include the NAS Synch Indicator for the Iu Selected codec in the Iu-RELOCATION-REQUEST. If the Iu Supported Codecs List was received by 3G_MSC-B and 3G_MSC-B supports the selection of codec based on the Iu-Supported Codecs List, then the Iu Selected codec shall be indicated in the MAP-PREPARE-HANDOVER response, sent from 3G_MSC‑B to 3G_MSC‑A.

If radio resources are available in 3G_MSC‑B, the MAP-PREPARE-HANDOVER response will contain the complete IU-RELOC-REQUEST-ACKNOWLEDGE message received from RNS-B, containing the radio resources definition to be sent by RNS-A to the UE (in case of relocation without Iur interface) and possible extra RANAP information, amended by 3G_MSC‑B due to the possible interworking between the RANAP protocol carried on the E-interface and the RANAP protocol used on the Iu-interface. If the radio resource allocation is not possible, the MAP-PREPARE-HANDOVER response containing an IU-RELOCATION-FAILURE will be sent to 3G_MSC‑A. 3G_MSC‑B will do the same if a fault is detected on the identity of the RNS where the call has to be relocated. 3G_MSC‑B simply reports the events related to the dialogue. It is up to 3G_MSC‑A to decide the action to perform if it receives negative responses or the operation fails due to the expiry of the MAP-PREPARE-HANDOVER timer.

If an error related to the TCAP dialogue or to the MAP-PREPARE-HANDOVER request is returned from 3G_MSC‑B, this will be indicated to 3G_MSC‑A and 3G_MSC‑A will terminate the relocation attempt. The existing connection to the UE shall not be cleared.

When the IU-RELOC-REQUEST-ACKNOWLEDGE has been received, 3G_MSC‑A shall establish a circuit between 3G_MSC‑A and 3G_MSC‑B by signalling procedures supported by the network. In figure 30 this is illustrated by the messages IAM (Initial Address Message) and ACM (Address Complete Message) of Signalling System no 7. 3G_MSC‑B awaits the capturing of the UE (clause 6.2.3) on the radio path when the ACM is sent and 3G_MSC‑A initiates the relocation execution when ACM is received (illustrated by the IU-RELOC-COMMAND and described in clause 6.2.3). 3G_MSC‑A shall remove the transcoder between the MSC and other party.

3G_MSC‑B transfers to 3G_MSC‑A the acknowledgement received from the correct UE (IU-RELOC-DETECT/IU-RELOC-COMPLETE). The IU-RELOC-DETECT, if received, is transferred to 3G_MSC‑A using the MAP-PROCESS-ACCESS-SIGNALLING request. The IU-RELOC-COMPLETE, when received from the correct UE, is included in the MAP-SEND-END-SIGNAL request and sent back to 3G_MSC‑A. The circuit is through connected in 3G_MSC‑A when the IU-RELOC-DETECT or the IU-RELOC-COMPLETE is received from 3G_MSC‑B. The old radio resources are released when the IU-RELOC-COMPLETE message is received from 3G_MSC‑B. The sending of the MAP-SEND-END-SIGNAL request starts the MAP supervision timer for the MAP dialogue between 3G_MSC‑A and 3G_MSC‑B. When the MAP-SEND-END-SIGNAL request including the IU-RELOC-COMPLETE message is received in 3G_MSC‑A, the resources in RNS-A shall be released.

In order not to conflict with the PSTN/ISDN signalling system(s) used between 3G_MSC‑A and 3G_MSC‑B, 3G_MSC‑B must generate an answer signal when IU-RELOC-DETECT/COMPLETE is received.

3G_MSC‑B shall release the Handover Number when the circuit between 3G_MSC‑A and 3G_MSC‑B has been established.

If the circuit between 3G_MSC‑A and 3G_MSC‑B cannot be established, (e.g. an unsuccessful backward message is received instead of ACM) 3G_MSC‑A terminates the inter-3G_MSC relocation attempt by sending an appropriate MAP message, for example an ABORT.

3G_MSC‑A shall retain overall call control until the call is cleared by the fixed subscriber or the UE and there is no further call control functions to be performed (e.g. servicing waiting calls, echo cancellers).

When 3G_MSC‑A clears the call to the UE it also clears the call control functions in 3G_MSC‑A and sends the MAP-SEND-END-SIGNAL response to release the MAP resources in 3G_MSC‑B.

3G_MSC‑A may terminate the procedure at any time by sending an appropriate MAP message to 3G_MSC‑B. If establishment of the circuit between 3G_MSC‑A and 3G_MSC‑B has been initiated, the circuit must also be cleared.

The relocation will be aborted by 3G_MSC‑A if it detects release or interruption of the radio path before the call has been established on 3G_MSC‑B.

8.3.1.2 With multiple circuit connections (Optional functionality)

8.3.1.2.1 3G_MSC-B does not support multiple bearers

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 8.3.1.1.

Upon receipt of the IU-RELOCATION-REQUIRED from RNS-A, 3G_MSC-A generates IU-RELOCATION-REQUEST and sends a MAP-PREPARE-HANDOVER request to 3G_MSC-B including the IU-RELOCATION-REQUEST message, which may include multiple bearers. If 3G_MSC-A receives an indication that 3G_MSC-B does not support multiple bearers, 3G_MSC-A shall select one bearer to be handed over if the UE is engaged with multiple bearers. 3G_MSC-A reconstructs IU-RELOCATION-REQUEST and sends again a MAP-PREPARE-HANDOVER request to 3G_MSC-B including the IU-RELOCATION-REQUEST message, which includes only the selected bearer.

When MAP-PREPARE-HANDOVER response including an IU-RELOCATION-REQUEST-ACK is received from 3G_MSC-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 MAP-SEND-END-SIGNAL request from 3G_MSC-B, 3G_MSC-A shall release calls via 3G_MSC-B, which has been carried by the bearers not to be handed over, and then 3G_MSC-A sends IU-RELEASE-COMMAND to RNS-A.

8.3.1.2.2 3G_MSC-B supports multiple bearers

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

When MAP-PREPARE-HANDOVER request including an IU-RELOCATION-REQUEST message is received by the 3G_MSC-B and the number of bearers included in the IU-RELOCATION-REQUEST message has exceeded the maximum number of bearers supported by 3G_MSC-B, the 3G_MSC-B shall select several bearers so that the number of bearers will fulfil the range of 3G_MSC-B capability. In this case 3G_MSC-B shall reconstruct IU-RELOCATION-REQUEST message to cope with the capability of 3G_MSC-B. The 3G_MSC-B shall retrieve multiple Handover Numbers from its associated VLR (exchange of the messages MAP-allocate-handover-number request and MAP-send-handover-report request several times). The number of Handover Numbers depends on the number of RAB IDs in the reconstructed IU-RELOCATION-REQUEST.

After the completion of Handover Number allocation 3G_MSC-B may select several bearers and reconstruct IU-RELOCATION-REQUEST again if the number of successfully allocated Handover Numbers is less than the number of required bearers, and sends IU-RELOCATION-REQUEST to RNS-B.

After the reception of IU-RELOCATION-REQUEST-ACK from RNS-B, the 3G_MSC-B shall generate Relocation Number List, which includes couples of RAB ID (See 3GPP TS 25.413 [11]) and Handover Number successfully allocated. Then the 3G_MSC-B sends MAP-PREPARE-HANDOVER response including Relocation Number List back to the 3G_MSC-A.

Upon receipt of the MAP-PREPARE-HANDOVER response 3G_MSC-A shall establish circuits between 3G_MSC-A and 3G_MSC-B by signalling procedures supported by the network according to the Relocation Number List. When 3G_MSC-A receives all the results from attempted circuits (the results may be successful ACM message or unsuccessful backward message for each attempt) and if at least one circuit has been successfully established, 3G_MSC-A sends IU-RELOCATION-COMMAND, which indicates the bearers failed to set up in RNS-B and the bearers associated with circuits which has failed to set up as bearers to be released, to RNS-A.

After 3G_MSC-A receives MAP-SEND-END-SIGNAL request from 3G_MSC-B, 3G_MSC-A shall release calls via 3G_MSC-B, which has been carried by the bearers failed to set up in RNS-B and the bearers associated with circuits which has failed to set up, and then 3G_MSC-A sends IU-RELEASE-COMMAND to RNS-A.

If no circuit connection has been successfully established 3G_MSC-A terminates the inter-3G_MSC relocation attempt by sending an appropriate MAP massage, for example ABORT.

8.3.2 Basic relocation procedure not requiring the establishment of a circuit connection between 3G_MSC‑A and 3G_MSC‑B

The basic SRNS relocation procedures to be used when no circuit connection is required by 3G_MSC‑A are similar to those described in clause 8.3.1 for circuit switched calls. The main differences to the procedures described in clause 8.3.1 relate to the establishment of circuits between the network entities and the Handover Number allocation.

In the case of basic relocation, 3G_MSC‑A shall specify to 3G_MSC‑B that no Handover Number is required in the MAP-PREPARE-HANDOVER request (see 3GPP TS 29.002 [12]). As for the basic relocation using a circuit connection, the IU-RELOC-REQUEST is transmitted at the same time together with the identity of the target RNS to which the call is to be relocated. Any subsequent Handover Number allocation procedure will not be invoked until the completion of the basic relocation procedure (see clause: Subsequent Channel Assignment using a circuit connection). 3G_MSC‑B shall then perform the radio resources allocation as described in clause 8.3.1 if applicable. The MAP-PREPARE-HANDOVER response shall be returned to 3G_MSC‑A including either the response of the radio resources allocation request received from RNS-B (IU-RELOC-REQUEST-ACKNOWLEDGE/IU-RELOC-FAILURE with possible extra RANAP information. This extra information is amended by 3G_MSC‑B due to the possible interworking between the RANMAP protocol carried on the E-interface and the RANAP protocol used on the Iu-interface). The basic relocation procedure will continue as described in clause 8.3.1 except that no circuit connection will be established towards 3G_MSC‑B.

The relevant case for the basic relocation without circuit connection is shown in figure 31. As can be seen the major differences to the equivalent figure 30 are the omission of any circuit establishment messaging and the omission of handover number allocation signalling.

Figure 31: Basic SRNS relocation procedure without a circuit connection

8.3.3 Procedure for subsequent relocation requiring a circuit connection

After the call has been relocated to 3G_MSC‑B, if the UE leaves the area of 3G_MSC‑B during the same call, subsequent relocation is necessary in order to continue the connection when no Iur interface exists between the involved RNSs, or to optimise the transmission path when the Iur interface is used.

The following cases apply:

i) the UE moves back to the area of 3G_MSC‑A;

ii) the UE moves into the area of a third 3G_MSC (3G_MSC‑B’).

In both cases the call is switched in 3G_MSC‑A; the circuit between 3G_MSC‑A and 3G_MSC‑B shall be released after a successful subsequent relocation has been performed.

If 3G_MSC-A is replaced by MSC-A in the procedures, then a subsequent relocation from 3G_MSC-B to 3G_MSC-B’ shall not be possible since MSC-A does not support the RANAP protocol.

8.3.3.1 Description of subsequent relocation procedure i): 3G_MSC‑B to 3G_MSC‑A

The procedure for successful relocation from 3G_MSC‑B back to 3G_MSC‑A is shown in figure 32.

Figure 32: Subsequent relocation procedure i) successful relocation
from 3G_MSC‑B to 3G_MSC‑A using a circuit connection

8.3.3.1.1 With one circuit connection

The procedure is as follows.

If 3G_MSC-B supports SRNS Relocation to a CSG cell, 3G_MSC-A provided CSG subscription data during the basic inter-MSC handover/relocation, and RNS-A includes a CSG ID for the target cell in the IU-RELOCATION-REQUIRED message, then 3G_MSC-B shall check the CSG membership of the UE for the target cell as described in clause 4.4.1 before generating the MAP-PREPARE-SUBSEQUENT-HANDOVER request. If the UE fails the CSG membership check and the target cell is a CSG cell, 3G_MSC-B shall send an IU-RELOCATION-PREPARATION-FAILURE message to RNS-A.

3G_MSC‑B sends the MAP-PREPARE-SUBSEQUENT-HANDOVER request to 3G_MSC‑A indicating the new 3G_MSC number (3G_MSC‑A number), indicating also the identity of the target RNS where the call has to be relocated and including a complete IU-RELOC-REQUEST message.

For speech calls, 3G_MSC-B shall configure the RANAP RAB parameters according to the appropriate default speech codec. For a relocation to UTRAN Iu mode, if this codec is different from the Iu Currently used codec, 3G_MSC‑B shall also include the NAS Synch Indicator for the default speech codec in the Iu-RELOCATION-REQUEST.

Alternatively, if 3G_MSC-A is known to support the use of the Iu Supported Codecs List, 3G_MSC-B may configure the RANAP RAB parameters according to the preferred codec and indicate this to 3G_MSC-A by including the RAB configuration indicator in the MAP-PREPARE-SUBSEQUENT-HANDOVER request. For a relocation to UTRAN Iu mode, if the preferred codec is different from the Iu Currently used codec, 3G_MSC‑B shall also include the NAS Synch Indicator for the preferred codec in the Iu-RELOCATION-REQUEST.

NOTE: 3G_MSC‑B shall not send further MAP-PREPARE-SUBSEQUENT-HANDOVER requests while a relocation attempt is pending or before any timeouts.

Since 3G_MSC‑A is the call controlling 3G_MSC, this 3G_MSC needs no Handover Number for routing purposes; 3G_MSC‑A can immediately initiate the relocation towards the target RNS.

For speech calls, 3G_MSC‑A shall select an Iu Selected codec and connect a transcoder.

3G_MSC-A shall reconfigure the RANAP RAB parameters according to the Iu Selected codec:

– if the RAB configuration indicator is included in the MAP-PREPARE-SUBSEQUENT-HANDOVER request, and the codec selected by 3G_MSC‑A is different from the preferred codec; or

– if the RAB configuration indicator is not included in the MAP-PREPARE-SUBSEQUENT-HANDOVER request and the codec selected by 3G_MSC‑A is different from the appropriate default speech codec.

Additionally, for a relocation to UTRAN Iu mode, if the Iu Selected codec is different from the Iu Currently used codec, 3G_MSC-A shall include the NAS Synch Indicator for the Iu Selected codec in the Iu-RELOCATION-REQUEST.

When relocation can be initiated, 3G_MSC‑A shall return in the MAP-PREPARE-SUBSEQUENT-HANDOVER response the complete IU-RELOC-REQUEST-ACKNOWLEDGE message received from the RNS-B and possible extra RANAP information, amended by 3G_MSC‑A due to the possible interworking between the RANAP protocol carried on the E-interface and the RANAP protocol used on the Iu-interface. If a radio resource cannot be assigned or if a fault is detected on the target RNS identity, or the target RNS identity in the IU-RELOC-REQUEST is not consistent with the target 3G_MSC number, the MAP-PREPARE-SUBSEQUENT-HANDOVER response containing an IU-RELOC-FAILURE message shall be given to 3G_MSC‑B, in addition 3G_MSC‑B shall maintain the connection with the UE.

If the procedure in 3G_MSC‑A is successful then 3G_MSC‑B can request the UE to retune to the new RNS-B on 3G_MSC‑A in the case of relocation without Iur interface, or request RNS-B to become serving RNS in the case of relocation with Iur interface. This is illustrated in figure 32 by the IU-RELOC-COMMAND message. The operation is successfully completed when 3G_MSC‑A receives the IU-RELOC-COMPLETE message.

After relocation 3G_MSC‑A shall release the circuit to 3G_MSC‑B.

3G_MSC‑A must also terminate the MAP procedure for the basic relocation between 3G_MSC‑A and 3G_MSC‑B by sending an appropriate MAP message. 3G_MSC‑B will release the resources in RNS-A when the MAP-SEND-END-SIGNAL response is received.

8.3.3.1.2 With multiple circuit connections (Optional functionality)

Upon receipt of the IU-RELOCATION-REQUIRED from RNS-A, 3G_MSC-B generates IU-RELOCATION-REQUEST which may include several bearers and sends it to 3G_MSC-A over MAP-PREPARE-SUBSEQUENT-HANDOVER request.

3G_MSC-A sends IU-RELOCATION-REQUEST to RNS-B and receives IU-RELOCATION-REQUEST-ACK.

When MAP-PREPARE-SUBSEQUENT-HANDOVER response is received from 3G_MSC-A, 3G_MSC-B 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 IU-RELOCATION-COMPLETE message from RNS-B, 3G_MSC-A shall release calls via RNS-B, which has been carried by the bearers failed to set up in RNS-B, and then 3G_MSC-A sends MAP-SEND-END-SIGNAL response to 3G_MSC-B.

8.3.3.2 Description of subsequent relocation procedure ii): 3G_MSC‑B to 3G_MSC‑B’

The procedure for successful relocation from 3G_MSC‑B to 3G_MSC‑B’ is shown in figure 33.

The procedure consists of two parts:

– a subsequent relocation from 3G_MSC‑B back to 3G_MSC‑A as described in clause 8.3.3.1; and

– a basic relocation from 3G_MSC‑A to 3G_MSC‑B’ as described in clause 8.3.1.

8.3.3.2.1 With one circuit connection

If 3G_MSC-B 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-B shall check the CSG membership of the UE for the target cell as described in clause 8.3.3.1.1 before initiating the procedure, and reject the handover if necessary.

3G_MSC‑B sends the MAP-PREPARE-SUBSEQUENT-HANDOVER request to 3G_MSC‑A indicating a new 3G_MSC number (which is the identity of 3G_MSC‑B’), indicating also the target RNS identity and including a complete IU-RELOC-REQUEST, 3G_MSC‑A then starts a basic relocation procedure towards 3G_MSC‑B’.

Alternatively, if 3G_MSC-A and 3G_MSC-B’ are known to support the use of the Iu Supported Codecs List, 3G_MSC-B may configure the RANAP RAB parameters according to the preferred codec and indicate this to 3G_MSC-A by including the RAB configuration indicator in the MAP-PREPARE-SUBSEQUENT-HANDOVER request. For a relocation to UTRAN Iu mode, if the preferred codec is different from the Iu Currently used codec, 3G_MSC‑B shall also include the NAS Synch Indicator for the preferred codec in the Iu-RELOCATION-REQUEST. The decision to use this option is based on internal configuration information in 3G_MSC-B.

If 3G_MSC-A supports A interface over IP, then for speech calls 3G_MSC-A may include the AoIP-Supported Codecs List (Anchor) in the MAP-PREPARE-HANDOVER request towards 3G_MSC‑B’. For a detailed description of the handling of this codec list by 3G_MSC-A and 3G_MSC-B’ see 3GPP TS 23.153 [25].

When 3G_MSC‑A receives the ACM from 3G_MSC‑B’, 3G_MSC‑A informs 3G_MSC‑B that 3G_MSC‑B’ has successfully allocated the radio resources on RNS-B’ side by sending the MAP-PREPARE-SUBSEQUENT-HANDOVER response containing the complete IU-RELOC-REQUEST-ACKNOWLEDGE received from RNS-B’ and possible extra RANAP information, amended by 3G_MSC‑A due to the possible interworking between the RANAP protocol carried on the E-interface between 3G_MSC‑A and 3G_MSC‑B’ and the RANAP protocol carried on the E‑interface between 3G_MSC‑A and 3G_MSC‑B. Now 3G_MSC‑B can start the procedure on the radio path if needed.

For 3G_MSC‑A the relocation is completed when it has received the MAP-SEND-END-SIGNAL REQUEST from 3G_MSC‑B’containing the IU-RELOC-COMPLETE received from the RNS-B’. The circuit between 3G_MSC‑A and 3G_MSC‑B is released. 3G_MSC‑A also sends the MAP-SEND-END-SIGNAL response to 3G_MSC‑B in order to terminate the original MAP dialogue between 3G_MSC‑A and 3G_MSC‑B. 3G_MSC‑B releases the radio resources when it receives this message.

If no radio resource can be allocated by 3G_MSC‑B’ or no circuit between 3G_MSC‑A and 3G_MSC‑B’ can be established or a fault is detected on the target RNS identity or the target RNS identity in the IU-RELOC-REQUEST is not consistent with the target 3G_MSC number, 3G_MSC‑A informs 3G_MSC‑B by using the IU-RELOC-FAILURE message included in the MAP-PREPARE-SUBSEQUENT-HANDOVER response. 3G_MSC‑B shall maintain the existing connection with the UE.

When the subsequent relocation is completed, 3G_MSC‑B’ is considered as 3G_MSC‑B. Any further inter-3G_MSC relocation is handled as described above for a subsequent relocation.

8.3.3.2.2 With multiple circuit connections (Optional functionality)

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

Upon receipt of the IU-RELOCATION-REQUIRED from RNS-B 3G_MSC-B generates an IU-RELOCATION-REQUEST message which may include multiple bearer and sends it to 3G_MSC-A over MAP-PREPARE-SUBSEQUENT-HANDOVER request.

Upon receipt of the MAP-PREPARE-SUBSEQUENT-HANDOVER request from 3G_MSC-B, 3G_MSC-A starts a basic relocation procedure towards 3G_MSC-B’.

8.3.3.2.2.1 3G_MSC-B’ does not support multiple bearers

If 3G_MSC-A receives an indication that 3G_MSC-B’ does not support multiple bearers, 3G_MSC-A shall select one bearer to be handed over. 3G_MSC-A reconstructs IU-RELOCATION-REQUEST and sends again a MAP-PREPARE-HANDOVER request to 3G_MSC-B’ including the IU-RELOCATION-REQUEST message, which includes only the selected bearer. Upon receipt of MAP-PREPARE-HANDOVER response from 3G_MSC-B’, 3G_MSC-A shall reconstructs IU-RELOCATION-REQUEST-ACK to indicate the bearers not to be handed over as the bearers failed to set up in IU-RELOCATION-REQUEST-ACK and send it over MAP-PREPARE-SUBSEQUENT-HANDOVER response to 3G_MSC-B.

When MAP-PREPARE-SUBSEQUENT-HANDOVER response is received from 3G_MSC-A 3G_MSC-B sends IU-RELOCATION-COMMAND, which indicates the bearers failed to set up as bearers to be released, to RNS-A.

After 3G_MSC-A receives MAP-SEND-END-SIGNAL request from 3G_MSC-B’, 3G_MSC-A shall release calls via 3G_MSC-B’, which has been carried by the bearers failed to set up, and then 3G_MSC-A sends MAP-SEND-END-SIGNAL response to 3G_MSC-B.

8.3.3.2.2.2 3G_MSC-B’ supports multiple bearers

If some of circuit connections failed to set up between 3G_MSC-A and 3G_MSC-B’, 3G_MSC-A shall reconstruct IU-RELOCATION-REQUEST-ACK message so that the IU-RELOCATION-REQUEST-ACK includes only the bearers which have successfully established circuit connection and sends it to 3G_MSC-B over MAP-PREPARE-SUBSEQUENT-HANDOVER response.

When MAP-PREPARE-SUBSEQUENT-HANDOVER response is received from 3G_MSC-A 3G_MSC-B sends IU-RELOCATION-COMMAND, which indicates the bearers failed to set up as bearers to be released, to RNS-A.

NOTE 1: Can be sent at any time after the reception of IAM.

Figure 33: Subsequent relocation procedure ii) Successful SRNS relocation
from 3G_MSC‑B to 3G_MSC‑B’ requiring a circuit connection

8.3.4 Procedure for subsequent relocation not requiring a circuit connection

As for the subsequent relocation with a circuit connection between 3G_MSC‑A and 3G_MSC‑B, the same two cases of subsequent relocation apply:

i) the UE moves back to the area of 3G_MSC‑A;

ii) the UE moves into the area of a third 3G_MSC (3G_MSC‑B’).

If 3G_MSC-A is replaced by MSC-A in the procedures, then a subsequent relocation from 3G_MSC-B to 3G_MSC-B’ shall not be possible since MSC-A does not support the RANAP protocol.

8.3.4.1 Description of subsequent relocation procedure i): 3G_MSC‑B to 3G_MSC‑A

The procedure for successful relocation from 3G_MSC‑B back to 3G_MSC‑A without circuit connection is shown in figure 34. The only difference with the figure 32 is that no circuit release is needed between 3G_MSC‑A and 3G_MSC‑B.

Figure 34: Subsequent relocation procedure i) successful relocation
from 3G_MSC‑B to 3G_MSC‑B not requiring a circuit connection

8.3.4.2 Description of subsequent relocation procedure ii): 3G_MSC‑B to 3G_MSC‑B”

The procedure for successful relocation from 3G_MSC‑B to 3G_MSC‑B’ is shown in figure 35.

The procedure consists of two parts:

– a subsequent relocation from 3G_MSC‑B back to 3G_MSC‑A as described in clause 8.3.4.1; and

– a basic relocation from 3G_MSC‑A to 3G_MSC‑B’ as described in clause 8.3.2.

The only difference to the equivalent figure 33 is the omission of the circuit and handover number allocation signallings.

Figure 35: Subsequent relocation procedure ii) Successful SRNS relocation
from 3G_MSC‑B to 3G_MSC‑B’ not requiring a circuit connection