5.6 CN Node handling of Codec Types & Codec Modes
23.1533GPPOut of band transcoder controlRelease 17Stage 2TS
5.6.1 Signalling between UE and MSC
The default Codec Type for "R99 UMTS only" terminals is UMTS_AMR, the default Codec Type for all terminals supporting GSM and UMTS radio access is UMTS_AMR_2, (see [5] for the detailed description). The UMTS_AMR_2 is a superset of the UMTS_AMR. It behaves as a FR_AMR codec in the UL and as a UMTS_AMR codec in the DL. This allows all UMTS terminals, except R99 UMTS only terminals, to operate in TFO with GSM terminals. The UMTS_AMR_2 is fully compatible with R99 CN nodes (TC in MGW). In any multi-mode configuration the UMTS_AMR shall be treated as only TFO and TrFO compatible to itself, not to any other AMR codec Type, to avoid incompatibilities in TFO-TrFO-TFO interworking scenarios. In single mode configuration, UMTS_AMR and UMTS_AMR_2 are TFO and TrFO compatible, when both codec types use the same single rate ACS, (see [10]).
During call setup, a UE supporting Rel-4 or later releases will indicate to the MSC the codecs supported by the UE in the Supported Codecs List (DTAP) (see [2]). For the codecs in this Supported Codecs List (DTAP), no order of priority is defined.
If no Supported Codecs List (DTAP) is received and the UE is "UMTS only", then the MSC shall assume UMTS_AMR as supported Codec Type. If no Supported Codecs List (DTAP) is received, but the UE is "dual system", then the MSC shall assume UMTS_AMR_2 as the supported codec type. The MSC shall assume "dual system" support only if the UE indicates at least one GSM speech version in Octet 3a etc. of the Bearer Capability.
5.6.2 Node originating the OoBTC codec negotiation
The node originating the OoBTC codec negotiation shall implement the procedures described in Q.1902.4, clause 8.3.1 [6]. Additionally, the following applies:
In UTRAN, GERAN Iu mode or GERAN AoIP mode, when constructing the list of codecs (and configurations for AMR, AMR-WB or EVS codecs) for the Supported Codecs List (BICC), the MSC Server should take the codec types and codec configurations supported by the RNC or BSC into account (see clause 5.6.6 for UTRAN or GERAN Iu mode and clause 5.6.7 for GERAN AoIP mode). The MSC may include more than one Single codec element indicating the same codec type, but different configurations, in the Supported Codecs List (BICC) (see [5]).
NOTE 1: This may be necessary, e.g. if the RNC supports for an AMR codec different sets of codec modes, e.g., (a, b, c, d) and (e, f, g), which are not subsets of each other, and the RNC does not support combinations of these sets, e.g. (a, b, c, d, e, f, g).
For AMR codecs the originating CN node shall use the "Optimization Mode" parameter in the Single Codec information element in the Supported Codec List (BICC) (see [5]) to indicate whether or not other nodes may change the offered ACS.
EXAMPLE: An RNC implementing only the prioritised RABs for interoperability testing specified in [18] will support for the UMTS_AMR_2 codec e.g. the set of codec modes (12.2, 7.4, 5.9, 4.75), but none of its subsets containing 2 or 3 codec modes. If the MSC Server connected to this RNC includes the codec configuration (12.2, 7.4, 5.9, 4.75) in the Supported Codecs List (BICC), it will therefore set the OM parameter of the respective Single Codec information element to "Optimization of the ACS not supported".
For AMR codecs, if the OM is set to "Optimization of the ACS supported", the originating CN node shall indicate the maximum number of codec modes (MACS) that may be selected for the ACS during speech codec negotiation. This maximum number of codec modes may depend on optimization strategies applied by the originating CN node. The recommended value is 4 (see [10]).
For AMR-WB codecs the "Optimization Mode" is defined implicitly by the configuration parameter "Config-WB-Code" in the Single Codec information element (see [5]). If for a configuration the OM is set to "Optimization of the ACS supported", then the configuration may be changed to any other allowed configuration specified in [5].
NOTE 2: For the UMTS_EVS codec type, there is no "Optimization Mode" parameter included in the Single Codec information element or in the allowed configurations (see [5]). The "Optimization Mode" parameter is not used.
For the UMTS_EVS codec type, the originating CN node shall include at least configuration 0, 1 or 2 (see [5], table 5.7A-1) in the Single Codec information element, and it may also include configuration 3, as follows:
– if only one configuration is included, it shall be configuration 0, 1 or 2 in octet Config-EVS, and octet Config-EVS2 shall not be included; and
– if two configurations are included, configuration 3 shall be included in octet Config-EVS, and configuration 0, 1 or 2 shall be included in octet Config-EVS2.
In order to support interworking with 2G systems it is recommended that MGWs support 2G codecs (GSM_HR, GSM_FR, GSM_EFR, PDC_EFR, TDMA_EFR). In order to avoid modifications during handover between 2G and 3G systems the MSC nodes may give preference to a suitable 2G codec.
Whenever one or several TrFO links have been already established and initialised, the CN node (e.g. the serving CN in case of Call Hold scenarios, the visited CN node in case of Call Forwarding scenarios, etc.) initiating a subsequent codec negotiation on a new call leg or a mid-call codec negotiation on an established and initialised TrFO link, should give the already negotiated Selected Codec (BICC), including its ACS, highest preference to reduce the probability of having to perform a bearer re-establishment or UP re-initialisation of the already established and initialised TrFO links.
The creation of a "structured" Supported codec list shall be as described for SIP-I (see Clause 9.7.2).
NOTE 3: The auxiliary payload types do not apply to BICC.
5.6.3 Intermediate node
An intermediate node taking part in an OoBTC codec negotiation shall implement the procedures described in Q.1902.4, clause 8.3.2 [6]. Additionally, the following applies:
If a Single Codec information element for an AMR codec is included in the Supported Codecs List (BICC), with the OM set to "Optimization of the ACS not supported", the intermediate node shall delete the Single Codec information element
1) if the codec type is not supported; or
2) if one or more codec modes of the offered ACS are not supported.
If a Single Codec information element for an AMR codec is included in the Supported Codecs List (BICC), with the OM set to "Optimization of the ACS supported", the intermediate node
1) shall delete the Single Codec information element, if the codec type is not supported;
2) shall delete codec modes from the offered SCS and ACS, if they are not supported. If the last codec mode is deleted from the offered SCS, the Single Codec information element shall be deleted from the Supported Codecs List (BICC);
3) shall reduce MACS to a locally supported value, if necessary;
4) may change the ACS to a different ACS within the offered SCS; and
5) shall change the OM parameter from "Optimization of the ACS supported" to "not supported", if necessary.
NOTE: In interworking scenarios with TFO, step (iv) may prevent the establishment of an end-to-end tandem free and transcoder free connection; therefore, the intermediate node should not do this without a good reason.
During the processing of a Single Codec information element of an AMR codec with the OM set to "Optimization of the ACS supported", the intermediate node may replace the original Single Codec information element by two or more new Single Codec information elements, which can be derived from the original Single Codec information element by the steps (i) to (v) listed above.
If a Single Codec information element for an AMR-WB codec is included in the Supported Codecs List (BICC), the intermediate node shall
1) delete the Single Codec information element, if the codec type or codec configuration is not supported; or
1) replace a Single Codec information element with configuration 1, 3, or 5 (see [5], table 5.7-1) by a Single Codec information element with configuration 0 and, optionally, another Single Codec information element with configuration 2 or 4, if configuration 3 or 5 is not supported.
If a Single Codec information element for the UMTS_EVS codec type is included in the Supported Codecs List (BICC), the intermediate node shall:
1) delete the Single Codec information element, if the codec type or codec configuration is not supported;
2) replace the Single Codec information element with configuration 2 (see [5], table 5.7A-1) by the Single Codec information element with configuration 0 or 1, if configuration 2 is not supported;
3) replace the Single Codec information element with configuration 1 (see [5], table 5.7A-1) by the Single Codec information element with configuration 0, if configuration 1 is not supported; or
4) replace configuration 3 (see [5], table 5.7A-1) with configuration 0, 1 or 2 in octet Config-EVS of the Single Codec information element, and remove octet Config-EVS2 from the Single Codec information element, if configuration 3 is not supported.
5.6.4 Node terminating the OoBTC codec negotiation
The node terminating the OoBTC codec negotiation shall implement the procedures described in Q.1902.4, clause 8.3.3 [6]. Additionally, the following procedures apply:
The terminating node shall process the Supported Codecs List (BICC) as described for the intermediate node in clause 5.6.3.
In UTRAN, GERAN Iu mode or GERAN AoIP mode, when processing the codec types (and configurations for AMR, AMR-WB or EVS codecs) in the Supported Codecs List (BICC), the terminating MSC Server should take the codec types and codec configurations supported by the terminating RNC or BSC into account (see clause 5.6.6 for UTRAN or GERAN Iu mode and clause 5.6.7 for GERAN AoIP mode).
For the selection of the Selected Codec (BICC) from the Supported Codecs List (BICC), the following additional procedures apply:
If an adaptive multi-rate codec is selected, then the decision about the actual codec modes to be included in the selected ACS shall also be made by the terminating CN node. If the OM of the offered configuration is set to "Optimization of the ACS supported", the selected ACS may be different from the offered ACS, but it shall be a subset of the offered SCS and be consistent with MACS.
In order to provide harmonisation of out of band codec negotiation (for TrFO) and inband codec negotiation (for TFO) similar codec type and codec configuration selection mechanisms as those being defined for TFO should be applied for TrFO (see [10]).
NOTE 1: For TrFO codec negotiation, besides the speech quality additional aspects may be considered which are not applicable to TFO, e.g. the location of the transcoder that may need to be inserted or possible bandwidth savings in the core network.
If an adaptive multi-rate codec is selected, the terminating MSC Server shall exactly specify the ACS in the Selected Codec (BICC) and set the OM to "Optimization of the ACS not supported".
In the Available Codecs List (BICC), sent back to the originating node, the terminating MSC server may include more than one Single Codec information element indicating the same codec type, but different configurations. Single Codec information elements for adaptive multi-rate codecs may also be included with the OM set to "Optimization of the ACS supported" and the ACS being a subset of the SCS.
According to Q.1902.4, clause 8.3.3 [6], the terminating node shall include the Selected Codec (BICC) in the Available Codecs List (BICC). For AMR, AMR-WB and EVS codecs, the following applies:
If the Selected Codec (BICC) is an AMR codec, it shall be considered as included in the Available Codecs List (BICC), if the Available Codecs List (BICC) contains a Single Codec information element with the same codec type and:
– exactly the same configuration, i.e. the same ACS and the OM set to "Optimization of the ACS not supported"; or
– the Selected Codec (BICC) is consistent with the Single Codec information element, i.e. the selected ACS is a subset of the SCS of the Single Codec information element, the Number of codec modes in the selected ACS is less or equal to the MACS parameter of the Single Codec information element, and the OM of the Single Codec information element is set to "Optimization of the ACS supported".
If the Selected Codec (BICC) is an AMR-WB codec, it shall be considered as included in the Available Codecs List (BICC), if the Available Codecs List (BICC) contains a Single Codec information element with the same codec type and:
– exactly the same configuration, i.e. the same the configuration parameter "Config-WB-Code"; or
– any configuration for which the OM is set to "Optimization of the ACS supported".
If the Selected Codec (BICC) is an EVS codec, it shall be considered as included in the Available Codecs List (BICC), if the Available Codecs List (BICC) contains a Single Codec information element with the same codec type and exactly the same configuration, i.e. the same the configuration in parameter "Config-EVS-Code" or parameter "Config-EVS-Code 2".
Additionally, if the Selected Codec (BICC) is an EVS codec, the terminating MSC Server shall specify exactly one configuration as per the rules specified in [5], table 5.7A-3, and indicate this configuration in octet Config-EVS of the Selected Codec (BICC).
The creation of a "structured" Available codec list shall be as described for SIP-I (see Clause 9.7.3).
NOTE 2: The auxiliary payload types do not apply to BICC.
5.6.5 Signalling between server and MGW
According to Q.1902.4, clause 8.3 [6], during the OoBTC codec negotiation a server can provide its associated MGW with the preferred codec from the Supported Codecs List (BICC), and as a result of the negotiation the server will provide its associated MGW with the Selected Codec (BICC). The information is sent via the Mc interface as Codec (H.248).
If the Codec (H.248) is an adaptive multi-rate codec, the server shall exactly specify the ACS in the respective Single Codec information element and set the OM to "Optimization of the ACS not supported", both for the preferred codec and the Selected Codec (BICC).
For the Single Codec information elements of adaptive multi-rate codecs in the TFO Codec List (H.248), the OM may be set to "Optimization of the ACS supported", and the ACS may be a subset of the SCS. This applies also to the first entry in the TFO Codec List (H.248), the Local Used Codec.
NOTE: In some scenarios the flexible configuration of the Local Used Codec may be used for a faster TFO establishment (see [10]).
5.6.6 Signalling between MSC and UTRAN or GERAN Iu-mode
The MSC Server shall know the codec types and codec configurations supported by the RNC. The MSC Server shall select only from these configurations for the RAB assignment.
For GERAN Iu-mode the MSC Server receives a list of codec types (for definition see [15]) as well as the supported codec modes (for an adaptive multi-rate codec type) within the RANAP INITIAL UE MESSAGE, indicating the GERAN capabilities, which will be available at the RAB establishment procedure. With this information the MSC Server shall delete those codec types and codec modes (for an adaptive multi-rate codec type) from the Supported Codecs List (BICC) which are not supported by the GERAN, taking into account the GERAN classmark and the MS capabilities. This possibly reduced list shall be used by the MSC Server during the codec negotiation procedure. The value of the maximum number of supported codec modes shall be set to 4 (see [10]).
When the MSC node requests a RAB assignment the Subflow Combinations provided shall either all be initialised by the RNC or all rejected with appropriate cause code.
The MSC shall always assume "Discontinuous Transmission (DTX)" as mandatory and shall define "SID" SDUs in addition to the negotiated speech codec modes. This is because for TrFO the RAB requested by one RNC must match that requested by the peer RNC – they are effectively the same RAB. If one MSC requires DTX support then the RAB requested by the far end MSC must also support DTX (even if it is not desired by that MSC). As no Out Of Band negotiation for DTX is supported nor DTX control to the UE, DTX shall be mandatory for TrFO connections.
Once an adaptive multi-rate codec with an ACS has been selected as Selected Codec (BICC), the MSCs shall indicate in the RAB Assignment parameters [3] for the Guaranteed Bitrate the lowest speech mode in the ACS (assuming any SID frames are smaller than the SDU for lowest speech mode, otherwise the Guaranteed Bitrate shall be set to the largest SID frame). The Maximum bitrate shall correspond to the highest mode in the ACS.
5.6.7 Signalling between MSC and GERAN AoIP-mode
In both mobile originating and mobile terminating calls the MSC Server receives the Supported Codecs List (BSSMAP) – "BSC-SCL" – containing a list of Codec types (for definition see 3GPP TS 48.008 [15]) as well as the codec configurations (for adaptive multi-rate codec types) within the BSSMAP COMPLETE LAYER 3 INFORMATION message, indicating the temporary GERAN capabilities for this call in this cell.
The Codec Types within this BSC-SCL can be viewed as divided into three different A-Interface types:
1) Codecs with PCM only on the A-Interface – transcoding always occurs inside the BSS.
2) Codecs with transcoding inside the BSS, but supported with TFO on the A-Interface.
3) Codecs supported with "Full IP" for the A-Interface – no transcoding inside the BSS.
These are described in detail in 3GPP TS 48.008 [15], clause 3.2.2.103.
These A-Interface types may then be used by the MSC to create a structured "Supported Codec List", with Direct Codecs and Indirect Codecs, as described in clause 9.7.2.
When creating the Supported Codecs List (BICC or SIP-I), only codecs supported in GERAN with either "Full IP" or TFO shall be included in the "direct" part of the Supported Codecs List (BICC or SIP-I), if also the MS and the MGW support them in this way. Codec types and codec configurations not supported in GERAN (with either Full IP or TFO) or MS, but supported by the MGW with transcoding, may be negotiated as "indirect" codec types.
This potentially reduced direct codec list and potentially increased indirect codec list shall be used by the MSC Server during the codec negotiation procedure.
During the Assignment procedure, the MSC server shall include the MSC-Preferred-Codec-List (BSSMAP) as defined in 3GPP TS 48.008 [15] clause 3.2.2.103.