ISO 14819-1:2003

INTERNATIONAL ISO
STANDARD 14819-1
First edition
2003-06-01
Traffic and Traveller Information (TTI) —
TTI messages via traffic message
coding —
Part 1:
Coding protocol for Radio Data
System — Traffic Message Channel
(RDS-TMC) using ALERT-C
Informations sur le trafic et le tourisme (TTI) — Messages TTI via le
codage de messages sur le trafic —
Partie 1: Protocole de codage sur le système de radiodiffusion de
données (RDS) — Canal de messages d'informations sur le trafic
(RDS-TMC) avec Alert-C
Reference number
©
ISO 2003
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 2003
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 2003 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
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 14819-1 was prepared by the European Committee for Standardization (CEN) in collaboration with
Technical Committee ISO/TC 204, Intelligent transport systems, in accordance with the Agreement on technical
cooperation between ISO and CEN (Vienna Agreement).
Throughout the text of this document, read “.this European Standard.” to mean “.this International
Standard.”.
ISO 14819 consists of the following parts, under the general title Traffic and Traveller Information (TTI) — TTI
messages via traffic message coding:
— Part 1: Coding protocol for Radio Data System — Traffic Message Channel (RDS-TMC) using ALERT-C
— Part 2: Event and information codes for Radio Data System — Traffic Message Channel (RDS-TMC)
— Part 3: Location referencing for ALERT-C

CONTENTS
Foreword.v
INTRODUCTION .vi
1 SCOPE .1
1.1 General Scope .1
1.2 Content.1
1.3 Message Management.2
1.4 Transmission.2
1.5 Event List.2
2 NORMATIVE REFERENCES.2
3 Terms and definitions and abbreviated terms.3
3.1 Terms and definitions.3
3.2 Abbreviated terms .5
4 APPLICATION.6
4.1 General.6
4.2 Definition of the TMC "travel service".6
4.3 TMC virtual terminal .7
4.4 Event-orientated end-user information messages .7
4.5 Strategic and tactical information .7
4.6 Geographic relevance .7
4.7 Transmitted message priority.8
4.8 Event List.8
4.9 Future extensions.9
5 PRESENTATION.9
5.1 General.9
5.2 TMC virtual language .9
5.3 Message content .9
5.4 Implicit information .14
5.5 Optional message content.15
6 MESSAGE MANAGEMENT.19
6.1 General.19
6.2 System messages.20
6.3 Message repetition .21
6.4 Message updating .21
6.5 Message deletion .22
6.6 Message presentation .24
6.7 Out of area referencing .24
7 TRANSMISSION .25
7.1 General.25
7.2 Format of type 8A groups.25
7.3 Immediate repetition.26
7.4 Single-group user messages.26
7.5 System messages.27
7.6 Multi-group messages.34
7.7 Summary of X-bit usage in RDS-TMC type 8A groups .37
iv © ISO 2003 – All rights reserved

Foreword
The text of the International Standard from Technical Committee ISO/TC 204 "Intelligent transport systems"
of the International Organization for Standardization (ISO) a European Standard by Technical Committee
CEN/TC 278, "Road transport and traffic telematics", the secretariat of which is held by NEN.
This European Standard shall be given the status of a national standard, either by publication of an identical text or
by endorsement, at the latest by November 2003, and conflicting national standards shall be withdrawn at the latest
by November 2003.
This document supersedes ENV 12313-1:1998.
According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following
countries are bound to implement this European Standard: Austria, Belgium, Czech Republic, Denmark, Finland,
France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Luxembourg, Malta, Netherlands, Norway, Portugal,
Slovak Republic, Spain, Sweden, Switzerland and the United Kingdom.
INTRODUCTION
Traffic and traveller information may be disseminated through a number of services or means of communication,
covering static displays, inter-active terminals and in-vehicle equipment.
For all such services, the data to be disseminated and the message structure involved in the various interfaces
require clear definition and standard formats, in order to allow competitive products to operate with any received
data.
This standard focuses on the data specification for TTI messages, their network layer and their service layer, to be
conveyed by the RDS-TMC feature, specified in IEC 62106:2000. Other standards are being developed by CEN/TC
278 Working Group 4 to cover TTI messages that may be conveyed by other carriers.
The following terms should be noted, to enable the TTI information chain to be more fully understood.
Data Service Provider: An organisation that manages any data service, by gathering data, processing data and
selling the data service. A Data Service Provider then negotiates for the use of the necessary data bandwidth with a
Broadcaster and/or Transmission Operator. A Data Service Provider is responsible for the "quality" of data to his
customers and must provide suitable customer support. Editorial control over the data may be part of a "data bit-
rate contract" agreement (for example an RDS-TMC service may require the Broadcaster to apply some editorial
control, so that both RDS-TMC messages and other broadcast services, such as spoken or teletext traffic and
travel information, possibly derived from more than one source, are not contradictory).
Programme Service Provider: An organisation that manages and originates programming and associated data for
broadcast. This will often be carried out by a Broadcaster but allows for the subtle distinction, where a separate
company is commissioned to produce a programme, together with associated data, e.g. text of teachers’ notes for
an educational series.
Broadcaster: A traditionally incorporated organisation responsible for a continuous strand of programmes, their
quality and programme associated data, as well as responsible for overall co-ordination of "broadcast
transmissions" (often a Broadcaster is the licensee of a national regulator). A Broadcaster may also be a
Programme Service Provider and sometimes be a Data Service Provider.
Network Operator: An organisation contracted to supply both programme and data circuits interconnecting Data
Service Provider, Programme Service Provider, Broadcaster and Transmission Operator. According to the
connections, various protocols may be used, e.g. ALERT-C, EBU Universal Encoder Communications Protocol.
Transmission Operator: Organisation responsible for the actual transmission of the full broadcast signal including
the audio programme, programme associated data and data services. Normally a Transmission Operator is
contracted to perform the transmission task by a Broadcaster.
Broadcasters already provide valuable TTI services to motorists, in countries throughout Europe, using spoken
reports and teletext information. Due to the widespread adoption of the Radio Data System, there is now the
possibility of transmitting coded TTI messages digitally and "silently" using the RDS-TMC feature, which avoids the
interruption of planned programmes. Potentially this has two advantages: messages can be decoded into the
"language" of the user, regardless of location and many more messages can be made available.
The ALERT-C protocol defined in this specification supports a digital, silent broadcasting service for motorists,
providing information about many kinds of traffic events. This includes roadworks, weather and traffic incident
information relating to major national and international routes, regional routes and local or urban roads.
The present standard is based on the ALERT-C traffic message coding protocol, which was a major product of
DRIVE Project V1029, "RDS Advice and Problem Location for European Road Traffic". The RDS-ALERT project
aimed to define standards for RDS-TMC throughout Europe, working in conjunction with the European Broadcasting
Union (EBU) and the European Conference of Ministers of Transport (ECMT).
vi © ISO 2003 – All rights reserved

Changes that have been made in the present document in comparison with earlier versions and the original ALERT-
C proposal of 1990 are based on comments that have been received from many parties, and have been thoroughly
discussed in CEN TC278 Sub-working group 4.1.
All aspects referring to location referencing were dealt with separately by CEN TC278 SWG7.3 in EN ISO 14819-3
and are not included in this document.
The RDS system is fully described in IEC 62106:2000 and it contains the 'hooks' to RDS-TMC, which is detailed in
this standard. RDS type 3A groups are defined to carry the ODA identification and service and network layer
information, while type 8A groups are defined to carry RDS-TMC message and location information.
Two methodologies are generally distinguished in the ”RDS-TMC world”:
The first approach is based on the idea of a universal ALERT-C service. This is possible if a continuous and inter-
operable network of ALERT-C free-access services is in place in a country or around a continent.
The second approach allows a Data Service Provider to offer a value added service, generally a paid-for service,
which will contain status-oriented messages according to the ALERT-Plus protocol and must also contain event-
oriented messages according to the ALERT-C protocol. For historical reasons, two RDS-TMC Open Data
Applications (ODA) have been defined. The first ODA only allows the implementation of the ALERT-C service. The
second ODA takes into account both possible services (ALERT-C with ALERT-Plus), allowing operation of a
universal service as well as an added value RDS-TMC service on the same transmitter. A service provider is thus
able to offer the universal service, and to propose in parallel to his clients a more sophisticated information such as
travel times. This additional service may be paid-for and encrypted while the basic ALERT-C service may remain
free-access.
Message management issues were also felt to be an area where further discussion was required prior to 'fixing'.
Concern has also been expressed about the desirability of fixing items where the wording had been deliberately left
open pending field trial results. As a result of this, the term 'cycle' referred to in the fixed parts of the text, should not
be considered as prescribing a rigid structure of cycles at this stage.
1 SCOPE
1.1 General Scope
The ALERT-C protocol is designed to provide mostly event-orientated road end-user information messages.
Many "hooks" have been left for future development and indeed a few status-orientated road end-user
information messages were included. This protocol is designed to be closely linked to the ALERT-Plus protocol,
which is specifically designed for status-orientated road end-user information; both protocols may be available in
the same RDS transmission. The ALERT-Plus protocol is specified in ENV 12313-4.
1.2 Content
The presentation section of the ALERT-C protocol specifies messages that may be presented to the user in
accordance with the general requirements set out above. It defines the message structure and content, and its
presentation to the end-user.
RDS-TMC messages are language-independent, and can be presented in the language of the user's choice. The
ALERT-C protocol utilises a standardised Event List (EN ISO 14819-2) of event messages with their code values,
which also includes general traffic problems and weather situations.
ALERT-C defines two categories of information within messages: basic and optional items. In principle, basic
information is present in all messages. Optional information can be added to messages where necessary.
Standard RDS-TMC user messages provide the following five basic items of explicit, broadcast information:
1. Event description, giving details of road event situation, general traffic problems and weather situations (e.g.
congestion caused by accident) and where appropriate its severity (e.g. resulting queue length).
2. Location, indicating the area, road segment or point location where the source of the problem is situated.
3. Direction and Extent, identifying the adjacent segments or specific point locations also affected by the incident,
and where appropriate the direction of traffic affected.
4. Duration, giving an indication of how long the problem is expected to last.
5. Diversion advice, showing whether or not end-users are recommended to find and follow an alternative route.
Optional information can be added to any message using one or more additional RDS data groups. This optional
addition can give greater detail or can deal with unusual situations. Any number of additional fields can in principle
be added to each basic message, subject only to a maximum message length of five RDS data groups.
1.3 Message Management
The message management component deals with the message management functions of RDS-TMC. The ALERT-
C protocol distinguishes between user messages and system messages. User messages are those potentially
made known to the end-user, as defined in the presentation section. System messages are of use only to the RDS-
TMC terminal, for message management purposes.
1.4 Transmission
The transmission component conveys the messages over-air. The ALERT-C protocol, which RDS-TMC uses,
retains the fundamental approach of earlier work, which aims to code most messages entirely within a single RDS
group.
RDS-TMC information comprises both ‘system information’ and ‘user messages’. System information relates to the
particular TMC service, and details the parameters that the terminal needs to be able to find identify and decode the
TMC information. System information is transmitted in type 3A groups and in type 8A groups.
User messages contain the details of the traffic events; these may use one or more type 8A groups. Most
messages may be transmitted using a single type 8A group, however messages with more detail (e.g. diversion
advice) may use up to a total of five, type 8A groups.
1.5 Event List
The ALERT-C Event List contains all event descriptions. It is described in EN ISO 14819-2.
2 NORMATIVE REFERENCES
This European Standard incorporates by dated or undated reference, provisions from other publications. These
normative references are cited at the appropriate places in the text and the publications are listed hereafter. For
dated references, subsequent amendments to or revisions of any of these publications apply to this European
Standard only when incorporated in it by amendment or revision. For undated references the latest edition of the
publication referred to applies (Including amendments).
EN ISO 14819-2 Traffic and Traveller Information (TTI) - TTI Messages via traffic message coding -
Part 2: Event and information codes for Radio Data System – Traffic Message
Channel (RDS-TMC) (ISO/FDIS 14819-2:2002)
EN ISO 14819-3 Traffic and Traveller Information (TTI) - TTI Messages via traffic message coding -
Part 3: Location Referencing for ALERT-C (ISO/TS 14819-3:2000)
ENV 12313-4 Traffic and Traveller Information (TTI) - TTI Messages via Traffic Message Coding -
Part 4: Coding Protocol for Radio Data System - Traffic Message Channel (RDS-TMC)
– RDS-TMC using ALERT-Plus with ALERT-C
ENV 13106:2000 Road transport and traffic telematics - DATEX traffic and travel data dictionary (version
3.1.a)
EN 28601 Data elements and interchange formats - Information interchange - Representation of
dates and times (ISO 8601:1988 and its technical corrigendum 1:1991)
IEC 62106:2000 Specification of the radio data system (RDS) for VHF/FM sound broadcasting in the
frequency range from 87.5 to 108.0 MHz
2 © ISO 2003 – All rights reserved

3 Terms and definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this European Standard, the following terms and definitions apply.
3.1.1
Continuity Index Field
the purpose of the Continuity Index Field is to help distinguish between different multi-group messages. All groups
within any particular multi-group message contain the same value of this continuity index.
3.1.2
Country Code
The Country Code is defined in the RDS specification IEC 62106:2000 and assigns a code to each country.
Country codes are not unique to one country and can be repeated in non-neighbouring countries.
3.1.3
Direction and Extent
Identifying the adjacent segments or specific point locations also affected by the incident, and where appropriate the
direction of traffic affected.
3.1.4
Diversion Advice
Showing whether or not end-users are recommended to find and follow an alternative route.
3.1.5
Duration
Giving an indication of how long the problem is expected to last.
3.1.6
End-user
In this specification, end-user is used to cover the meaning for all possible terminal clients. This could be a vehicle
driver, a user of a portable or fixed TMC receiver or an intelligent client that processes the information such as in a
navigation system.
3.1.7
Event Description
Giving details of the traffic problem (e.g. congestion caused by accident) and where appropriate its severity (e.g.
resulting queue length) or weather situation.
3.1.8
Event List
An agreed table of event descriptions and parameters, assigned an event code value giving details of traffic
problem (e.g. congestion caused by accident) and where appropriate its severity (e.g. resulting queue length) or the
weather situation. The Event List is defined in EN ISO 14819-2: 2002.
3.1.9
Foreign Location Table
A location table different from the default location table used by the transmitter.
3.1.10
INTER-ROAD
A way of referencing locations from other location tables via special multi-group messages. These messages can
be used to inform end-users about problems in other areas, in particular in neighbouring countries.
3.1.11
Extended Country Code
The Extended Country Code is defined in the RDS specification IEC 62106:2000 and assigns a unique code to
each country.
3.1.12
Location
Indicating the area, road segment or point location where the source of the problem is situated.
3.1.13
Location Table
An agreed location table for each service which contains information to indicate the area, road segment or point
location where the source of the problem is situated. Each service has a Location Table defined by the Location
Table Number (LTN).
3.1.14
Programme Identifier
The Programme Identification code is defined in the RDS specification IEC 62106:2000 and assigns a unique value
to each audio programme source.
3.1.15
Silent Cancellation Message
The Event List contains many silent cancellation messages descriptions which are used to delete messages from
the end-user terminal.
3.1.16
Service-ID
The Service ID is used to uniquely identify a particular TMC service from a service provider.
3.1.17
System Information
System Information enables an RDS-TMC terminal to decode and evaluate essential data, which describes the
transmission being received. System Information indicates an RDS-TMC service and comprises some service
characteristics needed to select the RDS-TMC service.
3.1.18
Terminal
RDS-TMC terminals provide the user interfaces with the TMC service. Their functionality may cover a range of
terminal functions from simple terminals with a limited message repertoire and restricted location database to more
sophisticated terminals offering full TMC message features and/or a wide range of strategic and tactical location
databases.
3.1.19
Tuning Information
Tuning Information enables a RDS-TMC terminal to change from one transmitter to another at boundaries of a
particular transmitter’s coverage. Each transmitter should direct the RDS-TMC terminal to specific frequencies or
TMC services in adjacent areas.
3.1.20
User Message
user messages are those potentially made known to the end-user. They contain event, location, direction and
extent, duration etc. descriptions.
4 © ISO 2003 – All rights reserved

3.2 Abbreviated terms
For the purposes of this standard, the following abbreviated terms apply.
3.2.1
AF
Alternative Frequency -an RDS feature.
3.2.2
AFI
Alternative Frequency Information -an RDS-TMC feature.
3.2.3
ALERT-C
Advice and Problem Location for European Road Traffic, Version C.
3.2.4
CC
Country Code -an RDS feature.
3.2.5
CT
Clock Time -an RDS feature.
3.2.6
EBU
European Broadcasting Union.
3.2.7
ECC
Extended Country Code -an RDS feature.
3.2.8
ECMT
European Conference of Ministers of Transport.
3.2.9
LTN
Location Table Number.
3.2.10
MGS
Message Geographical Scope.
3.2.11
ODA
Open Data Application –an RDS feature.
3.2.12
ON
Other Network -an RDS feature.
3.2.13
PI
Programme Identifier -an RDS feature.
3.2.14
RDS
Radio Data System.
3.2.15
rfu
Reserved for future use.
3.2.16
SID
Service-ID.
3.2.17
TMC
Traffic Message Channel.
3.2.18
TN
Tuned Network.
3.2.19
UTC
Universal Co-ordinated Time.
4 APPLICATION
4.1 General
Spoken broadcast traffic messages already provide a valuable information service to motorists in countries
throughout Europe. Digital broadcasting techniques have now become available due to the widespread adoption of
the Radio Data System (RDS). RDS enables traffic messages to be carried digitally and silently by a Traffic
Message Channel (TMC), without necessarily interrupting the audio programme.
The ALERT-C protocol defined in this specification supports a digital, silent broadcast service for motorists,
providing information about many kinds of traffic events. This includes roadworks, weather and traffic incident
information relating to major national and international routes, regional routes and local roads.
Some basic information about public transport is included within the scope of the current protocol for the special
case of ferries and short rail links designed to carry road vehicles, such as Alpine tunnels or the Channel Tunnel.
4.2 Definition of the TMC "travel service"
ALERT-C defines the Traffic Message Channel (TMC) as a travel service digitally and silently broadcast using RDS,
which can provide an end-user with:
— event-orientated end-user information on the nature, severity and probable evolution of both urban and
interurban traffic problems;
— reduced frustration and uncertainty due to this provision of timely and helpful information;
— assistance with journey planning, including rerouting and rescheduling of trips to avoid current or projected
strategic traffic situations;
— details of local traffic incidents which may be avoidable through the use of minor diversions;
— status-orientated information on traffic conditions which can help to support intelligent on-vehicle route guidance
equipment; and
— additional data on roadside amenities and tourism information which can in future complement and update on-
vehicle mobile databases.
6 © ISO 2003 – All rights reserved

4.3 TMC virtual terminal
Information broadcast digitally and silently can only be interpreted by suitable RDS-TMC terminals. These RDS-
TMC terminals provide the user interfaces with the TMC service. Their functionality may vary substantially according
to technical developments and market requirements, which cannot be wholly predicted in advance. Instead, a
virtual terminal model is defined which covers a range of terminal functions, including:
— simple terminals with a limited message repertoire and restricted location database;
— more sophisticated terminals offering full TMC message features and/or a wide range of strategic and tactical
location databases;
— terminals which monitor only a single, selected TMC service, and others which employ more sophisticated
search strategies of several or many channels;
— terminals which are active before the start of a journey, and others which must acquire their TMC data after the
journey begins; and
— terminals which provide output via speech synthesis and/or visual displays, and others which interface to more
sophisticated on-vehicle route guidance equipment.
4.4 Event-orientated end-user information messages
The ALERT-C protocol defines only event-orientated end-user information messages. Provision is also made
for the subsequent definition of other types of message, such as status-orientated route guidance information, or
such other applications as may be desired in future.
End-user information messages are those designed primarily to service an in-vehicle terminal, offering information
directly to end-users via speech synthesis and/or displays. Terminals can also be used in home and office terminals
or public access terminals, to assist in pre-trip journey planning.
Event-oriented messages describe deviations from the normal traffic equilibrium state, and include problems such
as congestion, roadworks, adverse weather conditions, accidents, ferry delays or cancellations, etc.
4.5 Strategic and tactical information
ALERT-C follows EBU Guidelines on Broadcasts for Motorists, revised June 1990, in distinguishing between
strategic information, of value for trip planning and route selection in the medium term, and tactical information likely
to be of relevance for immediate local diversions around current traffic problems.
In more detail, broadcast traffic information comprises:
a) immediate "tactical" information, for transmission as soon as possible, with frequent repeats;
b) medium-term "strategic" information, for transmission at intervals, according to available channel capacity;
c) long-term "background" information, for transmission from time to time;
d) forecasts such as weather and expected road conditions, traffic density, coming events, etc.; and
e) tourist and other messages, including public transport information, which may be relevant for motorists.
The ALERT-C protocol follows these guidelines, aiming to allow as many as possible of the existing spoken
messages to be carried in similar forms using the digital TMC medium.
4.6 Geographic relevance
ALERT-C utilises location coding strategies prepared in guidelines developed within the DRIVE Project. These
guidelines adopt hierarchical principles of structuring the location database in accordance with EBU Broadcast for
Motorists group functional recommendations for strategic and tactical messages. This is dealt with in EN ISO
14819-3.
This protocol does not address the internal management of traffic messages by broadcasters in respect of
geographic relevance. In the following it is assumed, that broadcasters will arrange to transmit messages with a
priority that is appropriate to its geographic relevance. This means, that the frequency with which a message is
inserted into the message cycle is not only dependent on the event but is also a function of the location in relation to
the broadcasting area.
Extremely urgent messages (X-messages) have to be included by all relevant services that cover the respective
area in which the X-message is located.
4.7 Transmitted message priority
Message priorities used by broadcasters adopting RDS-TMC should follow the current approach set out in the EBU
Guidelines on Broadcasts for Motorists, revised June 1990. In the context of RDS-TMC, this can be interpreted as
the following range of transmitted message priorities:
a) Extremely urgent information with highest priority, for immediate broadcast, interrupting existing RDS-TMC
message cycles and being repeated very frequently;
b) Tactical information, for non-delayed broadcast, with frequent repeats;
c) Strategic information, broadcast at intervals according to RDS-TMC channel capacity; and
d) Background information, broadcast less frequently, when channel capacity permits.
The ALERT-C protocol does not address the internal management of traffic messages by broadcasters in respect
of broadcast message priority. The protocol assumes that broadcasters will arrange to transmit messages at the
appropriate level of priority using existing procedures such as those defined by the EBU Guidelines on Broadcasts
for Motorists, revised June 1990.
RDS is a single direction broadcast system – and hence a service provider has no means of knowing if any RDS
data has been successfully and correctly received by any RDS audio receiver or TMC terminal.
A number of factors, including the topology of the broadcasting area, the insertion level of the RDS data signal, the
use of ARI (see IEC 62106:2000 Annex H) on the transmitter, and the location of a particular terminal affect its
ability to receive RDS information. To optimise the possibility of a terminal receiving RDS data, all RDS groups are
transmitted more than once.
For information that is static (or static for long periods), RDS groups are repeated periodically, the period between
successive repeated groups may be several minutes.
For data relating to dynamically changing situations (e.g. traffic conditions), the appropriate RDS-TMC groups are
repeated in quick succession. Typically a type 8A RDS-TMC message group is transmitted, followed by between
three and eleven non-TMC groups, then an exact repeat of the type 8A RDS-TMC message, another gap of
between three and eleven non RDS-TMC message groups, and finally another repeat of the RDS-TMC message
group. The transmission of groups according to this so-called ‘immediate’ repetition pattern was shown in field trials
to be optimal for a terminal to acquire RDS data.
In this ALERT-C protocol, a terminal is required to receive at least two identical RDS-TMC groups, through either
immediate or periodic repetitions, before it can accept the data as being valid (see 7.3 and 7.6).
The protocol does address the separate question of message urgency within the decoder (see 5.4.5). This aspect
of the protocol can be used by terminal manufacturers to determine how a terminal will respond when it receives an
RDS-TMC message. .Depending on the duration type of the event (see Explanatory notes in the Event List), a
message is defined as dynamic or longer lasting dynamic messages may be inserted more often in the periodic
repetition cycle and must be update more often in relation to their duration. Longer lasting messages may be
transmitted less frequently.
4.8 Event List
For the purposes of event-orientated end-user-information messages, ALERT-C protocol utilises a standard
International list of traffic related event descriptions and weather information.
8 © ISO 2003 – All rights reserved

4.9 Future extensions
Provision is made for future extensions to the protocol:
— using the undefined elements of the ALERT-Plus switch bit (x4);
— using the location numbers reserved in the upper part of the location tables; and
— by means of code combinations left unused in the present coding (e.g. continuity index 000 and 111).
5 PRESENTATION
5.1 General
The presentation section of the ALERT-C protocol specifies messages, which can be presented to the end-user in
accordance with the general requirements set out in the application component. It defines the message structure
and content, and its presentation to the end-user.
5.2 TMC virtual language
Traffic Message Channel (TMC) information is conveyed using a "virtual language" in which the codes broadcast
over-air comprise addresses of information stored in databases in the terminals. These databases contain lists of
road event situations, including general traffic problems and weather situations, advice, durations and other
information; plus lists of locations, including intersections, road numbers and place names.
Several processes are involved in the presentation section:
a) before transmission, information concerning an event is mapped into the TMC virtual language by selection from
nested menus of event descriptions and other items, or by a fully-automated traffic monitoring and reporting
system;
b) the resulting coded messages are transmitted via RDS, with frequent repetitions;
c) in the terminal, the TMC codes are checked to see if they contain new information or are updates of already
received messages. New codes are stored in memory and are subject to message management; and
d) at appropriate times the codes are translated back into messages using look-up tables for presentation to the
end-user.
In this virtual language concept, the Event List used at the source and those used in an individual terminal are not
necessarily identical. For example, the messages may be input in one language and reproduced in another. The
translated event descriptions, in the correct wording and traditions of the respective languages and countries, have
to be consistent with the English definitions of the DATEX Data Dictionary version 3.1a, (ENV 13106:2000).
Much of the information conveyed by the codes is implicit and is derived from secondary look-up tables stored in the
terminals. These tables are not addressed by explicit fields in the broadcast information, but are derived from the
context of the message itself combined with information from the message management and other RDS codes
defined in EN IEC 62106:2000.
5.3 Message content
5.3.1 General
The ALERT-C protocol defines two categories of information within messages: basic and optional items. In
principle, basic information items are present in all messages. Optional information can be added to messages
where necessary.
Distinction is also made between explicit and implicit information. Explicit information is broadcast directly using
defined codes. Implicit information is derived from the secondary look-up tables stored within the terminal, which
only occasionally will be explicitly overruled using optional, additionally transmitted codes.
RDS-TMC user messages provide the following five basic items of explicit, broadcast information:
a) Event Description, giving details of the weather situation or traffic problem (e.g. congestion caused by accident)
and where appropriate its severity (e.g. resulting queue length);
b) Location, indicating the area, road segment or point location where the source of the problem is situated;
c) Direction and Extent, identifying the adjacent segments or point locations also affected by the event, and where
appropriate the direction of traffic affected;
d) Duration, giving an indication of how long the problem is expected to last; and
e) Diversion Ddvice, showing whether or not end-users are recommended to find and follow an alternative route.
5.3.2 Event Description (11 bits)
The event description utilised by this standard are listed in the Event List. This standard list is built up from a
repertoire of phrases defined in English in ENV 13106. Many event descriptions are single phrase descriptions. In
addition to these, the Event List contains event descriptions in which two or more phrases from the Data Dictionary
have been combined, so that they can be used (similarly as a single phrase description) in a single-group message.
The event descriptions in the Event List are grouped into update classes. These are used to regulate updating and
cancellation of messages (see 6.4). A number of attributes are attached to each event description in the Event List.
These are described in 5.4, Implicit
...