ISO/TS 21219-9:2016

Intelligent transport systems - Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) - Part 9: Service and network information (TPEG2-SNI)

ISO/TS 21219-9:2016 establishes the method of delivering service and network information within a TPEG service. The TPEG-SNI application is designed to allow the efficient and 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. NOTE A number of tables of information are described, which provide comprehensive options for describing services, their timing, content, geographical coverage, etc. In all TPEG streams, it is mandatory to deliver to so-called 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 reseau (TPEG2-SNI)

General Information

• Status: Withdrawn
• Publication Date: 28-Mar-2016
• ICS: 03.220.01 - Transport in general
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: ISO/TC 204 - Intelligent transport systems
• Drafting Committee: ISO/TC 204/WG 10 - Traveller information systems
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 25-May-2023
• Completion Date: 13-Dec-2025

Relations

• Revised: ISO 21219-9:2023 - Intelligent transport systems - Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) - Part 9: Service and network information (TPEG2-SNI)
• Effective Date: 23-Apr-2020

Standards Content (Sample)

TECHNICAL ISO/TS
SPECIFICATION 21219-9
First edition
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 reseau (TPEG2-SNI)
PROOF/ÉPREUVE
Reference number
©
ISO 2016
© ISO 2016, Published in Switzerland
All rights reserved. Unless otherwise specified, 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
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. [phone]
Fax [phone]
[e-mail]
www.iso.org
ii © ISO 2016 – All rights reserved

Contents Page
Foreword .v
Introduction .vii
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 4
5 Application specific constraints . 5
5.1 Application identification . 5
5.2 Version number signalling . 5
5.3 TPEG 1 binary compatibility of SNI . 5
5.4 TPEG Service Component Frame. 6
5.5 Conceptual model — Multiplexed applications and services . 6
6 Design principle . 6
6.1 Variable content referencing . 6
6.2 Example of the TPEG-SNI application in a TPEG data-stream . 7
6.3 Concept of allocating services . 8
6.4 General rules for the TPEG-SNI application .10
7 SNI Structure .11
8 SNI Message components.11
8.1 SNI1Template .11
8.1.1 General.11
8.1.2 Usage of the version number .12
8.2 CurrentServiceInformation .12
8.3 ServiceLogo .12
8.4 SubscriberInformation .13
8.5 FreeTextInformation .13
8.6 HelpInformation .13
8.7 GST_GuideToServiceTables .13
8.8 GST1_FastTuningTable .14
8.9 GST2_TimeScheduleTable .15
8.10 GST3_ContentDescription .16
8.11 GST4_GeographicalCoverage .16
8.12 GST5_ServiceComponentReset .16
8.13 GST6_ConditionalAccessInformationReference .16
8.14 GST7_Versioning .17
8.15 GST_ServiceTableAccelerator .17
8.16 LinkageToSameService .18
8.17 Same Service Definition .18
8.18 LinkageToRelatedService .19
8.19 Reserved for future use .19
8.20 BearerLinkageInfoDAB .19
8.21 BearerLinkageInfoDARC .19
8.22 BearerLinkageInfoDVB .20
8.23 BearerLinkageInfoURL.20
8.24 BearerLinkageInfoHDRadio .20
8.25 SIT_ServiceInformationTables .20
8.26 SIT1_NumberOfMessages .21
9 SNI Datatypes .22
9.1 MaskedTime .22
9.2 DayMask .22
9.3 AppStartTime .22
9.4 TimeSlot .23
9.5 OpTime .23
9.6 GeographicCoverage.24
9.7 CoordinatePair .24
9.8 ByteField.24
9.9 GST1_Entry .25
9.10 GST2_Entry .25
9.11 GST3_Entry .26
9.12 GST4_Entry .26
9.13 GST5_Entry .26
9.14 GST6_Entry .27
9.15 GST7_Entry .27
9.16 RelatedServiceEntry .27
9.17 DABFrequency .28
9.18 DVBFrequency .28
9.19 FMFrequency .29
9.20 AMFrequency .29
9.21 SameServiceEntry .29
9.22 SIT1_Entry.30
9.23 HDRadioStationID .31
9.24 HDFMBearerInfo .31
9.25 HDAMBearerInfo .31
10 SNI Tables .32
10.1 sni001:GraphicType .32
10.2 sni002:CharacterEncoding .32
Annex A (normative) TPEG SNI, TPEG-Binary Representation .34
Annex B (normative) TPEG SNI, tpegML representation .50
Bibliography .63
iv PROOF/ÉPREUVE © ISO 2016 – All rights reserved

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 on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical
Barriers to Trade (TBT) see the following URL: Foreword - Supplementary information.
The committee responsible for this document is ISO/TC 204 Intelligent transport systems, in cooperation
with the Traveller Information Services Association (TISA), TPEG Applications Working Group through
Category A Liaison status.
ISO/TS 21219 consists of the following parts, under the general title Intelligent transport systems —
Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2):
— Part 1: Introduction, numbering and versions
— Part 2: UML modelling rules
— Part 3: UML to binary conversion rules
— Part 4: UML to XML conversion rules
— Part 5: Service framework
— Part 6: Message management container
— Part 9: Service and network information
— Part 10: Conditional access information
— Part 14: Parking information application
— Part 15: Traffic event compact
— Part 18: Traffic flow and prediction application
— Part 19: Weather information
The following parts are under preparation:
— Part 16: Fuel price information and availability application
The following parts are planned:
— Part 7: Location referencing container
— Part 20: Extended TMC location referencing
— Part 21: Geographic location referencing
— Part 22: OpenLR location referencing
— Part 23: Roads and multi-modal routes application
— Part 24: Light encryption
— Part 25: Electromobility information
vi PROOF/ÉPREUVE © ISO 2016 – All rights reserved

Introduction
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, 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, 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, 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 parts of the ISO/TS 18234
series to provide location referencing.
The ISO/TS 18234 series has become known as TPEG Generation 1.
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 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/TS 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 is embodied in the ISO/TS 21219 series and it comprises many parts that cover introduction,
rules, tool kit and application components. TPEG2 is built around UML modelling and has a core of rules
that contain the modelling strategy covered in Parts 2, 3, 4 and the conversion to two current physical
formats: binary and XML; others could 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, that forms the Annex for each physical format.
TPEG2 has a three container conceptual structure: Message Management (Part 6), Application (many
Parts) and Location Referencing (Part 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:
— Toolkit parts: TPEG2-INV (part 1), TPEG2-UML (part 2), TPEG2-UBCR (part 3), TPEG2-
UXCR (part 4), TPEG2-SFW (part 5), TPEG2-MMC (part 6), TPEG2-LRC (part 7);
— Special applications: TPEG2-SNI (part 9), TPEG2-CAI (part 10);
— Location referencing: TPEG2-ULR (part 11), TPEG2-ETL (part 20), TPEG2-GLR (part 21), TPEG2-
OLR (part 22);
— Applications: TPEG2-PKI (part 14), TPEG2-TEC (part 15), TPEG2-FPI (part 16), TPEG2-
TFP (part 18), TPEG2-WEA (part 19), TPEG2-RMR (part 23).
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 having both long-term,
unchanging content and highly dynamic content, such as Parking Information.
This Technical Specification is based on the TISA specification technical/editorial version reference:
SP13006/3.2/001
The International Organization for Standardization (ISO) (and/or) International Electrotechnical
Commission (IEC) draws attention to the fact that it is claimed that compliance with this Technical
Specification may involve the use of a patent concerning “the HD Radio Bearer and Linkage Information”
given in 10.5. ISO [and/or] IEC take[s] no position concerning the evidence, validity and scope of this
patent right.
The holder of this patent right has ensured the ISO (and/or) IEC that he/she is willing to negotiate
licences under reasonable and non-discriminatory terms and conditions with applicants throughout
the world. In this respect, the statement of the holder of this patent right is registered with ISO (and/or)
IEC. Information may be obtained from the following.
iBiquity Digital Corporation
6711 Columbia Gateway Drive, Suite 500
Columbia, MD 21046
USA
viii PROOF/ÉPREUVE © ISO 2016 – All rights reserved

TECHNICAL SPECIFICATION ISO/TS 21219-9:2016(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 part of ISO/TS 21219 establishes the method of delivering service and network information within
a TPEG service. The TPEG-SNI application is designed to allow the efficient and 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.
NOTE A number of tables of information are described, which provide comprehensive options for describing
services, their timing, content, geographical coverage, etc. In all TPEG streams, it is mandatory to deliver to so-
called GST. Additionally, it is possible to signal linkage of content between different bearers and services.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
ISO/TS 21219-3, Intelligent transport systems - Traffic and travel information (TTI) via transport protocol
experts group, generation 2 (TPEG2) — Part 3: UML to binary conversion rules
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
1)
IETF RFC 1738, Uniform Resource Locators (URL)
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
guide to the service tables
GST
basic service (3.10) information such as service structure, service timing and content description (3.4), etc.
3.2
fast tuning GST
FT-GST
directory of the applications (3.11) and content (3.12) of the service (3.10) 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.
1) RFC 1738 can be found at http://www.ietf.org/rfc/rfc1738.txt
3.3
time schedule GST
TS-GST
indicates the operation times of selected service components (3.16)
3.4
content description GST
CD-GST
optional table that gives the textual descriptions of selected service components (3.16)
3.5
geographical coverage GST
GC-GST
optional table that defines the spatial range of selected service components (3.16)
3.6
service component reset GST
SCR-GST
optional table that is used by the service provider (3.14) to delete application-specific data older than a
certain moment
3.7
conditional access information reference GST
CAI-GST
optional table that is used by the service provider (3.14) to indicate which service component (3.16)
carries the CAI application data required to decode encrypted service components
3.8
versioning of TPEG applications GST
VER-GST
mandatory table that is used by the service provider (3.14) to indicate which version of the application
specification the service component (3.16) complies to
3.9
number of messages within a TPEG service component
NOM-SIT
optional table that is used to transmit the number of messages currently available for each service
component (3.16)
3.10
service
collection of different information streams [applications (3.11)] logically bound together and delivered
from a service provider (3.14) to the end user
3.11
application
stream of information that by itself provides a benefit to (i.e. can be “applied by”) the end user
3.12
content
information inside an application (3.11)
Note 1 to entry: A service (3.10) may contain several instances of the same application type, each containing
different content. Within an application, different content is labelled with a unique content ID (COID) specified by
the originator of the content.
3.13
application instance
actual data stream containing content (3.12) as defined by an application (3.11)
2 PROOF/ÉPREUVE © ISO 2016 – All rights reserved

3.14
service provider
organization that provides information a [service (3.10)] to end users and manages the content (3.12) of
its service and decides whether a service is encrypted or not
Note 1 to entry: A service provider that generates the content of a service is called a service originator. A service
provider that carries content generated by another originator is called the carrier. There is only one service
originator of content, but there may be more than one service carrier.
3.15
content originator
original provider of an application instance (3.13)
Note 1 to entry: The content originator may distribute the application (3.11) data to different service providers (3.14).
In some cases, the service provider generates its own application data and is therefore also the content originator.
3.16
service component
information stream [application (3.11)] that is part of a service (3.10)
Note 1 to entry: A TPEG stream is logically divided into parts known as service components. Each service
component carries an application instance (3.13). A service component is effectively a “channel” within the
multiplex of a TPEG stream. Each stream comprises a number of these “channels” which are identified by the
component identifier in TPEG2-SFW and linked to the COID and AID in the TPEG2-SNI application.
3.17
service identification
worldwide unique identifier for a service (3.10)
Note 1 to entry: It consists of three elements called SID A, SID-B, SID-C (cf. subclause 0). These are allocated as
described in ISO/TS 18234-2.
3.18
content identification
COID
identifier that is unique within a given application (3.11) and used to specify its content (3.12)
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.19
application and content identification
ACID
worldwide unique identifier that defines the content (3.12) of a service (3.10)
Note 1 to entry: The ACID is composed of the originator service identification (SID-A, SID-B, SID-C) (3.17), the
content identification (COID) (3.18) and the application identification (AID) (3.20).
3.20
application identification
AID
identifier that specifies how to process TPEG content (3.12) and route information to the appropriate
application decoder
Note 1 to entry: Each TPEG application has a unique number, which identifies the application (3.11) according
to Clause 5. The application identification is part of the TPEG specification and is defined as and when new
applications are developed.
3.21
service component identification
SCID
unique identifier that defines a service component within a service (3.10)
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.22
service table
table containing basic service information, such as service structure, service timing and content
description (3.4), etc.
4 Abbreviated terms
AID Application Identification
ACID Application and Content Identifier
ADC Application Data Container
CAI Conditional Access Information
CEN Comité Européen de Normalization
COID Content Identification
DAB Digital Audio Broadcasting
DARC Data Radio Channel - an FM sub-carrier system for data transmission
DVB Digital Video Broadcasting
EBU European Broadcasting Union
ETSI European Telecommunications Standards Institute
GST Guide to Service Tables
INV Introduction, Numbering and Versions (see TPEG2-INV - ISO/TS 21219-1)
IPR Intellectual Property Right(s)
ISO International Organization for Standardization
LHW Local Hazard Warning
LRC Location Reference Container
MMC Message Management Container
OSI Open Systems Interconnection
PTI TPEG1-PTI Public Transport Information (see ISO 18234-5)
RTM TPEG1-RTM Road Traffic Message application (see ISO 18234-4)
SCID Service Component Identification
SFW TPEG Service Framework: Modelling and Conversion Rules
4 PROOF/ÉPREUVE © ISO 2016 – All rights reserved

SID Service Identification
SIT Service Information Table
SNI Service and Network Information application (this Technical Specification)
STI Status and Travel-time Information (proposed TPEG application)
tba to be announced
TEC Traffic Event Compact
TISA Traveller Information Services Association
TPEG Transport Protocol Expert Group
TTI Traffic and Traveller Information
UML Unified Modelling Language
UTC Coordinated Universal Time
WEA Weather Information Application
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 Identification (AID). An AID is defined whenever a new application is developed
and these are all listed in TPEG2-INV.
The application identification number is used within the TPEG2-SNI application to indicate how to
process TPEG content and 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 may have an impact on client devices.
The version numbering principle is defined in TPEG2-SNI.
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 2
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 complies with the UXCR Specification TPEG2-UXCR and is hence fully TPEG2 compliant. For
the binary physical format, the TPEG1 compliance was mandatory, to allow 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 TPEG2-UBCR. 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 TPEG2-
SNI.
Each SNI component should appear only at most once 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.
6 PROOF/ÉPREUVE © ISO 2016 – All rights reserved

Service A (national)
Service B (regional)
Service C
(local)
Service D
(local)
Service H (inter -local)
Service F
(local)
Service G
(local)
Service E (regional)
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.
Key
SCID Service Component Identification
SNI Service and Network Information Application
RTM Road Traffic Message Application
PTI Public Transport Information Application
CTT Congestion and Travel Time Information Application (notional future Application)
Figure 3 — Example of the TPEG-SNI application in a TPEG data-stream
6.3 Concept of allocating services
Figure 4 shows the use of TPEG Application names and AIDs.
SNI = Service and Network Information Application AID = 0000
RTM = Road Traffic Message Application AID = 0001
PTI = Public Transport Information Application AID = 0002
CTT = Congestion and Travel Time Application AID = 0005 (notional future application code)
WEA = Weather Information Application AID = 0033 (notional future application code)
8 PROOF/ÉPREUVE © ISO 2016 – All rights reserved

Key
SID Service Identification (with three parts: -A, -B, -C)
COID Content Identification
AID Application Service Component Identification Identification
SCID Service Component Identification
Figure 4 — Example of service allocation on a wideband bearer
Use of the Service ID.
There are two instances where Service Identification is used.
— Originator SID (SID-A, SID-B, SID-C): This is the service identification of the service provider who
generates the content.
— Carrier SID (SID-A, SID-B, SID-C): This is the service identification of the service provider who is
delivering the service at the service frame level (see TPEG2-SFW).
Application names and AIDs:
SNI = Service and Network Information Application AID = 0000
RTM = Road Traffic Message Application AID = 0001
PTI = Public Transport Information Application AID = 0002
WEA = Weather Information Application AID = 0033 (notional future application code)
The following Figure 5 shows an example for the use of the SID and AID.
Key
SID Service Identification (with three parts: -A, -B, -C)
COID Content Identification
AID Application Service Component Identification Identification
SCID Service Component Identification
Figure 5 — Example of service allocation on a narrowband bearer
6.4 General rules for the TPEG-SNI application
The following rules for the allocation of services by the service provider on one single bearer are
elaborated.
— 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 guide to the Service Table is mandatory within the SNI.
— The service component identifier (SCID) identifies the combination of an application and its content
within a service.
— The application IDs are standardized by ISO/TS 18234-1.
— The content identification (COID) is used for specifying the content of a component within a service.
— The originator service identification (SID-A, SID-B, SID-C), content identification (COID) and
application identification (AID) together form the application and content identification (ACID)
which uniquely identifies the same content worldwide.
— The application and content identification (ACID) is associated with the service component
identification (SCID) within a service.
10 PROOF/ÉPREUVE © ISO 2016 – All rights reserved

— Some instances of a service are equivalent, but not necessarily identical. For example, the same service
may be distributed on different bearers with different service component identifications (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 never 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.
class SNI - Serv ice and Network Information
SNI1Template
CurrentServiceInformation SubscriberInformation HelpInformation LinkageToSameService
+ serviceName: ShortString + subscriberData: ByteField + helpText: ShortString + tableVersion: IntUnTi
+ serviceDescription: ShortString + tableEntry: SameServiceEntry [1.255]
Serv iceLogo FreeTextInformation GST_GuideToServiceTables LinkageToRelatedServ ice
+ graphicType: sni001:GraphicType + freeText: ShortString + tableVersion: IntUnTi
+ graphicData: ByteField + tableEntry: RelatedServiceEntry [1.255]
SIT_ServiceInformationTables
Figure 6 — SNI message structure
8 SNI Message components
8.1 SNI1Template
8.1.1 General
The service and network information application does not use the typical TPEG message management,
but instead provides various components to necessary to decode a TPEG service. For compliance with
...

TECHNICAL ISO/TS
SPECIFICATION 21219-9
First edition
2016-04-01
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 reseau (TPEG2-SNI)
Reference number
©
ISO 2016
© ISO 2016, Published in Switzerland
All rights reserved. Unless otherwise specified, 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
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. [phone]
Fax [phone]
[e-mail]
www.iso.org
ii © ISO 2016 – All rights reserved

Contents Page
Foreword .v
Introduction .vii
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 4
5 Application specific constraints . 5
5.1 Application identification . 5
5.2 Version number signalling . 5
5.3 TPEG 1 binary compatibility of SNI . 5
5.4 TPEG Service Component Frame. 5
5.5 Conceptual model — Multiplexed applications and services . 5
6 Design principle . 6
6.1 Variable content referencing . 6
6.2 Example of the TPEG-SNI application in a TPEG data-stream . 7
6.3 Concept of allocating services . 8
6.4 General rules for the TPEG-SNI application .10
7 SNI Structure .11
8 SNI Message components.11
8.1 SNI1Template .11
8.1.1 General.11
8.1.2 Usage of the version number .12
8.2 CurrentServiceInformation .12
8.3 ServiceLogo .12
8.4 SubscriberInformation .13
8.5 FreeTextInformation .13
8.6 HelpInformation .13
8.7 GST_GuideToServiceTables .13
8.8 GST1_FastTuningTable .14
8.9 GST2_TimeScheduleTable .15
8.10 GST3_ContentDescription .15
8.11 GST4_GeographicalCoverage .16
8.12 GST5_ServiceComponentReset .16
8.13 GST6_ConditionalAccessInformationReference .16
8.14 GST7_Versioning .16
8.15 GST_ServiceTableAccelerator .17
8.16 LinkageToSameService .17
8.17 Same Service Definition .18
8.18 LinkageToRelatedService .19
8.19 Reserved for future use .19
8.20 BearerLinkageInfoDAB .19
8.21 BearerLinkageInfoDARC .19
8.22 BearerLinkageInfoDVB .19
8.23 BearerLinkageInfoURL.20
8.24 BearerLinkageInfoHDRadio .20
8.25 SIT_ServiceInformationTables .20
8.26 SIT1_NumberOfMessages .21
9 SNI Datatypes .22
9.1 MaskedTime .22
9.2 DayMask .22
9.3 AppStartTime .22
9.4 TimeSlot .23
9.5 OpTime .23
9.6 GeographicCoverage.24
9.7 CoordinatePair .24
9.8 ByteField.24
9.9 GST1_Entry .24
9.10 GST2_Entry .25
9.11 GST3_Entry .26
9.12 GST4_Entry .26
9.13 GST5_Entry .26
9.14 GST6_Entry .26
9.15 GST7_Entry .27
9.16 RelatedServiceEntry .27
9.17 DABFrequency .28
9.18 DVBFrequency .28
9.19 FMFrequency .28
9.20 AMFrequency .28
9.21 SameServiceEntry .29
9.22 SIT1_Entry.30
9.23 HDRadioStationID .30
9.24 HDFMBearerInfo .31
9.25 HDAMBearerInfo .31
10 SNI Tables .31
10.1 sni001:GraphicType .31
10.2 sni002:CharacterEncoding .32
Annex A (normative) TPEG SNI, TPEG-Binary Representation .33
Annex B (normative) TPEG SNI, tpegML representation .49
Bibliography .62
iv © ISO 2016 – All rights reserved

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 on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical
Barriers to Trade (TBT) see the following URL: Foreword - Supplementary information.
The committee responsible for this document is ISO/TC 204 Intelligent transport systems, in cooperation
with the Traveller Information Services Association (TISA), TPEG Applications Working Group through
Category A Liaison status.
ISO/TS 21219 consists of the following parts, under the general title Intelligent transport systems —
Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2):
— Part 1: Introduction, numbering and versions
— Part 2: UML modelling rules
— Part 3: UML to binary conversion rules
— Part 4: UML to XML conversion rules
— Part 5: Service framework
— Part 6: Message management container
— Part 9: Service and network information
— Part 10: Conditional access information
— Part 14: Parking information application
— Part 15: Traffic event compact
— Part 18: Traffic flow and prediction application
— Part 19: Weather information
The following parts are under preparation:
— Part 16: Fuel price information and availability application
The following parts are planned:
— Part 7: Location referencing container
— Part 20: Extended TMC location referencing
— Part 21: Geographic location referencing
— Part 22: OpenLR location referencing
— Part 23: Roads and multi-modal routes application
— Part 24: Light encryption
— Part 25: Electromobility information
vi © ISO 2016 – All rights reserved

Introduction
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, 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, 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, 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 parts of the ISO/TS 18234
series to provide location referencing.
The ISO/TS 18234 series has become known as TPEG Generation 1.
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 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/TS 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 is embodied in the ISO/TS 21219 series and it comprises many parts that cover 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 Parts 2, 3, 4 and the conversion to two current physical
formats: binary and XML; others could 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, that forms the Annex for each physical format.
TPEG2 has a three container conceptual structure: Message Management (Part 6), Application (many
Parts) and Location Referencing (Part 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:
— Toolkit parts: TPEG2-INV (part 1), TPEG2-UML (part 2), TPEG2-UBCR (part 3), TPEG2-
UXCR (part 4), TPEG2-SFW (part 5), TPEG2-MMC (part 6), TPEG2-LRC (part 7);
— Special applications: TPEG2-SNI (part 9), TPEG2-CAI (part 10);
— Location referencing: TPEG2-ULR (part 11), TPEG2-ETL (part 20), TPEG2-GLR (part 21), TPEG2-
OLR (part 22);
— Applications: TPEG2-PKI (part 14), TPEG2-TEC (part 15), TPEG2-FPI (part 16), TPEG2-
TFP (part 18), TPEG2-WEA (part 19), TPEG2-RMR (part 23).
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 having both long-term,
unchanging content and highly dynamic content, such as Parking Information.
This Technical Specification is based on the TISA specification technical/editorial version reference:
SP13006/3.2/001
The International Organization for Standardization (ISO) (and/or) International Electrotechnical
Commission (IEC) draws attention to the fact that it is claimed that compliance with this Technical
Specification may involve the use of a patent concerning “the HD Radio Bearer and Linkage Information”
given in 10.5. ISO [and/or] IEC take[s] no position concerning the evidence, validity and scope of this
patent right.
The holder of this patent right has ensured the ISO (and/or) IEC that he/she is willing to negotiate
licences under reasonable and non-discriminatory terms and conditions with applicants throughout
the world. In this respect, the statement of the holder of this patent right is registered with ISO (and/or)
IEC. Information may be obtained from the following.
iBiquity Digital Corporation
6711 Columbia Gateway Drive, Suite 500
Columbia, MD 21046
USA
viii © ISO 2016 – All rights reserved

TECHNICAL SPECIFICATION ISO/TS 21219-9:2016(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 part of ISO/TS 21219 establishes the method of delivering service and network information within
a TPEG service. The TPEG-SNI application is designed to allow the efficient and 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.
NOTE A number of tables of information are described, which provide comprehensive options for describing
services, their timing, content, geographical coverage, etc. In all TPEG streams, it is mandatory to deliver to so-
called GST. Additionally, it is possible to signal linkage of content between different bearers and services.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
ISO/TS 21219-3, Intelligent transport systems - Traffic and travel information (TTI) via transport protocol
experts group, generation 2 (TPEG2) — Part 3: UML to binary conversion rules
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
1)
IETF RFC 1738, Uniform Resource Locators (URL)
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
guide to the service tables
GST
basic service (3.10) information such as service structure, service timing and content description (3.4), etc.
3.2
fast tuning GST
FT-GST
directory of the applications (3.11) and content (3.12) of the service (3.10) 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.
1) RFC 1738 can be found at http://www.ietf.org/rfc/rfc1738.txt
3.3
time schedule GST
TS-GST
indicates the operation times of selected service components (3.16)
3.4
content description GST
CD-GST
optional table that gives the textual descriptions of selected service components (3.16)
3.5
geographical coverage GST
GC-GST
optional table that defines the spatial range of selected service components (3.16)
3.6
service component reset GST
SCR-GST
optional table that is used by the service provider (3.14) to delete application-specific data older than a
certain moment
3.7
conditional access information reference GST
CAI-GST
optional table that is used by the service provider (3.14) to indicate which service component (3.16)
carries the CAI application data required to decode encrypted service components
3.8
versioning of TPEG applications GST
VER-GST
mandatory table that is used by the service provider (3.14) to indicate which version of the application
specification the service component (3.16) complies to
3.9
number of messages within a TPEG service component
NOM-SIT
optional table that is used to transmit the number of messages currently available for each service
component (3.16)
3.10
service
collection of different information streams [applications (3.11)] logically bound together and delivered
from a service provider (3.14) to the end user
3.11
application
stream of information that by itself provides a benefit to (i.e. can be “applied by”) the end user
3.12
content
information inside an application (3.11)
Note 1 to entry: A service (3.10) may contain several instances of the same application type, each containing
different content. Within an application, different content is labelled with a unique content ID (COID) specified by
the originator of the content.
3.13
application instance
actual data stream containing content (3.12) as defined by an application (3.11)
2 © ISO 2016 – All rights reserved

3.14
service provider
organization that provides information a [service (3.10)] to end users and manages the content (3.12) of
its service and decides whether a service is encrypted or not
Note 1 to entry: A service provider that generates the content of a service is called a service originator. A service
provider that carries content generated by another originator is called the carrier. There is only one service
originator of content, but there may be more than one service carrier.
3.15
content originator
original provider of an application instance (3.13)
Note 1 to entry: The content originator may distribute the application (3.11) data to different service providers
(3.14). In some cases, the service provider generates its own application data and is therefore also the content
originator.
3.16
service component
information stream [application (3.11)] that is part of a service (3.10)
Note 1 to entry: A TPEG stream is logically divided into parts known as service components. Each service
component carries an application instance (3.13). A service component is effectively a “channel” within the
multiplex of a TPEG stream. Each stream comprises a number of these “channels” which are identified by the
component identifier in TPEG2-SFW and linked to the COID and AID in the TPEG2-SNI application.
3.17
service identification
worldwide unique identifier for a service (3.10)
Note 1 to entry: It consists of three elements called SID A, SID-B, SID-C (cf. subclause 0). These are allocated as
described in ISO/TS 18234-2.
3.18
content identification
COID
identifier that is unique within a given application (3.11) and used to specify its content (3.12)
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.19
application and content identification
ACID
worldwide unique identifier that defines the content (3.12) of a service (3.10)
Note 1 to entry: The ACID is composed of the originator service identification (SID-A, SID-B, SID-C) (3.17), the
content identification (COID) (3.18) and the application identification (AID) (3.20).
3.20
application identification
AID
identifier that specifies how to process TPEG content (3.12) and route information to the appropriate
application decoder
Note 1 to entry: Each TPEG application has a unique number, which identifies the application (3.11) according
to Clause 5. The application identification is part of the TPEG specification and is defined as and when new
applications are developed.
3.21
service component identification
SCID
unique identifier that defines a service component within a service (3.10)
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.22
service table
table containing basic service information, such as service structure, service timing and content
description (3.4), etc.
4 Abbreviated terms
AID Application Identification
ACID Application and Content Identifier
ADC Application Data Container
CAI Conditional Access Information
CEN Comité Européen de Normalization
COID Content Identification
DAB Digital Audio Broadcasting
DARC Data Radio Channel - an FM sub-carrier system for data transmission
DVB Digital Video Broadcasting
EBU European Broadcasting Union
ETSI European Telecommunications Standards Institute
GST Guide to Service Tables
INV Introduction, Numbering and Versions (see TPEG2-INV - ISO/TS 21219-1)
IPR Intellectual Property Right(s)
ISO International Organization for Standardization
LHW Local Hazard Warning
LRC Location Reference Container
MMC Message Management Container
OSI Open Systems Interconnection
PTI TPEG1-PTI Public Transport Information (see ISO 18234-5)
RTM TPEG1-RTM Road Traffic Message application (see ISO 18234-4)
SCID Service Component Identification
SFW TPEG Service Framework: Modelling and Conversion Rules
SID Service Identification
SIT Service Information Table
SNI Service and Network Information application (this Technical Specification)
STI Status and Travel-time Information (proposed TPEG application)
tba to be announced
TEC Traffic Event Compact
TISA Traveller Information Services Association
TPEG Transport Protocol Expert Group
TTI Traffic and Traveller Information
4 © ISO 2016 – All rights reserved

UML Unified Modelling Language
UTC Coordinated Universal Time
WEA Weather Information Application
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 Identification (AID). An AID is defined whenever a new application is developed
and these are all listed in TPEG2-INV.
The application identification number is used within the TPEG2-SNI application to indicate how to
process TPEG content and 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 may have an impact on client devices.
The version numbering principle is defined in TPEG2-SNI.
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 2
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 complies with the UXCR Specification TPEG2-UXCR and is hence fully TPEG2 compliant. For
the binary physical format, the TPEG1 compliance was mandatory, to allow 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 TPEG2-UBCR. 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
TPEG2-SNI.
Each SNI component should appear only at most once 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.
6 © ISO 2016 – All rights reserved

Service A (national)
Service B (regional)
Service C
(local)
Service D
(local)
Service H (inter -local)
Service F
(local)
Service G
(local)
Service E (regional)
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.
Key
SCID Service Component Identification
SNI Service and Network Information Application
RTM Road Traffic Message Application
PTI Public Transport Information Application
CTT Congestion and Travel Time Information Application (notional future Application)
Figure 3 — Example of the TPEG-SNI application in a TPEG data-stream
6.3 Concept of allocating services
Figure 4 shows the use of TPEG Application names and AIDs.
SNI = Service and Network Information Application AID = 0000
RTM = Road Traffic Message Application AID = 0001
PTI = Public Transport Information Application AID = 0002
CTT = Congestion and Travel Time Application AID = 0005 (notional future application code)
WEA = Weather Information Application AID = 0033 (notional future application code)
8 © ISO 2016 – All rights reserved

Key
SID Service Identification (with three parts: -A, -B, -C)
COID Content Identification
AID Application Service Component Identification Identification
SCID Service Component Identification
Figure 4 — Example of service allocation on a wideband bearer
Use of the Service ID.
There are two instances where Service Identification is used.
— Originator SID (SID-A, SID-B, SID-C): This is the service identification of the service provider who
generates the content.
— Carrier SID (SID-A, SID-B, SID-C): This is the service identification of the service provider who is
delivering the service at the service frame level (see TPEG2-SFW).
Application names and AIDs:
SNI = Service and Network Information Application AID = 0000
RTM = Road Traffic Message Application AID = 0001
PTI = Public Transport Information Application AID = 0002
WEA = Weather Information Application AID = 0033 (notional future application code)
The following Figure 5 shows an example for the use of the SID and AID.
Key
SID Service Identification (with three parts: -A, -B, -C)
COID Content Identification
AID Application Service Component Identification Identification
SCID Service Component Identification
Figure 5 — Example of service allocation on a narrowband bearer
6.4 General rules for the TPEG-SNI application
The following rules for the allocation of services by the service provider on one single bearer are
elaborated.
— 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 guide to the Service Table is mandatory within the SNI.
— The service component identifier (SCID) identifies the combination of an application and its content
within a service.
— The application IDs are standardized by ISO/TS 18234-1.
— The content identification (COID) is used for specifying the content of a component within a service.
— The originator service identification (SID-A, SID-B, SID-C), content identification (COID) and
application identification (AID) together form the application and content identification (ACID)
which uniquely identifies the same content worldwide.
— The application and content identification (ACID) is associated with the service component
identification (SCID) within a service.
10 © ISO 2016 – All rights reserved

— Some instances of a service are equivalent, but not necessarily identical. For example, the same service
may be distributed on different bearers with different service component identifications (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 never 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.
class SNI - Serv ice and Network Information
SNI1Template
CurrentServiceInformation SubscriberInformation HelpInformation LinkageToSameService
+ serviceName: ShortString + subscriberData: ByteField + helpText: ShortString + tableVersion: IntUnTi
+ serviceDescription: ShortString + tableEntry: SameServiceEntry [1.255]
Serv iceLogo FreeTextInformation GST_GuideToServiceTables LinkageToRelatedServ ice
+ graphicType: sni001:GraphicType + freeText: ShortString + tableVersion: IntUnTi
+ graphicData: ByteField + tableEntry: RelatedServiceEntry [1.255]
SIT_ServiceInformationTables
Figure 6 — SNI message structure
8 SNI Message components
8.1 SNI1Template
8.1.1 General
The service and network information application does not use the typical TPEG message management,
but instead provides various components to necessary to decode a TPEG service. For compliance with
the UML modelling rules (TPEG2-UMR), an abstract “SNI1Template” has been introduced to provide the
anchor point for th
...