See also: Developer Exchange.
This is the same architecture as the project index, broken down feature by feature against TS 26.501's own definitions — what's fully implemented, what's partial, and what isn't started yet.
What This Project Implements
The functional entities of 5G Media Streaming, instantiated for 5G Unicast Downlink Media Streaming (5GMSd), including support for various of the features specified, reference points and APIs.
5G Media Streaming (5GMS) is a 3GPP framework for high-quality, efficient delivery of media, supporting services from Mobile Network Operators (MNOs) and third parties in both Downlink (5GMSd) and Uplink (5GMSu) Media Streaming. The 5GMS architecture is functionally divided into independent components, enabling deployments with various degrees of integration between 5G MNOs and Content Providers.
For the full M1-M8 reference-point table (the named interfaces between these components), see 5GMS Overview: Interfaces for 5GMSd — kept as one canonical copy rather than repeated here.
The reference tools developed by 5G-MAG for 5GMSd consist of four main components: the 5GMSd Application Function (AF) (rt-5gms-application-function), which exposes the M1 provisioning and M5 session handling interfaces; the 5GMSd Application Server (AS) (rt-5gms-application-server), which caches and delivers media objects to clients; the Media Session Handler (rt-5gms-media-session-handler), an Android background service that manages the streaming session on the User Equipment (UE) side; and the Media Stream Handler (rt-5gms-media-stream-handler), which handles media playback using the configuration provided by the Media Session Handler. In TS 26.501 terms the Media Stream Handler plays the role of the downlink Media Player.
Scope boundaries worth noting up front:
- The uplink direction (5GMSu), where the UE is the media source, is defined by the same specifications but is not implemented by these tools.
- Several fields accepted by the M1 Content Hosting API are not yet implemented (Content Preparation, Edge Resources, geo-fencing and URL signing); see the notes in the "Feature: Content Hosting" section below.
- The generic UE data collection and event exposure framework (TS 26.531 and TS 26.532) is provided as a separate project (UE Data Collection, Reporting and Event Exposure) and is not yet wired into 5GMS; see the "Feature: Data collection, reporting and exposure" section below.
The reference tools implement the downlink direction (5GMSd) against the Release 17 normative baseline. They track the Release 18 changes (where the session-handling APIs move from TS 26.512 into TS 26.510 and are generalised across the 5GMS and RTC systems).
Technical documentation providing context to this project can be found in the link below.
Tech: Streaming, Media Delivery & Data Collection
A list of relevant specifications can be found in the link below.
Deployment Configurations
The Reference Tools can be combined in several deployment configurations, each pairing 5G Media Streaming with a different set of supporting projects.
5G Downlink Media Streaming (5GMSd)
The baseline configuration: the 5GMSd tools delivering adaptive bitrate streaming over 5G unicast.
5G Downlink Media Streaming (5GMSd) with UE Data Collection Reporting and Event Exposure
Adds the UE Data Collection, Reporting and Event Exposure project so that consumption and quality data can feed analytics and event subscribers.
- 5G Media Streaming
- UE Data Collection, Reporting and Event Exposure
- 3GPP RAN and Core Platforms
- Common Tools: Repositories
5G Downlink Media Streaming (5GMSd) with 5GC Service Consumers
Adds the 5G Core (5GC) Service Consumers project, letting the AF consume core network APIs (for example for policy and QoS control).
5G Downlink Media Streaming (5GMSd) over eMBMS
Combines 5GMSd with the 5G Broadcast and content delivery projects to distribute content over evolved Multimedia Broadcast Multicast Service (eMBMS) broadcast bearers.
- 5G Media Streaming
- 5G Broadcast
- Content Delivery Protocols
- 3GPP RAN and Core Platforms
- Common Tools: Repositories
5G Unicast Downlink Media Streaming (5GMSd)
A functional 5GMSd implementation is available with the building blocks highlighted with the green tick below.
Figure: 5GMSd downlink architecture. Entities marked with a green tick are implemented by the 5G-MAG Reference Tools.
This includes the implementation of the following entities: 5GMSd Application Provider, 5GMSd AS, 5GMSd AF, 5GMSd Client (with Media Session Handler and Media Player) and 5GMSd-Aware Application.
Note that before the required features of the 5GMS System can be used by 5GMS Clients, they are first provisioned by a 5GMS Application Provider creating one or more Provisioning Sessions. The 5GMSd Application Provider can then specify one or more 5GMSd features in the Provisioning Session. The Provisioning Session information may include Content Hosting Configurations, Content Preparation Templates, Server Certificates, Policy Templates, a Consumption Reporting Configuration, Metrics Reporting Configurations, Edge Resources Configurations and Event Data Processing Configurations.
Once created, this is a representation of a Provisioning Session:
{
"provisioningSessionId": "string",
"provisioningSessionType": "DOWNLINK",
"aspId": "string",
"appId": "string",
"serverCertificateIds": ["string"],
"contentPreparationTemplateIds": ["string"],
"metricsReportingConfigurationIds": ["string"],
"policyTemplateIds": ["string"],
"edgeResourcesConfigurationIds": ["string"],
"eventDataProcessingConfigurationIds": ["string"]
}
Where:
provisioningSessionId: A unique identifier for this Provisioning Session.provisioningSessionType: The type of Provisioning Session.aspId: The identity of the Application Service Provider responsible for this Provisioning Session.appId: The Application Identifier to which this Provisioning Session pertains.
Docker deployment support
Docker-Compose setups are provided to run the 5GMS Application Function, the 5GMS Application Server and the 5GMS Application Provider in Docker container environments.
Implementation status board
Status key: Yes implemented · Partial partially implemented · Hold on hold (a decision to wait) · To check not yet independently verified · No not implemented · N/A out of scope.
TS 26.501 / TS 26.5125GMS Downlink (5GMSd) Features2/8
| Feature | Status | Notes |
|---|---|---|
| Content Hosting | Partial | Base ingest/hosting is implemented; Content Preparation, Edge Resources, geo-fencing and URL signing are accepted by the API but not yet implemented by the Reference Tools. |
| Network Assistance | Partial | Only Delivery Boost is currently implemented by the Reference Tools; Throughput Estimation is still in development. |
| Dynamic Policies | Partial | The base feature is implemented; of the Service Data Flow Description methods, only 5-Tuple is implemented (2-Tuple, ToS, Flow Label and Domain Name are not). |
| Consumption Reporting | Yes | |
| QoE Metrics Reporting | Yes | Currently supports the HTTP request/response list, Representation Switch Events, Buffer Level and MPD Information metrics. |
| Data Collection, Reporting and Exposure | No | Not yet implemented within the framework of 5GMS. A generic UE data collection architecture exists separately under the UE Data Collection, Reporting and Event Exposure project, not yet wired into 5GMS. |
| Edge Processing | No | |
| eMBMS Delivery | To check | No existing site content states this feature’s implementation status either way; genuinely not yet assessed. |
Six of the eight rows above carry real status already published on this site (this project's own former per-feature prose and the Tutorials page's own per-interface checkbox table), carried forward rather than discarded — not an independent code audit performed this pass; see each row's statusEvidence in src/data/blueprints/5gms.js for exactly what it's based on. The real, independent code audit (re-checking each row against the repos directly) is a separate, later effort.
What's still pending
No curated "good first issue" list exists for this project, so the rows above are the real gaps, each pointing at the repo that owns it and, where one exists, its real tracking issue.
Feature Deep Dives
Reference points, APIs, JSON configuration schemas and worked detail for each 5GMSd feature, one level deeper than the status board above.
Content Hosting
The content hosting feature provides a service equivalent to a Content Delivery Network (CDN) deployed inside or outside the Trusted DN. It includes selecting the ingest protocol and format, caching and proxying of media objects, content preparation, access protection (e.g. URL signing) and indicating a target distribution area (e.g. through geofencing).
The following are the reference points and APIs.
-
At M1:
-
At M5:
Once a Provisioning Session is established using the API at interface M1d, Content Hosting can be configured. The security of the content published to the 5GMS System may be guaranteed by a provisioned Server Certificate.
This is a JSON scheme of a Content Hosting Configuration, which tells the 5GMS System where to ingest content from and how to distribute it:
{
"name": "string",
"ingestConfiguration": {
"pull": true,
"protocol": "string",
"baseURL": "string"
},
"distributionConfigurations": [
{
"entryPoint": {
"relativePath": "string",
"contentType": "string",
"profiles": ["string"]
},
"contentPreparationTemplateId": "string",
"edgeResourcesConfigurationId": "string",
"canonicalDomainName": "string",
"domainNameAlias": "string",
"baseURL": "string",
"pathRewriteRules": [
{
"requestPathPattern": "string",
"mappedPath": "string"
}
],
"cachingConfigurations": [
{
"urlPatternFilter": "string",
"cachingDirectives": {
"statusCodeFilters": [0],
"noCache": true,
"maxAge": 0
}
}
],
"geoFencing": {
"locatorType": "string",
"locators": ["string"]
},
"urlSignature": {
"urlPattern": "string",
"tokenName": "string",
"passphraseName": "string",
"passphrase": "string",
"tokenExpiryName": "string",
"useIPAddress": true,
"ipAddressName": "string"
},
"certificateId": "string",
"supplementaryDistributionNetworks": [
{
"distributionNetworkType": "NETWORK_EMBMS",
"distributionMode": "MODE_EXCLUSIVE"
}
]
}
]
}
Key fields:
name: A human-readable label for this configuration.ingestConfiguration: How the AS obtains the source content, including the ingestprotocoland the sourcebaseURL.distributionConfigurations: How the content is exposed to clients, including theentryPoint(relative path, content type and profiles), caching rules, geo-fencing and URL signing.
Note that some fields are accepted by the API but are not yet implemented by the Reference Tools (see the implementation status board above): Content Preparation, Edge Resources, Geo-fencing and URL signing.
Note that the supported protocols in 3GPP Release 17 are:
- HTTP pull-based content ingest protocol:
urn:3gpp:5gms:content-protocol:http-pull-ingest - DASH-IF push-based content ingest protocol:
urn:3gpp:5gms:content-protocol:dash-if-ingest
Examples are available in the examples-files directory of rt-5gms-examples
Network Assistance
The network assistance feature enables the 5GMS Client in the UE to interrogate or manipulate the network Quality of Service (QoS) for an ongoing media streaming session. It defines two mechanisms for obtaining network assistance: via interactions with the Policy Control Function (PCF) (AF-based network assistance), or via Access Network Bitrate Recommendation (ANBR) signalling interactions between the UE modem and the Radio Access Network (RAN) (ANBR-based network assistance).
Of the two Network Assistance capabilities described below, the implementation status board above indicates that only Delivery Boost is currently implemented; Throughput Estimation (Bit Rate Recommendation) is still in development. The descriptions below cover both as defined by the specification.
Both mechanisms make it possible to obtain:
-
Bit Rate Recommendation (Throughput Estimation), which allows the 5GMS Client to stay synchronized with the network's current capabilities.
- The client asks the 5GMS System for a bit rate estimate. The system then queries the Policy Control Function (PCF) to determine the available throughput for that specific session.
- The client uses this data to proactively adjust its streaming speed, for example by switching media quality levels (downlink).
- It prevents stuttering and lag, ensuring a stable and consistent Quality of Experience (QoE) by staying within the network's "QoS envelope."
-
Delivery Boost, which is a reactive feature used to request extra network performance when needed.
- The client requests a temporary increase in bit rate. The 5GMS System asks the PCF to modify the session parameters to grant this extra capacity.
- If the network has spare capacity, the boost is granted. The client uses this "boost" of speed to quickly refill a depleted buffer or finish a large file transfer faster.
- It helps the user recover from potential playback interruptions or speeds up time-sensitive data tasks.
The following are the reference points and APIs.
The network assistance feature is not explicitly provisioned by the 5GMS Application Provider. It is either available for a particular media streaming session or not, depending on system pre-configuration and/or policy.
Dynamic Policies
The dynamic policies feature enables the 5GMS Client in the UE to manipulate the network traffic handling policies for an ongoing media streaming session.
The following are the reference points and APIs.
-
At M1:
-
At M5:
When the dynamic policy feature is offered and selected, the 5GMSd Application Provider specifies a set of policies which can be invoked for the unicast downlink streaming session. The UE becomes aware of the selected policies in the form of a list of valid Policy Template Ids.
Examples are available in the examples-files directory of rt-5gms-examples
This is a JSON scheme of a Policy Template, which describes the QoS and charging treatment a session may request:
{
"externalReference": "string",
"qoSSpecification": {
"qosReference": "string",
"maxBtrUl": "string",
"maxBtrDl": "string",
"maxAuthBtrUl": "string",
"maxAuthBtrDl": "string",
"defPacketLossRateDl": 0,
"defPacketLossRateUl": 0
},
"applicationSessionContext": {
"sliceInfo": {
"sst": 255,
"sd": "string"
},
"dnn": "string"
},
"chargingSpecification": {
"sponId": "string",
"sponStatus": "SPONSOR_DISABLED",
"gpsi": ["string"]
}
}
Key fields:
externalReference: An identifier for the policy used outside the 5GMS System.qoSSpecification: The requested QoS, including the QoS reference and the maximum uplink and downlink bit rates.applicationSessionContext: The network slice (sliceInfo) and Data Network Name (dnn) the policy applies to.chargingSpecification: Sponsored-data and charging settings for the session.
Consumption Reporting
The consumption reporting feature allows consumption of downlink media streaming to be logged by the 5GMS System and exposed for analysis.
The following are the reference points and APIs.
-
At M1:
-
At M5:
Once a Provisioning Session is established using the API at interface M1d, Consumption Reporting can be configured.
This is a JSON scheme of a Consumption Reporting Configuration:
{
"reportingInterval": 1,
"samplePercentage": 100,
"locationReporting": true,
"accessReporting": true
}
Where:
reportingInterval: The interval between two consecutive consumption reports. The value shall be greater than zero.samplePercentage: The proportion of media streaming clients that shall report media consumption, expressed as a floating point value between 0.0 and 100.0.locationReporting: Stipulates whether the Media Session Handler is required to provide location data to the 5GMSd AF in consumption reporting messages.accessReporting: Stipulates whether the Media Session Handler is required to provide consumption reporting messages to the 5GMSd AF when the access network changes during a media streaming session.
Examples are available in the examples-files directory of rt-5gms-examples
QoE Metrics Reporting
The QoE metrics reporting feature enables the 5GMS System to log and expose streaming performance data for further analysis.
The framework defines two distinct reporting paths:
-
RAN-based Reporting: Metrics are sent to the Operations, Administration, and Maintenance (OAM) system via the Radio Access Network.
-
AF-based Reporting: Metrics are sent directly to the network-side components (AF) of the 5GMS System.
The following are the reference points and APIs.
-
At M1:
-
At M5:
Once a Provisioning Session is established using the API at interface M1d, QoE Metrics Reporting can be configured.
This is a JSON scheme of a Metrics Reporting Configuration:
{
"metricsReportingConfigurationId": "string",
"sliceScope": [
{
"sst": 255,
"sd": "string"
}
],
"scheme": "string",
"dataNetworkName": "string",
"reportingInterval": 0,
"samplePercentage": 100,
"urlFilters": ["string"],
"samplingPeriod": 0,
"metrics": ["string"]
}
Where the field metrics for downlink media streaming and for the 3GPP scheme urn:3GPP:ns:PSS:DASH:QM10 corresponds, for example, to one or more of the following quality metrics for DASH. Metrics currently supported by the Reference Tools are shown in green and marked "(supported)" in the list below:
- HTTP request/response urn:3GPP:ns:PSS:DASH:QM10#HTTPList (supported)
- List of Representation Switch Events: urn:3GPP:ns:PSS:DASH:QM10#RepSwitchList (supported)
- Average Throughput: urn:3GPP:ns:PSS:DASH:QM10#AvgThroughput
- Initial Playout Delay: urn:3GPP:ns:PSS:DASH:QM10#InitialPlayoutDelay
- Buffer Level: urn:3GPP:ns:PSS:DASH:QM10#BufferLevel (supported)
- Play List: urn:3GPP:ns:PSS:DASH:QM10#PlayList
- MPD Information: urn:3GPP:ns:PSS:DASH:QM10#MPDInformation (supported)
- Playout Delay for Media Start-up: urn:3GPP:ns:PSS:DASH:QM10#PlayoutDelayforMediaStartup
- Device information: urn:3GPP:ns:PSS:DASH:QM10#DeviceInformationList
Examples are available in the examples-files directory of rt-5gms-examples
Data Collection, Reporting and Exposure
This feature is not yet implemented within the framework of 5GMS. A generic architecture for UE Data Collection and Reporting is available separately (see the note at the end of this section).
The data collection, reporting and exposure feature enables the 5GMS System to log data relating to media streaming sessions and to expose this to subscribers in the form of Events.
The following are the reference points and APIs.
At the moment, a generic architecture for UE Data Collection and Reporting is available in the Reference Tools under the following project: UE Data Collection, Reporting and Event Exposure. Note these entities are not yet implemented within the framework of 5GMS.
Related
- Repositories & Releases
- Implementation Blueprint: 5GMS session establishment — the step-by-step procedure this tool implements
- Applications: Media Streaming, Multicast & Real-Time Communications — real, assembled scenarios built on this tool
Refer to the rt-5gms-application-function and related 5G-MAG Reference Tools repositories to contribute to this project. See How to Contribute for the process.