EP1030475A2 - Verfahren zur Übertragung von digital codierten Verkehrsnachrichten und Funkempfänger dazu - Google Patents

Verfahren zur Übertragung von digital codierten Verkehrsnachrichten und Funkempfänger dazu Download PDF

Info

Publication number
EP1030475A2
EP1030475A2 EP00100560A EP00100560A EP1030475A2 EP 1030475 A2 EP1030475 A2 EP 1030475A2 EP 00100560 A EP00100560 A EP 00100560A EP 00100560 A EP00100560 A EP 00100560A EP 1030475 A2 EP1030475 A2 EP 1030475A2
Authority
EP
European Patent Office
Prior art keywords
information
traffic
tmc
class
digitally coded
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP00100560A
Other languages
English (en)
French (fr)
Other versions
EP1030475A3 (de
Inventor
Michael Ruf
Ulrich Kersken
Claus Dorenbeck
Heinrich Schmidt
Karin Hempel
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Robert Bosch GmbH
Original Assignee
Robert Bosch GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Robert Bosch GmbH filed Critical Robert Bosch GmbH
Publication of EP1030475A2 publication Critical patent/EP1030475A2/de
Publication of EP1030475A3 publication Critical patent/EP1030475A3/de
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/09—Arrangements for giving variable traffic instructions
    • G08G1/091—Traffic information broadcasting
    • G08G1/092—Coding or decoding of the information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/53—Arrangements specially adapted for specific applications, e.g. for traffic information or for mobile receivers
    • H04H20/55—Arrangements specially adapted for specific applications, e.g. for traffic information or for mobile receivers for traffic information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/02—Arrangements for generating broadcast information; Arrangements for generating broadcast-related information with a direct linking to broadcast information or to broadcast space-time; Arrangements for simultaneous generation of broadcast information and broadcast-related information
    • H04H60/07—Arrangements for generating broadcast information; Arrangements for generating broadcast-related information with a direct linking to broadcast information or to broadcast space-time; Arrangements for simultaneous generation of broadcast information and broadcast-related information characterised by processes or methods for the generation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H2201/00—Aspects of broadcast communication
    • H04H2201/10—Aspects of broadcast communication characterised by the type of broadcast system
    • H04H2201/13—Aspects of broadcast communication characterised by the type of broadcast system radio data system/radio broadcast data system [RDS/RBDS]

Definitions

  • the invention is based on a method for transmission of digitally encoded traffic news and one Radio receiver for this purpose, according to the genus of claims 1 and 7.
  • receiver build up where the traffic news is standardized be transmitted.
  • the highway numbers that Route names and other place names as well as the Standard texts are stored in a memory and carried in a corresponding radio receiver.
  • Kick now an obstacle to traffic so the information digitally transmitted in the form of abbreviations and then in Broadcast receiver for a complete message composed. This ensures that with very few Bytes of complete traffic messages are transmitted can, so that even with less powerful Data transmission systems very many traffic news in be transmitted in a relatively short time.
  • the header is also particularly advantageous to encrypt traffic messages at the same time use. This makes it possible, for example, To provide traffic news only when certain services are received or fees were paid. It is also advantageous that divide further information into classes, each Class a class identifier and at least one package having. By dividing it into classes, it is possible not only to transmit location information, but also further additional information with the Connect traffic news, for example to memory to be provided with new location data in the radio receiver or but additional foreign language texts of place names to transmit, so that foreign drivers the Receive information in your native language. It is cheap also that the number of subsequent packets after the Class identifier is transferred. This will ensures that the radio receiver is able to all information of a class is complete to record.
  • the radio receiver according to the invention for performing the Method according to one of claims 1 to 6 has a Separator of digital data and voice information and an evaluation circuit for evaluating the digital transmitted traffic news.
  • an evaluation circuit for evaluating the digital transmitted traffic news is included.
  • the radio receiver only has a memory for standard texts. By This measure is achieved that standard texts on everyone Case do not need to be transferred.
  • FIG. 1 shows a radio receiver, for example one Broadcast receiver with an antenna 1 to which a Broadcast receiving part 2 is connected.
  • the decoded received Signal available.
  • FM radio in addition to the spoken words and the music spoken traffic radio and via the radio data system RDS broadcast digitally encoded traffic news.
  • the Coding is based on a standard that is specifically for the limited data capacity was developed by RDS.
  • the received Information separated.
  • the spoken words become that Amplifier 3 supplied and via the speaker 4 to the listener made audible.
  • the digitally transmitted data is the Decoder 5 supplied, at the output of a serial signal with so-called TMC data is available.
  • TMC messages are not only used to inform the driver, but also for dynamization navigation, i.e. when calculating before driving routes the traffic situation is taken into account in navigation systems, which was transmitted via TMC, so that for example the Navigation already gives hints on how to avoid a traffic jam is.
  • the problem with TMC is that carried in the terminal Lists and tables, in particular the To be mentioned is the location code table, which is the list of all locations for the road network relevant for the traffic announcement saved.
  • There is also an event list in which the possible events are listed are, for example, the length of a traffic jam and the reason why a traffic jam occurred.
  • Storage space is the update of the location code tables a problem and it should be remembered that not all Traffic reports can be encoded, especially if by blocking or adding more streets Location code table is out of date.
  • the event list only allows the use of the predefined events. New events can be viewed through TMC in its familiar form not be transferred. On the other hand, TMC enjoys one increasing popularity because of the standard won with very little information a lot of information can be conveyed.
  • TMC is no longer only used in FM radio, but is also used in conjunction with GSM radio telephones, which also takes advantage of the TMC location with the short transmission times.
  • TMC is also under discussion with new, advanced broadcast transmission systems, such as digital audio broadcasting (DAB). Due to the advanced technology, however, the newer transmission methods are able to transmit significantly higher data rates than is the case with RDS-TMC. It is essential, however, that all radio reception systems have in common that after the reception and the demodulation of the information the speech information and TMC information must be separated, which must be processed in a suitable manner in a computer.
  • DAB digital audio broadcasting
  • a standard TMC message 13 is broadcast expanded.
  • the expanded TMC message 10 is composed of a header 12 and the actual message 11.
  • the message 11 itself in turn consists of a standardized TMC message 13, as well as at least one piece of additional information 14, 15 and 16. If a header 12 precedes the TMC message 13, at least one additional piece of information 14 must be present, which is also transmitted. This additional information 14 must also be location information.
  • the additional information 15 and 16 and additional information are optional and are used to transmit different classes of information.
  • the header 12 is necessary in order to be able to recognize that it is an expanded TMC information.
  • the header 12 may include information about how much Additional information 14, 15 and 16 of the actual TMC message follow and serves one if needed Encrypt the TMC message. Such Encryption must be signaled and at the same time must what type of encryption it is acts. A header can therefore also be used Encryption indicator must be incorporated. So it will possible to encrypt the TMC message differently and different TMC information depending on the service for example, to transmit via GSM or DAB. That's the way it is for example possible, a service provider A a first Assign encryption and a service provider B a other encryption method.
  • the Header is therefore able to identify a extended TMC message to perform other tasks, such as encryption and how much Additional information is expected.
  • TMC message 13 While the structure of the TMC message 13 is standardized, see above that there is no need to go into detail here the additional information can be structured differently. It is important that at least one piece of additional information 14 is a Contains location description, otherwise an extended TMC message wouldn't make sense.
  • the additional information is shown in detail in FIG. 3.
  • the additional information that has different contents can, is divided into so-called classes 20, where the classes from a class identifier 21, from a Class length 22, which is the number of subsequent packets describes and composed of the packages 23, 24, wherein the number of packages only by the class length 22 is determined. It is still important that certain Classes with a specific class name Minimum amount of mandatory packages is assigned, so that a optimal evaluation of the TMC data is possible. In addition however, any other packages can optionally be attached become.
  • the definition of class 20 is also for the TMC message 13 itself applicable. As a class identifier the code for TMC messages is then at position 21 used, while the class length is the number of TMC messages indicates. Then as packets 23 and 24 follows one TMC group each.
  • TMC message for a package several TMC messages are to be transmitted transferred, several packets are to be formed.
  • the standardized traffic reports also allow that traffic information not only from a group, but also can consist of up to five groups. In this case must have a total of five packages 23, 24 for a traffic announcement be used. Recognizing the togetherness of the Packets can be seen in Figure 4, since it is shown here that each packet 23 and 24, there designated 25, on the one hand consists of type 26 and data 27. At the Type marking 26 can now be seen whether the subsequent data 27 to a previous packet belong, or whether the data 27 in itself are interpretable. TMC messages can now be due to the construction of the class several traffic reports together are transmitted via the TMC message module 13.
  • one of the additional information items 14 contain a class to describe the location. And here Information from those contained in the TMC report encoded locations are included. Depending on the type the situation described in the TMC message is required one or more for such a location description different types of packages. The combination of packages in terms of number, type and order lead to education several different classes, these classes Required information included.
  • Mandatory information for the Location information is, for example, packets for the Street name, for the name or short name of the Street, its numbering, coordinates, audio modules and to see something similar. This enables the in to add content transmitted in coded form to TMC data, which are constantly updated.
  • the microprocessor 6 in FIG. 1 additionally contains a memory 7, in which the standardized events are stored in a special exemplary embodiment of the invention. Since the normalized events change less frequently than location data, mixed operation can also be achieved by the invention, namely by part of the necessary TMC information, in particular the events such as 3 km of traffic jam "and the like is stored in a memory of the radio receiver while other information whose change is more likely, such as place names, is transmitted. However, this is not mandatory. Of course it is possible to provide no memory at all and also to record the events as To transmit additional information, or to keep a complete location code and event list and only transmit information as extended topics for information that is not included in the location code list. It is essential that the TMC message itself with the already standardized TMC message is compatible.
  • the following table 1 shows various packet types that can be transmitted as a packet in a class of additional information.
  • No Package type Type length description 0 number 5 bytes TMC group 1 number 8 bytes Location: ECC + CC + LocDB # + Locationcode (according to ALERT C) 2nd number 1 byte Street class (primary, secondary, etc., coded as 1,2, etc.) 3rd Street designation n bytes Street ID (e.g. A, ST, etc.) 4th Street designation n bytes Street number (e.g. 4.1204 etc.) 5 text n bytes Street suffix (e.g. n, old, etc.) 6 Surname n bytes Street name (e.g. GmbHer Ring) 7 Surname n bytes 1.
  • Table 2 shows different class structures. No Mandatory packages Optional packages description 1 1,9,10,17 12.13 Area reporting 2nd 1,2,4,7,8,17 3,5,6,12,13,14 19 Road or segment message 3rd 1,2,4,9,10,13,16 3,5,6,7 8,12,18 19 Point in town 4th 1,2,4,7,8,9, 10,11,16 3,5,6,12,13,14 15,18 Point outside a city 5 1,2,4,9,10,13,16 3,5,6,12,18,19 2 points in a city .. .. . 9 2,4,7,8,1,9, 10,11,16,1,9,10,11,16 3,5,6,12,14,15 18,19 2 points, both outside a city .. 17th 245 - Location list update ..
  • class 1 with certain numbers according to the table, plus an additional two optional packets can be transmitted, but not are imperative.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Circuits Of Receivers In General (AREA)
  • Time-Division Multiplex Systems (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Es wird ein Verfahren zur Übertragung von digital codierten Verkehrsnachrichten vorgeschlagen, wobei die Verkehrsnachrichten in einem standardisierten Aufbau übertragen werden. Den Verkehrsnachrichten selbst wird dabei ein Header vorangestellt und der digitalen Verkehrsmeldung wird mindestens eine weitere Information nachgeordnet, wobei diese Information eine Ortsbeschreibung enthält. Durch die erfindungsgemäße Maßnahme wird erreicht, daß auch Verkehrsmeldungen übertragen werden können, die im standardisierten Aufbau nicht möglich oder nicht vorgesehen sind. <IMAGE>

Description

Stand der Technik
Die Erfindung geht aus von einem Verfahren zur Übertragung von digital codierten Verkehrsnachrichten und einem Funkempfänger dazu, nach der Gattung der Ansprüche 1 und 7. Aus der DE-35 36 820 C2 ist es bereits bekannt, Empfänger aufzubauen, bei denen die Verkehrsnachrichten standardisiert übertragen werden. Hierbei sind vorgegebenen Autobahnnummern oder Bundesstraßennummern Streckenführungsnamen, meist Orte, zugeordnet sowie Standardtexte vorgesehen, so daß auf codierte Art und Weise sehr schnell Verkehrsnachrichten übertragen werden können. Die Autobahnnummern, die Streckenführungsnamen und sonstige Ortsnamen sowie die Standardtexte werden hierbei in einem Speicher abgelegt und in einem entsprechenden Rundfunkempfänger mitgeführt. Tritt nun ein Verkehrshindernis auf, so werden die Informationen digital in Form von Kürzeln übertragen und dann im Rundfunkempfänger zu einer vollständigen Meldung zusammengesetzt. Dadurch wird erreicht, daß mit sehr wenigen Bytes komplette Verkehrsnachrichten übertragen werden können, so daß auch bei weniger leistungsfähigen Datenübertragungssystemen sehr viele Verkehrsnachrichten in einer relativ kurzen Zeit übertragen werden.
Problematisch wird dies dann, wenn sich Autobahnbezeichnungen oder Bundesstraßenbezeichnungen geändert haben oder aber auch Ortsnamen oder sonstige Streckenführungsnamen im Rahmen von Umstrukturierungen geändert werden. Dann werden von einem, mit einem entsprechenden Speicher ausgestatteten Funkempfänger Ortsangaben wiedergegeben, die in dieser Form beispielsweise auf Schildern nicht mehr lesbar sind, so daß der Fahrer irritiert wird.
Vorteile der Erfindung
Erfindungsgemäß wird nun vorgeschlagen, der eigentlich standardisiert übertragenen codierten Verkehrsmeldung mindestens eine Ortsbeschreibung hinzuzufügen. Dadurch wird es möglich, auch auf geänderte Ortsnamen einzugehen oder aber auch Ortsnamen zu übertragen, die in einem ursprünglichen Speicher des Funkempfängers nicht vorgesehen sind. Da weiterhin die digitale Nachrichtenübertragung über Funk immer zunimmt, und zudem in neuerer Zeit auch Übertragungsverfahren zur Verfügung stehen, die auch ein hohes Datenaufkommen übertragen können, ist es weiterhin möglich, auf einen Speicher im Funkempfänger ganz zu verzichten oder nur die vorgegebenen Standardtexte in diesem Speicher abzulegen und die Ortsangabe generell an die digital codierte Verkehrsnachricht anzuhängen. Dies erhöht die Flexibilität der digital zu übertragenden Verkehrsnachrichten in hohem Maße. Der Header dient dazu, daß der Funkempfänger erkennen kann, daß nicht nur digital codierte Verkehrsnachrichten übertragen werden, sondern den digital codierten Verkehrsdaten Ortsinformationen oder sonstige weitere Informationen folgen.
In den Unteransprüchen sind vorteilhafte Weiterbildungen und Verbesserung zu den im Anspruch 1 angegebenen Verfahren aufgezeigt. Vorteilhaft ist insbesondere auch den Header gleichzeitig zur Verschlüsselung der Verkehrsnachrichten zu verwenden. Dadurch ist es beispielsweise möglich, Verkehrsnachrichten nur dann zur Verfügung zu stellen, wenn bestimmte Dienste empfangen werden oder aber Gebühren entrichtet wurden. Vorteilhaft ist es weiterhin, die weiteren Informationen in Klassen aufzuteilen, wobei jede Klasse einen Klassenbezeichner und mindestens ein Paket aufweist. Durch die Aufteilung in Klassen ist es möglich, nicht nur Ortsinformationen zu übertragen, sondern auch weitere zusätzliche Informationen mit den Verkehrsnachrichten zu verbinden, beispielsweise um Speicher im Rundfunkempfänger mit neuen Ortsdaten zu versehen oder aber fremdsprachliche Texte von Ortsbezeichnungen zusätzlich zu übertragen, so daß auch ausländische Fahrer die Information in ihrer Muttersprache erhalten. Günstig ist es auch, daß die Zahl der folgenden Pakete nach dem Klassenbezeichner übertragen wird. Dadurch wird sichergestellt, daß der Funkempfänger in der Lage ist, sämtliche Informationen einer Klasse vollständig aufzunehmen. Günstig ist auch weiterhin, jedes Paket durch den Pakettyp, das heißt dem Inhalt der Information und den Daten zu bestimmen. Dadurch wird es möglich, in einer Klasse Pakete unterschiedlichen Typs zu übertragen. Vorteilhaft ist es weiterhin, das für jede Klasse eine Mindestzahl von Pflichtpaketen festgelegt wird. Dadurch wird sichergestellt, daß für jede Klasse wirklich alle Informationen, die zwingend notwendig sind, übertragen werden.
Der erfindungsgemäße Funkempfänger zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 6 weist eine Trennvorrichtung von digitalen Daten und Sprachinformationen und eine Auswerteschaltung zur Auswertung der digital übertragenen Verkehrsnachrichten auf. Hiermit wird es möglich, anhand des Headers einerseits die Empfangsberechtigung zu prüfen und andererseits zu erkennen, welche Information neben den digital codiert übertragenen Verkehrsnachrichten ansonsten in dem Nachrichtenpaket enthalten ist. Vorteilhaft ist auch, wenn der Funkempfänger lediglich einen Speicher für Standardtexte aufweist. Durch diese Maßnahme wird erreicht, daß Standardtexte auf jeden Fall nicht übertragen werden müssen.
Zeichnung
Ein Ausführungsbeispiel der Erfindung ist in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher erläutert. Es zeigen
  • Figur 1 einen Funkempfänger zur Realisierung der Erfindung,
  • Figur 2 den Aufbau eines Datenwortes gemäß der Erfindung
  • Figur 3 den Aufbau eines Datenwortes für die Klasse und
  • Figur 4 den Aufbau eines Datenwortes für ein Paket.
    • Beschreibung des Ausführungsbeispiels
    Figur 1 zeigt einen Funkempfänger, beispielsweise einen Rundfunkempfänger mit einer Antenne 1, an den ein Rundfunkempfangsteil 2 angeschlossen ist. Am Ausgang des Rundfunkempfangsteils 2 steht das decodierte empfangene Signal zur Verfügung. Beim bekannten FM-Rundfunk werden neben den gesprochenen Worten und der Musik auch gesprochener Verkehrsfunk sowie über das Radiodatensystem RDS digital codierte Verkehrsnachrichten ausgestrahlt. Die Codierung basiert dabei auf einem Standard, der speziell für die eingeschränkte Datenkapazität von RDS entwickelt wurde. Am Ausgang des Empfängers 2 werden nun die empfangenen Informationen getrennt. Die gesprochenen Worte werden dem Verstärker 3 zugeführt und über den Lautsprecher 4 dem Hörer hörbar gemacht. Die digital übertragenen Daten werden dem Decoder 5 zugeführt, an dessen Ausgang ein serielles Signal mit sogenannten TMC Daten zur Verfügung steht. Diese werden nun im Microrechner 6 verarbeitet und dem Fahrer eines Fahrzeuges akustisch oder optisch zur Anzeige gebracht.
    Aufgrund der geringen Übertragungsbandbreite, der Kanaleigenschaften und anderer Zielsetzungen, beispielsweise die Sprachunabhängigkeit, werden bei der heutigen Übertragung von Verkehrsnachrichten auf standardisierter Basis das Mitführen von Listen und Tabellen in den Endgeräten für die Decodierungen der empfangenen Meldungen gefordert, wie dies in der eingangs genannten Patentschrift beschrieben ist. TMC-Meldungen dienen heutzutage nicht nur zur Information des Fahrers, sondern auch zur Dynamisierung der Navigation, das heißt bei der Berechnung vor Fahrtrouten in Navigationssystemen wird die Verkehrslage berücksichtigt, die per TMC übertragen wurde, so daß beispielsweise die Navigation bereits Hinweise gibt, wie ein Stau zu umfahren ist.
    Das Problem bei TMC liegt in dem im Endgerät mitgeführten Listen und Tabellen, in denen insbesondere die Ortscodetabelle zu nennen ist, die die Liste sämtlicher Orte für das für die Verkehrsmeldung relevante Straßennetz gespeichert hat. Weiterhin ist eine Ereignisliste mitzuführen, in der die möglichen Ereignisse aufgeführt sind, beispielsweise die Länge eines Staus und der Grund, warum ein Stau aufgetreten ist. Abgesehen von dem benötigten Speicherplatz ist die Aktualisierung der Ortscodetabellen ein Problem und es ist weiterhin zu bedenken, daß nicht alle Verkehrsmeldungen codiert werden können, insbesondere wenn durch das Sperren oder Hinzukommen weiterer Straßen die Ortscodetabelle nicht mehr aktuell ist. Die Ereignisliste erlaubt nur die Verwendung der vordefinierten Ereignisse. Neue Ereignisse können über TMC in seiner bekannten Form nicht übertragen werden. Andererseits erfreut sich TMC einer zunehmenden Beliebtheit, da durch den gewonnen Standard mit sehr wenig Information ein großer Informationsinhalt vermittelt werden kann.
    In zunehmendem Maße findet TMC nicht mehr nur im FM Rundfunk Anwendung, sondern wird ebenfalls in Verbindung mit GSM-Funktelefonen eingesetzt, die sich auch den TMC-Standort mit den kurzen Übertragungszeiten zunutze macht. Auch bei neuen fortschrittlichen Rundfunkübertragungssystemen, wie beispielsweise dem Digital Audio Broadcasting (DAB) ist TMC im Gespräch. Aufgrund der fortentwickelten Technik sind jedoch die neueren Übertragungsverfahren in der Lage, erheblich höhere Datenraten zu überragen, als dies bei RDS-TMC der Fall ist.
    Wesentlich ist jedoch allen Funkempfangssystemen gemeinsam, daß nach dem Empfang und der Demodulation der Information eine Trennung der Sprachinformation und TMC-Information erfolgen muß, die in geeigneter Weise in einem Rechner verarbeitet werden muß. In Figur 2 ist nun ein Verfahren zur Übertragung von digitalcodierten Verkehrsnachrichten aufgezeigt, das zum an sich bekannten TMC-Verfahren rückwärts kompatibel ist, das heißt unter der Verwendung des bekannten TMC-Verfahrens zusätzliche Informationsmöglichkeiten anbietet. Eine Standard TMC Meldung 13 wird erweitert ausgestrahlt. Die erweiterte TMC-Meldung 10 setzt sich aus einem Header 12 und der eigentlichen Meldung 11 zusammen. Die Meldung 11 selbst besteht wiederum aus einer standardisierten TMC-Meldung 13, so wie mindestens einer Zusatzinformation 14, 15 und 16. Wird ein Header 12 der TMC-Meldung 13 vorangestellt, so muß mindestens eine Zusatzinformation 14 vorhanden sein, die mit übertragen wird. Diese Zusatzinformation 14 muß zudem eine Ortsinformation sein. Die weiteren Zusatzinformationen 15 und 16 sowie weitere Zusatzinformation sind optional und dienen dazu, verschiedene Klassen von Informationen zu übertragen.
    Der Header 12 ist notwendig, um erkennen zu können, daß es sich um eine erweiterte TMC-Information handelt. Der Header 12 kann Informationen darüber enthalten, wieviel Zusatzinformationen 14, 15 und 16 der eigentlichen TMC-Meldung folgen und dient dazu, bei Bedarf eine Verschlüsselung der TMC-Meldung durchzuführen. Eine solche Verschlüsselung muß signalisiert werden und gleichzeitig muß angegeben werden, um welche Art der Verschlüsselung es sich handelt. Im Header kann daher auch ein Verschlüsselungsindikator eingearbeitet sein. Somit wird es möglich, die TMC-Meldung unterschiedlich zu verschlüsseln und diensteabhängig unterschiedliche TMC-Informationen beispielsweise über GSM oder DAB zu übertragen. So ist es beispielsweise möglich, einem Dienstanbieter A eine erste Verschlüsselung zuzuordnen und einem Dienstanbieter B eine andere Verschlüsselungsmethode. Somit ist es auch mittels GSM möglich, entweder über den Short-Message-Channel oder über übliche GSM-Signale abhängig von Diensteanbieter unterschiedliche Verkehrsinformationen zu übertragen. Der Header ist daher in der Lage, neben der Kennzeichnung einer erweiterten TMC-Meldung noch weitere Aufgaben wahrzunehmen, wie nämlich die Verschlüsselung und die Anzeige, wieviel Zusatzinformationen zu erwarten sind.
    Während der Aufbau der TMC-Meldung 13 standardisiert ist, so daß hier nicht näher darauf eingegangen werden muß, können die Zusatzinformationen unterschiedlich aufgebaut sein. Wichtig ist, daß zumindest eine Zusatzinformation 14 eine Ortsbeschreibung enthält, da ansonsten eine erweiterte TMC-Meldung keinen Sinn machen würde.
    Die Zusatzinformation ist im Detail in Figur 3 dargestellt. Die Zusatzinformation, die unterschiedliche Inhalte haben kann, ist in sogenannte Klassen 20 aufgeteilt, wobei sich die Klassen aus einem Klassenbezeichner 21, aus einer Klassenlänge 22, die die Anzahl der nachfolgenden Pakete beschreibt und aus den Pakten 23, 24 zusammensetzt, wobei die Zahl der Pakete lediglich durch die Klassenlänge 22 bestimmt ist. Wichtig hierbei ist noch, daß bestimmten Klassen mit einer bestimmten Klassenbezeichnung eine Mindestmenge von Pflichtpaketen zugeordnet ist, so daß eine optimale Auswertung der TMC-Daten möglich ist. Zusätzlich können jedoch beliebige weitere Pakete optional angehängt werden. Die Definition der Klasse 20 ist im übrigen auch für die TMC-Meldung 13 selbst anwendbar. Als Klassenbezeichner wird dann an der Stelle 21 der Code für TMC-Meldungen eingesetzt, während die Klassenlänge die Anzahl der TMC-Meldungen kennzeichnet. Als Pakete 23 und 24 folgt dann jeweils eine TMC-Gruppe. Bei einem Paket ist daher eine TMC-Meldung zu übertragen, sind mehrere TMC-Meldungen zu übertragen, sind mehrere Pakete zu bilden. Die standardisierten Verkehrsmeldungen erlauben es auch, daß eine Verkehrsinformation nicht nur aus einer Gruppe, sondern aus bis zu fünf Gruppen bestehen kann. In diesem Falle müssen insgesamt fünf Pakete 23, 24 für eine Verkehrsmeldung aufgewandt werden. Das Erkennen der Zusammengehörigkeit der Pakete wird aus Figur 4 ersichtlich, da hier aufgezeigt ist, daß jedes Paket 23 und 24, dort mit 25 bezeichnet, einerseits aus dem Typ 26 und dem Daten 27 besteht. An der Typkennzeichnung 26 ist nun zu erkennen, ob die nachfolgenden Daten 27 zu einem vorhergehenden Paket gehören, oder aber ob die Daten 27 in sich selbständig interpretierbar sind. Bei TMC-Meldungen können nun aufgrund des Aufbaus der Klasse mehrere Verkehrsmeldungen zusammen über den TMC-Meldungsbaustein 13 übertragen werden.
    Wie bereits erwähnt, muß eine der Zusatzinformationen 14 eine Klasse zur Ortsbeschreibung enthalten. Wobei hier Informationen von den in der TMC-Meldung enthaltenen codierten Ortsangaben enthalten sind. Abhängig von der Art der in der TMC-Meldung beschriebenen Situation benötigt man für eine solche Ortsbeschreibung einen oder mehrere verschiede Pakettypen. Die Kombination von Paketen hinsichtlich Anzahl, Typ und Reihenfolge führen zur Bildung mehrerer verschiedener Klassen, wobei diese Klassen Pflichtangaben enthalten. Pflichtangaben für die Ortsinformation sind beispielsweise Pakete für die Straßenbezeichnug, für den Namen oder Kurzbezeichnung der Straße, deren Numerierung, Koordinaten, Audiobausteine und ähnliches zu sehen. Hierdurch wird es möglich, den in codierter Form übermittelten TMC-Daten Inhalte hinzuzufügen, die ständig zu aktualisieren sind. Für den Empfänger bietet sich dann der Vorteil, daß der eingangs erwähnte Speicher beispielsweise bei einem GSM Handfunk-Gerät nicht vorhanden sein muß, da die Daten zur Codierung des TMC-Paket anschließend in der Klasse Ortsinformation mit übertragen werden. Dadurch wird bereits eine Ausgabe der Information auf dem Display möglich. Werden zusätzlich noch Audioinformationen übertragen, wird eine Sprachwiedergabe erreicht. Kommen zusätzlich noch Koordinaten hinzu, können diese Koordinaten dazu verwendet werden, sofort zum Navigationsgerät überführt zu werden, so daß eine neue Routenberechnung dadurch vereinfacht wird. In weiteren Klassen können nun applikationsspezifische Anwendungen abgelegt werden, beispielsweise Zusatzinformationen für spezielle Navigationssysteme Hinweise auf Sehenswürdigkeiten oder besondere Gefahrangaben, wie starkes Gefälle, Glatteis oder Kurve.
    Der Microprozessor 6 in Figur 1 enthält zusätzlich einen Speicher 7, in den in einem speziellen Ausführungsbeispiel der Erfindung die normierten Ereignisse abgelegt sind. Da die normierten Ereignisse sich weniger häufig ändern als Ortsdaten, kann auch durch die Erfindung ein gemischter Betrieb erreicht werden, indem nämlich ein Teil der notwendigen TMC-Informationen, insbesondere die Ereignisse, wie
    Figure 00100001
    3 km Stau" und ähnliches in einem Speicher des Funkempfängers abgelegt wird während andere Informationen, deren Änderung mehr wahrscheinlich ist, wie beispielsweise Ortsnamen, übertragen werden. Dies ist jedoch nicht zwingend. Selbstverständlich ist es möglich, gar keinen Speicher vorzusehen und auch die Ereignisse als Zusatzinformation zu übertragen, oder aber eine komplette Ortscode- und Ereignisliste vorzuhalten und nur solche Informationen als erweiterte Themen zur Information zu übertragen, die in der Ortscodeliste nicht enthalten sind. Wesentlich dabei ist, daß die TMC-Meldung selbst mit der bereits genormten TMC-Meldung kompatibel ist.
    In der folgenden Tabelle 1 sind beispielhaft verschiedene Pakettypen aufgeführt, die als Paket in einer Klasse von Zusatzinformationen übertragen werden können.
    Nr Paket-Typ Typ-Länge Beschreibung
    0 Zahl 5 Byte TMC-Gruppe
    1 Zahl 8 Byte Location: ECC+ CC+LocDB#+Locationcode (nach ALERT C)
    2 Zahl 1 Byte Straßenklasse (Primary,Secondary,etc., codiert als 1,2,etc.)
    3 Str.Bezeich n Byte Straßenkennung (z.B. A,ST,etc.)
    4 Str.Bezeich n Byte Straßennummer (z.B.4,1204 etc.)
    5 Text n Byte Straßensuffix (z.B. n,old,etc.)
    6 Name n Byte Straßenname (z.B. Kölner Ring)
    7 Name n Byte 1. Segmentname
    8 Name n Byte 2. Segmentname
    9 Text n Byte Locationtyp (nach ENV12313-3,z.B.A1.0, P1.13.etc.)
    10 Text n Byte Locationtyp-Bezeichnung (z.B. Ausfahrt)
    11 Name n Byte Locationname (z.B. Hildesheim-Drispenstedt)
    12 Nummer n Byte Ausfahrtnummer(z.B. 17b)
    13 Text n Byte Gebietsbezeichnung (z.B. Regierungsbezirk)
    14 Name n Byte Gebietsname (z.B. Hannover)
    15 Nummer n Byte Umleitungsnummer
    16 Text n Byte Umleitungssuffix
    17 Koo 18 Byte Punkt-Koordinate (WGS84)
    18 Koo 36 Byte Koordinaten-Paar (WGS84)
    19 zahl 8 Byte Cross-Referenz auf anderen Location-Code
    20 Str.Bezeich n Byte Europa-Straßen-Nummer (z.B.4 für die E4)
    21 Audio n Byte Audio-Datei
    22 Nummer 1 Byte Versionsnummer (der Location-Datenbank)
    23 Text n Byte Freier Text
    ..
    24 n Byte Location-Listen-Zeile (zur Aktualisierung von Listen im Endgerät)
    Tabelle 2 zeigt unterschiedliche Klassenstrukturen auf.
    Nr Pflichtpakete Optionale Pakete Beschreibung
    1 1,9,10,17 12,13 Gebietsmeldung
    2 1,2,4,7,8,17 3,5,6,12,13,14 19 Straßen-oder Segment-Meldung
    3 1,2,4,9,10,13,16 3,5,6,7 8,12,18 19 Punkt in Stadt
    4 1,2,4,7,8,9, 10,11,16 3,5,6,12,13,14 15,18 Punkt außerhalb einer Stadt
    5 1,2,4,9,10,13,16 3,5,6,12,18,19 2 Punkte in einer Stadt
    ..
    ..
    ..
    9 2,4,7,8,1,9, 10,11,16,1,9,10,11,16 3,5,6,12,14,15 18,19 2 Punkte, beide außerhalb einer Stadt
    ..
    17 245 - Location-Liste-Update
    ..
    Hier ist beispielsweise aufgeführt, daß die Klasse 1 mit bestimmten Nummern gemäß Tabelle, sowie zusätzlich zwei optionale Pakete übertragen werden können, die jedoch nicht zwingend sind. Ähnlich ist dies bei den übrigen Klassen zu sehen.
    Im folgenden soll der Weg der Codierung einer erweiterten TMC-Meldung exemplarisch aufgezeigt werden. Folgende Meldung ist eine typische Verkehrsfunkmeldung für eine Störung auf einer Autobahn:
    A4 Olpe Richtung Köln, zwischen Bergisch-Gladbach Moitzfeld und Bergisch-Gladbach Bensberg 2 km stockender Verkehr".
    Wird diese Verkehrsmeldung nach dem gegebenen Standard hexadezimal codiert, ergibt sich folgende Darstellung: 08 086E 2B74. Dies wäre die Information, die nunmehr als Verkehrsmeldung als TMC-Meldung 13 in einem Paket 23 übertragen würde. Als Klasse für die Ortsinformation wird, aufgrund der in der Verkehrsmeldung beschriebenen Situation im Ausführungsbeispiel am besten die Klasse 9 gemäß Tabelle 2 benutzt. Diese hat den Aufbau, wie er in der Tabelle 3 dargestellt ist.
    Klasse d. Ortsinformationen Pflichtpakete (Pakettypen der Ortsinformation) Optionale Pakete (Pakettypen der Ortsinformation
    9 2,4,7,8,1,9,10, 3,5,6,12,14,15, 2 Punkte, beide außerhalb einer Stadt
    11,16, 18,19
    1,9,10,11,16
    Ausführung der Pflichtpakete:
  • Element 2: Strassenklasse: 1
  • Element 4: Strassennr.: 4
  • Element 7: Olpe
  • Element 8: Köln
  • 1. Element 1: ECC=E0, CC=D, LocDB#=1;Locationcode=2B74h
  • 1. Element 9: P1.3
  • 1. Element 10: Bergisch-Gladbach Moitzfeld
  • 1. Element 11: 20
  • 1. Element 16: 007642312,051238721
  • 2. Element 1: ECC=E0, CC=D, LocDB#=1;Locationcode=2B73h
  • 2. Element 9: P1.3
  • 2. Element 10: Bergisch-Gladbach Bensberg
  • 2. Element 11: 19
  • 2. Element 16: 007542342,051029628
  • Ausführung der optionalen Pakete
  • Element 14: 50 (Da die U50 von Moitzfeld n. Bensberg führt)
  • Element 19: 40 (Da die A4 Teil der E40 ist).
    • Aufgrund der nun vorliegenden Informationen ist es nicht nur möglich, ein Nagivationsgerät mit den notwendigen Daten zu übertragen, sondern die oben erwähnte Verkehrsfunkmeldung kann ein eindeutig zurückgewonnen werden, ohne daß irgendwelche Informationen im Funkempfänger gespeichert sein müssen.
    Als Zusatzinformationen in den weiteren Feldern 15 und 16 können beispielsweise die Ortsangaben für den Stauanfang und das Stauende, Zwischenstützpunkte oder der aktuelle Zeitverlust übertragen werden, der sich aufgrund der maximalen Verkehrsdichte der Straße ergibt. Weiterhin sind als zusätzliche Informationen die Ereignisklasse übertragbar, oder nähere Beschreibungen. Anhand der Ereignisklasse ist es dann möglich, die Verkehrsmeldungen nach verschiedenen Kriterien zu sortieren.

    Claims (8)

    1. Verfahren zum Übertragen von digital codierten Verkehrsnachrichten, wobei die Verkehrsmeldungen nach einem standardisierten Aufbau, insbesondere nach dem TMC-Verfahren, übertragen werden, dadurch gekennzeichnet, daß den digital codierten Verkehrsmeldungen (13) ein Header (12) vorangestellt wird und daß der digital codierten Verkehrsmeldung (13) mindestens eine weitere Information (14, 15, 16) folgt, wobei eine dieser Informationen (14) eine Ortsbeschreibung enthält.
    2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß der Header (12) zur Verschlüsselung der Verkehrsnachrichten dient.
    3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß die weiteren Informationen (14, 15, 16) in Klassen (20) aufgeteilt sind, wobei jede Klasse (20) einen Klassenbezeichner (21) und mindestens 1 Paket (23, 24) aufweist.
    4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, daß die Zahl der folgenden Pakete (23, 24) nach dem Klassenbezeichner (21) übertragen wird.
    5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, daß jedes Paket (23, 24) durch den Typ (26) und die Daten (27) bestimmt wird.
    6. Verfahren nach einem der Ansprüche 2 bis 5, dadurch gekennzeichnet, daß durch die Klasse die Zahl der Pflichtpakete festgelegt wird.
    7. Funkempfänger zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 6, mit einem Funkempfangsteil (2) mit einer Trennvorrichtung von digitalen Daten und Sprachinformationen, mit einer Auswerteschaltung (5) zur Auswertung digital codiert übertragener Verkehrsnachrichten, insbesondere TMC-Nachrichten, und einer Recheneinrichtung (6) zum Auswerten der digital empfangenen Informationen.
    8. Funkempfänger nach Anspruch 7, dadurch gekennzeichnet, daß er nur einen Speicher (7) für Standardtexte aufweist.
    EP00100560A 1999-02-11 2000-01-12 Verfahren zur Übertragung von digital codierten Verkehrsnachrichten und Funkempfänger dazu Ceased EP1030475A3 (de)

    Applications Claiming Priority (2)

    Application Number Priority Date Filing Date Title
    DE19905893 1999-02-11
    DE19905893A DE19905893A1 (de) 1999-02-11 1999-02-11 Verfahren zur Übertragung von digital codierten Verkehrsnachrichten und Funkempfänger dazu

    Publications (2)

    Publication Number Publication Date
    EP1030475A2 true EP1030475A2 (de) 2000-08-23
    EP1030475A3 EP1030475A3 (de) 2005-05-11

    Family

    ID=7897304

    Family Applications (1)

    Application Number Title Priority Date Filing Date
    EP00100560A Ceased EP1030475A3 (de) 1999-02-11 2000-01-12 Verfahren zur Übertragung von digital codierten Verkehrsnachrichten und Funkempfänger dazu

    Country Status (3)

    Country Link
    US (1) US6996089B1 (de)
    EP (1) EP1030475A3 (de)
    DE (1) DE19905893A1 (de)

    Cited By (12)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    EP1376512A3 (de) * 2002-06-28 2005-09-28 Robert Bosch Gmbh Verfahren zur Informationsübertragung und Informationsempfänger
    EP1624599A3 (de) * 2004-08-02 2006-06-14 Samsung Electronics Co., Ltd. Digitales Rundfunksystem und -Verfahren zur Benutzung eines digitalen Rundfunksignals mit Positionsinformation
    WO2006123896A1 (en) 2005-05-18 2006-11-23 Lg Electronics Inc. Method and apparatus for providing transportation status information and using it
    WO2006123902A1 (en) 2005-05-18 2006-11-23 Lg Electronics Inc. Providing road information including vertex data for a link and using the same
    WO2007083899A2 (en) 2006-01-19 2007-07-26 Lg Electronics Inc. Method and apparatus for providing congestion and travel time information to users
    EP1619642A3 (de) * 2004-07-23 2007-08-01 Robert Bosch Gmbh Verfahren zur Übertragung von digital codierten Meldungen in Datengruppen und Empfänger
    US7729335B2 (en) 2005-05-18 2010-06-01 Lg Electronics Inc. Providing traffic information relating to a prediction of congestion status and using the same
    CN101248470B (zh) * 2005-05-27 2010-12-08 Lg电子株式会社 使用编码字段编码和解码交通信息
    US7907590B2 (en) 2005-05-18 2011-03-15 Lg Electronics Inc. Providing information relating to traffic congestion tendency and using the same
    US7940741B2 (en) 2005-05-18 2011-05-10 Lg Electronics Inc. Providing traffic information relating to a prediction of speed on a link and using the same
    US7940742B2 (en) 2005-05-18 2011-05-10 Lg Electronics Inc. Method and device for providing traffic information including a prediction of travel time to traverse a link and using the same
    US8050853B2 (en) 2005-05-18 2011-11-01 Lg Electronics Inc. Providing traffic information including sub-links of links

    Families Citing this family (12)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    DE10038765A1 (de) 2000-08-09 2002-02-21 Bosch Gmbh Robert Verfahren zur Übertragung von digital codierten Verkehrsnachrichten
    DE10145165A1 (de) * 2001-09-13 2003-03-20 Siemens Ag Verfahren und Vorrichtung zur Datenübertragung in einem Kommunikationsnetz
    TW581309U (en) * 2001-11-26 2004-03-21 Sin Etke Technology Co Ltd Real-time traffic condition providing device
    US7349799B2 (en) * 2004-04-23 2008-03-25 Lg Electronics Inc. Apparatus and method for processing traffic information
    KR20060122668A (ko) * 2005-05-27 2006-11-30 엘지전자 주식회사 교통 정보 제공 방법 및 수신 장치
    US8711850B2 (en) 2005-07-08 2014-04-29 Lg Electronics Inc. Format for providing traffic information and a method and apparatus for using the format
    DE102005050575A1 (de) * 2005-10-21 2007-04-26 Robert Bosch Gmbh Verfahren zur Codierung von Verkehrsstörungen und Berechnung einer Route
    DE102005062019A1 (de) 2005-12-22 2007-06-28 Robert Bosch Gmbh Verfahren zur Codierung von Meldungen, Verfahren zur Decodierung von Meldungen und Empfänger zum Empfang und zur Auswertung von Meldungen
    DE502006007027D1 (de) 2006-03-28 2010-07-08 Bosch Gmbh Robert Verfahren zur Rundfunk-Übertragung von Verkehrsmeldungen und Rundfunkempfänger
    US7587186B2 (en) 2006-04-14 2009-09-08 Robert Bosch Gmbh Method for the radio transmission of traffic messages and radio receiver
    US8626208B2 (en) * 2008-06-30 2014-01-07 General Motors Llc Traffic data transmission from a vehicle telematics unit
    KR101470107B1 (ko) * 2012-12-28 2014-12-05 현대자동차주식회사 라디오 교통방송을 이용한 교통정보 제공 장치 및 그 방법

    Citations (1)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    WO1998039875A2 (de) * 1997-03-04 1998-09-11 Mannesmann Ag Verfahren zur einbringung eines diensteschlüssels in ein endgerät und vorrichtungen zur durchführung des verfahrens

    Family Cites Families (13)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    DE3536820A1 (de) 1985-10-16 1987-04-16 Bosch Gmbh Robert Verkehrfunk-decoder
    DE4137000C2 (de) * 1991-11-11 1994-06-09 Opel Adam Ag Verfahren zur feldstärkeabhängigen Auswertung von Rundfunkinformationen für Fahrzeuge
    DE4233210C2 (de) * 1992-10-02 1996-08-14 Bosch Gmbh Robert Rundfunkempfänger
    ATE533112T1 (de) * 1992-11-27 2011-11-15 Io Res Pty Ltd Verteiltes datenbanksystem und datenbankempfänger dafür
    DE19516477A1 (de) * 1995-05-05 1996-11-07 Bosch Gmbh Robert Einrichtung zur Aufbereitung und Ausgabe von Informationen für einen Fahrzeugführer
    DE19538453A1 (de) * 1995-10-16 1997-04-17 Bayerische Motoren Werke Ag Funksignalempfänger für Kraftfahrzeuge mit einem RDS-Dekoder für digitale Signale
    US5655561A (en) * 1995-11-27 1997-08-12 Wendel; A. Christopher Wireless system for detecting and stopping water leaks
    US6278660B1 (en) * 1996-04-29 2001-08-21 Sun Microsystems, Inc. Time-zone-tracking timepiece
    US6434138B2 (en) * 1996-05-08 2002-08-13 Robert Bosch Gmbh Process for transmitting messages by digital sound broadcasting and receiver for carrying out this process
    US5903216A (en) * 1996-12-12 1999-05-11 Sutsos; Pete Security structure unlocking system for use by emergency response and authorized personnel
    US6289012B1 (en) * 1998-08-03 2001-09-11 Instanton Corporation High concurrency data download apparatus and method
    WO2000019680A2 (en) * 1998-09-17 2000-04-06 Tod Mcnamara System and method for network flow optimization using traffic classes
    US6438561B1 (en) * 1998-11-19 2002-08-20 Navigation Technologies Corp. Method and system for using real-time traffic broadcasts with navigation systems

    Patent Citations (1)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    WO1998039875A2 (de) * 1997-03-04 1998-09-11 Mannesmann Ag Verfahren zur einbringung eines diensteschlüssels in ein endgerät und vorrichtungen zur durchführung des verfahrens

    Cited By (20)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    EP1376512A3 (de) * 2002-06-28 2005-09-28 Robert Bosch Gmbh Verfahren zur Informationsübertragung und Informationsempfänger
    EP1619642A3 (de) * 2004-07-23 2007-08-01 Robert Bosch Gmbh Verfahren zur Übertragung von digital codierten Meldungen in Datengruppen und Empfänger
    EP1624599A3 (de) * 2004-08-02 2006-06-14 Samsung Electronics Co., Ltd. Digitales Rundfunksystem und -Verfahren zur Benutzung eines digitalen Rundfunksignals mit Positionsinformation
    US7907590B2 (en) 2005-05-18 2011-03-15 Lg Electronics Inc. Providing information relating to traffic congestion tendency and using the same
    US7940741B2 (en) 2005-05-18 2011-05-10 Lg Electronics Inc. Providing traffic information relating to a prediction of speed on a link and using the same
    WO2006123902A1 (en) 2005-05-18 2006-11-23 Lg Electronics Inc. Providing road information including vertex data for a link and using the same
    EP1886295A4 (de) * 2005-05-18 2008-07-30 Lg Electronics Inc Bereitstellung von strasseninformationen, einschliesslich vertexdaten für eine verbindung und verwendung dieser
    EP1882245A4 (de) * 2005-05-18 2008-08-27 Lg Electronics Inc Verfahren und vorrichtung zur bereitstellung von tranportstatusinformationen sowie deren verwendung
    US7729335B2 (en) 2005-05-18 2010-06-01 Lg Electronics Inc. Providing traffic information relating to a prediction of congestion status and using the same
    USRE47239E1 (en) 2005-05-18 2019-02-12 Lg Electronics Inc. Method and apparatus for providing transportation status information and using it
    WO2006123896A1 (en) 2005-05-18 2006-11-23 Lg Electronics Inc. Method and apparatus for providing transportation status information and using it
    CN101128858B (zh) * 2005-05-18 2011-04-06 Lg电子株式会社 用于提供运输状态信息以及使用该信息的方法和装置
    US8332131B2 (en) 2005-05-18 2012-12-11 Lg Electronics Inc. Method and apparatus for providing transportation status information and using it
    US7940742B2 (en) 2005-05-18 2011-05-10 Lg Electronics Inc. Method and device for providing traffic information including a prediction of travel time to traverse a link and using the same
    US8086393B2 (en) 2005-05-18 2011-12-27 Lg Electronics Inc. Providing road information including vertex data for a link and using the same
    US8050853B2 (en) 2005-05-18 2011-11-01 Lg Electronics Inc. Providing traffic information including sub-links of links
    CN101248470B (zh) * 2005-05-27 2010-12-08 Lg电子株式会社 使用编码字段编码和解码交通信息
    EP1974182A4 (de) * 2006-01-19 2011-11-16 Lg Electronics Inc Verfahren und vorrichtung zur bereitstellung von stau- und reisezeitinformationen an endbenutzer
    US8009659B2 (en) 2006-01-19 2011-08-30 Lg Electronics Inc. Providing congestion and travel information to users
    WO2007083899A2 (en) 2006-01-19 2007-07-26 Lg Electronics Inc. Method and apparatus for providing congestion and travel time information to users

    Also Published As

    Publication number Publication date
    EP1030475A3 (de) 2005-05-11
    DE19905893A1 (de) 2000-08-17
    US6996089B1 (en) 2006-02-07

    Similar Documents

    Publication Publication Date Title
    EP1030475A2 (de) Verfahren zur Übertragung von digital codierten Verkehrsnachrichten und Funkempfänger dazu
    DE3536820C2 (de)
    EP0769181B1 (de) Einrichtung zur information eines fahrzeugführers
    EP1079353B1 (de) Verfahren zur Anforderung und zur Verarbeitung von Verkehrsmeldungen
    EP0769180A1 (de) Einrichtung zur aufbereitung und ausgabe von informationen für einen fahrzeugführer
    DE10038765A1 (de) Verfahren zur Übertragung von digital codierten Verkehrsnachrichten
    EP0725505B1 (de) Rundfunkempfänger zum Empfang sowie zur Verwaltung und Wiedergabe von digital codierten Verkehrsmeldungen
    DE102005062019A1 (de) Verfahren zur Codierung von Meldungen, Verfahren zur Decodierung von Meldungen und Empfänger zum Empfang und zur Auswertung von Meldungen
    EP1114406A1 (de) Verfahren zur codierung strassenübergreifender verkehrsbehinderungen
    EP1460599A2 (de) Datenbasis zur Codierung oder Decodierung von Verkehrsmeldungen und Verfahren zur Übertragung codierter Verkehrsmeldungen
    EP1141911B1 (de) Einrichtung zur übertragung von fahrtroutenempfehlungen und empfänger
    EP1721299B1 (de) Verfahren zur ausgabe von textuellen informationen mittels einer anzeige
    DE10252735B4 (de) Datenformat, digitales Rundfunksignal, zugeordnetes Informationssystem und Verfahren zum Betreiben desselben
    EP0880245B1 (de) Empfänger mit einer Einrichtung zur Selektion von digital codierten Meldungen
    DE10023309A1 (de) Verfahren, Datenformat, Codierungsvorrichtung, Decodierungsvorrichtung und System
    DE19911676A1 (de) Duales Übertragungssystem
    EP1076325B1 (de) Verfahren zur Anforderung und zur Verarbeitung von Verkehrsmeldungen
    EP1840857B1 (de) Verfahren zur Rundfunk-Übertragung von Verkehrsmeldungen und Rundfunkempfänger
    EP0984416A2 (de) Verfahren zur Verknüpfung von digitalen Verkehrswegenetzbeschreibungen und Ortsdatenbank
    EP0930736A2 (de) Einrichtung zum Empfang und Ortstabelle zur Decodierung von digital codierten Meldungen
    EP1619642A2 (de) Verfahren zur Übertragung von digital codierten Meldungen in Datengruppen und Empfänger
    DE102004010510A1 (de) Navigationssystem mit einem Empfänger für Verkehrsmeldungen und Verfahren zum Übertragen von Verkehrsmeldungen
    DE19917842A1 (de) Verfahren zur Identifizierung segmentübergreifender Ereignisse durch Segmente
    EP1011219A2 (de) Verfahren und Vorrichtung für die Erzeugung von Verkehrsinformationen für sich über mehrere verkettete Segmente eines Strassenverkehrsnetzes erstreckenden Zuständen
    EP1370833A1 (de) Verfahren und einrichtungen zum bereitstellen von informationsdaten

    Legal Events

    Date Code Title Description
    PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

    Free format text: ORIGINAL CODE: 0009012

    AK Designated contracting states

    Kind code of ref document: A2

    Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

    AX Request for extension of the european patent

    Free format text: AL;LT;LV;MK;RO;SI

    RIN1 Information on inventor provided before grant (corrected)

    Inventor name: HEMPEL, KARIN

    Inventor name: SCHMIDT,HEINRICH

    Inventor name: DORENBECK, CLAUS

    Inventor name: KERSKEN, ULRICH

    Inventor name: RUF, MICHAEL

    PUAL Search report despatched

    Free format text: ORIGINAL CODE: 0009013

    AK Designated contracting states

    Kind code of ref document: A3

    Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

    AX Request for extension of the european patent

    Extension state: AL LT LV MK RO SI

    17P Request for examination filed

    Effective date: 20051111

    AKX Designation fees paid

    Designated state(s): DE FR GB IT SE

    17Q First examination report despatched

    Effective date: 20060905

    STAA Information on the status of an ep patent application or granted ep patent

    Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

    18R Application refused

    Effective date: 20160624