Content for  TS 26.114  Word version:  18.5.0

MTSI clients receiving RTCP Receiver Reports (RR) indicating nonzero packet loss shall support adjusting their outgoing bitrate accordingly (see RFC 3550). 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 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.

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, RFC 5104. 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 clause 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).

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. Another way to estimate the transmitted bitrate is to analyse the size of the packets and the RTP time stamps.

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

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.

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, RFC 4585 shall be used whenever possible.

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:
  requested_bitrate= min((currently_allowed_bitrate+ rate_increase_step),negotiated_bitrate)
  (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:
  requested bitrate = {

  ≥ min((currently_allowed_bitrate+0.8*rate_increase_step),negotiated_bitrate)

  ≤ min((currently_allowed_bitrate+ rate_increase_step),negotiated_bitrate)
  (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, RFC 3550. 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.

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

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