top of page

02.05.24 - 5G-MAG Workshop with 3GPP SA4: “Advanced Media Delivery"

5G-MAG members are invited to join this Workshop on “Advanced Media Delivery”

Introductory session on the 18th April 2024 – 14:00 CEST

Main Session with 3GPP SA4 on the 2nd May 2024 - 15:30 CEST

3GPP is kicking off a Feasibility Study on Advanced Media Delivery in the context of potential improvements and extensions involving, among others, Common Client Metadata, Common Server-and Network-Assisted Streaming, Multi-CDN and Multi-Access Media Delivery, Modem Usage Optimized Media Streaming, DRM and Conditional Access, In-session Unicast Repair for MBS Object Distribution, MBS User Service and Delivery Protocols for eMBMS, Selected MBMS Functionalities not supported in MBS, DASH/HLS Interoperability, Further harmonization of RTC and Streaming for Advanced Media Delivery, Improved QoS support, Impacts and opportunities of QUIC for segmented content delivery.

In addition, issues coming from the implementation of specifications under the 5G-MAG Reference Tools are also expected to be shared.

Additional information can be found in:


Introductory session on the 18th April at 14:00 CEST:

Main Session with 3GPP SA4 on the 2nd May at 15:30 CEST:


Some more background on the issues under discussion:

  1. Common Client Metadata: While 3GPP and MPEG in DASH support DASH metrics, the reporting is not common to any player, for example all DASH players as well as HLS players. As an example, CTA WAVE has developed: CTA-5004: Web Application Video Ecosystem Common-Media-Client-Data (CMCD) with an excellent overview here: It is worthwhile to study the benefits of integrating commonly supported metrics and client data reporting in 5GMS workflows. The focus is the integration of already defined metrics rather than developing new metrics. Examples of study include support of specific metric keys, player APIs, sending options from client to server (user plane, M5 reference point, EVEX), M3 reference point impact, as well as usage of the data in operations. A study of creating a common harmonized reporting framework and studying the interaction of different frameworks may be included.

  2. Common Server-and Network-Assisted Streaming: MPEG-DASH supports Server and Network Assisted DASH (SAND). Certain profiles of SAND were adopted in TS 26.247, but the industry has generalized the concepts in SAND in efforts such as Content Steering (see ETSI TS 103 998), Web Application Video Ecosystem (WAVE) specification for Common Media Server Data (CMSD), or Addressable Resource Index (ARI) Tracks in MPEG. The study and integration of these technologies into the Media Delivery System and MBS/MBMS workflows is of significant interest, in particular also in combination with existing QoS mechanisms.

  3. Multi-CDN and Multi-Access Media Delivery: Content distributors often use multiple Content Delivery Networks (CDNs) to distribute their content to tend-users. As an example, they may upload a copy of their catalogue to each CDN, or more commonly have all CDNs pull the content from a common origin. In advanced deployments, technologies such as Coded Multisource Media Format (CMMF) use Application Layer FEC techniques to stripe different subsets of content across multiple CDNs. Different client implementations may then beneficially use the content on multiple CDNs, potentially guided by the service or network provider. In addition, formats and techniques for generating content for multiple CDN delivery such as MPEG-DASH Part 9 (ReAP) may be taken into account. Further extensions include the ability for a client to use multiple access networks at the same time to support media delivery. Study of integration of different technologies into the Media Delivery System is of relevance to address content provisioning, content hosting, impacts on user plane reference points M2 and M4, and on media session handling at reference point M5 as well as potential benefits in terms of quality and resource usage.

  4. Modem Usage Optimized Media Streaming: In Rel-18, basic support for Background Data Transfer is added. UE power resources are constrained, and media delivery typically also results in power consumption if the radio is always connected. In order to better support streaming services, requests and access to the modem and the resources should be well balanced. Enhancements to Background Data Transfer to support preload as well as functionality of what is defined in W3C Managed Media Source Extension to minimize active network connections are relevant topics to study with the aim of limiting battery consumption in the UE resulting from media delivery.

  5. DRM and Conditional Access: DRM and Conditional Access are commonly used by third-party streaming services. However, in case streaming is done through MBS or MBMS, a more careful management of the keys needs to be checked. Scalability of key delivery is an issue. The support for -encrypted content in Unicast/Multicast and Broadcast is relevant. Integration of Content Protection interfaces in the provisioning, for example using CPIX back-end interfaces is of high relevance for the industry and should accordingly be studied. The impacts of these on media plane (reference points M2 and M4) as well as the media session handling APIs (reference points M3, M5) should also be studied.

  6. In-session Unicast Repair for MBS Object Distribution: For live and low-latency live services using the Object Distribution Method in MBS, in certain cases the transmission of an object is not successful. In this case, unicast repair for individual MBS Clients can improve the service quality. However, the timing of such requests needs to be carefully studied in order to avoid network overloads or significant latencies in the delivery. A study to extend MBS User Services and object streaming to address in-session repair is of relevance.

  7. MBS User Service and Delivery Protocols for eMBMS: The MBS User Service architecture and protocol follows the modern design philosophies of the 5G System with separation of user services from transport, a service-based architecture and RESTful APIs. At the same time, eMBMS and enTV as used for LTE-based 5G Broadcast support a transparent delivery mode. While interworking in between MBMS and MBS is addressed in TS 23.247, interworking between these two systems at the User Service level is not addressed. In order for MBMS and LTE-based 5G broadcast to leverage MBS User Service technologies, a study is warranted to identify the gaps to fully support this functionality.

  8. Selected MBMS Functionalities not supported in MBS: In completing TS 26.502 and TS 26.517, it is obvious that only a subset of the MBMS functionalities is supported in Rel-17. While many MBMS functionalities are likely not important to be supported for MBS, a systematic analysis of MBMS User Services features and their potential relevance for MBS should be completed and recommendations made on which ones to migrate to MBS User Services specifications and how best to achieve this.

  9. DASH/HLS Interoperability: DASH/HLS interoperability is a key issue to support highly scalable distribution systems for CDN-based distribution as well as for MBS/MBMS distribution. Offering common CMAF segments that can be consumed by both DASH and HLS media players promises to address these issues. However, detailed nuances need to be identified to ensure optimized delivery and CTA WAVE has provided detailed guidelines in CTA-5005-A to support this matter. Studying these guidelines and understanding the impacts on the 5GMS System as well as MBS/MBMS distribution is of relevance. In addition, formats and techniques supporting DASH/HLS interoperability such as MPEG-DASH part 9 (ReAP) may be taken into account.

  10. Further harmonization of RTC and Streaming for Advanced Media Delivery: With the creation of TS 26.510 in Rel-18, Media delivery across the 5G Media Streaming (5GMS) System and the Real-time media Communication (RTC) System was harmonized. However, not all functionalities from TS 26.512 are yet commonly available for RTC as well. Study of further harmonization is encouraged to fully implement common Media Delivery functions.

  11. Issues identified by Market Representation Partners, in particular 5G-MAG: Through the development in 5G-MAG of reference implementations for MBMS, 5GMS and MBS, 5G-MAG is identifying specific problems which are collected in While some of the issues are purely related to bug fixes, some of the issues may require study by SA4 and the development of new functionalities in the relevant technical specifications. It is vital to support the industry and MRPs in deploying 3GPP technologies.

  12. Improved QoS support: In Rel-18, SA2 has defined a number of new features in the 5G System, especially in the PCF, from which media delivery may benefit. Examples documented in TS 23.501 include the use of Explicit Congestion Notification (ECN) to support Low Latency, Low Loss, Scalable Throughput (L4S) services (clause 5.37.3), PDU Set handling (clause 5.37.5) and QoS Monitoring (clause 5.45), and there are likely others. The impact and usefulness of selected features is preferably studied. The functions identified in this context may be studied in one or more of the above work topics.

  13. Impacts and opportunities of QUIC for segmented content delivery: Since the finalisation of the QUIC protocol by the IETF in May 2021, there has been significant deployments of QUIC driven by the usage of HTTP/3 for streaming services. In the IETF, the working group on Media Over QUIC (MOQ) is working towards an extensible protocol for publishing media for ingest and distribution. While QUIC is mostly used today as the underlying protocol of HTTP/3, there is still open questions as to how media segments are delivered over QUIC streams when using HTTP/3 but also considering other QUIC-based protocols such as MOQ. Considering different types of media application, e.g. multi-stream use cases, will be of interest. Studying the various strategies for delivering segmented content over QUIC streams will also bring insights for the network management aspects. For instance, findings in this domain may be relevant to WT#2.1 in the ongoing study in SA2 called FS_XRM_Ph2 (SP-231671) whose deliverable is available as TR 23.700-70.


bottom of page