10 Adaptation

26.1143GPPIP Multimedia Subsystem (IMS)Media handling and interactionMultimedia telephonyRelease 18TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

10.1 General

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 sub-clause 10.6.

10.2 Speech

10.2.0 General

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.

NOTE 1: The media-receiver is aware that other nodes in the media path may also influence the media adaptation. A media-receiver sending a specific CMR value X can expect that (after some time) no media is received with a mode higher than X, but modes lower than X may be received any time.

The adaptation for AMR, AMR-WB and EVS includes adapting the media bit-rate, the frame aggregation, the redundancy level and the redundancy offset. The domain of adaptation for EVS 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, [28].
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:

– CMR in the EVS RTP payload, [125].

– RTCP-APP, see clause 10.2.1.

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.

Table 10.1: Configuration parameters when ECN is used as a trigger

Parameter

Description

ECN_min_rate

Lower 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_wait

The 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.

NOTE 2: For example, if the ECN-triggered adaptation indicates that AMR5.9 should be used and if the PLR-triggered adaptation indicates that AMR4.75 should be used then the rate that the MTSI client uses should be no higher than min(AMR5.9, AMR4.75) = AMR4.75.An example adaptation scheme is described in Annex C.

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.

10.2.1 RTCP-APP with codec control requests

10.2.1.1 General

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 is used. The codec mode request used for AMR-WB is also used when the EVS AMR-WB IO mode is used. The application specific format supports additionally five requests that are used for the EVS codec. The RTCP-APP packet is put in a compound RTCP packets according to the rules outlined in RFC 3550 [9] and RFC 4585 [40]. 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.

10.2.1.2 General Format of RTCP-APP packet with codec control requests

The RTCP-APP packet defined to be used for adaptation signalling for speech in MTSI is constructed as shown in figure 10.1.

Figure 10.1: RTCP-APP formatting

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.

Figure 10.2: Basic syntax of the application-dependent data fields

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] … [1000] are specified in the present document, whereas the other ID code points are reserved for future use.

The signalling for three 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.

10.2.1.2a Padding

PADDING: This message contains no request but is identical to a padding byte with all zeroes and is therefore used as padding.

Figure 10.2a: Padding

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

RTCP_APP_REQ_RED: Request for redundancy level and offset of redundant data.

Figure 10.3: Redundancy request

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.

10.2.1.4 Frame Aggregation Request

RTCP_APP_REQ_AGG: Request for a change of frame aggregation.

Figure 10.4: Frame aggregation request

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.

10.2.1.5 Codec Mode Request

RTCP_APP_CMR: Codec Mode Request

Figure 10.5: Codec mode request

Codecs: This request can only be used for the AMR codec, the AMR-WB codecs and for the EVS codec when operating in 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 [28]. 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 [28]).

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

10.2.1.6 Generation of RTP payloads for multiple codec control requests

Figure 10.6 below illustrates how the three requests are used by the transmitter. In this case, RTCP_APP_REQ_RED is equal to "000000000101".

– The speech encoder generates frames every 20 ms.

– The speech frames are buffered in the aggregation buffer until it is possible to generate a payload chunk with the number of frames requested by either ptime at session setup or by RTCP_APP_REQ_AGG during a session.

– The current payload chunk is used when constructing the current RTP packet.

– The history buffer contains previously transmitted payload chunks. The length of this buffer needs to be dimensioned to store the maximum number of payload chunks that are possible. This value is based on the max-red value, the maxptime values and from the minimum number of frames that the transmitter will encapsulate in the RTP packets. In this case, the buffer length is selected to 11 payload chunks since this corresponds to the worst case of max-red=220, maxptime=240 and one frame per payload chunk.

– After transmitting the current RTP packet, the content of the history buffer is shifted, the current payload chunk is shifted in to the history buffer as P(n-1) and the oldest payload chunk P(n-11) is shifted out.

– When constructing the (provisional) RTP payload, the selected preceding payload chunks are selected from the history buffer and added to the current payload chunk. In order to form a valid RTP payload, the transmitter needs to verify that the maxptime value is not exceeded. If the provisional RTP payload is longer than what maxptime allows, then the oldest speech frames shall be removed until the length (in time) of the payload no longer violates the maxptime value. NO_DATA frames in the beginning or at the end of the payload does not need to be transmitted and are therefore removed. The RTP Time Stamp needs to be incremented when a NO_DATA frames are removed from the beginning of the payload. A (provisional) RTP packet containing only NO_DATA frames does not need to be transmitted.

Note also that the transmitter is not allowed to send frames that are older than the max-red value that the transmitter has indicated in the SDP.

Figure 10.6: Visualization of how the different adaptation requests
affect the encoding and the payload packetization

It should be noted that RTCP_APP_REQ_AGG and RTCP_APP_REQ_RED are independent. Furthermore, it should also be noted that different redundant payload chunks may contain different number of speech frames.

10.2.1.7 EVS Primary Rate Request

RTCP_APP_REQ_EPRR: EVS Primary Rate Request

Figure 10.6a: EVS primary rate request

Codecs: This request can be used for the EVS codecs when operating in EVS Primary mode.

The DATA field a 4-bit field and is encoded as described in the table below. The rate request indicates the maximum codec mode (highest bit-rate) that the receiver wants to receive. The sender may use a lower codec mode (lower bit-rate) when sending. The rate request shall comply with the media type parameters that are negotiated in the session.

Table 10.1a Encoding of the DATA field in the EVS Primary Rate Request.

Index	EVS Primary rate request
0000	5.9
0001	7.2
0010	8
0011	9.6
0100	13.2
0101	16.4
0110	24.4
0111	32
1000	48
1001	64
1010	96
1011	128
1100	Not used
1101	Not used
1110	Not used
1111	Not used

10.2.1.8 EVS Bandwidth Request

RTCP_APP_REQ_EBWR: EVS Bandwidth Request

Figure 10.6b: EVS bandwidth request

Codecs: This request can be used for the EVS codecs when operating in Primary mode.

The DATA field is a 4-bit field b0…b3, corresponding to bit 4 to bit 7 in the octet:

– b0 set to ‘1’ = request for narrowband.

– b1 set to ‘1’ = request for wideband.

– b2 set to ‘1’ = request for super-wideband.

– b3 set to ‘1’ = request for fullband.

Each bit in the DATA field indicates a bandwidth that the receiver wants to receive. One or several of these four bits can be set to ‘1’. For example, a request for ‘1110’ indicates that the receiver wants to receive narrowband, wideband or super-wideband speech but not fullband speech. The bandwidth request shall comply with the media type parameters that are negotiated in the session.

10.2.1.9 EVS Channel Aware Request

RTCP_APP_REQ_EPRED: EVS Channel Aware Request

Figure 10.6d: EVS partial redundancy request

Codecs: This request can be used for the EVS codecs when operating in Primary mode.

The DATA field is a 4-bit field and is encoded as described in the table below.

Table 1.b Encoding of the DATA field in the EVS Channel Aware Request.

Index	Partial Redundancy request
0000	13.2 CA-L-O2
0001	13.2 CA-L-O3
0010	13.2 CA-L-O5
0011	13.2 CA-L-O7
0100	13.2 CA-H-O2
0101	13.2 CA-H-O3
0110	13.2 CA-H-O5
0111	13.2 CA-H-O7
1000	Not used
1001	Not used
1010	Not used
1011	Not used
1100	Not used
1101	Not used
1110	Not used
1111	Not used

Since channel-aware mode is only defined for the EVS Primary 13.2 kbps mode then sending an EVS Channel Aware Request also implies changing to the EVS Primary mode and to the 13.2 kbps bit-rate and possibly also changing the audio bandwidth to either WB or SWB.

10.2.1.10 EVS Primary mode to EVS AMR-WB IO mode Switching Request

RTCP_APP_REQ_EP2I: EVS Primary mode to EVS AMR-WB IO mode Switching Request

Figure 10.6e: EVS primary mode to EVS AMR-WB IO mode switching request

Codecs: This request can be used for the EVS codecs when operating in Primary mode.

The DATA field is an 11-bit field where the first 9 bits (b4-b12) are used to indicate the AMR-WB codec modes that are allowed and the 2 last bits (b13 and b14) are flags to set mode-change-period and mode-change-neighbor as follows:

– first 9 bits for mode-set:

– b4 = ‘0’: AMR-WB 6.60 not allowed
b4 = ‘1’: AMR-WB 6.60 allowed,

– b5 = ‘0’: AMR-WB 8.85 not allowed
b5 = ‘1’: AMR-WB 8.85 allowed,

– b6 = ‘0’: AMR-WB 12.65 not allowed
b6 = ‘1’: AMR-WB 12.65 allowed,

– b7 = ‘0’: AMR-WB 14.25 not allowed
b7 = ‘1’: AMR-WB 14.25 allowed,

– b8 = ‘0’: AMR-WB 15.85 not allowed
b8 = ‘1’: AMR-WB 15.85 allowed,

– b9 = ‘0’: AMR-WB 18.25 not allowed
b9 = ‘1’: AMR-WB 18.25 allowed,

– b10 = ‘0’: AMR-WB 19.85 not allowed
b10 = ‘1’: AMR-WB 19.85 allowed,

– b11 = ‘0’: AMR-WB 23.05 not allowed
b11 = ‘1’: AMR-WB 23.05 allowed,

– b12 = ‘0’: AMR-WB 23.85 not allowed
b12 = ‘1’: AMR-WB 23.85 allowed.

– flags:

– b13 = ‘0’: mode-change-period=1,
b13 = ’1’: mode-change-period=2,

– b14 = ‘0’: mode-change-neightbor=0,
b14 = ‘1’: mode-change-neightbor=1.

An MTSI client sending this request shall set at least one of the mode-set bits to ‘1’. An MTSI client receiving a request with all zeroes shall ignore the request.

The mode-set indicated in the EVS Primary mode to EVS AMR-WB IO mode Switching Request can only allow codec modes that have been negotiated in SDP offer-answer. This request cannot be used to allow codec modes that have not been negotiated in SDP offer-answer.

An MTSI client sending this request should also send an RTCP_APP_CMR to indicate the codec mode that should be used after switching to EVS AMR-WB IO mode. An MTSI client receiving this request without a request for a codec mode should use the rules for Initial Codec Mode (ICM) defined in clause 7.5.2.1.6 to determine the codec mode that should be used after switching to EVS AMR-WB IO mode.

The last bit (b15) ‘R’ is reserved for future use. An MTSI client sending this request shall set it to ‘0’. An MTSI client receiving this request shall ignore this bit.

10.2.1.11 EVS AMR-WB IO mode to EVS Primary mode Switching Request

RTCP_APP_REQ_EI2P: EVS AMR-WB IO mode to EVS Primary mode Switching Request

Figure 10.6f: EVS AMR-WB IO mode to EVS Primary mode Switching request

Codecs: This request can be used for the EVS codecs when operating in AMR-WB IO mode.

The DATA field is a 4-bit field which is reserved for future use. All four bits are set to ‘0’.

The bitrates and bandwidths that can be used after switching to EVS Primary mode are the same as negotiated at session setup or in a preceding session modification.

10.2.2 Example use cases

The following examples demonstrate how requests for redundancy and frame aggregation are realised in the RTP stream.

All examples assume that the speech codec generates frames numbered N-10…N in a continuous flow.

Figure 10.7: Flow of parameter sets for encoded frames
Each increment corresponds to a time difference of 20 ms

In the examples below, P-1…P denote the sequence numbers of the packets.

EXAMPLE 1:

An RTCP_APP_REQ_RED request with bit field 000000000000 (no redundancy) and RTCP_APP_REQ_AGG request with value = 0 (no frame aggregation) will yield packets as shown in figure 10.8.

Figure 10.8: Default frame aggregation with one frame per packet

EXAMPLE 2:

An RTCP_APP_REQ_RED request with bit field 000000000001 (100% redundancy and no offset) and an RTCP_APP_REQ_AGG request with value = 0 (no frame aggregation) will yield packets as shown in figure 10.9.

Figure 10.9: Payload packetization with 100 % redundancy and an offset of one packet

EXAMPLE 3:

An RTCP_APP_REQ_RED request with bit field 000000000010 (100% redundancy with offset 1 extra packet) and an RTCP_APP_REQ_AGG request with value = 0 (no frame aggregation) will yield packets as shown in figure 10.10.

Figure 10.10: Payload packetization with 100 % redundancy and an extra offset of one packet

NO_DATA frames must be inserted to fill the gaps between two non-consecutive frames, e.g. between N-2 and N.

EXAMPLE 4:

An RTCP_APP_REQ_RED request with bit field 000000000000 (no redundancy) and RTCP_APP_REQ_AGG request with value = 1 (frame aggregation 2 frames/packet) will yield packets as shown in figure 10.11.

Figure 10.11: Payload packetization with 2 frames aggregated per packet

EXAMPLE 5:

An RTCP_APP_REQ_RED request with bit field 000000000001 (100% redundancy) and an RTCP_APP_REQ_AGG request with value = 1 (frame aggregation 2 frames/packet) will yield packets as shown in figure 10.12.

Figure 10.12: Payload packetization with 100 % redundancy and 2 frames aggregated per packet

EXAMPLE 6:

An RTCP_APP_REQ_RED request with bit field 000000000010 (100% redundancy with offset 1 extra packet) and an RTCP_APP_REQ_AGG request with value = 1 (frame aggregation 2 frames/packet) will yield packets as shown in figure 10.13.

Figure 10.13: Payload packetization with 100 % redundancy,
one extra offset and 2 frames aggregated per packet

10.2.3 SDP negotiation for RTCP-APP

RTCP-APP request messages that can be used are negotiated with SDP using the ‘3gpp_mtsi_app_adapt’ attribute. The syntax for the 3GPP MTSI RTCP-APP adaptation attribute is:

a=3gpp_mtsi_app_adapt:<reqNames>

where:

<reqNames> is a comma-separated list identifying the different request messages (see below).

The ABNF for the RTCP-APP adaptation messages negotiation attribute is the following:

adaptation attribute = "a" "=" "3gpp_mtsi_app_adapt" ":" reqName *("," reqName)

reqName = "RedReq" / "FrameAggReq" / "AmrCmr" / "EvsRateReq" / "EvsBandwidthReq" / "EvsParRedReq" / "EvsIoModeReq" / "EvsPrimaryModeReq"

The name denotes the RTCP APP packet types the SDP sender supportes to receive. The meaning of the values is as follows:

RedReq: Redundancy Request, clause 10.2.1.3

FrameAggReq: Frame Aggregation Request, clause 10.2.1.4

AmrCmr: Codec Mode Request for AMR and AMR-WB, clause 10.2.1.5

EvsRateReq: EVS Primary Rate Request, clause 10.2.1.7

EvsBandwidthReq: EVS Bandwidth Request, clause 10.2.1.8

EvsParRedReq: EVS Partial Redundancy Request, clause 10.2.1.9

EvsIoModeReq: EVS Primary mode to EVS AMR-WB IO mode Switching Request, clause 10.2.1.10

EvsPrimaryModeReq: EVS AMR-WB IO mode to EVS Primary mode Switching Request, clause 10.2.1.11

An MTSI client supporting the reception of any RTCP APP packets defined in the present specification shall indicate the supported RTCP APP packet types in an initial SDP offer or answer it sends using the SDP "a=3gpp_mtsi_app_adapt" attribute. If the answerer receives an "a=3gpp_mtsi_app_adapt" attribute in the SDP offer, it may send the indicated RTCP APP packet types towards the offerer. The answerer shall indicate its capabilties with the "a=3gpp_mtsi_app_adapt" attribute irrespective if an "a=3gpp_mtsi_app_adapt" attribute was received and the capabilities within. If the offerer receives an "a=3gpp_mtsi_app_adapt" attribute in the SDP answer, it may send the indicated RTCP APP packet types towards the answerer.

An MTSI client supporting only AMR and AMR-WB therefore may for instance include the following in the SDP offer:

a=3gpp_mtsi_app_adapt: RedReq,FrameAggReq,AmrCmr

An MTSI client supporting only AMR, AMR-WB and EVS may for instance include the following in the SDP offer:

a=3gpp_mtsi_app_adapt: RedReq,FrameAggReq,AmrCmr,EvsRateReq,EvsBandwidthReq,EvsParRedReq,EvsIoModeReq,EvsPrimaryModeReq

The attribute shall only be used on media level.

When interworking with pre-Rel-12 clients or non-MTSI clients, it may happen that they support the RTCP-APP signalling but not the SDP negotiation for AMR and AMR-WB. An MTSI client failing to negotiate RTCP-APP as described may still try to use the RTCP-APP signalling when requesting adaptation, but the MTSI client shall then also monitor the received media in order to determine if some or all of the adaptation requests included in the RTCP-APP were partially or fully followed or not followed at all. If none of the adaptation requests is followed, not even partially, then this is an indication that the remote client does not support the RTCP-APP signalling. The MTSI client should then try to use other means for triggering the adaptation, for example CMR in the AMR/AMR-WB payload or RTCP Sender Reports/Receiver Reports.

10.3 Video

10.3.1 General

MTSI clients receiving RTCP Receiver Reports (RR) indicating nonzero packet loss shall support adjusting their outgoing bitrate accordingly (see RFC 3550 [9]). Note that for IMS networks, which normally have nonzero packet loss and fairly long round-trip delay, the amount of bitrate reduction specified in RFC 3448 [56] is generally too restrictive for video and may, if used as specified, result in very low video bitrates already at (for IMS) moderate packet loss rates.

A video sender shall support adapting its video output rate based on RTCP reports and TMMBR messages. This adaptation shall be used as described in clauses 10.3.2 to 10.3.6 unless the video sender is explicitly notified that no rate adaptation shall be performed, e.g.by setting the minimum quality bitrate equal to the negotiated bitrate. This adaptation should be performed while maintaining a balance between spatial quality and temporal resolution, which matches the bitrate and image size. Some examples are given in Annex B. For the handling of packet loss signaled through AVPF NACK and PLI, or for rate adaptation with RTCP reports and TMMBR messages, the video sender shall be able to dynamically adapt to the reported conditions, in particular to facilitate the operation of quality-recovery techniques pertinent to the situations. Quality-recovery techniques include, but may not be limited to, adapted intra frame periods, adaptation of random intra macroblock refresh ratios, FEC, and adaptation of the bit rates.

The rate adaptation can be controlled by using the video adaptation parameters defined in clause 17.2. By using the MIN_QUALITY/BIT_RATE/ABSOLUTE or the MIN_QUALITY/BIT_RATE/RELATIVE parameters it is possible to set the minimum bitrate for the adaptation.

10.3.2 Signaling mechanisms

The use of TMMBR and TMMBN depends on the outcome of the SDP offer/answer negotiation, see Clause 6.2.3.2.

If TMMBR and TMMBN are allowed to be used in the session and if the receiving MTSI client in terminal is made aware of a reduction in downlink bandwidth allocation through an explicit indication of the available bandwidth allocation from the network (e.g. due to QoS renegotiation or handoff to another radio access technology), or from measurements such as increased delay at the media receiver, it shall notify the media sender of the new current maximum bitrate using TMMBR. In this context the TMMBR message is used to quickly signal to the other party a reduction in available transport bitrate. If rate adaptation is allowed, the media sending MTSI client shall, after receiving TMMBR, adjust the sent media rate to the requested rate or lower and shall respond by sending TMMBN, as described in CCM [43]. When determining the encoder bitrate the MTSI client needs to compensate for the IP/UDP/RTP overhead since the bitrate indicated in the TMMBR message includes this overhead. To determine TMMBR and TMMBN content, both media sending and media receiving MTSI clients in terminals shall use their best estimates of packet measured overhead size when measured overhead values are not available. If the TMMBR message was sent due to an explicit indication of available bandwidth allocation, the MTSI client in terminal that sent the TMMBR message shall, after receiving the TMMBN, send a SIP UPDATE to the other party to establish the new rate as specified in clause 6.2.7.

It is the media sender’s responsibility to estimate if, and by how much, queue build-up has occurred due to use of a sending rate that was higher than the available throughput, before being able to reduce the sending rate. It is therefore also the media sender’s responsibility to recover the buffering delay by sending with a rate that is lower than what the media receiver has requested in the TMMBR message for some period of time.

If TMMBR and TMMBN are not allowed to be used in the session and if the MTSI client in terminal is made aware of a reduction in downlink bandwidth allocation (e.g. due to QoS renegotiation or handoff to another radio access technology) it shall send a SIP UPDATE to the other party to establish the new rate as specified in clause 6.2.7.

If the receiving MTSI client in terminal is made aware of an increase in downlink bandwidth allocation (determined via separate negotiation) through an explicit indication from the network (e.g. due to QoS renegotiation or handoff to another radio access technology) then, if this has not yet occurred, it shall send a SIP UPDATE to the other party to establish the new rate as specified in clause 6.2.7.

When an MTSI client in terminal receives available bandwidth information from ANBR (see 10.7), it shall not be considered an explicit indication of available bandwidth allocation that requires sending SIP UPDATE as described above. The conditions under which it is allowed to send SIP UPDATE based on ANBR are described in clause 6.2.5.1.

The media sender information in the RTCP Sender Reports (RTCP SR) contains information about how many packets and how much data the media sender has sent. A media receiving MTSI client in terminal may use this information to detect the difference between the sent bitrate (from the remote media sending client) and the received bitrate (in the local media receiving client).

The report blocks in the RTCP Receiver Reports (RTCP RR) or in the RTCP Sender Reports (RTCP SR), contain information about the highest received sequence number, the packet loss rate, the cumulative number of packet losses and interarrival jitter as experienced by the media receiver. A media sending MTSI client in terminal may use this information to detect the difference between the sent bitrate (from the local media sending client) and the received bitrate (in the remote media receiving client) and also to estimate the queue build-up that can happen when congestion occurs somewhere in the path.

To enable proper video rate adaptation, RTCP Reports must be sent frequently enough (e.g. at least twice per second) to allow MTSI clients to detect network congestion. An MTSI client in terminal shall set the RR and RS bandwidth modifiers in the SDP offer/answer to reserve an RTCP bandwidth that is no smaller than the bandwidth reserved by setting the RTCP bandwidth modifiers as follows (see Annex A.6):

– 0 bps for the RS field (at media level);

– 5000 bps for the RR field (at media level).

NOTE 1: In a point-to-point session the MTSI clients in terminals will be reserved, on average, 2500 bps of RTCP bandwidth in each direction when the RTCP bandwidth modifiers are negotiated as described above.

Furthermore, unless there is a clear need to set the RTCP bandwidth higher than specified above, the RTCP bandwidth modifiers in the SDP offer should be set as specified above.

NOTE 2: RFC 3550 recommends that the RTCP bandwidth default be 5% of the media bandwidth. However, this default may be excessive in various scenarios, including 3GPP access networks, and should therefore be carefully evaluated when setting the RR and RS values differently than recommended in this clause.

Another way to estimate the transmitted bitrate is to analyse the size of the packets and the RTP time stamps.

10.3.3 Adaptation triggers

An MTSI client in terminal sending or receiving media needs to know the currently allowed bitrate (). The currently allowed bitrate is the minimum of the bitrate negotiated in SDP offer/answer and the bitrate allowed after the latest preceeding adaptation (e.g. last previous TMMBR message) that increased or decreased the allowed bitrate for the encoder. When no bitrate reduction trigger is received, the value from SDP offer/answer shall be used. The currently allowed bitrate may therefore vary over time.

An MTSI client in terminal sending media shall use at least one adaptation trigger that is based on the reception report blocks in the received RTCP Receiver Reports or in the RTCP Sender Reports. An MTSI client in terminal sending media should also use ANBR as an adaptation trigger.

NOTE: When interworking with non-MTSI clients then it may happen that the remote client only sends RTCP Receiver Reports (or Sender Reports) but does not use any adaptation triggers in its receiver. This may happen even if the remote client supports and uses TMMBR because it is possible that the remote client uses TMMBR only to signal bitrate changes due to handoff to another access and not for dynamic rate adaptation.

An MTSI client in terminal receiving media shall use at least one adaptation trigger that is not ECN. Examples of adaptation triggers are: ANBR, measurements of packet loss rate; measurements of jitter; difference between sending bitrate (e.g. from RTCP SR) and measured received bitrate; differences between sending packet rate (from RTCP SR) and received packet rate; and play-out delay margin (from packet arrival time until their scheduled play-out time).

An MTSI client in terminal sending or receiving media:

– Should use one or more triggers that is capable to detect a needed reduction in throughput of 10% or more. If a trigger requires reception of an RTCP Sender or Receiver Report, the change should be detected within 3 frame durations of reception of the Sender or Receiver Report. If all triggers do not require Sender or Receiver Report reception, the change should be detected within 8 frame durations of the reduction in throughput.

– Shall use one or more triggers that is capable to detect a needed reduction in throughput of 25% or more. If a trigger requires reception of an RTCP Sender or Receiver Report, the change shall be detected within 6 frame durations of reception of the Sender or Receiver Report. If all triggers do not require Sender or Receiver Report reception, the change shall be detected within 15 frame durations of the reduction in throughput.

If an MTSI client in terminal receiving media uses DL ANBR to detect a needed reduction in throughput of 10% or more, it should send RTCP TMMBR to request the highest bitrate that is lower than ANBR and all other adaptation triggers.

An MTSI client in terminal sending media should take UL ANBR into account and adapt the sent bitrate to the highest bitrate that is still lower than or equal to the minimum of the adaptation triggers, and should then send RTCP TMMBN based on this bitrate.

An MTSI client in terminal receiving media shall use at least one method to estimate if and by how much the bitrate can be increased (). A method for how an MTSI client in terminal can estimate when and by how much the bitrate can be increased is described in Annex C.2.5.

10.3.4 Sender behavior, downswitching

10.3.4.1 Downswitching divided into phases

The downswitching of the encoder bitrate in response to received adaptation requests or performance metrics is divided into two phases:

– First a rate reduction phase, where the bitrate is reduced from the target bitrate currently used by the sender, which is too high for the current operating conditions, to the bitrate that is suitable for the current operating conditions.

– Then a delay recovery phase, where the delay of any buffered data is recovered.

These phases are described in more detail below.

Annex C.2 gives a further description of the downswitching procedure.

10.3.4.2 Rate reduction phase

An MTSI client in terminal sending media should be able to immediately change the sending bitrate to the bitrate requested in a received TMMBR message.

Due to differences in client implementations (video encoder, cameras, etc), a sending MTSI client in terminal may or may not be able to immediately change the sending bitrate to the bitrate requested in a TMMBR message. The capability to immediately change the bitrate may also depend on whether the bitrate adaptation requires changing the frame rate and/or the video resolution.

When a reduction of the bitrate is requested with TMMBR and the MTSI client in terminal cannot immediately adapt to the requested bitrate then this will introduce excessive bits () since the sending bitrate will be higher than the available bitrate. These excessive bits will cause buffering, packet delays and sometimes packet losses. In this case, the MTSI client in terminal shall calculate the amount of excessive bits that are created until the bitrate has been reduced to the requested bitrate. In this case, the sending MTSI client in terminal:

– should adapt the encoding bitrate such that:

(10.3.4.2-1)

– shall adapt the encoding bitrate such that:

(10.3.4.2-2)

where:

(10.3.4.2-3)

and: is the adaptation time required by the Worst-Case Adaptation Algorithm, see Annex C.2.4, in this case 1 second;

is the bit-rate used before the adaptation starts;

is the bit-rate requested in the TMMBR message.

The is calculated over the , which is from the time when the TMMBR message is received until encoder has adapted down to the , see also Annex C.2.4. The bitrate used by the encoder is expected to vary from frame to frame. The bitrate should therefore be averaged using a sliding window over at least the last 5 frame durations before comparing it to the .

An MTSI client in terminal reducing the bitrate:

– should have adapted down to after the TMMBR message was received,

– shall have adapted down to after the TMMBR message was received.

The above procedure applies only when a bitrate reduction is requested with a TMMBR message. When the bitrate is increased, after the congestion has been cleared, then the above procedure does not apply.

Annex C.2.4 gives a further description of the above requirements and recommendations and how the encoder should behave during the rate reducing phase.

10.3.4.3 Delay recovery phase

After adapting down to the requested bit-rate the sending MTSI client in terminal shall use a delay recovery phase where the bit-rate is (on average) lower than the requested bit-rate until the buffering delay caused by the excessive bits () described in clause 10.3.4.2 have been recovered, see also Annex C.2.4 and C.2.6.

10.3.5 Sender behavior, up-switching

An MTSI client in terminal sending media with a bitrate lower than currently allowed bitrate should try to increase the bitrate up to the currently allowed bitrate. The bitrate of the encoded media is increased slowly until the currently allowed bitrate is reached while monitoring that the quality is maintained, i.e. no packet losses and no delay should be introduced because of the up-switch.

An MTSI client in terminal sending media with a bitrate according to the currently allowed bitrate and receiving a TMMBR request for increasing the bitrate:

– should ramp up the bitrate to the currently allowed bitrate within 0.5 seconds,

– shall ramp up the bitrate to the currently allowed bitrate within 1 second.

If during the up-switch procedure the MTSI client receives a TMMBR message for reducing the bitrate then the up-switch shall be aborted and the down-switch is started as described in clause 10.3.4.

10.3.6 Receiver behavior, down-switching

An MTSI client in terminal receiving media and detecting that the throughput is reduced shall behave as follows:

– When detecting that the throughput is reduced by more than 10% then it should send a TMMBR message requesting a bitrate that is at least 10% lower than the currently allowed bitrate,

– When detecting that the throughput is reduced by more than 25% then it shall send a TMMBR message requesting a bitrate that is at least 25% lower than the currently allowed bitrate.

TMMBR messages for down-switch are urgent feedback messages and shall be sent as soon as possibly. AVPF early mode or immediate mode, [40] shall be used whenever possible.

10.3.7 Receiver behavior, up-switch

An MTSI client in terminal receiving media and detecting that the bitrate can be increase shall behave as follows:

– If the bitrate can be increased by at least 5% then the MTSI client in terminal should send a TMMBR message requesting a bitrate that is:

(10.3.7-1)

– If the bitrate can be increased by at least 15% then the MTSI client in terminal shall send a TMMBR message requesting a bitrate that is:

(10.3.7-2)

TMMBR messages for up-switch shall be sent with the normal compound RTCP packets following the normal RTCP transmission rules defined for the RTP/AVP profile, [9]. This is to not unnecessarily prevent possible subsequent urgent feedback messages, e.g. for down-switch, to be sent using AVPF early mode or immediate mode.

10.3.8 ECN triggered adaptation

ECN triggered adaptation may be used in addition to other adaptation triggers. However, when ECN is used an MTSI client in terminal receiving media shall also use at least one other adaptation trigger, see clause 10.3.3. When ECN is used, an MTSI client in terminal sending media shall also monitor the received RTCP SR/RR. If ANBR described in clause 10.7 is used, the bitrate value used in that bitrate recommendation shall be seen as independent from ECN and thus not taking ECN-CE markings into account. It is therefore possible that ECN-CE and ANBR with a decreased bitrate value both report on the same detected restriction.

NOTE 1: When ECN is negotiated, some networks in the path may allow ECN signalling to pass through even though the network does not actively use ECN to indicate congestion. For example, in a session between an LTE UE and a HSPA UE, the LTE access may allow and use ECN, but the backbone and the HSPA access may allow ECN to be used without marking packets with ECN-CE if congestion occurs in the backbone or in the HSPA access side.

Table 10.2 defines a mandatory set of parameters that are used by the ECN triggered adaptation. 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.

Table 10.2: Configuration parameters when ECN is used as a trigger

Parameter	Description
ECN_min_rate_relative	Lower boundary (proportion of the bit rate negotiated for the video stream) 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: Same as INITIAL_CODEC_RATE for video if defined, otherwise 50%
ECN_min_rate_absolute	Lower boundary (kbps) 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: 48 kbps
ECN_congestion_wait	The 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 ECN_min_rate parameter is set to the larger of the ECN_min_rate_relative and ECN_min_rate_absolute values. Since the ECN_min_rate_relative parameter is relative to the outcome of the offer-answer negotiation this means that the ECN_min_rate value may be different for different sessions. The ECN_min_rate_absolute parameter is used to prevent too low bit rates for video, which would result in too low quality.

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 ECN_min_rate when ECN-CE is detected, while it may reduce the media bit-rate even further for bad radio conditions when high PLR is detected.

Multiple adaptation algorithms can be used in parallel, for example ECN-triggered adaptation, ANBR, and Packet Loss Rate-triggered adaptation. When multiple adaptation trigger 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.

NOTE 2: For example, if the ECN-triggered adaptation indicates that 100kbps should be used and if the PLR-triggered adaptation indicates that 75kbps should be used then the rate that the MTSI client uses should be no higher than min(100, 75) = 75kbps.

10.4 Text

Rate adaptation (downgrade of used bandwidth) of text shall follow the recommendation in clause 9 of RFC 4103 [31]. RTCP reports are used as indicator of loss rate over the channel.

When the transmission interval has been increased in order to handle a congestion situation, return to normal interval shall be done when RTCP reports low loss.

10.5 Explicit Congestion Notification

When the (e)NodeB experiences congestion it may set the ECN bits in the IP header to ‘11’ to indicate "Congestion Experienced" for packets that have been marked with ECN Capable Transport (ECT), [83], [84].

Adaptation requests should be sent in response to ECN congestion events. Clauses 10.2 and 10.3 describe adaptation for speech and video when ECN-CE is detected.

10.6 Using the a=bw-info attribute for adaptation

This sub-clause outlines a few generic recommendations for how the bandwidth properties signalled with the ‘a=bw-info’ may be used for the adaptation. Media specific usage may override these guidelines.

During the session, when adaptation is needed:

– The bit rate range from the Minimum Desired Bandwidth up to the Maximum Desired Bandwidth (if different) defines the most commonly used adaptation range. The primary means for the adaptation in this range is adapting the source encoding while adapting the RTP packetization should remain unchanged. This includes adapting the frame range for video.

– When adapting in this range, downwards rate adaptation should be fast while upwards rate adaptation should be relatively slow. This is because when these bandwidth properties are different then it is likely that an MBR>GBR bearer is used and the performance defined with the QoS parameters is only guaranteed when the bit rate does not exceed the GBR [90].

– The bit rate range above the Maximum Desired Bandwidth up to the Maximum Supported Bandwidth (if different) is mainly intended for sending application layer redundancy, in case additional bandwidth is needed for this purpose.

– It is preferable to first try to overcome the degraded operating conditions by reducing the bit rate, at least down to the Minimum Desired Bandwidth or even down to the Minimum Supported Bandwidth, before adding application layer redundancy.

– The bit rate range below the Minimum Desired Bandwidth down to the Minimum Supported Bandwidth (if different) is mainly intended to be used to keep the session alive during severely degraded operating conditions. For video, this can be achieved by e.g. reducing the resolution or the frame rate. For speech, this can be achieved by using frame aggregation or using a codec mode below the Minimum Desired Bandwidth. The end-to-end delay may be significantly increased and/or the quality may be significantly reduced. It may still be preferable to keep the media alive compared to e.g. video freezing, even if the quality is degraded.

– The Minimum Supported Bandwidth may be set larger than zero to limit the adaptation, e.g. to fulfil certain service requirements on end-to-end delay or minimum quality level. If the throughput is so low that not even the Minimum Supported Bandwidth can be fulfilled then there is likely no reason to continue using that media type in the session.

10.7 Access network bitrate recommendation

10.7.1 General

Support and use of access network bitrate recommendations (ANBR) as described in this clause are optional for MTSI clients in terminal. Clause 10.7 does not apply to an MTSI client in terminal that does not support the ANBR message.

Some access networks may provide the MTSI client in terminal with ANBR messages, separately per local access bearer and separately for the local uplink and downlink. It is expected that an ANBR message is sent to the MTSI client in terminal whenever the access network finds it reasonable to inform about a change in the recommended bitrate, such that the MTSI client in terminal is generally provided with up-to-date recommended bitrate information.

In general, a single access bearer can carry multiple RTP streams, in which case ANBR applies to the sum of the individual RTP stream bitrates on that bearer.

Access networks supporting ANBR may also support a corresponding ANBR Query (ANBRQ) message, which allows the MTSI client in terminal to query the network for updated ANBR information. ANBRQ shall only be used to query for an ANBR update when media bitrate is to be increased, not for media bitrate decrease.

The ANBR and ANBRQ messages, as used in this clause, are conceptual messages that allows generalization of the description between different accesses, e.g. LTE (see 10.7.4) and NR (see 10.7.5) and wireless LAN. There shall be a defined mapping between the conceptual ANBR/ANBRQ and actual messages for each access where ANBR/ANBRQ signaling is to be used. The format of such access-specific ANBR/ANBRQ messages may differ between different types of access networks, and there may not even exist a one-to-one mapping of messages. The recommended bitrate value in ANBR/ANBRQ is here defined to include IP and higher layer overhead, including bitrate used for RTCP signaling (as opposed to e.g. b=AS line in SDP, which does not include RTCP). Other definitions can be used by the individual access network mappings (for LTE and NR, the recommended physical layer bitrate is signalled by the access network, see clauses 10.7.4 and 10.7.5), e.g., including overhead below IP layer that is added by the access network, and the UE shall then perform appropriate value translation, e.g. adjusting for use of ROHC and removing the lower layer overhead.

While the sizes of all other protocol overheads are static or change slightly during an MTSI session, the size of ROHC header is highly dynamic, and hence there is no deterministic and standardized way to map the recommended physical layer bitrate into the IP layer bitrate. The queried physical layer bitrate should be set considering all the L2 and above headers.

NOTE 1: The UE may determine the corresponding IP layer bitrate based on the long-term average of the IP packet sizes, L2 header sizes, and ROHC header sizes, but the translation methodologies and the estimation error levels required to implement accurate media bitrate adaptation have not been specified.

NOTE 2: The eNodeB may determine the corresponding IP layer bitrate based on the long-term average of the IP packet sizes, L2 header sizes, and ROHC header sizes, but the translation methodologies and the estimation error levels required to implement accurate media bitrate adaptation have not been specified.

NOTE 3: The recommended/queried bitrate as signalled over the LTE and NR access is defined to be in kbps at the physical layer. The uplink/downlink bitrate at the physical layer is , where is the bit-length of the k-th successfully transmitted/received TB by the UE within the window T. In TS 36.321 and 38.321, a window length of 2000 ms is applied.

10.7.2 Relation to session signaling bitrate information

ANBR is only a recommendation and does not change any bitrate restrictions established by session signaling, described in clause 6.2.5.1. Such unaffected session signaling bitrate information includes:

– SDP "b=" lines, including "b=AS", "b=RS", and "b=RR".

– SDP "a=bw-info" lines, if present.

– Codec-specific min/max bitrates, based on codec configuration and/or packetization parameters.

– MBR and GBR QoS parameters.

An ANBR value with a bitrate above a maximum bitrate limit established by any of the above shall therefore instead be considered as a bitrate recommendation for the lowest of the above listed maximum bitrates (except for GBR that is not considered a maximum bitrate). When using a codec configuration with discrete bitrate steps, and if the ANBR value does not exactly match such discrete codec bitrate, it shall be considered as a bitrate recommendation for the next lower, signaled codec bitrate.

If a GBR bearer is used (GBR > 0), an ANBR value below GBR may be ignored, but the MTSI client in terminal should then be prepared to handle a higher than target packet loss and / or delay for the affected bearer. An ANBR value of 0 should be taken as a recommendation to temporarily stop sending RTP media on the affected bearer, without re-negotiating the session, with the exception for RTP media related to the first "m=audio" line in the SDP that shall never temporarily stop sending based on ANBR value 0. Corresponding RTCP transmission shall, when enabled, continue even when RTP media is stopped due to ANBR value 0.

10.7.3 Use with dynamic bitrate adaptation

10.7.3.1 General

An MTSI client in terminal shall use the ANBR message as adaptation trigger, taking other available triggers into account. The same principle shall apply for both speech and video, adapting to the lowest bitrate resulting from any of the possibly multiple, available triggers. Clauses 10.2 and 10.3 describe adaptation details for speech and video. Use of ANBR in combination with ECN signaling is described in clause 10.3.8.

A received ANBR message for a certain access bearer and media direction shall be considered valid for use as input to adaptation trigger evaluation until either another ANBR message is received for the same access bearer and media direction, until that access bearer is closed, or until the SIP session is either re-negotiated or closed.

10.7.3.2 Adaptation of sent media

This relates to adaptation of the media in RTP streams that the MTSI client in terminal sends in the uplink direction, controlling the local media encoder bitrate.

The below figures with signaling diagrams describe ANBR usage for a single media, regardless if that is voice or video. The "Request max" message in those figures is a generalized application level message that corresponds to RTCP TMMBR for video and CMR or RTCP-APP for voice. Similarily, the "Notify max" message is a generalized application level message that corresponds to RTCP TMMBN for video. "Notify max" has no counterpart for voice and is therefore not used for voice.

An MTSI client in terminal that rececives both ANBR with bitrate R0 and a "Request max" message with bitrate R1 for its media sending direction shall use min(R0, R1) as the combined bitrate for those two adaptation triggers.

Figure 10.7-1 Uplink bitrate decrease based on ANBR

Figure 10.7-2 Uplink bitrate increase based on ANBR

When an MTSI client in terminal receives an ANBR message for the local uplink that triggers an adaptation decision (step 4 of Figures 10.7-1 and 10.7-2):

1. For both video and voice, an adaptation resulting in a reduction of the media sender bitrate shall be initiated immediately without further signaling (step 6 of Figure 10.7-1).

2. For the case of video and if TMMBR / TMMBN are supported in the session:

a) If the adaptation decision means that the MTSI client in terminal adapts bitrate below the most recently received TMMBR message (if any, step 4 of Figures 10.7-1 or 10.7-2), the media sender itself owns the uplink bitrate restriction and a corresponding TMMBN message shall be sent, notifying the remote media receiver of this changed local uplink restriction (step 7 of Figure 10.7-1 or step 5 of Figure 10.7-2). Such TMMBN message has the media sender’s own SSRC included in the bounding set [43]. Note that only the media sender or receiving TMMBR with a lower bitrate can then remove such own restriction, which means that TMMBR messages with a higher bitrate received from the remote media receiver will be ineffective and ignored. The media sender can repeat this procedure and either increase or decrease the used bitrate based on subsequent local uplink ANBR, sending corresponding TMMBN also for those changes, as long as the MTSI client in terminal does not receive a TMMBR from the remote MTSI client with a bitrate lower than the most recently sent TMMBN.

b) An adaptation resulting in an increase of the media sender bitrate in uplink (Figure 10.7-2) shall delay the media bitrate increase (step 6 of Figure 10.7-2) to allow sufficient time for the remote media receiver to receive and react to the TMMBN in bullet 2.a above, as described by section 3.5.4 of CCM [43] (steps 7-9 of Figure 10.7-2). After such delay, the media sender bitrate is increased (step 12 of Figure 10.7-2). The bitrate increase shall take all available adaptation triggers into account, which can cause the bitrate increase to be separated into several steps (see clause C.2.5).

c) It is recommended that the bitrate in a TMMBN from bullet 2.b) that is pre-announcing an increase in the media sender bitrate in uplink is set to correspond to the received ANBR message and not to the next bitrate step in a step-wise increase (see clause 10.3.5), to avoid unnecessary TMMBN, ANBRQ, and ANBR signaling (see also bullet 4) below).

3. For the case of voice, an adaptation resulting in an increase of the media sender bitrate in uplink shall result in an increase of media sender bitrate at the earliest opportunity (step 6 of Figure 10.7-2), taking other adaptation triggers into account, such as CMR.

Figure 10.7-3 Downlink bitrate decrease based on ANBR through application signaling

Figure 10.7-4 Downlink bitrate increase based on ANBR through application signaling

When an MTSI client in terminal receives application signaling for bitrate adaptation of media, such as CMR (for speech) or TMMBR (for video), that triggers an adaptation decision (step 4 of Figure 10.7-3 or step 6 of Figure 10.7-4):

4. For video and if TMMBR is supported in the session, when receiving a TMMBR that would result in an increase of the media sender bitrate in uplink direction (step 6 of Figure 10.7-4), the media sender shall take all available adaptation triggers for the local uplink into account, e.g. any bitrate limit from the most recently received ANBR message. If the media sender has reason to believe that the most recently received ANBR for its uplink no longer applies, it may send an ANBRQ message for its uplink (step 7 of Figure 10.7-4), if supported, to trigger receiving an ANBR message with recent information (step 8 of Figure 10.7-4) before deciding on what bitrate value to send in a TMMBN (step 10 of Figure 10.7-4) and to use for media in the uplink direction (step 11 of Figure 10.7-4).

5. For voice, when receiving a CMR that would result in an increase of the media sender bitrate in uplink direction (step 6 of Figure 10.7-4), the media sender shall take all available adaptation triggers for the local uplink into account, e.g. any bitrate limit from the most recently received ANBR message. If the media sender has reason to believe that the most recently received ANBR for its uplink no longer applies, it may send an ANBRQ message for its uplink (step 7 of Figure 10.7-4), if supported, to trigger receiving an ANBR message with recent information (step 8 of Figure 10.7-4) before deciding on what voice mode to use in the uplink direction (step 11 of Figure 10.7-4).

10.7.3.3 Adaptation of received media

This relates to adaptation of the media in RTP streams that the MTSI client in terminal receives in the downlink direction, which can require sending application-level messages to adapt the remote media encoder bitrate.

When an MTSI client in terminal receives an ANBR message for the local downlink that triggers an adaptation decision (step 2 of Figure 10.7-3 or step 4 of Figure 10.7-4):

1. For the case of video and if TMMBR / TMMBN are supported in the session:

a) A corresponding TMMBR message requesting the remote media sender to change its rate to match the local downlink restriction shall be sent, as described in clause 10.3.2 (step 4 of Figure 10.7-3 or step 6 of Figure 10.7-4).

NOTE: Adaptation is not triggered if the most recently received TMMBN from the remote media sender indicated a lower bitrate than would be included in a TMMBR message, because the remote media sender is then owning the bitrate limit itself (similar to bullet 2.a of the local uplink in clause 10.7.3.2 above).

b) It is recommended that the bitrate in a TMMBR from bullet 1.a) that is increasing the media sender bitrate is set to correspond to the most recently received ANBR message, to avoid unnecessary TMMBR, ANBRQ, and ANBR signaling caused by a possible step-wise increase (see also bullet 2.c in 10.7.3.2 above).

2. For the case of voice, adaptation signaling to match the local downlink restriction shall be initiated towards the remote media sender, as described in clause 10.2 (step 4 of Figure 10.7-3 or step 6 of Figure 10.7-4).

When an MTSI client in terminal receives application signaling for bitrate adaptation related to received media, such as TMMBN (for video):

3. A media receiver receiving a TMMBN with increased bitrate and where the remote media sender owns the restriction (see bullet 2.a of 10.7.3.2 and step 5 of Figure 10.7-2) shall re-evaluate its downlink adaptation triggers and, if an adaptation decision arrives at a lower bitrate value than in the received TMMBN (step 5 of Figure 10.7-2), send a TMMBR with that lower bitrate, as described by section 3.5.4 of CCM [43]. When deciding whether or not to send TMMBR, the media receiver shall take all available adaptation triggers into account, e.g. bitrate limit from the most recently received downlink ANBR message. If the media receiver has reason to believe the most recently received ANBR for its downlink no longer applies, it may send an ANBRQ message for its downlink (step 7 of Figure 10.7-2), if supported, to trigger receiving an ANBR message with recent information (step 8 of Figure 10.7-2).

10.7.4 Message mapping for LTE access

When using LTE access, ANBR is mapped to a MAC level message named "Recommended bit rate MAC Control Element" sent by the eNodeB and applicable to a specific dedicated bearer, as described by [85] and [157]. Similarly, when using LTE access, ANBRQ is mapped to a MAC level message named "Recommended bit rate query MAC Control Element" sent to the eNodeB and applicable to a specific, existing dedicated bearer, as described by [85] and [157]. An MTSI client in terminal using LTE access may support ANBR and ANBRQ signaling.

10.7.5 Message mapping for NR access

When using NR access, ANBR is mapped to a MAC level message named "Recommended bit rate MAC Control Element" sent by the gNB and applicable to a specific logical channel which is mapped to the single media flow (e.g., audio or video) to which the recommended bit rate applies. Similarly, when using NR access, ANBRQ is mapped to a MAC level message named "Recommended bit rate query MAC Control Element" sent to the gNB and applicable to a specific, existing logical channel which is mapped to the single media flow to which the recommended bit rate applies. An MTSI client in terminal using NR access may support ANBR and ANBRQ signaling.