ISO 21219-9:2023
(Main)Intelligent transport systems — Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) — Part 9: Service and network information (TPEG2-SNI)
Intelligent transport systems — Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) — Part 9: Service and network information (TPEG2-SNI)
This document specifies the method for delivering service and network information within a TPEG service. The TPEG-SNI application is designed to allow the efficient, language-independent delivery of information about the availability of the same service on another bearer channel, or similar service data from another service provider, directly from service provider to end-users. A number of tables of information are described in this document which provide comprehensive options for describing services, their timing, content, geographical coverage, etc. In all TPEG streams, it is mandatory to deliver the so-called guide to the service table (GST). Additionally, it is possible to signal linkage of content between different bearers and services.
Systèmes intelligents de transport — Informations sur le trafic et le tourisme via le groupe expert du protocole de transport, génération 2 (TPEG2) — Partie 9: Information de service et de réseau (TPEG2-SNI)
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 21219-9
First edition
2023-05
Intelligent transport systems —
Traffic and travel information (TTI)
via transport protocol experts group,
generation 2 (TPEG2) —
Part 9:
Service and network information
(TPEG2-SNI)
Systèmes intelligents de transport — Informations sur le trafic et le
tourisme via le groupe expert du protocole de transport, génération 2
(TPEG2) —
Partie 9: Information de service et de réseau (TPEG2-SNI)
Reference number
© ISO 2023
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 3
5 Application specific constraints . .4
5.1 Application identification . 4
5.2 Version number signalling . 4
5.3 TPEG 1 binary compatibility of SNI . 4
5.4 TPEG service component frame . 4
5.5 Conceptual model — Multiplexed applications and services. 5
6 Design principle . 5
6.1 Variable content referencing . 5
6.2 Example of the TPEG-SNI application in a TPEG data-stream . 6
6.3 General rules for the TPEG-SNI application . 8
7 SNI Structure . 9
8 SNI Message components .9
8.1 SNI1Template . 9
8.1.1 General . 9
8.1.2 Usage of the version number . 10
8.2 CurrentServiceInformation . 10
8.3 ServiceLogo . 10
8.4 SubscriberInformation . 10
8.5 FreeTextInformation . 11
8.6 HelpInformation . 11
8.7 GST_GuideToServiceTables . 11
8.8 GST1_FastTuningTable . 12
8.9 GST2_TimeScheduleTable .13
8.10 GST3_ContentDescription . 13
8.11 GST4_GeographicalCoverage . 14
8.12 GST5_ServiceComponentReset . 14
8.13 GST6_ConditionalAccessInformationReference . 14
8.14 GST7_Versioning . 14
8.15 GST_ServiceTableAccelerator . 15
8.16 LinkageToSameService . 15
8.17 Same service definition . 17
8.18 LinkageToRelatedService . 17
8.19 Reserved for future use . 17
8.20 BearerLinkageInfoDAB . 17
8.21 BearerLinkageInfoDARC . 17
8.22 BearerLinkageInfoDVB . 18
8.23 BearerLinkageInfoURL . 18
8.24 BearerLinkageInfoHDRadio . 18
8.25 SIT_ServiceInformationTables . 18
8.26 SIT1_NumberOfMessages . 19
9 SNI datatypes .19
9.1 MaskedTime . 19
9.2 DayMask . 20
9.3 AppStartTime . 20
9.4 TimeSlot . 21
iii
9.5 OpTime . 21
9.6 GeographicCoverage . 22
9.7 CoordinatePair . 22
9.8 ByteField . 22
9.9 GST1_Entry . 22
9.10 GST2_Entry .23
9.11 GST3_Entry . 24
9.12 GST4_Entry . 24
9.13 GST5_Entry . 24
9.14 GST6_Entry . 25
9.15 GST7_Entry . 25
9.16 RelatedServiceEntry .25
9.17 DABFrequency . 26
9.18 DVBFrequency . 26
9.19 FMFrequency . 27
9.20 AMFrequency . 27
9.21 SameServiceEntry . 27
9.22 SIT1_Entry .28
9.23 HDRadioStationID .29
9.24 HDFMBearerInfo .29
9.25 HDAMBearerInfo . 29
10 SNI tables .30
10.1 sni001:GraphicType . .30
10.2 sni002:CharacterEncoding . 30
Annex A (normative) TPEG SNI and TPEG-binary representation .31
Annex B (normative) TPEG SNI, tpegML representation .47
Bibliography .60
iv
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see
www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 204, Intelligent transport systems.
This first edition cancels and replaces the first edition (ISO/TS 21219-9:2016), which has been
technically revised.
The main changes are as follows:
— the document has been changed from a Technical Specification to an International Standard;
— outdated applications have been updated with current TPEG2 specifications (e.g. RTM to TEC, PTI
to PTS, CTT to TFP);
— application identification numbers (AIDs) have been updated accordingly.
A list of all parts in the ISO 21219 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
v
Introduction
0.1 History
TPEG technology was originally proposed by the European Broadcasting Union (EBU) Broadcast
Management Committee, who established the B/TPEG project group in the autumn of 1997 with a brief
to develop, as soon as possible, a new protocol for broadcasting traffic and travel-related information in
the multimedia environment. TPEG technology, its applications and service features were designed to
enable travel-related messages to be coded, decoded, filtered and understood by humans (visually and/
or audibly in the user’s language) and by agent systems. Originally, a byte-oriented data stream format,
which can be carried on almost any digital bearer with an appropriate adaptation layer, was developed.
Hierarchically structured TPEG messages from service providers to end-users were designed to
transfer information from the service provider database to an end-user’s equipment.
One year later, in December 1998, the B/TPEG group produced its first EBU specifications. Two
documents were released. Part 2 (TPEG-SSF, which became ISO/TS 18234-2) described the syntax,
semantics and framing structure which was used for all TPEG applications. Meanwhile, Part 4 (TPEG-
RTM, which became ISO/TS 18234-4) described the first application for road traffic messages.
Subsequently, in March 1999, CEN/TC 278, in conjunction with ISO/TC 204, established a group
comprising members of the former EBU B/TPEG and this working group continued development
work. Further parts were developed to make the initial set of four parts, enabling the implementation
of a consistent service. Part 3 (TPEG-SNI, later ISO/TS 18234-3) described the service and network
information application used by all service implementations to ensure appropriate referencing from
one service source to another.
Part 1 (TPEG-INV, later ISO/TS 18234-1) completed the series by describing the other parts and their
relationship; it also contained the application IDs used within the other parts. Additionally, Part 5, the
public transport information application (TPEG-PTI, later ISO/TS 18234-5), was developed. The so-
called TPEG-LOC location referencing method, which enabled both map-based TPEG-decoders and non-
map-based ones to deliver either map-based location referencing or human-readable text information,
was issued as ISO/TS 18234-6 to be used in association with the other applications of parts of the
ISO 18234 series to provide location referencing.
The ISO 18234 series has become known as TPEG Generation 1.
0.2 TPEG Generation 2
When the Traveller Information Services Association (TISA), derived from former forums, was
inaugurated in December 2007, TPEG development was taken over by TISA and continued in the TPEG
applications working group.
It was about this time that the (then) new Unified Modelling Language (UML) was seen as having major
advantages for the development of new TPEG applications in communities who would not necessarily
have the binary physical format skills required to extend the original TPEG TS work. It was also realized
that the XML format for TPEG described within the ISO 24530 series (now superseded) had a greater
significance than previously foreseen, especially in the content-generation segment, and that keeping
two physical formats in synchronism, in different standards series, would be rather difficult.
As a result, TISA set about the development of a new TPEG structure that would be UML-based. This has
subsequently become known as TPEG Generation 2 (TPEG2).
TPEG2 is embodied in the ISO 21219 series and it comprises many parts that cover an introduction,
rules, toolkit and application components. TPEG2 is built around UML modelling and has a core of
rules that contain the modelling strategy covered in ISO 21219-2, ISO 21219-3 and ISO 21219-4 and the
conversion to two current physical formats: binary (see Annex A) and XML (see Annex B); others can
be added in the future. TISA uses an automated tool to convert from the agreed UML model XMI file
directly into an MS Word document file, to minimize drafting errors; this file forms the annex for each
physical format.
vi
TPEG2 has a three-container conceptual structure: message management (ISO 21219-6), application
(several parts) and location referencing (ISO/TS 21219-7). This structure has flexible capability and
can accommodate many differing use cases that have been proposed within the TTI sector and wider
for hierarchical message content.
TPEG2 also has many location referencing options as required by the service provider community, any
of which may be delivered by vectoring data included in the location referencing container.
The following classification provides a helpful grouping of the different TPEG2 parts according to their
intended purpose. Note that the list below is potentially incomplete, as there is the possibility that new
TPEG2 parts will be introduced after the publication of this document.
— Toolkit parts: TPEG2-INV (ISO 21219-1), TPEG2-UML (ISO 21219-2), TPEG2-UBCR (ISO 21219-3),
TPEG2-UXCR (ISO 21219-4), TPEG2-SFW (ISO 21219-5), TPEG2-MMC (ISO 21219-6), TPEG2-LRC
(ISO/TS 21219-7).
— Special applications: TPEG2-SNI (ISO 21219-9 - this document), TPEG2-CAI (ISO 21219-10), TPEG2-
LTE (ISO/TS 21219-24).
— Location referencing: TPEG2-OLR (ISO/TS 21219-22), TPEG2-GLR (ISO/TS 21219-21), TPEG2-TLR
(ISO 17572-2), TPEG2-DLR (ISO 17572-3).
— Applications: TPEG2-PKI (ISO 21219-14), TPEG2-TEC (ISO 21219-15), TPEG2-FPI (ISO 21219-16),
TPEG2-SPI (ISO 21219-17) TPEG2-TFP (ISO 21219-18), TPEG2-WEA (ISO 21219-19), TPEG2-RMR
(ISO/TS 21219-23), TPEG2-EMI (ISO/TS 21219-25), TPEG2-VLI (ISO/TS 21219-26).
TPEG2 has been developed to be broadly (but not totally) backward compatible with TPEG1 to assist in
transitions from earlier implementations, while not hindering the TPEG2 innovative approach and being
able to support many new features, such as dealing with applications with both long-term, unchanging
content and highly dynamic content, such as parking information.
This document is based on the TISA specification technical/editorial version reference:
SP20009_3.3_001.
vii
INTERNATIONAL STANDARD ISO 21219-9:2023(E)
Intelligent transport systems — Traffic and travel
information (TTI) via transport protocol experts group,
generation 2 (TPEG2) —
Part 9:
Service and network information (TPEG2-SNI)
1 Scope
This document specifies the method for delivering service and network information within a TPEG
service. The TPEG-SNI application is designed to allow the efficient, language-independent delivery of
information about the availability of the same service on another bearer channel, or similar service
data from another service provider, directly from service provider to end-users.
A number of tables of information are described in this document which provide comprehensive
options for describing services, their timing, content, geographical coverage, etc. In all TPEG streams,
it is mandatory to deliver the so-called guide to the service table (GST). Additionally, it is possible to
signal linkage of content between different bearers and services.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 21219-1, Intelligent transport systems — Traffic and travel information (TTI) via transport protocol
experts group, generation 2 (TPEG2) — Part 1: Introduction, numbering and versions (TPEG2-INV)
ETSI EN 300-401, Radio broadcasting systems; Digital Audio Broadcasting (DAB) to mobile, portable and
fixed receivers
ETSI/TS 101 759, Digital Audio Broadcasting (DAB); Data Broadcasting — Transparent Data Channel
IETF RFC 1738, Uniform Resource Locators (URL)
IEC 62106:2015, Radio data system (RDS) - VHF/FM sound broadcasting in the frequency range from
64,0 MHz to 108,0 MHz
ETSI EN 300-468, Digital Video Broadcasting (DVB); Specification for Service Information (SI) in DVB
systems
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 21219-1 and the following
apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
application identification
AID
identifier that specifies how to process TPEG content and route information to the appropriate
application decoder
Note 1 to entry: Each TPEG application has a unique number, which identifies the application according to
Clause 5. The application identification is part of the TPEG specification and is defined as and when new
applications are developed.
3.2
application instance
actual data stream containing content as defined by an application
3.3
application and content identification
ACID
worldwide unique identifier that defines the content of a service
Note 1 to entry: The ACID is composed of the originator service identification (SID-A, SID-B, SID-C) (3.13), the
content identification (3.5) and the application identification (3.1).
3.4
content description
textual description of a selected service component (3.11)
3.5
content identification
COID
identifier that is unique within a given application and used to specify its content
Note 1 to entry: The COID is defined by the originator of the content and is unique within a specific application. It
is used for labelling the content of a component.
3.6
data radio channel
DARC
FM sub-carrier system for data transmission
3.7
content originator
original provider of an application instance (3.2)
Note 1 to entry: The content originator may distribute the application data to different service providers. In
some cases, the service provider generates its own application data and is therefore also the content originator.
3.8
fast tuning GST
FT-GST
directory of the applications and content of the service that indicates in which components the relevant
information can be found
Note 1 to entry: This contains the minimum set of information required for the acquisition of application data.
3.9
guide to the service table
GST
basic service information such as service structure, service timing and content description (3.4), etc.
3.10
Reference-English “word”
word which enables information to be transmitted as a concept, thereby letting the receiver device
choose the best possible representation of the given concept in the context of the other parts of the
message
Note 1 to entry: This approach means that devices can present concepts in any language or even as graphical
icons, for example. For further explanation, see ISO 21219-2.
3.11
service component
virtual channel for messages of a particular application
3.12
service component identification
SCID
unique identifier that defines a service component (3.11) within a service
Note 1 to entry: The SCID is chosen by the carrier service provider and identifies a component, which itself has
an ACID comprising originator SID, COID and AID. The same number may be used in a different service or, in the
same service at a later time to identify a completely different combination of originator SID, COID and AID.
3.13
service identification
worldwide unique identifier for a service
Note 1 to entry: It consists of three elements called SID A, SID-B, SID-C. These are allocated as described in
ISO/TS 18234-2.
3.14
service table
table containing basic service information, such as service structure, service timing and content
description (3.4), etc.
3.15
time schedule GST
T-GST
table indicating the operation times of selected service components (3.11)
4 Abbreviated terms
For the purposes of this document, the terms defined in ISO 21219-1 and the following apply.
DAB digital audio broadcasting
DVB digital video broadcasting
ECC extended country code
EID ensemble identification
ETSI European Telecommunications Standards Institute
FM frequency modulation
LHW local hazard warning
PI programme identification
RDS radio data system
SCR service component reset
SIS station information service
SIT service information table
STI status and travel-time information (proposed TPEG application)
tba to be announced
URL uniform resource locator
UTC coordinated universal zime
5 Application specific constraints
5.1 Application identification
The word “application” is used in the TPEG specifications to describe specific subsets of the TPEG
structure. An application defines a limited vocabulary for a certain type of messages, for example,
parking information or road traffic information. Each TPEG application is assigned a unique number,
called the application identity (AID). An AID number is defined in ISO 21219-1 whenever a new
application is developed.
The AID number is used within the TPEG2-SNI application (this document) to indicate how to process
TPEG content. It facilitates the routing of information to the appropriate application decoder.
5.2 Version number signalling
Version numbering is used to track the separate versions of an application through its development and
deployment. The differences between these versions could have an impact on client devices.
The version numbering principle is defined in ISO 21219-1.
Table 1 shows the current version numbers for signalling SNI within the SNI application.
Table 1 — Current version numbers for signalling of SNI
Major version number 3
Minor version number 3
5.3 TPEG 1 binary compatibility of SNI
The UML model for this application has been modelled according to TPEG2-UBR. The XML physical
format conforms with the UXCR Specification ISO 21219-4 and is hence fully TPEG2 conformant. For the
binary physical format, the TPEG1 conformance was mandatory to allow the coexistence of TPEG1 and
TPEG2 level applications within a single service. So, it was not possible to completely follow the binary
conversion rules specified in ISO 21219-3. Details are stated in Annex A.
5.4 TPEG service component frame
SNI makes use of the “service component frame with dataCRC and messageCount” according to this
document.
Each SNI component shall appear only once at most in the SNI component frame.
5.5 Conceptual model — Multiplexed applications and services
Figure 1 illustrates the conceptual model of the SNI application.
Figure 1 — Multiplexed applications and services
6 Design principle
6.1 Variable content referencing
Figure 2 contains a diagrammatic representation of the use of SCIDs in related services.
Key
Service A (national): SCID: 02, 03, 04, 05 Bearer: ii and iii
Service B (regional): SCID: 02, 03, 04 Bearer: iii
Service C (local): SCID: 02 Bearer: i
Service D (local): SCID: 03 Bearer: i
Service E (regional): SCID: 06, 07, 08 Bearer: ii
Service F (local): SCID: 06 Bearer: i
Service G (local): SCID: 07 Bearer: i
Service H (inter-local): SCID: 03, 06 Bearer: ii
Figure 2 — Diagrammatic representation of the use of SCIDs in related services
6.2 Example of the TPEG-SNI application in a TPEG data-stream
Figure 3 gives an example of the TPEG-SNI application in a TPEG data-stream.
Figure 3 — Example of the TPEG-SNI application in a TPEG data-streamConcept of allocating
services
Figure 4 shows the use of TPEG application names and AIDs.
TPEG application AID Comment
SNI 0000
TEC 0005
PTS 0013 Notional future application code.
TFP 0007
WEA 0010
Figure 4 — Example of service allocation on a wideband bearer
There are two instances where SID is used.
— Originator SID (SID-A, SID-B, SID-C): This is the SID of the service provider who generates the
content.
— Carrier SID (SID-A, SID-B, SID-C): This is the SID of the service provider who is delivering the service
at the service frame level (see ISO 21219-5).
Figure 5 shows an example for the use of the SID and AID.
TPEG application AID Comment
SNI 0000
TEC 0005
WEA 0010
Figure 5 — Example of service allocation on a narrowband bearer
6.3 General rules for the TPEG-SNI application
The following rules for the allocation of services by the service provider on one single bearer apply:
— for every service, the service and network information is mandatory;
— the SNI application shall only occur once within a service and has the reserved SCID of 00;
— the fast tuning GST is mandatory within the SNI;
— the SCID identifies the combination of an application and its content within a service.
— the AIDs are standardized by ISO 21219-1;
— the COID is used for specifying the content of a component within a service;
— the originator service identification (SID-A, SID-B, SID-C), COID and AID together form the ACID
which uniquely identifies the same content worldwide;
— the ACID is associated with the SCID within a service;
— some instances of a service are equivalent, but not necessarily identical. For example, the same
service may be distributed on different bearers with different SCIDs. In this case, the services do not
have an identical “byte-stream”, but carry equivalent data content;
— each SNI component (e.g. GST time schedule, linkage table, etc.), shall not occur more than once in
each SNI component frame.
7 SNI Structure
Figure 6 shows the structure of SNI components, while GST and SIT components are displayed as
summary boxes. The binary format and XML format of the TPEG2-SNI application for use in transmission
shall be in accordance with Annexes A and B, respectively.
Figure 6 — SNI message structure
8 SNI Message components
8.1 SNI1Template
8.1.1 General
The SNI does not use the typical TPEG message management, but instead provides various components
necessary to decode a TPEG service. For conformance with the UML modelling rules (ISO 21219-2), an
abstract “SNI1Template” has been introduced to provide the anchor point for the framing.
The components can be grouped as service information, component information and linkage
information:
a) service information
SNIMessages, that describe the service, like CurrentServiceInformation or ServiceLogo.
b) component information
The GST consists of several parts that carry the basic service information of different importance to
the system and the user. Taking this into account, the repetition rate of these basic tables can be
adjusted to the available channel capacity.
The SIT delivers dynamic information about the current service, for example, the number of messages
available for reception in a service component.
c) linkage information
TPEG services can be linked independently of the bearer system. These linking features are provided
for the same service or other services.
8.1.2 Usage of the version number
There is only one version number within the SNI application. It is used to synchronize the various
tables. If in any table, within the SNI, a version number exists, then the version number shall always
be the same in all of the tables. If any of the tables change, the version number in all tables shall be
incremented.
Exception for SITs: due to the dynamic nature of SITs, the version number in the SIT shall only be
changed if the version number of the GST1 changes.
8.2 CurrentServiceInformation
CurrentServiceInformation provides the TPEG service name and description to the receiver. This
information is mandatory for TPEG services. Exactly one instance of CurrentServiceInformation is
allowed in the SNI. The encoding of the CurrentServiceInformation is shown in Table 2.
Table 2 — Current service information
Name Type Multiplicity Description
serviceName ShortString 1 Identifies the service to a human being. Identifies the
service by a label, comparable to PS in RDS.
EXAMPLE “BBC 2 - TPEG Service”.
serviceDescription ShortString 1 Identifies the applications and scope thereof within
a service. Describes in more detail the content of a
service.
EXAMPLE “Local and interurban road traffic informa-
tion combined with public transport information for
South-East England”.
8.3 ServiceLogo
Service Logo provides a graphical identification of the service or the service provider. It promotes the
service or provider. The ServiceLogo is optional. Multiple logos can be referenced. The encoding of the
ServiceLogo is shown in Table 3.
Table 3 — Service logo
Name Type Multiplicity Description
graphicType sni001: GraphicType 1 n.a.
graphicData ByteField 1 n.a.
8.4 SubscriberInformation
This subclause describes additional payment and encryption information delivered to the end-
user. This information is optional for the SNI application, but enhances information provided to the
end-user. This mechanism will allow for tariffs to be announced to the end-user. The encoding of the
SubscriberInformation is shown in Table 4. This information optionally occurs in any encrypted or
potentially encrypted service.
Table 4 — SubscriberInformation
Name Type Multiplicity Description
subscriberData ByteField 1 Contents defined by the service provider. Gives
information about payment and tariffs for restricted
service components.
8.5 FreeTextInformation
In this subclause, more textual information for the end-user is defined. This information is not
mandatory and the occurrence in the stream is selected by the service provider. The encoding of the
FreeTextInformation is shown in Table 5.
EXAMPLE Announcement of service disruption, disclaim information, legal advice.
Table 5 — FreeTextInformation
Name Type Multiplicity Description
freeText ShortString 1 Additional information that is not coded and is there-
fore language-dependent.
8.6 HelpInformation
In this subclause, more textual information for the end-user is defined. This information is not
mandatory and the occurence in the stream is selected by the service provider. The encoding of the
HelpInformation is shown in Table 6.
EXAMPLE Internet address, hotline number, helpdesk.
Table 6 — HelpInformation
Name Type Multiplicity Description
helpText ShortString 1 Additional information that gives addresses to which
the user can apply. A link between the user and the
service provider for feedback.
8.7 GST_GuideToServiceTables
The GST consists of seven parts that carry the basic service information to the system and the user.
Taking this into account, the repetition rate of these basic tables can be adjusted to the available channel
capacity. The encoding of the GST_GuideToServiceTables is shown in Figure 7.
Figure 7 — SNI service tables
8.8 GST1_FastTuningTable
GST1 (fast tuning GST) is mandatory. All service components shall be defined in this table. The same
SCID may never occur more than once within this table.
EXAMPLE Table 7 shows a very simple example of a fast tuning GST, with only one entry (05) of one
application (0001). This application has only one content identification (03). This information itself is carried in a
component frame identified by 00, which is the default value for the SNI application.
Table 7 — Simple example of a GST tuning table
Version number Character table SCID: COID: AID:
identifier
Mandatory Mandatory Mandatory Mandatory Mandatory
1 Byte 1 Byte 1 Byte 1 Byte 2 Bytes
7B 7D 05 03 0001
The encoding of the GST1_FastTuningTable is shown in Table 8.
Table 8 — GST1_FastTuningTable
Name Type Multiplicity Description
tableVersion IntUnTi 1 Incremented, if any of the entries are
changed.
characterEncoding s n i 0 02: C h a r ac t erEnc o d i ng 1 Default character table for the current ser-
vice. The one and only encoding to be used
in TPEG is UTF-8. All other possible values
are deprecated.
The character table identifier is valid for the
whole service inclu
...
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...