EPISODE

2.7.2 Statement No 2, dated 10th April 1996

A statement from the EPISODE Project Management Committee
regarding RDS-TMC implementation issues

1. Transmission standardisation

The RDS system has been developed within the EBU, and the specification was first published in 1984. Since then it has become a European Standard (CENELEC EN 50067) of which two versions have been produced so far: the original 1990 standard and an enhanced version of 1992. At present there is a further enhancement under way which will be submitted this Summer for approval by CENELEC (prEN 50067:1996) and which is already available as a final draft from the EBU.

The RDS standard has been successfully implemented by almost all manufacturers of Consumer Electronics and according to our knowledge some 35 million receivers have been produced so far. Most of these are car radios distributed on the European market.

RDS-TMC has been developed within the 2nd and 3rd Framework RTD programmes of Transport Telematics (DG XIII). The standardisation aspects are handled in CEN TC 278; this Committee established a prENV (Draft standard) on an RDS-TMC transmission protocol called ALERT C and to which is attached an event list. For these elements there already exists a broad consensus. Location coding rules have also been specified.

As a result of the 3rd Framework RTD programme three vital issues regarding RDS-TMC were identified as requiring further work and appropriate standardisation before large scale implementation. These were:

management and deployment of the location databases;

a "networking layer" for RDS-TMC to facilitate the continuous reception of TMC from a diversity of transmitters and broadcasters over large areas; and

development of a "service id" permitting a wide range of service providers to offer complementary and competing services, and permitting the motorist to drive across Europe with continuous TMC services.

The work required to develop these additional layers was specifically planned into the 4th Framework activities and is identifiable as a work package in the FORCE project, for example.

Such work has to be carried out involving all the sectors with a view to achieve again abroad consensus. In particular the specialists for coding this into the RDS system must be involved. These experts have supported the development of the CENELEC standard and can be found in the RDS Forum which is an association of the RDS industry, broadcasters and service providers. This association is co-ordinated through the EBU.

The time frame for completing such a task could be relatively short, and it could match the time scale already established for upgrading the RDS standard (Summer 1996).

It is undesirable that the manufacturers wishing to implement RDS-TMC within a short time impose de facto implementations that jeopardise the future evolution of RDS and TMC, disregarding the flexibility now built into the RDS standard.

2. Receiver implementation

Up to this stage the feasibility of RDS-TMC was demonstrated in a large number of field trials all over Europe. Prototype RDS-TMC receivers were built in small quantities (several hundreds of units). Mass manufacturing has not been possible because no standard has been agreed. The technology required to produce such receivers at an acceptable price for end users has been developed by two major European manufacturers.

It should however be noted that none of the existing RDS receivers can be modified to receive RDS-TMC and end users will thus have to replace, even new RDS models, to have receivers with RDS-TMC capability. Such receivers are in the final design stage for mass production, but the manufacturing is deliberately delayed because the standardisation process of the transmission system has not yet come to an end. One special issue to be noted in an RDS-TMC receiver is that it requires an interface for a smart card carrying the location database.

3. Location databases/Smart cards

Location databases have been developed so far within many EU member states interested in RDS-TMC implementation. In almost all cases public funds have been used to develop these databases and their management software. Up to this stage, these databases are not generally available and no mechanism has been agreed as to how they could be distributed to end users of RDS-TMC. Much discussion in this context addressed the need for a Smart Card solution: the objective being general availability for European citizens at a reasonably low price with a reasonably high storage capacity that avoids end-users to require too many cards. Regular updates should be made available (perhaps annually) to assure full access to Traffic and Travel Information via RDS-TMC all across Europe. The minimum expectation for such a service is the full implementation of the ALERT C specification making all messages possible under the system that would then become freely available to the end-users. Any receiver constraints (e.g. use of small storage capacity smart cards) that compromise access to all messages/locations would be unacceptable to users and system operators.

There appear to still be conflicting proposals for types of Smart Cards to be used, and the interface with the RDS-TMC receiver is therefore still not specified. However some manufacturers would like to implement their own solution creating a de facto standard which would give them an economical advantage and seriously hamper consensus building in this area.

4. Impact of DAB

Some experts tend to judge that RDS-TMC is a technology that will soon be replaced by DAB. While this view may be correct in the long term (well beyond the year 2000), in the short to medium term they are overlooking the fact that no standard exists for DAB-TMC. Neither has there been any standardisation work done on a international level, nor has there been any field trials organised within the past and present framework RTD programmes. Therefore it is certainly necessary to support the development of DAB-TMC, but one should not wait for the development to end before implementing RDS-TMC. The traffic situation in Europe will not allow any delay for DAB delivery of traffic messages; they are needed now and we can learn from implementing RDS-TMC immediately. The know-how learnt can then be easily put into DAB-TMC, when that day comes. Thus RDS-TMC has its time now and for many years to come.

5. Broadcast infrastructure

Broadcasters have considerable operational practice in providing Travel and Traffic Information on both, radio and television. Their traffic and travel units collaborate with a number of information providers (police, road authorities, automobile associations and others) and apply skilled editorial responsibility to the transmitted output. The end users are accustomed to the style and content provided and expect a high quality of information content. This is the challenge to the public broadcasters.

As far as RDS-TMC is concerned the public broadcasters show some reluctance to introduce this for a number of reasons:

Insufficient existing infrastructures to distribute and manage traffic and travel information in TMC coded format involving all information providers concerned;
lack of comprehensive transmission standard for RDS-TMC, carrying the risk of overloading their RDS channel;
RDS-TMC receiver implementation is uncertain regarding user interface and free choice of radio listening;
the user interface being undefined, means that payment for the broadcast sector services is still unclear;
RDS-TMC receiver design is still unclear in its ability to present both RDS-TMC messages and normal radio listening.

6. System implementation issues

The public broadcast sector is concerned about how RDS-TMC implementation will affect the end users, their radio listeners. The quality of traffic information that listeners would expect from a new RDS-TMC service must at least equal the present spoken services and include more detail, perhaps with improved timeliness. To achieve this, road authorities need to provide improved traffic information gathering, using telematic solutions. While these exist in some test areas the investment to provide this all over Europe requires many more years work and considerable funds.

Although we have heard about solutions such as EDIFACT for communications between Traffic Information Centres (TICs) and the broadcasters, this whole area has had little evaluation up to now, and the broadcast sector expects that there will be a need to continue extensive development throughout Europe. The existing infrastructures for providing traffic and travel information will require different solutions to be adopted in different countries. There will be significant work required by the broadcasters to work with the TICs, and for them to develop operational interfaces and working methods.

Many broadcasters have, so far, only limited operational practice in providing dynamic data services on RDS, in most cases due to lack of data circuits from their studios to their transmitter networks.

While being aware that other sectors wish to implement RDS-TMC as from 1996, the broadcast sector believes this is too early because of the many implementation deficiencies identified here.

Payment mechanisms need to be established by the EU member states that would secure the system operation with all sectors involved being able to obtain a fair share of the funds that could be raised (e.g. via the fee collected for a smart card with limited validity).

Any further development of RDS-TMC ALERT Plus should only be undertaken if there exists some consensus about what is technically feasible with the RDS technology now available. Its evolution within a relatively short time-frame may now use the Open Data Application method of RDS. Otherwise, further development efforts may be better put into DAB-TMC.

Issue date January 03, 2000
Copyright © 1996, 1997, 1998 EBU. All rights reserved.