Transport Protocol Experts Group
The Transport Protocol Experts Group , or TPEG for short , is an expert group founded in 1997 whose aim was to provide solutions for better and more detailed traffic and travel information than the systems available until then. Over time, “TPEG” became a synonym for the data protocol that this group of experts developed.
Note: In the following, the term "TPEG" is always used for the data protocol.
TPEG is a series of data protocols for the transmission of traffic and travel information. It consists of various services (also called applications) and basic structures for managing the actual data transmission. The latter includes, for example, the grouping of messages into services, updating and deleting messages, error correction mechanisms or the encryption of commercial services. TPEG can be transmitted via various data channels (carrier media), e.g. B. digital radio , cellular or WiFi . TPEG services include, for example, event reports (accidents, construction sites, traffic jams), traffic flow information (average travel times on road segments), weather information, fuel prices, parking information or information on local public transport.
history
The Transport Protocol Experts Group launched in 1997 within the European Broadcasting Union (European Broadcast Union, EBU). The work was continued until 2007 under the leadership of the EBU. After the merger with the group led by ERTICO ITS Europe for the development of the Traffic Message Channel ( TMC ) protocol and the Mobile.Info project in Germany, where TPEG was tested for the first time under real operating conditions in vehicles, the Traveler Information Services Association was created at the end of 2007 ( TISA ) based in Brussels.
At the beginning of the work on TPEG, the vision was to develop services that go far beyond the technologies available until then, such as RDS - TMC or proprietary solutions. In addition to information for private transport (i.e. motorists), TPEG should also include services for local and long-distance public transport (e.g. departure times and delays for buses, underground and suburban trains, long-distance trains, departure times at airports). It all started with the Road Traffic Messages (RTM) service for individual and road traffic. The Public Transport Information (PTI) service soon followed. Both RTM and PTI jointly use a uniform method for location referencing, the TPEG Location Referencing.
TPEG RTM was designed as a monolithic solution (“one size fits all”). With the first implementations, however, it was found that this approach was too complex to integrate RTM as the successor to the previously very successful RDS-TMC in navigation systems. This 1st generation of TPEG services, also called TPEG1, was also only available in a binary version. An XML variant was only available as a separate specification. As a result, both the data model and the modeling process were revised and TPEG2 was created. Both the binary and the XML implementation are based on a uniform UML model, from which the binary and XML variants can be generated automatically with the appropriate code generators. A TPEG2 specification always contains the binary and the XML representation of the relevant service.
With the first TPEG2 service Traffic Event Compact (TEC), a breakthrough was achieved because service providers, end device manufacturers and the automotive industry accepted TEC as the successor to the previously very successful RDS-TMC.
Both TPEG1 and TPEG2 are published by the international standardization organization ISO as ISO / TS 18234 (TPEG1) and ISO / TS 21219 (TPEG2). TPEG1 is now generally considered to be out of date and its use for new services and devices is not recommended.
technology
TPEG specifies services for detailed and precisely referenced traffic and travel information. TPEG can be disseminated via various carrier media, e.g. B. via digital radio or cellular network. The latter is now the most widespread carrier medium.
TPEG is a data protocol that groups information on specific topics into services (applications) and transports it in message containers. Using this container concept and the structured coding of messages, further applications can be developed at any time and added to existing services or existing applications can be expanded with new messages. The design principles guarantee backward compatibility at all times.
Design principles
The development of TPEG applications follows a top-down approach, in which application scenarios (use cases) are modeled in the Unified Modeling Language (UML). Based on this UML modeling, two TPEG versions can be derived:
- Coding in Extensible Markup Language (XML) - This version is machine-readable as well as manually readable / interpretable. Backward compatibility is guaranteed by the fact that new XML elements (tags) from older devices are skipped because they cannot recognize and interpret the new tags.
- a binary coding - this version cannot be read / interpreted manually. The advantage, however, is that it is much more compact. Binary coding is therefore mainly used when bandwidth efficiency is the top priority.
Basic principles
The following principles are the cornerstones in the development of syntax and semantics of TPEG (see also ISO / TS 18234-2 and ISO / TS 21219-5):
- Unidirectionality - TPEG does not require a return channel (a return channel does not have to, but can be implemented in TPEG, especially for services via mobile radio or IP networks)
- Byte orientation
- asynchronous frame structure
- hierarchical error detection through cyclic redundancy checks (CRC) on different protocol levels
- TPEG requires suitable mechanisms for error correction in the transmission medium
- TPEG requires a transparent data channel
- Hierarchical frame structure for the coding of messages and services
- TPEG offers mechanisms for the transmission of information to service provider, service and network
- Encryption for commercial services
Further functionalities
- Separation of content and transmission in the protocol design
- Separation of message content and location referencing within the content coding
- Location referencing both via dynamic referencing methods (on-the-fly location referencing) or via fixed reference points on maps (location tables)
- Several methods are available for dynamic (on-the-fly) location referencing
- Language independence
- optional coding of messages with extensive attributes and additional information
- Possibility of filtering services and messages according to various criteria
- Expandability to include new services and message types
- Independence from databases with location references (e.g. necessary for RDS-TMC)
- Decoding of TPEG services is possible for high-performance end devices (e.g. navigation devices with maps and graphics) as well as for the simplest devices (e.g. without map and only with text display)
- Adaptation to new transmission media is easily possible by defining adaptation layers
Specific properties and functions of TPEG
Language independence
A traffic information system should be able to present the required information in the respective language of the user.
TPEG enables this multilingualism by using expandable translation tables. For this purpose, words with a similar meaning that are often required in TPEG messages are summarized in tables. These words can be referenced in a TPEG message via a number. These references are then transmitted in a TPEG message instead of plain text. Only on the client side is an output generated based on the tables that must be available on the client in the desired language. This can be a text message in the user's language, a symbol or voice output.
For example, various vehicles are listed in the TPEG-RTM table (rtm01) vehicle_type , such as car, taxi, bus or tram. To ensure that the tables can be expanded, each table also contains a default value. This means that not all clients have to be brought up to date when the tables are expanded. If a client that is not up to date receives a reference to an entry that is not yet included in its version, the standard entry is output. The user is usually still able to understand a message, even if details are possibly lost [TPEG].
If, for example, an incorrectly driving motorcycle is reported, TPEG-RTM transfers references to entries 19 and 7 in the tables vehicle_type and vehicle_problem_type.
If the above-mentioned message were transmitted to a client whose vehicle_type table does not yet contain entry 19, the default entry (vehicle) would be used. The user of a navigation system is shown instead of the message “A motorcycle is coming towards you on the A9 in the direction of Munich!” And a message of the type “A vehicle is coming towards you on the A9 in the direction of Munich!”.
So-called CEN-English is used to specify the tables. These are technical terms that often have nothing to do with everyday English and represent a definition for the individual entries. CEN-English is used to avoid confusion or inaccuracies. Because of the difference to conventional usage, CEN-English should not be output directly in English-speaking countries either, but should be translated into the commonly used terms. [TPEG] However, the language independence has its limits in the place names, since not all conceivable names can be stored in the tables. Such information is transmitted in the form of strings, although several language versions are also possible here.
Independence from map material (TPEG-Loc)
TPEG's location referencing system is called TPEG-Loc. It was designed in such a way that it generates location references that are as precise as possible both on clients that have a location database and on clients that are not equipped with location data. In addition, emphasis was placed on making the location references understandable for both humans and machines. A location database or a map that can be used to convert longitudes and latitudes into specific location information is not absolutely necessary for understanding the TPEG-Loc data.
In order to achieve the above-mentioned goals, in addition to the location coordinates in the WGS84 (World Geodetic System 1984) coordinate system, additional information is transmitted that is intended to relate to the environment. The transmission with the help of WGS84 coordinates makes sense because this referencing system is used by GPS , among other things , and represents a worldwide de facto standard.
To describe a point located 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 where this point is located. PDAs without map material, on the other hand, can at least roughly describe to their users that the point mentioned is between the two exits A and B.
Independence from the transmission channel
Since TPEG is to be used on various transmission channels such as digital audio broadcasting (DAB), digital video broadcasting (DVB) or on the Internet, the type of transmission must not play a role. In the original TPEG specification, a binary format was therefore developed that does not require a specific form of transmission such as packet or connection-oriented and also does not require a return channel. [TPEG2] To achieve this, the binary TPEG protocol in the ISO / OSI layer model takes on layers 3 to 7 itself. TPEG is therefore only dependent on layers 1 and 2. The transmission medium itself only has the task of transmitting the individual bytes. The higher functions such as segmentation or the detection of errors during transmission are handled by TPEG itself. [TPEG6] The segmentation is necessary because each message is transmitted as a single message. In addition, several TPEG services can transmit their messages on the same channel.
However, it should be noted here that due to the specification, TPEG clients are unable to request incorrectly transmitted information again. This restriction is necessary so that TPEG can also cope with transmission media without a return channel (e.g. DAB). The transmission channel should therefore be as robust as possible against transmission errors and have error compensation functions. In addition, the individual messages should be transmitted repeatedly if possible.
Because of its high entropy, the binary format is particularly suitable for transmission between the sending point and the client, since connections with low data rates can then also be used. The binary format is also advantageous for users who are connected to a TPEG provider via GPRS (General Packet Radio Service) or UMTS (Universal Mobile Telecommunications System), since the transmission volume is often billed here. In addition, the format is easier to decode on resource-poor clients than the later developed XML format tpegML (tpegML stands for TPEG in XML ), for whose processing complex XML parsers are required. On the other hand, the use of an easily manageable XML format makes sense, especially on the part of the content provider. In the meantime, XML parsers and validators are available for every common programming language. tpegML makes use of these properties and maps the TPEG data structures to this easy-to-use format. TPEG messages can be exchanged between individual systems in a standardized format while they are being created. A content provider can also query multiple data sources and process their information without great effort, if the sources adhere to this standard. Despite the contradiction between a binary stream and an XML file, the TPEG information contained in both formats can be mapped 1 to 1 on one another. The independence of data transmission in the TPEG standard can therefore be interpreted in two ways. On the one hand, a binary format was developed that is already used on the third layer in the ISO / OSI model and only requires the simple transmission of bits. On the other hand, with tpegML there is an XML-based data format that can be easily transmitted and, above all, processed. The conversion of this format is also easy to carry out thanks to numerous transformation options.
Data format
In principle, TPEG data are transmitted in packets or as individual messages. Since TPEG already uses layer 3 of the ISO / OSI model , the segmentation is also taken over by TPEG. A message consists at least of the Message Management Container, which contains control information for an application (RTM or PTI). If user data is to be transmitted in addition to the control information, the RTM or PTI event container and the TPEG location container must be attached. In order to invalidate another message, a message is used that only consists of a message management container. [TPEG2] It should be noted that the message management container can differ from application to application.
Structure of a TPEG message
Message management container
The term "Message Management" summarizes all information that is used to control and manage an RTM message (fields that must be present are marked):
- Message Identifier (mandatory): Contrary to what the name might suggest, this is not a unique name for a specific message, but a name for an event. This means that all messages that contain information about an event (e.g. traffic jam on a certain street) have the same message identifier.
- Version Number (mandatory): Consecutive number that shows the order of the messages for a specific event. With each new message about an event, this version number is increased by one. A TPEG decoder can thus restore the order of the messages that belong to an event (i.e. carry the same message identifier), even if the messages do not arrive in the correct order. This is of particular importance in broadcast scenarios because a recipient can start listening to the information stream at any point in time and thus only receives missed messages in a message sequence when the messages are sent repeatedly.
- Message Generation Date and Time: Time stamp that is created when the message is generated.
- 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 or was over.
- Message Expiry Date and Time: The expiry date of a message. If a client receives a message whose expiration date has passed, the client ignores this message.
- Time Schedule Information: This can be used to assign a time schedule to an event. One or more time intervals can be specified in which the event defined in the message takes place. Weekly repetitions can also be specified. So z. For example, it can be specified that a certain section of the route is closed on all weekdays between 5:00 p.m. and 9:00 p.m. The time schedule information is only valid in the period between Start Date and Time and Stop Date and Time.
- Severity Factor: Indicates the importance of a message. The user is able to sort incoming messages according to their importance or to hide unimportant messages.
- Unverified Information: Indicates whether the content of a message has been verified, i. H. comes from a trusted source or has been verified by a trusted source.
Event description container
This area of a message contains information about the event itself. The description of the event is structured hierarchically, so that the level of detail increases with each hierarchy level. A client that only decodes the first hierarchy level therefore only receives rough information that becomes more detailed with each additional decoded level. This is useful because, for example, only rough information should be displayed in a news overview. Clients who are not able to decode a complex message due to limited resources can simply ignore the lower hierarchy levels. The following types are currently defined for the first level, which in turn contain sub-types for a more precise description:
- Accident: description of accidents
- Obstructions: disabilities
- Activities: events such as parades or demonstrations
- Road Conditions: Information about the road conditions
- Network Performance: Information on the traffic flow (e.g. traffic jams or slow-moving traffic)
- Network Conditions: Traffic rules that deviate from normal conditions, e.g. B. the temporary change of the right of way
- Security Alert: Safety notices about situations that could endanger the driver (e.g. a bomb threat).
- Public Transport Information: Information about disruptions in the public transport system that can affect road traffic.
- Visibility: Description of the visibility conditions (e.g. fog)
- Weather: Weather information that affects the journey (e.g. black 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. Does it come B. for a traffic jam due to an accident due to road damage and poor visibility, the message consists of the types Accident, Network Performance, Road Conditions and Visibility.
TPEG location container
This container contains a location reference as already described above ( TPEG-Loc ). Every message that is linked to a location has such a container.
The binary format (according to TPEG2)
This section describes the part of the binary format that is specific to that format; H. for which there is no equivalent in XML format. Basically, a distinction is made between two types of messages, which are differentiated using the "Frame Type" field:
- Stream directory information: Contains a list of all service providers that are active in this stream.
- Conventional service frame data: contains user data
In addition to the frame type, a binary TPEG message contains further fields, which are explained below:
- Sync Word (2 bytes): used by the decoder to recognize a new message. This sync word always has the value FF0F hex.
- Field Length (2 bytes): Total length of the service frame in bytes. A service frame cannot be larger than 65535 bytes.
- Frame Type (1 byte): ensures the above-mentioned 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 fields Sync Word, Field Length, Frame Type and the first 11 bytes of the service frame. More information on this calculation can be found in [TPEG2].
- Service frame: contains the user data (possibly in encrypted form) as well as the service identifier. A content provider can be clearly identified using the Service Identifier (SID). The service frame is in turn divided into the following components:
- SID-A to C (1 byte each): together result in a unique identification number of a service provider, comparable to an IP address, e.g. B. 133.168.123.
- Encryption indicator (1 byte): specifies an encryption method based on a value between 0 and 255. The values 0 to 127 are reserved for standardized methods. 128–255 are intended for free use by a service provider. The encryption can e.g. B. used to develop paid services. The use of encrypted messages would also be possible in security-critical applications, such as B. police or military radio can be used.
- Component Multiplex: This possibly encrypted data area 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 hold several messages. The coding of this data can be found in the specification.
TPEG2 applications
| ISO No. | ISO reference | title | acronym | description |
| 21219-1 | Part 1: Introduction, numbering and versions | Introduction and nomenclature for TPEG Generation 2 components and services, including Application Identification (AID). | ||
| 21219-2 | Part 2: UML modeling rules | Syntax and semantics of TPEG services, independent of the physical data format (binary or XML). | ||
| 21219-3 | Part 3: UML to binary conversion rules | TPEG services are modeled in UML to ensure independence from the specific coding (binary or XML). By separating semantics and application description, functions can be developed easily and uniformly for both codings. The coding formats are then generated directly from the UML description using translation tools (code generators). | ||
| 21219-4 | Part 4: UML to XML conversion rules | Set of rules for converting TPEG UML descriptions into XML format. | ||
| 21219-5 | Part 5: Service framework | Description for the compilation (multiplexing) of service offers (bouquets) from different individual services. | ||
| 21219-6 | Part 6: Message management container | Message management in the end device | ||
| 21219-7 | Part 7: Location referencing container | The TPEG2 container for location referencing (Location Referencing Container) shows which referencing method is used. Different methods can be embedded for location referencing. | ||
| 21219-9 | Part 9: Service and network information | Coding of the display of service provider, service, service components and carrier medium. Can also be used to link the same or related services via other carrier media (service linking). | ||
| 21219-10 | Part 10: Conditional access information | Features to encrypt commercial services | ||
| 21219-11 | Part 11: Universal location referencing | Universal location referencing method | ||
| 21219-14 | Part 14: Parking information application | Information on parking spaces and parking garages (location, opening times, number of free spaces, etc.) | ||
| 21219-15 | Part 15: Traffic event compact application | TEC | Compact representation of event messages, especially for processing in navigation devices and to support dynamic route changes (detour recommendation) | |
| 21219-16 | Part 16: Fuel price information application | Information on petrol stations and fuel prices | ||
| 21219-18 | Part 18: Traffic flow and prediction application | TFP | Compact representation of traffic flow information, especially for processing in navigation devices and to support dynamic route changes (diversion recommendation) | |
| 21219-19 | Part 19: Weather information application | Weather information | ||
| 21219-20 | Part 20: Extended TMC location referencing | Extension for location referencing with fixed location referencing tables (TMC Location Tables), especially for use in connection with TEC | ||
| 21219-21 | Part 21: Geographic location referencing | Location referencing method for areas and points independent of streets | ||
| 21219-22 | Part 22: OpenLR location referencing | Location referencing method | ||
| 21219-23 | Part 23: Road and multimodal routes application | Multimodal route information |
TPEG services worldwide
Broadcasting
| country | Service provider | status | product | TPEG services |
| Belgium | Be-Mobile | live | Premium | TEC / TFP |
| Germany | ARD | live | Free to Air | TEC / TFP |
| Germany | HERE | live | Premium | TEC / TFP |
| Germany | Mediamobile | live | v-traffic | TEC / TFP |
| Luxembourg | Be-Mobile | live | Premium | TEC / TFP |
| Netherlands | Be-Mobile | live | Premium | TEC / TFP |
| Norway | Mediamobile | live | v-traffic | TEC / TFP |
| United Kingdom | Inrix | live | Premium | TEC / TFP |
| United Kingdom | Traffic master | live | Premium | TEC |
| Test broadcasts | ||||
| France | Mediamobile | Trial (in some cities) | v-traffic | TEC / TFP |
| Italy | Infoblu | Trial | Premium | TEC / TFP |
| Poland | Mediamobile | Trial | v-traffic | TEC / TFP |
| Sweden | Mediamobile | Trial | v-traffic | TEC / TFP |
Cellular broadcasting
| country | Service provider | status | product | TPEG services |
| Andorra | Tomtom | live | Premium | TEC / TFP / WEA |
| Argentina | HERE | live | Premium | TEC / TFP |
| Australia | HERE | live | Premium | TEC / TFP |
| Australia | Tomtom | live | Premium | TEC / TFP / WEA |
| Austria | HERE | live | Premium | TEC / TFP |
| Austria | Tomtom | live | Premium | TEC / TFP / WEA |
| Belgium | HERE | live | Premium | TEC / TFP |
| Belgium | Tomtom | live | Premium | TEC / TFP / WEA |
| Brazil | HERE | live | Premium | TEC / TFP |
| Brazil | Tomtom | live | Premium | TEC / TFP / WEA |
| Canada | HERE | live | Premium | TEC / TFP |
| Canada | Tomtom | live | Premium | TEC / TFP / WEA |
| Chile | Tomtom | live | Premium | TEC / TFP / WEA |
| China | Tomtom | live | Premium | TEC / TFP / WEA |
| Czech Republic | HERE | live | Premium | TEC / TFP |
| Czech Republic | Tomtom | live | Premium | TEC / TFP / WEA |
| Croatia | HERE | live | Premium | TEC / TFP |
| Denmark | HERE | live | Premium | TEC / TFP |
| Denmark | Tomtom | live | Premium | TEC / TFP / WEA |
| Finland | HERE | live | Premium | TEC / TFP |
| Finland | Tomtom | live | Premium | TEC / TFP / WEA |
| France | HERE | live | Premium | TEC / TFP |
| France | Tomtom | live | Premium | TEC / TFP / WEA |
| Germany | Tomtom | live | Premium | TEC / TFP / WEA |
| Germany | HERE | live | Premium | TEC / TFP |
| Germany | Inrix | live | Premium | TEC / TFP |
| Gibraltar | Tomtom | live | Premium | TEC / TFP / WEA |
| Greece | HERE | live | Premium | TEC / TFP |
| Hungary | HERE | live | Premium | TEC / TFP |
| India | HERE | live | Premium | TEC / TFP |
| Indonesia | HERE | live | Premium | TEC / TFP |
| Ireland | HERE | live | Premium | TEC / TFP |
| Ireland | Tomtom | live | Premium | TEC / TFP / WEA |
| Italy | HERE | live | Premium | TEC / TFP |
| Italy | Tomtom | live | Premium | TEC / TFP / WEA |
| Lesotho | Tomtom | live | Premium | TEC / TFP / WEA |
| Liechtenstein | Tomtom | live | Premium | TEC / TFP / WEA |
| Luxembourg | HERE | live | Premium | TEC / TFP |
| Luxembourg | Tomtom | live | Premium | TEC / TFP / WEA |
| Malaysia | HERE | live | Premium | TEC / TFP |
| Malaysia | Tomtom | live | Premium | TEC / TFP / WEA |
| Malta | Tomtom | live | Premium | TEC / TFP / WEA |
| Mexico | HERE | live | Premium | TEC / TFP |
| Mexico | Tomtom | live | Premium | TEC / TFP / WEA |
| Monaco | Tomtom | live | Premium | TEC / TFP / WEA |
| Netherlands | HERE | live | Premium | TEC / TFP |
| Netherlands | Tomtom | live | Premium | TEC / TFP / WEA |
| New Zealand | HERE | live | Premium | TEC / TFP |
| New Zealand | Tomtom | live | Premium | TEC / TFP / WEA |
| Norway | HERE | live | Premium | TEC / TFP |
| Norway | Tomtom | live | Premium | TEC / TFP / WEA |
| Poland | HERE | live | Premium | TEC / TFP |
| Poland | Tomtom | live | Premium | TEC / TFP / WEA |
| Portugal | HERE | live | Premium | TEC / TFP |
| Portugal | Tomtom | live | Premium | TEC / TFP / WEA |
| Puerto Rico | HERE | live | Premium | TEC / TFP |
| Russia | HERE | live | Premium | TEC / TFP |
| Russia | Tomtom | live | Premium | TEC / TFP / WEA |
| San Marino | Tomtom | live | Premium | TEC / TFP / WEA |
| Saudi Arabia | HERE | live | Premium | TEC / TFP |
| Saudi Arabia | Tomtom | live | Premium | TEC / TFP / WEA |
| Singapore | HERE | live | Premium | TEC / TFP |
| Singapore | Tomtom | live | Premium | TEC / TFP / WEA |
| Slovakia | HERE | live | Premium | TEC / TFP |
| Slovenia | HERE | live | Premium | TEC / TFP |
| South Africa | HERE | live | Premium | TEC / TFP |
| South Africa | Tomtom | live | Premium | TEC / TFP / WEA |
| South Korea | HERE | live | Premium | TEC / TFP |
| Spain | HERE | live | Premium | TEC / TFP |
| Spain | Tomtom | live | Premium | TEC / TFP / WEA |
| Sweden | HERE | live | Premium | TEC / TFP |
| Sweden | Tomtom | live | Premium | TEC / TFP / WEA |
| Switzerland | HERE | live | Premium | TEC / TFP |
| Switzerland | Tomtom | live | Premium | TEC / TFP / WEA |
| Taiwan | HERE | live | Premium | TEC / TFP |
| Taiwan | Tomtom | live | Premium | TEC / TFP / WEA |
| Thailand | HERE | live | Premium | TEC / TFP |
| Thailand | Tomtom | live | Premium | TEC / TFP / WEA |
| Turkey | HERE | live | Premium | TEC / TFP |
| Turkey | Tomtom | live | Premium | TEC / TFP / WEA |
| Ukraine | HERE | live | Premium | TEC / TFP |
| United Arab Emirates | HERE | live | Premium | TEC / TFP |
| United Arab Emirates | Tomtom | live | Premium | TEC / TFP / WEA |
| United Kingdom | HERE | live | Premium | TEC / TFP |
| United Kingdom | Tomtom | live | Premium | TEC / TFP / WEA |
| United States | HERE | live | Premium | TEC / TFP |
| United States | Tomtom | live | Premium | TEC / TFP / WEA |
| Vatican | Tomtom | live | Premium | TEC / TFP / WEA |
Hybrid services (broadcast + cellular)
| country | Service provider | status | product | TPEG services |
| United States | Total Traffic and Weather Network | live | TTN HD hybrid | TEC / TFP / FPI |
literature
- EUROPEAN BROADCASTING UNION, Guidelines for TPEG on the Internet, 2002
- EUROPEAN BROADCASTING UNION, TPEG - What is it all about ?, 2003
- EUROPEAN BROADCASTING UNION, TPEG specifications - Supplement: TPEG Tables: RTM, PTI, Loc - Version 3.0, 2002
- EUROPEAN BROADCASTING UNION, TPEG specifications - Part 2: Syntax, Semantics and Framing Structure, 2002
- EUROPEAN BROADCASTING UNION, TPEG specifications - Part 4: Road Traffic Message Application, 2002
- EUROPEAN BROADCASTING UNION, TPEG specifications - Part 5: Public Transport Information Application, 2002
- EUROPEAN BROADCASTING UNION, TPEG specifications - Part 6: Location Referencing for Applications, 2002
- EUROPEAN BROADCASTING UNION, tpegML specifications - Part 1: Introduction, common data types and tpegML v1.00, 2004
- EUROPEAN BROADCASTING UNION, tpegML specifications - Part 2: tpeg-locML v1.00, 2004
- EUROPEAN BROADCASTING UNION, tpegML specifications - Part 3: tpeg-rtmML v1.00, 2004
- MARKS, B., Guidelines for TPEG in DAB, 2000
Web links
- http://www.tisa.org New official website of the TMC and TPEG Forum successor organization
- Mobile Platform for Efficient Traffic Information Services. Website for efficient traffic information services. (No longer available online.) In: mobile-info.org. Archived from the original on April 3, 2010 ; accessed on December 13, 2018 .
- http://www.bmt-online.de Further information on TPEG
- http://www.wecantpeg.com Training and information on TPEG
Individual evidence
- ↑ EBU Technology & Innovation - TPEG (English, accessed on August 18, 2014).