ISO/TS 18234-3:2013

TECHNICAL ISO/TS
SPECIFICATION 18234-3
Second edition
2013-02-01
Intelligent transport systems — Traffic
and travel information via transport
protocol experts group, generation 1
(TPEG1) binary data format —
Part 3:
Service and network information
(TPEG1-SNI)
Systèmes intelligents de transport — Informations sur le trafic et le
tourisme via les données de format binaire du groupe d'experts du
protocole de transport, génération 1 (TPEG1) —
Partie 3: Informations relatives aux services et au réseau (TPEG1-SNI)

Reference number
©
ISO 2013
©  ISO 2013
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 2013 – All rights reserved

Contents Page
Foreword . v
Introduction . vii
1  Scope . 1
2  Normative references . 1
3  Terms and definitions . 2
4  Abbreviations . 4
5  Application identification. 5
6  Conceptual model . 5
6.1  Scope . 5
6.2  Multiplexed applications and services . 6
7  Design principle . 7
7.1  Variable content referencing . 7
7.2  Example of the TPEG-SNI application in a TPEG data-stream . 7
7.3  Concept of allocating services . 8
7.4  General rules for the TPEG-SNI application . 10
8  Description of SNI Data Types . 11
8.1  Types for periodic time functions . 11
8.1.1  Masked time . 11
8.1.2  Start time . 11
8.1.3  Time slot . 12
8.2  Operating time function . 12
8.2.1  Operating time . 12
8.3  Compound type for geographical coverage . 13
9  Description of basic features . 14
9.1  Service information . 14
9.1.1  Service name and service description . 14
9.1.2  Service logo . 14
9.1.3  Subscriber information . 14
9.1.4  Free text information . 15
9.1.5  Help information . 15
9.2  Component information . 15
9.2.1  Guide to the Service Table 1 (fast tuning) . 16
9.2.2  Guide to the Service Table 2 (time schedule) . 17
9.2.3  Guide to the Service Table 3 (content description) . 18
9.2.4  Guide to the Service Table 4 (geographical coverage) . 18
9.2.5  Guide to the Service Table 5 (service component reset) . 19
9.2.6  Service Table accelerator . 19
9.2.7  Guide to the Service Table 6 (Conditional Access Information Reference) . 19
9.2.8  Guide to the Service Table 7 (Versioning) . 20
9.3  Linkage information . 21
9.3.1  Linkage information to the components of the same service . 21
9.3.2  Linkage information to the components of related services . 23
9.4  Service Information Tables . 24
9.4.1  Service Information Table 1 (Number of Messages) . 24
10  Coding structure of basic features . 25
10.1  Component frame . 25
10.2  Service and network information component template . 25
10.3  Definition of service information .26
10.3.1  Definition of service name and service description .26
10.3.2  Coding of the service logo .26
10.3.3  Subscriber information .26
10.3.4  Free text information .27
10.3.5  Help information .27
10.4  Definition of the guide to the Service Tables .27
10.4.1  Guide to the Service Table 1 (fast tuning) .27
10.4.2  Guide to the Service Table 2 (time schedule) .27
10.4.3  Guide to the Service Table 3 (content description) .28
10.4.4  Guide to the Service Table 4 (geographical coverage) .28
10.4.5  Guide to the Service Table 5 (service component reset) .28
10.4.6  Service Table accelerator .29
10.4.7  Guide to the Service Table 6 (Conditional Access Information) .29
10.4.8  Guide to the Service Table 7 (Versioning) .29
10.5  Definition of the linkage table to the same service components .30
10.6  Definition of the linkage table to related service components .32
10.7  Service Information Table 1 (Number of Messages) .33
Bibliography .34

iv © ISO 2013 – 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.
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 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 the European Committee for Standardization (CEN) Technical Committee
CEN/TC 278, Road transport and traffic telematics, in collaboration with ISO Technical Committee TC 204,
Intelligent transport systems in accordance with the Agreement on technical cooperation between ISO and
CEN (Vienna Agreement).
This second edition cancels and replaces the first edition (ISO/TS 18234-3:2006), which has been technically
revised.
ISO/TS 18234 consists of the following parts, under the general title Intelligent transport systems — Traffic
and Travel Information (TTI) — TTI via Transport Protocol Expert Group (TPEG) data-streams:
 Part 1: Introduction, numbering and versions (TPEG1-INV)
 Part 2: Syntax, Semantics and Framing Structure (SSF)
 Part 3: Service and network information (TPEG1-SNI)
 Part 4: Road Traffic Message (RTM) application
 Part 5: Public Transport Information (PTI) application
 Part 6: Location referencing applications
1)
 Part 7: Parking Information (TPEG-PKI)
2)
 Part 8: Congestion and travel-time application (TPEC1-CTT)
3)
 Part 9: Traffic event compact (TPEG1-TEC)
4)
 Part 10: Conditional access information (TPEG1-CAI)
 Part 11: Location Referencing Container (TPEG1-LRC)

1) To be published.
2) To be published.
3) To be published.
4) To be published.
vi © ISO 2013 – All rights reserved

Introduction
TPEG technology uses a byte-oriented data 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
used to transfer information from the database of a service provider to an end-user’s equipment.
The brief history of TPEG technology development dates back to the European Broadcasting Union (EBU)
Broadcast Management Committee establishing 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. 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 EBU specifications. Two documents
were released. Part 2 (TPEG-SSF, which became ISO/TS 18234-2) described the Syntax, Semantics and
Framing structure, which is used for all TPEG applications. Part 4 (TPEG-RTM, which became
ISO/TS 18234-4) described the first application, for Road Traffic Messages.
Subsequently, 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 were developed to make the initial complete set of four parts, enabling the
implementation of a consistent service. Part 3 (TPEG-SNI, ISO/TS 18234-3) describes the Service and
Network Information Application, which should be used by all service implementations to ensure appropriate
referencing from one service source to another. Part 1 (TPEG-INV, ISO/TS 18234-1), completes the series, by
describing the other parts and their relationship; it also contains the application IDs used within the other parts.
Additionally, Part 5, the Public Transport Information Application (TPEG-PTI, ISO/TS 18234-5), was
developed.
A major step forward was to develop 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. The original issue of ISO/TS 18234-6 described the TPEG-LOC
application in detail and was used in association with the other parts of ISO/TS 18234 series to provide
location referencing.
This update to the first edition of ISO/TS 18234-3 provides additional specifications 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, the original parts are fully inter-workable and no specific dependencies exist.
This Technical Specification has the technical version number TPEG-SNI/3.2/001.

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

Intelligent transport systems — Traffic and travel information
via transport protocol experts group, generation 1 (TPEG1)
binary data format —
Part 3:
Service and network information (TPEG1-SNI)
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 Technical 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.
ISO/TS 18234-1, Traffic and Travel Information (TTI) — TTI via Transport Protocol Expert Group (TPEG)
data-streams — Part 1: Introduction, numbering and versions
ISO/TS 18234-2:2006, Traffic and Travel Information (TTI) — TTI via Transport Protocol Expert Group
(TPEG) data-streams — Part 2: Syntax, Semantics and Framing Structure (SSF)
EN 300 401, Radio broadcasting systems; Digital Audio Broadcasting (DAB) to mobile, portable and fixed
receivers
5)
RFC 1738, Uniform Resource Locators (URL)

5) RFC 1738 can be found at http://www.ietf.org/rfc/rfc1738.txt.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
guide to the Service Tables
GST
guide that carries the basic service information
EXAMPLE Service structure, service timing and content description, etc.
3.1.1
fast tuning GST
FT-GST
directory of the applications and content of the service that indicates in which components the relevant
information can be found
Note 1 to entry: This contains the minimum set of information required for the acquisition of application data.
3.1.2
time schedule GST
TS-GST
optional table that indicates the operation times of selected service components
3.1.3
content description GST
CD-GST
optional table that gives the textual descriptions of selected service components
3.1.4
geographical coverage GST
GC-GST
optional table that defines the spatial range of selected service components
3.1.5
service component reset GST
SCR-GST
optional table that is used by the service provider to delete application specific data older than a certain
moment
3.1.6
Conditional Access Information Reference GST
CAI-GST
optional table that is used by the service provider to indicate which service component carries the CAI
application data required to decode encrypted service components
3.1.7
Versioning of TPEG Applications GST
VER-GST
mandatory table that is used by the service provider to indicate to which version of the application
specification the service component complies
3.1.8
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
2 © ISO 2013 – All rights reserved

3.2
service
defined flow (from the service provider) of information meant for either the general public or a special target
group
Note1 to entry: A service comprises one or more applications.
3.3
service provider
organisation that constructs a data service, by gathering data, processing data and supplying the data service
Note 1 to entry: 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.
3.4
application
specific subset of the TPEG structure that defines a certain type of message
EXAMPLE Parking information or road traffic message information.
3.5
content
information inside an application
Note 1 to entry: 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
actual data stream containing content as defined by an application
3.7
content originator
original provider of an application instance
Note 1 to entry: The content originator may distribute the application data to different service providers. In some cases, the
service provider generates its own application data and is therefore also the content originator.
3.8
service component
“channel” within the multiplex of a TPEG stream with each stream comprising a number of these “channels”
which are identified by the component identifier in ISO/TS 18234-2 (TPEG-SSF) and linked to the COID and
AID in the TPEG-SNI application
Note 1 to entry: Each service component carries an application instance service identification.
3.9
SID-A, SID-B, SID-C
worldwide unique identifier for a service consisting of three elements called SID-A, SID-B, SID-C which are
allocated as described in ISO/TS 18234-2
Note 1 to entry: 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.
Note 2 to entry: See ISO/TS 18234-2:2006, 7.3 and 7.3.2.1.
3.10
content identification
COID
identification that is used for labelling the content of a component
Note 1 to entry: The COID is defined by the originator of the content and is unique within a specific application.
3.11
application and content identification
ACID
identification that uniquely identifies the content on a worldwide basis, 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
identification that indicates how to process TPEG content and routes information to the appropriate application
decoder
Note 1 to entry: Each TPEG application has a unique number, which identifies the application according to Clause 5. The
application identification is part of the TPEG specification and is defined as and when new applications are developed.
3.13
service component identification
CID
identification that uniquely identifies a service component within a service and is chosen by the carrier service
provider
Note 1 to entry: It identifies a component which itself has an ACID comprising originator SID, COID and AID.
Note 2 to entry: 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 document, the following abbreviations apply.
BPN Broadcast, Production and Networks (an EBU document publishing number system)
B/TPEG Broadcast/TPEG (the EBU project group name for the specification drafting group)
CEN Comité Européen de Normalisation
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 [ISO/TS 18234-1]
IPR Intellectual Property Right(s)
4 © ISO 2013 – All rights reserved

ISO International Organization for Standardization
OSI Open Systems Interconnection
PTI Public Transport Information [ISO/TS 18234-5]
RTM Road Traffic Message application [ISO/TS 18234-4]
SCID Service Component Identification
SID Service Identification
SNI Service and Network Information application (this Technical Specification)
SSF Syntax, Semantics and Framing Structure [ISO/TS 18234-2]
STI Status and Travel-Time Information (proposed TPEG application)
TBA To Be Announced
TPEG Transport Protocol Experts Group
TTI Traffic and Travel Information
UTC Coordinated Universal Time
WEA Weather Information Application
CAI Conditional Access Information
SIT Service Information Table
LHW Local Hazard Warning
TEC Traffic Event Compact
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/IEC 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 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 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.2 Multiplexed applications and services
Figure 1 illustrates the conceptual model of the SNI application.

Figure 1 — Multiplexed applications and services
6 © ISO 2013 – All rights reserved

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
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.
TPEG data-stream
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)
8 © ISO 2013 – All rights reserved

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
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
The following are rules for the allocation of services by the service provider on one single bearer:
a) For every service the SNI 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 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.
10 © ISO 2013 – All rights reserved

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), 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 to get the
type element (e.g. hour) from the real value:
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.
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 ISO/TS 18234-2:2006, 6.3.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
; : On 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 indicates start time, repetition and duration of an event in one function.
:= : 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 specific application. 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 can then tell the end-user what he might expect in the near future. To take full advantage of this
function six cases are distinguished as shown in Table 1:
Table 1 — Operating time
# Condition Explanation Meaning
1 T <= T <= T Component of the service starts and ends in the future Default situation
p s e
2 T <= T <= T Component of the service has already started and ends in the Programme is running
s p e
future
3 T <= T <= T Component of the service was transmitted, change to Programme is over
s e p
condition 1 expected
4 T <= T <= T Same as condition 2, but next start time is already announced Programme is running
p e s
5 T < = T <= T This condition indicates that a new service will be established New programme in the future
e p s
6 T <= T <= T This condition indicates that a service has been abandoned Old programme dropped
e s p
The time descriptors have the following meaning:
T : Present or current time, i.e. the actual time that changes continuously;
p
12 © ISO 2013 – All rights reserved

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
Resolution Resolution
Range of Type Min. value Max. value 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 degrees: 180,00 +180,00 0,01 1,08 Resolution [km] constant
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 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”

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.
14 © ISO 2013 – All rights reserved

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
3. Occurrence: Optional, selected by the service provider
4. Description: A link between the user and the service provider for feedback
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 seven 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 the Service Table 1 (fast tuning)
...