Traffic and Travel Information
(TTI) broadcasting
TTI has a long successful
history - before RDS-TMC
New technologies for TTI
funded by “Europe” within
ITS budgets
RDS-TMC is high
implementation priority for
Europe
Commercial interest in TTI
may not be public service
oriented
Public broadcasters RDS-TMC
services poorly coordinated
Traffic and Travel Information
broadcasting history
Broadcasters recognized the need to help drivers, with easy to understand
information, many years ago! EBU member organizations - the national
broadcasters with country-wide coverage -have a long successful history of public
service TTI broadcasting, delivered free to the end user. For many years they have
cooperated to develop this important area of broadcasting through the ongoing
EBU Broadcasts for Motorists activity and through the Eurotravel conferences,
usually held every four years. The range of TTI broadcasting is considerable and
includes many thousands of spoken TTI announcements across Europe every day,
supported by TV and Teletext information and service phones. Recently this has
been augmented by newly developed services using the Internet and emerging
RDS-TMC services.
Within the EBU framework, this significant broadcasting sector is supported
operationally by daily contacts between EBU members across national boarders, to
provide strategic knowledge covering TTI situations in other countries.
TTI coming up-to-date
In the last ten to 12 years, massive amounts of research and development have been
funded by the European Commission (EC), within the very wide Intelligent
Transport Systems (ITS) budgets, to bring forward many technical solutions for TTI
collection (eg road sensors), information interchange (eg DATEX) and
dissemination (eg RDS-TMC).
However, in the last five years, significant commercial exploitation, using non
broadcasting delivery (eg GSM phones) has been developed to the extent that TTI -
broadcasting and narrowcasting - now has many new opportunities and threats to
consider.
European perspective for TTI
These developments have led the European Union (EU) to declare its policy for
RDS-TMC, as the first priority action for deployment Europe-wide in the next few
years (Community Strategy and Framework for the Deployment of Road Transport
Telematics in Europe, COM(97)223 final). Over the last two and a half years, the EBU
has been working in the EC funded EPISODE Project, which is concerned with
monitoring the RDS-TMC final implementation plans. It is providing a “voice” for
the broadcast sector in the TTI and Transport worlds, which are dominated by
ministries and very large industrial companies who use their lobbying power,
through ERTICO, to influence EC policy-making, and ultimately this reaches the
European parliament decision-makers.
TTI issues are not all straight forward!
The EU priority action to deploy RDS-TMC was considered to become an EU
Directive. This would have imposed the need for broadcasters to implement RDS-

“A fifth of driving time
is spent getting lost on
unfamiliar roads and
motorists waste
350,000 tonnes
of fuel going around
in circles” - The
Automobile Association,
UK
“European statistics suggest that some 680 million road journeys are made each weekday, lasting an average of 20 minutes. If 10% of the
traffic is held up in traffic jams, that represents a total cost of ECU 32 billion per year, not counting heavy-goods traffic! The cost in time lost,
owing to traffic problems, is estimated at 0.5% of the European GDP. Public service TTI broadcasting, helping to alleviate these problems,
is a far from negligible contribution to the economies of the EU Member States.”
TMC, without any possibility of escape! Nevertheless the outcome was a
Memorandum of Understanding (MoU) for RDS-TMC services with so-called, ALERT
functionality. It appears that this MoU hides the use of the ALERT-Plus protocol for
Status oriented messages, as well as the ALERT-C protocol for RDS-TMC Event
oriented services (see article 13). Implementation of ALERT-Plus will not be acceptable
to public service broadcasters, who cannot release the very large RDS data capacity
required for ALERT-Plus.
The commercial sector has continued to attempt to push a point of view, which hardly
recognizes the public service elements of TTI and, as a result, the EU objective of
European-wide deployment of RDS-TMC is considerably delayed.
The EPISODE Project
The EPISODE Project, being a inter-disciplinary group, where journalists, programme
editors and engineers have worked closely together, has been able to monitor both
editorial, end-user and technical issues. As a result, it has issued a number of Project
Statements which are on the EPISODE Project web site at URL: www.rds.org.uk/
episode. These Statements were not always welcomed at the time of issue, but later
the non-broadcast sectors involed in RDS-TMC implementation have come to realise
that the concepts and predictions therein were indeed realistic and valid. Additionally,
the EPISODE Project developed the text of an EBU Statement D81-1996 on RDS-TMC,
which suggests a positioning in favour of RDS-TMC implementation, but also looks
towards the future of DAB.
RDS-TMC implementation steps
Across Europe, many EC-funded Projects are now beginning to set up RDS-TMC
deployments, but these are being driven by ministry and government agencies. The
Euro-Regional Projects, in particular, are aiming at solving cross border issues. From
the broadcasting viewpoint these are not fully coordinated and different models are
being used, including some in which the network-capable public service broadcasters
are not included. In this context the power of the European member states’ transport
ministries to decide on their policies (even potentially to the disadvantage of the
broadcasters traditional sources of information) must not be underestimated.
The European trend for separating broadcasters and transmission operators has been a
cause for concern within the EBU, because the TTI world does not understand the
resulting difficulty that broadcasters face in coordinating on-air information via the
various delivery mechanisms in use: Spoken radio announcements, Internet, TV,
Teletext, and RDS-TMC.
1
 TTI in the new competitive
environment
New multimedia technology
is developed for GSM
Trend to integrate
telematics functionality
into the car radio
Different telematics systems
will coexist
Multi-functionality introduced
by first installed car radio
equipment
TTI is also identified by GSM
operators as a “killer
application”
Navigational systems shall
offer Dynamic Route
Guidance
The upcoming new scenario for
TTI service provision
Future TTI services will have to be developed on the assumption that mobile
communication with people on the road will definitely take place within a new
competitive multimedia service environment where broadcast technology will be
just one delivery mechanism and another will be mobile telephone technology.
In this particular context, we can note the following trend: traffic information
receivers were in the past essentially car radios for which there was a significant
after-market, supported by more than 50 different consumer electronic
manufacturers, mainly from Europe and Far East, supplying a wide range of
products.
Since RDS has been on the market, car manufacturers have tended, more and more,
to integrate the car radio in conjunction with multi-functional displays in the
dashboard, and these will be increasingly used together with other telematics
functionality. Additionally they order OEM equipment, meeting their own
interface requirements, which somewhat opposes any standardization of these
interfaces.
Most recently, the German mobile telephone provider Mannesmann-Autocom
acquired VDO, a large company that manufactures vehicle instruments and car
dashboards and then, Philips Car Systems, one of the major car radio
manufacturers that is also an important supplier of telematic terminals and
navigational systems. All this indicates that the after-market for these products may
gradually shrink and that a number of different telematic systems, as accepted by
the market, will coexist through telematics equipment that is delivered with the car
to the end-user.
The possibility to use GSM for
cell data broadcasting
Studies on the use of the GSM mobile telephone system for the provision of two-
way communication between information centres and computers on-board
equipped vehicles started in the European Commissions’s DRIVE I (1989-1991)
project SOCRATES (System of Cellular Radio for Traffic Efficiency and Safety).
GSM includes the possibility for data communication such as the SMS (Short
Message Services) channel that can be used for traffic message services, point-to-
point and point-to-multipoint (cell broadcast), route guidance and emergency calls.
GSM also provides a full data call functionality that permits implementation of pre-
and on-trip travel planning and also dynamic route guidance in a navigational
system. The widely spread GSM technology is thus, in addition to traditional
broadcasting, very suitable for the provision of a large variety of data services of
interest to mobile road-users, either using the bi-directional communication link or
the inherent data cell broadcasting feature.
Integration of Internet and GSM technology has been studied extensively in the EC
funded PROMISE project. This project aims at the development of a traffic and travel information service employing a
new type of user terminal, the Nokia 9000 Communicator, using the data communication capabilities of the cellular GSM
network.

Finally, the Universal Mobile Telecommunication System (UMTS) will represent the third generation of wireless mobile
voice and data communication. This will probably attain a user data rate of 2 Mbit/s. The wide availability of GSM makes
it a good starting platform for the introduction of UMTS services.

The ETSI standardization work provides for a phased approach of evolutional enhancements to GSM technology with
the view to ensuring a long lifetime for GSM products using earlier versions of the standards.

ERTICO aims at defining a strategy for

supporting ITS services via GSM

With particular regard to ITS services, ERTICO, which is a European ITS technology interest group formed by
manufacturers, service providers, and road authorities, created in early 1997 an ITS services Committee whose members
were major European suppliers and service providers. The aim was to define a strategy for supporting ITS services via
GSM. In the report of this Committee two important developments were identified that enable GSM to
carry ITS services efficiently:

• The first development is the emerging industry standard (in 1997, forwarded to CEN TC 278) for telematics
services called GATS (Global Automotive Telematics Standard) that was jointly developed by two major
European telematics service providers, Mannesmann Autocom and Tegaron (a company created jointly by
Deutsche Telekom and Daimler Benz Interservices). The emerging standard is already implemented in systems to
be offered in Germany as from 1997/98. GATS permits to offer a group of commercial ITS services on GSM. For
data transmission a modular message structure has already been specified on application oriented layers of the air
interface between the service centre and the mobile station. It is subdivided into a transport protocol, conditional
access, a security layer, and application protocols containing service related data.

• The second development is a proposal on generic wireless information access called WAP (Wireless Application
Protocol). WAP can coexist with GATS and extends the functionality towards Internet-like information access
permitting the use of channels with a limited data rate. It thus provides a new access medium to ITS services on
GSM. The first version of the standard was released in September 1997. A WAP Forum will be created to manage
the further development and implementation of this standard.

The ERTICO Committee identified a list of ITS services that can be provided via GSM, as follows:

• Emergency and Breakdown Services / Assistance and Security Services,

• Traffic Information,
• Floating Car Data, based on individual measurements of telematics on-board units
within individual cars; this can be seen as traffic monitoring which can be
implemented at reasonable infrastructure cost,
• Route Guidance,
• Fleet management applications,
• Information Services to provide the driver with individual information,
• Vehicle Theft Detection and Recovery,
• Vehicle Remote Diagnostics.

GSM coverage is generally continuous and covers most of Europe. It is designed to operate in an urban and inter-urban
environment. GSM permits easy implementation of commercial ITS services since the system permits roaming, hand-

2
over, SIM-based authentication.
 The political environment
surrounding RDS-TMC
ECMT and EU policy makes
RDS-TMC a priority
ALERT MoU commits Member
States to deploy RDS-TMC
RDS-TMC receiver
availability - too slow
On-air TTI compatibility - still
to be solved
European Union and ECMT policy
The European Union (EU) has declared a very strong policy towards the use of
RDS-TMC, as their first priority action for deployment, Europe-wide in the next few
years. (Community Strategy and Framework for the Deployment of Road Transport
Telematics in Europe, COM(97)223 final). The European Conference of Ministers of
Transport (ECMT) made a pre-cursor decision about RDS-TMC at the ECMT
Council Session in Annecy in 1994 when the Ministers of Transport adopted a
Resolution on Driver Information and Route Guidance Systems in transport. This
Resolution contained nine principal recommendations of which Recommendation
9 concerned the implementation of RDS-TMC and included the following
recommendations:
• should define and establish all necessary institutional
agreements between participating partners (road and
traffic authorities, police, broadcasters, motorist clubs,
etc.);
• should use RDS-TMC as suitable way to broadcast traffic
messages to motorists;
• encourage and support the creation and updating of
location references for their transport network;
• promote international exchange of traffic messages to
alleviate international traffic;
• promote the adoption of compatible standards for the
supporting subsystems as far as these are needed to
ensure inter-operable sustainable RDS-TMC service.
Lobbying power and Directives
Over the last two and a half years, the EBU has been working in the EC funded
EPISODE project, which is concerned with monitoring the RDS-TMC final
implementation plans. It is providing a “voice” for the broadcast sector in the TTI
and Transport worlds, which are dominated by transport ministries, road
authorities and very large industrial companies who use their lobbying power,
often through ERTICO, to influence EC policy making, and ultimately this reaches
the European Parliament decision makers.
The EU priority action to deploy RDS-TMC narrowly missed becoming an EU
Directive.
This would have imposed RDS-TMC implementation directly on broadcasters,
without any possibility to escape! Nevertheless the outcome was the ALERT
Memorandum of Understanding for RDS-TMC services using the ALERT-C
protocol. However, this MoU hides the use of another protocol known as ALERT-
Plus which is essentially unacceptable to public service broadcasters because it
occupies too much RDS data capacity and if used, would prevent programme-
related RDS features from being fully implemented.
EPISODE project Statements

The EPISODE project, being a multi-disciplinary group of radio-programme and data

broadcast technology experts - one of the first in EBU history, where journalists,
programme editors, and engineers have worked closely together - has been able to
monitor both editorial, end user and technical issues. As a result, it has issued a
number of Project Statements which are on the EPISODE Project web site at URL:
www.rds.org.uk/episode.

Meanwhile the industrial sector has continued to attempt to push a point of view
which hardly recognizes the public-service elements of TTI and, as a result, the EU
objective of European-wide deployment of RDS-TMC is considerably delayed. The
classical chicken and egg problem has been used to suggest that RDS-TMC services
must be on-air before consumer electronics products are made available. Broadcasters
have ensured that RDS-TMC services were indeed on-air as promised (with many
more to follow), to underwrite the political requests and support industry. Then the
display/language issue has been posed as a difficulty because the industry initially
involved in RDS-TMC development has wanted to see unrealistically large initial
markets and expected additional funding for providing products with the necessary
display/language performance.

Euro-Regional Projects -
Broadcasters influence
Across Europe, there are now several EC-funded Euro-Regional Projects beginning to
set up RDS-TMC deployments, but these are being driven by ministry and
government agencies. From the broadcasting viewpoint these are not fully
coordinated and different models are being used, including some where the network
capable public service broadcasters are excluded. In this context the power of the
European member states’ transport ministries to decide on their policies (even
potentially to the disadvantage of the broadcasters traditional sources of information)
must not be underestimated. The European trend for separating Broadcasters and
Transmission Operators has already been a cause for concern within the EBU. The TTI
world also does not understand the resulting difficulty that broadcasters face in
coordinating on-air information via the various delivery mechanisms in use (eg
Spoken services, RDS-TMC, Teletext, TV and Internet).

3
 The public broadcasters role in
TTI service provision
EBU members have a long
history of free TTI services
EBU Events list was
foundation of RDS-TMC
Public Broadcasters need
information freely provided
On-air TTI compatibility -
a key objective
Long EBU History in TTI
As part of their public service remit, the members of the EBU have offered TTI
services freely to the end-user over many years, according to the technology
available. Firstly spoken messages appeared on radio services, followed by the
same on TV; then Teletext added another possibility and in-vision text services
followed; in German speaking areas ARI was implemented and eventually RDS
became widespread with the ability to “flag” traffic announcements, regardless of
listening choice, by using the EON feature. Throughout these developments the
Broadcasts for Motorists activity has ensured cross border liaison between
broadcasters and developed the first Events list (last published in 1990) to facilitate
information interchange between broadcasters, prior to scripting a TTI message.
TTI in the context of programmes
There has been a wide variety of TTI broadcasting across Europe, varying from
short snappy information spoken by professional presenters to long boring
announcements spoken by representatives of the information authority (eg police,
rail, and bus operators). Public broadcasters have willingly opened their
programmes to TTI, believing that their listening public require information free at
the point of use about a wide range of situations, covering all modes of transport.
Nevertheless, there has been an emphasis on road information, being by far the
most accident prone and most difficult sector to provide information to the traveller
in the vehicle.
Such TTI information has built up to the point where in some cases the amount of
TTI messages could be judged to damage the programme presentation style, while
in a few isolated cases it has been seen as a positive benefit to the style. Inevitably
the demand for more and more TTI has continued and RDS-TMC can now be seen
as a positive way of offering increased information in a structured way which will
through some filtering, give the user real advantages with respect to the torrent of
information pouring over him.
Broadcasters want RDS-TMC
It is clear that RDS-TMC will help broadcasters to offer the maximum amount of
information to the end user, but the cost is that a long transition period will be
needed. Initially very few RDS-TMC receivers will be in use, but gradually as they
become more widely available the broadcaster will be able to use the many different
media techniques available again in a more effective way.
Free information to create public
services with on-air consistency
Broadcasters through their information and news-gathering systems are well placed to
be RDS-TMC service providers and to be able to offer a particularly rich service with
factual and anecdotal information. The factual information is most appropriate for the
RDS-TMC service while the linked anecdotal information can be most effectively used
in other ways, often to support traffic management objectives.

The most critical issues that arise from this multi-layered approach are access to
information and on-air consistency. It is vital that public service broadcasters, who
provide free-to-air services for the benefit of the public across many media delivery
methods retain free access to TTI source information. The public broadcasters are
willing to deploy considerable effort to ensure that within their full service offerings,
there is on-air consistency for the benefit of the whole community.

4
 The international bodies involved
with TTI matters - ECMT, EC, CEN,
ECMT has the highest
political impact
The EC heavily invests in new
technology
The EC heavily invest in
building harmonized
infrastructures
CEN is a key organization for
ITS standards
CENELEC has responsibility
for RDS standard
ERTICO lobbies on industry
objectives
A wide range of international bodies is concerned with harmonization related to the
development, standardization and introduction of ITS services in Europe. These
include the provision of TTI data broadcast services involving the public and
private service sectors. The key players with which the EBU is expected to
harmonize its objectives are the following:
ECMT
The European Conference of Ministers of Transport (ECMT) is an
intergovernmental organization for Transport Ministers in 38 European countries.
ECMT Resolution 26 of 1994 led to the creation of a Working Group on Traffic
Management and Road Traffic Information whose task is among others to monitor
the implementation of the recommendations on new information technologies
approved by the Council of Ministers. These include the implementation of RDS-
TMC. The EBU is an invited observers to the meetings held by this Group. The
experience gained from collaborating with this Group is that it has a significant
impact on guiding the transport authorities with respect to technologies that should
be used on a European scale for the exchange and provision of road traffic
information with the view to facilitating the flow of traffic throughout the area
covered by the ECMT.
European Commission
The European Commission comprises many different Directorates, each with
specific sector interests. Each Directorate is divided into Sections concerning
specific matters and two directorate sections have specific concerns with RDS-TMC
technology.
DG VII
DG VII - A2 is the Section for Transport, International Relations and Trans
European Transport Network and Infrastructures, with concern for pilot projects
and implementations associated with RDS-TMC, over the last two or three years
and into the near term future. It supports the Euro-Regional Projects which are
beginning to evaluate the complex institutional cross-border issues interlinked with
RDS-TMC technology with the objective to be surmounted before a fully effective
operational RDS-TMC service can become available to users. In the field of Road
Transport, RDS-TMC has long been a goal and it has recently received a strong
impetus, being nominated by the European Council of Ministers a priority domain
for transport development in EU Member States.
DG XIII
DG XIII - C6 is the Section for Telecommunications, Information Market and
Exploitation of Research Telematics Applications for Transport and Environment,
with concern for many developments associated with RDS-TMC, over the last ten
years or so. The projects of the Telematics Application Programme: Transport
Sector (part of the 4th Framework Programme 1994 - 1998) are involved in the
CENELEC, ERTICO
development, demonstration and validation of enhanced services to transport users. This work, which is coordinated
with other initiatives on the Trans European Networks, also consolidates on the results of the previous programmes of
Research and Development concentrating on the need of users and the development of inter-operability.
In the field of Road Transport, RDS-TMC has long been a goal and funding was secured for the EPISODE Project
and the FORCE Project who, among other things, are progressing the standards development in cooperation with the
ECORTIS Project which has an emphasis on implementations. The former Projects have cooperated with the standards
organization, CEN to finalise the activity of several Working Groups and are now actively involved in disseminating
information about the inter-related RDS-TMC standards, for all workers in this field, before they are eventually
published.

Comité Européen de Normalisation (CEN)

The Comité Européen de Normalisation (CEN) is one of several European organizations responsible for
standardization (see Article 9). The corresponding international standards body on a worldwide level is the ISO.
European standards take precedence over national standards and even replace them.

Comité Européen de Normalisation Electrotechnique (CENELEC)

This is the European organization in charge of European standards in the electrotechnical sector. The Technical
Committee TC 107 (now called TC 207) issued the original RDS specification (see Article 9). The corresponding
international standards body on a worldwide level is the IEC.

European Road Transport Telematic Implementation

Coordination Organisation (ERTICO)

ERTICO, with its offices in Brussels, brings together industry, public and private infrastructure operators (mainly road
authorities and motorway companies), public authorities and, as they say themselves, also users.
It is a partnership created in 1991 on the initiative of a number of DRIVE project partners with the objective to
supply support to the EC for the provision of a coordination service which was since then much required to ensure a
higher degree of harmonization between the numerous projects. The legal entity of this “international association” is
that of a Belgian Cooperative Company, having itself given the aim by its founders “to identify and promote an effective
implementation strategy for the development of ATT (Advanced Transport Telematics) in road transport
infrastructures, exploiting the results achieved by EC funded ITS projects, and other national research and development
programmes, thus assuring a smooth transition from pre-competitive R&D to the market-driven investment of sector
actors”.
Consequently ERTICO has objectives such as to define long term transport telematics requirements, to
harmonize technical developments and specifications and to coordinate and to verify application fields.
In the RDS-TMC area, ERTICO has taken action to coordinate a consolidated message catalogue which is based
on the evaluation of all relevant DRIVE projects, in particular those of ALERT and STRADA. The coordination work of
ERTICO became a large part of the DRIVE II programme and the corresponding project was called CORD. In the area of
creating a European road database, ERTICO has also been active and has proposed harmonized coding rules based on
ALERT and SOCRATES requirements. Another area of activity concerns the traffic information cross-border data
exchange format DATEX, using the ISO standardized EDIFACT data communication protocol. In Autumn 1997 a
Memorandum of Understanding was signed by many EU countries in support of DATEX, recommending its
implementation.

ERTICO now has the vision, established during 1995, to stimulate wide deployment of RDS-TMC and yet continue to

5
evaluate other TTI options for the future, such as DAB delivery of TMC TTI messages.
 What is RDS?
RDS stands for
Radio Data System
RDS has been operational on
FM for more than ten years
Originally developed by the
EBU - now standardized by
CENELEC
Now by commercial and
public broadcasters alike,
across the world
Radio Data System
RDS uses the technique of adding data to a sub-carrier on an existing stereo
transmission in such a way that the data is carried inaudibly. RDS is designed with
a wide range of features to support programme-related aspects and to allow non-
programme-related data services to also be added, if capacity exists. RDS is
reported to have reached well over 50 million products in its first ten years, but now
it is almost impossible to buy a non RDS car radio in western Europe. Nevertheless
for RDS-TMC services it will require a whole new range of RDS-TMC compatible
products to be developed and marketed.
RDS tuning features
The most obvious RDS features are those seen on a typical RDS receiver. Modern
car receivers usually support the following features:
Alternative Frequencies (AF)
The AF feature is intended to give information on the frequency of the various
transmitters broadcasting the same programme in the same or adjacent reception
areas, to enable receivers equipped with a memory to store the list(s), to reduce the
time for switching to another transmitter. This facility is particularly useful for
mobile car and portable receivers.
Programme Service name (PS)
The Programme Service name feature is designed to provide information for an
RDS receiver to display the name of the radio programme service, instead of, for
example, the tuned frequency being displayed. The PS is formatted for eight
character displays using either LARGE or small characters, for example:
>Classic_<. The PS name is intended to inform the listener what programme
service is being broadcast. The Programme Service name is not intended to be used
for automatic search tuning and must not be used for giving sequential
information.
Traffic Announcements (TA)
The Traffic Announcement indicator feature is a two-state flag signal to inform a
receiver that there is a Traffic Announcement on air or not. This signalling may
permit a receiver to: switch automatically from any audio mode to the traffic
announcement; switch on the traffic announcement automatically when the
receiver is in a waiting reception mode and the audio signal is muted; switch from a
programme to another one carrying a traffic announcement, according to those
possibilities.
Traffic Programme (TP)
The Traffic Programme indicator feature is a two-state flag signal to inform a
receiver that the transmission being received carries Traffic Announcements or not.
The TP flag must only be set high on transmissions which dynamically switch on
the TA indicator flag during Traffic Announcements. The TP signal may be used
during automatic search tuning.
RDS support features

Programme Type (PTY)

The Programme Type feature uses an identification code, transmitted with each
programme item, which is intended to specify the current Programme Type from 29
possibilities, such as News, Drama and Sport. This code may be used for various
tuning modes and can assist a suitable receiver and/or recorder to be pre-set to
respond only to programme items of the desired type. The PTY feature also carries an
alarm functionality (and testing) to switch on the audio when a receiver is operated in
a waiting/muted reception mode.

Radio Text (RT)

The RadioText feature allows the transmission of text messages up to 64 characters in
length to be conveyed primarily to consumer home receivers. Shorter messages are
also possible and they may be frequently altered at a reasonable rate to allow
programme related information such as music title, conductor, orchestra and CD
number to be followed.

RDS supports a wide range of programme-related and non-programme-related

features, including:

Clock Time and date (CT))

Decoder Identification (DI)
dynamic PTY Indicator (PTYI)
Enhanced Other Networks information (EON)
Music Speech switch (MS)
Open Data Applications (ODA)
Programme Item Number (PIN)
Traffic Message Channel (TMC)

Many other data services features are also possible within RDS transmissions, by using
the Open Data Applications (ODA) feature.

Prototype BBC home tuner, 1982

Volvo SR 701 the first RDS car radio, 1987

Philips car radio: with PTY - News selection button 6

 The RDS-TMC concept
The need for TTI increases
as traffic volumes increase
RDS-TMC provides
language-independent
messages
Existing RDS receivers cannot
be adapted to RDS-TMC
RDS-TMC receivers require a
double-tuner: one for radio
listening, the other for
TTI
RDS-TMC receivers present
the user only with relevant
messages concerning his
journey
Objective
The objective of RDS-TMC is to broadcast Traffic and Travel Information (TTI)
messages as data on FM transmissions using RDS. This allows delivery of accurate,
timely, and relevant information without the need to interrupt the radio
programme - just the opposite of the common practice today with spoken traffic
messages. Thus, TTI can inaudibly be data broadcast in the background of existing
FM radio programmes.
Data collection
Data about traffic events are collected in regional and national Traffic Information
Centres, with many in the near future interconnected for the exchange of their
messages, across the national borders using the DATEX protocol.
Language independence
The messages are digitally coded in such a way that they are language-
independent. Standardized event and location code lists are being used to achieve
this. The coding also permits users to receive only those messages that are relevant
to their needs. Thus it may be possible for a tourist to travel, for example, from
London to Rome, through Belgium, Germany, Switzerland, France and Italy, while
always getting the traffic announcements via RDS-TMC in his own language, the
location codes being on a smart card or CD-ROM that he purchased in London. But
for this objective to be really achieved, apart from an agreed set of European
Standards specifying the system, there is additionally a strong need for a large
number of harmonized administrative and institutional agreements still to be
coordinated among the countries concerned.
Message filtering
The TTI messages that are distributed will, of course, be conveyed to and stored in
receiver memory which may subsequently permit traffic announcements to be
presented via speech synthesis in the language required. Messages can be filtered
on the basis of criteria derived from the needs of the end-user (eg location, direction,
route). This filtering thus aims at enabling the user to receive only relevant
information, selected from all the messages that are available on an RDS-TMC
service, at any given time.
The importance of filtering is demonstrated in this example: given the maximum
capacity of RDS-TMC, it will be possible to transmit about 300 different messages in
the air at any one time. If the same messages were spoken and each only took 15
seconds, the total announcement time would be 75 minutes. An obvious
information overload! In addition, RDS-TMC messages could be used to provide
assistance for route-planning, use of alternative transport facilities and routes,
continuous up-dating of electronic maps and systems used for navigational aids.
RDS has a very limited data transmission
capacity
The limited data transmission capacity of the RDS system does not generally permit
implementation of RDS-TMC on all programme services of the same broadcaster.
Therefore, for an RDS-TMC receiver to function correctly as a radio, allowing the end-
user to freely choose the radio programme, the RDS-TMC receiver must have a double
tuner to permit one tuner to always be used for radio listening and the other tuner be
used for RDS-TMC data collection.

7
 The RDS-TMC development
history
RDS-TP/TA was a first step in
the 1980s
EON provided a significant
enhancement
RDS-TMC development
started mid-1980s
1994 - ECMT recommends
RDS-TMC
1995 - EC chooses RDS-TMC
to become a priority issue
1997 - RDS-TMC starts to
become an operational
service
RDS-TMC implementation
across the EU continues into
the year 2000
From ARI to RDS-TP/TA
Traffic and Travel Information (TTI) is just one essential component of RDS, which
was clearly recognized long before RDS was first standardized in the mid 1980s. By
providing the traffic flags TP and TA which, as a concept, were developed for the
ARI system in the early 1970s, a basic service for spoken messages is in place thanks
to the very strong commitment of many public broadcasters in Europe, coordinated
through the EBU’s Broadcasts for Motorists activity.
RDS-TP/TA enhanced through EON
RDS next allowed the use of the EON feature to deploy a service using these flags,
but signalled in other radio programme services with vectoring information to
enable the listener to hear - when the EON option had been activated in the RDS-
EON receiver by the listener -the traffic announcements from any cross-referenced
programme. This has by now developed into an option much used to give
specifically also traffic announcements about local situations.
RDS-TMC appears on the horizon
The possibility of digitally coding traffic information and making it language
independent within the RDS data stream, was first mentioned by Bosch/Blaupunkt
in 1984 at the EBU Eurotravel conference in Grado, Italy. Bosch/Blaupunkt
immediately started the technical development in Germany, and Philips in the
Netherlands followed shortly afterwards. One year later, the European Association
of Consumer Electronics Manufacturers, known then as Eurotech (now EACEM)
agreed with the EBU that they would then jointly support the development of the
RDS-TMC feature, still called at that time CIM (Comprehensive Information for
Motorists).
European Commission involvement and
the ALERT-C protocol
The EBU accepted this proposal and created a group of RDS specialists in which the
interested manufacturers participated. In 1986, Bosch/Philips submitted a common
proposal which became the basis for further development. Pushed by the ECMT,
the EC became very interested in the objective to develop an RDS-TMC feature and
it was widely agreed due to the strong lobbying of Bosch/Philips to launch a
development project that included already a number of validation field trials in
several EU Member States. Subsequently, the RDS-TMC transmission protocol,
defined in 1991 in the EC/DRIVE I project as ALERT-C, became the basis for further
development.
Development of a European standard
for event codes
An agreed list of event codes was now needed and it was recognized that the EBU had
already issued in 1988 such a list which covered seven languages. However, through
the EC funded projects, the EBU event list was eventually much extended and
harmonized between all sectors interested in RDS-TMC service provision, but without
further involvement of the EBU. By now that event code list is standardized by CEN
(see article 9).

RDS-TMC becomes a priority issue for the EC

In the years 1992-1994, a number of RDS-TMC field trials (14 Euro-regional projects in
total) took place as part of the EC/DRIVE II programme on Advanced Transport
Telematics to test the feasibility of the service. The experience gained was largely
positive, so that in September 1995 the Council of Ministers at a meeting held in Essen
(Germany), recommended the general introduction of RDS-TMC as a priority action
for the further development of the Trans European Road Network (TERN) in all EU
Member States.

The EC-funded development work over the preceding ten years were coming to
fruition. It was recognized that the existing FM and RDS infrastructures were
substantially complete across Europe and that the language independent TTI services
capability of RDS-TMC would be very advantageous to the citizens of the EU member
states.

1997 was the year when the first operational RDS-TMC service introductions started in
a few EU member states (or only parts of them and some of them still only on a pre-
operational basis). The others have made in the meantime firm plans to follow in the
years up to the year 2000s. As a priority, these new RDS-TMC services intend first of all
to cover all major roads belonging to the TERN.

Since a public and open service is generally expected to become available all over the
European Union, it is also hoped within the European Commission that public/
private partnerships (ie partnerships between road authorities, police, automobile
clubs, industry, broadcasters etc.) will become possible within the EU member states
and that these will then work together actively towards achieving RDS-TMC
implementation to support the policy addressed in the resolution from the Council of
EU Ministers.

8
 European Standards for
RDS-TMC
RDS-TMC standardized by
CENELEC and CEN
EN 50067:1998 - the RDS
standard upgraded for
RDS-TMC
ENV 12313 series for
TMC - only pre-standards
completed
ENV 12313 series contain IPR
with licencing consequences
ALERT services covered by
MoU
Standards Background
The EC funded FORCE/ECORTIS Projects and the EC-funded EBU EPISODE
Project have been working for the last three years to complete the RDS-TMC
standardization, in collaboration with the RDS Forum and CEN TC 278 Working
Group 4. This was necessary to provide a comprehensive platform for a European
wide implementation of RDS-TMC. This is sometimes called the ALERT service
and has become the subject of the so-called ALERT Memorandum of
Understanding (MoU).
Since any ALERT service uses the TMC feature of RDS, conveyed by an RDS sub-
carrier added to the baseband multiplex signal of a VHF/FM Band II transmission,
it is usual to consider the RDS standard, CENELEC EN 50067:1998, as the core
specification. Additionally, a series of CEN pre-standards (including a considerable
amount of European industry IPR) are then used to fully specify RDS-TMC
functionality which comprises the message protocol, event messages, location
referencing, and the newer extension named ALERT-Plus, specified for Status
messages.
Specification of the RDS system
- the “core” RDS standard
(CENELEC EN 50067:1998)
The RDS standard is a truly “open” standard, originally developed by the EBU in
the early 1980s, then published as a European standard in 1992. It has recently been
updated as a result of successful work by the RDS Forum and CENELEC TC 207.
The standard is now available (from CENELEC and the EBU) published as
CENELEC EN 50067:1998 and contains several new features including the ODA
feature, originally suggested for RDS-TMC purposes; additionally it includes
specific references and “hooks” to the RDS-TMC standards in the CEN ENV 12313
series. Furthermore RDS Guidelines are being prepared by the RDS Forum and will
be published shortly. Comprehensive information can be obtained from the RDS
Forum web site at URL: www.rds.org.uk/.
Coding Protocol for RDS-TMC
- the “ALERT-C protocol”
(CEN ENV12313-1)
The coding protocol for RDS-TMC is defined in CEN ENV 12313-1:1998 and is now
available from the CEN Central Secretariat. Therefore this should be taken as the
main standard describing, the so-called, ALERT-C protocol. This standard contains
both the protocol and the RDS-TMC related coding which now uses type 1A, 3A
and 8A groups (ODA compliant format). It is to be hoped that the FORCE/
ECORTIS Projects will publish Guidelines for RDS-TMC shortly.
Event and Information codes for TMC
- the “Event List”
(CEN ENV12313-2)
The Event and Information codes for RDS-TMC, required by the ALERT-C protocol
are specified in the CEN ENV12313-2 standard and is now available from the CEN
Central Secretariat. This standard uses the so called CEN-English to define a traffic
message, eg “stationary traffic for 1km” which is code 102. The meaning of this code
has to be defined for each of the European languages and this work was completed in
spring 1998. In the example used above, it is interesting to note that the official UK
“translation” of code 102 is “stationary traffic for ½ mile”.

Location referencing rules for RDS-TMC

(CEN ENV12313-3)
CEN TC 278 SWG 7.3 has been responsible for drafting this standard which is now
planned to become the third part of the ENV 12313 standards series, specifying and, in
this case, detailing the Location referencing rules. These rules are required so that
every TMC Service Provider uses common methodology in creating their location
database, but it does not restrict their value-added aspects, allowing some to code
more “finely” than others. In early drafts, some variation of interpretation resulted,
and the FORCE/ECORTIS Projects established a subgroup “Interpretation of the
Location referencing Rules” with the intention to write a “Location coding
Handbook”.

European Pre-standards, numbered

in the ENV series
The CEN Internal Regulations state that a European Pre-standard may be established
as a prospective standard for provisional application in technical fields where the
innovation rate is high (e.g. Information Technology) or, when there is an urgent need
for guidance and primarily where aspects of safety for persons and goods are not
involved.

The lifetime of an ENV is first limited to three years. An extension of the ENV for
another two years (only once) is possible. It can also be converted after formal vote into
a European Standard in the EN series. As far as the ENV 12313 series of European Pre-
standards for RDS-TMC is concerned, it is unclear at the time of writing, when the
conversion from the Pre-standard ENV to the full standard EN will be made, for all
three specifications mentioned.

9
 The Open Data Applications
concept and RDS-TMC

Open Data Application -

designed for RDS-TMC RDS standard provides ODA for RDS-TMC

The Open Data Applications (ODA) feature of RDS was developed to allow data
ODA registered with EBU applications, not previously specified, to be conveyed in an RDS datastream, with
RDS Registrations Office minimal difficulty. The ODA feature, specified in the RDS standard EN 50067:1998,
permits a number of pre-determined RDS groups types to be used and these have to
be indicated in any RDS transmission using the ODA-Application Identification
ODA for ALERT-C (AID) feature, to allow decoders to monitor for them and then decode the relevant
data. A wide choice of groups are available for use by ODA data services and these
may be selected by a Transmission Operator at his convenience. The service is
ODA for ALERT-Plus identified in the associated RDS type 3A groups, in the same RDS datastream.
Labelling RDS-TMC services
RDS-TMC standards use predefined ODAs which have been agreed for simplicity of
decoder design, in advance of the service introductions. The so-called ALERT service
(see article 13) encompasses two protocols: ALERT-C and ALERT-Plus, which are
treated as two entirely different ODAs. However a service labelled as the latter must
also include ALERT-C messages. Thus, both applications use type 8A groups, both
have the same application group type 8A, but a different AID, which a decoder can use
to “unscramble” the data according to which service the data applies.

Capacity limitations for RDS-TMC

must be observed
It is important to note that the AID for the ALERT-C service only permits a maximum
of two ODA groups per second (including type 3A, and 8A groups) to be used;
whereas the ALERT-Plus service is registered to use a maximum of six groups per
second (including type 3A, and 8A groups). In practice this means that ALERT-C
services can probably only be implemented on existing RDS transmissions where the
Broadcaster can spare this capacity. However “ALERT-C with ALERT-Plus” services
can only be accommodated on FM transmissions not previously using RDS features
for the radio-programme related RDS service and specifically RadioText. Once in
operation, the radio-programme related RDS features can most probably no longer be
implemented since RDS has insufficient data transmission capacity for all the defined
RDS features to coexist on the same radio programme. This requires also a choice to be
made of those needed by the broadcaster and if he does not own the transmitter
network, he would need at least to be consulted by the Transmission Operator.

Reviewing RDS-TMC registrations

These ODA AID allocations are subject to review by the EBU RDS Registrations Office

10
in early 1999, after suitable field implementation experience was gained.
 The Universal Encoder
Communications Protocol
Initial RDS infrastructures
need to upgraded for RDS-
TMC
The UECP is a de facto
industry standard for RDS
encoders
Permits networked operation
of RDS encoders from various
suppliers
Supports latest version of the
RDS-TMC standards
and
Existing RDS infrastructures of the
nineteen eighties do not support RDS-TMC
At the time when RDS was implemented (starting in 1984) nobody had given any
thought to using this infrastructure one day for RDS-TMC.
Transmission Operators who want to implement any type of RDS service need to
install RDS encoders. They are normally installed at transmitter sites adjacent to the
stereo encoder, which generates a 19 kHz signal that the RDS encoder uses to
synchronize its output RDS datastream.
Static versus Dynamic RDS
Two “types” of RDS can be provided: Static RDS services can be provided by an
RDS encoder simply providing RDS information, such as a fixed AF list, from
internal memory; whereas Dynamic RDS services, such as RadioText, require data
input to an RDS encoder.
Even Static RDS services may have to be changed from time to time, depending
upon the network configuration and the type of radio programme on air.
Dynamic RDS is needed for a number of reasons. RDS data related to the radio
programme content requires a high degree of control from the on-air studio. In the
case of a data service such as RDS-TMC, a high degree of control is required from
the Service Provider to supply their data to the RDS encoder, either to a single
broadcast transmitter or to a network of broadcast transmitters.
Once a Dynamic RDS encoder has been chosen, then in most situations, a uni-
directional data link has only been possible for update-data to be sent to the RDS
encoder. This is due to the fact that for economic reasons the Transmission Operator
had to adapt existing analogue, or even digital, audio distribution networks which
are essentially uni-directional, to add a data distribution function.
Proprietary communication protocols
versus the open UECP
A number of proprietary RDS encoder update protocols were initially implemented
on data links between source RDS data servers and the RDS encoders; several of
them were encoder manufacturer specific. These protocols were used to send data
messages from an RDS controller/management system (or simply an RDS encoder
server) to the RDS encoders. Acknowledgements from the encoder were not
essential and, instead, it was arranged to send repeats of each message in order to
ensure their receipt. In this way a whole range of Dynamic RDS features could be
used by the broadcaster to enhance RDS performance for the listener. In some cases
an RDS encoder controller, running on a PC, has been used to send update
messages to the RDS encoder, or if a very full implementation is required, then a
dedicated RDS management computer system, frequently called an RDS Server,
has be used to control, on a scheduled basis, the whole range of RDS features,
RDS-TMC
including the radio programme related RDS features and the full array of EON
reference data.

In the early 1990s, the EBU began to deal with a requirement that the various existing
and implemented RDS encoder communication protocols should be harmonized with
the view to facilitate the upgrading of already existing encoder equipment and also its
replacement, not necessarily with equipment from the initial supplier. Such
harmonization would then enable broadcasters to purchase RDS system components
(eg RDS encoders, RDS Server computers and software) from a variety of sources. This
would permit significant economies in network operation and it would offer the
necessary high flexibility to implement, in successive stages, enhancements to already
existing RDS implementations, specifically within transmitter networks. RDS system
component manufacturers would then also be able to integrate their products with
those from other manufacturers, enabling more complex systems to be produced than
those that would otherwise have been impossible.

These proprietary update protocols had similar functional elements, however they
differed significantly in their environmental models. The structure, functionality, and
addressing of their intended networks and the data structures within each RDS
encoder are often quite different. Therefore the Universal Encoder Communication
Protocol (UECP) specification, now widely accepted by broadcasters and the whole
industry involved, was based on harmonized environmental and encoder models.

The UECP is a layered communication protocol which is in line with the commonly
used OSI reference model (ISO Recommendation 7498). The UECP in its present
Version - 5.1 (August 1997) - encompasses all current RDS features including the latest
TMC specifications and it is also designed to accommodate all new developments that
will use the ODA concept.

EBU developed with the UECP a de facto

industry standard
This de facto standard, developed by the EBU was the result of Broadcasters and
Transmission Operators realising that they needed a common standard to
communicate from broadcast centres to transmitters where the RDS encoders are
situated, to allow more suppliers into the niche market for professional equipment.

EBU SPB 490, the Universal Encoder Communications Protocol, is now operated by
many major Broadcasters and Transmission Operators in Europe. It defines the data
stream used between RDS servers and RDS encoders. Version 4.0 included all
commands to match the RDS standard, EN 50067:1992. It was then upgraded by the
RDS Forum, between 1996 and 1997, to include the full ODA set of commands and the
special RDS-TMC commands specified in CEN ENV 12313-1:1998. The most recent
edition of SPB 490, Version 5.1, was issued in 1997, and it is available for downloading
from the RDS Forum web site at URL: www.rds.org.uk/.

11
 Principles of RDS-TMC
Location reference coding
For RDS-TMC message
encoding and decoding
the same code table is
mandatory
Location code tables need
to be created specifically
for RDS-TMC
Location code tables require
maintenance
ALERT-C and ALERT-Plus use
different location code tables
Messages referring to locations require
in RDS-TMC a Location reference code
Most RDS-TMC messages provide information about a location (e.g. a stretch of
road, an intersection, a region) and they refer to it by using a location reference. This
is an identifier that can be interpreted without ambiguity by the receiving system.
In RDS-TMC, locations are pre-defined and pre-coded, and the codes are stored in
location code tables. The maximum number of codes in one table is determined by
the field length for location codes in RDS-TMC, i.e. 16 bit which corresponds to
65,536 possible codes.
An obvious disadvantage is
the maintenance required
The disadvantage of these tables is that they need to be created and maintained (see
article 16). The receiving system must use exactly the same Location code table as
the one used for encoding of the message. Otherwise the message is not receivable.
The rules for location reference coding are specified in CEN pre-standard ENV
12313-3 (see article 9). These rules apply to ALERT-C messages only.
ALERT-Plus uses a different system. Because of the provisional nature of ALERT-
Plus, no further reference is made to that particular coding method and all details
that follow are extracted from the pre-standard and apply thus to ALERT-C
messages only.
Principles of arranging
the location codes within tables
Pre-defined locations are referenced by their location code which is the tabular
address of a number of pre-stored location details. Each table of stored locations
must be given a unique location table number by one unique agency in each country
or state. A country code (note: RDS-TMC uses the RDS country codes) identifies the
agency responsible for location reference coding and which defined the location
table and its number.
The concept of primary and
secondary locations
Many location references extend through several adjacent areas or road sections.
The concept of primary and secondary locations is then used to indicate the
extremities of the affected sections, without having to list all the intervening places.
For example, if an accident occurs at “km 14.2” on the E15 (A26 road in France) and
the resulting queue extends back to “km 10.9", the situation location can be defined
as E15, “km 14.2 - 10.9”. Where “km 14.2” is defined as the primary location and
“km 10.9” is then the secondary location. The primary location is taken to be where the
cause of the problem can be found, whenever a cause can be pin-pointed
geographically. However, both, primary and secondary location shall lie on the same
road.

For the primary location, the location reference is the nearest downstream location in
the direction of travel. The secondary location is indicated in terms of extent, i.e. the
number of steps back along the road, through other pre-defined locations.
Alternatively, a distance marker may be used.

The EUROAD concept

All location codes belong to a unique location table. Within any particular location
code table each location has one unique number in the range 1 - 63,487. The other 2048
numbers are reserved for EUROAD, an agreed concept used for coding messages to
international travellers on the Trans European Road Network (TERN).

The hierarchical structure of

the location code tables
RDS-TMC uses a hierarchical structure of pre-defined locations. A system of pointers
provides upwards references to higher level locations containing the specified
location. For example, Kent would have an upward area reference to South-East
England which will be upwards referenced to the UK, then the British Isles, then
Europe.

Junction 25 on the M1 motorway in the UK would have a section of route referenced to

a motorway segment, e.g. Leicester - Sheffield. This segment will then be referenced
upwards to the whole road, i.e. the motorway M1.

What is a Direction and an Extent code

in RDS-TMC?

Also, Junction 25 on a motorway may be offset to Junction 26 in the positive direction,

and to Junction 24 in the negative direction.

In many cases, events affecting road traffic, cover a number of locations, such as where
an accidents results in long tailbacks. The ALERT-C protocol defines such occurrences
by addressing the location of the accident as the primary location, then identifying the
end of the tailback by using the direction and extent fields. These fields consist of 4 bits
in total, one direction bit and three extent bits. The direction bit indicates the queue
growth and not the direction of traffic flow. The extent bits identify the number of
locations along the road that are affected by the problem with a maximum of 8
(primary location and seven related locations). An extent of 1 would identify the
secondary location (the end of the event’s extent) as being the next location along the
same road from the primary location. An extent of 3 would force the receiver to search

12
the database for the third location along the same road from the primary location.
 RDS-TMC
Event and Status messages
Message phrases encoded for transmission
RDS-TMC relies upon a simple encoding process which requires the use of pre-
determined databases for message Event descriptions (and location information) to
be present at both the Service Provider and all his “customers or subscribers”. Thus,
a simple number can be transmitted via RDS-TMC, and by using a look-up method,
it can be interpreted into a user understandable message in the RDS-TMC receiver.
Whilst this has some disadvantages, eg the receiver must have an up-to-date copy
of the database, it has one big advantage: the end user can use a receiver which
presents the information in his own language. This is a big advantage in Europe
with so many languages, in everyday use, in very close geographical proximity.

Event list with 31 update classes

The ALERT-C protocol Event list is standardized in CEN ENV 12313-2 (see article
9), which is a culmination of many years of work, funded by the EC, to distill a very
wide knowledge base into an agreed set of Events phrases. These phrases total
some 1375 from a possible 2048 events, and these are divided into 31 update classes
for coding and message management convenience. It is very important to realize
that the Event list in this standard is written in so-called CEN-English to allow it to
be translated by knowledgeable traffic engineering interpreters into user-friendly
phrases of the languages of Europe. These translations are the responsibility of the
relevant standards authorities of the member states and will be disseminated to
system designers. The meaning of each code has to be defined for each of the
European languages and this work was completed in spring 1998. There needs to be
Event List standardised coherence between expressions used by the coded messages and those used in the
for Europe spoken messages of the broadcasters.

1375 Event phrases coded Event list translations

It has even been necessary to develop an English version of the Event list to allow
Event messages presented for the different use of distance measurement, eg “stationary traffic for 1km” which
in end user’s language is code 102 and which has to be understood by the Service Provider and the English
user alike, as “stationary traffic for ½ mile”, and not forgetting that a French user,
when in England will be perfectly able to understand the information from his RDS-
Harmonised translations TMC receiver as: “bouchon sur 1 km”, even though generated by an English Service
for many languages exist Provider!

ALERT-C delivers Event Constraints created by the

messages limited RDS capacity
RDS can only provide a very small bandwidth for RDS-TMC messages, so a
ALERT-Plus delivers Status distinction between Event and Status messages was made very early in the
messages development process, because Status messages were expected to require
considerably more bandwidth. This distinction seems to cause much concern;
however the differences can quite easily be defined.

Definitions of Event and Status

An Event message concerns an unplanned or planned occurrence on the road
network. Examples are: an accident, a traffic jam (unplanned), notification of
roadworks (planned).

A Status message concerns the characteristics of an object (e.g. a part of the road
network), for which, at all times, a value can be established (normal or deviating from
normal). Examples are: travel time and traffic flow.

An event has an incidental character (information is only given when something

happens), whereas status relates to an information stream (information is provided on
a continuous basis, often related to the normal situation).

ALERT-C Event messages and ALERT-Plus

Status messages

Both Event and Status messages, using two different message protocols, can now be
conveyed in RDS-TMC. The so-called ALERT-C protocol Event list is standardized in
CEN ENV 12313-2. Additionally, the so called ALERT-Plus protocol is now
implemented for Status messages which will be standardized in part 4 of the ENV
12313 series.

13
 Message generation and
infrastructure for RDS-TMC
TTI Messages - expanding
information to process
DATEX MoU - agreements
about TTI interchange
TTI Service Providers -
compile data into a useable
end-user product
On-air broadcasts require
compatibility with existing
infrastructures
TTI services using a variety
of outputs require to be
coherent
TTI Messages - where do they start?
Throughout Europe, over the last ten years, a considerable infrastructure has been
installed on major roads (particularly on the Trans European Road Network) to
monitor vehicle flow. This monitoring takes the form of video cameras, infrared
sensors, and loops in the surface; but they all allow for greater or lesser amounts of
traffic management to be undertaken. This is probably the primary objective for
funding supply, but a huge amount of information is gathered and this may be
interpreted into useful information for individual drivers to take autonomous
decisions, if it can be delivered economically. This is where broadcast TTI can play
a significant role.
TTI Message interchange via DATEX-Net
Many Traffic Information Centres (TIC) throughout Europe are beginning to
implement the DATEX-Net specification for information interchange. This is a
powerful set of tools enabling automatic information exchange between TICs and
other interested parties. The DATEX-Net protocol uses a Data Dictionary, data
models, Location referencing and Message exchange formats which were
developed to a relatively mature stage by 1996. Subsequently the EDEN Project has
built a consensus about using these tools and developed the European DATEX
Memorandum of Understanding, which seeks to involve all 15 EU member states,
Norway and Switzerland in agreed methods of interchanging TTI.
TTI Service Provider roles
DATEX-Net can be usefully employed by RDS-TMC Service Providers to obtain
information from local, national or foreign TICs, according to their service needs.
But these messages will, in essence, be about situations with traffic management
emphasis and need to be enhanced with other information before an end-user
message can be compiled. Many sources of information are used by an RDS-TMC
Service Provider to compile a service for the end-user, including Floating Car Data,
telephone calls, staff reporters etc. All this information needs to be gathered and
collated in a database, to facilitate a suitable picture for the operational staff to make
sense of the situation before compiling a TTI Message.
A Service Provider also has the responsibility of marketing his service to the end-
user, whether it is a free or paid-for service. This requires extensive subscriber
management and, in the case of RDS-TMC, Location database management and
distribution. (see articles 12 and 15).
RDS-TMC Message Generation

A range of software designs has been developed to facilitate the rapid generation of
RDS-TMC messages, both automatically and manually, from the vast amount of
available data. These software applications are designed to output messages directly
for RDS-TMC using a number of protocols suited to the existing infrastructure the
Broadcaster or Transmission Operator needs to deploy within. Nevertheless they are
designed to facilitate compatibility on-air of RDS-TMC messages and other methods of
delivering TTI, such as spoken messages, TV, Teletext and Internet. This is a vital
function of a Service Provider, since a multi-modal approach is natural for the end
user, firstly planning a journey at home or office, using TV and Teletext or Internet,
then in the car using RDS-TMC today and finally on foot using a “walkman radio” to
only listen to spoken TTI messages.

Public service broadcasters use skilled editors who interpret, compare, check and
control every message that is broadcast. It is the editor who can ensure that the RDS-
TMC messages make sense to users - that they give sound and safe advice.

This quality check is more difficult to achieve if messages are automatically generated
and transmitted.

14
 Smart-cards and
payment for RDS-TMC
Smart-cards -why does RDS-TMC
need them?
Because RDS-TMC is using a relatively low data capacity carrier (RDS only has
about 650 bits/s available for all features and services), it is necessary to compress
TTI message data into the smallest possible datastream for delivery to the end-user.
This is achieved by compressing Location information (see article 12) and Message
information (see articles 13 and 14), and using look-up tables in the receiver to
reconstruct the full message for the user. This has another big advantage: the data
can be presented in the language of the user, according to the RDS-TMC receiver
that has been purchased. Furthermore the language of display is then independent
of the country it is received in, overcoming a significant language barrier to
understanding of potentially important TTI messages (eg about ghost drivers).

Generally the Message information, in the form of a standardized Event list (see
articles 9 and 13) will be stored in a receiver for all time. However the Location
information is a database that will become outdated as the road network develops
with new by-passes, road sections and even new motorways. It is somewhat like a
map: as it needs to be updated regularly, say every other year, and this must be
distributed to end-users, for them to be able to decode all messages and continue to
receive the highest quality of service.

Distribution of the database

The pan-European vision of RDS-TMC foresees that a traveller can buy or rent a
Smart-card (or CD-ROM) in Italy which has Location codes for London, but use it in
an RDS-TMC receiver giving messages pronounced in Italian. Such a card needs to
be assembled using information derived from the UK database. This principle
extends all over Europe, and it is clear that each database needs to be made very
widely available, through RDS-TMC Service Providers.

Location database is the

key to decoding Location database influences
RDS-TMC messages
In any RDS-TMC system it is necessary for the same Location database information
to be used at all Traffic Information Centres (TICs), by all Service Providers and by
Smart-cards or CD-ROMs all devices which receive information from those sources. Such a system is depicted
carry Location information in the figure opposite. It introduces the role of a Card Provider, translating the
available database to a physical and marketable form. If any of the system elements
has a database which differs from the others, then performance will be less than
Smart-cards - help pan- optimal. For example, if an RDS-TMC receiver were to have an old database,
European services develop missing new Location codes, then messages relating to these locations cannot be
received and presented to the driver. Such omission may be regarded as simply
unfortunate, but could have major safety implications.
Periodic Smart-card
replacement for revenue
and quality reasons
Location database ownership
Within the system described above there can only be one database per area/country or
per Service Provider, and all system elements (TIC, Service Provider, Card Provider
and end-user) must derive their individual databases from this one source. It is,
however, quite possible for Service Providers, Card Providers and Receiver
Manufacturers to operate competitively. Each database will need to be maintained,
and such maintenance should be conducted at periodic and defined dates, to enable all
system components to operate with a common, and latest version. This means that
cards produced for receivers will need to have an expiry date.

Smart-card sales
An end-user wishing to use a particular RDS-TMC service will need to obtain the
smart-card from a local Service Provider. In turn, a Service Provider needs to fund the
service by deriving income from sale of smart-cards. Since periodic replacement is
necessary to facilitate updated Location information about new road locations, it is
expected that this can become the necessary revenue stream to fund the service
offered. In many cases cross border information will definitely be required and
Service Provider agreements to co-operate can lead to cost sharing as shown in the
figure below.

Smart-cards and CD-ROMs

It is expected that a smart-card will have a quite limited data capacity, but easily able to
contain a single countries Location database. However for the long distance traveller
the need for multiple smart-cards is partly overcome by the EUROAD concept
whereby each Service Provider is encouraged to include some or all of the major
Locations of the whole Trans European Road Network. It is quite possible that RDS-
TMC receivers will quite soon be able to read CD-ROMs with much greater storage
capacity and containing many more Location references, but this will depend mostly
upon alliances being built by Service Providers across national borders.

15
 Multimedia and the
Human Machine Interface in the
vehicle Multimedia in the vehicle - is it safe?
At first sight, the suggestion that it is possible to have a multimedia terminal in the
vehicle, under driver control, seems to be unacceptable for driver safety reasons.
Car radios have become more and more complex as cassettes and CD players have
been added to many improved receiver functionalities. Some safety improvements
seem to be in sight for various in-vehicle products, but very careful integration will
be needed if all parties - Service Providers and end-users alike - can truly benefit
from these new products.

RDS-TMC - is it multimedia?

The original idea for RDS-TMC presentation was that messages would be presented
as speech synthesized phrases, to allow the driver to hear about road situations; this
would allow the driver to continue listening to whatever is required: passenger
conversation, radio, cassette or CD.

However some of the first RDS-TMC products will rely mostly upon visual display
of icons or text, in order to keep the product price reasonably low. Icons have been
used in first generation navigation systems with little or no adverse effect and
appear to have a long future ahead (although standardisation of their meaning is an
issue still to be solved). The text display of RDS-TMC messages has, to date, been
engineered for the driver to access more information on a “press-once for next
display” basis, to avoid scrolling long message information texts.

It is interesting to note that multi-character text displays have been in use in a

number of products from taxi driver information systems to, most recently, full 64
character RadioText messages on “top-of-the-range” RDS receivers, but these are
placed under some control, either from the vehicle ignition system or other control.

What about the car radio?

HMIs can be developed to
meet safety requirements It is easy to see that the European car manufacturing sector is now taking great steps
to integrate electronics in the car “dash board” to a higher level. This involves car
radios, navigation systems, car instruments and even the humble clock. Integration
Navigation systems HMI leads to the need for one display area in the best possible visually ergonomic
is the present priority location on the “dash board” to service all the functionalities required. The key
question soon becomes: which has the highest priority?

RDS-TMC HMI will comprise The CARMINAT Project has done extensive work on visual displays in cars and a
displays and/or voice good body of work exists to show where a display should be fitted and the size, font
synthesis and number of characters per line that can be easily and safely used by a driver. But
this work is completely geared towards TTI and navigation displays.

Is the car radio lost in The implication here is that the car radio is being driven into second or even third
new directions for HMI place, which cannot be seen as a good move from any broadcaster’s perspective. It
developments? is necessary to study driver reactions to automatic prioritorization of the display
functionality and to study the implementation of various modes to allow secondary
functions some percentage of the available display space. For example, when using a
navigation system normally showing a map display, could 90% of the display space be
allocated for that purpose, allowing 10% to be used for radio station Programme
Service name and Programme Type display? In such an example, when the user
wishes to change the radio settings the display proportion could automatically
increase to give more detail about the listening choices to be easily and safely made and
then revert back to navigation mode after a delay.

HMI standardization for in-vehicle

information
At the time of writing, in summer 1998, the standardization of good HMI practice had
reached an important stage, with the publication of a European Statement of
Principles, which aims to cover three critical issues:

• Design and location of information systems for

compatibility with the driving task

• Presentation of information, not impairing driver’s visual

allocation to road scene

• Design of system interaction, to allow a driver safe control

of the vehicle

This activity also fully recognizes the ongoing work within ISO to develop a range of
standards covering In-vehicle (Traffic Information) control systems.

16
 RDS-TMC receiver issues
RDS-TMC should not detract
to the listening experience
RDS-TMC information in own
“spoken” language still not
readily available
RDS-TMC is strongly trended
towards costly navigation
systems
There is little scope for a
medium-priced car radio
with full RDS-TMC
functionality
The Vision for RDS-TMC receivers
The developers of RDS-TMC started to think about their vision before the EC came
along to fund the many research projects that have worked on related infrastructure
and RDS-TMC specifications over the last ten or 12 years. The original idea can be
summed up, as very close to: “an RDS-TMC receiver would be able to intervene in
the drivers normal choice of radio listening with relevant (filtered for that journey)
and timely (no need to await a suitable programme slot to voice an announcement)
voice synthesized information, in his own language. The RDS-TMC service should
be free of charge to the end-user, except for the need to purchase a new RDS-TMC
receiver at a reasonable to low cost, and the need perhaps to buy an update of the
location database, occasionally.” This suggests a number of principles which can
today be seen embodied in the various RDS and RDS-TMC standards (see article 9).
Listening choice should not be impaired
Message filtering
Own language information presentation
Since then, a European dimension has been added, with the pan-European service
element, to allow a driver to obtain information as the vehicle traverses national
borders. Additionally, because of the long development cycle, the significance that
TTI has for updating navigation systems and the perceived higher value of these
products has made RDS-TMC a killer application for navigation systems in the near
term. Even allowing for the long development time, the end user has become more
sophisticated in expectation, and the development of voice synthesis technology
has not been able, to achieve the expectations at a low enough price. So solutions
have been sought which will still reach acceptable end user appeal.
Thus the focus for RDS-TMC products has drifted away from the lower-priced
market to the much higher-priced market, before simple RDS-TMC receivers could
be delivered to the European consumer.
Introducing first generation RDS-TMC
receivers
Perhaps inevitably as the technology for RDS-TMC was developed, it became clear
that some elements were a little too revolutionary and solutions had to be found
that would use technology of today for the solution, knowing that by tomorrow the
price would fit the product price profile required. The most obvious example of
this is the smart-card used to carry the Location database which is needed to
decrypt the location information carried in every RDS-TMC ALERT-C message (see
article 12). The problem now is that this technology is already in doubt for two
reasons: firstly the intellectual property rights (IPR) situation relative to the many
patents registered by Bosch/Philips is seen as a barrier to introduction, and the
potentially cheaper CD-ROM technology has become acceptable in navigation
systems. The institutional challenges to introducing either are much the same, but
do not appear to be diminishing at a fast rate and still appear to be one of the big
 obstacles to wide user acceptance of RDS-TMC, because the Service Providers are not
yet fully active in trying to overcome these challenges.

The reality of RDS-TMC receivers today

It has to be said that, from the broadcasters viewpoint, the availability and
functionality of first generation RDS-TMC receivers is extremely disappointing. The
consumer electronics manufacturers (CEM), who have entered the market so far,
appear to be less than enthusiastic for this particular market. This is strange given the
lead they have through European-funded research. It appears that one particular
change has occurred in the market, which was not predicted: the CEMs now see the car
industry - line fitted products - as their major market and not the end-user. This results
in the navigation market products taking early precedence in the marketing plans of
CEMs and the car industry. In turn this leaves the RDS-TMC Service Provider high
and dry, with no significant supply of products in the market place for them to base
their service sales upon.

So what is available, at the time of writing in summer 1998? Bosch are offering their
Viking RDS-TMC receiver, which at first sight is nearest to the early developers vision,
but it only “speaks” German. Actually, the designers have produced a relatively low-
cost product, but have had to sacrifice the full voice synthesized approach to a hybrid,
recorded speech and text display solution. This kind of receiver cannot “speak” all the
locations and also not all the messages. Most recently Bosch committed to develop the
Viking also for English, Dutch, Danish and Italian. Sagem have produced RDS-TMC
receivers specifically for car fitting into the French market, which are ALERT-Plus
terminals, but thy do not yet provide a pan-European product. One of the navigation
system product is available from Volvo (the RTI system), which can only be fitted into
some of their current car range and trucks. VDO/ Philips Car Systems has launched
an RDS-TMC car radio which needs to be connected to their own navigation system to
enable the TMC functionality. Some small companies do appear to want to break into
the RDS-TMC receiver market, but IPR issues may slow their progress, nevertheless
they should be encouraged. Of course, we cannot report on those other companies
who may be developing RDS-TMC products but who will not reveal their plans until
all is ready.

Thus, from the broadcasters viewpoint, many of whom have already invested in RDS-
TMC broadcast and transmission infrastructures, they are left, as usual, having laid
the egg and now waiting for the chicken to
hatch. The problem is that the incubation
period does not yet appear to have an obvious
end to it!
VDO Car Communication
Volvo / Mitsubishi

17
 RDS-TMC projects spread
Europe-wide
EC invests “seed money”
in RDS-TMC infrastructure,
since 1996
12 EU member states
covered through many
projects
Cross-border implementation
priority on the TERN
The political commitment of
EC Directorate DG VII
In summer 1995, the EC Directorate DG VII committed itself to financially support
an action plan covering the years 1995-99 that would stimulate - with “seed money”
- the introduction of RDS-TMC. Since 1996, DG VII has funded several RDS-TMC
implementation initiatives and among them two European projects (FORCE/
ECORTIS and EDEN) and several Euro-regional (VIKING, CENTRICO,
CORVETTE, SERTI and ARTS), as well as national projects that altogether involve:
Belgium, Denmark, Finland, France, Germany, Italy, the Netherlands, Portugal,
Spain, and the United Kingdom. This has led to many regional RDS-TMC
implementations on important sections of the Trans European Road Network
(TERN), concerning the main trunk roads in the European Union.
The research projects and support activities leading to RDS-TMC implementation
across the various service sectors involved have generally been funded with
support from DG XIII. Cross border infrastructure implementation and common
interest demonstrators (validation projects) are usually carried out with the support
from DG VII, in line with the Trans-European Network for Transport (TEN-T)
guidelines, and the corresponding budget has so far (up to the end of 1998)
contributed some ECU 79 million for RDS-TMC infrastructure development and
implementation.
Europe-wide projects focus on building European consensus for the provision of
pan-European services and comprise: DEFI (now completed - it sought to define a
common definition of the European RDS-TMC services); ECORTIS which is
coordinating the implementation of RDS-TMC implementations to ensure the pan-
European perspective of the national plans is met, and EDEN which deals with the
DATEX network required for Traffic Information Centres as the backbone for data
exchange, including cross-border exchange of traffic and travel information for
Europe.
The five Euro-regional projects
The five Euro-regional projects now underway focus on cross-border cooperation
by implementing continuous and interoperable services in neighbouring trans-
border areas:
ARTS - coordinates regional and national ITS implementation projects with RDS-
TMC in the South-West of Europe, linking parts of Portugal, Spain, and France. The
project started in autumn 1997. The objective is the improvement of the continuity
and quality of traffic management and traffic information services on the main
international corridors concerned.
CENTRICO - coordinates the implementation plans for traffic management and
user information services, for centrally located countries in Europe: Belgium, and
Luxembourg, and parts of France, Germany and The Netherlands; with the United
Kingdom as an observer. During 1995 and 1996, a common action programme has
been prepared focussing on monitoring, cross-border traffic management and re-
routing, traffic information exchange, coordination of traffic centres, the
implementation of ITS in urban areas, on-trip information through RDS-TMC and
inter-operability of automatic toll collection. In 1996 and 1997, the study work was
completed, and implementation projects will begin in 1998.

CORVETTE - coordinates regional, bi-lateral and multilateral ITS implementation

projects in the Alpine area covering for regions of almost equal size, ie. Austria, parts
of Southern Germany (Bavaria), the North-Eastern part of Italy, and Switzerland. The
project started in autumn 1996 and will continues in several phases up to 1999, at least.
The main domains that have been identified are: traffic data collection and monitoring
of service provision conditions, cross-border data exchange, traffic management using
Variable Message Signs, RDS-TMC traffic information services, and automatic toll
collection.

SERTI - coordinates the implementation of traffic management and user information

services covering the southern region of Europe: adjacent parts of France, Germany,
Italy and Spain. During 1996 and 1997, studies have been conducted and coordinated
to define a common action programme covering monitoring, organizational problems,
data exchange, traffic management using Variable Message Signs, RDS-TMC traffic
information services, and pre-trip information services. In 1997, remaining study
work was finalized and implementation of the applications started in 1998,
concentrating on the highest priorities in the action programme. Part of the SERTI
project is a specific TMC car radio receiver test with professional drivers on the TERN
in the SERTI area.

VIKING - will coordinate national and bilateral traffic management and ITS
implementation projects in the northern part of Europe: Denmark and parts of
Finland, Northern Germany, Norway and Sweden. The coordination ensures
continuity and a high quality of ITS services, and gives special attention to intermodal
aspects - to support personal travel and freight haulage. The project started in autumn
1996: consensus on traffic management on the northern part of the trans-European
network, definition and harmonization of services, information management and data
exchange, RDS-TMC traffic information services, automatic toll collection and
demand management, and traffic management in urban and peri-urban areas.

Given so many projects, RDS-TMC is being developed in almost every corner of

Europe. However, the complex detail of these projects cannot be fully covered here:
only the broadcast sector activity in the context of RDS-TMC implementation has been
focused on. Initially RDS-TMC coverage of the Trans European Road Network is

18
being given priority, but some EU member states have only very few roads involved.
 National RDS-TMC
implementation projects
Austria
A new RDS-TMC pilot project (CORVETTE Phase III) is now planned to start in 1998/99 on four international motorway corridors. The ORF, the
public broadcaster, is ready to cooperate in the CORVETTE project under the prerequisite that an appropriate contract is agreed with the other
partners involved. ORF could contribute the editing of traffic information supplied by the Federal Ministry of Science and Transport, and the
distribution and transmission of these TTI data in the RDS-TMC format within the Austrian CORVETTE area (the Inn valley from Kufstein to
Innsbruck (A12), from Innsbruck to Brenner (A13) and the region of Vienna, up to Wiener Neustadt (A2 and A23).

Belgium
VRT, the Dutch language public broadcaster, has adapted its infrastructure and equipment for RDS-TMC. VRT is now ready, technically and
operationally, to provide RDS-TMC on its five networks. VRT coordinates its efforts with the authorities responsible for establishing a new TIC in the
Flanders region permitting enhanced traffic data collection and distribution. A better perspective for suitable RDS-TMC receivers to become available
on the market would positively influence the decision making process, to start the operational TMC service.

RTBF, the French language public broadcaster will start RDS-TMC operations in the Brussels and the Wallonia region at the end of 1998. A new TIC
in the Wallonia region will be opened in autumn.

Denmark
Danmarks Radio is working with the Danish Ministry of Transport Roads Directorate and it is proposed to implement RDS-TMC before the end of
1998 on two services: Radio 3 carrying the nationwide coverage and Radio 2 giving a regional service. This will involve implementation of the UECP
V5.1 and possibly new RDS encoders.

Finland
YLE, the public broadcaster, and the Finnish National Road Administration have now started an experiment in Southern Finland with the view to
begin the fully operational RDS–TMC service in 1999. By the end of 1999, this service will then cover the whole of Finland.

France
There is considerable activity through the Médiamobile company in the Paris area where RDS-TMC
services (ALERT Plus focused) started in early 1998 via a number of different transmissions. Additionally
Radio France is investigating a collaborative project with the DSCR to ensure coverage is given on a
national level. The French motorway radio companies start RDS-TMC operations as from 98/99.

Germany
The public broadcasters had taken a major role, coodinated through the ARD, with the target of providing
RDS-TMC services in time for the IFA in August 1997. By now, almost all of Germany is covered: Radio
Bremen, Ostdeutscher Rundfunk Brandenburg and Saarländischer Rundfunk are likely to follow before
the end of 1998. There is increasingly major concern that most of the regional (Länder based) broadcasters
have still to care for the coding of the TMC messages by their own editorial TTI-unit on the basis of their
messages for the spoken service. Road authorities’ TICs are still missing and so is, in many cases, the
proper infrastructure and the interfaces required that would be necessary to offer the broadcasters an
uninterrupted data chain of coded messages. For example, in the case of Saarländischer Rundfunk, this is
the main obstacle for TMC to be put on air, whereas the inhouse infrastructure to start the TMC operation
has been ready for quite some quite time. Regarding the receiver market, the lack of a competitive variety
of TMC radios at different price levels is a serious threat to development of a German mass market, and
National implementations there is still no commitment by most of the car manufacturers to offer TMC receivers at the point of sale,
progress continuously apart from relatively expensive navigation systems with a TMC component.

Italy
EC-funded projects RAI, the national public broadcaster, will have a new RDS Server installed in summer 1998 to allow RDS-
supporting widespread TMC messages to be sent on a regional basis to the appropriate transmitters and a full regular RDS-TMC
actions service will be available as from summer 1998 in northern Italy on almost all roads, and in particular all
the west - east and north south Autostradas from the Brenner Pass down to Bologna. Saxa Rubra, the national TIC, is then linked with a large number of
regional and national TICs operated by five different information providers, the local police (Arma dei Carabinieri), the traffic police, the Italian
Automobile Club ACI, the motorway operators association AISCAT and the national road administration ANAS. All data-exchange uses the European
standard protocol DATEX. The national Italian plan foresees a continuous extension of this service until full RDS-TMC coverage will be achieved by
2002.

DAB services will start to cover 60 % of the population as from 1999. However for continuous area coverage to be obtained with DAB and comparable
to that with FM, at least five to ten years of further DAB service development are still required by the RAI.

The Netherlands
The NIKITA consortium has been established and they will operate an RDS-TMC service, generating all ALERT-C messages that are then transferred to
Nozema - the Transmission Operator - bypassing any broadcast studios. It is not yet clear how coordination with spoken TTI messages will be achieved.

In January 1997, the Rijkswaterstaat commissioned the Nikita consortium (with no broadcaster involvement) to develop the information systems
technology and integrated systems for the RDS-TMC service. The information provider will be the TIC-Nederland, jointly operated by the KLPD
(National Police) and the Rijkswaterstaat. The technical infrastructure was complete by spring 1998, and operational service ha s started with public
funding assured for three years.

Portugal
In Portugal, all efforts have concentrated on 1998 EXPO, and RDS-TMC will be implemented around the greater Lisbon area. The national project team
includes the Junta Autónoma de Estradas and RDP, the public broadcaster.

Spain
An agreement has been reached between the Dirección General de Tráfico and RNE, the public broadcaster, to be the organization which delivers RDS-
TMC. Through the SERTI Project the implementation started in spring 1998, extending the demonstrator of Madrid to the north eastern part of Spain,
inside the triangle formed by Madrid, Valencia and Barcelona, extending this last vertex to the French border.

The development of RDS-TMC has resulted for RNE in the installation and configuration of more than one hundred RDS encoders, with ODA capability
on the Radio 3 transmitter network.

The Dirección General de Tráfico is now modifying the software, on the TMC server for ODA, and service will start in spring 1999.

Sweden
The Swedish National Roads Administration has been working on RDS-TMC implementation for some time and implemented RDS-TMC as from
September 1997.

Switzerland
The national Traffic Information Centre has been built in Geneva and it is jointly operated by the Swiss public broadcaster SRG/SSR and the Swiss
automobile association TCS. Software for the generation of RDS-TMC messages has now been installed. As from autumn 1998, RDS-TMC test will start
in the Berne area and the receiver market will be analysed. Subsequently, the decision will be taken about the introduction of RDS-TMC on FM (as from
autumn 1999) and /or TTI on DAB. The introduction of the DAB transmission chain will start in 1998.

United Kingdom
The Automobile Association (AA), Royal Automobile Club (RAC), C&MT (a private sector datacaster), and the UK Government have signed a
Memorandum of Understanding, which undertakes to provide an RDS-TMC demonstration service from Summer 1998 covering the major motorway
network of Southern England. The RDS-TMC data will be conveyed via the transmissions of the Classic FM network, which has national coverage
potential. A competitive service from the AA and RAC will be provided to the end-user, within the single RDS-TMC transmission.

The BBC - the national public service broadcaster - decided not to join this consortium, because the UK government could not resolve the free of charge
to the end user issue, before the project started. Free-of-charge pan-European services are an essential objective, commonly shared by the public
broadcasters of the EBU.
19
 Traffic and Travel Information
on the Internet
Public broadcasters have
already RDS-TMC coherent
traffic info on the Internet
The display mode chosen to
present traffic info on DAB
is also on the Internet
Paris is on top of the
development with real-time
traffic info on the Internet
The EC funded SERTI project
has the most interesting site
for pre-trip planning
Example 1:
Traffic info from Public broadcasters
These broadcasters compile TTI from a number of different TICs and use special
editing software for presentation of the same information over a variety of bearers:
spoken messages, RDS-TMC, DAB, TV, Teletext and Internet. Once a message is
edited, it is output after automatic processing in the editing computer on all these
bearers. Each bearer, of course, has of course its own specific presentation format
and the required format adaptation is automatically achieved through the editing
computer.
Web sites: www.ndr.de
www.mdr.de
www.swr-online.de
www.wdr.de
Example 2:
Traffic and much travel support info
from an automobile club
This site displays the same kind of information as in the previous example. In
addition, there is a trip planner, hotel finder, and a possibility for online shopping
of travel guides and maps.
Web site: www.rac.co.uk
Example 3:
Road map with traffic info for Digital Radio
There is a field trial in the south-western part of Germany where a number of
innovative data services for Digital Radio DAB are implemented via the MOT
(Multimedia Object Transfer) protocol which will now become integral part of the
European DAB ETSI standard. The TTI shown by the public broadcaster SWR
(formely SDR and SWF) is produced by using the editing process described in
example 1.
Web site: www.swr-online.de
Example 4:
Traffic info display for Digital Radio
The public broadcaster WDR is testing on DAB, in addition to example 3, another
display format as shown.
Web site: www.wdr.de

Example 5:
Road map traffic info from a road authority
Web site: www.roaddirectorate.dk

Example 6:
SERTI - The best site on pre-trip information
This site is part of the EC funded Euro-regional project SERTI (see article 18) which
involves parts of Germany, Italy, France and Spain. The pre-trip information section
was previously developed in the EC funded DESPINA project and it is now extended
over the four countries offering a choice of user languages, including English. In
coordination with the public authorities, an information service is being proposed to
allow to prepare a holiday itinerary using a frequently updated TTI database. In
addition the site gives access to spoken regional traffic bulletins and real-time video
from cameras installed on motorways.
Web site: www2.3ct.com/serti

Example 7:
Real-time metropolitan area traffic info

Data are collected by the City of Paris using magnetic loop detectors which are installed
every 500 to 750 m on 2000 km of all major roads in Paris. The City of Madrid is
building a similar system.
Web sites: www.sytadin.tm.fr
www.dgt.es

Example 8:
City traffic info for Athens
Here one can calculate how far one can travel from the City of Athens’ periphery
towards the city centre under real time traffic conditions.

Web site: http://frida.transport.civil.ntua.gr/map/

20
 Industry coordination and
Forums ○○○○○○○○○○○○○○○○○
Standards can be
mis-understood or
mis-interpreted
Regular industry
coordination in a Forum
avoids implementation
problems
RDS and WordDAB Forums
are based on consensus
building
Open Forums provide
leadership and maintain a
standardized technology with
involvement from many
industry sectors
Whilst successful standards are in use by the few people who helped develop them,
then all is likely to be well, because they know what they intended when drafting
the documents! But once a wider group of users has a need for a standard then, the
intentions, not fully or well specified, can be misunderstood or misinterpreted.
Furthermore field experience of implementing standards tends to throw up many
new issues.
This is the kind of scenario where industry coordination becomes an important
issue. The system standards once developed, now need system maintenance and
users of that new technology require guidelines for a compatible Europe-wide
implementation. Any field experience can now be shared between the various
sectors involved, which is extremely useful at the stage where implementation
guidelines have to be drawn up. Although the projects of the European
Commission have served to achieve similar objectives, users of a given technology
such as RDS and DAB have found it even more useful to cooperate in specialised
industry Forums that regularly bring important players together using that
particular technology. Sharing the experience of deploying a new technology and
raising awareness about constraints that one or the other sector does encounter on
the road to full implementation is what has motivated the co-operation in these
Forums.
RDS Forum - a world-wide association of
RDS users
The RDS Forum has existed since 1993. Membership is open to all professionals
involved in using RDS technology. The RDS Forum has so far held two plenary
meetings per year and a large proportion of the more than 100 members,
worldwide attend. The operational expenses of the association are shared among
all those interested to join it. Members pay for each registered representative an
annual fee of CHF 1750.- The EBU has so far funded the Secretariat of the RDS
Forum office.
In 1997, the RDS Forum had four working groups concerned with maintaining and
upgrading the RDS standard, developing accepted Guidelines for RDS system
operation, upgrading the Universal Encoder Communications Protocol UECP to
include full ODA and RDS-TMC functionality and, RDS/DAB cross-referencing to
support implementation plans for DAB transmissions with RDS/DAB receivers
that offer a compatible user interface.
Web site : www.rds.org.uk/
WorldDAB Forum
Another forum with potential significance in the field of TTI broadcasting is the
WorldDAB Forum, which was formed a few years ago, with the support of the
EBU, to become the prime focus for all matters associated with the development
and introduction of Digital Radio. Each registered organization pays an annual fee
of CHF 8000.-
○○○○
○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○

Digital Radio DAB, using the Eureka 147 system as standardized by ETSI, provides the
potential for audio and multimedia services in a transmission which can be
reconfigured to allow for demand as necessary. It is expected that non-programme-
related data services may use up to 50 kbits/s. This is a significant increase on the data
available for RDS-TMC. The potential advantages of the increased data capacity have
been recognized by the EBU and a Project group is already developing the TPEG
protocol to provide TTI along compatible lines with RDS-TMC, but using extra
bandwidth potential to overcome the data compression that RDS-TMC required for
the Event list and Location database.
Web site: www.worlddab.org

A new TMC Forum to secure the future of

RDS-TMC

The management of the FORCE/ECORTIS project invited all partners in the RDS-
TMC business chain to join an inaugural ALERT Forum meeting, held on 9 th June
1998 in Brussels. The objective was to save the future of RDS/TMC before the FORCE/
ECORTIS project ends. The invitation from ERTICO announced that this Forum was
aimed to become the Club of those members that have signed one or both MoUs in
support of an RDS-TMC service with ALERT functionality. The meeting was hosted
by ERTICO and was devoted to discussion and consensus. About 60 different
companies and organisations attended.

The consensus ended up remarkably different than intended initially: Having only a
closed shop of MoU signatories was generally rejected. The use of the term ALERT
which covers not only RDS-TMC under the ALERT-C protocol, but also ALERT-Plus,
was dropped in favour of the more generic term TMC.

The promoters of the new TMC Forum presented the following objectives to be
achieved:

• Coordination of RDS-TMC activities across Europe

• Promotion for RDS-TMC services and products
• To secure the evolution of TMC in the widest context
• Provision of a central point of contact (eg for the updating
and exchange of location data bases)

The Forum and its Task Forces will be self-funded. ERTICO is likely to be funded by
the European Commission to provide the Secretariat. On 30th September 1998 a second
meeting will be held to approve the terms of reference and to install a management
board.

The RDS Forum offered cooperation to avoid duplicated use of resources.

Web site: www.alert-tmc.com

○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○21
 Future prospects of TTI
TTI is here to stay!
TTI moves into the
competitive market led
world
More and more TTI
will be needed
Public broadcasters
infrastructure ideally
suited to future TTI services
TTI is here to stay!
Given the strong political drive for the development of TTI delivered through RDS-
TMC, to a very large number of users in Europe, the infrastructure to support this is
gathering pace and will become very widespread in the next few years. (see articles
18 and 19) This infrastructure will certainly support the delivery of TTI by other
means, too. Already the potential impact of the GSM network has been realised and
various commercial Service Providers are beginning to offer their services, however
some will be relatively expensive (being call charge based) and their widespread
market penetration is not necessarily guaranteed.
Nevertheless, European public broadcasters see TTI as a significant part of their
complete programme and information services portfolio and they wish to continue
in their public service role. Thus we can expect the continuation of Traffic and
Travel Information broadcasting via existing delivery mechanisms, such as
Internet, In-vision, Spoken services, TV, Teletext, and RDS-TMC. But additionally
broadcasters, and especially those collaborating within the EBU, will develop new
services and new delivery technologies that can provide accurate and timely
information about multi-modal events, such as accidents, train cancellations,
congestion or roadworks. These services should be available free of charge to the
public, but it is also recognised that there will be many additional opportunities for
paid-for value-added services, such as information about local hotels, restaurants
or status oriented urban traffic information services. New ways of conveying such
services are just around the corner, such as Internet (significantly enhanced
services), DAB and DVB. All of these will fit directly into the broadcasters remit
and certainly TTI data broadcasting will play a significant role, giving Europe
widespread easily accessible services.
TPEG
RDS-TMC is not able to provide multi-modal information and relies on proprietary
location databases at the receiving terminal creating barriers to a pan-European
service, language-independence and free-to-air provision. Having recognised the
need for future TTI to be bearer independent, the European Broadcasting Union
(EBU) has established the Transport Protocol Experts Group (TPEG). This activity
has recognised the benefits and value of RDS-TMC together with its strong
limitations and is developing the TPEG protocol to take the advantages and
develop a protocol which has far less disadvantages and is fully bearer
independent. TPEG is firmly aimed at the multimedia broadcasting environment.
The TPEG Mission Statement reads:
The work of B/TPEG, commissioned by the EBU’s Broadcast Management
Committee, is to develop a new protocol for Traffic and Travel Information, for use in
the multimedia broadcasting environment. B/TPEG will develop applications,
service and transport features which will enable travel related messages to be coded,
decoded, filtered and understood both by humans (audibly and/or visually) and by
agent systems.
TPEG will allow a Service Provider to develop a service which can be delivered by one
or more delivery technologies (eg DAB, Internet, Teletext) simultaneously from one
message generation procedure. Furthermore it will allow a range of receiver types to
be used simultaneously, ranging from a sophisticated agent receiver serving a
navigation system through to a very simple receiver (eg a Personal Digital Assistant
plug-in card) only able to decode top level information.

In many debates about the future of broadcasting, arguments about the choice of
delivery technologies threaten to overwhelm the much more important issue of
content provision. This also seems to be true in the case of RDS-TMC and DAB. In
practice, the collection of TTI data and subsequent processing is far more complicated
and expensive than distributing it to the public. In essence, there is no direct conflict
between the provision of TTI data services on RDS-TMC and on DAB. The
infrastructure required by broadcasters for handling of RDS-TMC data will also meet
the needs of future services, such as TPEG on DAB.

In addition, experiences gained with operating and provision of RDS-TMC services

will surely help launching future transport telematics services including greater value
transport and travel information services to all travellers.

Long term future

Long term forecasts in the consumer market environment are notoriously difficult to
make. But certainly TTI is here to stay: Europe will not solve its road traffic problems in
a decade, so TTI will still be a significant factor especially to promote better safety. A
gradual upgrading of public transport may be anticipated, so emphasis on the TTI
content will move more towards multimodal journeys, combining private and public
transport. As urban congestion is still expected to increase, so too will the need for
more pre-trip planning become important, to learn how to best undertake a
multimodal journey. Furthermore rural journeys, with increased car ownership, will
require more TTI to assist users.

Thus a more diverse market for TTI will emerge. Examples will include: one-to-one
information, where the Service Provider offers high value personal information,
perhaps via a GSM network; high data rate information to update a navigation system
to certain subscribers and Internet delivered TTI services especially orientated to pre-
trip planning, with the possibility to download information for later use in a PDA (eg
Nokia Communicator, Psion Organiser).

However, the large majority of road users can economically only be reached through a
wide range of on-air TTI broadcast services delivering real time information to a whole
range of receiver types, from small portable radios and car receivers to home receivers,
operating via various delivery technologies. Well developed infrastructures, of public
service broadcasters, have no difficulty in supporting such an important European
objective.

22
 The mysteries of the market and
the time-scales involved
Technology,
infrastructure and content
are linked to the key
of success
RDS came as the silent
revolution
90% of all cars equipped
with RDS will take 20 years
to achieve
90% of all cars equipped
with RDS-TMC will take
even longer
The three pillars
Digital systems, common standards, open systems, good or excellent technology,
none of them of themselves, guarantee success. But success clearly is achievable
sometimes. How can we understand the mysteries of the market?
The successful introduction of a new media technology is an edifice like a Greek
temple resting on three pillars: technology, infrastructure, and content.
All three need to be in place or the introduction will fail.
The technology pillar comes from research and development. It determines of
whether we can achieve the system technically. The technology pillar today is often
the easiest to build. We are moving from an age when technology fundamentally
limits what media can deliver to a world where the real problem is deciding what
we want to achieve with the new technology.
The second pillar is infrastructure. Are there sufficient transmitters and receivers
going to be out there? Do we have the necessary bandwidth or data transmission
capacity to broadcast the new data service? Shall we have - and from where -
sufficient income to cover the infrastructure costs? At the other end of the chain, we
find consumers. Will they be able and willing to pay for the new receivers? Will the
cost of the new equipment match the perceived added value in the new data
service?
The third pillar is content itself. In the end, the consumer does not buy hardware;
he buys the programmes and multimedia services (programme-related or not) he
wants to receive. They must have much more value, and be much more interesting
than the ones he was using before. If they are not, he will not bother to change his
receiver. Even the most marvellous technology is nothing at all for the public
without creative new content. This is the factor most affecting success or failure.
As we have seen, the technology pillar determines whether the system can be made.
The infrastructure pillar determines whether the system can be delivered, and at
what price. The content pillar determines if there is sufficient added value in the
new multimedia services content for the system to be attractive and to develop into
an established market.
Looking at the media delivery system successes and failures in Europe over recent
years, wesee how lack of attention, most often to infrastructure or content, has been
the cause ofsee how lack of attention, most often to infrastructure or content, has
been the cause of failure, or very slow roll-out. These two pillars have often not been
thought through fully. There has often been no business plan based on all of the
pillars simultaneously.
Time-scales experienced with
new technologies
It is important to appreciate the long time-scales for implementation of new technologies: Adoption of new broadcast
services can be very slow when new receivers are required as in the case of RDS-TMC.

Even the most successful consumer electronics products, such as the CDs and video recorders, took more than ten years
to reach 50% penetration of households.

Therefore, being realistic, it is unlikely that 50% of cars will be fitted with RDS-TMC within the next 15 years.

The trend towards factory-fitted car radios is potentially helpful to the roll-out of new technologies, such as RDS-TMC or
DAB. This makes it necessary to persuade only a few key players (e.g. car manufacturers and car radio suppliers) and this
should be much easier than trying to persuade individual members of the general public to discard their existing car
radios and to buy new radios with added functionality (e.g. RDS-TMC or DAB). However, the corollary is that car
manufacturers are understandably reluctant to commit to including new technologies as standard features without clear
evidence of consumers’ willingness to pay and widespread availability of receivers.

For VHF/FM radio RDS came as a silent revolution. It represents a significant step towards putting the user at ease with
the radio, primarily in the mobile reception mode. But only now, in the later phases of RDS implementation comes the
time when listerners at home can enjoy some of the more advanced programme-related features of RDS (eg Radio Text
and Programme Type). When RDS development started more than twenty years ago in the EBU, there was an
expectation that eventually all FM radios would be equipped with functionality for RDS. In 1998, this objective has not
yet been achieved. Only about 50% of all cars have an RDS car radio (without RDS-TMC). However, 90% of all new cars
are now line-fitted with RDS radios, and also 90% of all new aftermarket sale car radios in Europe have now RDS.
Nevertheless, it will then probably take another ten years, until we can say that 90% of all cars in Europe have RDS. Given
that first RDS radios appeared on the market in 1988, it will have taken 20 years to achieve this. In this context it is
worthwhile to note that RDS technology, as developed by the EBU, was well accepted by the consumer electronics
industry. The RDS specification was published by the EBU in 1984. Through a consensus reached within the EBU, public
broadcasters in Europe implemented RDS within three years and receiver manufacturers needed four years to roll-out
products.

The future of RDS-TMC

The future of RDS-TMC is impossible to predict with any certainty, but is probably
described by one of the following scenarios:

• RDS-TMC is a great success, becoming a standard feature of all new cars within five years
• RDS-TMC is moderately successful in the next five years, but is then eclipsed by DAB-TPEG
• RDS-TMC fails because it is not adopted by car manufacturers or consumers.
• RDS-TMC fails because of competition from non-broadcast technologies, such as UMTS

Existing on-air audio TTI announcements will still be needed for more than 15 years and, once started, RDS-TMC
services will need to be maintained for 10-15 years (even if RDS-TMC is not a huge success).

23