ISO/TS 18234-4:2006

TECHNICAL ISO/TS
SPECIFICATION 18234-4
First edition
2006-06-01
Traffic and Travel Information (TTI) — TTI
via Transport Protocol Expert Group
(TPEG) data-streams —
Part 4:
Road Traffic Message (RTM) 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 4: Application de message de trafic sur route (RTM)

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

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

Contents Page
Foreword. iv
Introduction . v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions. 2
4 Symbols and abbreviations . 4
5 RTM application overview. 6
5.1 Introduction . 6
5.2 TPEG-message concept. 8
5.3 TPEG-messages delivering additional information . 9
5.4 Elements of a TPEG road traffic message .9
5.5 Message management. 11
5.6 Event description. 13
5.7 Location Referencing . 14
6 RTM container. 14
6.1 Structure of road traffic messages . 14
6.2 Notation . 16
6.3 RTM application component frame. 17
7 Message management container . 18
7.1 Mandatory elements . 18
7.2 Date and time elements. 18
7.3 Severity and reliability elements . 19
7.4 Coding of the message management container. 19
8 Event container . 21
8.1 Event description. 21
8.2 Level one classes . 21
8.3 Coding of the events container . 26
8.4 RTM application primitives . 58
Annex A (informative) Conversion formulae . 96
Bibliography . 98

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-4 was prepared by Technical Committee ISO/TC 204, Intelligent transport systems.
ISO/TS 18234 consists of the following parts, under the general title Traffic and Travel Information (TTI) — TTI
via Transport Protocol Expert Group (TPEG) data-streams:
⎯ Part 1: Introduction, numbering and versions
⎯ Part 2: Syntax, Semantics and Framing Structure (SSF)
⎯ Part 3: Service and Network Information (SNI) application
⎯ Part 4: Road Traffic Message (RTM) application
⎯ Part 5: Public Transport Information (PTI) application
⎯ Part 6: Location referencing applications

iv © ISO 2006 – All rights reserved

Introduction
TPEG technology uses a byte-oriented stream format, which may be carried on almost any digital bearer with
an appropriate adaptation layer. TPEG-messages are delivered from service providers to end-users, and are
used to transfer application data from the database of a service provider to a user’s equipment.
This document describes the Road Traffic Message application in detail.
It should be remembered that the TPEG-RTM has been derived from earlier work that resulted in the
RDS-TMC standards (EN ISO 14819-2). Upon analysis, RDS-TMC can be seen to drift into other application
areas, where it covers a few public transport, parking and weather messages. TPEG-RTM is just one of
several applications required to provide a fully comprehensive traffic and travel information service, for
example a service is likely to need public transport information, parking information and weather information –
these are or will be the subject of other TPEG-application specifications.
Nevertheless, TPEG-RTM, where reasonable, has included the ability to convey similar content to RDS-TMC,
in order to offer considerable backwards compatibility and the prospect of automatically generating RDS-TMC
messages from TPEG-RTM messages.
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-4, provides a full specification provides a full specification for
the Road Traffic Message application.
During the development of the TPEG technology a number of versions have been documented and various
trials implemented using various versions of the specifications. At the time of the publication of this Technical
Specification, all parts are fully inter-workable and no specific dependencies exist. This Technical
Specification has the technical version number TPEG-RTM_3.0/003.

vi © ISO 2006 – All rights reserved

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

Traffic and Travel Information (TTI) — TTI via Transport
Protocol Expert Group (TPEG) data-streams —
Part 4:
Road Traffic Message (RTM) application
1 Scope
This document establishes the method of delivering Road Traffic Messages within a TPEG service. The
TPEG-RTM application is designed to allow the efficient and language independent delivery of road
information directly from service provider to end-users. The information provided relates to event and some
status information on the road network and on associated infrastructure affecting a road journey. For example,
limited information about abnormal operation of links in the network may be included, such as ferries, lifting-
bridges, etc.
The term “application” is used in TPEG specifications to describe specific applications, such as in this case
the Road Traffic Message 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-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 (CEN ISO/TS 18234-3) to indicate how to process TPEG
content and allows routing of data to an appropriate application decoder.
AID = 0001 is assigned to the TPEG-Road Traffic Message application, described in this specification.
A hierarchical methodology has been developed to allow the creation of messages from a set of TPEG-RTM
tables, which are essentially word oriented and cover most needs. Many of the TTI descriptive words, in the
TPEG-RTM tables, were obtained from the DATEX dictionary (ENV 13106), which embodies European TTI
knowledge of the last ten years or more, including a deconstruct of the phrase oriented RDS-TMC events list
(EN ISO 14819-2). These TPEG-RTM tables (essentially word oriented data object dictionaries) comprise a
wide ranging ability to describe a TTI event and some status information, introducing new precision in a
number of areas such as “vehicle types”, “positional information on the carriageway” and “diversion routing
advice”.
NOTE Explicit backwards compatibility with the RDS-TMC events list (EN ISO 14819-2) could not be achieved since
some “update classes”, such as “29 Reference to Audio Broadcasts” and “30 Service Messages”, fall outside the
TPEG-RTM remit.
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/IEC 7498-1, Information technology — Open Systems Interconnection — Basic Reference Model: The
Basic Model
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-3, 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, Traffic and Travel Information (TTI) — TTI via Transport Protocol Expert Group (TPEG)
data-streams — Part 6: Location Referencing application
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-RTM is completely focussed on 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
cross reference information (CRI)
pointer to one or more messages in the same, or another TPEG service
3.2
event description (EVE)
part of a message describing the event, unplanned or planned occurrence affecting the road or transport
network, (for example the transport network in the case of a ferry carrying vehicles between parts of the road
network) or status information, including qualifiers and quantifiers
NOTE This definition varies from the DATEX Data Dictionary definition (ENV 13106).
3.3
locations
see CEN ISO/TS 18234-6 for full details of the location referencing container explanations
3.4
location referencing
method for referencing locations to facilitate the exchange of location related information between different
systems
3.5
message
collection of coherent information sent through an information channel. Describes an event or a collection of
related events, or status information and including message management information. The latter is contained
in the message header
3.6
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)
2 © ISO 2006 – All rights reserved

3.7
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.8
message identifier (MID)
unique identifier for a sequence of versions of one message relating to a particular event of a particular
service component
3.9
position
defines where an event has taken place in relation to the road: driving lane 1, hard shoulder, central
reservation, etc. The driving lanes are numbered according to the usual local practice, i.e. driving lane 1 is the
lane nearest to the hard shoulder. In countries which drive on the left, driving lanes are hence numbered from
left-to-right, and in countries driving on the right, from right-to-left
3.10
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.11
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.12
status
characteristic of an element of the transport system for which at all times a value can be established. Status
relates to an information stream. Values can be normal or deviating from normal
3.13
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.14
time schedule information (TSI)
gives information about the time schedule for repetitive events within the start and stop time
3.15
unverified information (UNV)
indicates that a message includes information from an unverified source
3.16
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).
4 Symbols and abbreviations
For the purposes of this Technical Specification, the following abbreviations apply.
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
CRI
Cross Reference Information (see 3.1)
4.6
DAB
Digital Audio Broadcasting
4.7
DVB
Digital Video Broadcasting
4.8
EBU
European Broadcasting Union
4.9
ETSI
European Telecommunications Standards Institute
4.10
EVE
Event Description (see 3.2)
4.11
ILOC
Intersection location
4.12
INV
Introduction, Numbering and Versions (see CEN ISO/TS 18234-1)
4.13
IPR
Intellectual Property Right(s)
4.14
ISO
International Organization for Standardization
4 © ISO 2006 – All rights reserved

4.15
MET
Message Expiry Time (see 3.6)
4.16
MGT
Message Generation Time (see 3.7)
4.17
MID
Message Identifier (see 3.8)
4.18
OSI
Open Systems Interconnection
4.19
PTI
Public Transport Information (see CEN ISO/TS 18234-5)
4.20
RDS-TMC
Radio Data System – Traffic Message Channel
4.21
RFU
Reserved for future use (not necessarily abbreviated)
4.22
RTM
Road Traffic Message application (this specification)
4.23
SEV
Severity Factor (see 3.10)
4.24
SNI
Service and Network Information application (see CEN ISO/TS 18234-3)
4.25
SSF
Syntax, Symantics and Framing Structure (see CEN ISO/TS 18234-2)
4.26
STA
Start Time (See 3.11)
4.27
STO
Stop Time (see 3.13)
4.28
TPEG
Transport Protocol Experts Group
4.29
TSI
Time Schedule Information (see 3.14)
4.30
TTI
Traffic and Travel Information
4.31
UAV
Unassigned value
4.32
UNV
Unverified Information (see 3.15)
4.33
UTC
Coordinated Universal Time
4.34
VER
Version Number (see 3.16)
5 RTM application overview
5.1 Introduction
The TPEG-Road Traffic Message application allows for a wide range of TPEG-decoder types and
presentation possibilities to be supported. It may support simultaneously a wide range of TPEG-decoder
types, from sophisticated agent TPEG-decoders serving navigation systems, through to simple TPEG-
decoders only able to decode ‘top-level’ information. Some of the possibilities include digital map-based
TPEG-decoders, GPS TPEG-decoders without digital map, and in-vehicle, fixed or portable TPEG-decoders
without either GPS or digital map. Road traffic messages may be presented to the user in many different ways,
including by text, by synthesized speech, graphically, or in route calculation.
Each road traffic message will need to include at least some of the following elements to satisfy the user
requirements for information upon which decisions may be based:
— To whom is the information targeted,
— The geographical location to which the information relates,
— The position on the roadway, or adjacent area affected,
— The event being described,
— How severe is the effect of the described message on the journey,
— Whether the information has been verified,
— The time period for which the message remains valid,
— The consequence the message has on expected journey time in the form of delay information,
— Advice on alternative routes,
— Alternative travel options using other modes of transport by cross-references to other applications,
— Further associated information.
6 © ISO 2006 – All rights reserved

Different road users will have disparate needs and interests in various road traffic messages. Different road
users may have disparate needs and interests in various road traffic messages. Some may be useful to many
users while others may be relevant to only a few users, for example drivers of heavy goods vehicles.
Structure in the coding of messages provides for each to be suitably client-filtered. Filtering can be based on
many elements, including phrases, attributes, location, times, and the severity of the message on the journey.
No additional coding structure is needed.
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 road network, a road 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, an accident occurs, in general the effect the incident causes will change over time. Immediately
following an accident, there will be some disruption to traffic flow, the disruption will increase as traffic builds
up behind the incident, then begin to lessen as the accident is cleared, and eventually traffic flow 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 road traffic 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 as long a time-period as possible has elapsed. Ideally, a service provider should use all 65 535
possible message identification numbers before re-using a previously used MID.
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 public transport timetables, 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 RTM
Container) and a location Ccontainer, 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 (CEN ISO/TS 18234-5) and TPEG-RTM messages are streamed
together.
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).
8 © ISO 2006 – All rights reserved

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 road traffic message
Most elements of a road traffic message 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-RTM message, which has three containers.

Figure 4 — TPEG-RTM 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 RTM-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 RTM-messages — All possible elements
Road traffic messages could theoretically include all the elements and containers shown in Figure 6.
10 © ISO 2006 – All rights reserved

Figure 6 — RTM messages – Message management elements
5.4.4 Declarative coding
NOTE Every TPEG-RTM element is declaratively coded, and therefore the order of the elements is not defined.
This method of coding allows a road traffic message to contain one or more event description elements,
according to the need to describe various aspects of the event. For example, an accident with appropriate
detail and the resultant network performance with appropriate detail and a suggested diversionary route may
be combined together within the same message.
5.5 Message management
5.5.1 Dates and times
Date and time references are included within the road traffic message application to serve two distinct
purposes. The first is for use by the TPEG-decoder, for both presentation to the user and for filtering of
information. The second is essentially for message management, and is not intended for display to the
end-user. Date and time should be expressed with an accuracy of ± 1 second, referenced to Universal
Co-ordinated Time (UTC).
NOTE 1 For the use of the term UTC, see ITU Recommendation 535-1; Use of the term UTC.
NOTE 2 For simplicity in reading this specification the complete phrase ‘date and time’ is often shortened to only: ‘time’.
It should be noted however that the coding algorithm for date and time always causes both date and time to be conveyed
in a message.
5.5.1.1 Start and stop times
The most obvious use is when describing events with scheduled start and end times, for example the times
during which a road is planned for closure for roadworks. Provision is made to specify both a start time and a
stop time for each message. These times are intended for presentation to the user, and possibly may be used
as an element in message filtering by the end-user’s TPEG-decoder.
In the case of a message relating to an unplanned incident, for example an accident, it may be unnecessary to
specify a start time as the incident has already occurred. The end time of an unplanned incident is likely to
change over the lifetime of a message, since it may not be known with any certainty, sometimes it may be
difficult to specify a stop time.
5.5.1.2 Message expiry time
Another use of time information is for message management purposes.
A mechanism is required to ensure that old messages are eventually purged from TPEG-decoders. This is
because there is no guarantee that, once a TPEG-decoder has received a message, it will receive an update
message, or cancellation message. A service provider sending the message expiry time to detail when the
TPEG-decoder should delete a message will therefore achieve message purging.
The message expiry time is not presented to the end-user; it is only for message deletion purposes in the
TPEG-decoder.
5.5.1.3 Message generation time
A message generation time may also be included with each message. This is not intended for display to the
end-user, as its primary purpose is to enable a service provider to track a message through the distribution
and broadcast infrastructure from end-to-end.
If a service provider intends to make use of the service component reset feature (see 5.5.1.5) provided by the
service and network information (TPEG-SNI) application (CEN ISO TS 18234-3), the inclusion of the message
generation time with every non-cancellation (MID and VER = 255) message is mandatory.
5.5.1.4 Time schedule information
For certain types of messages there is a need to give a schedule for when the event takes place. For single
events this time information can be handled by the start and stop time functionality but for certain types, for
example a schedule for the opening times of a tunnel or alternative starting times for convoy driving there is a
need to be able to send schedules for the events. These times are intended for presentation to the user.
5.5.1.5 Service component reset
Another means of deleting messages is possible with the service component reset (SCR) feature provided in
the service and network information (TPEG-SNI) application (CEN ISO TS 18234-3). Use of SCR by a service
provider is optional.
The service component reset is delivered in the guide to the service table for a specific service component
used for the RTM application. On receipt of the SCR for the RTM application, the TPEG-decoder knows that
all messages older than the value in the SCR table are no longer valid. Hence, the SCR feature
provides the ability for a service provider to delete several messages with a single command, as may
exceptionally be required in order to reset the message stock following a major problem with the message
generation system.
5.5.2 Road traffic message effect and reliability
Road traffic messages essentially contain two primary pieces of information: what has occurred, and where.
For an end-user or agent system to make judgements about the effect on travel, it is often necessary to
provide further information. A service provider may optionally provide additional information.
12 © ISO 2006 – All rights reserved

5.5.2.1 Severity factor
A major factor in accessing which messages to present is how seriously the incident is likely to affect the
journey. This is a judgement that can only be assessed by the service provider who will choose one of five
levels to represent the disruption to travel. The severity factor is determined by the service provider taking
into account the seriousness of the incident, weighted by the traffic density at the location affected, to
represent the disruption to travel. The severity factor is likely to change over the lifetime of an event as it
develops.
The severity factor may be one element that is assessed and used by broadcast systems and bearers to
determine message repetition rates, or even which messages to ignore entirely should the total number of
messages exceed capacity on lower data-rate bearers.
5.5.2.2 Unverified information
Although most service providers compile information received from reliable sources, on occasion, due to the
potential importance of the information, it may be appropriate to send a message about an incident that has
not yet been verified. A particular message may be coded to indicate to the end-user that it has not yet been
verified. The TPEG-decoder should present the information to the end-user, indicating that the message has
not been verified.
5.5.3 Cross-reference information concept
Transport Infrastructures are complex and a single incident may have a profound affect on the performance of
many different parts of the infrastructure. Cross-reference information (CRI) fields in the road traffic message
application would allow each message to be cross-referenced to other messages, either within the road traffic
message application, or in other TPEG applications. For example, a road/rail level crossing, which has “stuck
half open and half closed”, may affect travel for drivers, bus and coach users, and rail passengers alike. In
this case, CRI may be used to cross-reference from a public road traffic message application to a private road
traffic message application for bus operators, and to a public transport information application, which is rail
focussed.
The method of cross-referencing will be described in a subsequent version. A new would
be used to convey the cross-referencing information of a message.
5.6 Event description
A major objective of service providers in the development of intelligent information systems has been the
ability to present descriptions of road traffic messages to end-users, independent of language. Currently the
most suitable method of achieving this essential objective is to use a standardized catalogue of descriptive
words or phrases, each represented by a short-form code. A TPEG-decoder interprets this code by reference
to a stored table, and it can then present the phrase appropriately to the end-user. Presentation can be verbal
or in written text form in a language determined by the user, or represented symbolically by an icon.
In TPEG-RTM, the entire event information is built up using descriptive “words” or very short 2/3 word phrases,
with numeric and other quantifiers and qualifiers, selected from a hierarchical classification structure.
At the highest level (level one), there are a small number of distinct classes, (for example, ACCIDENT,
VISIBILITY, ROAD CONDITIONS) which have been chosen to give the end-user a rapid understanding of the
message content. Each level one class then has a number of lower-level branches allowing increased
message detail to be described. This allows total flexibility for the service provider to send as much or as little
detail as they want (or have), and independently, the end-user system to derive and present increasing levels
of detail.
Events are not restricted to being described by reference to only a single level one class. For example, a
message describing freezing snow may appear under both “WEATHER” and “ROAD CONDITIONS” classes.
EXAMPLE This concept of a message using several levels may be illustrated by considering this example of a
message:
“An articulated lorry has overturned in the slow-vehicle lane.”
Level 1 ACCIDENT    (ONE)
Level 2 SLOW-VEHICLE LANE
Level 2  VEHICLE   (ONE)
Level 3  OVERTURNED
Level 3  HEAVY GOODS VEHICLE
Level 4   ARTICULATED
At its simplest, a TPEG-decoder could just advise the end-user of a SINGLE ACCIDENT ahead. A TPEG-decoder
decoding to the second level would be able to enhance this description to advise that the ACCIDENT involved a
SINGLE VEHICLE, in the SLOW-VEHICLE LANE. Level 3 information allows the detail of OVERTURNED and
HEAVY GOODS VEHICLE to be added, and
...