Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 26.114  Word version:  18.5.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.6.4…   Y.6.5…   Y.7…

 

6.2.7  Negotiated QoS parametersp. 64

6.2.7.1  General |R13|p. 64

The MTSI client in the terminal may support the negotiation of the QoS. The term "negotiated" in the present document describes the end result of a QoS negotiation between an MTSI client in terminal and the network (or the end result of what the network grants to the MTSI client in terminal even if no negotiation takes place).
An MTSI client in terminal supporting the transport level QoS negotiation should verify that the QoS parameters, e.g. MBR and GBR, are aligned with the media configurations negotiated in SDP. While checking whether the different bandwidth parameters are aligned or not, the MTSI client in terminal should take into account the following areas where differences are likely to occur: parameter encoding; units used; packetization schemes related to the IP/UDP/RTP overhead; the amount of RTCP bandwidth. The MTSI client in terminal needs to compensate for the differences if found.
In the following sections it is assumed that the MTSI client in terminal supports the QoS negotiation and is made aware of the negotiated bandwidth properties and other QoS hints (if supported and used, see clause 6.2.7.4).
Up

6.2.7.2  Alignment of negotiated QoS parameters and b=AS bandwidth modifier |R13|p. 64

In SDP offer-answer, the b=AS bandwidth modifier is used to describe the maximum bandwidth for the receiving direction. The IP/UDP/RTP overhead is included in the bandwidth value for RTP-based media but the RTCP bandwidth is not included. The IP/UDP/DTLS/SCTP overhead is included in the bandwidth value for SCTP-based media such as the data channel (see clause 6.2.10). The bandwidth value is an integer and the unit is kbps.
If, at session setup or at session re-negotiation, the MTSI client in terminal detects that the negotiated downlink QoS Maximum Bit Rate (MBR) is not aligned with the b=AS bandwidth modifier in the sent SDP then it should try to align the bandwidth properties in a subsequent SDP offer-answer.
If, during the session, the negotiated downlink Maximum Bit Rate(s) (MBR) for the bearer(s) has been updated from the network then the MTSI client in terminal should check if the bandwidth(s) it sent within b=AS bandwidth modifiers in previous SDP (e.g. during the initial session setup or earlier session re-negotiation, if any) are aligned with the downlink MBR(s) allocated for the bearer(s) and its receiving capabilities.
The rules for alignment are different depending on how many media streams that are handled by the bearer, as follows:
  • When a bearer carries a single media stream, then it is the media-level b=AS bandwidth for that media stream that should be aligned with the MBR of the bearer.
  • When a bearer carries several media streams, then it is the sum of the media-level b=AS bandwidths for those media streams that should be aligned with the MBR of the bearer.
The rules for alignment are also different depending on whether the media stream(s) are bi-directional (sendrecv) or uni-direction (sendonly or recvonly), as follows:
  • If the MTSI terminal receives (and possibly sends) a media stream, it should consider the sent b=AS bandwidth(s) in SDP for that media stream in comparison with the downlink MBR.
  • If the MTSI terminal only sends a media stream, it should not consider the sent b=AS bandwidth(s) in SDP for that media stream in comparison with the downlink MBR.
If the MTSI client in terminal determines that the b=AS bandwidth(s) are not aligned with the MBR and the receiving capabilities of the MTSI client, then it should align the media-level b=AS bandwidth(s) to the MBR and its receiving capabilities by sending to the other party an SDP offer with the new b=AS bandwidth value(s). In the process of this alignment it is also likely that the session-level b=AS bandwidth needs to be updated. In addition, the MTSI client in terminal may modify other parts of the SDP, e.g., to replace the codecs or adjust codec parameters (such as the AMR or AMR-WB mode-set).
This alignment may require re-negotiation, which should preferably be performed when there is session re-negotiation for other reasons. When additional re-negotiation is required, which adds load to the SIP bearer and the SIP servers, it is not desirable to repeat the re-negotiation multiple times. Therefore, if re-negotiation fails to align the b=AS bandwidth modifier and the QoS parameters then it should not be repeated unless new re-negotiation is needed for other reasons, e.g. to add or remove media components.
If an MTSI client in a terminal receives a new SDP offer with new b=AS bandwidth value(s) (e.g., in a SIP UPDATE or in a SIP re-INVITE) and it accepts the session update then it shall generate an SDP answer as described in clause 6.2.
Any subsequent QoS changes indicated to the MTSI client in terminal during an MTSI session (including the cases described in clause 10.3) shall be signalled by the MTSI client in terminal (subject to the QoS update procedure) to the other party using the same signalling described above.
Examples of SDP using negotiated QoS are given in clause A.8.
When the MTSI client in terminal receives an indication that the negotiated uplink Maximum Bit Rate (MBR) is less than the current maximum sending rate of its sender, the MTSI client in terminal should configure the maximum sending rate of its sender to align with the negotiated uplink Maximum Bit Rate (MBR).
When the MTSI client in terminal receives an indication that the negotiated uplink Maximum Bit Rate (MBR) is greater than the current maximum sending rate of its sender and rate adaptation is possible for the session, the MTSI client in terminal should configure the maximum sending rate of its sender to align with the smallest of the following:
  • the negotiated uplink Maximum Bit Rate (MBR)
  • the bandwidth value, if the b=AS parameter was included in the last SDP offer or answer received by the client
  • the preconfigured data rate for the selected codec, if the MTSI client has been preconfigured by the operator to use a particular data rate for the selected codec
Up

6.2.7.3  Alignment of negotiated QoS parameters and a=bw-info attribute |R13|p. 65

The Maximum Supported Bandwidth for the sending direction should be aligned with the uplink MBR.
The Minimum Desired Bandwidth for the sending direction should be aligned with the uplink GBR.
The Maximum Supported Bandwidth for the receiving direction should be aligned with the downlink MBR.
The Minimum Desired Bandwidth for the receiving direction should be aligned with the downlink GBR.
The procedures for aliging the above listed bandwidth properties with the above listed QoS parameters are the same as given above in clauses 6.2.7.1 and 6.2.7.2 for other bandwidth-related information.
Up

6.2.7.4  The a=3gpp-qos-hint SDP attribute |R17|p. 65

6.2.7.4.1  General |R16|p. 65
In some cases, it is not possible to uniquely map a media type in SDP to an appropriate QoS without additional information on the intended usage of that media from the application or the end-user of that application.
The MTSI client in terminal may include a non-authoritative QoS hint in one or more SDP media description(s), for use by local and remote policy control functions, by adding an "a=3gpp-qos-hint" media-level SDP attribute with a value that is set based on the intended media usage. The QoS hints included on the "a=3gpp-qos-hint" line applies jointly to the aggregate of all packets (e.g. if more than one media stream is part of the same media description), and equally in both directions (uplink and downlink) unless restricted by the inclusion of "a=sendonly" or "a=recvonly" in the same media description.
If this attribute is included in an SDP media description, policy control can choose to take this additional information into account for the affected media.
An "a=3gpp-qos-hint" attribute shall not occur more than once for an SDP media description.
SDP examples are provided in Annex A.16.
Up
6.2.7.4.2  3gpp-qos-hint ABNF syntax and semantics |R16|p. 66
3gpp-qos-hint-value = qos-hint *(";" qos-hint)
qos-hint = qos-hint-property ["=" qos-hint-end-to-end-value *(qos-hint-split)]
qos-hint-property = "loss" / "latency" / token
qos-hint-end-to-end-value = qos-hint-value
qos-hint-split = "/" qos-hint-split-method ":" qos-hint-split-value
qos-hint-split-method = "local" / token
qos-hint-split-value = qos-hint-value
qos-hint-value = zero-based-integer / non-zero-real / token
; token as defined by RFC 4566
; zero-based-integer and non-zero-real as defined by RFC 8866.
; The IANA registration information for this attribute is provided in Annex M.11.
A qos-hint-property value shall only occur once on the "a=3gpp-qos-hint" line. If a qos-hint-property value is not included on the "a=3gpp-qos-hint" line, it should be interpreted as the UE and application have no preference of any qos-hint-value for that qos-hint-property but anything the network can provide is equally acceptable.
If a qos-hint-property has no qos-hint-end-to-end-value, it is of boolean (on/off) type.
If the qos-hint-propery has a qos-hint-end-to-end-value but doesn't include any explicit qos-hint-split, the qos-hint-end-to-end-value is split equally between the SDP offerer and the SDP answerer. If an explicit qos-hint-split is included, it specifies how the split of the qos-hint-end-to-end-value between SDP offerer and SDP answerer is made. The following qos-hint-split-method values are currently defined:
"local":
The qos-hint-split-value specifies the SDP sender's part of the qos-hint-end-to-end-value that is applied across its local link, in the same format and units used by the associated qos-hint-end-to-end-value, the value being the same in both send and receive directions. The SDP sender of the SDP offer is the SDP offerer and the SDP sender of the SDP answer is the SDP answerer.
The following qos-hint-property values are currently defined:
"loss":
This qos-hint-property qos-hint-end-to-end-value describes the maximum desirable end-to-end transport level packet loss rate in percent (without "%" sign) as a zero-based-integer or as a non-zero-real value.
"latency":
This qos-hint-property qos-hint-end-to-end-value describes the maximum desirable end-to-end transport level packet latency in milliseconds as a zero-based-integer or as a non-zero-real value. The value excludes any application-level processing in the sender and receiver, such as e.g. application-level retransmission or encoding/decoding.
Up
6.2.7.4.3  Creating an SDP offer |R16|p. 67
An "a=3gpp-qos-hint" line may be included in any media description in an SDP offer.
6.2.7.4.4  Creating an SDP answer |R16|p. 67
If there is no "a=3gpp-qos-hint" line included in a media description in the SDP offer, it shall not be included in the corresponding media description in the SDP answer.
If a qos-hint with an unknown or malformed qos-hint-property or qos-hint-value is received in an SDP offer, that qos-hint shall be ignored, shall be omitted from the SDP answer, and shall neither cause the "a=3gpp-qos-hint" line nor the entire media description to be rejected in the SDP answer.
An SDP answerer shall not add any qos-hint-property values on the "a=3gpp-qos-hint" line that are not present in the received SDP offer.
A "loss" qos-hint-end-to-end-value received in the SDP offer that is accepted by the SDP answerer shall be kept unmodified in the SDP answer. A "loss" qos-hint-end-to-end-value received in the SDP offer that cannot be supported by the SDP answerer even when making use of an allowable qos-hint-split-value (see below) may be increased in the SDP answer to a value that can be supported by the SDP answerer. A "loss" qos-hint-end-to-end-value received in the SDP offer that is higher than required by the SDP answerer may be decreased in the SDP answer to a value that is required by the SDP answerer. Figure 6.2.7.4.4-1 and Figure 6.2.7.4.4-2 provide illustrated examples of these principles. If the "loss" qos-hint-property is known by the SDP answerer but if there are no known, supported qos-hint-values for it, the entire qos-hint shall be omitted from the SDP answer.
A "latency" qos-hint-value received in the SDP offer that cannot be supported by the SDP answerer as the desirable maximum end-to-end packet latency should be increased in the SDP answer to a value that can be supported by the SDP answerer. A "latency" qos-hint-end-to-end-value received in the SDP offer that is higher than required by the SDP answerer may be decreased in the SDP answer to a value that is required by the SDP answerer. Figure 6.2.7.4.4-1 and Figure 6.2.7.4.4-2 provide illustrated examples of the principles for "loss" that is also applicable for "latency". If the "latency" qos-hint-property is known by the SDP answerer but if there are no known, supported qos-hint-values for it, the entire qos-hint shall be omitted from the SDP answer.
If, as a result of the above procedures, there are no qos-hints to be included in the SDP answer, the entire "a=3gpp-qos-hint" line shall be omitted from the SDP answer.
Reproduction of 3GPP TS 26.114, Fig. 6.2.7.4.4-1: Illustration of 3gpp-qos-hint "loss" UE-to-UE offer/answer
Up
Reproduction of 3GPP TS 26.114, Fig. 6.2.7.4.4-2: Illustration of 3gpp-qos-hint "loss" UE-to-Network offer/answer
Up
If a qos-hint with an unknown or malformed qos-hint-split-method or qos-hint-split-value is received in an SDP offer, the entire qos-hint-split shall be ignored, shall be omitted from the SDP answer, and shall neither cause the "a=3gpp-qos-hint" line nor the entire media description to be rejected in the SDP answer.
The qos-hint-split provides the SDP offerer's opinion on how that qos-hint-end-to-end-value should be split between the SDP offerer's and the SDP answerer's local links. As stated above, if no qos-hint-split is provided the qos-hint-end-to-end-value is split equally between SDP offerer and SDP answerer local links and is equivalent to a qos-hint-split being provided with a value that is half of the qos-hint-end-to-end-value.
If the SDP answerer accepts a default split (without explicit qos-hint-split in the SDP offer) it shall not include any qos-hint-split in the SDP answer.
If the SDP answerer accepts an explicitly provided qos-hint-split proposed by the SDP offer, it shall include a qos-hint-split in the SDP answer with a qos-split-hint-value being equal to qos-hint-end-to-end-value in the SDP answer minus the corresponding qos-hint-split-value from the SDP offer.
If the SDP answerer does not accept the qos-hint-split-value proposed in the SDP offer, regardless if that qos-hint-split-value is explicit or not, it can make one of the following choices for the SDP answer:
  • If the SDP offerer qos-hint-split-value is smaller than what the SDP answerer requires (i.e., qos-hint-end-to-end-value in the SDP offer minus the corresponding qos-hint-split-value from the SDP offer is larger than required across the SDP answerer's local link), the SDP answerer may include a qos-hint-split-value in the SDP answer that is less than the qos-hint-end-to-end-value in the SDP answer minus the corresponding qos-hint-split-value from the SDP offer. The SDP answerer may use the value 0 if the actual (non-zero) qos-hint-split-value can be considered insignificant compared to the qos-hint-split-value in the SDP offer.
  • If the SDP offerer qos-hint-split-value is larger than what the SDP answerer considers feasible (i.e., qos-hint-end-to-end-value in the SDP offer minus the corresponding qos-hint-split-value from the SDP offer is smaller than feasible across the SDP answerer's local link), the SDP answerer may include a qos-hint-split-value in the SDP answer that is larger than the qos-hint-end-to-end-value included in the SDP offer minus the corresponding qos-hint-split-value from the SDP offer, but the included value shall then also be less than or equal to half of the qos-hint-end-to-end-value included in the SDP answer. The exception to that rule is when the qos-hint-end-to-end-value included in the SDP answer is less than the qos-hint-end-to-end-value included in the SDP offer (see also above), in which case the qos-hint-split-value should instead be the qos-hint-end-to-end-value included in the SDP answer minus the corresponding qos-hint-split-value from the SDP offer, unless the SDP answerer cannot support such qos-hint-split-value. In that case the included value shall be less than or equal to half of the qos-hint-end-to-end-value included in the SDP answer.
Up
6.2.7.4.5  Offerer receiving an SDP answer |R16|p. 68
If there is no "a=3gpp-qos-hint" line included in a media description in the SDP answer, it shall be interpreted as the answerer either does not support the attribute at all or cannot accept any of the qos-hint-property values from the offer, and QoS hints will therefore not be used for that media description.
If a qos-hint with an unknown or malformed qos-hint-property or qos-hint-value is received in an SDP answer, that qos-hint shall be ignored, and shall neither cause the "a=3gpp-qos-hint" line nor the entire media description to be rejected (e.g. by issuing a new SDP offer with that "m=" line disabled).
A "loss" property value received in the SDP answer that is identical to the SDP offer shall be taken as the SDP answerer accepting to share end-to-end packet loss budget equally. A "loss" property value received in the SDP answer that is larger than in the SDP offer shall be taken as the SDP answerer being incapable of sharing end-to-end packet loss budget with the proposed split from the SDP offer while keeping the end-to-end packet loss value that was included in the SDP offer (see illustrative examples in Figure 6.2.7.4.4-1 and Figure 6.2.7.4.4-2). A "loss" property value received in the SDP answer that is smaller than in the SDP offer shall be taken as the SDP answerer requiring a lower end-to-end packet loss for the media.
A "latency" property value received in the SDP answer that is identical to the SDP offer shall be taken as the SDP answerer accepting to share end-to-end packet latency budget equally. A "latency" property value received in the SDP answer that is larger than in the SDP offer shall be taken as the SDP answerer being incapable of sharing end-to-end packet latency budget with the proposed split from the SDP offer while keeping the end-to-end packet latency value that was included in the SDP offer (the principles in the illustrative examples for "loss" in Figure 6.2.7.4.4-1 and Figure 6.2.7.4.4-2 apply also for "latency"). A "latency" property value received in the SDP answer that is smaller than in the SDP offer shall be taken as the SDP answerer requiring a lower end-to-end latency for the media.
If a qos-hint with an unknown or malformed qos-hint-split-method or qos-hint-split value is received in an SDP answer, the entire qos-hint-split shall be ignored, and shall neither cause the "a=3gpp-qos-hint" line nor the entire media description to be rejected (e.g. by issuing a new SDP offer with that "m=" line disabled).
If no qos-hint-split is included in the received SDP answer and if no qos-hint-split was included in the SDP offer, the SDP answerer has accepted the offered default, equal split.
If a qos-hint-split is included in the received SDP answer with a qos-split-hint-value equal to the qos-hint-end-to-end-value in the SDP answer minus the corresponding qos-hint-split-value from the SDP offer, the SDP answerer has accepted the qos-hint-split proposed by the SDP offer.
If a qos-hint-split is included in the received SDP answer with a qos-split-hint-value different than the above, the SDP answerer has modified the qos-hint-split-value allocation from the SDP offer, regardless if that qos-hint-split-value was explicit or not in the SDP offer, and the resulting split is described by the SDP answer.
Table 6.2.7.4.5-1 below shows what resulting QoS hint values from the SDP answer that can be used during resource reservation at the SDP offerer and SDP answerer sides, respectively, for each of the defined qos-hint-property-values.
QoS hint condition SDP offerer side part SDP answerer side part
No qos-hint-split included0.5 * qos-hint-end-to-end-value0.5 * qos-hint-end-to-end-value
qos-hint-split includedqos-hint-end-to-end-value - qos-hint-split-valueqos-hint-split-value
Up

6.2.8  Delay Budget Information (DBI) Signaling |R16|p. 69

An MTSI client may support Delay Budget Information (DBI) signaling as specified in subclause 7.3.8.
An MTSI client supporting DBI shall offer 'Delay Budget Information' (DBI) signaling in SDP for all media streams containing speech. An MTSI client supporting DBI may also offer 'Delay Budget Information' (DBI) signaling in SDP for all media streams containing video. DBI shall be offered by including the a=rtcp-fb attribute (RFC 4585) with the DBI type under the relevant media line scope. The DBI type in conjunction with the RTCP feedback method shall be expressed with the following parameter: 3gpp-delay-budget. A wildcard payload type ("*") shall be used to indicate that the RTCP feedback attribute for DBI signaling applies to all payload types. Here is an example usage of this attribute to signal DBI relative to a media line based on the RTCP feedback method:
a=rtcp-fb:* 3gpp-delay-budget
The IANA registration information on the new RTCP feedback type for DBI signaling is provided in Annex R.2.
The ABNF for rtcp-fb-val corresponding to the feedback type "3gpp-delay-budget" is given as follows:
rtcp-fb-val =/ "3gpp-delay-budget" 
As described in subclause 7.3.8, DBI signalling involves RTCP feedback signalling to carry both (i) available additional delay budget from the MTSI receiver to the MTSI sender, and (ii) requested additional delay budget from the MTSI sender to the MTSI receiver.
Annex V.3 presents SDP examples on DBI signalling capability.
Up

6.2.9  ANBR Support attribute "anbr" |R16|p. 70

Access network bitrate recommendation (ANBR) is described in clause 10.7. Use of ANBR with dynamic bitrate adaptation is described in clause 10.7.3 and related adaptation of sent and received media is described in clauses 10.7.3.2 and 10.7.3.3, respectively. At the radio signalling level, ANBR signaling capability, also known as RAN-assisted codec adaptation, is specified in TS 36.321 for LTE access and TS 38.321 for NR access respectively.
The media-level SDP attribute "anbr" is specified in this clause to indicate ANBR support. The MTSI client in terminal supporting "anbr" shall only signal this attribute in the SDP offer and answer if all of the following are true:
  • MTSI client in terminal supports ANBR as described in clause 10.7, including the use of ANBR with dynamic bitrate adaptation as described in clause 10.7.3.
  • The UE of the MTSI client in terminal is capable of RAN-assisted codec adaptation specified in TS 36.321 for LTE access and/or TS 38.321 for NR access. For LTE access, inclusion of "anbr" in the SDP indicates that the UE is able to query and receive ANBR information (for both downlink and uplink ANBR) from its eNB. Likewise, for NR access inclusion of this attribute indicates that the UE is able to query and receive ANBR information (for both downlink and uplink ANBR) from its gNB.
  • The P-CSCF has indicated to the UE of the MTSI client in terminal its ability to handle this SDP attribute, as described in clause E.10 of TS 23.228, and specified in TS 24.229 through the respective SIP registration procedures via the corresponding feature capability indicator g.3gpp.anbr.
Signalling of ANBR capabilities in the SDP via "a=anbr" enables end-to-end coordination of ANBR capabilities across the UEs, access networks, and PCF/PCRF. In particular, such ANBR capability signalling can be useful for the PCF/PCRF when setting GBR<MBR bearers.
Here is an example use of the "a=anbr" attribute relative to a media line:
a=anbr
The IANA registration information for the "a=anbr" SDP attribute is provided in Annex M.8.
SDP examples on ANBR capability signalling are provided in Annex A.15.
Up

Up   Top   ToC