5.5 TrFO/TFO Codec Negotiation Harmonisation

23.1533GPPOut of band transcoder controlRelease 17Stage 2TS

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:

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 or EVS for the UMTS radio access.

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 or UMTS_EVS 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.

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]).

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’ (see 3GPP TS 28.062[10]). All the entries of the TFO Codec List (H.248) shall be used by the MGW as Local Codec List in the TFO in-band negotiation. For adaptive multi-rate 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’ (see 3GPP TS 28.062[10]) as received by the MGW during TFO in-band negotiations. All the 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. 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.