Content for TS 26.114 Word version: 18.8.0

0… 3… 4… 5… 6… 6.2.3… 6.2.5… 6.2.7… 6.2.10… 7… 7.5… 8… 9… 10… 10.2.1.6… 10.2.2… 10.3… 10.4… 11… 12… 12.3… 12.7… 13a… 16… 16.5… 17… 18… 19… A… A.3… A.4… A.5… A.10… A.14… A.15… B… C… C.1.3… C.1.3.5 C.2… D E… E.18… E.31… G… K… L… M… N… O… P… P.3 Q… R… S… T… U… V… W… X… Y… Y.6… Y.6.4… Y.6.5… Y.7…

10.4 Text 10.5 Explicit Congestion Notification 10.6 Using the a=bw-info attribute for adaptation 10.7 Access network bitrate recommendation 10.7.1 General 10.7.2 Relation to session signaling bitrate information 10.7.3 Use with dynamic bitrate adaptation 10.7.3.1 General 10.7.3.2 Adaptation of sent media 10.7.3.3 Adaptation of received media 10.7.4 Message mapping for LTE access 10.7.5 Message mapping for NR access
...

10.4 Text p. 131

Rate adaptation (downgrade of used bandwidth) of text shall follow the recommendation in Section 9 of RFC 4103. 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 |R9| p. 132

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), (RFC 3168), RFC 6679.

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 |R13| p. 132

This subclause 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 (TS 23.203).
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 |R14| p. 132

10.7.1 General p. 132

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 clause 10.7.4) and NR (see clause 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 clause 10.7.4 and clause 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.

10.7.2 Relation to session signaling bitrate information p. 133

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

10.7.3.1 General p. 134

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

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.

Reproduction of 3GPP TS 26.114, Fig. 10.7-1: Uplink bitrate decrease based on ANBR

Figure 10.7-1: Uplink bitrate decrease based on ANBR

Reproduction of 3GPP TS 26.114, Fig. 10.7-2: Uplink bitrate increase 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 Figure 10.7-1 and Figure 10.7-2):

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

Step 2.

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

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 Figure 10.7-1 and Figure 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, RFC 5104. 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.
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 RFC 5104 (CCM) (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).
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).

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

Reproduction of 3GPP TS 26.114, Fig. 10.7-3: Downlink bitrate decrease based on ANBR through application signaling

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

Reproduction of 3GPP TS 26.114, Fig. 10.7-4: Downlink bitrate increase 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):

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

Step 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 p. 137

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):

Step 1.

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

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).
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 clause 10.7.3.2 above).

Step 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):

Step 3.

A media receiver receiving a TMMBN with increased bitrate and where the remote media sender owns the restriction (see bullet 2.a of clause 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 RFC 5104 (CCM). 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 p. 137

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 TS 36.300 and TS 36.321. 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 TS 36.300 and TS 36.321. An MTSI client in terminal using LTE access may support ANBR and ANBRQ signaling.

10.7.5 Message mapping for NR access |R15| p. 137

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.