Traffic and Travel Information (TTI) broadcasting

Traffic and Travel Information broadcasting history

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

Within the EBU framework, this significant broadcasting sector is supported operationally by daily contacts between EBU members across national boarders, to provide strategic knowledge covering TTI situations in other countries.

TTI coming up-to-date

In the last ten to 12 years, massive amounts of research and development have been funded by the European Commission (EC), within the very wide Intelligent Transport Systems (ITS) budgets, to bring forward many technical solutions for TTI collection (eg road sensors), information interchange (eg DATEX) and dissemination (eg RDS-TMC). However, in the last five years, significant commercial exploitation, using non TTI has a long successful broadcasting delivery (eg GSM phones) has been developed to the extent that TTI - history - before RDS-TMC broadcasting and narrowcasting - now has many new opportunities and threats to consider.

New technologies for TTI European perspective for TTI funded by “Europe” within ITS budgets These developments have led the European Union (EU) to declare its policy for RDS-TMC, as the first priority action for deployment Europe-wide in the next few years (Community Strategy and Framework for the Deployment of Road Transport RDS-TMC is high Telematics in Europe, COM(97)223 final). Over the last two and a half years, the EBU implementation priority for has been working in the EC funded EPISODE Project, which is concerned with Europe monitoring the RDS-TMC final implementation plans. It is providing a “voice” for the broadcast sector in the TTI and Transport worlds, which are dominated by ministries and very large industrial companies who use their lobbying power, Commercial interest in TTI through ERTICO, to influence EC policy-making, and ultimately this reaches the may not be public service European parliament decision-makers. oriented TTI issues are not all straight forward!

Public broadcasters RDS-TMC The EU priority action to deploy RDS-TMC was considered to become an EU services poorly coordinated Directive. This would have imposed the need for broadcasters to implement RDS- TMC, without any possibility of escape! Nevertheless the outcome was a Memorandum of Understanding (MoU) for RDS-TMC services with so-called, ALERT functionality. It appears that this MoU hides the use of the ALERT-Plus protocol for Status oriented messages, as well as the ALERT-C protocol for RDS-TMC Event oriented services (see article 13). Implementation of ALERT-Plus will not be acceptable to public service broadcasters, who cannot release the very large RDS data capacity required for ALERT-Plus.

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

The EPISODE Project

The EPISODE Project, being a inter-disciplinary group, where journalists, programme editors and engineers have worked closely together, has been able to monitor both editorial, end-user and technical issues. As a result, it has issued a number of Project Statements which are on the EPISODE Project web site at URL: www.rds.org.uk/ episode. These Statements were not always welcomed at the time of issue, but later the non-broadcast sectors involed in RDS-TMC implementation have come to realise that the concepts and predictions therein were indeed realistic and valid. Additionally, the EPISODE Project developed the text of an EBU Statement D81-1996 on RDS-TMC, which suggests a positioning in favour of RDS-TMC implementation, but also looks towards the future of DAB.

RDS-TMC implementation steps

Across Europe, many EC-funded Projects are now beginning to set up RDS-TMC deployments, but these are being driven by ministry and government agencies. The Euro-Regional Projects, in particular, are aiming at solving cross border issues. From the broadcasting viewpoint these are not fully coordinated and different models are being used, including some in which the network-capable public service broadcasters are not included. In this context the power of the European member states’ transport “A fifth of driving time ministries to decide on their policies (even potentially to the disadvantage of the is spent getting lost on broadcasters traditional sources of information) must not be underestimated. unfamiliar roads and motorists waste The European trend for separating broadcasters and transmission operators has been a 350,000 tonnes cause for concern within the EBU, because the TTI world does not understand the of fuel going around resulting difficulty that broadcasters face in coordinating on-air information via the in circles” - The various delivery mechanisms in use: Spoken radio announcements, Internet, TV, Automobile Association, Teletext, and RDS-TMC. UK

“European statistics suggest that some 680 million road journeys are made each weekday, lasting an average of 20 minutes. If 10% of the traffic is held up in traffic jams, that represents a total cost of ECU 32 billion per year, not counting heavy-goods traffic! The cost in time lost, owing to traffic problems, is estimated at 0.5% of the European GDP. Public service TTI broadcasting, helping to alleviate these problems, is a far from negligible contribution to the economies of the EU Member States.” 1 TTI in the new competitive environment

The upcoming new scenario for TTI service provision

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

In this particular context, we can note the following trend: traffic information receivers were in the past essentially car radios for which there was a significant after-market, supported by more than 50 different consumer electronic manufacturers, mainly from Europe and Far East, supplying a wide range of products.

Since RDS has been on the market, car manufacturers have tended, more and more, to integrate the car radio in conjunction with multi-functional displays in the dashboard, and these will be increasingly used together with other telematics functionality. Additionally they order OEM equipment, meeting their own interface requirements, which somewhat opposes any standardization of these interfaces.

Most recently, the German mobile telephone provider Mannesmann-Autocom New multimedia technology acquired VDO, a large company that manufactures vehicle instruments and car is developed for GSM dashboards and then, Philips Car Systems, one of the major car radio manufacturers that is also an important supplier of telematic terminals and navigational systems. All this indicates that the after-market for these products may Trend to integrate gradually shrink and that a number of different telematic systems, as accepted by telematics functionality the market, will coexist through telematics equipment that is delivered with the car into the car radio to the end-user.

The possibility to use GSM for Different telematics systems cell data broadcasting will coexist Studies on the use of the GSM mobile telephone system for the provision of two- way communication between information centres and computers on-board Multi-functionality introduced equipped vehicles started in the European Commissions’s DRIVE I (1989-1991) by first installed car radio project SOCRATES (System of Cellular Radio for Traffic Efficiency and Safety). equipment GSM includes the possibility for data communication such as the SMS (Short Message Services) channel that can be used for traffic message services, point-to- TTI is also identified by GSM point and point-to-multipoint (cell broadcast), route guidance and emergency calls. operators as a “killer GSM also provides a full data call functionality that permits implementation of pre- application” and on-trip travel planning and also dynamic route guidance in a navigational system. The widely spread GSM technology is thus, in addition to traditional broadcasting, very suitable for the provision of a large variety of data services of Navigational systems shall interest to mobile road-users, either using the bi-directional communication link or offer Dynamic Route the inherent data cell broadcasting feature. Guidance Integration of Internet and GSM technology has been studied extensively in the EC funded PROMISE project. This project aims at the development of a traffic and travel information service employing a new type of user terminal, the Nokia 9000 Communicator, using the data communication capabilities of the cellular GSM network.

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

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

ERTICO aims at defining a strategy for supporting ITS services via GSM

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

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

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

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

Emergency and Breakdown Services / Assistance and Security Services, • Traffic Information, • Floating Car Data, based on individual measurements of telematics on-board units • within individual cars; this can be seen as traffic monitoring which can be implemented at reasonable infrastructure cost, • Route Guidance, • Fleet management applications, • Information Services to provide the driver with individual information, • Vehicle Theft Detection and Recovery, • Vehicle Remote Diagnostics. GSM coverage is generally continuous and covers most of Europe. It is designed to operate in an urban and inter-urban environment. GSM permits easy implementation of commercial ITS services since the system permits roaming, hand- over, SIM-based authentication. 2 The political environment surrounding RDS-TMC

European Union and ECMT policy

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

should define and establish all necessary institutional • agreements between participating partners (road and traffic authorities, police, broadcasters, motorist clubs, etc.); should use RDS-TMC as suitable way to broadcast traffic • messages to motorists; encourage and support the creation and updating of • location references for their transport network; promote international exchange of traffic messages to • alleviate international traffic; promote the adoption of compatible standards for the • supporting subsystems as far as these are needed to ensure inter-operable sustainable RDS-TMC service.

Lobbying power and Directives

Over the last two and a half years, the EBU has been working in the EC funded EPISODE project, which is concerned with monitoring the RDS-TMC final implementation plans. It is providing a “voice” for the broadcast sector in the TTI and Transport worlds, which are dominated by transport ministries, road ECMT and EU policy makes authorities and very large industrial companies who use their lobbying power, RDS-TMC a priority often through ERTICO, to influence EC policy making, and ultimately this reaches the European Parliament decision makers.

ALERT MoU commits Member The EU priority action to deploy RDS-TMC narrowly missed becoming an EU States to deploy RDS-TMC Directive.

This would have imposed RDS-TMC implementation directly on broadcasters, RDS-TMC receiver without any possibility to escape! Nevertheless the outcome was the ALERT availability - too slow Memorandum of Understanding for RDS-TMC services using the ALERT-C protocol. However, this MoU hides the use of another protocol known as ALERT- Plus which is essentially unacceptable to public service broadcasters because it On-air TTI compatibility - still occupies too much RDS data capacity and if used, would prevent programme- to be solved related RDS features from being fully implemented. EPISODE project Statements

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

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

Euro-Regional Projects - Broadcasters influence

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

3 The public broadcasters role in TTI service provision

Long EBU History in TTI

As part of their public service remit, the members of the EBU have offered TTI services freely to the end-user over many years, according to the technology available. Firstly spoken messages appeared on radio services, followed by the same on TV; then Teletext added another possibility and in-vision text services followed; in German speaking areas ARI was implemented and eventually RDS became widespread with the ability to “flag” traffic announcements, regardless of listening choice, by using the EON feature. Throughout these developments the Broadcasts for Motorists activity has ensured cross border liaison between broadcasters and developed the first Events list (last published in 1990) to facilitate information interchange between broadcasters, prior to scripting a TTI message.

TTI in the context of programmes

There has been a wide variety of TTI broadcasting across Europe, varying from short snappy information spoken by professional presenters to long boring announcements spoken by representatives of the information authority (eg police, rail, and bus operators). Public broadcasters have willingly opened their programmes to TTI, believing that their listening public require information free at the point of use about a wide range of situations, covering all modes of transport. Nevertheless, there has been an emphasis on road information, being by far the most accident prone and most difficult sector to provide information to the traveller in the vehicle.

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

EBU members have a long history of free TTI services Broadcasters want RDS-TMC

It is clear that RDS-TMC will help broadcasters to offer the maximum amount of EBU Events list was information to the end user, but the cost is that a long transition period will be foundation of RDS-TMC needed. Initially very few RDS-TMC receivers will be in use, but gradually as they become more widely available the broadcaster will be able to use the many different media techniques available again in a more effective way. Public Broadcasters need information freely provided

On-air TTI compatibility - a key objective Free information to create public services with on-air consistency

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

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

4 The international bodies involved with TTI matters - ECMT, EC, CEN,

A wide range of international bodies is concerned with harmonization related to the development, standardization and introduction of ITS services in Europe. These include the provision of TTI data broadcast services involving the public and private service sectors. The key players with which the EBU is expected to harmonize its objectives are the following:

ECMT

The European Conference of Ministers of Transport (ECMT) is an intergovernmental organization for Transport Ministers in 38 European countries. ECMT Resolution 26 of 1994 led to the creation of a Working Group on Traffic Management and Road Traffic Information whose task is among others to monitor the implementation of the recommendations on new information technologies approved by the Council of Ministers. These include the implementation of RDS- TMC. The EBU is an invited observers to the meetings held by this Group. The experience gained from collaborating with this Group is that it has a significant impact on guiding the transport authorities with respect to technologies that should be used on a European scale for the exchange and provision of road traffic information with the view to facilitating the flow of traffic throughout the area covered by the ECMT.

European Commission

The European Commission comprises many different Directorates, each with specific sector interests. Each Directorate is divided into Sections concerning ECMT has the highest specific matters and two directorate sections have specific concerns with RDS-TMC political impact technology.

DG VII The EC heavily invests in new technology DG VII - A2 is the Section for Transport, International Relations and Trans European Transport Network and Infrastructures, with concern for pilot projects and implementations associated with RDS-TMC, over the last two or three years The EC heavily invest in and into the near term future. It supports the Euro-Regional Projects which are building harmonized beginning to evaluate the complex institutional cross-border issues interlinked with infrastructures RDS-TMC technology with the objective to be surmounted before a fully effective operational RDS-TMC service can become available to users. In the field of Road Transport, RDS-TMC has long been a goal and it has recently received a strong CEN is a key organization for impetus, being nominated by the European Council of Ministers a priority domain ITS standards for transport development in EU Member States.

DG XIII CENELEC has responsibility for RDS standard DG XIII - C6 is the Section for Telecommunications, Information Market and Exploitation of Research Telematics Applications for Transport and Environment, with concern for many developments associated with RDS-TMC, over the last ten ERTICO lobbies on industry years or so. The projects of the Telematics Application Programme: Transport objectives Sector (part of the 4th Framework Programme 1994 - 1998) are involved in the CENELEC, ERTICO

development, demonstration and validation of enhanced services to transport users. This work, which is coordinated with other initiatives on the Trans European Networks, also consolidates on the results of the previous programmes of Research and Development concentrating on the need of users and the development of inter-operability. In the field of Road Transport, RDS-TMC has long been a goal and funding was secured for the EPISODE Project and the FORCE Project who, among other things, are progressing the standards development in cooperation with the ECORTIS Project which has an emphasis on implementations. The former Projects have cooperated with the standards organization, CEN to finalise the activity of several Working Groups and are now actively involved in disseminating information about the inter-related RDS-TMC standards, for all workers in this field, before they are eventually published.

Comité Européen de Normalisation (CEN)

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

Comité Européen de Normalisation Electrotechnique (CENELEC)

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

European Road Transport Telematic Implementation Coordination Organisation (ERTICO)

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

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

Radio Data System

RDS uses the technique of adding data to a sub-carrier on an existing stereo transmission in such a way that the data is carried inaudibly. RDS is designed with a wide range of features to support programme-related aspects and to allow non- programme-related data services to also be added, if capacity exists. RDS is reported to have reached well over 50 million products in its first ten years, but now it is almost impossible to buy a non RDS car radio in western Europe. Nevertheless for RDS-TMC services it will require a whole new range of RDS-TMC compatible products to be developed and marketed.

RDS tuning features

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

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

Programme Service name (PS) The Programme Service name feature is designed to provide information for an RDS receiver to display the name of the radio programme service, instead of, for example, the tuned frequency being displayed. The PS is formatted for eight character displays using either LARGE or small characters, for example: >Classic_<. The PS name is intended to inform the listener what programme service is being broadcast. The Programme Service name is not intended to be used for automatic search tuning and must not be used for giving sequential information. RDS stands for Radio Data System Traffic Announcements (TA) The Traffic Announcement indicator feature is a two-state flag signal to inform a receiver that there is a Traffic Announcement on air or not. This signalling may RDS has been operational on permit a receiver to: switch automatically from any audio mode to the traffic FM for more than ten years announcement; switch on the traffic announcement automatically when the receiver is in a waiting reception mode and the audio signal is muted; switch from a programme to another one carrying a traffic announcement, according to those Originally developed by the possibilities. EBU - now standardized by CENELEC Traffic Programme (TP) The Traffic Programme indicator feature is a two-state flag signal to inform a receiver that the transmission being received carries Traffic Announcements or not. Now by commercial and The TP flag must only be set high on transmissions which dynamically switch on public broadcasters alike, the TA indicator flag during Traffic Announcements. The TP signal may be used across the world during automatic search tuning. RDS support features

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

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

RDS supports a wide range of programme-related and non-programme-related features, including:

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

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

Prototype BBC home tuner, 1982

Volvo SR 701 the first RDS car radio, 1987

Philips car radio: with PTY - News selection button 6 The RDS-TMC concept

Objective

The objective of RDS-TMC is to broadcast Traffic and Travel Information (TTI) messages as data on FM transmissions using RDS. This allows delivery of accurate, timely, and relevant information without the need to interrupt the radio programme - just the opposite of the common practice today with spoken traffic messages. Thus, TTI can inaudibly be data broadcast in the background of existing FM radio programmes.

Data collection

Data about traffic events are collected in regional and national Traffic Information Centres, with many in the near future interconnected for the exchange of their messages, across the national borders using the DATEX protocol.

Language independence

The messages are digitally coded in such a way that they are language- independent. Standardized event and location code lists are being used to achieve this. The coding also permits users to receive only those messages that are relevant to their needs. Thus it may be possible for a tourist to travel, for example, from London to Rome, through Belgium, Germany, Switzerland, France and Italy, while always getting the traffic announcements via RDS-TMC in his own language, the location codes being on a smart card or CD-ROM that he purchased in London. But for this objective to be really achieved, apart from an agreed set of European The need for TTI increases Standards specifying the system, there is additionally a strong need for a large as traffic volumes increase number of harmonized administrative and institutional agreements still to be coordinated among the countries concerned.

RDS-TMC provides Message filtering language-independent messages The TTI messages that are distributed will, of course, be conveyed to and stored in receiver memory which may subsequently permit traffic announcements to be presented via speech synthesis in the language required. Messages can be filtered Existing RDS receivers cannot on the basis of criteria derived from the needs of the end-user (eg location, direction, be adapted to RDS-TMC route). This filtering thus aims at enabling the user to receive only relevant information, selected from all the messages that are available on an RDS-TMC service, at any given time. RDS-TMC receivers require a double-tuner: one for radio The importance of filtering is demonstrated in this example: given the maximum listening, the other for capacity of RDS-TMC, it will be possible to transmit about 300 different messages in TTI the air at any one time. If the same messages were spoken and each only took 15 seconds, the total announcement time would be 75 minutes. An obvious information overload! In addition, RDS-TMC messages could be used to provide RDS-TMC receivers present assistance for route-planning, use of alternative transport facilities and routes, the user only with relevant continuous up-dating of electronic maps and systems used for navigational aids. messages concerning his journey RDS has a very limited data transmission capacity

The limited data transmission capacity of the RDS system does not generally permit implementation of RDS-TMC on all programme services of the same broadcaster. Therefore, for an RDS-TMC receiver to function correctly as a radio, allowing the end- user to freely choose the radio programme, the RDS-TMC receiver must have a double tuner to permit one tuner to always be used for radio listening and the other tuner be used for RDS-TMC data collection.

7 The RDS-TMC development history

From ARI to RDS-TP/TA

Traffic and Travel Information (TTI) is just one essential component of RDS, which was clearly recognized long before RDS was first standardized in the mid 1980s. By providing the traffic flags TP and TA which, as a concept, were developed for the ARI system in the early 1970s, a basic service for spoken messages is in place thanks to the very strong commitment of many public broadcasters in Europe, coordinated through the EBU’s Broadcasts for Motorists activity.

RDS-TP/TA enhanced through EON

RDS next allowed the use of the EON feature to deploy a service using these flags, but signalled in other radio programme services with vectoring information to enable the listener to hear - when the EON option had been activated in the RDS- EON receiver by the listener -the traffic announcements from any cross-referenced programme. This has by now developed into an option much used to give specifically also traffic announcements about local situations.

RDS-TMC appears on the horizon

RDS-TP/TA was a first step in The possibility of digitally coding traffic information and making it language the 1980s independent within the RDS data stream, was first mentioned by Bosch/Blaupunkt in 1984 at the EBU Eurotravel conference in Grado, Italy. Bosch/Blaupunkt immediately started the technical development in Germany, and Philips in the EON provided a significant Netherlands followed shortly afterwards. One year later, the European Association enhancement of Consumer Electronics Manufacturers, known then as Eurotech (now EACEM) agreed with the EBU that they would then jointly support the development of the RDS-TMC feature, still called at that time CIM (Comprehensive Information for RDS-TMC development Motorists). started mid-1980s European Commission involvement and the ALERT-C protocol 1994 - ECMT recommends RDS-TMC The EBU accepted this proposal and created a group of RDS specialists in which the interested manufacturers participated. In 1986, Bosch/Philips submitted a common proposal which became the basis for further development. Pushed by the ECMT, 1995 - EC chooses RDS-TMC the EC became very interested in the objective to develop an RDS-TMC feature and to become a priority issue it was widely agreed due to the strong lobbying of Bosch/Philips to launch a development project that included already a number of validation field trials in several EU Member States. Subsequently, the RDS-TMC transmission protocol, 1997 - RDS-TMC starts to defined in 1991 in the EC/DRIVE I project as ALERT-C, became the basis for further become an operational development. service

RDS-TMC implementation across the EU continues into the year 2000 Development of a European standard for event codes

An agreed list of event codes was now needed and it was recognized that the EBU had already issued in 1988 such a list which covered seven languages. However, through the EC funded projects, the EBU event list was eventually much extended and harmonized between all sectors interested in RDS-TMC service provision, but without further involvement of the EBU. By now that event code list is standardized by CEN (see article 9).

RDS-TMC becomes a priority issue for the EC

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

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

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

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

8 European Standards for RDS-TMC

Standards Background

The EC funded FORCE/ECORTIS Projects and the EC-funded EBU EPISODE Project have been working for the last three years to complete the RDS-TMC standardization, in collaboration with the RDS Forum and CEN TC 278 Working Group 4. This was necessary to provide a comprehensive platform for a European wide implementation of RDS-TMC. This is sometimes called the ALERT service and has become the subject of the so-called ALERT Memorandum of Understanding (MoU).

Since any ALERT service uses the TMC feature of RDS, conveyed by an RDS sub- carrier added to the baseband multiplex signal of a VHF/FM Band II transmission, it is usual to consider the RDS standard, CENELEC EN 50067:1998, as the core specification. Additionally, a series of CEN pre-standards (including a considerable amount of European industry IPR) are then used to fully specify RDS-TMC functionality which comprises the message protocol, event messages, location referencing, and the newer extension named ALERT-Plus, specified for Status messages.

Specification of the RDS system - the “core” RDS standard (CENELEC EN 50067:1998)

The RDS standard is a truly “open” standard, originally developed by the EBU in the early 1980s, then published as a European standard in 1992. It has recently been updated as a result of successful work by the RDS Forum and CENELEC TC 207.

RDS-TMC standardized by The standard is now available (from CENELEC and the EBU) published as CENELEC and CEN CENELEC EN 50067:1998 and contains several new features including the ODA feature, originally suggested for RDS-TMC purposes; additionally it includes specific references and “hooks” to the RDS-TMC standards in the CEN ENV 12313 EN 50067:1998 - the RDS series. Furthermore RDS Guidelines are being prepared by the RDS Forum and will standard upgraded for be published shortly. Comprehensive information can be obtained from the RDS RDS-TMC Forum web site at URL: www.rds.org.uk/.

ENV 12313 series for Coding Protocol for RDS-TMC TMC - only pre-standards - the “ALERT-C protocol” completed (CEN ENV12313-1)

The coding protocol for RDS-TMC is defined in CEN ENV 12313-1:1998 and is now ENV 12313 series contain IPR available from the CEN Central Secretariat. Therefore this should be taken as the with licencing consequences main standard describing, the so-called, ALERT-C protocol. This standard contains both the protocol and the RDS-TMC related coding which now uses type 1A, 3A and 8A groups (ODA compliant format). It is to be hoped that the FORCE/ ALERT services covered by ECORTIS Projects will publish Guidelines for RDS-TMC shortly. MoU Event and Information codes for TMC - the “Event List” (CEN ENV12313-2)

The Event and Information codes for RDS-TMC, required by the ALERT-C protocol are specified in the CEN ENV12313-2 standard and is now available from the CEN Central Secretariat. This standard uses the so called CEN-English to define a traffic message, eg “stationary traffic for 1km” which is code 102. The meaning of this code has to be defined for each of the European languages and this work was completed in spring 1998. In the example used above, it is interesting to note that the official UK “translation” of code 102 is “stationary traffic for ½ mile”.

Location referencing rules for RDS-TMC (CEN ENV12313-3)

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

European Pre-standards, numbered in the ENV series

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

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

9 The Open Data Applications concept and RDS-TMC

Open Data Application - designed for RDS-TMC RDS standard provides ODA for RDS-TMC

The Open Data Applications (ODA) feature of RDS was developed to allow data ODA registered with EBU applications, not previously specified, to be conveyed in an RDS datastream, with RDS Registrations Office minimal difficulty. The ODA feature, specified in the RDS standard EN 50067:1998, permits a number of pre-determined RDS groups types to be used and these have to be indicated in any RDS transmission using the ODA-Application Identification ODA for ALERT-C (AID) feature, to allow decoders to monitor for them and then decode the relevant data. A wide choice of groups are available for use by ODA data services and these may be selected by a Transmission Operator at his convenience. The service is ODA for ALERT-Plus identified in the associated RDS type 3A groups, in the same RDS datastream. Labelling RDS-TMC services

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

Capacity limitations for RDS-TMC must be observed

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

Reviewing RDS-TMC registrations

These ODA AID allocations are subject to review by the EBU RDS Registrations Office in early 1999, after suitable field implementation experience was gained. 10 The Universal Encoder Communications Protocol and

Existing RDS infrastructures of the nineteen eighties do not support RDS-TMC

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

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

Static versus Dynamic RDS

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

Even Static RDS services may have to be changed from time to time, depending upon the network configuration and the type of radio programme on air.

Dynamic RDS is needed for a number of reasons. RDS data related to the radio programme content requires a high degree of control from the on-air studio. In the case of a data service such as RDS-TMC, a high degree of control is required from the Service Provider to supply their data to the RDS encoder, either to a single broadcast transmitter or to a network of broadcast transmitters.

Once a Dynamic RDS encoder has been chosen, then in most situations, a uni- directional data link has only been possible for update-data to be sent to the RDS encoder. This is due to the fact that for economic reasons the Transmission Operator had to adapt existing analogue, or even digital, audio distribution networks which Initial RDS infrastructures are essentially uni-directional, to add a data distribution function. need to upgraded for RDS- TMC Proprietary communication protocols versus the open UECP

The UECP is a de facto A number of proprietary RDS encoder update protocols were initially implemented industry standard for RDS on data links between source RDS data servers and the RDS encoders; several of encoders them were encoder manufacturer specific. These protocols were used to send data messages from an RDS controller/management system (or simply an RDS encoder server) to the RDS encoders. Acknowledgements from the encoder were not Permits networked operation essential and, instead, it was arranged to send repeats of each message in order to of RDS encoders from various ensure their receipt. In this way a whole range of Dynamic RDS features could be suppliers used by the broadcaster to enhance RDS performance for the listener. In some cases an RDS encoder controller, running on a PC, has been used to send update messages to the RDS encoder, or if a very full implementation is required, then a Supports latest version of the dedicated RDS management computer system, frequently called an RDS Server, RDS-TMC standards has be used to control, on a scheduled basis, the whole range of RDS features, RDS-TMC

including the radio programme related RDS features and the full array of EON reference data.

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

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

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

EBU developed with the UECP a de facto industry standard

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

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

11 Principles of RDS-TMC Location reference coding

Messages referring to locations require in RDS-TMC a Location reference code

Most RDS-TMC messages provide information about a location (e.g. a stretch of road, an intersection, a region) and they refer to it by using a location reference. This is an identifier that can be interpreted without ambiguity by the receiving system. In RDS-TMC, locations are pre-defined and pre-coded, and the codes are stored in location code tables. The maximum number of codes in one table is determined by the field length for location codes in RDS-TMC, i.e. 16 bit which corresponds to 65,536 possible codes.

An obvious disadvantage is the maintenance required

The disadvantage of these tables is that they need to be created and maintained (see article 16). The receiving system must use exactly the same Location code table as the one used for encoding of the message. Otherwise the message is not receivable.

The rules for location reference coding are specified in CEN pre-standard ENV 12313-3 (see article 9). These rules apply to ALERT-C messages only.

ALERT-Plus uses a different system. Because of the provisional nature of ALERT- Plus, no further reference is made to that particular coding method and all details that follow are extracted from the pre-standard and apply thus to ALERT-C messages only.

Principles of arranging the location codes within tables

For RDS-TMC message Pre-defined locations are referenced by their location code which is the tabular encoding and decoding address of a number of pre-stored location details. Each table of stored locations the same code table is must be given a unique location table number by one unique agency in each country mandatory or state. A country code (note: RDS-TMC uses the RDS country codes) identifies the agency responsible for location reference coding and which defined the location table and its number. Location code tables need to be created specifically for RDS-TMC The concept of primary and secondary locations

Location code tables require Many location references extend through several adjacent areas or road sections. maintenance The concept of primary and secondary locations is then used to indicate the extremities of the affected sections, without having to list all the intervening places. For example, if an accident occurs at “km 14.2” on the E15 (A26 road in France) and ALERT-C and ALERT-Plus use the resulting queue extends back to “km 10.9", the situation location can be defined different location code tables as E15, “km 14.2 - 10.9”. Where “km 14.2” is defined as the primary location and “km 10.9” is then the secondary location. The primary location is taken to be where the cause of the problem can be found, whenever a cause can be pin-pointed geographically. However, both, primary and secondary location shall lie on the same road.

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

The EUROAD concept

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

The hierarchical structure of the location code tables

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

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

What is a Direction and an Extent code in RDS-TMC?

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

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

Message phrases encoded for transmission

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

Event list with 31 update classes

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

1375 Event phrases coded Event list translations

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

ALERT-C delivers Event Constraints created by the messages limited RDS capacity

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

Definitions of Event and Status

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

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

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

ALERT-C Event messages and ALERT-Plus Status messages

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

13 Message generation and infrastructure for RDS-TMC

TTI Messages - where do they start?

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

TTI Message interchange via DATEX-Net

Many Traffic Information Centres (TIC) throughout Europe are beginning to implement the DATEX-Net specification for information interchange. This is a powerful set of tools enabling automatic information exchange between TICs and other interested parties. The DATEX-Net protocol uses a Data Dictionary, data models, Location referencing and Message exchange formats which were developed to a relatively mature stage by 1996. Subsequently the EDEN Project has built a consensus about using these tools and developed the European DATEX Memorandum of Understanding, which seeks to involve all 15 EU member states, Norway and Switzerland in agreed methods of interchanging TTI.

TTI Service Provider roles TTI Messages - expanding information to process DATEX-Net can be usefully employed by RDS-TMC Service Providers to obtain information from local, national or foreign TICs, according to their service needs. But these messages will, in essence, be about situations with traffic management DATEX MoU - agreements emphasis and need to be enhanced with other information before an end-user about TTI interchange message can be compiled. Many sources of information are used by an RDS-TMC Service Provider to compile a service for the end-user, including Floating Car Data, telephone calls, staff reporters etc. All this information needs to be gathered and TTI Service Providers - collated in a database, to facilitate a suitable picture for the operational staff to make compile data into a useable sense of the situation before compiling a TTI Message. end-user product A Service Provider also has the responsibility of marketing his service to the end- user, whether it is a free or paid-for service. This requires extensive subscriber On-air broadcasts require management and, in the case of RDS-TMC, Location database management and compatibility with existing distribution. (see articles 12 and 15). infrastructures

TTI services using a variety of outputs require to be coherent RDS-TMC Message Generation

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

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

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

14 Smart-cards and payment for RDS-TMC

Smart-cards -why does RDS-TMC need them?

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

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

Distribution of the database

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

Location database is the key to decoding Location database influences RDS-TMC messages In any RDS-TMC system it is necessary for the same Location database information to be used at all Traffic Information Centres (TICs), by all Service Providers and by Smart-cards or CD-ROMs all devices which receive information from those sources. Such a system is depicted carry Location information in the figure opposite. It introduces the role of a Card Provider, translating the available database to a physical and marketable form. If any of the system elements has a database which differs from the others, then performance will be less than Smart-cards - help pan- optimal. For example, if an RDS-TMC receiver were to have an old database, European services develop missing new Location codes, then messages relating to these locations cannot be received and presented to the driver. Such omission may be regarded as simply unfortunate, but could have major safety implications. Periodic Smart-card replacement for revenue and quality reasons Location database ownership

Within the system described above there can only be one database per area/country or per Service Provider, and all system elements (TIC, Service Provider, Card Provider and end-user) must derive their individual databases from this one source. It is, however, quite possible for Service Providers, Card Providers and Receiver Manufacturers to operate competitively. Each database will need to be maintained, and such maintenance should be conducted at periodic and defined dates, to enable all system components to operate with a common, and latest version. This means that cards produced for receivers will need to have an expiry date.

Smart-card sales

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

Smart-cards and CD-ROMs

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

15 Multimedia and the Human Machine Interface in the vehicle Multimedia in the vehicle - is it safe?

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

RDS-TMC - is it multimedia?

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

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

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

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

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

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

HMI standardization for in-vehicle information

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

Design and location of information systems for • compatibility with the driving task

Presentation of information, not impairing driver’s visual • allocation to road scene

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

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

16 RDS-TMC receiver issues

The Vision for RDS-TMC receivers

The developers of RDS-TMC started to think about their vision before the EC came along to fund the many research projects that have worked on related infrastructure and RDS-TMC specifications over the last ten or 12 years. The original idea can be summed up, as very close to: “an RDS-TMC receiver would be able to intervene in the drivers normal choice of radio listening with relevant (filtered for that journey) and timely (no need to await a suitable programme slot to voice an announcement) voice synthesized information, in his own language. The RDS-TMC service should be free of charge to the end-user, except for the need to purchase a new RDS-TMC receiver at a reasonable to low cost, and the need perhaps to buy an update of the location database, occasionally.” This suggests a number of principles which can today be seen embodied in the various RDS and RDS-TMC standards (see article 9).

Listening choice should not be impaired Message filtering Own language information presentation

Since then, a European dimension has been added, with the pan-European service element, to allow a driver to obtain information as the vehicle traverses national borders. Additionally, because of the long development cycle, the significance that TTI has for updating navigation systems and the perceived higher value of these products has made RDS-TMC a killer application for navigation systems in the near term. Even allowing for the long development time, the end user has become more sophisticated in expectation, and the development of voice synthesis technology has not been able, to achieve the expectations at a low enough price. So solutions have been sought which will still reach acceptable end user appeal.

Thus the focus for RDS-TMC products has drifted away from the lower-priced market to the much higher-priced market, before simple RDS-TMC receivers could RDS-TMC should not detract be delivered to the European consumer. to the listening experience

Introducing first generation RDS-TMC RDS-TMC information in own receivers “spoken” language still not readily available Perhaps inevitably as the technology for RDS-TMC was developed, it became clear that some elements were a little too revolutionary and solutions had to be found that would use technology of today for the solution, knowing that by tomorrow the RDS-TMC is strongly trended price would fit the product price profile required. The most obvious example of towards costly navigation this is the smart-card used to carry the Location database which is needed to systems decrypt the location information carried in every RDS-TMC ALERT-C message (see article 12). The problem now is that this technology is already in doubt for two reasons: firstly the intellectual property rights (IPR) situation relative to the many There is little scope for a patents registered by Bosch/Philips is seen as a barrier to introduction, and the medium-priced car radio potentially cheaper CD-ROM technology has become acceptable in navigation with full RDS-TMC systems. The institutional challenges to introducing either are much the same, but functionality do not appear to be diminishing at a fast rate and still appear to be one of the big obstacles to wide user acceptance of RDS-TMC, because the Service Providers are not yet fully active in trying to overcome these challenges.

The reality of RDS-TMC receivers today

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

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

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

The political commitment of EC Directorate DG VII

In summer 1995, the EC Directorate DG VII committed itself to financially support an action plan covering the years 1995-99 that would stimulate - with “seed money” - the introduction of RDS-TMC. Since 1996, DG VII has funded several RDS-TMC implementation initiatives and among them two European projects (FORCE/ ECORTIS and EDEN) and several Euro-regional (VIKING, CENTRICO, CORVETTE, SERTI and ARTS), as well as national projects that altogether involve: Belgium, Denmark, Finland, France, Germany, Italy, the Netherlands, Portugal, Spain, and the United Kingdom. This has led to many regional RDS-TMC implementations on important sections of the Trans European Road Network (TERN), concerning the main trunk roads in the European Union.

The research projects and support activities leading to RDS-TMC implementation across the various service sectors involved have generally been funded with support from DG XIII. Cross border infrastructure implementation and common interest demonstrators (validation projects) are usually carried out with the support from DG VII, in line with the Trans-European Network for Transport (TEN-T) guidelines, and the corresponding budget has so far (up to the end of 1998) contributed some ECU 79 million for RDS-TMC infrastructure development and implementation.

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

The five Euro-regional projects

The five Euro-regional projects now underway focus on cross-border cooperation by implementing continuous and interoperable services in neighbouring trans- EC invests “seed money” border areas: in RDS-TMC infrastructure, since 1996 ARTS - coordinates regional and national ITS implementation projects with RDS- TMC in the South-West of Europe, linking parts of Portugal, Spain, and France. The project started in autumn 1997. The objective is the improvement of the continuity 12 EU member states and quality of traffic management and traffic information services on the main covered through many international corridors concerned. projects CENTRICO - coordinates the implementation plans for traffic management and user information services, for centrally located countries in Europe: Belgium, and Cross-border implementation Luxembourg, and parts of France, Germany and The Netherlands; with the United priority on the TERN Kingdom as an observer. During 1995 and 1996, a common action programme has been prepared focussing on monitoring, cross-border traffic management and re- routing, traffic information exchange, coordination of traffic centres, the implementation of ITS in urban areas, on-trip information through RDS-TMC and inter-operability of automatic toll collection. In 1996 and 1997, the study work was completed, and implementation projects will begin in 1998.

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

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

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

Given so many projects, RDS-TMC is being developed in almost every corner of Europe. However, the complex detail of these projects cannot be fully covered here: only the broadcast sector activity in the context of RDS-TMC implementation has been focused on. Initially RDS-TMC coverage of the Trans European Road Network is being given priority, but some EU member states have only very few roads involved. 18 National RDS-TMC implementation projects

Austria

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The BBC - the national public service broadcaster - decided not to join this consortium, because the UK government could not resolve the free of charge to the end user issue, before the project started. Free-of-charge pan-European services are an essential objective, commonly shared by the public broadcasters of the EBU. 19 Traffic and Travel Information on the Internet

Example 1: Traffic info from Public broadcasters

These broadcasters compile TTI from a number of different TICs and use special editing software for presentation of the same information over a variety of bearers: spoken messages, RDS-TMC, DAB, TV, Teletext and Internet. Once a message is edited, it is output after automatic processing in the editing computer on all these bearers. Each bearer, of course, has of course its own specific presentation format and the required format adaptation is automatically achieved through the editing computer. Web sites: www.ndr.de www.mdr.de www.swr-online.de www.wdr.de

Example 2: Traffic and much travel support info from an automobile club

This site displays the same kind of information as in the previous example. In addition, there is a trip planner, hotel finder, and a possibility for online shopping of travel guides and maps. Web site: www.rac.co.uk

Example 3: Road map with traffic info for Digital Radio Public broadcasters have already RDS-TMC coherent There is a field trial in the south-western part of Germany where a number of traffic info on the Internet innovative data services for Digital Radio DAB are implemented via the MOT (Multimedia Object Transfer) protocol which will now become integral part of the European DAB ETSI standard. The TTI shown by the public broadcaster SWR The display mode chosen to (formely SDR and SWF) is produced by using the editing process described in present traffic info on DAB example 1. is also on the Internet Web site: www.swr-online.de

Paris is on top of the development with real-time traffic info on the Internet

The EC funded SERTI project has the most interesting site for pre-trip planning Example 4: Traffic info display for Digital Radio

The public broadcaster WDR is testing on DAB, in addition to example 3, another display format as shown. Web site: www.wdr.de

Example 5: Road map traffic info from a road authority

Web site: www.roaddirectorate.dk

Example 6: SERTI - The best site on pre-trip information

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

Example 7: Real-time metropolitan area traffic info

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

Example 8: City traffic info for Athens

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

Web site: http://frida.transport.civil.ntua.gr/map/ 20 Industry coordination and

Forums ○○○○○○○○○○○○○○○○○

Whilst successful standards are in use by the few people who helped develop them, then all is likely to be well, because they know what they intended when drafting the documents! But once a wider group of users has a need for a standard then, the intentions, not fully or well specified, can be misunderstood or misinterpreted. Furthermore field experience of implementing standards tends to throw up many new issues.

This is the kind of scenario where industry coordination becomes an important issue. The system standards once developed, now need system maintenance and users of that new technology require guidelines for a compatible Europe-wide implementation. Any field experience can now be shared between the various sectors involved, which is extremely useful at the stage where implementation guidelines have to be drawn up. Although the projects of the European Commission have served to achieve similar objectives, users of a given technology such as RDS and DAB have found it even more useful to cooperate in specialised industry Forums that regularly bring important players together using that particular technology. Sharing the experience of deploying a new technology and raising awareness about constraints that one or the other sector does encounter on the road to full implementation is what has motivated the co-operation in these Forums.

RDS Forum - a world-wide association of RDS users

The RDS Forum has existed since 1993. Membership is open to all professionals involved in using RDS technology. The RDS Forum has so far held two plenary meetings per year and a large proportion of the more than 100 members, Standards can be worldwide attend. The operational expenses of the association are shared among mis-understood or all those interested to join it. Members pay for each registered representative an mis-interpreted annual fee of CHF 1750.- The EBU has so far funded the Secretariat of the RDS Forum office.

Regular industry In 1997, the RDS Forum had four working groups concerned with maintaining and coordination in a Forum upgrading the RDS standard, developing accepted Guidelines for RDS system avoids implementation operation, upgrading the Universal Encoder Communications Protocol UECP to problems include full ODA and RDS-TMC functionality and, RDS/DAB cross-referencing to support implementation plans for DAB transmissions with RDS/DAB receivers that offer a compatible user interface. RDS and WordDAB Forums are based on consensus Web site : www.rds.org.uk/ building WorldDAB Forum

Open Forums provide Another forum with potential significance in the field of TTI broadcasting is the leadership and maintain a WorldDAB Forum, which was formed a few years ago, with the support of the standardized technology with EBU, to become the prime focus for all matters associated with the development involvement from many and introduction of Digital Radio. Each registered organization pays an annual fee industry sectors of CHF 8000.- ○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○

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

A new TMC Forum to secure the future of RDS-TMC

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

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

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

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

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

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

Web site: www.alert-tmc.com ○○○○○○○○○○○○○○○○○○○○○○○○○○○

○○○○○○○○○○ 21 Future prospects of TTI

TTI is here to stay!

Given the strong political drive for the development of TTI delivered through RDS- TMC, to a very large number of users in Europe, the infrastructure to support this is gathering pace and will become very widespread in the next few years. (see articles 18 and 19) This infrastructure will certainly support the delivery of TTI by other means, too. Already the potential impact of the GSM network has been realised and various commercial Service Providers are beginning to offer their services, however some will be relatively expensive (being call charge based) and their widespread market penetration is not necessarily guaranteed.

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

TPEG

RDS-TMC is not able to provide multi-modal information and relies on proprietary location databases at the receiving terminal creating barriers to a pan-European service, language-independence and free-to-air provision. Having recognised the TTI is here to stay! need for future TTI to be bearer independent, the European Broadcasting Union (EBU) has established the Transport Protocol Experts Group (TPEG). This activity has recognised the benefits and value of RDS-TMC together with its strong TTI moves into the limitations and is developing the TPEG protocol to take the advantages and competitive market led develop a protocol which has far less disadvantages and is fully bearer world independent. TPEG is firmly aimed at the multimedia broadcasting environment.

The TPEG Mission Statement reads: More and more TTI will be needed The work of B/TPEG, commissioned by the EBU’s Broadcast Management Committee, is to develop a new protocol for Traffic and Travel Information, for use in the multimedia broadcasting environment. B/TPEG will develop applications, Public broadcasters service and transport features which will enable travel related messages to be coded, infrastructure ideally decoded, filtered and understood both by humans (audibly and/or visually) and by suited to future TTI services agent systems. TPEG will allow a Service Provider to develop a service which can be delivered by one or more delivery technologies (eg DAB, Internet, Teletext) simultaneously from one message generation procedure. Furthermore it will allow a range of receiver types to be used simultaneously, ranging from a sophisticated agent receiver serving a navigation system through to a very simple receiver (eg a Personal Digital Assistant plug-in card) only able to decode top level information.

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

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

Long term future

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

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

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

22 The mysteries of the market and the time-scales involved

The three pillars

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

The successful introduction of a new media technology is an edifice like a Greek temple resting on three pillars: technology, infrastructure, and content.

All three need to be in place or the introduction will fail.

The technology pillar comes from research and development. It determines of whether we can achieve the system technically. The technology pillar today is often the easiest to build. We are moving from an age when technology fundamentally limits what media can deliver to a world where the real problem is deciding what we want to achieve with the new technology.

The second pillar is infrastructure. Are there sufficient transmitters and receivers going to be out there? Do we have the necessary bandwidth or data transmission capacity to broadcast the new data service? Shall we have - and from where - sufficient income to cover the infrastructure costs? At the other end of the chain, we find consumers. Will they be able and willing to pay for the new receivers? Will the cost of the new equipment match the perceived added value in the new data service?

The third pillar is content itself. In the end, the consumer does not buy hardware; he buys the programmes and multimedia services (programme-related or not) he wants to receive. They must have much more value, and be much more interesting than the ones he was using before. If they are not, he will not bother to change his receiver. Even the most marvellous technology is nothing at all for the public Technology, without creative new content. This is the factor most affecting success or failure. infrastructure and content are linked to the key As we have seen, the technology pillar determines whether the system can be made. of success The infrastructure pillar determines whether the system can be delivered, and at what price. The content pillar determines if there is sufficient added value in the new multimedia services content for the system to be attractive and to develop into RDS came as the silent an established market. revolution Looking at the media delivery system successes and failures in Europe over recent years, wesee how lack of attention, most often to infrastructure or content, has been 90% of all cars equipped the cause ofsee how lack of attention, most often to infrastructure or content, has with RDS will take 20 years been the cause of failure, or very slow roll-out. These two pillars have often not been to achieve thought through fully. There has often been no business plan based on all of the pillars simultaneously.

90% of all cars equipped with RDS-TMC will take even longer Time-scales experienced with new technologies

It is important to appreciate the long time-scales for implementation of new technologies: Adoption of new broadcast services can be very slow when new receivers are required as in the case of RDS-TMC.

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

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

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

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

The future of RDS-TMC

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

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

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

23