Traffic and Travel Information

(TTI) broadcasting

Traffic and Travel Informationbroadcasting history

Broadcasters recognized the need to help drivers, with easy to understandinformation, many years ago! EBU member organizations - the nationalbroadcasters with country-wide coverage -have a long successful history of publicservice TTI broadcasting, delivered free to the end user. For many years they havecooperated to develop this important area of broadcasting through the ongoingEBU Broadcasts for Motorists activity and through the Eurotravel conferences,usually held every four years. The range of TTI broadcasting is considerable andincludes many thousands of spoken TTI announcements across Europe every day,supported by TV and Teletext information and service phones. Recently this hasbeen augmented by newly developed services using the Internet and emergingRDS-TMC services.

Within the EBU framework, this significant broadcasting sector is supportedoperationally by daily contacts between EBU members across national boarders, toprovide 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 beenfunded by the European Commission (EC), within the very wide IntelligentTransport Systems (ITS) budgets, to bring forward many technical solutions for TTIcollection (eg road sensors), information interchange (eg DATEX) anddissemination (eg RDS-TMC).However, in the last five years, significant commercial exploitation, using nonbroadcasting delivery (eg GSM phones) has been developed to the extent that TTI -broadcasting and narrowcasting - now has many new opportunities and threats toconsider.

European perspective for TTI

These developments have led the European Union (EU) to declare its policy forRDS-TMC, as the first priority action for deployment Europe-wide in the next fewyears (Community Strategy and Framework for the Deployment of Road TransportTelematics in Europe, COM(97)223 final). Over the last two and a half years, the EBUhas been working in the EC funded EPISODE Project, which is concerned withmonitoring the RDS-TMC final implementation plans. It is providing a “voice” forthe broadcast sector in the TTI and Transport worlds, which are dominated byministries and very large industrial companies who use their lobbying power,through ERTICO, to influence EC policy-making, and ultimately this reaches theEuropean parliament decision-makers.

TTI issues are not all straight forward!

The EU priority action to deploy RDS-TMC was considered to become an EUDirective. This would have imposed the need for broadcasters to implement RDS-

TTI has a long successfulhistory - before RDS-TMC

New technologies for TTIfunded by �Europe� withinITS budgets

RDS-TMC is highimplementation priority forEurope

Commercial interest in TTImay not be public serviceoriented

Public broadcasters RDS-TMCservices poorly coordinated

TMC, without any possibility of escape! Nevertheless the outcome was aMemorandum of Understanding (MoU) for RDS-TMC services with so-called, ALERTfunctionality. It appears that this MoU hides the use of the ALERT-Plus protocol forStatus oriented messages, as well as the ALERT-C protocol for RDS-TMC Eventoriented services (see article 13). Implementation of ALERT-Plus will not be acceptableto public service broadcasters, who cannot release the very large RDS data capacityrequired for ALERT-Plus.

The commercial sector has continued to attempt to push a point of view, which hardlyrecognizes the public service elements of TTI and, as a result, the EU objective ofEuropean-wide deployment of RDS-TMC is considerably delayed.

The EPISODE Project

The EPISODE Project, being a inter-disciplinary group, where journalists, programmeeditors and engineers have worked closely together, has been able to monitor botheditorial, end-user and technical issues. As a result, it has issued a number of ProjectStatements 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 laterthe non-broadcast sectors involed in RDS-TMC implementation have come to realisethat 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 lookstowards the future of DAB.

RDS-TMC implementation steps

Across Europe, many EC-funded Projects are now beginning to set up RDS-TMCdeployments, but these are being driven by ministry and government agencies. TheEuro-Regional Projects, in particular, are aiming at solving cross border issues. Fromthe broadcasting viewpoint these are not fully coordinated and different models arebeing used, including some in which the network-capable public service broadcastersare not included. In this context the power of the European member states’ transportministries to decide on their policies (even potentially to the disadvantage of thebroadcasters traditional sources of information) must not be underestimated.

The European trend for separating broadcasters and transmission operators has been acause for concern within the EBU, because the TTI world does not understand theresulting difficulty that broadcasters face in coordinating on-air information via thevarious delivery mechanisms in use: Spoken radio announcements, Internet, TV,Teletext, and RDS-TMC.

1

�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.�

�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

TTI in the new competitiveenvironment

The upcoming new scenario forTTI service provision

Future TTI services will have to be developed on the assumption that mobilecommunication with people on the road will definitely take place within a newcompetitive multimedia service environment where broadcast technology will bejust one delivery mechanism and another will be mobile telephone technology.

In this particular context, we can note the following trend: traffic informationreceivers were in the past essentially car radios for which there was a significantafter-market, supported by more than 50 different consumer electronicmanufacturers, mainly from Europe and Far East, supplying a wide range ofproducts.

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 thedashboard, and these will be increasingly used together with other telematicsfunctionality. Additionally they order OEM equipment, meeting their owninterface requirements, which somewhat opposes any standardization of theseinterfaces.

Most recently, the German mobile telephone provider Mannesmann-Autocomacquired VDO, a large company that manufactures vehicle instruments and cardashboards and then, Philips Car Systems, one of the major car radiomanufacturers that is also an important supplier of telematic terminals andnavigational systems. All this indicates that the after-market for these products maygradually shrink and that a number of different telematic systems, as accepted bythe market, will coexist through telematics equipment that is delivered with the carto the end-user.

The possibility to use GSM forcell 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-boardequipped 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 (ShortMessage 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 navigationalsystem. The widely spread GSM technology is thus, in addition to traditionalbroadcasting, very suitable for the provision of a large variety of data services ofinterest to mobile road-users, either using the bi-directional communication link orthe inherent data cell broadcasting feature.Integration of Internet and GSM technology has been studied extensively in the EC

New multimedia technologyis developed for GSM

Trend to integratetelematics functionalityinto the car radio

Different telematics systemswill coexist

Multi-functionality introducedby first installed car radioequipment

TTI is also identified by GSMoperators as a �killerapplication�

Navigational systems shalloffer Dynamic RouteGuidance

2

funded PROMISE project. This project aims at the development of a traffic and travel information service employing anew type of user terminal, the Nokia 9000 Communicator, using the data communication capabilities of the cellular GSMnetwork.

Finally, the Universal Mobile Telecommunication System (UMTS) will represent the third generation of wireless mobilevoice and data communication. This will probably attain a user data rate of 2 Mbit/s. The wide availability of GSM makesit 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 withthe view to ensuring a long lifetime for GSM products using earlier versions of the standards.

ERTICO aims at defining a strategy forsupporting ITS services via GSM

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

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

• The second development is a proposal on generic wireless information access called WAP (Wireless ApplicationProtocol). WAP can coexist with GATS and extends the functionality towards Internet-like information accesspermitting the use of channels with a limited data rate. It thus provides a new access medium to ITS services onGSM. The first version of the standard was released in September 1997. A WAP Forum will be created to managethe 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 unitswithin individual cars; this can be seen as traffic monitoring which can beimplemented 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-urbanenvironment. GSM permits easy implementation of commercial ITS services since the system permits roaming, hand-over, SIM-based authentication.

The political environment

surrounding RDS-TMCEuropean Union and ECMT policy

The European Union (EU) has declared a very strong policy towards the use ofRDS-TMC, as their first priority action for deployment, Europe-wide in the next fewyears. (Community Strategy and Framework for the Deployment of Road TransportTelematics in Europe, COM(97)223 final). The European Conference of Ministers ofTransport (ECMT) made a pre-cursor decision about RDS-TMC at the ECMTCouncil Session in Annecy in 1994 when the Ministers of Transport adopted aResolution on Driver Information and Route Guidance Systems in transport. ThisResolution contained nine principal recommendations of which Recommendation9 concerned the implementation of RDS-TMC and included the followingrecommendations:

� should define and establish all necessary institutionalagreements between participating partners (road andtraffic authorities, police, broadcasters, motorist clubs,etc.);

� should use RDS-TMC as suitable way to broadcast trafficmessages to motorists;

� encourage and support the creation and updating oflocation references for their transport network;

� promote international exchange of traffic messages toalleviate international traffic;

� promote the adoption of compatible standards for thesupporting subsystems as far as these are needed toensure 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 fundedEPISODE project, which is concerned with monitoring the RDS-TMC finalimplementation plans. It is providing a “voice” for the broadcast sector in the TTIand Transport worlds, which are dominated by transport ministries, roadauthorities and very large industrial companies who use their lobbying power,often through ERTICO, to influence EC policy making, and ultimately this reachesthe European Parliament decision makers.

The EU priority action to deploy RDS-TMC narrowly missed becoming an EUDirective.

This would have imposed RDS-TMC implementation directly on broadcasters,without any possibility to escape! Nevertheless the outcome was the ALERTMemorandum of Understanding for RDS-TMC services using the ALERT-Cprotocol. However, this MoU hides the use of another protocol known as ALERT-Plus which is essentially unacceptable to public service broadcasters because itoccupies too much RDS data capacity and if used, would prevent programme-related RDS features from being fully implemented.

ECMT and EU policy makesRDS-TMC a priority

ALERT MoU commits MemberStates to deploy RDS-TMC

RDS-TMC receiveravailability - too slow

On-air TTI compatibility - stillto be solved

3

EPISODE project Statements

The EPISODE project, being a multi-disciplinary group of radio-programme and databroadcast technology experts - one of the first in EBU history, where journalists,programme editors, and engineers have worked closely together - has been able tomonitor both editorial, end user and technical issues. As a result, it has issued anumber 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 viewwhich hardly recognizes the public-service elements of TTI and, as a result, the EUobjective of European-wide deployment of RDS-TMC is considerably delayed. Theclassical chicken and egg problem has been used to suggest that RDS-TMC servicesmust be on-air before consumer electronics products are made available. Broadcastershave ensured that RDS-TMC services were indeed on-air as promised (with manymore to follow), to underwrite the political requests and support industry. Then thedisplay/language issue has been posed as a difficulty because the industry initiallyinvolved in RDS-TMC development has wanted to see unrealistically large initialmarkets and expected additional funding for providing products with the necessarydisplay/language performance.

Euro-Regional Projects -Broadcasters influence

Across Europe, there are now several EC-funded Euro-Regional Projects beginning toset up RDS-TMC deployments, but these are being driven by ministry andgovernment agencies. From the broadcasting viewpoint these are not fullycoordinated and different models are being used, including some where the networkcapable public service broadcasters are excluded. In this context the power of theEuropean member states’ transport ministries to decide on their policies (evenpotentially to the disadvantage of the broadcasters traditional sources of information)must not be underestimated. The European trend for separating Broadcasters andTransmission Operators has already been a cause for concern within the EBU. The TTIworld also does not understand the resulting difficulty that broadcasters face incoordinating on-air information via the various delivery mechanisms in use (egSpoken services, RDS-TMC, Teletext, TV and Internet).

The public broadcasters role in

TTI service provision

Long EBU History in TTI

As part of their public service remit, the members of the EBU have offered TTIservices freely to the end-user over many years, according to the technologyavailable. Firstly spoken messages appeared on radio services, followed by thesame on TV; then Teletext added another possibility and in-vision text servicesfollowed; in German speaking areas ARI was implemented and eventually RDSbecame widespread with the ability to “flag” traffic announcements, regardless oflistening choice, by using the EON feature. Throughout these developments theBroadcasts for Motorists activity has ensured cross border liaison betweenbroadcasters and developed the first Events list (last published in 1990) to facilitateinformation 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 fromshort snappy information spoken by professional presenters to long boringannouncements spoken by representatives of the information authority (eg police,rail, and bus operators). Public broadcasters have willingly opened theirprogrammes to TTI, believing that their listening public require information free atthe 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 themost accident prone and most difficult sector to provide information to the travellerin the vehicle.

Such TTI information has built up to the point where in some cases the amount ofTTI messages could be judged to damage the programme presentation style, whilein a few isolated cases it has been seen as a positive benefit to the style. Inevitablythe demand for more and more TTI has continued and RDS-TMC can now be seenas a positive way of offering increased information in a structured way which willthrough some filtering, give the user real advantages with respect to the torrent ofinformation pouring over him.

Broadcasters want RDS-TMC

It is clear that RDS-TMC will help broadcasters to offer the maximum amount ofinformation to the end user, but the cost is that a long transition period will beneeded. Initially very few RDS-TMC receivers will be in use, but gradually as theybecome more widely available the broadcaster will be able to use the many differentmedia techniques available again in a more effective way.

EBU members have a longhistory of free TTI services

EBU Events list wasfoundation of RDS-TMC

Public Broadcasters needinformation freely provided

On-air TTI compatibility -a key objective

Free information to create publicservices with on-air consistency

Broadcasters through their information and news-gathering systems are well placed tobe RDS-TMC service providers and to be able to offer a particularly rich service withfactual and anecdotal information. The factual information is most appropriate for theRDS-TMC service while the linked anecdotal information can be most effectively usedin other ways, often to support traffic management objectives.

The most critical issues that arise from this multi-layered approach are access toinformation and on-air consistency. It is vital that public service broadcasters, whoprovide free-to-air services for the benefit of the public across many media deliverymethods retain free access to TTI source information. The public broadcasters arewilling 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,A wide range of international bodies is concerned with harmonization related to thedevelopment, standardization and introduction of ITS services in Europe. Theseinclude the provision of TTI data broadcast services involving the public andprivate service sectors. The key players with which the EBU is expected toharmonize its objectives are the following:

ECMT

The European Conference of Ministers of Transport (ECMT) is anintergovernmental organization for Transport Ministers in 38 European countries.ECMT Resolution 26 of 1994 led to the creation of a Working Group on TrafficManagement and Road Traffic Information whose task is among others to monitorthe implementation of the recommendations on new information technologiesapproved 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. Theexperience gained from collaborating with this Group is that it has a significantimpact on guiding the transport authorities with respect to technologies that shouldbe used on a European scale for the exchange and provision of road trafficinformation with the view to facilitating the flow of traffic throughout the areacovered by the ECMT.

European Commission

The European Commission comprises many different Directorates, each withspecific sector interests. Each Directorate is divided into Sections concerningspecific matters and two directorate sections have specific concerns with RDS-TMCtechnology.

DG VII

DG VII - A2 is the Section for Transport, International Relations and TransEuropean Transport Network and Infrastructures, with concern for pilot projectsand implementations associated with RDS-TMC, over the last two or three yearsand into the near term future. It supports the Euro-Regional Projects which arebeginning to evaluate the complex institutional cross-border issues interlinked withRDS-TMC technology with the objective to be surmounted before a fully effectiveoperational RDS-TMC service can become available to users. In the field of RoadTransport, RDS-TMC has long been a goal and it has recently received a strongimpetus, being nominated by the European Council of Ministers a priority domainfor transport development in EU Member States.

DG XIII

DG XIII - C6 is the Section for Telecommunications, Information Market andExploitation of Research Telematics Applications for Transport and Environment,with concern for many developments associated with RDS-TMC, over the last tenyears or so. The projects of the Telematics Application Programme: TransportSector (part of the 4th Framework Programme 1994 - 1998) are involved in the

ECMT has the highestpolitical impact

The EC heavily invests in newtechnology

The EC heavily invest inbuilding harmonizedinfrastructures

CEN is a key organization forITS standards

CENELEC has responsibilityfor RDS standard

ERTICO lobbies on industryobjectives

CENELEC, ERTICO

5

development, demonstration and validation of enhanced services to transport users. This work, which is coordinatedwith other initiatives on the Trans European Networks, also consolidates on the results of the previous programmes ofResearch 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 Projectand the FORCE Project who, among other things, are progressing the standards development in cooperation with theECORTIS Project which has an emphasis on implementations. The former Projects have cooperated with the standardsorganization, CEN to finalise the activity of several Working Groups and are now actively involved in disseminatinginformation about the inter-related RDS-TMC standards, for all workers in this field, before they are eventuallypublished.

Comité Européen de Normalisation (CEN)

The Comité Européen de Normalisation (CEN) is one of several European organizations responsible forstandardization (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 TechnicalCommittee TC 107 (now called TC 207) issued the original RDS specification (see Article 9). The correspondinginternational standards body on a worldwide level is the IEC.

European Road Transport Telematic ImplementationCoordination Organisation (ERTICO)

ERTICO, with its offices in Brussels, brings together industry, public and private infrastructure operators (mainly roadauthorities 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 tosupply support to the EC for the provision of a coordination service which was since then much required to ensure ahigher degree of harmonization between the numerous projects. The legal entity of this “international association” isthat of a Belgian Cooperative Company, having itself given the aim by its founders “to identify and promote an effectiveimplementation strategy for the development of ATT (Advanced Transport Telematics) in road transportinfrastructures, exploiting the results achieved by EC funded ITS projects, and other national research and developmentprogrammes, thus assuring a smooth transition from pre-competitive R&D to the market-driven investment of sectoractors”.

Consequently ERTICO has objectives such as to define long term transport telematics requirements, toharmonize 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 basedon the evaluation of all relevant DRIVE projects, in particular those of ALERT and STRADA. The coordination work ofERTICO became a large part of the DRIVE II programme and the corresponding project was called CORD. In the area ofcreating a European road database, ERTICO has also been active and has proposed harmonized coding rules based onALERT and SOCRATES requirements. Another area of activity concerns the traffic information cross-border dataexchange format DATEX, using the ISO standardized EDIFACT data communication protocol. In Autumn 1997 aMemorandum of Understanding was signed by many EU countries in support of DATEX, recommending itsimplementation.

ERTICO now has the vision, established during 1995, to stimulate wide deployment of RDS-TMC and yet continue toevaluate other TTI options for the future, such as DAB delivery of TMC TTI messages.

What is RDS?

Radio Data System

RDS uses the technique of adding data to a sub-carrier on an existing stereotransmission in such a way that the data is carried inaudibly. RDS is designed witha 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 isreported to have reached well over 50 million products in its first ten years, but nowit is almost impossible to buy a non RDS car radio in western Europe. Neverthelessfor RDS-TMC services it will require a whole new range of RDS-TMC compatibleproducts to be developed and marketed.

RDS tuning features

The most obvious RDS features are those seen on a typical RDS receiver. Moderncar receivers usually support the following features:

Alternative Frequencies (AF)The AF feature is intended to give information on the frequency of the varioustransmitters broadcasting the same programme in the same or adjacent receptionareas, to enable receivers equipped with a memory to store the list(s), to reduce thetime for switching to another transmitter. This facility is particularly useful formobile car and portable receivers.

Programme Service name (PS)The Programme Service name feature is designed to provide information for anRDS receiver to display the name of the radio programme service, instead of, forexample, the tuned frequency being displayed. The PS is formatted for eightcharacter displays using either LARGE or small characters, for example:>Classic_<. The PS name is intended to inform the listener what programmeservice is being broadcast. The Programme Service name is not intended to be usedfor automatic search tuning and must not be used for giving sequentialinformation.

Traffic Announcements (TA)The Traffic Announcement indicator feature is a two-state flag signal to inform areceiver that there is a Traffic Announcement on air or not. This signalling maypermit a receiver to: switch automatically from any audio mode to the trafficannouncement; switch on the traffic announcement automatically when thereceiver is in a waiting reception mode and the audio signal is muted; switch from aprogramme to another one carrying a traffic announcement, according to thosepossibilities.

Traffic Programme (TP)The Traffic Programme indicator feature is a two-state flag signal to inform areceiver that the transmission being received carries Traffic Announcements or not.The TP flag must only be set high on transmissions which dynamically switch onthe TA indicator flag during Traffic Announcements. The TP signal may be usedduring automatic search tuning.

RDS stands forRadio Data System

RDS has been operational onFM for more than ten years

Originally developed by theEBU - now standardized byCENELEC

Now by commercial andpublic broadcasters alike,across the world

RDS support features

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

Radio Text (RT)The RadioText feature allows the transmission of text messages up to 64 characters inlength to be conveyed primarily to consumer home receivers. Shorter messages arealso possible and they may be frequently altered at a reasonable rate to allowprogramme related information such as music title, conductor, orchestra and CDnumber to be followed.

RDS supports a wide range of programme-related and non-programme-relatedfeatures, 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 usingthe Open Data Applications (ODA) feature.

Philips car radio: with PTY - News selection button

Prototype BBC home tuner, 1982

Volvo SR 701 the first RDS car radio, 1987

6

The RDS-TMC concept

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 radioprogramme - just the opposite of the common practice today with spoken trafficmessages. Thus, TTI can inaudibly be data broadcast in the background of existingFM radio programmes.

Data collection

Data about traffic events are collected in regional and national Traffic InformationCentres, with many in the near future interconnected for the exchange of theirmessages, 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 achievethis. The coding also permits users to receive only those messages that are relevantto their needs. Thus it may be possible for a tourist to travel, for example, fromLondon to Rome, through Belgium, Germany, Switzerland, France and Italy, whilealways getting the traffic announcements via RDS-TMC in his own language, thelocation codes being on a smart card or CD-ROM that he purchased in London. Butfor this objective to be really achieved, apart from an agreed set of EuropeanStandards specifying the system, there is additionally a strong need for a largenumber of harmonized administrative and institutional agreements still to becoordinated among the countries concerned.

Message filtering

The TTI messages that are distributed will, of course, be conveyed to and stored inreceiver memory which may subsequently permit traffic announcements to bepresented via speech synthesis in the language required. Messages can be filteredon 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 relevantinformation, selected from all the messages that are available on an RDS-TMCservice, at any given time.

The importance of filtering is demonstrated in this example: given the maximumcapacity of RDS-TMC, it will be possible to transmit about 300 different messages inthe air at any one time. If the same messages were spoken and each only took 15seconds, the total announcement time would be 75 minutes. An obviousinformation overload! In addition, RDS-TMC messages could be used to provideassistance for route-planning, use of alternative transport facilities and routes,continuous up-dating of electronic maps and systems used for navigational aids.

The need for TTI increasesas traffic volumes increase

RDS-TMC provideslanguage-independentmessages

Existing RDS receivers cannotbe adapted to RDS-TMC

RDS-TMC receivers require adouble-tuner: one for radiolistening, the other forTTI

RDS-TMC receivers presentthe user only with relevantmessages concerning hisjourney

RDS has a very limited data transmissioncapacity

The limited data transmission capacity of the RDS system does not generally permitimplementation 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 doubletuner to permit one tuner to always be used for radio listening and the other tuner beused for RDS-TMC data collection.

7

The RDS-TMC developmenthistory

From ARI to RDS-TP/TA

Traffic and Travel Information (TTI) is just one essential component of RDS, whichwas clearly recognized long before RDS was first standardized in the mid 1980s. Byproviding the traffic flags TP and TA which, as a concept, were developed for theARI system in the early 1970s, a basic service for spoken messages is in place thanksto the very strong commitment of many public broadcasters in Europe, coordinatedthrough 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 toenable 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-referencedprogramme. This has by now developed into an option much used to givespecifically also traffic announcements about local situations.

RDS-TMC appears on the horizon

The possibility of digitally coding traffic information and making it languageindependent within the RDS data stream, was first mentioned by Bosch/Blaupunktin 1984 at the EBU Eurotravel conference in Grado, Italy. Bosch/Blaupunktimmediately started the technical development in Germany, and Philips in theNetherlands followed shortly afterwards. One year later, the European Associationof Consumer Electronics Manufacturers, known then as Eurotech (now EACEM)agreed with the EBU that they would then jointly support the development of theRDS-TMC feature, still called at that time CIM (Comprehensive Information forMotorists).

European Commission involvement andthe ALERT-C protocol

The EBU accepted this proposal and created a group of RDS specialists in which theinterested manufacturers participated. In 1986, Bosch/Philips submitted a commonproposal 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 andit was widely agreed due to the strong lobbying of Bosch/Philips to launch adevelopment project that included already a number of validation field trials inseveral 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 furtherdevelopment.

RDS-TP/TA was a first step inthe 1980s

EON provided a significantenhancement

RDS-TMC developmentstarted mid-1980s

1994 - ECMT recommendsRDS-TMC

1995 - EC chooses RDS-TMCto become a priority issue

1997 - RDS-TMC starts tobecome an operationalservice

RDS-TMC implementationacross the EU continues intothe year 2000

Development of a European standardfor event codes

An agreed list of event codes was now needed and it was recognized that the EBU hadalready issued in 1988 such a list which covered seven languages. However, throughthe EC funded projects, the EBU event list was eventually much extended andharmonized between all sectors interested in RDS-TMC service provision, but withoutfurther 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 intotal) took place as part of the EC/DRIVE II programme on Advanced TransportTelematics to test the feasibility of the service. The experience gained was largelypositive, 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 actionfor the further development of the Trans European Road Network (TERN) in all EUMember States.

The EC-funded development work over the preceding ten years were coming tofruition. It was recognized that the existing FM and RDS infrastructures weresubstantially complete across Europe and that the language independent TTI servicescapability of RDS-TMC would be very advantageous to the citizens of the EU memberstates.

1997 was the year when the first operational RDS-TMC service introductions started ina 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 theyears up to the year 2000s. As a priority, these new RDS-TMC services intend first of allto cover all major roads belonging to the TERN.

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

8

European Standards for

RDS-TMCStandards Background

The EC funded FORCE/ECORTIS Projects and the EC-funded EBU EPISODEProject have been working for the last three years to complete the RDS-TMCstandardization, in collaboration with the RDS Forum and CEN TC 278 WorkingGroup 4. This was necessary to provide a comprehensive platform for a Europeanwide implementation of RDS-TMC. This is sometimes called the ALERT serviceand has become the subject of the so-called ALERT Memorandum ofUnderstanding (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 corespecification. Additionally, a series of CEN pre-standards (including a considerableamount of European industry IPR) are then used to fully specify RDS-TMCfunctionality which comprises the message protocol, event messages, locationreferencing, and the newer extension named ALERT-Plus, specified for Statusmessages.

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 inthe early 1980s, then published as a European standard in 1992. It has recently beenupdated 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 asCENELEC EN 50067:1998 and contains several new features including the ODAfeature, originally suggested for RDS-TMC purposes; additionally it includesspecific references and “hooks” to the RDS-TMC standards in the CEN ENV 12313series. Furthermore RDS Guidelines are being prepared by the RDS Forum and willbe published shortly. Comprehensive information can be obtained from the RDSForum 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 nowavailable from the CEN Central Secretariat. Therefore this should be taken as themain standard describing, the so-called, ALERT-C protocol. This standard containsboth the protocol and the RDS-TMC related coding which now uses type 1A, 3Aand 8A groups (ODA compliant format). It is to be hoped that the FORCE/ECORTIS Projects will publish Guidelines for RDS-TMC shortly.

RDS-TMC standardized byCENELEC and CEN

EN 50067:1998 - the RDSstandard upgraded forRDS-TMC

ENV 12313 series forTMC - only pre-standardscompleted

ENV 12313 series contain IPRwith licencing consequences

ALERT services covered byMoU

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 protocolare specified in the CEN ENV12313-2 standard and is now available from the CENCentral Secretariat. This standard uses the so called CEN-English to define a trafficmessage, eg “stationary traffic for 1km” which is code 102. The meaning of this codehas to be defined for each of the European languages and this work was completed inspring 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 nowplanned to become the third part of the ENV 12313 standards series, specifying and, inthis case, detailing the Location referencing rules. These rules are required so thatevery TMC Service Provider uses common methodology in creating their locationdatabase, but it does not restrict their value-added aspects, allowing some to codemore “finely” than others. In early drafts, some variation of interpretation resulted,and the FORCE/ECORTIS Projects established a subgroup “Interpretation of theLocation referencing Rules” with the intention to write a “Location codingHandbook”.

European Pre-standards, numberedin the ENV series

The CEN Internal Regulations state that a European Pre-standard may be establishedas a prospective standard for provisional application in technical fields where theinnovation rate is high (e.g. Information Technology) or, when there is an urgent needfor guidance and primarily where aspects of safety for persons and goods are notinvolved.

The lifetime of an ENV is first limited to three years. An extension of the ENV foranother two years (only once) is possible. It can also be converted after formal vote intoa 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 theconversion from the Pre-standard ENV to the full standard EN will be made, for allthree specifications mentioned.

9

The Open Data Applications

concept and RDS-TMC

RDS standard provides ODA for RDS-TMC

The Open Data Applications (ODA) feature of RDS was developed to allow dataapplications, not previously specified, to be conveyed in an RDS datastream, withminimal 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 tobe indicated in any RDS transmission using the ODA-Application Identification(AID) feature, to allow decoders to monitor for them and then decode the relevantdata. A wide choice of groups are available for use by ODA data services and thesemay be selected by a Transmission Operator at his convenience. The service isidentified in the associated RDS type 3A groups, in the same RDS datastream.

Open Data Application -designed for RDS-TMC

ODA registered with EBURDS Registrations Office

ODA for ALERT-C

ODA for ALERT-Plus

10

Labelling RDS-TMC services

RDS-TMC standards use predefined ODAs which have been agreed for simplicity ofdecoder design, in advance of the service introductions. The so-called ALERT service(see article 13) encompasses two protocols: ALERT-C and ALERT-Plus, which aretreated as two entirely different ODAs. However a service labelled as the latter mustalso include ALERT-C messages. Thus, both applications use type 8A groups, bothhave the same application group type 8A, but a different AID, which a decoder can useto “unscramble” the data according to which service the data applies.

Capacity limitations for RDS-TMCmust be observed

It is important to note that the AID for the ALERT-C service only permits a maximumof 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 persecond (including type 3A, and 8A groups). In practice this means that ALERT-Cservices can probably only be implemented on existing RDS transmissions where theBroadcaster can spare this capacity. However “ALERT-C with ALERT-Plus” servicescan only be accommodated on FM transmissions not previously using RDS featuresfor the radio-programme related RDS service and specifically RadioText. Once inoperation, the radio-programme related RDS features can most probably no longer beimplemented since RDS has insufficient data transmission capacity for all the definedRDS features to coexist on the same radio programme. This requires also a choice to bemade of those needed by the broadcaster and if he does not own the transmitternetwork, 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 Officein early 1999, after suitable field implementation experience was gained.

The Universal Encoder

Communications Protocol and

Existing RDS infrastructures of thenineteen eighties do not support RDS-TMC

At the time when RDS was implemented (starting in 1984) nobody had given anythought to using this infrastructure one day for RDS-TMC.

Transmission Operators who want to implement any type of RDS service need toinstall RDS encoders. They are normally installed at transmitter sites adjacent to thestereo encoder, which generates a 19 kHz signal that the RDS encoder uses tosynchronize its output RDS datastream.

Static versus Dynamic RDS

Two “types” of RDS can be provided: Static RDS services can be provided by anRDS encoder simply providing RDS information, such as a fixed AF list, frominternal memory; whereas Dynamic RDS services, such as RadioText, require datainput to an RDS encoder.

Even Static RDS services may have to be changed from time to time, dependingupon 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 radioprogramme content requires a high degree of control from the on-air studio. In thecase of a data service such as RDS-TMC, a high degree of control is required fromthe Service Provider to supply their data to the RDS encoder, either to a singlebroadcast 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 RDSencoder. This is due to the fact that for economic reasons the Transmission Operatorhad to adapt existing analogue, or even digital, audio distribution networks whichare essentially uni-directional, to add a data distribution function.

Proprietary communication protocolsversus the open UECP

A number of proprietary RDS encoder update protocols were initially implementedon data links between source RDS data servers and the RDS encoders; several ofthem were encoder manufacturer specific. These protocols were used to send datamessages from an RDS controller/management system (or simply an RDS encoderserver) to the RDS encoders. Acknowledgements from the encoder were notessential and, instead, it was arranged to send repeats of each message in order toensure their receipt. In this way a whole range of Dynamic RDS features could beused by the broadcaster to enhance RDS performance for the listener. In some casesan RDS encoder controller, running on a PC, has been used to send updatemessages to the RDS encoder, or if a very full implementation is required, then adedicated RDS management computer system, frequently called an RDS Server,has be used to control, on a scheduled basis, the whole range of RDS features,

Initial RDS infrastructuresneed to upgraded for RDS-TMC

The UECP is a de factoindustry standard for RDSencoders

Permits networked operationof RDS encoders from varioussuppliers

Supports latest version of theRDS-TMC standards

RDS-TMCincluding the radio programme related RDS features and the full array of EONreference data.

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

These proprietary update protocols had similar functional elements, however theydiffered significantly in their environmental models. The structure, functionality, andaddressing of their intended networks and the data structures within each RDSencoder are often quite different. Therefore the Universal Encoder CommunicationProtocol (UECP) specification, now widely accepted by broadcasters and the wholeindustry involved, was based on harmonized environmental and encoder models.

The UECP is a layered communication protocol which is in line with the commonlyused OSI reference model (ISO Recommendation 7498). The UECP in its presentVersion - 5.1 (August 1997) - encompasses all current RDS features including the latestTMC specifications and it is also designed to accommodate all new developments thatwill use the ODA concept.

EBU developed with the UECP a de factoindustry standard

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

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

11

Principles of RDS-TMCLocation reference coding

Messages referring to locations requirein RDS-TMC a Location reference code

Most RDS-TMC messages provide information about a location (e.g. a stretch ofroad, an intersection, a region) and they refer to it by using a location reference. Thisis 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 inlocation code tables. The maximum number of codes in one table is determined bythe field length for location codes in RDS-TMC, i.e. 16 bit which corresponds to65,536 possible codes.

An obvious disadvantage isthe maintenance required

The disadvantage of these tables is that they need to be created and maintained (seearticle 16). The receiving system must use exactly the same Location code table asthe 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 ENV12313-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 detailsthat follow are extracted from the pre-standard and apply thus to ALERT-Cmessages only.

Principles of arrangingthe location codes within tables

Pre-defined locations are referenced by their location code which is the tabularaddress of a number of pre-stored location details. Each table of stored locationsmust be given a unique location table number by one unique agency in each countryor state. A country code (note: RDS-TMC uses the RDS country codes) identifies theagency responsible for location reference coding and which defined the locationtable and its number.

The concept of primary andsecondary locations

Many location references extend through several adjacent areas or road sections.The concept of primary and secondary locations is then used to indicate theextremities 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) andthe resulting queue extends back to “km 10.9", the situation location can be definedas E15, “km 14.2 - 10.9”. Where “km 14.2” is defined as the primary location and

For RDS-TMC messageencoding and decodingthe same code table ismandatory

Location code tables needto be created specificallyfor RDS-TMC

Location code tables requiremaintenance

ALERT-C and ALERT-Plus usedifferent location code tables

“km 10.9” is then the secondary location. The primary location is taken to be where thecause of the problem can be found, whenever a cause can be pin-pointedgeographically. However, both, primary and secondary location shall lie on the sameroad.

For the primary location, the location reference is the nearest downstream location inthe direction of travel. The secondary location is indicated in terms of extent, i.e. thenumber 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 locationcode table each location has one unique number in the range 1 - 63,487. The other 2048numbers are reserved for EUROAD, an agreed concept used for coding messages tointernational travellers on the Trans European Road Network (TERN).

The hierarchical structure ofthe location code tables

RDS-TMC uses a hierarchical structure of pre-defined locations. A system of pointersprovides upwards references to higher level locations containing the specifiedlocation. For example, Kent would have an upward area reference to South-EastEngland which will be upwards referenced to the UK, then the British Isles, thenEurope.

Junction 25 on the M1 motorway in the UK would have a section of route referenced toa motorway segment, e.g. Leicester - Sheffield. This segment will then be referencedupwards to the whole road, i.e. the motorway M1.

What is a Direction and an Extent codein 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 wherean accidents results in long tailbacks. The ALERT-C protocol defines such occurrencesby addressing the location of the accident as the primary location, then identifying theend of the tailback by using the direction and extent fields. These fields consist of 4 bitsin total, one direction bit and three extent bits. The direction bit indicates the queuegrowth and not the direction of traffic flow. The extent bits identify the number oflocations 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 thesecondary location (the end of the event’s extent) as being the next location along thesame road from the primary location. An extent of 3 would force the receiver to searchthe database for the third location along the same road from the primary location. 12

RDS-TMCEvent 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) tobe 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 copyof the database, it has one big advantage: the end user can use a receiver whichpresents the information in his own language. This is a big advantage in Europewith 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 article9), which is a culmination of many years of work, funded by the EC, to distill a verywide knowledge base into an agreed set of Events phrases. These phrases totalsome 1375 from a possible 2048 events, and these are divided into 31 update classesfor coding and message management convenience. It is very important to realizethat the Event list in this standard is written in so-called CEN-English to allow it tobe translated by knowledgeable traffic engineering interpreters into user-friendlyphrases of the languages of Europe. These translations are the responsibility of therelevant standards authorities of the member states and will be disseminated tosystem designers. The meaning of each code has to be defined for each of theEuropean languages and this work was completed in spring 1998. There needs to becoherence between expressions used by the coded messages and those used in thespoken messages of the broadcasters.

Event list translations

It has even been necessary to develop an English version of the Event list to allowfor the different use of distance measurement, eg “stationary traffic for 1km” whichis code 102 and which has to be understood by the Service Provider and the Englishuser 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-TMC receiver as: “bouchon sur 1 km”, even though generated by an English ServiceProvider!

Constraints created by thelimited RDS capacity

RDS can only provide a very small bandwidth for RDS-TMC messages, so adistinction between Event and Status messages was made very early in thedevelopment process, because Status messages were expected to require

Event List standardisedfor Europe

1375 Event phrases coded

Event messages presentedin end user�s language

Harmonised translationsfor many languages exist

ALERT-C delivers Eventmessages

ALERT-Plus delivers Statusmessages

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 roadnetwork. Examples are: an accident, a traffic jam (unplanned), notification ofroadworks (planned).

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

An event has an incidental character (information is only given when somethinghappens), whereas status relates to an information stream (information is provided ona continuous basis, often related to the normal situation).

ALERT-C Event messages and ALERT-PlusStatus messages

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

13

Message generation and

infrastructure for RDS-TMCTTI Messages - where do they start?

Throughout Europe, over the last ten years, a considerable infrastructure has beeninstalled on major roads (particularly on the Trans European Road Network) tomonitor vehicle flow. This monitoring takes the form of video cameras, infraredsensors, and loops in the surface; but they all allow for greater or lesser amounts oftraffic management to be undertaken. This is probably the primary objective forfunding supply, but a huge amount of information is gathered and this may beinterpreted into useful information for individual drivers to take autonomousdecisions, if it can be delivered economically. This is where broadcast TTI can playa significant role.

TTI Message interchange via DATEX-Net

Many Traffic Information Centres (TIC) throughout Europe are beginning toimplement the DATEX-Net specification for information interchange. This is apowerful set of tools enabling automatic information exchange between TICs andother interested parties. The DATEX-Net protocol uses a Data Dictionary, datamodels, Location referencing and Message exchange formats which weredeveloped to a relatively mature stage by 1996. Subsequently the EDEN Project hasbuilt a consensus about using these tools and developed the European DATEXMemorandum 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 obtaininformation from local, national or foreign TICs, according to their service needs.But these messages will, in essence, be about situations with traffic managementemphasis and need to be enhanced with other information before an end-usermessage can be compiled. Many sources of information are used by an RDS-TMCService 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 andcollated in a database, to facilitate a suitable picture for the operational staff to makesense 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 subscribermanagement and, in the case of RDS-TMC, Location database management anddistribution. (see articles 12 and 15).

TTI Messages - expandinginformation to process

DATEX MoU - agreementsabout TTI interchange

TTI Service Providers -compile data into a useableend-user product

On-air broadcasts requirecompatibility with existinginfrastructures

TTI services using a varietyof outputs require to becoherent

RDS-TMC Message Generation

A range of software designs has been developed to facilitate the rapid generation ofRDS-TMC messages, both automatically and manually, from the vast amount ofavailable data. These software applications are designed to output messages directlyfor RDS-TMC using a number of protocols suited to the existing infrastructure theBroadcaster or Transmission Operator needs to deploy within. Nevertheless they aredesigned to facilitate compatibility on-air of RDS-TMC messages and other methods ofdelivering TTI, such as spoken messages, TV, Teletext and Internet. This is a vitalfunction of a Service Provider, since a multi-modal approach is natural for the enduser, 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” toonly listen to spoken TTI messages.

Public service broadcasters use skilled editors who interpret, compare, check andcontrol 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 generatedand transmitted.

14

Smart-cards and

payment for RDS-TMCSmart-cards -why does RDS-TMCneed them?

Because RDS-TMC is using a relatively low data capacity carrier (RDS only hasabout 650 bits/s available for all features and services), it is necessary to compressTTI message data into the smallest possible datastream for delivery to the end-user.This is achieved by compressing Location information (see article 12) and Messageinformation (see articles 13 and 14), and using look-up tables in the receiver toreconstruct the full message for the user. This has another big advantage: the datacan be presented in the language of the user, according to the RDS-TMC receiverthat has been purchased. Furthermore the language of display is then independentof the country it is received in, overcoming a significant language barrier tounderstanding of potentially important TTI messages (eg about ghost drivers).

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

Distribution of the database

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

Location database influences

In any RDS-TMC system it is necessary for the same Location database informationto be used at all Traffic Information Centres (TICs), by all Service Providers and byall devices which receive information from those sources. Such a system is depictedin the figure opposite. It introduces the role of a Card Provider, translating theavailable database to a physical and marketable form. If any of the system elementshas a database which differs from the others, then performance will be less thanoptimal. For example, if an RDS-TMC receiver were to have an old database,missing new Location codes, then messages relating to these locations cannot bereceived and presented to the driver. Such omission may be regarded as simplyunfortunate, but could have major safety implications.

Location database is thekey to decodingRDS-TMC messages

Smart-cards or CD-ROMscarry Location information

Smart-cards - help pan-European services develop

Periodic Smart-cardreplacement for revenueand quality reasons

Location database ownership

Within the system described above there can only be one database per area/country orper Service Provider, and all system elements (TIC, Service Provider, Card Providerand end-user) must derive their individual databases from this one source. It is,however, quite possible for Service Providers, Card Providers and ReceiverManufacturers to operate competitively. Each database will need to be maintained,and such maintenance should be conducted at periodic and defined dates, to enable allsystem components to operate with a common, and latest version. This means thatcards 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 thesmart-card from a local Service Provider. In turn, a Service Provider needs to fund theservice by deriving income from sale of smart-cards. Since periodic replacement isnecessary to facilitate updated Location information about new road locations, it isexpected that this can become the necessary revenue stream to fund the serviceoffered. In many cases cross border information will definitely be required andService Provider agreements to co-operate can lead to cost sharing as shown in thefigure below.

Smart-cards and CD-ROMs

It is expected that a smart-card will have a quite limited data capacity, but easily able tocontain a single countries Location database. However for the long distance travellerthe need for multiple smart-cards is partly overcome by the EUROAD conceptwhereby each Service Provider is encouraged to include some or all of the majorLocations 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 storagecapacity and containing many more Location references, but this will depend mostlyupon alliances being built by Service Providers across national borders.

15

Multimedia and the

Human Machine Interface in thevehicle

Multimedia in the vehicle - is it safe?

At first sight, the suggestion that it is possible to have a multimedia terminal in thevehicle, under driver control, seems to be unacceptable for driver safety reasons.Car radios have become more and more complex as cassettes and CD players havebeen added to many improved receiver functionalities. Some safety improvementsseem to be in sight for various in-vehicle products, but very careful integration willbe needed if all parties - Service Providers and end-users alike - can truly benefitfrom these new products.

RDS-TMC - is it multimedia?

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

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

It is interesting to note that multi-character text displays have been in use in anumber of products from taxi driver information systems to, most recently, full 64character RadioText messages on “top-of-the-range” RDS receivers, but these areplaced under some control, either from the vehicle ignition system or other control.

What about the car radio?

It is easy to see that the European car manufacturing sector is now taking great stepsto integrate electronics in the car “dash board” to a higher level. This involves carradios, navigation systems, car instruments and even the humble clock. Integrationleads to the need for one display area in the best possible visually ergonomiclocation on the “dash board” to service all the functionalities required. The keyquestion soon becomes: which has the highest priority?

The CARMINAT Project has done extensive work on visual displays in cars and agood body of work exists to show where a display should be fitted and the size, fontand number of characters per line that can be easily and safely used by a driver. Butthis work is completely geared towards TTI and navigation displays.

The implication here is that the car radio is being driven into second or even thirdplace, which cannot be seen as a good move from any broadcaster’s perspective. Itis necessary to study driver reactions to automatic prioritorization of the display

HMIs can be developed tomeet safety requirements

Navigation systems HMIis the present priority

RDS-TMC HMI will comprisedisplays and/or voicesynthesis

Is the car radio lost innew directions for HMIdevelopments?

functionality and to study the implementation of various modes to allow secondaryfunctions some percentage of the available display space. For example, when using anavigation system normally showing a map display, could 90% of the display space beallocated for that purpose, allowing 10% to be used for radio station ProgrammeService name and Programme Type display? In such an example, when the userwishes to change the radio settings the display proportion could automaticallyincrease to give more detail about the listening choices to be easily and safely made andthen revert back to navigation mode after a delay.

HMI standardization for in-vehicleinformation

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

� Design and location of information systems forcompatibility with the driving task

� Presentation of information, not impairing driver�s visualallocation to road scene

� Design of system interaction, to allow a driver safe controlof the vehicle

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

16

RDS-TMC receiver issues

The Vision for RDS-TMC receivers

The developers of RDS-TMC started to think about their vision before the EC camealong to fund the many research projects that have worked on related infrastructureand RDS-TMC specifications over the last ten or 12 years. The original idea can besummed up, as very close to: “an RDS-TMC receiver would be able to intervene inthe 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 shouldbe free of charge to the end-user, except for the need to purchase a new RDS-TMCreceiver at a reasonable to low cost, and the need perhaps to buy an update of thelocation database, occasionally.” This suggests a number of principles which cantoday be seen embodied in the various RDS and RDS-TMC standards (see article 9).

Listening choice should not be impairedMessage filteringOwn language information presentation

Since then, a European dimension has been added, with the pan-European serviceelement, to allow a driver to obtain information as the vehicle traverses nationalborders. Additionally, because of the long development cycle, the significance thatTTI has for updating navigation systems and the perceived higher value of theseproducts has made RDS-TMC a killer application for navigation systems in the nearterm. Even allowing for the long development time, the end user has become moresophisticated in expectation, and the development of voice synthesis technologyhas not been able, to achieve the expectations at a low enough price. So solutionshave been sought which will still reach acceptable end user appeal.

Thus the focus for RDS-TMC products has drifted away from the lower-pricedmarket to the much higher-priced market, before simple RDS-TMC receivers couldbe delivered to the European consumer.

Introducing first generation RDS-TMCreceivers

Perhaps inevitably as the technology for RDS-TMC was developed, it became clearthat some elements were a little too revolutionary and solutions had to be foundthat would use technology of today for the solution, knowing that by tomorrow theprice would fit the product price profile required. The most obvious example ofthis is the smart-card used to carry the Location database which is needed todecrypt the location information carried in every RDS-TMC ALERT-C message (seearticle 12). The problem now is that this technology is already in doubt for tworeasons: firstly the intellectual property rights (IPR) situation relative to the manypatents registered by Bosch/Philips is seen as a barrier to introduction, and thepotentially cheaper CD-ROM technology has become acceptable in navigationsystems. The institutional challenges to introducing either are much the same, butdo not appear to be diminishing at a fast rate and still appear to be one of the big

RDS-TMC should not detractto the listening experience

RDS-TMC information in own�spoken� language still notreadily available

RDS-TMC is strongly trendedtowards costly navigationsystems

There is little scope for amedium-priced car radiowith full RDS-TMCfunctionality

obstacles to wide user acceptance of RDS-TMC, because the Service Providers are notyet 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 andfunctionality of first generation RDS-TMC receivers is extremely disappointing. Theconsumer electronics manufacturers (CEM), who have entered the market so far,appear to be less than enthusiastic for this particular market. This is strange given thelead they have through European-funded research. It appears that one particularchange has occurred in the market, which was not predicted: the CEMs now see the carindustry - line fitted products - as their major market and not the end-user. This resultsin the navigation market products taking early precedence in the marketing plans ofCEMs and the car industry. In turn this leaves the RDS-TMC Service Provider highand dry, with no significant supply of products in the market place for them to basetheir service sales upon.

So what is available, at the time of writing in summer 1998? Bosch are offering theirViking 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 thelocations and also not all the messages. Most recently Bosch committed to develop theViking also for English, Dutch, Danish and Italian. Sagem have produced RDS-TMCreceivers specifically for car fitting into the French market, which are ALERT-Plusterminals, but thy do not yet provide a pan-European product. One of the navigationsystem product is available from Volvo (the RTI system), which can only be fitted intosome of their current car range and trucks. VDO/ Philips Car Systems has launchedan RDS-TMC car radio which needs to be connected to their own navigation system toenable the TMC functionality. Some small companies do appear to want to break intothe RDS-TMC receiver market, but IPR issues may slow their progress, neverthelessthey should be encouraged. Of course, we cannot report on those other companieswho may be developing RDS-TMC products but who will not reveal their plans untilall 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 tohatch. The problem is that the incubationperiod does not yet appear to have an obviousend to it!

Vol

vo /

Mits

ubis

hi

17

VD

O C

ar C

omm

unic

atio

n

RDS-TMC projects spread

Europe-wide

The political commitment ofEC Directorate DG VII

In summer 1995, the EC Directorate DG VII committed itself to financially supportan 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-TMCimplementation 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-TMCimplementations 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 implementationacross the various service sectors involved have generally been funded withsupport from DG XIII. Cross border infrastructure implementation and commoninterest demonstrators (validation projects) are usually carried out with the supportfrom 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 andimplementation.

Europe-wide projects focus on building European consensus for the provision ofpan-European services and comprise: DEFI (now completed - it sought to define acommon definition of the European RDS-TMC services); ECORTIS which iscoordinating the implementation of RDS-TMC implementations to ensure the pan-European perspective of the national plans is met, and EDEN which deals with theDATEX network required for Traffic Information Centres as the backbone for dataexchange, including cross-border exchange of traffic and travel information forEurope.

The five Euro-regional projects

The five Euro-regional projects now underway focus on cross-border cooperationby 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. Theproject started in autumn 1997. The objective is the improvement of the continuityand quality of traffic management and traffic information services on the maininternational corridors concerned.

CENTRICO - coordinates the implementation plans for traffic management anduser information services, for centrally located countries in Europe: Belgium, andLuxembourg, and parts of France, Germany and The Netherlands; with the UnitedKingdom as an observer. During 1995 and 1996, a common action programme has

EC invests �seed money�in RDS-TMC infrastructure,since 1996

12 EU member statescovered through manyprojects

Cross-border implementationpriority on the TERN

been prepared focussing on monitoring, cross-border traffic management and re-routing, traffic information exchange, coordination of traffic centres, theimplementation of ITS in urban areas, on-trip information through RDS-TMC andinter-operability of automatic toll collection. In 1996 and 1997, the study work wascompleted, and implementation projects will begin in 1998.

CORVETTE - coordinates regional, bi-lateral and multilateral ITS implementationprojects in the Alpine area covering for regions of almost equal size, ie. Austria, partsof Southern Germany (Bavaria), the North-Eastern part of Italy, and Switzerland. Theproject 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 monitoringof service provision conditions, cross-border data exchange, traffic management usingVariable Message Signs, RDS-TMC traffic information services, and automatic tollcollection.

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

VIKING - will coordinate national and bilateral traffic management and ITSimplementation projects in the northern part of Europe: Denmark and parts ofFinland, Northern Germany, Norway and Sweden. The coordination ensurescontinuity and a high quality of ITS services, and gives special attention to intermodalaspects - to support personal travel and freight haulage. The project started in autumn1996: consensus on traffic management on the northern part of the trans-Europeannetwork, definition and harmonization of services, information management and dataexchange, RDS-TMC traffic information services, automatic toll collection anddemand management, and traffic management in urban and peri-urban areas.

Given so many projects, RDS-TMC is being developed in almost every corner ofEurope. 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 beenfocused on. Initially RDS-TMC coverage of the Trans European Road Network isbeing given priority, but some EU member states have only very few roads involved. 18

National RDS-TMCimplementation projectsAustria

A new RDS-TMC pilot project (CORVETTE Phase III) is now planned to start in 1998/99 on four international motorway corridors. The ORF, thepublic broadcaster, is ready to cooperate in the CORVETTE project under the prerequisite that an appropriate contract is agreed with the otherpartners involved. ORF could contribute the editing of traffic information supplied by the Federal Ministry of Science and Transport, and thedistribution and transmission of these TTI data in the RDS-TMC format within the Austrian CORVETTE area (the Inn valley from Kufstein toInnsbruck (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 andoperationally, to provide RDS-TMC on its five networks. VRT coordinates its efforts with the authorities responsible for establishing a new TIC in theFlanders region permitting enhanced traffic data collection and distribution. A better perspective for suitable RDS-TMC receivers to become availableon 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 TICin 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 of1998 on two services: Radio 3 carrying the nationwide coverage and Radio 2 giving a regional service. This will involve implementation of the UECPV5.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 tobegin 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-TMCservices (ALERT Plus focused) started in early 1998 via a number of different transmissions. AdditionallyRadio France is investigating a collaborative project with the DSCR to ensure coverage is given on anational 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 providingRDS-TMC services in time for the IFA in August 1997. By now, almost all of Germany is covered: RadioBremen, Ostdeutscher Rundfunk Brandenburg and Saarländischer Rundfunk are likely to follow beforethe end of 1998. There is increasingly major concern that most of the regional (Länder based) broadcastershave still to care for the coding of the TMC messages by their own editorial TTI-unit on the basis of theirmessages for the spoken service. Road authorities’ TICs are still missing and so is, in many cases, theproper infrastructure and the interfaces required that would be necessary to offer the broadcasters anuninterrupted data chain of coded messages. For example, in the case of Saarländischer Rundfunk, this isthe main obstacle for TMC to be put on air, whereas the inhouse infrastructure to start the TMC operationhas been ready for quite some quite time. Regarding the receiver market, the lack of a competitive varietyof TMC radios at different price levels is a serious threat to development of a German mass market, andthere is still no commitment by most of the car manufacturers to offer TMC receivers at the point of sale,apart from relatively expensive navigation systems with a TMC component.

Italy

RAI, the national public broadcaster, will have a new RDS Server installed in summer 1998 to allow RDS-TMC messages to be sent on a regional basis to the appropriate transmitters and a full regular RDS-TMCservice will be available as from summer 1998 in northern Italy on almost all roads, and in particular all

National implementationsprogress continuously

EC-funded projectssupporting widespreadactions

19

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 ofregional and national TICs operated by five different information providers, the local police (Arma dei Carabinieri), the traffic police, the ItalianAutomobile Club ACI, the motorway operators association AISCAT and the national road administration ANAS. All data-exchange uses the Europeanstandard protocol DATEX. The national Italian plan foresees a continuous extension of this service until full RDS-TMC coverage will be achieved by2002.

DAB services will start to cover 60 % of the population as from 1999. However for continuous area coverage to be obtained with DAB and comparableto 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 toNozema - 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 systemstechnology 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 publicfunding 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 teamincludes 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 capabilityon 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 fromSeptember 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 Swissautomobile association TCS. Software for the generation of RDS-TMC messages has now been installed. As from autumn 1998, RDS-TMC test will startin 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 fromautumn 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 aMemorandum of Understanding, which undertakes to provide an RDS-TMC demonstration service from Summer 1998 covering the major motorwaynetwork of Southern England. The RDS-TMC data will be conveyed via the transmissions of the Classic FM network, which has national coveragepotential. 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 chargeto the end user issue, before the project started. Free-of-charge pan-European services are an essential objective, commonly shared by the publicbroadcasters of the EBU.

Traffic and Travel Information

on the Internet

Example 1:Traffic info from Public broadcasters

These broadcasters compile TTI from a number of different TICs and use specialediting software for presentation of the same information over a variety of bearers:spoken messages, RDS-TMC, DAB, TV, Teletext and Internet. Once a message isedited, it is output after automatic processing in the editing computer on all thesebearers. Each bearer, of course, has of course its own specific presentation formatand the required format adaptation is automatically achieved through the editingcomputer.

Web sites: www.ndr.dewww.mdr.de

www.swr-online.dewww.wdr.de

Example 2:Traffic and much travel support infofrom an automobile club

This site displays the same kind of information as in the previous example. Inaddition, there is a trip planner, hotel finder, and a possibility for online shoppingof 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 ofinnovative data services for Digital Radio DAB are implemented via the MOT(Multimedia Object Transfer) protocol which will now become integral part of theEuropean DAB ETSI standard. The TTI shown by the public broadcaster SWR(formely SDR and SWF) is produced by using the editing process described inexample 1.

Web site: www.swr-online.de

Public broadcasters havealready RDS-TMC coherenttraffic info on the Internet

The display mode chosen topresent traffic info on DABis also on the Internet

Paris is on top of thedevelopment with real-timetraffic info on the Internet

The EC funded SERTI projecthas the most interesting sitefor pre-trip planning

20

Example 4:Traffic info display for Digital Radio

The public broadcaster WDR is testing on DAB, in addition to example 3, anotherdisplay 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) whichinvolves parts of Germany, Italy, France and Spain. The pre-trip information sectionwas previously developed in the EC funded DESPINA project and it is now extendedover the four countries offering a choice of user languages, including English. Incoordination with the public authorities, an information service is being proposed toallow to prepare a holiday itinerary using a frequently updated TTI database. Inaddition the site gives access to spoken regional traffic bulletins and real-time videofrom 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 installedevery 500 to 750 m on 2000 km of all major roads in Paris. The City of Madrid isbuilding a similar system.

Web sites: www.sytadin.tm.frwww.dgt.es

Example 8:City traffic info for Athens

Here one can calculate how far one can travel from the City of Athens’ peripherytowards the city centre under real time traffic conditions.

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

Industry coordination and

Forums

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 draftingthe documents! But once a wider group of users has a need for a standard then, theintentions, not fully or well specified, can be misunderstood or misinterpreted.Furthermore field experience of implementing standards tends to throw up manynew issues.

This is the kind of scenario where industry coordination becomes an importantissue. The system standards once developed, now need system maintenance andusers of that new technology require guidelines for a compatible Europe-wideimplementation. Any field experience can now be shared between the varioussectors involved, which is extremely useful at the stage where implementationguidelines have to be drawn up. Although the projects of the EuropeanCommission have served to achieve similar objectives, users of a given technologysuch as RDS and DAB have found it even more useful to cooperate in specialisedindustry Forums that regularly bring important players together using thatparticular technology. Sharing the experience of deploying a new technology andraising awareness about constraints that one or the other sector does encounter onthe road to full implementation is what has motivated the co-operation in theseForums.

RDS Forum - a world-wide association ofRDS users

The RDS Forum has existed since 1993. Membership is open to all professionalsinvolved in using RDS technology. The RDS Forum has so far held two plenarymeetings per year and a large proportion of the more than 100 members,worldwide attend. The operational expenses of the association are shared amongall those interested to join it. Members pay for each registered representative anannual fee of CHF 1750.- The EBU has so far funded the Secretariat of the RDSForum office.

In 1997, the RDS Forum had four working groups concerned with maintaining andupgrading the RDS standard, developing accepted Guidelines for RDS systemoperation, upgrading the Universal Encoder Communications Protocol UECP toinclude full ODA and RDS-TMC functionality and, RDS/DAB cross-referencing tosupport implementation plans for DAB transmissions with RDS/DAB receiversthat 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 theWorldDAB Forum, which was formed a few years ago, with the support of theEBU, to become the prime focus for all matters associated with the developmentand introduction of Digital Radio. Each registered organization pays an annual feeof CHF 8000.-

Standards can bemis-understood ormis-interpreted

Regular industrycoordination in a Forumavoids implementationproblems

RDS and WordDAB Forumsare based on consensusbuilding

Open Forums provideleadership and maintain astandardized technology withinvolvement from manyindustry sectors

○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○

Digital Radio DAB, using the Eureka 147 system as standardized by ETSI, provides thepotential for audio and multimedia services in a transmission which can bereconfigured 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 dataavailable for RDS-TMC. The potential advantages of the increased data capacity havebeen recognized by the EBU and a Project group is already developing the TPEGprotocol to provide TTI along compatible lines with RDS-TMC, but using extrabandwidth potential to overcome the data compression that RDS-TMC required forthe Event list and Location database.

Web site: www.worlddab.org

A new TMC Forum to secure the future ofRDS-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 June1998 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 wasaimed to become the Club of those members that have signed one or both MoUs insupport of an RDS-TMC service with ALERT functionality. The meeting was hostedby ERTICO and was devoted to discussion and consensus. About 60 differentcompanies and organisations attended.

The consensus ended up remarkably different than intended initially: Having only aclosed shop of MoU signatories was generally rejected. The use of the term ALERTwhich 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 beachieved:

� 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 updatingand exchange of location data bases)

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

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!

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 isgathering pace and will become very widespread in the next few years. (see articles18 and 19) This infrastructure will certainly support the delivery of TTI by othermeans, too. Already the potential impact of the GSM network has been realised andvarious commercial Service Providers are beginning to offer their services, howeversome will be relatively expensive (being call charge based) and their widespreadmarket penetration is not necessarily guaranteed.

Nevertheless, European public broadcasters see TTI as a significant part of theircomplete programme and information services portfolio and they wish to continuein their public service role. Thus we can expect the continuation of Traffic andTravel Information broadcasting via existing delivery mechanisms, such asInternet, In-vision, Spoken services, TV, Teletext, and RDS-TMC. But additionallybroadcasters, and especially those collaborating within the EBU, will develop newservices and new delivery technologies that can provide accurate and timelyinformation about multi-modal events, such as accidents, train cancellations,congestion or roadworks. These services should be available free of charge to thepublic, but it is also recognised that there will be many additional opportunities forpaid-for value-added services, such as information about local hotels, restaurantsor status oriented urban traffic information services. New ways of conveying suchservices are just around the corner, such as Internet (significantly enhancedservices), DAB and DVB. All of these will fit directly into the broadcasters remitand certainly TTI data broadcasting will play a significant role, giving Europewidespread easily accessible services.

TPEG

RDS-TMC is not able to provide multi-modal information and relies on proprietarylocation databases at the receiving terminal creating barriers to a pan-Europeanservice, language-independence and free-to-air provision. Having recognised theneed for future TTI to be bearer independent, the European Broadcasting Union(EBU) has established the Transport Protocol Experts Group (TPEG). This activityhas recognised the benefits and value of RDS-TMC together with its stronglimitations and is developing the TPEG protocol to take the advantages anddevelop a protocol which has far less disadvantages and is fully bearerindependent. 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 ManagementCommittee, is to develop a new protocol for Traffic and Travel Information, for use inthe 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 byagent systems.

TTI is here to stay!

TTI moves into thecompetitive market ledworld

More and more TTIwill be needed

Public broadcastersinfrastructure ideallysuited to future TTI services

22

TPEG will allow a Service Provider to develop a service which can be delivered by oneor more delivery technologies (eg DAB, Internet, Teletext) simultaneously from onemessage generation procedure. Furthermore it will allow a range of receiver types tobe used simultaneously, ranging from a sophisticated agent receiver serving anavigation system through to a very simple receiver (eg a Personal Digital Assistantplug-in card) only able to decode top level information.

In many debates about the future of broadcasting, arguments about the choice ofdelivery technologies threaten to overwhelm the much more important issue ofcontent provision. This also seems to be true in the case of RDS-TMC and DAB. Inpractice, the collection of TTI data and subsequent processing is far more complicatedand expensive than distributing it to the public. In essence, there is no direct conflictbetween the provision of TTI data services on RDS-TMC and on DAB. Theinfrastructure required by broadcasters for handling of RDS-TMC data will also meetthe needs of future services, such as TPEG on DAB.

In addition, experiences gained with operating and provision of RDS-TMC serviceswill surely help launching future transport telematics services including greater valuetransport and travel information services to all travellers.

Long term future

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

Thus a more diverse market for TTI will emerge. Examples will include: one-to-oneinformation, where the Service Provider offers high value personal information,perhaps via a GSM network; high data rate information to update a navigation systemto 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 (egNokia Communicator, Psion Organiser).

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

The mysteries of the market andthe time-scales involved

The three pillars

Digital systems, common standards, open systems, good or excellent technology,none of them of themselves, guarantee success. But success clearly is achievablesometimes. How can we understand the mysteries of the market?

The successful introduction of a new media technology is an edifice like a Greektemple 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 ofwhether we can achieve the system technically. The technology pillar today is oftenthe easiest to build. We are moving from an age when technology fundamentallylimits what media can deliver to a world where the real problem is deciding whatwe want to achieve with the new technology.

The second pillar is infrastructure. Are there sufficient transmitters and receiversgoing to be out there? Do we have the necessary bandwidth or data transmissioncapacity 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, wefind consumers. Will they be able and willing to pay for the new receivers? Will thecost of the new equipment match the perceived added value in the new dataservice?

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) hewants to receive. They must have much more value, and be much more interestingthan the ones he was using before. If they are not, he will not bother to change hisreceiver. Even the most marvellous technology is nothing at all for the publicwithout 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 atwhat price. The content pillar determines if there is sufficient added value in thenew multimedia services content for the system to be attractive and to develop intoan established market.

Looking at the media delivery system successes and failures in Europe over recentyears, wesee how lack of attention, most often to infrastructure or content, has beenthe cause ofsee how lack of attention, most often to infrastructure or content, hasbeen the cause of failure, or very slow roll-out. These two pillars have often not beenthought through fully. There has often been no business plan based on all of thepillars simultaneously.

Technology,infrastructure and contentare linked to the keyof success

RDS came as the silentrevolution

90% of all cars equippedwith RDS will take 20 yearsto achieve

90% of all cars equippedwith RDS-TMC will takeeven longer

Time-scales experienced withnew technologies

It is important to appreciate the long time-scales for implementation of new technologies: Adoption of new broadcastservices 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 yearsto 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 orDAB. This makes it necessary to persuade only a few key players (e.g. car manufacturers and car radio suppliers) and thisshould be much easier than trying to persuade individual members of the general public to discard their existing carradios and to buy new radios with added functionality (e.g. RDS-TMC or DAB). However, the corollary is that carmanufacturers are understandably reluctant to commit to including new technologies as standard features without clearevidence 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 withthe radio, primarily in the mobile reception mode. But only now, in the later phases of RDS implementation comes thetime when listerners at home can enjoy some of the more advanced programme-related features of RDS (eg Radio Textand Programme Type). When RDS development started more than twenty years ago in the EBU, there was anexpectation that eventually all FM radios would be equipped with functionality for RDS. In 1998, this objective has notyet been achieved. Only about 50% of all cars have an RDS car radio (without RDS-TMC). However, 90% of all new carsare 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. Giventhat first RDS radios appeared on the market in 1988, it will have taken 20 years to achieve this. In this context it isworthwhile to note that RDS technology, as developed by the EBU, was well accepted by the consumer electronicsindustry. The RDS specification was published by the EBU in 1984. Through a consensus reached within the EBU, publicbroadcasters in Europe implemented RDS within three years and receiver manufacturers needed four years to roll-outproducts.

The future of RDS-TMC

The future of RDS-TMC is impossible to predict with any certainty, but is probablydescribed 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-TMCservices will need to be maintained for 10-15 years (even if RDS-TMC is not a huge success).

23