DE69634659T2 - Empfänger für digitalen tonrundfunk sowie verfahren und vorrichtung zur formatumwandlung einer dab-datenfolge - Google Patents

Empfänger für digitalen tonrundfunk sowie verfahren und vorrichtung zur formatumwandlung einer dab-datenfolge Download PDF

Info

Publication number
DE69634659T2
DE69634659T2 DE69634659T DE69634659T DE69634659T2 DE 69634659 T2 DE69634659 T2 DE 69634659T2 DE 69634659 T DE69634659 T DE 69634659T DE 69634659 T DE69634659 T DE 69634659T DE 69634659 T2 DE69634659 T2 DE 69634659T2
Authority
DE
Germany
Prior art keywords
data
frame
sequence
bits
type
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 - Lifetime
Application number
DE69634659T
Other languages
English (en)
Other versions
DE69634659D1 (de
Inventor
Cees Richard SPIERO
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.)
Koninklijke Philips NV
Original Assignee
Koninklijke Philips Electronics NV
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 Koninklijke Philips Electronics NV filed Critical Koninklijke Philips Electronics NV
Publication of DE69634659D1 publication Critical patent/DE69634659D1/de
Application granted granted Critical
Publication of DE69634659T2 publication Critical patent/DE69634659T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04HBROADCAST COMMUNICATION
    • H04H40/00Arrangements specially adapted for receiving broadcast information
    • H04H40/18Arrangements characterised by circuits or components specially adapted for receiving
    • H04H40/27Arrangements characterised by circuits or components specially adapted for receiving specially adapted for broadcast systems covered by groups H04H20/53 - H04H20/95
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04HBROADCAST COMMUNICATION
    • H04H2201/00Aspects of broadcast communication
    • H04H2201/10Aspects of broadcast communication characterised by the type of broadcast system
    • H04H2201/20Aspects of broadcast communication characterised by the type of broadcast system digital audio broadcasting [DAB]

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Circuits Of Receivers In General (AREA)
  • Communication Control (AREA)

Description

  • Die vorliegende Erfindung bezieht sich auf einen Empfänger zum Empfangen eines digitalen Audio Rundfunksignal (DAB) mit Mitteln zum Decodieren eines empfangenen DAB-Signals in eine erste Folge von Daten, organisiert in Frames eines ersten Typs, wobei die genannten Frames an vorbestimmten Stellen innerhalb des Frames eine Anzahl Datentypen aufweisen.
  • Die vorliegende Erfindung bezieht sich weiterhin auf ein Gerät zum Umwandeln einer ersten Folge von Daten in eine zweite Folge von Daten.
  • Ein DAB-Empfänger ist aus einer Broschüre "DAB452 Digital Audio Broadcasting test receiver", veröffentlicht von Philips Consumer Electronics, Niederlande, Februar 1995.
  • Bei dem bekannten DAB-Empfänger wird ein empfangenes DAB-Signal in der Frequenz umgewandelt und in einer "Fast Fourier Transform" Anordnung demoduliert, entschachtelt und zu einer DAB Datenfolge decodiert, in Frames eines ersten Typs organisiert, wobei die genannten Frames an vorbestimmten Stellen innerhalb des Frames eine Anzahl Datentypen aufweisen. Die Ausgangsdaten des Kanaldecoders können die ganze entschachtelte und decodierte DAB Datenfolge enthalten oder nur einen Teil dieser Folge. Die Ausgangsdaten werden an dieser Stelle als die erste Datenfolge betrachtet und sind an einer externen Schnittstelle des DAB-Empfängers verfügbar zum Liefern derselben zu den Randgeräten zur weiteren Verarbeitung. Dies bedeutet, dass in dem Fall, dass die ganze DAB Datenfolge verfügbar ist, die Randapparatur im Bilde sein muss über die Struktur des DAB-Formats zum Decodieren der richtigen Information innerhalb der ersten Folge. In dem Fall, dass nur ein Teil der DAB Datenfolge verfügbar ist, sollen die Randgeräte dennoch im Bilde sein über den Typ von Daten, die verfügbar sind. Dies macht, dass ein Randgerät ziemlich komplex ist. Weiterhin wird das Frameformat der ersten Folge von Daten in der digitalen Domäne nicht universell verwendet: es wird nur für DAB verwendet. Dies macht, dass die Schnittstelle des DAB-Empfängers zu den Randgeräten nicht standard ist, was unerwünscht ist in Applikationen, in denen eine Anzahl Randgeräte erforderlich ist um miteinander zu kommunizieren.
  • Es ist nun u. a. eine Aufgabe der vorliegenden Erfindung, einen DAB-Empfänger, ein Gerät und ein Verfahren zum Umwandeln von Daten in der ersten Folge in ein leichter zugängliches Format zu schaffen.
  • Die Aufgabe nach der vorliegenden Erfindung wird gelöst durch den Wandler zur Umwandlung einer erste Folge von Daten, organisiert in Frames eines ersten Typs, wobei die genannten Frames eine Anzahl Datentypen an vorbestimmten Stellen innerhalb eines Frames enthalten, in eine zweite Datenfolge, organisiert in Frames eines zweiten Typs, wobei eine Framelänge des ersten Frametyps anders ist als die Framelänge des zweiten Frametyps, wobei der Wandler zu den nachfolgenden Zwecken vorgesehen ist:
    • – das Zerlegen der ersten Datenfolge in wenigstens zwei einzelne Datenfolgen, wobei jede Datenfolge der einzelnen Datenfolgen für einen vorbestimmten Datentyp reserviert ist,
    • – das Aufteilen der einzelnen Folgen in Frames vom zweiten Typ,
    • – das Zusammenstellen der einzelnen Folgen zu Frames eines zweiten Typs, wobei jedes Frame einen Frametypidentifizierer aufweist zum Identifizieren der einzelnen Folgen innerhalb der zweiten Folge, und weiterhin das Zusammenstellen der zweiten Folge aus den einzelnen Folgen.
  • Durch Aufteilung der ersten Folge in einzelne Folgen, wobei jede einzelne Folge für einen bestimmten Datentyp reserviert ist, und durch Verteilung der einzelnen Folgen über die Frames der zweiten Folge und durch weitere Hinzufügung zu den Frames in der zweiten Folge können die einzelnen Folgen innerhalb der zweiten Folge identifiziert werden ohne dass es notwendig ist, dass die genaue Stelle der Datentypen in der zweiten Folge bekannt ist. Dies reduziert die Komplexität eines Randgeräts und dies führt zu einer zweiten Folge, auf die einfacher zugegriffen werden kann.
  • Ein DAB-Empfänger nach der vorliegenden Erfindung weist das Kennzeichen auf, dass der DAB-Empfänger weiterhin einen Wandler aufweist zum Umwandeln der ersten Folge von Daten in die zweite Folge von Daten, wie oben erläutert worden ist.
  • Das entsprechende Verfahren der Umwandlung ist in Anspruch 15 gegeben.
  • Eine Ausführungsform der vorliegenden Erfindung weist das Kennzeichen auf, dass die Umwandlungsmittel dazu vorgesehen sind, einen Datentypidentifizierer zu wenigstens einer der einzelnen Folgen hinzuzufügen zur Identifikation des Datentyps in der einzelnen Folge. Dies ermöglicht es, dass das Randgerät auf eine einfache Art und Weise bestimmt, welcher Datentyp in einer der einzelnen Folgen anwesend ist.
  • Eine weitere Ausführungsform der vorliegenden Erfindung weist das Kennzeichen auf, dass die zweite Folge eine Anzahl Pakete umfasst, wobei eine einzelne Folge ein Paket umfasst, das eine Anzahl Frames in der zweiten Folge umfasst, wobei ein Paket durch vorbestimmte Werte des Frametypidentifizierers (FTI) identifiziert wird, wobei das Paket einen Kopf mit dem Datentypidentifizierer aufweist. Dadurch, dass die Daten in Paketen gegliedert werden, wobei jedes Paket einen Kopf aufweist, werden nur wenig Gesamtkosten in der zweiten Folge verwendet, da nicht jedes Frame in der zweiten Folge einen Datentypidentifizierer zu haben braucht zum Identifizieren desjenigen Datentyps, zu dem die Daten gehören. Dies führt zu einer hohen Effizienz der zweiten Folge.
  • Eine andere Ausführungsform der vorliegenden Erfindung weist das Kennzeichen auf, dass die zweite Folge einzelne Datenframes aufweist, die durch wenigstens einen weiteren vorbestimmten Wert des Frametypidentifizierers identifiziert wird, wobei jedes Frame in der zweiten Folge Daten und einen Datentypidentifizierer aufweist.
  • Dadurch, dass die Daten in Frames gegliedert und den Frames ein weiterer Identifizierer hinzugefügt wird, wird das Decodieren der Daten vereinfacht, was zu einem weniger komplexen Randgerät führt.
  • Eine Ausführungsform der vorliegenden Erfindung weist das Kennzeichen auf, dass die Umwandlungsmittel dazu vorgesehen sind, zu der zweiten Folge ein Synchronisationssignal hinzuzufügen, und zwar zur Signalisierung eines Starts eines Frames vom ersten Typ. Durch Hinzufügung eines Synchronisationssignals, das den Start eines Frames in der ersten Folge angibt, kann das Randgerät bestimmen, welche Daten in der zweiten Folge zu demselben Frame der ersten Folge gehören.
  • Eine vorteilhafte Implementierung einer derartigen Ausführungsform weist das Kennzeichen auf, dass das Synchronisationssignal ein Frame mit einem Frametypidentifizierer mit einem vorbestimmten Wert ist.
  • Eine Ausführungsform der vorliegenden Erfindung weist das Kennzeichen auf, dass ein Frame der zweiten Folge wenigstens 20 Bits für Daten von der ersten Sequenz und höchstens 4 Bits für den Frametypidentifizierer aufweist, wobei die gesamte Framelänge 24 Bits beträgt. Dies führt zu einer Framelänge, die ein Vielfaches von 8 Bits ist und deswegen einfacher verarbeitet werden kann da die meisten Anordnungen vorgesehen sind zum verarbeiten von Daten in einem Vielfachen von 8 Bits. Diese Framelänge ermöglicht es ebenfalls, dass das Frame in ein Hilfsframe entsprechend dem IEC958-Standard einge bettet ist, wodurch eine weitere Standardisierung der Datenkommunikation zwischen verschiedenen Anordnungen ermöglicht wird.
  • Eine Ausführungsform der vorliegenden Erfindung weist das Kennzeichen auf, dass je nach dem Datentyp ein Frame 20 Bits für Daten und 4 Bits für den Frametypidentifizierer oder 22 Bits für Daten und 2 Bits für den Frametypidentifizierer aufweist. Dies ermöglicht es, dass mehr Daten in ein Frame gesteckt werden können, und zwar in Fällen, wo dies notwendig ist. Wenn beispielsweise Daten von einem DAB-Empfänger in die zweite Folge umgewandelt werden, können MSC-Daten nicht völlig in ein Frame gepasst werden das nur 20 Datenbits hat. Durch Reduktion des Frametypindikators und durch Steigerung des Datenfeldes um zwei Bits, werden diese MSC Daten in die zweite Folge passen.
  • Eine Ausführungsform der vorliegenden Erfindung, wobei der Empfänger Mittel aufweist zum Decodieren von Daten, eingebettet in das DAB-Signal, weist das Kennzeichen auf, dass die Umwandlungsmittel dazu vorgesehen sind, die von den Mitteln zum Decodieren von Daten gelieferten decodierten Daten als eine einzelne Folge zu der Folge hinzuzufügen.
  • Durch diese Maßnahme ist es möglich, gerade diejenigen Daten, die nicht auf bequeme Weise in den Ausgangsdaten des Kanaldecoders vorhanden sind, an eine zugreifbare Stelle in der zweiten Folge zu setzen. Ein Beispiel davon sind die TII-Daten, die nicht ein Teil der ersten Folge sind, sondern in dem Null-Symbol des DAB-Signals codiert sind.
  • Eine weitere Ausführungsform der vorliegenden Erfindung weist das Kennzeichen auf, dass die decodierten Daten DAD-Daten sind. Ein weiteres Beispiel von Daten, auf die nicht leicht von der ersten Folge zugegriffen werden kann, sind die PAD-Daten, die mit der Audi-Information in der ersten Folge zusammen genommen werden. In der zweiten Folge werden sie normalerweise auch mit der Audioinformation assoziiert. Dies erfordert, dass die Randapparatur einen Audiodecoder aufweist zum Zurückgewinnen der PAD-Daten. Da ein DAB-Empfänger mit einem Audiodecoder versehen ist, sind die PAD-Daten bereits in dem Empfänger verfügbar. Durch Hinzufügung der PAD-Daten als eine einzelne Folge zu der zweiten Folge, braucht ein Randgerät nicht länger die Audioinformation zusammen mit den PAD-Daten zu decodieren um die PAD-Daten wieder zu gewinnen, aber das Gerät kann die PAD-Daten unmittelbar in der zweiten Folge finden. Dies vereinfacht das Wiedergewinnen der PAD-Daten aus der zweiten Folge wesentlich.
  • Eine Ausführungsform der vorliegenden Erfindung weist das Kennzeichen auf, dass ein Frame der zweiten Folge in ein IEC958 Subframe eingebettet ist und dass die Umwandlungsmittel dazu vorgesehen sind, die einzelne Folge mit PAD-Daten in einen Benutzerdatenkanal in dem IEC958 Subframe einzufügen. In dem IEC958 Format kann der Benutzerdatenkanal nach Belieben verwendet werden. Durch Verwendung des Benutzerdatenkanals für die PAD-Daten brauchen keine regelmäßigen Frames in der zweiten Folge zum Hinzufügen der PAD-Daten zu der zweiten Folge geopfert zu werden.
  • Ausführungsbeispiele der Erfindung sind in der Zeichnung dargestellt und werden im Folgenden näher beschrieben. Es zeigen:
  • 1 ein Diagramm einer Ausführungsform eines Empfängers zum Empfangen digitaler Symbole nach der vorliegenden Erfindung,
  • 2 ein Diagramm eines DAB-Übertragungsframes,
  • 3A ein Diagramm eines Frames der zweiten Folge nach einer Ausführungsform der vorliegenden Erfindung,
  • 3B ein Diagramm eines IEC958 Subframes,
  • 4 ein Diagramm eines Beispiels der Struktur einer PAD-Nachricht zur Verwendung in einem Empfänger nach der vorliegenden Erfindung,
  • 5A ein Diagramm des ersten Kopfes IU einer Benutzerdatennachricht,
  • 5B ein Diagramm des zweiten Kopfes IU einer Benutzerdatennachricht,
  • 5C ein Diagramm des dritten Kopfes IU der Benutzerdatennachricht,
  • 5D ein Diagramm eines Daten-IU der Benutzerdatennachricht.
  • In den Figuren sind entsprechende Elemente mit denselben Bezugszeichen angegeben.
  • 1 ist ein Diagramm einer Ausführungsform eines Empfängers zum Empfangen digitaler Signale nach der vorliegenden Erfindung. Eine Empfangsantenne 2 ist mit einem ersten Eingang des Empfängers verbunden. Der Eingang des Empfängers ist mit einer Front-End-Einheit 4 verbunden. Ein Ausgang der Front-End-Einheit 4 ist mit einem Eingang eines FFT-Prozessors 6 verbunden. Ein Ausgang des FFT-Prozessors 6 ist mit einem Eingang eines Kanaldecoders 8 verbunden.
  • Ein Empfänger zum Empfangen digitaler Signale kann in dem "Digital Audio Broadcast"-System (DAB-System) verwendet werden. Ein OFDM-Signal mit einer Anzahl Träger, wobei diesen Trägern digitale Signale aufmoduliert sind, wird von dem Empfänger empfangen, verstärkt und in der Front-End-Einheit 4 in der Frequenz umge wandelt. Das Ausgangssignal der Front-End-Einheit 4 wird danach dem FFT-Prozessor 6 zur Demodulation zugeführt, und zwar zum Erhalten der digitalen Signale. An dem Ausgang des FFT-Prozessors 6 sind codierte und verschachtelte Signal verfügbar. Der FFT-Prozessor 6 liefert ebenfalls Information an einen Signalprozessor 14 zur Synchronisation der Front-End-Einheit 4. Der Signalprozessor kann auch Information aus dem FFT-Prozessor 6 über die Feldstärke der empfangenen Sender und die Identifikation der Sender, die "Transmitter Identification Information" oder TII, zurück gewinnen. Diese TII ist in einem Null-Symbol an dem Start jedes DAB-Frames vorhanden. Die Signale an dem Ausgang des FFT-Prozessors 6 werden entschachtelt und von dem Decoder 8 decodiert, und zwar zum Erhalten der rekonstruierten digitalen Signale. Ein Audio-Decoder, beispielsweise der Philips SAA2500, ist mit dem Ausgang des Decoders 8 gekoppelt, und zwar zum Decodieren dieser digitalen Signale mit Audioframes. An einem ersten Ausgang liefert der Audiodecoder 10 "Program Associated Data" (PAD), die in die Audioframes eingebettet sind. Diese PAD werden zur Weiterverarbeitung einer Steuereinheit 12 zugeführt. An einem zweiten Ausgang liefert der Audiodecoder 10 Audiodaten 32. Die Steuereinheit 12 steuert weiterhin die Abstimmung des Empfängers und die Decodierung in dem Decoder 8. Die Steuereinheit 12 hat eine Schnittstelle, die Daten 34 aufweist zum Empfangen von Information von einem Benutzer und zum Liefern von Information an den Benutzer.
  • 2 ist ein Diagramm eines DAB-Übertragungsframes. Das DAB-Frame umfasst drei Felder: einen Synchronisationskanal SC, einen Schnellinformationskanal FIC und einen Hauptdienstkanal MSC. Der FIC umfasst eine Anzahl Schnellinformationsblöcke FIB. Diese Anzahl ist abhängig von der DAB-Übertragungsmode. In der Mode I umfasst das DAB-Frame 12 FIBs, in der Mode II 3 FIBs und in der Mode III 4 FIBs. Der Hauptdienstkanal umfasst eine Anzahl gemeinsamer verschachtelter Frames (CIFs). Diese Anzahl ist ebenfalls abhängig von der DAB-Übertragungsmode. In der Mode I umfasst das DAB-Frame 4 CIFs, in der Mode II 1 CIF und in der Mode III 1 CIF. In der Mode I werden die ersten 3 FIBs dem ersten CIF zugeordnet, die zweiten 3 FIBs werden dem zweiten CIF zugeordnet usw. Der Hauptdienstkanal ist ein zeitverschachtelter Datenkanal, aufgeteilt in eine Anzahl Subkanäle, die je eine Subkanalidentifikationsnummer SUBCHId haben, und jeder Subkanal kann ein oder mehrere Dienstelemente, wie Audio, Daten usw. tragen. Der MSC ist weiterhin in Kapazitätseinheiten von 64 Bits aufgeteilt und ein Subkanal kann eine oder mehrere dieser Kapazitätseinheiten besetzen. Die Organisation der Subkanäle und de ren Lage in Kapazitätseinheiten wird, nebst anderen Items, in dem FIC übertragen. Für eine detaillierte Beschreibung eines DAB Übertragungsframes, dessen Struktur und dessen Inhalt sei auf das nachfolgende Dokument verwiesen: "Radio Broadcast Systems; Digital Audio Broadcasting (DAB) to mobile, portable and fixed receivers" "ETS 300 401", veröffentlicht von dem "European Telecommunications Standards Institute" Sophia Antipolis, 1995.
  • In dem Empfänger nach 1 kann der Decoder 8, wie zurzeit verwendet, nicht die ganze DAB Folge insgesamt decodieren, sondern kann nur selektierte Teile der DAB Daten decodieren. So instruiert beispielsweise ein Benutzer die Steuereinheit 12 die Audiodaten von einem Programm, beispielsweise "Radio 3" einem Decoder 10 zu liefern. Die Steuereinheit 12 analysiert dann den FIC und bestimmt, über welchen Subkanal in dem Hauptdienstkanal das Programm von "Radio 3" anwesend ist. Die Steuereinheit 12 bestimmt danach, welche Kapazitätseinheiten diesem Subkanal zugeordnet sind, beispielsweise die CUs 6, 7 und 8. Die Steuereinheit 12 instruiert danach den Decoder 8 zu decodieren und die decodierten Daten von den CUs 6, 7 und 8 auszuliefern und ein erstes Fenstersignal zu aktivieren um zu signalisieren, dass die decodierten Daten vorhanden sind. Der Audiodecoder 10 empfängt die Daten und das Fenstersignal und liefert die Audiodaten an dem Ausgang. Auf diese Weise kann der Decoder 8 nur einen begrenzten Betrag an Daten liefern. Ein künftiger Decoder 8 wird imstande sein, die kompletten decodierten Daten von dem DAB Signal zu liefern.
  • Der Empfänger nach 1 umfasst weiterhin nach der vorliegenden Erfindung Umwandlungsmittel 16, welche die nachfolgenden Elemente aufweisen:
    • – einen ersten Eingang, der mit dem Ausgang des Decoders 8 gekoppelt ist zum Empfangen der ersten Folge von Daten, wobei die Folge entweder eine ganze DAB Datenfolge enthält oder wenigstens einen Teil der genannten DAB Datenfolge, und zwar je nach dem Decoder 8, wie oben erwähnt;
    • – einen Ausgang zum Liefern einer zweiten Folge von Daten 36, organisiert in Frames eines zweiten Typs, wobei eine Framelänge vom ersten Frametyp anders ist als eine Framelänge vom zweiten Frametyp, wobei die zweite Folge wenigstens zwei einzelne Folgen aufweist, wobei jede der einzelnen Folgen für einen anderen Datentyp reserviert ist, und in Frames vom zweiten Typ geliefert sind, wobei jedes Frame vom zweiten Typ einen Frametypidentifizierer aufweist zum Identifizieren der einzelnen Folgen innerhalb der zweiten Folge.
  • Nach einem weiteren Aspekt der vorliegenden Erfindung haben die Umwandlungsmittel 16 einen zweiten Eingang, der mit einem zweiten Ausgang des Signalprozessors 14 gekoppelt ist zum Empfangen von TII, in dem Null-Symbol eines DAB-Signals. Der Signalprozessor 14 liefert auch die relative Feldstärke, wie diese aus dem FFT des Null-Symbols gemessen wird, und gewünschtenfalls auch Werte der phasengleichen und Quadraturkomponenten selektierter Trägerpaare. Die Umwandlungsmittel 16 können danach die TII und die anderen Daten einfügen, die von dem Signalprozessor 14 geliefert werden, und zwar in die zweite Folge. Wie dies gemacht wird, wird nachstehend detailliert beschrieben, wobei der Inhalt der Frames in der zweiten Folge behandelt wird.
  • Nach einem anderen Aspekt der vorliegenden Erfindung, der sogar separat von den vorstehenden Aspekten der vorliegenden Erfindung gesehen werden kann, haben die Umwandlungsmittel 16 einen dritten Eingang, der mit dem zweiten Ausgang des Audiodecoders 10 gekoppelt ist, der die PAD-Daten liefert. Diese PAD-Daten werden danach auch in die Folge eingefügt. Dies kann auf dieselbe Art und Weise gemacht werden, wie bei TII und den assoziierten Daten, wobei ein einzelner Datentypidentifizierer für PAD geschaffen wird und die PAD-Daten in ein einzelnes Paket eingefügt werden. Dies ist nicht weiter detailliert beschrieben, In einer bevorzugten Ausführungsform, die nachstehend detailliert beschrieben wird, wird PAD in die zweite Folge in einem Benutzerdatenkanal eingefügt, wenn die Frames vom zweiten Typ Frames entsprechend dem IEC958 Format sind.
  • Ein anderer Name für die Umwandlungsmittel 16 ist Liefermittel, da die Umwandlungsmittel im Wesentlichen die zweite Folge mit Daten zu der Außenwelt liefern, u. a. an die Randapparatur usw.
  • 3A ist Diagramm eines Frames der zweiten Folge nach einer Ausführungsform der vorliegenden Erfindung. In der vorliegenden Erfindung wird die erste Folge von Daten in eine zweite Folge von Daten umgewandelt mit einer Framelänge, die anders ist als die Framelänge in der ersten Folge. In einer Ausführungsform ist die Framelänge in der zweiten Folge auf 24 Bits gewählt, von denen die ersten 20 Bits b0 ... b19 für Daten (DT) reserviert sind und die Bits b20 ... b23 für einen Frametypidentifizierer (FTL). Diese Wahl ermöglicht es, dass das Frame der zweiten Folge in einem Subframe entsprechend dem IEC958 Standard einverleibt wird. Für mehr Einzelheiten über diesen Standard sei auf den nachfolgenden Artikel verwiesen: "Digital Audio Interface", "International Standard IEC 958", veröffentlicht vom "Bureau Central de la Commission Electrotechnique Internationale", Schweiz 1989.
  • 3B ist ein Diagramm eines IEC958 Subframes. Das IEC958 umfasst ein 4 Bit Präambel PR, ein 4 Bit Feld für Hilfsdaten AXD, ein 20 Bit Feld für Audiodaten AD und vier 1 Bit Felder: ein Gültigkeitsmerkerbit V, ein Benutzerdatenkanalbit U, ein Kanalzustandsbit C und ein Paritätsbit P. Das Kanalzustandsbit C trägt ein Bit eines Kanalzustandswortes, was Information über die Daten erteilt, die in einem Kanal getragen werden. Das Benutzerdatenkanalbit U trägt ein Bit des Benutzerdatenkanals. Wenn das Frame der zweiten Folge in dem IEC958 Subframe einverleibt ist, wird es an Bitstellen a4 ... a27 getragen. Das Gültigkeitsmerkerbit V soll dann auf "1" gesetzt werden um eine zufällige Decodierung durch einen Audiodecoder zu vermeiden. In dem Kanalzustandswort soll der Zustand auf "Nicht-Audio" gesetzt werden (Bit 1 von Byte 0), "copyright" soll aufrechterhalten werden (Bit 2 von Byte 0 = "0"). Bits 3, 4 und 5 von Byte 0 soll auf "000" gesetzt werden und die Bits 6 & 7 von Byte 0 sollen auf Mode 0 gesetzt werden (= "00"). Der Kategoriecode '001" für Funkempfang von digitalem Audio soll benutzt werden (Bits 0, 1, 2 von Byte 1 = "001"). Das Erzeugungszustandsbit soll auf "original" gesetzt werden (Bit 7 von Byte 1 = "0"). In Byte 2 sollen die Quellennummer und die Kanalnummer "nicht spezifiziert" sein (Byte 2 = "00000000"). Die Abtastfrequenz soll 48 kHz sein (Bits 0, 1, 2, 3 von Byte 3 = "0100"). Die Taktgenauigkeit von etwa 100 ppm soll "Pegel II" sein (Bits 4, 5 von Byte 3 = "00"). Auf diese Weise wird empfohlen, die ersten vier Bytes des Kanalzustandswortes wie folgt zu setzen: Byte 0 auf "01000000", Byte 1 auf "00100100", Byte 2 auf "00000000" und Byte 3 auf "01000000". Die Bits 3, 4, 5, 6 in Byte 1 werden auf "0010" gesetzt, was ein Vorschlag ist für einen Eingang "DAB", der in der Kategorie "Funkempfang" definiert werden soll.
  • Die Tabelle 1 zeigt ein Beispiel für die Werte von Bits b20 ... b23 des Frametypidentifizierers.
  • Tabelle 1. Werte der Frametypidentifiziererbits b20 ... b23
    Figure 00090001
  • Figure 00100001
  • Frametypidentifiziererwerte "0001", "XX10", "0100" und "0111" bezeichnen eine Datenübertragung in Paketen. Die Werte '0001" und "0111" signalisieren den Start eines Pakets, wobei der Wert "0111" sogar auch den Datentyp in dem Paket identifiziert, der Wert "XX10" eine Fortsetzung des Pakets signalisiert und der Wert "0100" das Ende des Pakets signalisiert. Ein Vorteil von Datenübertragung ist, dass nur wenig Gesamtkosten verwendet werden, da nur ein Kopfframe – und möglicherweise ein Nachspannframe als Gesamtkosten verwendet werden, was beispielsweise den Datentyp und die Länge des Pakets signalisiert. Die Datenübertragung hoher Kapazität ist besonders nützlich in Kombination mit künftigen Kanaldecodern 8, welche die kompletten DAB-Daten decodieren können.
  • Der Frametypidentifiziererwert "XX10" bedeutet, dass die Werte der Bits b20 und b21 nicht ausmachen. Dies ist besonders günstig, wenn die 20 Datenbits, die von den Bits b0 ... b19 geliefert werden, nicht ausreichen und ein oder zwei weitere Datenbits in einem Fortsetzungsframe erforderlich sind. In diesem Fall werden die Bits b20 und b21 zu den Datenbits hinzugefügt, wodurch ein Datenfeld von 22 Bits verwirklicht wird. Wenn die Bits b20 und b21 nicht als Datenbits verwendet werden, je nach dem Datentyp in dem Paket, sollen sie vorzugsweise auf "00" gesetzt werden. In dem Fall beispielsweise von MSC-Daten werden die Bits b20 und b21 zu dem Datenfeld hinzugefügt, während in dem Fall von FIC oder TII Daten die Bits b20 und b21 ein Teil des Frametypidentifizierers sind.
  • Der Frametypidentifizierertyp "1111" signalisiert ein Frame mit Daten und dem Datentypidentifizierer. Da jedes Frame einen derartigen Identifizierer aufweist, ist es möglich, jedes Frame unabhängig von dem anderen zu verarbeiten. Dies macht die Verarbeitung von Frames am Empfangsende sehr einfach auf Kosten großer Gesamtkosten, da nun alle Frames einen Datentypidentifizierer aufweisen sollen.
  • Der Frametypidentifiziererwert "0000" signalisiert ein Füllframe, das an allen Stellen b0 ... b19 normalerweise nur eine logische "0" aufweist. Dieser Frametyp wird verwendet, wenn keine Daten bereit sind um übertragen zu werden und gewährleistet einen kontinuierlichen Fluss von Frames in der zweiten Folge, wenn keine Daten vorhanden sind.
  • Der Frametypidentifiziererwert "0101" signalisiert den Start eines Frames in der ersten Folge, d.h. beispielsweise ein logisches DAB Frame. Dieses Frame kann an den restlichen Bitstellen b0 ... b19 gewisse Information enthalten. In diesem Sinne sind die Bits b0 ... b3 für einen Synchronisationsframeinhalt-Indikator SFCI reserviert, in diesem Fall mit beispielsweise einem Wert von "0001", wodurch angegeben wird, dass ein Inhaltsfeld CF, d.h. die restlichen Bits b4 ... b19 die Anzahl korrigierter Fehler enthält, die durch Neucodierung des FICs des vorhergehenden DAB Frames detektiert worden sind. Andere Werte von Bits b0 ... b3 sind reserviert.
  • Im Falle einer Datenübertragung mit geringer Kapazität (wobei TII Frametypidentifiziererwerte "0111" in Verbindung mit "XX10" und "0100" und dem Frametypidentifiziererwert "1111" verwendet werden) werden die Frames, die einen Frametypidentifiziererwert "1111' haben, beispielsweise über den Kanal A des IEC958 Formats übertragen und die TII Frames, wenn überhaupt, werden alle über den Kanal B des IEC958 Formats übertragen. Die Datenübertragung mit geringer Kapazität ist besonders nützlich in Kombination mit dem zurzeit verwendeten Kanaldecoder 8, da nur ein begrenzter Betrag an Daten übertragen zu werden braucht.
  • Auf diese Weise steckt das Umwandlungsmittel 16 die TII und die assoziierten Daten entweder in ein Paket für Datenübertragung mit hoher Kapazität oder in ein Paket für Datenübertragung mit geringer Kapazität. Dasselbe gilt für die anderen Daten, wie MSC-Daten und FIC-Daten. Es dürfte einleuchten, dass Obenstehendes nur als Illustration interpretiert werden soll und das dies die vorliegende Erfindung nicht begrenzen soll.
  • Wie in der Tabelle 1 angegeben, gibt es Frametypidentifizierer für Datenübertragung mit geringer Kapazität. Diese haben die Werte "1111" und "0111" (mit den assoziierten Werten "XX10" und "0100" um den restlichen Teil eines Pakets anzugeben).
  • Frames mit einem Frametypidentifiziererwert "1111" umfassen 8 Bits mit Daten DT, vorzugsweise an den Bitstellen b8 ... b15 in dem Frame nach 3A. Ein Datentypidentifizierer DTI wird zu dem Frame an den Bits b6, b7 hinzugefügt, um den Ursprung der Daten anzugeben und um die Verwendung eines 6-Bit Feldes IDF in den Bits b0 ... b5 des Frames anzugeben, wie in der Tabelle 2 illustriert.
  • Tabelle 2. Datentypidentifiziererbits b6, b7 in einem "1111" Frame
    Figure 00110001
  • Figure 00120001
  • Der SubChId ist ein Identifizierer zum Identifizieren eines Subkanals innerhalb des MSC, wie oben erläutert. Der Kanaldecoder 8 aus 1 kann Fenstersignale liefern, zusammen mit der DAB Datenfolge. Ein derartiges Fenstersignal wird aktiv gemacht zu den Zeiten, in denen Daten in der DAB Datenfolge vorhanden sind, die zu einem bestimmten Datentyp gehören. So hat beispielsweise eine Steuereinheit aus dem FIC hergeleitet, dass in den Kapazitätseinheiten 6, 7 und 8 des MSCs ein bestimmter Subkanal vorhanden ist. Dann instruiert die Steuereinheit den Kanaldecoder 8 das Fenstersignal 1 zu dem Zeitpunkt zu aktivieren, wo decodierte Daten von den Kapazitätseinheiten 6, 7 und 8 an dem Ausgang des Kanaldecoders vorhanden sind. Danach signalisiert das Fenstersignal 1 das Vorhandensein decodierter Daten von den Kapazitätseinheiten 6, 7 und 8 an dem Ausgang und die Steuereinheit weiß, dass diese Daten mit der bestimmten Subkanalnummer assoziiert ist. In dem Frameformat können 16 verschiedene Fenstersignale von dem Kanaldecoder dadurch unterschieden werden, dass ein 4-Bit Fenstersignalidentifizierer an den Bitstellen b16 ... b19 in dem Frame vorgesehen wird. Ein Fenstersignal kann dadurch mit einem Subkanal gekoppelt werden, dass die SubChId in das ID-Feld an den Bitstellen b0 ... b5 des Frames eingefügt wird, in dem Fall, dass Daten von dem MSC herrühren. In anderen Fällen ist das ID-Feld reserviert. Eines der Fenstersignale kann zum Füllen verwendet werden, was angibt, dass keine Daten verfügbar sind.
  • Der Frametypidentifiziererwert "0111" bezeichnet den Kopf eines TII-Informationspakets für Datenübertragung mit niedriger Kapazität, und funktioniert auf diese Weise auch als Datentypidentifizierer. Frames mit Framewerten "XX10" und "0100" tragen Daten. In dem Kopfframe (Wert "0111") ist ein 5-Bit Wort an den Bitstellen b11 ... b15 reserviert um die Anzahl empfangener Sender (NRT) anzugeben. NRT kann zwischen 1 und 24 liegen. Die anderen Werte sind reserviert. Es gibt (NRT-1) Fortsetzungsframes und ein Nachspannframe und sie werden wie folgt gefüllt. Jedes dieser Frames umfasst eine 5-Bit SubId an den Bitstellen b8 ... b12 und eine 7-Bit HauptId an den Bitstellen b13 ... b19, wobei die HauptId und die SubId aus dem Abschnitt 8.1.9 des Dokumentes "Ra dio Broadcast Systems; Digital Audio Broadcasting (DAB) to mobile, portable and fixed receivers" "ETS 300 401", veröffentlicht von dem "European Telecommunications Standards Institute" Sophia Antipolis, 1995 bekannt sind. Weiterhin sind 3 Bits (b5 ... b7) reserviert um eine relative Feldstärke anzugeben, die von "001", was ein sehr schwaches Signal bedeutet, bis "111" reicht, was ein sehr starkes Signal angibt. Der Wert "000" bezeichnet "nicht signalisiert". Die restlichen Bits b0 ... b4 sind reserviert. Wie oben erwähnt, hat das letzte Datenframe den Frametypidentifiziererwert "0100", enthält aber dieselbe Art von Daten wie die Fortsetzungsframes, da kein spezifisches Nachspannframe erforderlich ist.
  • Bei der Datenübertragung mit geringer Kapazität können die TII Frames mit den Datenframes mit dem Frametyp 1111 abgewechselt werden. Füllframes können beliebig eingefügt werden.
  • Der Frametypidentifizierer "0001" identifiziert ein Kopfframe mit Paketen für eine Datenübertragung mit hoher Kapazität. Dazu bilden die Bits b18 und b19 in dem Kopfframe einen Datentypidentifizierer und sind reserviert um den Datentyp in dem Paket anzugeben, wie in der Tabelle 3 dargestellt.
  • Tabelle 3. Datentypidentifiziererbits b18, b19 in einem "0001" Frame
    Figure 00130001
  • Der Frametypidentifiziererwert "XX10" signalisiert ein Fortsetzungsframe, d.h. ein Frame, das ein Teil eines Pakets ist und der Frameidentifiziererwert "0100" kann als ein Nachspannframe betrachtet werden, welches das Ende eines Pakets signalisiert.
  • In dem Fall, dass MSC-Daten übertragen werden (b18 = 0 b19 = 1), kann das Kopfframe in den Bits b0 ... b11 die Anzahl M von RDI-Frames enthalten, d.h. die Länge des Pakets, und in den Bits b12 ... b17 den Subkanalidentifizierer. Alle Fortsetzungsframes tragen Daten. Das vorletzte Frame in dem Paket umfasst Daten und Füllbits, da es sein kann, dass die gesamte Anzahl Datenbits mit der gesamten Anzahl verfügbarer Datenbits in dem Paket nicht übereinstimmt. Das Nachspannframe umfasst ein 16 Bit Feld, das die Anzahl durch Neucodierung detektierter korrigierter Fehler spezifiziert. Ausnahmsweise soll der Code "1111 1111 1111 1111" angeben, dass diese Information nicht signalisiert worden ist. In dem Fall, dass MSC Daten übertragen werden, wird der Frametypidentifizierer mit einem Wert "XX10" vorzugsweise auf gerade die zwei letzten Bits gekürzt: "10". Aus der Tabelle 1 dürfte es einleuchten, dass diese zwei letzten Bits ausreichen zum Erkennen eines Fortsetzungsframes. Dies führt zu 2 zusätzlichen Bits (b20 und b21) für Daten, wodurch auf diese Weise das Feld von 10 Bits auf 24 Bits erweitert wird. In anderen Fällen, wo die 2 zusätzlichen Datenbits nicht erforderlich sind, werden diese Datenbits auf "00" gesetzt.
  • In dem Fall, dass FIC Daten übertragen werden (b18 = 0 b19 = 1) umfasst das Kopfframe zwei Bits, welche die DAB Übertragungsmode angeben, beispielsweise die Bits b14 und b15. Die Tabelle 4 zeigt die Werte der Bits b14 und b15 und die assoziierte DAB Übertragungsmode.
  • Tabelle 4. DAB Übertragungsmodebits b14, b15 in dem FIC Kopfframe.
    Figure 00140001
  • In dem FIC Kopfframe sind 4 Bits (beispielsweise die Bits b10 ... b13) für eine FIB-Nummer reserviert. In den DAB Übertragungsmoden II und III ist das FIB-Nummerfeld als eine binäre Zahl ohne Vorzeichen codiert, welche die FIB spezifiziert. In der Tabelle 5 ist die Codierung der FIB-Nummer gegeben.
  • Tabelle 5. Codierung der FIB-Nummerbits b10 ... b13 in der Mode I
    Figure 00140002
  • Das Nachspannframe mit dem Frametypidentifiziererwert "0100" enthält in dem Fall eines FIC Pakets Folgendes. Drei Bits (beispielsweise die Bits b16 ... b18) sind für einen Fehleridentifikationstyp (EIT) reserviert, der die Art der in einem 16 Bit Fehlerprüffeld (ECF) getragenen Daten spezifiziert (beispielsweise die Bits b0 ... b15). Die Tabelle 6 zeigt die Codes für den EIT und den relatierten Inhalt in dem ECF.
  • Tabelle 6. Codierung der EIT-Bits b16 ... b18 und das relatierte ECF.
    Figure 00150001
  • In der DAB Übertragungsmode I können die 12 FIBs, die in einem einzigen Übertragungsframe enthalten sind, alle 96 ms in einem, oder als vier Reihen zu 3 FIBs mit Intervallen von 24 ms übertragen werden.
  • In dem Fall, dass TII Daten übertragen werden (b18 = 1 b19 = 0) umfasst das Kopfframe weiterhin einen TII Formatidentifizierer, der in diesem Beispiel 3 Bits b8 ... b10 enthält. Der TII Formatidentifizierer mit einem Wert von "010" bezeichnet ein Basisformat und der Wert "001" bezeichnet ein erweitertes Format. Wie bei dem Format mit geringer Kapazität (Frametypidentifiziererwert = "0111") enthalten die Bits b11 ... b15 den NRT.
  • In dem Basisformat (wobei b8 ... b10 in dem Kopf gleich "010" ist), ist der restliche Teil des TII Pakets derselbe wie in dem Format mit geringer Kapazität).
  • In dem erweiterten Format (wobei b8 ... b10 in dem Kopf gleich "001" ist), werden die ersten NRT Fortsetzungsframes auf gleiche Weise gefüllt wie in dem Basisformat, nun aber werden die Bits b1 ... b4 wie folgt verwendet. Bit b1 ist ein Nullsymbolindikator, der sich ändert, wenn Daten von einem neunen Nullsymbol zum ersten Mal übertragen werden. In dem erweiterten Format werden die komplexen Ergebnisse der diskreten Fourier-Transformation, wie diese in dem FFT-Prozessor 6 nach 1 an den Abtastwerten des Nullsymbols der selektierten Trägerpaare durchgeführt worden ist, geliefert. Dazu be zeichnen die Bits b2 ... b4 die Anzahl Trägerpaare (NCP), für die Information geschaffen wird für den von der HauptID und der SubId identifizierten Sender. In den Fortsetzungsframes hinter der Anzahl NRT Frames, wie oben beschrieben, enthalten 16 Bits, codiert als Binärkomplement, den reellen oder den imaginären Teil des FFT-Ergebnisses an den Abtastwerten des Nullsymbols für jedes der Anzahl Trägerpaare, wie durch NCP bezeichnet für jeden Sender, wie in der Anzahl NRT Frames identifiziert.
  • Die zeitliche Reihenfolge der Übertragung von Daten von dem MSC Subkanälen, dem FIC und TII in jedem Format ist beliebig. Füllframes können an jeder Stelle eingefügt werden. Es ist aber eine Regel, dass alle Daten, die sich auf ein einziges logisches DAB Frame beziehen, innerhalb des Intervalls gesendet werden, das durch zwei aufeinander folgende Übertragungen eines Synchronisationsframes definiert ist. TII Daten können gewünschtenfalls in verschiedenen Paketen gesendet werden. TII Information für jedes Trägerpaar soll vorzugsweise nur einmal je bewertetes Nullsymbol übertragen werden. Diese Information kann aber über verschiedene logische Frames verteilt werden. Der Start eines neuen Datensatzes wird durch einen neuen Wert des Nullsymbolindikators angegeben.
  • In der ersten Folge gibt es nur diejenigen TII-Daten, die bereits in dem FIC einverleibt sind. Ein DAB Signal umfasst ebenfalls TII-Daten in dem Nullsymbol an dem Anfang jedes DAB-Frames. In der vorliegenden Erfindung werden diese TII-Daten zusammen mit Daten in Bezug auf die relative Feldstärke der empfangenen Sender aus dem FFT-Prozessor 6 zurück gewonnen, und in die zweite Folge eingefügt.
  • In der ersten Folge sind PAD-Daten zusammen mit Audioinformation in dem Bitstrom eingebettet. Zum Wiedergewinnen dieser PAD-Daten ist es notwendig, dass zunächst die Audio-Frames und danach daraus die PAD-Daten wieder gewonnen werden. Dies ist ein aufwendiger Vorgang, der extra Hardware kostet. In den meisten DAB-Empfängern sind Audi-Decodiermittel vorhanden, die ebenfalls die PAD-Daten aus den Audio-Frames wiedergewinnt. Nach der vorliegenden Erfindung kann dies auf vorteilhafte Weise dadurch verwendet werden, dass diese DAP-Daten als eine einzelne Folge in die zweite Folge eingefügt werden. Dadurch kann ein Randgerät, dass die zweite Folge empfängt, einfacher die PAD-Daten aus der zweiten Folge wiedergewinnen, da keine Audio-Decoder erforderlich sind.
  • 4 zeigt ein Beispiel der Struktur einer PAD-Nachricht zur Verwendung in einem Empfänger nach der vorliegenden Erfindung, wobei die PAD-Daten in die zweite Folge eingefügt werden. Die PAD-Nachricht umfasst:
    • – einen Kopf (HDR) um zu signalisieren, dass die Nachricht die Struktur hat, wie diese nachstehend beschrieben wird,
    • – einen Längenindikator (LI), der die Anzahl Bytes spezifiziert, die in der PAD-Nachricht folgt,
    • – ein Zwei-Byte-Feld (F-PAD), das das F-PAD trägt, wie in ETS 300 401 definiert. Die zwei F-PAD Bytes befinden sich in der logischen Ordnung,
    • – falls vorgesehen, ein weiteres Feld (X-PAD), das eine Anzahl Bytes von dem X-PAD Feld trägt, wie in ETS 300 401 definiert. Diese Bytes befinden sich auch in der logischen Reihenfolge.
  • Der Kopf und der Längenindikator sind vorzugsweise ein Ein-Byte-Feld, wobei der Kopf den hexadezimalen Wert "AD" zur Identifikation der Nachrichtenstruktur enthalten soll. Das X-PAD-Feld ist fakultativ; das Vorhandensein und die Länge kann aus dem Längenidikator LI hergeleitet werden. An dieser Stelle sei bemerkt, dass der DAB-Empfänger mehr Bytes in dem X-PAD-Feld schaffen kann als diejenigen, die wirklich X-PAD-Daten enthält; in dem Fall transportiert der DAB-Empfänger nur Bytes von dem Ende eines Audio-Frames ohne Unterschied, ob sie Audio-Daten oder PAD-Daten enthalten.
  • In einer bevorzugten Ausführungsform können die PAD-Nachrichten über den Benutzerdatenkanal der IEC958 transportiert werden. Dies bedeutet, dass die Information in Informationseinheiten (IU) getragen werden soll, wobei jede IU 8 Bits aufweist, wobei das erste ein Startmerker (SF) ist, der immer auf "1" gesetzt wird, wonach 7 Informationsbits folgen. Eine Benutzerdatennachricht umfasst einen Kopf von drei IUs und eine Anzahl Daten-IUs.
  • 5A ist ein Diagramm der ersten Kopf-UI einer Benutzerdatennachricht. Die erste UI umfasst zunächst ein Fünf-Bit-Feld, das einen Identifizierer trägt zum Identifizieren des Typs der Nachricht (TMI). Vorzugsweise trägt dieses Feld die Binärzahl "10010". Es umfasst weiterhin ein Letzter-Merker-Bit (LF), auf "1" gesetzt, wenn diese Nachricht die letzte einer Reihe von Benutzerdatennachrichten ist, die zusammen eine einzige PAD-Nachricht transportieren. Sonst soll es auf "0" gesetzt werden. Zum Schluss umfasst es auch ein erster-Merker-Bit (FF), das gesetzt werden soll, wenn diese Nachricht die erste einer Reihe von Benutzerdatennachrichten enthält, die zusammen eine einzige PAD-Nachricht transportieren. Sonst soll es auf "0" gesetzt werden.
  • 5B ist ein Diagramm der zweiten Kopf-UI einer Benutzerdatennachricht. Die zweite IU in dem Kopf enthält den Nachrichtenlängenindikator (LI) von 7 Bits. Es sei bemerkt, dass der dritte Kopf IU in diesem Längenwert vorgesehen ist.
  • 5C ist ein Diagramm der dritten Kopf-IU der Benutzerdatennachricht. Die dritte IU in dem Kopf umfasst ein 7-Bit-Feld (OCO), das vorzugsweise den Herkunftkategoriecode des Kanalzustandes (Bits b0 ... b6 des Bytes 1) des IEC958 Formats dupliziert.
  • 5D ist ein Diagramm einer Daten-IU der Benutzerdatennachricht. Wenn die IU Daten trägt, d.h. einen Teil der PAD-Nachrichten, können die restlichen 7 Bits für Daten in dem Benutzerdatenfeld (UDF) benutzt werden. In einer bevorzugten Ausführungsform kann das zweite Bit in der IU (= das erste Bit des 7-Bit-Benutzerdatenfeldes) für einen Fehlermerker (EF) reserviert werden, der signalisiert, ob ein Fehler in den nachfolgenden sechs Benutzerdatenbits detektiert wurde. Auf diese Weise kann eine Benutzerdaten-IU vorzugsweise 6 Bits der Benutzerdaten in dem Benutzerdatenfeld (UDF) transportieren und sogar 7 Bits, wenn auf den Fehlermerker verzichtet wird. Das letzte UDF in einer Nachricht kann eine Anzahl Füllbits enthalten, wenn weniger als 6 (oder 7) Bits vorgesehen sind.
  • IUen innerhalb einer Benutzerdatennachricht können durch Füllbits mit einem logischen Wert "0" mit einem Maximum von 8 Füllbits, getrennt werden, da ein Bit mit einem Wert "1", der 9 aufeinander folgenden Bits mit einem logischen Wert "0" folgt, als den Start einer neuen Benutzerdatennachricht erkannt wird. Füllung zwischen IUen, die zu verschiedenen Benutzerdatennachrichten gehören, ist nicht auf eine maximale Länge begrenzt, solange die Länge wenigstens 9 Bits beträgt. Eine PAD-Nachricht, die nicht in eine einzige Benutzerdatennachricht passt, kann in verschiedene Benutzerdatennachrichten aufgeteilt werden. Das Aufteilen der PAD-Nachricht braucht nicht an einer Byte-Grenze zu sein. Der Kopf der Benutzerdatennachricht gibt an, dass die Nachricht DAB-PAD, die Länge der Benutzerdatennachricht enthält und ob die Nachricht der Start, die Fortsetzung oder das Ende einer Reihe von Nachrichten ist, die zusammen eine PAD-Nachricht bauen.
  • Das oben gegebene Beispiel der zusätzlichen Einfügung der PAD-Nachrichten in den IEC958 Benutzerdatenkanal ist besonders vorteilhaft aus den nachfolgenden Gründen. Es sind elektronische Schaltungsanordnungen verfügbar, die zum Codieren und Decodieren von Daten in dem Benutzerdatenkanal vorgesehen sind, separat von der Codierung und Decodierung anderer Daten. Dies ist sehr vorteilhaft zum Reduzieren der Codierungs/Decodierungskomplexität, insbesondere für diejenigen Randgeräte, auf die nur die PAD zuzugreifen braucht.
  • Die gegebenen Beispiele sind vorwiegend als eine Illustration der vorliegenden Erfindung gemeint. Die eingebetteten Daten brauchen nicht auf PAD in DAB-Daten begrenzt zu sein. Weiterhin kann die PAD im Rahmen der vorliegenden Erfindung auch in anderen Bitströmen, die nicht mit dem IEC958 übereinstimmen, und auch in einer anderen Struktur vorgesehen sein.

Claims (27)

  1. Wandler (16) zur Umwandlung einer ersten Datenfolge, organisiert in Frames eines ersten Typs, wobei die genannten Frames eine Anzahl Datentypen an vorbestimmten Stellen innerhalb eines Frames enthalten, in eine zweite Datenfolge, organisiert in Frames eines zweiten Typs, wobei eine Framelänge des ersten Frametyps anders ist als die Framelänge des zweiten Frametyps, wobei der Wandler zu den nachfolgenden Zwecken vorgesehen ist: – das Zerlegen der ersten Datenfolge in wenigstens zwei einzelne Datenfolgen, wobei jede Datenfolge der einzelnen Datenfolgen für einen vorbestimmten Datentyp reserviert ist, – das Aufteilen der einzelnen Folgen in Frames vom zweiten Typ, – das Zusammenstellen der einzelnen Folgen zu Frames eines zweiten Typs, wobei jedes Frame einen Frametypidentifizierer aufweist zum Identifizieren der einzelnen Folgen innerhalb der zweiten Folge, und weiterhin das Zusammenstellen der zweiten Folge aus den einzelnen Folgen.
  2. Wandler nach Anspruch 1, dadurch gekennzeichnet, dass der Wandler dazu vorgesehen ist, einen Datentypidentifizierer zu wenigstens einer der einzelnen Folgen hinzuzufügen zur Identifikation des Datentyps in der einzelnen Folge.
  3. Wandler nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die zweite Folge eine Anzahl Pakete umfasst, wobei eine einzelne Folge ein Paket umfasst, das eine Anzahl Frames in der zweiten Folge umfasst, wobei ein Paket durch vorbestimmte Werte des Frametypidentifizierers (FTI) identifiziert wird, wobei das Paket einen Kopf mit dem Datentypidentifizierer aufweist.
  4. Wandler nach Anspruch 1, 2 oder 3, dadurch gekennzeichnet, dass die zweite Folge einzelne Datenframes aufweist, die durch wenigstens einen weiteren vorbestimmten Wert des Frametypidentifizierers identifiziert wird, wobei jedes Frame in der zweiten Folge Daten und einen Datentypidentifizierer aufweist.
  5. Wandler nach Anspruch 1, 2, 3 oder 4, dadurch gekennzeichnet, dass der Wandler dazu vorgesehen ist, zu der zweiten Folge ein Synchronisationssignal hinzuzufügen, und zwar zur Signalisierung eines Starts eines Frames vom ersten Typ.
  6. Wandler nach Anspruch 5, dadurch gekennzeichnet, dass das Synchronisationssignal ein Frame mit einem Frametypidentifizierer mit einem vorbestimmten Wert ist.
  7. Wandler nach Anspruch 1, 2, 3, 4, 5 oder 6, dadurch gekennzeichnet, dass ein Frame der zweiten Folge wenigstens 20 Bits für Daten von der ersten Sequenz und höchstens 4 Bits für den Frametypidentifizierer aufweist, wobei die gesamte Framelänge 24 Bits beträgt.
  8. Wandler nach Anspruch 7, dadurch gekennzeichnet, dass je nach dem Datentyp ein Frame 20 Bits für Daten und 4 Bits für den Frametypidentifizierer oder 22 Bits für Daten und 2 Bits für den Frametypidentifizierer aufweist.
  9. Wandler nach Anspruch 7 oder 8, dadurch gekennzeichnet, dass das Frame der zweiten Folge entsprechend dem IEC958 Standard in ein Subframe eingebettet ist.
  10. Wandler nach einem der Ansprüche 1 bis 9, wobei der Wandler mit Mitteln (10) gekoppelt ist zum Decodieren von Daten, eingebettet in ein DAB-Signal, dadurch gekennzeichnet, dass der Wandler vorgesehen ist zum Hinzufügen der decodierten Daten aus den Mitteln zum Decodieren von Daten als einzelne Folge zu der zweiten Folge.
  11. Wandler nach Anspruch 10, dadurch gekennzeichnet, dass die decodierten Daten TI1-Daten in einem Null-Symbol des DAB-Signals sind.
  12. Wandler nach Anspruch 10, dadurch gekennzeichnet, dass die decodierten Daten PAD-Daten sind.
  13. Wandler nach Anspruch 12, dadurch gekennzeichnet, dass ein Frame der zweiten Folge in ein IEC958 Subframe eingebettet ist und dass der Wandler vorgesehen ist zum Einfügen der einzelnen Folge mit PAD-Daten in einen Benutzerdatenkanal in dem IEC958 Subframe.
  14. Empfänger zum Empfangen eines "Digital Audio Broadcast" Signals mit Mitteln (8) zum Decodieren eines empfangenen DAB-Signals in eine erste Datenfolge, organisiert in Frames eines ersten Typs, wobei die genannten Frames eine Anzahl Datentypen an vorbestimmten Stellen innerhalb des Frames aufweisen, dadurch gekennzeichnet, dass der Empfänger weiterhin den Wandler (16) nach Anspruch 1 aufweist.
  15. Verfahren zum Umwandeln einer ersten Datenfolge, organisiert in Frames eines ersten Typs, wobei die genannten Frames eine Anzahl Datentypen an vorbestimmten Stellen innerhalb des Frames aufweisen, in eine zweite Datenfolge, organisiert in Frames eines zweiten Typs, wobei eine Framelänge des ersten Frametyps anders ist als eine Framelänge des zweiten Frametyps, wobei das genannte Verfahren die nachfolgenden Verfahrensschritte umfasst: – das Lesen der ersten Folge, – das Zerlegen der ersten Datenfolge in wenigstens zwei einzelne Datenfolgen, wobei jede Folge der einzelnen Datenfolgen für einen vorbestimmten Datentyp reserviert ist, – das Aufteilen der einzelnen Folgen in Frames vom zweiten Typ, – das Zusammenstellen der einzelnen Folgen zu Frames vom zweiten Typ, wobei jedes Frame einen Frametypidentifizierer aufweist zum Identifizieren der einzelnen Folgen innerhalb der zweiten Folge, – das Zusammenstellen der zweiten Folge aus den einzelnen Folgen.
  16. Verfahren nach Anspruch 15, dadurch gekennzeichnet, dass ein Datentypidentifizierer wenigstens einer der einzelnen Folgen hinzugefügt wird, und zwar zum Identifizieren des Datentyps in der einzelnen Folge.
  17. Verfahren nach Anspruch 15 oder 16, dadurch gekennzeichnet, dass die zweite Folge eine Anzahl Pakete aufweist, wobei eine einzelne Folge ein Paket aufweist, das eine Anzahl Frames in der zweiten Folge aufweist, wobei ein Paket durch vorbestimmte Werte des Frametypidentifizierers identifiziert wird, wobei das genannte Paket einen Kopf mit dem Datentypidentifizierer aufweist.
  18. Verfahren nach Anspruch 15, 16 oder 17, dadurch gekennzeichnet, dass die zweite Folge einzelne Datenframes aufweist, identifiziert durch wenigstens einen weiteren vorbestimmten Wert des Frametypidentifizierers, wobei jedes Frame in der zweiten Folge Daten und einen Datentypidentifizierer aufweist.
  19. Verfahren nach Anspruch 15, 16, 17 oder 18, dadurch gekennzeichnet, dass der zweiten Folge ein Synchronisationssignal hinzugefügt wird zum Signalisieren eines Startes eines Frames vom ersten Typ.
  20. Verfahren nach Anspruch 19, dadurch gekennzeichnet, dass das Synchronisationssignal ein Frame mit einem Frametypidentifizierer mit einem vorbestimmten Wert ist.
  21. Verfahren nach Anspruch 15, 16, 17, 18, 19 oder 20, dadurch gekennzeichnet, dass ein Frame der zweiten Folge wenigstens 20 Bits für Daten von der ersten Folge und höchsten 4 Bits für den Frametypidentifizierer aufweist, wobei die gesamte Framelänge 24 Bits beträgt.
  22. Verfahren nach Anspruch 21, dadurch gekennzeichnet, dass je nach dem Datentyp ein Frame 20 Bits für Daten und 4 Bits für den Frametypidentifizierer oder 22 Bits für Daten und 2 Bits für den Frametypidentifizierer aufweist.
  23. Verfahren nach Anspruch 21 oder 22, dadurch gekennzeichnet, dass entsprechend dem IEC958 Standard das Frame in ein Subframe eingebettet ist.
  24. Verfahren nach Anspruch 15, 16, 17, 18, 19, 20, 21, 22 oder 23, wobei die erste Sequenz aus einem DAP-Signal zurück gewonnen wird, und wobei Daten, die in ein DAB-Signal eingebettet sind decodiert werden, dadurch gekennzeichnet, dass die decodierten Daten als eine einzelne Folge der zweiten Folge hinzugefügt werden.
  25. Verfahren nach Anspruch 24, dadurch gekennzeichnet, dass die decodierten Daten TI1-Daten in einem Null Symbol des DAP-Signals sind.
  26. Verfahren nach Anspruch 24, dadurch gekennzeichnet, dass die decodierten Daten PAD-Daten sind.
  27. Verfahren nach Anspruch 26, dadurch gekennzeichnet, dass ein Frame der zweiten Folge in ein IEC958 Subframe eingebettet ist und dass die einzelne Folge mit PAD-Daten in einen Benutzerdatenkanal in dem IEC958 Subframe eingefügt wird.
DE69634659T 1995-10-04 1996-09-25 Empfänger für digitalen tonrundfunk sowie verfahren und vorrichtung zur formatumwandlung einer dab-datenfolge Expired - Lifetime DE69634659T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP95202664 1995-10-04
EP95202664 1995-10-04
PCT/IB1996/000994 WO1997013339A1 (en) 1995-10-04 1996-09-25 Dab receiver, apparatus and method for a format conversion of a dab data sequence

Publications (2)

Publication Number Publication Date
DE69634659D1 DE69634659D1 (de) 2005-06-02
DE69634659T2 true DE69634659T2 (de) 2006-03-02

Family

ID=8220682

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69634659T Expired - Lifetime DE69634659T2 (de) 1995-10-04 1996-09-25 Empfänger für digitalen tonrundfunk sowie verfahren und vorrichtung zur formatumwandlung einer dab-datenfolge

Country Status (9)

Country Link
US (1) US6078592A (de)
EP (1) EP0807342B1 (de)
JP (1) JP4014224B2 (de)
KR (1) KR100436315B1 (de)
CN (1) CN1115810C (de)
CA (1) CA2206627C (de)
DE (1) DE69634659T2 (de)
ES (1) ES2242197T3 (de)
WO (1) WO1997013339A1 (de)

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI99185C (fi) * 1995-12-21 1997-10-10 Nokia Oy Ab Ohjelmatiedosto digitaalisessa yleisradiojärjestelmässä
FI100629B (fi) * 1996-05-09 1998-01-15 Nokia Oy Ab Linkkiobjektin käyttö digitaalisessa yleisradiojärjestelmässä
TW366631B (en) * 1996-06-25 1999-08-11 Koninkl Philips Electronics Nv A method and system for providing synchronization in a stream of messages and a transmitter and a receiver for use in such a system
SE9703630L (sv) * 1997-03-03 1998-09-04 Telia Ab Förbättringar av, eller med avseende på, synkronisering
DE19716063C1 (de) * 1997-04-17 1998-11-19 Grundig Ag Datenendgerät für einen DAB-Empfänger
BR9804955B1 (pt) * 1997-06-03 2009-12-01 aparelho e processo para a reprodução de um sinal de audio digital a partir de um suporte de gravação.
US20020114316A1 (en) * 2001-02-22 2002-08-22 Buchanan Stanley P. Method and system for alignment of streaming data between circuit and packet domains of a communication system
DE10337321A1 (de) * 2003-08-12 2005-03-24 Robert Bosch Gmbh Vorrichtung zum Empfang und zur Verteilung codierter digitaler Audio- und Datensignale
KR100739511B1 (ko) * 2004-06-25 2007-07-13 삼성전자주식회사 직교 주파수 분할 다중 방식을 사용하는 통신 시스템에서파일럿 신호 송수신 장치 및 방법
KR100710308B1 (ko) * 2005-01-25 2007-04-23 엘지전자 주식회사 유료 이동형 방송 서비스를 위한 데이터 구조, 유료이동형 방송 서비스 방법, 및 이동형 방송 수신기
CN100369477C (zh) * 2005-01-26 2008-02-13 乐金电子(惠州)有限公司 数字多媒体广播接收机的频道解码器
KR100617836B1 (ko) * 2005-05-30 2006-08-28 삼성전자주식회사 지상파 디지털 방송 데이터를 수신하는 이동 통신 단말기의사용자 인터페이스 구성 방법
US8744388B2 (en) * 2006-05-30 2014-06-03 Nokia Corporation Dynamic radio data system options
US8520852B2 (en) * 2006-12-22 2013-08-27 Ibiquity Digital Corporation Method and apparatus for store and replay functions in a digital radio broadcasting receiver
US8014446B2 (en) 2006-12-22 2011-09-06 Ibiquity Digital Corporation Method and apparatus for store and replay functions in a digital radio broadcasting receiver
KR101405965B1 (ko) * 2007-06-25 2014-06-12 엘지전자 주식회사 디지털 방송 시스템 및 데이터 처리 방법
WO2010005234A2 (en) * 2008-07-08 2010-01-14 Lg Electronics Inc. Transmitting/receiving system and method of processing data in the transmitting/receiving system
CN101685636B (zh) * 2008-09-25 2013-01-09 数维科技(北京)有限公司 Dra数据格式转换方法及其实现装置
EP2355427A1 (de) * 2009-12-15 2011-08-10 Nxp B.V. Digitaler Kommunikationsempfänger

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE4118424A1 (de) * 1991-06-05 1992-12-10 Thomson Brandt Gmbh Verfahren zur verarbeitung und wiedergabe empfangener digital codierter audio-daten und rundfunkempfaenger zum empfang von digital codierter ton-rundfunkdaten (dar)
JP3082447B2 (ja) * 1992-06-25 2000-08-28 ソニー株式会社 デジタル放送受信機
US5483686A (en) * 1992-11-02 1996-01-09 Matsushita Electric Industrial Co., Ltd. Channel selecting apparatus for simultaneous use with both phase-continuous modulation signals and digital modulation signals
DE4319769C1 (de) * 1993-06-15 1994-07-14 Grundig Emv Verfahren und Anordnung zur Einstellung der lokalen Oszillatoren eines Empfängers in einem Mehrkanalübertragungssystem
FR2718905B1 (fr) * 1994-04-19 1996-06-28 France Telecom Signal numérique organisé en containers de données autonomes, notamment pour la transmission de données vers des récepteurs à fonctionnement intermittent, procédé de diffusion et procédé de réception correspondants.
FI97840C (fi) * 1995-03-09 1997-02-25 Nokia Technology Gmbh Menetelmä hypertekstidokumentin ja hypermediapalvelun siirtämiseksi jamuodostamiseksi liikkuvalle vastaanottajalle
US5751774A (en) * 1996-04-04 1998-05-12 Lucent Technologies Inc. Transmission system for digital audio broadcasting
US5748686A (en) * 1996-04-04 1998-05-05 Globespan Technologies, Inc. System and method producing improved frame synchronization in a digital communication system

Also Published As

Publication number Publication date
CN1115810C (zh) 2003-07-23
CA2206627C (en) 2006-11-14
WO1997013339A1 (en) 1997-04-10
CN1168205A (zh) 1997-12-17
ES2242197T3 (es) 2005-11-01
KR100436315B1 (ko) 2004-08-09
US6078592A (en) 2000-06-20
JPH11502390A (ja) 1999-02-23
DE69634659D1 (de) 2005-06-02
CA2206627A1 (en) 1997-04-10
JP4014224B2 (ja) 2007-11-28
EP0807342A1 (de) 1997-11-19
KR980700745A (ko) 1998-03-30
EP0807342B1 (de) 2005-04-27

Similar Documents

Publication Publication Date Title
DE69634659T2 (de) Empfänger für digitalen tonrundfunk sowie verfahren und vorrichtung zur formatumwandlung einer dab-datenfolge
DE602004012711T2 (de) Fehlerkodierung in einem Überrahmen für digitalen Hörfunk (DAB)
DE602004006057T2 (de) Vorrichtung und Verfahren zum Senden/Empfangen von Informationen in einem digitalen multimedia Rundfunkdienst
DE10393776B4 (de) Verfahren und Systeme zur Kodierung von mehreren Nachrichten in Audiodaten und zur Detektion derselben
US5796785A (en) Digital audio broadcast receiver having circuitry for retrieving embedded data and for supplying the retrieved data to peripheral devices
DE19749743C2 (de) Kommunikationseinheit und Verfahren für Paketbestätigung
DE69913506T2 (de) Verfahren für den digitalen tonrundfunk unter verwendung eines punktierbaren faltungskodes
DE60033718T2 (de) Vorrichtung für die Übertragung mehrerer Datenströme im gleichen Band und Kanal
DE602004010254T2 (de) Burst-übertragung
EP0838108A1 (de) Verfahren zur übertragung von durchsagen mittels digitaler hörfunksendungen und empfänger zur durchführung des verfahrens
DE3783194T2 (de) Verfahren zur rundfunkuebertragung von textnachrichten auf einen untertraeger, verbunden mit einer radiophonen traegerfrequenz.
EP0561917B1 (de) Verfahren zum übertragen von zusatzinformationen in einem am-rundfunksignal
EP1376512B1 (de) Verfahren zur Informationsübertragung und Informationsempfänger
EP0757454B1 (de) RDS-TMC-Rundfunkempfänger
DE102015100887B4 (de) Notfallfrühwarnsystem und -verfahren unter Verwendung eines Rundfunksystems
DE69834175T2 (de) Verfahren zur Bestimmung der Zugriffszeit von wiederholt übertragenen Objekte
DE19630195A1 (de) Verfahren zur Übertragung von Durchsagen mit Empfänger zur Durchführung des Verfahrens
EP0847154B1 (de) Verfahren und Einrichtung zum Senden von Meldungen mit schwankendem Aufkommen als Radio-Daten-Signale
DE4102919A1 (de) Verfahren zum auswaehlen einer empfangsfrequenz bei einem rds-empfaenger
EP0978166B1 (de) Endgerat für den digitalen mobilfunk und verfahren zum auswerten von in einem solchen endgerät empfangenen daten
EP2854314B1 (de) Verfahren und Vorrichtung zum Einblenden von Alarmmeldungen in einem DAB-Ensemble innerhalb eines Tunnels
EP0901724B1 (de) Verfahren zur verarbeitung von daten mit einem rundfunkempfänger
DE19524269B4 (de) Empfänger für Verkehrsfunkmeldungen
EP1138030A1 (de) Verfahren, empfänger und sender zur übertragung von digital codierten verkehrsinformationen
DE19801012A1 (de) Einrichtung zum Empfang und Ortstabelle zur Decodierung von digital codierten Meldungen

Legal Events

Date Code Title Description
8320 Willingness to grant licences declared (paragraph 23)
8364 No opposition during term of opposition