4 Out-of-Band Transcoder control functionality

23.1533GPPOut of band transcoder controlRelease 17Stage 2TS

Cellular networks depend heavily on codecs to provide their services. Codecs are necessary to compress speech in order to utilise efficiently the expensive bandwidth resources both in the radio interface and in the transmission networks.

Unnecessary transcoding of speech significantly degrades quality and, therefore, cellular systems try to avoid it for mobile-to-mobile calls when both UEs and the network support a common codec type.

Although the main reason for avoiding transcoding in mobile-to-mobile calls has been speech quality, the transmission of compressed information in the CN and CN-CN interface of the cellular network also offers the possibility of bandwidth savings. Therefore Out-of-Band Transcoder Control is not limited to mobile-to-mobile calls but can be applied for calls to or from an external network as well.

Digital cellular systems support an increasing number of codec types. As a result, in order to allocate transcoders for a call inside the network, and to select the appropriate codec type inside the UEs, signalling procedures are defined to convey the codec type selected for a call to all the affected nodes (UEs and (potential) transcoding points inside the network). Also, codec negotiation capabilities are being defined to enable the selection of a codec type supported in all the affected nodes, i.e. to resolve codec mismatch situations. This codec negotiation maximises the chances of operating in compressed mode end-to-end for mobile-to-mobile calls.

To allow transport of information in a compressed way in transmission networks, these networks make use of the transport -independent call control protocol as specified in [8] that provides means for signalling codec information, negotiation and selection of codecs end-to-end.

4.1 OoBTC Requirements

The OoBTC mechanism shall support the following:

– The capability to negotiate the preferred codec type to be used between two end nodes and to avoid the use of transcoders in the network at call set-up.

The originating UE indicates the list of its supported codec types for codec negotiation. This list shall be conveyed to the terminating MSC. The terminating UE indicates its list of supported codec types to the terminating MSC. The terminating MSC shall convey the selected codec to the originating MSC, which then indicates the selected codec to the originating UE.

Where no compatible codec type can be selected between the UEs then the default PCM coding shall be selected. Therefore, the default PCM codec shall always be included in the codec list for OoBTC. The originating MSC shall insert a transcoder in the path from the originating UE. Codec selection for the terminating UE is then performed within the terminating MSC, independently of the originating MSC.

NOTE: For a codec type supporting various modes, the described functionality shall also be applicable to negotiate the set of codec modes common to originating and terminating UEs. Other negotiations such as Initialisation and Rate control are performed at a later point in time by the Iu framing protocol.

– The capability to control the presence of transcoders in the network after call set-up.

Where a change to the call state of a transcoder free connection occurs, such that compressed speech cannot be maintained, it shall be possible to insert a transcoder or pair of transcoders where needed in the path. If this results in change to the encoding of the speech in other nodes then it shall be possible to inform the end points of this segment that the speech coding is changed. Such examples where this could occur are:

– SS interruptions (e.g. A to B call connection becomes to multiparty call connection.)

– Handover to an incompatible partner.

– Synchronisation loss

Where a change in call state as described above is temporary then it shall be possible to return to a transcoder free connection by removing the inserted transcoders and informing the endpoints that the connection has resumed to compressed speech encoding.

– The codec types comprise codecs for speech in the first phase of the present document. The transcoder control should have enough expandability to support future enhancements of codec types.

– The transcoder control procedure shall not cause a perceivable time lag in the cases of establishing transcoder free connection and reverting to normal (double transcoded) call connection in the cases described above for control of the presence of transcoders.

– The capability to insert transcoder (in cases where a TrFO connection is not possible) at the most appropriate location, i.e. to save bandwidth it should be located at the CN edge between an ATM or IP transport network and a STM network. When Transcoders are inserted, the OoBTC procedures shall provide support for TFO for inband codec negotiation and transmission of compressed speech.

When a transport network cannot maintain compressed voice then reversion to the default PCM coding shall occur. A transcoder shall be inserted at that point and OoBTC procedures terminated. TrFO link is then possible between that point and the preceding nodes.

When a Non-TrFO call reaches the UMTS CN then OoBTC procedures are initiated from that point and after codec negotiation has been performed, if compressed voice can be supported through the CN then a transcoder is inserted at the edge of the CN.

– The OoBTC signalling procedures shall be supported by the call control protocol on the Nc interface, for example codec negotiation, codec modification, codec list modification, codec renegotiation, and codec list re-negotiation. BICC CS2 (see 3GPP TS 29.205 [6]) supports such a mechanism, through the APM procedures defined by [7].

– If TMR = 3.1Khz Audio is set for incoming calls, this shall be kept if OoBTC is intiated at the edge of the PLMN.

For mobile originating calls, TMR=speech shall be used for speech calls with OoBTC. For other TMR values OoBTC shall not be used.

– The OoBTC signalling procedures shall be supported by the bearer control protocol on the Iu and Nb interfaces, for example to increase the bandwidth of the bearer (if needed) in the procedures for the codec modification.

4.2 Relationship between OoBTC and In-band TFO

OoBTC is used before call set-up to attempt to establish an UE-UE transcoder free connection. If successful the result is a saving of transcoding equipment in the path and provides a cost efficient transmission.
The In-band TFO protocol (described in [10]) is activated after call set-up only if transcoders are inserted in the path. In case two transcoders in tandem (a pair of transcoders with PCM coding between them) are able to communicate to each other (both support TFO), then the inband TFO protocol allows the transcoders to compare coding schemes. If compatible codec types exist, the transcoders are able to overwrite the PCM coding with the pure compressed speech (effectively bypassing the transcoding functions). In-band TFO provides fast fallback mechanisms in case the TFO connection can not be maintained (insertion of CCD, DTMF, tones, etc). In-band TFO provides no direct saving of transmission costs.

If the OoBTC fails to establish the TrFO and transcoders are required, then in-band TFO may be used after call set-up. Inband TFO shall be the fallback mechanism when transcoders cannot be avoided, either at set-up or during the communication phase. In-band TFO shall be used for interworking with the 2G systems (e.g. GSM) using PCM coding.

4.3 Lawful interception

The TrFO shall be maintained if the interception is made due to the lawful interception. Two decoders are needed to monitor the TrFO call.

Lawful interception shall not have any influence on the establishment or maintenance of the TrFO connection in order to avoid any audible effect in speech quality or noticeable effect in speech delay to the end users.

The existing requirements for lawful interception shall be considered, these are described in [9].