DVB-I (DVB internet, an ETSI-published DVB specification) lets a device discover and present linear TV and radio services delivered over IP, listing broadcast and broadband streams together in a single service list. This page covers how DVB-I service discovery works over 5G Systems, so that services carried by 5G Broadcast or 5G Media Streaming can appear alongside other IP-delivered content.
5G-MAG tracks this work and maintains related reference tooling, built by contributors including Fraunhofer FOKUS, Dolby Laboratories, Qualcomm and the BBC. The project has no repositories of its own: the reference tools linked below implement the delivery scenarios against the specifications this page describes.
The Problem It Solves
Without DVB-I, a broadcaster's 5G Broadcast service and its 5GMS unicast service would look like two unrelated things to a device, discovered separately with no common presentation. DVB-I's service instance model fixes that: one logical service can carry several delivery instances — a broadcast instance and a unicast instance for the same channel — and the device picks between them by priority, or, for a hybrid device already tuned to the broadcast signal directly, de-duplicates the two so the same channel doesn't appear twice. That is what lets broadcast and broadband content sit in one combined service list instead of two separate discovery systems a viewer has to reconcile themselves.
Open Source, Built Together
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.
Key specifications: DVB A177 / ETSI TS 103 770 (DVB-I Service Discovery and Programme Metadata), DVB A178 / ETSI TR 103 972 (DVB-I service delivery over 5G Systems deployment guidelines).
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. - 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.
- 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.
The delivery-parameter types inside a service instance are the extension point the 5G work relies on: a DASH delivery (a DVB-DASH presentation) for unicast, a DVB multicast (DVB-MABR) session for scalable delivery, or a broadcast source carried on a broadcast bearer. Where a service has more than one instance, TS 103 770 Clause 5.5.4 (ServiceInstanceType) gives each instance a @priority attribute: a lower value means higher priority, and the client selects accordingly. Tie-breaking between equal-priority instances is implementation-dependent — a client's own capability and coverage logic (and any broadcast/unicast fallback policy) comes in on top of the @priority ordering. A hybrid client that also receives the same content over classical DVB-T/C/S separately performs a distinct step, Service Instance Matching (Clause 5.2.1): de-duplicating a DVB-I-discovered instance against an already-tuned broadcast service using DVB Triplet/Network ID metadata, so the two don't 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–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 a DVB-MABR session carried over 5G Broadcast (ETSI TS 103 720) — that specific mapping is what DVB A178 / TR 103 972 defines.
| Step | What happens | Clause |
|---|---|---|
| 1. 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, broadcast NIT/BAT signalling, a CICAM, or mDNS/DNS-SD. | 5.1.3.1 (the options); 5.1.3.3–5.1.3.9 (each mechanism) |
| 2. Query the Service List Registry | HTTP GET to the SLR endpoint, optionally with filter parameters (TargetCountry, regulatorListFlag, Delivery, Language, Genre, ProviderName, inlineImages, image_variant, 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. 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. Select a delivery instance per service | Where a Service has more than one ServiceInstance (for example broadcast and DASH), the client orders them by the @priority attribute (lower value wins); ties are implementation-dependent. | 5.5.4 (ServiceInstanceType) |
| 5. Hybrid clients only: de-duplicate against a tuned broadcast service | If the client also receives DVB-T/C/S directly, it matches a DVB-I instance against an already-tuned service using DVB Triplet/Network ID metadata, so it isn't listed twice. | 5.2.1 (Service Instance Matching) |
| 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) for the same clauses — both give identical clause numbers and content for every row above. Instance selection is driven by the @priority attribute on ServiceInstanceType (Clause 5.5.4), with capability/coverage logic only breaking ties between equal-priority instances; "Service Instance Matching" (Clause 5.2.1) is a distinct, hybrid-only step (de-duplicating against a directly-tuned broadcast service), not the general instance-selection mechanism.
Delivery over 5G Systems
The deployment guidance for carrying DVB-I over 5G is DVB A178, published by ETSI as 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.
The report proposes a single DVB-I-over-5G reference architecture that supports all three service scenarios, built on a clean split between layers: the service layer (DVB-I) handles discovery, selection and programme metadata, unchanged across scenarios; the media format layer (DVB) is DVB-DASH (ETSI TS 103 285) for the media presentation and DVB-MABR (ETSI TS 103 769) where multicast delivery is used; and the transport layer (3GPP / ETSI) is 5G Media Streaming for unicast and the LTE-based 5G Broadcast system (ETSI TS 103 720) for broadcast.
| Scenario | Bearer | DVB media | 3GPP / ETSI transport |
|---|---|---|---|
| Standalone DVB-I over 5G Broadcast | Broadcast only | DVB-MABR carrying DVB-DASH | 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 | Broadcast and unicast | DVB-DASH, DVB-MABR on the broadcast leg | Both of the above |
Standalone DVB-I over 5G Broadcast. The service list is delivered (or pre-provisioned) and the selected service instance references a broadcast source. The client receives a DVB-MABR-style multicast on the 5G Broadcast bearer and reconstructs the DVB-DASH presentation locally. There is no unicast return leg for the media itself; any interactivity depends on separate connectivity.
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 broadcast instance and a unicast instance are present for the same service. 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.
A specific alignment question the report examines is the relationship between DVB-I service discovery and the 3GPP service announcement used on the broadcast/multicast path: how a DVB-I service list can reference, or coexist with, that announcement rather than duplicating the same information in two places. This is one of the areas where recommended changes were fed back to the responsible bodies.
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.
Because A178 is a technical report, a substantial part of its value is the catalogue of gaps it identified and the recommended changes to specifications owned by DVB, 3GPP and ETSI. The Requirements, Specifications and Gaps page maps the commercial requirements to the specifications addressing them and re-checks the fourteen gaps ETSI TR 103 972 recorded.
The slide deck below introduces DVB-I service discovery over 5G Systems; download the file for the full detail.
Download the slide deck with more information and the Execution Plan tracks current implementation work.
Related: Standards: DVB-I Services over 5G Systems · DVB-I Services over 5G Systems Reference Tools · 5G Media Streaming (5GMS) and 5G Broadcast - TV and Radio Services: the unicast and broadcast delivery paths
Join the Effort
Help shape what connected media looks like next and scale your projects with the industry.