-
Technisches Gebiet
-
Die vorliegende Erfindung betrifft ein Datenformat für das Übertragen von digitalen Rundfunksignalen auf D[igital]A[udio]B[roadcasting]-Basis, aufweisend
- – mindestens ein Typenfeld,
- – mindestens ein Datenlängefeld,
- – mindestens ein auch für T[raffic]M[essage]C[hannel]-Daten ausgelegtes Datenfeld und
- – mindestens ein Zusatzdatenfeld.
-
Die vorliegende Erfindung betrifft des weiteren ein digitales Rundfunksignal auf D[igital]A[udio]B[roadcasting]-Basis, insbesondere ein DAB-Ensemble oder einen DAB-Multiplex, ein Informationssystem zum Empfangen und zum Verarbeiten derartiger digitaler Rundfunksignale sowie ein Verfahren zum Betreiben eines derartigen Informationssystems.
-
Stand der Technik
-
Neben D[igital]A[udio]B[roadcasting] (= digitaler Hörfunk) erlaubt auch R[adio]D[ata]S[ystem] (= Radio-Daten-System) das Übertragen digitaler Zusatzdienste zusätzlich zum eigentlichen Hörfunkprogramm. Aufgrund der unterschiedlichen technischen Gegebenheiten, das heißt einer hohen Datenrate in DAB und einer niedrigen Datenrate in RDS unterscheiden sich die Datenformate wie auch die Dateninhalte zwischen DAB und RDS erheblich.
-
Um die erforderliche Entwicklungsarbeit hinsichtlich zusätzlicher Dekoder-Software so gering wie möglich zu halten, ergab sich die bislang einzige Gemeinsamkeit der Dateninhalte zwischen DAB und RDS bei T[raffic]M[essage]C[hannel] (= Kanal für Verkehrsdurchsagen = Verkehrsfunkkanal mit automatisierter Erfassung der Verkehrslage und mit Aufbereitung entsprechender Verkehrsmeldungen). In diesem Zusammenhang wird die in RDS bereits seit geraumer Zeit praktizierte Übertragung von kodierten Verkehrsinformationen und -nachrichten in T[raffic]M[essage]C[hannel] als durchaus interessante Erweiterung des DAB-Systems angesehen.
-
Grundsätzlich handelt es sich bei TMC um einen Datenkanal, der bei DAB im F[ast]I[nformation]C[hannel] (= schneller Informationskanal) mitgesendet wird; dies hat den Vorteil, daß die Daten ohne Verzögerungen, wie sie etwa bei M[ultimedia]O[bject]T[ransfer] (= Konzept zum Übertragen von Multimedia-Dateien) vorkommen, ausgestrahlt werden, was etwa für Falschfahrermeldungen besonders wichtig ist.
-
Die Daten im TMC sind stark komprimiert und bezeichnen nur bestimmte Meldungstypen sowie bestimmte Straßenpositionen entsprechend einer Nummernliste. Der Empfänger muß diese Nummern wieder in normalsprachliche Meldungen übersetzen. Das System wurde ursprünglich für U[ltra]K[urz]W[elle]-RDS entwickelt und genutzt. Trotz der starken Komprimierung konnten bei UKW-RDS aber aus Kapazitätsgründen nur Informationen für die wichtigsten Straßen übertragen werden.
-
Bei DAB stehen mehr Kapazitäten zur Verfügung, um die TMC-Daten öfter sowie schneller zu senden und dennoch alle Meldungen von allen Straßen mitzusenden, so daß auch Ausweichempfehlungen und Staumeldungen für Ausweichrouten und für Nebenstrecken mit übertragen werden können.
-
In bezug auf für derartige digitale Rundfunksignale ausgelegte Informationssysteme ist des weiteren zu bedenken, daß diese heutzutage die Möglichkeit haben, Informationen sowohl in Textform als auch in Symbolform in einer Karte darzustellen. Zur Zeit dient diese Fähigkeit – jedenfalls bei Rundfunkempfangsgeräten oder bei Navigationsgeräten – jedoch ausschließlich dazu, vorgenannte Verkehrsmeldungen auf TMC-Basis sowie statische Daten, wie etwa sogenannte ”Points of Interest” (POI), das heißt Flughäfen, Tankstellen, Werkstätten oder dergleichen, in Abhängigkeit vom System als Text oder als Symbol anzuzeigen.
-
Hierbei belegen die im Radio-Daten-System (RDS) gemäß TMC-Standard übertragenen Verkehrsinformationen, daß es trotz der beschränkten Datenkapazität von weniger als 300 Bit pro Sekunde möglich ist, aktuelle Informationen auf diesem Wege verfügbar zu machen.
-
Neben den Verkehrsinformationen wären für viele Nutzer aber auch weitere Daten, Informationen und Dienste von gesteigerter Bedeutung. Die Wiedergabe derartiger zusätzlicher Daten, Informationen und Dienste gewissermaßen ”auf Knopfdruck” ist daher aus Sicht des Nutzers eine besonders erstrebenswerte Funktion. Allerdings hat es sich bislang nicht als möglich erwiesen, auch andere im RDS verfügbare (Zusatz-)Dienste im DAB zu realisieren und dem Nutzer zur Verfügung zu stellen.
-
Der DAB Standard ist in der ETSI EN 300 401 veröffentlicht. Darin wird u. a. ein Datenformat für das Übertragen von digitalen Rundfunksignalen auf DAB Basis definiert.
-
In der
DE 198 58 568 A1 wird eine Einrichtung zur Übertragung von Fahrtroutenempfehlungen zu Empfängern beschrieben.
-
Die
US 6,018,772 beschreibt eine Vorrichtung sowie ein Verfahren zur Übertragung von Daten durch wieder zuweisbare Gruppen.
-
Darstellung der Erfindung: Aufgabe, Lösung, Vorteile
-
Ausgehend von den vorstehend dargelegten Nachteilen und Unzulänglichkeiten sowie unter Würdigung des umrissenen Standes der Technik liegt der vorliegenden Erfindung die Aufgabe zugrunde, ein Datenformat der eingangs genannten Art, ein digitales Rundfunksignal der eingangs genannten Art, ein Informationssystem der eingangs genannten Art sowie ein Verfahren der eingangs genannten Art so weiterzuentwickeln, daß neben TMC auch andere RDS-Zusatzdienste im DAB ermöglicht werden (hierbei soll nicht die Übertragung RDS-spezifischer Daten, wie etwa A[lternative]F[requencies], P[rogramme]I[dentity code] oder P[rogramme]S[ervice name], betroffen sein), so daß die Wiedergabe dieser Zusatzdienste gewissermaßen ”auf Knopfdruck” technisch realisierbar ist und die dann im Informationssystem vorhandenen Daten sinnvollerweise für Anzeigezwecke, im Bedarfsfalle auch für Navigationszwecke, genutzt werden können.
-
In diesem Zusammenhang zielt die vorliegende Erfindung des weiteren darauf ab, ein Datenformat der eingangs genannten Art, ein digitales Rundfunksignal der eingangs genannten Art, ein Informationssystem der eingangs genannten Art sowie ein Verfahren der eingangs genannten Art zur Verfügung zu stellen, die trotz der Implementierung dieser Kriterien erschwinglich bleiben und deren Funktionalität sich gut mit der Funktionalität bereits bestehender Systeme ergänzt.
-
Diese Aufgabe wird gemäß der Lehre der vorliegenden Erfindung
- – durch ein Datenformat mit den im Anspruch 1 genannten Merkmalen,
- – durch ein digitales Rundfunksignal mit den im Anspruch 5 genannten Merkmalen,
- – durch ein Informationssystem mit den im Anspruch 6 genannten Merkmalen sowie
- – durch ein Verfahren mit den im Anspruch 10 genannten Merkmalen
gelöst. Vorteilhafte Ausgestaltungen und zweckmäßige Weiterbildungen der vorliegenden Erfindung sind in den jeweiligen Unteransprüchen gekennzeichnet.
-
Mithin ist der erfindungswesentliche Kern in dem Kriterium zu sehen, daß RDS-Daten in DAB nutzbar sind, so daß neben TMC auch andere RDS-Dienste, wie etwa E[mergency]W[arning]S[ystem] (= Notfall-Warnsystem) oder Paging, im DAB ermöglicht werden.
-
Erfindungsgemäß wird dies erreicht, indem das Datenfeld des eingangs vorgestellten Datenformats zusätzlich für auf R[adio]D[ata]S[ystem]-Basis übermittelbare Dienste, insbesondere für programmbegleitende Datendienste oder programmunabhängige Datendienste, ausgelegt wird, und zwar vorzugsweise unabhängig davon, ob die digitalen Daten im sogenannten ”packet mode” (= nicht-kontinuierlicher Datenstrom bei wechselnder Bandbreite) oder im stream mode (= kontinuierlicher Datenstrom bei kontinuierlicher Bandbreite; Audiodaten der Radioprogramme werden grundsätzlich im stream mode übertragen) übertragen werden.
-
Ein wesentlicher Vorteil der vorliegenden Erfindung ist darin zu sehen, daß für beliebige, nunmehr in DAB einsetzbare und nutzbare Zusatzdienste keine gesonderte Software zum Dekodieren entwickelt werden muß; vielmehr bleibt der Datenkanal für externe Applikationen völlig transparent.
-
Des weiteren wird der Fachmann auf dem technischen Gebiet der digitalen Signalübermittlung insbesondere zu schätzen wissen, daß sich die Übertragungszeit für einen kompletten Zyklus infolge der höheren Übertragungsbandbreite bei DAB um etwa den Faktor zehn verringert.
-
Aufgrund von Zykluszeiten von mehreren Minuten wurden bislang in RDS im Regelfall nur Dienste ausgesendet, die auf das jeweilige Bundesland zugeschnitten waren; die vorliegende Implementierung des gesamten Spektrums verfügbarer RDS-Dienste in DAB hingegen bietet die Möglichkeit, einheitliche und bundesweite RDS-Dienste anzubieten.
-
Als weiterer Vorzug ist zu berücksichtigen, daß das DAB-System eine erheblich höhere Sicherheit bei der Übertragung insbesondere in schwierigen Empfangssituationen bietet; dies erhöht zusätzlich den Datendurchsatz.
-
Technische Grundlage für die vorbeschriebene Nutzung von RDS-Datendiensten in DAB ist, daß in den vergangenen Jahren für RDS die Funktionalität der sogenannten O[pen]D[ata]A[pplication]-Application entwickelt und in der erweiterten RDS-Norm EN 50067:1998 bzw. IEC 62106:2000 standardisiert wurde.
-
Mit dem Prinzip gemäß der vorliegenden Erfindung, das heißt mit einem speziellen ODA-Dienst muß die Kodierung nicht geändert werden, das heißt die Orts- und Ereignislisten sowie das Meldungsmanagement gemäß dem ALERT-C-Protokoll (ALERT = Advice and problem Location for European Road Traffic) sind unverändert auch für die RDS-Dienste in DAB anwendbar.
-
Hierbei wirkt sich für die vorliegende Erfindung als günstig aus, daß das ALERT-C-Protokoll als festgelegtes Protokoll zum Transport der Meldungen von der Erfassung bis zum Funkhaus genau auf die RDS-Übertragung zugeschnitten ist. Es werden komprimierte Informationen im neutralen Datenformat übertragen, sozusagen Adressen, die in der Empfangseinheit gemäß der vorliegenden Erfindung dann in die Landessprache expandiert werden; die Ausgabe kann dann auf Papier, auf einem Display oder auf einem Vo[ice]coder (= Sprachkodierer) erfolgen.
-
Die vorbeschriebene ODA-Application ermöglichte es bislang allerdings nur, über die A[pplication]IDdentification]D[ata] beliebige Zusatzdienste in RDS zu realisieren. Hierzu wurden beispielsweise in RDS-Gruppentyp 3A die AID als Identifikation für den auf diesem Kanal ausgestrahlten Zusatzdienst übertragen. Für TMC mit ALERT-C ist dies CD46, für TMC mit ALERT-Plus und ALERT-C gemischt ist dies 4B02, der Testmodus für ALERT-C hat die Kennung 0D45.
-
Nachdem in der Vergangenheit in DAB als Zusatzdienst in F[ast]I[nformation]G[roup] 5/1 ausschließlich ALERT-C mit CD46 übertragen worden war, wurde dies erweitert, indem unter FIG 0/13 (vgl. 1A) zusätzlich die AID für andere TMC-Modi signalisiert wurden; allerdings war man hiermit auf ausschließliche TMC-Dienste festgelegt, und weitere RDS-Dienste über DAB waren blockiert.
-
Aus diesem Grunde wird erfindungsgemäß vorgeschlagen, das Datenformat bzw. die Datenstruktur so anzupassen, daß alle in RDS möglichen Zusatzdienste auch über DAB realisiert werden. Zu diesem Zwecke werden in FIG 0/13 nicht nur AID für TMC übertragen, sondern FIG 0/13 wird nun so definiert, daß jede beliebige AID dort signalisiert wird.
-
Gemäß einer besonders vorteilhaften Weiterbildung des vorliegenden Datenformats kann in einem weiteren Datenfeld (ein Byte) noch der Gruppentyp aus RDS übertragen werden, um den Dienst eineindeutig zu kennzeichnen. Hierdurch ist es möglich, ohne zusätzlichen Aufwand an Software jeden beliebigen RDS-Dienst auch in FIG 5/1 über DAB zu übertragen, denn auch in DAB unter FIG 5/1 sind lediglich 37 Bit lange Felder (= 37 verfügbare Bits pro Gruppe) zu definieren; gegebenenfalls kann auch eine weitere FIG, wie etwa FIG 5/3, für andere RDS Dienste genutzt werden.
-
Gemäß einer besonders erfinderischen Weiterbildung ermöglicht mindestens ein sogenannter D[igital]R[adio]S[erver] die Aufbereitung und Einspeisung von RDS-Diensten in das DAB-System. Aus einer beliebigen RDS-Quelle werden Meldungen zum Beispiel über das Internet dem DAB-System zugeführt und gemeinsam mit den Systeminformationen, die unter anderem Auskunft über den Anbieter des Dienstes enthalten, in einen sendefähigen Zyklus zusammengeführt. Die Codierung des Zyklus erfolgt gemäß der DAB-Spezifikation EN 300 401 in der F[ast]I[nformation]G[roup] 5/1.
-
Im Ergebnis können also RDS-(Zusatz-)Dienste in der erfindungsgemäß ausgelegten Empfangseinheit des Informationssystems, insbesondere des Navigationssystems, jederzeit abrufbar vorgehalten werden; demzufolge sind erfindungswesentliche Voraussetzungen erfüllt, um nicht nur den digitalen Rundfunk selbst, sondern auch assoziierte Zusatzdienste auf RDS-Basis zu individualisieren. Die Empfangseinheiten können – bei Vorliegen entsprechend großer Speicher – routenrelevante Meldungen aus einer Datenbank suchen und beispielsweise dem Führer eines Fortbewegungsmittels auf Knopfdruck in seiner Muttersprache mitteilen.
-
Des weiteren wird durch die optionale Nutzung von ALERT-C für die Kodierung mithin der Zusatzdienst sprachunabhängig, so daß der Nutzer der vorliegenden Erfindung den Wetterbericht beispielsweise auch bei Reisen im Ausland in seiner Muttersprache erhält.
-
Ein weiterer Nutzen der vorliegenden Erfindung ist im Verbinden der RDS-Funktionalität mit einer automatischen Umwandlung in DAB-Meldungen zu sehen. Durch dieses Verbinden lassen sich Kosten für das Aufbereiten der Meldungen senken; des weiteren kann hierdurch gleichzeitig die Aktualität der Meldungen erhöht werden.
-
Eine erfindungswesentliche Eigenschaft des vorliegenden Gegenstands besteht ferner darin, daß als sogenannte ”Locationcodes” gerade die beim RDS-Prinzip selten genutzten Gebiete relevant sind. Die zusätzlichen Datendienste sollten sich hierbei auf administrative Gebiete, wie etwa Bundesländer, Regierungsbezirke oder dergleichen, aber auch auf vorhandene touristische Großräume, wie etwa auf den Bayerischen Wald oder auf die Lüneburger Heide, beziehen.
-
Im Ergebnis ist die für das RDS-/DAB-Prinzip gemäß der vorliegenden Erfindung benötigte Teilmenge der Ortsliste regelmäßig sehr klein, etwa von der Größenordnung hundert Einträge, so daß spezielle Datenträger für die Nutzung des RDS-/DAB-Prinzips problemlos mehrere solcher spezialisierter, das heißt an das RDS-/DAB-Prinzip angepaßter Ortslisten umfassen können (so kann sich der Umfang etwa auf alle Staaten Europas erstrecken).
-
Eine ähnliche Situation findet sich bei der Ereignisliste, bei der auch lediglich eine kleine Untermenge aller vorhandenen Ereignisse für TMC benötigt wird. Als Folge sind die für eine Sprachausgabe benötigten Datenmengen relativ gering, was zu reduzierten Kosten auf der Endgeräteseite, insbesondere hinsichtlich der Empfangseinheit, führt. Für kombinierte RDS-/DAB-Empfangseinheiten bedeutet dies, daß der Mehraufwand für das Implementieren der weiteren RDS-Zusatzdienste gegenüber TMC gering ist.
-
Eine Erweiterung des Informationssystems gemäß der vorliegenden Erfindung ist insoweit möglich, als bei einer bevorzugten Ausbildung des Informationssystems als Navigationssystem bei der Routenberechnung zweckmäßigerweise aktuelle RDS-Dienste Berücksichtigung finden können. So können etwa im Rahmen von E[mergency]W[arning]S[ystem] Gebiete, die gerade überschwemmt oder eingeschneit sind oder sonstige Gefahrenquellen, wie etwa Großfeuer oder Tornados in den USA, beinhalten, umfahren werden.
-
Der Vorteil für den Benutzer, der beispielsweise auch mittels des Paging-Dienstes jederzeit benachrichtigbar ist, ist hier unter anderem darin zu sehen, daß etwa schon bei der Anreise aktuelle Daten und Informationen des Zielgebiets abgefragt und – etwa in Unwettersituationen – bestimmte Bereiche zielgerichtet gemieden werden können.
-
In bezug auf den Fortschritt sowie auf den Nutzen bei der vorliegenden Erfindung ist zu bedenken, daß insbesondere durch das gesteigerte Interesse der Automobilindustrie an der Dynamisierung der in einigen Fahrzeugtypen bereits serienmäßig eingebauten Navigationssysteme die Aussendung von RDS-DAB eine zusätzliche Motivation zur Ausstattung von Fortbewegungsmitteln mit DAB-Empfängern darstellt.
-
Ein Verfahren zum Betreiben mindestens einer mindestens einem Informationssystem gemäß der vorstehend dargelegten Art zugeordneten Empfangseinheit, insbesondere Rundfunkempfangseinheit, zum Empfangen von als O[pen]D[ata]A[pplication]-Applikation kodiert übertragenen digitalen Daten und Informationen, weist die folgenden Schritte auf:
- (i) Starten und
Gehen zu Schritt (ii);
- (ii) Initialisieren und
Gehen zu Schritt (iii);
- (iii) Aktivieren des Empfangens von als O[pen]D[ata]A[pplication]-Applikation kodiert übertragenen digitalen Daten und Informationen:
– wenn ja (+), dann Gehen zu Schritt (iv);
– wenn nein (–), dann Gehen zu Schritt (x);
- (iv) Suchen mindestens eines dem Empfangen von als O[pen]D[ata]A[pplication]-Applikation kodiert übertragenen digitalen Daten und Informationen zugeordneten Gruppentyps, insbesondere R[adio]D[ata]S[ystem]-Gruppentyps, und
Gehen zu Schritt (v);
- (v) Finden eines dem Empfangen von als O[pen]D[ata]A[pplication]-Applikation kodiert übertragenen digitalen Daten und Informationen zugeordneten Gruppentyps, insbesondere R[adio]D[ata]S[ystem]-Gruppentyps, mit zutreffender Anwendungskennung (= A[pplication]ID[entification]):
– wenn ja (+), dann Gehen zu Schritt (vi);
– wenn nein (–), dann
- (xii) Deaktivieren des Empfangens von als O[pen]D[ata]A[pplication]-Applikation kodiert übertragenen digitalen Daten und Informationen und
Gehen zu Schritt (x);
- (vi) Anzeigen mindestens eines/r als O[pen]D[ata]A[pplication]-Applikation kodiert übertragenen digitalen Daten und Informationen zugeordneten Textes, Tabelle, Graphik, Symbols oder dergleichen in der Ausgabeeinheit (80) und
Gehen zu Schritt (vii);
- (vii) Sammeln von auf R[adio]D[ata]S[ystem]-Basis übermittelten Diensten, insbesondere von programmbegleitenden Datendiensten oder von programmunabhängigen Datendiensten, wie etwa E[mergency]W[arning]S[ystem] oder Paging, und
Gehen zu Schritt (viii);
- (viii) Abrufen der Dienste:
– wenn ja (+), dann
- (xiii) Anzeigen der als O[pen]D[ata]A[pplication]-Applikation kodiert übertragenen digitalen Daten und Informationen in der Ausgabeeinheit (80) und
Gehen zu Schritt (ix);
– wenn nein (–), dann Gehen zu Schritt (ix);
- (ix) Wechseln des Senders:
– wenn ja (+), dann Gehen vor Schritt (iv);
– wenn nein (–), dann Gehen zu Schritt (x);
- (x) Empfangen von als O[pen]D[ata]A[pplication]-Applikation kodiert übertragenen digitalen Daten und Informationen, noch im Aktivierungszustand:
– wenn ja (+), dann Gehen vor Schritt (vii);
– wenn nein (–), dann Gehen zu Schritt (xi);
- (xi) Beenden.
-
Kurze Beschreibung der Zeichnungen
-
Wie bereits vorstehend erörtert, gibt es verschiedene Möglichkeiten, die Lehre der vorliegenden Erfindung in vorteilhafter Weise auszugestalten und weiterzubilden. Hierzu wird einerseits auf die den Ansprüchen 1 und 6 nachgeordneten Ansprüche verwiesen, andererseits werden weitere Ausgestaltungen, Merkmale und Vorteile der vorliegenden Erfindung nachstehend anhand des durch die 1B bis 4 veranschaulichten Ausführungsbeispiels näher erläutert.
-
Es zeigt:
-
1A in schematischer Prinzipdarstellung die Definition eines Datenformats (”user application definition”) unter F[ast]I[nformation]G[roup] 0/13 gemäß dem Stand der Technik (z. B. DAB-Spezifikation EN 300 401);
-
1B in schematischer Prinzipdarstellung die Definition eines Datenformats (”user application definition”) unter F[ast]I[nformation]G[roup] 0/13 gemäß der vorliegenden Erfindung;
-
2 in schematischer Prinzipdarstellung die Definition einer dem Datenformat aus 1B zugeordneten Datenstruktur gemäß der vorliegenden Erfindung;
-
3 in schematischer Prinzipdarstellung ein Ausführungsbeispiel eines Informationssystems gemäß der vorliegenden Erfindung, das digitale Daten gemäß den 1B und 2 empfangen und verarbeiten kann; und
-
4 in schematischer Blockdarstellung das Ablaufdiagramm für ein Ausführungsbeispiel eines Verfahrens zum Betreiben einer dem Informationssystem aus 3 zugeordneten Empfangseinheit.
-
Gleiche oder ähnliche Ausgestaltungen, Elemente oder Merkmale sind in den 1A bis 4 mit identischen Bezugszeichen versehen.
-
Bester Weg zur Ausführung der Erfindung
-
In 1B ist ein Ausführungsbeispiel für ein definiertes Datenformat 200 (”user application definition”) unter F[ast]I[nformation]G[roup] 0/13 gemäß der vorliegenden Erfindung in schematischer Prinzipdarstellung abgebildet.
-
Dieses Datenformat 200 dient zum Übertragen von digitalen Rundfunksignalen auf D[igital]A[udio]B[roadcasting]-Basis und ist so gewählt, daß sämtliche in RDS möglichen Zusatzdienste auch über DAB realisiert werden können. Dazu werden in FIG 0/13 nicht nur A[pplication]ID[dentification]D[ata] für den T[raffic]M[essage]C[hannel] übertragen (vgl. Datenformat in 1A gemäß dem Stand der Technik), sondern FIG 0/13 wird so definiert, daß jede beliebige AID dort signalisiert wird.
-
Hierzu weist das Datenformat 200 zunächst ”kopfseitig” ein Typenfeld 202 (”user application type”) sowie ein Datenlängefeld 204 (”user application data length”) auf. Im Unterschied zum gemäß 1A dargestellten Datenformat aus dem Stand der Technik (→ ”user application data: TMC AID” 206 in 1A) folgt sodann ein Datenfeld 206, das nicht nur für T[raffic]M[essage]C[hannel]-Daten, sondern zusätzlich auch für auf R[adio]D[ata]S[ystem]-Basis übermittelbare Dienste, insbesondere für programmbegleitende Datendienste oder programmunabhängige Datendienste, wie etwa E[mergency]W[arning]S[ystem] oder Paging, ausgelegt ist (”user application data: RDS AID”).
-
Zwischen dem vorbeschriebenen Datenfeld 206 und einem abschließenden Zusatzdatenfeld 210 (”user application data: additional info”) ist ein zusätzliches R[adio]D[ata]S[ystem]-Gruppentyp-Datenfeld 208 (”user application data: RDS-GType”) von einem Byte Länge vorgesehen.
-
In diesem weiteren Datenfeld 208 kann also noch der Gruppentyp aus RDS übertragen werden, um den Dienst eineindeutig zu kennzeichnen. Damit ist es möglich, ohne zusätzlichen Software-Aufwand jeden beliebigen RDS-Dienst auch in FIG 5/1 über DAB zu übertragen, denn auch in DAB sind unter FIG 5/1 nur 37 Bit lange Felder (= 37 verfügbare Bits pro Gruppe) zu definieren (gegebenenfalls kann auch ein weiterer FIG, zum Beispiel FIG 5/3, für andere RDS-Dienste genutzt werden).
-
In 2 ist eine schematische Prinzipdarstellung einer dem Datenformat 200 aus 1B exemplarisch zugeordneten Datenstruktur 300 auf Basis von FIG 0/13 gezeigt. Diese Datenstruktur 300 setzt sich aus drei Komponenten 310, 320, 330 zusammen, nämlich aus
- – einer B[roadcast]W[eb]S[ite]-Application-Komponente 310
→ ”Packet Mode”-Übertragung 312,
- – einer TMC AID = CD46-Komponente 320
→ FIG 5/1 Übertragung 322 und
- – einer zusätzlichen RDS-Application-Komponente 330 in DAB
→ FIG 5/x Übertragung 332.
-
Durch das dargelegte Datenformat 200 sowie durch die dargelegte Datenstruktur 300 werden erfindungsgemäß digitale Rundfunksignale auf D[igital]A[udio]B[roadcasting]-Basis, im speziellen sogenannte DAB-Ensembles oder DAB-Multiplexe, konstituiert, die durch Realisieren der Datenstruktur 300 im Standard nachweisbar sind.
-
In diesem Zusammenhang wird unter einem DAB-Ensemble oder DAB-Multiplex ein Paket aus etwa fünf bis etwa acht Radioprogrammen sowie aus zusätzlichen Datendiensten verstanden. Ein derartiges Paket weist eine feste Gesamtkapazität auf, die jedoch flexibel unter den verschiedenen Programmen und Diensten aufgeteilt werden kann.
-
Jedes DAB-Ensemble bzw. jeder DAB-Multiplex wird – vergleichbar einem klassischen U[ltra]K[urz]W[elle]-Radioprogramm – in einem bestimmten Bereich ausgestrahlt, zum Beispiel in einem Bundesland oder auch nur im Raum einer Großstadt, oder vielleicht auch in einem gesamten Land. In einem Gebiet können hierbei viele verschiedene DAB-Ensembles bzw. DAB-Multiplexe ausgestrahlt werden.
-
Ein DAB-Ensemble bzw. ein DAB-Multiplex bedient sich in diesem Zusammenhang jedoch stets einer einzigen Frequenz und weist eine eindeutige Identifikationsnummer sowie einen eindeutigen Namen auf. Die Ausbreitungsgebiete der DAB-Ensembles bzw. der DAB-Multiplexe werden hierbei auch als Bedeckungen bezeichnet.
-
Der Datenstrom des DAB-Multiplex hat eine maximale Kapazität von etwa 1,7 Megabit pro Sekunde, den sich üblicherweise mehrere Radioprogramme (sogenannte ”Audiostreams”) und mehrere Datenkanäle (sogenannte N[ot]P[rogramme]A[ssociated]D[ata] = nicht-programmbegleitende Datendienste) miteinander teilen. Der Name DAB-”Multiplex” bezieht sich darauf, daß die einzelnen Datenströme gemultiplexed, das heißt jeweils abwechselnd stückchenweise gesendet werden.
-
Ein Multiplex benötigt auf dem Frequenzband etwa 1,5 Megahertz an Bandbreite; die in einem Multiplex übertragene Gesamtzahl an Daten, Diensten und Programmen wird auch Ensemble genannt. Das Sendesignal selbst weist eine Reihe von eng benachbarten und im wesentlichen äquidistanten orthogonalen Trägern auf.
-
In 3 ist ein Ausführungsbeispiel eines Informationssystems gemäß der vorliegenden Erfindung in schematischer Prinzipdarstellung abgebildet, wobei dieses Informationssystem 100 als Navigationssystem ausgebildet ist.
-
Das Navigationssystem ist in einem (in den 1A bis 4 aus Gründen der Übersichtlichkeit der Darstellung nicht explizit gezeigten) Kraftfahrzeug installiert und leitet den Führer des Kraftfahrzeugs einfach, schnell und sicher an einen gewünschten Zielort, ohne daß der Führer des Kraftfahrzeugs vorher aufwendig eine Route planen und entsprechendes Kartenmaterial erwerben bzw. studieren muß.
-
Hierzu liegen entsprechende, beispielsweise auf Karten, Landkarten oder Straßenkarten basierende Navigationsdaten im Informationssystem 100 – etwa auf C[ompact]D[isc]-R[ead]O[nly]M[emory] gespeichert – vor. Das Informationssystem 100 nutzt beispielsweise G[lobal]P[ositioning]S[ystem], um den momentanen Standort des Kraftfahrzeugs festzustellen und entsprechende Anweisungen zu berechnen, die zu einem vorbestimmten Ziel führen.
-
In diesem Zusammenhang beinhalten die Navigationsdaten Informationen über Straßen und Wege für Kraftfahrzeuge; hierbei kommen im Informationssystem 100 entsprechende Algorithmen zur Routenberechnung zum Einsatz, die aus der Vorgabe eines Ausgangspunkts und eines Zielpunkts zusammen mit den gespeicherten Navigationsdaten eine optimale Route zur Fahrt vom Ausgangspunkt zum Zielpunkt errechnen. Derartige Algorithmen zur Routenberechnung stützen sich beispielsweise auf sogenannte Bestwege-Algorithmen, die aus der Graphentheorie bekannt sind und die an die besonderen Anforderungen für den Einsatz in autarken, beispielsweise fortbewegungsmittelgebundenen Informationssystemen 100 angepaßt werden.
-
Das Informationssystem 100 gemäß 3 weist nun als sogenannte Subsysteme im wesentlichen
- – eine digitalisierte Straßenkarte,
- – eine als Rechenmodul ausgebildete Prozessoreinheit 70 zur Fahrtroutenberechnung,
- – eine Positionsbestimmungseinheit 20 zum Bestimmen der Position des Kraftfahrzeugs sowie zum Ermitteln von Positionsdaten,
- – eine (System-)Verwaltungseinheit 50 zum Verwalten der Positionsdaten und der Bewegungsdaten sowie der eingegebenen Daten und Informationen,
- – eine Sensoreinheit 30 zum Erkennen der Bewegungen des Kraftfahrzeugs sowie zum Ermitteln der Bewegungsdaten des Kraftfahrzeugs und
- – eine Eingabeeinheit 40 zum manuellen und akustischen Eingeben von Daten und Informationen durch den Führer des Kraftfahrzeugs sowie
- – eine Ausgabeeinheit 80 zum Ausgeben sowie zum optischen und akustischen Vermitteln der Reisedaten und Verkehrsinformationen
- – letztere beiden als Schnittstellen für die Bedienung des Informationssystems 100 – auf.
-
Zusätzlich werden teilweise Verkehrsdaten und -informationen verarbeitet, etwa um Verkehrsstörungen zu umfahren; hierbei wird dem Führer des Kraftfahrzeugs über optische und akustische Fahrhinweise mitgeteilt, in welche Fahrtrichtung zu fahren ist, um nach den voreingestellten Routenoptionen optimal, das heißt schnellstmöglich und mit maximaler Sicherheit an den Zielpunkt zu gelangen.
-
Des weiteren besteht für das anhand 3 veranschaulichte Ausführungsbeispiel des Informationssystems 100 die Möglichkeit, Daten und Informationen eines Reiseführers von einem Datenträger, beispielsweise von einer C[ompact]D[isc], zu lesen. Um den Benutzer, das heißt den Führer des Kraftfahrzeugs hierbei nicht mit allen Daten und Informationen zu belasten, ist eine der Prozessoreinheit 70 und der Ausgabeeinheit 80 vorgeschaltete Filtereinheit 60 angeordnet, die dem Führer des Kraftfahrzeugs die vorliegenden Daten und Informationen in Abhängigkeit vom Standort, vom Zielgebiet und/oder von der Thematik in einer geeigneten selektiven Form zur Auswahl präsentiert. Der Führer des Kraftfahrzeugs kann sich dann vom Informationssystem 100 nach Auswahl eines Objekts zu diesem führen lassen.
-
Das anhand 3 veranschaulichte Ausführungsbeispiel des Informationssystems 100 zeichnet sich nun dadurch gegenüber konventionellen Informationssystemen aus, daß die Empfangseinheit 10 auch für das Empfangen der vorstehend dargelegten digitalen Datensignale gemäß dem Datenformat 200 (vgl. 1B) bzw. gemäß der Datenstruktur 300 (vgl. 2) bestimmt ist.
-
Hierzu ist die Empfangseinheit 10 gemäß der Darstellung der 3 als digitale Rundfunkempfangseinheit ausgebildet und zum Empfangen von als O[pen]D[ata]A[pplication]-Applikation kodiert übertragenen Daten und Informationen ausgelegt. Demzufolge können mit der Empfangseinheit 10 neben TMC auch andere RDS-Zusatzdienste im DAB aufgenommen werden, so daß die Wiedergabe dieser RDS-Zusatzdienste gewissermaßen ”auf Knopfdruck” der Eingabeeinheit 40 technisch realisierbar ist und die dann im Informationssystem 100 vorhandenen Daten sinnvollerweise für Anzeigezwecke, im Bedarfsfalle auch für Navigationszwecke, genutzt werden können.
-
In Korrespondenz hierzu, im speziellen zur Empfangseinheit 10, dient die Verwaltungseinheit 50 auch zum Verwalten der aufgenommenen RDS-Zusatzdienste; mit der Prozessoreinheit 70 können die aufgenommenen RDS-Zusatzdienste dann verarbeitet und ausgewertet werden.
-
Gemäß einem erfindungswesentlichen Merkmal ergibt sich bei kombinierten TMC-/RDS-Systemen in DAB insofern eine optimale Synergie, als dann die Dekodiereinrichtungen von TMC auch für die weiteren RDS-Dienste in DAB genutzt werden können; die spezifischen Erweiterungen sind dann im Vergleich zur Gesamtkomplexität vernachlässigbar. Die Haupterweiterung der Empfangseinheit 10 des Informationssystems 100 besteht dann darin, daß, sobald eine Gruppe mit einer RDS-Dienst-A[pplication]ID[entification] gefunden und verifiziert wird, der in dieser Gruppe angegebene Gruppentyp zusätzlich zu den auf TMC bezogenen 8A-Gruppen gesammelt und dekodiert wird.
-
Da nun beim Informationssystem 100 neben TMC auch andere RDS-Dienste, wie etwa E[mergency]W[arning]S[ystem] (= Notfall-Warnsystem) oder Paging, im DAB ermöglicht werden, ist in bezug auf den RDS/TMC-kodierten Übertragungsstandard zu berücksichtigen, daß die TMC-Übertragung im RDS in der RDS-Gruppe 8A mit 37 verfügbaren Bits pro Gruppe erfolgt. Bei etwa sechs bis acht TMC-Gruppen pro Sekunde (in Abhängigkeit von der Belegung des RDS-Kanals) ergeben sich etwa 200 Bit pro Sekunde bis 300 Bit pro Sekunde, die für das TMC-Prinzip verfügbar sind.
-
Hierbei ist die kodierte TMC-Übertragung prinzipiell auch in amplitudenmodulierten Systemen (AM-Systemen) möglich, etwa auf Mittelwellen- oder Langwellensendern mit Amplitudenmodulation (AM) zum Übertragen von AM-Zusatzinformationen mit brutto etwa 200 Bit pro Sekunde. Die Übertragung erfolgt durch Phasenmodulation des Trägersignals, wobei die Datenstruktur ähnlich wie im RDS ist.
-
Hinsichtlich der konkreten Übertragung von Daten nach dem Prinzip gemäß der vorliegenden Erfindung ist – im Unterschied zum reinen TMC-Prinzip – eine spezielle sogenannte Anwendungskennung (= A[pplication]ID[entification]) bei der E[uropean]B[roadcasting]U[nion] zu beantragen. (Siehe hierzu http://www.rds.org.uk).
-
Auch ist zu berücksichtigen, daß beim Prinzip gemäß der vorliegenden Erfindung – im Unterschied zum reinen TMC-Prinzip (→ Gruppentyp 8A) – keine Zuordnung zu einem speziellen RDS-Gruppentyp gegeben ist. Die Suche nach einem zusätzlichen, in DAB implementierten RDS-Dienst wird aus diesen Gründen im Vergleich zur TMC-Suche etwas länger dauern, denn beispielsweise wird der Gruppentyp 3A nur etwa alle fünf Sekunden ausgesendet. Dies ist jedoch nicht nachteilig, denn die allermeisten zusätzlichen, in DAB implementierten RDS-Dienste sind – im Gegensatz zu TMC-Meldungen – nicht zeitkritisch.
-
In 4 schließlich wird das Funktionsprinzip einer für den Empfang von auf R[adio]D[ata]S[ystem]-Basis übermittelten programmbegleitenden sowie programmunabhängigen Datendiensten, wie etwa E[mergency]W[arning]S[ystem] oder Paging, ausgelegten Empfangseinheit 10 gemäß der vorliegenden Erfindung skizziert. Deutlich wird hier, daß im Unterschied zu einer reinen TMC-Empfangseinheit eine Meldungsausgabe nicht notwendigerweise automatisch erfolgt, sondern der Meldungsbestand auch erst auf Verlangen, etwa durch Knopfdruck des Nutzers, zur Verfügung gestellt werden kann.
-
Im einzelnen erfolgt nach dem Starten (= Verfahrensschritt (i)) zunächst eine Initialisierung (= Verfahrensschritt (ii)) der Empfangseinheit 10, die unter anderem ein Auslesen der L[ongitudinal]C[onversion]L[oss]-Kennung oder dergleichen, ein Scannen des frequenzmodulierten Bandes und ein Suchen von Gruppentypen, nämlich von RDS-Gruppentypen wie etwa 3A und 8A, beinhalten kann.
-
Wird daraufhin die Empfangseinheit 10 in bezug auf den Empfang von als O[pen]D[ata]A[pplication]-Applikation kodiert übertragenen digitalen Daten und Informationen aktiviert (= Verfahrensschritt (iii)), so erfolgt eine Suche nach dem dem Empfangen von als O[pen]D[ata]A[pplication]-Applikation kodiert übertragenen digitalen Daten und Informationen zugeordneten RDS-Gruppentyp (= Verfahrensschritt (iv)); andernfalls (= ”–”) erfolgt eine Überprüfung, ob der auf R[adio]D[ata]S[ystem]-Basis übermittelte Datendienst noch aktiviert ist (= Verfahrensschritt (x)).
-
Wenn nun der passende RDS-Gruppentyp mit der zutreffenden Anwendungskennung (= A[pplication]ID[entification]) nicht gefunden wird (= ”–”), dann erfolgt eine Deaktivierung (= Verfahrensschritt (xii)), und es wird eine Überprüfung eingeleitet, ob der auf R[adio]D[ata]S[ystem]-Basis übermittelte Datendienst überhaupt noch aktiviert ist (= Verfahrensschritt (x)).
-
Wird hingegen der passende RDS-Gruppentyp mit der zutreffenden Anwendungskennung (= A[pplication]ID[entification]) gefunden (= Verfahrensschritt (v)), dann wird im Display der Ausgabeeinheit 80 ein Icon oder dergleichen angezeigt (= Verfahrensschritt (vi)), woraufhin O[pen]D[ata]A[pplication]-Applikation kodiert übertragene digitale Daten und Informationen gesammelt werden (= Verfahrensschritt (vii)).
-
Nach diesem Sammeln erfolgt dann der Abruf (= Verfahrensschritt (viii)) und im positiven Falle (= ”+”) ein Anzeigen der Meldungen auf dem Display der Ausgabeeinheit 80 (= Verfahrensschritt (xiii)), wobei sich hinter dieser Funktion die vorstehend dargelegte Komplexität einer Benutzerschnittstelle (”user interface”) insofern verbirgt, als die Anzeige in Text, in Graphik oder in Sprache erfolgen kann.
-
Im negativen Falle (= ”–”) des Verfahrensschritts (viii) erfolgt ein Wechseln des Senders (= Verfahrensschritt (ix)). In Abhängigkeit vom Erfolg des versuchten Senderwechsels (→ ”+”) springt das Verfahren gemäß der vorliegenden Erfindung vor Verfahrensschritt (iv) zurück oder (→ ”–”) überprüft, ob der auf R[adio]D[ata]S[ystem]-Basis übermittelte Datendienst noch aktiviert ist (= Verfahrensschritt (x)). Falls dies der Fall ist (= ”+”), springt das Verfahren vor Verfahrensschritt (vii) zurück; andernfalls (= ”–”) wird das Verfahren beendet (= Verfahrensschritt (xi)).
-
Abschließend sei noch auf die erfindungswesentliche Eigenschaft hingewiesen, daß die Meldungen auch für die Dynamisierung der Routensuche genutzt werden können, wobei dies sinnvollerweise analog dem beim TMC-Prinzip eingesetzten Verfahren erfolgt. In dieser Funktion kann dann auch die Navigation selbst als ”User” die Funktion ”Anzeigen der Meldungen” (= Verfahrensschritt (xiii)) auslösen und erhält als Antwort die aktuelle Liste der anstehenden Meldungen.
