19 Additional bandwidth information

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

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

19.1 General

This clause describes additional bandwidth properties that can be used when the existing bandwidth modifiers (b=AS, etc) give insufficient information. The additional information can be used to, for example (but not limited to): align the resource allocation end-to-end; align the bearer setup in different networks; or to assist how the MTSI clients should adapt in case of degraded operating conditions. The bandwidth properties are defined in clause 19.2.

A new SDP attribute ‘a=bw-info’ is defined in clause 19.3 and can be used to negotiate the additional bandwidth properties end-to-end. The SDP attribute allows for future extensions.

The IANA registration information on the new SDP attribute is provided in Annex M.6.

19.2 Bandwidth properties

19.2.1 General description

This clause defines in total seven bandwidth properties, which can be used both for sending and receiving direction. When the Maximum Supported Bandwidth property is defined for the receiving direction then this is semantically very similar to the b=AS parameter.

Four bandwidth properties are defined to describe different transport bandwidths:

– Maximum Supported Bandwidth

– Maximum Desired Bandwidth

– Minimum Desired Bandwidth

– Minimum Supported Bandwidth

These bandwidth properties shall include the IP, UDP and RTP overhead.

NOTE 1: Corresponding bandwidth parameters excluding IP, UDP and RTP overhead can be defined in the future but are not included here.

Since the above bandwidth properties include the IP, UDP and RTP overhead, the following bandwidth properties are defined to assist the re-calculation of the above bandwidth properties, e.g. when a MGW does conversion between different IP versions and therefore need to re-calculate these values:

– IP version

– Maximum packet rate

– Minimum packet rate

Detailed descriptions for these bandwidth properties are given in the following sub-sections.

The motivations for defining these properties are:

– The best compromise between quality and network utilization is reached when the media uses bandwidths from the Minimum Desired Bandwidth up to the Maximum Desired Bandwidth, which is therefore the most preferred bandwidth range. The higher end of this range should preferably be used for most sessions. When bitrate adaptation is needed due to degraded operating conditions, it may require changing the bandwidth down towards the Minimum Desired Bandwidth.

– Bandwidths below the Minimum Desired Bandwidth, down to the Minimum Supported Bandwidth, may be used during poor operating conditions, although this should happen rarely. If the operating conditions are so poor that not even media using Minimum Supported Bandwidth can be maintained then the media may be stopped or the session may be closed.

– Bandwidths above the Maximum Desired Bandwidth, up to the Maximum Supported Bandwidth, can be used to provide room for redundancy so that the media may survive during very bad operating conditions and when bandwidth reduction alone is unable to provide sufficient quality. This range should be used rarely.

NOTE 2: Increasing the bandwidth during bad operating conditions is an exception. Normally, the end-points ought to reduce the bandwidth. However, there are cases when it is not possible to reduce the bandwidth. For example, when AMR 4.75 kbps is used then the encoding bitrate cannot be reduced any further. It is then possible to use frame aggregation to reduce the IP/UDP/RTP overhead. However, if the limitation is in the RAN, where ROHC is used, then this will have limited effect, possibly even no effect at all. In this case, the only remaining option to improve the probability that speech reaches the receiving end-point is to allow the end-points to use redundancy, even if this means using a higher bandwidth. Otherwise, it is likely that the session will be terminated prematurely. This specification therefore allows for using up to 300% redundancy, as described in clause 9.2.1.

This means that the following relationships apply:

– Minimum Supported Bandwidth ≤ Minimum Desired Bandwidth

– Minimum Desired Bandwidth ≤ Maximum Desired Bandwidth

– Maximum Desired Bandwidth ≤ Maximum Supported Bandwidth

19.2.2 Maximum Supported Bandwidth

Definition:

Identifies the highest bandwidth that can be used in the session during any operating conditions (including redundancy).

Should be used to set MBR.

Should also be used to set GBR for MBR=GBR bearers.

The unit for this bandwidth property shall be kbps.

Usage during the session:

The additional bandwidth for redundancy should only be used if adapting the bitrate to lower values, down to the Minimum Supported Bandwidth, fails to provide sufficient quality.

Quality aspects:

When additional bandwidth is allocated for redundancy, the resilience against losses should be improved. It should however be expected that the end-to-end delay will be longer than for the normal operating range.

19.2.3 Maximum Desired Bandwidth

Definition:

Identifies the highest bandwidth that should be used in most cases during normal operating conditions. This normally corresponds to the maximum bitrate allowed for the encoding.

The unit for this bandwidth property shall be kbps.

Usage during the session:

The adaptation should ensure that bandwidths up to the Maximum Desired Bandwidth are used whenever possible.

Quality aspects:

Using bandwidths in the higher end of the Minimum Desired Bandwidth ~ Maximum Desired Bandwidth range should give the intended encoding quality and end-to-end delay.

19.2.4 Minimum Desired Bandwidth

Definition:

Identifies the lowest bandwidth that should be used in the session during relatively normal or slightly degraded operating conditions.

Used for setting GBR for MBR>GBR bearers.

The unit for this bandwidth property shall be kbps.

Usage during the session:

Bandwidths in the lower end of the Minimum Desired Bandwidth ~ Maximum Desired Bandwidth should be used less frequently, mainly during periods with high load and/or degraded operating conditions.

The bandwidth used by media can be lower than the Minimum Desired Bandwidth, for example during DTX periods or lower rate operation of Source-Controlled Variable Bit Rate modes, e.g. EVS 5.9 VBR, for speech or when DTMF is being transmitted instead of speech.

Quality aspects:

Using bandwidths in the lower end of this range can give slightly reduced encoding quality but should not give increased end-to-end delay.

For video, this bandwidth should be selected such that the video is still relatively smooth.

19.2.5 Minimum Supported Bandwidth

Definition:

Identifies the lowest bandwidth that may be used in the session during exceptional operating conditions.

The unit for this bandwidth property shall be kbps.

Usage during the session:

Bandwidths below the Minimum Desired Bandwidth, down to the Minimum Supported Bandwidth, should be used quite rarely, mainly for severely degraded operating conditions.

If the operating conditions are so poor that not even Minimum Supported Bandwidth can be maintained then the session can be terminated.

The bandwidth used by media can deliberately be lower than the Minimum Supported Bandwidth, for example during DTX periods or lower rate operation of Source-Controlled Variable Bit Rate modes, e.g. EVS 5.9 VBR, for speech or when DTMF is being transmitted instead of speech. This is not to be considered a violation of the bandwidth parameter.

Quality aspects:

It can be expected that the encoding quality is reduced for these bandwidths and also that the end-to-end delay is increased.

19.2.6 IP version

Definition:

Identifies the IP version used for the calculation of the bandwidth properties.

This bandwidth property shall have the numerical values 4 or 6.

Usage during the session:

It may happen that gateways performing IPv4-IPv6 conversion re-calculate the bandwidth modifiers, e.g. b=AS, while leaving the bandwidths indicated with the ‘a=bw-info’ attribute unchaged. It is therefore beneficial to indicate which IP version that was assumed when the bandwidth properties were calculated.

The bandwidth properties may be calculated either using IPv4 and/or IPv6. The SDP may include bandwidth properties for both IPv4 and IPv6 in which case different attribute lines are used for the different IP versions and the IP version needs to be indicated

If no IP version is included for any of the ‘a=bw-info’ lines related to a certain payload type and direction then IPv6 is assumed for all bandwidth properties related to the same direction and payload type, on all of the related ’a=bw-info’ lines.

19.2.7 Maximum Packet Rate

Definition:

Identifies the maximum packet rate assumed when calculating the bandwidth properties.

The unit for this bandwidth property shall be packets per second.

Usage during the session:

The overhead when transmitting media using IP/UDP/RTP depends on the packet rate, especially for media using a relatively low bit-rate media, e.g. speech. When IPv4-IPv6 conversion is performed and when the bandwidth properties are re-calculated for the ‘a=bw-info’ attribute, it is necessary to know which packet rate that was assumed when the bandwidth properties were originally calculated.

The maximum packet rate is used when re-calculating the Maximum Supported Bandwidth, Maximum Desired Bandwidth and Minimum Desired Bandwidth bandwidth properties.

19.2.8 Minimum Packet Rate

Definition:

Identifies the minimum packet rate assumed when calculating the bandwidth properties.

The unit for this bandwidth property shall be packets per second.

Usage during the session:

The minimum packet rate is used when re-calculating the Minimum Supported Bandwidth bandwidth property.

19.3 SDP attribute

19.3.1 Definition

The syntax for the SDP attribute is:

a=bw-info:<pt-def> <direction> <bw-prop-1>=<bw-value-def-1>; …; <bw-prop-N>=<bw-value-def-N>

where:

<pt-def> is the definition of the RTP payload type(s) that the bandwidth information applies to. This can be a single value, a comma-separated list of RTP payload type numbers, or a wild card (‘*’).

<direction> is either ‘send’ or ‘recv’. The direction shall be defined for each ‘a=bw-info’ line.

<bw-prop-X>=<bw-value-def-X> define the bandwidth property and the related bandwidth value(s).

The new attribute is designed to allow for future extensibility.

19.3.2 SDP grammar

The ABNF RFC 5234 [153] for this attribute is the following:

bw-attrib = "a=bw-info:" pt-def SP direction SP bw-def *(";" [SP] bw-def)

pt-def = "*" / pt-val *("," pt-val)

pt-val = 1*3DIGIT

direction = "send" / "recv" / "sendrecv" / direction-ext

direction-ext = 1*VCHAR

bw-def = bw-name "=" bw-val-def

bw-name = 1*VCHAR ; Label defining the bandwitdh property

bw-val-def = zero-based-int-or-real / bw-val-def-ext ; Bandwidth value for the bandwidth property

bw-val-def-ext = zero-based-int-or-real *(":" zero-based-int-or-real)

; Extension possibility

; DIGIT as defined by IETF RFC 4566

; zero-based-int-or-real as defined by IETF RFC 8866

The ‘a=bw-info’ attribute defines the following possible directionalities for the bandwidth. Three directionalities are defined here:

– send: In the send direction for SDP Offer/Answer agent providing the SDP or in case of declarative use in relation to the device that is being configured by the SDP.

– recv: In the receiving direction for the SDP Offer/Answer agent providing the SDP or in case of declarative use in relation to the device that is being configured by the SDP.

– sendrecv: In both the send and receiving directions for the SDP Offer/Answer agent providing the SDP or in case of declarative use in relation to the device that is being configured by the SDP.

Additional directionalities may be defined in the future, if needed. If an ‘a=bw-info’ line is received with an unknown directionality then the entire ‘a=bw-info’ line is ignored.

The directionality shall be specified when the ‘a=bw-info’ attribute is used. Only one directionality can be specified on each ‘a=bw-info’ line.

It is allowed to define different bandwidth properties on different attribute lines for the same payload type and direction. However, special care should be taken to avoid conflicting definitions. Therefore, a single bandwidth property shall not be included in several attribute lines applicable to the same payload type, direction and IP version. For example, if bandwidth property ‘MaxSupBw’ is defined for payload number 96 on one ‘a=bw-info’ line for direction ‘send’ and IPv6, then ‘MaxSupBw’ cannot be defined on another ‘a=bw-info’ line for the same payload type number, direction and IP version. However, for example, ‘MaxSupBw’ and ‘MinSupBw’ may be defined in different ‘a=bw-info’ lines, even for the same payload type, direction and IP version. This applies also when a wild card is used for the payload type number.

The ‘bw-name’ is a character string describing the name (or label) used for the bandwidth property that is defined. Four bandwidth property names are defined here for indicating bandwidth needs:

– MaxSupBw: The Maximum Supported Bandwidth, see clause 19.2.2. The Maximum Supported Bandwidth may be a real value.

– MaxDesBw: The Maximum Desired Bandwidth, see clause 19.2.3. The Maximum Desired Bandwidth may be a real value.

– MinDesBw: The Minimum Desired Bandwidth, see clause 19.2.4. The Maximum Desired Bandwidth may be a real value.

– MinSupBw: The Minimum Supported Bandwidth, see clause 19.2.5. The Maximum Supported Bandwidth may be a real value.

These bandwidth properties include IP/UDP/RTP overhead but not RTCP bandwidth, similar to b=AS. This means that the Maximum Supported Bandwidth for the receiving direction corresponds to the b=AS value used in an SDP offer-answer negotiation.

The following bandwidth property names are also defined:

– IpVer: The IP version, see clause 19.2.6. Allowed values are 4 and 6 for IPv4 and IPv6, respectively. If the IP version is not indicated then IPv6 is assumed.

– MaxPRate: The Maximum Packet Rate, see clause 19.2.7. The maximum packet rate may be a real value.

– MinPRate: The Minimum Packet Rate, see clause 19.2.8. The minimum packet rate may be a real value.

Unknown bandwidth property names shall be ignored, and shall not be included in an answer if received in an offer. A received SDP may include ‘a=bw-info’ lines containing both known and unknown bandwidth properties. Ignoring unknown bandwidth properties shall not cause known bandwidth properties to be ignored.

19.3.3 Declarative use

In declarative usage the SDP attribute is interpreted from the perspective of the end-point being configured by the particular SDP. An interpreter may ignore ‘a=bw-info’ attribute lines that contain only unknown payload numbers.

19.3.4 Usage in offer/answer

The offer/answer negotiation is performed for each ‘a=bw-info’ attribute line, payload type, direction and bandwidth property individually.

An offerer may use the ‘a=bw-info’ attribute line for some or all of the offered payload types. The offerer may use the wild card to describe that a bandwidth property applies to all payload types included in the offer. Different bandwidth properties may be defined on different ‘a=bw-info’ attribute lines, even for the same payload type (including wild card) and directionality. However, the offerer shall ensure that there is no contradicting information. Therefore, a bandwidth property shall not occur on multiple ‘a=bw-info’ lines for the same payload type (including wild card), direction and IP version.

An answerer may remove the ‘a=bw-info’ attribute line(s) for the payload types where it was used in the SDP offer. If ‘a=bw-info’ is included in the SDP offer, the answerer may add additional ‘a=bw-info’ lines for payload types it has added in the SDP answer compared to the SDP offer. An answerer may also remove or add individual bandwidth properties.

The SDP may include an offer for some of the defined bandwidth properties without including an offer for other defined bandwidth properties, in which case the values of the omitted properties are undefined, but may still be implicitly limited by the general property equalities defined in clause 19.2.1.

An offer may include any defined directionality in the ‘a=bw-info’ attribute(e.g. ‘send’, ‘recv’ or ‘sendrecv’) regardless of the directional attribute defined for the media stream (‘a=sendrecv’, ‘a=sendonly’, ‘a=recvonly’ or ‘a=inactive’).

An agent understanding the ‘a=bw-info’ attribute and answering to an offer including the ‘a=bw-info’ attribute should include the attribute in the answer for all payload types for which it was offered.

If an answerer has received ‘a=bw-info’ in an SDP offer with a certain set of bandwidth properties, and would like to add additional bandwidth properties, possibly using other directionality, then it may do so by adding such definitions in the SDP answer.

An agent may also divide an ‘a=bw-info’ line into several ‘a=bw-info’ lines. One example is when the SDP offer included an ‘a=bw-info’ lines listing several different RTP payload types, or using a wild card. The agent may then divide the attribute line with the payload type list into several attribute lines with payload type lists consisting of fewer payload type numbers or even several attribute lines with only a single payload type number each. Another example is separating a list of bandwidth properties from a single ‘a=bw-info’ line onto multiple ‘a=bw-info’ lines.

An agent may also merge several ‘a=bw-info’ offers into fewer offers or even a single offer.

An agent responding to an ‘a=bw-info’ offer will need to consider the directionalities and reverse them in the answer when responding to media streams using unicast.

If the answerer removes one or several RTP Payload Types from the SDP when creating the SDP answer then the corresponding payload type numbers should be removed from the ‘a=bw-info’ lines as well.

An agent accepting an offer with the ‘a=bw-info’ attribute may modify the bandwidth properties in the following ways when including them in the answer:

– The Maximum Supported Bandwidth may be reduced.

– The Maximum Desired Bandwidth may be reduced.

– The Minimum Desired Bandwidth may be reduced.

– The Minimum Supported Bandwidth may be increased. If the reason for increasing the Minimum Supported Bandwidth is that the Minimum Packet Rate needs to be increased then the Minimum Packet Rate shall also be adjusted.

– The Maximum Packet Rate may be reduced.

– The Minimum Packet Rate may be increased.

19.4 Modifications of the bandwidth information by intermediate network nodes

Networks nodes in the path, capable of understanding and modifying the SDP, may modify the new bandwidth information in the SDP offer for each codec and configuration in the following manner:

– The first node may decrease the maximum supported, maximum desired and minimum desired bandwidth according to network policies. However, the first node should not increase the maximum supported, maximum desired and minimum desired bandwidth except when required to correct undesired or erroneous UE behavior, or for IPv4/IPv6 transport interworking.

– The first node may increase the minimum supported bandwidth according to network policies. However, the first node should not decrease the minimum supported bandwidth except when required to correct UE misbehavior, or for IPv4/IPv6 transport interworking.

– Subsequent nodes may decrease the maximum supported, maximum desired and minimum desired bandwidths and increase the minimum supported bandwidth, but shall not increase the maximum supported, maximum desired and minimum desired bandwidths, and shall also not decrease the minimum supported bandwidth except when required due to IPv4/IPv6 transport interworking.

– Networks nodes may remove an unwanted codec or configuration together with all related bandwidth information.

– Networks nodes may add codecs or configurations accessible via transcoding together with all related bandwidth information.

– If a network node desires to use a MBR=GBR bearer, it should decrease maximum supported bandwidth down to the maximum desired bandwidth in the SDP offer.

– The following relationships shall be maintained by any network node when modifying the bandwidth propertiess:

Minimum Supported Bandwidth <= Minimum Desired Bandwidth

Minimum Desired Bandwidth <= Maximum Desired Bandwidth

Maximum Desired Bandwidth <= Maximum Supported Bandwidth

NOTE: These rules allow all both the originating and terminating operators in the call setup direction to implement certain policies, but avoid that subsequent operators in the call setup chain counteract the policies of the first operator, and guarantee that the used bandwidths remain in the supported range of the originating UE. For instance, the following policies are supported:
An operator desiring to set a lower limit to the acceptable QoS can increase the Minimum Supported Bandwidth.
An operator desiring to limit the GBR for MBR>GBR bearers can decrease the Minimum Desired Bandwidth.
An operator desiring to limit the GBR for MBR=GBR bearers can decrease the Maximum Supported Bandwidth.

In the SDP answer, the first node should not modify the bandwidth values except when required to correct UE misbehavior, when replacing the selected codec and configuration in the SDP answer due to transcoding, or due to IPv4/IPv6 transport interworking. Subsequent node also shall not modify the bandwidth values except when replacing the selected codec and configuration in the SDP answer due to transcoding, or due to IPv4/IPv6 transport interworking.

Annex A (informative):
Examples of SDP offers and answers