6.2.2 Inter-MSC SRNS Relocation

23.1533GPPOut of band transcoder controlRelease 17Stage 2TS

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

The following figures are describing inter-MSC SRNS relocation. The figures are a combination of figure 6.2/1 for intra-MSC SRNS relocation and of figures 8.4/1 and 8.4/2 in 3GPP TS 23.205 [8].

Figure 6.2/4: Configuration during inter-MSC SRNS Relocation

Figure 6.2/4 shows the configuration during inter-MSC SRNS relocation. After setting up the new I_U interface (towards RNC-A’) until releasing the old one, the original TrFO relation (A⇔B) and the target TrFO relation (A’⇔B) exist in parallel. Within the respective contexts (TBE) interworking between T4and T5 at MGW-A’ and T1, T2 and T3 at MGW-A are necessary:

T3 (MGW-A) shall perform initialisation towards MGW-A’.

T4 (MGW-A’) will receive initialisation from RNC-A’.

T5 (MGW-A’) shall hide initialisation performed on I_U,A’ from MGW-A and RNC-B.

If the option to remove the TBE was applied in MGW-A after call setup, the whole context (TBE) needs to be inserted prior to performing inter-MSC SRNS Relocation. Initialisation data need to be available within MGW-A. After Relocation, the context (TBE) may be removed again.

Figure 6.2/5: Inter-MSC SRNS Relocation and TrFO. Flow chart part 1

Note: There can be interim network transit nodes between MSC-A and MSC-A’

Figure 6.2/6: Inter-MSC SRNS Relocation and TrFO. Flow chart part 2

RAB Assignment on the new Iu leg:

A RAN side termination with IuFP property (T4 (MSC-A’)) has to be seized (step 3.) before sending Relocation Request (4.), that contains all the RAB parameters already applied on the Iu leg towards RNC-A.

MAP signalling for handover and codec negotiation

The MSC-A server shall include an Iu-Supported Codecs List and an Iu-Currently Used Codec in the MAP Prepare Handover request. When selecting the order of priority for the codecs within the Iu-Supported Codecs List, MSC-A shall take the Available Codecs List (BICC) negotiated with the far end party into account.

If the MSC-A server supports GERAN AoIP-mode then it may insert an AoIP-Supported Codecs List (Anchor) (MAP) in the MAP Prepare Handover Request message to allow MSC-A’ to use this information during a subsequent intra-MSC handover to GERAN AoIP-mode, see Clause 6.14.1.

NOTE: the full list of codec types supported by the UE and the anchor MSC for GERAN access is included in Radio Resource Information IE in MAP Prepare Handover Request message.

MSC-A’ shall include in the MAP Prepare Handover response the Iu-Selected codec and the Iu-Available Codecs List, i.e. the list of codecs available at the Iu interface in MSC-A’ after handover.

Network side bearer establishment and codec handling

The handling of the bearer establishment between MSC-A and MSC-A’ shall be performed as for a normal call with OoBTC. For a speech bearer, the MSC-A server shall perform a call set-up with codec negotiation towards the MSC-A’ server, using a Supported Codec List (BICC) containing:

a) optionally, the Iu-Selected codec (MAP) (negotiated with MSC-A’ during the MAP E-interface signalling) if it is different from list item b;

NOTE 1: This codec can be included as the preferred codec, if MSC-A knows by means of configuration information that all nodes of the network support OoBTC, or TrFO/TFO interworking and TFO, including codec mismatch resolution. If this codec does not match the Selected Codec (BICC), but is eventually selected for the network side bearer to the target MSC (MSC-A’), then either MSC-A must transcode at the anchor MGW or MSC-A will need to trigger a codec modification to the far end. Given that the anchor MSC cannot trigger all these changes at once, it must first establish the network side bearer – i.e. insert a transcoder at the anchor MGW and then trigger the codec modification to the far end as a second step.

b) the Selected codec (BICC), previously selected for the leg towards the far end party;

NOTE 2: This codec is preferred, if the anchor MSC-A does not know by means of configuration information if all nodes in the network support OoBTC, or TrFO/TFO interworking and TFO, including codec mismatch resolution. This is also the best codec to be selected if the goal is to avoid additional transcoding in MSC-A or a codec modification from MSC-A towards the far end party.

c) the default PCM codec;

d) optionally, further codecs from the Iu-Supported Codecs List (MAP) that are applicable to the target radio access, e.g. the Iu-Selected codec (MAP), if it is not already included according to list item a or b; and

e) optionally, for subsequent inter-RAT intra MSC-A’ handover further codecs from the Available Codec List (BICC) that are applicable to other radio access types.

For UDI/RDI multimedia calls with fallback and service change according to 3GPP TS 23.172 [17], the Supported Codecs List (BICC) shall contain the multimedia dummy codec and the Available Codecs List (BICC) can contain this codec (see [17], clause 4.3.7). If the MSC-A server wants to establish a bearer for the multimedia dummy codec, it shall include this codec as the preferred codec.

If MSC-A’ receives a Supported Codec List (BICC) with the IAM message, MSC-A’ shall select a codec from this list, taking the Iu-Selected codec and the priorities expressed by the order of the codecs in the Supported Codec List (BICC) into account.

NOTE 3: Usually, selection of the preferred codec of the Supported Codec List (BICC) will result in the best speech quality or best transcoder location or both; however, e.g. if MSC-A’ knows by means of configuration information that OoBTC is not supported on some links in the network, and some nodes in the network are not supporting the creation of a "structured" Supported Codec List (BICC) as specified in clause 9.7.2, MSC-A’ can select another codec, e.g. the Iu-Selected codec or the default PCM codec.

If MSC-A’ selects the default PCM codec, or if MSC-A’ receives an IAM message without a Supported Codec List (BICC), MSC-A’ shall insert a transcoder in MGW-A’.

If the Selected Codec (BICC) received by MSC-A in response to the BICC codec negotiation towards the target MSC (MSC-A’) is different from the current Selected Codec (BICC) used towards the far end, the MSC-A shall insert a transcoder in MGW-A.

MSC-A/MSC-A’ shall request seizure of network side bearer terminations with IuFP properties (see steps 10. and 12.). MSC-A’ shall send the Address Complete message only after MGW-A’ has indicated the successful initialisation of the IuFP (step 15.).

Additionally, when the bearer between MGW-A and MGW-A’ was established successfully, MSC-A may initiate a codec modification or mid-call codec negotiation as described in Annex A.

UP initialisation

RNC-A’ shall accept the requested set of codec modes and is not allowed to puncture out any negotiated mode. The INIT frames shall be according to the RAB parameters received.

MSC-A’ shall request seizure of network side bearer terminations with IuFP properties.

At reception of an INIT frame from the new RNC, the termination at MGW-A’ shall not perform forwarding of the IuFP initialisation. When the NbFP has been initialised from MGW-A towards MGW-A’, the MGW-A’ shall check whether the received RFCI allocations match the stored RFCI allocation. If it does not match, the MGW-A’ may re-initialise the IuFP towards RNC-A’ at this point in time.

Removal of TrFO Break Equipment (TBE)

If the MGW-A supports the removal of TBEs, it shall insert the TBE before seizing the additional termination. It may again remove the TBE after through-connection of the new termination and the termination to the far end party.

If the MGW-A’ supports the removal of TBEs, it may remove the TBE after performing RFCI matching and through-connection of the terminations.