ISO/TS 18234-11:2013

Intelligent transport systems - Traffic and Travel Information (TTI) via transport protocol experts group, generation 1 (TPEG1) binary data format - Part 11: Location Referencing Container (TPEG1-LRC)

ISO/TS 18234-11:2013 establishes the method of signalling the specific location referencing used by all TPEG1 applications that require detailed location information to be delivered to client devices such as TPEG1-RTM, TPEG1-PTI, TPEG1-TEC or TPEG1-PKI. The TPEG1-Location Referencing Container (TPEG1-LRC) is described as well as how it is used to signal which specific location referencing method is in use for a particular TPEG Message. It is able to handle Location Referencing methods that are external to the present ISO series and the internal location referencing method (TPEG1-LOC) defined in Part 6 of this series.

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 11: Conteneur de référencement d'emplacement

General Information

• Status: Published
• Publication Date: 14-Jan-2013
• 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: 9093 - International Standard confirmed
• Start Date: 06-Nov-2024
• Completion Date: 13-Dec-2025

Overview

ISO/TS 18234-11:2013 defines the Location Referencing Container (TPEG1-LRC) for TPEG1 - the byte-oriented Traffic and Travel Information (TTI) binary format used in Intelligent Transport Systems (ITS). The Technical Specification standardizes how TPEG1 messages signal which location referencing method is used so detailed location information can be delivered reliably to client devices (for example TPEG1-RTM, TPEG1-PTI, TPEG1-TEC, TPEG1-PKI). TPEG1-LRC supports both the internal TPEG location method (TPEG1-LOC, Part 6) and external location referencing schemes, enabling worldwide interoperability for traffic, travel and navigation services.

Key topics

• Purpose: Signalling the specific location referencing method used in a TPEG message so clients can interpret location data correctly.
• Supported methods: Descriptions and handling for multiple location reference types (examples in the document include DLR1, Korean Node/Link, TMC, TPEG Location/TPEG-LOC, VICS Link, ETL, GLR).
• Message components: Definition of the LocationReferencingContainer, TPEGLocationReference and specific location reference components; list of generic component IDs and how they are encoded.
• Binary format and data types: Annex A provides normative binary Syntax, Semantics and Framing (SSF) elements and data type definitions required for implementation.
• Dynamic and pre-coded references: Support for both dynamic location references (generated on-the-fly from map data) and pre-coded location references (shared identifiers agreed by sender and receiver).
• Interoperability: Ability to reference external location methods and to integrate with other TPEG1 applications; note that some application profiles mandate specific LRC methods (e.g., TPEG1-TEC is used with LRC containing DLR1, not TPEG1-LOC).

Applications

• Traffic data providers and broadcasters encoding TPEG streams for distribution.
• Navigation system vendors and map database providers decoding TPEG messages to place events on maps.
• Automotive OEMs and telematics platform developers implementing ITS client decoders.
• Public transport and fleet-management services delivering location-aware PTI, RTM, TEC, PKI messages. Practical benefits include consistent location interpretation across devices, enabling accurate event positioning, route guidance, congestion warnings and dynamic travel information in multiple markets.

Related standards

• ISO/TS 18234-2 (TPEG SSF), -3 (SNI), -4 (RTM), -5 (PTI), -6 (Location referencing / TPEG1-LOC)
• ISO 17572-2/-3 (pre-coded and dynamic location referencing profiles)
• ISO 639-1, ISO 3166-1, ISO 4217 (referenced code sets)

Keywords: ISO/TS 18234-11:2013, TPEG1-LRC, TPEG1, Location Referencing Container, location referencing, TPEG-LOC, dynamic location reference, Intelligent Transport Systems, Traffic and Travel Information.

Standards Content (Sample)

TECHNICAL ISO/TS
SPECIFICATION 18234-11
First edition
2013-02-01
Intelligent transport systems — Traffic
and Travel Information (TTI) via transport
protocol experts group, generation 1
(TPEG1) binary data format —
Part 11:
Location Referencing Container
(TPEG1-LRC)
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 11: Conteneur de référencement d'emplacement

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 [e-mail]
Web www.iso.org
Published in Switzerland
ii © ISO 2013 – All rights reserved

Contents Page
Foreword . iv
Introduction . vi
1  Scope . 1
2  Normative references . 1
3  Terms and definitions . 2
3.1  dynamic location reference . 2
3.2  location referencing . 2
3.3  location referencing container . 2
3.4  message . 3
3.5  pre-coded location reference . 3
3.6  TPEG-LOC, TPEG Location . 3
4  Abbreviations . 3
5  Location Referencing Container . 4
5.1  TPEG-LRC Introduction . 4
5.2  TPEG-LRC Methods . 5
5.2.1  DLR1 Location . 5
5.2.2  Korean Node Link Location . 5
5.2.3  TMC Location . 5
5.2.4  TPEG Location . 6
5.2.5  VICS Link Location . 6
5.2.6  ETL Location . 6
5.2.7  GLR Location . 6
6  Message components . 6
6.1  List of Generic Component IDs . 6
6.2  LocationReferencingContainer . 7
6.3  TPEGLocationReference . 7
6.4  DLR1LocationReference . 8
6.5  TMCLocationReference . 8
6.6  KoreanNodeLinkLocationReference . 8
6.7  VICSLinkReference . 9
6.8  ETLLocationReference . 9
6.9  GLRLocationReference . 9
Annex A (normative) Binary SSF and Data Types . 10
Bibliography . 50

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

 Part 7: Parking Information (TPEG-PKI)
 Part 8: Congestion and travel-time application (TPEC1-CTT)
 Part 9: Traffic event compact (TPEG1-TEC)
 Part 10: Conditional access information (TPEG1-CAI)
 Part 11: Location Referencing Container (TPEG1-LRC)

To be published.
To be published.
To be published.
To be published.
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 (TPEG1-SSF, which became ISO/TS 18234-2) described the Syntax, Semantics and
Framing structure, which is used for all TPEG applications. Part 4 (TPEG1-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 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 (TPEG1-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 (TPEG1-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 (TPEG1-PTI, ISO/TS 18234-5) and TPEG1-LRC,
ISO/TS 18234-6), were developed.
This Technical Specification adds a powerful mechanism for the ISO/TS 18234 series, allowing detailed road
event information to be encoded and transmitted to the user; it was developed specifically to satisfy the need
for a number of location referencing methods for Navigation Systems for worldwide markets. This Technical
Specification includes new datatypes as specified in Annex A.
TPEG applications are now developed using UML modelling and a software tool is used to automatically
select content which then populates this Technical Specification. Diagrammatic extracts from the model are
used to show the capability of the binary coding in place of lengthy text descriptions; the diagrams do not
necessarily include all relevant content possible.
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. Now, however, at
least for TPEG1-TEC, profiles are used to define which Applications should be used together. For example
TPEG1-TEC is used only with TPEG1-LRC containing DLR1 and never with TPEG1-LOC.

vi © ISO 2013 – All rights reserved

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

Intelligent transport systems — Traffic and Travel Information
(TTI) via transport protocol experts group, generation 1 (TPEG1)
binary data format —
Part 11:
Location Referencing Container (TPEG1-LRC)
1 Scope
This Technical Specification establishes the method of signalling the specific location referencing used by all
TPEG1 applications that require detailed location information to be delivered to client devices such as TPEG1-
RTM, TPEG1-PTI, TPEG1-TEC or TPEG1-PKI. The TPEG1-Location Referencing Container (TPEG1-LRC) is
described, as well as how it is used to signal which specific location referencing method is in use for a
particular TPEG Message. It is able to handle Location Referencing methods that are external to
ISO/TS 18234 (all parts) and the internal location referencing method (TPEG1-LOC) defined in
ISO/TS 18234-6.
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 639-1:2002, Codes for the representation of names of languages — Part 1: Alpha-2 code
ISO 3166-1:2006, Codes for the representation of names of countries and their subdivisions — Part 1:
Country codes
ISO 4217:2008, Codes for the representation of currencies and funds
ISO 17572-2:2008, Intelligent transport systems (ITS) — Location referencing for geographic databases —
Part 2: Pre-coded location references (pre-coded profile)
ISO 17572-3:2008, Intelligent transport systems (ITS) — Location referencing for geographic databases —
Part 3: Dynamic location references (dynamic profile)
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)
ISO/TS 18234-3:2006, Traffic and Travel Information (TTI) — TTI via Transport Protocol Expert Group
(TPEG) data-streams — Part 3: Service and Network Information (SNI) application
ISO/TS 18234-6:2006, Traffic and Travel Information (TTI) — TTI via Transport Protocol Expert Group
(TPEG) data-streams — Part 6: Location referencing applications
IEC 60559:1989, Binary floating-point arithmetic for microprocessor systems
3 Terms and definitions
For the purpose of this document, the following terms and definitions apply.
NOTE Digital map-based systems, either on the message generation side or the client (end-user) side tend to be
based upon road mapping rather than, for example, rail track mapping. Therefore, throughout ISO/TS 18234 (all parts)
there is a tendency to use roads as examples. However, roads are not necessarily implied, so the use and context of an
element must be clarified.
3.1
dynamic location reference
location reference generated on the fly based on geographic properties in a digital map database
3.2
location referencing
means to provide information that allows a system to identify a location accurately
Note 1 to entry: The content of a location reference allows the location to be presented in a plain-language manner directly
to the end-user (i.e. text, speech or icons) or to be used for navigational purposes, for example, for map-based systems.
3.3
location referencing container
concept applied to the grouping of all the location referencing elements of a TPEG Message together in one
place
Note 1 to entry: Many TPEG applications are designed to deliver TPEG messages, which consist of three high level
containers, each with one or more elements. These containers are for message management, event information and
location referencing information. Note that some special application messages do NOT include a location referencing
container, such as a cancellation message. It should also be noted that each container does not necessarily have all
possible lower level elements included.
Figure 1 shows the “container view” structure used, for example, when a TPEG1-RTM (See ISO/TS 18234-4) application
message is generated to describe a road event and location references need to be given to the end-user.

Figure 1 — The “container view” of a TPEG Message
The main purpose of the location referencing container is to provide both human understandable and machine-readable
elements to appropriate client decoders. It may be delivered to a “thin client”, which for example is only able to convey
limited location referencing information to the end-user, or it may be delivered to a “thick client” using a considerable
number of elements and using considerable processing power to filter the information for a comprehensive display to an
end-user.
2 © ISO 2013 – All rights reserved

3.4
message
collection of coherent information sent through the information channel describing an event, a collection of
related events, or status information and including message management information
3.5
pre-coded location reference
location reference using a unique identifier that is agreed upon in both sender and receiver systems to select
a location from a set of pre-coded locations
3.6
TPEG-LOC
TPEG Location
native TPEG location referencing method focused on providing location references for various TPEG
applications, which are designed for delivering messages to end-users
Note 1 to entry: Since TPEG-LOC is designed for delivering messages to end-users, some definitions have a meaning
which is different from that found in other location referencing systems.
Note 2 to entry: An important aspect of the TPEG-LOC referencing method is that a location description may be created
on-the-fly by the service provider when needed. It may then be interpreted and used by the TPEG-decoder, and then
discarded. The pre-creation of codes and the use of a database and code maintenance is entirely avoided.
4 Abbreviations
For the purposes of this document, the following abbreviations apply.
CEN Comité Européen de Normalisation
EBU European Broadcasting Union
ETL Extended TMC Location Reference
GLR Geographical Location Reference
ISO International Organization for Standardization
OSI Open Systems Interconnection
RTM Road Traffic Message
SSF Syntax, Semantics and Framing Structures
TISA Traveller Information Services Association
TPEG Transport Protocol Experts Group
TTI Traffic and Travel Information
VICS Vehicle Information and Communication System
NOTE Real-time road traffic information system providing congestion and regulation information developed and
deployed by Japan.
5 Location Referencing Container
5.1 TPEG-LRC Introduction
TPEG applications are described by the TPEG specifications in this Technial Specification series and are
placed at the highest layers of the OSI protocol stack, ISO/IEC 7498-1:1994. Each TPEG application (e.g.
TPEG1-RTM) is assigned a unique Application IDentification (AID) number. In this respect, the TPEG1-LRC is
not an application, but it is an essential constituent part of all TPEG Messages requiring location referencing.
To satisfy the principles of the TPEG technology, location referencing requires the transmission of data that
will allow a client to present such details to a human, directly as text, speech, graphics or a combination of
these, to recreate a comprehensible representation of a real-world place.
Generally, location referencing comes in three distinct types:
 pre-coded, where a number of locations are fixed in a list and the same list must be used by the service
provider as well as by the client device decoder;
 dynamic, where locations are encoded on-the-fly and decoded by the client device with no specific prior
knowledge;
 hybrid, a mixture of the two.
The key concept of the TPEG1-LRC design is that it allows any location referencing method presently
identified to be specified in this Technical Specification (and allows for future extension methods to be
identified and agreed), to be used within any TPEG Message. Indeed a service provider may implement the
use of any one or more location references per TPEG Message. The choice will depend upon market driven
factors and thus there is full service provision choice for both transitional and long-term location referencing
requirements.
To date, seven location referencing methods have been identified as suitable for use within TPEG1-LRC. In
alphabetical order they are: DLR1, Korean Node Link Location, Extended TMC Location Reference,
Geographic Location Reference, TMC Location, TPEG-Location and VICS Link Location. These are further
described in 6.2. These location referencing methods are detailed in other specifications (see Clause 2,
Normative references) and they may be used by inserting the location data, encoded according to their
specification, into the TPEG1-LRC. The LRC ensures a stable way to identify the method in use and thus
allows client decoder(s) to choose what location method(s) are present in the message for their use.
4 © ISO 2013 – All rights reserved

Figure 2 — Location Referencing Container construct
5.2 TPEG-LRC Methods
The following TPEG-LRC methods are currently approved for use within the LRC:
5.2.1 DLR1 Location
The DLR1 location referencing method is a dynamic location referencing method developed by ISO/TC 204.
The method is designed to provide compact location references that allow accurate location referencing for
100 % of the road network. DLR1 location references are machine readable and are primarily aimed at
dynamic route guidance navigation systems. The DLR1 method is specified in ISO 17572-3.
5.2.2 Korean Node Link Location
Korean Node Link Location is a pre-coded location referencing method designed for the South Korean road
network. The Korean Node Link Location reference method is further described in the ISO 17572 series.
5.2.3 TMC Location
The RDS-TMC protocol (i.e. ALERT-C protocol) is specified in ISO 14819-1. This protocol is designed to
provide pre-coded information messages using pre-coded location references to end-users on inter-urban
road networks. Both messages and locations are required to be stored in all client devices. The TMC system,
developed for FM transmission in the RDS sub-channel, is limited to a code-base of <64000 locations per
location table. The TMC location reference method for embedding ALERT-C location references in the
TPEG-LRC is described in ISO 17572-2.
5.2.4 TPEG Location
TPEG Location is the native dynamic location referencing method designed for use with TPEG applications
that require location information. It is the native TPEG location referencing method and is described fully in
ISO/TS 18234-6. It is designed to enable a service provider to give an impression or image to the human end-
user of where an event has taken place (this cannot be done easily because the human end-user may or may
not be familiar with the location.) The TPEG1-LOC method has the added challenge of attempting to be as
language independent as possible, while at the same time providing location data in a machine readable form
that allows great freedom of client device design. For example, clients offering text display only, text-to-speech
output or map matched icons are all possible.
Location references encoded according to TPEG1-LOC are client device-type agnostic in terms of how
locations are presented. As a minimum, it seeks to allow even the most basic client to present useful location
information to end-users.
5.2.5 VICS Link Location
VICS Link Location is a pre-coded location referencing method designed for the Japanese road network. The
VICS Link Location reference method is further described in ISO 17572-2.
5.2.6 ETL Location
The RDS-TMC protocol (i.e. ALERT-C protocol) is specified in ISO 14819-1. That protocol is designed to
provide pre-coded information messages using pre-coded location references to end-users on inter-urban
road networks. Both messages and locations are required to be stored in all client devices. The TMC system,
developed for FM transmission in the RDS sub-channel, is limited to a code-base of <64000 locations per
location table. Some Events in the RDS-TMC protocol address only the exit and entries of the point location
defined by the location code. Complete addressing of exits and entries requires additional information to be
used with a location code and has to be supplied in the location container. The Extended TMC Location
Reference extends the TMC Location referencing defined in ISO 17572-2 to allow, additionally, specifying exit
and entry roads of a defined TMC-Point location. The ETL Location Reference method for embedding
ALERT-C location references in TPEG-LRC is described in TISA SP10037.
5.2.7 GLR Location
The GLR location referencing method is a simple geographic location referencing method developed by TISA.
The method is designed to provide compact, dynamic location references for geographic features, e.g.
geographic point, line and area locations. GLR location references are machine readable. The GLR method is
primarily aimed at geo-oriented (i.e. non-road network related) applications such as weather reports, safety
alerts and emergency warnings. The GLR method is specified in TISA SP10038.
6 Message components
6.1 List of Generic Component IDs
Name Id
TPEGLocationReference 0
DLR1LocationReference 1
TMCLocationReference 2
VICSLinkReference 3
KoreanNodeLinkLocationReference 4
ETLLocationReference 5
GLRLocationReference 6
6 © ISO 2013 – All rights reserved

6.2 LocationReferencingContainer
The generic LocationReferencingContainer can contain a pre-coded or a dynamic location reference.
One or more location referencing methods, e.g. TPEG Location, DLR1 Location, ETL Location, GLR
LocationTMC Location, VICS Link Location or Korean Node Link Location, can be used to describe one
physical location. Any particular method shall be used only once in any LocationReferencingContainer.
>:=
(x), : Identifier, is defined by the instance
(lengthComp), : Length of component in bytes, excluding the id and length
indicator
(lengthAttr), : Length of attributes, always 0 since this component has
no attributes
unordered {
t * (tpegLoc)[0.1], : t represents the number of occurrences between 0 and 1
d * (dlr1Loc)[0.1],
: d represents the number of occurrences between 0 and 1
m * (tmcLoc)[0.1], : m represents the number of occurrences between 0 and 1
v * (vicsLoc)[0.1], : v represents the number of occurrences between 0 and 1
k * (klrLoc)[0.1], : k represents the number of occurrences between 0 and 1
e * (tetLoc)[0.1], : e represents the number of occurrences between 0 and 1
g * (vicsLoc)[0.1], : g represents the number of occurrences between 0 and 1
};
If the specific LocationReferencing-Method top level container does not include the standard component
length (IntUnLoMB) and attributeLength (IntUnLoMB) (see A.2.3.3.1), these need to be added to the container,
while the id and native length indicators of the external top level container are replaced with the ones specified
in this Technical Specification. However all further content of the top level container is not modified, which
implies that child components may have different (non-standard) component headers.
6.3 TPEGLocationReference
This element is defined by ISO/TS 18234-6.
The content of this component is defined in another specification. The purpose of this class definition is to
assign a unique identifier to the component.
>:=
external ; : Defined in ISO/TS 18234-6

The TPEGLocationReference as defined in ISO/TS 18234-6 does not include the standard component length
(IntUnLoMB) and attributeLength (IntUnLoMB) (see A.2.3.3.1). Hence, these need to be added to the
container, while the id and native length indicators of the external top level container are replaced with the
ones specified in this document as follows.
>:=
(0), : Identifier = 0, TPEG-Loc
(lengthComp), :Length of component in bytes, excluding id and length indicator
(lengthAttr), Length of attributes of this component in bytes
……. :TPEG-Loc content as defined in ISO/TS 18234-6, but without id and
intunli length indicator
6.4 DLR1LocationReference
This element is defined by ISO 17572-3.
The content of this component is defined in another specification. The purpose of this class definition is to
assign a unique identifier to the component.
>:=
external ;
: Defined in ISO 17572-3
6.5 TMCLocationReference
This element is defined by ISO 17572-2.
The content of this component is defined in another specification. The purpose of this class definition is to
assign a unique identifier to the component.
>:=
external ; : Defined in ISO 17572-2:2008, Annex A

6.6 KoreanNodeLinkLocationReference
This element is defined by ISO 17572-2.
The content of this component is defined in another specification. The purpose of this class definition is to
assign a unique identifier to the component.
>:=
external ; : Defined in ISO 17572-2

8 © ISO 2013 – All rights reserved

6.7 VICSLinkReference
This element is defined by ISO 17572-2.
The content of this component is defined in another specification. The purpose of this class definition is to
assign a unique identifier to the component.
>:=
external ;
: Defined in ISO 17572-2:2008, Annex A (logical
format only)
6.8 ETLLocationReference
This element is defined by TISA SP10037.
The content of this component is defined in another specification. The purpose of this class definition is to
assign a unique identifier to the component.
>:=
external ; : Defined in TISA SP10037

6.9 GLRLocationReference
This element is defined by TISA SP10038.
The content of this component is defined in another specification. The purpose of this class definition is to
assign a unique identifier to the component.
>:=
external ; : Defined in TISA SP10038

Annex A
(normative)
Binary SSF and Data Types
NOTE This annex replaces Clauses 5, 6 and 7 of ISO/TS 18234-2:2006. All other clauses of ISO/TS 18234-2 remain
valid and thus remain valid as a normative reference to this Technical Specification.
A.1 Conventions and symbols
A.1.1 Conventions
A.1.1.1 Byte ordering
All numeric values using more than one byte are coded in “Big Endian” format (most significant byte first).
Where a byte is subdivided into bits, the most significant bit (“b7”) is at the left-hand end and the least
significant bit (“b0”) is at the right-hand end of the structure.
A.1.1.2 Method of describing the byte-oriented protocol
TPEG uses a data-type representation for the many structures that are integrated to form the transmission
protocol. This textual representation is designed to be unambiguous, easy to understand and to modify, and
does not require a detailed knowledge of programming languages.
Data types are built up progressively. Primitive elements, which may be expressed as a series of bytes are
built into compound elements. More and more complex structures are built up with compound elements and
primitives. Some primitives, compounds and structures are specified in this Technical Specifcation, and apply
to all TPEG Applications. Other primitives, compounds and structures are defined within applications and are
local only to that application.
A resultant byte-stream code using C-type notation is shown in ISO/TS 18234-2:2006, Annex E.
A.1.1.3 Reserved data fields
If any part of a TPEG data structure is not completely defined, then it should be assumed to be available for
future use. The notation is UAV (unassigned value). This unassigned value should be encoded by the service
provider as the value 00 hex. This allows newer decoders using a future TPEG Standard to ignore this data
when receiving a service from a provider encoding to this older level of specification. A decoder which is not
aware of the use of any former UAVs can still make use of the remaining data fields of the corresponding
information entity. However, the decoder will not be able to process the newly defined additional information.
A.1.2 Symbols
A.1.2.1 Literal numbers
Whenever literal numbers are quoted in TPEG Standards, the following applies:
123 = 123 decimal
123 hex = 123 hexadecimal
10 © ISO 2013 – All rights reserved

A.1.2.2 Variable numbers
Symbols are used to represent numbers whose values are not predefined within the TPEG Standards. In
these cases, the symbol used is always local to the data type definition. For example, within the definition of a
data type, symbols such as “n” or “m” are often used to represent the number of bytes of data within the
structure, and the symbol “id” is used to designate the occurrence of the identifier of the data type.
A.1.2.3 Implicit numbers
Within the definition of a data structure it is frequently necessary to describe the inclusion of a component
which is repeated any number of times, zero or more. In many of these cases it is convenient to use a
numerical symbol to show the component structure being repeated a number of times, but the number itself is
not explicitly included within the definition of the data structure. Often, the symbol “m” is used for this purpose.
A.2 Representation of syntax
A.2.1 General
This clause introduces the terminology and the syntax that is used to define TPEG data elements and
structures.
A.2.2 Data type notation
A.2.2.1 Rules for data type definition representation
The following general rules are used for defining data types:
5)
 a data type is written in upper camel case letters in one single expression. The data type may contain
letters (a-z), numbers (0-9), underscore "_", round brackets "()" and colon ":"; the first must be a letter;
EXAMPLE 1 IntUnLo stands for Integer Unsigned Long.
 a data type is framed by angle brackets “ < > ”;
 the content of a data type is defined by a colon followed by an equal sign “ := ”;
 the end of a data type is indicated by a semicolon “ ; ”;
 a descriptor written in lower camel case may be added to a data type as one single expression without spaces;
 a descriptor is framed by round brackets “ ( ) ”;
 the descriptor contains either a value or a name of the associated type;
 data types in a definition list of another one are separated by commas “ , ”. The order of definition is defined as the
order of occurrence in a data stream;
 curly brackets (braces) “ { } ” group together a block of data types;
 control statements ( “if”, “infinite”, “unordered” or “external”) are noted in lower-case letters. A control statement is
followed by a block statement or only one data type:

5) Camel case is the description given to the use of compound words wherein each individual word is signalled by a
capital letter inside the compound word. Upper camel case means that the compound word begins with an upper-case
(capital) letter, and lower camel case means the compound word begins with a lower-case (small) letter.
1) “if” defines a condition statement. The block’s (or data type’s) occurrence is conditional on the condition
statement being valid. The condition statement is framed with round brackets. This statement applies to any
data type;
2) “infinite” defines endless repetition of the block (or data type). This is only used to mark the main TPEG stream
as not ending stream of data;
3) “unordered” defines that the following block contains data types which may occur in any order, not only the one
used to specify subsequent data types. This statement applies to components only (see A.2.3.3);
4) “external” defines that the content of the data type is being defined externally to the scope of the given
specification. The control statement “external” must be followed by only one data. A reference to the
corresponding specification should follow in the comment. All types specified in TYP specification are treated as
being in the scope of any application.
EXAMPLE 2
:= : externally defined component
external ; : id = 1, See Annex B (Message Management
Container)
 the expression “ n * ” indicates multiplicity of occurrence of a data type. The lower and upper bound are implicitly from
0 to infinite; other bounds are described in square brackets between two points “ . ” and behind the data type
descriptor. The “ * ” stands for no limitation at upper bound;
EXAMPLE 3
m * (Attribute) [1.*] , : The “Attribute” must occur once at least and up
to infinite.
 a function “ f ( ) ” that is calculated over a data type is indicated by italic lower-case letters. The comment behind the
n
definition of the function shall explain which function is used;
 any text after a colon “ : ” is regarded as a comment;
 a data type definition can be a template (i.e. not a fully defined declarative structure) having a parameter inside of
round brackets “(x)” at the end of the data type name. Templates define structures, whose structural definition is
included as a basis for other data type definitions. To declare the given template (making it identifiable) the name of
the parameter is repeated as a descriptor in a nested data type of the subsequent definition list. Templates allow for
reading the generalised part of different instances i.e. to specify data type interfaces (see A.2.3.2);
EXAMPLE 4
:= : x defines the template parameter
(x); : descriptor x defines position of setting the
parameter in the list
 a data type can inherit a template by concatenating the data type name of the template including the square brackets
to its own name. The data type itself can again be a template having the "(x)" at its end of name, or it instantiates the
inherited template by defining the value of the parameter in the brackets. In the latter case the brackets shall contain
the decimal number of the identifier and the value shall be set in the subsequent definition list. The structural
definition of the inherited template is repeated as the first part of the definition list before new data types are specified
(see A.2.3.2);
12 © ISO 2013 – All rights reserved

EXAMPLE 5
>:= : second template inherits first
(x), : repeated definition from first template
(n); : additional structural definition

>:= : instantiation of the second template
(1), : definition of parameter in the stream
(n), : structural definition from template
(value); : some more definition

 in the definition list a specific instance of a template (i.e. declarative structure) is described without the brackets. Any
inherited data type of this template may occur at that position in the data stream.
EXAMPLE 6
:=
(anyAnotherTemplate); : Data stream contains e.g.

The following additional guidelines help to improve the readability of data type definitions:
 data type names are written in bold;
 nested data type definitions are defined from top to bottom (i.e. higher levels first, then lower levels);
 a box is drawn around a data type definition;
 for clear graphical presentation, lines in a coding box if they are too long to fit, are broken with a backslash “\”
followed by a carriage return. The broken line restarts with an additional backslash.
EXAMPLE 7
:=
\NameMayBeInSeveralLines>, : Second line
,
;
A.2.2.2 Description of data type definition syntax
A data type is an interpretation of one or more bytes. Each data type has a structure, which may describe the
data type as a composition of other defined data types. The data type structure shows the composition and
the position of each data element. TPEG defines data structures in the following manner:
:= : Description of data type
(descriptorA), : Description of data A
(descriptorB); : Description of data B

This shows an example data structure, which has just two parts, one of type and the other of
. A descriptor may be assigned to the data type, to relate the element to another part of the
definition. Comments about the data structure are included at the right-hand side delimited by the colon “:”
separator. Each of the constituent data types may be itself composed of other data types, which are defined
separately. Eventually each data type is expressible as one or more bytes.
Where a data structure is repeated a number of times, this may be shown as follows:
:= : Description of data type
...