Advanced Media Delivery - 5G Media Streaming

[dsilhavy]

Background

In the 5G-MAG Reference Tools meetings on October 17th and October 24th we dived into 3GPP Release 19 features, specifically looking at Advanced Media Delivery for 5G Media Streaming.

In this thread, we will discuss the different topics that were presented and what it means to add them to the 5G-MAG Reference Tools.

Links

• Slides: Link

Main topics

• Common Media Client Data (CMCD)
• Multi-access media delivery
• Media delivery from multiple service endpoints/locations, including CMMF and Content Steering
• Distributing DRM-encrypted and high-value content
• Improved QoS support for Media Streaming services including ECN marking for L4S and QoS monitoring
• Media Streaming aspects of Network Slicing

Related Discussions

• Strategy for adding features from new 3GPP releases to the reference tools

[dsilhavy]

Common Media Client Data (CMCD)

Background

CMCD defines a set of structured key/value pairs communicating mutually beneficial media-related information from a player to a CDN.

The use cases which CMCD enables are broad – including robust pre-fetching of content, analytics solutions, forensic debugging, CDN delivery optimization, alerting and monitoring systems, low latency optimizations, server-side switching, research analytics and content steering decision-making.

In the context of 5G Media Streaming, the CMCD information may be used for several purposes that are elaborated further in the remainder of this clause:

1. Operational optimisation of the 5GMSd AS: The Application Server uses CMCD information to optimise its operation. For example, the 5GMSd AS may choose to pre-fetch content from the 5GMSd Application Provider based on the value of the CMCD Next object request key signalled by the Media Player.
2. Operational optimisation of the 5GMSd AF and 5G Media Streaming: The Application Function uses CMCD information in order to configure the 5G System for optimised media delivery across the User Plane. For example, the 5GMSd AF may invoke service operations on the PCF in order to effect a delivery boost if the CMCD Buffer starvation flag is set by the Media Player.
3. UE data collection on media playback and 5GMS reception, reporting and event exposure by 5GMS System: The Application Function uses the data collection and reporting framework to provide CMCD information to the 5G System or to external 5GMS Application Providers. This could, for example, take the form of a time series event log for audit purposes. Such data could, for example, be useful to determine the quality of reception and to identify anomalies or errors that can occur on players.

Links

• CMCD MVP#1 - Project Board
• CMCD MVP#2 - Project Board
• CMCD MVP#3 - Project Board

Specifications

• Stage 3 Support: S4-251463 (26.510) and S4aI250146 (26.512)
• In-band client reporting on M4 defined in TS 26.512, 10.5
• Client data reporting on M3 in TS 26.512, 11.4.3
• Configuration of Reporting via Service URL in TS 26.512, 12.4
• Configurations and settings API for Media Player via M7d and M11d in clause 13.2.4 of TS 26.512
• Event exposure on R5/R6 defined in clause 18.3.3 of TS 26.512
• Inband client reporting in DASH, defined in TS 26.512, Annex G.5

5G-MAG Reference Tools

Which existing components are affected?

• 5GMS Application Function
• 5GMS Application Server
• 5GMS Media Session Handler
• 5GMS Media Stream Handler
• Data Collection Application Function

What needs to be done from a high level?

See project board

How is the support in required 3rd party libraries & frameworks?

• Exoplayer supports CMCD v1 a PoC is available here: 5G-MAG/rt-5gms-media-stream-handler@9986eb1#diff-dfb6e2e6197687e0db0961ceea27696dfd61842410264c841e25493a31fd43ca

What is the estimated effort?

In-band client reporting on M4 defined in TS 26.512, 10.5

Client data reporting on M3 in TS 26.512, 11.4.3

Configuration of Reporting via Service URL in TS 26.512, 12.4

Configurations and settings API for Media Player via M7d and M11d in clause 13.2.4 of TS 26.512

Event exposure on R5/R6 defined in clause 18.3.3 of TS 26.512

Inband client reporting in DASH, defined in TS 26.512, Annex G.5

What is in scope of a first MVP/PoC?

MVP 1

• In-band client reporting via M4
• Log output of CMCD metrics in the AS logs
  • For query mode, this can be derived directly from the Nginx logs
  • For header mode, we might need to add some logic to extract the information (e.g. Lua script to dump key/values)
• Monitoring board

MVP 2

• Provisioning of CMCD configuration via M1
• Configuration of AS via M3
  • Content hosting configuration
  • Allow the AS to retrieve Service Access Information from the AF via M3
• Configuration of client via M5 Service Access Information

MVP 3

• Metrics reporting of CMCD information from AS to AF via M3
• Integration of the DCAF into the 5GMS AF
• Monitoring board
  • Register for events from the DCAF to get the CMCD information
  • Compare radio logs to user logs

What is the value of the feature, what can we demonstrate

• pre-fetch content from the 5GMSd Application Provider
  • can you see an effect in a demo?
• effect a delivery boost if the CMCD Buffer starvation flag
• data collection and reporting framework, monitoring board

Other aspects

• Headless testing with multiple clients

Who is interested and can contribute?

Fraunhofer FOKUS, Qualcomm

[dsilhavy]

Multi-CDN (Service Location) Media Delivery

Background

• 5GMS network provisioning and configuration extensions and APIs to:
  • Provision and expose multiple 5GMS AS service locations at reference point M4
  • Content Preparation to create/update Media Entry Points and/or prepare ingested media for delivery from multiple service locations (e.g., CMMF encoding
  • 5GMS AS service chaining at reference point M10

CMMF is a media delivery standard format that enables simultaneous streaming from multiple sources (e.g., CDNs) using coded media segments. It improves reliability, reduces latency, and enhances playback quality over single-source or multi-CDN switching.

Questions

• Do we do parallel requests for CMMF?
  • Answer by Dolby: Yes, but it is not required. As an example, let’s say that a media player wants to download a segment with relative URL "/path-to-content/seg-1.mp4". This URL is provided to a CMMF Receiver where it is converted into one or more URLs for the CMMF transport objects associated with that segment. For example, the URLs are "https://dist-a.3gppservices.org/path-to-content/cmmf-a/seg-1.mp4" and "https://dist-b.3gppservices.org/path-to-content/cmmf-b/seg-1.mp4". The 5GMS Client will request both CMMF transport resources in parallel. Once the 5GMS Client has downloaded enough information from one or both of these CMMF transport resources, it can decode the media segment for rendering and playback.
• Can we separate multi-CDN support from CMMF
  • Content Steering
    • Yes. The 5GMS System support multiple multi-CDN (multi-service location) approaches.
  • CMMF
• Can CMMF and Content steering information be signaled in the Service Access Information?
  • This information is signaled within the Media Entry Point, which can be signaled within the Service Access Information if the 5GMS System is provisioned appropriately (e.g., a Media Entry Point is identified when provisioning the Content Hosting Configuration).

Links

• CMMF project board
• Content Steering project board

Specifications

• Procedures for service chaining M10d and external interfaces M13d

• General summary in TS 26.510, clause 10.3A

• DASH content distribution using multiple service locations, Annex G.4 of TS 26.512

  • Content Steering for DASH (Reference to ETSI TS 103 998)

• Media streaming in the 5GMS System using CMMF, Annex H of TS 26.512

  • Protocols and formats for downlink media streaming using CMMF with reference to ETSI TS 103 973 

• CMMF: ETSI TS 103 973

5G-MAG Reference Tools

Which existing components are affected?

• 5GMS Media Stream Handler
• 5GMS Application Server

What needs to be done from a high level?

See project boards

How is the support in required 3rd party libraries & frameworks?

• Content Steering is being added to media3 Exoplayer right now
• Dolby might be able to provide a CMMF SDK

What is the estimated effort?

CMMF Support

Content Steering

What is in scope of a first MVP/PoC?

CMMF Support

• Do we want to create our own reference content?

Content Steering

• Do we consider a steering server in the scope of the reference tools?
• Do we want to create our own reference content: MPD with multiple BaseURL elements pointing to different CDNs

Who is interested and can contribute?

Dolby

[dsilhavy]

General feedback by Jason Cloud and @fredericgabin from Dolby. I am pasting the answers to the questions raised initially in this thread directly to the post itself.

3GPP Rel-19 supports network provisioning and delivery of media (both uplink and downlink) from multiple service locations exposed by the 5GMS AS. In general, network provisioning and content hosting is largely independent of the method a 5GMS Client uses to accesses/publish content. An Application Provider can provision the network to expose multiple service locations to clients. It is then up to the client to determine how to utilize those service locations. Current options include:

• Switching between service locations (i.e., client-side switching),
• Switching between service locations based on guidance from a content steering service (i.e., content steering), or
• Using multiple service locations in parallel, where CMMF is one option to do this efficiently.

On the network side, APIs specified in TS 26.510 and TS 26.512 to provision the network have been updated to allow for multiple service locations to be exposed by the 5GMS AS. This is done through the provisioning of multiple distribution configurations (for downlink streaming) or contribution configurations (for uplink streaming) where there is a one-to-one mapping between each distribution/contribution configuration and each service location.

On the client side, the multi-service location method in which to use is communicated within the Media Entry Point. In the case of DASH streaming, the Media Entry Point is an MPD which contains the base URLs of each of the available service locations. A 5GMS Client can use this information to select and/or switch between service locations at will. Furthermore, a MPD may also contain information about a content steering service endpoint that the 5GMS Client should use. In the case of CMMF, the Media Entry Point is a CMMF Configuration Information document or extended FDT as specified in ETSI TS 103 973 V1.1.3. This document contains the necessary information to configure a 5GMS Client to use CMMF, a pointer to a media presentation (e.g., MPD) that describes the content to be streamed, and a method in which to map the URLs contained with a media presentation (e.g., MPD) to CMMF transport objects used to deliver the content from one or more service locations.

[dsilhavy]

Additional feedback by @rjb1000

I would just add that the ability to provision multiple distributions in the Content Hosting Configuration has existed in TS 26.512 since the very outset (Rel-16). The initial usage, first described in Rel-17, is about offering multiple Media Entry Points at a particular distribution, differentiated for example by MIME media type. This allows a single distribution of CMAF content to be consumed via an MPEG-DASH MPD or an HLS master playlist without needing to duplicate caching in the 5GMS AS.

What changed in Rel-19 was that we borrowed the term service location from the MPEG-DASH specification to act as a bridge between the 5GMS System and the rest of the universe. This term also helpfully allows us to talk about a plurality of service endpoints offered by a single logical 5GMS AS function in a given 5GMS System that may be realised as a cluster of physical and/or virtual servers deployed across multiple data centres, for example. At the same time, we also introduced the abstract concept of (dis)affinity between the distributions (service locations) declared in the Content Hosting Configuration as a way of influencing the assignment of logical service locations to physical infrastructure. In particular, CMMF may wish that each content "stripe" is offered from a different resilient endpoint and the (dis)affinity declaration provides a strong hint the 5GMS System about this service requirement without being prescriptive about how the requirement is satisfied by a given implementation and deployment of the 5GMS System.

One other important thing missing from the description in the previous comment is the concept of the Content Preparation Template. This is a document provisioned in the 5GMS AF using the service API at M1 that is then passed to the 5GMS AS (after verifying that its MIME content type is part of the repertoire known to the 5GMS System implementation). In the case of CMMF, the Content Preparation Template associates a particular CMMF encoding configuration with a particular distribution (service location) in the Content Hosting Configuration by means of a cross-referencing identifier (distributionId or contributionId) that is unique within the scope of the Content Hosting Configuration. Part of any reference implementation would require the 5GMS AS to parse and act on this Content Preparation Template to ensure that the right CMMF encoding is exposed at the relevant distribution (service location).

I agree that multiple service locations and CMMF are not inextricably linked, and Jason worked hard to draft the changes to TS 26.512 to accommodate our desire to make that separation clear. The use of multiple service locations by CMMF is specified in the new annex H.

In a similar vein, I agree that content steering is a logically separate topic from CMMF that could be tackled as a (largely) independent development project. In this case, a content steering service is offered to the Media Stream Handler of the 5GMS Client at an additional endpoint of the 5GMS AS. Unlike CMMF, where decoder logic in the Media Stream Handler makes the steering decisions (typically to multiple service locations in parallel), here it is the content steering service in the 5GMS AS that makes steering recommendations which the Media Session Handler may then choose to follow. The content steering signalling from the 5GMS AS to the 5GMS Client is logically part of reference point M4. There are various different content steering signalling protocols around, but the one specified normatively in clause G.4.4 of TS 26.512 is ETSI TS 103 998. In that specification, the set of alternative service locations is pre-declared in the MPD using the BaseURL@serviceId attribute and the messages provided by the content steering service indicate their current relative priority. The Media Stream Handler of the 5GMS Client is required to poll the content steering server in the 5GMS AS whenever the last received content steering message has gone stale.

I think that @dsilhavy's initial impact assessment above is pretty accurate in isolating the scope of change to the Media Stream Handler of the 5GMS Client and the 5GMS AS. It needs to be checked, but I believe that the current Rel-17 reference implementation of the 5GMS System should support provisioning of Content Preparation Template documents at reference point M1, as well as the consequent configuration of these in the 5GMS AS using the pre-standardisation API we developed at reference point M3. (The Mas_Configuration API at this reference point was only formally standardised in Rel-18, off the back of this prototype.)

[dsilhavy]

Multi-Access Media Delivery

Background

UEs connected to multiple access networks (whether they be a 3GPP access network or non-3GPP access network, multiple disjoint 3GPP networks, etc.) may deploy and utilise multi-access techniques using any of the following

• The use of a multipath transport protocols such as MPTCP [RFC6897] or MPQUIC [MPQUIC] is one approach to enable multi-access media delivery. This approach requires implementation of the protocol(s) on both the UE and on the Application Server.
• Another method to enable multi-access media delivery is to use an application layer approach whereby a suitable object coding protocol is employed to enable efficient simultaneous use of the available access networks. The benefit of this approach is that the Application Server can remain agnostic of the UEs’ use of multiple access networks.
• The use of lower-layer network support using ATSSS (Access Traffic Steering, Switching, and Splitting) an optional feature for multi-access supported by the UE and 5G Core network and described in TS 23.501 [2]. The ATSSS feature enables a Multi-Access PDU Connectivity Service allowing for the exchange of PDUs between the UE and a Data Network by simultaneously using one or more 3GPP access networks and/or non-3GPP access networks.

Questions

• Discuss what would be in scope of the reference tools
• What is supported on Android platforms?

Links

• Multi-Access Media Delivery project board

Specifications

• Updates to procedures in clause 4.9 of TS 26.512
• Equivalent work for uplink streaming in clause 5.6 and 5.9
• Extension of Service URL to configure multi-access in clause 12.4
• Extensions to configuration and settings API in 13.2.4 to add

5G-MAG Reference Tools

Which existing components are affected?

• 5GMS Application Server
• 5GMS Media Stream Handler

What needs to be done from a high level?

How is the support in required 3rd party libraries & frameworks?

What is the estimated effort?

What is in scope of a first MVP/PoC?

Who is interested and can contribute?

[dsilhavy]

Distributing encrypted and high-value content

Addresses the case that the content is prepared in the AS for encrypted distribution

Background

Questions

• How are DRM information signaled to the client. If everything is included in the MPD there might be additional implementation tasks on the media player side
• Do we want to support on the fly encryption in the AS?

Links

• 5GMS: Advanced Media Delivery - Distributing encrypted and high-value content

Specifications

• Key exchange for encrypted content in clause 8.8 of TS 26.512
• Content Protection and DRM in DASH
  • DASH content encoding requirements according to DASH-IF-IOP-6
  • Media Player requirements and recommendations according to DASH-IF-IOP-6

5G-MAG Reference Tools

Which existing components are affected?

• 5GMS Application Server
• 5GMS Media Stream Handler

What needs to be done from a high level?

How is the support in required 3rd party libraries & frameworks?

What is the estimated effort?

What is in scope of a first MVP/PoC?

Who is interested and can contribute?

[dsilhavy]

Improved QoS support for Media Streaming services

Background

Questions

Links

• Project board

Specifications

5G-MAG Reference Tools

Which existing components are affected?

What needs to be done from a high level?

How is the support in required 3rd party libraries & frameworks?

What is the estimated effort?

What is in scope of a first MVP/PoC?

Who is interested and can contribute?

[dsilhavy]

Media Streaming aspects of Network Slicing

Background

Questions

Links

• Project board

Specifications

• Stage 2: S4-242016
• Stage 3: S4-251486

5G-MAG Reference Tools

Which existing components are affected?

What needs to be done from a high level?

How is the support in required 3rd party libraries & frameworks?

What is the estimated effort?

What is in scope of a first MVP/PoC?

Who is interested and can contribute?