Discussion: 5GMSd Network Assistance - Synergy with CTA-Wave Common Media Server Data (CMSD)

[dsilhavy]

Problem description

TS 26.501 defines Downlink Network Assistance(NA) as a feature that "enables a UE that is receiving a downlink media stream to improve the QoE of the media streaming session, by being able to make use of two distinct facilities"

Two facilities are described, namely throughput estimation and delivery boost. For this discussion only the throughput estimation seems to be relevant.

5GMSd AF-based downlink network assistance is further defined as:
The Network Assistance (NA) feature enables a UE to receive a bit rate recommendation from the 5GMSd AF that provides the NA server function. The 5GMSd AF provides the response with an estimation of throughput, or the recommendation of a bit rate, for the ensuing nominal time period.

In addition: "Each interaction for the 5GMSd AF-based downlink Network Assistance procedures consists of two steps in sequence...Between the UE (Media Session Handler) and the 5GMSd AF using a 5GMS API at interface M5d"

The goal of this issue is to define synergies between 5GMSd AF-based downlink network assistance and the work done in CTA-WAVE on CTA-5006 Common Media Server Data (CMSD).

Additional context

CMSD

CTA-5006 Common Media Server Data (CMSD) is defined in CTA-WAVE and can be downloaded here.

"The purpose of the Common Media Server Data (CMSD) specification is to define a standard means by which every media server (intermediate and origin) can communicate data with each media object response and have it received and processed consistently by every intermediary and player, for the purpose of improving the efficiency and performance of distribution and ultimately the quality of experience enjoyed by the users."

In the context of this discussion, CMSD defines two relevant parameters:

• etp (Estimated Throughput): The throughput between the server and the client over the currently negotiated transport as estimated by the server at the start of the response.
• mb (Max suggested bitrate): The maximum bitrate value that the player SHOULD play in its Adaptive Bit Rate (ABR) ladder. If the player is playing a bitrate higher than this value, it SHOULD immediately switch to a bitrate lower than or equal to this value.

With CMSD the parameters are typically included in the response headers of the media object requests. Consequently, they are provided by the Origin server and the edge server. Mapping this to the 5GMS architecture, this would be information provided via M4d and not via M5d.

SAND SRA

Moreover, there was some work done by MPEG some time ago in the context of Server and Network Assisted DASH (SAND) and shared resource allocation (SRA). This might be relevant as well for this discussion.

Proposed solution

The goal of this issue is to define synergies between Downlink Network Assistance and the work done in CTA-WAVE on Common Media Server Data (CMSD). It would be good to understand if we can leverage existing functionality as media players such as dash.js have started to implement CMSD. Leveraging this existing functionality could be an easy way to add support for 5GMSd AF-based downlink network assistance.

[rjb1000]

You correctly identify the architectural difference between the CSMD and SAND approaches (in-band signalled in HTTP media response headers) and the 5GMS approach to Network Assistance (session-based interaction between the Media Session Handler and the 5GMS AF).

At present, these approaches are mutually incompatible.

There are two potential ways I can think of to make them compatible:

1. Network-side solution. Allow 5GMSd AS to periodically query 5GMSd AF for estimated throughput and maximum suggested bit rate. The values could then be inserted by the 5GMSd AS in the M4d responses it generates.
   • It would be a fairly major architectural change to expose the Network Assistance API at reference point M3 (in addition to M5).
2. UE-side solution. Expose estimated throughput and maximum suggested bit rate via the M6 Media Session Handling client API. This could be exposed either as state (see TS 26.512 clause 12.2.2.2) or event notifications (TS 26.512 clause 12.2.5) or both. The Media Stream Handler could then read this state or latch the information received in event notifications and add the CMSD headers before they reach the player.
   • This might necessitate an HTTP proxy in the Media Stream Handler to provide the necessary intercept point, so seems quite difficult to achieve transparently.

There are problems associated with both solutions, so neither is ideal. But it's good to open this topic up to debate.

[rjb1000]

(Suggest we refocus attention on TS 26.510 Rel-18.)

[rjb1000]

Reassigned to Rel-19 label reflecting the likelihood that this topic will be studied in the Advanced Media Delivery feasibility study which was agreed at SA4#127 (Sophia Antipolis). The Work Item Description is to be considered for approval at SA#103 (Maastrict).