Skip to main content
DVB-I Services over 5G Systems

Implementation Detail

In short
  • Which specification the code follows: ETSI TS 103 770 V1.2.1 (2024-09), Service Discovery and Programme Metadata for DVB-I, with its schemas.
  • Status against TS 103 770: 89 requirements in 301 cases: 273 implemented, 13 differ from the specification, 10 not implemented, and 5 where the specification contradicts itself.
  • DVB-I over 5G, in its own section: 35 requirements in 96 cases, judged against TS 103 770 clause 9.3, 3GPP TS 26.347 V18.1.0 and ETSI TR 103 972 V1.1.1 (informative, so judged as guidelines): 18 implemented, 14 differ, 64 not implemented. The client checks and shows the 5G Broadcast signalling but reaches no MBMS Client. No component carries 5GMS Service Access Information, because no DVB or 3GPP element for it exists yet.
  • Source of this page: a code audit of the repositories on 2026-10-02: each requirement split into the cases its clause defines, each case checked against the code, and the TS 103 770 cases of the client, provider and registry then re-checked by a second reader.

For what the specifications define, see the Technical Analysis. For how to run the tools, see the Tutorials.

Architecture​

The DVB-I components and interfaces of TS 103 770, with the parts the Reference Tools provide and the status of each interface. The DVB-I over 5G architecture is in its own section.

DVB-I
DVB-I components and interfaces, with Reference Tools statusBased on ETSI TS 103 770 V1.2.1, figure 1; status from the code audit of 2026-10-02 against TS 103 770 V1.2.1

Click a figure to enlarge it.

Implementation status​

Each feature of TS 103 770, and the obligations it hands to ETSI TS 102 796 V1.8.1 (HTTP caching, the TLS profile, launch locations, the XML AIT and image formats), split into its requirements and each requirement into the cases its clause defines: what works, what does not, and why. Filter by component; open a feature, then a requirement.

  • ETSI TS 103 770 V1.2.1 (2024-09), Service Discovery and Programme Metadata for DVB-I, with its schemas (annex B).
  • ETSI TS 102 796 V1.8.1 (2026-09), Hybrid Broadcast Broadband TV, reference [21] of TS 103 770 V1.2.1 (undated, so its latest issue applies), with what it refers on to: TS 102 809 V1.3.1, IETF RFC 7230 and RFC 7234, RFC 8446, NIST SP 800-57 Part 1 Rev 5 and OIPF Release 2 volume 2 V2.3.
  • Client (DVB-I Application (browser client)): rt-dvb-i-application. Built against: TS 103 770 V1.2.1 (no build pin; stated in the README).
  • Provider (DVB-I Application Provider (service list and content guide)): rt-dvb-i-application-provider. Built against: TS 103 770 V1.2.1; output checked against its schemas.
  • Registry (DVB-I Service List Registry): rt-dvb-i-service-list-registry. Built against: TS 103 770 V1.2.1; responses checked against dvbi_service_list_discovery_v1.6.xsd.
  • Exo player (Exo DVB-I Player (Android WebView around an external DVB-I frontend, with ExoPlayer)): rt-5gms-application v1.3.0. Built against: ExoPlayer r2.18.2 (submodule); no DVB-I version stated.
  • Android (DVB-I over 5G Reference App (Android client)): rt-dvb-i-android-application. Built against: TS 103 770 V1.2.1 (stated in the README); Media3 ExoPlayer 1.10.0.
  • Source: code read in each repository, nothing built or run for the verdicts (the repositories' own tests pass); re-read after each change to the code, with an independent reader re-checking the TS 102 796 feature and the requirements whose verdicts changed, 2026-10-02.
273 of 301 implemented · 13 differ · 10 absent · 5 where the specification is inconsistentcases, over 89 requirements

✓ Implemented≠ Differs from the specification– Absent? Specification inconsistent: its text and its OpenAPI or tables disagreei Noted: observed, not a verdict against a clause

Service list discoveryThe registry answers queries with schema-valid Service List Entry Points for every offering type, includes offerings that leave a filter unspecified, refuses invalid TargetCountry and Language values, writes the service list media type and @regulatorListFlag, refuses unknown genre terms, and serves over TLS when configured, otherwise plain HTTP with a warning; how it treats image_variant falls under a contradiction in the specification. The browser client queries a registry, lists regulator lists first, acts on Delivery, Language, TargetCountry and logos, makes a regulator list the default whenever there is one, and checks ServiceListId. The Exo DVB-I Player does no discovery of its own.36 of 39 implemented · 1 differs · 1 absent · 1 where the specification is inconsistent
Service lists and servicesThe provider publishes schema-valid service lists as application/vnd.dvb.dvbisl+xml, with a new version on every change, JPEG or PNG logos, image variants, subscription packages, one LCN table per region and region selection by regionID. The client chooses one LCN table by region, honours @visible, @selectable and LCNRange, every target region, subscription packages, parental ratings and linked applications, and reads XML AITs, choosing an application by its type, its platform profile and its priority, and shows an application as unavailable, without an error, when its XML AIT has none it can run. The Exo player leaves all of this to an external frontend.66 of 69 implemented · 3 absent
Service instance selection and deliveryThe browser client selects instances by clause 5.2.13: per-instance availability, re-evaluation when hours change or an application exits, and @priority with its default of 0; it reads every DRM and CA system, shows DisplayName, caches and makes conditional requests, does not retry 400 or 406, backs off at random and fetches plain HTTP endpoints with a warning, not only on the same private subnet. It does not yet check codecs or the encryption scheme in advance, and after a 401 or 403 has no credentials to present. The provider writes schema-valid delivery signalling, including a 5G Broadcast instance as IdentifierBasedDeliveryParameters, and serves over TLS when a certificate is configured, otherwise plain HTTP with a warning. Carriage over 5G Broadcast (clause 9.3) is judged under DVB-I over 5G. The Exo wrapper leaves selection to an external frontend.40 of 51 implemented · 8 differ · 3 absent
Content guideThe provider signals its guide through ContentGuideSourceRef, answers timestamp requests with start and end checked and applied, now_next=true and now_next=window with the structural groups, and programme information by pid, writes the metadata profile including a deep-linked XML AIT for on-demand programmes, and returns both tables, empty, for a service with no events. The client finds guide sources by clause 6.1, makes aligned 12 hour, now/next and pid requests, browses More Episodes and Box Sets with pagination, launches on-demand through the XML AIT and enforces programme ratings; after a 404 from any guide endpoint it re-acquires the service list. The empty Schedule element and the programme image HowRelated term fall under contradictions in the specification. The Exo DVB-I Player leaves the guide to an external frontend.67 of 71 implemented · 2 absent · 2 where the specification is inconsistent
TS 102 796 (HbbTV, via TS 103 770)TS 103 770 hands eleven obligations to TS 102 796 V1.8.1 (its undated reference [21], whose latest issue applies). The browser and Android clients follow the HTTP/1.1 caching rules it leads to (no-store, freshness from Age and Date) and make conditional requests; where RFC 7234 has a no-cache response validated and TS 103 770 forbids a request before max-age has passed, the specification is inconsistent, and the two clients took opposite sides. Both use the clause 11.2 TLS profile for metadata connections, except that Android still lets a TLS 1.2 server sign with SHA-1, and both launch linked applications with the clause 6.2.2.6.2 launch location and XML AIT applications only of a platform profile table 5 admits. The provider and registry serve with that TLS profile and ECDHE preferred; the provider writes the XML AIT of its catch-up player to table 7, warns but still publishes an http: URLBase, accepts versions other than the 1.8.1 table 5 sets, and signals only JPEG and PNG images whose bytes it checks where it holds them. Whether the trust stores match the HbbTV root certificate list is not judged. The Exo DVB-I Player makes no conditional request and keeps no cache, and makes no TLS connection; the DSM-CC carousel and the AppInformation URNs of annex H apply to no component (no broadcast tuner, no access service signalled through a linked application).64 of 71 implemented · 4 differ · 1 absent · 2 where the specification is inconsistent

DVB-I over 5G status​

DVB-I services delivered over 5G Broadcast, over 5G Media Streaming, and over both together, judged against TS 103 770 clause 9.3, 3GPP TS 26.347 V18.1.0 and ETSI TR 103 972 V1.1.1. TR 103 972 is informative: its cases are guidelines, marked as such, not normative requirements.

DVB-I over 5G
DVB-I services over 5G systems, with Reference Tools statusBased on ETSI TR 103 972 V1.1.1, figure 5.1-1; status from the code audit of 2026-10-02 against TS 103 770 V1.2.1, TS 26.347 V18.1.0 and TR 103 972 V1.1.1

Click a figure to enlarge it.

Filter by component or specification; open a scenario, then a requirement.

  • ETSI TS 103 770 V1.2.1 (2024-09), Service Discovery and Programme Metadata for DVB-I, with its schemas (annex B).
  • ETSI TR 103 972 V1.1.1 (2023-07), DVB-I service delivery over 5G Systems; Deployment Guidelines (informative: it obliges no one).
  • 3GPP TS 26.347 V18.1.0 (Release 18), MBMS Application Programming Interface and URL.
  • Client (DVB-I Application (browser client)): rt-dvb-i-application. Built against: TS 103 770 V1.2.1 (no build pin; stated in the README).
  • Provider (DVB-I Application Provider (service list and content guide)): rt-dvb-i-application-provider. Built against: TS 103 770 V1.2.1; output checked against its schemas.
  • Registry (DVB-I Service List Registry): rt-dvb-i-service-list-registry. Built against: TS 103 770 V1.2.1; responses checked against dvbi_service_list_discovery_v1.6.xsd.
  • Exo player (Exo DVB-I Player (Android WebView around an external DVB-I frontend, with ExoPlayer)): rt-5gms-application v1.3.0. Built against: ExoPlayer r2.18.2 (submodule); no DVB-I version stated.
  • Android (DVB-I over 5G Reference App (Android client)): rt-dvb-i-android-application. Built against: TS 103 770 V1.2.1 (stated in the README); Media3 ExoPlayer 1.10.0.
  • Source: code read in each repository, nothing built or run for the verdicts (the repositories' own tests pass); re-read after each change to the code, with an independent reader re-checking the TS 102 796 feature and the requirements whose verdicts changed, 2026-10-02.
18 of 96 implemented · 14 differ · 64 absentcases, over 35 requirements

✓ Implemented≠ Differs from the specification– Absent? Specification inconsistent: its text and its OpenAPI or tables disagreei Noted: observed, not a verdict against a clause

DVB-I over 5GTS 103 770 clause 9.3 has the DVB-I client work through an MBMS Client, which falls on the 3GPP APIs of TS 26.347; TR 103 972 adds deployment guidelines for 5G Broadcast, 5G Media Streaming and both together, and is informative (clause 2.1: "Normative references are not applicable in the present document."; the NOTE under its requirement tables: "Modal verbs appearing in this table are non-normative in the context of the present document."), so its rows are judged as guidelines, not obligations. The provider publishes the service list for pull ingest with a new version on every change, a 5G Broadcast instance as an mbms:// locator it checks against TS 26.347 on save and restore and never publishes when invalid, and @priority on every instance; the registry keeps the Delivery values closed, as TS 103 770 requires. The browser client reads, checks and shows the 5G Broadcast signalling and plays a unicast instance of the service, DVB-I Playlists included, but calls no MBMS Client (owner decision: none is reached from the web for now) and no 5GMSd-Aware Application. The Android client, the DVB-I over 5G Reference App, does the same and also makes the calls a DVB-I client makes on an MBMS Client, but in every build they reach a stand-in that answers that none is available, as the MBMS Middleware for Android offers no interface to bind to yet; its 5G Media Streaming variant starts no 5GMS session. No component carries 5GMS Service Access Information, which no DVB or 3GPP element yet holds (owner decision: nothing invented). The Exo DVB-I Player leaves all of this to an external frontend.18 of 96 implemented · 14 differ · 64 absent
Full audit for members

This page summarises a requirement-by-requirement audit of the code. The full audit (each requirement with its clause quoted, the code that meets or misses it, and the findings) is available to 5G-MAG members through Developer Tools (the Standards2Deployments repository).

Become a member · Request access

Components​

DVB-I client​

DVB-I Application

A browser DVB-I client that discovers a service list,…

  • Built against: TS 103 770 V1.2.1 (stated in the README; no build pin).
  • Implemented: queries to a Service List Registry, with regulator lists first and a regulator list the default whenever there is one; Delivery, Language, TargetCountry and logos acted on; ServiceListId checked. One LCN table chosen by region, @visible, @selectable and LCNRange honoured, with target regions, subscription packages, parental ratings and linked applications. Service instances selected by clause 5.2.13, with @priority and its default of 0; caching and conditional requests. Content guide sources found by clause 6.1, with aligned 12 hour, now/next and pid requests, More Episodes and Box Sets with pagination, and programme ratings enforced. DASH instances and DVB-I Playlists played with dash.js.
  • TS 102 796: HTTP caching by RFC 7234 (no-store, freshness from Age and Date) with conditional requests; the clause 11.2 TLS profile for every metadata connection (TLS 1.3 and 1.2, the table 15a suites, no forbidden signature, root keys of at least 112 bits); the launch location of linked applications and of XML AIT requests; XML AIT applications chosen by application type and the table 5 platform profile.
  • Specification inconsistent: a response with both no-cache and max-age. RFC 7234 has it validated before each reuse, TS 103 770 clause 4.3.2.1 forbids a request before max-age has passed; this client follows TS 103 770.
  • Partial: codecs and the encryption scheme are not checked in advance; after a 401 or 403 there are no credentials to present; plain HTTP endpoints are fetched with a warning, not only on the same private subnet; a service list on a local Media Server loads only when the deployment names that server as an exception.
  • Not implemented: carriage in MBMS (clause 9.3) and the TS 26.347 MBMS Client APIs: for now no MBMS Client is reached from the browser. The client reads, checks and shows the 5G Broadcast signalling and plays a unicast instance of the service instead. It passes no MPD address to a 5GMSd-Aware Application.

DVB-I over 5G Reference App (Android)​

DVB-I over 5G Reference App

A native Android DVB-I client: it discovers a service list,…

  • Built against: TS 103 770 V1.2.1 (stated in the README); Media3 ExoPlayer 1.10.0. The user interface is based on the design of 5G-MAGflix, the 5GMSd Aware Application in rt-5gms-application, by Daniel Silhavy (Fraunhofer FOKUS).
  • What it is: a native Android DVB-I client that ports the logic of the DVB-I client above, audited with the other components. It has been run on a phone over Wi-Fi against the DVB-I examples, and its 122 unit tests pass.
  • Implemented: service lists from a URL or a Service List Registry query, with a regulator list the default whenever there is one; LCN tables by region; service instances selected by clause 5.2.13; DASH and HLS played, with live and on-demand controls; access services, ratings and delivery shown as icons; the HTTP rules of clause 4.3; now/next, schedules, a programme guide grid and programme information; More Episodes, Box Sets and on-demand programmes; linked applications and DVB-I Playlists; plain HTTP only to the hosts named at build time, with a warning.
  • TS 102 796: HTTP caching by RFC 7234 with conditional requests; the clause 11.2 TLS profile for metadata connections (TLS 1.3 and 1.2, the table 15a suites, certificates with an RSA key under 2 048 bits, a root under 112 bits or an MD5 or SHA-1 signature refused); the launch location of linked applications and of XML AIT requests; XML AIT applications chosen by application type and the table 5 platform profile; only JPEG and PNG images shown.
  • Partial: in TLS 1.2 the platform still offers the rsa_pkcs1_sha1 signature algorithm, which table 15b forbids.
  • Specification inconsistent: a response with both no-cache and max-age, as for the browser client; this client follows RFC 7234 and validates it before each reuse.
  • Not implemented: HbbTV applications, Restart links, and a PIN for restricted content. 5G Broadcast signalling is read, checked and shown; the app is built in three variants: plain DVB-I, DVB-I as the MBMS-Aware Application through the 5G-MAG MBMS Middleware for Android (which does not yet expose an interface to bind to), and DVB-I as a 5GMSd-Aware Application. The two 5G variants are placeholders for now.

Application Provider (service list and content guide)​

DVB-I Application Provider

Publishes a DVB-I service list and its content guide, and…

  • Built against: TS 103 770 V1.2.1; output checked against its schemas.
  • Implemented: schema-valid service lists published as application/vnd.dvb.dvbisl+xml, with a new version on every change, JPEG or PNG logos, image variants, subscription packages, one LCN table per region and region selection by regionID. Delivery signalling, including a 5G Broadcast instance as IdentifierBasedDeliveryParameters holding its mbms:// URL, checked against the TS 26.347 URL form on save and on restore so that an invalid one is never published, and @priority where one is configured. Content guide: ContentGuideSourceRef, timestamp, now/next and programme information requests, and the metadata profile, including a deep-linked XML AIT for on-demand programmes.
  • TS 102 796: the clause 11.2 TLS profile when served over TLS, with ECDHE suites preferred; the content deep-linked XML AIT of clause 7.2.3.2 (application type, control code, one transport, length limits, media type), with the platform version 1.8.1 that table 5 sets; images only as JPEG or PNG, no GIF.
  • Partial: served over TLS when a certificate is configured, otherwise plain HTTP with a warning. An http: URLBase in an XML AIT is published with a warning, where clause 11.9 advises https:. A 5G Broadcast instance is told apart from a unicast one only by its element and URL scheme.
  • Not implemented: DVB-I Playlists, and 5GMS Service Access Information, which no DVB or 3GPP element yet carries in a service list.
  • Specification inconsistent: the empty Schedule element and the programme image HowRelated term, where TS 103 770 contradicts itself.

Service List Registry​

DVB-I Service List Registry

Answers DVB-I client queries with a list of Service List…

  • Built against: TS 103 770 V1.2.1; responses checked against dvbi_service_list_discovery_v1.6.xsd.
  • Implemented: queries answered with schema-valid Service List Entry Points for every offering type, including offerings that leave a filter unspecified; invalid TargetCountry, Language and Genre values refused; the service list media type and @regulatorListFlag written; the Delivery values kept to those TS 103 770 defines.
  • TS 102 796: the clause 11.2 TLS profile when served over TLS, with ECDHE suites preferred.
  • Partial: served over TLS when configured, otherwise plain HTTP with a warning.
  • Specification inconsistent: the image_variant query parameter, where TS 103 770 contradicts itself.

Exo DVB-I Player​

5GMS-Aware Application

This repository holds applications that can be used to test…

  • Built against: ExoPlayer r2.18.2; no DVB-I version stated. Audited at release v1.3.0.
  • What it is: an Android WebView around an external DVB-I frontend, which is not 5G-MAG code, with ExoPlayer playing the DASH addresses the frontend requests.
  • Implemented: playback of the intercepted MPD address; no retry after a 400 or 406.
  • Partial: the service list is fetched from a fixed http:// address, with no conditional request and Cache-Control not honoured.
  • Not implemented: registry queries, service list handling, service instance selection and the content guide, which the external frontend does; MBMS carriage, the TS 26.347 APIs and 5G Media Streaming.

Supporting repositories​

These support the components above; the table does not rate them.

DVB-I Examples

Runnable examples that bring the DVB-I repositories up…

  • Examples: runnable examples that bring the DVB-I repositories up together on one machine, publishing and playing a service list.
  • Media origin: the examples use rt-media-origin, which packages each channel as live DASH and serves it. It is not yet public.

Used with other projects​

  • 5G Media Streaming (5GMS): the Exo DVB-I Player lives in rt-5gms-application. used.