- What it is: an analysis of DVB-I delivered over 5G, mapping commercial requirements to the specifications that address them.
- Why it matters: It shows where the specifications meet the requirements and which gaps remain.
- In this section: This page covers the proposition, the requirements and addressing specifications, and a re-check of the recorded gaps.
This page is in three parts. It begins with what DVB-I over 5G is for and the requirements that define it, then maps those requirements onto the specifications that address them, and only then looks at what is still missing. The gap list is the part most often quoted in isolation, and it reads very differently once the first two parts are in view.
Part 1: What DVB-I over 5G enables
The proposition
DVB-I is a delivery-agnostic service layer. A client discovers services from an XML service list, and each service can offer several service instances, each binding that same editorial service to a different bearer. Broadcast and broadband appear in one list, and the user sees channels rather than delivery mechanisms (ETSI TR 103 972 V1.1.1 clause 4.1.1; ETSI TS 103 770 V1.2.1 clause 5.5.1; ETSI TS 103 770 V1.2.1 clause 5.5.2; ETSI TS 103 770 V1.2.1 clause 5.5.4; ETSI TS 103 770 V1.2.1 clause 5.2.1; DVB C100 definition of terms (Service list)).
Putting 5G underneath that layer does three things that nothing else does at once:
It reaches devices broadcast cannot. Phones, tablets and vehicles have no DVB-T tuner. They do have 5G modems. Delivering a television service over 5G Broadcast reaches them without the per-user cost of unicast, and without the service provider losing the service-layer control that DVB-I gives them. Delivery to fixed receivers is not excluded: roof-top antennas, 5G fixed wireless access and 5G-based home gateways are all in scope (ETSI TR 103 972 V1.1.1 clause 4.1.1; DVB C100 clause 5.5).
It makes broadcast economics work at scale. A 5G Broadcast transmission carries one copy of a popular linear channel regardless of how many people are watching. Unicast cost grows with audience; broadcast cost does not. High-power high-tower, receive-only, free-to-air operation is supported by the LTE-based 5G Broadcast system, so this is classical TV distribution economics on a mobile bearer (ETSI TR 103 972 V1.1.1 clause 4.1.1; ETSI TS 103 720 V1.2.1 clause 4.1; ETSI TS 103 720 V1.2.1 clause 5.4.8).
It makes the hybrid service a first-class citizen. This is the part that is specific to DVB-I, and TR 103 972 calls it out as the particular benefit: a basic service distributed over broadcast, augmented by unicast for wider coverage, better quality, and experiences broadcast alone cannot provide. The service list is what holds the two halves together as one service rather than two (ETSI TR 103 972 V1.1.1 clause 4.1.1; DVB C100 clause 2.2.4).
What a hybrid service actually buys you
The hybrid case is not a single feature, it is a set of them, and the commercial requirements enumerate them individually: (DVB C100 clause 2.2.4; DVB C100 clause 2.5.4; DVB C100 clause 2.6.14)
| Capability | What it means in practice |
|---|---|
| Service continuity (DVB C100 clause 5.7; ETSI TR 103 972 V1.1.1 clause 6.4.4.3.2) | Reception continues on unicast when the user leaves broadcast coverage |
| Extended coverage (DVB C100 clause 5.7; ETSI TR 103 972 V1.1.1 clause 4.1.1) | Broadcast serves the coverage area, unicast fills the rest, one service either way |
| Component addition (DVB C100 clause 2.5.4) | Subtitles or metadata delivered over unicast for a service carried over broadcast |
| Component replacement (DVB C100 clause 2.5.5) | An alternative language or camera angle over unicast |
| Component augmentation (DVB C100 clause 2.5.7) | An enhancement layer over unicast on top of a broadcast base layer |
| Targeted replacement (DVB C100 clause 2.5.6) | Unicast content or advertising insertion targeted by user or region |
| Time-shifted viewing (DVB C100 clause 2.5.8) | Unicast access to the same service for catch-up, with near-seamless transition back to live |
| Fast start (DVB C100 clause 2.5.9) | Unicast for channel-change latency while broadcast carries the steady state |
| Error recovery (DVB C100 clause 2.6.14) | Unicast repair when broadcast reception is lossy |
Seven of these (all but service continuity and extended coverage) are separate requirements in DVB BlueBook C100 (clauses 2.5.4 to 2.5.9 and 2.6.14); service continuity and extended coverage come from the hybrid use case in clause 5.7. Each is a reason a broadcaster would want the service layer to span both bearers rather than running two products.
The six guiding use cases
The requirements were derived from six use cases contributed by DVB members and recorded in TR 103 972 clause 4.1.2: (DVB C100 clause 1.5; ETSI TR 103 972 V1.1.1 clause 4.1.2)
- DVB-I over 5G Media Streaming (ETSI TR 103 972 V1.1.1 clause 4.1.2; DVB C100 clause 1.5)
- 5G Broadcast / unicast hybrid delivery to handheld devices (ETSI TR 103 972 V1.1.1 clause 4.1.2; DVB C100 clause 1.5)
- 5G Broadcast standalone with unicast for the EPG (ETSI TR 103 972 V1.1.1 clause 4.1.2; DVB C100 clause 1.5)
- 5G Fixed Wireless Access (ETSI TR 103 972 V1.1.1 clause 4.1.2; DVB C100 clause 1.5)
- DVB-I services to vehicle infotainment systems over 5G (ETSI TR 103 972 V1.1.1 clause 4.1.2; DVB C100 clause 1.5)
- DVB-I hybrid service over 5G (ETSI TR 103 972 V1.1.1 clause 4.1.2; DVB C100 clause 1.5)
TR 103 972 clause 4.1.2 titles use case 3 "5G Broadcast standalone with Unicast for EPG". Its full description is in DVB BlueBook C100 clause 5.4.
Part 2: The requirements, and the specifications that address them
Where the requirements come from
The DVB Project approved DVB BlueBook C100, the commercial requirements for DVB-I service support over 5G networks and systems, in July 2021. It carries 70 technical and procedural requirements, derived from the six use cases above (ETSI TR 103 972 V1.1.1 clause 4.1.1; DVB C100 clause 1.5).
TR 103 972 clause 4.1.3 summarises the four things the Technical Module was asked to specify:
- Self-contained DVB-I services over a 5G Broadcast system (ETSI TS 103 720)
- Self-contained DVB-I services over a 5G Media Streaming system (ETSI TS 126 501)
- The same basic service over regular unicast, 5G Broadcast and 5GMS at the same time, as independent service instances, possibly at different quality (ETSI TR 103 972 V1.1.1 clause 4.1.3; DVB C100 clause 2.2.3; DVB C100 clause 2.2.4)
- Hybrid DVB-I services: described in a service list, distributed over 5G Broadcast, augmented by unicast or 5GMS (ETSI TR 103 972 V1.1.1 clause 4.1.3; DVB C100 clause 2.2.3; DVB C100 clause 2.2.4)
The detailed requirements are clustered by service-operation phase, in C100's own clause numbering: provisioning (2.3), announcement and detection (2.4), service components (2.5), distribution and delivery (2.6), quality and monitoring (2.7), and client functionality (2.8) (DVB C100 clause 2.3; DVB C100 clause 2.4; DVB C100 clause 2.5; DVB C100 clause 2.6; DVB C100 clause 2.7; DVB C100 clause 2.8).
Two procedural constraints shape every technical answer below. Existing DVB technology is to be reused wherever appropriate, and the solution is to stay layered: functionality predominantly access-independent and common with other DVB delivery means, enhanced only where the 5G delivery network genuinely requires it. That is why the answers are mostly small additions rather than a new system (DVB C100 clause 2.2.5; DVB C100 clause 2.2.6; ETSI TR 103 972 V1.1.1 clause 4.1.4; ETSI TR 103 972 V1.1.1 clause 4.1.1).
The layered answer
| Layer | What it provides | Specifications |
|---|---|---|
| Service layer | Discovery, selection, programme metadata. Unchanged across bearers. | DVB A177 / ETSI TS 103 770 |
| Media format layer | The media presentation itself | DVB-DASH (ETSI TS 103 285); DVB-MABR (ETSI TS 103 769) where multicast is used |
| Transport layer | The bearer | ETSI TS 103 720 (LTE-based 5G Broadcast); 3GPP 5GMS (TS 26.501, TS 26.512, TS 26.510) for unicast |
| Provisioning | Getting content onto a broadcast bearer | xMB (ETSI TS 129 116); MBMS protocols (3GPP TS 26.346) |
Requirements for the 5G Broadcast scenario
TR 103 972 table 6.2.1-1 lists the requirements this scenario has to satisfy. Status below is against the specifications as published today, not as they stood when the report was written.
| Requirement (C100) | What it asks for | Addressed by | Status |
|---|---|---|---|
| 2.2.1, 2.6.2 | Self-contained DVB-I services delivered and distributed over a 5G Broadcast system | ETSI TS 103 720 for the bearer; TS 103 770 clause 9.3 for carriage in an MBMS system | Addressed, except for the instance type below |
| 2.3.1 | Provisioning of those services | ETSI TS 129 116 clause 5.2.1.1, table 5.2.1.1-1: a service resource with a service-class property | Addressed |
| 2.4.4 | Embed the DVB-I service list in a 5G Broadcast signal | TS 103 770 clause 9.3.1, table 106: a user service of class DVB-I_Service_List:1 carries the list document | Addressed |
| 2.4.5 | Provide an updated service list in a 5G Broadcast signal | TS 103 770 clause 9.3.3: the client subscribes to MBMS Client notifications and acquires new versions as announced | Addressed |
| 2.4.17 | Announce the location of content guide endpoints | TS 103 770 clause 9.3.1, table 106: class DVB-I_Content_Guide:1 | Addressed, by carrying the documents themselves |
| 2.6.7 | Receive-only-mode reception from a 5G Broadcast system | ETSI TS 103 720 clause 5.4.8 makes receive-only mode mandatory for LTE-based 5G Broadcast services | Addressed at the bearer |
| 2.6.6 | Free-to-air delivery over a 5G Broadcast system | Follows from the same clause: ROM needs neither PLMN registration nor a USIM. Announcement to such receivers is 3GPP TS 26.346 clause 5.2.3.1.1 | Addressed at the bearer |
| 2.4.2 | An entry point referencing a service list registry | TS 103 770 clause 5.1.3.1 defines three discovery approaches (built-in URL, registry, CICAM); none is 5G-specific; the A177r8 draft keeps the same three principal approaches in clause 5.1.3.1 and adds mDNS/DNS-SD announcement in clause 5.1.3.9, also not 5G-specific | Partly: the registry exists, the 5G entry point does not |
| 2.4.3 (DVB C100 clause 2.4.3; ETSI TS 103 770 V1.2.1 clause 9.3.1; ETSI TS 103 770 V1.2.1 clause 9.3.3) | Announce the location of one or more service lists in the broadcast signal | Clause 9.3 carries the list itself rather than a pointer to it | Partly, by a different means |
| 2.4.7 | The service list shall define a service instance type for 5G Broadcast | No service instance type. The mbms:// locator itself fits IdentifierBasedDeliveryParameters (TS 103 770 clause 5.5.4, table 16), on 5G-MAG's reading | Open: the locator has an element, the type does not |
| 2.4.10 | Identify an editorial service from radio-layer parameters (frequency plus TMGI) | Nothing. TS 103 770 does not mention TMGI | Open |
| 2.4.15, 2.4.16 | Signal free-to-air and receive-only-mode service instances | Nothing on the service-list side. TS 103 770 has FTAContentManagement (clause 5.5.19), which carries content management policy, not free-to-air reception | Open, downstream of 2.4.7 |
The last four share one cause. Requirements 2.4.10, 2.4.15 and 2.4.16 all describe attributes of a 5G Broadcast service instance, and there is no 5G Broadcast service instance type to put them on. Close 2.4.7 and they become straightforward (ETSI TS 103 770 V1.2.1 clause 5.5.4).
Requirements for the 5G Media Streaming scenario
TR 103 972 table 6.3.1-1:
| Requirement (C100) | What it asks for | Addressed by | Status |
|---|---|---|---|
| 2.2.2, 2.6.1 | Self-contained DVB-I services over a 5GMS system | ETSI TS 126 501 (architecture), TS 126 512 (protocols), TS 126 510 (client APIs) | Addressed at the 3GPP layer |
| 2.3.1 | Provisioning over 5GMS | TS 126 510 clause 5.2, Provisioning (M1) interactions | Addressed |
| 2.4.1 | Announcement of DVB-I services via 5GMS | Ordinary HTTPS discovery: TS 103 770 clause 5.1.3 | Addressed |
| 2.6.3 | Make use of Content Hosting, Dynamic QoS Policies and Network Assistance | TS 126 510 clauses 5.2.7, 5.2.8 and 5.3.4; TS 126 512 clauses 4.3.3, 4.3.7 and 4.5.10 | Addressed at the 3GPP layer |
| 2.4.8 (DVB C100 clause 2.4.8; ETSI TS 103 770 V1.2.1 clause 5.5.4) | The service list shall define a service instance type for 5GMS | Nothing | Open |
The same shape as the broadcast scenario. The transport is specified in detail; what is missing is the one line in the service list that says a given instance uses it, so a DVB-I client can select it knowingly (ETSI TR 103 972 V1.1.1 clause 6.3.4).
Requirements for the hybrid scenario
TR 103 972 table 6.4.1-1 carries fourteen requirements: the two headline ones (2.2.3, 2.2.4), three on disambiguating and selecting between instances (2.4.9, 2.4.10, 2.4.12), six on component-level unicast behaviour (2.5.4 to 2.5.9), and the remainder on time alignment, error recovery and metrics (2.6.5, 2.6.14, 2.7.10) (ETSI TR 103 972 V1.1.1 clause 6.4.1).
The multi-instance mechanism these depend on already exists. TS 103 770 clause 5.5.4 (ServiceInstanceType) gives each instance a @priority attribute, lower value meaning higher priority, and TS 103 770 clause 5.2.1 (Service Instance Matching) has a hybrid client match instances of the same service using "the metadata it gathers during DVB-T/C/S installation, together with metadata present in Service Lists". The component-level behaviours are DVB-DASH and DVB-I mechanics that are not specific to 5G (ETSI TS 103 770 V1.2.1 clause 5.5.4; ETSI TS 103 770 V1.2.1 clause 5.2.1).
Without instance types for 5G Broadcast and 5GMS, nothing in the list says which instance uses which 5G system. TR 103 972 records further DVB-I signalling for the hybrid case as well: clause 6.4.4.4 says "New signalling is required in the DVB-I Service List to indicate that the content distributed on these two service instances is both identical and time-aligned", and clause 6.4.3.3 notes that service instances do not indicate their availability at specific locations. This page does not assess the fourteen hybrid requirements individually. TR 103 972 clause 6.4.4.3 covers service continuity, time-shifted viewing and content or component replacement, for option 1 only (ETSI TR 103 972 V1.1.1 clause 6.4.3.3; ETSI TS 103 770 V1.2.1 clause 5.5.4; ETSI TR 103 972 V1.1.1 clause 6.4.4.4; ETSI TR 103 972 V1.1.1 clause 6.4.4.1; ETSI TR 103 972 V1.1.1 clause 6.4.4.3.1).
How carriage over 5G Broadcast already works
Requirements 2.4.4, 2.4.5 and 2.4.17 above are marked addressed because TS 103 770 V1.2.1 clause 9.3 covers carriage of DVB-I in an MBMS system normatively. This is routinely missed, and it is why the broadcast path is closer to buildable than the gap list suggests (ETSI TS 103 770 V1.2.1 clause 9.3.1; ETSI TS 103 770 V1.2.1 clause 9.3.3).
The unit of carriage is an MBMS User Service, and its class says what it carries. A DVB-I deployment over MBMS is not one bearer but a set of user services, each announced separately and each labelled (ETSI TS 103 770 V1.2.1 clause 9.3.1; ETSI TS 103 770 V1.2.1 clause 9.3.3). TS 103 770 clause 9.3.1, table 106 defines three classes:
| Service class identifier | The user service carries |
|---|---|
urn:dvb:metadata:serviceClass:DVB-I_Service_List:1 (ETSI TS 103 770 V1.2.1 clause 9.3.1) | one service list document |
urn:dvb:metadata:serviceClass:DVB-I_Content_Guide:1 (ETSI TS 103 770 V1.2.1 clause 9.3.1) | content guide documents |
urn:dvb:metadata:serviceClass:DVB-I_Service_Instance:1 (ETSI TS 103 770 V1.2.1 clause 9.3.1) | the media assets of one service instance |
That attribute is the whole filtering mechanism: it is how a receiver tells a DVB-I service list from any other file being broadcast. Its absence was TR 103 972 clause 6.2.4 gap 4, now closed (ETSI TS 103 770 V1.2.1 clause 9.3.2).
Provisioning path:
| Step | Where it is specified |
|---|---|
| Content provider creates a service over xMB and sets its class | ETSI TS 129 116 V19.0.0 clause 5.2.1.1, table 5.2.1.1-1, row service-class |
BM-SC carries it in the User Service Description as userServiceDescription@serviceClass | 3GPP TS 26.346 V19.3.0 clause 11.2.1.2 |
| For media, the User Service Description also references the entry point document (the MPD) | 3GPP TS 26.346 V19.3.0 clause 5.2.2.1 |
| User services are announced | 3GPP TS 26.346 V19.3.0 clause 5.2.3.1 |
| For LTE-based 5G Broadcast, announcement uses 5G Broadcast SA Services | ETSI TS 103 720 V1.2.1 clause 5.4.2 |
Receiver behaviour. TS 103 770 clause 9.3.3 puts the DVB-I client in the role of an MBMS-Aware Application driving an MBMS Client, in four steps: (ETSI TS 103 770 V1.2.1 clause 9.3.3)
- Start the announcement channel. The client invokes the MBMS Client to start receiving the MBMS Service Announcement Channel (3GPP TS 26.346 clause 5.2.3). The result is a User Service Description for every user service in the system (ETSI TS 103 770 V1.2.1 clause 9.3.3).
- Read the class off each one. The MBMS Client exposes the service class identifier to the DVB-I client (TS 103 770 clause 9.3.2, referring to ETSI TS 126 347 clause 6.2) (ETSI TS 103 770 V1.2.1 clause 9.3.2).
- Acquire the metadata and keep it current. A client with no unicast connection acquires the service list from a user service of class
DVB-I_Service_List:1, and may then acquire content guide metadata the same way. It subscribes to MBMS Client notifications and picks up new versions as announced. A unicast client instead checks for updates under TS 103 770 clause 5.1.7, with the HTTP caching rules of clause 4.3.2 (ETSI TS 103 770 V1.2.1 clause 9.3.3; ETSI TS 103 770 V1.2.1 clause 5.1.7; ETSI TS 103 770 V1.2.1 clause 4.3.2). - Select an instance and hand off to the player. On selecting an instance with an
mbms://locator, the client invokes the MBMS Client to initiate reception, and passes the player the entry point document referenced by the User Service Description (ETSI TS 103 770 V1.2.1 clause 9.3.3).
This split matches the component architecture the 5G-MAG reference tools already have: an MBMS Client holding the announcement channel and the reception, and an MBMS-aware application driving it over a local API. A DVB-I receiver occupies the second role (ETSI TS 103 770 V1.2.1 clause 9.3.3).
Part 3: The gap analysis
Why the published gap list needs re-checking
ETSI TR 103 972 is the deployment guidance for all of the above, produced by the DVB / 5G-MAG Joint Task Force. Being a technical report, its output is guidance and recommended changes rather than normative requirements, and its most-quoted content is clauses 6.2.4 and 6.3.4, which enumerate what was missing from the standards (ETSI TR 103 972 V1.1.1 clause 6.1; ETSI TR 103 972 V1.1.1 clause 6.2.4; ETSI TR 103 972 V1.1.1 clause 6.3.4).
It is dated 2023-07. Every document it points at has moved since, several by two or three releases (ETSI TR 103 972 V1.1.1 clause 2.2). Three things follow, and all three turn out to matter:
- A gap may have closed in a later issue of the owning document.
- A gap's clause reference may no longer resolve, because the owning document was restructured or the material moved to a different specification entirely.
- A gap may have been closed before the report was published, where the report cites a document without a version (ETSI TR 103 972 V1.1.1 clause 2.2).
Each of the fourteen gaps below was therefore re-checked against the newest published issue of the document that owns it. This is an engineering assessment by 5G-MAG, not a statement of the DVB or 3GPP position on any item.
Versions checked: ETSI TS 103 770 V1.2.1 (2024-09), ETSI TR 103 972 V1.1.1 (2023-07), ETSI TS 103 720 V1.2.1 (2023-06), ETSI TS 129 116 V19.0.0 (2025-10), ETSI TS 126 512 V19.3.0, ETSI TS 126 510 V19.2.0, 3GPP TS 26.346 V19.3.0 (2025-12), 3GPP TS 26.347 V19.0.0, and, for the DVB side, the DVB A177r8 draft of TS 103 770 V1.3.1 (30 June 2026). The draft is a DVB document; this page has not verified that ETSI has published it. The latest published ETSI version remains V1.2.1.
Headline
| Status | Count |
|---|---|
| Closed | 7 |
| Addressed by restructuring, though not as proposed | 1 |
| Met by an existing element, on 5G-MAG's reading | 1 |
| Not a gap; the report says so itself | 1 |
| Open | 4 |
One gap was closed a month before the report was published. Five more closed afterwards, three of them in a 3GPP document that did not exist in its current form when the report was written (ETSI TS 103 720 V1.2.1 clause 7.4; ETSI TR 103 972 V1.1.1 clause 6.2.4).
The asymmetry matters more than the count. The 3GPP-derived documents account for six of the seven closures. The DVB side has been reissued once in the same period, closing the seventh, and added no 5G-specific signalling to the service list itself. The A177r8 draft adds none either: its clause 9.3 (carriage in an MBMS system, table 106) matches V1.2.1 in substance, and it names no service instance type for 5G Broadcast or 5GMS (ETSI TS 103 770 V1.2.1 clause 9.3.1; DVB A177r8 draft clause 9.3.1).
5G Broadcast scenario (TR 103 972 clause 6.2.4)
| # | Gap | Owner | Status |
|---|---|---|---|
| 1 | How Keep updated interval and Periodic update interval should be configured is unclear | TS 129 116 | Open, unchanged through Release 19 |
| 2 | A 5G Broadcast Receiver is not required to support simultaneous reception of more than one user service | TS 103 720 | Closed, one month before the report appeared |
| 3 | Possible gap in the stage 3 xMB-C API for notifying the BM-SC of updates | TS 129 116 | Open |
| 4 (ETSI TR 103 972 V1.1.1 clause 6.2.4; ETSI TS 103 770 V1.2.1 clause 9.3.1) | A service class filter for DVB-I services needs defining by DVB | DVB | Closed |
| 5 | A service instance cannot refer to a 5G Broadcast or MBMS URL | TS 103 770, TS 126 347 or TS 103 720 | Met by an existing element, on 5G-MAG's reading |
Gap 2 was closed by TS 103 720 V1.2.1 clause 7.4, dated 2023-06, one month before the report. The report's reference to TS 103 720 carries no version, which is how that happens.
Gap 4 was closed by TS 103 770 V1.2.1 clause 9.3.1, table 106, the service classes described in Part 2. That is exactly the filter the report asked for, and it arrived in the issue published a year later (ETSI TS 103 770 V1.2.1 clause 9.3.1).
Gaps 1 and 3 are open. TS 129 116 V19.0.0 still defines both update-interval properties semantically with no guidance on choosing values or on how the two interact. On gap 3, the notification machinery in that API runs the other way: TS 129 116 clause 8 specifies push from the BM-SC to the Content Provider, so a Content Provider signalling a change still relies on polling (ETSI TS 129 116 V19.0.0 clause 5.2.2.1; ETSI TS 129 116 V19.0.0 clause 8.2).
Gap 5: TR 103 972 clause 6.2.4 asks for "an extension" "such that a service instance can refer to a 5G Broadcast/MBMS URL and include a new set of service delivery parameters specifically for 5G Broadcast", which "may either be defined in ETSI TS 103 770 [i.21] or in an MBMS (e.g. ETSI TS 126 347 [i.4]) or 5G Broadcast (ETSI TS 103 720 [i.8]) specification." TS 103 770 V1.2.1 already has an element that can hold the URL: IdentifierBasedDeliveryParameters, which clause 5.5.4, table 16, defines as "An identifier in the form of a locator (URL) or name (URN) that contains the parameters of the relevant delivery system for this service instance." No clause names it for MBMS, so this is 5G-MAG's reading. The "new set of service delivery parameters" has no element, and requirement 2.4.7, a service instance type for 5G Broadcast, stays open. The A177r8 draft changes neither (ETSI TR 103 972 V1.1.1 clause 6.2.4; ETSI TS 103 770 V1.2.1 clause 5.5.4; ETSI TS 103 770 V1.2.1 clause 5.5.18; DVB C100 clause 2.4.7).
5G Media Streaming scenario (TR 103 972 clause 6.3.4)
| # | Gap | Owner | Status |
|---|---|---|---|
| 1 | Service instance metadata needs 5GMS Service Access Information | TS 103 770, or TS 126 501 and TS 126 512 | Open |
| 2 | Playlist entry needs the same | TS 103 770, or TS 126 501 and TS 126 512 | Open |
| 3 | No means to bind the Media Player Entry URL to Service Access Information | TS 126 512 | Addressed, differently |
| 4 | No mechanism for implicitly launching the Media Session Handler | TS 126 512 | Not a gap, the report says so itself |
| 5 | No notification that QoE metrics reporting was activated | TS 126 512 | Closed, relocated |
| 6 | Playback state not explicitly exposed in M7 status | TS 126 512 | Closed |
| 7 | No notification that a metrics report was submitted | TS 126 512 | Closed, relocated |
| 8 | OPERATION_POINT_CHANGED carries no payload; no operation point in status; no external reference | TS 126 512 | Closed |
| 9 | No client API to request network assistance | TS 126 512 | Closed, relocated |
The client APIs moved, and the report's clause numbers no longer locate anything. In TS 126 512 V19.3.0 the clauses cited for gaps 5, 7 and 9 (12.2.5, 12.2.6, 12.2.7) are all marked Void. That material now lives in TS 126 510, which TS 126 512 references throughout. Anyone still checking those gaps against the numbers in the report will conclude they are open (TS 26.512 V19.3.0 clause 12.2.5; TS 26.512 V19.3.0 clause 12.2.6; TS 26.512 V19.3.0 clause 12.2.7; ETSI TR 103 972 V1.1.1 clause 6.3.4).
- Gaps 5 and 7 are closed by TS 126 510 V19.2.0 clause 11.6.2: table 11.6.2-2 lists
METRICS_REPORTING_ACTIVATEDandNEW_METRICS_REPORTamong the notification events, and table 11.6.2-1 addslastMetricsReportstatus information (TS 26.510 V19.2.0 clause 11.6.2). - Gap 9 is closed by TS 126 510 clause 11.4, a Network Assistance client API where the report found an empty clause (ETSI TR 103 972 V1.1.1 clause 6.3.4; TS 26.510 V19.2.0 clause 11.4).
- Gap 6 is closed: TS 126 512 V19.3.0 table 13.2.6-1 carries a
staterow holding an enumerated Media Player state, rather than leaving it to be inferred from a non-zero playback rate (TS 26.512 V19.3.0 clause 13.2.6; ETSI TR 103 972 V1.1.1 clause 6.3.4). - Gap 8 is closed in both halves: the notification now declares a payload carrying the media delivery session identifier and the external reference identifier of the selected Service Operation Point, and the dynamic status exposes
serviceOperationPoints(TS 26.512 V19.3.0 clause 13.2.5; TS 26.512 V19.3.0 clause 13.2.6). - Gap 3 is addressed, but not as proposed. Rather than the additional M7 method the report suggested,
attachMPD()in TS 126 512 V19.3.0 clause 13.2.3.3 takes a media delivery session identifier alongside the MPD URL, binding the presentation to an already-initialised session. Whether that satisfies the intent is a judgement call and should be confirmed with 3GPP (ETSI TR 103 972 V1.1.1 clause 6.3.4; TS 26.512 V19.3.0 clause 13.2.3.3).
What remains
The four open gaps fall into two groups.
Two are about 5GMS Service Access Information (TR 103 972 clause 6.3.4 gaps 1 and 2): a DVB-I service list has nowhere to put it, on a service instance or on a playlist entry. The TR names two places it could be specified: "In addition, or alternatively, the extension could be specified in ETSI TS 126 501 [i.6] and ETSI TS 126 512 [i.7]." These sit beside commercial requirement 2.4.8, a service instance type for 5GMS. Requirement 2.4.7, the type for 5G Broadcast, stays open as well, with 2.4.10, 2.4.15 and 2.4.16, which describe attributes such an instance would carry (ETSI TR 103 972 V1.1.1 clause 6.3.4; ETSI TS 103 770 V1.2.1 clause 5.5.18.6; DVB C100 clause 2.4.8; DVB C100 clause 2.4.7; DVB C100 clause 2.4.10; DVB C100 clause 2.4.15; DVB C100 clause 2.4.16).
Two are xMB provisioning details (TR 103 972 clause 6.2.4 gaps 1 and 3). Neither blocks a demonstration. Both would matter to an operator running the provisioning chain in earnest.
Where the mbms:// locator goes
Step 4 of the receiver procedure in Part 2 begins "a DVB-I service instance with an mbms:// locator", and TS 103 770 does not name the element that carries it. None of the eight delivery parameter types (clauses 5.5.18.1 to 5.5.18.8) is MBMS (ETSI TS 103 770 V1.2.1 clause 9.3.3; ETSI TS 103 770 V1.2.1 clause 5.5.18). Two elements can hold it:
IdentifierBasedDeliveryParameters(clause 5.5.18.8), defined in clause 5.5.4, table 16, as "An identifier in the form of a locator (URL) or name (URN) that contains the parameters of the relevant delivery system for this service instance." Annex G.2.3 uses it for HLS. This needs no extension, and it is what the 5G-MAG reference tools use (ETSI TS 103 770 V1.2.1 clause 5.5.18.8; ETSI TS 103 770 V1.2.1 clause 5.5.4; ETSI TS 103 770 V1.2.1 clause G.2.3).OtherDeliveryParameters, typedExtensionBaseType, the extension point annex G.2.2 uses for HLS. A deployment that uses it defines its own type, outside the specification (ETSI TS 103 770 V1.2.1 clause 5.5.4; ETSI TS 103 770 V1.2.1 clause G.2.2).
Neither is named for MBMS, so either is a reading. TR 103 972 clause 6.4.3.3 is worth reading before choosing. It sets out two options and discourages the first, signalling a 5G Broadcast service as DASH delivery with an added MBMS URL, because existing DVB-I clients may assume all DASH services are unicast. Both elements above avoid that (ETSI TR 103 972 V1.1.1 clause 6.4.3.3). The URL itself follows 3GPP TS 26.347 V19.0.0 clause 8.2.2, which says its prefix "is the serviceId of the service on which the resource is available."
What would be built first
The smallest useful step is not teaching a receiver to drive an MBMS Client, which is the
substantial piece of work. It is publishing the service list itself as a user service of class
DVB-I_Service_List:1 and having the receiver load it from the MBMS Client's local copy.
That exercises provisioning, the class label, the announcement channel and object delivery, it satisfies requirements 2.4.4 and 2.4.5, and it needs no 5G service instance at all, because a service list carried this way still describes ordinary unicast service instances. The procedure is that of TS 103 770 clause 9.3.3 (ETSI TS 103 770 V1.2.1 clause 9.3.3).
The 5G Media Streaming path is blocked on the two Service Access Information gaps above and is not a candidate for early work.
Every status above was checked against the document that owns the requirement or gap, at the version listed under "Versions checked", not against a summary or an earlier issue. Where a clause number in the report no longer resolves, the current location is given.
Three points are worth stating. DVB BlueBook C100 numbers the requirements; the page quotes them as TR 103 972 reproduces them in its tables 6.2.1-1, 6.3.1-1 and 6.4.1-1, and the numbering was checked against C100 clause 2 (DVB C100 clause 2). The form of the mbms:// URL was checked in 3GPP TS 26.347 V19.0.0 clause 8.2.2; TS 103 770 clause 9.3.2 refers to its clause 6.2, which is the File Delivery Application Service API. And nothing here establishes whether DVB intends to close the remaining gaps in a future issue: the A177r8 draft does not (its clauses 5.5.4, 5.5.18 and 9.3 define no 5G instance type, and its text does not mention TMGI), but a draft is not a plan of record, and the question belongs to DVB (ETSI TS 103 770 V1.2.1 clause 9.3.2; TS 26.347 V19.0.0 clause 6.2).
How it works
DVB-I service discovery is delivery-agnostic; 5G enters at one specific point, where a service instance's delivery parameters point at a 5G Media Streaming or 5G Broadcast transport.
DVB-I service discovery
DVB-I service discovery is specified by DVB A177, published in identical technical form by ETSI as TS 103 770 (Digital Video Broadcasting (DVB); Service Discovery and Programme Metadata for DVB-I). It is an XML-based, delivery-agnostic layer: the client discovers services and their metadata, and the delivery of the actual media is handled by whatever bearer each service references.
- Service List: the XML document a provider publishes. It contains one or more
Serviceentries, each with a stable identifier, presentation metadata (names, logos), optional targeting, and one or more service instances (ETSI TS 103 770 V1.2.1 clause 5.5.1; ETSI TS 103 770 V1.2.1 clause 5.5.2). - Service Instance: a concrete way to obtain a given service. Each instance carries a delivery parameter set that binds the service to a specific bearer and format. Multiple instances on one service is the mechanism used to describe the same channel over unicast, multicast, and broadcast at the same time (ETSI TS 103 770 V1.2.1 clause 5.5.2; ETSI TS 103 770 V1.2.1 clause 5.5.4).
- Content Guide / Programme Metadata: schedule (now/next and longer) and on-demand programme information, expressed with the DVB schemas aligned to the TV-Anytime data model, retrievable per service (ETSI TS 103 770 V1.2.1 clause 6.5; ETSI TS 103 770 V1.2.1 clause 6.6; ETSI TS 103 770 V1.2.1 clause 6.10).
The delivery-parameter types inside a service instance are where the 5G work enters. TS 103 770 V1.2.1 has eight (clauses 5.5.18.1 to 5.5.18.8): DVB-T, DVB-S, DVB-C, RTSP, multicast transport stream, DASH, SAT>IP and identifier-based, plus the OtherDeliveryParameters extension point. None is named for 5G. Where a service has more than one instance, clause 5.2.13 sets the precedence: instances outside their scheduled service hours are not evaluated, and instances whose controlling application cannot be started, or that the client knows in advance it cannot play, are discarded; "Otherwise the signalled ServiceInstance@priority shall be respected". In @priority (clause 5.5.4), a lower value means higher priority, ties are implementation-dependent, and clients may let users override the default rules. A hybrid client that also receives DVB-T/C/S performs a distinct step, Service Instance Matching (clause 5.2.1), using "the metadata it gathers during DVB-T/C/S installation, together with metadata present in Service Lists", so the same service does not appear twice in the combined list.
A client needs a starting point: TS 103 770 defines a Service List Registry (SLR) query API so a client can find service lists (for example filtered by country or provider) rather than relying on a hard-coded URL. In a 5G deployment the registry and service-list endpoints are ordinary HTTPS resources and can themselves be delivered over the unicast path.
Implementation blueprint
This is the client-side bootstrap sequence from a cold start to content-guide data, checked against ETSI TS 103 770 V1.2.1 (2024-09). Most of it is delivery-network-agnostic: steps 1 to 3, 5 and 6 are plain DVB-I mechanics that work the same way over cable, satellite, terrestrial DTT or 5G. Step 4 is the one place "over 5G" enters: a service instance's delivery parameters can point at a DVB-DASH presentation carried over 5G Media Streaming (TS 26.501), or at an MBMS User Service carried over 5G Broadcast (ETSI TS 103 720) by its mbms:// URL (TS 103 770 clause 9.3.3). TR 103 972 describes how both are deployed; it is informative.
| Step | What happens | Clause |
|---|---|---|
| 1 (ETSI TS 103 770 V1.2.1 clause 5.1.3.1; ETSI TS 103 770 V1.2.1 clause 5.1.3.3; ETSI TS 103 770 V1.2.1 clause 5.1.3.8). Locate a Service List Registry, or a pre-configured Service List | The client obtains an SLR endpoint (or a built-in/provisioned Service List URL directly) via a pre-configured URL, announcement in a broadcast channel, a CICAM, or a broadcast carousel. | 5.1.3.1 (the options); 5.1.3.3 to 5.1.3.8 (each mechanism) |
| 2 (ETSI TS 103 770 V1.2.1 clause 5.1.3.2; ETSI TS 103 770 V1.2.1 clause 5.3.2). Query the Service List Registry | HTTP GET to the SLR endpoint, optionally with filter parameters (TargetCountry, regulatorListFlag, Delivery, Language, Genre, ProviderName, inlineImages, in that fixed order); the SLR returns an XML list of Service List Entry Points. | 5.1.3.2 (the query); 5.3.1–5.3.2 (the response schema) |
| 3 (ETSI TS 103 770 V1.2.1 clause 5.5.1). Fetch the chosen Service List | HTTP GET to the Service List Server named in the entry point; returns the Service List XML document. | 5.5.1 (ServiceList) |
| 4 (ETSI TS 103 770 V1.2.1 clause 5.2.13; ETSI TS 103 770 V1.2.1 clause 5.5.4). Select a delivery instance per service | Where a Service has more than one ServiceInstance (for example broadcast and DASH), the client first leaves out instances outside their scheduled hours and discards those it cannot play, then follows the @priority attribute (lower value wins); ties are implementation-dependent. | 5.2.13 (Service Instance Precedence); 5.5.4 (ServiceInstanceType) |
| 5 (ETSI TS 103 770 V1.2.1 clause 5.2.1). Hybrid clients only: match instances of the same service | If the client also receives DVB-T/C/S directly, it matches instances using the metadata gathered during DVB-T/C/S installation (DVB Triplet, Network ID) together with the Service List, so a service is not listed twice. | 5.2.1 (Service Instance Matching) |
| 6 (ETSI TS 103 770 V1.2.1 clause 6.5; ETSI TS 103 770 V1.2.1 clause 6.6). Request Content Guide data | HTTP GET to the Content Guide Server referenced in the Service List entry; timestamp-filtered or now/next-filtered schedule, or full programme information, on demand. | 6.5 (Schedule Information Requests); 6.6 (Programme Information Request) |
Verified against primary sources: checked directly against ETSI TS 103 770 V1.2.1 (2024-09), downloaded from the ETSI deliverable server, and cross-checked against the DVB A177r8 / draft ETSI TS 103 770 V1.3.1 text (dated June 2026). The draft differs on steps 1 and 2: it adds mDNS/DNS-SD discovery of service lists and registries on the local network (its clause 5.1.3.9), which is not in V1.2.1, and it moves the image_variant query parameter, already in V1.2.1, into a new clause on images (clause 5.2.8.2.1). It also adds ?querycapabilities for customised queries (clause 4.3.4) and a version in the service list URL, the registry offering and the service list itself (clause 4.6.1). Instance selection follows clause 5.2.13 (step 4), with @priority applied after its discard rules; "Service Instance Matching" (clause 5.2.1) is a distinct, hybrid-only step, not the general instance-selection mechanism.
Delivery over 5G Systems
The deployment guidance for carrying DVB-I over 5G is ETSI TR 103 972 (DVB-I service delivery over 5G Systems; Deployment Guidelines). It was produced by the DVB / 5G-MAG Joint Task Force, which mapped the commercial requirements captured in DVB C100 (Commercial Requirements for DVB-I over 5G, 2021) into a reference architecture and per-scenario workflows, and recorded the specification gaps it found. Because TR 103 972 is a technical report, its output is guidance and recommended changes rather than normative requirements.
| Scenario | Bearer | DVB media | 3GPP / ETSI transport |
|---|---|---|---|
| Standalone DVB-I over 5G Broadcast | Broadcast only | DVB-DASH in MBMS User Services | ETSI TS 103 720 (LTE-based 5G Broadcast) |
| DVB-I over 5GMS | Unicast only | DVB-DASH | 3GPP 5GMS (TS 26.501 and companions) |
| Concurrent / hybrid | 5G Broadcast and ordinary unicast | DVB-DASH | ETSI TS 103 720 for broadcast; the device's ordinary unicast connection (SGi/N6) |
Standalone DVB-I over 5G Broadcast. In the scenario TR 103 972 works through (clauses 6.2.2 and 6.2.3), DVB-DASH content is carried in MBMS User Services, with the MPD pulled by the BM-SC, and the selected service instance refers to the MBMS User Service. DVB-MABR is described as an alternative (clause 6.2.5.2), with its MPD handling left for further study.
DVB-I over 5GMS. The service instance references a DASH source served through 5G Media Streaming. The 5GMS downlink architecture (3GPP TS 26.501) provides the Media Application Server, session handling, and reporting; the DVB-DASH presentation is fetched and rendered by a 5GMS-aware client. The DVB-I layer above is unchanged.
Concurrent / hybrid. Both a 5G Broadcast instance and a unicast instance are present for the same service. TR 103 972 clause 6.4.3.2 has the unicast steps "carried out using the client's basic unicast connection to the public IP network at reference point SGi/N6 in place of 5GMSd reference point M8d." The client selects or switches between them based on coverage and capability, for example receiving popular linear channels over broadcast while using unicast for on-demand or out-of-coverage fallback.
The report relates DVB-I service discovery to the 3GPP service announcement differently in each scenario. For 5GMS, "Each service instance in the DVB-I Service List plays the role here of a Service Announcement at reference point M8d." (clause 6.3.3.2). For 5G Broadcast, the MBMS Service Announcement is used, with a DVB service class to find DVB-I services (clause 6.2.3.1 step 12; gap 4 of clause 6.2.4). The gaps it found "are documented as recommended changes to the relevant specifications under the control of the respective organization" (clause 6.1) (ETSI TR 103 972 V1.1.1 clause 6.3.3.2; ETSI TR 103 972 V1.1.1 clause 6.2.3.1; ETSI TR 103 972 V1.1.1 clause 6.2.4; ETSI TR 103 972 V1.1.1 clause 6.1).
The DVB-I layer itself exposes HTTP(S) interfaces: the Service List Registry query API, the service-list endpoint, and the content-guide/metadata endpoints, all defined in TS 103 770. On the transport side the reference points are those of the underlying 3GPP/ETSI systems rather than DVB: on the unicast path, the 5GMS reference points (for example the interfaces between the 5GMS-Aware Application, the Media Session Handler, the 5GMS AF, and the Media Application Server) apply as defined in 3GPP TS 26.501, see the 5GMS tech page; on the broadcast path, the reception and session-acquisition behaviour is defined by ETSI TS 103 720 and the underlying LTE terrestrial broadcast / MBMS procedures, see the 5G Broadcast tech page. DVB-I contributes the delivery parameters that tell the client which of these transports to use for a given service instance; it does not redefine the transport reference points.
The slide deck below introduces DVB-I service discovery over 5G Systems; download the file for the full detail.