ETSI TS 103 464 V1.2.1 (2020-05)

Hybrid Broadcast Broadband TV Application Discovery over Broadband

RTS/JTC-053

General Information

• Status: Not Published
• Technical Committee: BROADCAS - EBU/CENELEC/ETSI on Broadcasting
• Current Stage: 12 - Completion
• Due Date: 27-May-2020
• Completion Date: 25-May-2020

Standards Content (Sample)

TECHNICAL SPECIFICATION
Hybrid Broadcast Broadband TV
Application Discovery over Broadband


2 ETSI TS 103 464 V1.2.1 (2020-05)

Reference
RTS/JTC-053
Keywords
broadcasting, DVB, HTML, internet

ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2020.
© European Broadcasting Union 2020.
All rights reserved.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.

3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners. ®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 ETSI TS 103 464 V1.2.1 (2020-05)
Contents
Intellectual Property Rights . 6
Foreword . 6
Modal verbs terminology . 6
Introduction . 7
1 Scope . 8
2 References . 8
2.1 Normative references . 8
2.2 Informative references . 9
3 Definition of terms, symbols and abbreviations . 9
3.1 Terms . 9
3.2 Symbols . 9
3.3 Abbreviations . 10
4 Overview (informative) . 10 ®
5 HbbTV Application Discovery over Broadband . 12
5.1 Introduction . 12
5.2 Discovering broadcaster AIT servers . 12
5.3 Service Identification . 13
5.3.1 Service Identification in the presence of DVB Service Information . 13
5.3.2 Service Identification using ATSC 3 watermarks . 14 ®
5.4 HbbTV DNS FQDN Construction . 14 ®
5.4.1 HbbTV DNS FQDN Construction in the presence of DVB Service Information . 14 ®
5.4.2 HbbTV DNS FQDN Construction using ATSC 3 watermarks . 14
5.5 Resolution of Authoritative FQDN . 15
5.6 AIT retrieval . 15
5.6.1 AIT retrieval in the presence of DVB Service Information . 15
5.6.2 AIT retrieval when ATSC 3 watermarks are used . 16
5.6.3 Common AIT retrieval requirements . 16
6 Service and application model . 16
6.1 Introduction . 16
6.2 Priority between application discovery mechanisms . 16
6.2.1 Services received via DVB transmission . 16
6.2.2 Services received via HDMI . 17
6.2.3 Services received via other input sources . 17
6.3 Watermark states and transitions . 17
6.3.1 State machine . 17
6.3.2 Verification of video watermarks . 25
6.3.3 Monitoring for watermarks . 25
6.4 Application lifecycle when controlled by watermarks . 25
6.4.1 Introduction. 25 ®
6.4.2 Managing the HbbTV application lifecycle . 25
6.4.2.1 Introduction . 25
6.4.2.2 Acquire and Process an AIT. 27
6.4.2.3 AIT Validity . 28
6.4.2.4 Watermark media timeline . 28
6.4.2.4.1 Introduction . 28
6.4.2.4.2 Initializing the watermark media timeline . 29
6.4.2.4.3 Determining the Media Time of watermarked content . 31
6.4.2.4.4 Maintaining synchronization to the Watermark Media Timeline . 31
6.4.3 Loss of watermark . 31 ®
6.4.4 Transitioning between HbbTV Application types . 32
7 Formats and protocols . 32
7.1 Signalling of applications . 32
ETSI
4 ETSI TS 103 464 V1.2.1 (2020-05)
7.1.1 XML AIT for Broadcast-related broadband application discovery . 32
7.1.2 XML AIT Extensions . 33
7.2 Watermark formats . 38
7.2.1 Introduction. 38
7.2.2 ATSC 3 Watermarks . 38
8 Browser application environment . 39
8.1 Extensions to the application/oipfApplicationManager embedded object and the Application class . 39
9 System integration . 40
9.1 Use of video/broadcast API and related classes with watermarking . 40
9.2 Use of MediaSynchroniser API with watermarking . 42
9.3 Use of Stream Events API . 43
9.3.1 Stream events in the presence of DVB Service Information . 43
9.3.2 Stream events with application discovery using ATSC3 watermarking . 43
9.3.2.1 General . 43
9.3.2.2 Events delivered in video watermarks. 43
9.3.2.3 Deriving stream events from VP1 payloads . 44
9.4 Reliability and resilience . 46
9.4.1 User interaction . 46
9.4.2 Malformed or malicious inputs . 46
9.4.3 Long-term use . 47
9.4.4 Watermarks and XML-AIT . 47
10 Capabilities . 47
10.1 Display model . 47
10.2 Terminal capabilities and functions . 47
10.2.1 Minimum terminal capabilities . 47 ®
10.2.2 HbbTV reported capabilities and option strings . 48
11 Security. 48
11.1 Introduction . 48
11.2 Modification of DVB Service Information or the VP1 Payload of the watermark . 48
11.2.1 Risks . 48
11.2.2 Applicable Application Discovery Methods . 49
11.2.3 Mitigation Techniques . 49
11.3 Modification of dynamic event messages carried in watermarks . 49
11.3.1 Risks . 49
11.3.2 Applicable Application Discovery Methods . 49
11.3.3 Mitigation Techniques . 49
11.4 Attacks on DNS Resolution. 49
11.4.1 Risks . 49
11.4.2 Applicable Application Discovery Methods . 50
11.4.3 Mitigation Techniques . 50
12 Privacy . 50
12.1 Introduction . 50
12.2 Application Retrieval via Broadband . 50
12.2.1 Risks . 50
12.2.2 Applicable Application Discovery Methods . 50
12.2.3 Mitigation Techniques . 51
12.3 AIT Retrieval via Broadband . 51
12.3.1 Risks . 51
12.3.2 Applicable Application Discovery Methods . 51
12.3.3 Mitigation Techniques . 51
12.4 Authoritative FQDN Resolution Using Watermarking . 51
12.4.1 Risks . 51
12.4.2 Applicable Application Discovery Methods . 51
12.4.3 Mitigation Techniques . 51
Annex A (normative): OIPF specification profile . 52
A.1 Detailed section-by-section definition for volume 5 . 52
ETSI
5 ETSI TS 103 464 V1.2.1 (2020-05)
A.2 Modifications, extensions and clarifications to volume 5 . 52
A.2.1 Extensions to the OIPF-defined capability negotiation mechanism . 52
Annex B (normative): Electronic attachments . 55
Annex C (informative): Sequence diagrams . 56
C.1 Application discovery in the presence of DVB Service Information . 56
C.2 Application discovery using ATSC 3 watermarks . 58
History . 61

ETSI
6 ETSI TS 103 464 V1.2.1 (2020-05)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Technical Specification (TS) has been produced by Joint Technical Committee (JTC) Broadcast of the European
Broadcasting Union (EBU), Comité Européen de Normalisation ELECtrotechnique (CENELEC) and the European
Telecommunications Standards Institute (ETSI).
NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body
by including in the Memorandum of Understanding also CENELEC, which is responsible for the
standardization of radio and television receivers. The EBU is a professional association of broadcasting
organizations whose work includes the co-ordination of its members' activities in the technical, legal,
programme-making and programme-exchange domains. The EBU has active members in about
60 countries in the European broadcasting area; its headquarters is in Geneva.
European Broadcasting Union
CH-1218 GRAND SACONNEX (Geneva)
Switzerland
Tel: [phone]
Fax: [phone]
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
7 ETSI TS 103 464 V1.2.1 (2020-05)
Introduction
The versions of ETSI TS 102 796 [1] published to date rely on signalling in the broadcast to start broadcast-related
applications, through the Application Information Table (AIT). The present document defines methods for discovery of ®
broadcast-related HbbTV services via a broadband internet connection for circumstances when the AIT and related ®
signalling via the broadcast network is not available to the HbbTV terminal. The discovery methods rely on retrieving
or extracting a unique identifier for a broadcast channel and then starting a discovery process to find a server that can be
contacted to retrieve an AIT over the broadband connection. The broadband-retrieved AIT would only be used if no
AIT is available in the broadcast channel. The discovery method relies on the Internet's DNS system. In simplified
form, the process works as follows:
• Extract a unique identifier from the broadcast channel.
• With the unique identifier, perform a DNS query to find (resolve) the AIT server.
• Ask the AIT server for an AIT that matches the broadcast channel. ®
• Using the AIT, retrieve the HbbTV application.
The present document is targeted at two main deployment scenarios:
® ®
• HbbTV terminals connected to a DVB network which does not carry the HbbTV AIT. In this case the
unique identifier is based on DVB Service Information. ®
• HbbTV TV sets connected via HDMI to a STB that is in turn connected to the DVB network. In this case the
unique identifier is based on information carried in the video and audio content (referred to as a 'watermark' in
the present document). This method has the additional capability of enabling discovery of a media timeline
and stream events. This capability can also be employed when a terminal is connected to a DVB network that
does not carry timeline or stream events.
Both discovery methods can also be used in other deployment scenarios, for example the watermark can be used for
application discovery from a DVB broadcast and the service information approach could be adapted for use with IPTV
or live OTT solutions using proprietary service discovery.
An AIT retrieved over the broadband connection and the Application referenced in that AIT are not necessarily the ®
same as the AIT that would be available in the broadcast and the associated HbbTV Application. Generally, when no
AIT is available in the broadcast, then neither would be event signalling, and the provider of the application may want ®
to resort to alternative methods for providing event signalling to the HbbTV application. When discovery using DVB
is employed, the application may have to be modified to receive events in another manner (e.g. via broadband). When
discovery using watermarking is employed, stream events may be delivered via the watermark.
The discovery method that employs DVB Service Information does not allow for application changes over time - e.g.
when the program changes. When this method is employed, the application will have to include the necessary logic.
Entities relying on the functionality provided in the present document are advised to consider these limitations when
writing their applications.
ETSI
8 ETSI TS 103 464 V1.2.1 (2020-05)
1 Scope
The present document augments clause 6 of ETSI TS 102 796 [1], which states that broadcast-related applications are ®
signalled as part of the broadcast. It defines a method for discovery of HbbTV applications in settings where AIT ®
signalling via the broadcast network is not available to the terminal. In this situation, an HbbTV terminal may discover ®
broadcast-related HbbTV services via a broadband internet connection.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI TS 102 796: "Hybrid Broadcast Broadband TV".
NOTE: Including the latest errata as published on http://hbbtv.org/resource-library/#specifications.
[2] ETSI TS 102 796 (V1.4.1): "Hybrid Broadcast Broadband TV".
NOTE: Including the latest errata as published on http://hbbtv.org/resource-library/#specifications.
[3] ETSI EN 300 468: "Digital Video Broadcasting (DVB); Specification for Service Information (SI)
in DVB systems".
[4] Open IPTV Forum Release 2 specification, volume 5 (V2.3): "Declarative Application
Environment".
[5] ETSI TS 102 034 (V1.5.1): "Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based
DVB Services over IP Based Networks".
[6] ETSI TS 102 809: "Digital Video Broadcasting (DVB); Signalling and carriage of interactive
applications and services in Hybrid Broadcast/Broadband environments".
[7] IETF RFC 6066: "Transport Layer Security (TLS) Extensions: Extension Definitions".
[8] W3C Recommendation (Second Edition) (10 June 2008): "XML Signature Syntax and
Processing".
[9] ATSC A/336: "Content Recovery in Redistribution Scenarios".
[10] IETF RFC 1034: "Domain Names - Concepts and Facilities".
[11] IETF RFC 1035: "Domain Names - Implementation and Specification".
[12] ATSC A/334: "Audio Watermark Emission".
[13] ATSC A/335: "Video Watermark Emission".
[14] ISO/IEC 8859-5: Information technology -- 8-bit single-byte coded graphic character sets -- Part 5:
Latin/Cyrillic alphabet".
ETSI
9 ETSI TS 103 464 V1.2.1 (2020-05)
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI TS 103 270 (V1.1.1): "RadioDNS Hybrid Radio; Hybrid lookup for radio services".
[i.2] ETSI TS 103 286-2 (V1.2.1):"Digital Video Broadcasting (DVB); Companion Screens and
Streams; Part 2: Content Identification and Media Synchronization".
[i.3] ISO/IEC 13818-1:2018: "Information technology -- Generic coding of moving pictures and
associated audio information -- Part 1: Systems".
[i.4] IETF RFC 4033: "DNS Security Introduction and Requirements".
[i.5] IETF RFC 4034: "Resource Records for the DNS Security Extensions".
[i.6] IETF RFC 4035: "Protocol Modifications for the DNS Security Extensions".
[i.7] ETSI TS 103 555: "IP-delivered Broadcast Channels and Related Signalling of HbbTV
Applications".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI TS 102 796 [1] and the following apply:
AIT server: server that for provides broadcast-related AIT(s) over broadband
audio watermark segment: VP1 audio watermark segment as defined in clause 5.2.5 of ATSC A/336 [9] ®
authoritative FQDN: internet domain for a (HbbTV ) service provider
discovered AIT: broadcast related AIT retrieved according to the present document ®
HbbTV DNS FQDN: internet domain constructed only for the purpose of querying DNS
interval_field: field in the ATSC A/336 VP1 payload containing the interval code
interval code: value that identifies the interval of content in which the VP1 payload value is embedded
query flag: value of the query_flag field in an instance of the VP1 Payload as defined in ATSC A/336 [9]
server code: value that identifies a server which acts as the starting point for acquisition of supplementary content
server field: field in the ATSC A/336 VP1 payload containing the server code
video watermark segment: VP1 video watermark segment as defined in clause 5.1.7 of ATSC 336 [9]
watermark segment: audio watermark segment or a video watermark segment
3.2 Symbols
Void.
ETSI
10 ETSI TS 103 464 V1.2.1 (2020-05)
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI TS 102 796 [1] and the following apply:
TTL Time To Live
4 Overview (informative)
The methodology is modelled after RadioDNS [i.1], using certain parameters provided in the broadcast for the
identification of services. These could be digital parameters extracted from DVB Service Information, e.g. DVB-SI [3],
or parameters encoded in a digital watermark that is inserted for the purpose of enabling this discovery method. The
present document defines operation either in the presence of DVB Service Information or, alternatively, in the presence
of specified audio and/or video watermarks; other operation modes may be added in a future version.
The discovery method allows broadcasters to uniquely associate an AIT server with their channel and comprises
discovering an authoritative FQDN for an AIT server, using DNS queries to hbbtvdns.org, a root domain name server.
NOTE: It is possible for local markets to define a market-specific alternative to hbbtvdns.org; this is not further
addressed in the present document.
The protocol for discovery and retrieval of an AIT for a single service follows a number of steps, as outlined below.
Figure 1 illustrates the steps using the example of DVB-based parameters and figure 2 illustrates the steps using the
example of watermark-based parameters: ®
• The terminal queries a DNS recursive resolver using an HbbTV DNS FQDN constructed from information
present in the broadcast (1). A DNS recursive resolver known to the terminal returns the authoritative FQDN
for that service (2), acquiring the mapping (if available) from the root domain name server if it is not locally
cached.
• Either (1) When the terminal is receiving a DVB broadcast, there is no AIT in the broadcast signal or (2)
When the terminal is presenting video from HDMI and receives a watermark as defined in the present
document; then the terminal retrieves an XML-encoded AIT from the server using a URL constructed from
authoritative FQDN (3 and 4). AIT retrieval includes acquisition of the AIT server address by the terminal
from a DNS recursive resolver, which in turn acquires it (if available) from the broadcaster's Authoritative
FQDN DNS root if it is not locally cached.
• The terminal uses the AIT for that broadcast service and retrieves the application (5 and 6).
ETSI
11 ETSI TS 103 464 V1.2.1 (2020-05)
®
Figure 1: HbbTV Application Discovery over Broadband in the presence of DVB Service Information
ETSI
12 ETSI TS 103 464 V1.2.1 (2020-05)
®
Figure 2: HbbTV Application Discovery over Broadband in the presence of watermark information ®
5 HbbTV Application Discovery over Broadband
5.1 Introduction
This clause defines a method for discovery and signalling of broadcast-related applications, which are discovered and
signalled via broadband, instead of being signalled as part of the broadcast channel as defined in clause 7.2.3.1 of ETSI
TS 102 796 [1].
The structure of this clause reflects the fact that the present document defines generic methods as well as instantiations
that map on specific ways in which identifiers can be extracted and used. The present version defines such a mapping
for a terminal that receives a DVB signal and one that relies on watermarking, to enable operation of terminals that do
not receive the digital broadcast signal, for instance when the terminal is connected to a set top box with an HDMI ®
cable. Mappings for non-DVB digital broadcasts can be added based on the HbbTV IPTV specification ETSI
TS 103 555 [i.7] or platform specific integration.
Terminals shall implement all of the mandatory requirements in the ETSI TS 102 796 [1], except where explicitly stated
otherwise in the present document.
5.2 Discovering broadcaster AIT servers
The terminal shall attempt to discover broadcasters' AIT servers according to the process as described below. This
process is independent from service selection by the user and shall be executed in the following cases:
• For each service in the terminal's channel list (see ETSI TS 102 796 [1] and the OIPF DAE specification [4])
and for each server_field in the server field cache (if application discovery using watermarking is supported), ®
when the terminal is powered on. These attempts shall be made in alphabetical order by HbbTV DNS FQDN.
ETSI
13 ETSI TS 103 464 V1.2.1 (2020-05)
• For any service where the terminal detects a change in the service name.
• For any service that is added to the terminal's channel list.
• For every service in the terminal's channel list, when the terminal's country setting is changed.
• For every server field value, when it is added to the server field cache.
Discovery of an AIT server shall be performed in the following way:
• The Authoritative FQDN shall be resolved as specified in clause 5.5, using Service Identification as specified ®
in clause 5.3 and the HbbTV DNS FQDN construction as specified in clause 5.4.
The following caching rules shall apply to DNS resolution performed for resolution of the Authoritative FQDN as
specified in clause 5.5:
• DNS resource records shall be cached by the terminal in accordance with the resolver caching rules of IETF
RFC 1034 [10] and IETF RFC 1035 [11], as amended by the present clause.
• Cached DNS resource records shall not be retained over a power cycle.
• Terminals shall be capable of simultaneously caching the DNS resource records of all services in the channel
list and, if the terminal supports application discovery using watermarking, all server fields in the server_field
cache as defined below.
• If a DNS resource record retrieval returns a name error (i.e. the record does not exist), the terminal shall cache
this negative response with a TTL of 24 hours.
• Terminals shall refresh each cached DNS resource record once it has been stored in the cache for a number of
seconds equal to the TTL associated with the DNS record (as defined in clause 5.1 of IETF RFC 1035 [11]),
independently of and asynchronous to AIT retrieval.
NOTE: It is understood that terminals typically incorporate a DNS stub resolver that does not perform caching
and rely on a remote recursive resolver identified via DHCP for caching. Terminals are not expected to
implement a recursive resolver for the purpose of complying with these requirements. The DNS caching
behaviour is expected to be included as part of a terminal implementation that employs a stub resolver.
The server field cache enables the terminal to populate its DNS cache with the records associated with previously
viewed watermarked services upon power-up. Terminals supporting application discovery based on watermarking shall
apply the following caching rules to server_field values detected from watermarks:
• server_field values detected from watermarks shall be cached by the terminal (the "server field cache").
• The server field cache shall be retained across power cycles and erased only upon user request (e.g. via a
terminal feature such as "restore factory settings" or "delete stored information"). To ensure that the cache is
retained when power is removed from the terminal entirely, terminals shall write changes to server field cache
data to persistent storage within 5 minutes of the terminal being put into standby and should write changes to
server field cache data to persistent storage soon after that data has been set or modified, e.g. within 30 s.
• Terminals shall be capable of storing 200 server_field values in the server field cache and the cached values
shall not expire. However, if the cache does not have space to store a new server_field value, it shall replace
the oldest (i.e. least recently added) entry in the cache.
5.3 Service Identification
5.3.1 Service Identification in the presence of DVB Service Information
For terminals supporting application discovery over broadband using DVB Service Information, identification of a
service shall be provided by a combination of DVB service parameters. The parameters are defined in table 1.
ETSI
14 ETSI TS 103 464 V1.2.1 (2020-05)
Table 1: HbbTVDNS parameters
Parameter Description Value
Country 3-character country code as specified 3-char string
by the Configuration.countryId
property in Open IPTV Forum
Release 2 specification [4].
Servicename The DVB service name bytes from the Up to 256 two digit hex bytes
service_name field in the
service_descriptor in the SDT for this
service as defined in ETSI
EN 300 468 [3], encoded as a string of
two digit hex bytes.
Onid The original network id for this service 4-digit lower case hex string
as defined in ETSI EN 300 468 [3]
encoded as a string of two digit hex
bytes.
In the case of using the present document in the context of IPTV or OTT networks, mappings of DVB-SI and equivalent ®
information can be done based on the HbbTV IPTV specification [i.7] or via platform specific integration.
5.3.2 Service Identification using ATSC 3 watermarks
For watermarks whose payload is according to clause 5.2.3 of ATSC A/336 [9], services are identified using the
server_field (Server Code) from the vp1_payload structure. ®
5.4 HbbTV DNS FQDN Construction ®
5.4.1 HbbTV DNS FQDN Construction in the presence of DVB Service
Information ®
The terminal shall construct a HbbTV DNS FQDN as follows:
...dvb.hbbtvdns.org

The terminal shall extract and re-encode all the bytes from the service_name field in the service_descriptor in the SDT
as transmitted including any optional character selection byte. No character set processing or translation shall be
performed. This shall be done regardless of what character sets a terminal supports. ®
Some examples of HbbTV DNS FQDNs constructed from broadcast parameters are shown in table 2.
® ®
Table 2: Examples of HbbTV DNS FQDN construction for HbbTV ®
Country Servicename Onid HbbTV DNS FQDN
NLD 154e504f2031 ("NPO 1" with the 0x15 indicating 1e36 1e36.154e504f2031.NLD.dvb.hbbtvdns.org
UTF-8 character encoding as defined by ETSI
EN 300 468 [3])
DEU 10415244 ("ARD" with the 0x10 indicating 2345 2345.10415244.DEU.dvb.hbbtvdns.org
ISO/IEC 8859-5 [14] character encoding as defined
by ETSI EN 300 468 [3]). ®
5.4.2 HbbTV DNS FQDN Construction using ATSC 3 watermarks ®
For watermarks whose payload is according to clause 5.2.3 of ATSC A/336 [9], the terminal shall construct an HbbTV
DNS FQDN as follows;
.a336.watermark.hbbtvdns.org

ETSI
15 ETSI TS 103 464 V1.2.1 (2020-05)
The server_field from the most recently detected audio watermark shall be used, except in the Verified video watermark
detected only state (see table 5) where the server_field from the most recently detected video watermark payload shall
be used. The bits of the server_field shall be encoded as a hexadecimal number without leading zeros and with 10 to 15
being represented by lower case 'a' through 'f'.
EXAMPLE: A server code of binary 001 0010 1011 0100 1101 1000 is encoded as 12b4d8
Only the large_domain syntax is required to be supported.
5.5 Resolution of Authoritative FQDN ®
The terminal shall perform a DNS request using the HbbTV DNS FQDN, to acquire the Authoritative FQDN. The
response to this request contains a single CNAME record [11] containing the Authoritative FQDN of the service
provider. If no CNAME is returned (a "negative response"), then a broadband-discoverable AIT service has not been
registered. ®
EXAMPLE: Consider a TV service identified by the HbbTV DNS FQDN:
1e36.154e504f2031.NLD.dvb.hbbtvdns.org

A DNS lookup will yield the following lookup result:
1e36.154e504f2031.NLD.dvb.hbbtvdns.org. 86400 IN CNAME npo1.hbbtv.npo.nl.

Therefore, for this service, the Authoritative FQDN is:
npo1.hbbtv.npo.nl
5.6 AIT retrieval
5.6.1 AIT retrieval in the presence of DVB Service Information
The terminal shall retrieve the AIT by performing an HTTPS GET where the TLS client connection request includes the
Authoritative FQDN in the Server Name Indication (SNI) as specified in IETF RFC 6066 [7] request to the following
address:
https:///xml.aitx?onid=&network=&servicename=&sid=

The parameters that the terminal shall provide are shown in table 3.
Table 3: AIT request parameters
Parameter Description Value
domain-name The Authoritative FQDN obtained
...