SIST-TP ETR 211 E2:2005

SLOVENSKI STANDARD
01-november-2005
Digitalna videoradiodifuzija (DVB) – Smernice za uvedbo in uporabo servisnih
informacij (SI)
Digital Video Broadcasting (DVB); Guidelines on implementation and usage of Service
Information (SI)
Ta slovenski standard je istoveten z: ETR 211 Edition 2
ICS:
33.170 Televizijska in radijska Television and radio
difuzija broadcasting
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

ETSI ETR 211
TECHNICAL August 1997
REPORT Second Edition
Source: EBU/CENELEC/ETSI JTC Reference: RTR/JTC-00DVB-40
ICS: 33.020
Key words: DVB, broadcasting, digital, video, MPEG, TV
European Broadcasting Union Union Européenne de Radio-Télévision
Digital Video Broadcasting (DVB);
Guidelines on implementation and usage of
Service Information (SI)
ETSI
European Telecommunications Standards Institute
ETSI Secretariat
Postal address: F-06921 Sophia Antipolis CEDEX - FRANCE
Office address: 650 Route des Lucioles - Sophia Antipolis - Valbonne - FRANCE
X.400: c=fr, a=atlas, p=etsi, s=secretariat - Internet: secretariat@etsi.fr
Tel.: +33 4 92 94 42 00 - Fax: +33 4 93 65 47 16
Copyright Notification:
No part may be reproduced except as authorized by written permission. The copyright and the
foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 1997.
© European Broadcasting Union 1997.
All rights reserved.
Page 2
ETR 211: August 1997
Whilst every care has been taken in the preparation and publication of this document, errors in content,
typographical or otherwise, may occur. If you have comments concerning its accuracy, please write to
"ETSI Editing and Committee Support Dept." at the address shown on the title page.

Page 3
ETR 211: August 1997
Contents
Foreword .5
1 Scope .7
2 References.7
3 Definitions and abbreviations .8
3.1 Definitions .8
3.2 Abbreviations .9
4 Rules of operation .9
4.1 Service Information (SI) table information .10
4.1.1 Network Information Table (NIT) information.11
4.1.2 Bouquet Association Table (BAT) information .12
4.1.3 Service Description Table (SDT) information.12
4.1.4 Event Information Table (EIT) information .13
4.1.4.1 EIT Present/Following information.13
4.1.4.2 EIT Schedule information .14
4.1.4.2.1 EIT Schedule structure .14
4.1.4.2.2 EIT scrambling.15
4.1.5 Time and Date Table (TDT) .15
4.1.6 Time Offset Table (TOT).15
4.1.7 Running Status Table (RST) .16
4.1.8 Stuffing Table (ST) .16
4.1.9 Table update mechanism.16
4.2 SI descriptor allocation and usage.17
4.2.1 Descriptors of the Network Information Table (NIT) .17
4.2.1.1 First descriptor loop .17
4.2.1.1.1 Linkage descriptor .17
4.2.1.1.2 Multilingual network name descriptor .17
4.2.1.1.3 Network name descriptor.17
4.2.1.2 Second descriptor loop.17
4.2.1.2.1 Delivery system descriptors.18
4.2.1.2.2 Service list descriptor.18
4.2.1.2.3 Frequency list descriptor.18
4.2.2 Descriptors of the Bouquet Association Table (BAT).18
4.2.2.1 First descriptor loop .18
4.2.2.1.1 Bouquet name descriptor.18
4.2.2.1.2 CA identifier descriptor .18
4.2.2.1.3 Country availability descriptor .19
4.2.2.1.4 Linkage descriptor .19
4.2.2.1.5 Multilingual bouquet name descriptor .19
4.2.2.2 Second descriptor loop.19
4.2.2.2.1 Service list descriptor.19
4.2.3 Descriptors of the Service Description Table (SDT) .20
4.2.3.1 Bouquet name descriptor .20
4.2.3.2 CA identifier descriptor .20
4.2.3.3 Country availability descriptor.20
4.2.3.4 Data_broadcast_descriptor .20
4.2.3.5 Linkage descriptor .21
4.2.3.6 Mosaic descriptor .21
4.2.3.7 Multilingual service descriptor.21
4.2.3.8 NVOD reference descriptor .21
4.2.3.9 Service descriptor.22
4.2.3.10 Telephone descriptor.22
4.2.3.11 Time shifted service descriptor.22
4.2.4 Descriptors of the Event Information Table (EIT).22
4.2.4.1 Component descriptor .22
4.2.4.2 Content descriptor .23

Page 4
ETR 211: August 1997
4.2.4.3 Data_broadcast_descriptor. 23
4.2.4.4 Extended event descriptor . 23
4.2.4.5 Linkage descriptor. 23
4.2.4.6 Multilingual component descriptor . 23
4.2.4.7 Parental rating descriptor. 23
4.2.4.8 Short event descriptor. 24
4.2.4.9 Telephone descriptor . 24
4.2.4.10 Time shifted event descriptor. 24
4.2.5 Descriptors of the Time Offset Table (TOT). 24
4.2.5.1 Local time offset descriptor. 24
4.2.6 Descriptors of the Program Map Table (PMT) . 25
4.2.6.1 Mosaic descriptor. 25
4.2.6.2 Service move descriptor . 25
4.2.6.3 Stream identifier descriptor. 25
4.2.6.4 Teletext descriptor . 25
4.2.7 Other descriptors . 25
4.2.7.1 Private data specifier descriptor. 25
4.2.7.2 Stuffing descriptor . 25
4.2.7.3 Data_broadcast_descriptor. 26
4.2.8 ISO 13818-1 descriptors. 26
4.2.9 Unknown descriptors . 26
4.3 Program Specific Information (PSI) and DVB SI operational interaction states. 26
4.4 Minimum repetition rates. 27
4.4.1 Satellite and cable delivery systems. 27
4.4.2 Terrestrial delivery systems . 28
4.5 Terrestrial systems. 28
4.5.1 Terms used within terrestrial systems . 28
4.5.2 The use of alternative frequencies for multiplexes . 29
4.5.3 Regional or local services. 30
4.6 Text string formatting . 31
4.6.1 Use of control codes in names . 31
4.6.2 Use of control codes in text . 32
5 Applications . 32
5.1 NVOD services. 32
5.2 Mosaic services. 34
5.2.1 General considerations. 34
5.2.2 Relationship between mosaic service and SI/PSI Tables. 35
5.3 Transitions at broadcast delivery media boundaries. 37
5.3.1 Seamless transitions. 37
5.3.2 Non-seamless transitions without re-multiplexing . 37
5.3.3 Transitions with re-multiplexing . 38
6 Storage media . 38
6.1 Program Association Table (PAT). 38
6.2 Program Map Table (PMT). 38
6.3 SI tables (NIT, SDT, EIT, BAT, RST, TDT, TOT). 38
6.4 Selection Information Table (SIT). 38
6.5 Discontinuity Information Table (DIT) . 39
Annex A (informative): Inter-operation with ATSC Systems. 40
A.1 PIDs. 40
A.2 Table Ids. 40
A.3 Descriptor tags. 40
Annex B (informative): Bibliography . 41
History. 42

Page 5
ETR 211: August 1997
Foreword
This ETSI Technical Report (ETR) has been produced under the authority of the Joint Technical
Committee (JTC) of the European Broadcasting Union (EBU), Comité Européen de Normalisation
ELECtrotechnique (CENELEC) and the European Telecommunications Standards Institute (ETSI).
This ETR is based on the DVB document TM1324, rev. X / 162 rev. 13, and it may be converted into a
standard after market feedback. For this purpose, the wording of a standard (normative elements) rather
than of a technical report (informative elements) has been used.
ETRs are informative documents resulting from ETSI studies which are not appropriate for
European Telecommunication Standard (ETS) or Interim European Telecommunication Standard (I-ETS)
status. An ETR may be used to publish material which is either of an informative nature, relating to the
use or the application of ETSs or I-ETSs, or which is immature and not yet suitable for formal adoption as
an ETS or an I-ETS.
NOTE: The EBU/ETSI JTC was established in 1990 to co-ordinate the drafting of standards in
the specific field of broadcasting and related fields. Since 1995 the JTC 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
Case Postale 67
CH-1218 GRAND SACONNEX (Geneva)
Switzerland
Tel: +41 22 717 21 11
Fax: +41 22 717 24 81
Digital Video Broadcasting (DVB) Project
Founded in September 1993, the DVB Project is a market-led consortium of public and private sector
organizations in the television industry. Its aim is to establish the framework for the introduction of
MPEG-2 based digital television services. Now comprising over 200 organizations from more than
25 countries around the world, DVB fosters market-led systems, which meet the real needs, and
economic circumstances, of the consumer electronics and the broadcast industry.

Page 6
ETR 211: August 1997
Blank page
Page 7
ETR 211: August 1997
1 Scope
The present document provides implementation guidelines for the use and implementation of the DVB
Service Information (SI) coding in a DVB digital TV environment including satellite- cable- and terrestrial
networks.
The guidelines are intended to be highly recommended rules for the usage of the DVB SI syntax specified
in EN 300 468 [1]. As such, they facilitate the efficient and reliable implementation of basic user-interaction
functions in Integrated Receiver-Decoders (IRD).
The rules apply to broadcasters, network operators as well as manufacturers.
The rules are specified in the form of constraints on the DVB SI streams or in terms of intended
interpretation by IRDs.
The specification of these functions in no way prohibits IRD manufacturers from including additional
features, and should not be interpreted as stipulating any form of upper limit to the performance.
The guidelines do not cover features related to user-interface details or advanced Electronic Program
Guides (EPG). Such issues are left to the marketplace.
NOTE: It is highly recommended that the IRD should be designed to allow for future
compatible extensions to the DVB SI syntax. All the fields "reserved" (for ISO),
"reserved_future_use" (for ETSI), and "user defined" in the EN 300 468 [1] should be
ignored by IRDs designed not to make use of them. The "reserved" and
"reserved_future_use" fields may be specified in the future by the respective bodies,
whereas the "user defined" fields will not be standardized.
The present document uses the terminology defined in EN 300 468 [1] and should be read in conjunction
with that ETS.
2 References
For the purposes of the present document, the following references apply:
[1] EN 300 468: "Digital Video Broadcasting (DVB); Specification for Service
Information (SI) in DVB systems".
[2] ISO/IEC 13818-1: "Information Technology - Generic Coding of Moving Pictures
and Associated Audio Recommendation H.222.0 (systems)".
[3] EN 300 472: "Digital Video Broadcasting (DVB); Specification for conveying
ITU-R System B Teletext in DVB bitstreams".
[4] ETR 162: "Digital Video Broadcasting (DVB); Allocation of Service Information
(SI) codes for DVB systems".
[5] prEN 301 192: "Digital Video Broadcasting (DVB); Specification for data
broadcasting".
[6] prTR 101 202: "Digital Video Broadcasting (DVB); Guidelines for the
implementation and usage of the DVB data broadcasting specification".

Page 8
ETR 211: August 1997
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following definitions apply:
bouquet: A collection of services marketed as a single entity.
broadcaster (SERVICE Provider): An organization which assembles a sequence of events or
programmes to be delivered to the viewer based upon a schedule.
component (ELEMENTARY Stream): One or more entities which together make up an event, e.g. video,
audio, Teletext.
Conditional Access (CA) system: A system to control subscriber access to services, programmes and
events e.g. Videoguard, Eurocrypt.
delivery system: The physical medium by which one or more multiplexes are transmitted e.g. satellite
system, wide-band coaxial cable, fibre optics, terrestrial channel of one emitting point.
event: A grouping of elementary broadcast data streams with a defined start and end time belonging to a
common service, e.g. first half of a football match, News Flash, first part of an entertainment show.
MPEG-2: Refers to the standard ISO/IEC 13818. Systems coding is defined in part 1. Video coding is
defined in part 2. Audio coding is defined in part 3.
multiplex: A stream of all the digital data carrying one or more services within a single physical channel.
network: A collection of MPEG-2 TS multiplexes transmitted on a single delivery system, e.g. all digital
channels on a specific cable system.
section: A section is a syntactic structure used for mapping all service information into
ISO/IEC 13818-1 [2] Transport Stream (TS) packets.
programme: A concatenation of one or more events under the control of a broadcaster e.g. news show,
entertainment show.
service: A sequence of programmes under the control of a broadcaster which can be broadcast as part of
a schedule.
Service Information (SI): Digital data describing the delivery system, content and scheduling/timing of
broadcast data streams etc. It includes MPEG-2 Program Specific Information (PSI) together with
independently defined extensions.
sub-table: A sub-table is comprised of a number of sections with the same value of table_id,
table_id_extension and version_number. The table_id_extension field is equivalent to the fourth and
fifth byte of a section when the section_syntax_indicator is set to a value of "1".
table: A table is comprised of a number of sections with the same value of table_id.
Transport Stream (TS): A data structure defined in ISO 13818-1 [2]. It is the basis of the DVB standards.

Page 9
ETR 211: August 1997
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ATSC Advanced Television Systems Committee of the USA
BAT Bouquet Association Table
bslbf bit string, left bit first
CA Conditional Access
DIT Discontinuity Information Table
DVB Digital Video Broadcasting
EIT Event Information Table
EPG Electronic Program Guide
IRD Integrated Receiver-Decoder
MFN Multi-Frequency Network
MJD Modified Julian Date
MPEG Moving Pictures Expert Group
NIT Network Information Table
NVOD Near Video On Demand
PAT Program Association Table
PCR_PID Program Clock Reference_Packet IDentifier
PID Packet IDentifier
PMT Program Map Table
PSI Program Specific Information
QAM Quadrature Amplitude Modulation
QPSK Quadrature Phase Shift Keying
RST Running Status Table
SDT Service Description Table
SFN Single Frequency Network
SHY Soft HYphen
SI Service Information
SIT Selection Information Table
SMATV Satellite Master Antenna TeleVision
ST Stuffing Table
TDT Time and Date Table
TOT Time Offset Table
TS Transport Stream
uimsbf unsigned integer, most significant bit first
UTC Universal Time Coordinated
VCR Video Cassette Recorder
4 Rules of operation
This clause contains some recommendations on the usage of the Digital Video Broadcasting (DVB)
Service Information (SI) syntax.

Page 10
ETR 211: August 1997
4.1 Service Information (SI) table information
Figure 1: SI table information

Page 11
ETR 211: August 1997
4.1.1 Network Information Table (NIT) information
The Network Information Table (NIT) provides a grouping of Transport Streams (TSs) and the relevant
tuning information. The NIT could be used during set-up procedures of the IRD and the relevant tuning
information may be stored in non-volatile memory. The NIT also could be used to signal changes of tuning
information. The following rules apply to the NIT:
a) transmission of the NIT is mandatory for the actual delivery system;
b) the NIT describing the actual delivery system is valid if and only if it contains applicable delivery
system descriptors for the actual delivery system. This rule specifies the conditions under which the
NIT contains valid information. At some transitions of broadcast delivery system boundaries, the
NIT carried in a TS is allowed to describe an earlier network in the broadcast chain. A different
mechanism has to be selected by the IRD to obtain the relevant tuning information for the actual
delivery system. If a satellite IRD receives a satellite delivery system descriptor for the actual
delivery system, then it is valid. If a cable IRD receives a cable delivery system descriptor for the
actual delivery system, then it is valid. If a cable IRD receives a satellite delivery system descriptor
for the actual delivery system, then it is assumed to be invalid for the cable IRD;
c) if a valid NIT for the actual delivery system is present in the SI bit stream then it shall list all TSs of
the actual delivery system;
d) the SI stream shall have at least 8 TS packets per 10 seconds carrying NIT data or NULL packets.
This rule simplifies the replacement of the NIT at broadcast delivery system boundaries. With the
simple replacement mechanism, local frequency control is possible with relatively low cost
equipment.
The SI uses two labels related to the concept of a delivery system, namely the network_id and the
original_network_id. The latter is intended to support the unique identification of a service, contained in a
TS, even if that TS has been transferred to another delivery system than the delivery system where it
originated. A TS can be uniquely referenced through the path original_network_id/transport_stream_id.
A service can be uniquely referenced through the path
original_network_id/transport_stream_id/service_id. The network_id, thus, is not part of this path.
In addition each service_id shall be unique within each original_network_id. When a service (contained
inside a TS) is transferred to another delivery system, only the network_id changes, whereas the
original_network_id remains unaffected.
By way of example, consider the following, where two services (A and B), which originate in two different
delivery systems and happen to have the same service_ids and transport_stream_ids, are transferred to a
new delivery system.
In the example, the two services are located on different TSs (X and Y) in the new network. If the two
services were being combined onto the same TS, then it would be necessary to modify the identification of
the services, since the same service_id value cannot be assigned to more than one service within a TS,
and only one original_network_id can be associated with a TS (see subclause 5.3 for further discussion on
transitions at broadcast delivery media boundaries).

Page 12
ETR 211: August 1997
Figure 2: Transfer to a new delivery system
4.1.2 Bouquet Association Table (BAT) information
The BAT provides a grouping of services which serves as one basis on which an IRD presents the
available services to a user. Transmission of the BAT is optional. The following rule improves the
consistency in the SI bit streams and simplifies the processing in the IRDs.
The SI bit stream shall list in each BAT sub-table all the services belonging to that bouquet.
NOTE: One service may belong to more than one bouquet. This rule creates consistency
across the different TSs which are accessible to the IRD.
If it is intended for the IRD to present service information to the user grouped in bouquets, then it would be
beneficial to ensure that every service is listed in one or more bouquets, or some services will be omitted
from this method of presentation. A bouquet may group together services from more than one TS, which
could even be carried in different networks. The IRD's access to information on all the services of a
bouquet would be facilitated if all the services referred to in the BAT were listed in the Service Description
Table (SDT). Similarly, the IRD's access to these services is facilitated if NIT information is given for all
TSs in which services of the bouquet occupy capacity.
4.1.3 Service Description Table (SDT) information
The SDT is used to list the names and other parameters of the services within TSs. For each TS a
separate SDT sub-table exists. The following rules apply in order to improve the acquisition of services:
- the transmission of the SDT for the actual TS is mandatory;
- the SI bit stream shall list in the SDT of a particular TS at least all the services of that TS.
In addition:
- any SDT for another TS than the actual one (i.e. with table_id = 0x46) shall list all the services of
that TS;
- it is strongly recommended that service_ids, once assigned to a specific service within a network,
remain unchanged in order to enable IRDs to implement features like favourite channel lists, etc.

Page 13
ETR 211: August 1997
4.1.4 Event Information Table (EIT) information
The Event Information Table (EIT) is used to transmit information about present, following and further
future events. For each service a separate EIT sub-table exists.
4.1.4.1 EIT Present/Following information
The following rule simplifies the acquisition of the EIT Present/Following information. The SI specification
states that an EIT section has a maximum size of 4 096 bytes.
The SI bit stream shall have two sections per service for an EIT Present/Following with the
section_number 0x00 reserved for the description of the present event and section_number 0x01 for the
following event. These constraints do not apply in the case of an NVOD reference service which may have
more than one event description per section, and may have more than two sections in the EIT
Present/Following. It is recommended that the event descriptions be given in ascending order of event_id.
The SI bit stream shall have maximum of 4 096 bytes to describe a single event in a section.
The organization of the EIT Present/Following is based on the concept of present and following events.
Which event is the present one can be determined using the following scheme:
a) at each instant in time, there is at most one present event;
b) when there is a present event, this event shall be described in section 0 of the
EIT Present/Following;
c) when there is no present event (e.g. in the case of a gap in the schedule) an empty section 0 of
the EIT Present/Following shall be transmitted;
d) the running_status field in the description of the present event shall be given the interpretation
in table 1:
Table 1: running_status of the present event
undefined No information except the nominal status is provided.
IRDs and VCRs shall treat the present event as running.
running IRDs and VCRs shall treat the present event as running.
not running IRDs and VCRs shall treat the present event as not running.
In other words, this event is nominally the present one, but at this time has
either not started or already ended.
pausing IRDs and VCRs shall treat the present event as pausing.
In other words, this event is nominally the present one and has already
started, but at this time the material being broadcast is not a part of the
event itself.
The transmission of event material shall resume at a later time.
starts in a few IRDs and VCRs shall prepare for the change of event status to "running" in
seconds a few seconds.
The duration of an event as encoded in the field duration of the EIT shall also include the duration
of all times when the event has the status "not running" or "paused". The start time of an event
as encoded in the field start_time of the EIT shall be the start time of the entire event, i.e. not the
start time after the pause has finished;
e) at each point in time, there shall be at most one following event;
f) if a following event exists, it shall be described in section 1 of the EIT Present/Following;
g) if no following event exists, an empty section 1 of the EIT Present/Following shall be transmitted;

Page 14
ETR 211: August 1997
h) the running_status field in the definition of the following event shall be given the following
interpretation:
Table 2: running_status of the following event
undefined No information except the nominal status is provided.
IRDs and VCRs shall treat the following event as not running.
running Not allowed.
not running IRDs and VCRs shall treat the present event as not running.
pausing This status is intended to indicate that the "following" event has been
running at some time, but is now overlapped by another event.
In such a case, during the whole time that the "following" event has status
"pausing", one and the same overlapping event shall be encoded in section
0 of the EIT Present/Following.
Furthermore, an event which has the status "pausing" shall acquire the
status "running" at a later time, then replacing the overlapping event in
section 0 of the EIT Present/Following.
starts in a few IRDs and VCRs shall prepare for the status of the following event to
seconds change to running within a few seconds.
The duration of an event as encoded in the field duration of the EIT shall also include the duration of all
times when the event has the status "not running" or "paused". The start time of an event as encoded
in the field start_time of the EIT shall be the start time of the entire event, i.e. not the start time after the
pause has finished.
NOTE 1: The start time of one event plus its duration may be smaller than the start time of the
following event. In other words, gaps between events are allowed. In such a case, the
following event is considered to be the event scheduled to begin after the gap.
This event shall be encoded in section 1 of the EIT Present/Following.
NOTE 2: The start time and duration are scheduled times. Some broadcasters may update this
information if the schedule is running late, whereas others may prefer to keep the
indicated start time unchanged, e.g. to avoid having an event called "The News at 8"
from being indicated as starting at 8:01:23, instead of 8:00:00.
4.1.4.2 EIT Schedule information
4.1.4.2.1 EIT Schedule structure
The EIT Schedule information is structured in such a way that it is easy to access the EIT data in a flexible
manner. The EIT Schedule Tables shall obey the following rules:
a) the EIT/Schedule is distributed over 16 table_ids, being 0x50 - 0x5F for the actual TS, and
0x60 - 0x6F for other TSs, which are ordered chronologically;
b) the 256 sections under each sub-table are divided into 32 segments of 8 sections each.
Segment #0, thus, comprises sections 0 to 7, segment #1 section 8 to 15 etc.;
c) each segment contains information about events that start (see below) anywhere within a
three-hour period;
d) the information about separate events is ordered chronologically within segments;
e) if only n < 8 sections of a segment are used, the information shall be placed in the first n sections of
the segment. To signal that the last sections of the segment are not used, the value s0 + n - 1,
where s0 is the first section number of the segment, shall be encoded in the field
segment_last_section_number of the EIT header. As an example, if segment 2 contains only
2 sections, the field segment_last_section_number shall contain the value 8 + 2 - 1 = 9 in
those two sections;
Page 15
ETR 211: August 1997
f) segments that contain all their sections shall have the value s0 + 7 encoded in the field
segment_last_section_number;
g) entirely empty segments shall be represented by an empty section, (i.e. a section which does not
contain any loop over events) with the value s0 + 0 encoded in the field
segment_last_section_number;
h) the placing of events in segments is done referring to a time t0.
t0 is "last midnight" in Universal Time Coordinated (UTC) time.
Suppose, for instance, that it is 5.00 PM in the time zone UTC-6. It is then 11.00 PM in the time
zone UTC+0, which makes it 23 hours since "last midnight". Therefore, t0 is 6.00 PM the previous
day in UTC-6;
i) segment #0 of table_id 0x50 (0x60 for other TSs) shall contain information about events that start
between midnight (UTC Time) and 02:59:59 (UTC Time) of "today". Segment #1 shall contain
events that start between 03:00:00 and 05:59:59 UTC time, and so on. This means that the first
sub-table (table_id 0x50, or 0x60 for other TSs) contains information about the first four days of
schedule, starting today at midnight UTC time;
j) the field last_section_number is used to indicate the end of the sub-table. Empty segments that fall
outside the section range indicated by last_section_number shall not be represented by empty
sections;
k) the field last_table_id is used to indicate the end of the entire EIT/Schedule structure. Empty
segments that fall outside the table_id range indicated by last_table_id shall not be represented by
empty sections;
l) segments that correspond to events in the past may be replaced by empty segments (see rule g));
m) the running_status field of event definitions contained in the EIT/Schedule shall be set to undefined
(0x00);
n) EIT/Schedule tables are not applicable to NVOD Reference Services, since these have events with
undefined start times.
4.1.4.2.2 EIT scrambling
The EIT Schedule Tables may be scrambled. In order to provide an association with the
Conditional Access (CA) streams, it is necessary to allocate a service_id (= MPEG-2 program_number)
which is used in the Program Specific Information (PSI) to describe scrambled EIT Schedule Tables.
The EIT is identified in the Program Map Table (PMT) section for this service_id as a programme
consisting of one private stream, and this PMT section includes one or more CA_descriptors to identify the
associated CA streams. The service_id value 0xFFFF is reserved in DVB applications for this purpose.
4.1.5 Time and Date Table (TDT)
The Time and Date Table (TDT) transmits the actual UTC-time coded as Modified Julian Date (MJD).
It may be used to synchronize the internal clock of an IRD. The TDT shall be transmitted at least every
30 seconds. The encoded time is intended to be valid when the section becomes valid according to
figure 3 of this ETR.
4.1.6 Time Offset Table (TOT)
The TOT transmits the actual UTC-time including also time offset information coded as MJD. It may be
used to synchronize the internal clock of an IRD. Transmission of the TOT is optional, but if present it shall
be transmitted at least every 30 seconds. The encoded time is intended to be valid when the section
becomes valid according to figure 3 of this ETR.

Page 16
ETR 211: August 1997
4.1.7 Running Status Table (RST)
Running status sections are used to rapidly update the running status of one or more events. Running
status sections are sent out only once, at the time the status of an event changes, unlike other SI Tables
which are normally repetitively transmitted. Thus there does not exist any update mechanism for RSTs.
At the moment an RST is transmitted to update the running status of an event, it invalidates the running
status of that event, transmitted previously by the EIT Present/Following. The following time the EIT is
transmitted, it shall contain the updated running status bits.
The intended use of this optional mechanism is to enable IRDs or VCRs to implement highly accurate
switching to the beginning of events by setting up a filter on Running Status Tables and waiting for the
occurrence of the RST section containing the event.
4.1.8 Stuffing Table (ST)
A stuffing section may occur in anywhere that a section belonging to an SI Table is allowed.
Stuffing Tables may be used to replace or invalidate either sub-tables or complete SI Tables. In order to
guarantee consistency, all sections of a sub-table shall be stuffed. It is not allowed to replace some
sections of a sub-table by stuffing some sections while keeping others.
4.1.9 Table update mechanism
The section syntax used in the DVB Service Information (SI) supports various signalling mechanisms
for SI contents updates.
The update of a section will be signalled by incrementing the version_number field. The update will be
effective immediately following the last byte of the CRC_32 of the new version of the section, so the
current_next_indicator shall always have the value of "1". Sections with current_next_indicator set to "0"
are never transmitted.
Transmission
ST V
ST V ST V St V
j i
j i j i+1 j i+1
S S S S S S S S S S S S
S S S S
1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
Validity
Time
Sub-table ST version V all sections valid
j i
ST V all sections still valid
j i
ST V section S valid, rest of ST not defined
j i+1 1 j
ST V S + S valid, rest of ST not defined
j i+1 1 2 j
ST V S + S + S valid, rest of ST not defined
j i+1 1 2 3 j
ST V S becomes valid, whole of ST V valid
j i+1 4 j i+1
NOTE: Sections of a sub-table do not have to be transmitted in number order.
Some IRD implementations may acquire data with improved efficiency if the sections of a
sub-table are transmitted in numerical order. However, a broadcaster may not transmit the
sections in order owing to random access considerations.
Figure 3: Timing of table updates and validity

Page 17
ETR 211: August 1997
4.2 SI descriptor allocation and usage
This subclause specifies the location where descriptors can be expected in a SI bit stream, and identifies
which descriptors may occur multiple times. Descriptors which contain fundamental SI data are identified
as recommended to be decoded by the IRD. The interpretation of other descriptors by the IRD is optional.
4.2.1 Descriptors of the Network Information Table (NIT)
The NIT is organized as follows:
/* header .*/
for i = 0; i < N; i++ { /* 1st descriptor loop */
descriptor()
}
for ( i = 0; i < N; i++) {
/* loop over Transport Streams */
transport_stream_id
original_network_id
for ( j = 0; Ij < M; j++) { /* 2nd descriptor loop */
descriptor()
}
}
/* CRC etc. */
4.2.1.1 First descriptor loop
Only the DVB SI descriptors in this subclause have a defined meaning in the first loop of the NIT.
4.2.1.1.1 Linkage descriptor
This descriptor is used to give a link to another service or TS. If it appears in this loop it links to a service
that is attached to the network operator. This descriptor is allowed more than once in this loop, it could for
example point to the "Paris Cable Info channel" and to "Paris Cable Text". Transmission of this descriptor
is optional. The meaning of the descriptor when it occurs here depends on the value of the linkage_type.
If the linkage_type is:
a) 0x01, it refers to a service that contains information about the network. An example of the intended
use is for the IRD to switch to the information service when the user requests additional information
about the network;
b) 0x02, it refers to an Electronic Program Guide (EPG) for the network. Note that the IRD can only
make use of this type of linkage if it can decode the EPG service. This ETR does not specify the
contents of such a service;
c) 0x04, it refers to a TS which carries comprehensive Service Information. The SI carried in the
referenced TS includes at least all the SI information available on all other TSs of the network.
The meaning of other values of linkage_type is not defined in this context. Note that the linkage_type does
not indicate the service_type of the referenced service. An example of the intended use of the linkage
descriptor is that an IRD user interface could include a mechanism like "info about the network" which
would make the IRD tune to the linked service after the user initiated the mechanism.
4.2.1.1.2 Multilingual network name descriptor
This descriptor may be used to convey the name of the network in one or more languages. It may be
included once in the descriptor loop. Inclusion of this descriptor is optional.
4.2.1.1.3 Network name descriptor
This descriptor is used to transmit the name of a physical network, e.g. "ASTRA", "EUTELSAT",
"MUNICH CABLE" etc. This descriptor shall be used exactly once in any NIT sub-table.
4.2.1.2 Second descriptor loop
Only the DVB SI descriptors in this subclause have a defined meaning in the second loop of the NIT.

Page 18
ETR 211: August 1997
4.2.1.2.1 Delivery system descriptors
The delivery system descriptors are the satellite_delivery_system_descriptor,
cable_delivery_system_descriptor and the terrestrial_delivery_system_descriptor.
Descriptors for other delivery systems may be defined in the future. The delivery_system_descriptors are
used to transmit the physical parameters for each transport multiplex in the network.
One (and only one) delivery system descriptor shall appear in each loop. IRDs shall be able to interpret
the delivery system descriptor in order to tune to TSs quickly (see subclauses 4.1.1 and 5.3.1).
4.2.1.2.2 Service list descriptor
This descriptor is used to list the services and service types for each TS. The services are listed identified
by service_id (= MPEG-2 program_number). The transport_stream_id and original_network_id, which are
necessary to identify a DVB service uniquely, are given at the start of the descriptor loop.
The service list descriptor is allowed only once in each loop. Transmission of this descriptor is optional,
but if it is present, then the service list shall b
...