11 Interworking between MGW Terminations
26.4543GPPCodec for Enhanced Voice Services (EVS)Interface to Iu, Uu, Nb and MbRelease 17TS
11.1 Interworking between different EVS Configurations
11.1.0 General
It may happen, e.g. to combat cell overload, that the RNC selects a smaller EVS Configuration for Uu, than the EVS Configuration for Iu, which the MSC has selected, see also clause 7.
Example: The local MSC selects during the Codec Negotiation with the remote side the EVS Configuration EVS (Set 2), which is equivalent to the SDP description EVS (br=5.9-24.4, bw=nb-fb). The RAB Assignment Request towards the local RNC contains the corresponding rates, see Table 6.2-2. The RNC, however, decides to setup a set of TFCs on the Uu interface that is corresponding to EVS (Set 1), equivalent to the SDP description EVS (br=5.9-13.2, bw=nb-swb). The UE determines the EVS Configuration for UE based on the set of TFCs. When the RNC select a smaller transport channel for Uu, then this is unknown to the MSC and MGW and to the UE. The RNC may also change the transport channel for Uu (and by that the EVS Configuration for UE) during the call without notice to the MSC or MGW. Only indirectly, when by UL Iu_Init and/or UL RC Proc the maximum rate in DL is set, the MGW gets some information on limitations of the Uu interface in DL, see clause 6.
In such a situation, the Iu-terminating MGW may send DL EVS-CMRs that are outside the EVS Configuration for UE. The UE maps these EVS-CMRs into its known EVS Configuration for UE, see clause 7. Example: The Iu-terminating MGW may send DL EVS-CMR (br=24.4; bw=fb) and the UE needs to map this to DL EVS-CMR (br=13.2; bw=swb).
A similar situation may happen within the IM-MGW between the CS-internal interface and the Mb interface: different EVS Configurations may be used. The EVS Configuration for Mb may be often bigger than inside the CS network.
Example: After SRVCC, the IMS Selected Codec (applied still on Mb) may be different, but TrFO-compatible to the Target RAN Codec (applied on the CS channel of the IM-MGW). The Target RAN Codec may be EVS (Set 3), equivalent to the SDP description EVS (br=9.6-13.2, bw=swb), while the IMS Selected Codec on Mb may be equivalent to EVS (br=9.6-24.4; bw=swb). The IMS-side may send CMR (br=24.4; bw=swb) and the IM-MGW maps this to EVS-CMR (br=13.2; bw=swb).
The same situation may happen between CS-internal interfaces (Iu, Nb, A): different EVS Configurations may be used on both sides of the MGW. These scenarios occur mainly after handover, but they are not excluded for call setup.
In all such cases the EVS-CMR, coming into one termination of the MGW (or IM-MGW) may have to be mapped into the EVS Configuration on the outgoing termination. Without this mapping, the receiver of an EVS-CMR may ignore the EVS-CMR, because it is outside its own EVS Configuration, see TS 26.445, clause A.2.2.1.1, CMR byte. The only (known) exception is the mapping onto the Iu Interface and the handling by the 3G-UE, because, as described above, the 3G-UE may get EVS-CMRs that fit to the EVS Configuration for Iu, but are outside the EVS Configuration for UE.
TS 26.103 [20] specifies three "EVS Bottom Up Configurations", EVS (Set 0), EVS (Set 1) and EVS (Set 2) and one "Single audio band Configuration", EVS (Set 3) for the 3G-CS network.
The Interworking rules are defined in the following clauses.
11.1.1 Interworking between EVS Bottom Up Configurations
If the EVS Configurations on both sides of the MGW are identical, then no mapping is necessary.
If the EVS Bottom up Configuration on one side (e.g. Set 2 on Nb or Mb), is bigger than the EVS Bottom up Configuration on the other side (e.g. Set 1 on Iu), then the following rules apply:
– If the EVS-CMR, which has to be sent on a certain outgoing termination, is within the EVS Configuration of this outgoing termination, then no mapping is required.
– If the EVS-CMR is outside the EVS Configuration of the outgoing termination, then the EVS-CMR shall first be reduced in its bit rate request, until it fits to the outgoing Configuration.
Example: EVS-CMR (br=24.4; bw=swb) ==> EVS-CMR (br=13.2; bw=swb).
– The maximum audio bandwidth request should be kept, unless the resulting bit rate request does not support it, in which case the next smaller maximum audio bandwidth shall be applied that fits to the requested maximum bit rate. Example: EVS-CMR (br=24.4; bw=fb) ==> EVS-CMR (br=13.2; bw=swb).
– The major operation mode shall never be changed by such a mapping, i.e. EVS-CMR for an EVS primary mode shall remain and an EVS-CMR for an EVS AMR-WB IO mode shall remain. If necessary, the next lower bit rate shall be used that fit to the outgoing Configuration without changing the major operation mode.
Note, however, that a MGW has the right to modify the request for a major operation mode, e.g. in case of handover.
– An EVS-CMR request for the EVS-CA mode of operation, not supported by the outgoing Configuration, shall be mapped to the next fitting EVS primary mode.
Example: EVS-CMR (br=13.2; bw=swb; CA=on) ==> EVS-CMR (br=8; bw=wb).
Note that it is in principle possible that the EVS Configuration for Mb consists in fact of two different EVS Configurations, one in direction CS=>IMS and one in direction CS<=IMS. In such a case, TrFO is possible, if both EVS Configurations on Mb are Bottom up Configurations.
11.1.2 Interworking between Single Band Configurations
If the EVS Configurations on both sides of the MGW are identical, then no mapping is necessary.
If the Single (audio) Band Configuration on the Mb interface is bigger than the EVS Configuration EVS (Set 3), but TrFO-compatible, i.e. it uses the same bw=swb and has all lower rates in common with EVS (Set 3), then the following rules apply:
– If the EVS-CMR, which has to be sent on a certain outgoing termination, is within the EVS Configuration of this outgoing termination, then no mapping is required.
– If the EVS-CMR is outside the EVS Configuration of the outgoing termination, then the EVS-CMR shall first be reduced in its bit rate request, until it fits to the outgoing Configuration.
Example: EVS-CMR (br=24.4; bw=swb) ==> EVS-CMR (br=13.2; bw=swb).
– The major operation mode shall never be changed by such a mapping, i.e. EVS-CMR for an EVS primary mode shall remain and an EVS-CMR for an EVS AMR-WB IO mode shall remain. If necessary, the next lower bit rate shall be used that fit to the outgoing Configuration without changing the major operation mode.
Note, however, that a MGW has the right to modify the request for a major operation mode, e.g. in case of handover.
Note that it is in principle possible that the EVS Configuration for Mb consists in fact of two different EVS Configurations, one in direction CS=>IMS and one in direction CS<=IMS. In such a case, TrFO is possible, if both EVS Configurations on Mb are of the same Single (audio) Band "family" of Configurations.
11.1.3 Interworking between Bottom Up and Single Band Configurations
If the EVS Configuration on one termination is a Bottom up Configuration (Set 0, Set 1, Set 2 or a bigger one) and
if the EVS Configuration on the other terminating is a Single (audio) Band Configuration (e.g. Set 3 or a bigger one),
then transcoding is required, even if sometimes the used incoming EVS mode would fit to the outgoing Configuration.
In such a transcoding case, the incoming EVS-CMRs are terminated inside the MGW. New EVS-CMRs are generated by the MGW and sent on the outgoing terminations. The two incoming and the two outgoing EVS mode control loops are independent from each other.
11.1.4 Interworking between Bottom Up and Non-Bottom Up Configurations
A Non-Bottom Up Configuration does not include the lowest bit rates and is not TrFO-compatible to any Bottom Up Configuration.
If the EVS Configuration on one termination is a Bottom up Configuration and the EVS Configuration on the other terminating is a Non-Bottom Up Configuration, then transcoding is required.
In such a transcoding case, the MGW terminates the incoming EVS-CMRs. The MGW generates new EVS-CMRs and sends them on the outgoing terminations. The two incoming and the two outgoing EVS mode control loops are independent from each other.
11.2 Handling of Speech and SID payload
11.2.1 Handling of Speech and SID payload during the call
If the MGW operates in TrFO mode, i.e. the EVS Configurations on both terminations are TrFO-compatible, then incoming Speech or SID payloads are not modified, but in some scenarios repacked. Important to note is that on all CS-channels (Iu and Nb) each packet transports exactly one Speech, SID or CMR-Only payload. On Mb this is not always the case.
The MGW shall repack the EVS-CMR in an incoming Speech or SID packet on Iu or Nb together with the Speech or SID payload into the same outgoing Speech or SID packet on Nb or Iu. If no Speech or SID data are present in the incoming packet, then the MGW repacks only the EVS-CMR.
11.2.1.1 Repacking between Iu and Nb (BICC)
The packing for EVS primary modes and EVS AMR-WB IO modes on Iu and Nb (BICC) are identical. The Speech and SID data are copied bit by bit in both directions.
The 7-bit UL EVS-CMR (Iu) of the UL PDU 0 packet on Iu is extracted, potentially combined with an UL RC Proc request, may be filtered, modified by the MGW and shall be mapped to the EVS Configuration for the Nb interface.
The 7-bit DL EVS-CMR (Nb) is extracted, may be filtered, modified by the MGW and shall be mapped to the EVS Configuration for the Iu interface.
11.2.1.2 Repacking between Iu and Nb (SIP-I)
11.2.1.2.1 General
The packing on Nb (SIP-I) is different and requires more attention.
11.2.1.2.2 Repacking from Iu to Nb (SIP-I)
The 7-bit UL EVS-CMR (Iu) of the UL PDU Type 0 packet on Iu is extracted, potentially combined with UL RC Proc requests, it may be filtered and modified and shall be mapped to the EVS Configuration of the Nb interface and then complemented with the CMR-Header bit (1). This CMR octet is then placed as first octet in the RTP payload for the Nb (SIP-I) interface.
The MGW creates the Table of Contents octet (ToC) according to TS 26.445 [12] and places this after the CMR octet.
Finally, the MGW copies the Speech or SID data bit by bit, from the PDU Type 0 packet to the RTP packet, without changing the sequence.
11.2.1.2.3 Repacking from Nb (SIP-I) to Iu
The MGW extracts first the Speech and SID data from the received RTP packet and copies these bit by bit, without changing the sequence, into the DL PDU Type 0 packet for Iu.
The ToC is verified and then ignored.
The 7-bit DL EVS-CMR (Nb) of the received CMR octet is extracted, it may be filtered and modified by the MGW and shall be mapped to the EVS Configuration for Iu. This DL EVS-CMR (Iu) is then placed after the Speech or SID payload, maybe complemented with padding bits.
11.2.1.3 Repacking between Nb (BICC) and Mb
11.2.1.3.1 General
This repacking is similar to the repacking between Iu and Nb (SIP-I), because Nb (SIP-I) and Mb are based on TS 26.445 [12]. Differences arise, because the freedom on Mb is far wider than on Nb (SIP-I). On Mb several Speech or SID frames may be included in one RTP packet, RTP redundancy may be added, the CMR may be omitted or sent only on demand or rate and mode control may be performed by RTCP-APP, see TS 26.114 [21].
11.2.1.3.2 Repacking from Nb (BICC) to Mb with one frame per RTP packet
The 7-bit EVS-CMR (Nb) of the PDU Type 0 packet on Nb is extracted, it may be filtered, modified and shall be mapped to the EVS Configuration of the Mb interface and then complemented with the CMR-Header bit (1). This CMR octet is placed as first octet in the RTP payload for the Mb interface.
The IM-MGW creates the Table of Contents octet (ToC) according to TS 26.445 [12] and places this after the CMR octet. Finally, the IM-MGW copies the Speech or SID data bit by bit, from the PDU Type 0 packet to the RTP packet, without changing the sequence. The EVS-CMR in an incoming Speech or SID packet may be filtered and modified by the MGW and shall be mapped together with the same Speech or SID payload to the outgoing RTP packet.
11.2.1.3.3 Repacking from Mb with one frame per RTP packet to Nb (BICC)
The IM-MGW extracts first the Speech and SID data from the received RTP packet and copies these bit by bit, without changing the sequence, into the DL PDU Type 0 packet for Nb (BICC).
The ToC is verified and then ignored.
The 7-bit DL EVS-CMR (Mb) of the received CMR octet is extracted, it may be filtered and modified by the MGW and shall be mapped to the EVS Configuration for Nb. This DL EVS-CMR (Nb) is then placed after the Speech or SID payload, maybe complemented with padding bits.
11.2.2 Handling of Speech and SID payload at call setup
NOTE: This subclause is for further study.
11.3 Filtering and Modification of EVS-CMR by the MGW
11.3.0 General
If applicable, due to operator policy, the MGW (or IM-MGW) may filter and modify the received EVS-CMR in both speech path directions.
"Filter" in this context means for example: according to operator policy the Iu-terminating MGW may disallow certain UL EVS CMR, sent by the 3G-UE. This leads to that the UL EVS CMR is discarded and replaced completely.
"Modify" in this context means the MGW may replace the incoming EVS-CMR by a different EVS-CMR, e.g. due to Maximum Mode Control or according to operator policy or if needed in exceptional cases, e.g. due to handover.
11.3.1 Maximum Mode Control for EVS in general
If the MGW is in TrFO mode, then per default the received EVS-CMR is forwarded unfiltered and unmodified, just mapped to the outgoing Configuration (that is indispensable, of course), see above in clause 11.1.0 General.
It is, however, allowed that the MGW observes the incoming stream of speech frames or packets and determines, if or if not the active EVS mode is (still) suitable, or if a lower EVS mode (lower bit rate) is more appropriate. In such a case, the MGW may modify the EVS-CMRs, flowing in the opposite direction of the observed speech flow.
It is allowed, to modify the EVS-CMR to a lower maximum bit rate, but it is not allowed to modify it to a higher maximum bit rate. Since all nodes in the speech path follow this "Maximum Mode Control" principle, the receiver of the final EVS-CMR, i.e. the media-sender, gets the EVS-CMR that is most suitable to the smallest bottleneck in the overall speech path. The media-sender, e.g. in a 3G-UE, may still use an even lower bit rate than the maximum bit rate given by the received DL EVS-CMR, see clause 7 for details.
If in such an event, when the maximum bit rate request is reduced, the resulting maximum bit rate does no longer support the originally requested maximum audio bandwidth, then the maximum audio bandwidth may be reduced by the MGW to the next lower one that fits to the reduced maximum bit rate.
These modifications of the EVS-CMR due to Maximum Mode Control shall not modify the major operation mode.
A MGW may be forced to modify the major operation mode of an incoming EVS-CMR in two cases:
a) when interworking between EVS and AMR-WB and
b) during handover.
11.3.2 Maximum Mode Control for the EVS Channel Aware mode
If the MGW is in TrFO mode within the speech path and receives EVS-CMR, requesting the EVS-CA mode of operation with a certain CA-offset and CA-depth, then the MGW let this typically pass unmodified, potentially mapped to the outgoing Configuration.
It is, however, allowed that the MGW observes the incoming stream of speech frames or packets and determines, if or if not the active EVS-CA parameters are (still) suitable, or if other EVS-CA parameters are more appropriate. In such a case, the MGW may modify the EVS-CMRs, flowing in the opposite direction of the observed speech flow. The MGW may modify the received CA-Offset to a bigger one (e.g. from 2 to 3) and the CA-depth to the lower, more robust one. The MGW shall not reduce the CA-Offset or modify the received CA-depth to a less robust one.
The MGW should not block the EVS-CA mode.
11.3.3 Maximum Mode Control for the EVS Variable Bit Rate mode
The EVS Variable Bit Rate mode may be regarded as separate mode of operation or as lowest possible mode of the EVS Primary mode of operation. Clause 7 does not allow the 3G-UE to enter the EVS-VBR on its own initiative.
The MGW may, however, decide that the EVS-VBR is the most suitable mode and may modify the received primary-mode EVS-CMR into the EVS-CMR for EVS-VBR. The 3G-UE shall then follow this EVS-CMR, see clause 7.
11.3.4 Maximum Mode Control for Handover
NOTE: This subclause is for further study.
11.4 Interworking between Nb and Mb
11.4.1 Interworking for EVS Rate Control
11.4.1.1 General
On the Nb interface, only EVS-CMR, as specifies in the present document, provides for in-band rate and mode control via the EVS-CMR field of every Codec frame (Speech or SID) and CMR-Only frame.
On the Mb interface, signaling for rate and mode control is provided either by CMR in RTP packets, as specified in 3GPP TS 26.445 [xx], or by rate and mode control commands in RTCP-APP packets, as specified in TS 26.114 [x]. Clause 10.3 of the present document gives an overview of various alternatives (Mb-Alt 1 to Mb-Alt 3) for rate and mode control for EVS on Mb. Mb-Alt 4 is the alternative, where rate and mode control is completely forbidden on Mb.
NOTE 1: TS 26.114 [x] specifies the RTCP-APP for EVS with other coding than CMR of TS 26.445 [x], but specifies new rate and mode control commands for EVS. The present document does not describe the Interworking between CMR in RTP and these RTCP-APP commands. It is anticipated that every CMR can be translated into an RTCP-APP command and vice versa.
NOTE 2: Neither EVS-CMR on Nb, nor CMR on Mb nor RTCP-APP provide secure transmission for rate and mode control signalling, i.e. packets containing rate and mode control signalling may be lost without notice by the sender and/or receiver. No acknowledgement for retransmission is defined.
EVS-CMR is therefore repeated in every Speech or SID frame to heal transmission errors as quick as possible, typically 20 ms to 160 ms after a potential loss or error. This repetition provides a strong forward error correction code. EVS-CMR code-point "NO_REQ" is not used, instead the active CMR is sent on Nb. Also the CMR on Mb is repeated in every Speech or SID frame in Mb-Alt 1, if the optional code points "NO_REQ" and "none" are not used, providing then the same strong forward error correction. The other alternatives (Mb-Alt 2 and Mb-Alt 3) on Mb leave error protection and recovery to the implementations.
Interworking of rate and mode control procedures at an IM-MGW between an Mb interface and a corresponding Nb interface only applies, if the IM-MGW bridges compatible codec configurations between the interfaces without applying a transcoding function and if the SDP offer/answer negotiation has not disabled the rate and mode control on Mb (Mb-Alt 4 in clause 10.3). In all other cases, transcoding applies and the rate and mode control loops on Nb and Mb are independent.
11.4.1.2 RTP on Mb contains one Speech or one SID frame
Transcoding free Interworking between Nb and Mb is easiest, when exactly one Speech or SID frame or one CMR-Only frame is included in RTP on Mb, as is the case on Nb.
An IM-MGW, receiving an EVS-CMR from an incoming Nb interface in either a Speech or SID or CMR-Only packet, may filter and modify the EVS-CMR contents based on operator policies and shall map the resulting EVS-CMR onto the EVS Configuration on the outgoing Mb interface. Depending on the negotiated alternative for CMR on Mb, the IM-MGW shall send on Mb:
– Mb-Alt 1: either the resulting CMR in the corresponding Speech or SID or CMR-Only packet, in which case every outgoing Speech or SID or CMR-Only packet contains the active CMR;
– Mb-Alt 2: or the resulting CMR, but only if it is different to the previously sent CMR-value ("CMR on demand"), in which case the new CMR should be repeated at least 3 times within the next 100 ms to provide a minimum of error robustness, if necessary using also additional CMR-Only packets in speech pauses;
– Mb-Alt 3: or a corresponding RTCP-APP command, if CMR in RTP is disabled on Mb and RTCP-APP is enabled and if the resulting CMR-value is different to the previously sent CMR-value ("RTCP-APP on demand"). Note that RTP and RTCP-APP packets are not synchronized with respect to each other.
An IM-MGW, receiving a rate or mode control request as CMR from an incoming Mb interface in either a Speech or SID or CMR-Only packet, or an RTCP-APP command, which is then first translated into the corresponding CMR, may filter and modify the received CMR based on operator policies and shall map the resulting EVS-CMR onto the EVS Configuration of the outgoing Nb interface. In all cases, the IM-MGW shall send an active EVS-CMR in every Speech or SID or CMR-Only frame on Nb. If an RTCP-APP command is received within a speech pause, then it may be necessary to send one or more CMR-Only packet on Nb.
Depending on the negotiated alternative for CMR on Mb, the IM-MGW may have to translate the incoming rate and mode control procedure. If the negotiated Rate and Mode control procedure on Mb is
– Mb-Alt 1: then the IM-MGW gets either in every incoming Speech or SID or CMR-Only packet the active CMR, or – depending on the implementation in the media-sender – the IM-MGW may get sometimes an active CMR and sometimes a "NO_REQ" or "none" code, see TS 26.445 [x]. The IM-MGW shall store the most recent active CMR for future use, until it is replaced by a new active CMR;
– Mb-Alt 2: then the IM-MGW gets sometimes ("CMR on demand") an active CMR within a Speech or SID or CMR-Only packet on Mb, in which case the IM-MGW must store the most recent active CMR for future use, until it is replaced by a new active CMR;
– Mb-Alt 3: then the IM-MGW gets sometimes rate and/or mode control commands on Mb via RTCP-APP, in which case the IM-MGW must translate these into corresponding EVS-CMR and handle them as in Mb-Alt 2.
11.4.1.3 RTP on Mb contains N Speech or SID frames
Transcoding free Interworking between Nb and Mb is also possible, if multiple (N) Speech or SID frames are packed into one RTP packet on Mb. This clause specifies the rate and mode control handling for Mb-Alt 1 on Mb. The handling for the other alternatives shall be derived from that.
If the negotiated alternative for CMR on Mb is Alt-1, then the IM-MGW shall send on Mb the active CMR in every RTP packet. If N frames (Speech or SID or CMR-Only) are received on Nb and packed into one N-frame RTP packet on Mb, then the most recent active CMR-value is packed into the RTP packet, all other, older CMR-values are ignored. The most recent EVS-CMR is filtered, modified and mapped as described above.
If an N-frame RTP packet is received on Mb, then the received CMR (if any) is valid for all Speech or SID frames inside the RTP Packet. This CMR is filtered, modified and mapped as described above and then the IM-MGW sends the resulting EVS-CMR in every outgoing Speech or SID or CMR-Only frame on Nb. If no new active CMR is received, then the stored CMR is used.
11.4.2 Interworking for Discontinuous Transmission
In CS Networks DTX is always activated in the uplink direction for AMR, AMR-WB and EVS, i.e. in direction CS => IMS. The CS Network is always able to receive DTX in direction CS <= IMS.
On the Mb interface, it is, however, possible to deactivate DTX in send and/or receive direction.
If the IMS side requires interworking with DTX deactivated in its media-receive direction, then the IM-MGW shall insert transcoding in this direction (CS => IMS).
If the IMS side requires interworking with DTX deactivated in its media-send direction, then the IM-MGW shall insert transcoding in this direction (CS <= IMS).
NOTE: Deactivating DTX on IMS side in either sending or receiving direction requires transcoding with higher usage of MGW resources and lower voice quality end-to-end in CS <=> IMS interworking.
11.5 Interworking between EVS and AMR-WB
It may happen that EVS is used on one termination of the MGW or the IM-MGW and AMR-WB is used on the other termination.
The EVS Codec includes the EVS AMR-WB IO major operation mode and is therefore TrFO-compatible to the AMR-WB Codec, if the mode-sets and mode-change-period parameters are TrFO-compatible. For example, AMR-WB on the Nb-termination and EVS on the Mb-termination (or vice versa) are TrFO-compatible Codecs, if the mode-sets are TrFO-compatible and mode-change-period=2 on both sides.
If the MGW or IM-MGW bridges between an EVS Codec Configuration that is TrFO-compatible to the AMR-WB Codec Configuration, then the following applies:
– If the Codec of the incoming termination is EVS and the Codec on the outgoing termination is AMR-WB, then the Rate control procedure for AMR-WB shall apply at the outgoing termination, with the maximum rate equal to or lower than the maximum rate received in the EVS-CMR. The MGW or IM-MGW shall map received EVS-CMRs to the selected mode-set of the outgoing AMR-WB termination.
– If the Codec of the incoming termination is AMR-WB and the Codec on the outgoing termination is EVS, then the Rate control procedure for AMR-WB shall apply on the incoming termination. It shall determine the maximum rate of the EVS-CMR to be sent by the MGW or IM-MGW. In this case, the outgoing EVS-CMR shall request the EVS AMR-WB IO major operation mode.
If the MGW or IM-MGW bridges between an EVS Codec Configuration that is not TrFO-compatible to the AMR-WB Codec Configuration, then transcoding shall apply. Then the rate and mode control procedures on both terminations are independent.
11.6 Interworking for the EVS Channel Aware Mode
11.6.1 Introduction
The EVS channel aware (EVS-CA) mode of operation (see TS 26.445 [12]), includes a source-controlled partial-redundant copy in-band, as part of the overall codec payload, which operates at a constant bitrate of 13,2 kbps (264 bits/frame). The partial-redundant copy associated with frame N is encoded and transmitted along with the primary encoding of a "future" frame (N+K). The offset parameter, K, determines the separation between the primary and redundant frame. K is transmitted inband (2 bit), as well as a CA-flag (1 bit) and the length-index for the redundant part (3 bits).
The RTP packets may be subjected to varying scheduling and routing conditions in PS networks, which may result in packets arriving out of order and experiencing varying end-to-end delay. Packets may also be lost, notably on the uplink radio channel(s). In packet-switched networks, typically, a (de-)jitter buffer together with a jitter buffer management (JBM) is used in speech decoders to remove this jitter and feed the speech frames for decoding in the right order and timing.
In the EVS-CA mode, if frame N is due for decoding, but is lost, then the de-jitter buffer is inspected for the availability of future frame (N+K). If available, the partial-redundant copy in frame (N+K) is extracted for the synthesis of the lost frame N.
In particular, in the PS downlink (e.g. PS to PS, CS to PS), the de-jitter buffer at the PS-UE helps retrieve and use the partial-redundant copies for decoding of packets lost in the network as shown in the example below, Figure 11.6.1-1. In this example, the partial-redundant copies are encoded and sent at offset K=2 frames.
Figure 11.6.1-1: PS downlink, de-jitter buffer handling and partial copy recovery
In CS networks, speech is often also transmitted in RTP packets, but the jitter is comparably small or even negligible. A 3G-UE therefore does not deploy a jitter buffer management for decoding. In order to compensate for this unavailability of a de-jitter buffer in the 3G-UE some interworking is necessary within a MGW and between the MGW and the remote 3G-UE. In particular, in the CS downlink (e.g. PS to CS), as there is no de-jitter buffer available in 3G-UEs, the 3G-UE may perform a concealment as shown in the example below, Figure 11.6.1-2, if the partial copies are not available.
Figure 11.6.1-2: CS downlink, absence of EVS-CA interworking
11.6.2 Removal of Jitter in direction PS to CS
The jitter introduced by the PS uplink has to be removed, before the speech frame can be sent further in the CS network on the Iu Interface. This JBM should be located within the Iu-terminating MGW, i.e. just before the Iu Interface, or the transcoder, if present. It is, however, also allowed, although not recommended, to remove the jitter in an "earlier" MGW, e.g. the IM-MGW. The jitter processing is used in current MGWs for enabling the PS to CS calls and not detailed here.
The JBM in the Iu-terminating MGW operates as described in clause 11.6.1, sending in most cases the well-received, reordered, de-jittered speech frame forward to the Iu interface and the decoder within the 3G-UE in due time, one frame every 20 ms.
If frame N was lost in the PS network, then the MGW may look into the jitter buffer and if frame (N+K) is available, then it can send frame (N+K) to the 3G-UE for decoding as partial-redundant copy.
In effect, the MGW serves as the JBM for the 3G-UE.
However, the MGW needs to convey the information to the 3G-UE on how to decode the frame, e.g. as primary frame or as partial-redundant copy frame. That is, the 3G-UE, when it receives the 13,2 kbps EVS-CA frame, needs to know, if it should use the primary portion to decode or use the partial-redundant copy to decode.
This information is conveyed through the "use_partial_copy" signalling bit. The position of this signalling bit within the EVS CA frame depends on the CA Frame Type, the Coder Type and the bandwidth mode (swb or wb), as shown in Table 11.6.2-1. This use_partial_copy signalling bit is unused (i.e. set to 0) by the EVS encoder in the EVS CA mode and is ignored in the PS-UE EVS decoder, see TS 26.445 [12].
Table 11.6.2-1: Signalling bit for "use_partial_copy" decoding
|
swb |
wb |
|||
|
CA Frame Type |
Coder type |
b[i], {i=0,1,…263} |
Coder type |
b[i], {i=0,1,…263} |
|
6 |
2 |
b[175] |
1,2,3 |
b[187] |
|
5 |
1,2,3 |
b[179] |
1,2,3 |
b[191] |
|
4 |
2,3 |
b[182] |
NA |
|
|
3 |
2,3 |
b[229] |
2,3 |
b[241] |
|
2 |
3 |
b[229] |
3 |
b[241] |
|
0,1,7 |
NA |
|||
If frame N was lost in the PS network, then the JBM in the MGW shall look into the jitter buffer and if frame (N+K) is available, then the JBM shall send frame (N+K) to the 3G-UE with the use_partial_copy signalling bit set to 1. For the case, where the signalling bit is not applicable (e.g. as they are RF_NO_DATA, SID frames, shown as "NA" in Table 11.6.2-1), the MGW shall simply signal a frame erasure (i.e. send nothing) similar to the case when partial-redundant copy is not available.
The handling within the 3G-UE is described in clause 7.4.
In some corner cases, it may well be that a call is setup between a PS-UE1 and a 3G-UE2, until the 3G-UE2 is transferred (by handover, SRVCC, DRVCC) into a PS-domain (e.g. LTE or Wi-Fi). The CS network and the Iu-terminating CS-MGW remain in the call path. In such a case, the Iu-terminating CS-MGW, after performing the User Plane switch to the PS domain, shall delete the received frame with this signalling bit set to1, getting back to the situation before the first JBM. Just the first PS-uplink jitter is removed by the first JBM, but the stream of speech frames after the CS-MGW is the same again as before the first JBM.
11.6.3 Removal of Jitter in direction CS to PS
Since the CS-network does not introduce jitter (or only comparably small jitter) and since the PS-network introduces and handles jitter anyway in the PS-UE, there is no need for any jitter removal in the direction CS to PS in a MGW.
The EVS-CA Mode of operation in the direction CS to PS is helpful to mitigate frame losses on the sending CS uplink and the receiving PS downlink, if the JBM is located in the PS-UE.
Annex A (informative):
Change history
|
Change history |
|||||||
|
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
2016-03 |
SA#71 |
SP-160072 |
Presented to TSG SA#71 (for approval) |
1.0.0 |
|||
|
2016-03 |
SA#71 |
Approved at TSG SA#71 |
13.0.0 |
||||
|
2016-06 |
SA#72 |
SP-160261 |
0002 |
– |
F |
Changes to clause 5 RAB Aspects |
13.1.0 |
|
2016-06 |
SA#72 |
SP-160261 |
0003 |
1 |
F |
Mb Interface User Plane |
13.1.0 |
|
2016-09 |
SA#73 |
SP-160592 |
0005 |
– |
F |
Correction in clause 4 General for EVSoCS |
13.2.0 |
|
2016-09 |
SA#73 |
SP-160592 |
0006 |
1 |
F |
Filtering and Modification of EVS-CMR |
13.2.0 |
|
2016-09 |
SA#73 |
SP-160592 |
0007 |
1 |
F |
Interworking between different EVS Configurations |
13.2.0 |
|
2016-09 |
SA#73 |
SP-160592 |
0008 |
1 |
F |
Handling of Speech and SID payload |
13.2.0 |
|
2016-09 |
SA#73 |
SP-160592 |
0009 |
– |
F |
Interworking between EVS and AMR-WB |
13.2.0 |
|
2016-09 |
SA#73 |
SP-160592 |
0010 |
– |
F |
Correction to clause 6 Iu interface for EVSoCS |
13.2.0 |
|
2016-09 |
SA#73 |
SP-160592 |
0011 |
– |
F |
Uu Interface User Plane for EVSoCS |
13.2.0 |
|
2016-09 |
SA#73 |
SP-160592 |
0012 |
– |
F |
Nb Interface for EVSoCS |
13.2.0 |
|
2016-09 |
SA#73 |
SP-160592 |
0013 |
1 |
F |
Interworking between Nb and Mb |
13.2.0 |
|
2016-09 |
SA#73 |
SP-160592 |
0014 |
– |
F |
Clarification to avoid rate adaptation quality issues in uplink for UTRAN |
13.2.0 |
|
2017-03 |
SA#75 |
Version for Release 14 |
14.0.0 |
||||
|
2018-06 |
SA#80 |
Version for Release 15 |
15.0.0 |
||||
|
2019-03 |
SA#83 |
SP-190036 |
0015 |
– |
B |
Addition of reference to Alt_FX_EVS implementation |
16.0.0 |
|
2022-04 |
– |
– |
– |
– |
– |
Update to Rel-17 version (MCC) |
17.0.0 |