Transport Protocol Experts Group – Wikipedia

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[Bearbeiten | Quelltext bearbeiten]

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^[1] 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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

• 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[Bearbeiten | Quelltext bearbeiten]

Sprachunabhängigkeit[Bearbeiten | Quelltext bearbeiten]

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)[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

Message Management Container[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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)[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

TPEG Dienste Weltweit[Bearbeiten | Quelltext bearbeiten]

Rundfunkverbreitung[Bearbeiten | Quelltext bearbeiten]

Mobilfunkverbreitung[Bearbeiten | Quelltext bearbeiten]

Hybride Dienste (Rundfunk + Mobilfunk)[Bearbeiten | Quelltext bearbeiten]

Literatur[Bearbeiten | Quelltext bearbeiten]

• 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[Bearbeiten | Quelltext bearbeiten]

• http://www.tisa.org Neue offizielle Website der TMC und TPEG Forum Nachfolgeorganisation
• Mobile Platform for Efficient Traffic Information Services. Website für effiziente Verkehrsinformationsdienste. In: mobile-info.org. Archiviert vom Original (nicht mehr online verfügbar) 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[Bearbeiten | Quelltext bearbeiten]

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.