11 TFO Decision Algorithm
28.0623GPPInband Tandem Free Operation (TFO) of speech codecsService descriptionStage 3TS
The TFO decision algorithm defines the processes invoked in both transcoders in order to examine the possibility for TFO establishment. Codec Types are in general only compatible to itself.
All members of the AMR-NB Codec Type family, except UMTS_AMR, are compatible, when both Codec Types use compatible multi-mode ACSs. In any multi-mode configuration the UMTS_AMR shall be regarded as only compatible to itself, not to any other AMR-NB Codec Type, to avoid incompatibilities in TFO-TrFO-TFO interworking scenarios. In single mode configuration, UMTS_AMR and UMTS_AMR_2 are compatible, when both Codec Types use the same single rate ACS. The UMTS_AMR_2 is the preferred AMR-NB Codec Type for 3G systems.
All members of the AMR-WB Codec Type family are compatible, when both codec types use compatible multi-mode ACSs.
For the AMR Codec Type family the following tables 11-1 and 11-2 illustrate the compatible combinations (Table 11-1 for AMR-NB codec types, table 11-2 for AMR-WB codec types):
Table 11-1: Compatibility of AMR-NB Codec Types
|
distant → ↓ local |
UMTS_AMR_2 |
UMTS_AMR |
FR_AMR |
HR_AMR |
OHR_AMR |
|
UMTS_AMR_2 |
compatible |
compatible (Note) |
compatible |
compatible |
compatible |
|
UMTS_AMR |
compatible (Note) |
compatible |
– |
– |
– |
|
FR_AMR |
compatible |
– |
compatible |
compatible |
compatible |
|
HR_AMR |
compatible |
– |
compatible |
compatible |
compatible |
|
OHR_AMR |
compatible |
– |
compatible |
compatible |
compatible |
Note: only for single mode ACSs.
Table 11-2 Compatibility of AMR-WB Codec Types
|
distant → ↓ local |
FR_AMR-WB |
UMTS_AMR-WB |
OFR_AMR-WB |
OHR_AMR-WB |
|
FR_AMR-WB |
compatible |
compatible |
compatible |
compatible |
|
UMTS_AMR-WB |
compatible |
compatible |
compatible |
compatible |
|
OFR_AMR-WB |
compatible |
compatible |
compatible |
compatible |
|
OHR_AMR-WB |
compatible |
compatible |
compatible |
compatible |
11.1 Main TFO Decision Procedure
The main TFO decision procedure is depicted in figure 11.1-1.
Figure 11.1-1: Main TFO Decision Algorithm
11.2 TFO Decision Algorithm for AMR codec types
The TFO Decision Algorithm for AMR codec types defines the processes that are invoked in order to examine the possibility for a TFO establishment if both radio legs use compatible AMR codec types.
11.2.1 Principles
In order to yield high speech quality the following items are underlying principles of the TFO decision algorithm for AMR codec types:
– Avoid immediate TFO establishment with a following codec optimisation that has to interrupt the TFO connection.
– Go into immediate TFO if this is possible with a good configuration, otherwise do codec optimisation.
– Only do codec mode optimisation if the ongoing TFO connection is established on a contiguous subset of the ACS and if this ongoing TFO connection need not be interrupted.
11.2.2 Available Information at Call Set-up
After the exchange of TFO_REQ and TFO_ACK messages the following information is available at the transcoders on both sides:
– Local / distant codec type (FR_AMR, HR_AMR, UMTS_AMR, UMTS_AMR_2, OHR_AMR, FR_AMR-WB, UMTS_AMR-WB, OHR_AMR-WB, OFR_AMR-WB)
– Local / distant supported codec set (LSCS / DSCS)
– Local / distant ACS (LACS / DACS)
– Local / distant MACS
– Local / distant ACS optimisation mode (OM)
– Local / distant version number (Ver)
With this information the following can be calculated:
– Common ACS (CACS)
– Common supported codec set (CSCS)
– Common MACS (CMACS)
– Optimised ACS (OACS)
Furthermore, additional information on supported codecs may become available when the Codec List is received. There are several possibilities for receiving this information: 1) by TFO_REQ and TFO_ACK messages including optional Extension_Blocks, 2) by TFO_REQ_L and TFO_ACK_L messages, and 3) by Configuration Frames (Con_Req, Con_Ack). In any case, the following information is available for each supported codec in the Codec List:
– Local / distant supported codec type
– Local / distant supported codec set (LSCS / DSCS)
– Local / distant MACS
In the case that Generic Configuration Frames are used to transmit the Codec List the following information is also available for each codec in the Codec List:
– Local / distant intended ACS (LACS/ DACS)
– Local / distant ACS optimisation mode (OM)
In all other cases (no Generic Configuration Frames are used) the OM bit shall be assumed to be set ("ACS optimisation allowed").
With this information the following can be calculated for each compatible codec combination in the local and distant Codec List:
– Common supported codec set (CSCS)
– Common MACS (CMACS)
– Optimised ACS (OACS)
11.2.3 Void
11.2.4 Flowchart for AMR-NB TFO Decision
Figure 11.2.4-1: Flowchart for AMR-NB TFO Establishment at Call Set-Up
Figure 11.2.4-2: Flowchart for AMR-WB TFO Establishment at Call Set-Up
11.2.5 Annotations to the Flowcharts
– LACS == DACS:
Establish immediate TFO if the local and distant ACS are identical.
Example: Enable immediate TFO establishment within one operator’s homogenous network. The operator’s choice is always acceptable and needs no optimisation.
– FR – HR Matching
The rules for FR – HR – Matching are stated in clause 12.6.
Goal: Enable immediate TFO between 3G channels and 2G FR and 2G HR channels.
– FR – HR – Optimisation
The rules for FR – HR – Optimisation are stated in clause 11.4.
– Calculate OACS and IACS:
The calculation of the OACS is described in clause 12.
The Immediate ACS (IACS) is given by the common ACS (CACS) if it is contiguous.
– OACS acceptable:
The acceptability rules for the OACS are stated in clause 12.5.
– IACS == OACS
If the immediate ACS is already optimal, establish immediate TFO.
– IACS subset of OACS:
Immediate TFO is established on a contiguous subset of the OACS. Afterwards, a codec mode optimisation is performed without interrupting the TFO connection.
– Change ACS to OACS
If immediate TFO cannot be established, both sides must change their ACS to the OACS in order to enable TFO. If one side doesn’t support an ACS change (ACS Optimisation Mode), the OACS determination rules ensure that the OACS is a contiguous subset of the fix ACS. So a TFO connection can be established without the need for an ACS change on that side.
– Codec Mismatch Resolution
A TFO connection with the currently used AMR codec types will not be possible, but the remaining codec types have to be investigated.
11.3 Immediate TFO Establishment
Immediate TFO establishment shall take place if
– both radio legs use the same codec type that is different from an AMR codec type; or
– the local ACS is equal to the distant ACS in the case of two compatible AMR codec types; or
– the CACS is equal to the OACS and the CACS fulfils the contiguity rule in the case of two compatible AMR codec types; or
– the rules for FR – HR – matching are fulfilled in the case of two compatible AMR-NB codec types; or
– the CACS is a contiguous subset of the OACS in the case of two compatible AMR codec types and Codec Mode Optimisation is supported and will be done after immediate TFO establishment.
If both radio legs use the same codec type that is different from an AMR codec type, immediate TFO shall be established on this common codec type. If both radio legs use compatible AMR codec types and immediate TFO can be established, each side keeps its own AMR codec type (e. g. FR_AMR, HR_AMR, UMTS_AMR, UMTS_AMR_2) and Active Codec Set (ACS).
If immediate TFO is possible on a currently used codec type, but also on a supported codec type with a higher preverence level (see 11.6.2), then TFO shall not be started on the used codec type, but only after switching to the preferred codec. For details on this Immediate Codec Type Optimisation see 11.7.
11.4 FR – HR – Optimisation (only for AMR-NB)
FR – HR – Optimisation takes place after immediate TFO establishment in the case of FR – HR – Matching. The FR_AMR-side adopts the ACS of the HR_AMR-side, if this ACS is supported and the optimisation mode allows an ACS change.
This ACS change can be done without interrupting the TFO connection that is established on a contiguous subset.
11.5 Codec Mode Optimisation
After an immediate TFO establishment with compatible AMR codec types, a codec mode optimisation shall be invoked if the optimisation can be done without interrupting the TFO connection, i.e. without degradation of speech quality. Codec Mode Optimisation takes place in the following situations:
– After immediate TFO establishment on a IACS that is a contiguous subset of the OACS.
11.6 Codec Type Optimisation and Codec Mismatch Resolution
The objective of the Codec Mismatch Resolution and the Codec Type Optimisation is to find the optimised TFO codec type and configuration for a TFO connection. Codec Mismatch Resolution is invoked if a TFO establishment is not possible on the currently used codec types. Codec Type Optimisation may happen while a TFO connection is ongoing and the capabilities of one radio leg have changed (e. g. after a hand-over, other reasons).
Codec Mismatch Resolution and Codec Type Optimisation are optional features. If one radio leg doesn’t support these features, the codec list sent in the TFO_REQ_L and TFO_ACK_L messages (or Con_Req and Con_Ack frames) shall be restricted to the local used codec. If supported, the Codec Type Mismatch Resolution or the Codec Type Optimisation shall be performed every time a new codec list is sent or received by TFO_REQ_L or TFO_ACK_L (or Con_Req and Con_Ack frames) messages.
The determination of the local codec list (list of all codec types supported by the local radio leg, consisting of the local UE and the local RAN) is outside the scope of the present document. Similarly, the determination of the attributes of all locally supported codec types (e.g. LSCS for AMR codec types) is also outside the scope of the present document. Only codec types that are real alternatives, considering all resources (UE, RAN, TC, radio interface, cell capacity, interference), shall be reported within the local codec list. Only codec type Attributes that can be considered shall be indicated with the codec list as well. This means that if a TFO configuration is not desirable, it should not be listed in the TFO_REQ_L or TFO_ACK_L messages (or Con_Req and Con_Ack frames).
11.6.1 Procedure
1) The transcoders shall exchange their lists of supported codec types (codec list) and their associated attributes. This is done either by the exchange of TFO_REQ_L and/or TFO_ACK_L messages or Con_Req and Con_Ack frames.
2) Each side shall identify all candidate TFO configurations involving compatible codec types supported by both radio legs.
3) Each side shall calculate the OACS in the case of an AMR TFO candidate. If the OACS is not acceptable, this candidate shall be removed from the list of candidate TFO configurations.
4) The candidate TFO configuration with the highest preference level shall define the optimised codec type and the optimised codec configuration.
5) Each side shall switch its operation to the optimised codec type and the optimised codec configuration. If no acceptable TFO candidate was found, TFO is not possible.
11.6.2 Preference List of TFO candidates
The preference list of TFO candidates orders all possible TFO combinations according to the speech quality they provide.
Table 11.6.2-1: Codec Type Combination Preference List, Part 1
|
distant → |
OFR_AMR-WB |
UMTS_AMR-WB |
FR_AMR-WB |
OHR_AMR-WB |
|
OFR_AMR-WB |
1 |
2 |
4 |
7 |
|
UMTS_AMR-WB |
symmetric |
3 |
5 |
8 |
|
FR_AMR-WB |
symmetric |
symmetric |
6 |
9 |
|
OHR_AMR-WB |
symmetric |
symmetric |
symmetric |
10 |
For AMR-WB the preference is determined by the OACS: A combination with the highest mode in the OACS has preference. If the highest mode in OACSs for at least two combinations is identical, then the preference level as given in Table 11.6.2-1 shall decide.
Examples:
The configuration (OFR_AMR-WB, UMTS_AMR-WB, OACS={6,60, 8,85, 12,65, 23,85}) is preferred to (OFR_AMR-WB, OFR_AMR-WB, OACS={6,60, 8,85, 12,65, 15,85}).
The configuration (OFR_AMR-WB, OFR_AMR-WB, OACS={6,60, 8,85, 12,65}) is preferred to (OFR_AMR-WB, UMTS_AMR-WB, OACS={6,60, 8,85, 12,65}).
Table 11.6.2-2 Codec Type Combination Preference List, Part 2
|
distant → |
UMTS_AMR_2 |
FR_AMR |
UMTS_AMR |
OHR_AMR |
HR_AMR |
|
UMTS_AMR_2 |
11 |
12 |
15 (Note) |
17 |
20 |
|
FR_AMR |
symmetric |
13 |
Not compatible |
18 |
21 |
|
UMTS_AMR |
symmetric |
Not compatible |
14 |
Not compatible |
Not compatible |
|
OHR_AMR |
symmetric |
symmetric |
Not compatible |
19 |
22 |
|
HR_AMR |
symmetric |
symmetric |
Not compatible |
symmetric |
23 |
Note: only for single mode ACSs
Table 11.6.2-3 Codec Type Combination Preference List, Part 3
|
distant → |
GSM_EFR |
GSM_FR |
GSM_HR |
|
GSM_EFR |
16 |
Not compatible |
Not compatible |
|
GSM_FR |
Not compatible |
24 |
Not compatible |
|
GSM_HR |
Not compatible |
Not compatible |
25 |
All other possible codec type combinations not listed in these table 11.6.2.3-1/2/3 are not compatible.
The codec type FR_AMR-WB is preferred to the AMR-NB codec types, because it still provides significantly better speech quality.
The two equivalent combinations FR_AMR-WB UMTS_AMR-WB and UMTS_AMR-WB FR_AMR-WB should not exist in parallel, because these two AMR-WB codec types are not offered by one side simultaneously.
The speech quality of some AMR-WB codec type combinations involving FR_AMR-WB, UMTS_AMR-WB and OHR_AMR-WB are very similar. Therefore within category 1 the OACSs of the possible combinations are evaluated. For details on this evaluation see clause 12.3.2.2 .
The codec type UMTS_AMR_2 is the most preferred AMR-NB codec type, because it is compatible with all other AMR codec types.
The codec type FR_AMR is preferred to UMTS_AMR because UMTS_AMR is not compatible with FR_AMR and HR_AMR.
If the two equivalent AMR-NB combinations like FR_AMR HR_AMR and HR_AMR FR_AMR or UMTS_AMR_2 HR_AMR and HR_AMR UMTS_AMR_2 etc. exist in parallel, then they shall be ranked according to the following rules:
1) The combination with the highest number of modes shall be selected.
2) If they have the same number of modes, then the combination with the widest spread shall be selected. The spread is the difference between the highest and the lowest mode indexes.
3) If the spreads are identical, then the combination with the highest mode in the OACS shall be selected.
4) If the highest modes are identical, repeat 3 with the second highest mode. If the second highest are identical, then repeat 3 with the third highest, etc.
11.7 Immediate Codec Type Optimisation
The Codec Type Optimisation described in the previous section is performed after the exchange of TFO_REQ_L and TFO_ACK_L messages. Because these messages are exchanged in a late phase of the protocol and may require significant time for transmission, the optimisation may be delayed by a significant amount of time. Furthermore, if TFO was already established before optimisation, a switch to the preferred codec type may disturb the ongoing speech call. To avoid these drawbacks, the codec type optimisation can also be performed immediately during TFO establishment, i.e., in a very early stage of the TFO protocol. This option for TFO establishment is termed "Immediate Codec Type Optimisation" and is explained in the following.
The objective of the Immediate Codec Type Optimisation is to switch the codec type at the local and/or the distant side if this results in a preferred TFO configuration. The required information to decide if Immediate Codec Type Optimization shall be performed is included in the TFO_REQ and TFO_ACK messages by means of the TFO_Version Extension_Block (see Clause 7.4.5). This information is equivalent to the Codec_List included in TFO_REQ_L and TFO_ACK_L messages, however, signalled in a different way. If a preferred TFO configuration becomes possible by changing the local and/or the distant codec type, both sides remain in the Contact state as long as the Immediate Codec Type Optimisation is being performed, i.e., until the local and/or the distant side has/have changed the codec type. After the switch, the TFO protocol continues as usual.
Immediate Codec Type Optimisation becomes only effective in TFO version 5 or higher. If either the local or the distant side is using a lower version, no Immediate Codec Type Optimisation is used. Hence, the protocol is compatible with older versions that do not include Immediate Codec Type Optimisation. Note that a switch to a different codec type is always possible using the normal Codec Type Optimisation in the Mismatch state.
The procedure and preference list used for finding the optimal configuration is exactly identical to Clause 11.6. The only difference is that the required information (active codec, codec list, attributes, …) is obtained from TFO_REQ and TFO_ACK messages instead of TFO_REQ_L and TFO_ACK_L messages. Furthermore, the change of codec type is performed in the Contact state instead of the Mismatch or Operation state.
11.8 TFO Decision Table for AMR-WB
For AMR-WB only a limited set of configurations is allowed. Table 12.8-1.gives the effective ACS for all combinations of these allowed configurations.
Table 11.8-1: Effective ACS for AMR-WB TFO
|
Local scenario Distant scenario |
0: 12,65 OM=F |
1: OM=A |
2: 15,85 OM=F |
3: 15,85 OM=A |
4: 12,65 OM=F |
5: 12,65 OM=A |
|
0 |
A |
A |
A |
A |
A |
A |
|
1 |
Symmetrical |
A |
B |
B |
C |
C |
|
2 |
Symmetrical |
Symmetrical |
B |
B |
A |
B |
|
3 |
Symmetrical |
Symmetrical |
Symmetrical |
B |
C |
C |
|
4 |
Symmetrical |
Symmetrical |
Symmetrical |
Symmetrical |
C |
C |
|
5 |
Symmetrical |
Symmetrical |
Symmetrical |
Symmetrical |
Symmetrical |
C |
Immediate TFO (see 11.3) is always possible for each combination of the allowed configurations. In some cases a Codec Mode Optimisation (see 11.5) is invoked after TFO establishment. For these cases the changing configuration is also specified in the table 12.8-1. Remark: For all combinations where one side changes the configuration, immediate TFO is established on ACS A.
All final (and immediate) ACSs as listed in table 12.8-1 are contiguous and acceptable, by design. No check – as for an AMR-NB OACS (see clause 12.4, 12.5 and 12.7) – is needed.