C.2 Overview

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

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

TFO in GSM implies that the different entities of the BSS collaborate. This is achieved by the distribution of TFO processes on these entities. Figure C.2-1 provides an overview of the TFO processes inside the BSS. This figure shows also the interfaces between these TFO processes.

Figure C.2-1: Processes and Interfaces for TFO in GSM

The interfaces as shown in Figure C.2-1 are:

1) The Abis/Ater Interface (traffic): Only for the AMR or AMR-WB speech Codec Types the Abis/Ater interface is influenced by the TFO. In this case TFO information is exchanged in Config frames and Time Alignment and Rate Control is influenced.

2) An optional proprietary interface between the BSC and the TRAU; may be used for non-AMR and AMR and AMR-WB Speech Codec Types (FR_AMR, HR_AMR, GSM_FR, GSM_EFR, OHR_AMR, GSM_HR, FR_AMR-WB, UMTS_AMR-WB, OFR_AMR-WB, OHR_AMR-WB) to exchange messages on the distant and local codec configurations, or the optimal configuration.

3) Layer 3 signalling between the BSC and the BTS.

4) Layer 3 signalling between the BSC and the MS to modify a Codec Type or a Codec Configuration.

5) Air interface (RATSCCH, see 3GPP TS 45.009 [9]) to change the Codec Mode Indication phase in downlink or the Codec Configuration in case of AMR TFO.

TFO in GSM involves the following processes:

– TFO_TRAU: Mandatory for all Speech Codec Types

– TFO_BTS: Not existent for GSM_FR, GSM_HR and GSM_EFR. Some parts are mandatory, some are optional for the AMR and AMR-WB Speech Codec Type

– TFO_BSC: Optional for all Speech Codec Types

C.2.1 TFO_TRAU

Tandem Free Operation is essentially managed by the TRAU. In the simplest implementation version the TRAU can establish and maintain TFO fully on its own (within certain limits) as described below.

For all Codec Types the TRAU is responsible for the inband TFO Protocol, i.e. the TFO negotiation, TFO setup and the fast fall back to normal operation, if necessary. The TRAU has to monitor the ongoing call permanently for fast reaction, if required.
In all cases the TRAU has to perform the TFO Decision algorithm (see clauses 11 and 12). This TFO decision algorithm takes all known local and distant configuration parameters into account and identifies whether TFO is possible and what are the optimal call configuration parameters (Optimal Codec Type and Codec Configuration) in the given situation.
The TRAU has the responsibility to inform the BSC (and the BTS) about any change in the distant call configuration. It is optional for the BSC and the BTS to evaluate this information.

The TRAU may provide to the BSC and the BTS the optimal call configuration parameters resulting from the TFO Decision algorithm. It is optional for the BSC and/or BTS to evaluate these parameters. See also Annex D (TFO in UMTS) where the TC runs the TFO Decision algorithm and may provide the optimal configuration parameters to the serving MSC.

In case of the AMR and AMR-WB Codec Types the TRAU is responsible for the TFO relevant Rate Control. It shall limit the maximally allowed Rate (Codec Mode) in a way that it is always within the Common Active Codec Set of both sides. During TFO Konnect the TRAU is responsible to steer the uplink rate down to the TFO Setup Mode and release it as soon as TFO is in Operation.

If informed by the BSC with Pre-Handover Notification (optional), the TRAU is responsible for a safe handover in TFO by steering the uplink and downlink rates down into the Handover Mode, to fit best after handover.

C.2.2 TFO_BSC

The BSC has the overall responsibility, especially for all resources, on the radio channel and the BSS. For all Codec Types the BSC is responsible for Call Setup and for the support of BTS and TRAU with the necessary configuration parameters (Codec Type, Codec Configuration, alternative Codec List, radio channel capacity, Abis channel capacity, etc). The BSC is responsible to enable or disable TFO.

The BSC is responsible for Handover and should take care that the call configuration is not modified during handover unless absolutely necessary, because every local change has direct influence on the distant side.

The BSC is responsible that TFO is properly terminated before handover, if the call configuration after handover is not longer TFO compatible. This feature is optional. The BSC may delegate this responsibility to the TRAU, but this can only perform optimal, if supported by Pre-Handover Notification (optional).

The BSC is responsible for the change of the Codec Type, e.g. for Mismatch Resolution and Optimisation for TFO, if this is required or better for Tandem Free Operation. This feature is optional. This modification needs to be performed by BSS-MS Layer 3 signalling (Intra-cell Handover).

For the AMR and AMR-WB Codec Types the BSC is responsible for the change of the AMR configuration, if this is required or better for Tandem Free Operation. This feature is optional; it is signalled by the Optimisation Mode. If the BSC signals that it is willing to change, then it shall perform the change when necessary. The change may be performed by BSS-MS Layer 3 signalling (Intra-cell Handover or Mode Modify) or by BTS-MS inband signalling (RATSCCH).
The BSC may delegate the responsibility for changes of the AMR Configuration temporarily or fully to the BTS (optional). If this option is selected, then the BSC shall guarantee that the MS gets the correct and consistent configuration after local handover. This may be achieved by the BSC in two ways: either by withdrawing this responsibility from the BTS before every local handover in order to guarantee that the BTS terminates a potentially ongoing configuration modification properly; or by providing the full set of Configuration parameters for the time after handover to the MS and new BTS.

C.2.3 TFO_BTS

The BTS is not specifically involved in TFO processes for the Non_AMR Codec Types ( GSM_FR, GSM_HR, GSM_EFR).

For the GSM AMR and AMR-WB Codec Types (FR_AMR, HR_AMR, FR_AMR-WB) the BTS is responsible for the following functions. Some are optional.

The BTS receives the Codec Type and Codec Configuration from the BSC. The BTS shall send them in Config Frames uplink to the TRAU.

NOTE: The term "Config Frame" is used whenever configuration data are exchanged between BTS and TRAU, although in some Codec Modes these configuration data can be embedded into speech frames. But this is not relevant for the procedures and the understanding.

The BTS is responsible for the Rate Control concerning its local uplink and downlink radio interface.

The BTS shall take the Rate Control commands (CMR) from the TRAU into account, regardless whether TFO is ongoing or not. By this the TRAU can steer the Codec Mode (Rate) into the TFO Setup Mode (before TFO) and into the Handover Mode (in TFO, if informed properly by the BSC), and the TRAU can keep the Rates within the Common Active Codec Set.

The BTS shall suspend Time Alignment, when TFO is announced or established by the TRAU. Instead the BTS shall buffer the downlink TRAU frames for the proper transmission on the air interface. The BTS may perform phase alignment on the downlink radio interface by RATSCCH to optimise the downlink speech delay. This feature is optional.

The BTS shall perform bad frame handling and SID and No_Data frame handling in downlink.

The BTS has the (optional) ability to perform a traffic synchronised modification of the AMR Configuration (Active Codec Set) by the RATSCCH protocol without interrupting the speech communication. This is important in TFO situations where the distant TFO Partner modifies its AMR Configuration relatively often. This RATSCCH protocol can be triggered by the BSC. If delegated by the BSC to the BTS the RATSCCH protocol can be triggered by the BTS itself, or by the TRAU. The latter two options reduce the signalling and computational load of the BSC.

C.2.4 Modifications of the Codec Type and/or the Codec Configuration

The following clauses provide a brief overview over all possible versions (not to be mixed up with "AMR TFO Version" or "TFO Version"). They differ in the Node where the TFO Decision is performed and the Node that executes the decided change. The following table provides an overview:

TFO Decision by → ↓ Execution of change by	TRAU (always necessary)	BTS (optional)	BSC (optional)
TRAU (only Rate Control)	Version 0	–	–
BTS (only Configuration change by RATSCCH)	Version 5	Version 3	Version 2
BSC (Codec Type change by Layer 3 and Configuration change by Layer 3)	Version 6 (used in UMTS)	Version 4	Version 1

Version 0, TRAU decided, no change: The TRAU gets the distant Codec Type and Codec Configuration and runs the TFO Decision algorithm. No change of Codec Configuration or Codec Type is allowed. The TRAU may only limit the maximally allowed Codec Mode via Rate Control.

Versions 1 and 2, BSC decided: The BSC gets the distant Codec Type and Codec Configuration from the TRAU and runs the TFO Decision algorithm (in addition to the TRAU). If necessary the BSC modifies the Codec Type (including the Codec Configuration) by Intra Cell Handover (Version 1 only). If only the Codec Configuration has to be changed, the BSC can do this either by Intra Cell Handover or by Mode Modify (Version 1) or by RATSCCH (Version 2).

NOTE 1: These versions provide the slowest Codec Configuration modification on interface (5), due to the signalling on interface (3) and potential latency time within the (loaded) BSC. They generate some signalling load on interfaces (3) and (4) and some computational load within the BSC. The AMR internal Rate Control and Configuration problems are clearly visible for the BSC. The BSC has full control. Intra Cell handover for Codec Configuration modification requires radio capacity and some interruption of the speech path. Mode Modify for this purpose does not guarantee a synchronised update in MS and BTS. In both cases it is recommended to terminate TFO before, if ongoing.

The TFO Decision algorithm must be implemented and updated identically in TRAU and BSC to get consistent results.

Versions 3 and 4, BTS decided: If delegated so by the BSC the BTS has to run the TFO Decision algorithm (in addition to the TRAU) and has to perform Configuration Optimisation and Modification by the RATSCCH protocol (Version 3). In this case the BTS has to inform the BSC after each successful modification on the radio interface. The BSC can suspend this BTS process at any time. It may be necessary to suspend it by the BSC especially before handover and delegate it after handover again. In cases when the Codec Type must be modified, the BTS must send the Optimal Codec Type and Codec Configuration to the BSC for the modification and shall not perform any modification itself (Version 4).

NOTE 2: Version 3 provides the fastest Codec Configuration modification on interface (5) with minimal signalling on interfaces (3) and (4) and minimal computational load within the BSC. It hides AMR internal Rate Control and Configuration problems for the BSC. The BSC has not to run the TFO Decision algorithm, but the BTS. Version 4 is similar to version 1 in timing.

Versions 5, TRAU decided, BTS executed: The TRAU has to run the TFO decision algorithm anyway. It sends the Optimal Codec Type and Codec Configuration down to the BTS. This eliminates the need to run the TFO Decision algorithm in the BTS and/or BSC again. In cases when the Codec Type must be modified, the BTS must send the Optimal Codec Type and Codec Configuration to the BSC for the modification and shall not perform any modification itself (see Version 6).
If delegated by the BSC the BTS has to perform Codec Configuration modification (if the Codec Type does not change) by the RATSCCH protocol. In this case the BTS has to inform the BSC after each successful modification. The BSC can suspend this BTS process at any time. It must be suspended by the BSC especially before handover and delegated after handover again.

NOTE 3: This version provides the fastest Codec Configuration modification on interface (5) with minimal signalling on interfaces (3) and (4) and minimal computational load within the BTS and BSC. It hides AMR internal Rate Control and Configuration problems for the BSC. The BTS and the BSC do not have to run the TFO Decision algorithm. This version is preferred in networks with different configurations in neighbouring cells and/or the TFO partners, where the configuration changes often during handovers, especially at the distant side.

Version 6, TRAU decided, BSC executed:
The TRAU has to run the TFO decision algorithm anyway. It sends the Optimal Codec Type and Codec Configuration down via the BTS to the BSC, or via a proprietary TRAU-BSC interface directly to the BSC. This eliminates the need to run the TFO Decision algorithm in the BTS and BSC again. The further procedures are as in version 1, BSC executed.

NOTE 4: The TFO Decision algorithm must only be implemented and updated in one unit, the TRAU. This guarantees consistency. The BTS and BSC functions for TFO remain relatively simple. This version is preferred in networks with identical or compatible configurations in neighbouring cells and similar TFO partners. It performs best if the configuration do not have to be changed during handovers on both sides. In the optimal case (full AMR set in all cells) the Codec Configuration need not to be modified at all and the TFO_BSC and TFO_BTS processes disappear.

This version is used for TFO in UMTS (see Annex D).

These different processes as well as the inter-processes dialogues are described in the following clauses in detail.