API to Request the Status of the Network Traffic

[awajs]

From our participation in Proof's of Concept with various carriers it has been desirable to have some method of querying the status of the network. The following Use Case illustrates how this may be used.

Use Case: Adapting Video Encoding to the Network Conditions When processing data from a video camera the bandwidth required is highly dependent on the encoding settings within the camera. The bandwidth can be controlled by either changing the resolution of the video or the encoding quality. 

There is a trade off between video quality and delay. If the delay reaches a threshold it is more desirable to reduce video quality than to have the highest possible video quality. It is desirable to reduce the video quality if it reduces the network delay for the video delivery.

The application monitors an API which provides an indication of the status of the network. This status may include the delay and traffic levels and other parameters that would indicate the performance of the network.

Based on the status that is provided to the Application calling the API, the Application adjusts the encoding level to best suite the condition in network. 

[Kevsy]

I understand the use case - but at least for cellular, the radio air interface (base station to UE) is the most volatile hop, with bandwidth potentially varying by orders of magnitude in under a second due to SINR, reflections, fading, etc.. Hence, querying network status including the radio air interface conditions (received signal strength, scheduler load) risks being stale by the time an application layer API call has returned, due to this volatility...and querying network status not including radio air for the target UE will at best indicate if the core network is congested.

Ideally this would be handled at the applicaiton layer and E2E congestion control, where the effect of varying signal strength is reflected in the receiver rate and resulting change in sender rate. Modern congestion control algorithms such as BBR do a better job at this on cellular than older algorithms (which assumed any delayed ACK meant packet drop, and retransmitted).

As an extension to this, a few years ago I worked on this IETF draft for 'mobile throughput signalling' with Nokia and Google. The network enriches the transport layer of a flow with information on network status, so the endpoints can react accordingly. Early test results were promising, and we could revisit this approach also accounting for Quic.

The CAMARA API angle could be using a service API to request that flows be enriched in-band this way so that an Adaptive Bitrate Video provider can respond faster and more accurately to changing network conditions.

[awajs]

From some previous proof of concept work that we have done it was possible for the network to provide an indication of its congestion and performance. This was made available to an application through a status value that could be queried. From the material at https://www.ietf.org/proceedings/92/slides/slides-92-tsvwg-12.pdf it looks like the Mobile Throughput Guidance Exposure is a method that could be used to measure the status of the network. I think that it would be desirable to have an API that provides the information irrespective of the method used to obtain it.

[eric-murray]

A quick comment on this before the meeting.

Cell congestion monitoring is a supported use case of the NEF, assuming that the RCAF (RAN Congestion Awareness Function) has been deployed in the network. However, this does not appear to be a widely supported network element, nor to have a high priority for deployment. So, in principle, congestion state is something that we could provide, but we are likely to have to use proprietary backend implementations until such time as the RCAF is generally available.

From memory, RCAF allows for 32 possible values for the RAN congestion state. For a "developer friendly" CAMARA version, I'd propose "% congestion" returned as an integer, so 101 possible values.

For achievable throughout and latency guidance, this is a harder problem to solve, and is not a supported use case for the NEF. I'm still considering options here.

[eric-murray]

Having thought about this further, I think we should link throughput and latency guidance to the QoS levels offered by the QoD API. Currently these are relative QoS levels, so THROUGHPUT_L, THROUGHPUT_M and THROUGHPUT_S for throughput, and LOW_LATENCY for latency. There would also be a "default" level, which is what you would get if you didn't ask for enhanced QoS. Traditionally, we call this BEST_EFFORT, though I've always found that term somewhat misleading.

There was some discussion at the last QoD meeting on introducing absolute QoS levels, so ranges measured in Mb/s for throughput and ms for latency. If adopted, then network status guidance could also adopt these QoS levels. If the number of QoS levels is sufficiently small, then we could consider supporting notifications for when the expected QoS level that could be supported changes.

Throughput or latency guidance from a network status API could only be regarded as indicative and not be a guarantee that the device would get these QoS levels if requested via the QoD API. But the guidance could be used by a developer to help decide for which devices it would be worth requesting a higher QoS level.

[jordonezlucena]

@awajs: based on the comments received, what is your approach of moving this forward? I find last comment from Eric quite reasonable. However, to make a decision on Scenera proposal (the decision shall be based on the guidelines to be approved at the next SteerCo meeting), we need to have further details on the expectations of your API proposal, specially on the input/output params, in line with what has been done with the rest of API proposals in the backlog.

[awajs]

@awajs: based on the comments received, what is your approach of moving this forward? I find last comment from Eric quite reasonable. However, to make a decision on Scenera proposal (the decision shall be based on the guidelines to be approved at the next SteerCo meeting), we need to have further details on the expectations of your API proposal, specially on the input/output params, in line with what has been done with the rest of API proposals in the backlog.

Hi Jordon - Once the guidelines have been approved and the template provided I will update the proposal to fit the template.

[jordonezlucena]

@awajs: the guidelines were approved one month ago (https://github.com/camaraproject/Governance/blob/ee5d1709292e564980b7eb2b3c994ca17178b402/documentation/API-onboarding.md). If you want this API proposal to move forward, please take action

[jordonezlucena]

It is proposed to close this issue for now, unless a partner wants to bring a 'network status API proposal'. In such a case, the issue will be re-opened accordingly to resume the discussion.