EP1840857B1 - Verfahren zur Rundfunk-Übertragung von Verkehrsmeldungen und Rundfunkempfänger - Google Patents

Verfahren zur Rundfunk-Übertragung von Verkehrsmeldungen und Rundfunkempfänger Download PDF

Info

Publication number
EP1840857B1
EP1840857B1 EP20060111789 EP06111789A EP1840857B1 EP 1840857 B1 EP1840857 B1 EP 1840857B1 EP 20060111789 EP20060111789 EP 20060111789 EP 06111789 A EP06111789 A EP 06111789A EP 1840857 B1 EP1840857 B1 EP 1840857B1
Authority
EP
European Patent Office
Prior art keywords
traffic
urgency
component
messages
encrypted
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.)
Expired - Fee Related
Application number
EP20060111789
Other languages
English (en)
French (fr)
Other versions
EP1840857A1 (de
Inventor
Ralf Duckeck
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
Priority to DE200650007027 priority Critical patent/DE502006007027D1/de
Priority to EP20060111789 priority patent/EP1840857B1/de
Publication of EP1840857A1 publication Critical patent/EP1840857A1/de
Application granted granted Critical
Publication of EP1840857B1 publication Critical patent/EP1840857B1/de
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

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

Definitions

  • the invention is based on a method for broadcasting traffic reports and a radio receiver according to the preamble of the independent claims.
  • place table In a place table (location table) these place codes are each place names and also references to the place under consideration in the course preceding and subsequent places or their location codes specified. By transmitting such a location code and a direction of travel is thus the location of a traffic-related event on a stretch between two coded locations and a particular direction of travel established.
  • LTN location table number
  • the transmitted codes are assigned to corresponding message components on the basis of decoding tables stored therein and then displayed on the display or converted into spoken messages by means of speech synthesis and output via the connected loudspeakers.
  • TMC traffic reports are transmitted, for example by means of the so-called Radio Data System (RDS), which is specified for example in DIN / EN 50 067, inaudible next to a radio program on a broadcast frequency.
  • RDS Radio Data System
  • RDS-TMC is currently implemented in two variants throughout Europe.
  • a free service which is receivable in large parts of Europe
  • payment service (Pay-TMC or conditional access (CA)
  • CA conditional access
  • This service is often provided by private service providers and requires special software in the receivers so that they can decode the encrypted traffic messages.
  • the providers require that for each device that is to be able to decode CA, a certain fee is paid by the terminal equipment manufacturers to the provider.
  • the DE 199 05 893 A1 suggests a way to broadcast advanced RDS TMC traffic news.
  • the actual message is preceded by a header, which contains references to possible additions to the actual main message. In this header can also be pointed to an encryption of the actual messages.
  • the EP 0 818 898 A2 describes a method for the selection of digitally coded traffic reports. Each traffic message is assigned a priority characterizing the degree of the respective traffic disruption. Depending on a number of received traffic reports, traffic reports to be issued are selected according to the priority.
  • CA providers One obvious and preferred solution by CA providers would be that institutions would only require all terminal manufacturers to offer CA in their devices. Thus all terminals could receive and decode all and thus also the above-mentioned CA-TMC traffic reports. However, this would mean that the terminal equipment manufacturers would automatically have to pay licenses for all end devices to the CA providers. However, this solution is unacceptable from the point of view of terminal manufacturers as well as users who would ultimately have to pay the surcharge for CA capability of the terminals.
  • the present invention solves the above problem with a different approach.
  • the core is to be seen in the fact that within a transmission channel, which in addition to transmit conditional access information, which is usually encrypted, to transmit generally accessible unencrypted information.
  • the receiver is designed to recognize in the amount of incoming information or messages those that are transmitted unencrypted and then selectively evaluate this, while encrypted messages are ignored.
  • the recipient preferably accesses non-encrypted message components for the purpose of detecting unencrypted messages, which messages contain a direct or indirect indication as to whether the currently incoming messages are encrypted or unencrypted messages.
  • TMC traffic announcements An indirect indication in the case of TMC traffic announcements, for example, is the event codes, since in the standard, each cataloged traffic event is assigned one of several possible urgencies.
  • messages that are cataloged as particularly urgent (x-urgent) such as information about wrong-way drivers on motorways, should always be transmitted unencrypted.
  • the recipient can then determine, by analyzing the event code, whether or not it is a particularly urgent message and, in the case of a particularly urgent message, assume that it has been transmitted unencrypted.
  • the invention is described below using the example of RDS-TMC traffic reports. In principle, however, the invention can also be applied to other broadcast standards such as Digital Broadcasting (DAB), Digital Multimedia Broadcasting (DVB) or other transmission methods such as GSM (Global System for Mobile Communication) , UMTS, etc.) and others.
  • DAB Digital Broadcasting
  • DVD Digital Multimedia Broadcasting
  • GSM Global System for Mobile Communication
  • RDS signal The structure of the radio data signal, hereinafter RDS signal, as well as the coded TMC traffic information transmitted with it will be explained below FIG. 1 explained in more detail.
  • the RDS signal 1 is composed of a sequence of data blocks 10, which are also referred to as groups.
  • Each group 10 consists of four blocks 11, 12, 13, 14 of 26 bits each, of which each of the first 16 bits 15 are available for the actual payload, while the remaining 10 bits 16 of the transmission of redundancy information for error detection and correction (checkword) and the synchronization of the receiver (offset) are used.
  • checkword error detection and correction
  • offset synchronization of the receiver
  • the combination 20 of group type identifier and version bit BO serves to identify a group type in the strict sense.
  • a particularly important date of the RDS signal, which is why in every one of them Group is transmitted in the first block is the program identification code (PI) 15.
  • PI program identification code
  • SWR South West German Broadcasting Corporation
  • RDS Radio Data System
  • FIG. 1 shows a so-called single-sequence message, ie a traffic message, which is transmitted with a single group of the RDS signal.
  • the bit 35 (F) has the value "1".
  • bit 35 (F) is set to the value "0".
  • ISO 14819-1, -2 and -3 A detailed description can be found in ISO 14819-1, -2 and -3.
  • multi-sequence messages which are explained, for example, in ISO 14819-1, -2, -3.
  • type 3AA groups are preceded by type 3A groups in the RDS data stream (TMC traffic reports).
  • FIG. 2 contain in the fourth block 14 a so-called application identifier (Application ID, AID) 41, which indicates which type of information in the following groups of the type 8A, in the present case TMC messages.
  • Application ID Application ID
  • AID application identifier
  • these include a location table number (LTN) 42 which indicates which of a plurality of possible location tables has been used for encoding the event locations on the transmitter side and, consequently, should also be used on the receiver side for decoding the location codes.
  • LTN location table number
  • Different location tables are for example to allow the coding of places in several countries, ie for Germany there is a first, France a second, etc. place table.
  • the standard also provides for groups of type 8A in which management information (ADMIN 8A) is transmitted. These differ from the groups of the type "8A" carrying the actual traffic reports by the bit "T" 36, which in the case of a management group has the value "1", but in the case of traffic message groups the value "0".
  • the standard was later extended backwards compatible to enable Conditional Access TMC.
  • the code 0 (zero) is transmitted in group 3A, which was defined as "undefined” in the old standard.
  • An old-style device can not handle this code and ignores the CA-TMC traffic messages included in the following 8A groups.
  • One for receiving CA-TMC traffic messages recognizes based on the LTN "0" that the service transmits encrypted traffic reports.
  • the encryption of traffic information is carried out on the transmitter side via an encryption of the location codes according to one of several possible regulations.
  • a special 8A group ( FIG. 3 ) first the actual LTN (before encryption) 51, which can usually be the same number as for the free TMC service. Furthermore, a decryption key number (encryption ID ENCID) 52 is transmitted which is stored in a receiver-side decryption table (FIG. FIG. 4 , Numeral 60) designating one of a plurality of decryption instructions 61 to be used.
  • the decryption table 60 is available to all terminal manufacturers who pay appropriate licenses to use CA-TMC to the service provider. By applying the correct decryption rule, the encrypted received location codes can be assigned the correct location codes, which can then be assigned to places by means of the location table.
  • FIG. 5 shows an arrangement of radio transmitter 100 and radio receiver 200 for carrying out the method according to the invention.
  • the transmitter 100 basically codes traffic reports according to the conditional access (CA) method.
  • CA conditional access
  • the traffic messages thus coded are broadcast as broadcast signal 110 according to the known CA-TMC method.
  • the transmitted location code is unencrypted, but in the case of lower urgency it is encrypted.
  • the receiver 200 receives the broadcast signal 110 broadcast by the transmitter 100, which contains encrypted (CA-) TMC traffic reports, via an antenna 210.
  • a subsequent receiver 220 which is well known in the art and therefore not described here, the Broadcast signal demodulated and the RDS signal isolated. From this, the actual RDS information, in this case in particular the TMC information, is obtained in a subsequent RDS demodulator 230. These are in turn processed in a downstream processor 240.
  • the processor 240 then analyzes a group 3A obtained from the RDS signal to determine if it contains the LTN "0". If this is the case, then the received broadcast signal is one which includes TMC traffic messages according to the conditional access method. On the other hand, if the obtained group 3A contains another LTN, it is not a CA-TMC signal but a freely accessible, unencrypted TMC signal.
  • TMC traffic reports ie if unencrypted TMC traffic reports are received, they can be decoded and output in a conventional manner (260) or further processed, eg for being taken into account in a vehicle navigation system as part of a driving route calculation.
  • the location table number (LTNBE) 51 is obtained from a subsequent management group 8A of the RDS signal.
  • the event code 32 is evaluated in each case and then checked whether the associated event is an event with normal, low or particularly high urgency (x-urgent). If it is an event of less than particularly high urgency, the processor 240 assumes that the associated location code of that message has been transmitted in encrypted form. Since using it without decryption would result in erroneous messages, the entire message is ignored.
  • the processor 240 can assume that the associated location code has been transmitted unencrypted and evaluates it using the location table 250, whose number it obtained in the form of the LTNBE, in a manner known per se taking into account the country code of the PI code obtained from any group of the RDS signal. Likewise, the other message components, in particular direction and event are evaluated.
  • a corresponding urgency increase bit (label 1) is set in the context of a multi-sequence message in a following group 8A.
  • the processor 240 for this capability is designed to evaluate this bit and increase the urgency of the event. If the event then has the highest urgency, the processor again proceeds from an unencrypted location code and decodes the message in a known manner.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Circuits Of Receivers In General (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

    Stand der Technik
  • Die Erfindung geht von einem Verfahren zur Rundfunk-Übertragung von Verkehrsmeldungen und einem Rundfunkempfänger nach der Gattung der unabhängigen Patentansprüche aus.
  • In DE 35 36 820 C2 sowie den ISO-Normen 14819-1, -2 und -3 ist ein gattungsgemäßes Verfahren zur Rundfunkübertragung von codierten Verkehrsmeldungen angegeben. Das dort beschriebene TMC-(Traffic Message Channel-) Verfahren verfolgt den Ansatz, übliche Verkehrsmeldungen in ihre elementaren Bestandteile, nämlich insbesondere den Ort eines Ereignisses (location), die Fahrtrichtung (direction), die Ausdehnung des Ereignisses und das eigentliche Ereignis (event) zu zerlegen, diese Bestandteile zu katalogisieren und den katalogisierten Bestandteilen der Verkehrsmeldungen entsprechende vorgegebene Codes zuzuordnen. Statt der eigentlichen Verkehrsmeldungen werden dann nur die entsprechend der zu übertragenden Meldung zusammengestellten Codes übertragen. Beispielsweise werden besonders wichtige Punkte entlang wichtiger Verkehrswege, also etwa Ein- und Ausfahrten, Tankstellen, Rastplätze usw. entlang von Autobahnen sogenannte Ortscodes (location codes) zugeordnet. In einer Ortstabelle (location table) sind diesen Ortscodes jeweils Ortsnamen sowie auch Hinweise auf dem betrachteten Ort im Streckenverlauf vorhergehende und nachfolgende Orte bzw. deren Ortscodes angegeben. Durch Übertragung eines solchen Ortscodes und einer Fahrtrichtung ist somit der Ort eines verkehrsrelevanten Ereignisses auf einen Streckenabschnitt zwischen zwei codierten Orten und eine bestimmte Fahrtrichtung festgelegt. Um für die Ortscodes nur einen begrenzten Adressraum zur Verfügung stellen zu müssen, sind für verschiedene Länder verschiedene Ortstabellen vorgesehen, wobei eine bestimmte länderspezifische Ortstabelle über eine zugeordnete Ortstabellen-Nummer (location table number, LTN) identifizierbar ist.
  • Im Rundfunkgerät werden die übertragenen Codes anhand von dort gespeicherten Dekodiertabellen entsprechenden Meldungsbestandteilen zugeordnet und anschließend auf dem Display angezeigt oder mittels einer Sprachsynthese in gesprochene Meldungen umgesetzt und über die angeschlossenen Lautsprecher ausgegeben.
  • Diese TMC-Verkehrsmeldungen werden beispielsweise mittels des sogenannten Radio-DatenSystems (RDS), welches beispielsweise in DIN/EN 50 067 spezifiziert ist, unhörbar neben einem Hörfunkprogramm über eine Rundfunkfrequenz übertragen.
  • RDS-TMC ist derzeit in zwei Varianten europaweit implementiert. Zum einen als kostenloser Dienst, der in weiten Teilen Europas empfangbar ist, zum anderen als Bezahldienst (Pay-TMC oder Conditional Access (CA)), der u. A. in Frankreich, Großbritannien und zum Teil in Deutschland abgeboten wird. Dieser Dienst wird häufig von privaten Diensteanbietern zur Verfügung gestellt und erfordert spezielle Software in den Empfängern, damit diese die verschlüsselten Verkehrsmeldungen dekodieren können. Die Anbieter verlangen dazu, dass für jedes Gerät, das CA dekodieren können soll, eine bestimmte Gebühr von den Endgeräteherstellem an die Anbieter entrichtet wird.
  • Die DE 199 05 893 A1 schlägt eine Möglichkeit vor, erweiterte RDS-TMC-Verkehrsmeldungen zu übertragen. Dabei wird der eigentlichen Meldung ein Header vorangestellt, der Hinweise auf mögliche Ergänzungen zur eigentlichen Hauptmeldung enthält. In diesem Header kann auch auf eine Verschlüsselung der eigentlichen Meldungen hingewiesen werden.
  • Die EP 0 818 898 A2 beschreibt ein Verfahren zur Selektion von digital kodierten Verkehrsmeldungen. Dabei ist jeder Verkehrsmeldung eine den Grad der jeweiligen Verkehrsstörung kennzeichnende Priorität zugeordnet. In Abhängigkeit von einer Anzahl empfangener Verkehrsmeldungen werden auszugebende Verkehrsmeldungen nach der Priorität selektiert.
    • Aufgabe und Vorteile der Erfindung
  • Da ein Teil der Informationen zu TMC kostenlos von der Polizei als sicherheitsrelevanter Dienst zur Verfügung gestellt wird, steht nun insbesondere von Seiten der europäischen Verkehrsministerien die Forderung im Raum, dass zukünftig auch CA-Anbieter bestimmte Meldungen kostenlos an die Endgeräte und Nutzer übertragen bzw. zur Verfügung stellen sollen. Da dies zur Zeit systembedingt noch nicht möglich ist - es gibt entweder kostenlosen TMC oder CA, jedoch keine Mischung aus beiden - muss dazu eine Lösung gefunden werden.
  • Eine an sich nahe liegende und von den CA-Anbietern bevorzugte Lösung bestünde darin, dass die Ministerien nur alle Endgerätehersteller verpflichten müssen, CA in ihren Geräten anzubieten. Damit könnten alle Endgeräte sämtliche und damit auch die oben genannten CA-TMC-Verkehrsmeldungen empfangen und dekodieren. Das würde allerdings bedeuten, dass die Endgerätehersteller auch automatisch für alle Endgeräte Lizenzen an die CA-Anbieter bezahlen müssten. Diese Lösung ist jedoch aus Sicht der Endgerätehersteller wie auch der Nutzer, die den Aufpreis für CA-Fähigkeit der Endgeräte letztlich bezahlen müssten, nicht akzeptabel.
  • Die vorliegende Erfindung löst die obige Aufgabe mit einem abweichenden Ansatz.
  • Der Kern ist dabei darin zu sehen, dass innerhalb eines Übertragungskanals, der zur Übertragung von Conditional Access-Informationen, die üblicherweise verschlüsselt sind, zusätzlich allgemein zugängliche unverschlüsselte Informationen zu übertragen. Der Empfänger ist dabei dazu ausgebildet, in der Menge der eingehenden Informationen bzw. Meldungen diejenigen zu erkennen, die unverschlüsselt übertragen werden und diese sodann gezielt auszuwerten, während verschlüsselte Meldungen ignoriert werden.
  • Vorzugsweise greift der Empfänger dabei zur Erkennung von unverschlüsselten Meldungen auf nicht verschlüsselte Meldungsbestandteile zu, die einen direkten oder indirekten Hinweis darauf enthalten, ob es sich bei den aktuell eingehenden Meldungen um verschlüsselte oder unverschlüsselte Meldungen handelt.
  • Einen indirekten Hinweis bieten im Falle von TMC-Verkehrsmeldungen beispielsweise die Ereigniscodes, da nämlich im Standard jedem katalogisierten Verkehrsereignis eine von mehreren möglichen Dringlichkeiten zugeordnet ist. Im Falle von TMC-Verkehrsmeldungen wird hier vorgeschlagen, als besonders dringlich (x-urgent) katalogisierte Meldungen, wie Informationen über Falschfahrer auf Autobahnen, grundsätzlich unverschlüsselt zu übertragen. Der Empfänger kann dann durch Analyse des Ereigniscodes feststellen, ob es sich um eine Meldung besonders hoher Dringlichkeit handelt oder nicht und für den Fall, dass eine besonders dringende Meldung vorliegt, davon ausgehen, dass diese unverschlüsselt übertragen worden ist.
  • Da beim aktuell in Betrieb befindlichen CA-RDS-TMC nur die Ortscodes für Verkehrsereignisse verschlüsselt übertragen werden, können im Falle besonderes dringlicher Meldungen, also solcher mit einem entsprechenden Ereignis-Code, der als besonders dringlich katalogisiert ist, die übertragenen Ortscodes ohne weitere Entschlüsselung verwendet werden. Im Falle verschlüsselter Ortscodes hingegen werden diese und die zugehörigen weiteren Meldungsbestandteile ignoriert, da die Weiterverwendung verschlüsselter Ortscodes ohne Entschlüsselung zu Fehlmeldungen führen würde.
    • Detaillierte Beschreibung eines bevorzugten Ausführungsbeispiels
  • Die Erfindung wird nachfolgend am Beispiel von RDS-TMC-Verkehrsmeldungen beschrieben. Grundsätzlich lässt sich die Erfindung jedoch auch auf andere Rundfunküberiragungsstandards, wie etwa digitalen Rundfunk (DAB - digital audio broadcasting, DMB - digital multimedia broadcasting, DVB - digital video broadcasting u.a.) oder auch andere Übertragungsverfahren wie etwa Mobilfunkübertragung (GSM - global system for mobile communication, UMTS u.a.) und andere übertragen.
  • Der Aufbau des Radio-Daten-Signals, nachfolgend RDS-Signals, sowie der damit übertragenen codierten TMC-Verkehrsmeldungen wird nachfolgend anhand Figur 1 näher erläutert.
  • Das RDS-Signal 1 setzt sich aus einer Aneinanderreihung von Datenblöcken 10, die auch als Gruppen bezeichnet werden, zusammen. Jede Gruppe 10 besteht dabei aus vier Blöcken 11, 12, 13, 14 zu je 26 Bit, wobei davon jeweils die ersten 16 Bit 15 für die eigentlichen Nutzdaten zur Verfügung stehen , während die verbleibenden 10 Bit 16 der Übertragung von Redundanz-Informationen zur Fehlererkennung und -korrektur (Checkword) und der Synchronisation des Empfängers (Offset) dienen. Zur Übertragung unterschiedlicher Informationsarten sind dabei verschiedene Gruppentypen vorgesehen. Zur Kennzeichnung des jeweiligen Gruppentyps ist eine Gruppentypkennung (group type code, GT) 21 vorgesehen, die die ersten vier Bit X15, X14, X13 und X12 des zweiten Blocks einer jeden Gruppe umfasst. Ferner ist ein Versionsbit (B0) 22, das fünfte Bit X11 der zweiten Gruppe, vorgesehen. Die Kombination 20 aus Gruppentypkennung und Versionsbit BO dient der Kennzeichnung eines Gruppentyps im engeren Sinne. Ein besonders wichtiges Datum des RDS-Signals, das aus diesem Grund auch in jeder Gruppe im ersten Block übertragen wird, ist der Programm-Identifikations-Code (PI) 15. Dieser dient der eindeutigen Identifizierung eines bestimmten Rundfunkprogramms und umfasst dazu eine Länderkennung, welche den Standort des Senders angibt und die eigentliche Programmkennung, welche ein bestimmtes Rundfunkprogramm, wie z.B. das dritte Programm des Süd-Westdeutschen-Rundfunks (SWR) bezeichnet. Eine detaillierte Beschreibung des Radio Daten Systems (RDS) findet sich beispielsweise in DIN EN 50 067.
  • In Figur 1 ist beispielhaft eine Gruppe des Typs 8A, also mit GT 8, Version A, dargestellt. Diese Gruppe dient der Übertragung von codierten TMC-Verkehrsmeldungen gemäß dem erwähnten Standard ISO 14819-1, -2, -3. Die wesentlichen Bestandteile einer solchen TMC-Verkehrsmeldung sind dabei
    • der Ort des Geschehens, location 31, für den die 16 Bit Z15-ZO des letzten Blocks zu Verfügung stehen,
    • die Art des Verkehrsereignisses, event 32, z.B. Stau, zähfließender Verkehr, Sperrung usw., zu dessen Codierung die letzten 11 Bit des dritten Blocks reserviert sind,
    • die Ausdehnung des Ereignisses, extent 33, gemessen in der Zahl von locations, über die sich das Ereignis bzw. die daraus resultierende Verkehrsstörung erstreckt, umfassend die Bits Y13, Y12 und Y11 des dritten Blocks sowie
    • ein Bit Y14 des dritten Blocks zur Codierung der Fahrtrichtung (+/-) 34.
  • Das Beispiel der Figur 1 zeigt eine so genannte Einsequenz-Meldung, also eine Verkehrsmeldung, die mit einer einzigen Gruppe des RDS-Signals übertragen wird. Bei dieser weist das Bit 35 (F) den Wert "1" auf. Demgegenüber gibt es auch Mehrsequenzmeldungen für den Fall, dass die Kapazität einer einzelnen Gruppe 8A des RDS-Signals zu Übertragung einer Verkehrsmeldung nicht ausreicht. Zur Kennzeichnung solcher Mehrsequenzmeldungen ist das Bit 35 (F) auf den Wert "0" gesetzt. Eine detaillierte Beschreibung findet sich in den ISO 14819-1, -2 und -3. Daneben gibt es auch Mehrsequenz-Meldungen, die beispielsweise in ISO 14819-1, -2, -3 erläutert sind.
  • Da in Gruppen des Typs 8A auch andere Informationen als die eigentlichen TMC-Verkehrsmeldungen übertragen werden können, werden zur Ankündigung von TMC-Verkehrsmeldungen enthaltenden Typ-8A-Gruppen im RDS-Datenstrom Gruppen des Typs 3A vorausgeschickt (Figur 2). Diese enthalten im vierten Block 14 eine so genannte Anwendungskennung (Application ID, AID) 41, welche angibt, welche Informationsart in den folgenden Gruppen des Typs 8A übertragen wird, im vorliegenden Fall also TMC-Meldungen. Weiter enthalten diese eine Ortstabellennummer (location table number, LTN) 42, welche angibt, welche aus einer Mehrzahl von möglichen Ortstabellen zur Codierung der Ereignisorte senderseitig verwendet worden ist und folgerichtig auch empfängerseitig zu Decodierung der Ortscodes verwendet werden soll. Verschiedene Ortstabellen sind dabei beispielsweise zur Codierung von Orten in mehreren Ländern zu ermöglichen, d.h. für Deutschland gibt es eine erste, Frankreich eine zweite usw. Ortstabelle.
  • Schließlich sieht der Standard auch Gruppen des Typs 8A vor, in denen Verwaltungsinformationen (ADMIN 8A) übertragen werden. Diese unterscheiden sich von den die eigentlichen Verkehrsmeldungen tragenden Gruppen des Typs "8A" durch das Bit "T" 36, welches im Falle einer Verwaltungsgruppe des Wert "1" aufweist, im Falle von Verkehrsmeldungsgruppen hingegen den Wert "0".
  • Zur Dekodierung dieser TMC-Meldungen nach ALERT C-Standard, wie beispielsweise in den vorgenannten Normen ISO 14819-1, -2 und -3 beschrieben, müssen zunächst Land und die gültige Ortstabelle identifiziert werden. Dazu dient die LTN (Location Table Number) zusammen mit dem Programm-Identifikations- (PI-) Code des Senders. Aus diesen beiden Informationen lässt sich genau ermitteln, in welchem Land man sich befindet und welche LTN aktuell in Verwendung ist. Damit kann jeder kostenlose TMC-Dienst eindeutig identifiziert und dekodiert werden.
  • Der Standard wurde später rückwärtskompatibel erweitert, um Conditional Access TMC zu ermöglichen. Dazu wird in Gruppe 3A statt der gültigen LTN der Code 0 (Null) übertragen, der im alten Standard als "undefined" festgelegt wurde. Ein Gerät nach altem Standard kann mit diesem Code nichts anfangen und ignoriert die in den folgenden Gruppen des Typs 8A enthaltenen CA-TMC-Verkehrsmeldungen. Ein zum Empfang von CA-TMC-Verkehrsmeldungen erkennt auf Grundlage der LTN "0", dass der Dienst verschlüsselte Verkehrsmeldungen überträgt. Die Verschlüsselung der Verkehrsmeldungen erfolgt dabei senderseitig über eine Verschlüsselung der Ortscodes nach einer von mehreren möglichen Vorschriften.
  • Um diese verschlüsselten Ortscodes empfängerseitig entschlüsseln zu können, wird in einer speziellen 8A-Gruppe (Figur 3) zunächst die tatsächliche LTN (before encryption) 51 übertragen, die im Regelfall die selbe Nummer sein kann, wie auch für den kostenlosen TMC-Dienst. Ferner wird eine Entschlüsselungs-Kennnummer (encryption ID ENCID) 52 übertragen, die in einer empfängerseitigen Entschlüsselungstabelle (Figur 4, Bezugszeichen 60) die eine anzuwendende von mehreren Entschlüsselungsvorschriften 61 bezeichnet. Die Entschlüsselungstabelle 60 steht allen Endgeräteherstellern zur Verfügung steht, die entsprechende Lizenzen zur Nutzung von CA-TMC an den Diensteanbieter bezahlen. Durch Anwendung der korrekten Entschlüsselungsvorschrift können den verschlüsselten empfangenen Location-Codes die korrekten Location-Codes zugeordnet werden, denen dann wiederum mittels der Ortstabelle Orte zugeordnet werden können.
  • Die Lösung besteht darin, dass zumindest bestimmte, nämlich besonders dringende Meldungen, die im Ereignis- (Event-) Katalog als X-Urgent gekennzeichnet sind (z.B.: Geisterfahrer, Gefahrenmeldungen, Menschen, Tiere und Gegenstände auf der Fahrbahn), prinzipiell immer als freie Meldungen zur Verfügung gestellt werden müssen. Das würde auch den Forderungen der Verkehrsministerien entsprechen. Diese Meldungen müssen immer mit unverschlüsselten Location Codes 31 übertragen werden. Da zukünftige Empfangsgeräte auch LTN 0 erkennen können und in der entsprechenden Gruppe 8A auch die korrekte LTNBE (before encryption) 51 lesen können, die wie bereits erwähnt, meist identisch mit der üblichen nationalen LTN ist, kann dann die Meldung richtig empfangen werden, da der Code in unverschlüsselter Form vorliegt und die sonst erforderliche Entschlüsselungstabelle mit den Schlüsseln nicht notwendig ist und somit auch keine Lizenzkosten für Conditional Access TMC gezahlt werden müssen.
  • Zusätzlich ist im RDS-TMC Standard noch definiert, dass unter Verwendung eines zusätzlichen Labels die "default Urgency", also die standardmäßig eingestellte Dringlichkeit einer Meldung verändert, hier insbesondere erhöht, werden kann (siehe EN ISO 14819-1, Chapter 5.5.3, Label 1, Code 0). Mit dieser Möglichkeit können auch Meldungen mit normaler Dringlichkeit zu X-Urgent umgewandelt werden und erfindungsgemäß mit unverschlüsseltem Location Code übertragen werden.
  • Figur 5 zeigt eine Anordnung aus Rundfunksender 100 und Rundfunkempfänger 200 zur Durchführung des erfindungsgemäßen Verfahrens.
  • Der Sender 100 codiert Verkehrsmeldungen grundsätzlich gemäß dem Conditional Access (CA-) Verfahren. Dies bedeutet, dass zu Verkehrsereignissen, denen im Ereigniskatalog nicht die höchste Dringlichkeit zugeordnet ist, der zugehörige Ereignis-, also beispielsweise Unfallort, mit einem verschlüsselten Ortscode codiert wird. Im Falle von Verkehrsereignissen, denen hingegen im Ereigniskatalog die höchste Dringlichkeit zugeordnet ist, wird der Ereignisort demgegenüber unverschlüsselt anhand der Ortstabelle codiert.
  • Die so codierten Verkehrsmeldungen werden gemäß dem bekannte CA-TMC-Verfahren als Rundfunksignal 110 ausgestrahlt. Dies bedeutet, dass zum einen eine RDS-Gruppe 3A mit der Ortstabellennummer (LTN) "0", des weiteren eine Gruppe 8A gemäß Figur 3 mit der unverschlüsselten Ortstabelle (LTNBE) und der Entschlüsselungs-Kennnummer (ENCID) sowie eine weitere Gruppe 8A mit dem Ereigniscode (Event), der Fahrtrichtung (+/-) und dem Ortscode (Location) übertragen wird. Im Falle einer besonders dringenden Meldung, der im Ereigniskatalog die standardmäßige Dringlichkeit "x-urgent" zugeordnet ist, ist der übertragene Ortscode unverschlüsselt, im Falle geringerer Dringlichkeit hingegen verschlüsselt.
  • Der Empfänger 200 empfängt das vom Sender 100 ausgestrahlte Rundfunksignal 110, welches verschlüsselte (CA-) TMC-Verkehrsmeldungen enthält, über eine Antenne 210. In einem nachfolgenden Empfangsteil 220, das an sich hinlänglich bekannt ist und daher hier nicht näher beschrieben wird, wird das Rundfunksignal demoduliert und das RDS-Signal isoliert. Aus diesem werden in einem nachfolgenden RDS-Demodulator 230 die eigentlichen RDS-Informationen, hier also insbesondere die TMC-Informationen, gewonnen. Diese werden wiederum in einem nachgeschalteten Prozessor 240 verarbeitet.
  • Der Prozessor 240 analysiert eine aus dem RDS-Signal gewonnene Gruppe 3A daraufhin, ob sie die LTN "0" enthält. Ist dies der Fall, so handelt es sich bei dem empfangenen Rundfunksignal um eines, welches TMC-Verkehrsmeldungen nach dem Conditional Access-Verfahren beinhaltet. Enthält hingegen die erhaltene Gruppe 3A eine andere LTN, so handelt es sich nicht um ein CA-TMC-Signal, sondern um ein frei zugängliches, nicht verschlüsseltes TMC-Signal.
  • Im letzteren Fall, wenn also unverschlüsselte TMC-Verkehrsmeldungen empfangen werden, können diese in herkömmlicher Weise decodiert und ausgegeben (260) bzw. anderweit weiterverarbeitet, z.B. für im Rahmen einer Fahrroutenberechnung in einem Fahrzeugnavigationssystem berücksichtigt werden.
  • Im ersteren Fall, wenn also verschlüsselte CA-TMC-Verkehrsmeldungen empfangen werden, wird aus einer nachfolgenden Verwaltung-Gruppe 8A des RDS-Signals die Ortstabellennummer (LTNBE) 51 gewonnen.
  • Bei den darauf folgenden Gruppen 8A wird jeweils der Ereigniscode 32 ausgewertet und daraufhin geprüft, ob das zugeordnete Ereignis ein Ereignis mit normaler, geringer oder besonders hoher Dringlichkeit (x-urgent) ist. Handelt es sich um ein Ereignis mit geringerer als besonders hoher Dringlichkeit, geht der Prozessor 240 davon aus, dass der zugehörige Ortscode dieser Meldung verschlüsselt übertragen worden ist. Da dessen Verwendung ohne Entschlüsselung zu fehlerhaften Meldungen führen würde, wird die gesamte Meldung ignoriert.
  • Handelt es sich hingegen um ein Ereignis mit besonders hoher Dringlichkeit, kann der Prozessor 240 davon ausgehen, dass der zugehörige Ortscode unverschlüsselt übertragen worden ist und wertet diesen anhand der Ortstabelle 250, deren Nummer er in Form der LTNBE zuvor erhalten, in an sich bekannter Weise unter Berücksichtigung der Länderkennung des aus einer beliebigen Gruppe des RDS-Signals gewonnenen PI-Code aus. Ebenso werden auch die weiteren Meldungsbestandteile, insbesondere Fahrtrichtung und Ereignis ausgewertet.
  • Gemäß der bereits beschriebenen Weiterbildung können auch Meldungen mit standardmäßig geringer oder normaler Dringlichkeit die höchste Dringlichkeit zugeordnet werden. Hierzu wird im Rahmen einer Mehrsequenz-Meldung in einer folgenden Gruppe 8A ein entsprechendes Dringlichkeiterhöhungsbit (Label 1) gesetzt. Der Prozessor 240 ist für diese Möglichkeit dazu ausgebildet, dieses Bit auszuwerten und die Dringlichkeit des Ereignisses zu erhöhen. Verfügt das Ereignis sodann über die höchste Dringlichkeit, geht der Prozessor wieder von einem unverschlüsselten Ortscode aus und decodiert die Meldung in bekannter Weise.

Claims (11)

  1. Verfahren zur Übertragung von codierten Verkehrsmeldungen über einen Datenkanal zur Übertragung verschlüsselter Verkehrsmeldungen,
    dadurch gekennzeichnet, dass eine bestimmte Untermenge von Verkehrsmeldungen über den Datenkanal grundsätzlich in unverschlüsselter Form übertragen wird, wobei zur Verschlüsselung einer Verkehrsmeldung nur jeweils einer von mindestens zwei Bestandteilen der Verkehrsmeldung verschlüsselt wird, wobei der unverschlüsselte zweite Bestandteil eine Information über eine Dringlichkeit der Verkehrsmeldung enthält, wobei der erste Bestandteil der Verkehrsmeldung ein Ereignisort ist, welcher abhängig von der Dringlichkeit der Verkehrsmeldung verschlüsselt wird und wobei sich die Information über die Dringlichkeit aus einem Ereigniscode als zweitem Bestandteil ergibt und sich die Information über die Verschlüsselung des ersten Bestandteils aus der Dringlichkeit ergibt.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der erste Bestandteil nicht verschlüsselt wird, wenn die Dringlichkeit der Verkehrsmeldung einen festgelegten Wert hat.
  3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass der festgelegte Wert eine hohe Dringlichkeit, insbesondere den Wert "X-Urgent", darstellt.
  4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Verkehrsmeldungen nach dem TMC-Standard codiert sind.
  5. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass sich die Dringlichkeit der Verkehrsmeldung aus einem Ereigniscode als zweitem Bestandteil in Verbindung mit einer gegebenenfalls vorhandenen Dringlichkeitserhöhungsinformation für den zweiten Bestandteil ergibt.
  6. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Datenkanal zur Übertragung verschlüsselter Verkehrsmeldungen alle Verkehrsmeldungen umfasst, bei denen eine Ortstabellennummer, die eine Zuordnung zu Orten umfasst, den Wert 0 hat, was die einer Übertragung von TMC-Verkehrs-meldungen nach dem Conditional-Access-Verfahren entspricht.
  7. Verkehrsmeldungssender mit Mitteln zum Übertragen von Verkehrsmeldungen nach einem der vorhergehenden Ansprüche.
  8. Verfahren zum Empfangen von codierten Verkehrsmeldungen über einen Datenkanal zur Übertragung von teilweise verschlüsselten Verkehrsmeldungen,
    dadurch gekennzeichnet, daß
    - mindestens zwei Bestandteile einer Verkehrsmeldung empfangen werden, von denen je nur der erste Bestandteil verschlüsselt sein kann,
    - wobei dem zweiten unverschlüsselten Bestandteil ein Ereigniscode entnommen wird, aus dem sich eine Dringlichkeit der Verkehrsmeldung ergibt,
    - wobei der erste Bestandteil der Verkehrsmeldung ein Ereignisort ist, der abhängig von der Dringlichkeit der Verkehrsmeldung ohne Entschlüsselung weiterverarbeitet wird.
  9. Verfahren nach Anspruch 10, dadurch gekennzeichnet, dass der erste Bestandteil ohne Entschlüsselung weiterverarbeitet wird, wenn die Dringlichkeit der Verkehrsmeldung einen festgelegten Wert hat.
  10. Verfahren nach einem der Ansprüche 8 oder 9, dadurch gekennzeichnet, dass sich die Dringlichkeit der Verkehrsmeldung aus einem Ereigniscode als zweitem Bestandteil in Verbindung mit einer gegebenenfalls vorhandenen Dringlichkeitserhöhungsinformation für den zweiten Bestandteil ergibt.
  11. Empfänger mit Mitteln zum Empfangen von Verkehrsmeldungen nach dem Verfahren eines der Ansprüche 8 bis 10.
EP20060111789 2006-03-28 2006-03-28 Verfahren zur Rundfunk-Übertragung von Verkehrsmeldungen und Rundfunkempfänger Expired - Fee Related EP1840857B1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE200650007027 DE502006007027D1 (de) 2006-03-28 2006-03-28 Verfahren zur Rundfunk-Übertragung von Verkehrsmeldungen und Rundfunkempfänger
EP20060111789 EP1840857B1 (de) 2006-03-28 2006-03-28 Verfahren zur Rundfunk-Übertragung von Verkehrsmeldungen und Rundfunkempfänger

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP20060111789 EP1840857B1 (de) 2006-03-28 2006-03-28 Verfahren zur Rundfunk-Übertragung von Verkehrsmeldungen und Rundfunkempfänger

Publications (2)

Publication Number Publication Date
EP1840857A1 EP1840857A1 (de) 2007-10-03
EP1840857B1 true EP1840857B1 (de) 2010-05-26

Family

ID=36980387

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20060111789 Expired - Fee Related EP1840857B1 (de) 2006-03-28 2006-03-28 Verfahren zur Rundfunk-Übertragung von Verkehrsmeldungen und Rundfunkempfänger

Country Status (2)

Country Link
EP (1) EP1840857B1 (de)
DE (1) DE502006007027D1 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102014213351A1 (de) * 2014-07-09 2016-01-14 Siemens Aktiengesellschaft Gesichertes Verarbeiten eines Signalausschnittes eines Empfangssignals

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19628086A1 (de) 1996-07-12 1998-01-15 Bosch Gmbh Robert Verfahren und Einrichtung zur Selektion von digital codierten Verkehrsmeldungen
DE19905893A1 (de) 1999-02-11 2000-08-17 Bosch Gmbh Robert Verfahren zur Übertragung von digital codierten Verkehrsnachrichten und Funkempfänger dazu

Also Published As

Publication number Publication date
EP1840857A1 (de) 2007-10-03
DE502006007027D1 (de) 2010-07-08

Similar Documents

Publication Publication Date Title
EP1966780B1 (de) Verfahren zur codierung von meldungen, verfahren zur decodierung von meldungen und empfänger zum empfang und zur auswertung von meldungen
EP1079353B1 (de) Verfahren zur Anforderung und zur Verarbeitung von Verkehrsmeldungen
DE4233210C2 (de) Rundfunkempfänger
DE3820640C2 (de) Auswerteverfahren digitaler Verkehrsnachrichten
EP0769180A1 (de) Einrichtung zur aufbereitung und ausgabe von informationen für einen fahrzeugführer
DE19905893A1 (de) Verfahren zur Übertragung von digital codierten Verkehrsnachrichten und Funkempfänger dazu
EP0838108A1 (de) Verfahren zur übertragung von durchsagen mittels digitaler hörfunksendungen und empfänger zur durchführung des verfahrens
EP1151562A1 (de) Duales übertragungssystem
EP1376512B1 (de) Verfahren zur Informationsübertragung und Informationsempfänger
EP1840857B1 (de) Verfahren zur Rundfunk-Übertragung von Verkehrsmeldungen und Rundfunkempfänger
EP0900432B1 (de) Verfahren und empfänger zur geographischen selektion von digital codierten meldungen
DE10011702A1 (de) Verfahren zur standortbezogenen Information von Verkehrsteilnehmern
DE102004055576A1 (de) Verfahren zur Rundfunk-Übertragung von Verkehrsmeldungen und Rundfunkempfänger
DE19630195A1 (de) Verfahren zur Übertragung von Durchsagen mit Empfänger zur Durchführung des Verfahrens
DE19855638B4 (de) Verfahren, Empfänger und Sender zur Übertragung von digital codierten Verkehrsinformationen
EP0880245B1 (de) Empfänger mit einer Einrichtung zur Selektion von digital codierten Meldungen
DE19911676A1 (de) Duales Übertragungssystem
EP0836292B1 (de) Verfahren und Einrichtung zur gebietsabhängigen selektiven Ausgabe von empfangenen digital codierten Meldungen
DE19801012A1 (de) Einrichtung zum Empfang und Ortstabelle zur Decodierung von digital codierten Meldungen
DE10104080A1 (de) Verfahren zur Meldung eines Notrufs
DE19937370A1 (de) Verfahren zur Anforderung und zur Überarbeitung von Verkehrsmeldungen
DE19801011A1 (de) Einrichtung mit begrenztem Arbeitsspeicher zum Empfang und Ortstabelle zur Decodierung von digital codierten Meldungen
EP1619642A2 (de) Verfahren zur Übertragung von digital codierten Meldungen in Datengruppen und Empfänger
DE19916656A1 (de) Vorrichtung zur Information von Verkehrsteilnehmern

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: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK YU

17P Request for examination filed

Effective date: 20080403

17Q First examination report despatched

Effective date: 20080513

AKX Designation fees paid

Designated state(s): DE FR GB IT NL

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): DE FR GB IT NL

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

Free format text: NOT ENGLISH

REF Corresponds to:

Ref document number: 502006007027

Country of ref document: DE

Date of ref document: 20100708

Kind code of ref document: P

REG Reference to a national code

Ref country code: NL

Ref legal event code: T3

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

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

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

26N No opposition filed

Effective date: 20110301

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 502006007027

Country of ref document: DE

Effective date: 20110228

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20110525

Year of fee payment: 6

REG Reference to a national code

Ref country code: DE

Ref legal event code: R119

Ref document number: 502006007027

Country of ref document: DE

Effective date: 20121002

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20121002

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 11

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20160322

Year of fee payment: 11

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: IT

Payment date: 20160318

Year of fee payment: 11

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 12

GBPC Gb: european patent ceased through non-payment of renewal fee

Effective date: 20170328

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GB

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20170328

Ref country code: IT

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20170328

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 13

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: FR

Payment date: 20190326

Year of fee payment: 14

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: NL

Payment date: 20190321

Year of fee payment: 14

REG Reference to a national code

Ref country code: NL

Ref legal event code: MM

Effective date: 20200401

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: NL

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20200401

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: FR

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20200331