This documentation is currently under development and subject to change. It reflects outcomes elaborated by 5G-MAG members. If you are interested in becoming a member of the 5G-MAG and actively participating in shaping this work, please contact the Project Office
How It Works
Intro
5GMS is a 3GPP framework for high-quality, efficient delivery of media, supporting services from mobile network operators and third parties in both Downlink (5GMSd) and Uplink (5GMSu) directions. It is not a separate network but a functional extension of the standard 5G System Architecture, adding media-specific control, hosting and reporting functions on top of the existing 5G System so that media delivery can be provisioned, managed and measured in a standardised way. The architecture is functionally divided into independent components, enabling deployments with different degrees of integration between operators and content providers.
The remainder of this page focuses on downlink (5GMSd), the direction covered by the 5G-MAG reference tools; see Uplink variant below for how uplink differs. This page is the technical analysis: architecture and features distilled to how the system works. For the normative specification list and Work Items/CRs, see Standards: 5G Media Streaming instead.
Architecture
The diagram below shows the general 5GMS architecture, with the functional entities and the reference points that connect them.
Figure: General 5GMS architecture and its reference points.
The main functional entities are:
- 5GMS Application Provider: The entity that uses the 5G network to deliver content. It provides a 5GMS Aware-Application on the UE to make use of 5GMS Client and network functions via 5GMS interfaces and APIs.
- 5GMS Application Function (5GMS AF): A specialized application function dedicated to the management and optimization of media streaming sessions.
- 5GMS Application Server (5GMS AS): A specialized application server whose primary job is to store, cache, and deliver media content to the User Equipment (UE) or to receive and ingest media from the UE.
- 5GMS Client: The functional part of the user's device (UE) that handles the media session and the player/streamer logic.
Downlink specialisation (5GMSd)
To deliver downlink streaming services, the network is the origin of the media and the UE acts as the consumption device. The downlink entities below are the same general roles introduced above, specialised for the downlink direction and carrying a "d" suffix.
Figure: Downlink (5GMSd) architecture, media flowing from network to device.
- 5GMSd Application Provider: The external entity responsible for the "source" side of the media, including creating, encoding, and formatting the content. It utilizes 5GMSd interfaces to deliver this media to the user's application.
- 5GMSd AS: The hosting environment for media content. It can be a single server or a distributed network, such as a Content Delivery Network (CDN), to optimize delivery.
- 5GMSd AF: The control-plane entity providing management functions to the device's Media Session Handler and the Application Provider. It also acts as the bridge to the 5G Core, interacting with the PCF or NEF.
- 5GMSd Client: The primary receiver on the device for downlink streaming services. It consists of two sub-components, which communicate through the UE-internal APIs at reference points M6d and M7d; these APIs may be exposed to the 5GMSd-Aware Application, or kept private when the Client is implemented as a single self-contained (monolithic) block:
- Media Session Handler: The "control brain" on the device. It coordinates with the 5GMSd AF to set up and manage sessions while gathering data like Quality of Experience (QoE) and consumption metrics.
- Media Player: The "data engine" on the device. It communicates with the 5GMSd AS to fetch and play the actual media stream. It provides playback controls to the app and session status to the Session Handler.
- 5GMSd-Aware Application: An external app (e.g., a streaming service) that holds the provider's specific logic. Uses standardized APIs to initiate and manage media sessions.
The 5GMSd Client may include several subfunctions, depicted below.
Interfaces (M1–M8)
In 3GPP terminology a reference point is a named interface between two functional entities, defining the interactions that cross it (it may or may not be exposed as a public API). The reference points below map to the M6d and M7d interfaces mentioned above for the on-device sub-components. Note that M3d is an internal, unspecified interface between the 5GMSd AF and AS, and M8d is a service-level interface between the application and the provider that is not specified by 3GPP.
| Interface | Name | Description |
|---|---|---|
| M1d | 5GMSd Provisioning API | External API exposed by the 5GMSd AF; allows the Application Provider to configure the system for downlink streaming and receive feedback. |
| M2d | 5GMSd Ingest API | Optional external API exposed by the 5GMSd AS; used for uploading content when the AS is hosted within a trusted Data Network. |
| M3d | Internal Interface | An unspecified internal API used for information exchange between the 5GMSd AF and AS regarding content hosting. |
| M4d | Media Streaming APIs | The primary data-plane APIs exposed by the 5GMSd AS to the Media Player for streaming media content. |
| M5d | Media Session Handling API | Control-plane APIs between the 5GMSd AF and Media Session Handler for session control, QoE reporting, and security (auth/auth). |
| M6d | UE Media Session Handling APIs | Internal UE APIs that allow the 5GMSd-Aware App and the Media Player to access 5GMS session functions. |
| M7d | UE Media Player APIs | Internal UE APIs used by the 5GMSd-Aware App and Session Handler to control playback and media engine functions. |
| M8d | Application API | An external interface for "service-level" exchange (like metadata or login) between the App and the Provider. This is not specified by 3GPP. |
Uplink variant (5GMSu)
The same architecture is mirrored for the uplink direction, where the UE is the source of the media and the network ingests it. The functional entities and reference points carry a "u" suffix in place of "d".
The main differences from downlink are:
- The 5GMSu Application Provider consumes or further distributes the media that the UE sends, rather than sourcing it.
- The 5GMSu AS receives and ingests media from the UE instead of hosting and delivering it.
- The 5GMSu Client contains a Media Streamer in place of the Media Player. The Media Streamer captures, encodes and transmits the media on the uplink; the Media Session Handler role is unchanged.
- On M4u the media flows from the UE to the AS (media egest), the reverse of the downlink M4d.
- M2u carries content egest from the AS towards the Application Provider, the counterpart of the downlink M2d ingest.
M1u (provisioning) and M5u (media session handling) play the same control-plane roles as in downlink. The 5G-MAG reference tools implement the downlink direction (5GMSd); the uplink direction is defined by the same specifications but is not covered by the reference tools today. Low-latency and interactive uplink use cases relate to the Real-Time Communications (RTC) system; see Real-time Media Communication (RTC) Architecture where documented.
Features
The following features are defined for 5GMSd. The clause references below point into the specifications; for the detailed reference-point and API breakdown of each feature, see the 5GMSd Features page.
| Feature | Defined in (TS 26.501 clause) | Procedure (TS 26.501 clause) | APIs |
|---|---|---|---|
| Content hosting | 3GPP TS 26.501 4.0.2 | 3GPP TS 26.501 5.4 | 3GPP TS 26.510 + 26.512 |
| Network assistance | 3GPP TS 26.501 4.0.5 | 3GPP TS 26.501 5.9 | 3GPP TS 26.510 + 26.512 |
| Dynamic policies | 3GPP TS 26.501 4.0.6 | 3GPP TS 26.501 5.7 (5.8 for the network-slicing variant) | 3GPP TS 26.510 + 26.512 |
| Consumption reporting | 3GPP TS 26.501 4.0.8 | 3GPP TS 26.501 5.6 | 3GPP TS 26.510 + 26.512 |
| QoE metrics reporting | 3GPP TS 26.501 4.0.9 | 3GPP TS 26.501 5.5 | 3GPP TS 26.510 + 26.512 |
| Edge processing | 3GPP TS 26.501 4.0.10 | 3GPP TS 26.501 8 | 3GPP TS 26.510 + 26.512 |
| eMBMS delivery | 3GPP TS 26.501 4.0.11 | 3GPP TS 26.501 5.10 | 3GPP TS 26.510 + 26.512 |
| Data collection, reporting and exposure | 3GPP TS 26.501 4.0.12 | 3GPP TS 26.501 5.11 | 3GPP TS 26.510 + 26.512 |
Runtime flow and implementation blueprint
At runtime the features are used in two stages: first the Application Provider provisions the service by creating one or more Provisioning Sessions — each specifying whichever 5GMSd features it needs, from Content Hosting Configurations, Content Preparation Templates and Server Certificates to Policy Templates, Consumption Reporting, Metrics Reporting, Edge Resources and Event Data Processing Configurations. Then the Client retrieves the Service Access Information it needs — the parameters and addresses to activate and control the streaming session and to report consumption and QoE metrics — either embedded in the M8d service announcement or fetched directly from the 5GMSd AF.
At runtime the reference points are exercised in a repeatable order. This is a schematic view of the downlink case; the exact procedures are specified in TS 26.501 (clause 5) and the APIs in TS 26.510 and TS 26.512.
- Provisioning (M1d). The 5GMSd Application Provider creates a Provisioning Session on the 5GMSd AF and attaches the configurations it needs (Content Hosting Configuration, Server Certificates, Policy Templates, Consumption Reporting Configuration, Metrics Reporting Configurations, and where used Content Preparation Templates, Edge Resources Configurations and Event Data Processing Configurations).
- AS configuration (M3d). The AF configures the AS internally for the provisioned service. M3d is not standardised, so the AF-to-AS exchange is implementation-specific.
- Ingest (M2d). Content is ingested into the AS, either pulled by the AS or pushed to it, depending on the ingest protocol chosen in the Content Hosting Configuration.
- Service announcement (M8d) and Service Access Information (M5d). The Aware Application learns of the service (over the out-of-scope M8d interface) and the Media Session Handler obtains the Service Access Information, either embedded in the M8d announcement or fetched from the AF over M5d.
- Media session (M4d). The Media Player fetches and plays the media from the AS over M4d, typically DASH or HLS over HTTP, coordinating with the Media Session Handler over the UE-internal M6d and M7d APIs.
- In-session control and reporting (M5d). During playback the Media Session Handler can invoke dynamic policies and network assistance, and report consumption and QoE metrics, all over M5d.
The schematic view above condenses the two baseline procedures TS 26.501 actually specifies step by step: progressive download of on-demand content (Clause 5.2.2, Figure 5.2-1) and DASH streaming (Clause 5.2.3, Figure 5.2-2). Both assume the Application Provider has already provisioned the system and the Aware Application has received a service announcement. See the Implementation Blueprints index for the other blueprints on this portal.
| Step | Interface | What happens | Clause |
|---|---|---|---|
| 1. Discover the service | — | The Aware Application runs Service Announcement and Service/Content Discovery (out of scope of TS 26.501); the announcement carries either the full Service Access Information or just a reference to it | 5.2.2/5.2.3 (step 1 of each) |
| 2. Select content and start playback | — | The application picks a Media Player Entry and triggers playback: the Media Session Handler (progressive download) or the 5GMSd Client as a whole (DASH) | 5.2.2/5.2.3 (steps 2–3) |
| 3. Resolve Service Access Information | M5d | If only a reference was announced, the Media Session Handler fetches the full Service Access Information from the 5GMSd AF | 5.2.2/5.2.3 (step 4) |
| 4. Start the Media Player | M6d/M7d | The Media Session Handler triggers the Media Player, which establishes its transport session | 5.2.2 (steps 5–6); 5.2.3 (steps 5–6) |
| 5. Acquire manifest and initialise | M4d | Progressive download: the Player requests and receives initialization information directly. DASH: the Player first requests and processes the MPD to size the needed transport sessions and initialise the decode/render pipeline (and DRM, if used) | 5.2.2 (steps 7–9); 5.2.3 (steps 6–13) |
| 6. Notify session state | M6d/M7d | The Player tells the Media Session Handler about the transport session and content (and, for DASH, that it's ready to start) | 5.2.2 (step 10); 5.2.3 (steps 10, 14) |
| 7. (Optional) Acquire DRM licence | — | The Player fetches a DRM licence from the Application Provider if the content is protected | 5.2.2 (step 11); 5.2.3 (step 11) |
| 8. Stream and render | M4d | The Player requests and receives media (segments, for DASH) continuously, feeding the rendering pipeline until playback ends | 5.2.2 (steps 12–13); 5.2.3 (steps 15–19) |
Checked directly against TS 26.501 V19.4.0. Every clause number in the feature table above is confirmed correct except one, now fixed: "Dynamic policies" pointed only to Clause 5.8 ("Dynamic Policy based on Network Slicing"), a specific sub-case; the general dynamic-policy establishment procedure is Clause 5.7 ("Establishing a unicast downlink media streaming session with 5GMSd AF interactions for dynamic policy updates"), now cited alongside it. The blueprint table above paraphrases the numbered steps of Clauses 5.2.2 and 5.2.3 rather than reproducing 3GPP's text, consistent with the copyright approach used elsewhere on this portal.