7 TFO Messages

28.0623GPPInband Tandem Free Operation (TFO) of speech codecsService descriptionStage 3TS

The TFO Messages, introduced in clause 6, follow the generic IS_Message principle defined in annex A.

The following definitions are provided for the Sender side:

TFO_REQ (): Identifies the source of the message as a TFO capable device, using a defined Codec_Type.
TFO_REQ contains the following parameters ():

– the System_Identification of the sender;

– the specific Local_Signature of the sender;

– the Local_Used_Codec_Type at sender side;

– possibly additional attributes for the Local_Used_Codec_Type;

– possibly additionally the TFO_Version;

– possibly additionally alternative Codec_Types (short form of Codec_List);

– possibly additionally a future TFO_Extension.

TFO_ACK (): Is the response to a TFO_REQ Message.
TFO_ACK contains the corresponding parameters as TFO_REQ, except for the Local_Signature replaced by the Reflected_Signature, copied from the received TFO_REQ Message.

TFO_REQ_L (): Is sent in case of Codec Mismatch or for sporadic updates of information.
TFO_REQ_L contains the following parameters ():

– the System_Identification of the sender;

– the specific Local_Signature of the sender;

– the Local_Used_Codec_Type at sender side;

– the Local_Codec_List of alternative Codec_Types;

– possibly additional attributes for the used and the alternative Codec_Types

– possibly additionally the TFO_Version

– possibly additionally a future TFO_Extension.

TFO_ACK_L (): Is the response to a TFO_REQ_L Message.
TFO_ACK_L contains the corresponding parameters as TFO_REQ_L, except for the Local_Signature replaced by the Reflected_Signature, copied from the received TFO_REQ_L Message.

TFO_TRANS (): Commands possible IPEs to let the TFO Frames pass transparently within the LSB (8 kbit/s) or the two LSBs (16 kbit/s) or the four LSBs (32kbit/s). TFO_TRANS contains the following parameter ():

– the Local_Channel_Type (8 kbit/s or 16 kbit/s or 32 kbit/s).

TFO_NORMAL: Commands possible IPEs to revert to normal operation.
TFO_NORMAL has no parameters.

TFO_DUP: Informs the distant partner that TFO Frames are received, while still transmitting PCM samples.
TFO_DUP has no parameters.

TFO_SYL: Informs the distant partner (if still possible) that TFO Frames are no longer received.
TFO_SYL has no parameters.

TFO_FILL: Message without specific meaning, used to pre-synchronise IPEs or to bridge over gaps in TFO protocols. TFO_FILL has no parameters.

7.1 Extendibility

A mechanism for future extensions is defined in a way that existing implementations in the field shall be able to ignore future, for them unknown Codec_Types and their potential attributes. The existing implementations shall be able to decode the remainder of the messages (which is known to them) uncompromised. This mechanism allows to extent:

– the number of Local_Used_Codec_Types from 15 (short form) up to 255 (long form) for one System_Identification;

– the Codec_List;

– the Codec_Attributes (if needed).

In case of the TFO_REQ or TFO_ACK messages the attributes of the Local_Used_Codec_Type shall be sent in the codec specific way, without a preceding Codec_Attribute_Head Extension_Block. Existing equipment, that do not know a future Codec_Type and therefore do not know if and how many attribute Extension_Blocks do follow, shall skip these Extension_Blocks, until they find a TFO Message Header again. Similarly, if future Extension_Blocks to a known Codec_Type are detected, existing equipment shall skip these Extension_Blocks, until they find a TFO Message Header again.

In case of the TFO_REQ_L or TFO_ACK_L Messages the simple Codec_List shall be sent immediately after the SIG_LUC and possible Codec_x Extension_Blocks. Then the attributes of all alternative Codec_Types shall follow. Each set of codec attributes shall be preceded by the Codec_Attribute_Head Extension_Block (with Codec_Type Identifier and Length Indicator) followed by the Codec specific attributes.

7.2 Regular and Embedded TFO Messages

A TFO Message is called "regular", if it is sent inserted into the PCM sample stream. A TFO Message is called "embedded", if it is embedded into a TFO Frame. The bit stealing scheme, as defined in Annex A, is identical for regular and embedded TFO Messages. The EMBED bit of the TFO Frames (see clause 5) indicates if the TFO Frame contains an embedded TFO Message. Due to the specific construction of the TFO Messages, they replace some of the synchronisation bits of the TFO Frames. Consequently, the TFO Frame synchronisation pattern will be affected by the presence of an embedded TFO Message, without compromising the synchronisation performances. Data and other control bits of the TFO Frames are not affected by embedded TFO Messages.

7.3 Cyclic Redundancy Check

The Extension_Blocks, defined in the following clauses, shall be protected by three CRC parity bits. These shall be generated as defined in the 3GPP TS 48.060 for the Enhanced Full Rate. For simplicity the present document is reprinted here:

"These parity bits are added to the bits of the subset, according to a degenerate (shortened) cyclic code using the generator polynomial:

g(D) = D3 + D + 1

The encoding of the cyclic code is performed in a systematic form which means that, in GF(2), the polynomial:

d(m)Dn + d(m+1)Dn‑1 + ……+ d(m + n‑3)D3 + p(0)D2 + p(1)D + p(2)

where p(0), p(1), p(2) are the parity bits, when divided by g(D), yields a remainder equal to:

1 + D + D2

For every CRC, the transmission order is p(0) first followed by p(1) and p(2) successively."

In case of Extension_Blocks, p(0)..p(2) are mapped to bits 16..18.

7.4 TFO_REQ Messages

Symbolic Notation:
TFO_REQ (Sys_Id, LSig, Local_Used_Codec_Type[, Used_Codec_Attributes] )
TFO_REQ_L (Sys_Id, LSig, Local_Used_Codec_Type, Codec_List [, Alternative_Codec_Attributes] )

The TFO_REQ Messages conform to the IS_REQ Message format, defined in the Annex A, with IS_System_Identification, followed by the SIG_LUC Extension_Block, optionally the Codec_x Extension_Block, the Codec_List Extension_Block(s) and the Codec_Attribute Extension_Blocks.

The shortest TFO_REQ takes 140 ms for transmission, see Figure 7.4-1.
The shortest TFO_REQ_L takes 180 ms (Figure 7.4-2).

Figure 7.4-1: Construction of the shortest possible TFO_REQ Message

Figure 7.4-2: Construction of the shortest possible TFO_REQ_L Message

Figure 7.4-3: Example of a TFO_REQ Message with a Codec with an index higher than 15 and with three Attribute Extension_Blocks (300 ms length)

Figure 7.4-4: Example of a TFO_REQ_L Message with Codec_List and one alternative Codec with two Attribute Extension_Blocks (300 ms length)

A TFO_REQ (TFO_ACK) may have an additional TFO_Version Extension_Block that contains the TFO_Version.Subversion and a Selector. This Selector may indicate future extensions to TFO_REQ (TFO_ACK), which may require further additional Extension_Blocks following the TFO_Version, see figure 7.4-5.

Figure 7.4-5: Construction of a TFO_REQ Message with Selector, TFO_Version.Subversion
and one additional Extension_Block

7.4.1 Definition of the SIG_LUC Extension_Block

The SIG_LUC Extension_Block consists of 20 bits, as defined in Table 7.4.1-1. It shall always follow immediately after the SYS_ID Extension_Block. It differentiates a TFO_REQ from a TFO_REQ_L message and a TFO_ACK from a TFO_ACK_L message.

The Codec_x Extension_Block shall also be used in TFO_REQ or TFO_REQ_L messages if the Local_Used_Codec_Type has a CoID higher than 14.

Table 7.4.1-1: SIG_LUC Extension_Block

Bit

Description

Comment

Bit 1

"0"

normal IS-Message Sync Bit, constant.

Bit 2

List_Ind

Indicates, whether the Codec_List is included in the TFO Message or not

0: S: TFO_REQ or TFO_ACK: Codec_List is not included (short)

1: L: TFO_REQ_L or TFO_ACK_L: Codec_List is included (long)

Bit 3..10

Sig

An 8-bit random number to facilitate the detection of circuit loop back conditions and to identify the message source

Bit 11

"0"

normal IS-Message Sync Bit, constant

Bit 12.. 15:

Codec_Type
CoID_s

(short form)

Identifies the Local_Used_Codec_Type, which is currently used by the sender

0000…1110: reserved for 15 Codec_Types
1111: Codec_x Extension_Block follows immediately

Bit 16..18:

CRC

3 CRC bits protecting Bits 2 to 10 and 12 to 15

Bit 19..20:

EX

EX == "0.0"

EX == "1.1"

The normal 2 bits for IS_Message Extension.

No other extension block follows

An other extension block follows

7.4.2 Definition of the Codec_x Extension_Block

The Codec_x Extension_Block, if present, always follows the SIG_LUC Extension_Block. It consists of 20 bits, as defined in Table 7.4.2-1. It shall follow always immediately after the SIG_LUC Extension_Block, if the Codec_Type field is set to "1111".

Table 7.4.2-1: Codec_x Extension_Block

Bit

Description

Comment

Bit 1

"0"

normal IS-Message Sync Bit, constant.

Bit 2

Codec_Sel

Differentiates the Codec_x Extension_Block
0: U: Used_Codec_Type is defined in Codec_Type_x field

1: Reserved

Bit 3..10

Codec_Type_x
CoID

(long form)

Identifies the Local_Used_Codec_Type, which is currently used by the sender

0000.0000 … 1111.1111 reserved for 255 Codec_Types
0000.1111 is undefined and shall not be used.

Bit 11

"0"

normal IS-Message Sync Bit, constant

Bit 12.. 15:

"1010"

Reserved for future use, set to "1010" to minimise audible effects

Bit 16..18:

CRC

3 CRC bits protecting Bits 2 to 10 and 12 to 15

Bit 19..20:

EX

The normal 2 bits for IS_Message Extension.

00: No other extension block follows

11: An other extension block follows

7.4.3 Definition of the Codec_List_Extension_Block

The Codec_List Extension_Block is used in a TFO_REQ_L, TFO_ACK_L messages to list the supported Codec_Types. It consists of 20 bits, as defined in Table 7.4.3-1. The Codec_List must at least contain the Local_Used_Codec_Type. If a system supports more than 12 Codec_Types, then other Codec_List Extension_Blocks (Table 7.4.3-2) may follow.

Table 7.4.3-1: Codec_List Extension Block

Bit

Description

Comment

Bit 1

"0"

Normal IS-Message Sync Bit, constant.

Bit 2..10

Codec_List_1

First part of Codec_List. For each Codec_Type one bit is reserved.
If the bit is set to "0" then the specific Codec_Type is not supported;
if the bit is set to "1" then the specific Codec_Type could be used.

Bit 11

"0"

Normal IS-Message Sync Bit, constant

Bit 12.. 14:

Codec_List_2

Second part of the Codec_List; All three bits are reserved for future Codec_Types (up to Codec_Type 12)

Bit 15

Codec_List_x

If set to "1" a further Codec_List Extension_Block follows;
otherwise set to "0"

Bit 16..18:

CRC

3 CRC bits protecting Bits 2 to 10 and 12 to 15

Bit 19..20:

EX

The normal 2 bits for IS_Message Extension:

00: No other extension block follows

11: An other extension block follows

Table 7.4.3-2: Further Codec_List Extension Block(s)

Bit

Description

Comment

Bit 1

"0"

normal IS-Message Sync Bit, constant.

Bit 2..10

Codec_List_1x

First part of Codec_List. For each Codec_Type one bit is reserved.
If the bit is set to "0" then the specific Codec_Type is not supported;
if the bit is set to "1" then the specific Codec_Type could be used.

Bit 2: Codec_Type 13 (+ x*12; x=1..2..3)
Bit 4: Codec_Type 14 (+ x*12; x=1..2..3)
and so on

Bit 11

"0"

normal IS-Message Sync Bit, constant

Bit 12.. 14:

Codec_List_2x

Second part of the Codec_List; All three bits are reserved for future Codec_Types (up to Codec_Type 24 (+x*12; x=1..2..3)

Bit 15

Codec_List_xx

If set to "1" a further Codec_List Extension_Block follows;
otherwise set to "0"

Bit 16..18:

CRC

3 CRC bits protecting Bits 2 to 10 and 12 to 15

Bit 19..20:

EX

The normal 2 bits for IS_Message Extension:

00: No other extension block follows

11: An other extension block follows

7.4.4 Definition of the Codec_Attribute_Head Extension_Block

The Codec_Attribute_Head Extension_Block (Table 7.4.4-1) shall precede the Codec Attribute Extension_Blocks of a Codec_Type, if this Codec_Type needs additional attributes. This Codec_Attribute_Head identifies the Codec_Type and the number of additional Extension_Blocks to follow.

Table 7.4.4-1: Codec_Attribute_Head Extension_Block

Bit

Description

Comment

Bit 1

"0"

normal IS-Message Sync Bit, constant.

Bit 2

PAR_Sel

Differentiates this Extension_Block
0: Parameters included in PAR field: Simple Codec_List_Extension
1: Length Indicator (LI) included: Parameters follow in subsequent Extension_Blocks

Bit 3..10

CoID

This field identifies the Codec_Type for which the subsequent attributes are valid. The same coding as in the Codec_x Extension_Block is used (long form)

Bit 11

"0"

normal IS-Message Sync Bit, constant

Bit 12.. 15:

LI / PAR

If Par_Sel==1: LI: Length Indicator:
0000: reserved;
0001: one other Extension_Block follows, etc.
If Par_Sel==0: PAR: Codec specific definition of these four bits

Bit 16..18:

CRC

3 CRC bits protecting Bits 2 to 10 and 12 to 15

Bit 19..20:

EX

The normal 2 bits for IS_Message Extension:

00: No other extension block follows

11: An other extension block follows

NOTE: This Extension_Block shall be used for the codecs introduced in the future that need attributes. It shall precede the Attribute Extension_Blocks. This allows earlier versions to skip the blocks they do not understand. It shall not be used for the GSM_FR, GSM_HR and GSM_EFR Codec_Types.

7.4.5 Definition of the TFO_Version Extension_Block

The TFO_Version Extension_Block (Table 7.4.5-1) contains the "TFO_Version" (4 bit), the "TFO_Subversion" (4 bit) and a "Selector" (5bit). The TFO_Version Extension Block (and the additional Extension_Blocks indicated by the Selector, if any, see below) shall always be the last of Extension_Blocks of a TFO_REQ or TFO_REQ_L (or TFO_ACK or TFO_ACK_L) message. This is necessary to provide compatibility with older versions, which must be able to skip these Extension_Blocks without being effected negatively.

The TFO_Version and TFO_Subversion are specified in Annex H. A TFO implementation of Release 5 or onwards shall send this TFO_Version. If it is omitted then a TFO_Version lower than 5 shall be assumed by the receiving side.

The Selector is used to indicate the type of extension and the number of additional extension blocks (if any). The Selector code "00000" indicates that no further extension is followig.

The Selector code "10101" is not allowed to provide improved distinction against the TFO_Header.

7.4.5.1 Selector for Alternative Codecs

If the Selector is set to "00001" then this indicates that alternative codec types are supported, which are specified in additional Extension_Blocks following the TFO_Version Extension_Block. This Selector shall not be used in TFO_REQ_L or TFO_ACK_L messages, since equivalent information would then already be provided in the Codec_List Extension_Block. It shall only be used in TFO_REQ or TFO_ACK messages to provide information on alternative codec types in an early stage of the TFO protocol, i.e., before TFO is established. For each alternative Codec_Type that is offered during TFO negotiation, one Codec_Attribute_Head Extension_Block shall be included. If the specified Codec_Type requires additional attributes then the required number of Codec_Attribute Extension_Blocks follow after the Codec_Attribute_Head Extension_Block. The list of alternative Codec_Types is terminated when the EX bits indicate no further Extension_Blocks (00) and the next TFO Message Header is following.

Table 7.4.5-1: TFO_Version Extension_Block

Bit

Description

Comment

Bit 1

"0"

normal IS-Message Sync Bit, constant.

Bit 2..6

Selector

Indicates if and which further extension_blocks are following.
Coding for bits 2.3.4.5.6:

00000: nothing is following after this TFO_Version
00001: One (or more) alternative Codec Type(s) is (are) following, 10101: reserved (used by the IS_Header)
all other codes: reserved for future use.

Bit 7..10

Ver

This field contains the TFO_Version number as specified in Annex H

Bit 11

"0"

normal IS-Message Sync Bit, constant

Bit 12.. 15:

Sver

This field contains the TFO_Subversion number as specified in Annex H

Bit 16..18:

CRC

3 CRC bits protecting Bits 2 to 10 and 12 to 15

Bit 19..20:

EX

The normal 2 bits for IS_Message Extension:

00: No other extension block follows

11: An other extension block follows

7.5 TFO_ACK Messages

Symbolic Notation:
TFO_ACK (Sys_Id, RSig, Local_Used_Codec_Type [, Used_Codec_Attributes] )
TFO_ACK_L (Sys_Id, RSig, Local_Used_Codec_Type, Codec_List [, Alternative_Codec_Attributes] ).

The TFO_ACK Messages conform to the IS_ACK Message, defined in the Annex A, with IS_System_Identification, followed by the SIG_LUC Extension_Block, and optionally the Codec_x Extension_Block, the Codec_List Extension_Block(s) and the Codec_Attribute Extension_Blocks.

TFO_ACK and TFO_REQ Messages differ only in the ACK / REQ Command block and the construction of the Signature: Local_Signature in case of TFO_REQ, Reflected_Signature in case of TFO_ACK. All extension blocks defined for the TFO_REQ are valid as well for TFO_ACK.

The shortest TFO_ACK takes 140 ms for transmission.
The shortest TFO_ACK_L takes 180 ms.

7.6 TFO_TRANS Messages

Symbolic Notation: TFO_TRANS (Channel_Type).

Two TFO_TRANS Messages are defined in conformity to the IS_TRANS Messages in Annex A.
For 8 kbit/s submultiplexing the "TFO_TRANS (8k)" is used and is identical to "IS_TRANS_1_u".
For 16 kbit/s submultiplexing the "TFO_TRANS (16k)" is used and is identical to "IS_TRANS_2_u".

For 32 kbit/s submultiplexing the "TFO_TRANS (32k)" is used and is identical to "IS_TRANS_4_u".

TFO_TRANS() takes 100 ms for transmission.

In most cases the respective TFO_TRANS Message shall be sent twice: once as a regular TFO Message, exactly before any series of TFO Frames, and once embedded into the first TFO Frames, see clause 10.

7.7 TFO_NORMAL Message

Symbolic Notation: TFO_NORMAL.

The TFO_NORMAL Message is identical to the IS_NORMAL Message defined in the Annex A.

It shall be sent at least once whenever an established Tandem Free Operation needs to be terminated in a controlled way.

TFO_NORMAL takes 100 ms for transmission.

7.8 TFO_FILL Message

Symbolic Notation: TFO_FILL.

The TFO_FILL Message is identical to the IS_FILL Message, defined in the Annex A.

TFO_FILL may be used to pre-synchronise IPEs. Since IS_FILL is one of the shortest IS Messages, this is the fastest way to synchronise IPEs, without IPEs swallowing other protocol elements. By default three TFO_FILL messages shall be sent at the beginning; this number may be, however, configuration dependent.

One TFO_FILL takes 60 ms for transmission.

7.9 TFO_DUP Message

Symbolic Notation: TFO_DUP

The TFO_DUP Message is identical to the IS_DUP Message, defined in Annex A.

TFO_DUP informs the distant TFO Partner, that TFO Frames have been received unexpected, e.g. during Establishment. This enables a fast re-establishment of TFO after a local handover.

TFO_DUP takes 60 ms for transmission.

7.10 TFO_SYL Message

Symbolic Notation: TFO_SYL

The TFO_SYL Message is identical to the IS_SYL Message, defined in Annex A.

TFO_SYL informs the distant TFO Partner, that tandem free operation has existed, but suddenly no TFO Frames were received anymore. This enables a fast re-establishment of TFO after a distant handover.

TFO_SYL takes 60 ms for transmission.

7.11 Specification of the TFO Messages

7.11.1 Codec_Types

The Codec_Types are defined according to 3GPP TS 26.103, table 6.3-1.

The short form (CoID_s) exists for all Codec_Types with indices below 15 and consists of the last four bits (LSBs) of the long form (CoID).

7.11.2 Codec_List

The Codec_List is defined according to 3GPP TS 26.103. The mapping into the Codec_List Extension block shall be as follows: bit 1 of octet 1 shall be placed into Bit 2 of the Codec_List Extension block, and so on until bit 4 of octet 2 shall be placed into Bit 14.

If more than 12 Codec Types are contained in the Codec_List, then Bit 15 of the first Codec_List Extension block shall be set to "1" and an further Codec_List Extension block shall be added for the next 12 Codec Types.

7.11.3 Codec_Type Attributes

The Codec_Types GSM Full Rate, GSM Half Rate and GSM Enhanced Full Rate do not need additional attributes. They are fully defined by the System_Identification (see Annex A.5) and the Codec_Type.

7.11.3.1 AMR Codec_Type Attributes

The Adaptive Multi-Rate Codec_Types (FR_AMR, HR_AMR, UMTS_AMR, UMTS_AMR_2, OHR_AMR) and the Adaptive Multi-Rate Wideband Codec_Types (FR_AMR-WB, UMTS_AMR-WB, OFR_AMR-WB, OHR_AMR-WB) need several attributes within the TFO_REQ and TFO_ACK as well as in the TFO_REQ_L and TFO_ACK_L Messages. For Con_Req and Con_Ack frames see Annex C.

There are two major kinds of attributes: the ACS (Active Codec Set) and potentially the SCS (Supported Codec Set). These attributes are signalled differently for the AMR Codec_Types and AMR-WB Codec_Types, resulting in a different construction of TFO messages.

The ACS is related to the Local_Used_Codec_Type and is part of the Used_Codec_Attributes. One and exactly one ACS_Extension_Block shall be sent in all cases where the Local_Used_Codec_Type is an AMR Codec_Type. In all cases where the Local_Used_Codec_Type is an AMR-WB Codec_Type the ACS is signalled within the AMR-WB specific Attribute_Head Extension_Block. In the former case, the ACS_Extension_Block carries some more parameters, as defined in the next clause, the most important one is the "Full_Sub" flag, indicating whether or not the full set or a sub-set of the AMR codec modes is supported. In TFO_REQ and TFO_ACK Messages the ACS shall follow immediately after the SIG_LUC_Extension_Block. In TFO_REQ_L and TFO_ACK_L Messages an Attribute_Head_Extension_Block shall follow after the Local_Codec_List, indicating the Codec_Type it specifies. In the case of an AMR Codec_Type the corresponding ACS_Extension_Block is following next. In the case of an AMR-WB Codec_Type no ACS_Extension_Block is following since the ACS is already defined within the Attribute_Head.

The SCS shall be sent in TFO_REQ or TFO_ACK only if the ACS_Extension_Block indicates that the sending side does not support the full set of AMR codec modes, but a subset (Full_Sub flag). In this case the SCS_Extension_Block shall follow immediately after the ACS_Extension_Block.

NOTE 1: Hence, the TFO_Protocol can decide immediately after the reception of TFO_REQ or TFO_ACK whether TFO is possible or not, and can report the distant TFO parameters to the Control Entity in the Network.

One and only one ACS_Extension_Block is included in TFO_REQ_L and TFO_ACK_L, if the Local_Used_Codec_Type is an AMR Codec_Type. In addition, one SCS_Extension_Block is needed for each AMR Codec_Type flagged in the Local_Codec_List. In that case an Attribute_Head_Extension_Block shall follow after the Local_Codec_List, indicating the Codec_Type it specifies, followed by the corresponding SCS_Extension_Block. If multiple AMR_Codec_Types are flagged, then multiple Attribute_Heads and SCS_Extension_Blocks may be needed.

If the TFO_Version Extention_Block is not included, and if the full set of AMR Codec Modes is supported, then neither the Attribute_Head nor the SCS_Extension_Block shall be sent for the alternative Codec_Type(s).
If, however, the TFO_Version Extension_Block is included at the end of the TFO_REQ_L or TFO_ACK_L, then the Attribute_Head and potentially (if PAR_Sel is set to "1") the SCS_Extension_Block shall be sent for each alternative AMR Codec_Type.

For each AMR-WB Codec_Type flaged in the Local_Codec_List, one Attribute_Head Extension_Block shall follow after the Local_Codec_List. Since the AMR-WB specific Attribute_Head fully defines the SCS no further SCS Extension_Block is following.

The following figures give the examples for the full-set AMR TFO Messages. Note that an additional TFO_Version Extension_Block shall follow if the TFO version is equal or greater than 5.

Figure 7.11.3.1-1: Construction of the shortest possible TFO_REQ Message for any AMR Codec Type

TFO_ACK follows the same construction. Both have a length of 180ms.

Figure 7.11.3.1-2: Construction of the shortest possible TFO_REQ_L Message listing an AMR Codec_Type in the Codec_List

TFO_ACK_L follows the same construction. Both have a length of 260ms.

NOTE 2: In TFO_REQ_L (TFO_ACK_L) at least one Attribute_Head is needed, if the Local_Used_Codec_Type is an AMR Codec_Type, because otherwise a TFO partner that does not know the Local_Used_Codec_Type cannot know how many attributes are needed – if any. Since these longer messages are used only when mismatch is identified or in other situations, where protocol speed is not important, this additional 40ms message length is not important.

For example, assume that the Local_Used_Codec_Type is FR_AMR and the supported codecs which are flagged in the Codec_List are FR_AMR, HR_AMR, and FR_AMR-WB. Then, if neither FR_AMR nor HR_AMR support the full set of AMR modes, the following six Extension_Blocks follow the Codec_List: Atrib_Head(FR_AMR) – ACS(FR_AMR) – SCS(FR_AMR) – Atrib_Head(HR_AMR) – SCS(HR_AMR) – Atrib_Head(FR_AMR-WB).

7.11.3.1.1 AMR Active_Codec_Set Attributes

One AMR_ACS Extension_Block shall be added in the TFO_REQ and TFO_ACK messages after the SIG_LUC Extension_Block if an AMR Codec_Type is used as the Local_Used_Codec_Type.

Table 7.11.3.1.1-1: AMR_ACS Extension_Block

Bit

Description

Comment

Bit 1

"0"

Normal IS-Message Sync Bit, constant.

Bit 2..9

Active Codec Set

(NB_ACS)

Active Codec Set: For each Codec_Mode of the AMR one bit is reserved. If the bit is set to "0" then the specific Codec_Mode is not in the ACS, otherwise it is in and may be used by the adaptation algorithm.
Bit 2: AMR_Mode 12,2 kbit/s (undefined for HR_AMR)
Bit 3: AMR_Mode 10,2 kbit/s (undefined for HR_AMR)

Bit 4: AMR_Mode 7,95 kbit/s

Bit 5: AMR_Mode 7,40 kbit/s

Bit 6: AMR_Mode 6,70 kbit/s

Bit 7: AMR_Mode 5,90 kbit/s

Bit 8: AMR_Mode 5,15 kbit/s

Bit 9: AMR_Mode 4,75 kbit/s

Bit 10

Full_Sub
(NB_F/S)

0: Full Set supported, NB_SCS is not following

1: Subset only supported, NB_SCS is following immediately

Bit 11

"0"

Normal IS-Message Sync Bit, constant

Bit 12

spare

set to "1"

Bit 13

Optimisation Mode
(NB_OM)

ACS Optimisation Mode

0 No ACS Change supported

1 ACS change supported

Bit 14 & 15

NB_Ver

Version Number of the AMR-NB TFO Scheme

Bit 15 is equivalent to the ATVN in Configuration Frames, see Annex C

Bit 16..18

CRC

3 CRC bits protecting Bits 2 to 10 and 12 to 15

Bit 19..20:

EX

The normal 2 bits for IS_Message Extension:

00: No other extension block follows

11: An other extension block follows (i.e. SCS)
7.11.3.1.2 AMR Supported_Codec_Set Attributes

The AMR_SCS Extension_Block contains the information on the AMR Supported Codec Set. It shall be omitted, if the full set is supported. Table 7.11.3.1.2-1 gives the description of the SCS Extension_Block.

For the Local_Used_Codec_Type the SCS Extension_Block shall follow immediately after the corresponding ACS Extension_Block. In that case the Full_Sub flag shall be set within the ACS Extension_Block. For alternative Codec_Types, as flagged in the Local_Codec_List, the SCS shall follow immediately after the corresponding Attribute_Head Extension_Block.

NOTE: The VERsion numbers in ACS and SCS Extension_Blocks shall be identical for one Codec_Type, but may be different for different Codec_Types (e.g. FR_AMR and HR_AMR).

Table 7.11.3.1.2-1: AMR_SCS Extension_Block

Bit

Description

Comment

Bit 1

"0"

Normal IS-Message Sync Bit, constant.

Bit 2…9

Supported Codec Set
(NB_SCS)

Supported Codec Set: For each Codec_Mode of the AMR one bit is reserved. If the bit is set to "0" then the specific Codec_Mode is not supported; if the bit is set to "1" then the specific Codec_Mode is supported and may be considered for the optimisation of the common ACS.

Bit 2: AMR_Mode 12,2 kbit/s (undefined in SCS(H))
Bit 3: AMR_Mode 10,2 kbit/s (undefined in SCS(H))

Bit 4: AMR_Mode 7,95 kbit/s

Bit 5: AMR_Mode 7,4 kbit/s

Bit 6: AMR_Mode 6,7 kbit/s

Bit 7: AMR_Mode 5,9 kbit/s

Bit 8: AMR_Mode 5,15 kbit/s
Bit 9: AMR_Mode 4,75 kbit/s

Bit 10

NB_MACS MSB

See comment for Bit 12…13

Bit 11

"0"

normal IS-Message Sync Bit, constant

Bit 12…13

NB_MACS LSBs

The maximally supported number of Codec_Modes in this radio leg. Coding for bits 10.12.13:

"0.0.1" 1 Mode

"0.1.0" 2 Modes

"0.1.1" 3 Modes

"1.0.0" 4 Modes

"1.0.1" 5 Modes

"1.1.0" 6 Modes

"1.1.1" 7 Modes

"0.0.0" 8 Modes

Bit 14…15

NB_Ver

Version Number of the AMR TFO Scheme for that Codec_Type

Bit 15 is equivalent to the ATVN in Configuration Frames, see Annex C

Bit 16..18

CRC

3 CRC bits protecting Bits 2 to 10 and 12 to 15

Bit 19 20

EX

The normal 2 bits for IS_Message Extension:

00: No other extension block follows

11: An other extension block follows
7.11.3.1.3 AMR specific Codec_Attribute_Head Extension_Block

The AMR specific Codec_Attribute_Head Extension_Block (Table 7.11.3.1.3-1) shall precede the Codec Attribute Extension_Blocks of any AMR Codec_Type.

Table 7.11.3.1.3-1: AMR specific Codec_Attribute_Head Extension_Block

Bit

Description

Comment

Bit 1

"0"

normal IS-Message Sync Bit, constant.

Bit 2

PAR_Sel

Differentiates this Extension_Block
0: Parameters included in PAR field: Simple Codec_List_Extension
1: Length Indicator (LI) included: Parameters follow in subsequent Extension_Blocks

Bit 3..10

CoID =
HR_AMR or
FR_AMR or
UMTS_AMR or
UMTS_AMR2 or
OHR_AMR

This field identifies the AMR Codec_Type for which the subsequent attributes are valid. The same coding as in the Codec_x Extension_Block is used (long form)

Bit 11

"0"

normal IS-Message Sync Bit, constant

Bit 12.. 15:

LI / PAR

If Par_Sel==1: LI: Length Indicator:
0000: reserved;
0001: one other Extension_Block follows, etc.
If Par_Sel==0: PAR: Codec specific definition of these four bits

Bit 16..18:

CRC

3 CRC bits protecting Bits 2 to 10 and 12 to 15

Bit 19..20:

EX

The normal 2 bits for IS_Message Extension:

00: No other extension block follows

11: An other extension block follows

If PAR_Sel is set to "1" then the AMR_ACS and potentially AMR_SCS is/are following.
The option "Par_Sel=0" and the corresponding configuration codes can only be used in TFO Version 5 and onwards. A Pre-REL-5 implementation does not understand it and shall ignore it.

If PAR_Sel is set to "0", then one of 16 possible AMR Configurations is indicated in the
PAR field and no additional Codec Attribute Extension_Blocks do follow.
The coding for PAR (bits 12.13.14.15) is defined in Table 7.11.3.1.3-2 (Config-NB-Code):

Table 7.11.3.1.3-2: Preferred Configurations for the Adaptive Multi-Rate Codec Types

Configuration →
(Config-NB-Code)
↓ Codec Mode


0


1


2


3


4


5


6


7


8


9


10


11


12


13


14


15

12,20

(1)

1

1

1

10,20

1

1

1

7,95

1

1

1

7,40

1

1

1

1

6,70

1

1

1

1

1

1

5,90

1

1

1

1

1

1

1

1

1

1

5,15

4,75

1

1

1

1

1

1

1

1

1

1

OM

F

F

F

F

F

F

F

F

F

F

F

A

F

A

F

A

HR_AMR

Y

Y

Y

Y

Y

Y

Y

Y

Y

FR_AMR, OHR_AMR,
UMTS_AMR,
UMTS_AMR_2


Y


Y


Y


Y


Y


Y


Y


Y


Y


Y


Y


Y


Y


Y


Y


Y

The "1" in the table indicates that the Codec Mode is included in the Active Codec Set of the Configuration.

The parameter "OM" (Optimisation Mode) defines whether the indicated Configuration can be changed to any of the other Allowed ones (OM == A) or if the change is Forbidden (OM == F). For the three "A" configurations (11, 13 and 15) the TFO Decision algorithm shall consider the SCS {1, 1, 1, 1, 1, 1, 0, 1}, i.e. all AMR modes except the 5.15 kbps shall be treated as supported and the OM shall be assumed to be "Optimisation of the ACS supported". For the other "F" configurations the ACS and SCS shall be assumed to be identical and as shown in the configuration table. The OM shall be assumed to be "Optimisation of the ACS not supported".

Note: If one TFO Partner uses this short form to offer one of these three Preferred Configurations that allow a change of the configuration (i.e. offers Config-NB-codes 11, 13 or 15) and the other TFO Partner uses the long form to offer a configurations (i.e. with ACS, SCS, OM and MACS), then it might happen that the TFO Decision determines a common configuration that is not within the set of these 16 Preferred Configurations.

A change via Maximum Rate Control is always possible (e.g. from configurations 10, 11, 12, 13, 14, 15 to 9 and 8).

The "Y" in the table indicates, which Configuration is defined for which Codec Type.

Among these 16 preferred AMR Configurations is one with specific importance for calls between GERAN and UTRAN: "Config-NB-Code = 1", with modes 12.2, 7.4, 5.9, 4.75. This Configuration is especially recommended, because it leads in all call cases to TFO/TrFO compatible connections with optimal voice quality.

In case this Configuration "Config-NB-Code = 1" is signalled in the TFO Negotiation for the HR_AMR Codec Type, then it shall be assumed that AMR mode 12.2 kbps is (of course) not included. For all other AMR Codec Types all four modes are included.

7.11.3.1.4 AMR-WB specific Codec_Attribute_Head Extension_Block

The AMR-WB specific Codec_Attribute_Head Extension_Block is defined in Table 7.11.3.1.4-1.

Table 7.11.3.1.4-1: AMR-WB specific Codec_Attribute_Head Extension_Block

Bit

Description

Comment

Bit 1

"0"

normal IS-Message Sync Bit, constant.

Bit 2

PAR_Sel

Differentiates this Extension_Block
0: Parameters included in PAR field: Simple Codec_List_Extension
1: undefined

Bit 3..10

CoID =
FR_AMR-WB or
UMTS_AMR-WB or
OHR_AMR-WB or
OFR_AMR-WB

This field identifies the AMR-WB Codec_Type for which the subsequent attributes are valid. The same coding as in the Codec_x Extension_Block is used (long form)

Bit 11

"0"

normal IS-Message Sync Bit, constant

Bit 12.. 15:

PAR

AMR-WB configuration as defined in TS 26.103, table 5.7-1
(Config-WB-Code)

Bit 16..18:

CRC

3 CRC bits protecting Bits 2 to 10 and 12 to 15

Bit 19..20:

EX

The normal 2 bits for IS_Message Extension:

00: No other extension block follows

11: An other extension block follows