V.2 Example Signaling Flows on Delay Adaptation

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

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

Figure V.2.1: Signaling flow on usage of RAN delay budget reporting in MTSI without DBI signalling.

Step 1: UE-1 sends UE-2 rate request via CMR or RTCP-APP for voice at bitrate R0. The "Request" message here is a generalized application level rate request message that corresponds to CMR or RTCP-APP for voice.

Step 2: UE-2 sends RTP media flow for voice with bitrate R0.

Step 3: UE-1 detects good radio conditions locally, e.g., eNB-1 sends a DL access network bitrate recommendation (ANBR) of bitrate R1 > R0 to UE-1, and UE-1 measures low block error rate (BLER) over the local radio link based on the monitoring of successful downlink packet transmissions, and it may also measure downlink throughput over the radio air interface that is much higher than the received bitrate (after accounting for the relevant headers). In the meantime, UE-1 detects high packet losses after monitoring reception of RTP packets (also by monitoring RTCP sender and receiver reports) and applying the highest possible jitter buffer according to the reference Jitter Buffer Management (JBM) in clause 8 (subject to the JBM compliance requirement of MTSI). Hence, UE1 concludes that UE2’s local radio conditions are poor.

Step 4: UE-1 sends a UEAssistanceInformation message as specified in TS 36.331 [160] to eNB-1 with type-1 to turn off cDRX. It is assumed that eNB-1 grants this request and turns off cDRX for UE-1. Turning off cDRX is relevant only when PLR is high, which is the conclusion of UE-1 in this example, as per Step 3. It should however be noted that UE-1 can increase the JBM depth to compensate the delay for high jitter. In this scenario, delay budget request from UE-1 to eNB-1 is not necessary and UEAssistanceInformation message may not be sent. Moreover, due to other considerations, UE-1 may choose not to turn cDRX off, e.g., when saving battery power is critical.

Step 5: UE-2 detects high packet losses on its uplink due to poor coverage conditions, e.g., it may measure high BLER over its local radio link based on the monitoring of successful uplink packet transmissions, e.g., by monitoring the HARQ acknowledgements received. UE-2 requests additional delay budget from eNB-2 in order to perform additional re-transmissions to increase the reliability of its UL transmissions. When requesting this additional delay budget, UE-2 may also consider end-to-end RTT measured based on RTCP reports. It is assumed that eNB-2 grants this request. Because UE-1 has already turned its cDRX off, it is unlikely that the JBM constraint at UE-1 will lead to packet losses in response to the increase air interface delay over the RAN corresponding to UE-2.

Step-6: UE-1 measures reduced packet losses and improved voice quality.

It should be noted that the actions of UE-1 in Steps 3-4 above and actions of UE-2 in Step 5 above are completely independent and these are not necessarily sequential, as there is no coordination between the two UEs in this example.

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.

Figure V.2.2: Signaling flow on usage of RAN delay budget reporting with uni-directional DBI signaling in MTSI.

Steps 1-4: These are identical to the earlier signalling flow in Figure V.2.1.

Step 5: If delay budget information signalling is supported between UE-1 and UE-2, UE-1 sends an RTCP feedback (RTCP-FB) message as specified in clause 7.3.8 to UE-2 indicating the availability of additional delay budget due to cDRX being turned off. A concrete delay number may also be reported as part of the RTCP-FB message that corresponds to the air interface delay reduction on UE-1’s RAN after turning off cDRX, which would essentially be available for UE-2 to improve the reliability of its uplink transmissions. The reported delay number may also be determined considering UE1’s JBM constraints and can be based on its assessment of how much additional delay it can tolerate.

Step 6: UE-2 detects high packet losses on its uplink due to poor coverage conditions. UE-2 requests additional delay budget from eNB-2 in order to perform further re-transmissions to increase the reliability of its UL transmissions. When requesting the additional delay budget from eNB-2, UE-2 may also consider the RTCP-FB message it received from UE-1 on the availability of delay budget from UE-1’s perspective. It is assumed that eNB-2 grants this request.

Step-7: UE-1 measures reduced packet losses and improved voice quality.

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:

a) Allowing UE-2 to use more retransmission will increase the jitter. This may potentially cause more packets dropped at the JBM for UE-1.

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

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

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

Figure V.2.3: Another signaling flow on usage of RAN delay budget reporting with uni-directional DBI signalling in MTSI.

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:

Step 8: UE-1 sends UE-2 rate request via CMR or RTCP-APP for voice at bitrate R2 < R0. Other kinds of adaptation may also be invoked, for instance the use of application layer redundancy or transitioning to a more robust codec mode based on the negotiated codecs (e.g., channel-aware mode for EVS), in case the receiver side detects major packet loss but delay and jitter are within desired bounds.

Step 9: UE-2 sends RTP media flow for voice with bitrate R2.

Figure V.2.4: Signaling flow on usage of RAN delay budget reporting in MTSI with bi-directional DBI signalling.

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 Figures V.2.2, V.2.3 and 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.

Figure V.2.5: Signaling flow on usage of RAN delay budget reporting in MTSI with bi-directional DBI signalling and jitter buffer adjustment.

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