ETSI TS 102 606-2 V1.2.1 (2016-12)
Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE); Part 2: Logical Link Control (LLC)
Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE); Part 2: Logical Link Control (LLC)
RTS/JTC-DVB-366
General Information
Standards Content (Sample)
TECHNICAL SPECIFICATION
Digital Video Broadcasting (DVB);
Generic Stream Encapsulation (GSE);
Part 2: Logical Link Control (LLC)
2 ETSI TS 102 606-2 V1.2.1 (2016-12)
Reference
RTS/JTC-DVB-366
Keywords
broadcasting, DVB
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
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 only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
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.
© European Telecommunications Standards Institute 2016.
© European Broadcasting Union 2016.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI TS 102 606-2 V1.2.1 (2016-12)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Introduction . 6
1 Scope . 8
2 References . 8
2.1 Normative references . 8
2.2 Informative references . 9
3 Symbols and abbreviations . 10
3.1 Symbols . 10
3.2 Abbreviations . 10
4 Overview . 11
5 Protocol Elements . 11
5.0 LLC protocol architecture . 11
5.1 Record Structures . 13
5.1.1 Index Structure . 13
5.1.1.0 Index structure syntax and semantics . 13
5.1.1.1 Offset Mechanism . 13
5.1.2 Link Control Data (LCD) records table . 14
5.1.3 Network Control Data (NCD) records table . 15
5.1.3.0 NCD records table syntax and carriage . 15
5.1.3.1 Platform descriptors . 15
5.1.3.2 Target descriptors . 15
5.1.3.3 Operational descriptors . 15
5.2 Descriptors . 16
5.2.1 Descriptor identification and location . 16
5.2.2 Descriptor coding . 17
5.2.2.1 Application system descriptor . 17
5.2.2.1.0 Application system descriptor syntax and semantics. 17
5.2.2.1.1 OMA BCAST info . 17
5.2.2.2 C2 PHY descriptor . 19
5.2.2.2.1 Descriptor syntax and semantics . 19
5.2.2.2.2 Link association descriptor selector fields content . 20
5.2.2.3 DHCPv4 options descriptor . 20
5.2.2.3.0 DHCPv4 options descriptor syntax and semantics . 20
5.2.2.3.1 DHCPv4 options profile . 21
5.2.2.4 DHCPv6 options descriptor . 22
5.2.2.4.0 DHCPv6 options descriptor syntax and semantics . 22
5.2.2.4.1 DHCPv6 options profile . 23
5.2.2.5 IP/MAC generic stream location descriptor . 24
5.2.2.6 IP/MAC link location descriptor . 24
5.2.2.7 IP/MAC stream location descriptor . 24
5.2.2.8 Link association descriptor . 25
5.2.2.9 NGH PHY descriptor . 26
5.2.2.10 ROHC-U descriptor . 29
5.2.2.11 S2 PHY descriptor . 30
5.2.2.12 S2X PHY descriptor . 31
5.2.2.12.1 Descriptor syntax and semantics . 31
5.2.2.12.2 Link association descriptor selector fields content . 32
5.2.2.13 T2 PHY descriptor . 33
5.2.2.14 URI descriptor . 34
5.2.3 Rules for future extensibility of descriptors . 35
ETSI
4 ETSI TS 102 606-2 V1.2.1 (2016-12)
6 Transport in GSE Packets. 36
6.0 Carriage in extension headers . 36
6.1 GSE Header Fields . 36
6.1.1 Start Indicator and End Indicator . 36
6.1.2 Label Type Indicator . 36
6.1.3 Protocol Type . 36
6.1.4 Extension Header Byte . 36
6.1.5 PDU Data Byte . 37
6.2 GSE Table Structure Fields . 37
6.2.0 General . 37
6.2.1 Table ID . 37
6.2.2 Interactive Network ID . 37
6.2.3 Version Number and Current/Next Indicator . 37
6.3 Combining Streams From Different Interactive Networks . 37
7 Deployment Profiles . 38
7.1 Bi-directional interface emulation . 38
7.2 Generic network service profile . 38
7.3 Application system profile . 39
7.3.0 General use of the application system profile . 39
7.3.1 OMA BCAST system profile. 39
Annex A (informative): Examples . 40
A.1 Carriage of LLC data in extension headers . 40
A.2 Finding the size of the last table . 41
A.3 Underlying data model . 42
A.4 Use of Link Control Data . 45
A.4.1 Carriage of Links on different physical layers . 45
A.4.2 Use of physical layer channel aggregation modes . 46
A.4.2.1 DVB-C2 channel bundling . 46
A.4.2.2 DVB-S2X channel bonding and time slicing . 47
Annex B (informative): Change History . 49
History . 50
ETSI
5 ETSI TS 102 606-2 V1.2.1 (2016-12)
Intellectual Property Rights
IPRs essential or potentially essential to the present document 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.
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: +41 22 717 21 11
Fax: +41 22 717 24 81
The Digital Video Broadcasting Project (DVB) is an industry-led consortium of broadcasters, manufacturers, network
operators, software developers, regulatory bodies, content owners and others committed to designing global standards
for the delivery of digital television and data services. DVB fosters market driven solutions that meet the needs and
economic circumstances of broadcast industry stakeholders and consumers. DVB standards cover all aspects of digital
television from transmission through interfacing, conditional access and interactivity for digital video, audio and data.
The consortium came together in 1993 to provide global standardization, interoperability and future proof
specifications.
The present document is part 2 of a multi-part deliverable covering the Digital Video Broadcasting (DVB); Generic
Stream Encapsulation (GSE), as identified below:
Part 1: "Protocol";
Part 2: "Logical Link Control (LLC)";
Part 3: "Robust Header Compression (ROHC) for IP".
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
6 ETSI TS 102 606-2 V1.2.1 (2016-12)
Introduction
As introduced in ETSI TS 102 606-1 [1], the Generic Stream Encapsulation (GSE) protocol is a link layer which
provides multiplexing mechanisms that make it possible for several network protocols (for example IP, IPX, Decnet,
and Appletalk) to coexist within a multipoint network and to be transported over the same network media. GSE is
designed to be deployed across all DVB broadcast bearers which provide a Generic Stream mode.
Figure 1: Role of DVB-GSE across broadcast bearers
This abstraction from the MAC layer allows to provision services on top of network protocols independently of the
underlying physical layer. This is illustrated from a network operator's perspective in Figure 1, and from a protocol
stack perspective in Figure 2.
Figure 2: Protocol layers when using DVB-GSE
As shown in Figure 2, the DVB-GSE link layer hides any MAC layer specifics from the upper layers. It thus enables
receivers to present DVB-GSE streams as regular, LAN-type network interfaces to upper layers. The logical link
control protocol defined in the present document provides the necessary information to receivers to accomplish this.
ETSI
7 ETSI TS 102 606-2 V1.2.1 (2016-12)
On a Point-to-Point Protocol (PPP) link according to IETF RFC 1661 [i.3], two hosts establish a connection on any
point-to-point serial interface (e.g. RS-232), and exchange IP datagrams. The PPP implementation encapsulates this link
as a normal network interface, so that applications can use it as if it were a regular LAN interface. To achieve this, a
Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection, and a family of
Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols is defined in
IETF RFC 1661 [i.3]. When the connection establishment begins, the two hosts first use the LCP to negotiate the
configuration parameters (e.g. link speed) of the serial data link. After this is completed, the two hosts use the
appropriate NCPs to negotiate the configuration of the network interface (e.g. use of IPv4 or IPv6, IP addresses to use),
and thus conclude the connection establishment phase. After this, the hosts present new LAN-type network interfaces to
applications running on them.
The LLC protocol for DVB-GSE adopts the same partitioning of information. One set of information is needed to
enable the DVB-GSE layer to configure the underlying MAC and physical layer devices. This first set of information is
referred to as Link Control Data (LCD) in the present document. A second set of information is needed to configure the
network interfaces which represent the DVB-GSE streams and make them available for the upper layers. This second
set of information is referred to as Network Control Data (NCD) in the present document.
Figure 3: Application programming model of DVB-GSE with LLC
Once these network interfaces have been made available to the upper layers (see Figure 3), the properties of the MAC
and physical layers are no longer exposed to upper layers, and applications can act on these interfaces like on any other
network interface. Use of the tunnelling mechanism defined in IETF RFC 3077 [11] in combination with a return
channel allows for the interfaces to be used for reading and writing.
ETSI
8 ETSI TS 102 606-2 V1.2.1 (2016-12)
1 Scope
The present document specifies a Logical Link Control (LLC) method to be used on DVB streams where the Generic
Stream Encapsulation (GSE) [1] protocol is used as the link layer.
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
http://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 606-1: "Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE);
Part 1: Protocol".
[2] ETSI TS 102 606-3: "Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE);
Part 3: Robust Header Compression (ROHC) for IP".
[3] ETSI EN 301 192: "Digital Video Broadcasting (DVB); DVB specification for data broadcasting".
[4] ETSI EN 301 545-2: "Digital Video Broadcasting (DVB); Second Generation DVB Interactive
Satellite System (DVB-RCS2); Part 2: Lower Layers for Satellite standard".
[5] ETSI EN 300 468: "Digital Video Broadcasting (DVB); Specification for Service Information (SI)
in DVB systems".
[6] ETSI TS 101 162: "Digital Video Broadcasting (DVB); Allocation of identifiers and codes for
Digital Video Broadcasting (DVB) systems".
[7] IETF RFC 2131: "Dynamic Host Configuration Protocol".
[8] IETF RFC 2132: "DHCP Options and BOOTP Vendor Extensions".
NOTE: A complete list of all DHCP options defined by various sources is available from IANA at
http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xml.
[9] IETF RFC 5795: "The Robust Header Compression (ROHC) Framework".
[10] IETF RFC 3095: "Robust Header Compression (ROHC): Framework and four profiles: RTP,
UDP, ESP, and uncompressed".
[11] IETF RFC 3077: "A Link-Layer Tunneling Mechanism for Unidirectional Links".
[12] ETSI EN 302 769: "Digital Video Broadcasting (DVB); Frame structure channel coding and
modulation for a second generation digital transmission system for cable systems (DVB-C2)".
[13] ETSI EN 302 755: "Digital Video Broadcasting (DVB); Frame structure channel coding and
modulation for a second generation digital terrestrial television broadcasting system (DVB-T2)".
[14] ETSI EN 302 307-1: "Digital Video Broadcasting (DVB); Second generation framing structure,
channel coding and modulation systems for Broadcasting, Interactive Services, News Gathering
and other broadband satellite applications; Part 1: DVB-S2".
ETSI
9 ETSI TS 102 606-2 V1.2.1 (2016-12)
[15] DVB BlueBook A160: "Digital Video Broadcasting (DVB); Next Generation broadcasting system
to Handheld, physical layer specification (DVB-NGH)".
[16] IETF RFC 3986: "Uniform Resource Identifier (URI): Generic Syntax".
[17] IANA: "Unidirectional Lightweight Encapsulation (ULE) Next-Header Registry".
NOTE: See http://www.iana.org/assignments/ule-next-headers/ule-next-headers.xml.
[18] IETF RFC 4776: "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for
Civic Addresses Configuration Information".
[19] IETF RFC 4833: "Timezone Options for DHCP".
[20] IETF RFC 3011: "The IPv4 Subnet Selection Option for DHCP".
[21] IETF RFC 3442: "The Classless Static Route Option for Dynamic Host Configuration Protocol
(DHCP) version 4".
[22] IETF RFC 3495: "Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client
Configuration".
[23] IETF RFC 6225: "Dynamic Host Configuration Protocol Options for Coordinate-Based Location
Configuration Information".
[24] IETF RFC 3315: "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)".
[25] IETF RFC 3633: "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP)
version 6".
[26] IETF RFC 6603: "Prefix Exclude Option for DHCPv6-based Prefix Delegation".
[27] IETF RFC 3646: "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6
(DHCPv6)".
[28] IETF RFC 4326: "Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP
Datagrams over an MPEG-2 Transport Stream (TS)".
[29] OMA BCAST DVB-NGH Adaptation: OMA-TS-BCAST-DVB-NGH-Adaptation: "BCAST
Distribution System Adaptation - over DVB-NGH".
NOTE: See http://www.openmobilealliance.org.
[30] ETSI EN 302 307-2: "Digital Video Broadcasting (DVB); Second generation framing structure,
channel coding and modulation systems for Broadcasting, Interactive Services, News Gathering
and other broadband satellite applications; Part 2: DVB-S2 Extensions (DVB-S2X)".
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 102 771: "Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE)
implementation guidelines".
[i.2] ETSI TS 102 006: "Digital Video Broadcasting (DVB); Specification for System Software Update
in DVB Systems".
ETSI
10 ETSI TS 102 606-2 V1.2.1 (2016-12)
[i.3] IETF RFC 1661: "The Point-to-Point Protocol (PPP)".
NOTE: The assigned Next-Header values are published at http://www.iana.org/assignments/ule-next-headers/ule-
next-headers.xml.
[i.4] IETF RFC 3736: "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6".
[i.5] IEEE 1003.1™-2008: "Standard for Information Technology - Portable Operating System
Interface (POSIX®)".
3 Symbols and abbreviations
3.1 Symbols
For the purposes of the present document, the symbols given in ETSI TS 102 606-1 [1] and the following apply:
123 A number without prefix denotes a decimal integer (base 10)
0x123 A number with a "0x" prefix denotes a hexadecimal integer (base 16)
0123 A number with a "0" prefix denotes an octal integer (base 8)
(1010) A number enclosed in parentheses, and with a number suffix denotes an integer to the base
indicated by the suffix.
EXAMPLE: The representations for the number one-hundred and twenty three are: 123 to the base 10
(decimal), 0x7B to the base 16 (hexadecimal), 0173 to the base 8 (octal), and (1111011) to the
base 2 (binary).
NOTE: For binary and hexadecimal representations it may sometimes be convenient to group digits, and fill in
leading zeroes to accommodate common word sizes. The number one-hundred and twenty three can
, or
hence for example also be represented as 0x007B, 0x0000 007B, (0111 1011)2
(0000 0000 0111 1011) .
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI TS 102 606-1 [1] and the following apply:
BCAST OMA Mobile Broadcast Services
GSE Generic Stream Encapsulation
IANA Internet Assigned Numbers Authority
NOTE: See http://www.iana.org/.
IP Internet Protocol
ISP Internet Service Provider
LAN Local Area Network
LCD Link Control Data
LLC Logical Link Control
MAC Media Access Control
NCD Network Control Data
NSAP Network Service Access Point
OMA Open Mobile Alliance™
NOTE: See http://www.openmobilealliance.org/.
PLP Physical Layer Pipe
NOTE: See ETSI EN 302 755 [13], ETSI EN 302 769 [12], and DVB BlueBook A160 [15].
SNPA SubNetwork Point of Attachment
ETSI
11 ETSI TS 102 606-2 V1.2.1 (2016-12)
4 Overview
To enable receivers to process LLC data in an efficient way, it is sent in GSE packets with a specific protocol type (see
clause 6.1.3). This allows for very lightweight processing in the DVB-GSE layer: packets with the protocol type for
LLC are processed within the GSE layer, all other packets are forwarded to higher layers.
The two sets of LLC data, the LCD for configuring the MAC and physical layer devices, and the NCD for configuring
the network interfaces are transmitted in tables, which bear a table_id value for demultiplexing them. These LLC tables
are carried in an extension header of LLC GSE packets. To provide faster access and support local caching
mechanisms, an index structure is conveyed in an extension header. This scheme is shown in Figure 4.
Figure 4: Basic scheme of LLC transport
To allow for large configurations, the LLC tables in the payload may of course be fragmented as defined in part 1 [1].
The basic fragmentation scheme is shown in Figure 5.
NOTE: For a definition of Start and End packet, see clause 4.2.3 of part 1 [1].
Figure 5: Basic scheme of fragmenting LLC data
5 Protocol Elements
5.0 LLC protocol architecture
This clause defines the data structures and the associated semantics that constitute the GSE LLC protocol. For
information on how these data structures are conveyed, see clause 6.
ETSI
12 ETSI TS 102 606-2 V1.2.1 (2016-12)
The present document defines two table structures (see Figure 6):
• The first table structure (the LCD) conveys records describing the physical layer parameters in use on the
broadcast links, and associates the data channels in the broadcast links with stream identifiers.
• The second table structure (the NCD) conveys records describing the network protocol configurations in use
on the network interfaces, and associates the network interfaces with stream identifiers.
The concept of the stream identifier used in both record tables allows to associate network interfaces with broadcast
links as shown in Figure 6. This partitioning of the information in link-related and network-related data allows for
flexible end-to-end system management, where different entities can manage different parts or aspects of the operations.
These entities can generate the LLC records describing the applied configurations independently. The use of the stream
identifiers will only need to be coordinated when the set of streams changes, i.e. streams are added or removed from the
system. For typical changes of operational parameters, e.g. a modulation parameter change on the broadcast physical
layer, or the reallocation of a multicast group address to a different network interface, only the corresponding records
table needs to be updated, while the other table may remain unchanged.
Figure 6: Overview of LLC record structures
For the sake of clarity and brevity, the syntax definitions in the present document make use of a template for descriptor
loops. For the purposes of the present document, wherever a syntax element called "descriptor_loop()" - optionally
preceded by a prefix - occurs, it shall be encoded according to Table 1.
Table 1: Descriptor loop template structure
Syntax No. of Bits Mnemonic Applicable as of
protocol version
descriptors() {
descriptors_length
16 uimsbf 0
for (i=0;i
descriptor()
variable bslbf 0
}
}
Semantics for the descriptor loop template:
descriptors_length: This 16-bit field specifies the number of bytes following for descriptors.
descriptor(): This variable size field conveys descriptors as applicable.
NOTE: The type and size of each of the descriptors can be inferred from its tag value and length field.
ETSI
13 ETSI TS 102 606-2 V1.2.1 (2016-12)
5.1 Record Structures
5.1.1 Index Structure
5.1.1.0 Index structure syntax and semantics
The LLC index structure provides information on the presence and location of LLC tables in the extension header, and
on the version of each table to allow for timely detection and processing of any updates by receivers.
Table 2: Syntax of the Index Structure
Syntax No. of Bits Mnemonic Applicable as of
protocol version
LLC_index() {
protocol_version
8 uimsbf 1
num_table_entries
8 uimsbf 0
for (i=0;i
table_id
8 uimsbf 0
reserved
2 bslbf 0
version
5 uimsbf 0
current_next_indicator
1 bslbf 0
offset
32 uimsbf 0
}
}
Semantics of the LLC index:
protocol_version: This 8-bit field that indicates the version of the LLC protocol used. It shall be encoded according to
Table 3.
Table 3: Protocol version coding
protocol_version Description
0 version 1.1.1 of the present document
1 version 1.2.1 of the present document
1 to 255 reserved for future use
NOTE: This field was added with version 1.2.1 of the present document. Since it was inserted at the beginning of
the index data structure, a parser implementing ETSI TS 102 606 V1.1.1 will not be able to process data
encoded according to version 1.2.1 or later of the present document.
table_id, version, and current_next_indicator: These fields shall be set according to the corresponding fields in the
gse_table_structure() being described by the instance of the loop.
offset: This 32-bit field indicates the offset of the first byte of the LLC table being described in the respective instance
of the loop. It shall be encoded according to clause 5.1.1.1.
The LLC index shall correctly describe all the tables for the interactive network present in the stream up to (and
including) the next GSE end packet carrying LLC data (see also Figure 7).
5.1.1.1 Offset Mechanism
For the calculation of the offset field in the LLC index structure, it is assumed that the index structure itself, and all
LLC table structures are assembled in a theoretical buffer in the order they have been received. This is illustrated in
Figure 7.
ETSI
14 ETSI TS 102 606-2 V1.2.1 (2016-12)
NOTE: For a definition of Start, Intermediate, and End packet, see clause 4.2.3 of part 1 [1].
Figure 7: Offset calculation scheme
Given this model, the value of the offset field shall be calculated as the number of bytes between the last byte of the
index structure, and the first byte of the gse_table_structure() that is referenced. Hence, the offset of the first table (at
index zero) shall always be set to zero as it immediately follows the index.
The offset of a given LLC table at index position n may hence be calculated as:
⎧
0 for n = 0
offset(n) =
⎨
offset(n − 1) + sizeof (table ) for n ≥ 1
⎩
n−1
The length of a given table can be calculated by subtracting the table's offset from the offset of the following table.
Except for the last table, as in this case there is no following table. The end, and therefore the length of the last table can
be determined by calculating the last table's effective offset relative to the end of the PDU. The end of the PDU can be
inferred from the Total_Length field in the GSE header.
NOTE: For an example of finding the size of the last table in the index, see clause A.2.
5.1.2 Link Control Data (LCD) records table
The Link Control Data (LCD) provides information about the physical layer being used to transmit the link data
streams.
It shall be carried in the table_content_byte field of a gse_table_structure () as defined in clause 6.2.
NOTE: For a complete example of the us of the gse_table_structure(), see Figure A.1.
Table 4: Syntax of the LCD
Syntax No. of Bits Mnemonic Applicable as of
protocol version
LCD() {
PHY_descriptors()
variable bslbf 0
number_of_links
16 uimsbf 0
for (i=0;i
link_id
16 uimsbf 0
link_association_descriptors()
variable bslbf 0
}
}
ETSI
15 ETSI TS 102 606-2 V1.2.1 (2016-12)
Semantics of the LCD records table:
PHY_descriptors(): This variable size field describes the broadcast modulation systems associated with the
interactive_network_id (see clause 6.2.2).
number_of_links: This 16-bit field indicates the number of link records following.
link_id: This 16-bit field uniquely identifies the physical link within the interactive_network_id (see clause 6.2.2).
link_association_descriptors(): This variable size field conveys link association descriptors according to clause 5.2.
5.1.3 Network Control Data (NCD) records table
5.1.3.0 NCD records table syntax and carriage
The Network Control Data provides information describing the Network Service Access Points (NSAP) which are
provided by the network service. This information may be used by receivers to configure network interfaces as Sub-
Network Points of Attachment (SNPA).
NOTE: The latter typically involves populating routing tables.
It shall be carried in the table_content_byte field of a gse_table_structure () as defined in clause 6.2.
NOTE: For a complete example of the us of the gse_table_structure(), see Figure A.1.
Table 5: Syntax of the NCD
Syntax No. of Bits Mnemonic Applicable as of
protocol version
NCD() {
platform_descriptors()
variable bslbf 0
for (i=0;i
target_descriptors()
variable bslbf 0
operational_descriptors()
variable bslbf 0
}
}
5.1.3.1 Platform descriptors
The platform_descriptors() carries information about the IP/MAC platform. It shall be encoded as a descriptor loop
according to Table 1, and shall convey descriptors as defined in clause 5.2.
5.1.3.2 Target descriptors
The target_descriptors() discriminates between individual devices. It shall be encoded as a descriptor loop according to
Table 1, and shall convey descriptors as defined in clause 5.2.
This descriptor loop may contain target IP/MAC address, smartcard or private, etc. descriptors. This descriptor loop
forms a list of all target devices to be addressed and the operational loop applied. If this descriptor loop is empty, the
operational loop applies to all devices.
A receiver device not recognizing a target descriptor (new or unknown target descriptor) shall assume this target
descriptor does not target this receiver device.
5.1.3.3 Operational descriptors
The operational_descriptors() contains action, informational, and operational descriptors, which apply only to those
target devices that meet the requirements of the target descriptor loop. It shall be encoded as a descriptor loop according
to Table 1, and shall convey descriptors as defined in clause 5.2.
ETSI
16 ETSI TS 102 606-2 V1.2.1 (2016-12)
5.2 Descriptors
5.2.1 Descriptor identification and location
Table 6 lists the descriptors declared or defined within the present document, giving the descriptor_tag values and the
intended placement within the LCD and the NCD. This does not imply that their use in other tables is restricted. Table 6
further partitions the descriptor_tag name space, and those descriptor_tag values within each range, which are not being
assigned semantics in Table 6, shall be deemed to be reserved for future use.
Table 6: Identification and location of descriptors in LLC records
LCD NCD Loop Applicable as
Descriptor
loop of protocol
Name Note
tag
version
Descriptors defined in DVB-DATA [3] and 0x00 to 0x3F
DVB-SSU [i.2]
target_smartcard_descriptor 0x06 * See ETSI 0
EN 301 192 [3]
target_MAC_address_descriptor 0x07 * See ETSI 0
EN 301 192 [3]
target_serial_number_descriptor 0x08 * See ETSI 0
EN 301 192 [3]
target_IP_address_descriptor 0x09 * See ETSI 0
EN 301 192 [3]
target_IPv6_address_descriptor 0x0A * See ETSI 0
EN 301 192 [3]
IP/MAC_platform_name_descriptor 0x0C * See ETSI 0
EN 301 192 [3]
IP/MAC_platform_provider_name_descriptor 0x0D * See ETSI 0
EN 301 192 [3]
target_MAC_address_range_descriptor 0x0E * See ETSI 0
EN 301 192 [3]
target_IP_slash_descriptor 0x0F * See ETSI 0
EN 301 192 [3]
target_IP_source_slash_descriptor 0x10 * See ETSI 0
EN 301 192 [3]
target_IPv6_slash_descriptor 0x11 * See ETSI 0
EN 301 192 [3]
target_IPv6_source_slash_descriptor 0x12 * See ETSI 0
EN 301 192 [3]
IP/MAC_generic_stream_location_descriptor 0x15 * See ETSI 0
EN 301 192 [3]
IP/MAC_stream_location_descriptor 0x13 * See ETSI 0
EN 301 192 [3]
Descriptors defined in the present document 0x40 to 0xFF
S2_PHY_descriptor 0x40 * clause 5.2.2.11 0
T2_PHY_descriptor 0x41 * clause 5.2.2.13 0
C2_PHY_descriptor 0x42 * clause 5.2.2.2 0
NGH_PHY_descriptor 0x43 * clause 5.2.2.9 0
link_association_descriptor 0x44 * clause 5.2.2.8 0
application_system_desciptor 0x50 * * clause 5.2.2.1 0
DHCPv4_options_descriptor 0x51 * * clause 5.2.2.3 0
DHCPv6_options_descriptor 0x52 * * clause 5.2.2.4 0
ROHC-U_descriptor 0x53 * * clause 5.2.2.10 0
URI_descriptor 0x54 * clause 5.2.2.14 0
IP/MAC_link_location_descriptor 0x55 * clause 5.2.2.6 0
S2X_PHY_descriptor 0x56 * clause 5.2.2.12 1
ETSI
P
H
L
i
P
l
T
a
O
p
17 ETSI TS 102 606-2 V1.2.1 (2016-12)
5.2.2 Descriptor coding
5.2.2.1 Application system descriptor
5.2.2.1.0 Application system descriptor syntax and semantics
The application system descriptor identifies the application system used in the IP/MAC stream. This information can
assist receivers to optimize the service discovery process.
The following rules shall apply:
a) Transmission of this descriptor is optional.
b) More than one instance is allowed in a loop.
Table 7: Application system descriptor
Syntax No. of Bits Mnemonic Applicable as of
protocol version
application_system_desciptor() {
descriptor_tag
8 uimsbf 0
descriptor_length
8 uimsbf 0
application_system_id
16 uimsbf 0
selector_length
8 uimsbf 0
if (application_system_id == OMA_BCAST) {
OMA_BCAST_info()
} else {
for (i=0;i
selector_byte
8 bslbf 0
}
}
Semantics of the appli
...








Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...