DVB-I service discovery over 5G Broadcast, 5G Media Streaming, and hybrid delivery, so broadcast and IP-delivered services can appear in a single list.
Overview
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. For acronyms used here, see the Glossary.
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).
Reference tools: the DVB-I reference tools implement service discovery against the delivery scenarios described below.
Go deeper
Technology & Analysis
DVB-I service discovery (A177/TS 103 770), the A178/TR 103 972 deployment guidelines, and the three delivery scenarios (standalone broadcast, 5GMS unicast, hybrid) below.
Standards Tracking
DVB and ETSI specifications for DVB-I service discovery and its deployment over 5G Systems.
Software Tools
Reference implementation of DVB-I service discovery and the 5G delivery scenarios.
The slide deck below introduces DVB-I service discovery over 5G Systems; download the file for the full detail.
Download the slidedeck with more information
DVB-I service discovery in detail
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.
Data model
The relevant objects for an implementer are:
- 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. The service instance can reference:
- 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. The spec leaves tie-breaking between equal-priority instances implementation-dependent — this is where a client's own capability and coverage logic (and any broadcast/unicast fallback policy) comes in, on top of the @priority ordering the spec itself defines. 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.
Bootstrap and the Service List Registry
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. See the implementation blueprint below for the full bootstrap sequence with clause references. 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, verified against ETSI TS 103 770 V1.2.1 (2024-09), the current published version (cross-checked against the DVB A177r8 / draft ETSI TS 103 770 V1.3.1 text dated June 2026: the clause numbers below are identical in both, so they should hold even once that draft is published). See the Implementation Blueprints index for the other blueprints on this portal.
Most of this sequence 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" actually 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, covered below under "Delivery over 5G Systems." DVB-I over 5G reuses this blueprint almost unchanged, the same relationship MBS Broadcast over NTN has to the terrestrial MBS blueprint.
| Step | Interface (Fig. 1) | 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 one of several discovery paths: a pre-configured URL, broadcast NIT/BAT signalling, a CICAM, or mDNS/DNS-SD | 5.1.3.1 (the options); 5.1.3.3 to 5.1.3.9 (each specific mechanism) |
| 2. Query the Service List Registry | F1 → F2 | 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 | B1 → B2 | 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 | A1 → A2 | 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) |
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. One correction made in the course of this check: this page previously implied that a device selects among multiple service instances purely on local capability/coverage; the spec's own explicit mechanism is 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; the two were previously conflated on this page and are now described separately.
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.
Reference architecture
The report proposes a single DVB-I-over-5G reference architecture that supports all three service scenarios. The consistent principle is a clean split between layers:
- Service layer (DVB-I): discovery, selection, and programme metadata. Unchanged across scenarios.
- Media format layer (DVB): DVB-DASH (ETSI TS 103 285) for the media presentation; DVB-MABR (ETSI TS 103 769) where multicast delivery is used. The media pipeline above the bearer is the same whether the segments arrived by unicast or by broadcast.
- Transport layer (3GPP / ETSI): 5G Media Streaming for unicast, and the LTE-based 5G Broadcast system (ETSI TS 103 720) for broadcast.
The three service scenarios
| 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.
Service discovery meets 3GPP service announcement
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. On the 5G Broadcast side, 3GPP defines its own service announcement carrying the parameters a receiver needs to acquire a session. The report considers 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.
Interfaces and reference points
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 for the detail of those reference points.
- 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.
Identified gaps and follow-up
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 follow-up on those recommendations happens in the respective bodies (DVB for the DVB-I and delivery-format specifications, 3GPP SA4 for 5GMS and MBS, ETSI JTC Broadcast for TS 103 720). Implementers should treat the report as a snapshot of the integration approach and check the current versions of the referenced specifications for the state of any given item.
Related
- Standards: DVB-I Services over 5G Systems: the specification list for this topic
- DVB-I Services over 5G Systems Reference Tools: the software implementation
- 5G Media Streaming (5GMS) and 5G Broadcast - TV, Radio and Emergency Alerts: the unicast and broadcast delivery paths
Refer to the Tech repository to contribute to this documentation.