Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 26.114  Word version:  18.8.0

Top   Top   Up   Prev   Next
0…   3…   4…   5…   6…   6.2.3…   6.2.5…   6.2.7…   6.2.10…   7…   7.5…   8…   9…   10…   10.2.1.6…   10.2.2…   10.3…   10.4…   11…   12…   12.3…   12.7…   13a…   16…   16.5…   17…   18…   19…   A…   A.3…   A.4…   A.5…   A.10…   A.14…   A.15…   B…   C…   C.1.3…   C.1.3.5   C.2…   D   E…   E.18…   E.31…   G…   K…   L…   M…   N…   O…   P…   P.3   Q…   R…   S…   T…   U…   V…   W…   X…   Y…   Y.6…   Y.6.4…   Y.6.5…   Y.7… 
10 Adaptation  10.1 General  10.2 Speech  10.2.0 General  10.2.1 RTCP-APP with codec control requests  10.2.1.1 General  10.2.1.2 General Format of RTCP-APP packet with codec control requests  10.2.1.2a Padding  10.2.1.3 Redundancy Request  10.2.1.4 Frame Aggregation Request  10.2.1.5 Codec Mode Request 
...

 

10  Adaptation  p. 111

10.1  General  p. 111

Adaptive mechanisms are used to optimize the session quality given the current transport characteristics. The mechanisms provided in MTSI are bit-rate, packet-rate and error resilience adaptation. These mechanisms can be used in different ways; however, they should only be used when the result of the adaptation is assumed to increase the session quality even if e.g. the source bit-rate is reduced.
Adaptive mechanisms that act upon measured or signalled changes in the transport channel characteristics may be used in a conservative manner. Examples of measured changes in transport characteristics are variations in Packet Loss Rate (PLR) and delay jitter. Examples of signalled changes in transport characteristics are ANBR (see clause 10.7) and ECN Congestion Experienced (ECN-CE) marking in IP packet headers. A conservative use of adaptation is characterized by a fast response to degrading conditions, and a slower, careful upwards adaptation intended to return the session media settings to the original default state of the session. The long-term goal of any adaptive mechanism is assumed to be a restoration of the session quality to the originally negotiated quality. The short-term goal is to maximize the session quality given the current transport characteristics, even if that means that the adapted state of the session will give a lower session quality compared to the session default state if transported on an undisturbed channel.
The 'a=bw-info' attribute defined in clause 19 may be used to align the adaptation with the bearer setup and the end-to-end resource allocation. A few recommendations are described in subclause 10.6.
Up

10.2  Speech  p. 111

10.2.0  General |R9|  p. 111

To reduce the risk for confusion in the media-sender, it is beneficial if the signaling from media-receiver back to media-sender for the media adaptation is the same regardless of which triggers are used in the adaptation-decision in the media-receiver. The ANBR described in clause 10.7 should, if supported by both the access network and the MTSI client in terminal, be used as one such trigger.
The adaptation for AMR, AMR-WB, EVS and IVAS includes adapting the media bit-rate, the frame aggregation, the redundancy level and the redundancy offset. The domain of adaptation for EVS and IVAS furthermore includes adapting audio bandwidth, partial redundancy, switching between EVS primary mode and EVS AMR-WB IO mode.
When the AMR codec or the AMR-WB codec is used, two signaling mechanisms are defined:
  • CMR in the AMR/AMR-WB RTP payload, RFC 4867.
    CMR in RTP can be used by the media-receiver to restrict the codec mode in the remote media-sender to an upper limit (maximum mode).
  • RTCP-APP, see clause 10.2.1.
If the media-sender supports RTCP-APP, then the media-receiver can use it in the following way:
CMR in RTCP-APP can be used by the media-receiver to restrict the codec mode in the remote media-sender to an upper limit (maximum mode), in addition to CMR in RTP.
RTCP-APP can further be used by the media-receiver for the adaptation of frame aggregation, redundancy level and redundancy offset in the RTP packets to be sent by the remote media-sender.
When the EVS codec is used, the following signaling mechanism is defined:
When the IVAS codec is used, the following signaling mechanism is defined:
In response to received DL ANBR, a speech media receiver should trigger sending CMR requesting bitrate adaptation in the corresponding media sender RTP stream. If RTCP-APP is supported, then a speech media receiver should trigger sending CMR or RTCP-APP requesting bitrate adaptation in the corresponding media sender RTP stream based on the received DL ANBR.
When adapting frame aggregation and/or redundancy, the MTSI client must verify that the maximum packetization, defined by the maxptime SDP parameter, is not exceeded. The MTSI client must also verify that the IP packet sizes does not exceed the Maximum Transfer Unit (MTU).
The boundaries of the adaptation may be controlled by a set of parameters. These parameters may be configured into the MTSI client based on operator policy, for example using OMA-DM.
Table 10.1 defines a mandatory set of parameters that are used by the ECN triggered adaptation for AMR and AMR-WB. The default values for the parameters are also specified. Alternate values for these parameters may be configured into the MTSI client based on operator policy, for example using OMA-DM.
Parameter Description
ECN_min_rateLower boundary for the media bit-rate adaptation in response to ECN-CE marking. The media bit-rate shall not be reduced below this value as a reaction to the received ECN-CE.
The ECN_min_rate should be selected to maintain an acceptable service quality while reducing the resource utilization.
Default value: For AMR and AMR-WB, the default value shall be the rate of the recommended Initial Codec Mode, see clause 7.5.2.1.6.
ECN_congestion_waitThe waiting time after an ECN-CE marking for which an up-switch shall not be attempted.
A negative value indicates an infinite waiting time, i.e. to prevent up-switch for the whole remaining session.
Default value: 5 seconds
The configuration of adaptation parameters, and the actions taken during the adaptation, are specific to the particular triggers. For example, the adaptation may be configured to reduce the media bit-rate to AMR5.9 when ECN-CE is detected, while it may reduce the media bit-rate to AMR4.75 for bad radio conditions when high PLR is detected.
Multiple ECN-CE markings within one RTP-level round-trip time is considered as the same congestion event. Each time an MTSI client detects a congestion event it shall send an adaptation request to reduce the media bit-rate unless already operating at the ECN_min_rate or below. An MTSI client detecting a congestion event shall not send an adaptation request to increase the media bit-rate for a time period ECN_congestion_wait after the end of the congestion event.
Multiple adaptation trigger algorithms can be used in parallel, for example ECN-triggered adaptation, adaptation based on ANBR, and PLR-triggered adaptation. When multiple adaptation algorithms are used for the rate adaptation, the rate that the MTSI client is allowed to use should be no higher than any of the rates determined by each adaptation algorithm.
When additional transport bandwidth information is provided using the 'a=bw-info' attribute defined in clause 19, the Minimum Desired Bandwidth should be aligned with the ECN_min_rate configuration parameter.
Up

10.2.1  RTCP-APP with codec control requests  p. 113

10.2.1.1  General |R9|  p. 113

When signalling adaptation requests for speech in MTSI, an RTCP-APP packet should be used. This application-specific packet format supports three different adaptation requests when the AMR or AMR-WB codec is used; bit-rate requests, frame aggregation requests and redundancy requests. The requests for frame aggregation and redundancy are also used when the EVS codec or the IVAS codec is used. The codec mode request used for AMR-WB is also used when the EVS AMR-WB IO mode is used and when EVS AMR-WB IO mode is used in the IVAS codec. The application specific format supports additionally five requests that are used for the EVS codec or when IVAS is used in EVS mode. An additional adaptation requests are defined for the IVAS codec. The RTCP-APP packet is put in a compound RTCP packets according to the rules outlined in RFC 3550 and RFC 4585. In order to keep the size of the RTCP packets as small as possible it is strongly recommended that the RTCP packets are transmitted as minimal compound RTCP packets, meaning that they contain only the items:
  • SR or RR;
  • SDES CNAME item;
  • APP (when applicable).
The recommended RTCP mode is RTCP-AVPF early mode since it will enable transmission of RTCP reports when needed and still comply with RTCP bandwidth rules. The RTCP-APP packets should not be transmitted in each RTCP packet, but rather as a result in the transport characteristics which require end-point adaptation.
The signalling allows for a request that the other endpoint modifies the packet stream to better fit the characteristics of the current transport link. The request in the received RTCP-APP is valid until a new request is received. Note that the media sender can, if having good reasons, choose to not comply with the request received from the media receiver. One such reason could be knowledge of that the local conditions do not allow the requested format.
Up

10.2.1.2  General Format of RTCP-APP packet with codec control requests |R9|  p. 113

The RTCP-APP packet defined to be used for adaptation signalling for speech in MTSI is constructed as shown in Figure 10.1.
Reproduction of 3GPP TS 26.114, Fig. 10.1: RTCP-APP formatting
Figure 10.1: RTCP-APP formatting
Up
The RTCP-APP specific fields are defined as follows:
  • Subtype - the subtype value shall be set to "0".
  • Name - the name shall be set to "3GM7", meaning 3GPP MTSI Release 7.
The application-dependent data field contains the requests listed below. The length of the application-dependent data shall be a multiple of 32 bits. The unused bytes shall be set to zero.
Reproduction of 3GPP TS 26.114, Fig. 10.2: Basic syntax of the application-dependent data fields when only ID is used
Figure 10.2: Basic syntax of the application-dependent data fields when only ID is used
Up
The length of the messages is 1 or 2 bytes depending on request type.
The ID field identifies the request type. ID Code points [0000] ... [1010] are specified in the present document, whereas the other ID code points are reserved for future use.
The signalling for several different adaptation requests is defined below. For each request, the codecs that can use the request are also specified.
The requests that can be used in a session are negotiated with SDP, see clause 10.2.3.
Up

10.2.1.2a  Padding |R12|  p. 114

PADDING:
This message contains no request but is identical to a padding byte with all zeroes and is therefore used as padding.
Reproduction of 3GPP TS 26.114, Fig. 10.2a: Padding
Figure 10.2a: Padding
Up
Codecs:
This request can be used for all codecs.
The DATA field is a 4-bit value field with all bits set to zero. When receiving a PADDING message, the whole octet shall be ignored, regardless of the bits in the DATA field.
An MTSI client uses this to pad the RTCP-APP to be 32 bit aligned when needed.

10.2.1.3  Redundancy Request |R9|  p. 115

RTCP_APP_REQ_RED:
Request for redundancy level and offset of redundant data.
Reproduction of 3GPP TS 26.114, Fig. 10.3: Redundancy request
Figure 10.3: Redundancy request
Up
Codecs:
This request can be used for all codecs.
The Bit field is a 12 bit bitmask that signals a request on how non-redundant payloads chunks are to be repeated in subsequent packets.
The position of the bit set indicates which earlier non-redundant payload chunks is requested to be added as redundant payload chunks to the current packet.
  • If the LSB (rightmost bit) is set equal to 1 it indicates that the last previous payload chunk is requested to be repeated as redundant payload in the current packet.
  • If the MSB (leftmost bit) is set equal to 1 it indicates that the payload chunk that was transmitted 12 packets ago is requested to be repeated as redundant payload chunk in the current packet. Note that it is not guaranteed that the sender has access to such old payload chunks.
The maximum amount of redundancy is 300%, i.e., at maximum three bits can be set in the Bit field.
See clause 10.2.1 for example use cases.
Up

10.2.1.4  Frame Aggregation Request |R9|  p. 115

RTCP_APP_REQ_AGG:
Request for a change of frame aggregation.
Reproduction of 3GPP TS 26.114, Fig. 10.4: Frame aggregation request
Figure 10.4: Frame aggregation request
Up
Codecs:
This request can be used for all codecs.
The DATA field is a 4 bit value field:
  • 0000 - 1 frame / packet.
  • 0001 - 2 frames / packet.
  • 0010 - 3 frames / packet.
  • 0011 - 4 frames / packet.
The values 0100…1111 are reserved for future use.
The maximum allowed frame aggregation is also limited by the maxptime parameter in the session SDP since the sender is not allowed to send more frames in an RTP packet than what the maxptime parameter defines.
The default aggregation is governed by the ptime parameter in the session SDP. It is allowed to send fewer frames in an RTP packet, for example if there are no more frames available at the end of a talk spurt. It is also allowed to send more frames in an RTP packet, but such behaviour is not recommended.
See clauses 7.4.2 and 12.3.2.1 for further information.
Up

10.2.1.5  Codec Mode Request |R9|  p. 116

RTCP_APP_CMR:
Codec Mode Request
Reproduction of 3GPP TS 26.114, Fig. 10.5: Codec mode request
Figure 10.5: Codec mode request
Up
Codecs:
This request can only be used for the AMR codec, the AMR-WB codecs, for the EVS codec when operating in AMR-WB IO mode and for the IVAS codec when operating in EVS mode using the AMR-WB IO mode.
The definition of the CMR bits in the RTCP_APP_CMR message is identical to the definition of the CMR bits defined in RFC 4867. The CMR indicates the maximum codec mode (highest bit-rate) that the receiver wants to receive. The sender may very well use a lower codec mode (lower bit-rate) when sending.
An MTSI client in terminal that requests mode adaptation should transmit the CMR in an RTCP_APP_CMR, unless specified otherwise in clause 7.3.2.
When the MTSI MGW has an interworking session with a circuit-switched (CS) system using transcoding and requests mode adaptation, the MTSI MGW should transmit CMR in an RTCP_APP_CMR, unless specified otherwise in clause 7.3.2, and should set the CMR in the AMR payload to 15 (no mode request present (RFC 4867)).
When the MTSI MGW has an interworking session with a circuit-switched (CS) system using TFO/TrFO, then the MTSI media gateway should translate the CMR bits (in GERAN case) or the Iu/Nb rate control messages (in UTRAN case) from the CS client into the CMR bits in the AMR payload. If the MTSI media gateway prefers to receive a lower codec mode rate from the MTSI client in terminal than what the CMR from the CS side indicates, then the MTSI media gateway may replace the CMR from the CS side with the CMR that the MTSI media gateway prefers. The value 15 (no mode request present (RFC 4867)) shall be used in the CMR bits in the AMR payload towards the PS side if on the CS side no mode request has been received and if the MTSI media gateway has no preference on the used codec mode. The RTCP_APP_CMR should not be used in the direction from the MTSI media gateway towards the MTSI client when TFO/TrFO is used.
If an MTSI client receives CMR bits both in the AMR payload and in an RTCP_APP_CMR message, the mode with the lowest bit rate of the two indicated modes should be used. A codec mode request received in a RTCP_APP_CMR is valid until the next received RTCP_APP_CMR.
Up

Up   Top   ToC