C.6 The Dialogue between TFO_TRAU and TFO_BTS
28.0623GPPInband Tandem Free Operation (TFO) of speech codecsService descriptionStage 3TS
From REL-5 onwards the "Generic Configuration Frame" is defined (Annex H) as a mechanism to exchange Configuration parameters between BTS and TRAU, between the TRAUs and between local and distant BTSs. These generic configuration frames are codec-type-independent and may in principle be used also for older Codec Types. Clause 4.3 defines when to use this generic configuration frame and when to use the AMR Configuration frame or the TFO_REQ_L / TFO_ACK_L mechanism.
The BTS need not to be involved in TFO when GSM_FR, GSM_EFR or GSM_HR Speech Codec Types are used.
But from REL-5 onwards the generic configuration frames may also be used for these Codec Types. Then the BTS shall be able to handle them, at least to ignore them, when they appear in downlink on the Abis/Ater interface. If this is not possible, then the TRAU shall not use it either.
The following clauses address therefore mainly the dialog between the BTS and TRAU or between the Local and Distant TRAUs or BTSs in case of the AMR-NB and AMR-WB families of Codec Types.
C.6.1 Configuration Parameters in AMR-NB TRAU/TFO frames
C.6.1.1 Configuration Protocol Format
"TRAU AMR Configuration frames" and "TFO AMR Configuration frames" contain AMR-NB and TFO configuration parameters. The "generic configuration frames" contain configuration parameters for all codec types. These parameters are exchanged by the following configuration protocol between several entities (local BTS to local TRAU, local BTS to distant BTS, local TRAU to distant BTS and local TRAU to local BTS).
Three control fields are defined for the TFO and TRAU AMR Configuration frames and in generic configuration frames:
– Config_Prot field defines the sender and the recipient;
– Message_No field is a protocol counter;
– Par_Type field defines the contents of the parameter fields.
The Parameter fields carry the TFO and AMR Configuration parameters.
Each TFO (or TRAU) AMR configuration frame contains a set or a subset of these configuration parameters. Some exceptions exist (12,2 kbit/s for instance, see mapping of Configuration Parameters clause C.6.1.5).
Generic configuration frames do always contain a full set, see Annex H.
C.6.1.2 Config_Prot field
This field serves for the Configuration Protocol on the Abis/Ater interface and the A interface in both directions to indicate the source and meaning of the configuration parameters. It is defined in UL TRAU frames, in DL TRAU frames and in TFO frames, both for the AMR Configuration Frames and the Generic Configuration Frames.
Table C.6.1.2-1: Coding of Config_Prot
|
Config_Prot |
Name |
Exists on |
Meaning |
sent by |
recipient |
|
0.0.0 |
No_Con |
UL, DL, TFO frame |
No configuration included, shall not be acknowledged |
||
|
0.0.1 |
Con_Req |
UL, DL, TFO frame |
configuration included, |
L_BTS |
D_BTS, L_TRAU |
|
0.1.0 |
Dis_Req |
DL |
(subset of) configuration |
L_TRAU |
L_BTS |
|
0.1.1 |
Con_Ack |
UL, DL, TFO frame |
acknowledge for Con_Req |
L_BTS, D_BTS |
D_BTS, L_BTS |
|
1.0.0 |
Spare |
– |
for future use |
||
|
1.0.1 |
UL_Ack |
UL |
acknowledge for Dis_Req |
L_BTS |
L_TRAU |
|
1.1.0 |
DL_Ack |
DL |
acknowledge for Con_Req |
L_TRAU |
L_BTS |
|
1.1.1 |
Spare |
– |
for future use |
Notation: L_TRAU: local TRAU, L_BTS: local BTS, D_BTS: distant BTS.
For the mapping of these bits on TRAU/TFO frames, see clause C.6.1.5 for AMR Configuration frames and Annex H for generic configuration frames.
For the use of the Config_Prot, see clause C.8.
C.6.1.3 Message_No Field
The Message_No is used to mark a configuration request message at sender side in order to bind the acknowledgement from the receiver side. It is two bits long. For the mapping of these bits see clause C.6.1.5 and Annex H.
C.6.1.4 Configuration Parameters Fields
The configuration parameters are:
TFOE (1 bit)
TFOE (TFO_Enable) set to 0: TFO disabled; set to 1: TFO enabled.
By this bit set to 1 the BTS enables the TRAU to perform TFO negotiation and to go into Tandem Free Operation, if possible. Respectively, if this bit is set to 0, the TRAU shall terminate TFO as soon as possible and shall not initiate or respond to any TFO negotiation message.
TFOE in AMR Configuration frames or generic configuration frames is also used to signal to the distant TFO partner that TFO is terminated (see Annex G.3).
Time Alignment Field (6 bits)
The Time Alignment Field is defined in 3GPP TS 48.060 [3] for time and phase alignment.
In addition five more code points, which are reserved in3GPP TS 48.060 [3] are defined for TFO and Handover Notifications:
|
Time Alignment Field |
Name |
defined on |
|---|---|---|
|
1.1.1.0.0.0 |
TFO_On |
Abis/Ater |
|
1.1.1.0.0.1 |
TFO_Soon |
Abis/Ater |
|
1.1.1.0.1.0 |
TFO_Off |
Abis/Ater |
|
1.1.1.0.1.1 |
Handover_Soon |
Abis/Ater and A |
|
1.1.1.1.0.0 |
Handover_Complete |
Abis/Ater and A |
The protocol for the exchange of these Notifications is defined in Annex C.6.2.
Par_Type (2 bits)
Par_Type defines the meaning of the Configuration Parameters. It is set by the sender of the configuration frame.
MSB.LSB:
0.0 Configuration Parameters not valid
0.1 local Configuration Parameters
1.0 distant Configuration Parameters
1.1 optimal Configuration Parameters
Codec_List (13 bits)
The supported Codec Types are coded as defined in 3GPP TS 26.103, clause "Codec Bitmap", bit 1 to bit 13. Bit 13 is defined to be the MSB of the Codec List field. For the mapping of these bits on TRAU/TFO frames, see clause C.6.1.5 for AMR Configuration frames. This field is not present in generic configuration frames.
Sys_ID (4 bits)
The Sys_ID codes the System_Identification of the sending side, see table Annex A.5-1. Only the four LSBs are used here (short form) in AMR Configuration frames. The four MSBs are assumed to be "0". In generic configuration frames this parameter is coded with 8 bits.
Active_Codec_Type (ACT: 4 bits)
The Active_Codec_Type identifies the Codec_Type actually used. The coding is according to 3GPP TS 26.103, table 6.3-1. The lower four bits are used here in AMR configuration frames (short form). The long form is used in generic configuration frames.
Active_Codec_Set (ACS: 8 bits see 3GPP TS 45.009 [9]):
The ACS is defined, if the Active_Codec_Type is from the AMR-NB family. The coding is according to 3GPP TS 26.103.
Supported_Codec_Set (SCS: 8 bits; see 3GPP TS 45.009 [9]):
The SCS is defined, if the Active_Codec_Type is from the AMR-NB family.. The coding is according to 3GPP TS 26.103.
Maximum Number of Modes in the ACS (MACS: 3 bits)
The MACS is defined, if the Active_Codec_Type is from the AMR-NB family. The coding is according to 3GPP TS 26.103.
AMR TFO Version Number (ATVN: 1 bit)
The current AMR TFO Version Number is 0.
Optimisation Mode (OM: 1 bit)
The Optimisation Mode is defined, if the Active_Codec_Type is from the AMR-NB family. The coding is according to 3GPP TS 26.103.
Optimal or Distant Configuration (OD: 1 bit)
The "Optimal or Distant Configuration" parameter is described in clause C.5.2.2.
CRC_A : 3-bit CRC (see clause 7.3).
CRC_B: 3-bit CRC (see clause 7.3).
CRC_C: 3-bit CRC (see clause 7.3).
C.6.1.5 Mapping of the Configuration Parameters on 16 and 8 kbit/s TRAU/TFO frames for AMR Configuration
AMR Configuration frames are defined for REL-4 and REL-5. In case generic configuration frames shall be used (see clause 4.3) the AMR Configuration bits in TFO/TRAU Speech and No_Speech Frames shall be set to spare = "1".
Table C.6.1.5-1 gives the mapping of the AMR configuration fields for each frame (TRAU/TFO) format:
Table C.6.1.5-1: Mapping of the configuration parameters in the TRAU/TFO frames
|
Sub-multiplexing |
8 kbit/s |
8 kbit/s |
8 kbit/s |
16 kbit/s |
16 kbit/s |
16 kbit/s |
||
|
Codec Modes |
#bits |
No_Data |
SID |
Speech |
No_Speech |
Speech |
Speech |
|
|
Time Align. Field |
6 |
D1..D6 |
D1..D6 |
# (= TFO_On) |
C6..C11 |
C6..C11 |
C6..C11 |
|
|
Config_Prot |
3 |
D55..D57 |
D55..D57 |
D55..D57 |
C14..C16 |
C14..C16 |
C14..C16 |
|
|
Message_No |
2 |
D58..D59 |
D58..D59 |
D58..D59 |
C17..C18 |
C17..C18 |
C17..C18 |
|
|
TFO_Enable |
1 |
D64 |
D64 |
# (= 1) |
C20 |
C20 |
C20 |
|
|
Par_Type(5) |
2 |
D65..D66 |
D65..D66 |
# (= 0.0) |
D1..D2 |
D1..D2 |
D1..D2 |
|
|
OD |
1 |
D67 |
D67 |
# |
D3 |
D3 |
D3 |
|
|
OM(3) |
1 |
D68 |
D68 |
# |
D4 |
D4 |
D4 |
|
|
ACS(3) |
8 |
D69..D76 |
D69..D76 |
# |
D5..D12 |
D5..D12 |
D5..D12 |
|
|
SCS(3) |
8 |
D77..D84 |
D77..D84 |
# |
D13..D20 |
D13..D20 |
D13..D20 |
|
|
ATVN(3), short(6) |
1 |
D85 |
D85 |
# |
D21 |
D21 |
# (= 0) |
|
|
Sys_ID, short(6) |
4 |
D86..D89 |
D86..D89 |
# |
D22..D25 |
D22..D25 |
# (= 0..0) |
|
|
spare (= 0) |
3 |
D90..D92 |
D90..D92 |
# |
D26..D28 |
D26..D28 |
# (= 0) |
|
|
CRC_A |
3 |
D93..D95 |
D93..D95 |
# |
D29..D31 |
D29..D31 |
#(1) |
|
|
ACT(3) |
4 |
D96..D99 |
D96..D99 |
# |
D234..D237 |
D234..D237 |
D234..D237 |
|
|
MACS(3) |
3 |
D100..D102 |
D100..D102 |
# |
D238..D240 |
D238..D240 |
D238..D240 |
|
|
Codec List |
13 |
D103..D115 |
D103..D115 |
# |
D241..D253 |
D241..D253 |
D241..D253 |
|
|
CRC_B |
3 |
D116..D118 |
D116..D118 |
# |
D254..D256 |
D254..D256 |
#(2) |
|
|
SCS_2(4) |
8 |
D17..D24 |
# (= 1..1) (7 |
# |
D203..D210 |
D203..D210 |
# (= 1..1) (7) |
|
|
OM_2(4) |
1 |
D25 |
# (= 0) |
# |
D211 |
D211 |
# (= 0) |
|
|
MACS_2(4) |
3 |
D26..D28 |
# (= 1.0.0) |
# |
D212..D214 |
D212..D214 |
# (= 1.0.0) |
|
|
ATVN_2(4)(6) |
1 |
D29 |
# (= 0) |
# |
D215 |
D215 |
# (= 0) |
|
|
SCS_3(4) |
8 |
D30..D37 |
# (= 1..1) (7 |
# |
D216..D223 |
D216..D223 |
# (= 1..1) (7) |
|
|
OM_3(4) |
1 |
D38 |
# (= 0) |
# |
D224 |
D224 |
# (= 0) |
|
|
MACS_3(4) |
3 |
D39..D41 |
# (= 1.0.0) |
# |
D225..D227 |
D225..D227 |
# (= 1.0.0) |
|
|
ATVN_3(4)(6) |
1 |
D42 |
# (= 0) |
# |
D228 |
D228 |
# (= 0) |
|
|
spare (=0) |
2 |
D43..D44 |
# |
# |
D229..D230 |
D229..D230 |
# |
|
|
CRC_C |
3 |
D45..D47 |
# |
# |
D231..D233 |
D231..D233 |
# |
|
|
8k_spare |
7 |
D48..D54 |
# |
# |
||||
|
8k_spare |
7 |
D119..D125 |
D119..D125 |
# |
||||
|
16k_spare |
14 |
D44..D57 |
# |
# |
The bit positions refer to the positions reserved in 3GPP TS 48.060 [3] and 3GPP TS 48.061 [4] : D bits are data bits, C bits are control bits. The parameters are mapped into the field with MSB first, example:
Par_Type: MSB => D65, LSB => D66 in 8k frames.
# denotes not existing fields; the entries in brackets () denote the default values of the missing parameters, see Note(7). Only if the missing parameters are set to these default values, these frames may be used. Otherwise No_Data frames shall be used.
NOTE 1: In Mode 10,2 the bits D93..D95 are already used for the CRC1 of the first sub-frame. The bits otherwise protected by CRC_A shall be protected in Mode 10,2 by CRC1 (see 3GPP TS 48.060 [3]).
NOTE 2: In Mode 10,2 the bits D254..D256 are already used for the CRC4 of the fourth sub-frame. The bits otherwise protected by CRC_B shall be protected in Mode 10,2 by CRC4 (see 3GPP TS 48.060 [3]).
NOTE 3: The fields ACS, SCS,MACS, OM and ATVN shall always be used for the Active Codec Type, if from the AMR family.
NOTE 4: The fields SCS_2 … ATVN_3 are reserved for the other AMR Codec Types, when flagged in the Codec_List, according to the following mapping:
|
Active Codec Type |
ACS, SCS, OM, MACS, ATVN |
SCS_2, OM_2, MACS_2, ATVN_2 |
SCS_3, OM_3, |
|
none of AMR |
FR_AMR |
HR_AMR |
UMTS_AMR(_2) |
|
FR_AMR |
FR_AMR |
HR_AMR |
UMTS_AMR(_2) |
|
HR_AMR |
HR_AMR |
FR_AMR |
UMTS_AMR(_2) |
|
UMTS_AMR(_2) (8) |
UMTS_AMR(_2) |
FR_AMR |
HR_AMR |
If a Codec Type is not within the Codec_List, then the corresponding fields are undefined and shall be set to "0".
NOTE 5: If Par_Type is set to "Optimal Configuration", then ACT and ACS shall carry the optimal configuration. All other configuration parameters shall carry the Codec List and the relevant configuration parameters.
NOTE 6: For Sys_ID and ATVN a short form is used: only lower 4 bits for Sys_ID, only LSB for AVTN. The missing bits are defined to be "0".
NOTE 7: The default setting for the SCS fields shall be "1111.1111" for FR_AMR and UMTS_AMR and "0001.1111" for HR_AMR.
NOTE 8: Either UMTS_AMR or UMTS_AMR_2 shall be indicated, but not both together, with preference to UMTS_AMR_2.
Note for the AMR_TFO_8+8k frames: Only the "No_Data" frames convey all configuration parameters. Thus, a speech frame has to be stolen when this configuration information has to be sent. The frames with a rate lower or equal to 5,9 kbit/s can convey only the Config_Prot and Mess_No without stealing a speech frame. Par_Type in these speech frames is assumed to be "0.0".
Note for the AMR_TFO_16k frames: All the configuration parameters are included in the rates below the 10,2 kbit/s. The 12,2 kbit/s conveys TFO enable and the Config_Prot only. Par_Type in 12,2 kbit/s speech frames is assumed to be "0.0". Thus a speech frame has to be stolen to send configuration parameters.
C.6.2 TFO and Handover Status of the Connection
C.6.2.1 TFO Status Messages
The TRAU shall inform the BTS of its TFO status with three TFO Notifications:
– TFO_Off TFO is not established.
– TFO_Soon TFO is likely to be established.
– TFO_On TFO is established and ongoing.
The BTS may inform the TRAU and the distant partner with two Handover Notifications
– Handover_Soon Handover is to be expected soon.
– Handover_Complete Handover has been performed.
C.6.2.2 Notification of Status of Connection
The Messages "TFO_Soon", "TFO_On" and "TFO_Off" are sent by the Tx_TRAU within the Time Alignment Field.
The BTS shall acknowledge the correct receipt of TFO Notifications by sending the received TFO Notification back to the TRAU. If the TRAU does not get a correct acknowledgement within N_out_1 frames, then it shall repeat the TFO Notification. N_out_1 shall be initialised at resource allocation to 4, but shall be adapted to the round trip delay between TRAU and BTS during the connection.
The Handover Notifications "Handover_Soon" and "Handover_Complete" are sent by the BTS to the TRAU within the Time Alignment. Field, always embedded in Con_Req() frames. Since Con_Req() frames shall always be acknowledged, no further acknowledgement for the Handover Notifications is required. If the BTS does not get a correct acknowledgement within N_out_2 frames, then it shall repeat the Handover Notification. N_out_2 is set to [4]. It should be adapted according to the round-trip delay.
The Time Alignment Field is used for several purposes: TFO Notifications, Handover Notifications, Time Alignment Request and Time Alignment Acknowledgement. The TRAU and BTS may initiate requests independently and uncoordinated. In case of conflicts the following priority shall be obeyed: Time Alignment Message may always be overwritten. Otherwise: Acknowledgements shall always have higher priorities than requests. With other words: an ongoing exchange shall first be terminated before a new one is started.
In case of ongoing TFO all uplink TRAU frames shall be relayed with minimal delay onto the A-interface as TFO frames. Likewise the received TFO frames shall be relayed as TRAU frames down to the BTS. The time alignment field of the TFO frames shall be copied, too.