ISO/TS 18234-3:2006

TECHNICAL ISO/TS
SPECIFICATION 18234-3
First edition
2006-06-01
Traffic and Travel Information (TTI) — TTI
via Transport Protocol Expert Group
(TPEG) data-streams —
Part 3:
Service and Network Information (SNI)
application
Informations sur le trafic et le tourisme (TTI) — Messages TTI via les
flux de données du groupe d'experts du protocole de transport
(TPEG) —
Partie 3: Application de service et d'information de réseau

Reference number
©
ISO 2006
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO 2006
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2006 – All rights reserved

Contents Page
Foreword. iv
Introduction . v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions. 2
4 Abbreviations . 4
5 Application identification. 6
6 Conceptual model. 6
6.1 Conceptual model — Scope . 6
6.2 Conceptual model — Multiplexed applications and services . 7
7 Design principle . 8
7.1 Variable content referencing . 8
7.2 Example of the TPEG-SNI application in a TPEG data-stream . 9
7.3 Concept of allocating services. 10
7.4 General rules for the TPEG-SNI application . 11
8 Description of SNI data types. 12
8.1 Types for periodic time functions. 12
8.2 Operating time function . 13
8.3 Compound type for geographical coverage . 14
9 Description of basic features . 14
9.1 Service information . 14
9.2 Component information . 16
9.3 Linkage information. 20
10 Coding structure of basic features . 23
10.1 Component frame . 23
10.2 Service and network information component template. 23
10.3 Definition of service information. 23
10.4 Definition of the guide to the service tables . 25
10.5 Definition of the linkage table to the same service components . 27
10.6 Definition of the linkage table to related service components . 29

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.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
In other circumstances, particularly when there is an urgent market requirement for such documents, a
technical committee may decide to publish other types of normative document:
— an ISO Publicly Available Specification (ISO/PAS) represents an agreement between technical experts in
an ISO working group and is accepted for publication if it is approved by more than 50 % of the members
of the parent committee casting a vote;
— an ISO Technical Specification (ISO/TS) represents an agreement between the members of a technical
committee and is accepted for publication if it is approved by 2/3 of the members of the committee casting
a vote.
An ISO/PAS or ISO/TS is reviewed after three years in order to decide whether it will be confirmed for a
further three years, revised to become an International Standard, or withdrawn. If the ISO/PAS or ISO/TS is
confirmed, it is reviewed again after a further three years, at which time it must either be transformed into an
International Standard or be withdrawn.
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.
ISO/TS 18234-3 was prepared by Technical Committee ISO/TC 204, Intelligent transport systems.
ISO/TS 18234 consists of the following parts, under the general title Traffic and Travel Information (TTI) — TTI
via Transport Protocol Expert Group (TPEG) data-streams:
⎯ Part 1: Introduction, numbering and versions
⎯ Part 2: Syntax, Semantics and Framing Structure (SSF)
⎯ Part 3: Service and Network Information (SNI) application
⎯ Part 4: Road Traffic Message (RTM) application
⎯ Part 5: Public Transport Information (PTI) application
⎯ Part 6: Location referencing applications

iv © ISO 2006 – All rights reserved

Introduction
TPEG technology uses a byte-oriented stream format, which may be carried on almost any digital bearer with
an appropriate adaptation layer. TPEG messages are delivered from service providers to end-users, and are
used to transfer application data from the database of a service provider to a user’s equipment.
This document describes the Service and Network Information Application, which provides a means of
informing end-users about all possible services and their content which are considered relevant by a service
provider to either provide continuity of his services or inform the end-user about other related services. As
stated in the design criteria, TPEG is a bearer independent system. Therefore some rules are established for
the relation of information contents of the same service on different bearers. Also the mechanisms for
following a certain service on one single bearer have to be defined. For the client decoder it is essential to find
an adjacent or similar service if it leaves the current reception area. Nonetheless, basic information describing
the service itself is necessary. For the ease of the user, e.g. the service name, the service provider name, the
operating time and many other hints are delivered by the TPEG-SNI application.
Also, general models for the hand-over and the referencing of services are developed and shown in detail. It
is important to note that this Part 3 of CEN ISO/TS 18234 (TPEG-SNI) is closely related to Part 2 (TPEG-SSF)
and so they shall be used together, being dependent upon each other.
The Broadcast Management Committee of the European Broadcast Union (EBU) established the B/TPEG
project group in autumn 1997 with the mandate to develop, as soon as possible, a new protocol for
broadcasting traffic and travel-related information in the multimedia environment. The TPEG technology, its
applications and service features are 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.
One year later in December 1998, the B/TPEG group produced its first public specifications. Two documents
were released. Part 2 (TPEG-SSF, CEN ISO/TS 18234-2) described the Syntax, Semantics and Framing
structure, which will be used for all TPEG applications. Part 4 (TPEG-RTM, CEN ISO/TS 18234-4) described
the first application, for Road Traffic Messages.
CEN/TC 278/WG 4, in conjunction with ISO/TC 204/WG 10, established a project group comprising the
members of B/TPEG and they have continued the work concurrently since March 1999. Since then two further
parts have been developed to make the initial complete set of four parts, enabling the implementation of a
consistent service. Part 3 (TPEG-SNI, CEN ISO/TS 18234-3, this document) describes the Service and
Network Information Application, which is likely to be used by all service implementations to ensure
appropriate referencing from one service source to another. Part 1 (TPEG-INV, CEN ISO/TS 18234-1)
completes the work, by describing the other parts and their relationships; it also contains the application IDs
used within the other parts.
In April 2000, the B/TPEG group released revised Parts 1 to 4, all four parts having been reviewed and
updated in the light of initial implementation results. Thus a consistent suite of specifications, ready for wide
scale implementation, was submitted to the CEN/ISO commenting process.
In November 2001, after extensive response to the comments received and from many internally suggested
improvements, all four parts were completed for the next stage: the Parallel Formal Vote in CEN and ISO. But
a major step forward has been to develop the so-called TPEG-Loc location referencing method, which
enables both map-based TPEG-decoders and non map-based ones to deliver either map-based location
referencing or human readable information. Part 6 (TPEG-Loc, CEN ISO/TS 18234-6) is now a separate
specification and is used in association with the other parts of CEN ISO/TS 18234 to provide comprehensive
location referencing. Additionally Part 5, the Public Transport Information Application (TPEG-PTI, CEN
ISO/TS 18234-5), has been developed and been through the commenting process.
This Technical Specification, CEN ISO/TS 18234-3, provides a full specification for the Service and Network
Information Application.
During the development of the TPEG technology a number of versions have been documented and various
trials implemented using various versions of the specifications. At the time of the publication of this Technical
Specification, all parts are fully inter-workable and no specific dependencies exist. This Technical
Specification has the technical version number TPEG-SNI_3.0/002.

vi © ISO 2006 – All rights reserved

TECHNICAL SPECIFICATION ISO/TS 18234-3:2006(E)

Traffic and Travel Information (TTI) — TTI via Transport
Protocol Expert Group (TPEG) data-streams —
Part 3:
Service and Network Information (SNI) application
1 Scope
This Technical Specification 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.
The term “application” is used in TPEG specifications to describe specific applications, which are at the
highest layer of the ISO/OSI protocol stack (ISO/IEC 7498-1). Each TPEG application (e.g. TPEG-RTM) is
assigned a unique number that is called the Application IDentification (AID). An AID is defined whenever a
new application is developed. The AID is used within the TPEG-Service and Network Information Application
(this document) to indicate how to process TPEG content and allows routing of data to an appropriate
application decoder.
AID = 0000 is assigned to the TPEG-SNI application, described in this specification.
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 referenced documents are indispensable for the application 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.
CEN ISO/TS 18234-1, Traffic and Travel Information (TTI) — TTI via Transport Protocol Expert Group (TPEG)
data-streams — Part 1: Introduction, Numbering and Versions
CEN ISO/TS 18234-2, Traffic and Travel Information (TTI) — TTI via Transport Protocol Expert Group (TPEG)
data-streams – Part 2: Syntax, Semantics and Framing Structure (SSF)
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
IEC 62106, Specification of the radio data system (RDS) for VHF/FM sound broadcasting in the frequency
range from 87,5 to 108,0 MHz
ETSI EN 300 751, Radio broadcasting systems; System for Wireless Infotainment Forwarding and
Teledistribution (SWIFT)
ETSI EN 300 468, Digital Video Broadcasting (DVB); Specification for Service Information (SI) in DVB
systems
ISO/IEC 7498-1, Information technology — Open Systems Interconnection — Basic Reference Model: The
Basic Model
RFC 1738, Uniform Resource Locators (URL)
3 Terms and definitions
For the purpose of this Technical Specification, the following terms and definitions apply.
3.1
guide to the service tables (GST)
the guide to the service table (GST) carries the basic service information such as service structure, service
timing and content description, etc.
3.1.1
fast tuning GST (FT-GST)
This is a directory of the applications and content of the service and indicates in which components the
relevant information can be found. This contains the minimum set of information required for the acquisition of
application data
3.1.2
time schedule GST (TS-GST)
this optional table indicates the operation times of selected service components
3.1.3
content description GST (CD-GST)
this optional table gives the textual descriptions of selected service components
3.1.4
geographical coverage GST (GC-GST)
this optional table defines the spatial range of selected service components
3.1.5
service component reset GST (SCR-GST)
this optional table is used by the service provider to delete application specific data older than a certain
moment
3.2
service
a service comprises one or more applications; a service is a defined flow (from the service provider) of
information meant for either the general public or a special target group
3.3
service provider
the service provider manages the content of his service(s) and determines the TPEG applications in use and
their content. The service provider also decides whether a service is encrypted or not
— the service provider that generates the content of a service is called the originator,
— the service provider that carries content generated by another originator is called the carrier,
— there is only one originator of content but there may be more than one alternative carrier

RFC 1738 can be found at http://www.ietf.org/rfc/rfc1738.txt
2 © ISO 2006 – All rights reserved

3.4
application
the application is used to describe a specific part (e.g. TPEG-RTM) of the TPEG specifications
3.5
content
the content is the information inside an application. A service 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.6
application instance
an application instance is an actual data stream containing content as defined by an application
3.7
content originator
the content originator is the original provider of an application instance. 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
service component
a TPEG stream is logically divided into parts known as service components. Each service component carries
an application instance. 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 CEN
ISO/TS 18234-2 (TPEG-SSF) and linked to the COID and AID in the TPEG-SNI application
3.9
service identification (SID-A, SID-B, SID-C)
the service identification is a worldwide unique identifier for a service. It consists of three elements called
SID-A, SID-B, SID-C. These are allocated as described in CEN ISO/TS 18234-2
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 CEN/ISO/TS 18234-2, sections 7.3 and 7.3.2.1)
3.10
content identification (COID)
the content identification (COID) is used for labelling the content of a component. The COID is defined by the
originator of the content and is unique within a specific application
3.11
application and content identification (ACID)
the application and content identification uniquely identifies the content on a worldwide basis and is composed
of the originator service identification (SID-A, SID-B, SID-C), the content identification (COID) and the
application identification (AID)
3.12
application identification (AID)
the AID indicates how to process TPEG content and routes information to the appropriate application decoder.
Each TPEG application has a unique number, which identifies the application according section 5. The
application identification is part of the TPEG specification and is defined as and when new applications are
developed
3.13
service component identification (SCID)
the SCID uniquely identifies a service component within a service and is chosen by the carrier service
provider. It 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
4 Abbreviations
For the purposes of this Technical Specification, the following abbreviations apply.
4.1
AID
Application Identification
4.2
ACID
Application and Content Identification
4.3
BPN
Broadcast, Production and Networks (an EBU document publishing number system)
4.4
B/TPEG
Broadcast/TPEG (the EBU project group name for the specification drafting group)
4.5
CEN
Comité Européen de Normalisation
4.6
COID
Content Identification
4.7
DAB
Digital Audio Broadcasting
4.8
DARC
Data Radio Channel - an FM sub-carrier system for data transmission
4.9
DVB
Digital Video Broadcasting
4.10
EBU
European Broadcasting Union
4.11
ETSI
European Telecommunications Standards Institute
4.12
GST
Guide to Service Tables
4 © ISO 2006 – All rights reserved

4.13
INV
Introduction, Numbering and Versions (see CEN ISO/TS 18234–1)
4.14
IPR
Intellectual Property Right(s)
4.15
ISO
International Organization for Standardization
4.16
OSI
Open Systems Interconnection
4.17
PTI
Public Transport Information (see CEN ISO 18234-5)
4.18
RTM
Road Traffic Message application (see CEN ISO 18234-4)
4.19
SCID
Service Component Identification
4.20
SID
Service Identification
4.21
SNI
Service and Network Information application (this specification)
4.22
SSF
Syntax, Semantics and Framing Structure (see CEN ISO/TS 18234-2)
4.23
STI
Status and Travel-time Information (proposed TPEG application)
4.24
tba
to be announced
4.25
TPEG
Transport Protocol Experts Group
4.26
TTI
Traffic and Travel Information
4.27
UTC
Coordinated Universal Time
4.28
WEA
Weather Information (proposed TPEG application)
5 Application identification
The word 'application' is used in the TPEG specifications to describe specific applications, which are at the
highest layer of the ISO/OSI model as defined in ISO 7498-1. 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 CEN ISO/TS 18234-1.
The application identification number is used within the TPEG-SNI application to indicate how to process
TPEG content and facilitates the routing of information to the appropriate application decoder.
Since TPEG-SNI is itself classed as an application, it is assigned the AID = 0000.
6 Conceptual model
6.1 Conceptual model — Scope
The Service and Network Information (SNI) application was developed to facilitate the navigation through
several services distributed over different bearers. This enables the end-user to find a chosen service and
information on it. It also allows the possibility of switching between similar and related services transmitted on
the same or on several bearers. Information concerning the operation time, the content description, the
availability or access conditions, is also provided by the SNI application. These features allow a quick and
easy selection of a specific service.
From a technical viewpoint the TPEG-SNI application manages the tuning to, and the tracking of, a TPEG
service automatically. By means of suitable decoder equipment, the only action for the end-user is the
selection of his desired service from the many different services on different bearers.
In detail the following requirements are met:
— The SNI application enables a quick search for a specific service.
— The SNI application gives information about transmission times and repetition cycles of a service.
— The SNI application provides the tuning (identification) parameters for the underlying digital bearers.
— The SNI application supports the tracking of a service from one network or system to another.
— The SNI application enables the linkage of one service to another on the same bearer.
— The SNI application can also link services across different digital bearers.
— The SNI application manages the interaction of all other TPEG applications.
6 © ISO 2006 – All rights reserved

6.2 Conceptual model — Multiplexed applications and services
Figure 1 illustrates the conceptual model of the SNI application.

Figure 1 — Multiplexed applications and services
7 Design principle
7.1 Variable content referencing
Figure 2 contains a diagrammatic representation of the use of SCIDs in related services.

Figure 2 — Diagrammatic representation of the use of SCIDs in related services
8 © ISO 2006 – All rights reserved

7.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
7.3 Concept of allocating services
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)

Key
SID = Service Identification (with three parts: -A, -B, -C)
COID = Content Identification
AID = Application Identification
SCID = Service Component Identification
Figure 4 — Example of service allocation on a wideband bearer
10 © ISO 2006 – All rights reserved

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)

Key
SID = Service Identification (with three parts: -A, -B, -C)
COID = Content Identification
AID = Application Identification
SCID = Service Component Identification
Figure 5 — Example of service allocation on a narrowband bearer
7.4 General rules for the TPEG-SNI application
Some rules for the allocation of services by the service provider on one single bearer are elaborated:
a) For every service the service and network Information is mandatory.
b) The SNI application shall only occur once within a service and has the reserved SCID of 00.
c) The fast tuning guide to the service table is mandatory within the SNI.
d) The service component identifier (SCID) identifies the combination of an application and its content within
a service.
e) The application IDs are standardized by CEN ISO/TS 18234-1.
f) The content identification (COID) is used for specifying the content of a component within a service.
g) 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.
h) The application and content identification (ACID) is associated with the service component identification
(SCID) within a service.
i) 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.
j) Each SNI component (e. g. GST time schedule, linkage table, etc.), shall never occur more than once in
each SNI component frame.
8 Description of SNI data types
8.1 Types for periodic time functions
8.1.1 Masked time
This type expresses fixed date and time information.
Each byte can have a zero value meaning that the signalled event occurs periodically in this range. The value
zero is reserved for indicating repetition, therefore 1 has to be added to the hours, minutes and seconds.
The start year is therefore the year 2000 (2000-1999 = 1).
The first usage of the year element in the masked time function will thus not be before the year 2000.
The next box shows the changed type, the right hand column gives the formula how to get
the type element (e.g. hour) from the real value:
So two functions are available simultaneously: Pointing to a specific time and indicating a repeating event.
EXAMPLE 1   = 01 0C 00 0F 1F 01 hex - Meaning: The event starts every day in December 2000 at
14 hrs. 30 min. and 00 sec.
EXAMPLE 2   = 00 00 0B 00 2E 38 hex - Meaning: The event starts every year, every month, on the
11th day of the month, every hour, 45 min. and 55 sec. after the full hour.
:= : Masked time
, : Year,  0 : any; 1.255 : Year-1999
,
: Month,  0 : any; 1.12  : Month
, : Day,  0 : any; 1.31  : Day
, : Hour,  0 : any; 1.24  : Hour+1
,
: Min,  0 : any; 1.60  : Min+1
; : Sec,  0 : any; 1.60  : Sec+1

8.1.2 Start time
This type is a compound element and is helpful to indicate the start time and also the repeatability of an event
at the same time.
12 © ISO 2006 – All rights reserved

IMPORTANT: All time information is absolute and always referenced to UTC. For example an event in China
is repeated every Tuesday and Friday at 06.00 hrs. This leads automatically to a change of the
value (see CEN ISO/TS 18234-2, section 6.1.2.2), becoming Monday and Thursday. Also the
value must change according to the China time zone offset in relation to UTC. All receiving
clients shall “know its local time offset”, thus allowing it to convert all time information to the format that the
end-user expects.
:= : Start time of an application
,
: At what time and date
; : At which day of the week

NOTE The day in the masked time can be set along with the day mask. The resulting start time will be the first day of
the day mask on or after the specified day in the masked time.
st nd
EXAMPLE  Assume the 1 of July is a Thursday. If the masked time indicates the 2 of July and the day mask is
th th
Monday and Tuesday, then the resulting start time is Monday the 5 of July. The next occurrence is then Tuesday the 6 .
8.1.3 Time slot
This compound type allows to indicate start time, repetition and duration of an event in one.
:=
: Time, repetition, duration of an application
, : At what time and date
; : How long it lasts

8.2 Operating time function
8.2.1 Operating time
This time element consists of the start and stop time of a service component within a specificapplication. The
start and stop time is transmitted as an absolute UTC value to be independent from any other vague time
description (e.g. one hour after midday). The service provider may use this time information to announce the
next occurrence of a component of a certain service.
The decoder then can tell the end-user what he might expect in the near future. To take full advantage of this
function six cases are distinguished in Table 1:
Table 1 — Operating time
# Condition Explanation Meaning
Component of the service starts and ends in the future Default situation
1 T <= T <= T
p   s  e
Component of the service has already started and ends in the future Programme is running
2 T <= T <= T
s   p  e
Component of the service was transmitted, change to condition 1 Programme is over
3 T <= T <= T
s   e p
expected
Same as condition 2, but next start time is already announced Programme is running
4 T <= T <= T
p   e  s
This condition indicates that a new service will be established New programme in the future
5 T < = T <= T
e  p  s
This condition indicates that a service has been abandoned Old programme dropped
6 T <= T <= T
e  s   p
The time descriptors have the following meaning:
T : Present or current time, i.e. the actual time that changes continuously
p
T : Start time of a component within an application, fixed by the service provider
s
T : End (stop) time of a component within an application, fixed by the service provider
e
:= : Operating time
,
: Next start date and time
; : Next stop date and time

8.3 Compound type for geographical coverage
This basic type is needed to define an area, to which a specific service component is allocated. This feature
only makes sense if the application that uses that service component has a relation to a certain coverage area.
Type definition:
:= : Definition of rectangular coverage area
,
: North-west corner of rectangle
; : South-east corner of rectangle

NOTE Notional rectangle on a flat map.
:=
: Definition of the corner of rectangular
, : WGS 84 Longitude in units of 0,01 degrees
; : WGS 84 Latitude in units of 0,01 degrees

Table 2 — Numerical presentation of the coordinates
Range of Type Min. value Max. value Resolution Resolution Remarks
[deg] [km]
Decimal range of : - 32 768 + 32 767 N/A N/A
Decimal range for Longitude: - 18 000 + 18 000 N/A N/A
Range of Longitude in - 180,00 +180,00 0,01 1,08 Resolution [km] constant
degrees:
Decimal range for Latitude: - 9 000 + 9 000 N/A N/A
Range of Latitude in degrees: - 90,00 + 90,00 0,01 1,08 Resolution [km] variable

NOTE See CEN ISO/TS 18234-4 for a full description on forming Spatial Descriptors.
9 Description of basic features
9.1 Service information
9.1.1 Service name and service description
Table 3 — Service name
1. Name: Service name
2. Function: Identifies the service by a label, comparable to PS in RDS
3. Occurrence: Mandatory, general
4. Description: Identifies the service to a human being
5. Format: Short string, maximum 255 characters (label)
6. Example: “BBC 2 – TPEG Service”
14 © ISO 2006 – All rights reserved

Table 4 — Service description
1. Name: Service description
2. Function: Describes in more detail the content of a service
3. Occurrence: Mandatory, general
4. Description: Identifies the applications and scope thereof within a
service
5. Format: Short string, maximum 255 characters (label)
6. Example: “Local and interurban road traffic information combined with
public transport information for South-East England ”
9.1.2 Service logo
Table 5 — Service logo
1. Name: Service logo
2. Function: Promotes the service or provider
3. Occurrence: Optional, multiple
4. Description: Graphical identification of the service or the service provider
5. Format: Has to be defined as picture
6. Example: Bitmap or other format

9.1.3 Subscriber information
This section describes additional payment and encryption information delivered to the end-user. This
information is not vital 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.
Table 6 — Subscriber information
1. Name: Subscriber information
2. Function: Gives information about payment and tariffs for restricted service components
3. Occurrence: In any encrypted or potentially encrypted service component
4. Description: Helps the end-user to choose or select between chargeable services
5. Format: Byte field defined by the service provider
6. Example: Will be added later

9.1.4 Free text information
In this section more textual information for the end-user is defined. This information is not mandatory.
Table 7 — Free text information
1. Name: Free text information
2. Function: Additional information, that is not coded and therefore language dependent
3. Occurrence: Optional, selected by the service provider
4. Description: Possibility to transmit additional information for the end-user
5. Format: Short string, maximum 255 characters
6. Example: Announcement of service disruption, disclaim information, legal advice

9.1.5 Help information
In this section more textual information for the end-user is defined. This information is not mandatory.
Table 8 — Help information
1. Name: Help information
2. Function: Additional information that gives addresses to which the user can apply to
3. Occurrence: Optional, selected by the service provider
4. Description: A link between the user and the service provider for feed back
5. Format: Short string, maximum 255 characters
6. Example: Internet address, Hotline number, Helpdesk

9.2 Component information
This section mainly describes the guide to the service tables.
The guide to the service table (GST) consists of five parts that carry the basic service information being 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.
9.2.1 Guide to the service table 1 (fast tuning)
9.2.1.1 Description of table
Service table 1 is mandatory. All service components need to be defined in this table. The same SCID may
never occur more than once within this table.
Table 9 — Guide to service table 1 (fast tuning)
Table 1 Fast Tuning GST (Guide to the Service Table)
Version Number :
Range: 0.255, Incremented, if any of the entries is changed,  Type:
Character table identifier:
Default character table for the current service,   Type:

# 1 2 3 4
Name: Service Application and Content Identifier (ACID): Next operating Encryption
Component time: Indicator:
Identification
Originator Service Content Application

(SCID):
Identification: Identification: Identification:
(SID-A, SID-B, SID-C)
(COID) (AID)
Transmission: Mandatory Optional Mandatory Mandatory Optional Optional

Default: Carrier Service From the year 0 = Non

Identification, 1970 to 2106 encrypted
because the
content originates
from the carrier
Element 3 *
Structure: 1 Byte 3 Bytes 1 Byte 2 Bytes 8 Bytes 1 Byte

9.2.1.2 Character table identifier
The character table identifier is valid for the whole service including the SNI application itself. The character
table identifier belongs to the basic service features and is therefore integrated into the guide to the service
table.
If the is invalid or unknown to the receiver, it should assume that the equals 1.
9.2.1.3 Originator service identification
The originator service identification needs to be specified when the carrier service provider is not the originator
of the content of the related service component.
16 © ISO 2006 – All rights reserved

If the carrier service provider is also the originator of the content of the related service component then it is not
necessary to indicate the service identification in this column. In this case the default is the carrier service
provider.
9.2.1.4 Encryption indicator
In the service frame of the TPEG frame structure an encryption indicator is already defined for encrypting at
the service frame level. If this mechanism is used all underlying levels including the SNI data is “hidden”.
There is another encryption possibility in the SNI application at the service component level. Individual service
components may or may not be encrypted. This is indicated in the fast tuning GST. The SNI service
component (00) cannot be encrypted at this level. Where encryption is applied to a service component then
encryption shall not be applied to its SCID, field length and the header CRC of the service component frame.
The encryption indicator in the fast tuning GST is of the same type as defined in the CEN/ISO/TS 18234-2,
section 7.3.2.2.
9.2.1.5 Use 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 will change, the version number in all tables shall be incremented.
EXAMPLE   Table 10 shows a very simple example of a GST fast tuning table, having 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 10 — Simple example of a GST tuning table
...