End-to-end delay and jitter performance plays an important role in determining MTSI quality of experience. MTSI sender and MTSI receiver may perform adaptation based on delay budget adjustments, including jitter buffer size adaptation at the receiver, air interface delay adjustments at both sender and receiver using RAN delay budget reporting as specified in TS 36.331 for E-UTRA and TS 38.331 for NR. MTSI sender and MTSI receiver may also exchange delay budget information (DBI) with each other as described in clause 7.3.8, to signal available delay budget as well as to request delay budget. This clause provides various example informative signalling flows on delay adaptation using these mechanisms. Figure V.2.1 presents a signaling flow example for RAN delay budget reporting usage for voice in MTSI without DBI signalling. Figure V.2.2 and Figure V.2.3 present signaling flow examples for RAN delay budget reporting usage in MTSI involving uni-directional DBI signalling with only indication of available delay budget from MTSI receiver to MTSI sender. Figure V.2.4 presents a signaling flow example for RAN delay budget reporting usage in MTSI involving bi-directional DBI signalling with indication of available delay budget from MTSI receiver to MTSI sender and requested delay budget from MTSI sender to MTSI receiver. Figure V.2.5 presents a signalling flow example on usage of RAN delay budget request in MTSI with bi-directional DBI signalling and with jitter buffer adjustment.

In Figure V.2.1, a signaling flow for RAN delay budget reporting usage for voice in MTSI without DBI signalling is presented.

In Figure V.2.2, another signaling flow example for RAN delay budget reporting usage in MTSI involving delay budget information (DBI) signalling as described in clause 7.3.8 is presented. In this example, uni-directional DBI signalling is depicted with only indication of available delay budget from MTSI receiver to MTSI sender.

In this example, the available delay budget may be computed by the UE-1 (MTSI receiver) based on network delay, jitter, packet loss rate (PLR) and potentially other parameters. It may also take into account constraints on JBM (i.e., based on reference JBM in clause 8). In this respect, the following observations can be made on the expected UE behaviour:

1. Allowing UE-2 to use more retransmission will increase the jitter. This may potentially cause more packets dropped at the JBM for UE-1.
2. On the other hand, more retransmission also allows UE-2 to reduce packet losses in its RAN uplink and this means more end-to-end reliability. So there is a fine balance here, while it would also be expected that the end-to-end performance is limited by the high packet losses on the UL, and hence more retransmissions will help improve the end-to-end quality and delay performance.
3. UE-1 turning off cRDX will help to reduce end-to-end delay. In the meantime, if UE-1 needs to save on battery power and it is critical that cDRX is kept on for this purpose, then UE-1 may choose not to turn cDRX off. Even with cDRX off, if UE-1 decides that it can tolerate any further delay or jitter at its JBM, it may indicate this available delay budget via the RTCP-FB message for DBI signalling as defined in clause 7.3.8.
4. It is up to UE-1 to signal any additional delay budget to UE-2. If UE-1 figures that it is already close to its JBM constraint and cannot tolerate any additional delay or jitter (as this would lead to more packets being dropped), it may not signal additional delay availability to UE-2.

The signalling flow example in Figure V.2.2 relies on DBI signalling between the MTSI sender and MTSI receiver whereas the signalling flow in Figure V.2.1 does not include such signalling. The following can be observed when DBI signalling is not present:

1. While the MTSI sender and MTSI receiver UEs may both be independently able to adjust their air interface delays based on the information in their MTSI clients, they are never aware of the capabilities or actions of the other UE. For example, while an MTSI receiver in good coverage may turn off cDRX to create delay budget for an MTSI sender, it may be the case that the MTSI sender does not even support delay budget reporting, or that the MTSI sender's eNB may not grant the additional delay budget to the MTSI sender, so the effort of the MTSI receiver may not deliver any end-to-end performance gain, and end up wasting the battery power of the MTSI receiver UE. Likewise, an MTSI sender in poor coverage may increase its air interface delay in an attempt to perform further retransmissions to mitigate against packet losses, without any knowledge of the possible detrimental impacts on the MTSI receiver, e.g., packets being dropped at the jitter buffer management (JBM) level.
2. When UE-1 and UE-2 independently adjust their air interface delays, they rely on the end-to-end measurements available at their MTSI clients, e.g., by monitoring reception of RTP packets and RTCP sender and receiver reports, and knowledge of their local radio conditions. Purely relying on this information, an MTSI receiver may not be able to correctly detect the need for additional delay budget at the MTSI sender, e.g., as it may be the case that the losses are caused in the network. An explicit indication from the MTSI sender as would be enabled by DBI signaling can help the MTSI receiver make the right conclusion. Moreover, the MTSI receiver may not be able to determine exactly how much additional delay budget is needed on the air interface for the MTSI sender UE. Likewise, an MTSI sender may not be able to determine exactly how much additional delay budget it could ask from its eNB in the absence of any DBI signaling.
3. With the use of DBI signaling, delay budget adaptation and consequent larger number of retransmissions can be done faster via the real time exchange of delay budget information using RTP/RTCP signalling compared to the case when DBI signalling is absent, which would have to rely on measurements and inference at the UEs based on packet statistics, collection of which requires a certain observation period and averaging window.

The signaling flow in Figure V.2.3 is identical to the one in Figure V.2.2, except that in step 7, UE-1 still observes high packet loss rate and the following additional steps are taken:

The signalling flow in Figure V.2.4 is a variant of the one in Figure V.2.2, where UE-2 requests additional delay budget from UE-1 during the media flow (as depicted by Step 2b in Figure V.2.4), e.g., via the use of an RTCP-FB message for DBI signalling as defined in clause 7.3.8, after having detected poor radio conditions (e.g., high BLER) over the local RAN. The presence of this request message may further inform UE-1 that the radio conditions on UE-2's side are poor (in addition to its own detection, e.g., based on monitoring of RTP receive statistics). Another benefit of the bi-directional exchange of delay budget information between the two UEs is that this could help in identifying the scenario where the packet losses are introduced by neither of the RANs of UE1 and UE2 (i.e., both UEs enjoying good radio conditions) but rather by the network. In the meantime, it should be noted that the dominant cause of packet losses is expected to be from RAN impediments and the likelihood that the packet losses are caused by the network is quite small. When DBI signalling is present as in examples provided in Figure V.2.2, Figure V.2.3 and Figure V.2.4, the frequency of the DBI signaling needs to be limited such that terminals do not continuously have to expect new delay budget signaling, i.e., RTCP-FB message frequencies for both available delay budget and requested delay budget signalling need to be limited.

The signalling flow in Figure V.2.5 is a case of jitter buffer adjustment where UE-2 is suffering from poor network performance, e.g. under continuous weak coverage. UE-2 requests additional delay budget from UE-1 during the media flow (Step 3 in Figure V.2.5), e.g., via the use of an RTCP-FB message for DBI signalling as defined in clause 7.3.8, where a certain amount of expected extra delay is indicated. After receiving the request, jitter buffer in UE-1 may be extended (Step 4 in Figure V.2.5) to allow the sender to perform more uplink retransmissions and feedback to UE-2 how much additional delay is available for the uplink retransmissions after jitter buffer adjustment (Step 5 in Figure V.2.5). When UE-2 detects radio performance improved, it could notify UE-1 that it does not need an additional delay via another RTCP-FB message for DBI signalling to request a negative delay budget value (Step 7 in Figure V.2.5) and then UE-1 can shorten the jitter buffer accordingly (Step 8 in Figure V.2.5).

Table V.3.1 demonstrates an example SDP offer with Delay Budget Information (DBI) signalling capability for speech, based on the procedures specified in clause 6.2.8. The offer for DBI is indicated in the last line. The use of RTCP feedback messages carrying 'DBI' is negotiated with the '3gpp-delay-budget' parameter.

m=audio 49152 RTP/AVP 97 98 99 100 101
b=AS:42
b=RS:0
b=RR:2000
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
a=rtpmap:97 EVS/16000/1
a=fmtp:97 br=5.9-24.4; bw=nb-swb; max-red=220
a=rtpmap:98 AMR-WB/16000/1
a=fmtp:98 mode-change-capability=2; max-red=220
a=rtpmap:99 AMR-WB/16000/1
a=fmtp:99 mode-change-capability=2; max-red=220; octet-align=1
a=rtpmap:100 AMR/8000/1
a=fmtp:100 mode-change-capability=2; max-red=220
a=rtpmap:101 AMR/8000/1
a=fmtp:101 mode-change-capability=2; max-red=220; octet-align=1
a=ptime:20
a=maxptime:240
a=rtcp-fb:* 3gpp-delay-budget

An example SDP answer is shown in Table V.3.2, where the DBI signalling capability is also supported by the answerer, as indicated by the last line.

m=audio 49152 RTP/AVPF 97
b=AS:30
b=RS:0
b=RR:2000
a=acfg:1 t=1
a=rtpmap:97 EVS/16000/1
a=fmtp:97 br=5.9-13.2; bw=nb-wb; mode-set=0,1,2; max-red=220
a=ptime:20
a=maxptime:240
a=rtcp-fb:* 3gpp-delay-budget