Transport Protocol Experts Group

Die Transport Protocol Experts Group, kurz TPEG, ist eine 1997 gegründete Expertengruppe, deren Arbeit es zum Ziel hatte, Lösungen für bessere und detailliertere Verkehrs- und Reiseinformationen bereitzustellen, als die bis dahin verfügbaren Systeme. Mit der Zeit wurde „TPEG“ zum Synonym für das Datenprotokoll, welches diese Expertengruppe erarbeitete.

Hinweis: Im Folgenden wird der Begriff „TPEG“ stets für das Datenprotokoll verwendet.

TPEG ist eine Serie von Datenprotokollen für die Übertragung von Verkehrs- und Reiseinformationen. Sie besteht aus verschiedenen Diensten (auch Anwendungen genannt) sowie grundlegenden Strukturen für die Verwaltung der eigentlichen Datenübertragung. Letzteres umfasst beispielsweise die Gruppierung von Nachrichten zu Diensten, Aktualisierung und Löschung von Nachrichten, Fehlerkorrekturmechanismen oder Verschlüsselung von kommerziellen Diensten. TPEG kann über verschiedene Datenkanäle (Trägermedien) übertragen werden, z. B. Digitalradio, Mobilfunk oder auch WiFi. TPEG Dienste beinhalten beispielsweise Ereignismeldungen (Unfälle, Baustellen, Staus), Verkehrsflussinformationen (durchschnittliche Reisezeiten auf Straßensegmenten), Wetterinformationen, Kraftstoffpreise, Parkinformationen oder Informationen zum öffentlichen Nahverkehr.

Geschichte

Die Transport Protocol Experts Group startete in 1997 innerhalb der Europäischen Rundfunkunion (European Broadcast Union, EBU). Die Arbeit wurde unter Federführung der EBU bis 2007 fortgeführt. Nach dem Zusammenschluss mit der von ERTICO ITS Europe geleiteten Gruppe zur Entwicklung des Traffic Message Channel (TMC) Protokolls sowie des Mobile.Info Projektes in Deutschland, wo erstmals TPEG unter realen Einsatzbedingungen in Fahrzeugen getestet wurde, entstand Ende 2007 die Traveller Information Services Association (TISA) mit Sitz in Brüssel.

Zu Beginn der Arbeiten an TPEG stand die Vision, Dienste zu entwickeln, die weit über die bis dahin verfügbaren Technologien, wie beispielsweise RDS-TMC oder proprietäre Lösungen, hinausgehen. Neben Informationen für den Individualverkehr (d. h. Autofahrer) sollte TPEG auch Dienste für den öffentlichen Nah- und Fernverkehr (z. B. Abfahrtzeiten und Verspätungen für Busse, U- und S-Bahnen, Fernzüge, Abflugzeiten an Flughäfen) beinhalten. Am Anfang stand also der Dienst Road Traffic Messages (RTM) für Individual- bzw. Straßenverkehr. Schon bald folgte der Dienst Public Transport Information (PTI). Sowohl RTM als auch PTI nutzten gemeinsam ein einheitliches Verfahren zur Ortsreferenzierung, das TPEG Location Referencing.

TPEG RTM wurde als eine monolithische Lösung („one size fits all“) entworfen. Mit den ersten Implementierungen stellte man allerdings fest, dass dieser Ansatz zu komplex war, um RTM als Nachfolger des bis dahin sehr erfolgreichen RDS-TMC in Navigationssysteme zu integrieren. Diese 1. Generation von TPEG Diensten, auch TPEG1 genannt, war außerdem nur in einer binären Version verfügbar. Eine XML Variante war nur als separate Spezifikation verfügbar. Konsequenterweise wurde sowohl das Datenmodell als auch der Modellierungsprozess überarbeitet und es entstand TPEG2. Hier gehen sowohl die binäre als auch die XML Umsetzung von einem einheitlichen UML Modell aus, von welchem die binäre und die XML Variante mit entsprechenden Codegeneratoren automatisch erzeugt werden können. Eine TPEG2 Spezifikation enthält also stets die binäre und die XML Repräsentation des betreffenden Dienstes.

Mit dem ersten TPEG2 Dienst Traffic Event Compact (TEC) wurde dann auch gleich ein Durchbruch erreicht, weil sowohl Dienstanbieter als auch Endgerätehersteller und die Automobilindustrie TEC als den Nachfolger des bis dahin sehr erfolgreichen RDS-TMC akzeptierten.

Sowohl TPEG1 als auch TPEG2 werden über die internationale Standardisierungsorganisation ISO publiziert als ISO/TS 18234 (TPEG1) bzw. ISO/TS 21219 (TPEG2). TPEG1 wird nun allgemein als veraltet betrachtet und von einer Verwendung für neue Dienste und Endgeräte abgeraten.

Technologie

TPEG spezifiziert Dienste für detaillierte und präzise referenzierte Verkehrs- und Reiseinformationen. TPEG kann über verschiedene Trägermedien verbreitet werden, z. B. über Digitalradio oder Mobilfunk. Letzteres ist inzwischen das am weitesten verbreitete Trägermedium.

TPEG ist ein Datenprotokoll, welches Informationen über spezifische Themen zu Diensten (Anwendungen) gruppiert und in Nachrichtencontainern transportiert. Über dieses Containerkonzept und die strukturierte Codierung von Nachrichten können jederzeit weitere Anwendungen entwickelt und zu bestehenden Diensten hinzugefügt bzw. bestehende Anwendungen durch neue Meldungen erweitert werden. Eine Rückwärtskompatibilität ist durch die Designprinzipien dabei jederzeit gewährleistet.

Designprinzipien

Die Entwicklung von TPEG-Anwendungen folgt einem top-down Ansatz, bei dem Anwendungsszenarien (Use Cases) in der Unified Modeling Language (UML) modelliert werden. Ausgehend von dieser UML Modellierung können zwei TPEG Versionen abgeleitet werden:

• eine Codierung in der Extensible Markup Language (XML) – Diese Version ist sowohl maschinenlesbar als auch manuell lesbar/interpretierbar. Die Rückwärtskompatibilität wird dadurch gewährleistet, dass neue XML Elemente (Tags) von älteren Geräten übersprungen werden, weil diese die neuen Tags nicht erkennen und interpretieren können.
• eine binäre Codierung - Diese Version ist nicht manuell lesbar/interpretierbar. Der Vorteil besteht jedoch darin, dass diese deutlich kompakter ist. Die Binär-Codierung wird deshalb vorwiegend dann verwendet, wenn Bandbreiteneffizienz höchste Priorität hat.

Grundprinzipien

Die folgenden Prinzipien sind die Grundsteine bei der Entwicklung von Syntax und Semantik von TPEG (siehe auch ISO/TS 18234-2 bzw. ISO/TS 21219-5):

• Unidirektionalität – TPEG benötigt keinen Rückkanal (ein Rückkanal muss nicht, kann aber in TPEG implementiert werden, insbesondere für Dienste über Mobilfunk bzw. IP Netze)
• Byte-Orientierung
• asynchrone Rahmenstruktur
• hierarchische Fehlerdetektion durch Cyclic Redundancy Checks (CRC) auf verschiedenen Protokollebenen
• TPEG setzt geeignete Mechanismen zur Fehlerkorrektur im Übertragungsmedium voraus
• TPEG setzt einen transparenten Datenkanal voraus
• Hierarchische Rahmenstruktur für die Codierung von Nachrichten und Diensten
• TPEG bietet Mechanismen zur Übertragung von Informationen zu Dienstanbieter, Dienst und Netzwerk
• Verschlüsselung für kommerzielle Dienste

Weitere Funktionalitäten

• Separierung von Inhalt und Übertragung im Protokolldesign
  • innerhalb der Inhaltscodierung Trennung von Nachrichteninhalt und Ortsreferenzierung
• Ortsreferenzierung sowohl über dynamische Referenzierungsmethoden (on-the-fly Location Referencing) oder über fixe Referenzpunkte auf Karten (Location Tables)
  • für dynamische (on-the-fly) Ortsreferenzierung stehen mehrere Verfahren zur Verfügung
• Sprachunabhängigkeit
• optionale Codierung der Nachrichten mit umfangreichen Attributen und Zusatzinformationen
• Möglichkeit der Filterung von Diensten und Nachrichten nach verschiedenen Kriterien
• Erweiterbarkeit um neue Dienste und Meldungstypen
• Unabhängigkeit von Datenbanken mit Ortsreferenzen (wie z. B. bei RDS-TMC notwendig)
• Decodierung von TPEG Diensten ist sowohl für leistungsfähige Endgeräte (z. B. Navigationsgeräte mit Karten und Grafikdarstellung) als auch für einfachste Geräte (z. B. ohne Karte und nur mit Textanzeige) möglich
• Anpassung an neue Übertragungsmedien leicht möglich durch Definition von Adaptation Layern

Spezifische Eigenschaften und Funktionen von TPEG

Sprachunabhängigkeit

Ein Verkehrsinformationssystem sollte in der Lage sein, die benötigte Information in der jeweiligen Sprache des Nutzers zu präsentieren.

TPEG ermöglicht diese Mehrsprachigkeit durch Verwendung von erweiterbaren Übersetzungstabellen. Hierzu werden Wörter ähnlicher Bedeutung, die in TPEG-Nachrichten öfter benötigt werden, in Tabellen zusammengefasst. Diese Wörter können in einer TPEG-Nachricht über eine Nummer referenziert werden. In einer TPEG-Meldung werden dann an Stelle von Klartext diese Referenzen übertragen. Erst auf der Clientseite wird anhand der Tabellen, die auf dem Client in der gewünschten Sprache vorliegen müssen, eine Ausgabe generiert. Dies kann eine Textmeldung in der Sprache des Nutzers, ein Symbol oder auch Sprachausgabe sein.

Z. B. werden in der TPEG-RTM Tabelle (rtm01) vehicle_type verschiedene Fahrzeuge aufgeführt, wie Car, Taxi, Bus oder Tram. Um die Erweiterbarkeit der Tabellen sicherzustellen, enthält jede Tabelle außerdem einen Standardwert. So müssen nicht alle Clients bei Erweiterung der Tabellen auf den neuesten Stand gebracht werden. Erhält ein Client, der nicht auf dem aktuellen Stand ist, eine Referenz auf einen Eintrag, der in seiner Version noch nicht enthalten ist, so wird der Standardeintrag ausgegeben. Der Nutzer ist so meist trotzdem in der Lage, eine Nachricht zu verstehen, auch wenn evtl. Details verloren gehen [TPEG].

Wird beispielsweise ein falschfahrendes Motorrad gemeldet, überträgt TPEG-RTM Referenzen auf die Einträge 19 und 7 in den Tabellen vehicle_type und vehicle_problem_type.

Würde die oben genannte Meldung an einen Client übertragen, dessen vehicle_type Tabelle den Eintrag 19 noch nicht enthält, so würde der Defaulteintrag (vehicle) verwendet. Dem Nutzer eines Navigationssystems wird also statt der Meldung „Auf der A9 in Richtung München kommt Ihnen ein Motorrad entgegen!“ eine Meldung der Art „Auf der A9 in Richtung München kommt Ihnen ein Fahrzeug entgegen!“ angezeigt.

Zur Spezifikation der Tabellen wird so genanntes CEN-English verwendet. Hierbei handelt es sich um technische Begriffe, die häufig nichts mit der englischen Umgangssprache zu tun haben und eine Definition für die einzelnen Einträge darstellen. CEN-English wird verwendet, um Verwechslungen oder Ungenauigkeiten zu vermeiden. Wegen des Unterschieds zum herkömmlichen Sprachgebrauch sollte CEN-English auch in englischsprachigen Ländern nicht direkt ausgegeben werden, sondern in die allgemein üblichen Begriffe übertragen werden. [TPEG] Ihre Grenzen findet die Sprachunabhängigkeit allerdings bei den Ortsbezeichnungen, da nicht alle denkbaren Namen in den Tabellen hinterlegt werden können. Derartige Informationen werden in Form von Strings übertragen, wobei auch hier mehrere Sprachversionen möglich sind.

Unabhängigkeit vom Kartenmaterial (TPEG-Loc)

Das Ortsreferenzierungssystem von TPEG trägt den Namen TPEG-Loc. Es wurde so konzipiert, dass es sowohl auf Clients, die über eine Ortsdatenbank verfügen, als auch auf Clients, die nicht mit Ortsdaten ausgestattet sind, möglichst präzise Ortsreferenzen erzeugt. Außerdem wurde Wert darauf gelegt, die Ortsreferenzen sowohl für Mensch als auch Maschine verständlich zu machen. Eine Ortsdatenbank oder eine Karte, mit deren Hilfe Längen- und Breitengrade in konkrete Ortsangaben umgewandelt werden können, ist für das Verstehen der TPEG-Loc-Daten nicht zwingend erforderlich.

Um die oben genannten Ziele zu erreichen, werden neben den Ortskoordinaten im Koordinatensystem WGS84 (World Geodetic System 1984) weitere Informationen übertragen, die einen Bezug zur Umgebung herstellen sollen. Die Übertragung mit Hilfe von WGS84-Koordinaten ist deshalb sinnvoll, da dieses Referenzierungssystem unter anderem von GPS verwendet wird und einen weltweiten De-facto-Standard darstellt.

Zur Beschreibung eines Punktes, der zwischen zwei Autobahnausfahrten A und B liegt, werden beispielsweise neben den Koordinaten des Punktes auch die Namen der Ausfahrten verwendet. Die Vorteile dieser Angaben liegen auf der Hand: Ein Navigationssystem erhält die genaue Information, wo sich dieser Punkt befindet. PDAs ohne Kartenmaterial hingegen können ihren Nutzern zumindest ungefähr beschreiben, dass sich der genannte Punkt zwischen den beiden Ausfahrten A und B befindet.

Unabhängigkeit vom Übertragungskanal

Da TPEG auf verschiedenen Übertragungskanälen wie beim Digital Audio Broadcasting (DAB), Digital Video Broadcasting (DVB) oder im Internet zum Einsatz kommen soll, darf die Art der Übertragung keine Rolle spielen. In der ursprünglichen TPEG-Spezifikation wurde deshalb ein Binärformat entwickelt, welches keine bestimmte Übertragungsform wie paket- oder verbindungsorientiert voraussetzt und auch keinen Rückkanal benötigt. [TPEG2] Um dies zu erreichen übernimmt das binäre TPEG-Protokoll im ISO/OSI-Schichtenmodell die Schichten 3 bis 7 selbst. TPEG ist also nur noch von den Schichten 1 und 2 abhängig. Das Übertragungsmedium selbst hat demnach nur noch die Aufgabe die einzelnen Bytes zu übertragen. Die höheren Funktionen wie das Segmentieren oder das Erkennen von Fehlern bei der Übertragung werden von TPEG selbst erledigt. [TPEG6] Die Segmentierung ist notwendig, da jede Meldung als einzelne Nachricht übertragen wird. Außerdem können so mehrere TPEG-Dienste ihre Nachrichten auf dem gleichen Kanal übertragen.

Allerdings ist hier zu beachten, dass TPEG-Clients auf Grund der Spezifikation keine Möglichkeit haben, fehlerhaft übertragene Informationen erneut anzufordern. Diese Einschränkung ist nötig, damit TPEG auch mit Übertragungsmedien ohne Rückkanal (z. B. DAB) zurechtkommt. Der Übertragungskanal sollte deshalb möglichst robust gegenüber Übertragungsfehlern sein, und Fehlerkompensationsfunktionen besitzen. Außerdem sollten die einzelnen Nachrichten nach Möglichkeit wiederholt übertragen werden.

Wegen seiner hohen Entropie eignet sich das Binärformat besonders für die Übertragung zwischen Sendestelle und Client, da dann auch Verbindungen mit niedrigen Datenraten verwendet werden können. Das Binärformat ist auch für Nutzer von Vorteil, die beispielsweise über GPRS (General Packet Radio Service) oder UMTS (Universal Mobile Telecommunications System) an einen TPEG-Provider angebunden sind, da hier häufig das Übertragungsvolumen in Rechnung gestellt wird. Außerdem ist das Format auf ressourcenschwachen Clients leichter zu dekodieren, als das später entwickelte XML-Format tpegML (tpegML steht für TPEG in XML), für dessen Verarbeitung komplexe XML-Parser nötig sind. Andererseits ist die Verwendung eines leicht handhabbaren XML-Formats vor allem auf der Seite des Contentproviders sinnvoll. Mittlerweile sind XML-Parser und Validatoren für jede verbreitete Programmiersprache verfügbar. tpegML macht sich diese Eigenschaften zu Nutze und bildet die TPEG-Datenstrukturen auf dieses leicht handhabbare Format ab. TPEG-Nachrichten können so schon während ihrer Erstellung in einem normierten Format zwischen einzelnen Systemen ausgetauscht werden. Auch kann ein Contentprovider mehrere Datenquellen abfragen und deren Informationen ohne großen Aufwand verarbeiten, wenn sich die Quellen an diese Norm halten. Trotz der Gegensätzlichkeit zwischen einem Binärstream und einer XML-Datei lassen sich die enthaltenen TPEG-Informationen beider Formate 1 zu 1 aufeinander abbilden. Die Unabhängigkeit bei der Datenübertragung im TPEG-Standard ist demnach auf zwei Arten zu interpretieren. Einerseits wurde ein Binärformat entwickelt, welches im ISO / OSI Modell schon auf der dritten Schicht einsetzt und nur die simple Übertragung von Bits voraussetzt. Andererseits gibt es mit tpegML ein XML-basiertes Datenformat, das sich einfach übertragen und vor allem verarbeiten lässt. Auch ist die Konvertierung dieses Formats dank zahlreicher Transformationsmöglichkeiten einfach durchführbar.

Datenformat

Grundsätzlich werden TPEG-Daten paketweise bzw. als einzelne Nachrichten übertragen. Da TPEG bereits auf Schicht 3 des ISO / OSI Models einsetzt, wird auch die Segmentierung von TPEG übernommen. Eine Nachricht besteht mindestens aus dem Message Management Container, welcher Steuerinformationen für eine Applikation (RTM oder PTI) enthält. Sollen neben den Steuerinformationen auch Nutzdaten übertragen werden, müssen der RTM bzw. PTI Event Container und der TPEG Location Container angehängt werden. Um eine andere Nachricht für ungültig zu erklären, wird eine Nachricht verwendet, die lediglich aus einem Message Management Container besteht. [TPEG2] Es ist zu beachten, dass sich der Message Management Container von Applikation zu Applikation unterscheiden kann.

Aufbau einer TPEG Nachricht

Message Management Container

Unter dem Begriff „Message Management“ sind alle Informationen zusammengefasst, die zur Steuerung und Verwaltung einer RTM-Nachricht dienen (Felder, die zwingend vorhanden sein müssen, sind gekennzeichnet):

• Message Identifier (obligatorisch): Anders als die Bezeichnung evtl. vermuten lässt, handelt es sich dabei nicht um eine eindeutige Bezeichnung für eine bestimmte Nachricht, sondern um eine Bezeichnung für ein Event. D. h., alle Nachrichten, die Informationen zu einem Ereignis (z. B. Stau auf einer bestimmten Straße) enthalten, haben den gleichen Message Identifier.
• Version Number (obligatorisch): Fortlaufende Zahl, welche die Reihenfolge der Nachrichten eines bestimmten Events anzeigt. Mit jeder neuen Nachricht zu einem Event wird diese Version Number um eins erhöht. Ein TPEG-Dekoder kann so die Reihenfolge der Nachrichten, die zu einem Event gehören (also den gleichen Message Identifier tragen), auch dann wiederherstellen, wenn die Nachrichten nicht in der richtigen Reihenfolge bei ihm eintreffen. Dies ist in Broadcast-Szenarien von besonderer Bedeutung, weil ein Empfänger zu einem beliebigen Zeitpunkt mit dem Abhören des Informationsstroms beginnen kann und so bereits verpasste Nachrichten einer Nachrichtensequenz erst beim wiederholten Aussenden der Nachrichten erhält.
• Message Generation Date and Time: Zeitstempel der beim Erzeugen der Nachricht angelegt wird.
• Start Date and Time: Dieser Zeitstempel gibt an, wann ein Ereignis eingetreten ist oder eintreten wird.
• Stop Date and Time: Gibt an, wann ein Event zu Ende ist bzw. war.
• Message Expiry Date and Time: Verfallsdatum einer Nachricht. Trifft eine Nachricht bei einem Client ein, deren Verfallsdatum überschritten ist, wird diese Nachricht vom Client ignoriert.
• Time Schedule Information: Hiermit kann einem Event eine zeitliche Planung zugewiesen werden. Es können ein oder mehrere Zeitintervalle angegeben werden, in denen das, in der Nachricht definierte Event stattfindet. Auch können wochentägliche Wiederholungen spezifiziert werden. So kann z. B. angegeben werden, dass ein bestimmter Streckenabschnitt an allen Wochentagen zwischen 17:00 und 21:00 Uhr gesperrt ist. Die Time Schedule Information ist nur im Zeitraum zwischen Start Date and Time und Stop Date and Time gültig.
• Severity Factor: Gibt die Wichtigkeit einer Nachricht an. Der Benutzer ist so in der Lage, eingehende Nachrichten nach ihrer Wichtigkeit zu sortieren oder unwichtige Nachrichten auszublenden.
• Unverified Information: Zeigt an, ob der Inhalt einer Nachricht verifiziert wurde, d. h. aus einer vertrauenswürdigen Quelle stammt oder durch eine vertrauenswürdige Quelle überprüft wurde.

Event Description Container

Dieser Bereich einer Nachricht enthält Informationen über das Event an sich. Die Beschreibung des Events ist hierarchisch gegliedert, so dass der Detaillierungsgrad mit jeder Hierarchiestufe zunimmt. Ein Client, der nur die erste Hierarchiestufe dekodiert erhält also nur Grobinformationen, die mit jeder zusätzlich dekodierten Stufe detailreicher werden. Dies ist sinnvoll, da beispielsweise in einer Nachrichtenübersicht nur Grobeinformationen angezeigt werden sollen. Auch können Clients, die auf Grund begrenzter Ressource nicht in der Lage sind eine komplexe Nachricht zu dekodieren, die niedrigeren Hierarchiestufen einfach ignorieren. Für die erste Ebene sind derzeit folgende Typen definiert, welche wiederum Untertypen zur genaueren Beschreibung enthalten:

• Accident: Beschreibung von Unfällen
• Obstructions: Behinderungen
• Activities: Veranstaltungen wie Umzüge oder Demonstrationen
• Road Conditions: Informationen über den Straßenzustand
• Network Performance: Informationen zum Verkehrsfluss (z. B. Stau oder zähfließender Verkehr)
• Network Conditions: Vom Normalzustand abweichende Verkehrsregeln, z. B. das temporäre Ändern der Vorfahrtsverhältnisse
• Security Alert: Sicherheitshinweise über Situationen, die den Fahrer in Gefahr bringen können (z. B. eine Bombendrohung).
• Public Transport Information: Hinweise über Störungen im öffentlichen Verkehrssystem, die Auswirkungen auf den Straßenverkehr haben können.
• Visibility: Beschreibung der Sichtverhältnisse (z. B. Nebel)
• Weather: Wetterinformationen, die die Fahrt beeinflussen (z. B. Glatteis)
• Diversion Advise: Informationen über Alternativrouten, wie Umleitungen.

Ein Event wird durch mindestens einen dieser Typen beschrieben, kann aber auch aus mehreren bestehen. Kommt es z. B. zu einem Stau wegen eines Unfalls auf Grund von Straßenschäden und schlechter Sicht, so besteht die Nachricht aus den Typen Accident, Network Performance, Road Conditions und Visibility.

TPEG-Location Container

Dieser Container enthält eine Ortsreferenz wie sie weiter oben bereits beschrieben ist (TPEG-Loc). Jede Nachricht, die mit einem Ort verknüpft ist, hat einen solchen Container.

Das Binärformat (nach TPEG2)

Dieser Abschnitt beschreibt den Teil des Binärformats, der für dieses Format spezifisch ist, d. h. für den es keine Entsprechung im XML-Format gibt. Grundsätzlich wird zwischen zwei Typen von Nachrichten, welche anhand des Felds „Frame Type“ unterschieden werden, differenziert:

• Stream directory information: Enthält eine Liste aller Serviceprovider, die in diesem Stream aktiv sind.
• Conventional service frame data: enthält Nutzdaten

Neben Frame Type enthält eine binäre TPEG Nachricht weitere Felder, die im Folgenden erläutert werden:

• Sync Word (2 Bytes): dient dem Decoder zur Erkennung einer neuen Nachricht. Dieses Sync Word hat immer den Wert FF0F hex.
• Field Length (2 Bytes): Gesamtlänge des Services Frames in Bytes. Ein Service Frame kann somit nicht größer als 65535 Bytes sein.
• Frame Type (1 Byte): sorgt für die weiter oben besprochene Unterscheidung zwischen „Stream directory information“ und „Conventional service frame data“.
• Header CRC: Prüfsumme um die Korrektheit der Headerdaten sicherzustellen. Diese Summe wird anhand der Felder Sync Word, Field Length, Frame Type und der ersten 11 Byte des Service Frames berechnet. Nähere Informationen zu dieser Berechnung finden sich in [TPEG2].
• Service Frame: enthält die Nutzdaten (evtl. in verschlüsselter Form) sowie die Service Identifier. Über die Service Identifier (SID) kann ein Contentprovider eindeutig identifiziert werden. Das Service Frame wird wiederum in folgende Bestandteile unterteilt:
  • SID-A bis C (je 1 Byte): ergeben zusammen eine eindeutige Identifikationsnummer eines Service Providers, vergleichbar mit einer IP-Adresse, z. B. 133.168.123.
  • Encryption-Indikator (1 Byte): spezifiziert anhand eines Wertes zwischen 0 und 255 eine Verschlüsselungsmethode. Die Werte 0 bis 127 sind dabei für standardisierte Methoden vorbehalten. 128–255 sind für die freie Verwendung durch einen Service Provider vorgesehen. Die Verschlüsselung kann z. B. genutzt werden, um kostenpflichtige Dienste zu entwickeln. Auch wäre die Verwendung verschlüsselter Nachrichten evtl. bei sicherheitskritischen Anwendungen, wie z. B. Polizei- oder Militärfunk nutzbar.
  • Component Multiplex: Dieser evtl. verschlüsselte Datenbereich enthält dann die eigentlichen TPEG-Nachrichten, wie sie zu Beginn von Kapitel 3 beschrieben sind. Solange die Maximalgröße von 65531 Bytes nicht überschritten wird, kann dieser Bereich mehrere Nachrichten aufnehmen. Die Kodierung dieser Daten ist der Spezifikation zu entnehmen.

TPEG2 Anwendungen

ISO Nr.	ISO Referenz	Titel	Akronym	Beschreibung
21219-1	Part 1: Introduction, numbering and versions	Einführung und Nomenklatur für TPEG Generation 2 Komponenten und Dienste, einschließlich der Application Identification (AID).
21219-2	Part 2: UML modelling rules	Syntax und Semantik von TPEG Diensten, unabhängig vom physikalischen Datenformat (binär oder XML).
21219-3	Part 3: UML to binary conversion rules	TPEG Dienste werden in UML modelliert um die Unabhängigkeit von der konkreten Codierung (binär bzw. XML) zu gewährleisten. Durch die Trennung von Semantik und Anwendungsbeschreibung können Funktionen einfach und einheitlich für beide Codierungen entwickelt werden. Die Codierformate werden dann mit Übersetzungstools (Code-Generatoren) direkt aus der UML-Beschreibung heraus erzeugt.
21219-4	Part 4: UML to XML conversion rules	Regelwerk für die Konvertierung von TPEG UML Beschreibungen in das XML Format.
21219-5	Part 5: Service framework	Beschreibung für die Zusammenstellung (Multiplexing) von Dienstangeboten (Bouquets) aus verschiedenen Einzeldiensten.
21219-6	Part 6: Message management container	Nachrichtenverwaltung im Endgerät
21219-7	Part 7: Location referencing container	Der TPEG2 Container für Ortsreferenzierungen (Location Referencing Container) zeigt an, welche Referenzierungsmethode verwendet wird. Unterschiedliche Methoden können für die Ortsreferenzierung eingebettet werden.
21219-9	Part 9: Service and network information	Codierung der Anzeige von Dienstanbieter, Dienst, Dienstkomponenten und Trägermedium. Kann auch verwendet werden, um gleiche oder verwandte Dienste über andere Trägermedien zu verknüpfen (Service Linking).
21219-10	Part 10: Conditional access information	Funktionen zur Verschlüsselung kommerzieller Dienste
21219-11	Part 11: Universal location referencing	Universelle Ortsreferenzierungsmethode
21219-14	Part 14: Parking information application	Informationen zu Parkplätzen und Parkhäusern (Ort, Öffnungszeiten, Anzahl freier Plätze etc.)
21219-15	Part 15: Traffic event compact application	TEC	Kompakte Repräsentation von Ereignismeldungen, speziell für die Verarbeitung in Navigationsgeräten und zur Unterstützung von dynamischer Routenänderung (Umleitungsempfehlung)
21219-16	Part 16: Fuel price information application	Informationen zu Tankstellen und Kraftstoffpreisen
21219-18	Part 18: Traffic flow and prediction application	TFP	Kompakte Repräsentation von Verkehrsflussinformationen, speziell für die Verarbeitung in Navigationsgeräten und zur Unterstützung von dynamischer Routenänderung (Umleitungsempfehlung)
21219-19	Part 19: Weather information application	Wetterinformationen
21219-20	Part 20: Extended TMC location referencing	Erweiterung für Ortsreferenzierung mit fixen Ortsreferenzierungstabellen (TMC Location Tables), speziell für die Anwendung im Zusammenhang mit TEC
21219-21	Part 21: Geographic location referencing	Ortsreferenzierungsmethode für Gebiete und Punkte unabhängig von Straßen
21219-22	Part 22: OpenLR location referencing	Ortsreferenzierungsmethode
21219-23	Part 23: Road and multimodal routes application	Multimodale Routeninformationen

TPEG Dienste Weltweit

Rundfunkverbreitung

Land	Dienstanbieter	Status	Produkt	TPEG Dienste
Belgien	Be-Mobile	Live	Premium	TEC / TFP
Deutschland	ARD	Live	Free to Air	TEC / TFP
Deutschland	HERE	zum 01.05.2022 eingestellt	Premium	TEC / TFP
Deutschland	Mediamobile	Live	v-traffic	TEC / TFP
Luxemburg	Be-Mobile	Live	Premium	TEC / TFP
Niederlande	Be-Mobile	Live	Premium	TEC / TFP
Norwegen	Mediamobile	Live	v-traffic	TEC / TFP
Schweiz	SRG	Live	Free to Air
Vereinigtes Königreich	Inrix	Live	Premium	TEC / TFP
Vereinigtes Königreich	Trafficmaster	Live	Premium	TEC
Testausstrahlungen
Frankreich	Mediamobile	Trial (in some cities)	v-traffic	TEC / TFP
Italien	Infoblu	Trial	Premium	TEC / TFP
Polen	Mediamobile	Trial	v-traffic	TEC / TFP
Schweden	Mediamobile	Trial	v-traffic	TEC / TFP

Mobilfunkverbreitung

Land	Dienstanbieter	Status	Produkt	TPEG Dienste
Andorra	Tomtom	Live	Premium	TEC / TFP / WEA
Argentinien	HERE	Live	Premium	TEC / TFP
Australien	HERE	Live	Premium	TEC / TFP
Australien	Tomtom	Live	Premium	TEC / TFP /WEA
Österreich	HERE	Live	Premium	TEC / TFP
Österreich	Tomtom	Live	Premium	TEC / TFP /WEA
Belgien	HERE	Live	Premium	TEC / TFP
Belgien	Tomtom	Live	Premium	TEC / TFP /WEA
Brasilien	HERE	Live	Premium	TEC / TFP
Brasilien	Tomtom	Live	Premium	TEC / TFP /WEA
Kanada	HERE	Live	Premium	TEC / TFP
Kanada	Tomtom	Live	Premium	TEC / TFP /WEA
Chile	Tomtom	Live	Premium	TEC / TFP /WEA
China	Tomtom	Live	Premium	TEC / TFP /WEA
Tschechien	HERE	Live	Premium	TEC / TFP
Tschechien	Tomtom	Live	Premium	TEC / TFP /WEA
Kroatien	HERE	Live	Premium	TEC / TFP
Dänemark	HERE	Live	Premium	TEC / TFP
Dänemark	Tomtom	Live	Premium	TEC / TFP /WEA
Finnland	HERE	Live	Premium	TEC / TFP
Finnland	Tomtom	Live	Premium	TEC / TFP /WEA
Frankreich	HERE	Live	Premium	TEC / TFP
Frankreich	Tomtom	Live	Premium	TEC / TFP /WEA
Deutschland	Tomtom	Live	Premium	TEC / TFP /WEA
Deutschland	HERE	Live	Premium	TEC / TFP
Deutschland	Inrix	Live	Premium	TEC / TFP
Gibraltar	Tomtom	Live	Premium	TEC / TFP /WEA
Griechenland	HERE	Live	Premium	TEC / TFP
Ungarn	HERE	Live	Premium	TEC / TFP
Indien	HERE	Live	Premium	TEC / TFP
Indonesien	HERE	Live	Premium	TEC / TFP
Irland	HERE	Live	Premium	TEC / TFP
Irland	Tomtom	Live	Premium	TEC / TFP /WEA
Italien	HERE	Live	Premium	TEC / TFP
Italien	Tomtom	Live	Premium	TEC / TFP /WEA
Lesotho	Tomtom	Live	Premium	TEC / TFP /WEA
Liechtenstein	Tomtom	Live	Premium	TEC / TFP /WEA
Luxemburg	HERE	Live	Premium	TEC / TFP
Luxemburg	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
Mexiko	HERE	Live	Premium	TEC / TFP
Mexiko	Tomtom	Live	Premium	TEC / TFP /WEA
Monaco	Tomtom	Live	Premium	TEC / TFP /WEA
Niederlande	HERE	Live	Premium	TEC / TFP
Niederlande	Tomtom	Live	Premium	TEC / TFP /WEA
Neuseeland	HERE	Live	Premium	TEC / TFP
Neuseeland	Tomtom	Live	Premium	TEC / TFP /WEA
Norwegen	HERE	Live	Premium	TEC / TFP
Norwegen	Tomtom	Live	Premium	TEC / TFP /WEA
Polen	HERE	Live	Premium	TEC / TFP
Polen	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
Russland	HERE	Live	Premium	TEC / TFP
Russland	Tomtom	Live	Premium	TEC / TFP /WEA
San Marino	Tomtom	Live	Premium	TEC / TFP /WEA
Saudi-Arabien	HERE	Live	Premium	TEC / TFP
Saudi-Arabien	Tomtom	Live	Premium	TEC / TFP /WEA
Singapur	HERE	Live	Premium	TEC / TFP
Singapur	Tomtom	Live	Premium	TEC / TFP /WEA
Slowakei	HERE	Live	Premium	TEC / TFP
Slowenien	HERE	Live	Premium	TEC / TFP
Südafrika	HERE	Live	Premium	TEC / TFP
Südafrika	Tomtom	Live	Premium	TEC / TFP /WEA
Südkorea	HERE	Live	Premium	TEC / TFP
Spanien	HERE	Live	Premium	TEC / TFP
Spanien	Tomtom	Live	Premium	TEC / TFP /WEA
Schweden	HERE	Live	Premium	TEC / TFP
Schweden	Tomtom	Live	Premium	TEC / TFP /WEA
Schweiz	HERE	Live	Premium	TEC / TFP
Schweiz	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
Türkei	HERE	Live	Premium	TEC / TFP
Türkei	Tomtom	Live	Premium	TEC / TFP /WEA
Ukraine	HERE	Live	Premium	TEC / TFP
Vereinigte Arabische Emirate	HERE	Live	Premium	TEC / TFP
Vereinigte Arabische Emirate	Tomtom	Live	Premium	TEC / TFP /WEA
Vereinigtes Königreich	HERE	Live	Premium	TEC / TFP
Vereinigtes Königreich	Tomtom	Live	Premium	TEC / TFP /WEA
USA	HERE	Live	Premium	TEC / TFP
USA	Tomtom	Live	Premium	TEC / TFP /WEA
Vatikan	Tomtom	Live	Premium	TEC / TFP /WEA

Hybride Dienste (Rundfunk + Mobilfunk)

Land	Dienstanbieter	Status	Produkt	TPEG Dienste
United States	Total Traffic and Weather Network	Live	TTN HD-Hybrid	TEC / TFP / FPI

Literatur

• 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

Weblinks

• http://www.tisa.org Neue offizielle Website der TMC und TPEG Forum Nachfolgeorganisation
• Website für effiziente Verkehrsinformationsdienste. (Nicht mehr online verfügbar.) In: mobile-info.org. Archiviert vom Original am 3. April 2010; abgerufen am 13. Dezember 2018 (englisch). 
• http://www.bmt-online.de Weitere Infos zu TPEG
• http://www.wecantpeg.com Schulungen und Infos zu TPEG

Einzelnachweise

1. EBU Technology&Innovation – TPEG (englisch, abgerufen am 18. August 2014).
2. Broadcast.ch. Abgerufen am 1. Juni 2022. 
3. Umstellung der DAB-Verkehrsinfo-Services von Anbieter HERE auf ARD. Abgerufen am 17. Mai 2023.