6.3 IN and Call Forward SS

23.1533GPPOut of band transcoder controlRelease 17Stage 2TS

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

In some cases, IN services (e.g. voice prompting) are triggered at CC-IN nodes that require the establishment of an UP bearer for tones or announcements to be sent to the calling party. In order to establish this bearer, it is necessary that the CC-IN node temporarily selects one codec from the codec list sent from the initiating node, and informs the initiating node about the selected codec. Afterwards, the call may continue its establishment to the another node, which may not support the selected codec but requests that another one in the list be selected instead.

A similar situation arises with the CFNRy supplementary service. A UP connection needs to be established between the originating and "provisional" terminating CC nodes to enable ringing tones to be sent to the calling party. The type of codec must be agreed prior to the establishment of the bearer connection. Afterwards, the call is redirected to another node that may not support the selected code but requests the selection of another one.

6.3.1 TrFO interworking with SS (VMSC = service interworking node)

Figure 6.3.1/1. Codec Modification in case of SS interworking

In case of supplementary service interworking, it may become necessary to apply codec modification out of band. Figure 6.3.1/1 shows the network model, that may apply for a certain set of SS’s (call deflection (CD), call forwarding on no reply (CFNRy), CF on user determined busy (CFUB), etc.). Common to these scenarios is:

– the service interworking is controlled by the VMSC (this is common to all SSs).

– MSC-T extends the call towards MSC-T’ according to the forwarded-/deflected-to-number.

An intermediate TrFO relation will in general already exist between two RNC’s (RNC-O and RNC-T in figure 6.3.1/1) before the call is diverted to another node, as the ringing tone was applied in backward direction.

In order to perform codec negotiation with the third node (MSC-T’) as well it is necessary to forward the supported codec list from MSC-O. MSC-T’ signals back the codec it selected and the available codec list. If the codec negotiation result is different from the previously performed codec negotiation between MSC-O and MSC-T, MSC-O shall be informed. MSC-O shall be able to decide based on the received modified codec type whether Iu Framing re-initialisation and bearer modification is required. This scenario is depicted in Figure 6.3.1/2 below. If no codec modification has to be applied, MSC-T(B) shall extend the UP initialisation towards MSC-T'(C), i.e. MSC-T(B) shall initialise a termination (TD) with the property Initialisation Procedure = outgoing. MSC-T’ (C) shall also initialise a termination TE with the property Initialisation Procedure = incoming. Further call handling follows the mobile to mobile call establishment (see clause 6.1).

Figure 6.3.1/2: Codec Modification for SS-interworking & UP re-initialisation

6.3.2 IN interworking (VMSC ≠ service interworking node)

Figure 6.3.2/1. Codec Modification in case of IN interworking

Common to IN interworking scenarios is that service interworking is controlled by an IN service node that is generally not the VMSC.

IN interworking (i.e. in case of a separate IN service node, this is often a Gateway-MSC) may interrupt call establishment and apply an intermediate announcement back to the originating side. This means, that codec negotiation was in fact performed between the IN service node and the MSC-O.

When performing further call establishment, it is necessary to proceed with codec negotiation towards MSC-T. The codec negotiation process shall consider the capabilities of MGW-IN.

IN services, similar to call forwarding SS, are possible. The fact that this service interworking is controlled by an IN service node, may cause, that the leg towards MSC-T has to be released and a new leg towards MSC-T’ will be established. Codec negotiation is again necessary from MSC-IN on.

The sequence chart given in figure 6.3.1/2 applies in principle for the 1^st and the 2^nd negotiation scenarios with following modifications:

– as MSC-IN may be involved in subsequent service interworking again, the capabilities of MGW-IN shall be taken into account during codec negotiation with MSC-T or MSC-T’. This means, that the codec list forwarded to the succeeding nodes is in fact the available codec list of the 1^st negotiation.

– For the 3^rd negotiation scenario, the leg between MSC_IN(B) and MSC-T (C) has to be released and a new leg toward MSC-T'(D) has to be setup.