Tech-invite3GPPspaceIETF RFCsSIP
index21222324252627282931323334353637384‑5x

Content for  TS 26.114  Word version:  18.1.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.7…

 

10.3  Videop. 117

10.3.1  General |R12|p. 117

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

10.3.2  Signaling mechanisms |R12|p. 117

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

10.3.3  Adaptation triggers |R12|p. 118

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

10.3.4  Sender behavior, downswitching |R12|p. 119

10.3.4.1  Downswitching divided into phasesp. 119

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

10.3.4.2  Rate reduction phasep. 119

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 (excess_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:
    excess_bits ≤ 0.5*excess_bits_ wc
    (10.3.4.2-1)
  • shall adapt the encoding bitrate such that:
    excess_bits ≤ exess_bits_wc
    (10.3.4.2-2)
where:
excess_bits_wc = adapt_time_wc*(prev_rate - new_rate)
(10.3.4.2-3)
and:
adapt_time_wc is the adaptation time required by the Worst-Case Adaptation Algorithm, see Annex C.2.4, in this case 1 second;
prev_rate is the bit-rate used before the adaptation starts;
new_rate is the bit-rate requested in the TMMBR message.
The excess_bits is calculated over the measurement_window, which is from the time when the TMMBR message is received until encoder has adapted down to the new_rate, 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 new_rate.
An MTSI client in terminal reducing the bitrate:
  • should have adapted down to new_rate 1.5*adapt_time_wc after the TMMBR message was received,
  • shall have adapted down to new_rate 2* adapt_time_wc 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.
Up

10.3.4.3  Delay recovery phasep. 120

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 (excess_bits) described in clause 10.3.4.2 have been recovered, see also Annex C.2.4 and C.2.6.
Up

10.3.5  Sender behavior, up-switching |R12|p. 120

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

10.3.6  Receiver behavior, down-switching |R12|p. 121

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

10.3.7  Receiver behavior, up-switch |R12|p. 121

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, [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.
Up

10.3.8  ECN triggered adaptation |R12|p. 121

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.
Parameter Description
ECN_min_rate_relativeLower 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_absoluteLower 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. vDefault value: 48 kbps
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 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.
Up

Up   Top   ToC