Converting Recorded RDS-TMC Services into XML to Simplify Following Quality Assessment

RDS-TMC is a technology for distributing traffic information over the air. Despite its age, its popularity is still growing and is in many countries being freshly implemented. Because the way the information is encoded into RDS data is complex, it is quite difficult to objectively test and evaluate any RDS-TMC service; many times the evaluation simply states “it works” or “it does not work” on some particular device. This paper describes our approach to the conversion of raw RDS data into XML, which is much easier to understand and evaluate. We describe the format of XML and also mention possible technologies and tools which could help evaluating the information stored in these files, like XQuery, BaseX, etc. The described solution was used in real-life tests of three services: country-wide service in Czech Republic, regional service in Prague and pilot testing in Poland.


INTRODUCTION
RDS-TMC is a relatively old technology with limited over the air capacity which is not totally suitable for new navigation devices (Bureš, 2009).It is, however, proven technology and many navigation devices depend on it.Even today RDS-TMC services are being introduced in many countries and it is very likely the number of those countries will grow and the services will last for some years.Therefore it is still meaningful to monitor the end to end quality of RDS-TMC (Bureš & Vlčinský, 2011;Langebaek & Friis, 2008).
The main purpose of this paper is to present the conversion of raw RDS-TMC data into XML and to point out that any further service evaluation is much easier, as well as more flexible.Public traffic information services shall conform to a quality standard; the paper tries to approach the problem in a complex way by setting up the whole recording, processing and presentation chain of a future quality observation service.
1.1 Why to Convert the RDS-TMC Service into XML Form?RDS-TMC technology is quite complex and it is not easy to extract readable information from data conveyed over the service.To understand the content, one must record raw RDS data from the air, stored as RDS groups, decode the TMC related content and finally interpret and evaluate traffic messages.Working with raw RDS data is not easy, as one TMC message can span multiple RDS groups and there are many other types of RDS groups, which are not relevant to TMC.
By converting the raw RDS data into XML, the situation gets much better, even plain XML files can be read by a human reader and primary understanding of the content is thus very quick.There are also many tools which allow the processing and evaluating of XML so getting aggregated information is also possible.Simply stated, translating the content from the exotic and cryptic language (raw RDS) into a very common one (XML) makes evaluation easier.

WHAT IS RDS-TMC?
RDS-TMC is the current system for getting traffic information into navigation systems, where RDS stands for the delivery system and TMC stands for structure of traffic messages.

Radio Data System (RDS)
RDS allows the transmission of digital information over analog (VHF FM) channels.It provides a number of facilities that are of use to all radio listeners, such as providing radio station name to be displayed on the radio display, declaring the current type of programme, indicating traffic news, providing alternative frequencies where is the service available, etc. RDS data are transmitted in the form of a continuous stream of 11.4 RDS groups per second.The standard defines 32 possible group types, where each group type can be used for different purposes.The TMC service uses groups 3A (TMC service information) and 8A (actual traffic messages).

Traffic Message Channel (TMC)
TMC allows the continuous delivery of traffic information suitable for reproduction or display in the language chosen by the user and without interrupting normal audio broadcast services.Received data are typically processed by a navigation system, which then offers the driver a proposal for alternative routes to avoid traffic incidents (Wikipedia, 2011).
TMC defines how to fit traffic information into a standardized container.It introduces set of rules and tables that are together used to encode and to decode traffic information at traffic centers and navigation devices.Each traffic incident is binary-encoded and sent as a TMC message.Each message consists of an event code and a location code in addition to expected incident duration, affected extent and other details.
Event codes and location codes references table items containing more information.These tables, which allow real interpretation of TMC message, are never broadcast over RDS.It is always delivered to the device by other means.Event codes are given by a European standard CEN 14917-2, location tables are country / region specific and are developed and distributed by the information provider concerned according to the European standard CEN 14917-1.The description of a problem location in table 1 is derived from the location table using location, direction and extent codes.Real messages can be as simple as those shown in Table 1, but could get much more complex, using multiple event codes; quantifiers, making the information more specific; defining explicit start and stop time; proposing directions for avoiding the reported problem, etc.

RDS-TMC Transmission
Since RDS data are in reality easily affected by external noise, each 8A RDS group (group containing traffic information) must be received at least twice with the same content to be accepted as correct, so to prevent the reception of mistaken data.Also, to allow tuners to scan other frequencies and services, so called gaps are introduced.The service declares how many non-8A RDS groups are inserted in between two consecutive 8A groups.The tuner can then safely use the time of the gap to scan other frequencies without being in risk of losing an 8A RDS group.

Requirements to the Logical Structure of RDS-TMC
We deal with the problem of how to efficiently evaluate the quality of RDS-TMC.To understand the content, we process raw RDS data and store the results in XML files.The information in XML shall be organized in such a way that it is easily accessible and does not require too much processing.The following list shows the necessary information we have to store in order to understand and to be able to evaluate the quality of RDS-TMC service.
 General information (regardless TMC content); -Station name (i.e.Regina); -Frequency of the station (i.e.-Number of 8A RDS groups forming the message (i.e.groups="3"); -Time of first and last reception (i.e.<T1ST>2012-09-23T01:19:10Z</T1ST>); -Message start and stop time (i.e.<TSTO>2012-09-27T22:00:00Z</TSTO>);  RDS quality information (related to errors in the reception of a signal); -Number of valid, corrected and invalid RDS groups (some bad groups can be repaired (labeled as corrected) which is worth knowing); -Statistics of RDS group types detected and the number of groups received (to find out if the channel is used at its optimal capacity); -Gaps between groups 8A detected and their counts (shall be same as indicated in TMC information groups); -8A groups immediate repetition (for rejection of erroneous TMC messages).
The time period of testing can be sometimes be quite long and it is practical to split the XML data into some reasonable time slots, such as 1, 5 or 15 minute long.To make the processing easier, it is practical to include at the beginning of each XML file all messages which are valid at a given time.In this way, each file is self contained and there is no need to search for valid messages in the preceding files.
The RDS-TMC standard defines a so called virtual terminal as a logical model of a virtual device receiving RDS-TMC information.There are rules on how long the terminal shall keep each received message as valid.XML shall contain a container, called a snapshot, which is able to hold all the valid messages which are in the virtual terminal at the beginning of a given time slot.A snapshot (one record per unique message) contains messages in the same structure as messages received during the time slot (all -not only uniquemessages are in this tag, so if one exact message was received 100 times it will be presented that many times).In order to evaluate the service RDS parameters have to be stored somewhere in the XML file, parameters such as received RDS groups (valid/invalid/corrected), percentage of RDS group types, etc.

Mapping of RDS-TMC Information to XML
Each logical element defined in section 3.1 has to be transformed into a structural element as a part of an XML structured message.RDS standards and TMC standards were formally analyzed for all possible information elements.These elements have then been translated into XML elements and nested in a proper structure.Some of the items in figure 1 are mapped to list items in section 3.1 through sequence numbers of the list items, i.e. (2a) refers to a message identifier, version or number of reception.Some elements in the figure are not mentioned in previous list; an explanation of these is provided (even though it is not necessary, since the figure is in the paper just to prove the necessity of a transposition of a "list of items" to a machine readable code).The resulting XML document has been 1 Asterisk in the image means possibility of repetition of the element in the structure (multiplicity) viewed from the perspective of the user and processing software, this led to a changed structure (Figure 1) and added elements for faster computer processing like element debug_info.Each xml file holds a snapshot of a virtual terminal in the tag <message_snapshot> and a sequence of received TMC messages in the interval of recording (for an explanation see section 3.1) so it can be said that the general container "message information" was split into 2 more concrete ones that allow the recovery of all information from just one xml file, rather than from a collection of successive xml files if a snapshot element was missing.Other elements in the figure are just to give a more detailed view of other self-explanatory necessary elements, like a lite version of a location table.

SETTING UP AN RDS-TMC SERVICE EVALUATION CHAIN
RDS data shall be received, recorded, then converted into XML documents and finally evaluated and possibly presented.These steps may be connected in real-time, or could be evaluated off-line.

RDS-TMC Data Recording -ModulBusRds
We were looking for a device which allows the receiving and providing of RDS data to a PC connected over USB; to allow the PC tune the frequency; and is small and easy to use.Even though RDS is quite an old technology, we had a real problem with finding a suitable solution.

Converting Raw RDS Data to XML Files -TmcCruncher
Output from ModulBusRds can be fed to an application, called TmcCruncher, which is actually creating the XML files described in this paper.All TMC message test than could be handled internally using the XML message as the source document.
The next figure is a print screen of an XML file containing example messages with real values.In this example the following setup was used.Message content presented in message_snapshot element is zero, because the reception has just started.Element message_sequence contains just one multi group message (Figure 3, lines 12-29), which means only two 8A (x2 repetition) groups were received during the whole 60 s measurement period.This is also reflected in the element rds_measurement (Figure 3, line 32).Such an XML file can be used for information about current valid messages (snapshot) and message flow during the measurement period (sequence).The message sequence is vital, because if, for example, some message starts and ceased to exist during one measurement period it will be reflected only in the element message_sequence, since the element message_snapshot contains only a list of messages valid at the start of the measurement period.

Evaluating TMC Content in XML files
Evaluation of a couple of days of raw RDS data, converted into XML files with a time slot of 1, 5 or 15 minutes is a challenge, involving a large quantity of XML files.We use XQuery language that allows such processing in a very effective way.For the processing itself we use an Open Source XML database tool called BaseX (BaseX, 2011), that provides the latest XQuery specification and offers a very comfortable GUI.
For the standard tests a set of XQueries has been developed which can be run after all the XML data are imported into the BaseX database.Therefore, almost a complete evaluation can be performed automatically within a few minutes.
The following table shows the results of such a query performed on a larger volume of XML files with the task to obtain an overview of the evolution of TMC characteristics of received messages, such as locations and events.A description is added to each element after the symbol %. we have a prototype public website where any user with a common web browser can evaluate current data in time and location context with the possibility to do many kinds of data filtering on-line.This is currently a work in progress and can be seen at http://live.rds-tmc.cz.

CONCLUSIONS
The solution for a user friendly presentation of the RDS-TMC service has been developed; the solution consists of the reception of raw RDS data, conversion into XML files, evaluation of almost any aspects using XQuery and XML database BaseX and finally the presentation of results on the web using SIMILE Exhibit.The conversion is the most significant achievement, as it makes the RDS TMC content really tangible, and, at the same time, was the most difficult part of the project.
From the start of the project we have recorded more than a year of continuous reception of two of the most prominent Czech RDS-TMC services (NDIC at 105.00 MHz and TIC Prague at 92.6 MHz).The stored XML files are already being used for a detailed service analysis to uncover the sometimes faulty settings of services and to report this to their providers.
In the near future we plan to fine tune the format of raw RDS data (time in ISO format showing fractions of seconds i.e. 2011-01-03T14:23:25,99Z) and enhance the XML format to also show some subtleties, such as RDS TMC service related changes during the analyzed period.

Figure 1 :
Figure 1: Example mapping of logical structure of RDS-TMC into XML 1 .

Figure 2 :
Figure 2: RDS receiver PC-Radio SI4735 Set and the resulting stream of RDS data.

Figure 3 :
Figure 3: Example of XML message generated from RDS-TMC data.

Table 1 : TMC message structure and its reconstruction according to location table.
message: D1 between exit 11and exit 29 in direction to Brno, congestion for 12 km