Content for  TS 26.114  Word version:  18.8.0

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

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

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.

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.