Transcoder free operation_ts_123153v080200p
2 likes2,355 views
This document defines the stage 2 specifications for out-of-band transcoder control (OoBTC) for speech services in 3GPP networks. It describes the principles and procedures to support transcoder free operation (TrFO), tandem free operation (TFO), and the interworking between TrFO and TFO. The document also covers codec negotiation using SIP for OoBTC on the Nc interface.
![3GPP TS 23.153 version 8.2.0 Release 8
1
7
ETSI TS 123 153 V8.2.0 (2009-01)
Scope
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.
2
References
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]
3GPP TS 23.107: "QoS Concept and Architecture".
[2]
3GPP TS 24.008: "Mobile radio interface layer 3 specification Core Network Protocols –Stage 3".
[3]
3GPP TS 25.413: "UTRAN Iu Interface RANAP Signalling".
[4]
3GPP TS 25.415: "UTRAN Iu Interface User Plane Protocols".
[5]
3GPP TS 26.103: "Speech codec list for GSM and UMTS".
[6]
3GPP 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]
3GPP TS 23.205: "Bearer-independent CS Core Network.".
[9]
3GPP TS 33.106: "3GPP Security; Lawful Interception Requirements".
[10]
3GPP TS 28.062: "Inband Tandem Free Operation (TFO) of Speech Codecs; Service Description;
Stage 3".
[11]
3GPP TS 23.009: "Handover Procedures".
[12]
3GPP TS 29.232: "Media Gateway Controller (MGC) – Media Gateway (MGW) interface;
Stage 3".
[13]
ITU-T H.248: "Gateway Control Protocol".
[14]
3GPP TS 29.415: "Customised Applications for Mobile network Enhanced Logic (CAMEL) Phase
3; CAMEL Application Part (CAP) specification".
[15]
3GPP TS 48.008: "Mobile-services Switching Centre – Base Station System (MSC – BSS)
interface; layer 3 specification"
[16]
3GPP TS 43.051: "Technical Specification Group GSM/EDGE; Radio Access Network; Overall
description - Stage 2; "
[17]
3GPP TS 23.172: "Technical realization of Circuit Switched (CS) multimedia service; UDI/RDI
fallback and service modification - Stage 2".
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-8-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
8
ETSI TS 123 153 V8.2.0 (2009-01)
[18]
3GPP TS 34.108: "Common test environments for User Equipment (UE) conformance testing".
[19]
3GPP 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]
3GPP TS 23.231: "SIP-I Based Circuit-Switched Core Network; Stage 2".
[21]
3GPP TS 29.231: " Application of SIP-I Protocols to Circuit Switched (CS) core network
architecture; Stage 3".
[22]
IETF RFC 4733 "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals".
[23]
IETF RFC 3389: " Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)".
[24]
IETF RFC 3264: "An Offer/Answer Model with the Session Description Protocol (SDP)".
[25]
IETF 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]
IETF RFC 3362: "Real-time Facsimile (T.38) - image/t38 MIME Sub-type Registration"
3
Definitions and abbreviations
3.1
Definitions
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:
i)
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.
ii)
Supported Codecs List (BSSMAP) - "BSC-SCL" - this is the list of codecs supported by the BSS (BSSSCL). 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.
iii)
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 Iumode 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 3GPP TS 23.172 [17], the multimedia dummy codec will be
included (see 3GPP TS 26.103 [5]).
iv)
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
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-9-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
9
ETSI TS 123 153 V8.2.0 (2009-01)
achieved end-to-end, also by the UEs and the radio access networks that are involved in the call. At interMSC 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.
v)
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.
vi)
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 3GPP TS 26.103 [5]), are not included.
vii)
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 IuAvailable Codecs List (MAP) according to the capabilites of its associated MGW and the new target radio
access, if necessary.
viii)
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.
ix)
Iu-Currently Used Codec (MAP) – this is the codec in use on the serving Iu interface prior to an inter-MSC
handover.
x)
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]).
xi)
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]).
xii)
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.
xiii)
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).
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
NOTE 1: When the TFO protocol is not supported by both transcoders or the coding schemes are not compatible
then normal "Tandem" operation occurs and PCM encoded speech is passed 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
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-10-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
10
ETSI TS 123 153 V8.2.0 (2009-01)
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
NOTE 2: For example ITU G.711 A-law.
Transcoding free link (TrFL): bearer link, where compressed voice is being carried between bearer endpoints
NOTE 3: Within the UMTS network, the compressed voice is transmitted in Iu/ Nb User Plane format, depending
on the related interface.
Tandem free link (TFOL): bearer link between transcoders that are operating in Tandem Free Operation mode, i.e.
bypassing the transcoding functions
NOTE 4: The involved transcoders can be a UMTS transcoder or a GSM TRAU with TFO functionality.
Transcoder free operation (TrFO): calls that have no transcoders involved in the connection between the source
codecs
NOTE 5: For mobile to mobile calls this is UE to UE, although the connection could be UE to another type of
terminal. TrFO operation is considered a concatenation of TrFLs between RNCs.
NOTE 6: In case of mobile to fixed network calls the term "Transcoder free operation" is applicable for the TrFLs
carrying compressed speech. The TrFO usually ends at the Gateway to the PSTN where the speech is
transcoded e.g. to G.711.
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
NOTE 7: The Iu framing protocol is specified by [4].
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
For the purposes of the present document, the abbreviations defined in GSM 01.04 and the following apply:
ACS
APM
BC
BICC
CC
CCD
CFNRc
CFNRy
IN
IuFP
MACS
OM
OoBTC
Active Codec mode Set
Application Transport Mechanism
Bearer Control
Bearer Independent Call Control
Call Control
Conference Call Device
Call Forward Not Reachable
Call Forward on No Reply
Intelligent Network
Iu Framing Protocol
Maximal number of codec modes in the ACS
Optimization Mode
Out-of-Band Transcoder Control
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-11-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
QoS
RAB
SCS
TFO
TICC
TrFO
UP
11
ETSI TS 123 153 V8.2.0 (2009-01)
Quality of Service
Radio Access Bearer
Supported Codec mode Set
Tandem Free Operation
Transport Independent Call Control
Transcoder Free Operation
User Plane
4
Out-of-Band Transcoder control functionality
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.
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-12-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
-
12
ETSI TS 123 153 V8.2.0 (2009-01)
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 renegotiation. 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.
-
4.2
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.
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.
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-13-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
13
ETSI TS 123 153 V8.2.0 (2009-01)
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].
5
General Principles
5.1
Network Model
The codec negotiation mechanism (OoBTC) is designed to work in the general situation where more than two call
control (CC) nodes need to participate in the codec negotiation. The codec negotiation mechanism works as follows:
-
Originating CC node: sends its list of supported codec types and options, listed in order of preference.
-
Transit CC nodes: if needed, analyse the received list of options, delete unsupported options from the list and
forward the list. No modification is done to the preference levels of any of the listed codecs.
-
Terminating CC node: analyse the received list of options with their associated priorities and selects the
supported option with highest indicated priority appropriate for the call.
Figure 5.1/1 illustrates the architecture for Rel-4 for UMTS to UMTS TrFO connection. The transit network may exist
for calls between PLMNs or between islands of mobile CNs separated by transit networks. This figure is a basic
illustration, OoBTC shall apply to other access technologies where the OoBTC procedures are supported, i.e. not
limited to this figure. The negotiation occurs at call set-up phase, and possibly later on in the call due to other changes
such as handover or relocation. However, as described in the next clause, it shall be possible to modify the selected
codec at any moment during the active phase of the call.
Further detail of the Call & Bearer Separation for 3GPP is described in [8].
Control
Plane
MSC
Server
RANAP
OoB Codec
Negotiation
Bearer Req
ME
RNC
User
Plane
Radio Bearer
Iu Bearer
OoB Codec
Negotiation
T
r
a
MGw
n
Control
s
i
Bearer Req
t
MGW
N
e
t
w
o
CN bearer
r
k
MSC
Server
OoB Codec
RANAP
Negotiation
MGw
Control
Bearer Req
RNC
MGW
Iu Bearer
ME
Radio Bearer
End to end connection
Figure 5.1/1. Basic Architecture for UMTS to UMTS TrFO Connection
The following clauses describe successful call establishment scenarios using the codec negotiation mechanism.
5.2
Simple call set-up
The signalling flow for the simple call set-up case is illustrated in figure 5.2/1. Codec negotiation is done prior to the
establishment of bearer connections, so that appropriate bearer resources are committed to the call. In the proposed
sequence, the codec negotiation starts with the IAM message containing the list of supported codec types (in this
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-14-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
14
ETSI TS 123 153 V8.2.0 (2009-01)
example v, w, x, y, z), sent by the Originating MSC (O-MSC). Transit nodes may puncture out (i.e. delete) codec types
from the list (in this example y). The terminating MSC (T-MSC) selects the codec type (here v) The selected codec is
conveyed in an APM message, together with the remaining list of alternative, but currently not selected codec types
(here v, x, z).
O-MSC
T-MSC
Transit
Transit
MGW
O-MGW
T-MGW
Codec List (v, w, x, y, z)
Codec List (v, w, x, z)
Selected Codec = v
Selected Codec = v, Available List (v, x, z, )
Selected Codec = v, Available
List (v, x, z, )
Selected Codec = v
Selected Codec = v
Bearer Established
Bearer Established
Figure 5.2/1. Basic Codec Negotiation Sequence
The codec list for BICC is specified according to [7], where each 3GPP codec entry is defined according to [5].
5.3
Media Gateway Control for Codec Handling
The general handling of MGW control procedures are detailed in [8]. Specific handling related to the control of the
speech encoding is detailed in Figure. 5.3/1. The terms context, termination, streams and stream properties are described
in the ITU-T H.248 "Media Gateway Control Protocol" [13].
Stream property:
Speech codec = codec y
Stream property:
Speech codec = codec x
Media Gateway
context
Termination T1
Termination T2
streams
streams
Figure 5.3/1. MGW control for speech codec
The handling of transcoding between one codec type (media stream property applied at one termination) and another
codec type (media stream property at other termination) is a function of the MGW. The media stream property for
Audio Codec Type is defined in Annex C of the ITU-T MGW control protocol, H.248.
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-15-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
15
ETSI TS 123 153 V8.2.0 (2009-01)
If TFO-incompatible codec types are applied at different terminations of the same context, the MGW shall insert a
transcoder. For the definition of TFO-compatibility between 3GPP codec types and codec configurations see [10],
clauses 11 and 12.
Between codecs of the AMR codec family, the MGW need not insert a transcoder, if the codec types are TFOcompatible according to [10], table 11-1, and
-
the codecs use the same ACS; or
-
the ACSs are TFO-compatible and the use of codec modes is restricted to a common subset of the ACSs by
means of maximum rate control. In this case the MGW shall coordinate the rate control request.
Between codecs of the AMR-WB codec family, the MGW need not insert a transcoder, if
-
the codecs use the same ACS; or
-
the use of codec modes is restricted to a common subset of the ACSs by means of maximum rate control. In this
case the MGW shall coordinate the rate control request.
5.4
UP Framing Protocol Handling for TrFO
5.4.1
Framing Protocol Initialisation
For TrFO calls the compressed speech is carried end to end (RNC to RNC or between RNC and other compressed voice
terminal). In 3GPP Core Networks compressed voice framing protocol shall be specified by the Nb User Plane
specification. The specification for Iu interface is defined in [4], the specification for the Nb interface is defined in [12].
The framing protocol for these interfaces is the same, Iu framing and is thus described as such, for both the Iu interface
and the Nb interface. For compressed voice only the support mode is used, thus for TrFO the UP Initialisation
procedure defined for the Nb UP shall be supported by the CN, when a CN MGW is required to establish a connection.
When negotiating TrFO OoB, a given serving MSC server shall consider the capabilities of the RNCs and MGWs,
which are candidates to handle the TrFO call and which are controlled by this MSC server via an Iu/Mc interface. For
TrFO, the selected RNC and MGW have to be able to support at least one Iu/Nb UP version with TrFO capabilities.
Each MGW and RNC that supports TrFO shall support Iu/Nb UP version 2. If an RNC only supports Iu UP version 1
without TrFO capabilities, the MSC server shall insert a transcoder at the MGW that is connected to this RNC. For a
TrFO call, each MSC server shall indicate in the "RAB assignment"/"Add request" only UP versions with TrFO
capabilities. In the inband UP framing protocol version negotiation during framing protocol initialisation, the informed
RNCs/MGW shall only offer and/or accept UP version listed in the "RAB assignment"/"Add request".
The Iu framing Protocol is established through the CN in a forward direction, independently of the bearer establishment
direction. The Notify message to indicate bearer establishment shall not be sent until the Iu framing has been initialised.
The continuity message (COT) shall not be sent forward until the Notify message has been received from the MGW and
also the COT from the previous server has been received. The sequences for mobile originated calls are shown in
figures 5.4/1 and 5.4/2 for forward bearer and backward bearer establishment, respectively. The parameters in the Add
Request messages in the Figures are described in further detail in clause 5.4.5.
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-16-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
17
GM SC
Initial Address
ETSI TS 123 153 V8.2.0 (2009-01)
M G-G
M SC-T
M GW -T
AD D .request (C N, incoming)
AD D .reply
Initial Address
AD D .request (C N, incoming)
Codec Information
Codec Information
AD D .request (C N, incoming)
B earer Establish
Bearer Establish
AD D.reply
AD D.reply
STO RE RFCIs,
Acknowledge Iu
Framing Protocol Init,
forw ard control PDUs
to network side of
M GW
Bearer Confirm
STORE RFCIs,
Acknowledge Iu
franing protocol Init,
forward control PDUs
to network side of
M GW
B earer Confirm
NO TIFY.req
STORE RFCIs,
Acknow ledgeIu
framing protocol
Init, terminate Iu
framing protocol.
NO TIFY.req
Continuity
Address Complete
Address Complete
Figure 5.4.1/2: Iu Framing Protocol Establishment, backward bearer.
The transport independent call control procedures in [8] shall support a continuity mechanism, as described above.
5.4.2
RFCI Storage
The RNC shall allocate RAB Subflow Combination Indicators to the SDU formats (SDU formats sent to the RNC by
the MSC in the RAB Assignment). This allocation is then sent in the Iu Framing Initialisation PDU by the RNC in the
User Plane. For further details see [3] and [4].
During the TrFO call establishment each MGW linked into the call shall store the RFCIs received from Iu Framing
PDU Type 14. The first subflow combination in the initialisation frame corresponds to an Initial Rate Control, i.e.
indicates the highest rate for the first speech mode to be used in the direction of the Initialisation Acknowledgement
frame.
After the out of band codec negotiation has been performed, if the originating side is a UTRAN, then on request from
the MSC for a RAB Assignment, it shall initiate the Iu user plane. If the originating side is a network that does not
support Iu Framing then the Iu Framing initialisation is initiated by the GMSC, as described in detail in Clause 6.7. An
Initialisation Protocol Data Unit (PDU) shall be sent to the first MGW in the call connection. Each initialisation leg is
acknowledged per TrFO Link, i.e. per MGW-MGW interface. The subsequent initialisation is performed using the same
RFCI set as received from the preceding node, independently of the Stream mode directions (i.e. if the terminations are
not through connected).
This is shown figure 5.4.2/1.
Figure 5.4.2/1: RFCI Storage and subsequent initialisation in MGW
When the MGW terminations are through-connected and the RFCIs at both terminations are matching, then the MGW
may revert to transparent mode; the RNCs shall not perform any subsequent Iu Framing initialisations without explicit
request by the serving MSCs.
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-18-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
18
ETSI TS 123 153 V8.2.0 (2009-01)
All succeeding MGWs in the path shall behave in a similar way as described above.
5.4.3
RFCI Value Correction
At the terminating end of a TrFO connection with Iu Framing initialised to the terminating MGW, the originating RFCI
allocation is stored. The terminating RNC is then requested to perform a RAB Assignment towards the terminating
MGW. This results in an Iu Framing initialisation, where the allocation of the RFCI values is independent from the
Originating RNC's allocation. These values may then be different to the originating RNC's set.
The terminating MGW shall acknowledge the Iu Framing Initialisation and compare the RFCI values stored from the
originating side. If the allocated index values do not match, then the MGW shall perform one of the following
procedures:
1) initiate an Iu Framing Initialisation PDU towards the terminating RNC with the RFCI allocation as defined
by the preceding node (previously stored in the MGW. This behavior is shown in figure 5.4.3/1 and termed
'RFCI value correction') As the first Subflow combination received from the terminating RNC corresponds to
an initial (maximum) rate control the MGW shall send a Rate Control PDUindicating this maximum speech
mode back to the preceeding node in the core-network.
2) map the RFCI indices of the incoming side to the corresponding RFCI indices at the outgoing side for all
SDUs passed between the Iu Framing protocol terminations. As the first Subflow combination in the IuUP
initialisation corresponds to an initial rate control, i.e. indicates maximum rate for the mode to be used (in
direction of Initialisation acknowledgement frame) it is treated as the initial maximum rate control (see [4])
the MGW shall initiate a Rate Control PDU indicating this maximum speech mode toward the terminating
RNC. Similarly as the first Subflow combination received from the terminating RNC corresponds to an initial
(maximum) rate control the MGW shall send a Rate Control PDUindicating this maximum speech mode
back to the preceding node in the core-network. For further details on the rate control see clause 5.7.
MGw
RNC
MGw Termination
MGw Termination
RFCIs Stored
RFCIs Stored
IU Initialisation)
RFCI’s
Match ?
NO
IU Initialisation ACK)
IU Initialisation)
IU Initialisation ACK)
Figure 5.4.3/1:RFCI Value Correction
Further details of the TrFO call establishment are described in clause 6.
This resolution handling is required also during RNC relocation; further details are described in clause 6.
5.4.4
TrFO Break
The event and procedure when a TrFO connection must be interrupted at a certain point in the path, e.g. due to a
supplementary service invocation or for handover/relocation, is termed "TrFO Break". A TrFO Break may occur at a
MGW as a consequence of a command directed by the associated Server. During this period the Iu User Plane protocol
is terminated by this MGW, in general at both sides of the MGW. This means that it must respond to new Initialisation
PDUs and Inband Rate Control PDUs. The MGW inserts a TrFO Break Function, which then makes use of the stored
RFCI values, in order to perform the required Iu Framing protocol functions and interpret the payload. Further call
scenarios for specific services that incur a TrFO break are described in clause 6..
5.4.5
TrFO Break Recovery
During the TrFO break situation the individual connections are free to change, the RFCIs may have changed and also
the rate control (maximum rate, current rate). After the service that caused the TrFO break is complete, the MGW shall
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-19-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
19
ETSI TS 123 153 V8.2.0 (2009-01)
check if TrFO.can be re-established. If the coding schemes are matching but the RFCI's have changed then RFCI value
correction can be performed at the RNC side. In order to correct any changes in rate control between two RNCs, the
MGW shall send a rate control request from each Termination, with the current rate and maximum rate applied at the
other Termination. This will then result in the Distributed Rate Decision between the two RNCs in the call.
5.4.6
MGW Control Protocol Iu Framing Package properties
The following is a summary of the Iu Framing H.248 requirements; the procedures are described in [12] and are valid
for Iu Framing in Support Mode:
Additional Package Properties:
Iu Framing Termination Type: Values -
Iu-RAN (Iu Framing Protocol on Iu Interface)
Iu Framing Initialisation Procedure:
Iu-CN
(Iu Framing Protocol on Nb Interface)
Values – Incoming (For Iu-CN: the Iu Framing Protocol initialisation is
received by the media gateway and used for subsequent initialisation from this
MGW. For Iu-RAN this indicates the originating RNC interface).
- Outgoing (For Iu-CN the Iu Framing Protocol is generated by the core
network MGW, i.e. initialised on the Nb Interface. For the Iu-RAN interface
this specifies the terminating RNC Interface)
5.5
TrFO/TFO Codec Negotiation Harmonisation
When OoBTC procedures are initiated to a node where compressed voice cannot be supported (either at the node or to
the preceding node) then a transcoder is inserted. This can be due to the transport technology (e.g. TDM) or due to the
access technology (e.g. GSM with TDM based A-interface). The OoBTC procedures can result in the following call
scenarios:
Supported Codecs List (BICC)
(X, Y, Z)
MSC
Supported Codecs List (BICC)
(Y)
ISUP
TSN
TSN
Selected Codec (BICC)
(X)
MSC
Selected Codec (BICC)
(Y)
PLMN 1
TRANSIT
PLMN 2
UTRAN
UTRAN
Codec (X)
MGW
G.711
MGW
Codec (Y)
MGW
MGW
ATM / IP
TDM
ATM / IP
Figure 5.5/1: Cascaded TrFO & Transcoding
In Figure 5.5/ 1 the OoBTC cannot proceed as the call crosses a transit network that does not support compressed voice.
The same could occur if the transit network did not support out of band codec negotiation (Support in BICC is
optional).
In Figure 5.5/2 the OoBTC procedures result in the call terminating to a TDM based GSM access. As the GSM radio
access transcodes to default PCM codec, the OoBTC results in default PCM selected. The reply is passed back to the
originating network, which then inserts a transcoder from default PCM to AMR for the UMTS radio access.
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-20-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
20
ETSI TS 123 153 V8.2.0 (2009-01)
Codec list: U-AMR, U-AMR2, PCM Codec list: U-AMR,
U-AMR2, PCM
MSC
TSN
Codec list:U-AMR, U-AMR-2
Selected = PCM
Selected = PCM
UE
MSC
Select U-AMR
UMTS
RAN
MG
MG
MG
GSM
BSS
PLMN 2
MS
PLMN 1
GSM Codecs:
e.g. GSM FR, FR AMR, EFR
Figure 5.5/2: UMTS to GSM interworking
In a similar situation to that described in Figure 5.5/2, it is also possible that the OoBTC procedures result in
UMTS_AMR_2 as the selected codec, as this is compatible with FR_AMR codec. This is the optimal codec selection
for speech quality purposes. In this case, the transcoder shall be inserted at the terminating MGW in order to transcode
between PCM and UMTS_AMR_2, and UMTS_AMR_2 shall be signalled back to the originating UE. TFO can then
be used on the terminating A-interface to allow FR_AMR to be passed between the tandemed codecs, allowing the best
speech quality in the core network.
Further to the scenario described above in Figure 5.5/2, where there is no TFO compatible codec between the UMTS
UE and the GSM MS it is also possible that the OoBTC procedures result in UMTS_AMR as the selected codec. In this
case, the transcoder shall be inserted at the terminating MGW in order to transcode between PCM and UMTS_AMR (as
an example), and UMTS_AMR shall be signalled back to the originating UE. Bandwidth savings and avoiding
degradation in speech quality are then achieved in the core network.
For TFO to establish between the transcoders in the above scenarios, each TRAU must send a codec list inband after the
call has been established. If a common codec type is available (determined by pre-defined rules, described in TFO
specification [10]) then the OoBTC procedures need to be informed so that a codec modification can be performed. This
is shown in Figure 5.5/3. Note – a modification could also be required when a common codec type has been selected but
the ACS is not common.
Supported Codecs List (BICC)
(X, Y, Z)
MSC
Selected Codec (X)
Supported Codecs List (BICC)
(Y, Z)
ISUP
TSN
TSN
MSC
Codec Modify (Z)
Codec Modify (Z)
UTRAN
TFO Codec List
(X, Y, Z)
Codec (X -> Z)
Selected Codec (Y)
Optimal Codec
( Z)
MGW
G.711
UTRAN
TFO Codec List
(Y, Z)
MGW
Codec (Y -> Z)
MGW
MGW
TFO (Z)
ATM / IP
TDM
ATM / IP
PLMN 1
TRANSIT
PLMN 2
Figure 5.5/3: TFO support by OoBTC signalling
In H.248, the vertical MG control protocol, the coding types are specified by Media Stream Property, as defined by
Annex C of H.248 specification. A specific package is used for TFO (see [12]).
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-21-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
21
ETSI TS 123 153 V8.2.0 (2009-01)
The basic requirements are listed below:
i) Property for TFO Codec List (same format as for [5])
ii) Event for Optimal Codec, as determined by TFO in-band protocol
iii) Event for Distant Codec List sent by the distant TFO partner
iv) Event for TFO status
v) Procedures to define and enable TFO
The TFO package allows the Server to request the MGW to initiate the TFO in-band protocol towards a far end
transcoder. The package includes a property to turn on/off the TFO (tfoenable); this may be required prior to TrFO
break situations such as handover.
The TFO Codec List (H.248) is passed via the Mc interface from the Server to the MGW. The first entry of the TFO
Codec List (H.248) shall be used by the MGW as the 'Local Used Codec'. The other entries of the TFO Codec List
(H.248) shall be used by the MGW as Local Codec List in the TFO in-band negotiation (see [10]). For adaptive multirate codecs (AMR and AMR-WB codecs) some control of the level of negotiation is performed by the "Optimization
Mode" parameter in the respective Single Codec information element in the TFO Codec List (H.248) (see [5] and [12]).
This allows a node to indicate if the offered ACS may be modified or not during TFO procedures, and this is mapped to
the appropriate parameter in the TFO protocol by the MGW. If for a Single Codec information element in the TFO
Package from the Server to the MGW the OM is set to "Optimization of the ACS not supported", then the TFO
Negotiation shall not change the offered ACS of the respective Single Codec information element.
The MGW returns Notification Events for the Distant Codec List sent by the far end and the Optimal Codec Type as
selected by the Codec Selection mechanism in TFO. The first entry of the Distant Codec List (H.248) is the 'Distant
Used Codec' as received by the MGW during TFO in-band negotiations. The other entries of the Distant Codec List
(H.248) are the entries of the Distant Codec List as received by the MGW from the distant TFO Partner (see [10]). The
Server then compares the Distant Codec List (H.248) with its previously negotiated Available Codec List (BICC). If the
lists are not the same then an OoBTCCodec List Modification or Mid-call Codec Negotiation may be performed. If for
a Single Codec information element in the TFO Package from the MGW to the Server the OM is set to "Optimization of
the ACS not supported", then the offered ACS of the respective Single Codec information element shall not be changed
during OoBTC procedures.
If the TFO Status event is supported by the MGW and has been configured by the MSC Server, the MGW shall return
notification indicating whether a TFO link has been established or broken. The MGW should not report transient TFO
status change.
5.6
CN Node handling of Codec Types & Codec Modes
5.6.1
Signalling between UE and MSC
The default Codec Type for 'R99 UMTS only' terminals is UMTS_AMR, the default Codec Type for all terminals
supporting GSM and UMTS radio access is UMTS_AMR_2, (see [5] for the detailed description). The UMTS_AMR_2
is a superset of the UMTS_AMR. It behaves as a FR_AMR codec in the UL and as a UMTS_AMR codec in the DL.
This allows all UMTS terminals, except R99 UMTS only terminals, to operate in TFO with GSM terminals. The
UMTS_AMR_2 is fully compatible with R99 CN nodes (TC in MGW). In any multi-mode configuration the
UMTS_AMR shall be treated as only TFO and TrFO compatible to itself, not to any other AMR codec Type, to avoid
incompatibilities in TFO-TrFO-TFO interworking scenarios. In single mode configuration, UMTS_AMR and
UMTS_AMR_2 are TFO and TrFO compatible, when both codec types use the same single rate ACS, (see [10]).
During call setup, a UE supporting Rel-4 or later releases will indicate to the MSC the codecs supported by the UE in
the Supported Codecs List (DTAP) (see [2]). For the codecs in this Supported Codecs List (DTAP), no order of priority
is defined.
If no Supported Codecs List (DTAP) is received and the UE is 'UMTS only', then the MSC shall assume UMTS_AMR
as supported Codec Type. If no Supported Codecs List (DTAP) is received, but the UE is 'dual system', then the MSC
shall assume UMTS_AMR_2 as the supported codec type. The MSC shall assume 'dual system' support only if the UE
indicates at least one GSM speech version in Octet 3a etc. of the Bearer Capability.
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-22-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
5.6.2
22
ETSI TS 123 153 V8.2.0 (2009-01)
Node originating the OoBTC codec negotiation
The node originating the OoBTC codec negotiation shall implement the procedures described in Q.1902.4, subclause
8.3.1 [6]. Additionally, the following applies:
In UTRAN, GERAN Iu mode or GERAN AoIP mode, when constructing the list of codecs (and configurations for
AMR or AMR-WB codecs) for the Supported Codecs List (BICC), the MSC Server should take the codec types and
codec configurations supported by the RNC or BSC into account (see subclause 5.6.6 for UTRAN or GERAN Iu mode
and section 5.6.7 for GERAN AoIP mode). The MSC may include more than one Single codec element indicating the
same codec type, but different configurations, in the Supported Codecs List (BICC) (see [5]).
NOTE:
This may be necessary, e.g. if the RNC supports for an AMR codec different sets of codec modes, e.g., (a,
b, c, d) and (e, f, g), which are not subsets of each other, and the RNC does not support combinations of
these sets, e.g. (a, b, c, d, e, f, g).
For AMR codecs the originating CN node shall use the "Optimization Mode" parameter in the Single Codec
information element in the Supported Codec List (BICC) (see [5]) to indicate whether or not other nodes may change
the offered ACS.
EXAMPLE:
An RNC implementing only the prioritised RABs for interoperability testing specified in [18] will
support for the UMTS_AMR_2 codec e.g. the set of codec modes (12.2, 7.4, 5.9, 4.75), but none
of its subsets containing 2 or 3 codec modes. If the MSC Server connected to this RNC includes
the codec configuration (12.2, 7.4, 5.9, 4.75) in the Supported Codecs List (BICC), it will
therefore set the OM parameter of the respective Single Codec information element to
"Optimization of the ACS not supported".
For AMR codecs, if the OM is set to "Optimization of the ACS supported", the originating CN node shall indicate the
maximum number of codec modes (MACS) that may be selected for the ACS during speech codec negotiation. This
maximum number of codec modes may depend on optimization strategies applied by the originating CN node. The
recommended value is 4 (see [10]).
For AMR-WB codecs the "Optimization Mode" is defined implicitly by the configuration parameter "Config-WBCodec" in the Single Codec information element (see [5]). If for a configuration the OM is set to "Optimization of the
ACS supported", then the configuration may be changed to any other allowed configuration specified in [5].
In order to support interworking with 2G systems it is recommended that MGWs support 2G codecs (GSM_HR,
GSM_FR, GSM_EFR, PDC_EFR, TDMA_EFR). In order to avoid modifications during handover between 2G and 3G
systems the MSC nodes may give preference to a suitable 2G codec.
Whenever one or several TrFO links have been already established and initialised, the CN node (e.g. the serving CN in
case of Call Hold scenarios, the visited CN node in case of Call Forwarding scenarios, etc.) initiating a subsequent
codec negotiation on a new call leg or a mid-call codec negotiation on an established and initialised TrFO link, should
give the already negotiated Selected Codec (BICC), including its ACS, highest preference to reduce the probability of
having to perform a bearer re-establishment or UP re-initialisation of the already established and initialised TrFO links.
The creation of a "structured" Supported codec list shall be as described for SIP-I (see Clause 9.7.2).
NOTE:
5.6.3
The auxiliary payload types do not apply to BICC.
Intermediate node
An intermediate node taking part in an OoBTC codec negotiation shall implement the procedures described in
Q.1902.4, subclause 8.3.2 [6]. Additionally, the following applies:
If a Single Codec information element for an AMR codec is included in the Supported Codecs List (BICC), with the
OM set to "Optimization of the ACS not supported", the intermediate node shall delete the Single Codec information
element
i) if the codec type is not supported; or
ii) if one or more codec modes of the offered ACS are not supported.
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-23-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
23
ETSI TS 123 153 V8.2.0 (2009-01)
If a Single Codec information element for an AMR codec is included in the Supported Codecs List (BICC), with the
OM set to "Optimization of the ACS supported", the intermediate node
i) shall delete the Single Codec information element, if the codec type is not supported;
ii) shall delete codec modes from the offered SCS and ACS, if they are not supported. If the last codec mode is
deleted from the offered SCS, the Single Codec information element shall be deleted from the Supported Codecs
List (BICC);
iii) shall reduce MACS to a locally supported value, if necessary;
iv) may change the ACS to a different ACS within the offered SCS; and
v) shall change the OM parameter from "Optimization of the ACS supported" to "not supported", if necessary.
NOTE:
In interworking scenarios with TFO, step (iv) may prevent the establishment of an end-to-end tandem free
and transcoder free connection; therefore, the intermediate node should not do this without a good reason.
During the processing of a Single Codec information element of an AMR codec with the OM set to "Optimization of
the ACS supported", the intermediate node may replace the original Single Codec information element by two or more
new Single Codec information elements, which can be derived from the original Single Codec information element by
the steps (i) to (v) listed above.
If a Single Codec information element for an AMR-WB codec is included in the Supported Codecs List (BICC), the
intermediate node shall
i) delete the Single Codec information element, if the codec type or codec configuration is not supported; or
ii) replace a Single Codec information element with configuration 1, 3, or 5 (see [5], table 5.7-1) by a Single Codec
information element with configuration 0 and, optionally, another Single Codec information element with
configuration 2 or 4, if configuration 3 or 5 is not supported.
5.6.4
Node terminating the OoBTC codec negotiation
The node terminating the OoBTC codec negotiation shall implement the procedures described in Q.1902.4, subclause
8.3.3 [6]. Additionally, the following procedures apply:
The terminating node shall process the Supported Codecs List (BICC) as described for the intermediate note in
subclause 5.6.3.
In UTRAN, GERAN Iu mode or GERAN AoIP mode, when processing the codec types (and configurations for AMR
or AMR-WB codecs) in the Supported Codecs List (BICC), the terminating MSC Server should take the codec types
and codec configurations supported by the terminating RNC or BSC into account (see subclause 5.6.6 for UTRAN or
GERAN Iu mode and section 5.6.7 for GERAN AoIP mode).
For the selection of the Selected Codec (BICC) from the Supported Codecs List (BICC), the following additional
procedures apply:
If an adaptive multi-rate codec is selected, then the decision about the actual codec modes to be included in the selected
ACS shall also be made by the terminating CN node. If the OM of the offered configuration is set to "Optimization of
the ACS supported", the selected ACS may be different from the offered ACS, but it shall be a subset of the offered
SCS and be consistent with MACS.
In order to provide harmonisation of out of band codec negotiation (for TrFO) and inband codec negotiation (for TFO)
similar codec type and codec configuration selection mechanisms as those being defined for TFO should be applied for
TrFO (see [10]).
NOTE:
For TrFO codec negotiation, besides the speech quality additional aspects may be considered which are
not applicable to TFO, e.g. the location of the transcoder that may need to be inserted or possible
bandwidth savings in the core network.
If an adaptive multi-rate codec is selected, the terminating MSC Server shall exactly specify the ACS in the Selected
Codec (BICC) and set the OM to "Optimization of the ACS not supported".
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-24-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
24
ETSI TS 123 153 V8.2.0 (2009-01)
In the Available Codecs List (BICC), sent back to the originating node, the terminating MSC server may include more
than one Single Codec information element indicating the same codec type, but different configurations. Single Codec
information elements for adaptive multi-rate codecs may also be included with the OM set to "Optimization of the ACS
supported" and the ACS being a subset of the SCS.
According to Q.1902.4, subclause 8.3.3 [6], the terminating node shall include the Selected Codec (BICC) in the
Available Codecs List (BICC). For AMR and AMR-WB codecs, the following applies:
If the Selected Codec (BICC) is an AMR codec, it shall be considered as included in the Available Codecs List (BICC),
if the Available Codecs List (BICC) contains a Single Codec information element with the same codec type and
-
exactly the same configuration, i.e. the same ACS and the OM set to "Optimization of the ACS not supported";
or
-
the Selected Codec (BICC) is consistent with the Single Codec information element, i.e. the selected ACS is a
subset of the SCS of the Single Codec information element, the Number of codec modes in the selected ACS is
less or equal to the MACS parameter of the Single Codec information element, and the OM of the Single Codec
information element is set to "Optimization of the ACS supported".
If the Selected Codec (BICC) is an AMR-WB codec, it shall be considered as included in the Available Codecs List
(BICC), if the Available Codecs List (BICC) contains a Single Codec information element with the same codec type
and
-
exactly the same configuration, i.e. the same the configuration parameter "Config-WB-Codec"; or
-
any configuration for which the OM is set to "Optimization of the ACS supported".
The creation of a "structured" Available codec list shall be as described for SIP-I (see Clause 9.7.3).
NOTE:
5.6.5
The auxiliary payload types do not apply to BICC.
Signalling between server and MGW
According to Q.1902.4, subclause 8.3 [6], during the OoBTC codec negotiation a server can provide its associated
MGW with the preferred codec from the Supported Codecs List (BICC), and as a result of the negotiation the server
will provide its associated MGW with the Selected Codec (BICC). The information is sent via the Mc interface as
Codec (H.248).
If the Codec (H.248) is an adaptive multi-rate codec, the server shall exactly specify the ACS in the respective Single
Codec information element and set the OM to "Optimization of the ACS not supported", both for the preferred codec
and the Selected Codec (BICC).
For the Single Codec information elements of adaptive multi-rate codecs in the TFO Codec List (H.248), the OM may
be set to "Optimization of the ACS supported", and the ACS may be a subset of the SCS. This applies also to the first
entry in the TFO Codec List (H.248), the Local Used Codec.
NOTE:
5.6.6
In some scenarios the flexible configuration of the Local Used Codec may be used for a faster TFO
establishment (see [10]).
Signalling between MSC and UTRAN or GERAN Iu-mode
The MSC Server shall know the codec types and codec configurations supported by the RNC. The MSC Server shall
select only from these configurations for the RAB assignment.
For GERAN Iu-mode the MSC Server receives a list of codec types (for definition see [15]) as well as the supported
codec modes (for an adaptive multi-rate codec type) within the RANAP INITIAL UE MESSAGE, indicating the
GERAN capabilities, which will be available at the RAB establishment procedure. With this information the MSC
Server shall delete those codec types and codec modes (for an adaptive multi-rate codec type) from the Supported
Codecs List (BICC) which are not supported by the GERAN, taking into account the GERAN classmark and the MS
capabilities. This possibly reduced list shall be used by the MSC Server during the codec negotiation procedure. The
value of the maximum number of supported codec modes shall be set to 4 (see [10]).
When the MSC node requests a RAB assignment the Subflow Combinations provided shall either all be initialised by
the RNC or all rejected with appropriate cause code.
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-25-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
25
ETSI TS 123 153 V8.2.0 (2009-01)
The MSC shall always assume "Discontinuous Transmission (DTX)" as mandatory and shall define 'SID' SDUs in
addition to the negotiated speech codec modes. This is because for TrFO the RAB requested by one RNC must match
that requested by the peer RNC – they are effectively the same RAB. If one MSC requires DTX support then the RAB
requested by the far end MSC must also support DTX (even if it is not desired by that MSC). As no Out Of Band
negotiation for DTX is supported nor DTX control to the UE, DTX shall be mandatory for TrFO connections.
Once an adaptive multi-rate codec with an ACS has been selected as Selected Codec (BICC), the MSCs shall indicate in
the RAB Assignment parameters [3] for the Guaranteed Bitrate the lowest speech mode in the ACS (assuming any SID
frames are smaller than the SDU for lowest speech mode, otherwise the Guaranteed Bitrate shall be set to the largest
SID frame). The Maximum bitrate shall correspond to the highest mode in the ACS.
5.6.7
Signalling between MSC and GERAN AoIP-mode
In both mobile originating and mobile terminating calls the MSC Server receives the Supported Codecs List (BSSMAP)
– "BSC-SCL" - containing a list of Codec types (for definition see 3GPP TS 48.008 [15]) as well as the codec
configurations (for adaptive multi-rate codec types) within the BSSMAP COMPLETE LAYER 3 INFORMATION
message, indicating the temporary GERAN capabilities for this call in this cell.
The Codec Types within this BSC-SCL can be viewed as divided into three different A-Interface types:
1) Codecs with PCM only on the A-Interface – transcoding always occurs inside the BSS.
2) Codecs with transcoding inside the BSS, but supported with TFO on the A-Interface.
3) Codecs supported with "Full IP" for the A-Interface – no transcoding inside the BSS.
These are described in detail in 3GPP TS 48.008 [15], subclause 3.2.2.103.
These A-Interface types may then be used by the MSC to create a structured "Supported Codec List", with Direct
Codecs and Indirect Codecs, as described in subclause 9.7.2.
When creating the Supported Codecs List (BICC or SIP-I), only codecs supported in GERAN with either "Full IP"
or TFO shall be included in the "direct" part of the Supported Codecs List (BICC or SIP-I), if also the MS and the
MGW support them in this way. Codec types and codec configurations not supported in GERAN (with either Full IP or
TFO) or MS, but supported by the MGW with transcoding, may be negotiated as "indirect" codec types.
This potentially reduced direct codec list and potentially increased indirect codec list shall be used by the MSC Server
during the codec negotiation procedure.
During the Assignment procedure, the MSC server shall include in the MSC-Preferred-Codec-List (BSSMAP) all the
codecs (and configurations) supported by both the MGW and the MS (see 3GPP TS 48.008 [15]) as allowed by the
MSC for this assignment or handover.
Editor's note: 3GPP TS 48.008 currently contains two contradictory statements on whether the MSC-PCL shall
or may contain all the codecs currently supported by the MS and MSC. GERAN2 requirements need to be
clarified.
.
5.7
Inband Rate Control
Inband rate control shall only allow the RNCs to set the maximum codec mode (maximum bitrate) from the set of codec
modes that have been negotiated out of band. This procedure is called Maximum Rate Control. The final maximum
mode selected results from a rate control request from one side and the maximum rate supported at the receiving side;
the lower rate of these is selected. This is known as Distributed Rate Decision. In TrFO maximum rate control shall be
supported through the Iu Framing protocol and through transit networks supporting compressed voice. The maximum
rate control procedures are further defined within the Iu Framing protocol [4].
When the MSC requests for a RAB to be assigned, it shall always define 1 speech mode SDU (lowest rate), and DTX
SDU as non-rate controllable. Other SDU formats for higher rates shall be defined as rate controllable. The first
subflow combination in the IuUP initialisation shall be treated as an initial maximum rate control. Where a node is in
TrFO break (e.g. the terminating MGW) this initial maximum rate control received at a given MGW/IuUP termination
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-26-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
26
ETSI TS 123 153 V8.2.0 (2009-01)
shall be signalled to the other TrFO link using the IuUP Rate Control PDU unless the IuUP Initialisation frame is to be
sent on to the next link as in RFCI Value Correction (see clause 5.4.3).
At SRNS relocation the new RNC shall send a rate control frame at Relocation Detect indicating its current maximum
rate, it will receive in the acknowledgement the current maximum rate from the far end. This procedure is called
Immediate Rate Control. Again the distributed rate decision means both RNCs will operate within a common limit.
5.8
Modification Procedures
The OoBTC procedures shall support the following modification mechanisms:
i) Modification of Selected Codec.
(The codec type of the Selected Codec (BICC) may be switched to another type within the Available Codecs List
(BICC), and/or the Active Codec mode Set of the Selected Codec (BICC) may be modified, and/or the
Supported Codec mode Set of the Selected Codec (BICC) may be reduced.)
ii) Modification of Available Codecs List
(The Available Codecs List (BICC) may be reduced by removing codec types and modes)
iii) Mid-call Codec Negotiation
(The Available Codec List (BICC) is re-negotiated, allowing the addition and removal of codec types and modes
compared to the previous Available Codec List (BICC), and a new Selected Codec (BICC) is chosen out of the
new Available Codec List (BICC))
The specific call flows when such procedures may be required are detailed in Clause 6. Further information on the
Available Codecs List (BICC) and the Selected Codec (BICC) is provided in Section 5.2. Further information on codec
types, codec modes, a Supported Codec mode Set and an Active Codec mode Set is provided in TS 26.103 [5]. The
basic codec negotiation principles are defined by the BICC Call Control Procedures (see [6]) but the explicit Mc
interface procedures are added.
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-27-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
5.8.1
27
ETSI TS 123 153 V8.2.0 (2009-01)
Modification of Selected Codec
The codec modification procedures shall support the following changes:
i)
change of the codec type or codec configuration of the current Selected Codec (BICC) to another codec
type or codec configuration within the Available Codecs List (BICC);
ii)
modification of the Available Codecs List (BICC) according to subclause 5.8.2, (i) to (v), in combination
with any change of the codec type or codec configuration of the current Selected Codec (BICC) to another
codec type or codec configuration within the new Available Codecs List (BICC). The modification of the
Available Codecs List (BICC) may include removal of the current Selected Codec (BICC) from the list.
The procedures described in Q.1902.4, clauses 10.4.1 to 10.4.3 [6] shall apply.
The new codec type and codec configuration may be selected freely from the Available Codecs List (BICC). For an
AMR codec or AMR-WB codec, a codec configuration may be selected if it is considered to be included in the
Available Codecs List (BICC) according to the criteria specified at the end of subclause 5.6.4.
For the coding of the new Selected Codec (BICC), the new Available Codecs List (BICC), and the new Codec (H.248),
the same rules apply as specified in subclauses 5.6.4 and 5.6.5.
In Figure 5.8.1/1 and 5.8.1/2 the basic codec modification procedure is shown. This Figure is an example; the codec
modification procedure may be initiated by any node within the call.
Upon Reception of a Modify Codec message (action 5 and 9 in Figure 5.8.1/1), a server node shall check if the Selected
Codec is altered according to the criteria above. If the Selected Codec is not altered, the procedures in Section 5.8.2
(Modification of the Available Codec List) apply, otherwise the server node shall send a 'Reserve Characteristics'
procedure to the attached MGW for the corresponding termination (action 6 and 10 in Figure 5.8.1/1
To perform a modification of the selected codec at an Iu interface, the MSC server shall send a 'Modify Bearer
Characteristics' procedure to the attached MGW (action 1 and 12 in Figure 5.8.1/1). Upon completion of the 'Modify
Bearer Characteristics' procedure, the server node shall send a 'RAB Assignment Request' to the radio access network
(action 2 and 13 in Figure 5.8.1/1). The MSC server shall then wait to receive a corresponding 'RAB Assignment
Response' message from the radio access network (action 3 and 14 in Figures 5.8.1/2 and 5.8.1/3) before continuing the
modification procedure.
An MSC server shall use the 'Reserve Characteristic' procedure for the termination towards the preceeding node (with
respect to the Modify Codec message) to perform the necessary bearer level modification. The MGW shall respond for
that termination with the 'Bearer Modified' procedure to indicate that the possible bearer modification to increase
bandwidth was successful. The MGW shall not wait until the Iu UP initialisation is complete before replying with the
'Bearer Modified' procedure. Each server shall not send forward the modify request to the succeeding node until the
indication from its MGW that any necessary bearer level modification has been completed (BNC_Modified
notification). The MSC server shall use the 'Confirm Characteristics' procedure to confirm the modification at that
termination.
An MSC server shall use the 'Modify Characteristic' procedure for the termination towards the succeeding node (with
respect to the Modify Codec message) to confirm the codec modification.
The specific handling of the Iu UP initialisation is described in Section 5.8.4.
Error Cases are described in Section 5.8.5.
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-28-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
29
ETSI TS 123 153 V8.2.0 (2009-01)
iii)
reduction of the MACS of any Single Codec information element in the Available Codecs List (BICC) for
which OM is set to "Optimization of the ACS supported";
iv)
change of the OM of any Single Codec information element in the Available Codecs List (BICC) from
"Optimization of the ACS supported" to "not supported"; and
v)
deletion of one or more Single Codec information elements from the Available Codecs List (BICC).
This shall not include the removal of the Selected Codec (BICC) or of modes from the ACS of the Selected Codec
(BICC), as this would require a Modification of Selected Codec as described in 5.8.1.
The procedures described in Q.1902.4, clauses 10.4.1 to 10.4.3 [6] shall apply.
For the coding of the new Available Codecs List (BICC), the same rules apply as specified in subclause 5.6.4.
No modification of the user plane and signalling towards the MGWs and radio access network is required.
In Figure 5.8.2/1 the basic 'modification of available codec list' procedure is shown. This Figure is an example; the
codec modification procedure may be initiated by any node within the call.
Modify Codec
(Available Codec
List: XYZ,
Selected Codex X)
Modify Codec
(Available Codec
List: XYZ,
Selected Codex X)
2
MSC
Server
A
1
Server
B
MSC
Server
C
3
4
Successful Codec
Modification
Terminal/
Radio
Access
MGW A
Successful Codec
Modification
MGW B
MGW C
Terminal/
Radio
Access
Figure 5.8.2/1: Modification of Available Codec List
5.8.3
Mid-call Codec negotiation
The Selected Codec (BICC) and the Available Codecs List (BICC) can be (re-) negotiated during the call using the 'Mid
Call Codec Negotiation' mechanism. The Mid-Call Codec Negotiation mechanism results in a new Available Codecs
List (BICC), where new codec types or modes not within the previous Available Codecs List (BICC) may be included.
The codec negotiation procedure is performed as for call set-up.
The procedures described in Q.1902.4, clauses 10.4.4 to 10.4.6 [6] shall apply.
The sequence is shown in Figure 5.8.3/1. Starting with the Modify to Selected Codec message, the remaining sequence
is the same as for the Codec Modification in Section 5.8.1 except that the message name for the modify request is
'Modify To Selected Codec' (instead of 'Modify Codec') in order to allow collisions between the two procedures to be
resolved. Everything stated in Section 5.8.1 shall also apply for the Mid-Call Codec Negotiation procedure.
The node initiating the 'Mid Call Codec Negotiation' mechanism (MSC Server A in Figure 5.8.3/1) shall select a
Preferred Codec and a Supported Codecs List (BICC), which may contain new codecs and also may not contain codecs
from the previous Available Codecs List (BICC). If the list no longer contains the previous Selected Codec (BICC),
then a new codec shall be selected as Preferred Codec. If the previous Selected Codec (BICC) exists within the
Supported Codecs List (BICC), this codec should be selected as the Preferred Codec.
If a server node removes the Preferred Codec, from the Supported Codecs List (BICC), the node shall select a new
Preferred Codec.
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-30-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
31
Server A
ETSI TS 123 153 V8.2.0 (2009-01)
Server B
MGW-A
MGW-B
Modify Bearer Char
Modify Codec (Selected Codec, Available Codec List)
Reserve Bearer Char
Reserv Char Ack
Modify Bearer request
Modify BearerAck
Optionally sent to
allocate additional
bandwidth.
BNC_Modified
Modify Codec
IuUP Init [RFCIs]
IuUP Init [RFCIs]
IuUP Init Ack
IuUP Init Ack
Successful Codec Mod
Confirm_Bearer_Char
Modify Bearer request
Optionally sent to reduce
additional bandwidth.
Modify BearerAck
BNC_Modified
Successful Codec Modification
Figure 5.8.4/1: Successful Codec Modification including IuFP
A MGW receiving a Modify Bearer Characteristics procedure shall be prepared to receive an incoming modify bearer
procedure, this may be to increase the bandwidth prior to IuUP Initialisation or to reduce the bandwidth after the IuUP
Intialisation. The new codec indicated in the Modify Bearer Characteristics procedure shall always result in the MGW
being prepared to receive an Iu UP initialisation for the new codec, even if the SDU format is unchanged. The MSC
shall send the RAB Parameters IE and NAS Synchronisation Indicator IE to the RNC to indicate that the codec has
changed and IuUP Initialisation shall be generated..
Each termination receiving a Reserve_Char will initiate bearer level modification to the preceeding node if needed - i.e.
if the bandwidth needs to be increased to support the new IuUP. No IuUP initialisation occurs at this point in time. If
the Codec Modification Request is terminated by a MGW the IuUP init through the core-network is triggered by the
setting of the 3GUP package property 'initialisation direction' to 'OUT' in either the Reserve_Char or the Confirm_Char
procedure; the MGW shall then start the IuUP Initialisation out from that Termination. If the node terminating the
modification is an RNC then it will generate a new IuUP Initialisation toward its access MGW, each Termination shall
have the initialisation direction set to 'IN'. Each MGW shall in turn acknowledge the IuUP Init to the succeeding node
(with respect to the modification request) and forward the RFCIs in an IuUP Initialisation to the preceding MGW (as for
call set-up). After completing the Iu UP initialisation and receiving the'Confirm Characteristics' procedure, the MGW
may decrease the bandwidth of the corresponding bearer performing the 'Modify Bearer' procedure (if needed) - no
bearer bandwidth reduction shall be initiated while the UP is still initialised for the old codec.
An example call sequence is shown in Figures 5.8.4/2 and 5.8.4/3.
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-32-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
34
ETSI TS 123 153 V8.2.0 (2009-01)
If the reason for failed codec modification is due to an unsuccessful RAB Modification Request then the MSC shall
assume that the old RAB is resumed and thus shall restore the old codec.
Server A
Server B
MGW-A
MGW-B
Mid Call Codec Negotiation (New Codec List)
Modify Bearer Char
Modify To Selected Codec (Selected Codec, Available
Codec List)
Reserve Bearer Char (New Codec)
Ack
Mod Bearer
Optional
BNC_Modified
Modify To Codec
Codec Mod Failure
Confirm Char (old Codec)
Mod Bearer
Optional
BNC_Modified
Codec Modification Failure
Modify Bearer Char (old Codec)
Figure 5.8.5/1: Unsuccessful Codec Modification
IuUP Initialisation Unsuccessful
If the IuUP initialisation fails (this must be due to some protocol error or transmission error because the resources have
already been successfully reserved) then the UP protocol is cleared by the peers (see TS 25.415) and therefore the
MGW shall notify the Server with a Bearer_Released notification, the call shall be cleared (normal MGW initiated call
clearing applies – see TS 23.205 clause 7.4 [8]).
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-35-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
38
ETSI TS 123 153 V8.2.0 (2009-01)
6
Detailed Call Procedures
6.1
Mobile to Mobile TrFO Call Establishment
MSC Server - T
RANAP
MSC Server - O
interworking
TICC
IU
MC
RNC-T
TICC
RANAP
IU
MC
MC
MGW-T
MC
MGW-O
TrFO break equipment
RANAP
IU UP
term.T
interworking
Nc
T1
(Iu-RAN)
interworking
RNC-O
TrFO break equipment
T2
T3
(Iu-CN)
IU
(Iu-CN)
interworking
RANAP
T4
(Iu-RAN)
Nb
IU
IU UP
term.O
starts initialisation of UP
optionally removed after call setup
optionally removed after call setup
TrF0 Relation between RNC-O ⇔ RNC-T (after call setup)
Figure 6.1/1: Configuration during Call Setup of a Mobile to Mobile Call
Following network and protocol entities are involved in the scenario, outlined in Figure 6.1/1:
RNC-T, RNC-O: terminating/originating RNCs.
MSC Server-T, MSC Server-O: MSC Servers, performing service, i.e. codec negotiation.
MGW-T, MGW-O: terminating/originating MGWs with the optional capability to insert/remove so called.
TrFO break equipment: (TBEs), i.e. contexts containing an UTRAN- and a CN side IU Framing termination (T1 –
T4), inter-working in a distinct manner on control level. [Note: context is meant to be the H.248 specific throughout the
document]. It is aimed to design protocols for TrFO in a way, that these pieces of HW can be removed after call setup
phase to allow to revert to "simple" AAL2 switching in case of ATM transport.
IU FP term.T, IU FP term.O: Terminating- and originating-side TrFO peers (IU Framing terminations in RNC's in Figure
6.1/1).
RANAP, TICC:C-plane protocol incarnations, responsible for codec negotiation, controlling the respective interfaces
(IU, NC), creating, modifying, removing etc. terminations and contexts.
The final configuration is (at least logically) an end to end TrFO relation between RNC-T and RNC-O with the option
to remove the TBEs from the user data path, i.e. to revert to pure AAL2 switching in case of ATM Transport.
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-39-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
RNC-T
MSC-S-T
MGW-T
26. Direct Transfer (CONNECT)
RANAP
27. Mod. Req(T2)
MGW-O
RNC-O
TICC
RANAP
H.248
ETSI TS 123 153 V8.2.0 (2009-01)
MSC-S-O
24. Alerting
TICC
RANAP
41
25. Direct Transfer (ALERTING)
RANAP
H.248
disconnect A from ringing
tone/ announcement
H.248
H.248
Iu FP
Iu FP
27. Mod.Reply(T2)
H.248
28. Mod. Req(T2)
29. INIT (o-RFCI map of x-modes)
H.248
Iu FP
29. INIT ACK
Iu FP
through connect
remove TBE optionally
H.248
RANAP
31. Direct Transfer
(CONNECT ACK)
30. Mod.Reply(T2)
H.248
RANAP
TICC
32. Answer
TICC
H.248
33. Mod. Req(T3)
H.248
through connect
remove TBE optionally
H.248
RANAP
RANAP
34. Mod.Reply(T3)
H.248
35. Direct Transfer (CONNECT)
35. Direct Transfer (CONNECT ACK)
RANAP
RANAP
TrFO operation RNC-T ⇔ RNC-O
Figure 6.1/4: Call Setup. Mobile to Mobile Call. Message Flow part 3
Codec negotiation
Steps 1. to 6. give the codec negotiation phase. The mobiles inform the network about their capabilities (1. and 4.).
Afterwards the MSC-Server performs codec negotiation according to clause 5.6.
Network side bearer establishment
MSC-T/MSC-O shall request seizure of network side bearer terminations with IuFP properties (see steps 5. and 7.).
Intermediate CN nodes that may perform certain service interactions (e.g. IN nodes) have to seize terminations with
IuFP properties as well.
RAB Assignment
RAN side terminations with IuFP property have to be seized (9. and 17.) before sending RAB Assignment (steps 10.
and 18.), that contains RAB parameters according to the selected codec and the negotiated ACS. In addition, the
respective NAS synchronisation indicator shall be included.
6.2
SRNS Relocation during TrFO
In order to maintain TrFO connection in SRNS Relocation, procedures specified in 3GPP TS 23.205 [8] and 3GPP TS
23.009 [11] for "Intra-MSC SRNS Relocation" or "Inter-MSC SRNS Relocation" shall be followed. Note that the
"Intra-MSC SRNS Relocation" procedure can also be used for relocation between RNCs connected to different 3G
MSCs (see 3GPP TS 23.009 [11], clause 1, 'Flexible Iu interface for handover/relocation' option and 'Intra domain
connection of RAN nodes to multiple CN nodes' option).
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-42-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
46
ETSI TS 123 153 V8.2.0 (2009-01)
At reception of an INIT frame from the new RNC, the termination at MGW-A shall not perform forwarding of the IuFP
initialisation. The MGW shall check whether the received RFCI allocations match the stored RFCI allocation. If it does
not match, it may re-initialise the IuFP towards RNC-A' at this point in time.
Removal of TrFO Break Equipment (TBE)
If the MGW supports the removal of TBEs, it shall insert the TBE before seizing the additional termination. It may
again remove the TBE after performing RFCI matching and through-connection of the new termination and the
termination to the far end party.
6.2.2 Inter-MSC SRNS Relocation
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].
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-47-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
50
ETSI TS 123 153 V8.2.0 (2009-01)
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.
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 Selected codec (BICC), previously selected for the leg towards the far end party, as the preferred
codec;
NOTE:
this codec is included to cover the case where the codec negotiation is terminated prior to reaching the
target MSC. Then the best codec to be selected is the one also used towards the far end party – in order to
avoid the need for a codec modification or additional transcoding in MSC-A If MSC-A knows by means
of configuration information that all nodes of the network support TrFO/TFO interworking and TFO,
including codec mismatch resolution, this codec may be omitted from the list.
b) the Iu-Selected codec (MAP) (negotiated with MSC-A' during the MAP E-interface signalling), if it is not
already included according to list item a;
c) the default PCM codec; and
d) optionally, further codecs from the Iu-Supported Codecs List (MAP) that are applicable to the target radio
access.
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], subclause 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 from this list
-
the multimedia dummy codec, if it is the preferred codec;
-
the Iu-Selected codec, if it is contained in the list; 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'.
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.
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-51-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
R N C -A '
56
ETSI TS 123 153 V8.2.0 (2009-01)
M G W -A ’
M S C -S -A ’
M S C -S -A
T IC C
1 6 . M o d ify to se lecte d c o de c
(se lecte d co de c , co de c list)
O p tio n a lly se nt to
a llo ca te a d dition a l
b an d wid th
T rC ntrl
T rC ntrl
Iu F P
IuF P
IuFP
IuFP
IuFP
2 0 . IN IT (R F C I va lu e c o rre ction )
IuFP
2 0. IN IT A CK
1 9. INIT (R F CI m a p o f y-m o de s )
1 9 . IN IT A C K
IuFP
M S C -S -B
M G W -A
T IC C
17 . M o d ify B ea re r re qu e st
17 . M o d ify B ea re r co n firm
1 8 . IN IT (R F C I m a p o f
y-m o des )
1 8. INIT A C K
IuF P
IuF P
T IC C
2 1 . S u cces fu l co d ec m o d ific atio n
T IC C
IuF P
H .24 8
H .24 8
O p tion a lly se n t to
re d uc e b a n dw id th
2 2 . C o nfirm C ha r A ck
(T3 )
2 3 . M o dify B e a rer re q u est
T rC ntrl
23 . M o d ify B ea re r c on firm
T rC ntrl
H .24 8
T IC C
22 . C o nfirm C ha r(T 3 )
2 5 . S ucce ss ful c od e c m o dificatio n
2 4 . B e a re r M o d ifie d
(T 3 )
H .24 8
H .24 8
T rC ntrl
T rC ntrl
H .24 8
T IC C
Note: There can be interim network transit nodes between MSC-A and MSC-A'
Figure 6.2/10: Mid-call codec negotation after Inter-MSC SRNS Relocation. Flow Chart Part 2.
If the anchor MSC (MSC-S-A) wants to forward the (re-)negotiation of the selected codec and the Available Codecs
List (BICC) towards the UE and the serving MSC (MSC-S-A'), it shall apply the following procedure:
The anchor MSC shall send a MAP Forward Access Signalling request (2) containing the new Iu-Supported Codecs
List and the corresponding RAB Assign Modify Request to the current serving MSC (MSC-S-A'). When selecting the
order of priority for the codecs within the new Iu-Supported Codecs List, the anchor MSC shall take the new Available
Codecs List (BICC) negotiated with the far end party into account.
On reception of the MAP Forward Access Signalling request (2) the serving MSC (MSC-S-A') shall select a codec from
the Iu-Supported Codecs List, configure the attached MGW-A' for the new codec, and trigger the "RAB Assign
Modify" procedure (4-7) towards the RNC-A'. For details concerning the handling of the RAB Assign Modify Request
message by MSC-S-A' see 3GPP TS 23.009 [11], subclause 13.4.1. When the serving MSC receives the RAB Assign
Modify Response message (7), it shall send a MAP Process Access Signalling Request (10) containing the RAB Assign
Modify Response, the Iu-Selected codec, and the Iu-Available Codecs List to the anchor MSC (MSC-S-A).
When the anchor MSC (MSC-S-A) receives the MAP Process Access Signalling Request (8), it shall start the mid-call
codec negotiation procedure (9-25) for the Nb/Nc interface towards the serving MSC (MSC-S-A'), as described in
Section 5.8.
When receiving the "Mid-call codec negotiation" procedure (9), the serving MSC (MSC-S-A') shall not reconfigure the
RAN and shall configure the attached MGW-A' to wait for an Nb framing protocol initiation from MGW-A.
Unsuccessful Codec Modification in the Serving MSC
After receipt of MAP Forward Access Signalling request (3), if the modification to the new Iu-Selected codec is not
possible, e.g. because necessary resources are temporarily unavailable in the serving cell or in MGW-A', or the RAN
does not support the "RAB Assign Modify" procedure, the serving MSC (MSC-S-A') shall keep the old codec and the
corresponding RAB configuration and shall send a MAP Process Access Signalling request, containing a RAB Assign
Modify Response ("failed to modify") message, to the anchor MSC (MSC-S-A). If the anchor MSC detects that the
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-57-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
57
ETSI TS 123 153 V8.2.0 (2009-01)
RAB modification failed, it shall abort the mid-call codec negotiation procedure towards the serving MSC and complete
the mid-call codec negotiation procedure towards the far end side.
Unsuccessful BICC Mid-call Codec Negotiation between Anchor MSC and Serving MSC
If after a successful modification of the Iu-Selected Codec (MAP) the subsequent BICC codec mid-call codec
negotiation procedure between anchor MSC and serving MSC fails due to a MGW rejecting a request to reserve the
resources or a server rejecting the request to (re-)negotiate the codecs, the anchor MSC shall change the codec used at
the Iu interface back by sending a MAP Forward Access Signalling request containing the previous Iu-Selected Codec
to the serving MSC (MSC-S-A'). After receipt of the confirmation that the previous codec has been restored at the Iu
interface, the anchor MSC shall complete the mid-call codec negotiation procedure towards the far end side.
6.2.3.3 Modification Procedure after Codec Change in the Serving MSC
According to 3GPP TS 23.009 [11], subclause 4.4.1, the serving MSC (MSC-S-A') will inform the anchor MSC (MSCS-A) when the Iu-Selected codec was changed during a subsequent intra-MSC handover/relocation by sending a MAP
Process Access Signalling request. If the Iu-Available Codecs List was changed during the handover/relocation, the
serving MSC shall send a MAP Process Access Signalling request including the new Iu-Available Codecs List.
On reception of the MAP Process Access Signalling request the anchor MSC may initiate one of the modification
procedures as described in sections 5.8.1, 5.8.2, and 5.8.3 towards the serving MSC and/or towards the far end side. I.e.
towards the serving MSC no MAP signalling is used. Besides, towards the serving MSC (MSC-A') the procedures
described in sections 5.8.1, 5.8.2, and 5.8.3 are applicable with the modification that the serving MSC shall not modify
the radio access bearer.
6.3
IN and Call Forward SS
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.
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-58-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
Server A
62
ETSI TS 123 153 V8.2.0 (2009-01)
Server B
MGW-A
Modify Codec (v)
Server C
MGW B
MGW C
Reserve Char Codec (v)
Modify Char Codec (v)
Successful Codec Mod
Confirm Char Codec (v)
Figure 6.4/2: Multi-party Call, with codec modification
6.5
Information flow for handover from UMTS to GSM after
TrFO establishment
Inter-system handover procedures are described at call control level in [11] and details for bearer independent
architecture is described in [8]. For TrFO connected UMTS call, when a handover occurs to GSM radio access, by
definition the A-interface to the BSC shall be default PCM. Prior to receipt of Handover Detect the Anchor MGW has
one leg (A-interface) stream mode as default PCM and two terminations with compressed voice codec properties. It is
recommended that after the Handover Complete procedure, the network property is maintained as compressed. Thus the
Anchor MGW inserts a "TFO Partner" transcoder. Thus no modification to the compressed bearer to 64k PCM is
required. TFO procedures may then ensure that speech quality is maintained by avoiding transcoding.
In the Intra-MSC case shown in Figure 6.5/1 the MSC controlling the handover has both codec lists for each radio
access. The codec negotiation for the UMTS call was performed end to end with UMTS list. If this negotiation resulted
in a codec being selected that is also included in the GSM list then at handover the MSC shall indicate this codec as the
current speech version to the BSC and TFO can be achieved. If the selected codec is not supported for the GSM radio
access but the GSM list contains a codec that is also in the Available Codecs list then the MSC has the option to
perform codec modification to ensure TFO can be achieved. The MSC may also perform codec list modification by
sending forward the GSM list to update nodes in the network of the change to the Available Codecs List.
3
UMTS
RAN
handover
GSM
BSC
1 Codec list: AMR, EFR, PCM
MSC
TSN
Selected Codec: AMR,
Available Codecs:EFR,PCM
2
PLMN 1
MGW
MGW
Codec list: AMR, EFR, PCM
MSC
Selected Codec: AMR,
Available Codecs:EFR,PCM
PLMN 2
Figure 6.5/1: UMTS to GSM Inter-System Handover
ETSI
UMTS
RAN
MGW](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-63-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
6.9
70
ETSI TS 123 153 V8.2.0 (2009-01)
Mobile to Mobile TrFO Call Establishment for GERAN Iumode
MSC Server - T
RANAP
MSC Server - O
interworking
TICC
IU
MC
BSC-T
TICC
RANAP
IU
MC
MC
MGW-T
MC
MGW-O
TrFO break equipment
RANAP
IU UP
term.T
interworking
Nc
T1
(Iu-RAN)
IU
interworking
BSC-O
TrFO break equipment
T2
T3
(Iu-CN)
(Iu-CN)
interworking
RANAP
T4
(Iu-RAN)
Nb
IU
IU UP
term.O
starts initialisation of UP
optionally removed after call setup
optionally removed after call setup
TrF0 Relation between BSC-O ⇔ BSC-T (after call setup)
Figure 6.9/1: Configuration during Call Setup of a Mobile to Mobile Call for GERAN Iu-mode
The description of Figure 6.1/1 (Configuration during Call Setup of a Mobile to Mobile Call) within clause 6.1 applies
for the network and protocol entities involved in the Mobile to Mobile Call for GERAN Iu-mode scenario with
following modifications:
BSC-T acts as a RNC-T.
BSC-O acts as a RNC-O.
Therefore Figures 6.1/2 to 6.1/4. (the respective message flows for mobile to mobile call setup) apply as well with the
appropriate modifications outlined below:
Codec negotiation
Step 1. until 6., that give the codec negotiation phase in Figure 6.1/2, shall be applied with following modifications:
Before step 1 (BSC-O to MSC-S-O) and step 4 (BSC-T to MSC-S-T) the RANAP Initial UE message will be sent
indicating the GERAN capabilities, which will be available at the RAB establishment procedure. The IE describing the
GERAN capabilities contains a list of codec types as well as the supported codec modes (for an adaptive multi-rate
codec type), which will be available at the RAB establishment procedure. With this information the MSC Server shall
puncture out (i.e. delete) those codec types and codec modes (for an adaptive multi-rate codec type) from the supported
codec list taking into account the GERAN classmark and the MS capabilities which are not supported by the GERAN.
This possibly reduced list shall be used by the MSC Server during the negotiation procedure (step 2 and step 6). For
definition of list of supported codec types see [15].
The MSC-Server performs codec negotiation according to clause 5.6 with the following modifications:
The value of the maximum number of supported codec modes shall be set to "four" (see [10]).
RAB Assignment
RAB Assignment shall be performed as described in clause 6.1 with following modifications:
Additionally, the MSC Server shall include the selected codec type within RAB Assignment.
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-71-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
6.10
71
ETSI TS 123 153 V8.2.0 (2009-01)
Relocation during TrFO towards GERAN Iu-mode
MSC – Server - A
RANAP
(old)
IU
interworking
Nc
RANAP
(new)
MC
RNC/BSC-A
TICC
MC
MC
MGW-A
TrFO break equipment
RANAP
T1
T2
(Iu-RAN)
IU UP
term.A
(Iu-CN)
Nb
IU
TrFO
vis-a-vis
(RNC-B)
interworking
BSC-A‘
RANAP
IU UP
term.A‘
TICC
partner
(MSC-S-B)
T3
(Iu-RAN)
IU
Figure 6.10/1: Configuration during intra-MSC SRNS Relocation towards GERAN Iu-mode
The description of Figure 6.2/1 (Configuration during intra-MSC SRNS Relocation) within clause 6.2 applies for the
network and protocol entities involved in the Relocation towards GERAN Iu-mode scenario with following
modifications:
RAN node A either is a RNC or a BSC. In the latter case BSC-A acts as a RNC-A.
BSC-A' acts as a RNC-A'.
Therefore Figures 6.2/2 to 6.2/3. (the respective message flows for SRNS Relocation and TrFO) apply as well with the
appropriate modifications outlined below:
Relocation Initiation
If the MSC-Server-A received the GERAN capabilities of the target cell within the RANAP Relocation Required
message (for details when the capabilities are included see [16]), MSC-Server-A shall compare these capabilities with
the current Selected Codec (BICC) and the Available Codecs List (BICC), taking into account Supported Codec Set
and Active Codec Set for adaptive multimode codecs. If the GERAN capabilities in terms of codec types and modes for
adaptive multimode codecs do not include all codes types and modes in the Available Codecs List (BICC) and all
modes and the type of the Selected Codec (BICC), MSC Server A shall invoke the appropriate of the modification
procedures in Section 5.8. Criteria for the selection of the appropriate procedure are given in Section 5.8. Upon
completion of this procedure, or if no modification procedure is required, MSC server A shall proceed with the
Relocation procedure as described in Figure 6.2/2 to 6.2/3 (Step 2. to 17.).
RAB Assignment on the new Iu leg:
RAB Assignment on the new Iu leg shall be performed as described in clause 6.2 with following modifications:
The Relocation Request (Step 3.) contains possibly new RAB parameters depending on the actions executed as outlined
above during the Relocation Initiation phase according to the decision on the selected codec as well as on the selected
codec modes (for an adaptive multi-rate codec type). In addition, the MSC-Server-A shall include the selected codec
type within Relocation Request message. For definition of list of supported codec type see [15].
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-72-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
72
6.11
Inter-MSC Handover during TrFO
6.11.1
ETSI TS 123 153 V8.2.0 (2009-01)
Inter-MSC Handover
In order to enable the use of Tandem free and Transcoder free operation after inter-MSC handover, the procedures
specified in 3GPP TS 23.205 [8] and 3GPP TS 23.009 [11] for "Inter-MSC Handover" shall be followed. For the
handling of the codec lists and selected codecs the following rules apply:
The Prepare Handover request message shall include the Iu-Supported Codecs List (MAP).
If the serving radio access is UTRAN or GERAN Iu-mode, the Prepare Handover request message shall contain the IuCurrently Used Codec (MAP). Otherwise, if the serving radio access is A/Gb mode, the currently used codec is
indicated by the Speech Version (Chosen) in the BSSMAP Handover Request message included in the Prepare
Handover request message.
If the target radio access is UTRAN or GERAN Iu-mode, the Prepare Handover response message shall contain the IuSelected Codec (MAP) and the Iu-Available Codecs List (MAP). Otherwise, if the target radio access is A/Gb mode,
the selected codec is indicated by the Speech Version (Chosen) in the BSSMAP Handover Request Ack message
included in the Prepare Handover response message.
If the target radio access is UTRAN or GERAN Iu-mode, then 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 Codecs List (BICC) as specified in
subclause 6.2.2. When MSC-A' receives a Supported Codecs List (BICC) with the IAM message, it shall follow the
procedures specified in subclause 6.2.2.
If the target radio access is GERAN A/Gb mode, then for a speech bearer the anchor MSC shall perform a call set-up
with codec negotiation towards the target MSC, using a Supported Codec List (BICC) ordered as:
a) optionally, the Selected codec (BICC), previously selected for the leg towards the far end party, as the preferred
codec;
NOTE:
this codec is included to cover the case where the codec negotiation is terminated prior to reaching the
target MSC or the case where the GSM codec selected in the target BSS is not suitable on the BICC
bearer either because not supported on Nb bearers or TFO is not supported for this codec by the target
BSS. Then the best codec to be selected is the one also used towards the far end party – in order to avoid
the need for a codec modification or additional transcoding in MSC-A. If MSC-A knows by means of
configuration information that all nodes of the network support TrFO/TFO interworking and TFO,
including codec mismatch resolution, this codec may be omitted from the list.
b) the default PCM codec;
c) the GSM codec indicated by the serving MSC during the MAP E-interface signalling as Speech Version
(Chosen), if it is not already included according to list item a and if supported on Nb bearer; and
d) optionally, further GSM codecs that are supported by its associated MGW.
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], subclause 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 the target radio access is GERAN A/Gb mode and MSC-A' receives a Supported Codec List (BICC) with the IAM
message, MSC-A' shall select from this list
-
the multimedia dummy codec, if it is the preferred codec;
-
the GSM codec corresponding to the Speech Version (Chosen), if it is contained in the list and if suitable for the
target MSC (e.g. codec supported on Nb bearer, TFO supported by the target BSS for this codec); or
-
optionally, the first codec of the BICC-SCL; or
-
the default PCM codec.
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-73-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
6.11.2
73
ETSI TS 123 153 V8.2.0 (2009-01)
Codec Modification/Mid-Call Codec Negotiation after Inter-MSC
Handover
6.11.2.1 Codec Modification/Mid-Call Codec Negotiation Initiated by the Far End Side
If the serving radio access after inter-MSC handover is GERAN A/Gb mode, and the anchor MSC (MSC-S-A) receives
a "Modification of Selected Codec" procedure or a "Mid-Call Codec Negotiation" procedure from the far end side the
MAP signalling between the anchor MSC (MSC-S-A) and the serving MSC (MSC-S-A') shall be performed only, if the
old or the new Selected Codec (BICC) is the multimedia dummy codec.
If both the old and the new Selected Codec (BICC) are speech codecs, the anchor MSC may terminate the codec
modification or mid-call negotiation procedure, inserting a transcoder if required. Alternatively, the anchor MSC may
forward the request to the serving MSC (MSC-S-A'), using the procedures as described in section 5.8.
NOTE:
The anchor MSC may decide to forward the request to the serving MSC (MSC-S-A'), e.g. when it is
possible to (re-)establish Tandem free and Transcoder free operation end-to-end from the far end side up
to the serving TRAU.
If either the old or the new Selected Codec (BICC) is the multimedia dummy codec, i.e. the far end side requests a
service change between speech and multimedia, and the Available Codecs List (BICC) previously negotiated between
the anchor MSC and the serving MSC (MSC-S-A') indicates that the service change is supported end-to-end, the anchor
MSC shall forward the request to modify the radio access bearer to the serving MSC (MSC-S-A') and then perform a
codec modification or mid-call negotiation for the Nb/Nc interface towards the serving MSC (MSC-S-A'), using the
procedures as described in section 5.8. If the service change between speech and multimedia cannot be performed
successfully, the anchor MSC shall reject the request for codec modification or mid-call negotiation towards the far end
party.
6.11.2.2 TFO Codec Mismatch Resolution in the Serving MSC
If the serving radio access after inter-MSC handover is GERAN A/Gb mode, and TrFO has been established between
the anchor MSC and the serving MSC, the serving MSC may detect a TFO codec mismatch between the Selected
Codec (BICC) used on the TrFO link and the GSM speech codec chosen by the serving BSC.
If the serving MSC supports the codec mismatch resolution procedure (see 3GPP TS 28.062 [10], subclause 6.3) and
wants to change the Selected Codec (BICC) due to this procedure, the serving MSC shall initiate a codec modification
or mid-call codec negotiation procedure towards the anchor MSC as described in sections 5.8.1, 5.8.2 and 5.8.3.
In the event of a collision of codec modification/mid-call codec negotiation procedures initiated by the anchor MSC and
the serving MSC, the procedures described in Q.1902.4, subclause 10.4.7.5 [6] shall apply, with the following
modification of the first sentence in subclause 10.4.7.5 [6], list item 2:
Codec modification/mid-call codec negotiation requests initiated in the direction towards the serving MSC shall take
precedence over codec modification/mid-call codec negotiation requests initiated in the direction towards the anchor
MSC.
6.11.2.3 Modification Procedure after Codec Change in the Serving MSC
The procedures as specified in section 6.2.3.3 apply.
6.12
Incoming data call from PSTN
For incoming calls from PSTN, the TMR may not allow to identify the requested service, since the same value may be
used to identify both voice and data calls.
6.12.1
Identification of data call at Visited MSC
An incoming data call from the PSTN may be identified as data call using signalling interaction with the terminating
UE at the Visited MSC. The following procdures are recommended in a network supporting TrFO to allow the Visited
MSC to identify the data call using interactions with the terminating UE:
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-74-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
74
ETSI TS 123 153 V8.2.0 (2009-01)
The GMSC includes a G.711(and possibly other codecs) in the BICC supported codec list.
If the Visited MSC determines that an incoming call is a data call, it shall select G.711 as codec.
Note:
UE
A 64 kbit/s bearer, as required for data calls, will be set up if G.711 is selected.
PLMN-BC
V_MSC
IAM (codec list : codec1, codec 2, G711,
TMR= 3,1 KHz )
G_MSC
IAM (TMR= 3,1 Khz)
PSTN
APM (selected codec : G711)
MGW
Packet backbone
MGW
TDM
Figure 6.12.1/1.Identification of incoming data call at Visited MSC
6.12.2
Handling at transit exchange in inhomogenous networks
If a transit exchange connecting a packet backbone and a TDM backbone in an inhomogenous network is not able to
determine if an incoming call from the packet backbone side is a data call or a speech call (e.g. TMR=3.1kHz is
received), it may select G.711 as codec to enable possible data calls.
Note:
A 64 kbit/s bearer, as required for data calls, will be set up if G.711 is selected.
PLMN
IAM (TMR= 3,1 KHz)
TDM
VMSC
TSN
IAM
(codec list : codec 1,
codec 2, G711,
TMR= 3,1 KHz)
IAM (TMR= 3,1 KHz)
GMSC
PSTN
APM (selected codec : G711)
TDM
MGW
packet
backbone
MGW
TDM
Figure 6.12.2/1.Handling of possible data call at transit exchange between TDM and packet backbone
6.12.3
Identification of data call at G-MSC using multi-numbering
If the called mobile subscriber is configured with multinumbering service, the GMSC may use the GSM Bearer
Capability that may be received from the HLR during the Send Routing Information procedure to identify the requested
service and select directly a codec transparent for data call. It may also pass the bearer capability information to
subsequent nodes to allow them to select a codec transparent for data call as well (see 3GPP TS 29.007 [19]). This may
be particularly usefull in configurations where the terminating MSC does not participate to the codec negotiation
procedure, as illustrated in figures 6.12/1 and 6.12/2.
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-75-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
6.13
76
ETSI TS 123 153 V8.2.0 (2009-01)
Mobile to Mobile TrFO Call Establishment in GERAN AoIP
mode
MSC Server - T
BSSAP
MSC Server - O
interworking
TICC
A
MC
BSC-T
TICC
interworking
BSSAP
Nc
A
MC
MC
MGW-T
MC
MGW-O
BSC-O
BSSAP
RTP
term. T
BSSAP
T1
T2
(RTP-RAN)
(Nb-CN)
AoIP
T3
T4
(Nb-CN)
(RTP-RAN)
Nb
AoIP
RTP
term.O
TrF0 Relation between BSC-O ⇔ BSC-T (after call setup)
Figure 6.13/1: Configuration during Call Setup of a Mobile to Mobile Call in GERAN AoIP mode
Figure 6.13/1 shows the configuration for mobile to mobile call establishment in GERAN AoIP mode.
Following network and protocol entities are involved in the scenario, outlined in Figure 6.z/1:
BSC-T, BSC-O: terminating/originating BSCs.
MSC Server-T, MSC Server-O: MSC Servers, performing service, i.e. codec negotiation.
MGW-T, MGW-O: terminating/originating MGWs.
BSSAP, TICC:C-plane protocol incarnations, responsible for codec negotiation, controlling the respective interfaces
(A, NC), creating, modifying, removing etc. terminations and contexts.
NOTE:
The following sequences are examples, further detailed call flows are described in TS 23.205 [6].
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-77-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
82
9
Codec Negotiation For SIP-I on Nc
9.1
ETSI TS 123 153 V8.2.0 (2009-01)
General
Codec negotiation procedures for SIP-I are described in the following subclauses, where additions or exclusions to the
general procedures and principles described in the previous clauses for BICC are required; otherwise it shall be assumed
that the others clauses in this specification shall apply to SIP-I on Nc. Normal call handling procedures for SIP-I on Nc
are described in 3GPP TS 23.231 [20].
SIP-I codec negotiation procedures defined in the present specification extend the normal Offer/Answer rules defined
by IETF RFC 3264 [24]. In order to identify the compliance to these enhancements, the 3GPP OoBTC Indicator is
defined, see 3GPP TS 29.231 [21].
NOTE:
9.2
Non-speech RTP payload types may also need to be negotiated within the offer/answer procedures , e.g.
the Telephony Event RTP payload type or the ClearMode codec. This is further described in specific
clauses in other specifications such as 3GPP TS 23.231 [20] and 3GPP TS 29.007 [19].
Framing Protocol
SIP-I user plane does not use IuFP framing protocol or associated 3GUP procedures. Rate control procedures are
performed within RTP.
9.3
Basic Procedures
9.3.0
Applicability
The procedures in the subsequent subclauses 9.3.1 to 9.3.4 are applicable for speech calls and SCUDIF calls.
Procedures for SCUDIF calls are further specified in 3GPP TS 23.172 [17]. Procedures to establish data calls are
specified in 3GPP TS 23.231 [20] and 3GPP TS 29.007 [19].
NOTE:
For SCUDIF, a Multimedia Dummy Codec is offered together with a speech codec in a single SDP mline.
If an offerer is not able to determine if a call is a data call or a speech call, it shall only offer speech codecs including
the PCM codec and apply the procedures in subclause 6.12. If codecs other than PCM are also offered, it shall also
apply the procedures specified in subclauses 9.3.1 to 9.3.4.
9.3.1
3GPP Node Originating SDP Offer
-
An MSC-S initiating an offer shall include the OoBTC Indicator in the offer.
-
If the offering MSC-S receives an answer without the OoBTC Indicator, the codec list shall be interpreted in
accordance with the IETF codec rules. If the answer contains multiple codecs, the MSC-S shall initiate a second
offer with the selected codec and may include the OoBTC Indicator or leave it out.
-
If the offering MSC-S receives an answer with the OoBTC Indicator, then the codec list contains the 3GPP
Selected Codec and Available Codec List and shall be interpreted to be in accordance with the codec negotiation
procedures described in this specification.
9.3.2
3GPP Node Terminating SDP Offer
-
If the 3GPP MSC-S terminating the codec negotiation receives an offer with the OoBTC Indicator, it shall
include the OoBTC Indicator in the Answer. The returned codec list shall be formatted as a 3GPP Selected
Codec List and Available Codec List.
-
If the 3GPP MSC-S terminating the codec negotiation receives an offer without the OoBTC Indicator, the codec
list shall be interpreted in accordance with the IETF codec rules and the MSC-S shall initiate an answer with a
single codec. It may include the OoBTC Indicator in the Answer or leave it out.
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-83-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
-
9.5
ETSI TS 123 153 V8.2.0 (2009-01)
Codecs in the Available Codec List indicate codecs that are supported. This information may be used by an MSC
to decide if a change of the Selected Codec to some other codec using a new SDP offer-answer exchange is
attempted.
NOTE:
-
84
The Available Codec List may be used by a (G)MSC as decision criterion if a codec re-negotiation is
attempted. However, this does not preclude that an (G)MSC offers codecs not included in the previous
ACL in a codec re-negotiation.
A change from the Selected Codec in the answer to an "auxiliary" payload type within the answer, i.e. the RTP
Telephony Event (see IETF RFC 4733 [22]) or the comfort noise codec (see IETF RFC3389 [yx]), and vice
versa is permitted without new SDP offer-answer exchange by "Inband" switching, i.e. by simply sending the
other RTP payload type.
Handling of Auxiliary Payload types
If auxiliary payload types are negotiated the MSC Server shall configure the MGW to support the multiple payload
types for a given termination/stream where applicable (i.e. for speech codec and for RTP Telephony Event and/or
comfort noise codec) with the following condition:
-
9.6
Resources for a possible comfort noise codec (RFC3389) within the answer codec shall only be reserved in the
MGW by the MSC Server if the comfort noise codec (RFC3389) is applicable for the selected codec. For
instance, AMR does contain an internal comfort noise mode and is not used in combination with the comfort
noise codec (see IETF RFC3389 [23]).
Codec Negotiation Example Sequences
The following figures show examples of codec negotiation for a selection of common call scenarios to highlight the
principles agreed in the preceding clause; the sequences are not exhaustive.
Nc Interface
IW-MSC/
GMSC
MSC
Offered list
contains
supported codecs
.
OoBTCIndicator
shall be included
in offer.
INVITE[CodecList,
OoBTCIndicator]
18x session progress [IETF Codecs]
If multiple codecs
received in answer
and no
OoBTCIndicator
then Offerer shall
send a new offer to
reduce to a single
speech codec
.This
O/A exchange may
occur using
UPDATE of PRACK
.
NOTE PRACKs NOT
SHOWN
1a
18x session progress
[Selected Codec, ACL,
OoBTCIndicator]
UPDATE[SelectedCodec]
1
Intermediate Node may either
forward Answer from
succeeding node to preceding
node as received
Alternatively Intermediate Node
may select codec and return with
OoBTCIndicator to preceding
node. It shall then send second
offer to succeeding node to reduce
to single codec
.
UPDATE[SelectedCodec]
200 OK (UPDATE)
[SelectedCodec]
UPDATE[SelectedCodec]
200 OK (UPDATE)
[SelectedCodec]
200 OK (UPDATE)
[SelectedCodec]
Figure 9.6.1: Mobile Originating Codec Negotiation
ETSI
External
Node
INVITE[CodecList,
OoBTCIndicator]
18x Session progress [IETF
Codecs]
2
2a
Intermediate
Node deletes any
codecs that it
does not support](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-85-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
Nc Interface
MSC
85
ETSI TS 123 153 V8.2.0 (2009-01)
Intermediate
Node deletes
any codecs
that it does
not support
IW-MSC/
GMSC
INVITE[CodecList,
OoBTCIndicator]
INVITE[CodecList,
OoBTCIndicator]
MSC receives
multiple codes in
offer but includes
OoBTCIndicator 18x session progress [Selected
.
Selects appropriate
codec and returns Codec, ACL, OoBTCIndicator]
as first in list,
including Available
codecs and
OoBTCIndicator
.
External
Node
External Node
supports
OoBTCIndicator
.
Offered list conta
supported codec
18x session progress [Selected
Codec, ACL, OoBTCIndicator ]
Figure 9.6.2: Mobile Terminating Codec Negotiation – External Node supports OoBTCIndicator
Nc Interface
IW-MSC/
GMSC
MSC
If multiple codecs
received the MSC
shall select the
most appropriate
codec. If no
OoBTCIndicator
received then only
this single codec
shall be returned in
the answer
.
1a
If OoBTCIndicator
received then MSC
shall return
selected coded
,
available codecs
and
OoBTCIndicator
.
2a
Intermediate
Node deletes
any codecs
that it does
not support
External
Node
INVITE[IETF Codecs]
INVITE[IETF Codecs]
1
INVITE[CodecList,
OoBTCIndicator]
2
18x session progress
[Selected Codec]
18x session progress
[Selected Codec, ACL,
OoBTCIndicator]
Intermediate Node may either
forward Offer from preceding
node to suceeding node as
received
Offered list contains
multiple codecs, no
OoBTCIndicator
.
Alternatively Intermediate Node
may include OoBTCIndicator to
suceeding node It shall then send
.
second offer to preceding node to
reduce to single codec, after
.
answer from suceeding node
.
If intermediate node receives
available codecs and
OoBTCIndicator in answer but
did not receive OoBTCIndicator
from preceding node then it
removes all other codecs except
the selected code to preceding
node
18x Session progress
[Selected Codec]
Figure 9.6.3: Mobile Terminating Codec Negotiation – External Node does not support
OoBTCIndicator
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-86-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
External
Node
External node may
return multiple
codecs in reply If it
.
does not support
OoBTCIndicator(or
does not receive it
)
then it returns IETF
format codecs
1a,
2a
If OoBTCIndicator
received and
external node
supports3G OoBTC
then it shall return
selected coded
,
available codecs
and OoBTC
Indicator
.
86
ETSI TS 123 153 V8.2.0 (2009-01)
IW-MSC/
GMSC
GMSC determines
call is to be rerouted
outside PLMN(e.g.
explicit call forward
)
Intermediate
Node deletes
any codecs
that it does
not support
External
Node
INVITE[IETF Codecs]
INVITE[IETF Codecs]
1
INVITE[CodecList,
OoBTCIndicator]
Intermediate Node may either
forward Offer from preceding
node to succeeding node as
received
Offered list contains
multiple codecs, no
OoBTCIndicator
.
2
Alternatively Intermediate Node
may include OoBTCIndicator to
succeeding node
.
18x session progress
[IETF Codecs]
If intermediate node receives multiple
codecs and no OoBTCIndicator in answer 3a
18x session progress
but did not receive OoBTCIndicator from
[IETF Codecs]
preceding node then may forward answer
as received to the preceding node
.
Alternatively intermediate node selects an
appropriate codec from the list received
node and initiates a
4 from the succeedingsucceeding node to
subsequent offer to
indicate the single selected codec and
UPDATE[SelectedCodec]
signals the single selected coded back to
200 OK (UPDATE)
the preceding node
.
[SelectedCodec]
18x session progress
[Selected Codec, ACL,
OoBTCIndicator]
2b
18x Session progress
[Selected Codec]
Figure 9.6.4: Codec Negotiation during call forwarding outside of PLMN – external incoming node
does not support 3G OoBTCIndicator
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-87-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
External
Node
External node does
not support
OoBTCIndicator but
may returns
multiple codecs in
reply.
87
ETSI TS 123 153 V8.2.0 (2009-01)
IW-MSC/
GMSC
GMSC determines
call is to be rerouted
outside PLMN(e.g.
explicit call forward
)
Intermediate
Node deletes
any codecs
that it does
not support
External
Node
INVITE[CodecList,
OoBTCIndicator]
INVITE[CodecList,
OoBTCIndicator]
Intermediate Node forwards
Offer from preceding node to
succeeding node as received
18x session progress
[IETF Codecs]
Offered list contains
multiple codecs,
including
OoBTCIndicator
.
1
If intermediate node receives multiple
codecs and no OoBTCIndicator in
answer it may return multiple codecs
in reply to preceding node if it can
support multiple codes
18x session progress
[IETF Codecs]
2
UPDATE[SelectedCodec]
200 OK (UPDATE)
[SelectedCodec]
and either signal the single
selected codec back to the
preceding node
.
Or signal the selected codec
and available codecs list
including the OoBTCIndicator
back to the preceding node
.
Alternatively intermediate node selects an
appropriate codec and initiate a subsequent
offer to succeeding node to indicate the
single selected codec
.
2a
2b
18x Session progress
[Selected Codec]
18x session progress
[Selected Codec, ACL,
OoBTCIndicator]
Figure 9.6.5: Codec Negotiation during call forwarding outside of PLMN – external node supports 3G
extension
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-88-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
88
Nc Interface
MSC
INVITE[(AMR2, AMRWB,
G711), (3GIndc)]
IW-MSC/
GMSC
Offered list contains
supported codecs
.
3GIndc extension
shall be included in
offer.
18x
session progress [IETF
Codecs(G.711, G.722.2)]
If multiple codecs
received in answer
and no 3GIndc then
Offerer shall send a
new offer to reduce
to a single speech
codec.This O/A
exchange may
occur using
UPDATE of PRACK
.
NOTE PRACKs NOT
SHOWN
1a
ETSI TS 123 153 V8.2.0 (2009-01)
18x session progress
[Selected Codec(AMR2),
ACL(AMR2, G711), 3GIndc ]
Intermediate
Node deletes
any codecs
that it does
not support
External
Node
INVITE[(AMR2, G711), 3GIndc)]
18x Session progress [IETF
Codecs (G.711, G.722.2)]
1
2
Intermediate Node may either
forward Answer from
succeeding node to preceding
node as received
.
Alternatively Intermediate Node
may select codec and return with
3GIndc to preceding nodeIt shall
.
then send second offer to
succeeding node to reduce to
single codec
.
2a
UPDATE[SelectedCodec(G.711)]
200 OK (UPDATE)
UPDATE[SelectedCodec(G.711)
[SelectedCodec(G.711)]
]
200 OK (UPDATE)
[SelectedCodec(G.711)]
UPDATE[SelectedCodec(G.711)]
200 OK (UPDATE)
[SelectedCodec(G.711)]
Figure 9.6.6: Mobile Originating Codec Negotiation with specific codec examples
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-89-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
Nc Interface
MSC
If multiple codecs
received the MSC
shall select the
most appropriate
codec. If no 3GIndc
received then only
this single codec
shall be returned in
the answer
.
2a
ETSI TS 123 153 V8.2.0 (2009-01)
IW-MSC/
GMSC
INVITE[IETF Codecs(G.722.2,
G.711)]
INVITE[CodecList(AMR2,AM
RWB, G.711), 3GIndc)]
18x session progress
[Selected
Codec(G.711)]
1a
If 3GIndc received
then MSC shall
return selected
coded, available
codecs and 3G Ind.
89
18x session progress
[Selected Codec(AMR2),
ACL(AMR2, G.711), 3GIndc]
If intermediate node receives
selected codec and does not
match codecs supported on
external network then inserts
transcoder
.
Intermediate
Node deletes
any codecs
that it does
not support
External
Node
INVITE[IETF Codecs(G.722.2,
G.729, G.711)]
1
2
Intermediate Node may either
forward Offer from preceding
node to suceeding node as
received
Offered list contains
multiple codecs, no
3GIndc.
Alternatively Intermediate Node
may include 3GIndc to suceeding
node. It shall then send second
offer to preceding node to reduce
to single codec after answer from
.,
suceeding node
.
18x session progress
[Selected
Codec(G.711)]
18x session progress
[Selected
Codec(G.711)]
Figure 9.6.7: Mobile Terminating Codec Negotiation with specific codec examples
9.7
Codec Lists Structure
9.7.1
General
The following are rules that are applied when populating a Session Description Protocol (SDP) media offer or an SDP
media answer for 3GPP SIP-I OoBTC. A SIP-I signalling endpoint shall initiate an SDP Offer/Answer exchange during
call establishment and may initiate an SDP Offer/Answer exchange at any time that the bearer configuration changes,
e.g., during handover or invocation of a supplementary service such as 3pty.
9.7.2
Rules for Constructing an Offer
The Codec List/SDP in the Offer shall contain codecs/payload types defined as follows:
-
"Direct Codec" payload types that can be used between bearer endpoints without any additional transcoding
stage;
-
"Indirect Codec" payload types that can be used between bearer endpoints with an additional transcoding stage;
and
-
"Auxiliary" payload types unrelated to the primary codec selection process may be included.
The Offered Codec List shall contain two sub-lists ordered as: zero or more "Direct Codecs" plus zero or more
"Indirect Codecs". A list of zero or more "auxiliary" payload types, e.g., RTP Telephony Events, CN (comfort noise),
which are not used in the process of selecting the primary codec, may follow after the direct and indirect codec types.
The direct and indirect codec sub-lists shall be ordered in decreasing preference.
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-90-320.jpg)
![3GPP TS 23.153 version 8.2.0 Release 8
90
ETSI TS 123 153 V8.2.0 (2009-01)
G.711 shall always be included either as direct or indirect codec. When present, the indirect codec sub-list shall always
start with G.711, if G.711 is not a direct codec. However, an entry for G.711 shall appear only once in the offered codec
list.
The offer may contain a list of several direct and indirect codec types.
NOTE:
9.7.3
These rules for constructing an SDP Offer enable TrFO in the network by assuring that the network
configures the minimum number of transcoders for each session. These rules are needed to enable TrFO
in the network and are consistent with IETF RFC 3264 [24], but are not part of IETF RFC 3264 [24].
Other SIP endpoints may not follow the same conventions for prioritizing codecs. As an exception to the
aforementioned rules, the offerer could choose to construct an Offered Codec List in a different order
from the one described in the above rules, but this is not recommended as the answerer may select a
codec that does not minimize the number of transcoders for the session and does not enable TrFO.
Rules for Constructing an Answer
The answering signalling endpoint shall, before processing the Offer and before populating the Answer, structure the
available codec types on its access into "Direct Codecs," "Indirect Codecs", and "auxiliary" payload types.
The answering signalling endpoint shall then take both structured Codec Lists, the one received in the Offer and the one
created locally, into account and shall select the "optimal" codec type for the Answer, which shall be the first codec type
in the Answer; the Selected Codec. The Answer shall contain at least one direct or indirect codec from among those
listed in the Offer. The criteria for selecting the "optimal" codec may depend on operator choices and preferences (local
policy), such as Speech Quality, Bit Rate on transport or DSP load (for transcoding) or other.
If the Answer to a subsequent Offer comprises all or a subset of the Direct and Indirect codecs in the preceding Answer
within the dialog, then the IP address, and port information in the SDP Answer should remain the same.
Ideally the Selected "optimal" Codec is a direct codec type on both accesses, which results in no transcoding being
necessary.
9.8
Void
ETSI](https://image.slidesharecdn.com/transcoderfreeoperationts123153v080200p-140104124645-phpapp02/85/Transcoder-free-operation_ts_123153v080200p-91-320.jpg)
Transcoder free operation_ts_123153v080200p
- 1. ETSI TS 123 153 V8.2.0 (2009-01) Technical Specification Universal Mobile Telecommunications System (UMTS); LTE; Out of band transcoder control; Stage 2 (3GPP TS 23.153 version 8.2.0 Release 8)
- 2. 3GPP TS 23.153 version 8.2.0 Release 8 1 ETSI TS 123 153 V8.2.0 (2009-01) Reference RTS/TSGC-0423153v820 Keywords LTE, UMTS ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N° 348 623 562 00017 - NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N° 7803/88 Important notice Individual copies of the present document can be downloaded from: http://www.etsi.org The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at http://portal.etsi.org/tb/status/status.asp If you find errors in the present document, please send your comment to one of the following services: http://portal.etsi.org/chaircor/ETSI_support.asp Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. © European Telecommunications Standards Institute 2009. All rights reserved. TM TM TM TM DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members. TM 3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. LTE™ is a Trade Mark of ETSI currently being registered for the benefit of its Members and of the 3GPP Organizational Partners. GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association. ETSI
- 3. 3GPP TS 23.153 version 8.2.0 Release 8 2 ETSI TS 123 153 V8.2.0 (2009-01) Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (http://webapp.etsi.org/IPR/home.asp). Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document. Foreword This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under http://webapp.etsi.org/key/queryform.asp. ETSI
- 4. 3GPP TS 23.153 version 8.2.0 Release 8 3 ETSI TS 123 153 V8.2.0 (2009-01) Contents Intellectual Property Rights ................................................................................................................................2 Foreword.............................................................................................................................................................2 Foreword.............................................................................................................................................................6 1 Scope ........................................................................................................................................................7 2 References ................................................................................................................................................7 3 Definitions and abbreviations...................................................................................................................8 3.1 3.2 4 4.1 4.2 4.3 5 5.1 5.2 5.3 5.4 5.4.1 5.4.2 5.4.3 5.4.4 5.4.5 5.4.6 5.5 5.6 5.6.1 5.6.2 5.6.3 5.6.4 5.6.5 5.6.6 5.6.7 5.7 5.8 5.8.1 5.8.2 5.8.3 5.8.4 5.8.5 5.9 5.10 6 Definitions..........................................................................................................................................................8 Abbreviations ...................................................................................................................................................10 Out-of-Band Transcoder control functionality.......................................................................................11 OoBTC Requirements ......................................................................................................................................11 Relationship between OoBTC and In-band TFO .............................................................................................12 Lawful interception ..........................................................................................................................................12 General Principles ..................................................................................................................................13 Network Model ................................................................................................................................................13 Simple call set-up .............................................................................................................................................13 Media Gateway Control for Codec Handling...................................................................................................14 UP Framing Protocol Handling for TrFO.........................................................................................................15 Framing Protocol Initialisation ...................................................................................................................15 RFCI Storage ..............................................................................................................................................17 RFCI Value Correction...............................................................................................................................18 TrFO Break.................................................................................................................................................18 TrFO Break Recovery.................................................................................................................................18 MGW Control Protocol Iu Framing Package properties.............................................................................19 TrFO/TFO Codec Negotiation Harmonisation.................................................................................................19 CN Node handling of Codec Types & Codec Modes.......................................................................................21 Signalling between UE and MSC ...............................................................................................................21 Node originating the OoBTC codec negotiation.........................................................................................22 Intermediate node .......................................................................................................................................22 Node terminating the OoBTC codec negotiation........................................................................................23 Signalling between server and MGW .........................................................................................................24 Signalling between MSC and UTRAN or GERAN Iu-mode .....................................................................24 Signalling between MSC and GERAN AoIP-mode ...................................................................................25 Inband Rate Control .........................................................................................................................................25 Modification Procedures ..................................................................................................................................26 Modification of Selected Codec..................................................................................................................27 Modification of Available Codecs List.......................................................................................................28 Mid-call Codec negotiation.........................................................................................................................29 Detailed Procedures For Iu Framing Protocol & Codec Modification .......................................................30 Unsuccessful Codec Modification ..............................................................................................................33 DTMF Handling For TrFO Connections..........................................................................................................37 Framing Protocol for GERAN AoIP mode.................................................................................................37 Detailed Call Procedures ........................................................................................................................38 6.1 Mobile to Mobile TrFO Call Establishment.....................................................................................................38 6.2 SRNS Relocation during TrFO ........................................................................................................................41 6.2.1 Intra-MSC SRNS Relocation ...................................................................................................................................42 6.2.2 Inter-MSC SRNS Relocation ...................................................................................................................................46 6.2.3 Codec Modification/ Mid-Call Codec Negotiation after Inter-MSC Relocation......................................................51 6.2.3.1 Codec Modification Initiated by the Far End Side ................................................................................................51 6.2.3.2 Mid-Call Codec Negotiation Initiated by the Far End Side...................................................................................54 6.2.3.3 Modification Procedure after Codec Change in the Serving MSC........................................................................57 6.3 IN and Call Forward SS ...................................................................................................................................57 6.3.1 TrFO interworking with SS (VMSC = service interworking node)............................................................58 ETSI
- 5. 3GPP TS 23.153 version 8.2.0 Release 8 4 ETSI TS 123 153 V8.2.0 (2009-01) 6.3.2 IN interworking (VMSC ≠ service interworking node) ..............................................................................60 6.4 Information flow for interaction with Multiparty SS .......................................................................................61 6.5 Information flow for handover from UMTS to GSM after TrFO establishment..............................................62 6.6 Call Hold/Call Wait..........................................................................................................................................63 6.7 External Network to Mobile TrFO Call Establishment ....................................................................................68 6.8 Mobile to External Network TrFO Call Establishment ....................................................................................69 6.9 Mobile to Mobile TrFO Call Establishment for GERAN Iu-mode ..................................................................70 6.10 Relocation during TrFO towards GERAN Iu-mode.........................................................................................71 6.11 Inter-MSC Handover during TrFO...................................................................................................................72 6.11.1 Inter-MSC Handover ..................................................................................................................................72 6.11.2 Codec Modification/Mid-Call Codec Negotiation after Inter-MSC Handover...........................................73 6.11.2.1 Codec Modification/Mid-Call Codec Negotiation Initiated by the Far End Side................................................73 6.11.2.2 TFO Codec Mismatch Resolution in the Serving MSC ......................................................................................73 6.11.2.3 Modification Procedure after Codec Change in the Serving MSC......................................................................73 6.12 Incoming data call from PSTN.........................................................................................................................73 6.12.1 Identification of data call at Visited MSC ..................................................................................................73 6.12.2 Handling at transit exchange in inhomogenous networks...........................................................................74 6.12.3 Identification of data call at G-MSC using multi-numbering .....................................................................74 6.13 Mobile to Mobile TrFO Call Establishment in GERAN AoIP mode...............................................................76 7 7.1 7.2 7.2.1 7.2.2 7.2.3 7.2.4 7.3 7.3.1 7.3.2 7.3.3 7.3.4 7.4 7.5 7.6 7.7 7.8 7.9 7.10 7.10.1 7.10.2 7.11 7.12 Interactions with supplementary services...............................................................................................80 Call Deflection service (GSM 23.072) .............................................................................................................80 Line identification services (GSM 23.081) ......................................................................................................80 Calling Line Identification Presentation (CLIP) .........................................................................................80 Calling Line Identification Restriction (CLIR)...........................................................................................80 Connected Line Identification Presentation (COLP) ..................................................................................80 Connected Line Identification Restriction (COLR) ....................................................................................80 Call forwarding services (GSM 23.082)...........................................................................................................80 Call Forwarding Unconditional (CFU) .......................................................................................................80 Call Forwarding on mobile subscriber Busy (CFB) ...................................................................................80 Call Forwarding on No Reply (CFNRy).....................................................................................................80 Call Forwarding on mobile subscriber Not Reachable (CFNRc)................................................................80 Call wait (GSM 23.083) ...................................................................................................................................80 Call hold (GSM 23.083)...................................................................................................................................81 Multiparty (GSM 23.084).................................................................................................................................81 Closed user group (GSM 23.085).....................................................................................................................81 Advice of charge (GSM 23.086) ......................................................................................................................81 Userto-user signalling (GSM 23.087) ..............................................................................................................81 Call barring (GSM 23.088)...............................................................................................................................81 Barring of outgoing calls ............................................................................................................................81 Barring of incoming calls ...........................................................................................................................81 Explicit Call Transfer (GSM 23.091) ...............................................................................................................81 Completion of Calls to Busy Subscriber (3G TS 23.093) ................................................................................81 8 Charging .................................................................................................................................................81 9 Codec Negotiation For SIP-I on Nc .......................................................................................................82 9.1 9.2 9.3 9.3.0 9.3.1 9.3.2 9.3.3 9.3.4 9.4 9.5 9.6 9.7 9.7.1 9.7.2 9.7.3 9.8 General .............................................................................................................................................................82 Framing Protocol..............................................................................................................................................82 Basic Procedures ..............................................................................................................................................82 Applicability ...............................................................................................................................................82 3GPP Node Originating SDP Offer ............................................................................................................82 3GPP Node Terminating SDP Offer...........................................................................................................82 3GPP Intermediate Node Receiving SDP Offer .........................................................................................83 3GPP Intermediate Node Receiving SDP Answer......................................................................................83 Semantics of 3GPP OoBTC Indicator ........................................................................................................83 Handling of Auxiliary Payload types..........................................................................................................84 Codec Negotiation Example Sequences ...........................................................................................................84 Codec Lists Structure .......................................................................................................................................89 General........................................................................................................................................................89 Rules for Constructing an Offer..................................................................................................................89 Rules for Constructing an Answer ..............................................................................................................90 Void ............................................................................................................................................................90 ETSI
- 6. 3GPP TS 23.153 version 8.2.0 Release 8 5 ETSI TS 123 153 V8.2.0 (2009-01) Annex A (informative): Codec Re-negotiation.....................................................................................91 Annex B (normative): Wideband Speech Service .............................................................................92 Annex C (informative): Status of Technical Specification 23.153......................................................94 History ..............................................................................................................................................................97 ETSI
- 7. 3GPP TS 23.153 version 8.2.0 Release 8 6 ETSI TS 123 153 V8.2.0 (2009-01) Foreword This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP). The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying change of release date and an increase in version number as follows: Version x.y.z where: x the first digit: 1 presented to TSG for information; 2 presented to TSG for approval; 3 or greater indicates TSG approved document under change control. y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc. z the third digit is incremented when editorial only changes have been incorporated in the document. ETSI
- 8. 3GPP TS 23.153 version 8.2.0 Release 8 1 7 ETSI TS 123 153 V8.2.0 (2009-01) Scope 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. 2 References 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] 3GPP TS 23.107: "QoS Concept and Architecture". [2] 3GPP TS 24.008: "Mobile radio interface layer 3 specification Core Network Protocols –Stage 3". [3] 3GPP TS 25.413: "UTRAN Iu Interface RANAP Signalling". [4] 3GPP TS 25.415: "UTRAN Iu Interface User Plane Protocols". [5] 3GPP TS 26.103: "Speech codec list for GSM and UMTS". [6] 3GPP 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] 3GPP TS 23.205: "Bearer-independent CS Core Network.". [9] 3GPP TS 33.106: "3GPP Security; Lawful Interception Requirements". [10] 3GPP TS 28.062: "Inband Tandem Free Operation (TFO) of Speech Codecs; Service Description; Stage 3". [11] 3GPP TS 23.009: "Handover Procedures". [12] 3GPP TS 29.232: "Media Gateway Controller (MGC) – Media Gateway (MGW) interface; Stage 3". [13] ITU-T H.248: "Gateway Control Protocol". [14] 3GPP TS 29.415: "Customised Applications for Mobile network Enhanced Logic (CAMEL) Phase 3; CAMEL Application Part (CAP) specification". [15] 3GPP TS 48.008: "Mobile-services Switching Centre – Base Station System (MSC – BSS) interface; layer 3 specification" [16] 3GPP TS 43.051: "Technical Specification Group GSM/EDGE; Radio Access Network; Overall description - Stage 2; " [17] 3GPP TS 23.172: "Technical realization of Circuit Switched (CS) multimedia service; UDI/RDI fallback and service modification - Stage 2". ETSI
- 9. 3GPP TS 23.153 version 8.2.0 Release 8 8 ETSI TS 123 153 V8.2.0 (2009-01) [18] 3GPP TS 34.108: "Common test environments for User Equipment (UE) conformance testing". [19] 3GPP 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] 3GPP TS 23.231: "SIP-I Based Circuit-Switched Core Network; Stage 2". [21] 3GPP TS 29.231: " Application of SIP-I Protocols to Circuit Switched (CS) core network architecture; Stage 3". [22] IETF RFC 4733 "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals". [23] IETF RFC 3389: " Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)". [24] IETF RFC 3264: "An Offer/Answer Model with the Session Description Protocol (SDP)". [25] IETF 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] IETF RFC 3362: "Real-time Facsimile (T.38) - image/t38 MIME Sub-type Registration" 3 Definitions and abbreviations 3.1 Definitions 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: i) 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. ii) Supported Codecs List (BSSMAP) - "BSC-SCL" - this is the list of codecs supported by the BSS (BSSSCL). 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. iii) 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 Iumode 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 3GPP TS 23.172 [17], the multimedia dummy codec will be included (see 3GPP TS 26.103 [5]). iv) 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 ETSI
- 10. 3GPP TS 23.153 version 8.2.0 Release 8 9 ETSI TS 123 153 V8.2.0 (2009-01) achieved end-to-end, also by the UEs and the radio access networks that are involved in the call. At interMSC 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. v) 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. vi) 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 3GPP TS 26.103 [5]), are not included. vii) 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 IuAvailable Codecs List (MAP) according to the capabilites of its associated MGW and the new target radio access, if necessary. viii) 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. ix) Iu-Currently Used Codec (MAP) – this is the codec in use on the serving Iu interface prior to an inter-MSC handover. x) 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]). xi) 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]). xii) 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. xiii) 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). 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 NOTE 1: When the TFO protocol is not supported by both transcoders or the coding schemes are not compatible then normal "Tandem" operation occurs and PCM encoded speech is passed 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 ETSI
- 11. 3GPP TS 23.153 version 8.2.0 Release 8 10 ETSI TS 123 153 V8.2.0 (2009-01) 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 NOTE 2: For example ITU G.711 A-law. Transcoding free link (TrFL): bearer link, where compressed voice is being carried between bearer endpoints NOTE 3: Within the UMTS network, the compressed voice is transmitted in Iu/ Nb User Plane format, depending on the related interface. Tandem free link (TFOL): bearer link between transcoders that are operating in Tandem Free Operation mode, i.e. bypassing the transcoding functions NOTE 4: The involved transcoders can be a UMTS transcoder or a GSM TRAU with TFO functionality. Transcoder free operation (TrFO): calls that have no transcoders involved in the connection between the source codecs NOTE 5: For mobile to mobile calls this is UE to UE, although the connection could be UE to another type of terminal. TrFO operation is considered a concatenation of TrFLs between RNCs. NOTE 6: In case of mobile to fixed network calls the term "Transcoder free operation" is applicable for the TrFLs carrying compressed speech. The TrFO usually ends at the Gateway to the PSTN where the speech is transcoded e.g. to G.711. 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 NOTE 7: The Iu framing protocol is specified by [4]. 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 For the purposes of the present document, the abbreviations defined in GSM 01.04 and the following apply: ACS APM BC BICC CC CCD CFNRc CFNRy IN IuFP MACS OM OoBTC Active Codec mode Set Application Transport Mechanism Bearer Control Bearer Independent Call Control Call Control Conference Call Device Call Forward Not Reachable Call Forward on No Reply Intelligent Network Iu Framing Protocol Maximal number of codec modes in the ACS Optimization Mode Out-of-Band Transcoder Control ETSI
- 12. 3GPP TS 23.153 version 8.2.0 Release 8 QoS RAB SCS TFO TICC TrFO UP 11 ETSI TS 123 153 V8.2.0 (2009-01) Quality of Service Radio Access Bearer Supported Codec mode Set Tandem Free Operation Transport Independent Call Control Transcoder Free Operation User Plane 4 Out-of-Band Transcoder control functionality 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. ETSI
- 13. 3GPP TS 23.153 version 8.2.0 Release 8 - 12 ETSI TS 123 153 V8.2.0 (2009-01) 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 renegotiation. 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. - 4.2 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. 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. ETSI
- 14. 3GPP TS 23.153 version 8.2.0 Release 8 13 ETSI TS 123 153 V8.2.0 (2009-01) 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]. 5 General Principles 5.1 Network Model The codec negotiation mechanism (OoBTC) is designed to work in the general situation where more than two call control (CC) nodes need to participate in the codec negotiation. The codec negotiation mechanism works as follows: - Originating CC node: sends its list of supported codec types and options, listed in order of preference. - Transit CC nodes: if needed, analyse the received list of options, delete unsupported options from the list and forward the list. No modification is done to the preference levels of any of the listed codecs. - Terminating CC node: analyse the received list of options with their associated priorities and selects the supported option with highest indicated priority appropriate for the call. Figure 5.1/1 illustrates the architecture for Rel-4 for UMTS to UMTS TrFO connection. The transit network may exist for calls between PLMNs or between islands of mobile CNs separated by transit networks. This figure is a basic illustration, OoBTC shall apply to other access technologies where the OoBTC procedures are supported, i.e. not limited to this figure. The negotiation occurs at call set-up phase, and possibly later on in the call due to other changes such as handover or relocation. However, as described in the next clause, it shall be possible to modify the selected codec at any moment during the active phase of the call. Further detail of the Call & Bearer Separation for 3GPP is described in [8]. Control Plane MSC Server RANAP OoB Codec Negotiation Bearer Req ME RNC User Plane Radio Bearer Iu Bearer OoB Codec Negotiation T r a MGw n Control s i Bearer Req t MGW N e t w o CN bearer r k MSC Server OoB Codec RANAP Negotiation MGw Control Bearer Req RNC MGW Iu Bearer ME Radio Bearer End to end connection Figure 5.1/1. Basic Architecture for UMTS to UMTS TrFO Connection The following clauses describe successful call establishment scenarios using the codec negotiation mechanism. 5.2 Simple call set-up The signalling flow for the simple call set-up case is illustrated in figure 5.2/1. Codec negotiation is done prior to the establishment of bearer connections, so that appropriate bearer resources are committed to the call. In the proposed sequence, the codec negotiation starts with the IAM message containing the list of supported codec types (in this ETSI
- 15. 3GPP TS 23.153 version 8.2.0 Release 8 14 ETSI TS 123 153 V8.2.0 (2009-01) example v, w, x, y, z), sent by the Originating MSC (O-MSC). Transit nodes may puncture out (i.e. delete) codec types from the list (in this example y). The terminating MSC (T-MSC) selects the codec type (here v) The selected codec is conveyed in an APM message, together with the remaining list of alternative, but currently not selected codec types (here v, x, z). O-MSC T-MSC Transit Transit MGW O-MGW T-MGW Codec List (v, w, x, y, z) Codec List (v, w, x, z) Selected Codec = v Selected Codec = v, Available List (v, x, z, ) Selected Codec = v, Available List (v, x, z, ) Selected Codec = v Selected Codec = v Bearer Established Bearer Established Figure 5.2/1. Basic Codec Negotiation Sequence The codec list for BICC is specified according to [7], where each 3GPP codec entry is defined according to [5]. 5.3 Media Gateway Control for Codec Handling The general handling of MGW control procedures are detailed in [8]. Specific handling related to the control of the speech encoding is detailed in Figure. 5.3/1. The terms context, termination, streams and stream properties are described in the ITU-T H.248 "Media Gateway Control Protocol" [13]. Stream property: Speech codec = codec y Stream property: Speech codec = codec x Media Gateway context Termination T1 Termination T2 streams streams Figure 5.3/1. MGW control for speech codec The handling of transcoding between one codec type (media stream property applied at one termination) and another codec type (media stream property at other termination) is a function of the MGW. The media stream property for Audio Codec Type is defined in Annex C of the ITU-T MGW control protocol, H.248. ETSI
- 16. 3GPP TS 23.153 version 8.2.0 Release 8 15 ETSI TS 123 153 V8.2.0 (2009-01) If TFO-incompatible codec types are applied at different terminations of the same context, the MGW shall insert a transcoder. For the definition of TFO-compatibility between 3GPP codec types and codec configurations see [10], clauses 11 and 12. Between codecs of the AMR codec family, the MGW need not insert a transcoder, if the codec types are TFOcompatible according to [10], table 11-1, and - the codecs use the same ACS; or - the ACSs are TFO-compatible and the use of codec modes is restricted to a common subset of the ACSs by means of maximum rate control. In this case the MGW shall coordinate the rate control request. Between codecs of the AMR-WB codec family, the MGW need not insert a transcoder, if - the codecs use the same ACS; or - the use of codec modes is restricted to a common subset of the ACSs by means of maximum rate control. In this case the MGW shall coordinate the rate control request. 5.4 UP Framing Protocol Handling for TrFO 5.4.1 Framing Protocol Initialisation For TrFO calls the compressed speech is carried end to end (RNC to RNC or between RNC and other compressed voice terminal). In 3GPP Core Networks compressed voice framing protocol shall be specified by the Nb User Plane specification. The specification for Iu interface is defined in [4], the specification for the Nb interface is defined in [12]. The framing protocol for these interfaces is the same, Iu framing and is thus described as such, for both the Iu interface and the Nb interface. For compressed voice only the support mode is used, thus for TrFO the UP Initialisation procedure defined for the Nb UP shall be supported by the CN, when a CN MGW is required to establish a connection. When negotiating TrFO OoB, a given serving MSC server shall consider the capabilities of the RNCs and MGWs, which are candidates to handle the TrFO call and which are controlled by this MSC server via an Iu/Mc interface. For TrFO, the selected RNC and MGW have to be able to support at least one Iu/Nb UP version with TrFO capabilities. Each MGW and RNC that supports TrFO shall support Iu/Nb UP version 2. If an RNC only supports Iu UP version 1 without TrFO capabilities, the MSC server shall insert a transcoder at the MGW that is connected to this RNC. For a TrFO call, each MSC server shall indicate in the "RAB assignment"/"Add request" only UP versions with TrFO capabilities. In the inband UP framing protocol version negotiation during framing protocol initialisation, the informed RNCs/MGW shall only offer and/or accept UP version listed in the "RAB assignment"/"Add request". The Iu framing Protocol is established through the CN in a forward direction, independently of the bearer establishment direction. The Notify message to indicate bearer establishment shall not be sent until the Iu framing has been initialised. The continuity message (COT) shall not be sent forward until the Notify message has been received from the MGW and also the COT from the previous server has been received. The sequences for mobile originated calls are shown in figures 5.4/1 and 5.4/2 for forward bearer and backward bearer establishment, respectively. The parameters in the Add Request messages in the Figures are described in further detail in clause 5.4.5. ETSI
- 17. 3GPP TS 23.153 version 8.2.0 Release 8 RNC-0 16 MSC-O MGW-O ETSI TS 123 153 V8.2.0 (2009-01) Server-y MG-y Initial Address, Codec List Initial Address, Codec List Selected Codec, Bearer Information ADD.request (CN, incoming) ADD.reply Selected Codec,Bearer Information ADD.request(CN, incoming) Bearer Establish ADD.reply Bearer Confirm RAB ASSIGN REQ ADD.request (RAN, incoming) STORE RFCIs, ADD.reply Acknowledge Iu framing protcol Init, forward control PDUs to network side of MGW Bearer Establish Bearer Confirm Iu UP Init Iu UP Init Ack NOTIFY.req RAB ASSIGN RSP Continuity STORE RFCIs, Acknowledge framing protocol Init, forward control PDUs to network side of MGW Bearer Confirm Continuity Figure 5.4.1/1: Iu Framing Protocol Establishment, Forward Bearer ETSI
- 18. 3GPP TS 23.153 version 8.2.0 Release 8 17 GM SC Initial Address ETSI TS 123 153 V8.2.0 (2009-01) M G-G M SC-T M GW -T AD D .request (C N, incoming) AD D .reply Initial Address AD D .request (C N, incoming) Codec Information Codec Information AD D .request (C N, incoming) B earer Establish Bearer Establish AD D.reply AD D.reply STO RE RFCIs, Acknowledge Iu Framing Protocol Init, forw ard control PDUs to network side of M GW Bearer Confirm STORE RFCIs, Acknowledge Iu franing protocol Init, forward control PDUs to network side of M GW B earer Confirm NO TIFY.req STORE RFCIs, Acknow ledgeIu framing protocol Init, terminate Iu framing protocol. NO TIFY.req Continuity Address Complete Address Complete Figure 5.4.1/2: Iu Framing Protocol Establishment, backward bearer. The transport independent call control procedures in [8] shall support a continuity mechanism, as described above. 5.4.2 RFCI Storage The RNC shall allocate RAB Subflow Combination Indicators to the SDU formats (SDU formats sent to the RNC by the MSC in the RAB Assignment). This allocation is then sent in the Iu Framing Initialisation PDU by the RNC in the User Plane. For further details see [3] and [4]. During the TrFO call establishment each MGW linked into the call shall store the RFCIs received from Iu Framing PDU Type 14. The first subflow combination in the initialisation frame corresponds to an Initial Rate Control, i.e. indicates the highest rate for the first speech mode to be used in the direction of the Initialisation Acknowledgement frame. After the out of band codec negotiation has been performed, if the originating side is a UTRAN, then on request from the MSC for a RAB Assignment, it shall initiate the Iu user plane. If the originating side is a network that does not support Iu Framing then the Iu Framing initialisation is initiated by the GMSC, as described in detail in Clause 6.7. An Initialisation Protocol Data Unit (PDU) shall be sent to the first MGW in the call connection. Each initialisation leg is acknowledged per TrFO Link, i.e. per MGW-MGW interface. The subsequent initialisation is performed using the same RFCI set as received from the preceding node, independently of the Stream mode directions (i.e. if the terminations are not through connected). This is shown figure 5.4.2/1. Figure 5.4.2/1: RFCI Storage and subsequent initialisation in MGW When the MGW terminations are through-connected and the RFCIs at both terminations are matching, then the MGW may revert to transparent mode; the RNCs shall not perform any subsequent Iu Framing initialisations without explicit request by the serving MSCs. ETSI
- 19. 3GPP TS 23.153 version 8.2.0 Release 8 18 ETSI TS 123 153 V8.2.0 (2009-01) All succeeding MGWs in the path shall behave in a similar way as described above. 5.4.3 RFCI Value Correction At the terminating end of a TrFO connection with Iu Framing initialised to the terminating MGW, the originating RFCI allocation is stored. The terminating RNC is then requested to perform a RAB Assignment towards the terminating MGW. This results in an Iu Framing initialisation, where the allocation of the RFCI values is independent from the Originating RNC's allocation. These values may then be different to the originating RNC's set. The terminating MGW shall acknowledge the Iu Framing Initialisation and compare the RFCI values stored from the originating side. If the allocated index values do not match, then the MGW shall perform one of the following procedures: 1) initiate an Iu Framing Initialisation PDU towards the terminating RNC with the RFCI allocation as defined by the preceding node (previously stored in the MGW. This behavior is shown in figure 5.4.3/1 and termed 'RFCI value correction') As the first Subflow combination received from the terminating RNC corresponds to an initial (maximum) rate control the MGW shall send a Rate Control PDUindicating this maximum speech mode back to the preceeding node in the core-network. 2) map the RFCI indices of the incoming side to the corresponding RFCI indices at the outgoing side for all SDUs passed between the Iu Framing protocol terminations. As the first Subflow combination in the IuUP initialisation corresponds to an initial rate control, i.e. indicates maximum rate for the mode to be used (in direction of Initialisation acknowledgement frame) it is treated as the initial maximum rate control (see [4]) the MGW shall initiate a Rate Control PDU indicating this maximum speech mode toward the terminating RNC. Similarly as the first Subflow combination received from the terminating RNC corresponds to an initial (maximum) rate control the MGW shall send a Rate Control PDUindicating this maximum speech mode back to the preceding node in the core-network. For further details on the rate control see clause 5.7. MGw RNC MGw Termination MGw Termination RFCIs Stored RFCIs Stored IU Initialisation) RFCI’s Match ? NO IU Initialisation ACK) IU Initialisation) IU Initialisation ACK) Figure 5.4.3/1:RFCI Value Correction Further details of the TrFO call establishment are described in clause 6. This resolution handling is required also during RNC relocation; further details are described in clause 6. 5.4.4 TrFO Break The event and procedure when a TrFO connection must be interrupted at a certain point in the path, e.g. due to a supplementary service invocation or for handover/relocation, is termed "TrFO Break". A TrFO Break may occur at a MGW as a consequence of a command directed by the associated Server. During this period the Iu User Plane protocol is terminated by this MGW, in general at both sides of the MGW. This means that it must respond to new Initialisation PDUs and Inband Rate Control PDUs. The MGW inserts a TrFO Break Function, which then makes use of the stored RFCI values, in order to perform the required Iu Framing protocol functions and interpret the payload. Further call scenarios for specific services that incur a TrFO break are described in clause 6.. 5.4.5 TrFO Break Recovery During the TrFO break situation the individual connections are free to change, the RFCIs may have changed and also the rate control (maximum rate, current rate). After the service that caused the TrFO break is complete, the MGW shall ETSI
- 20. 3GPP TS 23.153 version 8.2.0 Release 8 19 ETSI TS 123 153 V8.2.0 (2009-01) check if TrFO.can be re-established. If the coding schemes are matching but the RFCI's have changed then RFCI value correction can be performed at the RNC side. In order to correct any changes in rate control between two RNCs, the MGW shall send a rate control request from each Termination, with the current rate and maximum rate applied at the other Termination. This will then result in the Distributed Rate Decision between the two RNCs in the call. 5.4.6 MGW Control Protocol Iu Framing Package properties The following is a summary of the Iu Framing H.248 requirements; the procedures are described in [12] and are valid for Iu Framing in Support Mode: Additional Package Properties: Iu Framing Termination Type: Values - Iu-RAN (Iu Framing Protocol on Iu Interface) Iu Framing Initialisation Procedure: Iu-CN (Iu Framing Protocol on Nb Interface) Values – Incoming (For Iu-CN: the Iu Framing Protocol initialisation is received by the media gateway and used for subsequent initialisation from this MGW. For Iu-RAN this indicates the originating RNC interface). - Outgoing (For Iu-CN the Iu Framing Protocol is generated by the core network MGW, i.e. initialised on the Nb Interface. For the Iu-RAN interface this specifies the terminating RNC Interface) 5.5 TrFO/TFO Codec Negotiation Harmonisation When OoBTC procedures are initiated to a node where compressed voice cannot be supported (either at the node or to the preceding node) then a transcoder is inserted. This can be due to the transport technology (e.g. TDM) or due to the access technology (e.g. GSM with TDM based A-interface). The OoBTC procedures can result in the following call scenarios: Supported Codecs List (BICC) (X, Y, Z) MSC Supported Codecs List (BICC) (Y) ISUP TSN TSN Selected Codec (BICC) (X) MSC Selected Codec (BICC) (Y) PLMN 1 TRANSIT PLMN 2 UTRAN UTRAN Codec (X) MGW G.711 MGW Codec (Y) MGW MGW ATM / IP TDM ATM / IP Figure 5.5/1: Cascaded TrFO & Transcoding In Figure 5.5/ 1 the OoBTC cannot proceed as the call crosses a transit network that does not support compressed voice. The same could occur if the transit network did not support out of band codec negotiation (Support in BICC is optional). In Figure 5.5/2 the OoBTC procedures result in the call terminating to a TDM based GSM access. As the GSM radio access transcodes to default PCM codec, the OoBTC results in default PCM selected. The reply is passed back to the originating network, which then inserts a transcoder from default PCM to AMR for the UMTS radio access. ETSI
- 21. 3GPP TS 23.153 version 8.2.0 Release 8 20 ETSI TS 123 153 V8.2.0 (2009-01) Codec list: U-AMR, U-AMR2, PCM Codec list: U-AMR, U-AMR2, PCM MSC TSN Codec list:U-AMR, U-AMR-2 Selected = PCM Selected = PCM UE MSC Select U-AMR UMTS RAN MG MG MG GSM BSS PLMN 2 MS PLMN 1 GSM Codecs: e.g. GSM FR, FR AMR, EFR Figure 5.5/2: UMTS to GSM interworking In a similar situation to that described in Figure 5.5/2, it is also possible that the OoBTC procedures result in UMTS_AMR_2 as the selected codec, as this is compatible with FR_AMR codec. This is the optimal codec selection for speech quality purposes. In this case, the transcoder shall be inserted at the terminating MGW in order to transcode between PCM and UMTS_AMR_2, and UMTS_AMR_2 shall be signalled back to the originating UE. TFO can then be used on the terminating A-interface to allow FR_AMR to be passed between the tandemed codecs, allowing the best speech quality in the core network. Further to the scenario described above in Figure 5.5/2, where there is no TFO compatible codec between the UMTS UE and the GSM MS it is also possible that the OoBTC procedures result in UMTS_AMR as the selected codec. In this case, the transcoder shall be inserted at the terminating MGW in order to transcode between PCM and UMTS_AMR (as an example), and UMTS_AMR shall be signalled back to the originating UE. Bandwidth savings and avoiding degradation in speech quality are then achieved in the core network. For TFO to establish between the transcoders in the above scenarios, each TRAU must send a codec list inband after the call has been established. If a common codec type is available (determined by pre-defined rules, described in TFO specification [10]) then the OoBTC procedures need to be informed so that a codec modification can be performed. This is shown in Figure 5.5/3. Note – a modification could also be required when a common codec type has been selected but the ACS is not common. Supported Codecs List (BICC) (X, Y, Z) MSC Selected Codec (X) Supported Codecs List (BICC) (Y, Z) ISUP TSN TSN MSC Codec Modify (Z) Codec Modify (Z) UTRAN TFO Codec List (X, Y, Z) Codec (X -> Z) Selected Codec (Y) Optimal Codec ( Z) MGW G.711 UTRAN TFO Codec List (Y, Z) MGW Codec (Y -> Z) MGW MGW TFO (Z) ATM / IP TDM ATM / IP PLMN 1 TRANSIT PLMN 2 Figure 5.5/3: TFO support by OoBTC signalling In H.248, the vertical MG control protocol, the coding types are specified by Media Stream Property, as defined by Annex C of H.248 specification. A specific package is used for TFO (see [12]). ETSI
- 22. 3GPP TS 23.153 version 8.2.0 Release 8 21 ETSI TS 123 153 V8.2.0 (2009-01) The basic requirements are listed below: i) Property for TFO Codec List (same format as for [5]) ii) Event for Optimal Codec, as determined by TFO in-band protocol iii) Event for Distant Codec List sent by the distant TFO partner iv) Event for TFO status v) Procedures to define and enable TFO The TFO package allows the Server to request the MGW to initiate the TFO in-band protocol towards a far end transcoder. The package includes a property to turn on/off the TFO (tfoenable); this may be required prior to TrFO break situations such as handover. The TFO Codec List (H.248) is passed via the Mc interface from the Server to the MGW. The first entry of the TFO Codec List (H.248) shall be used by the MGW as the 'Local Used Codec'. The other entries of the TFO Codec List (H.248) shall be used by the MGW as Local Codec List in the TFO in-band negotiation (see [10]). For adaptive multirate codecs (AMR and AMR-WB codecs) some control of the level of negotiation is performed by the "Optimization Mode" parameter in the respective Single Codec information element in the TFO Codec List (H.248) (see [5] and [12]). This allows a node to indicate if the offered ACS may be modified or not during TFO procedures, and this is mapped to the appropriate parameter in the TFO protocol by the MGW. If for a Single Codec information element in the TFO Package from the Server to the MGW the OM is set to "Optimization of the ACS not supported", then the TFO Negotiation shall not change the offered ACS of the respective Single Codec information element. The MGW returns Notification Events for the Distant Codec List sent by the far end and the Optimal Codec Type as selected by the Codec Selection mechanism in TFO. The first entry of the Distant Codec List (H.248) is the 'Distant Used Codec' as received by the MGW during TFO in-band negotiations. The other entries of the Distant Codec List (H.248) are the entries of the Distant Codec List as received by the MGW from the distant TFO Partner (see [10]). The Server then compares the Distant Codec List (H.248) with its previously negotiated Available Codec List (BICC). If the lists are not the same then an OoBTCCodec List Modification or Mid-call Codec Negotiation may be performed. If for a Single Codec information element in the TFO Package from the MGW to the Server the OM is set to "Optimization of the ACS not supported", then the offered ACS of the respective Single Codec information element shall not be changed during OoBTC procedures. If the TFO Status event is supported by the MGW and has been configured by the MSC Server, the MGW shall return notification indicating whether a TFO link has been established or broken. The MGW should not report transient TFO status change. 5.6 CN Node handling of Codec Types & Codec Modes 5.6.1 Signalling between UE and MSC The default Codec Type for 'R99 UMTS only' terminals is UMTS_AMR, the default Codec Type for all terminals supporting GSM and UMTS radio access is UMTS_AMR_2, (see [5] for the detailed description). The UMTS_AMR_2 is a superset of the UMTS_AMR. It behaves as a FR_AMR codec in the UL and as a UMTS_AMR codec in the DL. This allows all UMTS terminals, except R99 UMTS only terminals, to operate in TFO with GSM terminals. The UMTS_AMR_2 is fully compatible with R99 CN nodes (TC in MGW). In any multi-mode configuration the UMTS_AMR shall be treated as only TFO and TrFO compatible to itself, not to any other AMR codec Type, to avoid incompatibilities in TFO-TrFO-TFO interworking scenarios. In single mode configuration, UMTS_AMR and UMTS_AMR_2 are TFO and TrFO compatible, when both codec types use the same single rate ACS, (see [10]). During call setup, a UE supporting Rel-4 or later releases will indicate to the MSC the codecs supported by the UE in the Supported Codecs List (DTAP) (see [2]). For the codecs in this Supported Codecs List (DTAP), no order of priority is defined. If no Supported Codecs List (DTAP) is received and the UE is 'UMTS only', then the MSC shall assume UMTS_AMR as supported Codec Type. If no Supported Codecs List (DTAP) is received, but the UE is 'dual system', then the MSC shall assume UMTS_AMR_2 as the supported codec type. The MSC shall assume 'dual system' support only if the UE indicates at least one GSM speech version in Octet 3a etc. of the Bearer Capability. ETSI
- 23. 3GPP TS 23.153 version 8.2.0 Release 8 5.6.2 22 ETSI TS 123 153 V8.2.0 (2009-01) Node originating the OoBTC codec negotiation The node originating the OoBTC codec negotiation shall implement the procedures described in Q.1902.4, subclause 8.3.1 [6]. Additionally, the following applies: In UTRAN, GERAN Iu mode or GERAN AoIP mode, when constructing the list of codecs (and configurations for AMR or AMR-WB codecs) for the Supported Codecs List (BICC), the MSC Server should take the codec types and codec configurations supported by the RNC or BSC into account (see subclause 5.6.6 for UTRAN or GERAN Iu mode and section 5.6.7 for GERAN AoIP mode). The MSC may include more than one Single codec element indicating the same codec type, but different configurations, in the Supported Codecs List (BICC) (see [5]). NOTE: This may be necessary, e.g. if the RNC supports for an AMR codec different sets of codec modes, e.g., (a, b, c, d) and (e, f, g), which are not subsets of each other, and the RNC does not support combinations of these sets, e.g. (a, b, c, d, e, f, g). For AMR codecs the originating CN node shall use the "Optimization Mode" parameter in the Single Codec information element in the Supported Codec List (BICC) (see [5]) to indicate whether or not other nodes may change the offered ACS. EXAMPLE: An RNC implementing only the prioritised RABs for interoperability testing specified in [18] will support for the UMTS_AMR_2 codec e.g. the set of codec modes (12.2, 7.4, 5.9, 4.75), but none of its subsets containing 2 or 3 codec modes. If the MSC Server connected to this RNC includes the codec configuration (12.2, 7.4, 5.9, 4.75) in the Supported Codecs List (BICC), it will therefore set the OM parameter of the respective Single Codec information element to "Optimization of the ACS not supported". For AMR codecs, if the OM is set to "Optimization of the ACS supported", the originating CN node shall indicate the maximum number of codec modes (MACS) that may be selected for the ACS during speech codec negotiation. This maximum number of codec modes may depend on optimization strategies applied by the originating CN node. The recommended value is 4 (see [10]). For AMR-WB codecs the "Optimization Mode" is defined implicitly by the configuration parameter "Config-WBCodec" in the Single Codec information element (see [5]). If for a configuration the OM is set to "Optimization of the ACS supported", then the configuration may be changed to any other allowed configuration specified in [5]. In order to support interworking with 2G systems it is recommended that MGWs support 2G codecs (GSM_HR, GSM_FR, GSM_EFR, PDC_EFR, TDMA_EFR). In order to avoid modifications during handover between 2G and 3G systems the MSC nodes may give preference to a suitable 2G codec. Whenever one or several TrFO links have been already established and initialised, the CN node (e.g. the serving CN in case of Call Hold scenarios, the visited CN node in case of Call Forwarding scenarios, etc.) initiating a subsequent codec negotiation on a new call leg or a mid-call codec negotiation on an established and initialised TrFO link, should give the already negotiated Selected Codec (BICC), including its ACS, highest preference to reduce the probability of having to perform a bearer re-establishment or UP re-initialisation of the already established and initialised TrFO links. The creation of a "structured" Supported codec list shall be as described for SIP-I (see Clause 9.7.2). NOTE: 5.6.3 The auxiliary payload types do not apply to BICC. Intermediate node An intermediate node taking part in an OoBTC codec negotiation shall implement the procedures described in Q.1902.4, subclause 8.3.2 [6]. Additionally, the following applies: If a Single Codec information element for an AMR codec is included in the Supported Codecs List (BICC), with the OM set to "Optimization of the ACS not supported", the intermediate node shall delete the Single Codec information element i) if the codec type is not supported; or ii) if one or more codec modes of the offered ACS are not supported. ETSI
- 24. 3GPP TS 23.153 version 8.2.0 Release 8 23 ETSI TS 123 153 V8.2.0 (2009-01) If a Single Codec information element for an AMR codec is included in the Supported Codecs List (BICC), with the OM set to "Optimization of the ACS supported", the intermediate node i) shall delete the Single Codec information element, if the codec type is not supported; ii) shall delete codec modes from the offered SCS and ACS, if they are not supported. If the last codec mode is deleted from the offered SCS, the Single Codec information element shall be deleted from the Supported Codecs List (BICC); iii) shall reduce MACS to a locally supported value, if necessary; iv) may change the ACS to a different ACS within the offered SCS; and v) shall change the OM parameter from "Optimization of the ACS supported" to "not supported", if necessary. NOTE: In interworking scenarios with TFO, step (iv) may prevent the establishment of an end-to-end tandem free and transcoder free connection; therefore, the intermediate node should not do this without a good reason. During the processing of a Single Codec information element of an AMR codec with the OM set to "Optimization of the ACS supported", the intermediate node may replace the original Single Codec information element by two or more new Single Codec information elements, which can be derived from the original Single Codec information element by the steps (i) to (v) listed above. If a Single Codec information element for an AMR-WB codec is included in the Supported Codecs List (BICC), the intermediate node shall i) delete the Single Codec information element, if the codec type or codec configuration is not supported; or ii) replace a Single Codec information element with configuration 1, 3, or 5 (see [5], table 5.7-1) by a Single Codec information element with configuration 0 and, optionally, another Single Codec information element with configuration 2 or 4, if configuration 3 or 5 is not supported. 5.6.4 Node terminating the OoBTC codec negotiation The node terminating the OoBTC codec negotiation shall implement the procedures described in Q.1902.4, subclause 8.3.3 [6]. Additionally, the following procedures apply: The terminating node shall process the Supported Codecs List (BICC) as described for the intermediate note in subclause 5.6.3. In UTRAN, GERAN Iu mode or GERAN AoIP mode, when processing the codec types (and configurations for AMR or AMR-WB codecs) in the Supported Codecs List (BICC), the terminating MSC Server should take the codec types and codec configurations supported by the terminating RNC or BSC into account (see subclause 5.6.6 for UTRAN or GERAN Iu mode and section 5.6.7 for GERAN AoIP mode). For the selection of the Selected Codec (BICC) from the Supported Codecs List (BICC), the following additional procedures apply: If an adaptive multi-rate codec is selected, then the decision about the actual codec modes to be included in the selected ACS shall also be made by the terminating CN node. If the OM of the offered configuration is set to "Optimization of the ACS supported", the selected ACS may be different from the offered ACS, but it shall be a subset of the offered SCS and be consistent with MACS. In order to provide harmonisation of out of band codec negotiation (for TrFO) and inband codec negotiation (for TFO) similar codec type and codec configuration selection mechanisms as those being defined for TFO should be applied for TrFO (see [10]). NOTE: For TrFO codec negotiation, besides the speech quality additional aspects may be considered which are not applicable to TFO, e.g. the location of the transcoder that may need to be inserted or possible bandwidth savings in the core network. If an adaptive multi-rate codec is selected, the terminating MSC Server shall exactly specify the ACS in the Selected Codec (BICC) and set the OM to "Optimization of the ACS not supported". ETSI
- 25. 3GPP TS 23.153 version 8.2.0 Release 8 24 ETSI TS 123 153 V8.2.0 (2009-01) In the Available Codecs List (BICC), sent back to the originating node, the terminating MSC server may include more than one Single Codec information element indicating the same codec type, but different configurations. Single Codec information elements for adaptive multi-rate codecs may also be included with the OM set to "Optimization of the ACS supported" and the ACS being a subset of the SCS. According to Q.1902.4, subclause 8.3.3 [6], the terminating node shall include the Selected Codec (BICC) in the Available Codecs List (BICC). For AMR and AMR-WB codecs, the following applies: If the Selected Codec (BICC) is an AMR codec, it shall be considered as included in the Available Codecs List (BICC), if the Available Codecs List (BICC) contains a Single Codec information element with the same codec type and - exactly the same configuration, i.e. the same ACS and the OM set to "Optimization of the ACS not supported"; or - the Selected Codec (BICC) is consistent with the Single Codec information element, i.e. the selected ACS is a subset of the SCS of the Single Codec information element, the Number of codec modes in the selected ACS is less or equal to the MACS parameter of the Single Codec information element, and the OM of the Single Codec information element is set to "Optimization of the ACS supported". If the Selected Codec (BICC) is an AMR-WB codec, it shall be considered as included in the Available Codecs List (BICC), if the Available Codecs List (BICC) contains a Single Codec information element with the same codec type and - exactly the same configuration, i.e. the same the configuration parameter "Config-WB-Codec"; or - any configuration for which the OM is set to "Optimization of the ACS supported". The creation of a "structured" Available codec list shall be as described for SIP-I (see Clause 9.7.3). NOTE: 5.6.5 The auxiliary payload types do not apply to BICC. Signalling between server and MGW According to Q.1902.4, subclause 8.3 [6], during the OoBTC codec negotiation a server can provide its associated MGW with the preferred codec from the Supported Codecs List (BICC), and as a result of the negotiation the server will provide its associated MGW with the Selected Codec (BICC). The information is sent via the Mc interface as Codec (H.248). If the Codec (H.248) is an adaptive multi-rate codec, the server shall exactly specify the ACS in the respective Single Codec information element and set the OM to "Optimization of the ACS not supported", both for the preferred codec and the Selected Codec (BICC). For the Single Codec information elements of adaptive multi-rate codecs in the TFO Codec List (H.248), the OM may be set to "Optimization of the ACS supported", and the ACS may be a subset of the SCS. This applies also to the first entry in the TFO Codec List (H.248), the Local Used Codec. NOTE: 5.6.6 In some scenarios the flexible configuration of the Local Used Codec may be used for a faster TFO establishment (see [10]). Signalling between MSC and UTRAN or GERAN Iu-mode The MSC Server shall know the codec types and codec configurations supported by the RNC. The MSC Server shall select only from these configurations for the RAB assignment. For GERAN Iu-mode the MSC Server receives a list of codec types (for definition see [15]) as well as the supported codec modes (for an adaptive multi-rate codec type) within the RANAP INITIAL UE MESSAGE, indicating the GERAN capabilities, which will be available at the RAB establishment procedure. With this information the MSC Server shall delete those codec types and codec modes (for an adaptive multi-rate codec type) from the Supported Codecs List (BICC) which are not supported by the GERAN, taking into account the GERAN classmark and the MS capabilities. This possibly reduced list shall be used by the MSC Server during the codec negotiation procedure. The value of the maximum number of supported codec modes shall be set to 4 (see [10]). When the MSC node requests a RAB assignment the Subflow Combinations provided shall either all be initialised by the RNC or all rejected with appropriate cause code. ETSI
- 26. 3GPP TS 23.153 version 8.2.0 Release 8 25 ETSI TS 123 153 V8.2.0 (2009-01) The MSC shall always assume "Discontinuous Transmission (DTX)" as mandatory and shall define 'SID' SDUs in addition to the negotiated speech codec modes. This is because for TrFO the RAB requested by one RNC must match that requested by the peer RNC – they are effectively the same RAB. If one MSC requires DTX support then the RAB requested by the far end MSC must also support DTX (even if it is not desired by that MSC). As no Out Of Band negotiation for DTX is supported nor DTX control to the UE, DTX shall be mandatory for TrFO connections. Once an adaptive multi-rate codec with an ACS has been selected as Selected Codec (BICC), the MSCs shall indicate in the RAB Assignment parameters [3] for the Guaranteed Bitrate the lowest speech mode in the ACS (assuming any SID frames are smaller than the SDU for lowest speech mode, otherwise the Guaranteed Bitrate shall be set to the largest SID frame). The Maximum bitrate shall correspond to the highest mode in the ACS. 5.6.7 Signalling between MSC and GERAN AoIP-mode In both mobile originating and mobile terminating calls the MSC Server receives the Supported Codecs List (BSSMAP) – "BSC-SCL" - containing a list of Codec types (for definition see 3GPP TS 48.008 [15]) as well as the codec configurations (for adaptive multi-rate codec types) within the BSSMAP COMPLETE LAYER 3 INFORMATION message, indicating the temporary GERAN capabilities for this call in this cell. The Codec Types within this BSC-SCL can be viewed as divided into three different A-Interface types: 1) Codecs with PCM only on the A-Interface – transcoding always occurs inside the BSS. 2) Codecs with transcoding inside the BSS, but supported with TFO on the A-Interface. 3) Codecs supported with "Full IP" for the A-Interface – no transcoding inside the BSS. These are described in detail in 3GPP TS 48.008 [15], subclause 3.2.2.103. These A-Interface types may then be used by the MSC to create a structured "Supported Codec List", with Direct Codecs and Indirect Codecs, as described in subclause 9.7.2. When creating the Supported Codecs List (BICC or SIP-I), only codecs supported in GERAN with either "Full IP" or TFO shall be included in the "direct" part of the Supported Codecs List (BICC or SIP-I), if also the MS and the MGW support them in this way. Codec types and codec configurations not supported in GERAN (with either Full IP or TFO) or MS, but supported by the MGW with transcoding, may be negotiated as "indirect" codec types. This potentially reduced direct codec list and potentially increased indirect codec list shall be used by the MSC Server during the codec negotiation procedure. During the Assignment procedure, the MSC server shall include in the MSC-Preferred-Codec-List (BSSMAP) all the codecs (and configurations) supported by both the MGW and the MS (see 3GPP TS 48.008 [15]) as allowed by the MSC for this assignment or handover. Editor's note: 3GPP TS 48.008 currently contains two contradictory statements on whether the MSC-PCL shall or may contain all the codecs currently supported by the MS and MSC. GERAN2 requirements need to be clarified. . 5.7 Inband Rate Control Inband rate control shall only allow the RNCs to set the maximum codec mode (maximum bitrate) from the set of codec modes that have been negotiated out of band. This procedure is called Maximum Rate Control. The final maximum mode selected results from a rate control request from one side and the maximum rate supported at the receiving side; the lower rate of these is selected. This is known as Distributed Rate Decision. In TrFO maximum rate control shall be supported through the Iu Framing protocol and through transit networks supporting compressed voice. The maximum rate control procedures are further defined within the Iu Framing protocol [4]. When the MSC requests for a RAB to be assigned, it shall always define 1 speech mode SDU (lowest rate), and DTX SDU as non-rate controllable. Other SDU formats for higher rates shall be defined as rate controllable. The first subflow combination in the IuUP initialisation shall be treated as an initial maximum rate control. Where a node is in TrFO break (e.g. the terminating MGW) this initial maximum rate control received at a given MGW/IuUP termination ETSI
- 27. 3GPP TS 23.153 version 8.2.0 Release 8 26 ETSI TS 123 153 V8.2.0 (2009-01) shall be signalled to the other TrFO link using the IuUP Rate Control PDU unless the IuUP Initialisation frame is to be sent on to the next link as in RFCI Value Correction (see clause 5.4.3). At SRNS relocation the new RNC shall send a rate control frame at Relocation Detect indicating its current maximum rate, it will receive in the acknowledgement the current maximum rate from the far end. This procedure is called Immediate Rate Control. Again the distributed rate decision means both RNCs will operate within a common limit. 5.8 Modification Procedures The OoBTC procedures shall support the following modification mechanisms: i) Modification of Selected Codec. (The codec type of the Selected Codec (BICC) may be switched to another type within the Available Codecs List (BICC), and/or the Active Codec mode Set of the Selected Codec (BICC) may be modified, and/or the Supported Codec mode Set of the Selected Codec (BICC) may be reduced.) ii) Modification of Available Codecs List (The Available Codecs List (BICC) may be reduced by removing codec types and modes) iii) Mid-call Codec Negotiation (The Available Codec List (BICC) is re-negotiated, allowing the addition and removal of codec types and modes compared to the previous Available Codec List (BICC), and a new Selected Codec (BICC) is chosen out of the new Available Codec List (BICC)) The specific call flows when such procedures may be required are detailed in Clause 6. Further information on the Available Codecs List (BICC) and the Selected Codec (BICC) is provided in Section 5.2. Further information on codec types, codec modes, a Supported Codec mode Set and an Active Codec mode Set is provided in TS 26.103 [5]. The basic codec negotiation principles are defined by the BICC Call Control Procedures (see [6]) but the explicit Mc interface procedures are added. ETSI
- 28. 3GPP TS 23.153 version 8.2.0 Release 8 5.8.1 27 ETSI TS 123 153 V8.2.0 (2009-01) Modification of Selected Codec The codec modification procedures shall support the following changes: i) change of the codec type or codec configuration of the current Selected Codec (BICC) to another codec type or codec configuration within the Available Codecs List (BICC); ii) modification of the Available Codecs List (BICC) according to subclause 5.8.2, (i) to (v), in combination with any change of the codec type or codec configuration of the current Selected Codec (BICC) to another codec type or codec configuration within the new Available Codecs List (BICC). The modification of the Available Codecs List (BICC) may include removal of the current Selected Codec (BICC) from the list. The procedures described in Q.1902.4, clauses 10.4.1 to 10.4.3 [6] shall apply. The new codec type and codec configuration may be selected freely from the Available Codecs List (BICC). For an AMR codec or AMR-WB codec, a codec configuration may be selected if it is considered to be included in the Available Codecs List (BICC) according to the criteria specified at the end of subclause 5.6.4. For the coding of the new Selected Codec (BICC), the new Available Codecs List (BICC), and the new Codec (H.248), the same rules apply as specified in subclauses 5.6.4 and 5.6.5. In Figure 5.8.1/1 and 5.8.1/2 the basic codec modification procedure is shown. This Figure is an example; the codec modification procedure may be initiated by any node within the call. Upon Reception of a Modify Codec message (action 5 and 9 in Figure 5.8.1/1), a server node shall check if the Selected Codec is altered according to the criteria above. If the Selected Codec is not altered, the procedures in Section 5.8.2 (Modification of the Available Codec List) apply, otherwise the server node shall send a 'Reserve Characteristics' procedure to the attached MGW for the corresponding termination (action 6 and 10 in Figure 5.8.1/1 To perform a modification of the selected codec at an Iu interface, the MSC server shall send a 'Modify Bearer Characteristics' procedure to the attached MGW (action 1 and 12 in Figure 5.8.1/1). Upon completion of the 'Modify Bearer Characteristics' procedure, the server node shall send a 'RAB Assignment Request' to the radio access network (action 2 and 13 in Figure 5.8.1/1). The MSC server shall then wait to receive a corresponding 'RAB Assignment Response' message from the radio access network (action 3 and 14 in Figures 5.8.1/2 and 5.8.1/3) before continuing the modification procedure. An MSC server shall use the 'Reserve Characteristic' procedure for the termination towards the preceeding node (with respect to the Modify Codec message) to perform the necessary bearer level modification. The MGW shall respond for that termination with the 'Bearer Modified' procedure to indicate that the possible bearer modification to increase bandwidth was successful. The MGW shall not wait until the Iu UP initialisation is complete before replying with the 'Bearer Modified' procedure. Each server shall not send forward the modify request to the succeeding node until the indication from its MGW that any necessary bearer level modification has been completed (BNC_Modified notification). The MSC server shall use the 'Confirm Characteristics' procedure to confirm the modification at that termination. An MSC server shall use the 'Modify Characteristic' procedure for the termination towards the succeeding node (with respect to the Modify Codec message) to confirm the codec modification. The specific handling of the Iu UP initialisation is described in Section 5.8.4. Error Cases are described in Section 5.8.5. ETSI
- 29. 3GPP TS 23.153 version 8.2.0 Release 8 RAB Assignment Request (modified RAB and user plane information) 28 Modify Codec (Selected Codec Y) MSC Server A ETSI TS 123 153 V8.2.0 (2009-01) Modify Codec (Selected Codec Y) Server B 9 5 RAB Assignment Request (modified RAB and user plane information) MSC Server C 13 12 11 10 8 7 6 Modify Bearer Reserve Modify Bearer Reserve Modifi Char Modifi Char Char Char ed ed Terminal/ Radio Access MGW A 13a Modify Bearer (Conditional if bandwidth is increased) MGW B 10a Modify Bearer (Conditional if bandwidth is increased) 4 1 Modify Modify Char Char 2 3 MGW C 6a Modify Bearer (Conditional if bandwidth is increased) RAB Assign Rsp Terminal/ Radio Access 2a Modify Bearer (Conditional if bandwidth is increased) Old Codec Figure 5.8.1/1: Codec Modification Control Procedures RAB Assignment Response Successful Codec Modification MSC Server A Successful Codec Modification MSC Server C 18 Server B 16 15 14 17 Confirm Char Terminal/ Radio Access MGW A 13a Modify Bearer (Conditional if bandwidth is decreased) Confirm Char MGW B 15a Modify Bearer (Conditional if bandwidth is decreased) MGW C Terminal/ Radio Access 17a Modify Bearer (Conditional if bandwidth is decreased) New Codec Figure 5.8.1/2: Codec Modification acknowledgement 5.8.2 Modification of Available Codecs List The modification of the Available Codecs List (BICC) shall support the following changes: i) reduction of the ACS of any Single Codec information element in the Available Codecs List (BICC) for which OM is set to "Optimization of the ACS supported"; ii) reduction of the SCS of any Single Codec information element in the Available Codecs List (BICC) for which OM is set to "Optimization of the ACS supported"; ETSI
- 30. 3GPP TS 23.153 version 8.2.0 Release 8 29 ETSI TS 123 153 V8.2.0 (2009-01) iii) reduction of the MACS of any Single Codec information element in the Available Codecs List (BICC) for which OM is set to "Optimization of the ACS supported"; iv) change of the OM of any Single Codec information element in the Available Codecs List (BICC) from "Optimization of the ACS supported" to "not supported"; and v) deletion of one or more Single Codec information elements from the Available Codecs List (BICC). This shall not include the removal of the Selected Codec (BICC) or of modes from the ACS of the Selected Codec (BICC), as this would require a Modification of Selected Codec as described in 5.8.1. The procedures described in Q.1902.4, clauses 10.4.1 to 10.4.3 [6] shall apply. For the coding of the new Available Codecs List (BICC), the same rules apply as specified in subclause 5.6.4. No modification of the user plane and signalling towards the MGWs and radio access network is required. In Figure 5.8.2/1 the basic 'modification of available codec list' procedure is shown. This Figure is an example; the codec modification procedure may be initiated by any node within the call. Modify Codec (Available Codec List: XYZ, Selected Codex X) Modify Codec (Available Codec List: XYZ, Selected Codex X) 2 MSC Server A 1 Server B MSC Server C 3 4 Successful Codec Modification Terminal/ Radio Access MGW A Successful Codec Modification MGW B MGW C Terminal/ Radio Access Figure 5.8.2/1: Modification of Available Codec List 5.8.3 Mid-call Codec negotiation The Selected Codec (BICC) and the Available Codecs List (BICC) can be (re-) negotiated during the call using the 'Mid Call Codec Negotiation' mechanism. The Mid-Call Codec Negotiation mechanism results in a new Available Codecs List (BICC), where new codec types or modes not within the previous Available Codecs List (BICC) may be included. The codec negotiation procedure is performed as for call set-up. The procedures described in Q.1902.4, clauses 10.4.4 to 10.4.6 [6] shall apply. The sequence is shown in Figure 5.8.3/1. Starting with the Modify to Selected Codec message, the remaining sequence is the same as for the Codec Modification in Section 5.8.1 except that the message name for the modify request is 'Modify To Selected Codec' (instead of 'Modify Codec') in order to allow collisions between the two procedures to be resolved. Everything stated in Section 5.8.1 shall also apply for the Mid-Call Codec Negotiation procedure. The node initiating the 'Mid Call Codec Negotiation' mechanism (MSC Server A in Figure 5.8.3/1) shall select a Preferred Codec and a Supported Codecs List (BICC), which may contain new codecs and also may not contain codecs from the previous Available Codecs List (BICC). If the list no longer contains the previous Selected Codec (BICC), then a new codec shall be selected as Preferred Codec. If the previous Selected Codec (BICC) exists within the Supported Codecs List (BICC), this codec should be selected as the Preferred Codec. If a server node removes the Preferred Codec, from the Supported Codecs List (BICC), the node shall select a new Preferred Codec. ETSI
- 31. 3GPP TS 23.153 version 8.2.0 Release 8 30 Server A ETSI TS 123 153 V8.2.0 (2009-01) Server B MGW-A MGW-B Mid Call Codec Negotiation (New Codec List) Modify Char Modify To Selected Codec (Selected Codec, Available Codec List) Reserve Char Reserv Char Ack Modify Bearer request Modify BearerAck BNC_Modified Optionally sent to modify codec profile and/or allocate additional bandwidth. Successful Codec Modification Confirm Char Modify Bearer request Modify BearerAck Optionally sent to reduce bandwidth when no longer required. Figure 5.8.3/1: Mid Call Codec Negotiation 5.8.4 Detailed Procedures For Iu Framing Protocol & Codec Modification The IuFP must be initialised sequentially from one end to the other in order to store new RFCIs in each node to allow TrFO to resume. The IuFP shall be initialised in the backward direction with respect to the Codec Modification/Modify To Selected Codec message as shown in Figure 5.8.4/1. ETSI
- 32. 3GPP TS 23.153 version 8.2.0 Release 8 31 Server A ETSI TS 123 153 V8.2.0 (2009-01) Server B MGW-A MGW-B Modify Bearer Char Modify Codec (Selected Codec, Available Codec List) Reserve Bearer Char Reserv Char Ack Modify Bearer request Modify BearerAck Optionally sent to allocate additional bandwidth. BNC_Modified Modify Codec IuUP Init [RFCIs] IuUP Init [RFCIs] IuUP Init Ack IuUP Init Ack Successful Codec Mod Confirm_Bearer_Char Modify Bearer request Optionally sent to reduce additional bandwidth. Modify BearerAck BNC_Modified Successful Codec Modification Figure 5.8.4/1: Successful Codec Modification including IuFP A MGW receiving a Modify Bearer Characteristics procedure shall be prepared to receive an incoming modify bearer procedure, this may be to increase the bandwidth prior to IuUP Initialisation or to reduce the bandwidth after the IuUP Intialisation. The new codec indicated in the Modify Bearer Characteristics procedure shall always result in the MGW being prepared to receive an Iu UP initialisation for the new codec, even if the SDU format is unchanged. The MSC shall send the RAB Parameters IE and NAS Synchronisation Indicator IE to the RNC to indicate that the codec has changed and IuUP Initialisation shall be generated.. Each termination receiving a Reserve_Char will initiate bearer level modification to the preceeding node if needed - i.e. if the bandwidth needs to be increased to support the new IuUP. No IuUP initialisation occurs at this point in time. If the Codec Modification Request is terminated by a MGW the IuUP init through the core-network is triggered by the setting of the 3GUP package property 'initialisation direction' to 'OUT' in either the Reserve_Char or the Confirm_Char procedure; the MGW shall then start the IuUP Initialisation out from that Termination. If the node terminating the modification is an RNC then it will generate a new IuUP Initialisation toward its access MGW, each Termination shall have the initialisation direction set to 'IN'. Each MGW shall in turn acknowledge the IuUP Init to the succeeding node (with respect to the modification request) and forward the RFCIs in an IuUP Initialisation to the preceding MGW (as for call set-up). After completing the Iu UP initialisation and receiving the'Confirm Characteristics' procedure, the MGW may decrease the bandwidth of the corresponding bearer performing the 'Modify Bearer' procedure (if needed) - no bearer bandwidth reduction shall be initiated while the UP is still initialised for the old codec. An example call sequence is shown in Figures 5.8.4/2 and 5.8.4/3. ETSI
- 33. 3GPP TS 23.153 version 8.2.0 Release 8 RNC Server A 32 Server B MGW-A Far End Selects Codec ETSI TS 123 153 V8.2.0 (2009-01) MSC C MGW-B Mid Call Codec Negotiation (New Codecs) RNC-C MGW-C Mid Call Codec Negotiation (New Codecs) Modify Bearer Characteristics (3GUP: interface=RAN, Dir=OUT, New Codec) RAB Assign Modify (NSI=Selected Codec) Modify Bearer request possibly sent to allocate additional bandwidth IuFP Init IuFP Init Ack Modify Bearer request possibly sent to free bandwidth RAB Assign Modify Rsp Modify Bearer Characteristics (3GUP: interface=CN, Dir=IN, New Codec ) Modify To Selected Codec ReserveBearer Char (3GUP: interface=CN, Dir=IN, New Codec) (Selected Codec, Codec List) Modify Bearer request possibly sent to allocate additional bandwidth. BNC_Modified Modify Bearer Characteristics 3GUP: interface=CN, Dir=IN, New Codec) Modify To Selected Codec (Selected Codec, Codec List) Reserve Bearer Char 3GUP: interface=CN, Dir=IN, New Codec) possibly sent to allocate additional bandwidth Modify Bearer request BNC_Modified Figure 5.8.4/2: Mid Call Codec Negotiation Call Sequence. Call Flow Part 1 ETSI
- 34. 3GPP TS 23.153 version 8.2.0 Release 8 RNC 33 Server A ETSI TS 123 153 V8.2.0 (2009-01) Server B MSC C MGW-A MGW-B RNC-C MGW-C Modify Bearer Characteristics 3GUP: interface=RAN, Dir=IN, New Codec) RAB Assign Modify (NSI=Selected Codec) Modify Bearer request possibly sent to allocate additional bandwidth IuFP Init IuFP Init IuFP Init IuFP Init Ack IuFP Init Ack IuFP Init Ack Modify Bearer request possibly sent to allocate additional bandwidth IuFP Init (RFCI Value Correction) RAB Assign Modify RSP IuFP Init Ack optional Confirm Bearer Char 3GUP: interface=CN, Dir=IN) Modify Bearer request possibly sent to free bandwidth BNC_Modified Successful Codec Modification Confirm Bearer Char 3GUP: interface=CN, Dir=IN) Modify Bearer request possibly sent to free bandwidth BNC_Modified Successful Codec Modification Figure 5.8.4/3: Mid Call Codec Negotiation Call Sequence. Call Flow Part 2 5.8.5 Unsuccessful Codec Modification If the Codec Modification is unsuccessful at a certain node in the connection (due to the MGW rejecting a request to reserve the resources or a server rejecting the request to modify the codec) the Confirm_Char message shall be sent to a termination that previously performed a successful Reserve_Char Procedure to change the bearer back to its original bandwidth (if needed) and free up any reserved resources. However as the IuUP has not been modified, the Confirm_Char shall not trigger an IuFP re-initialisation. The basic sequence is shown in Figure 5.8.5/1 and a detailed call flow is described in Figure 5.8.5/2. A server that performed a Modify Bearer Characteristics procedure to a termination with the new codec shall perform a subsequent Modify Bearer Characteristics procedure to that termination with the old codec in the failure case. As no IuFP initialisation occurs in the unsuccessful case the IuFP currently intialised will then match the old codec restored by the subsequent Modify Bearer Char; the MGW then knows that it can return to TrFO. The Codec Modification Failure message shall not be returned to a preceding node until notification of the bearer level modification (BNC_Modified). RAB Assigment Modification Failure ETSI
- 35. 3GPP TS 23.153 version 8.2.0 Release 8 34 ETSI TS 123 153 V8.2.0 (2009-01) If the reason for failed codec modification is due to an unsuccessful RAB Modification Request then the MSC shall assume that the old RAB is resumed and thus shall restore the old codec. Server A Server B MGW-A MGW-B Mid Call Codec Negotiation (New Codec List) Modify Bearer Char Modify To Selected Codec (Selected Codec, Available Codec List) Reserve Bearer Char (New Codec) Ack Mod Bearer Optional BNC_Modified Modify To Codec Codec Mod Failure Confirm Char (old Codec) Mod Bearer Optional BNC_Modified Codec Modification Failure Modify Bearer Char (old Codec) Figure 5.8.5/1: Unsuccessful Codec Modification IuUP Initialisation Unsuccessful If the IuUP initialisation fails (this must be due to some protocol error or transmission error because the resources have already been successfully reserved) then the UP protocol is cleared by the peers (see TS 25.415) and therefore the MGW shall notify the Server with a Bearer_Released notification, the call shall be cleared (normal MGW initiated call clearing applies – see TS 23.205 clause 7.4 [8]). ETSI
- 36. 3GPP TS 23.153 version 8.2.0 Release 8 RNC A 35 Server A Server B MGW-A Far End Selects Codec ETSI TS 123 153 V8.2.0 (2009-01) MGW-B Mid Call Codec Negotiation (New Codecs) RNC C MSC C MGW-C Mid Call Codec Negotiation (New Codecs) Modify Bearer Characteristics (3GUP: interface=RAN, Dir=OUT, New Codec) RAB Assign Modify (NSI=Selected Codec) Modify Bearer request IuFP Init possibly sent to allocate additional bandwidth IuFP Init Ack RAB Assign Modify Rsp Modify Bearer Characteristics 3GUP: interface=CN, Dir=IN, New Codec) Modify To Selected Codec Reserve Char (Selected Codec, Modify Bearer request Codec List) sent to possibly allocate additional bandwidth. BNC_Modified Modify Bearer Characteristics 3GUP: interface=CN, Dir=IN, New Codec) Modify To Selected Codec (Selected Codec, Codec List) Reserve Beaerer Char3GUP: Modify Bearer request interface=CN, Dir=IN, New Codec) sent to possibly allocate additional bandwidth BNC_Modified Modify Bearer Characteristics 3GUP: interface=RAN, Dir=IN, New Codec) RAB Assign Modify (NSI=Selected Codec) Figure5.8.5/2: Call Sequence for Unsuccessful Modification. Call Flow Part 1 ETSI
- 37. 3GPP TS 23.153 version 8.2.0 Release 8 RNC A 36 Server A ETSI TS 123 153 V8.2.0 (2009-01) Server B MGW-A RNC C MSC C MGW-B MGW-C RNC unable to perform modification RAB Assign Modify FAIL Modify Bearer Char Old Codec) Confirm Char Old Codec) Modify Bearer Characteristics Codec Modification Failure Modify Char Old Codec) BNC_Modified Confirm Char Old Codec) Modify Bearer Characteristics Codec Modification Failure Modify Char Old Codec) BNC_Modified Modify Bearer Char (Old Codec, Interface = RAN, Dir = OUT) RAB Assign Modify (NSI=Selected Codec) Modify Bearer request IuFP Init IuFP Init Ack RAB Assign Modify Rsp IuFP Init (RFCI Value Correction) IuFP Init Ack Figure5.8.5/2: Call Sequence for Unsuccessful Modification. Call Flow Part 2 ETSI
- 38. 3GPP TS 23.153 version 8.2.0 Release 8 5.9 37 ETSI TS 123 153 V8.2.0 (2009-01) DTMF Handling For TrFO Connections DTMF from the UE is sent via DTAP procedures out-band. For a TrFO call the Originating MSC shall use an out-band DTMF procedure, all CN nodes shall support this procedure in their call control protocol. The out-band DTMF procedure shall also be used when TrFO is not achieved in order that TFO is possible. Insertion of DTMF in the PCM payload can result in the break of the TFO connection. For terminating calls DTMF may need to be received by the core network (for voice-prompted services, voicemail control procedures etc). If the DTMF is received out-band then out-band procedures shall be maintained in core network. If the DTMF is received for a TrFO call from an external network inband, in I.366.2 profile or RTP payload type, then the gateway MGW which interworks between Iu Framing and the external framing protocol shall report the DTMF tones via H.248 procedures to its server. The server shall then use out-band procedures to pass the DTMF through the CN. See Figure 5.9/1. The same shall apply if a DTMF tone is received for a TrFO call from an external network inband in a PCM coded stream. The DTMF tone shall be detected by the MGW and reported via H.248 procedures to its server. In order to prevent duplication of DTMF tones due to subsequent PCM legs in the call, when encoding to compressed codecs the detected tones shall not be allowed to continue in the compressed stream; the DTMF Digits shall be deleted by the MGW before entering the speech encoding stage. The MGW may also optionally pass DTMF inband where such an option exists for the Nb interface, and is supported by the proceeding MGW. Transcoding to default PCM to send DTMF tones shall be avoided for TrFO connections. AMR MSC-A IN/Server-C GMSC-B DTMF 3GPP-CN Terminating DTMF BICC-CS1 Network AMR I.366.2 MGW-A DTMF Network AMR MGW-B Iu Framing MGW-C PCM DTMF Voice Platform DTMF Figure 5.9/1:DTMF received inband from external network 5.10 Framing Protocol for GERAN AoIP mode AoIP user plane does not use IuFP framing protocol or associated 3GUP procedures. Rate control procedures are performed within RTP. ETSI
- 39. 3GPP TS 23.153 version 8.2.0 Release 8 38 ETSI TS 123 153 V8.2.0 (2009-01) 6 Detailed Call Procedures 6.1 Mobile to Mobile TrFO Call Establishment MSC Server - T RANAP MSC Server - O interworking TICC IU MC RNC-T TICC RANAP IU MC MC MGW-T MC MGW-O TrFO break equipment RANAP IU UP term.T interworking Nc T1 (Iu-RAN) interworking RNC-O TrFO break equipment T2 T3 (Iu-CN) IU (Iu-CN) interworking RANAP T4 (Iu-RAN) Nb IU IU UP term.O starts initialisation of UP optionally removed after call setup optionally removed after call setup TrF0 Relation between RNC-O ⇔ RNC-T (after call setup) Figure 6.1/1: Configuration during Call Setup of a Mobile to Mobile Call Following network and protocol entities are involved in the scenario, outlined in Figure 6.1/1: RNC-T, RNC-O: terminating/originating RNCs. MSC Server-T, MSC Server-O: MSC Servers, performing service, i.e. codec negotiation. MGW-T, MGW-O: terminating/originating MGWs with the optional capability to insert/remove so called. TrFO break equipment: (TBEs), i.e. contexts containing an UTRAN- and a CN side IU Framing termination (T1 – T4), inter-working in a distinct manner on control level. [Note: context is meant to be the H.248 specific throughout the document]. It is aimed to design protocols for TrFO in a way, that these pieces of HW can be removed after call setup phase to allow to revert to "simple" AAL2 switching in case of ATM transport. IU FP term.T, IU FP term.O: Terminating- and originating-side TrFO peers (IU Framing terminations in RNC's in Figure 6.1/1). RANAP, TICC:C-plane protocol incarnations, responsible for codec negotiation, controlling the respective interfaces (IU, NC), creating, modifying, removing etc. terminations and contexts. The final configuration is (at least logically) an end to end TrFO relation between RNC-T and RNC-O with the option to remove the TBEs from the user data path, i.e. to revert to pure AAL2 switching in case of ATM Transport. ETSI
- 40. 3GPP TS 23.153 version 8.2.0 Release 8 RNC-T MSC-S-T 39 ETSI TS 123 153 V8.2.0 (2009-01) MGW-T MSC-S-O MGW-O RNC-O 1. Direct Transfer (SETUP (codecs x,y,z)) RANAP RANAP MSC-S has to have static knowledge about codec capabilites of its MGW TICC 2. Initial Address (supp.codecs, fw.establish) TICC 3. Paging, etc. RANAP RANAP RANAP 4. Direct Transfer (CALL CONF RANAP (codecs v,w,x)) H.248 H.248 TICC 5. Add.Req(T$) 5. Add.Reply (T2) H.248 H.248 6. Bearer and Codec Information (codec x & ACS-x, avail.codecs) TICC H.248 H.248 7. Add.Req(T$) 7. Add.Reply(T3) 8. Bearer Establish TrCntrl 8. Bearer Confirm TrCntrl H.248 H.248 RANAP 9. Add.Req(T$) 9. Add.Reply(T4) H.248 H.248 TrCntrl TrCntrl H.248 H.248 10. RAB Assignment Req (SDU format comb. acc. to ACS-x, NASsync=x) TrCntrl TrCntrl 11. Bearer Establish 11. Bearer Confirm Figure 6.1/2: Call Setup. Mobile to Mobile Call. Message Flow part 1 ETSI RANAP TrCntrl TrCntrl
- 41. 3GPP TS 23.153 version 8.2.0 Release 8 RNC-T MSC-S-T 40 ETSI TS 123 153 V8.2.0 (2009-01) MGW-T MSC-S-O MGW-O RNC-O RNC - O is not allowed to puncture out any indicated SDU format combination. IuFP IuFP o-IuFP o-IuFP H.248 H.248 TICC TICC H.248 RANAP TrCntrl TrCntrl IuFP IuFP RANAP RANAP H.248 18. RAB Assignment Req (SDU format comb. acc. to ACS-x, NASsync=x) 14. Notify.Req(T2) 14. Notify.Res(T2) 12b. INIT (o-RFCI maps of x-modes) 12b. INIT ACK H.248 17. Add.Req(T$) 17. Add.Reply(T1) 13. RAB Assignment Res TICC TICC H.248 H.248 RANAP 19. Bearer Establish TrCntrl 19. Bearer Confirm TrCntrl 20. INIT (t-RFCI map of x-modes) IuFP 20. INIT ACK IuFP 21. RAB Assignment Response 22. Direct Transfer (ALERTING) RANAP RANAP H.248 H.248 if RFCIs do not match, IuFP termination in RNC-T may be re-initialised by MGW-T prior to final through connection (RFCI matching(step 27.) 23. Mod Req (T2 ringing) 23. Mod.Reply H.248 H.248 Figure 6.1/3: Call Setup. Mobile to Mobile Call. Message Flow part 2 ETSI IuFP IuFP H.248 16. Adress Complete IuFP IuFP RANAP 15. Continuity 12a. INIT (o-RFCI maps of x-modes) 12a. INIT ACK RANAP
- 42. 3GPP TS 23.153 version 8.2.0 Release 8 RNC-T MSC-S-T MGW-T 26. Direct Transfer (CONNECT) RANAP 27. Mod. Req(T2) MGW-O RNC-O TICC RANAP H.248 ETSI TS 123 153 V8.2.0 (2009-01) MSC-S-O 24. Alerting TICC RANAP 41 25. Direct Transfer (ALERTING) RANAP H.248 disconnect A from ringing tone/ announcement H.248 H.248 Iu FP Iu FP 27. Mod.Reply(T2) H.248 28. Mod. Req(T2) 29. INIT (o-RFCI map of x-modes) H.248 Iu FP 29. INIT ACK Iu FP through connect remove TBE optionally H.248 RANAP 31. Direct Transfer (CONNECT ACK) 30. Mod.Reply(T2) H.248 RANAP TICC 32. Answer TICC H.248 33. Mod. Req(T3) H.248 through connect remove TBE optionally H.248 RANAP RANAP 34. Mod.Reply(T3) H.248 35. Direct Transfer (CONNECT) 35. Direct Transfer (CONNECT ACK) RANAP RANAP TrFO operation RNC-T ⇔ RNC-O Figure 6.1/4: Call Setup. Mobile to Mobile Call. Message Flow part 3 Codec negotiation Steps 1. to 6. give the codec negotiation phase. The mobiles inform the network about their capabilities (1. and 4.). Afterwards the MSC-Server performs codec negotiation according to clause 5.6. Network side bearer establishment MSC-T/MSC-O shall request seizure of network side bearer terminations with IuFP properties (see steps 5. and 7.). Intermediate CN nodes that may perform certain service interactions (e.g. IN nodes) have to seize terminations with IuFP properties as well. RAB Assignment RAN side terminations with IuFP property have to be seized (9. and 17.) before sending RAB Assignment (steps 10. and 18.), that contains RAB parameters according to the selected codec and the negotiated ACS. In addition, the respective NAS synchronisation indicator shall be included. 6.2 SRNS Relocation during TrFO In order to maintain TrFO connection in SRNS Relocation, procedures specified in 3GPP TS 23.205 [8] and 3GPP TS 23.009 [11] for "Intra-MSC SRNS Relocation" or "Inter-MSC SRNS Relocation" shall be followed. Note that the "Intra-MSC SRNS Relocation" procedure can also be used for relocation between RNCs connected to different 3G MSCs (see 3GPP TS 23.009 [11], clause 1, 'Flexible Iu interface for handover/relocation' option and 'Intra domain connection of RAN nodes to multiple CN nodes' option). ETSI
- 43. 3GPP TS 23.153 version 8.2.0 Release 8 42 ETSI TS 123 153 V8.2.0 (2009-01) 6.2.1 Intra-MSC SRNS Relocation MSC – Server - A RANAP (old) IU interworking Nc RANAP (new) MC RNC-A MC TICC partner (MSC-S-B) MC MGW-A TrFO break equipment RANAP T1 T2 (Iu-RAN) IU UP term.A (Iu-CN) Nb IU TrFO vis-a-vis (RNC-B) interworking RNC-A‘ RANAP IU UP term.A‘ TICC T3 (Iu-RAN) IU Figure 6.2/1: Configuration during intra-MSC SRNS Relocation Figure 6.1/1 shows the configuration during intra-MSC SRNS relocation. After setting up the new IU 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 context (TBE) interworking between T1, T2 and T3 is necessary: T3 will receive initialisation from RNC-A'. T2 shall hide initialisation performed on IU,A' from RNC-B. If the option to remove the TBE was applied after call setup, the whole context (TBE) needs to be inserted prior to performing SRNS Relocation. Initialisation data need to be available within MGW-A. After Relocation, the context (TBE) may be removed again, i.e. the MGW-A again acts as a pure AAL2 switch. ETSI
- 44. 3GPP TS 23.153 version 8.2.0 Release 8 RNC-A 43 RNC-A‘ ETSI TS 123 153 V8.2.0 (2009-01) MSC-S-A MGW-A TrFO operation A-B RANAP 1. Relocation Required RANAP 2. Add.Req($) H.248 H.248 insert TBE (if necessary) recall RFCI map add new termination (T3) H.248 RANAP 3. Relocation Request 2. Add.Reply(T3) H.248 RANAP (SDU format comb. acc. to ACS-x, NASsync=x) TrCntrl TrCntrl IuFP IuFP RANAP RANAP 4. Bearer Establish TrCntrl 4. Bearer Confirm TrCntrl 5. INIT (A‘-RFCI map of x-modes) IuFP 5. INIT ACK 6. Relocation Request Ack 7. Relocation Command IuFP if RFCIs do not match, IuFP termination in RNC-A‘ may be perform RFCI Value Correction from this point . (Shown at step10) RANAP RANAP RANAP 8. Relocation Detect RANAP H.248 IuFP IuFP 9. ModifyReq 10. INIT (A-RFCI map of x-modes) 10. INIT ACK H.248 A‘-IuFP A‘-IuFP Figure 6.2/2: Intra-MSC SRNS Relocation and TrFO. Flow chart part 1 ETSI RNC-B
- 45. 3GPP TS 23.153 version 8.2.0 Release 8 RNC-A RNC-A‘ 44 ETSI TS 123 153 V8.2.0 (2009-01) MSC-S-A MGW-A 11. Immediate Rate Control (see chapter 5.7) optional removal of TBE possible 12. ModifyReply H.248 RANAP RANAP 14. Iu Release Command 13. Relocation Complete H.248 RANAP RANAP 15. Bearer Release RANAP 16. Iu Release Complete RANAP H.248 H.248 17. Subtract Req(T1) 17. Subtract Reply(T1) H.248 H.248 TrFO operation A‘-B Figure 6.2/3: Intra-MSC SRNS Relocation and TrFO. Flow chart part 2 ETSI RNC-B
- 46. 3GPP TS 23.153 version 8.2.0 Release 8 RNC-A 45 RNC-A‘ ETSI TS 123 153 V8.2.0 (2009-01) MSC-S-A MGW-A RNC-B TrFO ope ration A-B 1. Enhanced Reloc ation Complete Request RANAP RANAP 2. Add.Req($) H.248 H.248 ins ert TBE (if necessary) recall RFCI map add new termination (T3) 2. Add.Reply(T3) H.248 H.248 3. Enhanced Relocation Complete Respons e RANAP RANAP (SDU format c omb. acc. to ACS-x, NASsync=x) T rCntrl TrCntrl IuFP IuFP 4. Bearer Establish TrCntrl 4. Bearer Confirm T rCntrl 5. INIT (A‘-RFCI map of x-modes) IuFP 5. INIT ACK IuFP 6. Enhanced Relocation Complete Confirm RANAP if RFCIs do not match, IuFP termination in RNC-A‘ may be perform RFCI Value Correction from this point . (Shown at step10) RANAP 7. ModifyReq H.248 IuFP IuFP 8. INIT (A-RFCI map of x-modes) H.248 A‘-IuFP 8. INIT ACK A‘-IuFP 9. Immediate Rate Control (s ee chapter 5.7) optional removal of TBE poss ible 10. ModifyReply H.248 RANAP 11. Iu Releas e Command H.248 RANAP 12. Bearer Release RANAP 13. Iu Releas e Complete RANAP H.248 H.248 14. Subtract Req(T1) 14. Subtract Reply(T1) H.248 H.248 TrFO operation A‘-B Figure 6.2/3: Intra-MSC enhanced SRNS Relocation and TrFO. Flow chart RAB Assignment on the new Iu leg: A RAN side terminations with IuFP property (T3) has to be added to the already seized call context (step 2.) before sending Relocation Request (4.), that contains all the RAB parameters already applied on the Iu leg towards RNC-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. ETSI
- 47. 3GPP TS 23.153 version 8.2.0 Release 8 46 ETSI TS 123 153 V8.2.0 (2009-01) At reception of an INIT frame from the new RNC, the termination at MGW-A shall not perform forwarding of the IuFP initialisation. The MGW shall check whether the received RFCI allocations match the stored RFCI allocation. If it does not match, it may re-initialise the IuFP towards RNC-A' at this point in time. Removal of TrFO Break Equipment (TBE) If the MGW supports the removal of TBEs, it shall insert the TBE before seizing the additional termination. It may again remove the TBE after performing RFCI matching and through-connection of the new termination and the termination to the far end party. 6.2.2 Inter-MSC SRNS Relocation 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]. ETSI
- 48. 3GPP TS 23.153 version 8.2.0 Release 8 47 ETSI TS 123 153 V8.2.0 (2009-01) MSC – Server - A RANAP (old) IU interworking TICC TICC partner (MSC-S-B) Nc TICC (new) MC RNC-A MC MC MGW-A TrFO break equipment RANAP T1 TrFO vis-a-vis (RNC-B) T2 (Iu-RAN) IU UP term.A (Iu-CN) Nb IU interworking Nc T3 (Iu-CN) Nb MSC – Server – A’ RANAP (new) interworking TICC IU MC MC MGW-A’ RNC-A‘ TrFO break equipment RANAP IU UP term.A‘ T4 T5 (Iu-RAN) (Iu-CN) IU Figure 6.2/4: Configuration during inter-MSC SRNS Relocation ETSI
- 49. 3GPP TS 23.153 version 8.2.0 Release 8 48 ETSI TS 123 153 V8.2.0 (2009-01) Figure 6.2/4 shows the configuration during inter-MSC SRNS relocation. After setting up the new IU 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 IU,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. RNC-A MSC-S-A’ RNC-A‘ MGW-A’ MSC-S-A MGW-A TrFO operation A-B RANAP 1. Relocation Required RANAP 2. Prepare HO req (Iu-Supported Codecs, Iu-Currently Used Codec) MAP 3. Add.Req($) H.248 MAP H.248 3. Add.Reply(T4) H.248 H.248 4. Relocation Request RANAP RANAP (SDU format comb. acc. to ACS-x, NASsync=x) TrCntrl TrCntrl IuFP IuFP 5. Bearer Establish TrCntrl 5. Bearer Confirm TrCntrl 6. INIT (A‘-RFCI map of xmodes) 6. INIT ACK IuFP IuFP 7. Relocation Request Ack RANAP RANAP MAP TICC H.248 8. Prepare HO resp (Iu-Selected codec, Iu-Avail. Codecs) 9. Initial Address (supp.codecs, fw.establish) 10. Add.Req($) MAP TICC H.248 10. Add.Reply(T5) H.248 H.248 11. Bearer and Codec Information TICC (codec x & ACS-x, avail.codecs) TICC H.248 12. Add.Req($) H.248 insert TBE (if necessary) recall RFCI map add new termination (T3) H.248 12. Add.Reply(T3) H.248 Figure 6.2/5: Inter-MSC SRNS Relocation and TrFO. Flow chart part 1 ETSI RNC-B
- 50. 3GPP TS 23.153 version 8.2.0 Release 8 RNC-A RNC-A‘ 49 MSC-S-A’ ETSI TS 123 153 V8.2.0 (2009-01) MSC-S-A MGW-A’ MGW-A 13. Bearer Establish TrCntrl TrCntrl 13. Bearer Confirm A-IuFP TrCntrl 14. INIT (A-RFCI map of xmodes) TrCntrl IuFP 14. INIT ACK A-IuFP IuFP through connect if RFCIs do not match, IuFP termination in RNC-A‘ may be perform RFCI Value Correction from this point. (Shown at step 21) 15. Notify.Req(T5) H.248 H.248 15. Notify.Reply(T5) H.248 TICC RANAP H.248 16. Address complete TICC 17. Relocation Command RANAP 18. Relocation Detect RANAP RANAP MAP 19. Process Access Sign. req MAP H.248 20. ModifyReq H.248 21. INIT (A-RFCI map of x-modes) A‘-IuFP IuFP 21. INIT ACK A‘-IuFP IuFP 22. Immediate Rate Control (see chapter 5.7) optional removal of TBE possible 24. Relocation Complete RANAP H.248 23. ModifyReply H.248 RANAP MAP TICC RANAP optional removal of TBE possible 25. Send End Signal req MAP 26. Answer TICC 27. Iu Release Command RANAP 28. Bearer Release RANAP 29. Iu Release Complete RANAP H.248 H.248 30. Subtract Req(T1) 30. Subtract Reply(T1) H.248 H.248 TrFO operation A‘-B 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 ETSI RNC-B
- 51. 3GPP TS 23.153 version 8.2.0 Release 8 50 ETSI TS 123 153 V8.2.0 (2009-01) 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. 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 Selected codec (BICC), previously selected for the leg towards the far end party, as the preferred codec; NOTE: this codec is included to cover the case where the codec negotiation is terminated prior to reaching the target MSC. Then the best codec to be selected is the one also used towards the far end party – in order to avoid the need for a codec modification or additional transcoding in MSC-A If MSC-A knows by means of configuration information that all nodes of the network support TrFO/TFO interworking and TFO, including codec mismatch resolution, this codec may be omitted from the list. b) the Iu-Selected codec (MAP) (negotiated with MSC-A' during the MAP E-interface signalling), if it is not already included according to list item a; c) the default PCM codec; and d) optionally, further codecs from the Iu-Supported Codecs List (MAP) that are applicable to the target radio access. 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], subclause 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 from this list - the multimedia dummy codec, if it is the preferred codec; - the Iu-Selected codec, if it is contained in the list; 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'. 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. ETSI
- 52. 3GPP TS 23.153 version 8.2.0 Release 8 51 ETSI TS 123 153 V8.2.0 (2009-01) 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 throughconnection of the terminations. 6.2.3 Codec Modification/ Mid-Call Codec Negotiation after Inter-MSC Relocation 6.2.3.1 Codec Modification Initiated by the Far End Side Modification of Available Codec List If after inter-MSC SRNS relocation the anchor MSC (MSC-S-A) receives a "Modification of Available Codec List" procedure from the far end side as described in section 5.8.2, i.e. the Available Codecs List (BICC) is reduced, the anchor MSC may terminate the procedure at that point or forward the "Modification of Available Codec List" procedure to the serving MSC (MSC-S-A'). I.e. for a modification of the Available Codec List (BICC) without modification of the Selected codec, no MAP signalling is used. Modification of Selected Codec If after inter-MSC SRNS relocation the anchor MSC (MSC-S-A) receives a "Modification of Selected Codec" procedure from the far end side as described in section 5.8.1, and both the old and the new Selected Codec (BICC) are speech codecs, the anchor MSC may terminate the codec modification procedure, inserting a transcoder if required. Alternatively, the anchor MSC may forward the request to modify the codec to the serving MSC (MSC-S-A'), using the procedure described below. NOTE: The anchor MSC may decide to forward the request to the serving MSC (MSC-S-A'), e.g. when the new Selected Codec (BICC) for the call leg between the anchor MSC and the far end side was included in the Iu-Available Codec List previously received from the serving MSC, and it is possible to (re-)establish TrFO end-to-end from the far end side up to the serving MSC. If the anchor MSC (MSC-S-A) receives a "Modification of Selected Codec" procedure from the far end side as described in section 5.8.1, and either the old or the new Selected Codec (BICC) is the multimedia dummy codec, i.e. the far end side requests a service change between speech and multimedia, and the Available Codecs List (BICC) previously negotiated between the anchor MSC and the serving MSC (MSC-S-A') indicates that the service change is supported end-to-end, the anchor MSC shall forward the request to modify the radio access bearer to the serving MSC (MSC-S-A') and then perform a codec modification procedure for the Nb/Nc interface towards the serving MSC (MSCS-A'). If the service change cannot be performed successfully, the anchor MSC shall reject the request for codec modification towards the far end party. An example call sequence for the modification of the selected speech codec is shown in figures 6.2/7 and 6.2/8. The configuration depicted in figure 6.2/4 applies. ETSI
- 53. 3GPP TS 23.153 version 8.2.0 Release 8 RNC-A' 52 ETSI TS 123 153 V8.2.0 (2009-01) MGW-A’ MSC-S-A’ MGW-A MSC-S-A MSC-S-B TrFO operation A‘-B TICC H.248 H.248 3. Fwd Acc Signalling req (Iu-Selected Codec = y, RAB Assign Modify Req (SDU format comb. acc. to ACS-y, NASsync=y)) MAP 4. Modify Char(T4) H.248 1. Modify codec (y, avail. codecs) 2. Reserve Char(T2) 2. Reserve Char Ack (T2) TICC H.248 H.248 MAP H.248 4. Modify Char Ack H.248 H.248 (T4) RANAP TrCntrl TrCntrl 5. RAB Assign Modify Req (SDU format comb. acc. to RANAP ACS-y, NASsync=y) 6. Modify Bearer Req TrCntrl 6. Modify Bearer Conf TrCntrl IuFP 7. INIT (A‘-RFCI map of y-modes) IuFP 7. INIT ACK RANAP 8. RAB Assign Modify Resp Optionally sent to allocate additional bandwidth IuFP IuFP RANAP MAP 9. Proc Acc Signalling req (Iu-Selected Codec = y, RAB Assign Modify Resp) MAP H.248 H.248 TICC H.248 H.248 11. Modify codec (y, avail. codecs) 10. Modify Char Ack (T3) H.248 H.248 TICC 12. Reserve Char H.248 (T5, 3GUP:Dir=Out) 12. Reserve Char Ack (T5) Optionally sent to allocate additional bandwidth H.248 10. Modify Char(T3) H.248 13. Modify Bearer request TrCntrl 13. Modify Bearer confirm TrCntrl TrCntrl TrCntrl 14. Bearer Modified H.248 (T5) IuFP IuFP H.248 16. Confirm Char (T5) 16. Confirm Char Ack (T5) 15. INIT ACK IuFP IuFP H.248 H.248 15. INIT (A‘-RFCI map of y-modes) H.248 Figure 6.2/7: Codec modification after Inter-MSC SRNS Relocation. Flow Chart Part 1. ETSI
- 54. 3GPP TS 23.153 version 8.2.0 Release 8 R N C -A ' 53 ETSI TS 123 153 V8.2.0 (2009-01) M G W -A ’ M S C -S -A ’ M S C -S -A 17 . M o d ify B ea re r re qu e st T rC ntrl O p tio n a lly se n t to re du c e b a nd w id th M G W -A 1 7 . M o d ify B e a re r co n firm T rC ntrl M S C -S -B T rC ntrl T rC ntrl H .24 8 18 . B ea re r M od ifie d H .24 8 (T 5) T IC C 1 9. S ucc e ss fu l C o de c M o d ification T IC C H .248 H .248 T IC C 2 0 . C on firm C h a r(T 2 ) 2 0 . C o n firm C h a r A ck (T 2 ) H .248 H .248 2 1 . S ucces sfu l C od ec M o difica tion T IC C Note: There can be interim network transit nodes between MSC-A and MSC-A' Figure 6.2/8: Codec modification after Inter-MSC SRNS Relocation. Flow Chart Part 2. If the anchor MSC (MSC-S-A) wants to forward the modification of the codec used towards the UE and the serving MSC (MSC-S-A') from one speech codec to another speech codec within the Iu-Available Codecs List, it shall apply the following procedure: The anchor MSC shall send a MAP Forward Access Signalling request (3) containing the new Iu-Selected Codec and the corresponding RAB Assign Modify Request message to the serving MSC (MSC-S-A'). On reception of the MAP Forward Access Signalling request (3) the serving MSC (MSC-S-A') shall configure the attached MGW-A' for the new codec and trigger the "RAB Assign Modify" procedure (5-8) towards the RNC-A'. When the serving MSC receives the RAB Assign Modify Response message (8), it shall send a MAP Process Access Signalling Request (9) containing the RAB Assign Modify Response and the Iu-Selected codec to the anchor MSC (MSC-S-A). When the anchor MSC (MSC-S-A) receives the MAP Process Access Signalling Request (9), it shall start the codec modification procedure (11-19) for the Nb/Nc interface towards the serving MSC (MSC-S-A'), as described in section 5.8.1. If the anchor MSC needs to change also the Available Codecs List (BICC), it shall additionally initiate a procedure as described in section 5.8.2. When receiving the "Modify Codec" request (11), the serving MSC (MSC-S-A') shall not reconfigure the RAN and shall configure the attached MGW-A' to initate an Nb framing protocol initiation towards MGW-A. If the anchor MSC (MSC-S-A) needs to perform a service change from multimedia to speech, it shall send a MAP Forward Access Signalling request (3) containing the Iu-Supported Codecs List and the corresponding RAB Assign Modify Request message to the serving MSC (MSC-S-A'). After successful modification of the RAB, on reception of the MAP Process Access Signalling Request (9) the anchor MSC (MSC-S-A) shall start the codec modification procedure (11-19) for the Nb/Nc interface towards the serving MSC (MSC-S-A'), as described in section 5.8.1. If the anchor MSC (MSC-S-A) needs to perform a service change from speech to multimedia, it shall send a MAP Forward Access Signalling request (3) containing the corresponding RAB Assign Modify Request message for a data bearer, but no Iu-Selected Codec to the serving MSC (MSC-S-A'). After successful modification of the RAB, on reception of the MAP Process Access Signalling Request (9) the anchor MSC (MSC-S-A) shall start the codec ETSI
- 55. 3GPP TS 23.153 version 8.2.0 Release 8 54 ETSI TS 123 153 V8.2.0 (2009-01) modification procedure (11-19) for the Nb/Nc interface towards the serving MSC (MSC-S-A'), as described in section 5.8.1. Unsuccessful Codec Modification in the Serving MSC After receipt of MAP Forward Access Signalling request (3), if the modification to the new Iu-Selected codec is not possible, e.g. because necessary resources are temporarily unavailable in the serving cell or in MGW-A', or the RAN does not support the "RAB Assign Modify" procedure, the serving MSC (MSC-S-A') shall keep the old codec and the corresponding RAB configuration and shall send a MAP Process Access Signalling request, containing a RAB Assign Modify Response ("failed to modify") message, to the anchor MSC (MSC-S-A). If the anchor MSC detects that the RAB modification failed, it shall abort the codec modification procedure towards the serving MSC and shall complete the codec modification procedure towards the far end side. Unsuccessful BICC Codec Modification between Anchor MSC and Serving MSC After receipt of a MAP Process Access Signalling Request, containing a RAB Assign Modify Response ("success") message, if the subsequent BICC codec modification procedure between anchor MSC and serving MSC fails due to a MGW rejecting a request to reserve the resources or a server rejecting the request to modify the codec, the anchor MSC shall change the codec used at the Iu interface back by sending a MAP Forward Access Signalling request containing the previous Iu-Selected Codec to the serving MSC (MSC-S-A'). After receipt of the confirmation that the previous codec has been restored at the Iu interface, the anchor MSC shall complete the codec modification procedure towards the far end side. 6.2.3.2 Mid-Call Codec Negotiation Initiated by the Far End Side If after inter-MSC SRNS relocation the anchor MSC receives a "Mid-call Codec Negotiation" procedure from the far end side as described in section 5.8.3, and both the old and the new Selected Codec (BICC) are speech codecs, the anchor MSC may terminate the mid-call codec negotiation procedure, inserting a transcoder if required. Alternatively, if the new Selected Codec (BICC) was included in the last Iu-Available Codec List sent by the serving MSC (MSC-S-A') the anchor MSC may forward the request to the serving MSC (MSC-S-A'), using the procedure described below. If the anchor MSC (MSC-S-A) receives a "Mid-call Codec Negotiation" procedure from the far end side as described in section 5.8.3, and either the old or the new Selected Codec (BICC) is the multimedia dummy codec, i.e. the far end side requests a service change between speech and multimedia, and the Available Codecs List (BICC) previously negotiated between the anchor MSC and the serving MSC (MSC-S-A') indicates that the service change is supported end-to-end, the anchor MSC shall forward the request to modify the radio access bearer to the serving MSC (MSC-S-A') and then perform a mid-call codec negotiation procedure for the Nb/Nc interface towards the serving MSC (MSC-S-A'). If the service change between speech and multimedia cannot be performed successfully, the anchor MSC shall reject the request for mid-call codec negotiation towards the far end party. An example call sequence for the mid-call codec negotiation of speech codecs is shown in figures 6.2/9 and 6.2/10. The configuration depicted in figure 6.2/4 applies. ETSI
- 56. 3GPP TS 23.153 version 8.2.0 Release 8 RNC-A' 55 ETSI TS 123 153 V8.2.0 (2009-01) MGW-A’ MSC-S-A’ MGW-A MSC-S-A MSC-S-B TrFO operation A‘-B TICC 2. Fwd Acc Signalling req (Iu-Supp. Codecs, pref. codec = y, Iu-Currently Used Codec, RAB Assign Modify Req (SDU format comb. acc. to ACS-y, NASsync=y)) MAP 3. Modify Char(T4) H.248 1. Mid-call codec negotiation (new codecs) TICC MAP H.248 3. Modify Char Ack H.248 H.248 (T4) RANAP TrCntrl TrCntrl 4. RAB Assign Modify Req (SDU format comb. acc. to RANAP ACS-y, NASsync=y) 5. Modify Bearer Req TrCntrl 5. Modify Bearer Conf Optionally sent to allocate additional bandwidth TrCntrl IuFP 6. INIT (A‘-RFCI map of y-modes) IuFP IuFP 6. INIT ACK IuFP RANAP 7. RAB Assign Modify Resp RANAP MAP TICC H.248 H.248 TICC 8. Proc Acc Signalling req (Iu-Selected Codec = y, Iu-Avail. Codecs RAB Assign Modify Resp) 9. Mid-call codec negotiation (new codecs) 10. Modify Char (T5, 3GUP:Dir=In) 10. Modify Char Ack (T5) MAP TICC H.248 H.248 11. Modify to selected codec (selected codec, codec list) TICC H.248 H.248 Optionally sent to allocate additional bandwidth 12. Reserve Char(T3) H.248 12. Reserve Char Ack H.248 (T3) 13. Modify Bearer request TrCntrl 13. Modify Bearer confirm TrCntrl H.248 H.248 H.248 14. Bearer Modified (T3) 15. Modify Char(T2) 15. Modify Char Ack (T2) TrCntrl TrCntrl H.248 H.248 H.248 Figure 6.2/9: Mid-call codec negotiation after Inter-MSC SRNS Relocation. Flow Chart Part 1. ETSI
- 57. 3GPP TS 23.153 version 8.2.0 Release 8 R N C -A ' 56 ETSI TS 123 153 V8.2.0 (2009-01) M G W -A ’ M S C -S -A ’ M S C -S -A T IC C 1 6 . M o d ify to se lecte d c o de c (se lecte d co de c , co de c list) O p tio n a lly se nt to a llo ca te a d dition a l b an d wid th T rC ntrl T rC ntrl Iu F P IuF P IuFP IuFP IuFP 2 0 . IN IT (R F C I va lu e c o rre ction ) IuFP 2 0. IN IT A CK 1 9. INIT (R F CI m a p o f y-m o de s ) 1 9 . IN IT A C K IuFP M S C -S -B M G W -A T IC C 17 . M o d ify B ea re r re qu e st 17 . M o d ify B ea re r co n firm 1 8 . IN IT (R F C I m a p o f y-m o des ) 1 8. INIT A C K IuF P IuF P T IC C 2 1 . S u cces fu l co d ec m o d ific atio n T IC C IuF P H .24 8 H .24 8 O p tion a lly se n t to re d uc e b a n dw id th 2 2 . C o nfirm C ha r A ck (T3 ) 2 3 . M o dify B e a rer re q u est T rC ntrl 23 . M o d ify B ea re r c on firm T rC ntrl H .24 8 T IC C 22 . C o nfirm C ha r(T 3 ) 2 5 . S ucce ss ful c od e c m o dificatio n 2 4 . B e a re r M o d ifie d (T 3 ) H .24 8 H .24 8 T rC ntrl T rC ntrl H .24 8 T IC C Note: There can be interim network transit nodes between MSC-A and MSC-A' Figure 6.2/10: Mid-call codec negotation after Inter-MSC SRNS Relocation. Flow Chart Part 2. If the anchor MSC (MSC-S-A) wants to forward the (re-)negotiation of the selected codec and the Available Codecs List (BICC) towards the UE and the serving MSC (MSC-S-A'), it shall apply the following procedure: The anchor MSC shall send a MAP Forward Access Signalling request (2) containing the new Iu-Supported Codecs List and the corresponding RAB Assign Modify Request to the current serving MSC (MSC-S-A'). When selecting the order of priority for the codecs within the new Iu-Supported Codecs List, the anchor MSC shall take the new Available Codecs List (BICC) negotiated with the far end party into account. On reception of the MAP Forward Access Signalling request (2) the serving MSC (MSC-S-A') shall select a codec from the Iu-Supported Codecs List, configure the attached MGW-A' for the new codec, and trigger the "RAB Assign Modify" procedure (4-7) towards the RNC-A'. For details concerning the handling of the RAB Assign Modify Request message by MSC-S-A' see 3GPP TS 23.009 [11], subclause 13.4.1. When the serving MSC receives the RAB Assign Modify Response message (7), it shall send a MAP Process Access Signalling Request (10) containing the RAB Assign Modify Response, the Iu-Selected codec, and the Iu-Available Codecs List to the anchor MSC (MSC-S-A). When the anchor MSC (MSC-S-A) receives the MAP Process Access Signalling Request (8), it shall start the mid-call codec negotiation procedure (9-25) for the Nb/Nc interface towards the serving MSC (MSC-S-A'), as described in Section 5.8. When receiving the "Mid-call codec negotiation" procedure (9), the serving MSC (MSC-S-A') shall not reconfigure the RAN and shall configure the attached MGW-A' to wait for an Nb framing protocol initiation from MGW-A. Unsuccessful Codec Modification in the Serving MSC After receipt of MAP Forward Access Signalling request (3), if the modification to the new Iu-Selected codec is not possible, e.g. because necessary resources are temporarily unavailable in the serving cell or in MGW-A', or the RAN does not support the "RAB Assign Modify" procedure, the serving MSC (MSC-S-A') shall keep the old codec and the corresponding RAB configuration and shall send a MAP Process Access Signalling request, containing a RAB Assign Modify Response ("failed to modify") message, to the anchor MSC (MSC-S-A). If the anchor MSC detects that the ETSI
- 58. 3GPP TS 23.153 version 8.2.0 Release 8 57 ETSI TS 123 153 V8.2.0 (2009-01) RAB modification failed, it shall abort the mid-call codec negotiation procedure towards the serving MSC and complete the mid-call codec negotiation procedure towards the far end side. Unsuccessful BICC Mid-call Codec Negotiation between Anchor MSC and Serving MSC If after a successful modification of the Iu-Selected Codec (MAP) the subsequent BICC codec mid-call codec negotiation procedure between anchor MSC and serving MSC fails due to a MGW rejecting a request to reserve the resources or a server rejecting the request to (re-)negotiate the codecs, the anchor MSC shall change the codec used at the Iu interface back by sending a MAP Forward Access Signalling request containing the previous Iu-Selected Codec to the serving MSC (MSC-S-A'). After receipt of the confirmation that the previous codec has been restored at the Iu interface, the anchor MSC shall complete the mid-call codec negotiation procedure towards the far end side. 6.2.3.3 Modification Procedure after Codec Change in the Serving MSC According to 3GPP TS 23.009 [11], subclause 4.4.1, the serving MSC (MSC-S-A') will inform the anchor MSC (MSCS-A) when the Iu-Selected codec was changed during a subsequent intra-MSC handover/relocation by sending a MAP Process Access Signalling request. If the Iu-Available Codecs List was changed during the handover/relocation, the serving MSC shall send a MAP Process Access Signalling request including the new Iu-Available Codecs List. On reception of the MAP Process Access Signalling request the anchor MSC may initiate one of the modification procedures as described in sections 5.8.1, 5.8.2, and 5.8.3 towards the serving MSC and/or towards the far end side. I.e. towards the serving MSC no MAP signalling is used. Besides, towards the serving MSC (MSC-A') the procedures described in sections 5.8.1, 5.8.2, and 5.8.3 are applicable with the modification that the serving MSC shall not modify the radio access bearer. 6.3 IN and Call Forward SS 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. ETSI
- 59. 3GPP TS 23.153 version 8.2.0 Release 8 6.3.1 58 ETSI TS 123 153 V8.2.0 (2009-01) TrFO interworking with SS (VMSC = service interworking node) st 1 TrFO relation (RNC-O ⇔ RNC-T) (or RNC-O ⇔ MGW-T in case MGW-T applies a tone/announcment) 1st codec negot. 2nd codec negot. MSC-O(A) TA RNC-O(A) MSC-T(B) TB TC OoBTC and TrFO capable network CTXAB MGW-O(A) TD CTXCD TD’ MGW-T(B) RNC-T(B) MSC-T’(C) TE TF CTXEF MGW-T’(C) RNC-T’(C) nd 2 (re-negotiated) TrFO relation (RNC-O ⇔ RNC-T’) 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 reinitialisation 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). ETSI
- 60. 3GPP TS 23.153 version 8.2.0 Release 8 RNC-O MSC-S-O 59 MGW-O ETSI TS 123 153 V8.2.0 (2009-01) MSC-S-T MGW-T MSC-S-T‘ MGW-T‘ RNC-T‘ Bearers established, IuUP initiated according to first codec negotiation, (leg to RNC-T released in some SS cases) 1. Initial Address (supp.codec list from MSC-S-O) 2. Add.Req(T$) 3. Bearer Info (selected codec, avail. codecs) 2. Add.Reply(TE) if codec negot. results in a different codec/ACS a modified avail.codec list codec modification shall be applied 4. Bearer Info (modify req, select.codec and/or avail.codecs) if modification of codec type/ ACS accepted 5a. Mod.Req(TA) 5a. Mod.Reply(TA) 5b. Mod.Req(TB) 5b. Mod.Reply(TB) 6.RAB Ass Req (Modify) 7. Bearer Modification (if necessary) 7. Bearer Modify Confirm 8. INIT 8. INIT ACK 9.RAB Ass Res 10. Bearer Info (modification accepted) 11. Mod.Req(TC) 11. Mod.Reply(TC) 12.modification of bearer if necessary 13. Add.Req(T$) 13. Add.Reply(TD‘) 14. Bearer Establish 14. Bearer Confirm 15. INIT 15. INIT ACK 16. INIT 16. INIT ACK 17. Notify.Req 18. Continuity 19. Add.Req(T$) 19. Add.Reply(TF) 20.RAB Ass Req 21. Bearer Establish 21. Bearer Confirm 22. INIT 22. INIT ACK re-init IuUP if necessary 23.RAB Ass Res ringing and call completion phase Figure 6.3.1/2: Codec Modification for SS-interworking & UP re-initialisation ETSI
- 61. 3GPP TS 23.153 version 8.2.0 Release 8 60 ETSI TS 123 153 V8.2.0 (2009-01) IN interworking (VMSC ≠ service interworking node) 6.3.2 st 1 TrFO relation (RNC-O ⇔ MGW-IN) nd 2 TrFO relation (RNC-O ⇔ RNC-T) 1st codec negot. 2nd codec negot. MSC-O(A) MSCIN(B) 3rd codec negot. MSC-T(C) OoBTC and TrFO capable network RNC-O(A) TA TB CTXAB MGW-O(A) T1 T2 TC CTX12 MGWIN(B) TD CTXCD MGW-T(C) RNC-T(C) MSC-T’(D) TE TF CTXEF MGW-T(D) RNC-T(D) rd 3 TrFO relation (RNC-O ⇔ RNC-T’) 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 1st and the 2nd 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 1st negotiation. - For the 3rd negotiation scenario, the leg between MSCIN(B) and MSC-T (C) has to be released and a new leg toward MSC-T'(D) has to be setup. ETSI
- 62. 3GPP TS 23.153 version 8.2.0 Release 8 6.4 61 ETSI TS 123 153 V8.2.0 (2009-01) Information flow for interaction with Multiparty SS Server A Server C Server B MGW B MGW-A MGW C Codec List (v,w,x, y, z) Selected Codec = x, Available List (v, x, z) Selected Codec = x Selected Codec = x Bearer Established New Party Joins Codec List (v, y) Selected Codec = v, Available List (v) Selected Codec = v Selected Codec = v Bearer Established Figure 6.4/1: Multi-party Call The operation of the MGW for conference calls is implementation dependent. The sequence in Figure 6.4/1 shows three connections to the MGW, where two were configured TrFO and have matching codecs but the third connection could not be made with the same codec type. The Iu Framing connections for each multi-party call leg shall be terminated in the MGW where the multi-party call is controlled. The MGW shall control each connection independently during the multi-party call. When the multi-party call is released, if two parties remain in the connection it shall be possible to either revert directly to a TrFO connection if both codecs match or OoBTC procedures could be performed to modify one or both of the codec types to achieve a TrFO connection. However, if the Server does not perform this then the MGW shall continue to resolve the difference in codecs by internal transcoding procedures. Codec modification procedures may be employed (see clause 5.8.1) if a common codec exists, this is shown in Figure 6.4/2, where codec v is common to all parties. ETSI
- 63. 3GPP TS 23.153 version 8.2.0 Release 8 Server A 62 ETSI TS 123 153 V8.2.0 (2009-01) Server B MGW-A Modify Codec (v) Server C MGW B MGW C Reserve Char Codec (v) Modify Char Codec (v) Successful Codec Mod Confirm Char Codec (v) Figure 6.4/2: Multi-party Call, with codec modification 6.5 Information flow for handover from UMTS to GSM after TrFO establishment Inter-system handover procedures are described at call control level in [11] and details for bearer independent architecture is described in [8]. For TrFO connected UMTS call, when a handover occurs to GSM radio access, by definition the A-interface to the BSC shall be default PCM. Prior to receipt of Handover Detect the Anchor MGW has one leg (A-interface) stream mode as default PCM and two terminations with compressed voice codec properties. It is recommended that after the Handover Complete procedure, the network property is maintained as compressed. Thus the Anchor MGW inserts a "TFO Partner" transcoder. Thus no modification to the compressed bearer to 64k PCM is required. TFO procedures may then ensure that speech quality is maintained by avoiding transcoding. In the Intra-MSC case shown in Figure 6.5/1 the MSC controlling the handover has both codec lists for each radio access. The codec negotiation for the UMTS call was performed end to end with UMTS list. If this negotiation resulted in a codec being selected that is also included in the GSM list then at handover the MSC shall indicate this codec as the current speech version to the BSC and TFO can be achieved. If the selected codec is not supported for the GSM radio access but the GSM list contains a codec that is also in the Available Codecs list then the MSC has the option to perform codec modification to ensure TFO can be achieved. The MSC may also perform codec list modification by sending forward the GSM list to update nodes in the network of the change to the Available Codecs List. 3 UMTS RAN handover GSM BSC 1 Codec list: AMR, EFR, PCM MSC TSN Selected Codec: AMR, Available Codecs:EFR,PCM 2 PLMN 1 MGW MGW Codec list: AMR, EFR, PCM MSC Selected Codec: AMR, Available Codecs:EFR,PCM PLMN 2 Figure 6.5/1: UMTS to GSM Inter-System Handover ETSI UMTS RAN MGW
- 64. 3GPP TS 23.153 version 8.2.0 Release 8 63 ETSI TS 123 153 V8.2.0 (2009-01) If the Inter-system handover is an inter-MSC handover then the Anchor MSC sends the current speech version and the supported speech versions in the Prepare Handover Request message to the MSC-B. If the current speech version (codec selected for UMTS call) is not included in the GSM list then the MSC-A shall indicate a preferred codec in the current speech version parameter. The speech version for the GSM access that is finally selected by the MSC-B's BSS, is returned to MSC-A in the Prepare Handover Response message. The MSC-A can then decide if codec modification or codec re-negotiation shall be performed as described for the intra-MSC case. For further details on the inter-MSC signalling see section 6.11. The connections are shown in Figure 6.5/2. 1 Codec list: AMR, EFR, PCM TSN MSC-A Selected Codec: AMR, Available Codecs:EFR,PCM UMTS 2 RAN PLMN 1 MAP MGW MGW handover Procedures 3 Codec list: AMR, EFR, PCM MSC Selected Codec: AMR, Available Codecs:EFR,PCM UMTS RAN PLMN 2 MGW MSC-B MGW GSM BSC Figure 6.5/2: Inter-MSC, UMTS to GSM handover 6.6 Call Hold/Call Wait MSC-S-T RANAP MSC-S-O MSC-S-O‘ BICC RANAP TICC RANAP TICC TICC RANAP MGW-O RNC-T (subscr.B) T1 T4 T2 void T3 T4 MGW-T RNC-O (subscr.A) T5 T5 RNC-O‘ (subscr.C) MGW-O‘ Figure 6.6/1: Configuration during Call Hold/Call Wait scenario This scenario assumes subscriber C (served by RNC-O'') calls subscriber B (served by RNC-T), currently in communication with subscriber A. Subscriber C receives a tone/announcement, applied by terminating side. Then subscriber B puts subscriber A on Hold and A receives an announcement (applied again by terminating side.) MGW-O has to establish an originating side call context (T4, T5), MGW-T the respective terminating one (T3 only, T1 from subscriber will be moved to it during the scenario), the B party context has to be inserted into path again (if TBE was removed). ETSI
- 65. 3GPP TS 23.153 version 8.2.0 Release 8 RNC-T 64 MSC-S-T ETSI TS 123 153 V8.2.0 (2009-01) MGW-T MSC-S-O‘ MGW-O‘ MSC-S-O RNC-O‘ MGW-O RNC-O TrFO operation T-O 1. Direct Transfer (SETUP (codecs x,y‘,z‘)) RANAP TICC 2. Initial Adress (supp..codecs, fw. establish) RANAP TICC 3. Direct Transfer (SETUP, TI = B-C) RANAP RANAP RANAP 4. Direct Transfer (CALL CONF, RANAP TI = B-C, (v,w,x)) H.248 H.248 TICC 5. Add.Req(T$) 5. Add.Reply(T3) H.248 H.248 6. Codec and Bearer Information TICC (codec x & ACS-x) H.248 RANAP 7. Direct Transfer (ALERTING, TI = B-C) RANAP H.248 8. Add.Req($) 8. Add.Reply(T4) 9 Bearer Establish TrCntrl 9 Bearer Confirm TrCntrl H.248 H.248 RANAP H.248 H.248 TrCntrl TrCntrl 12. Add.Req($) 12. Add.Reply(T5) H.248 H.248 13. RAB Assignment Req RANAP (SDU format comb. acc. to ACS-x, NASsync=x) 14. Bearer Establish TrCntrl TrCntrl Figure 6.6/2: Call Hold/Call Wait and TrFO. Message flow part 1 ETSI TrCntrl 14. Bearer Confirm TrCntrl
- 66. 3GPP TS 23.153 version 8.2.0 Release 8 RNC-T 65 MSC-S-T ETSI TS 123 153 V8.2.0 (2009-01) MGW-T MSC-S-O‘ MGW-O‘ MSC-S-O RNC-O‘ MGW-O RNC-O RNC – O‘ is not allowed to puncture out any indicated SDU format combination. IuFP IuFP 15b. INIT (o-RFCI maps of x-modes) o-IuFP 15b. INIT ACK o-IuFP H.248 17. Continuity 18. Mod.Req(T3) 15a. INIT ACK IuFP IuFP IuFP IuFP RANAP TICC 15a. INIT (o-RFCI maps of x-modes) 16. RAB Assignment Res RANAP TICC H.248 connect C with announc./ ringing tone H.248 TICC 19. Mod.Reply(T3) H.248 20. Address Complete (Call Waiting) TICC 21. Direct Transfer (ALERT (CallIsWaiting-Ind)) RANAP TrFO operation MGW-T-RNC-O‘ Figure 6.6/3: Call Hold/Call Wait and TrFO. Message flow part 2 ETSI RANAP
- 67. 3GPP TS 23.153 version 8.2.0 Release 8 RNC-T 66 MSC-S-T MGW-T ETSI TS 123 153 V8.2.0 (2009-01) MSC-S-O‘ MSC-S-O RANAP 22. Direct Transfer (HOLD, TI = B-A) MGW-O‘ MGW-O RNC-O‘ RNC-O RANAP H.248 23. Mod Req (T1,T2) H.248 iinsert TBE for T1 & T2 break connection H.248 H.248 23. Mod.Reply(T1,T2) 24. Mod.Req (T2) H.248 H.248 apply announcement to T2 H.248 RANAP 25. Direct Transfer (HOLD ACK, TI = B-A) 24. Mod.Rep(T2) H.248 RANAP TICC 26. Call Progress(Remote Hold) TICC 27. Direct Transfer (FACILITY(CallOnHold-Ind)) RANAP new TrFO operation announcment⇔subscriber A RANAP 28. Direct Transfer (CONNECT, TI = B-C) RANAP H.248 29. Mod.Req (T3) H.248 disconnect C fromringing tone/ announcement H.248 30. Mod.Reply(T3) H.248 Figure 6.6/4: Call Hold/Call Wait and TrFO. Message flow part 3 ETSI RANAP
- 68. 3GPP TS 23.153 version 8.2.0 Release 8 RNC-T 67 MSC-S-T MGW-T ETSI TS 123 153 V8.2.0 (2009-01) MSC-S-O‘ MGW-O‘ MSC-S-O H.248 31. Move.Req (T1) MGW-O RNC-O‘ RNC-O H.248 move termination T1 to context of subscr.C H.248 H.248 32. Move.Reply(T1) 33. Modify.Req (T1,T3) H.248 H.248 re-initialise terminating Iu leg Iu FP Iu FP 34. INIT (o-RFCI map of modes from C party) Iu FP 35. INIT ACK Iu FP through connect B ⇔C remove TBE (with T1, T3) optionally H.248 RANAP 37. Direct Transfer (CONNECT ACK, TI = B-C) 36. Modify.Reply(T1,T3) H.248 RANAP TICC 38. Answer TICC H.248 39. Mod. Req(T4) H.248 through connect remove TBE optionally H.248 RANAP RANAP 39. Mod.Reply(T4) 41 Direct Transfer (CONNECT ACK) TrFO operation T-O‘ Figure 6.6/5: Call Hold/Call Wait and TrFO. Message flow part 4 ETSI H.248 40. Direct Transfer (CONNECT) RANAP RANAP
- 69. 3GPP TS 23.153 version 8.2.0 Release 8 6.7 68 ETSI TS 123 153 V8.2.0 (2009-01) External Network to Mobile TrFO Call Establishment Gateway MSC Server NNIC party within external network originating the call any CC interworking MSC Server - T TICC TICC interworking RANAP Nc MC IU MC MC Gateway MGW MC MGW-T RNC-T TrFO break equipment T1 NNIT (NNI) any FP interworking T2 T3 (Iu-CN) (Iu-CN) interworking RANAP T4 (Iu-RAN) Nb starts initialisation of UP any CC NNIC NNIT T1-T4 optionally removed after call setup TrF0 Relation between G-MGW ⇔ RNC-T (after call setup) Legend: TICC IU IU UP term.T ... a transport independent call control protocol (as specified for a 3GPP cs CN) ... any external call control protocol ... control plane interface to external network ... transport plane interface to external network ... terminations in an H.248 context Figure 6.7/1. Configuration during Call Setup of a External Network to Mobile Call The description of Figure 6.1/1 (Configuration during Call Setup of a Mobile to Mobile Call) within clause 6.1 applies for the network and protocol entities involved in the External Network to Mobile Call scenario with following modifications: No RNC-O is present – a party served by an external network originates the call instead. The originating CN nodes are Gateway nodes (Gateway MSC Server/Gateway MGW). The Gateway MGW call context is no TrFO break equipment in general, i.e. T1 in general do not support the IuFP framing protocol. Appropriate interworking (in some cases transcoding) has to be performed between T1 and T2. Therefore Figures 6.1/2 to 6.1/4. (the respective message flows for mobile to mobile call setup) apply in principle as well with appropriate modifications outlined below: Codec negotiation Step 1. Until 6., that give the codec negotiation phase in Figure 6.1/2, shall be applied with following modifications: There is no originating UE involved in this negotiation phase If the preceding node of the Gateway MSC-Server doesn't support OoBTC procedures for compressed voice types, the Gateway MSC-Server shall initiate OoBTC procedures in order to enable transcoders placement at the edge gateway node. The edge gateway node shall always send the complete list of the codec types and modes it supports for this type of call setup. UP initialisation The main difference compared to the Mobile to Mobile call setup is, that the CN side termination of the Gateway MGW (T2 in figure 6.7/1) shall start the initialisation of the IuFP according to the result of the codec negotiation. The forward initialisation principle shall be followed in any setup scenario. ETSI
- 70. 3GPP TS 23.153 version 8.2.0 Release 8 6.8 69 ETSI TS 123 153 V8.2.0 (2009-01) Mobile to External Network TrFO Call Establishment MSC Server - O RANAP interworking Gateway MSC Server TICC TICC IU Nc MC RNC-O MC any CC MC MGW - O NNIC party within external network MC Gateway MGW TrFO break equipment RANAP IU UP term.O interworking T1 (Iu-RAN) interworking T2 T3 (Iu-CN) interworking (Iu-CN) IU Nb T4 (NNI) any FP starts initialisation of UP NNIT optionally removed after call setup TrF0 Relation between G-MGW ⇔ RNC-O (after call setup) Legend: TICC ... a transport independent call control protocol (as specified for a 3GPP cs CN) any CC ... any external call control protocol ... control plane interface to external network NNIC ... transport plane interface to external network NNIT T1-T4 ... terminations in an H.248 context Figure 6.8/1. Configuration during Call Setup of a Mobile to External Network Call The description of Figure 6.1/1 (Configuration during Call Setup of a Mobile to Mobile Call) within clause 6.1 applies for the network and protocol entities involved in the External Network to Mobile Call scenario with following modifications: No RNC-T is present – a party served by an external network is the terminating side of the call instead. The terminating side CN nodes are Gateway nodes (Gateway MSC Server/Gateway MGW). The Gateway MGW call context is no TrFO break equipment in general, i.e. T4 in general do not support the IuFP framing protocol. Appropriate interworking (in some cases transcoding) has to be performed between T3 and T4. Therefore Figures 6.1/2 to 6.1/4. (the respective message flows for mobile to mobile call setup) apply in principle as well with appropriate modifications outlined below: Codec negotiation Step 1. Until 6., that give the codec negotiation phase in Figure 6.1/2, shall be applied with following modifications: There is no terminating UE involved in this negotiation phase. If the succeeding node of the Gateway MSC-Server doesn''t support OoBTC procedures for compressed voice types, the Gateway MSC-Server terminates the OoBTC procedures in order to enable transcoder placement at the edge gateway node. The edge gateway node should accept the Codec Type MSC-O prefers and should not puncture out any Codec Mode. If TFO is to be supported then the Gateway MSC-Server shall supply the MGW with the codec list and the selected Codec Type in order that inband TFO negotiation may be performed. For further details see chapter 5.5. ETSI
- 71. 3GPP TS 23.153 version 8.2.0 Release 8 6.9 70 ETSI TS 123 153 V8.2.0 (2009-01) Mobile to Mobile TrFO Call Establishment for GERAN Iumode MSC Server - T RANAP MSC Server - O interworking TICC IU MC BSC-T TICC RANAP IU MC MC MGW-T MC MGW-O TrFO break equipment RANAP IU UP term.T interworking Nc T1 (Iu-RAN) IU interworking BSC-O TrFO break equipment T2 T3 (Iu-CN) (Iu-CN) interworking RANAP T4 (Iu-RAN) Nb IU IU UP term.O starts initialisation of UP optionally removed after call setup optionally removed after call setup TrF0 Relation between BSC-O ⇔ BSC-T (after call setup) Figure 6.9/1: Configuration during Call Setup of a Mobile to Mobile Call for GERAN Iu-mode The description of Figure 6.1/1 (Configuration during Call Setup of a Mobile to Mobile Call) within clause 6.1 applies for the network and protocol entities involved in the Mobile to Mobile Call for GERAN Iu-mode scenario with following modifications: BSC-T acts as a RNC-T. BSC-O acts as a RNC-O. Therefore Figures 6.1/2 to 6.1/4. (the respective message flows for mobile to mobile call setup) apply as well with the appropriate modifications outlined below: Codec negotiation Step 1. until 6., that give the codec negotiation phase in Figure 6.1/2, shall be applied with following modifications: Before step 1 (BSC-O to MSC-S-O) and step 4 (BSC-T to MSC-S-T) the RANAP Initial UE message will be sent indicating the GERAN capabilities, which will be available at the RAB establishment procedure. The IE describing the GERAN capabilities contains a list of codec types as well as the supported codec modes (for an adaptive multi-rate codec type), which will be available at the RAB establishment procedure. With this information the MSC Server shall puncture out (i.e. delete) those codec types and codec modes (for an adaptive multi-rate codec type) from the supported codec list taking into account the GERAN classmark and the MS capabilities which are not supported by the GERAN. This possibly reduced list shall be used by the MSC Server during the negotiation procedure (step 2 and step 6). For definition of list of supported codec types see [15]. The MSC-Server performs codec negotiation according to clause 5.6 with the following modifications: The value of the maximum number of supported codec modes shall be set to "four" (see [10]). RAB Assignment RAB Assignment shall be performed as described in clause 6.1 with following modifications: Additionally, the MSC Server shall include the selected codec type within RAB Assignment. ETSI
- 72. 3GPP TS 23.153 version 8.2.0 Release 8 6.10 71 ETSI TS 123 153 V8.2.0 (2009-01) Relocation during TrFO towards GERAN Iu-mode MSC – Server - A RANAP (old) IU interworking Nc RANAP (new) MC RNC/BSC-A TICC MC MC MGW-A TrFO break equipment RANAP T1 T2 (Iu-RAN) IU UP term.A (Iu-CN) Nb IU TrFO vis-a-vis (RNC-B) interworking BSC-A‘ RANAP IU UP term.A‘ TICC partner (MSC-S-B) T3 (Iu-RAN) IU Figure 6.10/1: Configuration during intra-MSC SRNS Relocation towards GERAN Iu-mode The description of Figure 6.2/1 (Configuration during intra-MSC SRNS Relocation) within clause 6.2 applies for the network and protocol entities involved in the Relocation towards GERAN Iu-mode scenario with following modifications: RAN node A either is a RNC or a BSC. In the latter case BSC-A acts as a RNC-A. BSC-A' acts as a RNC-A'. Therefore Figures 6.2/2 to 6.2/3. (the respective message flows for SRNS Relocation and TrFO) apply as well with the appropriate modifications outlined below: Relocation Initiation If the MSC-Server-A received the GERAN capabilities of the target cell within the RANAP Relocation Required message (for details when the capabilities are included see [16]), MSC-Server-A shall compare these capabilities with the current Selected Codec (BICC) and the Available Codecs List (BICC), taking into account Supported Codec Set and Active Codec Set for adaptive multimode codecs. If the GERAN capabilities in terms of codec types and modes for adaptive multimode codecs do not include all codes types and modes in the Available Codecs List (BICC) and all modes and the type of the Selected Codec (BICC), MSC Server A shall invoke the appropriate of the modification procedures in Section 5.8. Criteria for the selection of the appropriate procedure are given in Section 5.8. Upon completion of this procedure, or if no modification procedure is required, MSC server A shall proceed with the Relocation procedure as described in Figure 6.2/2 to 6.2/3 (Step 2. to 17.). RAB Assignment on the new Iu leg: RAB Assignment on the new Iu leg shall be performed as described in clause 6.2 with following modifications: The Relocation Request (Step 3.) contains possibly new RAB parameters depending on the actions executed as outlined above during the Relocation Initiation phase according to the decision on the selected codec as well as on the selected codec modes (for an adaptive multi-rate codec type). In addition, the MSC-Server-A shall include the selected codec type within Relocation Request message. For definition of list of supported codec type see [15]. ETSI
- 73. 3GPP TS 23.153 version 8.2.0 Release 8 72 6.11 Inter-MSC Handover during TrFO 6.11.1 ETSI TS 123 153 V8.2.0 (2009-01) Inter-MSC Handover In order to enable the use of Tandem free and Transcoder free operation after inter-MSC handover, the procedures specified in 3GPP TS 23.205 [8] and 3GPP TS 23.009 [11] for "Inter-MSC Handover" shall be followed. For the handling of the codec lists and selected codecs the following rules apply: The Prepare Handover request message shall include the Iu-Supported Codecs List (MAP). If the serving radio access is UTRAN or GERAN Iu-mode, the Prepare Handover request message shall contain the IuCurrently Used Codec (MAP). Otherwise, if the serving radio access is A/Gb mode, the currently used codec is indicated by the Speech Version (Chosen) in the BSSMAP Handover Request message included in the Prepare Handover request message. If the target radio access is UTRAN or GERAN Iu-mode, the Prepare Handover response message shall contain the IuSelected Codec (MAP) and the Iu-Available Codecs List (MAP). Otherwise, if the target radio access is A/Gb mode, the selected codec is indicated by the Speech Version (Chosen) in the BSSMAP Handover Request Ack message included in the Prepare Handover response message. If the target radio access is UTRAN or GERAN Iu-mode, then 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 Codecs List (BICC) as specified in subclause 6.2.2. When MSC-A' receives a Supported Codecs List (BICC) with the IAM message, it shall follow the procedures specified in subclause 6.2.2. If the target radio access is GERAN A/Gb mode, then for a speech bearer the anchor MSC shall perform a call set-up with codec negotiation towards the target MSC, using a Supported Codec List (BICC) ordered as: a) optionally, the Selected codec (BICC), previously selected for the leg towards the far end party, as the preferred codec; NOTE: this codec is included to cover the case where the codec negotiation is terminated prior to reaching the target MSC or the case where the GSM codec selected in the target BSS is not suitable on the BICC bearer either because not supported on Nb bearers or TFO is not supported for this codec by the target BSS. Then the best codec to be selected is the one also used towards the far end party – in order to avoid the need for a codec modification or additional transcoding in MSC-A. If MSC-A knows by means of configuration information that all nodes of the network support TrFO/TFO interworking and TFO, including codec mismatch resolution, this codec may be omitted from the list. b) the default PCM codec; c) the GSM codec indicated by the serving MSC during the MAP E-interface signalling as Speech Version (Chosen), if it is not already included according to list item a and if supported on Nb bearer; and d) optionally, further GSM codecs that are supported by its associated MGW. 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], subclause 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 the target radio access is GERAN A/Gb mode and MSC-A' receives a Supported Codec List (BICC) with the IAM message, MSC-A' shall select from this list - the multimedia dummy codec, if it is the preferred codec; - the GSM codec corresponding to the Speech Version (Chosen), if it is contained in the list and if suitable for the target MSC (e.g. codec supported on Nb bearer, TFO supported by the target BSS for this codec); or - optionally, the first codec of the BICC-SCL; or - the default PCM codec. ETSI
- 74. 3GPP TS 23.153 version 8.2.0 Release 8 6.11.2 73 ETSI TS 123 153 V8.2.0 (2009-01) Codec Modification/Mid-Call Codec Negotiation after Inter-MSC Handover 6.11.2.1 Codec Modification/Mid-Call Codec Negotiation Initiated by the Far End Side If the serving radio access after inter-MSC handover is GERAN A/Gb mode, and the anchor MSC (MSC-S-A) receives a "Modification of Selected Codec" procedure or a "Mid-Call Codec Negotiation" procedure from the far end side the MAP signalling between the anchor MSC (MSC-S-A) and the serving MSC (MSC-S-A') shall be performed only, if the old or the new Selected Codec (BICC) is the multimedia dummy codec. If both the old and the new Selected Codec (BICC) are speech codecs, the anchor MSC may terminate the codec modification or mid-call negotiation procedure, inserting a transcoder if required. Alternatively, the anchor MSC may forward the request to the serving MSC (MSC-S-A'), using the procedures as described in section 5.8. NOTE: The anchor MSC may decide to forward the request to the serving MSC (MSC-S-A'), e.g. when it is possible to (re-)establish Tandem free and Transcoder free operation end-to-end from the far end side up to the serving TRAU. If either the old or the new Selected Codec (BICC) is the multimedia dummy codec, i.e. the far end side requests a service change between speech and multimedia, and the Available Codecs List (BICC) previously negotiated between the anchor MSC and the serving MSC (MSC-S-A') indicates that the service change is supported end-to-end, the anchor MSC shall forward the request to modify the radio access bearer to the serving MSC (MSC-S-A') and then perform a codec modification or mid-call negotiation for the Nb/Nc interface towards the serving MSC (MSC-S-A'), using the procedures as described in section 5.8. If the service change between speech and multimedia cannot be performed successfully, the anchor MSC shall reject the request for codec modification or mid-call negotiation towards the far end party. 6.11.2.2 TFO Codec Mismatch Resolution in the Serving MSC If the serving radio access after inter-MSC handover is GERAN A/Gb mode, and TrFO has been established between the anchor MSC and the serving MSC, the serving MSC may detect a TFO codec mismatch between the Selected Codec (BICC) used on the TrFO link and the GSM speech codec chosen by the serving BSC. If the serving MSC supports the codec mismatch resolution procedure (see 3GPP TS 28.062 [10], subclause 6.3) and wants to change the Selected Codec (BICC) due to this procedure, the serving MSC shall initiate a codec modification or mid-call codec negotiation procedure towards the anchor MSC as described in sections 5.8.1, 5.8.2 and 5.8.3. In the event of a collision of codec modification/mid-call codec negotiation procedures initiated by the anchor MSC and the serving MSC, the procedures described in Q.1902.4, subclause 10.4.7.5 [6] shall apply, with the following modification of the first sentence in subclause 10.4.7.5 [6], list item 2: Codec modification/mid-call codec negotiation requests initiated in the direction towards the serving MSC shall take precedence over codec modification/mid-call codec negotiation requests initiated in the direction towards the anchor MSC. 6.11.2.3 Modification Procedure after Codec Change in the Serving MSC The procedures as specified in section 6.2.3.3 apply. 6.12 Incoming data call from PSTN For incoming calls from PSTN, the TMR may not allow to identify the requested service, since the same value may be used to identify both voice and data calls. 6.12.1 Identification of data call at Visited MSC An incoming data call from the PSTN may be identified as data call using signalling interaction with the terminating UE at the Visited MSC. The following procdures are recommended in a network supporting TrFO to allow the Visited MSC to identify the data call using interactions with the terminating UE: ETSI
- 75. 3GPP TS 23.153 version 8.2.0 Release 8 74 ETSI TS 123 153 V8.2.0 (2009-01) The GMSC includes a G.711(and possibly other codecs) in the BICC supported codec list. If the Visited MSC determines that an incoming call is a data call, it shall select G.711 as codec. Note: UE A 64 kbit/s bearer, as required for data calls, will be set up if G.711 is selected. PLMN-BC V_MSC IAM (codec list : codec1, codec 2, G711, TMR= 3,1 KHz ) G_MSC IAM (TMR= 3,1 Khz) PSTN APM (selected codec : G711) MGW Packet backbone MGW TDM Figure 6.12.1/1.Identification of incoming data call at Visited MSC 6.12.2 Handling at transit exchange in inhomogenous networks If a transit exchange connecting a packet backbone and a TDM backbone in an inhomogenous network is not able to determine if an incoming call from the packet backbone side is a data call or a speech call (e.g. TMR=3.1kHz is received), it may select G.711 as codec to enable possible data calls. Note: A 64 kbit/s bearer, as required for data calls, will be set up if G.711 is selected. PLMN IAM (TMR= 3,1 KHz) TDM VMSC TSN IAM (codec list : codec 1, codec 2, G711, TMR= 3,1 KHz) IAM (TMR= 3,1 KHz) GMSC PSTN APM (selected codec : G711) TDM MGW packet backbone MGW TDM Figure 6.12.2/1.Handling of possible data call at transit exchange between TDM and packet backbone 6.12.3 Identification of data call at G-MSC using multi-numbering If the called mobile subscriber is configured with multinumbering service, the GMSC may use the GSM Bearer Capability that may be received from the HLR during the Send Routing Information procedure to identify the requested service and select directly a codec transparent for data call. It may also pass the bearer capability information to subsequent nodes to allow them to select a codec transparent for data call as well (see 3GPP TS 29.007 [19]). This may be particularly usefull in configurations where the terminating MSC does not participate to the codec negotiation procedure, as illustrated in figures 6.12/1 and 6.12/2. ETSI
- 76. 3GPP TS 23.153 version 8.2.0 Release 8 75 ETSI TS 123 153 V8.2.0 (2009-01) PLM N IAM (codec list : G711, TMR= 3,1 KHz, USI ) TDM VMSC IAM (TMR= 3,1 KHz, USI) IAM (TMR= 3,1 KHz,USI) IAM (TMR= 3,1 KHz) TSN TSN TDM GMSC PSTN APM (selected codec : G711) TDM MGW packet backbone MGW TDM Figure 6.12.3/1.Use of the GSM Bearer Capability by TDM GMSC for incoming data call from PSTN PLM N IAM (codec list : G711, TMR= 3,1 KHz, USI ) TDM VMSC IAM (TMR= 3,1 KHz, , USI) IAM (TMR= 3,1 KHz) TSN GMSC PSTN APM (selected codec : G711) TDM MGW packet backbone MGW TDM Figure 6.12.3/2.Use of the GSM Bearer Capability by GMSC for incoming data call from PSTN ETSI
- 77. 3GPP TS 23.153 version 8.2.0 Release 8 6.13 76 ETSI TS 123 153 V8.2.0 (2009-01) Mobile to Mobile TrFO Call Establishment in GERAN AoIP mode MSC Server - T BSSAP MSC Server - O interworking TICC A MC BSC-T TICC interworking BSSAP Nc A MC MC MGW-T MC MGW-O BSC-O BSSAP RTP term. T BSSAP T1 T2 (RTP-RAN) (Nb-CN) AoIP T3 T4 (Nb-CN) (RTP-RAN) Nb AoIP RTP term.O TrF0 Relation between BSC-O ⇔ BSC-T (after call setup) Figure 6.13/1: Configuration during Call Setup of a Mobile to Mobile Call in GERAN AoIP mode Figure 6.13/1 shows the configuration for mobile to mobile call establishment in GERAN AoIP mode. Following network and protocol entities are involved in the scenario, outlined in Figure 6.z/1: BSC-T, BSC-O: terminating/originating BSCs. MSC Server-T, MSC Server-O: MSC Servers, performing service, i.e. codec negotiation. MGW-T, MGW-O: terminating/originating MGWs. BSSAP, TICC:C-plane protocol incarnations, responsible for codec negotiation, controlling the respective interfaces (A, NC), creating, modifying, removing etc. terminations and contexts. NOTE: The following sequences are examples, further detailed call flows are described in TS 23.205 [6]. ETSI
- 78. 3GPP TS 23.153 version 8.2.0 Release 8 BSC-T MSC-S-T 77 ETSI TS 123 153 V8.2.0 (2009-01) MGW-T M SC-S-O M GW-O 1. CL3 (CM Service request (Supported codec list(BSSM AP)) BSSAP BSSAP 2. Direct Transfer (SETUP (codecs x,y,z)) BSC-O BSSAP BSSAP MSC-S has to have static know ledge about codec capabilites of its M GW TICC 3. Initial Address (supp.codecs, fw.establish) TICC 4. Paging, etc. BSSAP BSSAP BSSAP BSSAP 5. CL3 (Paging Resp (Supported BSSAP Codec List(BSSMAP))) 6. Direct Transfer (CALL C ONF BSSAP (codecs v,w,x)) H.248 H.248 TICC 7. Add.Req(T$) 7. Add.Reply (T2) H.248 H.248 8. Bearer and C odec Information (codec x & ACS-x, avail.codecs) TICC H.248 H.248 9. Add.Req(T$) 9. Add.Reply(T4) H.248 H.248 BSSAP 10. Assignment Req (MSC preferred Codec List) BSSAP BSSAP 11. Assignment Complete (BSC selected codec) BSSAP H.248 H.248 TICC 13. Continuity 12. Mod.Req(T4) 12. M od.Res(T4) H.248 H.248 TICC H.248 H.248 14. Add.Req(T$) 14. Add.Reply(T3) H.248 H.248 Figure 6.13/2: Call Setup. Mobile to Mobile Call in GERAN AoIP mode. Message Flow part 1 ETSI
- 79. 3GPP TS 23.153 version 8.2.0 Release 8 RNC-T MSC-S-T 78 MGW-T MSC-S-O 15. Bearer Establish TrCntrl 15. Bearer Confirm TrCntrl H.248 H.248 H.248 H.248 BSSAP 18. Assignment Req (MSC Preferred Codec List) BSSAP 19. Assignment Complete (BSC selected codec) 17. Add.Req(T$) 17. Add.Reply(T1) TrCntrl TrCntrl H.248 H.248 H.248 H.248 BSSAP H.248 21. Direct Transfer (ALERTING) 16. Notify.Res(T2) MGW-O BSSAP H.248 BSSAP 16. Notify.Req(T2) ETSI TS 123 153 V8.2.0 (2009-01) 20. Mod.Req(T1) 20. Mod.Res(T1) H.248 H.248 BSSAP TICC H.248 H.248 22. Adress Complete 23. Mod Req (T2 ringing) 23. Mod.Reply TICC H.248 H.248 Figure 6.13/3: Call Setup. Mobile to Mobile Call in AoIP mode. Message Flow part 2 ETSI BSC-O
- 80. 3GPP TS 23.153 version 8.2.0 Release 8 BSC-T 79 MSC-S-T MGW-T ETSI TS 123 153 V8.2.0 (2009-01) MSC-S-O BSSAP BSSAP 25. Direct Transfer (CONNECT) MGW-O 24. Direct Transfer (ALERTING) BSC-O BSSAP BSSAP H.248 26. Mod. Req(T2) H.248 disconnect A from ringing tone/ announcement H.248 H.248 26. Mod.Reply(T2) H.248 27. Mod. Req(T2) H.248 through connect H.248 BSSAP 28. Direct Transfer (CONNECT ACK) 27. Mod.Reply(T2) H.248 BSSAP TICC 29. Answer TICC H.248 30. Mod. Req(T3) H.248 through connect H.248 BSSAP BSSAP 30. Mod.Reply(T3) H.248 31. Direct Transfer (CONNECT) 32. Direct Transfer (CONNECT ACK) BSSAP BSSAP TrFO operation BSC-T ⇔ BSC-O Figure 6.13/4: Call Setup. Mobile to Mobile Call in AoIP mode. Message Flow part 3 Codec negotiation Steps 1. to 8. give the codec negotiation phase. The BSCs inform the MSC servers their capabilities (1. and 5.). The mobiles inform the network about their capabilities (2. and 6.). The MSC-Server performs codec negotiation according to clause 5.6. Assignment procedure RAN side terminations have to be seized (9. and 17.) before sending Assignment Request message (steps 10. and 18.). Assignment Request message contains the MSC server preferred codec list. BSC retains the decision to choose the final codec for the radio access and informs the MSC server about the codec to be used in the radio access in Assignment Complete message. Step 20 may then be required to modify the selected codec (SDP) if different from the preferred codec included at step 17. NOTE: The BSC should offer codecs that it can support for the call and should therefore under normal circumstances select the MSC preferred codec. ETSI
- 81. 3GPP TS 23.153 version 8.2.0 Release 8 80 ETSI TS 123 153 V8.2.0 (2009-01) 7 Interactions with supplementary services 7.1 Call Deflection service (GSM 23.072) In order to apply the confirmation tone to the originating party, the speech insertion procedure described in clause 6.3 is applied. 7.2 Line identification services (GSM 23.081) 7.2.1 Calling Line Identification Presentation (CLIP) No impact. 7.2.2 Calling Line Identification Restriction (CLIR) No impact. 7.2.3 Connected Line Identification Presentation (COLP) No impact. 7.2.4 Connected Line Identification Restriction (COLR) No impact. 7.3 Call forwarding services (GSM 23.082) 7.3.1 Call Forwarding Unconditional (CFU) In order to apply the confirmation tone to the originating party, the speech insertion procedure described in clause 6.3 is applied. 7.3.2 Call Forwarding on mobile subscriber Busy (CFB) In order to apply the confirmation tone to the originating party, the speech insertion procedure described in clause 6.3 is applied. 7.3.3 Call Forwarding on No Reply (CFNRy) In order to apply the confirmation tone to the originating party, the speech insertion procedure described in clauses 6.3 is applied. 7.3.4 Call Forwarding on mobile subscriber Not Reachable (CFNRc) In order to apply the confirmation tone to the originating party, the speech insertion procedure described in clauses 6.3 is applied. 7.4 Call wait (GSM 23.083) In order to apply the notice tone to the interjected party, the speech insertion procedure described in clause 6.4 is applied. ETSI
- 82. 3GPP TS 23.153 version 8.2.0 Release 8 7.5 81 ETSI TS 123 153 V8.2.0 (2009-01) Call hold (GSM 23.083) In order to apply the notice tone to the held party, the speech insertion procedure described in clause 6.4 is applied. 7.6 Multiparty (GSM 23.084) In order to mix calls, the speech insertion procedure described in clause 6.4 is applied. 7.7 Closed user group (GSM 23.085) No impact. 7.8 Advice of charge (GSM 23.086) No impact. 7.9 Userto-user signalling (GSM 23.087) No impact. 7.10 Call barring (GSM 23.088) 7.10.1 Barring of outgoing calls No impact. 7.10.2 Barring of incoming calls No impact. 7.11 Explicit Call Transfer (GSM 23.091) In case that a call A-B is transferred to C by B (A-C as result), A-B may use codec x, A-C may use codec y, the procedure described in clause 6.3 is applied. 7.12 Completion of Calls to Busy Subscriber (3G TS 23.093) Within CCBS there exists an option for CCBS calls where a bearer can be established before setup in the state "CC-establishment confirmed". If the selected codec after setup is different to the one which was used to establish the bearer, RAB assignment (modify) may be required when RAB parameters are different. 8 Charging The selected codec shall be included in all the call data records of the call legs involved in out-band codec negotiation belonging to a particular subscriber. ETSI
- 83. 3GPP TS 23.153 version 8.2.0 Release 8 82 9 Codec Negotiation For SIP-I on Nc 9.1 ETSI TS 123 153 V8.2.0 (2009-01) General Codec negotiation procedures for SIP-I are described in the following subclauses, where additions or exclusions to the general procedures and principles described in the previous clauses for BICC are required; otherwise it shall be assumed that the others clauses in this specification shall apply to SIP-I on Nc. Normal call handling procedures for SIP-I on Nc are described in 3GPP TS 23.231 [20]. SIP-I codec negotiation procedures defined in the present specification extend the normal Offer/Answer rules defined by IETF RFC 3264 [24]. In order to identify the compliance to these enhancements, the 3GPP OoBTC Indicator is defined, see 3GPP TS 29.231 [21]. NOTE: 9.2 Non-speech RTP payload types may also need to be negotiated within the offer/answer procedures , e.g. the Telephony Event RTP payload type or the ClearMode codec. This is further described in specific clauses in other specifications such as 3GPP TS 23.231 [20] and 3GPP TS 29.007 [19]. Framing Protocol SIP-I user plane does not use IuFP framing protocol or associated 3GUP procedures. Rate control procedures are performed within RTP. 9.3 Basic Procedures 9.3.0 Applicability The procedures in the subsequent subclauses 9.3.1 to 9.3.4 are applicable for speech calls and SCUDIF calls. Procedures for SCUDIF calls are further specified in 3GPP TS 23.172 [17]. Procedures to establish data calls are specified in 3GPP TS 23.231 [20] and 3GPP TS 29.007 [19]. NOTE: For SCUDIF, a Multimedia Dummy Codec is offered together with a speech codec in a single SDP mline. If an offerer is not able to determine if a call is a data call or a speech call, it shall only offer speech codecs including the PCM codec and apply the procedures in subclause 6.12. If codecs other than PCM are also offered, it shall also apply the procedures specified in subclauses 9.3.1 to 9.3.4. 9.3.1 3GPP Node Originating SDP Offer - An MSC-S initiating an offer shall include the OoBTC Indicator in the offer. - If the offering MSC-S receives an answer without the OoBTC Indicator, the codec list shall be interpreted in accordance with the IETF codec rules. If the answer contains multiple codecs, the MSC-S shall initiate a second offer with the selected codec and may include the OoBTC Indicator or leave it out. - If the offering MSC-S receives an answer with the OoBTC Indicator, then the codec list contains the 3GPP Selected Codec and Available Codec List and shall be interpreted to be in accordance with the codec negotiation procedures described in this specification. 9.3.2 3GPP Node Terminating SDP Offer - If the 3GPP MSC-S terminating the codec negotiation receives an offer with the OoBTC Indicator, it shall include the OoBTC Indicator in the Answer. The returned codec list shall be formatted as a 3GPP Selected Codec List and Available Codec List. - If the 3GPP MSC-S terminating the codec negotiation receives an offer without the OoBTC Indicator, the codec list shall be interpreted in accordance with the IETF codec rules and the MSC-S shall initiate an answer with a single codec. It may include the OoBTC Indicator in the Answer or leave it out. ETSI
- 84. 3GPP TS 23.153 version 8.2.0 Release 8 9.3.3 83 ETSI TS 123 153 V8.2.0 (2009-01) 3GPP Intermediate Node Receiving SDP Offer - A 3GPP intermediate node receiving an offer with the OoBTC Indicator shall forward the OoBTC Indicator in the Offer to the succeeding node. - A 3GPP intermediate node receiving an offer without the OoBTC Indicator shall behave according to two options dependent on implementation option: 1. The 3GPP intermediate node may forward the (IETF type) codec list to the succeeding node without the OoBTC Indicator. 2. The 3GPP intermediate node may include the OoBTC indicator in the offer it sends to the succeeding node. NOTE: 9.3.4 - The intermediate node may forward an INVITE for a call that was initiated by the external network (External NW -> intermediate node(s) -> external NW), in which case the offer received from the preceding node may not contain the OoBTC Indicator. 3GPP Intermediate Node Receiving SDP Answer A 3GPP intermediate node receiving an answer with the OoBTC Indicator shall behave according to the presence of the OoBTC Indicator in the initial offer received from the preceding node. 1. If the Initial Offer included the OoBTC Indicator, the 3GPP intermediate node shall forward the Answer with the OoBTC Indicator to the preceding node. The codec list shall be formatted as a 3GPP Selected Codec and Available Codec List. 2. If the Initial Offer did not include the OoBTC Indicator, the 3GPP intermediate node shall forward the Answer without the OoBTC Indicator to the preceding node. The answer shall contain a single codec (mapped from the 3GPP Selected Codec). - A 3GPP intermediate node receiving the answer with multiple codecs and without the OoBTC Indicator shall behave according to the three options below, dependent on implementation option: 1. The 3GPP intermediate node may forward the (IETF type) codec list to the preceding node, regardless of whether the preceding node included the OoBTC Indicator in the offer. The answer shall not contain the OoBTC Indicator. NOTE: This may be permitted when the intermediate node can support multiple speech codecs during a given session; if this is not the case then option 3 shall be performed. 2. If the initial offer received by the intermediate node contained the OoBTC Indicator, the 3GPP intermediate node may map the (IETF type) codec list into a 3GPP Selected Codec and Available Codec List and forward this to the preceding node with the OoBTC Indicator. This exchange concludes the offer/answer from the perspective of the preceding node. If the answer contains multiple codecs, the 3GPP intermediate node shall initiate a second offer toward the succeeding node with a single codec (same as the 3GPP Selected Codec) without the OoBTC Indicator. 3. If the initial offer received by the intermediate node did not contain the OoBTC Indicator the 3GPP intermediate node may signal back to the preceding node a single codec (it shall select the most appropriate codec from the list of received codecs). This exchange concludes the offer/answer from the perspective of the preceding node. The 3GPP intermediate node shall initiate a second offer toward the succeeding node with a single codec (same as the 3GPP Selected Codec) without the OoBTC Indicator. 9.4 Semantics of 3GPP OoBTC Indicator After the 3GPP OoBTC Indicator has been negotiated, i.e. the 3GPP OoBTC indicator has been included in both SDP offer and corresponding SDP answer the following rules apply. for both offerer and answerer: - A change from the Selected Codec to a codec within the Available Codec List (ACL) in the answer, is only permitted using a new SDP offer-answer exchange to re-negotiate the Selected Codec. Inband switching of speech codec types (by sending the new codec with corresponding RTP payload type) is not permitted, and no resources for these codecs need to be reserved e.g. at a MGW. ETSI
- 85. 3GPP TS 23.153 version 8.2.0 Release 8 - 9.5 ETSI TS 123 153 V8.2.0 (2009-01) Codecs in the Available Codec List indicate codecs that are supported. This information may be used by an MSC to decide if a change of the Selected Codec to some other codec using a new SDP offer-answer exchange is attempted. NOTE: - 84 The Available Codec List may be used by a (G)MSC as decision criterion if a codec re-negotiation is attempted. However, this does not preclude that an (G)MSC offers codecs not included in the previous ACL in a codec re-negotiation. A change from the Selected Codec in the answer to an "auxiliary" payload type within the answer, i.e. the RTP Telephony Event (see IETF RFC 4733 [22]) or the comfort noise codec (see IETF RFC3389 [yx]), and vice versa is permitted without new SDP offer-answer exchange by "Inband" switching, i.e. by simply sending the other RTP payload type. Handling of Auxiliary Payload types If auxiliary payload types are negotiated the MSC Server shall configure the MGW to support the multiple payload types for a given termination/stream where applicable (i.e. for speech codec and for RTP Telephony Event and/or comfort noise codec) with the following condition: - 9.6 Resources for a possible comfort noise codec (RFC3389) within the answer codec shall only be reserved in the MGW by the MSC Server if the comfort noise codec (RFC3389) is applicable for the selected codec. For instance, AMR does contain an internal comfort noise mode and is not used in combination with the comfort noise codec (see IETF RFC3389 [23]). Codec Negotiation Example Sequences The following figures show examples of codec negotiation for a selection of common call scenarios to highlight the principles agreed in the preceding clause; the sequences are not exhaustive. Nc Interface IW-MSC/ GMSC MSC Offered list contains supported codecs . OoBTCIndicator shall be included in offer. INVITE[CodecList, OoBTCIndicator] 18x session progress [IETF Codecs] If multiple codecs received in answer and no OoBTCIndicator then Offerer shall send a new offer to reduce to a single speech codec .This O/A exchange may occur using UPDATE of PRACK . NOTE PRACKs NOT SHOWN 1a 18x session progress [Selected Codec, ACL, OoBTCIndicator] UPDATE[SelectedCodec] 1 Intermediate Node may either forward Answer from succeeding node to preceding node as received Alternatively Intermediate Node may select codec and return with OoBTCIndicator to preceding node. It shall then send second offer to succeeding node to reduce to single codec . UPDATE[SelectedCodec] 200 OK (UPDATE) [SelectedCodec] UPDATE[SelectedCodec] 200 OK (UPDATE) [SelectedCodec] 200 OK (UPDATE) [SelectedCodec] Figure 9.6.1: Mobile Originating Codec Negotiation ETSI External Node INVITE[CodecList, OoBTCIndicator] 18x Session progress [IETF Codecs] 2 2a Intermediate Node deletes any codecs that it does not support
- 86. 3GPP TS 23.153 version 8.2.0 Release 8 Nc Interface MSC 85 ETSI TS 123 153 V8.2.0 (2009-01) Intermediate Node deletes any codecs that it does not support IW-MSC/ GMSC INVITE[CodecList, OoBTCIndicator] INVITE[CodecList, OoBTCIndicator] MSC receives multiple codes in offer but includes OoBTCIndicator 18x session progress [Selected . Selects appropriate codec and returns Codec, ACL, OoBTCIndicator] as first in list, including Available codecs and OoBTCIndicator . External Node External Node supports OoBTCIndicator . Offered list conta supported codec 18x session progress [Selected Codec, ACL, OoBTCIndicator ] Figure 9.6.2: Mobile Terminating Codec Negotiation – External Node supports OoBTCIndicator Nc Interface IW-MSC/ GMSC MSC If multiple codecs received the MSC shall select the most appropriate codec. If no OoBTCIndicator received then only this single codec shall be returned in the answer . 1a If OoBTCIndicator received then MSC shall return selected coded , available codecs and OoBTCIndicator . 2a Intermediate Node deletes any codecs that it does not support External Node INVITE[IETF Codecs] INVITE[IETF Codecs] 1 INVITE[CodecList, OoBTCIndicator] 2 18x session progress [Selected Codec] 18x session progress [Selected Codec, ACL, OoBTCIndicator] Intermediate Node may either forward Offer from preceding node to suceeding node as received Offered list contains multiple codecs, no OoBTCIndicator . Alternatively Intermediate Node may include OoBTCIndicator to suceeding node It shall then send . second offer to preceding node to reduce to single codec, after . answer from suceeding node . If intermediate node receives available codecs and OoBTCIndicator in answer but did not receive OoBTCIndicator from preceding node then it removes all other codecs except the selected code to preceding node 18x Session progress [Selected Codec] Figure 9.6.3: Mobile Terminating Codec Negotiation – External Node does not support OoBTCIndicator ETSI
- 87. 3GPP TS 23.153 version 8.2.0 Release 8 External Node External node may return multiple codecs in reply If it . does not support OoBTCIndicator(or does not receive it ) then it returns IETF format codecs 1a, 2a If OoBTCIndicator received and external node supports3G OoBTC then it shall return selected coded , available codecs and OoBTC Indicator . 86 ETSI TS 123 153 V8.2.0 (2009-01) IW-MSC/ GMSC GMSC determines call is to be rerouted outside PLMN(e.g. explicit call forward ) Intermediate Node deletes any codecs that it does not support External Node INVITE[IETF Codecs] INVITE[IETF Codecs] 1 INVITE[CodecList, OoBTCIndicator] Intermediate Node may either forward Offer from preceding node to succeeding node as received Offered list contains multiple codecs, no OoBTCIndicator . 2 Alternatively Intermediate Node may include OoBTCIndicator to succeeding node . 18x session progress [IETF Codecs] If intermediate node receives multiple codecs and no OoBTCIndicator in answer 3a 18x session progress but did not receive OoBTCIndicator from [IETF Codecs] preceding node then may forward answer as received to the preceding node . Alternatively intermediate node selects an appropriate codec from the list received node and initiates a 4 from the succeedingsucceeding node to subsequent offer to indicate the single selected codec and UPDATE[SelectedCodec] signals the single selected coded back to 200 OK (UPDATE) the preceding node . [SelectedCodec] 18x session progress [Selected Codec, ACL, OoBTCIndicator] 2b 18x Session progress [Selected Codec] Figure 9.6.4: Codec Negotiation during call forwarding outside of PLMN – external incoming node does not support 3G OoBTCIndicator ETSI
- 88. 3GPP TS 23.153 version 8.2.0 Release 8 External Node External node does not support OoBTCIndicator but may returns multiple codecs in reply. 87 ETSI TS 123 153 V8.2.0 (2009-01) IW-MSC/ GMSC GMSC determines call is to be rerouted outside PLMN(e.g. explicit call forward ) Intermediate Node deletes any codecs that it does not support External Node INVITE[CodecList, OoBTCIndicator] INVITE[CodecList, OoBTCIndicator] Intermediate Node forwards Offer from preceding node to succeeding node as received 18x session progress [IETF Codecs] Offered list contains multiple codecs, including OoBTCIndicator . 1 If intermediate node receives multiple codecs and no OoBTCIndicator in answer it may return multiple codecs in reply to preceding node if it can support multiple codes 18x session progress [IETF Codecs] 2 UPDATE[SelectedCodec] 200 OK (UPDATE) [SelectedCodec] and either signal the single selected codec back to the preceding node . Or signal the selected codec and available codecs list including the OoBTCIndicator back to the preceding node . Alternatively intermediate node selects an appropriate codec and initiate a subsequent offer to succeeding node to indicate the single selected codec . 2a 2b 18x Session progress [Selected Codec] 18x session progress [Selected Codec, ACL, OoBTCIndicator] Figure 9.6.5: Codec Negotiation during call forwarding outside of PLMN – external node supports 3G extension ETSI
- 89. 3GPP TS 23.153 version 8.2.0 Release 8 88 Nc Interface MSC INVITE[(AMR2, AMRWB, G711), (3GIndc)] IW-MSC/ GMSC Offered list contains supported codecs . 3GIndc extension shall be included in offer. 18x session progress [IETF Codecs(G.711, G.722.2)] If multiple codecs received in answer and no 3GIndc then Offerer shall send a new offer to reduce to a single speech codec.This O/A exchange may occur using UPDATE of PRACK . NOTE PRACKs NOT SHOWN 1a ETSI TS 123 153 V8.2.0 (2009-01) 18x session progress [Selected Codec(AMR2), ACL(AMR2, G711), 3GIndc ] Intermediate Node deletes any codecs that it does not support External Node INVITE[(AMR2, G711), 3GIndc)] 18x Session progress [IETF Codecs (G.711, G.722.2)] 1 2 Intermediate Node may either forward Answer from succeeding node to preceding node as received . Alternatively Intermediate Node may select codec and return with 3GIndc to preceding nodeIt shall . then send second offer to succeeding node to reduce to single codec . 2a UPDATE[SelectedCodec(G.711)] 200 OK (UPDATE) UPDATE[SelectedCodec(G.711) [SelectedCodec(G.711)] ] 200 OK (UPDATE) [SelectedCodec(G.711)] UPDATE[SelectedCodec(G.711)] 200 OK (UPDATE) [SelectedCodec(G.711)] Figure 9.6.6: Mobile Originating Codec Negotiation with specific codec examples ETSI
- 90. 3GPP TS 23.153 version 8.2.0 Release 8 Nc Interface MSC If multiple codecs received the MSC shall select the most appropriate codec. If no 3GIndc received then only this single codec shall be returned in the answer . 2a ETSI TS 123 153 V8.2.0 (2009-01) IW-MSC/ GMSC INVITE[IETF Codecs(G.722.2, G.711)] INVITE[CodecList(AMR2,AM RWB, G.711), 3GIndc)] 18x session progress [Selected Codec(G.711)] 1a If 3GIndc received then MSC shall return selected coded, available codecs and 3G Ind. 89 18x session progress [Selected Codec(AMR2), ACL(AMR2, G.711), 3GIndc] If intermediate node receives selected codec and does not match codecs supported on external network then inserts transcoder . Intermediate Node deletes any codecs that it does not support External Node INVITE[IETF Codecs(G.722.2, G.729, G.711)] 1 2 Intermediate Node may either forward Offer from preceding node to suceeding node as received Offered list contains multiple codecs, no 3GIndc. Alternatively Intermediate Node may include 3GIndc to suceeding node. It shall then send second offer to preceding node to reduce to single codec after answer from ., suceeding node . 18x session progress [Selected Codec(G.711)] 18x session progress [Selected Codec(G.711)] Figure 9.6.7: Mobile Terminating Codec Negotiation with specific codec examples 9.7 Codec Lists Structure 9.7.1 General The following are rules that are applied when populating a Session Description Protocol (SDP) media offer or an SDP media answer for 3GPP SIP-I OoBTC. A SIP-I signalling endpoint shall initiate an SDP Offer/Answer exchange during call establishment and may initiate an SDP Offer/Answer exchange at any time that the bearer configuration changes, e.g., during handover or invocation of a supplementary service such as 3pty. 9.7.2 Rules for Constructing an Offer The Codec List/SDP in the Offer shall contain codecs/payload types defined as follows: - "Direct Codec" payload types that can be used between bearer endpoints without any additional transcoding stage; - "Indirect Codec" payload types that can be used between bearer endpoints with an additional transcoding stage; and - "Auxiliary" payload types unrelated to the primary codec selection process may be included. The Offered Codec List shall contain two sub-lists ordered as: zero or more "Direct Codecs" plus zero or more "Indirect Codecs". A list of zero or more "auxiliary" payload types, e.g., RTP Telephony Events, CN (comfort noise), which are not used in the process of selecting the primary codec, may follow after the direct and indirect codec types. The direct and indirect codec sub-lists shall be ordered in decreasing preference. ETSI
- 91. 3GPP TS 23.153 version 8.2.0 Release 8 90 ETSI TS 123 153 V8.2.0 (2009-01) G.711 shall always be included either as direct or indirect codec. When present, the indirect codec sub-list shall always start with G.711, if G.711 is not a direct codec. However, an entry for G.711 shall appear only once in the offered codec list. The offer may contain a list of several direct and indirect codec types. NOTE: 9.7.3 These rules for constructing an SDP Offer enable TrFO in the network by assuring that the network configures the minimum number of transcoders for each session. These rules are needed to enable TrFO in the network and are consistent with IETF RFC 3264 [24], but are not part of IETF RFC 3264 [24]. Other SIP endpoints may not follow the same conventions for prioritizing codecs. As an exception to the aforementioned rules, the offerer could choose to construct an Offered Codec List in a different order from the one described in the above rules, but this is not recommended as the answerer may select a codec that does not minimize the number of transcoders for the session and does not enable TrFO. Rules for Constructing an Answer The answering signalling endpoint shall, before processing the Offer and before populating the Answer, structure the available codec types on its access into "Direct Codecs," "Indirect Codecs", and "auxiliary" payload types. The answering signalling endpoint shall then take both structured Codec Lists, the one received in the Offer and the one created locally, into account and shall select the "optimal" codec type for the Answer, which shall be the first codec type in the Answer; the Selected Codec. The Answer shall contain at least one direct or indirect codec from among those listed in the Offer. The criteria for selecting the "optimal" codec may depend on operator choices and preferences (local policy), such as Speech Quality, Bit Rate on transport or DSP load (for transcoding) or other. If the Answer to a subsequent Offer comprises all or a subset of the Direct and Indirect codecs in the preceding Answer within the dialog, then the IP address, and port information in the SDP Answer should remain the same. Ideally the Selected "optimal" Codec is a direct codec type on both accesses, which results in no transcoding being necessary. 9.8 Void ETSI
- 92. 3GPP TS 23.153 version 8.2.0 Release 8 91 ETSI TS 123 153 V8.2.0 (2009-01) Annex A (informative): Codec Re-negotiation A node may perform a procedure (e.g. handover) that results in a completely new list from that which was originally negotiated. Assuming that the current Selected Codec is still common (no Selected Codec Modification or renegotiation) then the node shall send a Re-negotiation Request with the new Supported Codec List. The Supported codec list may then be punctured by nodes in the network in the same was as for the basic Codec Negotiation procedure and a new Available Codecs List returned. If a node performs a procedure (e.g. handover) that results in both a completely new list and also the need for a new codec then Codec Re-negotiation may be performed with a request for a new codec selection. The procedure is then the same as for an initial codec negotiation. ETSI
- 93. 3GPP TS 23.153 version 8.2.0 Release 8 92 ETSI TS 123 153 V8.2.0 (2009-01) Annex B (normative): Wideband Speech Service Support Of WB speech service Several compatible Codec Types to enable wideband (WB) speech service are defined in 3G TS 26.103 v.5.0.0. Support of these Codec Typess by a UE is indicated to the MSC by inclusion in the Supported Codecs IE. Note, for GERAN there is also a specific classmark, which includes the radio access" support of WB Codec Typess. Normal TrFO signalling shall apply, where wideband Codec Types may be given preference in the codec list if the wideband service is available to that user. Call Establishment Where end-to-end TrFO cannot be achieved (e.g. the external network does not support OoBTC procedures) a decision whether to accept the WB codec type at the interworking point and transcode to narrowband PCM (G.711) or to remove the wideband codec type from the codec list and only allow narrowband service to continue has to be made. The decision making factors are: i) Is TFO supported? TFO allows the WB service to be negotiated inband and if successful allow end-to-end WB speech. ii) If TFO is supported then a NB speech Codec Type may be selected as the initial codec type. If the TFO inband protocol resolves that end-to-end WB speech is possible then mid-call codec negotiation/modification procedures shall be employed to switch to WB service. Alternatively if AMR-WB is proposed then codec modification will be required if TFO can be successful in NB but cannot be successful in WB. The decision on which Type to select initially should be based on the probability of acceptance of the service. iii) Which WB Codec Modes shall be permitted? AMR-WB has 3 mandatory modes for all RANs (6.60, 8.85, 12.65) and 2 optional modes for UTRAN & GERAN-8PSK_FR (15.85, 23.85). If transcoding from a WB mode to G.711 then only narrowband speech quality will result. Therefore no gain is obtained by allowing the higher modes whereas additional radio access bandwidth is used. iv) Decision rules for codec type selection and AMR-WB codec mode selection are described in TFO specification TS 28.062. v) . vi) Is charging applied to use of higher modes? Note: Transcoding between WB source encoding and default PCM/G.711 provides similar quality (but no better) as would be achieved by NB source encoding. Thus in many cases avoiding modification back to NB codec (when TrFO cannot be achieved) is preferred. On the other hand the WB Codec Types require slightly higher bit rates and thus are slightly less error robust. Handover between WB and NB speech Handover of a successfully established WB speech call to a radio access that cannot guarantee the support of WB speech again requires a decsion whether to transcode or modify. If the call has been established end-to-end in WB TrFO, or end-to-end in WB quality including TFO links, then a modification to NB speech on the TrFO link may be preferrable – to avoid inserting of 2 transcoders (one transcoding between WB speech and NB speech). It depends on the possibility to get WB TFO support on that NB radio access. In general the same decision rules apply as for call establishment described above. Interworking with external networks (PSTN/ISDN) In ITU-T a WB speech codecalgorithm is defined based on the 3GPP AMR-WB codec algorithm: G.722.2. ETSI
- 94. 3GPP TS 23.153 version 8.2.0 Release 8 Note: 93 ETSI TS 123 153 V8.2.0 (2009-01) It is desired that all Codec Types based on that WB algorithm are exactly compatible with the 3GPP AMR-WB Codec Types to enable end-to-end WB speech between fixed and mobile. This means that all configuration parameters must be compatible, for example codec mode change in sending direction (encoder side) should adhere to the 40ms interval required for GERAN radio access. Provided that G.722.2 is directly compatible interworking to external networks should indicate support for this codec type in the Supported Codec List when AMR-WB codec is received from the UE. Receipt of G.722.2 from an external network shall be translated to support of AMR-WB by the PLMN nodes. Multi-party Calls A decision whether to modify any WB legs to NB source encoding may be made based on similar decisions as for the call establishment when TrFO is not successful. Note: The conference bridge is assumed to convert any WB call leg into NB speech. Calls established in WB that result in subsequent parties being joined in conference or calls being established toward a specific conference bridge will under the existing conferencing technology result in NB speech quality. Lawful Interception Lawful Interception of AMR WB speech service shall be in accordance with clause 4.3. ETSI
- 95. 3GPP TS 23.153 version 8.2.0 Release 8 94 ETSI TS 123 153 V8.2.0 (2009-01) Annex C (informative): Status of Technical Specification 23.153 Change history Date TSG # Sep 1999 TSG Doc. CR Rev Subject/Comment First draft prepared by the rapporteur Old New 0.0.0 Oct 1999 2nd draft prepared by the rapporteur (Updated version from Abiko.) 0.0.0 0.1.0 Nov 1999 3rd draft prepared by the rapporteur 0.1.0 0.2.0 Dec 1999 Submitted to CN#06 for information 0.2.0 1.0.0 Feb 2000 4th draft prepared by the rapporteur 1.0.0 1.1.0 Feb 2000 5th draft prepared by the rapporteur (Updated version from Milan.) 1.1.0 1.2.0 Feb 2000 6th draft prepared by the rapporteur (Updated version from Milan.) 1.2.0 1.3.0 Feb 2000 7th draft prepared by the rapporteur (Updated version from Milan.) 1.3.0 1.4.0 Feb 2000 8th draft prepared by the rapporteur (Updated version from Milan.) 1.4.0 1.5.0 Mar 2000 Submitted to TSG CN#07 for approval 1.5.0 2.0.0 Oct 2000 9th draft prepared by the rapporteur (Updated version from Windsor) 2.0.0 2.0.3 Nov 2000 10th draft accepted, input to TrFO workshop #5, Stockholm 2.0.3 2.1.0 Nov 2000 11th draft, workshop #5 interim editors document. 2.1.0 2.1.1 Nov 2000 Final Draft for approval at CN4 WG #5 (Paris) 2.1.1 2.2.0 Nov 2000 Final Clean version for Approval CN TSG (Bangkok) 2.2.0 2.3.0 TS 23.153 Out of Band Transcoder Control - Stage 2 approved as version 4.0.0 2.3.0 4.0.0 Dec 2000 CN#10 NP-000653 Mar 2001 CN#11 NP-010084 001 1 Correct wording of Nb/Iu UP protocol 4.0.0 4.1.0 Mar 2001 CN#11 NP-010084 003 1 Alignment of codec modification procedures with current BICC CS2 4.0.0 procedures 4.1.0 Mar 2001 CN#11 NP-010084 004 1 Alignment of codec modification procedures with current BICC CS2 4.0.0 procedures 4.1.0 Mar 2001 CN#11 NP-010084 005 1 Alignment of codec modification procedures with current BICC CS2 4.0.0 procedures 4.1.0 Mar 2001 CN#11 NP-010084 006 1 Interaction with CCBS 4.0.0 4.1.0 Mar 2001 CN#11 NP-010084 007 2 Clause 5.6, establishment of additional calls 4.0.0 4.1.0 Mar 2001 CN#11 NP-010084 009 1 Editorials and minor corrections 4.0.0 4.1.0 Mar 2001 CN#11 NP-010084 012 2 Change of terminology from "Node X" to "MSC Server X" 4.0.0 4.1.0 Mar 2001 CN#11 NP-010084 014 1 Alignment of codec modification procedures with current BICC CS2 4.0.0 procedures 4.1.0 Mar 2001 CN#11 NP-010084 015 Alignment of SRNS Relocation with 3G TS 23.205 4.0.0 4.1.0 Mar 2001 CN#11 NP-010084 016 Inter-MSC Serving Area SRNS Relocation 4.0.0 4.1.0 Mar 2001 CN#11 NP-010084 017 General Improvements 4.0.0 4.1.0 Mar 2001 CN#11 NP-010084 020 Reference to Q.2630 in certain diagrams should be bearer 4.0.0 4.1.0 1 ETSI
- 96. 3GPP TS 23.153 version 8.2.0 Release 8 95 ETSI TS 123 153 V8.2.0 (2009-01) Change history Date TSG # TSG Doc. CR Rev Subject/Comment independent Old New Mar 2001 CN#11 NP-010084 021 1 Initialisation Issues 4.0.0 4.1.0 Mar 2001 CN#11 NP-010084 022 2 Avoiding double description of Iu framing package procedure 4.0.0 4.1.0 Jun 2001 CN#12 NP-010284 024 1 Role of MSC server in FP UP version negotiation for TrFO 4.1.0 4.2.0 Jun 2001 CN#12 NP-010297 025 Default Codec For UMTS & GSM dual systems 4.1.0 4.2.0 Sep 2001 CN#13 NP-010457 026 Optional FRCI value Correction 4.2.0 4.3.0 Sep 2001 CN#13 NP-010532 027 Default Codec Types For 'UMTS only' and 'UMTS & GSM dual system' UEs 4.2.0 4.3.0 Editorial clean up 4.2.0 4.3.0 1 Sep 2001 CN#13 Dec 2001 CN#14 NP-010620 028 Removal of "No Data" SDUs 4.3.0 4.4.0 Dec 2001 CN#14 NP-010620 029 Clarification for Codec Modification in case of SS/IN interworking 4.3.0 4.4.0 Mar 2002 CN#15 NP-020066 030 2 Codec fallback in TrFO Call Establishment to External Network 4.4.0 5.0.0 Jun 2002 CN#16 NP-020247 033 2 Introduction of AMR-WB 5.0.0 5.1.0 Sep 2002 CN#17 NP-020458 031 4 Introduction of GERAN Iu-mode 5.1.0 5.2.0 Sep 2002 CN#17 NP-020444 041 Initial Bitrate For TrFO 5.1.0 5.2.0 Sep 2002 CN#17 NP-020444 043 1 Handling of UMTS_AMR & UMTS_AMR_2 codecs in OoBTC 5.1.0 5.2.0 Dec 2002 CN#18 NP-020578 039 2 Correction/clarification to Codec Modification Procedures 5.2.0 5.3.0 Dec 2002 CN#18 NP-020578 049 2 Alignment on the optionality on usage of Global Titel Translation in 5.2.0 case of relocation between RNC"s connected to different 3G MSC"s 5.3.0 Mar 2003 CN#19 NP-030097 053 Guaranteed Bitrate & Maximum Bitrate settings for TrFO 5.3.0 5.4.0 Jun 2003 CN#20 NP-030222 051 Inter-MSC SRNS relocation with TrFO 5.4.0 5.5.0 Jun 2003 CN#20 NP-030211 055 Clarification of use of Default PCM codec and handling of the Codec List 5.4.0 5.5.0 Jun 2003 CN#20 NP-030211 057 Clarification of handling of DTMF in TrFO 5.4.0 5.5.0 Jun 2003 CN#20 NP-030211 059 1 Clarification of use of TMR for codec negotiation 5.4.0 5.5.0 Sep 2003 CN#21 NP-030380 063 1 Clarification on codec modification 5.5.0 5.6.0 Sep 2003 CN#21 NP-030380 067 1 Clarification of IuUP Initialisation during codec modification 5.5.0 5.6.0 Sep 2003 CN#23 NP-040053 068 5 Codec Modification/ Mid-Call Codec Negotiation after Inter-MSC Relocation 5.6.0 5.7.0 Sep 2003 CN#23 NP-040053 069 4 Correction of Inter-MSC SRSN Relocation procedure 5.6.0 5.7.0 Jun 2004 CN#24 NP-040214 071 1 Correction of Codec Negotiation and supported codec mode configurations 5.7.0 5.8.0 Jun 3004 CN#24 NP-040219 072 Correction to section 6.5 on information flow after UMTS to GSM handover 5.7.0 5.8.0 Dec 2004 CN#26 NP-040520 076 TFO/TrFO compatibility of UMTS_AMR and UMTS_AMR2 5.8.0 5.9.0 Dec 2004 CN#26 NP-040520 078 1 Detailed description of the handling of codec negotiation parameters 5.8.0 5.9.0 Dec 2004 CN#26 NP-040520 080 3 Addition of missing condition for transcoder free operation in the MGW 5.8.0 5.9.0 2 ETSI
- 97. 3GPP TS 23.153 version 8.2.0 Release 8 96 ETSI TS 123 153 V8.2.0 (2009-01) Change history Date TSG # Dec 2004 CN#26 TSG Doc. CR NP-040528 081 Rev Subject/Comment Correction of the inter-MSC handover during TrFO Old 5.8.0 New 5.9.0 Dec 2004 CN#26 NP-040548 074 1 3GUP properties correction 5.9.0 6.0.0 Mar 2005 CN#27 NP-050053 085 2 New "TFO status" event 6.0.0 6.1.0 Mar 2005 CN#27 NP-050034 089 Correction of the condition for the insertion of a transcoder 6.0.0 6.1.0 Jun 2005 CT#28 CP-050079 092 1 Codec Selection at Terminating Call Control Node for OoBTC 6.1.0 6.2.0 Sep 2005 CT#29 CP-050285 095 2 TrFO/TFO Codec Negotiation 6.2.0 6.3.0 Sep 2005 CT#29 CP-050316 098 2 CS data Mobile Terminating calls from PSTN 6.3.0 7.0.0 Dec 2005 CT#30 CP-050628 0099 2 Handling of CS data calls in inhomogeneous networks 7.0.0 7.1.0 Mar 2007 CT#35 CP-070014 0100 Codec negotiation during Inter-MSC handover 7.1.0 7.2.0 Dec 2007 CT#38 CP-070752 0101 3 Addition of Codec Negotiation for SIP-I 7.2.0 8.0.0 Sep 2008 CT#41 CP-080466 0106 1 AoIP impacts to OoBTC procedures 8.0.0 8.1.0 Sep 2008 CT#41 CP-080464 0107 1 Addition of CS data call related codec considerations 8.0.0 8.1.0 Dec 2008 CT#42 CP-080710 0108 Enhanced SRNS relocation 8.1.0 8.2.0 Dec 2008 CT#42 CP-080710 0110 1 OoBTC BICC Codec List 8.1.0 8.2.0 Dec 2008 CT#42 CP-080686 0111 1 Removal of SDP offer/answer requirements for CSD calls 8.1.0 8.2.0 Dec 2008 CT#42 CP-080697 0112 1 Correction to Codec lists definitions 8.1.0 8.2.0 Dec 2008 CT#42 CP-080697 0114 2 Signalling between MSC and GERAN AoIP-mode 8.1.0 8.2.0 ETSI
- 98. 3GPP TS 23.153 version 8.2.0 Release 8 97 History Document history V8.2.0 January 2009 Publication ETSI ETSI TS 123 153 V8.2.0 (2009-01)