TPEG

The Transport Protocol Experts Group ( TPEG ) is a group of experts, established in 1997 within the European Broadcasting Union (EBU / EBU). It developed with support from the European Commission the same open international standard for the transmission of language-independent and multi-modal traffic and travel information. By building on the experience of RDS -TMC TPEG information on the one hand be processed by machines and on the other hand prepared so that they are easily understood by people.

• 2.1 Structure of an RTM message ( cf. [ TPEG4 ] ) 2.1.1 Message Management Container
• 2.1.2 Event Description Container
• 2.1.3 TPEG -Location Container

Design criteria

Usability in public as well as in road traffic

TPEG has been designed so that it can be used both for public transport and road safety. For this reason, first a basic structure was designed to build on the then two profiles for road and public transport:

• TPEG -RTM: Road Traffic Message application
• TPEG - PTI: Public Transport Information

The distinction between road and public transport is because in the first place, that it is a line network is the public transport, in which the individual routes each have a specific start and end points does not change the course of a route during a trip usually will. [ TPEG5 ]

In road traffic, on the other hand, the driver can change the route at any time and react directly to the current situation. The information to be transmitted therefore differ depending on the system. Users of public transport need information such as delays, cancellation of compounds or special deliveries can be provided.

The information needed by car and truck drivers, however, have an impact on the route chosen by the driver and also on safety. Road users in the road network obtained via TPEG -RTM news on accidents, traffic jams, road or weather conditions such as ice or fog. [ TPEG4 ], [ TPEG5 ] The division of the TPEG system allows the implementation effort for the manufacturer of transmitters and receivers to mitigate, if they implement on their devices, only one of the two profiles. At the same time this leads to smaller data structures.

On the other hand, the basic structure of the two systems is the same. So both use the same Ortsreferenzierungssystem reach the language independence with the help of translation tables and use the same transmission system. For this reason, only TPEG -RTM is exemplarily described in more detail in this article.

The following ( more ) TPEG applications are common or currently in development:

• RTM - Road Traffic Messages
• TEC - Traffic Event Compact
• TFP - Traffic Flow Prediction
• PTI - Public Transport Information
• PKI - Parking Information
• SPI - Speed ​​Limit Information
• BSI - Bus Service Information
• WEA - Weather
• POI - Points of Interest
• CTT - Congestion and Travel Time

Language Independence

A traffic information system should be able to present the required information in the language of the user.

TPEG allows these multilingualism by using extensible translation tables. To this end, words of similar meaning, are needed more often in TPEG messages, summarized in tables. These words can be referenced in a TPEG message via a number. In a TPEG message these references are then transmitted instead of plain text. It was only on the client side, an output is based on the tables, which must be present on the client in the desired language generated. This can be a text message in the user's language, a symbol or speech output.

For example, ( rtm01 ) are vehicle_type different vehicles listed in the TPEG -RTM table, such as car, taxi, bus or tram. To ensure the extensibility of the tables, each table also includes a default value. Then not necessarily be placed in extension of the tables up to date all the clients. If a client that is not up to date, a reference to an entry that is not listed in his version, the default entry is returned. The user is usually still be able to understand a message, even if any details are lost. [ TPEG ]

If a wrong -propelled motorcycle reported, for example, transmits TPEG -RTM references to the entries 19 and 7 vehicle_type in the tables and vehicle_problem_type.

If the above message sent to a client whose vehicle_type table entry 19 does not contain, the default entry ( vehicle) would be used. The user of a navigation system is so instead of the message " On the A9 towards Munich you will encounter a motorcycle! " An error message like " On the A9 towards Munich you will encounter a vehicle! " Is displayed.

For the specification of the tables so-called CEN English will be used. These are technical terms that often have nothing to do with the English slang and constitute a definition for each entry. CEN English is used in order to avoid confusion or inaccuracies. Due to the difference to the conventional use of language should CEN English in English-speaking countries not be output directly, but will be transferred to the commonly used terms. [ TPEG ] your limits is the language independence, however at the place names because not all possible names can be stored in the tables. Such information is transmitted in the form of strings, where multiple language versions are also possible here.

Independence from the maps ( TPEG -Loc )

The Ortsreferenzierungssystem of TPEG is called TPEG -Loc. It was designed so that it generates both for clients to have a location database, as well as clients that are not equipped with location data as accurate as possible local references. In addition, emphasis was placed on that make local references for both human and machine understandable. A local database or a card with the help of longitude and latitude can be converted into concrete local information, is for understanding the TPEG -Loc data not mandatory.

To achieve the above objectives, in addition to the spatial coordinates in the coordinate system WGS84 ( World Geodetic System 1984 ) conferring additional information that is to establish a relationship with the environment. The transmission using WGS84 coordinates makes sense, since this referencing system is used, among others, GPS and a worldwide de facto standard represents.

For the description of a point that lies between two motorway exits A and B, the names of the exits are used, for example, in addition to the coordinates of the point. The advantages of this information are obvious: A navigation system receives the exact information, the location of this point. PDAs without maps, however, can describe their users, at least approximately, that is called the point between the two exits A and B.

Independence of the transmission channel

Since TPEG is scheduled for different transmission channels as Digital Audio Broadcasting ( DAB), Digital Video Broadcasting ( DVB) or on the Internet is used, the mode of transmission may play a role. In the original, therefore, a binary TPEG Specification was developed, which requires such as packet or connection-oriented transmission of any particular shape and no return channel is needed. [ TPEG2 ] To achieve this takes the binary TPEG protocol in the ISO / OSI reference model layers 3-7 TPEG itself therefore depends only on the layers 1 and 2. The transmission medium itself therefore has to transfer only the task of the individual bytes. The higher functions such as segmenting and recognizing errors in transmission be done by TPEG itself. [ TPEG6 ] The segmentation is necessary because each message is transmitted as a single message. In addition, as several TPEG services can transmit their messages on the same channel.

However, to note here is that TPEG client on the basis of specification have no ability to request incorrectly transmitted information again. This restriction is necessary in order TPEG ( eg DAB ) also manages transmission media without return channel. The transmission channel should therefore be robust against transmission errors, and have error compensation functions. In addition, each message should be transmitted repeatedly if possible.

Because of its high entropy is suitable binary format especially for the transmission between transmitter site and client, as well as compounds with low data rates can then be used. The binary format is also available for users of advantage, for example, via GPRS (General Packet Radio Service) or UMTS ( Universal Mobile Telecommunications System) are connected to a TPEG provider, since often the traffic volume will be invoiced. In addition, the format is easier to decode on resource-poor clients, as the later developed XML format tpegML ( tpegML stands for TPEG in XML) for its processing complex XML parsers are required. On the other hand, the use of an easily manageable XML format, especially on the side of the content provider makes sense. Meanwhile, XML parsers and validators for each used programming language is available. tpegML from these characteristics advantage and forms the TPEG data structures in this easy -to-handle format. TPEG messages can be exchanged even during their creation in a standardized format between systems. Also, a content provider to query multiple data sources and process their information without much effort, if the sources adhere to this standard. Despite the opposition between a binary stream and an XML file contained the TPEG information both formats 1 to 1 can be mapped to each other. The independence of data transmission in the TPEG standard is therefore to be interpreted in two ways. One hand, a binary format has been developed which uses the ISO / OSI model already on the third layer, and only the simple transfer of data bits requires. On the other hand, there are tpegML with an XML-based data format that can be easily transferred and mainly process. The conversion of this format is easy to perform thanks to the numerous possibilities of transformation.

Data format

Basically TPEG data is transmitted in packets or as individual messages. Since TPEG already using models on layer 3 of the ISO / OSI, the segmentation of TPEG is adopted. A message consists of at least the Message Management Container, which contains control information for an application ( RTM or PTI). If in addition to the control information and user data are transmitted, the RTM and PTI event container and the TPEG Location containers must be appended. To select a different message to be declared invalid, a message is used, which consists only of a Message Management Container. [ TPEG2 ] It should be noted that the message management can distinguish containers from application to application.

Building a RTM message ( cf. [ TPEG4 ] )

Message Management Container

The term " Message Management " all the information is summarized, which are used to control and manage a RTM message ( fields that must necessarily be present, are identified. )

• Message Identifier (mandatory): Unlike the name suggests possibly, it is not a unique name for a specific message but a name for an event. That all messages (eg traffic jam on a certain street ) contain the information about an event, have the same Message Identifier.
• Version Number (mandatory): Consecutive number which indicates the order of the messages of a particular event. With each new message to an event this version number is incremented by one. A TPEG decoder can so the order of the messages belonging to an event (ie have the same Message Identifier ), and then restore if the messages do not arrive in the correct order with him. This is in broadcast scenarios of particular importance because a recipient can begin at any point with the interception of the information stream and receives as already missed messages in a message sequence only when repeatedly transmitting the message.
• Message Generation Date and Time: time stamp that is applied when generating the message.
• Start Date and Time: This time stamp indicates when an event has occurred or will occur.
• Stop Date and Time: Indicates when an event is over or was.
• Message Expiry Date and Time: expiry date of a message. Does a message to a client whose expiration date has passed, the message is ignored by the client.
• Time Schedule Information: This can be an event of a timing be assigned. It can be given one or more time intervals in which there is the defined event in the message. Also weekly daily repetitions can be specified. So you can specify for example that a certain road section is locked on all weekdays 17:00 to 9:00 p.m. clock. The Time Schedule information is valid only for the period between Start Date and Time and Stop Date and Time.
• Severity Factor: Indicates the importance of a message. The user is thus able to sort incoming messages according to their importance or hide unimportant messages.
• Unverified information: Indicates whether the content of a message has been verified, that is, comes from a trusted source or been verified by a trusted source.

Event Description Container

This area of a message contains information about the event itself. The description of the events has a hierarchical structure, so that the level of detail increases with each level of the hierarchy. A client that decodes only the first level of the hierarchy so receives only coarse information that is more detailed with each additional stage decoded. This makes sense, since only coarse information should be displayed, for example, in a message list. Clients that are not due to limited resource in the location can also decode a complex message, just ignore the lower levels of the hierarchy. The following types are defined for the first level currently, which in turn contain sub- types for a more detailed description:

• Accident Description of accident
• Obstructions: Disabilities
• Activities: events such as parades or demonstrations
• Road Conditions: Information on road conditions
• Network Performance: Information about the flow of traffic (eg traffic or slow traffic )
• Network Conditions: deviating from the normal traffic rules, such as the temporary change the priority conditions
• Security Alert: Safety on situations that can put the driver in danger (such as a bomb threat ).
• Public transport information: information about disturbances in the public transport system can have an impact on the traffic.
• Visibility: Description of visibility ( eg fog )
• Weather: The weather information that affect driving (eg ice )
• Diversion Advise: information on alternative routes, such as detours.

An event is described by at least one of these types, but can also consist of several. If, for example, to a traffic jam because of an accident due to road damage and poor visibility, there is a message from the guy Accident, Network Performance, Road Conditions and Visibility.

TPEG -Location Container

This container contains a location reference as it is already described above ( TPEG -Loc ). Each message is linked to a place, having such a container.

The binary format (according to [ TPEG2 ] )

This section describes the part of the binary format, which is specific for this format, that is, for which there is no equivalent in XML format. Basically, two types of messages, which are differentiated by the field "Frame Type", differentiated:

• Stream directory information: Contains a list of all service providers that are active in this stream.
• Conventional service frame data: contains user data

Besides Frame Type a binary TPEG message contains additional fields that are explained below:

• Sync word (2 bytes): is the decoder for the recognition of a new message. This sync word always has the value FF0F hex.
• Field Length ( 2 bytes): Total length of service frames in bytes. A Service Frame can therefore not be greater than 65535 bytes.
• Frame Type (1 byte): provides the above -discussed distinction between "Stream directory information" and " Conventional service frame data".
• Header CRC: checksum to ensure the correctness of the header data. This sum is calculated using the Sync Word fields, field length, frame type and the first 11 bytes of the service frames. For more information on this calculation can be found in [ TPEG2 ].
• Service Frame: contains the user data (possibly encrypted ) and the service identifier. About the Service Identifier ( SID), a content provider be clearly identified. The service frame is divided into the following components: SID A to C ( 1 byte ): together give a unique identification number of a service provider, similar to an IP address, such as 133 168 123.
• Encryption indicator ( 1 byte): undefined reference to a value between 0 and 255 encryption method. The values ​​0 through 127 are reserved for standardized methods. 128-255 are provided for the free use by a service provider. Encryption can be used, for example, to develop fee-based services. Also, the use of encrypted messages would possibly be in safety-critical applications, such as available eg police or military radio.
• Component Multiplex: This possibly encrypted data field then contains the actual TPEG messages, as described at the beginning of Chapter 3. As long as the maximum size of 65531 bytes is not exceeded, this area can accommodate multiple messages. The coding of these data is given in the specification.

TPEG - TAP ( TPEG Automotive Profile )

This specially developed for use in navigation equipment specification includes the specification of TPEG -TEC (Traffic Event Compact). This protocol was developed for the transmission of traffic-related content. TPEG -TEC version 2.0 has been submitted to ISO for standardization.

Analysis of TPEG data streams

The TPEG Analyser is an analysis tool for TPEG data flows of the company Bayerische Medien Technik GmbH ( bmt ). The software allows the manufacturer " the graphic representation and evaluation of several TPEG data streams in real time" and is aimed primarily at operators of TPEG services and terminal manufacturers in the fields of navigation and car audio.