Content for TS 23.153 Word version: 18.0.0

3.1 Definitions 3.2 Abbreviations 4.1 OoBTC Requirements 4.2 Relationship between OoBTC and In-band TFO 4.3 Lawful interception
...

1 Scope p. 7

The present document specifies the stage 2 description of the Out-of-Band Transcoder Control for speech services. It describes the principles and procedures to support Transcoder Free Operation, Tandem Free Operation and the interworking between TrFO and TFO. Transcoder at the edge is also part of the present document.

The present document specifies functions, procedures and information which apply to GERAN Iu mode. However, functionality related to GERAN Iu mode is neither maintained nor enhanced.

2 References p. 7

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.

References are either specific (identified by date of publication, edition number, version number, etc.) or non specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.

[1]

TS 23.107: "QoS Concept and Architecture".

[2]

TS 24.008: "Mobile radio interface layer 3 specification Core Network Protocols -Stage 3".

[3]

TS 25.413: "UTRAN Iu Interface RANAP Signalling".

[4]

TS 25.415: "UTRAN Iu Interface User Plane Protocols".

[5]

TS 26.103: "Speech codec list for GSM and UMTS".

[6]

TS 29.205: "3rd Generation Partnership Project; Technical Specification Group CoreNetwork; Application of Q.1900 series to Bearer Independent circuit-switched core Network architecture; Stage 3".

[7]

ITU-T Recommendation Q.765.5: "Signalling system No. 7; Application transport mechanism: Bearer Independent Call Control (BICC)".

[8]

TS 23.205: "Bearer-independent CS Core Network.".

[9]

TS 33.106: "3GPP Security; Lawful Interception Requirements".

[10]

TS 28.062: "Inband Tandem Free Operation (TFO) of Speech Codecs; Service Description; Stage 3".

[11]

TS 23.009: "Handover Procedures".

[12]

TS 29.232: "Media Gateway Controller (MGC) - Media Gateway (MGW) interface; Stage 3".

[13]

ITU-T H.248: "Gateway Control Protocol".

[14]

TS 29.415: "Customised Applications for Mobile network Enhanced Logic (CAMEL) Phase 3; CAMEL Application Part (CAP) specification".

[15]

TS 48.008: "Mobile-services Switching Centre - Base Station System (MSC - BSS) interface; layer 3 specification"

[16]

TS 43.051: "Technical Specification Group GSM/EDGE; Radio Access Network; Overall description - Stage 2; "

[17]

TS 23.172: "Technical realization of Circuit Switched (CS) multimedia service; UDI/RDI fallback and service modification - Stage 2".

[18]

TS 34.108: "Common test environments for User Equipment (UE) conformance testing".

[19]

TS 29.007: "General requirements on interworking between the Public Land Mobile Network (PLMN) and the Integrated Services Digital Network (ISDN) or Public Switched Telephone Network (PSTN)".

[20]

TS 23.231: "SIP-I Based Circuit-Switched Core Network; Stage 2".

[21]

TS 29.231: " Application of SIP-I Protocols to Circuit Switched (CS) core network architecture; Stage 3".

[22]

RFC 4733 "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals".

[23]

RFC 3389: " Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)".

[24]

RFC 3264: "An Offer/Answer Model with the Session Description Protocol (SDP)".

[25]

RFC 4040: "RTP Payload Format for a 64 kbit/s Transparent Call"

[26]

ITU-T Recommendation T.38: "Procedures for real-time Group 3 facsimile communication over IP networks"

[27]

RFC 3362: "Real-time Facsimile (T.38) - image/t38 MIME Sub-type Registration"

3 Definitions and abbreviations p. 8

3.1 Definitions p. 8

For the purposes of the present document, the following definitions apply:

Codec:

device to encode information from its original representation into an encoded form and to decode encoded information into its original representation

Codec Lists, Selected Codecs:

The OoBTC procedures pass a number of codec lists created by comparing the capabilities of the different nodes or equipment involved. For the different interfaces involved during call setup, handover, and relocation, the following codec lists and selected codecs need to be distinguished - where codec lists are ordered, "ordered" is included in the description:

Supported Codecs List (DTAP) - this is the list of codecs supported by the UE. It is subdivided into codecs supported for the currently used radio access and codecs that can be used for other radio accesses supported by the UE. The list contains only the codec types, but not the individual configuration, as the UE is mandated to support all configurations for a given codec type.
Supported Codecs List (BSSMAP) - "BSC-SCL" - this is the list of codecs supported by the BSS (BSS-SCL). The list contains the codec types as well as the individual codec configurations supported by the radio access at the very moment of call setup.
Supported Codecs List (BICC) - this ordered list is used on NNI (BICC) OoBTC signalling. At call setup it is sent forward by the node originating the OoBTC signalling and contains the default PCM codec and a set of codecs that is common to the nodes and the equipment involved in setting up the call. For a mobile originating call, these are the UE and the MGWs involved in the connection and, for UTRAN, GERAN Iu-mode and GERAN AoIP mode, also the originating radio access. At inter-MSC relocation and inter-MSC handover, the Supported Codecs List (BICC) is sent forward by the anchor MSC towards the target MSC and contains the default PCM codec and a set of codecs that is common to the anchor MSC and the nodes involved in setting up the new call leg towards the target MSC. For UDI/RDI multimedia calls with fallback and service change according to TS 23.172, the multimedia dummy codec will be included (see TS 26.103).
Available Codecs List (BICC) - this is the list of codecs available for the NNI connection. It is returned in the backward signalling to the node that originated the OoBTC and is a subset of the Supported Codecs List (BICC) sent forward. At call setup the Available Codecs List (BICC) contains the default PCM codec and a common set of codecs that can be supported by all nodes and, if Transcoder Free Operation has been achieved end-to-end, also by the UEs and the radio access networks that are involved in the call. At inter-MSC relocation and inter-MSC handover to UMTS, the Available Codecs List (BICC) contains the default PCM codec and a set of codecs that can be supported by all nodes involved in setting up the new call leg towards the target MSC and, if Transcoder Free Operation can be maintained end-to-end after the handover or relocation, also by the UE and the target radio access network.
Selected Codec (BICC) - this is the codec selected to be used on the NNI connection. It is one of the codecs contained in the Available Codecs List (BICC) and may be different from the codec that is used on the radio interface, but if end-to-end Transcoder Free Operation has been achieved, this will be the common codec for all nodes, the UEs, and the radio accesses.
Iu-Supported Codecs List (MAP) - this ordered list is used for MAP signalling from the anchor MSC to the target MSC. It is subdivided into lists for UTRAN and GERAN Iu-mode and contains the codecs common to the UE and to the anchor MGW for each radio access supported by the UE. The codec capabilities of the serving radio access, i.e. the radio access used prior to the inter-MSC handover or relocation, are not taken into account. Codecs that are only applicable to the NNI, e.g. the default PCM codec or the multimedia dummy codec (see TS 26.103), are not included.
Iu-Available Codecs List (MAP) - this is the list of codecs available for the target Iu interface. When returned by the target MSC to the anchor MSC in response to an initial Prepare Handover message it is the Iu-Supported Codecs List (MAP) reduced according to the capabilites of the target MGW and the target radio access. After a subsequent intra-MSC handover or relocation, the target MSC may update the Iu-Available Codecs List (MAP) according to the capabilites of its associated MGW and the new target radio access, if necessary.
Iu-Selected Codec (MAP) - this is the codec selected for the target Iu interface. It is one of the codecs contained in the Iu-Available Codecs List (MAP). In response to a Prepare Handover request message this is the codec selected by the target MSC and indicated back to the anchor MSC. When sent from the anchor MSC in a Forward Access Signalling request message during a codec modification, it contains the codec type and configuration chosen by the anchor MSC.
Iu-Currently Used Codec (MAP) - this is the codec in use on the serving Iu interface prior to an inter-MSC handover.
TFO Codec List (H.248) - this is the list of codecs for use by the MGW during TFO in-band negotiations with a distant node. The list is passed via the Mc interface from the server to the MGW. The first entry of the TFO Codec List (H.248) is to be used by the MGW as the 'Local Used Codec' (see [10]).
Distant Codec List (H.248) - this is the list of codecs received by the MGW from a distant node during TFO in-band negotiations. The list is passed via the Mc interface from the MGW to the server. The first entry of the Distant Codec List (H.248) is the 'Distant Used Codec' received by the MGW (see [10]).
Codec (H.248) - this is the codec for use on a certain MGW termination. It is passed via the Mc interface from the server to the MGW.
MSC Preferred Codec List (BSSMAP) - "MSC-PCL" - this is the list of codecs supported by both the MSC and the MS as allowed by the MSC for this assignment or handover, ordered by the MSC with the most preferred Codec Types first (e.g. the ones that may enable TrFO or TFO).
AoIP-Supported Codecs List (Anchor) (MAP) - this ordered list is used for MAP signalling from the anchor MSC to the target MSC if anchor MSC supports GERAN AoIP mode. It contains codecs supported by the UE and by the anchor MSC for GSM access. Codecs that are only applicable to the NNI, e.g. the default PCM codec or the CSData Dummy Codec (see TS 26.103), are not included.
AoIP-Selected Codec (Target) (MAP) - the codec selected by the target BSS, to be used by the UE/MS in GERAN A/Gb mode after the handover to the BSS using A interface over IP. This is the Speech Codec (BSS chosen) as returned by the Target BSS in BSSAP.
AoIP-Available Codecs List (MAP) - a list of codecs for GERAN A/Gb mode available for the target AoIP interface signalled via MAP. This is the Codec List (BSS Supported) returned by the Target BSS in BSSAP reduced according to the capabilities of the Target MSC.

Within the ordered codec lists, the codecs are ordered in decreasing order of priority, the first entry in the list being the highest priority codec (preferred codec).

Tandem Free Operation:

configuration of a connection with two transcoders that support TFO protocol and whose external coding schemes are compatible, thus enabling compressed speech to pass between them

Transcoder:

device to change the encoding of information from one particular encoding scheme to a different one, most commonly to/from a compressed speech algorithm from/to PCM.

Transcoder Free Operation:

configuration of a speech or multimedia call for which no transcoder device is physically present in the communication path and hence no control or conversion or other functions can be associated with it

Out of Band Transcoder Control:

capability of a system to negotiate the types of codecs and codec modes on a call per call basis through out-of-band signalling, required to establish Transcoder Free Operation.

Default PCM Codec:

network default 64kb/s codec for speech in PCM domain

Transcoding free link (TrFL):

bearer link, where compressed voice is being carried between bearer endpoints

Tandem free link (TFOL):

bearer link between transcoders that are operating in Tandem Free Operation mode, i.e. bypassing the transcoding functions

Transcoder free operation (TrFO):

calls that have no transcoders involved in the connection between the source codecs

Tandem free and Transcoding free operation (TaTrFO):

concatenation of "transcoding free links" and "tandem free links"

Iu Framing:

framing protocol used for the speech packets on both the Iu User Plane interface and the Nb User Plane interface

In addition, the definitions of ACS, SCS, OM, and MACS provided in [5] apply.

Direct Codec:

is a codec that can be used without any additional transcoding stage inserted at the MGW that is offering the codec list. E.g., a direct codec can be AMR or another mobile codec when the end terminal is a mobile station, or G.711 when interworking with the PSTN.

Indirect Codec:

is a codec that requires transcoding at the MGW providing the codec list.

Auxiliary RTP payload type:

is a payload type used in combination with a speech codec to transmit some non-spech audio via RTP. The Telephony Event RTP Payload Type and the , Comfort Noise Codec are the only "Auxiliary" RTP payload type defined in the present Release.

3.2 Abbreviations p. 11

For the purposes of the present document, the abbreviations defined in GSM 01.04 and the following apply:

ACS

Active Codec mode Set

APM

Application Transport Mechanism

Bearer Control

BICC

Bearer Independent Call Control

Call Control

CCD

Conference Call Device

CFNRc

Call Forward Not Reachable

CFNRy

Call Forward on No Reply

EVS

Enhanced Voice Services

Intelligent Network

IuFP

Iu Framing Protocol

MACS

Maximal number of codec modes in the ACS

Optimization Mode

OoBTC

Out-of-Band Transcoder Control

QoS

Quality of Service

RAB

Radio Access Bearer

SCS

Supported Codec mode Set

TFO

Tandem Free Operation

TICC

Transport Independent Call Control

TrFO

Transcoder Free Operation

User Plane

4 Out-of-Band Transcoder control functionality p. 11

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 p. 11

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.

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 TS 29.205) 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 p. 12

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 p. 13

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