CEN ISO/TS 18234-5:2006

SLOVENSKI STANDARD
01-julij-2006
Prometne in potovalne informacije (TTI) – TTI preko toka podatkov ekspertne
skupine za prometne in potovalne protokole (TPEG) – 5. del: Aplikacija informacije
javnega transporta (PTI) (ISO/TS 18234-5:2006)
Traffic and Travel Information (TTI) - TTI via Transport Protocol Expert Group (TPEG)
data-streams - Part 5: Public Transport Information (PTI) application (ISO/TS 18234-
5:2006)
Reise- und Verkehrsinformation (TTI) ) - TTI über Datenströme der Transportprotokoll
Expertengruppe (TPEG) - Teil 5: Informationsanwendungen des Öffentlichen
Nahverkehrs (ISO/TS 18234-5:2006)
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 5: Application d'information
de transport public (ISO/TS 18234-5:2006)
Ta slovenski standard je istoveten z: CEN/ISO TS 18234-5:2006
ICS:
03.220.01
35.240.60
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

TECHNICAL SPECIFICATION CEN ISO/TS 18234-5

SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION June 2006
ICS 03.220.01; 35.240.60
English Version
Traffic and Travel Information (TTI) - TTI via Transport Protocol
Expert Group (TPEG) data-streams - Part 5: Public Transport
Information (PTI) application (ISO/TS 18234-5:2006)
Informations sur le trafic et le tourisme (TTI) - Messages Reise- und Verkehrsinformation (TTI) ) - TTI über
TTI via les flux de données du groupe d'experts du Datenströme der Transportprotokoll Expertengruppe
protocole de transport (TPEG) - Partie 5: Application (TPEG) - Teil 5: Informationsanwendungen des
d'information de transport public (ISO/TS 18234-5:2006) Öffentlichen Nahverkehrs (ISO/TS 18234-5:2006)
This Technical Specification (CEN/TS) was approved by CEN on 28 September 2004 for provisional application.

The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to submit their
comments, particularly on the question whether the CEN/TS can be converted into a European Standard.

CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS available
promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in parallel to the CEN/TS)
until the final decision about the possible conversion of the CEN/TS into an EN is reached.

CEN members are the national standards bodies of Austria, Belgium, Cyprus, Czech Republic, Denmark, Estonia, Finland, France,
Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania,
Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.

EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

Management Centre: rue de Stassart, 36  B-1050 Brussels
© 2006 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/ISO TS 18234-5:2006 E
worldwide for CEN national Members.

Foreword
This document (CEN ISO/TS 18234-5:2006) has been prepared by Technical Committee
CEN/TC 278 "Road transport and traffic telematics", the secretariat of which is held by NEN, in
collaboration with Technical Committee ISO/TC 204 "Transport information and control
systems".
According to the CEN/CENELEC Internal Regulations, the national standards organizations of
the following countries are bound to announce this CEN Technical Specification: Austria,
Belgium, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece,
Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and United
Kingdom.
TECHNICAL ISO/TS
SPECIFICATION 18234-5
First edition
2006-06-01
Traffic and Travel Information (TTI) — TTI
via Transport Protocol Expert Group
(TPEG) data-streams —
Part 5:
Public Transport Information (PTI)
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 5: Application d'information de transport public

Reference number
ISO/TS 18234-5:2006(E)
©
ISO 2006
ISO/TS 18234-5:2006(E)
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

ISO/TS 18234-5:2006(E)
Contents Page
Foreword. iv
Introduction . v
1 Scope . 1
2 Normative references . 2
3 Terms and definitions. 2
4 Abbreviations . 6
5 PTI application overview. 7
5.1 Introduction . 7
5.2 TPEG-message concept. 9
5.3 TPEG-messages delivering additional information . 10
5.4 Elements of a TPEG public transport information message. 10
5.5 Message management container . 12
5.6 Application event (PTI) container. 15
5.7 Location referencing . 16
6 PTI container . 16
6.1 Structure of public transport information . 16
6.2 Notation . 17
6.3 PTI application component frame . 18
7 Message management container . 19
7.1 Mandatory elements . 19
7.2 Date and time elements. 19
7.3 Severity and reliability elements . 20
7.4 Coding of the message management container. 20
8 Event container . 21
8.1 Event description. 21
8.2 Level one classes and their descriptions .21
8.3 Sub-level classes. 22
8.4 End-user presentation modes . 25
8.5 Coding structure . 27
8.6 Event container data types . 28
8.7 Coding of event container . 29
8.8 PTI application primitives . 35
8.9 TPEG tables (pti01 to pti34) indexing . 37
Bibliography . 58

ISO/TS 18234-5:2006(E)
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-5 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

ISO/TS 18234-5:2006(E)
Introduction
The 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 information from the database of a service provider to an end-user’s equipment.
This CEN ISO Technical Specification describes the Public Transport Information Application, its underlying
data structure as well as the means of encoding and decoding hierarchically structured messages containing
public (i.e. collective) transport information. This application is intended to provide service providers, including
broadcasters, with a means to transmit to an end-user public transport related travel news. The scope of
TPEG is intended to cover content as diverse as network disruption, cancellations and even aspects of
timetable information.
Messages generated can be classified to fit into user perceived categories. The underlying data elements
used for these classifications are taken from a superset that, the designers believe, is a complete set of
elements needed to fully describe the broadest range of public transport information.
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)) 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) completed 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-5, provides a full specification for the public (i.e. collective)
transport information application. This document has been prepared by CEN/TC 278, Road Transport and
Traffic Telematics in co-operation with ISO/TC 204, Intelligent Transport Systems.
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
ISO/TS 18234-5:2006(E)
Specification, all parts are fully inter-workable and no specific dependencies exist. This Technical
Specification has the technical version number TPEG-PTI_3.0/001.

vi © ISO 2006 – All rights reserved

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

Traffic and Travel Information (TTI) — TTI via Transport
Protocol Expert Group (TPEG) data-streams —
Part 5:
Public Transport Information (PTI) application
1 Scope
This Technical Specification describes the Public Transport Information (PTI) Application, which is intended to
cover all modes of public (i.e. collective) transport as well as inter-urban and intra-urban travel. The
application is designed to allow the efficient and language independent delivery of public transport information
directly from service provider to end-users.
The term “application” is used in TPEG specifications to describe specific applications, such as in this case
the public transport information application, which comprises three information containers: the message
management container, the application event container and the TPEG-location container. The first two
containers are fully described herein and the TPEG-location container is described in CEN ISO/TS 18234-6.
Each TPEG Application (e.g. TPEG-PTI) 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 (CEN ISO/TS 18234-3) to indicate how to process TPEG
content and allows routing of data to an appropriate Application decoder.
AID = 0002 (hex) is assigned to the TPEG-PTI application, described in this specification.
The TPEG-PTI application aims at describing “legs” of a journey also described as “rides” by other
methodologies. However, it is important to note that TPEG-PTI is not limited to describing single services,
because it also allows the more general description of route, service and area-wide problems.
Public (or collective) transport information is usually consumed in one of four principle ways as follows:
⎯ Leader board information as used at stations or terminals;
⎯ A report on the state of a network;
⎯ The description of an individual service;
⎯ As a news flash report.
The elements needed to provide information for any one of the four end-user presentation modes are largely
the same. The end-user focus of TPEG applications makes it useful to be able to mimic presentations, to
which end-users are accustomed, for example a railway station indicator board.
TPEG-PTI messages can therefore group data elements to present one of the following end-user presentation
modes:
⎯ Incident message report;
⎯ Station/terminal information;
ISO/TS 18234-5:2006(E)
⎯ Route information;
⎯ Individual service information.
It is important to bear in mind that these end-user presentation modes are merely presentational aides; they
have little to do with the content in the individual data elements. They do, however indicate how data elements
must be grouped if a presentation in any of these views is intended. Unlike the TPEG-RTM application
(CEN ISO/TS 18234-4), TPEG-PTI benefits from the nodal structure of public transport, making use of its
discrete start, end and stopping points as well as being limited to fixed, be it real or virtual, routes.
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 8601, Data elements and interchange formats — Information interchange — Representation of dates and
times
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, 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-6, Traffic and Travel Information (TTI) — TTI via Transport Protocol Expert Group (TPEG)
data-streams — Part 6: Location referencing for Applications
3 Terms and definitions
For the purposes of this Technical Specification, the following terms and definitions apply.
NOTE Definitions in this specification are in some cases derived from definitions found in the DATEX Data Dictionary
(ENV 13106). TPEG-PTI is completely focussed at delivering messages to end-users, so for this key operational reason
some definitions have a different meaning from that found in the DATEX Data Dictionary. These differences are
highlighted in this section.
3.1
additional information (ADI)
a combination of several elements to allow making full use of media links and back channels and to facilitate
the description of less common occurrences and allow the listing of emergency numbers. For the full use, it
needs function types as defined in TPEG table pti30
3.2
brand name (BDN)
an element permitting the use of the name of the service type given by the transport operator, intended to
provide a means of easy identification of a service by an end-user
EXAMPLE “InterCity”, “Thalys”, “Eurostar”.
3.3
booking status (BS)
BS is used to indicate availability of a particular service. It is used together with TPEG table pti24
2 © ISO 2006 – All rights reserved

ISO/TS 18234-5:2006(E)
3.4
cross reference information (CRI)
pointer to one or more messages in the same, or another, TPEG service
3.5
day types (DYT)
element used in conjunction with other time types, such as the timetable or the time types, to allow describing
the day on which a service is available or withdrawn. They are listed in TPEG table pti34
3.6
event reason (ER)
ER permits the reason for an event to be added to a message. It is structured to reflect on four subtypes of
reasons, whether it is general, personnel, equipment or environment. The lead table is TPEG table pti18; the
subtypes are listed in TPEG tables pti19 to TPEG table pti22
3.7
interval time (IVT)
IVT allows the description of repeated events within a certain time frame, such as running a special service
but only for a limited period. For example, an additional service may be added for a period of three weeks, but
it only runs on Tuesdays and Thursdays, so the STA and STO will mark the period, but IVT will be needed to
clarify the addition applies to specific days
3.8
location referencing
method for referencing locations to facilitate the exchange of location related information between different
systems
3.9
message
collection of coherent information sent through an information channel
3.10
message expiry time (MET)
date and time in accordance with EN ISO 8601 when the message should be deleted from all TPEG-decoders
(used for message management purposes)
3.11
message generation time (MGT)
date and time stamp in accordance with EN ISO 8601 originated at the actual time and point of message
generation (used for message management purposes)
3.12
message identifier (MID)
unique identifier for a sequence of versions of one message relating to a particular event of a particular
service component
3.13
message report type (MRT)
element to signal the type of message for presentation purposes. It may be an incident message report,
station/terminal information, route information or individual service information, as defined in TPEG table pti27
3.14
predicted time (PSTA/PSTO)
predicted time is dynamic, representing actual timings combined with estimates taking into account real-time
events with bearings on the operating schedule. To indicate this, the start and stop time elements are as
defined below but are prefixed with “P”. See also scheduled time
ISO/TS 18234-5:2006(E)
3.15
route description point (RDP)
TPEG-Locs with additional flags to indicate whether they are start, end and stopping as well as non-stopping
points. Types are listed in TPEG table pti15
3.16
scheduled time (SSTA/SSTO)
scheduled time indicates intended or planned timings, usually available in advance of a journey. To indicate
this, the start and stop time elements are as defined below but are prefixed with “S”. See also predicted time
3.17
service condition (SCO)
a description of what is happening with a service, e.g. additional train, cancelled ferry. Elements are listed in
TPEG table pti13
3.18
service delivery point (SDP)
element permitting the refining of the TPEG-Loc description of a place of service by adding information on
terminal gate or platform number/section. The details are listed in TPEG table pti17. To indicate whether it is
a scheduled or predicted SDP, it is associated with TPEG table pti16_01 for scheduled or pti16_02 for
predicted
3.19
service facilities (SF)
element allowing the description of available amenities for a particular service. They are found TPEG table
pti23
3.20
severity factor (SEV)
amount of disruption to traffic likely to be caused by a particular event
NOTE This definition varies from the DATEX Data Dictionary definition (ENV 13106).
3.21
start time (STA)
date and time in accordance with EN ISO 8601 at which an event, or status information, began or is
scheduled to begin (used for presentation to the end-user)
NOTE This definition varies from the DATEX Data Dictionary definition (ENV 13106).
3.22
stop time (STO)
date and time in accordance with EN ISO 8601 at which an event, or status information, ended or is
scheduled to end (used for presentation to the end-user)
NOTE This definition varies from the DATEX Data Dictionary definition (ENV 13106).
3.23
ticket restrictions (TR)
TR is used to indicate validity of ticket types on particular services. It is used together with TPEG table pti25
3.24
time types (TMT)
element used to distinguish between scheduled and predicted times, be they once or repeated. The details
are listed in TPEG table pti28. To indicate whether it is a scheduled or predicted time, it is associated with
TPEG table pti16_01 for scheduled or pti16_02 for predicted
4 © ISO 2006 – All rights reserved

ISO/TS 18234-5:2006(E)
3.25
timetable type (TTT)
TTT is used to indicate the timetable period to which reference is made. It is used together with TPEG table
pti33
3.26
transport mode (TM)
element specifying the mode of transport, whether train, ferry or other. TPEG table pti01 contains the modes
identified
3.27
transport operator (TO)
the name of the operator of a service
EXAMPLE SNCF, Eurolinies Maritimes, EasyJet.
NOTE The TO might also be the overall responsible organization, for example in “code-sharing” agreements.
3.28
transport operator subsidiary (TOS)
the name of the provider of a particular service, applicable if an operator has different divisions
EXAMPLE Cross Country, West Coast as part of the Virgin Group.
NOTE This would also apply to the particular service within a “code-sharing” agreement.
3.29
transport service ID (TSID)
a unique alphanumeric designation of a service
EXAMPLE A flight number or a train number.
3.30
transport submode (TSM)
TSM refines the notion of transport mode. It allows distinguishing between fast and stopping services, and
urban services. They are defined in TPEG table pti02 to TPEG table pti12
3.31
transport service name (TSN)
the name of a service
EXAMPLE A ship’s name or Metro Line name such as Koningin Beatrix or Circle Line.
3.32
unverified information (UNV)
UNV indicates that a message includes information from an unverified source
3.33
version number (VER)
serial number to distinguish successive messages having a particular message identifier. Version numbers
are used incrementally, allowing the progress of an event to be tracked from first notification (VER = 0),
through updates, to eventual cancellation (VER = 255)
NOTE This definition varies from the DATEX Data Dictionary definition (ENV 13106).
ISO/TS 18234-5:2006(E)
4 Abbreviations
For the purposes of this Technical Specification, the following abbreviations apply in addition to the
abbreviations given in section 3.
4.1
AID
Application Identification
4.2
BPN
Broadcast, Production and Networks (an EBU document publishing number system)
4.3
B/TPEG
Broadcast/TPEG (the EBU project group name for the specification drafting group)
4.4
CEN
Comité Européen de Normalisation
4.5
EBU
European Broadcasting Union
4.6
ETSI
European Telecommunications Standards Institute
4.7
ILOC
Intersection location
4.8
INV
Introduction, Numbering and Versions (see CEN ISO/TS 18234-1)
4.9
IPR
Intellectual Property Right(s)
4.10
ISO
International Organization for Standardization
4.11
OSI
Open Systems Interconnection
4.12
PTI
Public Transport Information
4.13
RDS-TMC
Radio Data System – Traffic Message Channel
6 © ISO 2006 – All rights reserved

ISO/TS 18234-5:2006(E)
4.14
RFU
Reserved for future use (not necessarily abbreviated)
4.15
RTM
Road Traffic Message application (see CEN ISO/TS 18234-4)
4.16
SNI
Service and Network Information application (see CEN ISO/TS 18234-3)
4.17
SSF
Syntax, Symantics and Framing Structure (see CEN ISO/TS 18234-2)
4.18
TPEG
Transport Protocol Experts Group
4.19
TTI
Traffic and Travel Information
4.20
UTC
Coordinated Universal Time
4.21
UAV
Unassigned Value
5 PTI application overview
5.1 Introduction
The TPEG Public Transport Information Application is intended to work across a wide range of TPEG-decoder
types and a variety of presentational possibilities should be supported. All types of TPEG-decoders shall be
supported simultaneously, from sophisticated agent TPEG-decoders, “thick clients”, serving navigation
systems, through to simple TPEG-decoders, “thin clients”, only able to decode text-based information as well
as software implementations running on computers and hand-held devices.
Some of the conceivable devices may include GPS receivers with and without a digital map, be fixed, like
home receivers or in-vehicle systems. Some may be portable, such as the next generation of mobile phones
or hand held computers. There may even be applications that can be used in vehicles as part of the
navigation system and outside on a stand-alone basis. Public Transport Information received by such devices
may be presented to users through use of text, synthesized speech, graphically or may be used directly in
route calculation or any combination of these.
Public transport information will need to include at least some of the following elements to enable a user to
make decisions based upon the content:
⎯ Who is affected?
⎯ What is the location to which the information relates?
⎯ Which route or area is affected?
ISO/TS 18234-5:2006(E)
⎯ The event being described
⎯ The severity of the incident
⎯ Whether the information is verified
⎯ The duration for which the message is valid
⎯ Does the message refer to a regular or ‘one-off’ event
⎯ Consequences of the incident on journey times
⎯ Advice on alternatives
⎯ Any additional information
5.1.1 Message considerations
While no message is likely to ever affect all who could receive it, some messages will apply to a larger number
of travellers than others. The coding structure reflects this and the ability to appropriately filter, gives users
control over the type and kind of information they wish to receive. For the selection process to be most useful
it should work on as many elements as possible, including, attributes, locations, times and the severity of a
message.
NOTE Part of each TPEG message is a location reference. TPEG technology uses one location referencing system
across all Applications, known as TPEG-Loc (CEN ISO/TS 18234-6). This has the potential of enabling messages from
different TPEG streams to be linked by their common location. Each message will be about a particular location. The
location may be quite specific, a single point on the network, a segment between two given points, or it may be a more
general area, often with more vague boundaries. The way in which the location is coded is important as it allows
information to be filtered by TPEG-decoders and integrated with route planning and navigation systems.
The descriptive phrase and attribute part of the message about an incident allows a user to make a judgement
about the likely progress of a journey, and may either directly or indirectly provide advice allowing travel plans
to be revised. To allow appropriate decisions to be made, various data about the incident may be required. If
for example, a problem occurs, in general the effect the incident causes will change over time. Immediately
following the incident, there will be some disruption, this may initially increase, and then begin to lessen as the
problem is cleared, and eventually the network will return to normal.
Each incident has a unique reference number (MID), and the changing progress of an incident is tracked by
including a VER with each message. The service provider will allocate a new MID and VER = 0 for a new
message, subsequent updates to the same event are indicated by allocation of the next higher VER. A MID
and version number 255 has the effect of cancelling all earlier versions of the same message.
There are a few particular things to note about MID and VER.
The first is that VER do NOT “wrap around” from version 255 to version 0. In the unlikely event that more than
254 updates to a specific incident is required, service providers must generate a ‘new’ message, using a new
MID (and VER = 0), and cancel the earlier message using Version number = 255. A public transport
information message uses two mandatory elements: MID and VER=255, which, used in combination, cancels
earlier sent messages with the same message ID.
The shortest non-cancellation message contains MID, VER, LOC and EVE; it should be noted that once a
location reference is used, one or more corresponding event descriptions must be included.
The second thing to note is that a message identification number, once used, and then cancelled, must NOT
be re-used until the longest time-period possible has elapsed. Ideally, a service provider should use all
65 535 possible message identification numbers before re-using a previously used MID.
8 © ISO 2006 – All rights reserved

ISO/TS 18234-5:2006(E)
This use of message identification numbers and version numbers will ensure that TPEG-decoders can
unambiguously identify the latest versions of each road traffic message, even if messages are received by the
TPEG-decoder ‘out of sequence’, when for example an earlier version of a message arrives after a
subsequent version, which updates the information that was originally transmitted.
Message identifier and version are the two elements that are mandatory for every message. They are used
for message management purposes in the user’s TPEG-decoder, and are not intended for direct display to the
user.
All other elements of a message are optional, used when appropriate. These include elements relating to time,
the specific or general location to which the message relates, and which particular driving lanes or
carriageway are affected. The service provider is also able to make a judgement on the severity of the effect
the incident may have upon journey times, and whether an authoritative reporter has verified the information.
As a result of a particular message, a user may wish to access more information, perhaps a suggested
diversion route, or even to study alternative modes of transport. An easy means of accessing additional
information, for example road traffic messages relating to an airport terminal, within a different TPEG
application is provided with the cross-referencing information.
5.2 TPEG-message concept
TPEG Applications follow an overall concept, which is indicated by the diagrams in this section to give a quick
and easily understood human concept, before a more technical description is given.
TPEG event messages may be seen as being built from three different parts, or containers, each with its own
clear task: a message management container, an application event container (in this application, the PTI
container) and a location container, a shown in Figure 1. (Location referencing details are described in TPEG-
Loc (CEN ISO/TS 18234-6).
Figure 1 — The three containers
The message management container handles all the elements that allow message tracking, quick
identification, validity and other “administrative” tasks. The elements in the application event container are
used to describe, with the end-user in mind, the reason for the message, what has happened, and what an
end-user may wish to know. The location container describes the location, route or an area for which the
event message is applicable.
Regardless of delivery method, it is assumed that a TPEG decoder will “see” a number of TPEG-messages,
one after the other, where they may be messages defined by one or more Applications. Figure 2 shows this
concept where two applications: TPEG-PTI and TPEG-RTM (CEN ISO/TS 18234-4) messages are streamed
together.
ISO/TS 18234-5:2006(E)
Figure 2 — TPEG-messages showing message management, event and location containers

Where a TPEG-message is one carrying traffic and travel information, Figure 2 also shows that it comprises
three “containers”: one for the message management, one for event content (e.g. “Accident – Buses running
slowly, etc.) and one for the location content (both machine readable and human understandable data).
5.3 TPEG-messages delivering additional information
TPEG-messages may also contain vital information for the full use of a service. For example, a special form
of message which is only a message management container (without any associated location container) may
be inserted to cancel an existing message (see 5.4.1). This concept is illustrated, in Figure 3.

Figure 3 — Delivering additional non-message information
5.4 Elements of a TPEG public transport information message
Most elements of a public transport information are optional, sent only if specifically required. Thus a
TPEG-message container may include various elements according to the following descriptions. Figure 4
shows a TPEG-PTI message, which has three containers.
10 © ISO 2006 – All rights reserved

ISO/TS 18234-5:2006(E)
Figure 4 — TPEG-PTI message normally has three containers
5.4.1 Cancellation message
A special case, used to cancel an earlier message, only comprises the two mandatory elements, message
identifier and version number = 255. Note it does not have an associated location container. This is shown in
Figure 5.
Figure 5 — Cancellation message
5.4.2 Short PTI-messages
Often a message will include only a few elements. The shortest, non-cancellation message may contain only
four elements: MID, VER, EVE and LOC.
5.4.3 PTI-messages — All possible elements
The elements that describe the actual event are taken from the following list.
Their individual combination will reflect on the particular message report type that a service provider has
chosen as the frame for generating the message. These elements form the set of elements needed to
describe public transport information; subsets are presented to an end-user in one of these report types:
incident messages, station/terminal information, route information or individual service information.
ISO/TS 18234-5:2006(E)
The elements are:
— TM: Transport Mode (TPEG table pti01)
— TSM: Transport Submode (TPEG tables pti02 to pti12)
— BDN: Brand Name (text string)
— TSID: Transport Service ID (TPEG table pti14 + text string)
— TSN: Transport Service Name (text string)
— TO: Transport Operator name (text string)
— TOS: Transport Operator subsidiary name (text string)
— SCO: Service Condition type (TPEG table pti13)
— SF: Service Facilities (TPEG table pti23)
— BS: Booking Status (TPEG table pti24)
— TR: Ticket Restrictions (TPEG table pti25)
— ER: Event Reason (TPEG tables pti18 to pti22)
— RDP: Route Description Point (TPEG table pti15 + TPEC-Loc)
— SDP: Service Delivery Point (TPEG table pti16 (scheduled or predicted) + pti17 + text string)
— TMT (Time Type): Time Information (TPEG table pti16 + pti28 + pti34 + time (EN ISO 8601))
— TTT: Timetable Type (TPEG table pti33)
— MRT: Message Report Type (TPEG table pti27)
— ADI: Additional Information: (TPEG table pti30 + loc41 + text string)
5.4.4 Declarative coding
NOTE Every TPEG-PTI element is declaratively coded, and therefore the order of the elements is not defined.
This method of coding allows a public transport information message to contain one or more event description
elements, according to the need to describe various aspects o
...