DE112011101692T5

DE112011101692T5 - Digitalrundfunksender, Digitalrundfunkempfänger sowie Streamkonfiguration und Verfahren zur Verarbeitung hiervon

Info

Publication number: DE112011101692T5
Application number: DE112011101692T
Authority: DE
Inventors: Jin-Hee Jeong; Yong-Sik Kwon; Jung-jin Kim
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 2010-05-17
Filing date: 2011-05-13
Publication date: 2013-06-20
Also published as: CA2800561A1; BR112012028417A2; WO2011145841A3; CA2800561C; CN102893622A; BR112012028417B1; WO2011145841A2; US8976894B2; KR101801106B1; US20130064280A1; CN102893622B; MX2012013216A; KR20110126540A

Abstract

Offenbart wird ein Streamverarbeitungsverfahren für einen Digitalrundfunksender. Das Verfahren beinhaltet ein Konfigurieren von Streams, in denen Schlitze, die eine Mehrzahl von Blöcken beinhalten, kontinuierlich angeordnet sind, und ein Codieren und Verschachteln der Streams zur Ausgabe als Transportstreams. Beinhalten kann das Konfigurieren der Streams hierbei ein Platzieren von Basisdaten in einem vorbestimmten Segment eines jeden benachbarten Schlitzes zur Bildung einer Langtrainingssequenz in Grenzabschnitten von benachbarten Schlitzen, die in einer sägezahnförmigen Konfiguration gekoppelt (interlocked) sind, wenn Schlitze, die auf einen Blockerweiterungsmodus 00 eingestellt sind, kontinuierlich angeordnet sind, um eine Verwendung von gesamten Blöcken in einem entsprechenden Schlitz zu ermöglichen. Entsprechend wird ein Digitalrundfunkdienst in verschiedenen Formaten verfügbar.

Description

Verweis auf verwandte Anmeldung
Die vorliegende Anmeldung ist eine nationale Phase der am 13. Mai 2011 eingereichten internationalen Anmeldung mit der Nummer PCT/KR2011/003566 und beansprucht die Priorität der am 17. Mai 2010 eingereichten vorläufigen US-Patentanmeldung mit der Nummer 61/344,065, wovon die Offenbarung hiermit in Gänze durch Verweisung aufgenommen ist.
Gebiet der Erfindung
Systeme und Verfahren, die zur vorliegenden Erfindung konsistent sind, betreffen einen Digitalrundfunksender, einen Digitalrundfunkempfänger sowie Verfahren zum Konfigurieren und Verarbeiten eines Streams hiervon und insbesondere einen Digitalrundfunksender, der einen Transportstream konfiguriert, der Mobildaten zusammen mit Normaldaten beinhaltet, und den Transportstream sendet, einen Digitalrundfunkempfänger, der den Transportstream empfängt und verarbeitet, sowie Verfahren hierfür.
Hintergrund der Erfindung
Digitalrundfunk ist allgemein üblich geworden, wobei verschiedene Typen von elektronischen Geräten Digitalrundfunkdienste unterstützen. Zusätzlich zu Geräten, die üblicherweise in Haushalten bereitstehen, so beispielsweise Digitalrundfunkfernsehgeräte oder Set-Top-Boxen, sind insbesondere tragbare Geräte, die leicht zu tragen sind, so beispielsweise Mobiltelefone, Navigationssysteme, Persönliche Digitale Assistenten (PDAs) und MP3-Geräte, mit einer Funktion zur Unterstützung von Digitalrundfunkdiensten ausgestattet.
Daher sind Digitalrundfunkstandards zur Bereitstellung von Digitalrundfunkdiensten für derartige tragbare Geräte derzeit in der Diskussion.
Einer hiervon ist der ATSC-MH-Standard. Der ATSC-MH-Standard offenbart eine Technologie zum Platzieren von Mobildaten in einem Transportstream, das heißt zum Senden von Daten für allgemeine Digitalrundfunkdienste, das heißt Normaldaten, und Senden der Mobildaten.
Da die Mobildaten durch ein tragbares Gerät empfangen und verarbeitet werden, werden die Mobildaten in einem Format verarbeitet, das stabil gegenüber einem Fehler infolge der Mobilität der tragbaren Geräte im Vergleich zu den Normaldaten ist, und sind in dem Transportstream beinhaltet.
1A und 1B sind Ansichten zur Darstellung eines Beispieles einer Transportstreamkonfiguration, die Mobildaten und Normaldaten beinhaltet.
1A zeigt einen Stream, in dem Mobildaten und Normaldaten in jeweils zugeteilten Paketen platziert und multiplexiert sind.
Der Stream von 1A wird in den Stream von 1B durch Verschachteln umgewandelt. Wie in 1B gezeigt ist, können MH, das heißt Mobildaten, in Bereiche A und B durch Verschachtelung unterteilt werden. Der Bereich A ist ein Bereich, der in einen vorbestimmten Bereich in Bezug auf einen Abschnitt fällt, in dem Mobildaten, die größer als eine vorbestimmte Größe sind, in einer Mehrzahl von Sendeeinheiten versammelt sind, während der Bereich B ein Bereich ist, in dem der Bereich A ausgeschlossen ist. Die Mobildaten sind beispielhalber in die Bereiche A und B unterteilt und können auf verschiedene Weise unterteilt sein. Dies bedeutet, dass, wie in 1B gezeigt ist, ein Abschnitt, der keine Normaldaten beinhaltet, auf einen Bereich A eingestellt werden kann, während ein Abschnitt, der einer Sendeeinheit entspricht, in der wenigstens Normaldaten platziert sind, auf den Bereich B eingestellt sein kann.
Es besteht ein Problem dahingehend, dass der Bereich B für einen Fehler im Vergleich zu dem Bereich A vergleichsweise anfällig ist. Dies bedeutet, dass die Digitalrundfunkdaten bekannte Daten beinhalten können, so beispielsweise eine Trainingssequenz zum geeigneten Demodulieren und Ausgleichen bzw. Entzerren durch einen Empfänger zur Berichtigung eines Fehlers. Entsprechend dem ATSC-MH-Standard aus dem Stand der Technik werden die bekannten Daten nicht in dem Bereich B platziert, sodass ein Problem dahingehend auftritt, dass der Bereich B anfällig für einen Fehler ist.
Zudem kann der Stream, der gemäß Darstellung in 1A und 1B definiert ist, eine Grenze zum Senden von Mobildaten bereitstellen. Dies bedeutet, dass die Anzahl von Rundfunkstationen und Geräten zur Unterstützung von Mobilrundfunkdiensten zugenommen hat, wohingegen ein Abschnitt, der den Normaldaten in dem Stream gemäß Darstellung in 1A und 1B zugeteilt ist, nicht verfügbar ist, weshalb sich die Effizienz des Streams verschlechtert.
Daher besteht Bedarf an einem Verfahren zur effizienten Verwendung eines Transportstreams.
Zusammenfassung
Ein exemplarisches Ausführungsbeispiel der vorliegenden Erfindung stellt einen Digitalrundfunksender, einen Digitalrundfunkempfänger sowie Verfahren zum Konfigurieren und Verarbeiten eines Streams hiervon bereit, die Pakete eines Transportstreams nutzen können, die Normaldaten auf verschiedene Weisen zugeteilt sind, wodurch die Sendeeffizienz von Mobildaten diversifiziert und das Leistungsvermögen beim Empfangen des Transportstreams verbessert wird.
Entsprechend einem Aspekt der vorliegenden Erfindung wird ein Verfahren zum Verarbeiten eines Streams eines Digitalrundfunksenders bereitgestellt, wobei das Verfahren beinhaltet: ein Konfigurieren eines Streams, in dem Schlitze, die eine Mehrzahl von Blöcken beinhalten, kontinuierlich platziert sind; und ein Codieren und Verschachteln des Streams und Senden des Streams als Transportstream, wobei das Konfigurieren des Streams ein dann, wenn Schlitze eines Blockerweiterungsmodus 00 kontinuierlich platziert sind, erfolgendes Verbinden von bekannten Daten, die an vorbestimmten Stellen von benachbarten Schlitzen platziert sind, miteinander zur Erzeugung einer Langtrainingssequenz beinhaltet.
Erste bekannte Daten, die in einem Sägezahnabschnitt eines vorhergehenden Schlitzes der benachbarten Schlitze platziert sind, und zweite bekannte Daten, die in einem Sägezahnabschnitt eines nachfolgenden Schlitzes der benachbarten Schlitze platziert sind, können abwechselnd miteinander an einer Grenze verbunden werden, wobei ein Wert der ersten bekannten Daten und ein Wert der zweiten bekannten Daten vorbestimmte Werte zur Erzeugung einer Langtrainingssequenz sein können, die dem Digitalrundfunksender und einem Digitalrundfunkempfänger bekannt ist.
Die bekannten Daten können eine selbe Sequenz als Langtrainingssequenz aufweisen, die in einem Schlitz eines Blockerweiterungsmodus 01 verwendet wird, worin ein bzw. irgendein Block eines entsprechenden Schlitzes für einen anderen Block bereitgestellt wird.
Das Senden kann ein Initialisieren eines Trellis-Codierers beinhalten, bevor bekannte Daten, die einem Anfangsabschnitt der Langtrainingssequenz entsprechen, Trellis-codiert werden.
Beinhalten kann das Senden ein dann, wenn Schlitze von verschiedenen Blockerweiterungsmodi kontinuierlich platziert sind, erfolgendes Initialisieren eines Trellis-Codierers, bevor bekannte Daten, die in einem Sägezahnabschnitt einer Grenze zwischen den kontinuierlich platzierten Schlitzen platziert sind, Trellis-codiert werden.
Entsprechend einem Aspekt der vorliegenden Erfindung wird ein Digitalrundfunksender bereitgestellt, der beinhaltet: eine Streamkonfigurationseinheit, die einen Stream konfiguriert, in dem Schlitze, die eine Mehrzahl von Blöcken beinhalten, kontinuierlich platziert sind, und eine Erregereinheit, die den Stream codiert und verschachtelt und den Stream als Transportstream sendet.
Wenn Schlitze eines Blockerweiterungsmodus 00, in dem alle Blöcke eines entsprechenden Schlitzes verwendet werden, kontinuierlich platziert sind, kann die Streamkonfigurationseinheit bekannte Daten in vorbestimmten Segmenten von benachbarten Schlitzen zur Erzeugung einer Langtrainingssequenz an einer Grenze zwischen den benachbarten Schlitzen in Eingriff mit einer sägezahnförmigen Konfiguration platzieren.
Erste bekannte Daten, die in einem Sägezahnabschnitt eines vorhergehenden Schlitzes der benachbarten Schlitze platziert sind, und zweite bekannte Daten, die in einem Sägezahnabschnitt eines nachfolgenden Schlitzes der benachbarten Schlitze platziert sind, können abwechselnd miteinander an der Grenze verbunden werden, wobei ein Wert der ersten bekannten Daten und ein Wert der zweiten bekannten Daten vorbestimmte Werte zur Erzeugung einer Langtrainingssequenz sein können, die dem Digitalrundfunksender und einem Digitalrundfunkempfänger bekannt sind.
Die bekannten Daten können eine selbe Sequenz wie eine Langtrainingssequenz aufweisen, die in einem Schlitz eines Blockerweiterungsmodus 01 verwendet wird, worin ein bzw. irgendein Block eines entsprechenden Schlitzes für einen anderen Schlitz bereitgestellt wird.
Die Erregereinheit kann beinhalten: eine Codiereinheit, die den Stream codiert, eine Verschachtlereinheit, die den codierten Stream verschachtelt, und eine Trellis-Codiereinheit, die den verschachtelten Stream Trellis-codiert.
Der Trellis-Codierer kann initialisiert werden, bevor bekannte Daten, die einem Anfangsabschnitt der Langtrainingssequenz entsprechen, Trellis-codiert werden.
Wenn Schlitze von verschiedenen Blockerweiterungsmodi kontinuierlich platziert sind, so kann die Trellis-Codierereinheit initialisiert werden, bevor bekannte Daten, die in einem Sägezahnabschnitt einer Grenze zwischen den kontinuierlich platzierten Schlitzen platziert sind, Trellis-codiert werden.
Entsprechend einem Aspekt der vorliegenden Erfindung wird ein Verfahren zum Verarbeiten eines Streams eines Digitalrundfunkempfängers bereitgestellt, wobei das Verfahren beinhaltet: ein Empfangen eines Transportstreams, der codiert und verschachtelt ist, wenn Schlitze, die eine Mehrzahl von Blöcken beinhalten, kontinuierlich platziert sind, ein Demodulieren des empfangenen Transportstreams, ein Ausgleichen bzw. Entzerren des demodulierten Transportstreams und ein Decodieren von neuen Mobildaten aus dem ausgeglichenen bzw. entzerrten Stream.
Jeder Schlitz des Transportstreams kann wenigstens eines von Normaldaten, bestehenden Mobildaten und neuen Mobildaten beinhalten, wobei dann, wenn Schlitze eines Blockerweiterungsmodus 00 kontinuierlich platziert werden, in dem Transportstream bekannte Daten, die an vorbestimmten Stellen von benachbarten Schlitzen platziert sind, miteinander zur Erzeugung einer Langtrainingssequenz verbunden werden können.
Erste bekannte Daten, die in einem Sägezahnabschnitt eines vorhergehenden Schlitzes der benachbarten Schlitze platziert sind, und zweite bekannte Daten, die in einem Sägezahnabschnitt eines nachfolgenden Schlitzes der benachbarten Schlitze platziert sind, können alternativ miteinander an einer Grenze verbunden werden, wobei ein Wert der ersten bekannten Daten und ein Wert der zweiten bekannten Daten vorbestimmte Werte zur Erzeugung einer Langtrainingssequenz sein können, die einem Digitalrundfunksender und dem Digitalrundfunkempfänger bekannt sind.
Die bekannten Daten können eine selbe Sequenz wie eine Langtrainingssequenz aufweisen, die in einem Schlitz eines Blockerweiterungsmodus 01 verwendet wird, worin ein bzw. irgendein Block eines entsprechenden Schlitzes für einen anderen Schlitz bereitgestellt wird.
Das Verfahren kann des Weiteren ein Decodieren von Signalisierungsdaten eines jeden Schlitzes und ein Identifizieren eines Blockerweiterungsmodus eines jeden der Schlitze beinhalten.
Beinhalten kann das Verfahren des Weiteren ein dann, wenn das Decodieren von Signalisierungsdaten des nachfolgenden Schlitzes der benachbarten Schlitze beendet ist und identifiziert wird, dass ein Blockerweiterungsmodus des nachfolgenden Schlitzes gleich 00 ist, erfolgendes Erfassen der bekannten Daten, die in dem Sägezahnabschnitt der Grenze zwischen den benachbarten Schlitzen platziert sind, als Langtrainingssequenz und ein Verarbeiten der bekannten Daten.
Das Verfahren kann des Weiteren ein Decodieren von Signalisierungsdaten des vorhergehenden Schlitzes der benachbarten Schlitze und ein Identifizieren von Blockerweiterungsmodi sowohl des vorhergehenden Schlitzes wie auch des nachfolgenden Schlitzes beinhalten.
Entsprechend einem Aspekt der vorliegenden Erfindung wird ein Digitalrundfunkempfänger bereitgestellt, der beinhaltet: eine Empfangseinheit, die einen Transportstream empfängt, der codiert und verschachtelt ist, wenn Schlitze, die eine Mehrzahl von Blöcken beinhalten, kontinuierlich platziert sind, einen Demodulierer, der den empfangenen Transportstream demoduliert, einen Ausgleicher bzw. Entzerrer, der den demodulierten Transportstream ausgleicht bzw. entzerrt, und eine Decodiereinheit, die neue Mobildaten aus dem ausgeglichenen bzw. entzerrten Stream decodiert.
Jeder Schlitz des Transportstreams kann wenigstens eines von Normaldaten, bestehenden Mobildaten und neuen Mobildaten beinhalten, wobei dann, wenn Schlitze eines Blockerweiterungsmodus 00 kontinuierlich platziert sind, in dem Transportstream bekannte Daten, die an vorbestimmten Stellen von benachbarten Schlitzen platziert sind, miteinander zur Erzeugung einer Langtrainingssequenz verbunden werden können.
Erste bekannte Daten, die in einem Sägezahnabschnitt eines vorhergehenden Schlitzes der benachbarten Schlitze platziert sind, und zweite bekannte Daten, die in einem Sägezahnabschnitt eines nachfolgenden Schlitzes der benachbarten Schlitze platziert sind, können abwechselnd miteinander an einer Grenze verbunden werden, wobei ein Wert der ersten bekannten Daten und ein Wert der zweiten bekannten Daten vorbestimmte Werte zur Erzeugung einer Langtrainingssequenz sein können, die einem Digitalrundfunksender und dem Digitalrundfunkempfänger bekannt ist.
Die Langtrainingssequenz kann eine selbe Sequenz wie eine Langtrainingssequenz aufweisen, die in einem Schlitz eines Blockerweiterungsmodus 01 verwendet wird, worin ein bzw. irgendein Block eines entsprechenden Schlitzes für einen anderen Schlitz bereitgestellt wird.
Der Digitalrundfunkempfänger kann des Weiteren einen Signaldecodierer beinhalten, der Signalisierungsdaten eines jeden Schlitzes decodiert und einen Blockerweiterungsmodus eines jeden der Schlitze identifiziert.
Der Digitalrundfunkempfänger kann des Weiteren eine Erfassungseinheit beinhalten, die dann, wenn das Decodieren von Signalisierungsdaten des nachfolgenden Schlitzes der benachbarten Schlitze beendet ist und identifiziert wird, dass ein Blockerweiterungsmodus des nachfolgenden Schlitzes gleich 00 ist, die bekannten Daten, die in dem Sägezahnabschnitt der Grenze zwischen den benachbarten Schlitzen platziert sind, als Langtrainingssequenz erfasst und die bekannten Daten verarbeitet.
Der Digitalrundfunk kann des Weiteren einen Signalisierungsdecodierer beinhalten, der Signalisierungsdaten des vorhergehenden Schlitzes der benachbarten Schlitze decodiert und Blockerweiterungsmodi sowohl des vorhergehenden Schlitzes wie auch des nachfolgenden Schlitzes identifiziert.
Entsprechend verschiedenen exemplarischen Ausführungsbeispielen aus der vorstehenden Beschreibung wird der Transportstream in verschiedenen Formaten gesendet, sodass der Empfänger verschiedene Typen von Mobildaten empfangen kann.
Zusätzliche Aspekte und Vorteile der exemplarischen Ausführungsbeispiele ergeben sich aus der Detailbeschreibung, sind aus dieser offensichtlich oder können durch praktische Umsetzung der exemplarischen Ausführungsbeispiele greifbar gemacht werden.
Kurzbeschreibung der Zeichnung
Die vorstehenden und/oder weitere Aspekte der Erfindung sind oder werden aus der nachfolgenden Beschreibung der exemplarischen Ausführungsbeispiele augenscheinlich, die in Verbindung mit der begleitenden Zeichnung zu betrachten ist, die sich wie folgt zusammensetzt.
1A und 1B sind Ansichten zur Darstellung eines Beispieles einer Transportstreamkonfiguration entsprechend einem ATSC-MH-Standard aus dem Stand der Technik.
2 bis 4 sind Blockdiagramme zur Darstellung eines Digitalrundfunksenders entsprechend verschiedenen exemplarischen Ausführungsbeispielen.
5 ist ein Blockdiagramm zur Darstellung eines Beispieles eines Frame-Codierers.
6 ist ein Blockdiagramm zur Darstellung eines Beispieles eines RS-Frame-Codierers (RS Reed Solomon) des Frame-Codierers von 6.
7 ist ein Blockdiagramm zur Darstellung eines Beispieles eines Blockprozessors.
8 ist eine Ansicht zur Erläuterung eines Beispieles eines Verfahrens zum Unterteilen eines Streams in Blöcke.
9 ist ein Blockdiagramm zur Darstellung eines Beispieles eine Signalisierungscodierers.
10 bis 13 sind Ansichten zur Darstellung von verschiedenen Beispielen eines Trellis-Codierers.
14 ist eine Ansicht zu Erläuterung eines Beispieles eines Mobildatenframes.
15 bis 21 sind Ansichten zur Darstellung eines Beispieles einer Streamkonfiguration entsprechend verschiedenen exemplarischen Ausführungsbeispielen.
22 bis 28 sind Ansichten zur Darstellung eines Einfügemusters von bekannten Daten entsprechend verschiedenen exemplarischen Ausführungsbeispielen.
29 ist eine Ansicht zur Darstellung eines Musters, in dem Mobildaten in einem Normaldatenbereich entsprechend einem ersten Modus platziert sind.
30 ist eine Ansicht zur Darstellung des Streams von 29 in einem verschachtelten Zustand.
31 ist eine Ansicht zur Darstellung eines Musters, in dem Mobildaten in einem Normaldatenbereich entsprechend einem zweiten Modus platziert sind.
32 ist eine Ansicht zur Darstellung des Streams von 31 in einem verschachtelten Zustand.
33 ist eine Ansicht zur Darstellung eines Musters, in der Mobildaten in einem Normaldatenbereich entsprechend einem dritten Modus platziert sind.
34 ist eine Ansicht zur Darstellung des Streams von 33 in einem verschachtelten Zustand.
35 ist eine Ansicht zur Darstellung eines Musters, in dem Mobildaten in einem Normaldatenbereich entsprechend einem vierten Modus platziert sind.
36 ist eine Ansicht zur Darstellung des Streams von 35 in einem verschachtelten Zustand.
37 bis 40 sind Ansichten zur Darstellung von Mustern, in denen Mobildaten entsprechend verschiedenen Modi platziert sind.
41 bis 43 sind Ansichten zur Darstellung von verschiedenen Typen von Schlitzen, die wiederholt in einer Sequenz bzw. Abfolge platziert sind.
44 bis 47 sind Ansichten zur Erläuterung eines Verfahrens zum Zuteilen von Blöcken entsprechend verschiedenen exemplarischen Ausführungsbeispielen.
48 ist eine Ansicht zur Erläuterung eines Verfahrens zum Definieren eines Anfangspunktes eines RS-Frames entsprechend verschiedenen exemplarischen Ausführungsbeispielen.
49 ist eine Ansicht zur Erläuterung einer Einfügestelle von Signalisierungsdaten.
50 ist eine Ansicht zur Darstellung eines Beispieles einer Datenfeldsynchronisierungskonfiguration zum Senden von Signalisierungsdaten.
51 bis 53 sind Ansichten zur Darstellung eines Digitalrundfunkempfängers entsprechend verschiedenen exemplarischen Ausführungsbeispielen.
54 ist eine Ansicht zur Darstellung eines Beispieles eines Streamformats nach dem Verschachteln.
55 ist eine Ansicht zur Erläuterung eines Beispieles eines Verfahrens zum Vorabsignalisieren von Information eines nächsten Frames.
56 ist eine Ansicht zur Darstellung einer Streamkonfiguration nach dem Verschachteln in einem skalierbaren Modus 11a.
57 ist eine Ansicht zur Darstellung einer Streamkonfiguration vor dem Verschachteln in einem skalierbaren Modus 11a.
58 ist eine Ansicht zur Darstellung einer Streamkonfiguration, die einen ersten Typ von verwaistem Bereich nach dem Verschachteln angibt.
59 ist eine Ansicht zur Darstellung einer Streamkonfiguration, die einen ersten Typ von verwaistem Bereich vor dem Verschachteln angibt.
60 ist eine Ansicht zur Darstellung einer Streamkonfiguration, die einen zweiten Typ von verwaistem Bereich nach dem Verschachteln angibt.
61 ist eine Ansicht zur Darstellung einer Streamkonfiguration, die einen zweiten Typ von verwaistem Bereich vor dem Verschachteln angibt.
62 ist eine Ansicht zur Darstellung einer Streamkonfiguration, die einen dritten Typ von verwaistem Bereich nach dem Verschachteln angibt.
63 ist eine Ansicht zur Darstellung einer Streamkonfiguration, die einen dritten Typ von verwaistem Bereich vor dem Verschachteln angibt.
64 ist eine Ansicht zur Darstellung einer Streamkonfiguration vor dem Verschachteln in einem Blockerweiterungsmodus 00.
65 ist eine Ansicht zur Darstellung einer Streamkonfiguration nach dem Verschachteln in einem Blockerweiterungsmodus 00.
Detailbeschreibung von exemplarischen Ausführungsbeispielen der Erfindung
Bezug genommen wird nachstehend detailliert auf die vorliegenden exemplarischen Ausführungsbeispiele der vorliegenden Erfindung, von der Beispiele in der begleitenden Zeichnung dargestellt sind, wobei gleiche Bezugszeichen durchweg gleiche Elemente bezeichnen. Die exemplarischen Ausführungsbeispiele werden nachstehend beschrieben, um die vorliegende Erfindung unter Bezugnahme auf die Figuren zu erläutern.
Digitalrundfunksender
Wie in 2 gezeigt ist, beinhaltet ein Digitalrundfunksender entsprechend einem exemplarischen Ausführungsbeispiel einen Datenvorprozessor 100 und einen Multiplexierer 200 (MUX).
Der Datenvorprozessor 100 empfängt eine Eingabe von Mobildaten, verarbeitet die Mobildaten geeignet und wandelt die Mobildaten in Daten eines Formates um, das zum Senden geeignet ist.
Der Multiplexierer 200 konfiguriert einen Transportstream, der die Mobildatenausgabe des Datenvorprozessors 100 beinhaltet. Sollen Normaldaten zusammen gesendet werden, so konfiguriert der Multiplexierer 200 einen Transportstream durch Multiplexieren der Mobildaten und der Normaldaten.
Der Datenvorprozessor 100 kann die Mobildaten derart verarbeiten, dass die Mobildaten in allen oder einigen der Pakete des gesamten Streams mit Zuteilung an die Normaldaten platziert sind.
Dies bedeutet, dass, wie anhand 1A und 1B gezeigt ist, einige der Pakete den Normaldaten entsprechend dem ATSC-MH-Standard zugeteilt sind. Insbesondere kann, wie in 1A und 1B gezeigt ist, der Stream in eine Mehrzahl von Schlitzen in der Zeiteinheit unterteilt werden, wobei ein Schlitz aus 156 Paketen bestehen kann. Unter diesen Paketen können 38 Pakete den Normaldaten zugeteilt werden, während die verbleibenden 118 Pakete den Mobildaten zugeteilt sein können. Im Sinne einer einfacheren Erläuterung werden die 118 Pakete als ein Bereich, der den Mobildaten zugeteilt ist, oder als erster Bereich bezeichnet, während die 38 Pakete als ein Bereich, der den Normaldaten zugeteilt ist, oder als zweiter Bereich bezeichnet werden. Die Normaldaten betreffen verschiedene Typen von bestehenden Daten, die durch einen landläufigen Fernseher (TV) empfangen und verarbeitet werden können, während die Mobildaten Daten betreffen, die durch ein Mobilgerät empfangen und verarbeitet werden können. Die Mobildaten können mit verschiedenen Begriffen bezeichnet werden, so beispielsweise robuste Daten, Turbodaten und zusätzliche Daten, was von der jeweiligen Situation abhängt.
Der Datenvorprozessor 100 kann die Mobildaten in einem Paketbereich platzieren, der den Mobildaten zugeteilt ist, und separat die Mobildaten in allen oder einigen der Pakete, die den Normaldaten zugeteilt sind, platzieren. Aus Gründen einer einfacheren Erläuterung werden die Mobildaten, die in den Paketen platziert sind, die den Mobildaten zugeteilt sind, als bestehende Mobildaten bezeichnet, wohingegen der Bereich, der den bestehenden Mobildaten zugeteilt ist, als erster Bereich, wie vorstehend beschrieben worden ist, bezeichnet wird. Demgegenüber werden die Mobildaten, die in dem zweiten Bereich platziert sind, das heißt die Pakete, die den Normaldaten zugeteilt sind, aus Gründen einer einfacheren Beschreibung als neue Mobildaten oder Mobildaten bezeichnet. Die bestehenden Mobildaten und und die Mobildaten können dieselben Daten sein oder können verschiedene Typen von Daten sein.
Der Datenvorprozessor 100 kann die Mobildaten in verschiedenen Mustern entsprechend einer Einstellbedingung, so beispielsweise einem Frame-Modus oder Modus, platzieren. Die Muster, in denen die Mobildaten platziert werden können, werden nachstehend anhand der Zeichnung beschrieben.
Der Multiplexierer 200 multiplexiert den Stream und die Normaldatenausgabe des Datenvorprozessors 100, wodurch ein Transportstream konfiguriert wird.
3 zeigt ein exemplarisches Ausführungsbeispiel, bei dem eine Steuerung 310 zu dem Digitalrundfunksender von 2 hinzugefügt ist. Wie in 3 gezeigt ist, bestimmt die Steuerung 310, die in dem Digitalrundfunksender bereitgestellt ist, eine Einstellbedingung eines Frame-Modus und steuert einen Betrieb des Datenvorprozessors 100.
Insbesondere wenn bestimmt wird, dass ein erster Frame-Modus eingestellt ist, steuert die Steuerung 310 den Datenvorprozessor 100 zum Platzieren der Mobildaten nur in dem ersten Bereich ohne Platzieren der Mobildaten in allen Paketen, die den Normaldaten zugeteilt sind. Dies bedeutet, dass der Datenvorprozessor 100 den Stream ausgibt, der nur die bestehenden Mobildaten beinhaltet. Entsprechend werden die Normaldaten in den Paketen, die den Normaldaten zugeteilt sind, durch den Multiplexierer 200 platziert, wodurch ein Transportstream konfiguriert wird.
Wenn demgegenüber bestimmt wird, dass ein zweiter Frame-Modus eingestellt wird, so steuert die Steuerung 310 den Datenvorprozessor 100 zum Platzieren der bestehenden Mobildaten in den Paketen, die Mobildaten zugeteilt sind, das heißt dem ersten Bereich, sowie zum Platzieren der Mobildaten in wenigstens einigen der Pakete, die den Normaldaten zugeteilt sind, das heißt wenigstens einem Teil des zweiten Bereiches.
In diesem Fall kann die Steuerung 310 einen Einstellbedingung eines separaten Modus, der nicht der Frame-Modus ist, bestimmen, das heißt ein Modus, der die Anzahl von Paketen, wo die Mobildaten platziert werden sollen, unter den Paketen, die den Normaldaten zugeteilt sind, angibt. Entsprechend kann die Steuerung 310 den Datenvorprozessor 100 zum Platzieren der Mobildaten in den Paketen entsprechend der Anzahl gemäß Einstellbedingung des Modus unter den gesamten Paketen, die den Normaldaten zugeteilt sind, steuern.
Der hier dargestellte Modus kann in verschiedenen Formen bereitgestellt werden. So kann der Modus beispielsweise wenigstens ein kompatibler Modus und ein inkompatibler Modus sein. Der kompatible Modus betrifft einen Modus, in dem eine Kompatibilität mit einem bestehenden Normaldatenempfänger, der Normaldaten empfängt und verarbeitet, aufrechterhalten wird, wobei der inkompatible Modus einen Modus betrifft, in dem die Kompatibilität nicht aufrechterhalten ist.
Insbesondere kann der kompatible Modus eine Mehrzahl von kompatiblen Modi beinhalten, in denen neue Mobildaten in wenigstens einem Teil des zweiten Bereiches platziert werden. Der kompatible Modus kann beispielsweise einer sein von einem ersten kompatiblen Modus, in dem die Mobildaten in nur einigen der Pakete, die den Normaldaten zugeteilt sind, platziert sind, oder einem zweitem kompatiblen Modus, in dem die Mobildaten in allen Paketen, die den Normaldaten zugeteilt sind, platziert sind.
Der erste kompatible Modus kann ein Modus sein, in dem die Mobildaten in nur einem Teil eines jeden Datenbereiches von einigen Paketen in dem zweiten Bereich platziert sind. Dies bedeutet, dass die Mobildaten in einem Teil des gesamten Datenbereiches von einigen Paketen platziert sein können, während die Normaldaten in dem anderen Datenbereich platziert sein können.
Zudem kam der erste kompatible Modus ein Modus sein, in dem die Mobildaten in dem gesamten Datenbereich von einigen Paketen in dem zweiten Bereich platziert sind.
Der Modus kann eingedenk der Anzahl von Paketen, die den Normaldaten zugeteilt sind, einer Größe der Mobildaten, einem Typ der Mobildaten, einer Sendezeit und einer Sendeumgebung in verschiedenen Formen bereitgestellt werden.
Wie beispielsweise in 1A und 1B gezeigt ist, kann, wenn 38 Pakete den Normaldaten zugeteilt sind, der erste kompatible Modus beinhalten:

(1) einen ersten Modus, in dem neue Mobildaten in den 38 Paketen bei einem Verhältnis von 1/4 platziert sind;
(2) einen zweiten Modus, in dem neue Mobildaten in den 38 Paketen bei einem Verhältnis von 2/4 platziert sind;
(3) einen dritten Modus, in dem neue Mobildaten in den 38 Paketen bei einem Verhältnis von 3/4 platziert sind, und
(4) einen vierten Modus, in dem neue Mobildaten in allen von den 38 Paketen platziert sind.

In dem ersten Modus können die neuen Mobildaten in einer Summe von 2 von den 38 Paketen und 9 Paketen platziert werden, was dem Quotienten der verbleibenden 36 Pakete geteilt durch 4 entspricht, das heißt insgesamt 11 Pakete. In dem zweiten Modus können die neuen Mobildaten in einer Summe von 2 von den 38 Paketen und 18 Paketen platziert werden, was dem Quotienten der verbleibenden 36 Pakete geteilt durch 2 entspricht, das heißt 20 Pakete insgesamt. In dem dritten Modus können die neuen Mobildaten in einer Summe von 2 von den 38 Paketen und 27 Paketen platziert sein, was den verbleibenden 36 Paketen geteilt durch 3/4 entspricht, das heißt 29 Pakete insgesamt. In dem vierten Modus können die neuen Mobildaten in allen von den 38 Paketen platziert sein.
Demgegenüber betrifft der inkompatible Modus einen Modus, in dem eine Sendekapazität der neuen Mobildaten unabhängig von der Kompatibilität mit dem Empfänger, der die Normaldaten empfängt, zunehmen kann. Insbesondere kann der inkompatible Modus ein Modus sein, in dem die neuen Mobildaten unter Verwendung eines MPEG-2-Headers und eines RS-Paritätsbereiches des ersten Bereiches zusätzlich zu dem gesamten zweiten Bereich platziert sind.
Im Ergebnis kann der Datenvorprozessor 100 von 2 oder 3 einen Transportstream durch Platzieren der neuen Mobildaten entsprechend verschiedenen Modi folgendermaßen konfigurieren:

(1) einen ersten Modus, in dem neue Mobildaten in 11 Paketen insgesamt unter den 38 Paketen, die den Normaldaten zugeteilt sind, platziert sind;
(2) einen zweiten Modus, in dem neue Mobildaten in 20 Paketen insgesamt unter den 38 Paketen, die den Normaldaten zugeteilt sind, platziert sind;
(3) einen dritten Modus, in dem neue Mobildaten in 29 Paketen insgesamt unter den 38 Paketen, die den Normaldaten zugeteilt sind, platziert sind;
(4) einen vierten Modus, in dem neue Mobildaten in allen von den 38 Paketen, die den Normaldaten zugeteilt sind, platziert sind; und
(5) einen fünften Modus, in dem neue Mobildaten in allen von den 38 Paketen, die den Normaldaten zugeteilt sind, und in einen Bereich entsprechend einem MPEG-Header und einer Parität eines Bereiches mit Zuteilung an die bestehenden Mobildaten platziert sind.

Obwohl der fünfte Modus als inkompatibler Modus bezeichnet wird und die ersten bis vierten Modi beim vorliegenden exemplarischen Ausführungsbeispiel aus Gründen der einfacheren Beschreibung als kompatible Modi bezeichnet werden, kann jeder Modus auch anders bezeichnet werden. Zudem kann, obwohl insgesamt fünf Modi, darunter vier kompatible Modi und ein inkompatibler Modus, bei dem vorbeschriebenen exemplarischen Ausführungsbeispiel vorhanden sind, die Anzahl von kompatiblen Modi verschieden geändert werden. Die ersten bis dritten Modi können beispielsweise als kompatibler Modus gemäß vorstehender Beschreibung verwendet werden, während der vierte Modus auf den fünften Modus, das heißt den inkompatiblen Modus, eingestellt sein kann.
Der Datenvorprozessor 100 kann bekannte Daten zusätzlich zu den Mobildaten einfügen. Die hier beschriebenen bekannten Daten bezeichnen eine Sequenz, die dem Digitalrundfunksender und dem Digitalrundfunkempfänger gemeinsam bekannt ist. Der Digitalrundfunkempfänger empfängt bekannte Daten, die von dem Digitalrundfunksender gesendet werden, und identifiziert eine Differenz bzw. einen Unterschied aus einer vorher bekannten Sequenz, und erfasst sodann den Grad der Fehlerberichtigung. Die bekannten Daten können mit verschiedenen Begriffen bezeichnet werden, darunter Trainingsdaten, Trainingssequenz, Bezugssignal oder zusätzliches Bezugssignal. Gleichwohl wird in der vorliegenden Beschreibung durchweg der Begriff „bekannte Daten” verwendet.
Der Datenvorprozessor 100 fügt wenigstens eines von den Mobildaten und den bekannten Daten in verschiedenen Abschnitten des gesamten Transportstreams ein, wodurch das Empfangsleistungsvermögen verbessert wird.
Dies bedeutet, dass im Zusammenhang mit der Streamkonfiguration gemäß Darstellung in 1B, MH, das heißt die Mobildaten, in dem Bereich A versammelt und in dem Bereich B in einer konischen Konfiguration ausgebildet sind. Daher kann der Bereich A auch als Body-Bereich bezeichnet werden, während der Bereich B als Head-/Tail-Bereich bezeichnet werden kann. Da bekannte Daten nicht in dem Head-/Tail-Bereich platziert sind, besteht im Stand der Technik ein Problem dahingehend, dass Daten kein gutes Leistungsvermögen im Vergleich zu Daten des Body-Bereiches aufweisen.
Entsprechend fügt der Datenvorprozessor 100 bekannte Daten an einer geeigneten Stelle zur Platzierung in dem Head-/Tail-Bereich ein. Die bekannten Daten können in einem Langtrainingssequenzformat platziert sein, in dem Daten, die größer als eine vorbestimmte Größe sind, kontinuierlich platziert sind, oder können in einem diskontinuierlich verteilten Format platziert werden.
Die Mobildaten und die bekannten Daten können in verschiedenen Formaten entsprechend einem exemplarischen Ausführungsbeispiel eingefügt werden. Dies wird detailliert unter Bezugnahme auf die begleitende Zeichnung beschrieben. Zunächst folgt jedoch eine detaillierte Beschreibung der Konfiguration eines Digitalrundfunksenders.
Detaillierte Konfiguration des Digitalrundfunksenders
4 ist ein Blockdiagramm zur Darstellung eines Digitalrundfunksenders entsprechend einem exemplarischen Ausführungsbeispiel im Detail. Wie in 4 gezeigt ist, kann der Digitalrundfunksender einen Normalprozessor 320 und eine Erregereinheit 400 zusätzlich zu dem Datenvorprozessor 100 und dem Multiplexierer 200 beinhalten. Aus Gründen der Erläuterung kann eine Einheit, die den Datenvorprozessor 100, den Normalprozessor 320 und den Multiplexierer 200 beinhaltet, als Streamkonfigurationseinheit bezeichnet werden.
In 4 ist die in 3 gezeigte Steuerung 310 weggelassen. Es ist gleichwohl augenscheinlich, dass die Steuerung 310 in dem Digitalrundfunksender beinhaltet ist. Zudem kann ein Element des Digitalrundfunksenders, das in 4 gezeigt ist, weggelassen sein, oder es kann ein neues Element hinzugefügt sind, so dies notwendig ist, und es kann die Anordnungsreihenfolge der Elemente und die Anzahl der Elemente verschieden geändert werden.
Wie in 4 gezeigt ist, empfängt der Normalprozessor 320 Normaldaten und wandelt sie in Daten eines Formates um, das für eine Transportstreamkonfiguration geeignet ist. Dies bedeutet, dass aufgrund dessen, dass der Digitalrundfunksender einen Transportstream konfiguriert, der Normaldaten und Mobildaten beinhaltet, und den Transportstream sendet, ein Empfänger, der Normaldaten empfängt, die Normaldaten geeignet empfangen und verarbeiten sollte. Entsprechend passt der Normalprozessor 320 eine Pakettaktung (Packet Timing) und einen Programmtaktbezug (Program Clock Reference PCR) der Normaldaten (oder Hauptdienstdaten) derart an, dass diese ein Format aufweisen, das für den MPEG/ATSC-Standard geeignet ist, der für die Normaldatendecodierung verwendet wird. Eine detaillierte Erläuterung hiervon ist in Anhang B der ASTC-MH-Spezifikation veröffentlicht und wird hier weggelassen.
Der Datenvorprozessor 100 beinhaltet einen Frame-Codierer 110, einen Blockprozessor 120, einen Gruppenformatierer 130, einen Paketformatierer 140 und einen Signalisierungscodierer 150.
Der Frame-Codierer 110 nimmt eine RS-Frame-Codierung vor. Insbesondere empfängt der Frame-Codierer 110 einen einzelnen Dienst und bildet eine vorbestimmte Anzahl von RS-Frames. Wenn beispielsweise ein einzelner Dienst eine M/H-Ensembleeinheit ist, die aus einer Mehrzahl von M/H-Paraden besteht, so bildet der Frame-Codierer 110 ein vorbestimmtes von den RS-Frames für jede M/H-Parade. Insbesondere verwürfelt (randomize) der Frame-Codierer 110 Eingabemobildaten, nimmt eine RS-CRC-Codierung vor und verteilt die Mobildaten in RS-Frames entsprechend einem vorbestimmten Frame-Modus und gibt ein vorbestimmtes von den RS-Frames aus.
5 ist ein Blockdiagramm zur Darstellung eines Beispieles des Frame-Codierers 110. Wie in 5 gezeigt ist, beinhaltet der Frame-Codierer 110 einen Eingabedemultiplexierer 111, eine Mehrzahl von RS-Frame-Codierern 112-1~112-M und einen Ausgabemultiplexierer 113.
Werden Mobildaten einer vorbestimmten Diensteinheit (beispielsweise ein M/H-Ensemble) eingegeben, so demultiplexiert der Eingabedemultiplexierer 111 die Mobildaten in eine Mehrzahl von Ensembles, so beispielsweise ein primäres Ensemble und ein sekundäres Ensemble, entsprechend einer voreingestellten Konfigurationsinformation, das heißt ein Frame-Modus, und gibt Ensembles an die RS-Frame-Codierer 112-1~112-M aus. Jeder von den RS-Frame-Codierern 112-1~112-M nimmt eine Verwürfelung, eine RS-CRC-Codierung und eine Unterteilung in Bezug auf die Eingabeensembles vor und gibt die Ensembles an den Ausgabemultiplexierer 113 aus. Der Ausgabemultiplexierer 113 multiplexiert Frame-Abschnitte aus der Ausgabe der RS-Frame-Codierer 112-1~112-M und gibt einen primären RS-Frame-Abschnitt und einen sekundären RS-Frame-Abschnitt aus. In diesem Fall kann der primäre RS-Frame-Abschnitt entsprechend einer Einstellbedingung des Frame-Modus ausgegeben werden.
6 ist ein Blockdiagramm zur Darstellung eines Beispieles eines RS-Frame-Codierers, der einer von den RS-Frame-Codierern 112-1~112-M ist. Wie in 6 gezeigt ist, beinhaltet der Frame-Codierer 112 eine Mehrzahl von M/H-Verwürflern 112-1a und 112-1b, eine Mehrzahl von RS-CRC-Codierern 112-2a und 112-2b und eine Mehrzahl von RS-Frame-Unterteilern 112-3a und 112-3b.
Werden das primäre M/H-Ensemble und das sekundäre M/H-Ensemble aus dem Eingabedemultiplexierer 111 eingegeben, so nimmt jeder von den M/H-Verwürflern 112-1a und 112-1b eine Verwürfelung vor, und es codiert jeder von den RS-CRC-Codierern 112-2a und 112-2b die verwürfelten Daten gemäß RS-CRC. Jeder von den RS-Frame-Unterteilern 112-3a und 112-3b unterteilt die Daten zur Blockcodierung geeignet und gibt die Daten an den Ausgabemultiplexierer 113 aus, sodass der Blockprozessor 120 mit Anordnung an einem rückwärtigen Ende des Frame-Codierers 110 die Daten geeignet blockcodiert. Der Ausgabemultiplexierer 113 multiplexiert Frame-Abschnitte durch geeignetes Kombinieren und gibt die Frame-Abschnitte an den Blockprozessor 120 aus, sodass der Blockprozessor 120 die Daten blockcodiert.
Der Blockprozessor 120 codiert den Stream aus der Ausgabe des Frame-Codierers 110 in der Einheit eines Blockes, das heißt blockcodiert den Stream.
7 ist ein Blockdiagramm zur Darstellung eines Beispieles des Blockprozessors 120.
Wie in 7 gezeigt ist, beinhaltet der Blockprozessor 120 einen ersten Wandler 121, einen Byte-zu-Bit-Wandler 122, einen Faltungscodierer 123, einen Symbolverschachtler 124, einen Symbol-zu-Byte-Wandler 125 und einen zweiten Wandler 126.
Der erste Wandler 121 wandelt die RS-Frame-Eingabe aus dem Frame-Codierer in der Einheit des Blockes um. Dies bedeutet, dass der erste Wandler 121 Mobildaten in dem RS-Frame entsprechend einem vorbestimmten Blockmodus kombiniert und einen SCCC-Block (Serially Concatenated Convolutional Code SCCC, seriell verketteter Faltungscode) ausgibt.
Ist der Blockmodus beispielsweise gleich „00”, so wird ein einzelner M/H-Block zu einem einzelnen SCCC-Block als solches.
8 ist eine Ansicht zur Darstellung von Mobildaten, die in M/H-Blöcke in der Einheit eine Blockes unterteilt sind. Wie in 8 gezeigt ist, kann eine einzelne Mobildateneinheit, so beispielsweise eine M/H-Gruppe in 10 Blöcke (B1 bis B10) unterteilt werden. Ist der Blockmodus gleich „00”, so wird jeder Block B1 bis B10 als SCCC-Block ausgegeben. Wenn demgegenüber der Blockmodus gleich „01” ist, so werden zwei M/H Blöcke kombiniert und als einzelner SCCC-Block ausgegeben. Das Kombinationsmuster kann verschieden eingestellt sein. So können die Blöcke B1 und B6 beispielsweise zur Bildung des Blockes SCB1 kombiniert werden, und die Blöcke B2 und B7, die Blöcke B3 und B8, die Blöcke B4 und B9 und die Blöcke B5 und B10 werden zur Bildung der Blöcke SCB2, SCB3, SCB4 beziehungsweise SCB5 kombiniert. Die Blöcke können auf verschiedene Weisen kombiniert werden, und es kann die Anzahl der kombinierten Blöcke entsprechend anderen Blockmodi verschieden sein.
Der Byte-zu-Bit-Wandler 122 wandelt den SCCC-Block von einer Byte-Einheit in eine Bit-Einheit um. Dies rührt daher, dass der Faltungscodierer 123 in einer Bit-Einheit betrieben wird. Entsprechend nimmt der Faltungscodierer 123 eine Faltungscodierung der umgewandelten Daten vor.
Anschließend nimmt der Symbolverschachtler 124 eine Symbolverschachtelung vor. Die Symbolverschachtelung kann auf dieselbe Weise wie bei einem Typ von Blockverschachtelung vorgenommen werden. Die symbolverschachtelten Daten werden in die Byte-Einheit durch den Symbol-zu-Byte-Wandler 125 umgewandelt und in eine M/H-Blockeinheit durch den zweiten Wandler 126 umgewandelt und ausgegeben.
Der Gruppenformatierer 130 empfängt den Stream, der von dem Blockprozessor 120 verarbeitet worden ist, und formatiert den Stream in der Einheit einer Gruppe. Insbesondere bildet der Gruppenformatierer 130 die Datenausgabe des Blockprozessors 120 auf eine geeignete Stelle in dem Stream ab und addiert bekannte Daten, Signalisierungsdaten und Initialisierungsdaten zu dem Stream bzw. fügt diese hinzu. Der Gruppenformatierer 130 kann ein Platzhalterbyte für Normaldaten, einen MPEG-2-Header und eine nichtsystematische RS-Parität und ein Dummybyte hinzufügen, damit Entsprechung zum Gruppenformat gegeben ist.
Die Signalisierungsdaten geben eine Vielfalt von Informationen an, die zur Verarbeitung des Transportstreams nötig sind. Die Signalisierungsdaten können geeignet von dem Signalisierungscodierer 150 verarbeitet und für den Gruppenformatierer 130 bereitgestellt werden.
Zum Senden von Mobildaten können ein Transportparameterkanal (Transport Parameter Channel TPC) und ein Schnellinformationskanal (Fast Information Channel FIC) verwendet werden. Der TPC dient zum Bereitstellen von verschiedenen Parametern, so beispielsweise einer FEC-Modus-Information (Forward Error Correction FEC, Vorwärtsfehlerberichtigung) und einer M/H-Frame-Information, während der FIC dem Ermitteln eines Schnelldienstes des Empfängers dient und eine Kreuzschichtinformation (cross layer information) zwischen einer physischen Schicht und einer oberen Schicht beinhaltet. Werden die TPC-Information und die FIC-Information für den Signalisierungscodierer 150 bereitgestellt, so verarbeitet der Signalisierungscodierer 150 die Information geeignet und stellt die Information als Signalisierungsdaten dar.
9 ist ein Blockdiagramm zur Darstellung eines Beispieles des Signalisierungscodierers 150.
Wie in 9 gezeigt ist, beinhaltet der Signalisierungscodierer 150 einen RS-Codierer 151 für einen TPC, einen Multiplexierer 152, einen RS-Codierer 153 für einen FIC, einen Blockverschachtler 154, einen Signalisierungsverwürfler 155 und einen PCCC-Codierer (Parallel Concatenated Convolutional Code PCCC, Parallelverkettungsfaltungscode) 156. Der RS-Codierer 151 für den TPC RS-codiert die eingegebenen TPC-Daten und bildet ein TPC-Codewort. Der RS-Codierer 153 für den FIC und den Blockverschachtler 154 RS-codiert und blockverschachtelt die eingegebenen FIC-Daten und bildet ein FIC-Codewort. Der Multiplexierer 152 platziert das FIC-Codewort nach dem TPC-Codewort, wodurch eine Reihe von Sequenzen gebildet wird. Die Sequenzen werden durch den Signalisierungsverwürfler 155 verwürfelt, durch den PCCC-Codierer 156 PCCC-codiert und an den Gruppenformatierer 130 als Signalisierungsdaten ausgegeben.
Die bekannten Daten betreffen eine Sequenz, die dem Digitalrundfunksender und dem Digitalrundfunkempfänger, wie vorstehend beschrieben worden ist, allgemein bekannt ist. Der Gruppenformatierer 130 fügt die bekannten Daten an einer geeigneten Stelle entsprechend einem Steuersignal ein, das von einem separat bereitgestellten Element (beispielsweise der Steuerung 310) bereitgestellt wird, sodass die bekannten Daten an einer geeigneten Stelle des Systems nach der Verschachtelung durch die Erregereinheit 400 platziert sind. Die bekannten Daten können beispielsweise an einer geeigneten Stelle derart eingefügt werden, dass die bekannten Daten in dem Bereich B der Streamkonfiguration von 18 platziert sind. Der Gruppenformatierer 130 kann eine Einfügestelle der bekannten Daten selbst bestimmen, und zwar unter Berücksichtigung einer Verschachtelungsregel.
Die Initialisierungsdaten bezeichnen Daten, die für die Trellis-Codiereinheit 450 der Erregereinheit 400 zur Initialisierung der internen Speicher hiervon zu einem geeigneten Zeitpunkt notwendig sind. Dies wird detailliert nachstehend im Rahmen der Beschreibung der Erregereinheit 400 erläutert.
Der Gruppenformatierer 130 kann eine Gruppenformatkonfiguration (nicht gezeigt) zum Konfigurieren des Streams in einem Gruppenformat durch Einfügen von verschiedenen Bereichen und Signalen in dem Stream gemäß vorstehender Beschreibung und einen Datenentschachtler zum Entschachteln des in dem Gruppenformatierer konfigurierten Streams beinhalten.
Der Datenentschachtler nimmt ein Neuanordnen der Daten in umgekehrter Reihenfolge im Vergleich zu derjenigen des Verschachtlers 430 vor, der an einem rückwärtigen Ende des Streams angeordnet ist. Der Stream, der durch den Datenentschachtler entschachtelt ist, kann für den Paketformatierer 140 bereitgestellt werden.
Der Paketformatierer 140 entfernt verschiedene Platzhalter aus der Bereitstellung in dem Stream durch den Gruppenformatierer 130 und fügt einen MPEG-Header mit einer PID hinzu, die eine Paket-ID von Mobildaten ist. Entsprechend gibt der Paketformatierer 140 den Stream in der Einheit einer vorbestimmten Anzahl von Paketen für jede Gruppe aus. Entsprechend können 118 TS-Pakete ausgegeben werden.
Wie vorstehend beschrieben worden ist, ist der Datenvorprozessor 100 in verschiedenen Konfigurationen realisiert und konfiguriert die Mobildaten in einem geeigneten Format. Wenn insbesondere eine Mehrzahl von Mobildiensten bereitgestellt wird, kann die Anzahl von Elementen, die in dem Datenvorprozessor 100 beinhaltet sind, zahlreich sein.
Der Multiplexierer 200 multiplexiert einen Normalstream, der von dem Normalprozessor 320 verarbeitet worden ist, und einen Mobilstream, der von dem Datenvorprozessor 100 verarbeitet worden ist, und konfiguriert hierdurch einen Transportstream. Der Transportstream aus der Ausgabe des Multiplexierers 200 kann die Normaldaten und die Mobildaten beinhalten und kann des Weiteren bekannte Daten zur Verbesserung des Empfangsleistungsvermögens beinhalten.
Die Erregereinheit 400 nimmt ein Codieren, Verschachteln, Trellis-Codieren und Modulieren in Bezug auf den Transportstream vor, der durch den Multiplexierer 200 konfiguriert worden ist, und gibt den Transportstream aus. Entsprechend einem Fall kann die Erregereinheit 400 als Datennachprozessor bezeichnet werden.
Wie in 4 gezeigt ist, beinhaltet die Erregereinheit 400 einen Verwürfler 410, einen RS-Codierer 420, einen Verschachtler 430, eine Paritätsersetzungseinheit 440, eine Trellis-Codiereinheit 450, einen RS-Neucodierer bzw. Recodierer 460, einen Synchronisierungsmultiplexierer 470, eine Piloteinfügeeinheit 480 und einen 8-VSB-Modulator 490 sowie einen RS-Aufwärtswandler 495.
Der Verwürfler 410 verwürfelt den Transportstream aus der Ausgabe des Multiplexierers 200. Der Verwürfler 410 nimmt dieselbe Funktion wie diejenige des Verwürflers entsprechend dem ATSC-Standard vor.
Der Verwürfler 410 kann eine XOR-Berechnung des MPEG-Headers der Mobildaten und der gesamten Normaldaten mit einer maximal 16-Bit-Länge-PRBS (Pseudo Random Binary Sequence PRBS, Pseudozufallsbinärsequenz) vornehmen, kann jedoch nicht eine XOR-Berechnung eines Nutzlastbytes der Mobildaten vornehmen. In diesem Fall kann jedoch ein PRBS-Generator mit dem Schieben eines Schieberegisters fortfahren. Dies bedeutet, dass der Verwürfler 410 eine Nutzlastbyte der Mobildaten übergeht bzw. bypasst.
Der RS-Codierer 420 nimmt eine RS-Codierung in Bezug auf den verwürfelten Stream vor.
Insbesondere wenn ein Abschnitt, der den Normaldaten entspricht, eingegeben wird, nimmt der RS-Codierer 420 ein systematisches RS-Codieren auf dieselbe Weise wie bei dem ATSC-System aus dem Stand der Technik vor. Dies bedeutet, dass der RS-Codierer 420 eine 20-Byte-Parität zu einem Endabschnitt eines jeden der Pakete von 187 Byte hinzufügt. Wenn demgegenüber ein Abschnitt, der den Mobildaten entspricht, gegeben ist, nimmt der RS-Codierer 420 eine nichtsystematische RS-Codierung vor. In diesem Fall sind die 20-Byte-RS-FEC-Daten, die durch das nichtsystematische RS-Codieren erhalten werden, an einer vorbestimmten Paritätsbytestelle in jedem Mobildatenpaket platziert. Entsprechend kann der Sender eine Kompatibilität mit einem Empfänger nach dem ATSC-Standard aus dem Stand der Technik aufweisen.
Der Verschachtler 430 verschachtelt den Stream, der durch den RS-Codierer 420 codiert ist. Das Verschachteln kann auf dieselbe Weise wie dasjenige bei einem ATSC-System aus dem Stand der Technik vorgenommen werden. Dies bedeutet, dass der Verschachtler 430 Daten schreibt und liest, während eine Mehrzahl von Wegen ausgewählt wird, die aus einer verschiedenen Anzahl von Schieberegistern bestehen, und zwar in einer Sequenz bzw. Abfolge unter Verwendung eines Schalters, sodass eine Verschachtelung in Entsprechung zur Anzahl der Schieberegister auf dem Weg vorgenommen wird.
Die Paritätsersetzungseinheit 440 berichtigt die Parität, die infolge der Speicherinitialisierung gemäß Durchführung durch die Trellis-Codiereinheit 450 an dem rückwärtigen Ende geändert wird.
Dies bedeutet, dass die Trellis-Codiereinheit 450 den verschachtelten Stream empfängt und eine Trellis-Codierung in Bezug auf den Stream vornimmt. Die Trellis-Codiereinheit 450 verwendet im Allgemeinen zwölf Trellis-Codierer. Entsprechend verwendet werden ein Demultiplexier zum Unterteilen des Streams in 12 unabhängige Streams und Eingeben der Streams in jeden Trellis-Codierer und ein Multiplexierer zum Kombinieren der Streams, die durch die Trellis-Codierer codiert worden sind, zur Bildung eines einzigen Streams.
Jeder der Trellis-Codierer nimmt eine Trellis-Codierung auf eine Weise vor, dass er eine Logikberechnung eines neuen Eingabewertes und eines Wertes, der in einem internen Speicher vorgespeichert ist, unter Verwendung einer Mehrzahl von internen Speichern vornimmt und einen Wert ausgibt.
Wie vorstehend beschrieben worden ist, kann der Transportstream bekannte Daten beinhalten. Die bekannten Daten sind eine bekannte Sequenz, die dem Digitalrundfunksender und dem Digitalrundfunkempfänger allgemein bekannt ist. Der Digitalrundfunkempfänger kann einen Grad der Fehlerberichtigung durch Identifizieren eines Zustandes der empfangenen bekannten Daten bestimmen. Dies bedeutet, dass die bekannten Daten auf eine Weise, die der Empfänger kennt, gesendet werden sollen. Da jedoch der Wert, der in dem internen Speicher gespeichert ist, der in dem Trellis-Codierer bereitgestellt ist, nicht bekannt ist, sollte der interne Speicher derart initialisiert werden, dass er einen bestimmten Wert aufweist, bevor die bekannten Daten eingegeben werden. Entsprechend initialisiert die Trellis-Codiereinheit 450 den Speicher vor dem Trellis-Codieren der bekannten Daten. Die Speicherinitialisierung kann als Trellis-Rücksetzung (Trellis Reset) bezeichnet werden.
10 ist eine Ansicht zur Darstellung eines Beispieles von einem aus der Mehrzahl von Trellis-Codierern, der in der Trellis-Codiereinheit 450 bereitgestellt ist.
Wie in 10 gezeigt ist, beinhaltet der Trellis-Codierer erste und zweite Multiplexierer 451 und 452, erste und zweite Addierer bzw. Hinzufüger 453 und 454, erste bis dritte Speicher 455, 456 und 457 und einen Abbilder 458.
Der erste Multiplexierer 451 empfängt Daten N in dem Stream und einen Wert I, der in dem ersten Speicher 455 gespeichert ist, und gibt einen Wert, das heißt N oder I, entsprechend einem Steuersignal N/I aus. Entsprechend wirkt ein Steuersignal, das eine Steuerung zur Auswahl von I vornimmt, wenn ein Wert entsprechend einem Initialisierungsdatenabschnitt eingegeben wird, derart, dass I von dem ersten Multiplexierer 451 ausgegeben wird. In den anderen Abschnitten wird N ausgegeben. Auf gleiche Weise wird I von dem zweiten Multiplexierer 459 nur dann ausgegeben, wenn der Wert entsprechend dem Initialisierungsdatenabschnitt eingegeben ist.
Entsprechend gibt der erste Multiplexierer 451 den verschachtelten Wert an einem rückwärtigen Ende als solches aus, wenn ein Abschnitt, der nicht der Initialisierungsdatenabschnitt ist, eingegeben wird, wobei der Ausgabewert in den ersten Addierer 453 zusammen mit einem in dem ersten Speicher 455 vorgespeicherten Wert eingegeben wird. Der erste Addierer 453 nimmt eine logische Operation vor, das heißt ein Exklusiv-ODER in Bezug auf die eingegebenen Werte, und gibt Z2 aus. Wenn in diesem Zustand der Initialisierungsdatenabschnitt eingegeben wird, so wird der Wert, der in dem ersten Speicher 455 gespeichert ist, durch den ersten Multiplexierer 451 als solches ausgewählt und ausgegeben. Da entsprechend die zwei selben Werte in den ersten Addierer 443 eingegeben werden, ist der Logikbetriebswert immer ein konstanter Wert. Dies bedeutet, dass dann, wenn ein Exklusiv-ODER vorgenommen wird, 0 ausgegeben wird. Da der Ausgabewert des ersten Addierers 453 in den ersten Speicher 455 als solches eingegeben wird, wird der erste Speicher 455 derart initialisiert, dass er den Wert 0 aufweist.
Wird der Initialisierungsdatenabschnitt eingegeben, so wählt der zweite Multiplexierer 452 einen Wert aus, der in dem dritten Speicher 457 als solches gespeichert ist, und gibt den Wert aus. Der Ausgabewert wird in den zweiten Addierer 454 zusammen mit dem Wert, der in dem dritten Speicher 457 gespeichert ist, ausgegeben. Der zweite Addierer 454 nimmt eine Logikoperation in Bezug auf die beiden selben Werte vor und gibt einen resultierenden Wert an den zweiten Speicher 456 aus. Wie vorstehend beschrieben worden ist, sind die Eingabewerte des zweiten Addierers 454 dieselben, und es wird eine Logikoperation für dieselben Werte, so beispielsweise 0 für den Fall des Exklusiv-ODERs, in den zweiten Speicher 456 eingegeben. Entsprechend wird der zweite Speicher 456 initialisiert. Der Wert, der in dem zweiten Speicher 456 gespeichert ist, wird verschoben und in dem dritten Speicher 457 gespeichert. Wenn entsprechend die nächsten Initialisierungsdaten eingegeben werden, wird ein aktueller Wert des zweiten Speichers 456, das heißt 0, in den dritten Speicher 457 als solches eingegeben, womit der dritte Speicher 457 ebenfalls initialisiert wird.
Der Abbilder 458 empfängt den Ausgabewert des ersten Addierers 453, den Ausgabewert des zweiten Multiplexierers 452 und den Ausgabewert des zweiten Speichers 456, bildet die Werte auf einen entsprechenden Symbolwert R ab und gibt den Symbolwert aus. Wenn beispielsweise Z0, Z1 und Z2 als 0, 1 beziehungsweise 0 ausgegeben werden, so gibt der Abbilder 458 ein –3-Symbol aus.
Da der RS-Codierer 420 vor dem Trellis-Codierer 450 angeordnet ist, enthält der Wert, der in den Trellis-Codierer 450 eingegeben wird, eine Parität, die bereits hinzu addiert bzw. hinzugefügt ist. Daher sollte, wenn der Trellis-Codierer 450 eine Initialisierung vornimmt und daher ein bestimmter Wert der Daten geändert wird, die Parität ebenfalls geändert werden.
Der RS-Neucodierer bzw. Recodierer 460 ändert den Wert des Initialisierungsdatenabschnittes unter Verwendung von X1' und X2', die von der Trellis-Codiereinheit 450 eingegeben werden, wodurch eine neue Parität entsteht. Der RS-Recodierer bzw. Neucodierer 460 kann auch als nichtsystematischer RS-Codierer bezeichnet werden.
Obwohl der Speicher derart initialisiert ist, dass er einen Wert 0 in 10 aufweist, kann der Speicher auch derart initialisiert werden, dass er einen Wert aufweist, der nicht 0 ist.
11 ist eine Ansicht zur Darstellung eines weiteren Beispieles für die Trellis-Codierung.
Wie in 11 gezeigt ist, kann der Trellis-Codierer erste und zweite Multiplexierer 451 und 452, erste bis vierte Addierer 453, 454, 459-1 und 459-2 sowie erste bis dritte Speicher 455, 456 und 457 beinhalten. Der Abbilder 458 ist in 11 weggelassen.
Insbesondere kann der erste Multiplexierer 451 eines von einem Streameingabewert X2 und einem Wert des dritten Addierers 459-1 ausgeben. Ein Wert I_X2 oder Speicherwert des ersten Speichers 455 werden in den dritten Addierer 459-1 eingegeben. Der Wert I_X2 betrifft einen Speicherrücksetzwert, der aus einer externen Quelle eingegeben wird. Wenn beispielsweise der erste Speicher 455 derart initialisiert werden soll, dass er einen Wert 1 aufweist, so wird der Wert I_X2 als 1 eingegeben. Ist der Speicherwert des ersten Speichers 455 gleich 0, so ist der Ausgabewert des dritten Addierers 459-1 gleich 1, und der erste Multiplexierer 451 gibt 1 aus. Entsprechend nimmt der erste Addierer 453 ein Exklusiv-ODER in Bezug auf den Ausgabewert des ersten Multiplexierers 451, nämlich 1, und den Speicherwert des ersten Speichers 455, nämlich 0, vor und speichert einen sich ergebenden Wert, nämlich 1, in dem ersten Speicher 455. Im Ergebnis wird der erste Speicher 455 derart initialisiert, dass er den Wert 1 aufweist.
Werden die Initialisierungsdaten eingegeben, so wählt der zweite Multiplexierer 452 einen Ausgabewert des vierten Addierers 459-2 aus und gibt den Wert aus. Der vierte Addierer 459-2 gibt einen Speicherrücksetzwert I_X1, der von außen eingegeben worden ist, und einen Exklusiv-ODER-Wert des dritten Speichers 457 aus. Wenn beispielsweise 1 und 0 in den zweiten beziehungsweise dritten Speichern 456 und 457 gespeichert sind und die beiden Speicher derart initialisiert werden, dass die Werte von 1 beziehungsweise 1 aufweisen, so gibt der zweite Multiplexierer 452 einen Exklusiv-ODER-Wert 1 des Wertes von 0 aus der Speicherung in dem dritten Speicher 457 und den I_XI-Wert 1 aus. Der zweite Addierer 454 nimmt ein Exklusiv-ODER in Bezug auf den Ausgabewert 1 und den Wert 0 aus der Speicherung in dem dritten Speicher 457 vor und gibt einen sich ergebenden Wert von 1 in den zweiten Speicher 456 ein. Der Wert von 1, der ursprünglich in dem zweiten Speicher 456 gespeichert worden ist, wird in den dritten Speicher 457 verschoben, sodass der Wert des dritten Speichers 457 gleich 1 ist. In diesem Zustand wird, wenn das zweite I_X1 als 1 eingegeben ist, eine Exklusiv-ODER-Operation in Bezug auf I_XI und den Wert von 1 des dritten Speichers 457 durchgeführt, und es wird ein sich ergebender Wert von 0 von dem zweiten Multiplexierer 452 ausgegeben. Nimmt der zweite Addierer 454 ein Exklusiv-ODER in Bezug auf den Wert von 0 aus der Ausgabe des zweiten Multiplexiers 452 und den Wert von 1 aus der Speicherung in dem dritten Speicher 457 vor, so wird ein sich ergebender Wert von 1 in den zweiten Speicher 456 eingegeben, und der Wert 1 aus der Speicherung in dem zweiten Speicher 456 wird in den dritten Speicher 457 verschoben und in dem dritten Speicher 457 gespeichert. Im Ergebnis werden die zweiten und dritten Speicher 456 und 457 derart initialisiert, dass sie den Wert 1 aufweisen.
12 und 13 sind Ansichten zur Darstellung des Trellis-Codierers entsprechend verschiedenen exemplarischen Ausführungsbeispielen.
Wie in 12 gezeigt ist, beinhaltet der Trellis-Codierer des Weiteren dritte und vierte Multiplexierer 459-3 und 459-4 zusätzlich zu den Elementen von 11. Die dritten und vierten Multiplexierer 459-3 und 459-4 können Werte der ersten und zweiten Addierer 453 und 454 oder Werte I_X2 und I_X1 entsprechend einem Steuersignal N/I ausgeben. Entsprechend können die ersten bis dritten Speicher 455, 456 und 457 derart initialisiert werden, dass sie gewünschte Werte aufweisen.
13 zeigt den Trellis-Codierer in einer vereinfachten Konfiguration. Wie in 13 gezeigt ist, kann der Trellis-Codierer erste und zweite Addierer 453 und 454, erste bis dritte Speicher 455, 456, 457 sowie dritte und vierte Multiplexierer 459-3 und 450-4 beinhalten. Entsprechend können die ersten bis dritten Speicher 455, 456, 457 entsprechend Werten I_X1, I_X2 aus der Eingabe in die dritten und vierten Multiplexierer 459-3 beziehungsweise 459-4 initialisiert werden. Dies bedeutet, dass, wie in 13 gezeigt ist, die Werte I_X2 und I_X1 in den ersten Speicher 455 und den zweiten Speicher 456 als solches eingegeben werden und zu Werten des ersten Speichers 455 und des zweiten Speichers 456 werden.
Auf eine noch detailliertere Beschreibung des Betriebs des Trellis-Codierers von 12 und 13 wird verzichtet.
Wie in 4 gezeigt ist, werden eine Feldsynchronisierung und eine Segmentsynchronisierung zu dem Stream mit Trellis-Codierung durch die Trellis-Codiereinheit 450 durch den Synchronisierungsmultiplexier 470 addiert bzw. hinzugefügt.
Wie vorstehend beschrieben worden ist, sollte dann, wenn der Datenvorprozessor 100 die Mobildaten in den Paketen, die bestehenden Normaldaten zugeteilt sind, platziert und die Mobildaten verwendet, der Digitalrundfunksender den Empfänger über das Vorhandensein von neuen Mobildaten informieren. Das Vorhandensein von neuen Mobildaten kann auf verschiedene Weisen mitgeteilt werden. Eine von den verschiedenen Weisen bedient sich einer Feldsynchronisierung. Dies wird nachstehend detailliert beschrieben.
Die Piloteinfügeeinheit 480 fügt einen Pilot in den Transportstream ein, der von dem Synchronisierungsmultiplexierer 470 verarbeitet wird, und es nimmt der 8-VSB-Modulator 490 eine Modulation gemäß einem 8-VSB-Modulationsverfahren vor. Der RF-Aufwärtswandler 495 wandelt den modulierten Stream in ein oberes RF-Bandsignal zur Sendung um und sendet das umgewandelte Signal über eine Antenne.
Wie vorstehend beschrieben worden ist, kann der Transportstream an den Empfänger mit den Normaldaten, den Mobildaten und den bekannten Daten, die darin beinhaltet sind, gesendet werden.
14 ist eine Ansicht zur Erläuterung eines Mobildaten-Frames des Transportstreams, das heißt einer Einheitskonfiguration eines M/H-Frames. Wie bei a) von 14 gezeigt ist, ist ein M/H-Frame gleich 968 ms in einer Zeiteinheit lang und ist in fünf Unterframes unterteilt, wie bei b) von 14 gezeigt ist. Ein Unterframe kann eine Zeiteinheit von 193,6 ms aufweisen. Zudem kann, wie bei c) von 14 gezeigt ist, jedes Unterframe in 16 Schlitze unterteilt sein. Jeder Schlitz kann eine Zeiteinheit von 12,1 ms aufweisen und kann insgesamt 156 Transportstreampakete beinhalten. Wie beschrieben worden ist, sind 38 von den gesamten Transportstreampaketen den Normaldaten zugeteilt, und es sind 18 Pakete den Mobildaten zugeteilt. Dies bedeutet, dass eine M/H-Gruppe aus 118 Paketen besteht.
In diesem Zustand kann der Datenvorprozessor 100 die Mobildaten und die bekannten Daten in den Paketen, die den Normaldaten zugeteilt sind, platzieren, um hierdurch die Sendeeffizienz der Mobildaten und das Empfangsleistungsvermögen zu verbessern.
Verschiedene exemplarische Ausführungsbeispiele eines geänderten Transportstreams
15 bis 21 sind Ansichten zur Darstellung einer Transportstreamkonfiguration entsprechend verschiedenen exemplarischen Ausführungsbeispielen.
15 zeigt eine einfachste modifizierte Konfiguration, das heißt eine Streamkonfiguration, die mit den Mobildaten verschachtelt ist, die in den Paketen platziert sind, die den Normaldaten zugeteilt sind, das heißt einen zweiten Bereich. In dem Stream von 15 können die bekannten Daten in dem zweiten Bereich zusammen mit den Mobildaten platziert werden.
Daher können ein Abschnitt, der nicht für Mobildaten bei dem ATSC-MH-Standard aus dem Stand der Technik verwendet wird, das heißt 38 Pakete für Mobildaten verwendet werden. Da der zweite Bereich unabhängig von einem bestehenden Mobildatenbereich (das heißt dem ersten Bereich) verwendet wird, kann ein Dienst oder können mehrere Dienste zusätzlich bereitgestellt werden. Werden neue Mobildaten für denselben Dienst wie diejenigen der bestehenden Mobildaten verwendet, so kann die Sendeeffizienz weiter verbessert werden.
Wenn demgegenüber die neuen Mobildaten und die bekannten Daten, wie in 15 gezeigt ist, gesendet werden sollen, so können das Vorhandensein der neuen Mobildaten und der bekannten Daten und die Stellen der neuen Mobildaten und der bekannten Daten dem Empfänger unter Verwendung von Signalisierungsdaten oder einer Feldsynchronisierung mitgeteilt werden.
Die Mobildaten und die bekannten Daten können durch den Datenvorprozessor 100 platziert werden. Insbesondere kann der Gruppenformatierer 130 des Datenvorprozessors 100 die Mobildaten und die bekannten Daten in den 38 Paketen platzieren.
Aus 15 ist ersichtlich, dass bekannte Daten eines 6-Langtrainingssequenzformates in einem Body-Bereich platziert werden, wo bestehende Mobildaten versammelt sind. Es ist zudem ersichtlich, dass die Signalisierungsdaten zwischen den ersten und den zweiten Langtrainingssequenzen platziert werden, um die Fehlerstabilität der Signalisierungsdaten zu erreichen. Demgegenüber können die bekannten Daten in den Paketen, die den Normaldaten zugeteilt sind, in einem verteilten Format wie auch in dem Langtrainingssequenzformat platziert werden.
In 15 bezeichnet ein schraffierter Bereich, der durch das Bezugszeichen 1510 angegeben ist, einen MPEG-Header-Abschnitt, ein schraffiertes Gebiet, das durch das Bezugszeichen 1520 angegeben ist, bezeichnet einen RS-Paritätsbereich, ein schraffiertes Gebiet, das durch das Bezugszeichen 1530 angegeben ist, bezeichnet einen Dummy-Bereich, ein schraffiertes Gebiet, das durch das Bezugszeichen 1540 angegeben ist, bezeichnet Signalisierungsdaten, und ein schraffiertes Gebiet, das durch das Bezugszeichen 1550 angegeben ist, bezeichnet Initialisierungsdaten. Wie in 15 gezeigt ist, werden die Initialisierungsdaten platziert, bevor die bekannten Daten auftreten. Das Bezugszeichen 1400 bezeichnet N – 1-Schlitz-M/H-Daten, das Bezugszeichen 1500 bezeichnet N-Schlitz-M/H-Daten, und das Bezugszeichen 1600 bezeichnet N + 1-Schlitz-M/H-Daten.
16 zeigt eine Transportstreamkonfiguration zum Senden von Mobildaten und bekannten Daten unter Verwendung von Paketen, die Normaldaten zugeteilt sind, das heißt einen zweiten Bereich, und einen Teil eines ersten Bereiches, der bestehenden Mobildaten zugeteilt ist.
Wie in 16 gezeigt ist, sind in dem Bereich A, das heißt einem Body-Bereich, wo die bestehenden Mobildaten versammelt sind, die bekannten Daten des 6-Langtrainingssequenzformates platziert. Zudem sind in dem Bereich B die bekannten Daten in dem Langtrainingssequenzformat platziert. Die bekannten Daten sind in einigen der 118 Pakete, die den bestehenden Mobildaten zugeteilt sind, wie auch in den 38 Paketen beinhaltet, sodass sie in dem Bereich B in dem Langtrainingssequenzformat platziert sind. Die neuen Mobildaten sind in dem verbleibenden Bereich der 38 Pakete platziert, die die bekannten Daten nicht beinhalten. Entsprechend kann die Fehlerberichtigungsleistung des Bereiches B verbessert werden.
Werden die bekannten Daten erneut zu einem Teil des Bereiches für die bestehenden Mobildaten hinzugefügt bzw. addiert, so wird es möglich, eine Information an einer Stelle der neuen bekannten Daten zu bestehenden Signalisierungsdaten für die Kompatibilität mit einem Empfänger bestehender Mobildaten zu addieren bzw. hinzuzufügen oder einen Header eines bestehenden Mobilpaketes, in das die neuen bekannten Daten derart eingefügt sind, dass sie ein Format, das von dem Empfänger der bestehenden Mobildaten nicht erkannt werden kann, so beispielsweise ein Nullpaketformat, aufweisen, zu verarbeiten. Da entsprechend der Empfänger der bestehenden Mobildaten die neu addierten bzw. hinzugefügten bekannten Daten nicht erkennt, tritt eine Fehlfunktion auf.
17 zeigt eine Streamkonfiguration, bei der wenigstens eines von den Mobildaten und den bekannten Daten in einem MPEG-Header, einer RS-Parität, wenigstens einem Teil eines Dummys und bestehenden MH-Daten platziert ist. In diesem Fall kann eine Mehrzahl von neuen Mobildaten entsprechend einer Stelle platziert werden.
Dies bedeutet, dass im Vergleich zu 15 17 angibt, dass neue Mobildaten und neue bekannte Daten in dem MPEG-Header, der RS-Parität und einem Teil des Dummys gebildet werden. Die Mobildaten, die in diese Abschnitte eingefügt sind, und die Mobildaten, die in die Normaldatenpakete eingefügt sind, können verschiedene Daten oder auch dieselben Daten sein.
Die neuen Mobildaten können in dem Bereich für die bestehenden Mobildaten zusätzlich zu diesen Abschnitten platziert werden.
Ist der Stream gemäß Darstellung in 17 konfiguriert, so kann die Sendeeffizienz der Mobildaten und der bekannten Daten im Vergleich zu 15 und 16 weiter verbessert werden. Insbesondere kann eine Mehrzahl von Mobildatendiensten bereitgestellt werden.
Ist der Stream gemäß Darstellung in 17 konfiguriert, so sind die neuen Signalisierungsdaten in dem Bereich für die neuen Mobildaten unter Verwendung von bestehenden Signalisierungsdaten und einer Feldsynchronisierung beinhaltet, sodass eine Mitteilung dahingehend erfolgt, ob die neuen Mobildaten beinhaltet sind oder nicht.
18 zeigt eine Streamkonfiguration, in der neue Mobildaten und bekannte Mobildaten in dem Bereich B platziert sind, das heißt einen ersten Bereich, der einem sekundären Dienstbereich entspricht, wie auch einen zweiten Bereich.
Wie in 18 gezeigt ist, ist der gesamte Stream in einen primären Dienstbereich und einen sekundären Dienstbereich unterteilt. Der primäre Dienstbereich kann als Body-Bereich bezeichnet werden, während der sekundäre Dienstbereich als Head-/Tail-Bereich bezeichnet werden kann. Wie beschrieben worden ist, wird, da der Head-/Tail-Bereich keine bekannten Daten beinhaltet und Daten von verschiedenen Schlitzen koexistieren, das Leistungsvermögen des Head-/Tail-Bereiches im Vergleich zu demjenigen des Body-Bereiches schlechter. Daher können die bekannten Daten in diesem Abschnitt zusammen mit den neuen Mobildaten platziert und verwendet werden. Die bekannten Daten können in einem Langtrainingssequenzformat wie in dem Body-Bereich platziert werden. Dies sollte jedoch nicht als Beschränkung betrachtet werden. Die bekannten Daten können in einem verteilten Format platziert werden oder können sowohl in dem Langtrainingssequenzformat wie auch dem verteilten Format platziert werden.
Wird der Abschnitt für die bestehenden Mobildaten als Bereich für neue Mobildaten verwendet, so ist ein Header eines Paketes eines Abschnittes des Bereiches für bestehende Mobildaten einschließlich der neuen Mobildaten oder der bekannten Daten in einem Format konfiguriert, das nicht von dem bestehenden Empfänger erkannt werden kann, sodass die Kompatibilität mit dem Empfänger entsprechend dem bestehenden ATSC-MH-Standard aufrechterhalten werden kann.
Zudem kann die vorbeschriebene Tatsache durch bestehende Signalisierungsdaten oder neue Signalisierungsdaten mitgeteilt werden.
19 zeigt ein Beispiel eines Transportstreams zum Senden von neuen Mobildaten und bekannten Daten unter Verwendung von allem von dem Bereich für bestehende Normaldaten, dem MPEG-Header, dem RS-Paritätsbereich, wenigstens einem Teil des Dummys der bestehenden Mobildaten und dem Bereich der bestehenden Mobildaten. 17 zeigt einen Fall, in dem neue Mobildaten, die von neuen Mobildaten mit Platzierung in dem Normaldatenbereich verschieden sind, in diesen Bereichen gesendet werden, wohingegen 19 einen Fall zeigt, in dem neue Mobildaten unter Verwendung des Normaldatenbereiches und dieser Bereiche zusammen gesendet werden.
20 zeigt einen Transportstream zum Senden von neuen Mobildaten und bekannten Daten unter Verwendung von allem von dem gesamten Bereich B, dem Normaldatenbereich, dem MPEG-Header, dem RS-Paritätsbereich und wenigstens einem Teil des Dummys der bestehenden Mobildaten.
In diesem Fall kann ein Abschnitt, der die neuen Mobildaten und die bekannten Daten beinhaltet, derart verarbeitet werden, dass der Abschnitt wegen der Kompatibilität mit dem bestehenden Empfänger nicht erkannt werden kann.
21 zeigt eine Transportstreamkonfiguration, in der ein Dummy eines Bereiches zur Verwendung durch bestehende Mobildaten durch eine Parität oder einen Bereich für neue Mobildaten ersetzt ist und Mobildaten und bekannte Daten unter Verwendung des ersetzten Dummys und des Normaldatenbereiches platziert werden. In 21 sind ein Dummy des (N – 1)-ten Schlitzes und ein Dummy des N-ten Schlitzes dargestellt.
Wie vorstehend beschrieben worden ist, zeigen 15 bis 21 die Streamkonfiguration nach dem Verschachteln. Der Datenvorprozessor 100 platziert die Mobildaten und die bekannten Daten an geeigneten Stellen, damit sich die Streamkonfiguration gemäß Darstellung in 15 bis 21 ergibt, und zwar nach dem Verschachteln.
Insbesondere platziert der Datenvorprozessor 100 ein Mobildatenpaket in dem Normaldatenbereich, das heißt in den 38 Paketen in der Streamkonfiguration gemäß Darstellung in 1A entsprechend einem vorbestimmten Muster. In diesem Fall können die Mobildaten in einer gesamten Nutzlast des Paketes platziert werden oder können in einem bestimmten Bereich in dem Paket sein. Zudem können die Mobildaten in einem Bereich platziert werden, der in einem Header oder einem Teil des bestehenden Mobilbereiches nach dem Verschachteln befindlich ist, wie auch dem Normaldatenbereich.
Die bekannten Daten können in jedem Mobildatenpaket oder Normaldatenpaket platziert sein. In diesem Fall können die bekannten Daten kontinuierlich in einer vertikalen Richtung oder in einem vorbestimmten Intervall gemäß Darstellung in 1A derart platziert werden, dass die bekannten Daten ein Format einer Langtrainingssequenz oder einer ähnlichen Langtrainingssequenz in einer horizontalen Richtung nach dem Verschachteln aufweisen.
Die bekannten Daten können in einem verteilten Format neben dem Langtrainingssequenzformat gemäß vorstehender Beschreibung platziert werden. Nachstehend werden verschiedene Beispiele eines Platzierungsmusters der bekannten Daten erläutert.
Platzierung von bekannten Daten
Wie vorstehend beschrieben worden ist, werden die bekannten Daten an einer geeigneten Stelle durch den Gruppenformatierer 130 des Datenvorprozessors 100 platziert und werden sodann durch den Verschachtler 430 der Erregereinheit 400 zusammen mit dem Stream verschachtelt. 22 bis 28 sind Ansichten zur Erläuterung eines Verfahrens zum Platzieren von bekannten Daten entsprechend verschiedenen exemplarischen Ausführungsbeispielen.
22 zeigt einen Body-Bereich, in dem verteilte bekannte Daten zusammen mit einer bestehenden Langtrainingssequenz platziert sind, und einen Head-/Tail-Bereich, in dem bekannte Daten zusätzlich in einem konischen Abschnitt platziert sind. Wie vorstehend beschrieben worden ist, werden bekannte Daten neuaddiert, während bestehende Daten als solches derart erhalten werden, dass die Synchronisations- und Kanalschätzungsleistung sowie die Ausgleichs- bzw. Entzerrungsleistung des Empfängers verbessert werden kann.
Die Platzierung der bekannten Daten gemäß Darstellung in 22 wird durch den Gruppenformatierer 130 gemäß vorstehender Beschreibung vorgenommen. Der Gruppenformatierer 130 kann eine Einfügestelle der bekannten Daten eingedenk einer Verschachtelungsregel des Verschachtelns 430 bestimmen. Die Verschachtelungsregel kann entsprechend verschiedenen exemplarischen Ausführungsbeispielen verschieden sein. Wenn jedoch die Verschachtelungsregel bekannt ist, kann dwe Gruppenformatierer 130 eine Stelle der bekannten Daten geeignet bestimmen. Wenn beispielsweise bekannte Daten einer vorbestimmten Größe in einen Teil einer Nutzlast eingefügt oder ein separat bereitgestelltes Feld in jeden vier Paketen eingefügt wird, können bekannte Daten, die in einem regelmäßigen Muster verteilt sind, durch Verschachtelung erhalten werden.
23 zeigt eine Streamkonfiguration zur Darstellung eines Beispieles eines weiteren Verfahrens des Einfügens von bekannten Daten.
Wie in 23 gezeigt ist, werden verteilte bekannte Daten nicht in einem konischen Bereich, sondern nur in einem Body-Bereich zusammen mit einer Langtrainingssequenz platziert.
24 zeigt eine Streamkonfiguration, in der eine Länge einer Langtrainingssequenz im Vergleich zu derjenigen von 23 verringert ist, und verteilte bekannte Daten entsprechend einer verringerten Anzahl von Sequenzen platziert sind. Entsprechend kann das Leistungsvermögen des Doppler-Tracking verbessert werden, während die Dateneffizienz gleich bleibt.
25 zeigt eine Streamkonfiguration zur Darstellung eines Beispieles eines weiteren Verfahrens des Einfügens von bekannten Daten.
Wie in 25 gezeigt ist, wird nur eine erste Sequenz unter den 6-Langtrainingssequenzen in einem Body-Bereich als solches aufrechterhalten, und es werden die verbleibenden Sequenzen durch verteilte bekannte Daten ersetzt. Entsprechend können die Anfangssynchronisierungs- und Kanalschätzungsleistung durch die erste Langtrainingssequenz mit Beginn in dem Body-Bereich und zudem das Leistungsvermögen beim Doppler-Tracking verbessert werden.
26 zeigt eine Streamkonfiguration zur Darstellung eines Beispieles eines weiteren Verfahrens des Einfügens von bekannten Daten. Wie in 26 gezeigt ist, wird eine zweite Sequenz unter den 6-Langtrainingssequenzen durch verteilte bekannte Daten ersetzt.
27 zeigt die Streamkonfiguration von 26, in der bekannte Daten, die in einem verteilten Format ersetzt sind, abwechseln zusammen mit Signalisierungsdaten platziert sind.
28 zeigt eine Streamkonfiguration, in der bekannte Daten zu einem Tail-Bereich wie auch zu einem Head-Bereich hinzugefügt werden.
Wie vorstehend beschrieben worden ist, können die bekannten Daten in verschiedenen Formaten platziert werden.
Werden Mobildaten Paketen, die Normaldaten zugeteilt sind, neuzugeteilt, so kann das Zuteilungsmuster verschieden geändert werden. Nachstehend wird eine Konfiguration eines Transportstreams erläutert, der Mobildaten beinhaltet, die auf verschiedene Weisen entsprechend einem Modus platziert werden.
Platzierung von Mobildaten
Der Datenvorprozessor 100 identifiziert eine Einstellbedingung eines Frame-Modus. Der Frame-Modus kann verschieden eingestellt werden. So kann der Frame-Modus beispielsweise einen ersten Frame-Modus beinhalten, in dem Pakete, die Normaldaten zugeteilt sind, für Normaldaten als solche verwendet werden, wobei nur die Pakete, die bestehenden Mobildaten zugeteilt sind, für Mobildaten verwendet werden, sowie einen zweiten Frame-Modus, in dem wenigstens einige der Pakete, die Normaldaten zugeteilt sind, auch für Mobildaten verwendet werden. Der Frame-Modus kann willkürlich unter Berücksichtigung der Absicht des Bereitstellers der Digitalrundfunksendung und der Sende- und Empfangsumgebung eingestellt werden.
Ist der erste Frame-Modus eingestellt, in dem Normaldaten in allen von den Paketen, die den Normaldaten zugeteilt sind, platziert sind, platziert der Datenvorprozessor 100 Mobildaten nur in den Paketen mit Zuteilung an die Mobildaten auf dieselbe Weise wie bei dem ATSC-MH-Standard aus dem Stand der Technik.
Wenn demgegenüber der zweite Frame eingestellt ist, so bestimmt der Datenvorprozessor 100 eine Einstellbedingung des Modus erneut. Der Modus gibt an, in welchem Muster die Mobildaten in den Paketen, die den Normaldaten zugeteilt sind, platziert sind, das heißt den zweiten Bereich, oder in wie vielen Paketen die Mobildaten platziert sind, und es werden verschiedene Modi entsprechend einem exemplarischen Ausführungsbeispiel bereitgestellt.
Insbesondere eingestellt werden kann der Modus auf einen von einem Modus, in dem Mobildaten in nur einigen der Pakete, die Normaldaten zugeteilt sind, platziert sind, einem Modus, in dem Mobildaten in allen von den Paketen, die Normaldaten zugeteilt sind, platziert sind, und einem inkompatiblen Modus, in dem Mobildaten in allen von den Paketen, die Normaldaten zugeteilt sind, platziert sind und die Mobildaten ebenfalls in einem RS-Paritätsbereich und einem Header-Bereich platziert sind, die für die Kompatibilität mit einem Empfänger zum Empfangen der Normaldaten bereitgestellt sind. In diesem Fall kann der Modus, in dem die Mobildaten in nur einigen von den Paketen platziert sind, in einen Modus, in dem ein Datenbereich von einigen Paketen bzw. eines Paketes, das heißt ein gesamter Nutzlastbereich für die Mobildaten verwendet wird, und einen Modus, in dem nur ein Teil des Nutzlastbereiches für die Mobildaten genutzt wird, unterteilt werden.
Insbesondere beinhaltet, wenn 38 Pakete einen zweiten Bereich, der Normaldaten zugeteilt ist, der Modus:

(1) einen ersten Modus, in dem neue Mobildaten in 11 Paketen unter den 38 Paketen, die den Normaldaten zugeteilt sind, platziert sind;
(2) einen zweiten Modus, in dem neue Mobildaten in 20 Paketen unter den 38 Paketen, die den Normaldaten zugeteilt sind, platziert sind;
(3) einen dritten Modus, in dem neue Mobildaten in 29 Paketen unter den 38 Paketen, die den Normaldaten zugeteilt sind, platziert sind;
(4) einen vierten Modus, in dem neue Mobildaten in allen von den 38 Paketen, die den Normaldaten zugeteilt sind, platziert sind; und
(5) einen fünften Modus, in dem neue Mobildaten in allen von den 38 Paketen, die den Normaldaten zugeteilt sind, und einem Bereich entsprechend dem MPEG-Header und der Parität bei dem Bereich, der bestehenden Mobildaten zugeteilt ist, platziert sind.

Wie vorstehend beschrieben worden ist, kann der fünfte Modus als inkompatibler Modus bezeichnet werden, während die ersten bis vierten Modi als kompatibler Modus bezeichnet werden können. Ein Typ von THE-kompatiblem Modus und die Anzahl von Paketen in jedem Modus können verschieden geändert werden.
29 zeigt eine Streamkonfiguration, in der Mobildaten und bekannte Daten durch den Gruppenformatierer 130 entsprechend dem ersten Modus in einem Ausführungsbeispiel platziert sind, in dem neue Mobildaten unter Verwendung des zweiten Bereiches und des Head-/Tail-Bereiches gesendet werden.
Wie in 29 gezeigt ist, sind die neuen Mobildaten 2950 und bekannte Daten 2960 in dem zweiten Bereich in einem vorbestimmten Muster platziert. Zudem sind die neuen Mobildaten und die bekannten Daten in einem Abschnitt 2950 entsprechend dem Head-/Tail-Bereich neben dem zweiten Bereich platziert.
Es ist ersichtlich, dass der MPEG-Header 2910, die bekannten Daten 2920, die Signalisierungsdaten 2930, die bestehenden Mobildaten 2940 und der Dummy 2970 in dem Stream in einer vertikalen Richtung angeordnet sind. In einem derartigen Zustand wird ein leerer Raum in dem zweiten Bereich mit den Normaldaten gefüllt, wobei anschließend eine Streamkonfiguration gemäß Darstellung in 30 durch Codieren und Verschachteln erzeugt wird.
30 zeigt eine Streamkonfiguration in einem verschachtelten Zustand in dem ersten Modus.
Wie in 30 gezeigt ist, werden neue Mobildaten 3010 und bekannte Daten 3030 in einem Teil eines Paketbereiches, der Normaldaten zugeteilt ist, platziert. Insbesondere werden die bekannten Daten diskontinuierlich in dem zweiten Bereich angeordnet, wodurch ein ähnliches Langtrainingssequenzformat für eine Langtrainingssequenz des Body-Bereiches gebildet wird.
Die Mobildaten 2950, die in einem Abschnitt platziert sind, der dem Head-/Tail-Bereich in 29 entspricht, entsprechen Mobildaten 3020, die in dem Head-/Tail-Bereich von 30 platziert sind, und die bekannten Daten 2955, die zusammen mit den Mobildaten 2950 platziert sind, bilden die bekannten Daten 3030 des ähnlichen Langtrainingssequenzformates zusammen mit den bekannten Daten in dem zweiten Bereich von 30.
31 zeigt eine Streamkonfiguration, in der Mobildaten und bekannte Daten durch den Gruppenformatierer 130 entsprechend dem zweiten Modus bei einem exemplarischen Ausführungsbeispiel platziert sind, bei dem neue Mobildaten unter Verwendung des zweiten Bereiches und des Head-/Tail-Bereiches gesendet werden.
31 zeigt ein vergrößertes Verhältnis von Mobildaten, die in dem zweiten Bereich beinhaltet sind, im Vergleich zu 29. Es ist ersichtlich, dass ein Abschnitt, der von Mobildaten und bekannten Daten eingenommen wird, in 31 im Vergleich zu 29 zunimmt.
32 zeigt den Stream von 31 in einem verschachtelten Zustand. Wie in 32 gezeigt ist, bilden die bekannten Daten in dem zweiten Bereich eine ähnliche Langtrainingssequenz, dies jedoch dichter als bei den bekannten Daten in dem zweiten Bereich von 30.
33 zeigt eine Streamkonfiguration, bei der Mobildaten und bekannte Daten durch den Gruppenformatierer 130 entsprechend dem dritten Modus bei einem exemplarischen Ausführungsbeispiel platziert werden, bei dem neue Mobildaten unter Verwendung des zweiten Bereiches und des Head-/Tail-Bereiches gesendet werden. 34 zeigt den Stream von 33 in einem verschachtelten Zustand.
Es existiert kein spezielles Merkmal in 33 und 34 mit Ausnahme dessen, dass Mobildaten und bekannte Daten im Vergleich zu Modi 1 und 2 dichter platziert sind, weshalb auf eine Detailbeschreibung verzichtet wird.
35 zeigt eine Streamkonfiguration in dem vierten Modus, die einen gesamten Normaldatenbereich bei einem exemplarischen Ausführungsbeispiel verwendet, bei dem alle von den Paketen, die den Normaldaten zugeteilt sind, und der Paketbereich, der bestehenden Mobildaten zugeteilt ist, entsprechend dem Head-Tail-Bereich verwendet werden.
Wie in 35 gezeigt ist, sind bekannte Daten in dem zweiten Bereich und einem umgebenden Bereich des zweiten Bereiches in einer vertikalen Richtung angeordnet, während der andere Bereich mit neuen Mobildaten gefüllt ist.
36 zeigt den Stream von 35 in einem verschachtelten Zustand. Wie in 36 gezeigt ist, sind der Head-/Tail-Bereich und der gesamte Normaldatenbereich mit neuen Mobildaten und bekannten Daten gefüllt, wobei insbesondere die bekannten Daten in einem Langtrainingssequenzformat angeordnet sind.
Die bekannten Daten werden in diesen Bereichen wiederholt allmählich durch eine Mehrzahl von Musterperioden eingefügt, sodass die bekannten Daten zu verteilten bekannten Daten nach dem Verschachteln werden.
37 ist eine Ansicht zur Erläuterung eines Verfahrens des Einfügens von neuen Mobildaten in dem zweiten Bereich, das heißt Pakete, die Normaldaten zugeteilt sind (beispielsweise 38 Pakete) in verschiedenen Modi.
Zum Zwecke einer einfacheren Erläuterung werden die neuen Mobildaten als ATSC-Mobile-1.1-Daten (oder 1.1-Versionsdaten) bezeichnet, während die bestehenden Mobildaten als ATSC-Mobile-1.0-Daten (oder 1.0-Versionsdaten) nachstehend bezeichnet werden.
Zunächst werden bei a) in dem ersten Modus die 1.1-Versionsdaten in einem Anfangspaket und einem Endpaket platziert, und es werden ein 1.1-Paket und drei Normaldatenpakete wiederholt in die Pakete zwischen dem Anfangspaket und dem Endpaket eingefügt. Entsprechend können insgesamt 11 Pakete zum Senden der 1.1-Versionsdaten, das heißt der neuen Mobildaten gesendet werden.
Als Nächstes werden bei b) in dem zweiten Modus die 1.1-Versionsdaten in dem Anfangspaket und dem Endpaket auf gleiche Weise platziert, und es wird ein 1.1-Paket und ein Normaldatenpaket abwechselnd in die Pakete zwischen dem Anfangspaket und dem Endpaket eingefügt. Entsprechend können 20 Pakete insgesamt zum Senden der 1.1-Versionsdaten, das heißt der neuen Mobildaten, gesendet werden.
Als Nächstes werden bei c) in dem dritten Modus die 1.1-Versionsdaten in dem Anfangspaket und dem Endpaket auf gleiche Weise platziert, und es werden drei 1.1-Pakete und ein Normaldatenpaket wiederholt in die Pakete zwischen dem Anfangspaket und dem Endpaket eingefügt.
Als Nächstes werden bei d) in dem vierten Modus alle von den Paketen entsprechend dem zweiten Bereich zum Senden der 1.1-Versionsdaten verwendet.
Der vierte Modus kann durch einen kompatiblen Modus realisiert sein, in dem nur die Pakete, die dem zweiten Bereich entsprechen, zum Senden der 1.1-Versionsdaten verwendet werden, oder auch durch einen inkompatiblen Modus, in dem nicht nur die Pakete, die dem zweiten Bereich entsprechen, sondern auch der MPEG-Header und der Paritätsbereich mit Bereitstellung für eine Kompatibilität mit einem Normaldatenempfänger mit den 1.1-Versionsdaten gefüllt sind. Der inkompatible Modus kann als separater fünfter Modus bereitgestellt werden.
Die ersten bis vierten Modi können jeweils der Verwendung von 1/4, 2/4, 3/4 und 4/4 der gesamten Pakete des zweiten Bereiches zum Senden der Mobildaten entsprechen. Gleichwohl ist die Gesamtanzahl von Paketen gleich 38, was kein Vielfaches von 4 ist, weshalb ein Paket als Paket zum Senden von neuen Mobildaten oder Normaldaten fixiert ist, während die verbleibenden Pakete entsprechend den vorgenannten Verhältnissen klassifiziert werden, sodass die Modi klassifiziert sind. Dies bedeutet, dass wie unter a), b) und c) vorstehend erläutert worden ist, 36 Pakete, das heißt 38 Pakete minus eine vorbestimmte Anzahl von Paketen, das heißt 2 Pakete, die 1.1-Daten mit dem Verhältnis von 1/4, 2/4 und 3/4 beinhalten können.
38 ist eine Ansicht zur Erläuterung eines Mobildatenplatzierungsmusters in einem anderen Modus.
Wie in 38 gezeigt ist, sind zwei 1.1-Versionsdaten in Zwischenpaketen platziert, die in der Mitte des Streams von allen Paketen in dem zweiten Bereich befindlich sind, das heißt 38 Pakete, und es sind 1.1-Versionsdaten und Normaldaten in den anderen Paketen entsprechend einem Verhältnis gemäß Definition in jedem Modus platziert.
Dies bedeutet, dass bei a) in einem ersten Modus in Bezug auf die Pakete mit Ausnahme der beiden Pakete in dem mittleren Abschnitt drei Normaldatenpakete und ein 1.1-Versionsdatenpaket wiederholt in dem oberen Abschnitt platziert werden, während ein 1.1-Versionsdatenpaket und drei Normaldatenpakete wiederholt in dem unteren Abschnitt platziert werden.
Bei b) in einem zweiten Modus sind in Bezug auf die Pakete mit Ausnahme der beiden Pakete in dem mittleren Abschnitt zwei Normaldatenpakete und zwei 1.1-Versionsdatenpakete wiederholt in dem oberen Abschnitt platziert, während zwei 1.1-Versionsdatenpakete und zwei Normaldatenpakete wiederholt in dem unteren Abschnitt platziert sind.
Bei c) in einem dritten Modus sind in Bezug auf die Pakete mit Ausnahme der zwei Pakete in dem mittleren Abschnitt ein Normaldatenpaket und drei 1.1-Versionsdatenpakete wiederholt in dem oberen Abschnitt platziert, während drei 1.1-Versionsdatenpakete und ein Normaldatenpaket wiederholt in dem unteren Abschnitt platziert sind.
Bei d) in einem vierten Modus werden 1.1-Versionsdaten in allen von den Paketen platziert. Dies ist dasselbe wie in dem vierten Modus von 37.
Zudem zeigt 39 ein exemplarisches Ausführungsbeispiel, in dem 1.1-Versionsdaten aus einem mittleren Paket in oberen und unteren Paketen in einer Sequenz unter Bezugnahme auf eine Stelle in dem Stream platziert sind.
Dies bedeutet, dass bei a) in einem ersten Modus von 39 elf Pakete unter den gesamten Paketen des zweiten Bereiches aus dem mittleren Abschnitt nach oben und nach unten in einer Sequenz bzw. Abfolge platziert sind.
Bei b) in einem zweiten Modus von 39 sind insgesamt 20 Pakete aus dem mittleren Abschnitt nach oben und nach unten in einer Sequenz bzw. Abfolge platziert. Bei c) in einem dritten Modus von 39 sind insgesamt 30 Pakete aus dem mittleren Abschnitt nach oben und nach unten in einer Sequenz bzw. Abfolge platziert. Bei d) in einem vierten Modus von 39 sind sämtliche der Pakete mit 1.1-Versionsdaten gefüllt.
40 zeigt eine Streamkonfiguration entsprechend einem exemplarischen Ausführungsbeispiel, in dem Mobildaten aus oberen und unteren Paketen in einem mittleren Abschnitt in einer Sequenz bzw. Abfolge in einer Reihenfolge entgegengesetzt zu derjenigen von 39 platziert sind. Zudem ist, wie in 40 gezeigt ist, die Anzahl von neuen Mobildatenpaketen in den ersten bis vierten Modi anders als bei denjenigen der vorbeschriebenen Ausführungsbeispiele eingestellt.
Dies bedeutet, dass bei a) in einem ersten Modus von 40 vier 1.1-Versionsdatenpakete aus einem oberen Paket nach unten platziert werden, während vier 1.1-Versionsdatenpakete von einem unteren Paket nach oben platziert werden. Dies bedeutet, dass insgesamt acht 1.1-Versionsdatenpakete platziert werden.
Bei b) in einem zweiten Modus sind acht 1.1-Versionsdatenpakete aus dem oberen Paket nach unten platziert, während acht 1.1-Versionsdatenpakete aus dem unteren Paket nach oben platziert werden. Dies bedeutet, dass sechzehn 1.1-Versionsdatenpakete insgesamt platziert werden.
Bei c) in dem dritten Modus werden zwölf 1.1-Versionsdatenpakete aus dem oberen Paket nach unten platziert, während zwölf 1.1-Versionsdatenpakete aus dem unteren Paket nach oben platziert werden. Dies bedeutet, dass insgesamt 24 1.1-Versionsdatenpakete platziert werden.
Die verbleibenden Pakete sind mit Normaldaten gefüllt. In einem vierten Modus ist das Paketmuster dasselbe wie in 37, 38 und 39 und ist aus 40 weggelassen.
Obwohl ein Muster des Einfügens von bekannten Daten in 37 bis 40 nicht dargestellt ist, können die bekannten Daten in einem beliebigen Bereich desselben Paketes wie derjenige der Mobildaten eingefügt werden oder können in einem Bereich eines separaten Paketes oder einem gesamten Nutzlastbereich eingefügt werden. Das Verfahren zum Einfügen von bekannten Daten ist vorstehend beschrieben worden und aus 37 bis 40 weggelassen.
In einem fünften Modus, das heißt in einem inkompatiblen Modus, werden neue Mobildaten zusätzlich in einem RS-Paritätsbereich und einem Header-Bereich in einem Bereich für bestehende Mobildaten, der nicht der Normaldatenbereich ist, eingefüllt, weshalb der fünfte Modus aus 37 bis 40 weggelassen ist.
Obwohl der vorbeschriebene fünfte Modus ein neuer Modus sein kann, der separat von dem vierten Modus ist, können der vierte Modus oder der fünfte Modus mit den ersten bis dritten Modi kombiniert werden, sodass insgesamt vier Modi realisiert werden können.
In 37 bis 40 ist das Verfahren zum Einfügen von neuen Mobildaten in dem zweiten Bereich, das heißt die Pakete, die Normaldaten zugeteilt sind (beispielsweise 38 Pakete) in verschiedenen Modi beschrieben worden. Das Verfahren zum Platzieren von neuen Mobildaten in den Paketen, die den Normaldaten zugeteilt sind, entsprechend einem vorbestimmten Modus ist entsprechend den ersten bis vierten Modi, wie vorstehend anhand 37 bis 40 beschrieben worden ist, verschieden. Der vierte Modus kann durch einen Modus realisiert sein, in dem nur die 38 Pakete mit neuen Mobildaten gefüllt sind, oder einen Modus, in dem neue Mobildaten in dem RS-Paritätsbereich und dem Header-Bereich zusätzlich zu den 38 Paketen platziert werden. Wie vorstehend beschrieben worden ist, kann zudem der Modus alle von den ersten bis fünften Modi beinhalten.
Wenn ein Modus zum Bestimmen, wie viele Pakete unter den 38 Paketen neuen Mobildaten zugeteilt sind, und wie Blöcke in einer M/H-Gruppe konfiguriert sind, ein skalierbarer Modus ist, werden, a) ein skalierbarer Modus 00, b) ein skalierbarer Modus 01, c) ein skalierbarer Modus 10 und d) ein skalierbarer Modus 11 unter Verwendung eines Signalfeldes von 2 Bit in 37 definiert. Sogar dann, wenn alle von den 38 Paketen den neuen Mobildaten zugeteilt sind, wie dies bei d) von 37 der Fall ist, können 118 Pakete, die ein Bereich für bestehenden Mobildaten sind, und die 38 Pakete, denen die Mobildaten neuzugeteilt werden, eine einzelne M/H-Gruppe bilden.
In diesem Fall sind zwei skalierbare Modi entsprechend dem definiert, wie Blöcke in der M/H-Gruppe konfiguriert sind. Entsprechend dem, ob eine gesamte Sendedatenrate von 19,4 Mbps Mobildaten zugeteilt ist oder nicht, kann eine M/H-Gruppe mit einer anderen Blockkonfiguration sogar dann erzeugt werden, wenn alle 38 Pakete in einem Schlitz den Mobildaten in 37 zugeteilt sind.
Wenn die gesamte Sendedatenrate von 19,4 Mbps den Mobildaten zugeteilt ist, ist die Normaldatenrate gleich 0 Mbps. In diesem Fall beachtet ein Rundfunkbereitsteller einen Normaldatenempfänger nicht und beachtet nur einen Mobildatenempfänger. In diesem Fall ist ein Bereich, in dem ein Platzhalter für den MPEG-Header und die RS-Parität, die aus Gründen der Kompatibilität mit einem bestehenden Normaldatenempfänger bleiben, existiert, als Bereich für Mobildaten definiert, wobei eine Sendekapazität der Mobildaten auf 21,5 Mbps angehoben wird.
Um die gesamte Sendedatenrate von 19,4 Mbps den Mobildaten zuzuteilen, sollten 156 Pakete der M/H-Schlitze zum Konfigurieren des M/H-Frames den Mobildaten zugeteilt werden. Dies bedeutet, dass 16 Schlitze in jedem M/H-Unterframe alle auf einen skalierbaren Modus 11 eingestellt werden. In diesem Fall sind die 38 Pakete, die dem Normaldatenbereich entsprechen, mit den Mobildaten gefüllt, und zusätzlich kann ein SB5-Block entsprechend demjenigen Bereich, in dem der Platzhalter für den MPEG-Header und die RS-Parität des Body-Bereiches existieren, erzeugt werden. Werden die 16 Schlitze des M/H-Unterframes alle auf den skalierbaren Modus 11 eingestellt und wird ein RS-Frame-Modus auf 00 eingestellt (Single-Frame-Modus), so existiert der SB5-Block nicht separat, und es wird der Platzhalter entsprechend SB5 in M/H-Blöcken B4, B5, B6 und B7 absorbiert. Sind die 16 Schlitze des M/H-Unterframes alle auf den skalierbaren Modus 11 eingestellt und ist der RS-Frame-Modus gleich 01 (Dual-Frame-Modus), konfiguriert der Platzhalter, der in SB5 befindlich ist, einen Block SB5. Der Platzhalterbereich für die RS-Parität mit Existenz in dem Head-/Tail-Bereich, der nicht der Body-Bereich ist, ist auch mit den Mobildaten gefüllt, und es wird ??? in einem Block absorbiert, zu dem ein Segment, in dem der Platzhalter für die RS-Parität existiert, gehört. Ein Platzhalter, der in einem entsprechenden Segment von M/H-Blöcken B8 und B9 befindlich ist, ist in SB1 absorbiert. Ein Platzhalter, der in den ersten 14 Segmenten des M/H-Blockes B10 befindlich ist, ist in SB2 absorbiert. Ein Platzhalter, der in den letzten 14 Segmenten des M/H-Blockes B1 des nächsten Schlitzes befindlich ist, ist in SB3 absorbiert. Ein Platzhalter, der in entsprechenden Segmenten der M/H-Blöcke B2 und B3 des nächsten Schlitzes befindlich ist, ist in SB4 absorbiert. Wie in 20 gezeigt ist, existiert, wie vorstehend beschrieben worden ist, kein Bereich für den MPEG-Header und die RS-Parität in dem Gruppenformat nach dem Verschachteln.
Wenn keines von der bestehenden Sendedatenrate von 19,4 Mbps den Mobildaten zugeteilt wird, ist die Normaldatenrate nicht gleich 0 Mbps. In diesem Fall stellt ein Rundfunkbereitsteller Dienste unter Berücksichtigung sowohl eines Normaldatenempfängers wie auch eines Mobildatenempfängers bereit. In diesem Fall werden, um die Kompatibilität mit einem bestehenden Normaldatenempfänger zu erhalten, der MPEG-Header und die RS-Parität nicht als Mobildaten neudefiniert und sollten so, wie sie sind, gesendet werden. Dies bedeutet, dass wie bei dem vorbeschriebenen kompatiblen Modus sogar dann, wenn nur einige der 38 Pakete mit neuen Mobildaten gefüllt sind oder alle der 38 Pakete mit neuen Mobildaten gefüllt sind, der MPEG-Header und die RS-Parität nicht mit neuen Mobildaten gefüllt sind. Entsprechend wird sogar dann, wenn die 38 Pakete, die ein Normaldatenbereich in einem bestimmten Schlitz sind, alle mit Mobildaten gefüllt sind, kein Block SB5 entsprechend einem Bereich, wo der MPEG-Header und die RS-Parität des Body-bereiches existieren, erzeugt.
57 zeigt ein Gruppenformat einer Paketeinheit vor dem Verschachteln unter Berücksichtigung der Kompatibilität, wenn 38 Pakete, die ein Normaldatenbereich sind, alle mit Mobildaten gefüllt sind. Wie bei d) von 37 bis 40 sind alle von den 38 Paketen den Mobildaten zugeteilt, wobei, wie in 56 gezeigt ist, der Bereich, in dem der MPEG-Header und die RS-Parität existieren, in einem Gruppenformat einer Segmenteinheit nach dem Verschachteln erhalten werden, wobei kein SB5-Block-Bereich erzeugt wird. Ein derartiges Gruppenformat kann als Gruppenformat entsprechend dem vierten Modus oder dem skalierbaren Modus 11 definiert werden. Zudem kann der vierte Modus mit Befüllung nur der 38 Pakete mit den neuen Mobildaten unter Berücksichtigung der Kompatibilität als skalierbarer Modus 11a bezeichnet werden.
Wird der skalierbare Modus 11, der ein inkompatibler Modus ist, verwendet, so kann ein Schlitz, der mit neuen Mobildaten in den anderen Modi gefüllt ist, nicht verwendet werden. Dies bedeutet, dass sämtliche Schlitze, das heißt der 0. bis 15. Schlitz mit neuen Mobildaten entsprechend dem skalierbaren Modus 11 gefüllt werden sollte. Demgegenüber können die ersten bis vierten Modi in Kombination verwendet werden.
Wie vorstehend beschrieben worden ist, kann der Normaldatenbereich eines jeden Schlitzes mit den Mobildaten in verschiedenen Formaten gefüllt sein. Entsprechend kann das Format des Schlitzes entsprechend der Einstellbedingung des Frame-Modus und des Modus variieren.
Werden die vier Modi gemäß vorstehender Beschreibung bereitgestellt, so können Schlitze, in denen Mobildaten in den ersten bis vierten Modi platziert sind, als vom ersten Typ seiende Schlitze bis vom vierten Typ seiende Schlitze bezeichnet werden.
Der Digitalrundfunksender kann denselben Typ von Schlitz in jedem Schlitz konfigurieren. Demgegenüber kann der Digitalrundfunksender jedoch einen Stream derart konfigurieren, dass er verschiedene Typen von Schlitzen aufweist, die in der Einheit einer vorbestimmten Anzahl von Schlitzen wiederholt werden.
Dies bedeutet, dass, wie in 41 gezeigt ist, der Datenvorprozessor 100 Mobildaten derart platzieren kann, dass ein vom ersten Typ seiender Schlitz und drei vom Nulltyp seiende Schlitze wiederholt platziert werden. Der vom Nulltyp seiende Schlitz betrifft einen Schlitz, in dem Normaldaten Paketen zugeteilt werden, die Normaldaten zugeteilt sind.
Derartige Typen von Schlitzen können unter Verwendung von bestehenden Signalisierungsdaten, so beispielsweise eines spezifischen Abschnittes eines TPC oder eines FIC definiert werden.
Ist der Frame-Modus, wie vorstehend beschrieben worden ist, auf 1 eingestellt, so kann der Modus auf einen aus der Mehrzahl von Modi, den ersten bis vierten Modi, eingestellt werden. Der vierte Modus kann der skalierbare Modus 11 oder der skalierbare Modus 11a gemäß vorstehender Beschreibung sein. Zudem kann der vierte Modus die skalierbaren Modi 11 und 11a sein und kann einer von den fünf Modi insgesamt sein. Der Modus kann in wenigstens einen kompatiblen Modus und einem inkompatiblen Modus, das heißt einen skalierbaren Modus 11 unterteilt werden.
Wenn der Modus die ersten bis vierten Modi entsprechend einem exemplarischen Ausführungsbeispiel beinhaltet, so können Schlitze entsprechend den Modi als 1-1-, 1-2-, 1-3 und 1-4-Typ-Schlitze bezeichnet werden.
Dies bedeutet, dass der 1-1-Typ-Schlitz einen Schlitz bezeichnet, in dem 38 Pakete in dem ersten Modus zugeteilt sind, der 1-2-Typ-Schlitz einen Schlitz bezeichnet, in dem 38 Pakete in dem zweiten Modus zugeteilt sind, der 1-3-Typ-Schlitz einen Schlitz bezeichnet, in dem 38 Pakete in dem dritten Modus zugeteilt sind, und der 1-4-Typ-Schlitz einen Schlitz bezeichnet, in dem 38 Pakete in dem vierten Modus zugeteilt sind.
42 zeigt Beispiele eines Streams, in dem verschiedene Typen von Schlitzen wiederholt platziert sind.
Beispiel 1 von 42 zeigt einen Stream, in dem der Nulltyp-Schlitz und die 1-1-, 1-2-, 1-3-, und 1-4-Typ-Schlitze in Sequenz bzw. Abfolge wiederholt werden.
Beispiel 2 von 42 zeigt einen Stream, in dem der 1-4-Typ-Schlitz und der Nulltyp-Schlitz abwechselnd wiederholt werden. Wie vorstehend beschrieben worden ist, ist der vierte Modus ein Modus, in dem der gesamte Normaldatenbereich mit Mobildaten gefüllt ist. Daher sind in dem gesamten Normaldatenbereich von Beispiel 2 ein Schlitz, der für Mobildaten verwendet wird, und ein Schlitz, der für Normaldaten verwendet wird, abwechselnd platziert.
Wie bei Beispielen 3, 4 und 5 können verschiedene Typen von Schlitzen wiederholt auf verschiedene Weisen platziert werden. Insbesondere können, wie bei Beispiel 6 die gesamten Schlitze zu einem einzigen Typ zusammengefasst werden, wodurch ein Stream konfiguriert wird.
43 ist eine Ansicht zur Darstellung einer Streamkonfiguration entsprechend Beispiel 2 von 42. Wie in 43 gezeigt ist, wird in dem Nulltyp-Schlitz der Normaldatenbereich für Normaldaten verwendet, wobei in dem vom ersten Typ seienden Schlitz der gesamte Normaldatenbereich für mobile bzw. Mobildaten verwendet wird, während gleichzeitig bekannte Daten in einem Langgrainingssequenzformat platziert werden. Wie vorstehend beschrieben worden ist, können die Typen der Schlitze verschieden realisiert werden.
44 bis 47 zeigen Streamkonfigurationen zur Erläuterung eines Verfahrens zum Zuteilen von Blöcken in Modi 1 bis 4. Wie vorstehend erläutert worden ist, kann jeder von dem ersten Bereich und dem zweiten Bereich in eine Mehrzahl von Blöcken unterteilt werden.
Der Datenvorprozessor 100 kann ein Blockcodieren in einer Einheit eines einzelnen Blockes oder einer Kombination aus einer Mehrzahl von Blöcken entsprechend einem vorbestimmten Blockmodus durchführen.
44 zeigt eine Blockunterteilung in dem ersten Modus. Wie in 44 gezeigt ist, ist der Body-Bereich in Blöcke B3 bis B8 unterteilt, und es ist der Head-/Tail-Bereich in Blöcke BN1 bis BN4 unterteilt.
45 und 46 zeigen eine Blockunterteilung in dem zweiten Modus und dem dritten Modus. Wie in 44 gezeigt ist, ist jeder von dem Body-Bereich und dem Head-/Tail-Bereich in eine Mehrzahl von Blöcken unterteilt.
47 zeigt eine Blockunterteilung in dem vierten Modus, in dem der Head-/Tail-Bereich vollständig mit Mobildaten gefüllt ist. Da der Normaldatenbereich vollständig mit den Mobildaten gefüllt ist, sind der MPEG-Header des Body-Bereiches und die Parität der Normaldaten redundant. Diese Bereiche sind als Block BN5 in 47 definiert. Der Block BN5 ist mit neuen Mobildaten in dem inkompatiblen Modus gefüllt und wird für den Header und die Mehrzahl in dem kompatiblen Modus verwendet. Im Vergleich zu 44 bis 46 zeigt 47 den Head-/Tail-Bereich, der in Blöcke BN1 bis BN5 unterteilt ist.
Wie vorstehend beschrieben worden ist, wandelt der Blockprozessor 120 des Datenvorprozessors 100 ein RS-Frame in einer Einheit eines Blockes um und verarbeitet Blöcke. Dies bedeutet, dass, wie in 7 gezeigt ist, der Blockprozessor 120 den ersten Wandler 121, der Mobildaten in dem RS-Frame entsprechend einem vorbestimmten Blockmodus kombiniert, beinhaltet, wodurch ein SCCC-Block (Serially Concatenated Convolutional Code SCCC, seriell verketteter Faltungscode) ausgegeben wird.
Der Blockmodus kann verschieden eingestellt sein.
Ist beispielsweise der Blockmodus auf 0 eingestellt, so sind die Blöcke BN1, BN2, BN3, BN4 und BN5 als ein einzelner SCCC-Block ausgegeben und dienen als Einheit zur SCCC-Codierung.
Wenn demgegenüber der Blockmodus auf 1 eingestellt ist, werden Blöcke hinzugefügt, wodurch ein SCCC-Block konfiguriert wird. Insbesondere gilt: BN1 + BN3 = SCBN1 und BN2 + BN4 = SCBN2. Der Block BN5 kann solitär zu dem Block SCBN3 werden.
Neben den Mobildaten, die in dem zweiten Bereich platziert sind, können bestehende Mobildaten, die in dem ersten Bereich platziert sind, durch Einbeziehung in einen einzigen Block oder eine Mehrzahl von Blöcken entsprechend dem Blockmodus blockcodiert werden. Dies ist dasselbe wie in dem ATSC-MH-Standard aus dem Stand der Technik, weshalb eine detaillierte Beschreibung hiervon unterbleibt.
Information über den Blockmodus kann auf bestehende Signalisierungsdaten geschrieben oder in einen Bereich einbezogen werden, der in neuen Signalisierungsdaten bereitgestellt wird, und kann dem Empfänger mitgeteilt werden. Der Empfänger identifiziert die Information über den Blockmodus und decodiert die Daten geeignet, wodurch der ursprüngliche Stream wiederhergestellt wird.
Wie vorstehend beschrieben worden ist, können die zur Blockcodierung anstehenden Daten zur Konfigurierung eines RS-Frame kombiniert werden. Dies bedeutet, dass der Frame-Codierer 110 in dem Datenvorprozessor 100 ein RS-Frame durch Kombinieren von Frame-Abschnitten derart erzeugt, dass der Blockprozessor 120 eine Blockcodierung geeignet durchführen kann.
Insbesondere wird ein RS-Frame 0 durch Kombinieren der Blöcke SCBN1 und SCBN2 erzeugt, und es wird ein RS-Frame 1 durch Kombinieren der Blöcke SCBN3 und SCBN4 erzeugt.
Zudem kann der RS-Frame 0 durch Kombinieren der Blöcke SCBN1, SCBN2, SCBN3 und SCBN4 erzeugt werden, und es kann das RS-Frame 1 durch den Block SCBN5 erzeugt werden.
Zudem kann ein einzelnes RS-Frame durch Addieren bzw. Hinzufügen der Blöcke SCBN1, SCBN2, SCBN3, SCBN4 und SCBN5 erzeugt werden.
Zudem kann ein RS-Frame durch Addieren bzw. Hinzufügen von Blöcken entsprechend bestehenden Mobildaten und neu hinzugefügten bzw. addierten Blöcken (SCBN1~SCBN5) erzeugt werden.
48 ist eine Ansicht zur Erläuterung von verschiedenen Verfahren zum Definieren eines Anfangspunktes eines RS-Frames. Wie in 48 gezeigt ist, ist ein Transportstream in eine Mehrzahl von Blöcken unterteilt. In dem ATSC-MH-Standard aus dem Stand der Technik ist ein RS-Frame zwischen den Blöcken BN2 und BN3 identifiziert. Gleichwohl kann, wenn Mobildaten und bekannte Daten in den Normaldatenbereich wie bei der vorliegenden Erfindung eingefügt sind, ein Anfangspunkt des RS-Frames verschieden definiert werden.
So kann beispielsweise das RS-Frame an einer Grenze zwischen den Blöcken BN1 und B8 anfangen, kann an einer Grenze zwischen den Blöcken BN2 und BN3 ähnlich zu einem aktuellen Bezugspunkt anfangen oder kann an einer Grenze zwischen den Blöcken B8 und BN1 anfangen. Der Anfangspunkt des RS-Frames kann verschieden entsprechend einer Kombinationsbedingung der Blockcodierung definiert sein.
Die Konfigurationsinformation des vorbeschriebenen RS-Frames kann in einem Bereich beinhaltet sein, der in bestehenden Signalisierungsdaten oder neuen Signalisierungsdaten bereitgestellt wird, und kann dem Empfänger mitgeteilt werden.
Da neue Mobildaten und bekannte Daten in einem Bereich eingefügt werden, der ursprünglich Normaldaten zugeteilt ist, sowie einem Bereich, der bestehenden Mobildaten, wie vorstehend beschrieben worden ist, zugeteilt ist, wird eine Vielzahl von Informationen zum Mitteilen dieses Umstandes an den Empfänger benötigt. Derartige Information kann unter Verwendung eines reservierten Bits in einem TPC-Bereich entsprechend dem ATSC-MH-Standard aus dem Stand der Technik gesendet werden. Zudem wird ein Signalisierungsdatenbereich erneut erhalten, und es werden neue Signalisierungsdaten unter Verwendung jenes Bereiches gesendet. Da der neu bereitgestellte Signalisierungsbereich an derselben Stelle in jedem Modus bereitgestellt werden sollte, wird der neue Signalisierungsbereich in einem Head-/Tail-Abschnitt platziert.
49 zeigt eine Streamkonfiguration, die eine Platzierungsstelle von bestehenden Signalisierungsdaten und eine Platzierungsstelle von neuen Signalisierungsdaten angibt.
Wie in 49 gezeigt ist, befinden sich die bestehenden Signalisierungsdaten zwischen Langtrainingssequenzen eines Body-Bereiches, während die neuen Signalisierungsdaten in einem Head-/Tail-Bereich befindlich sind. Die neuen Signalisierungsdaten, die von dem Signalisierungscodierer 150 codiert werden, werden an einer vorbestimmten Stelle gemäß Darstellung in 49 durch den Gruppenformatierer 130 eingefügt.
Der Signalisierungscodierer 150 kann die Leistung unter Verwendung eines Codes verbessern, der von demjenigen eines Signalisierungscodierers aus dem Stand der Technik verschieden ist, oder auch mittels Vornehmen einer Codierung mit einer anderen Codierrate.
Dies bedeutet, dass dieselben Daten zweimal unter Verwendung eines 1/8-PCCC-Codes zusätzlich zu dem bestehenden RS-Code oder unter Verwendung eines RS + 1/4-PCCC-Codes derart gesendet werden, dass derselbe Effekt wie bei Verwendung eines 1/8-Raten-PCCC-Codes erhalten werden kann.
Da die bekannten Daten in dem Transportstream gemäß vorstehender Beschreibung beinhaltet sind, sollte ein Speicher in einem Trellis-Codierer initialisiert werden, bevor das Trellis-Codieren für die bekannten Daten durchgeführt wird.
Wird eine Langtrainingssequenz wie in Modus 4 bereitgestellt, so wird es möglich, eine entsprechende Sequenz durch eine einzelne Initialisierung zu verarbeiten, wobei hier kein großes Problem besteht. Wenn jedoch die bekannten Daten diskontinuierlich wie in den anderen Modi platziert werden, besteht ein Problem dahingehend, dass die Initialisierung mehrfach durchgeführt werden muss. Wenn zudem der Speicher derart initialisiert wird, das er einen Wert von 0 aufweist, wird es schwierig, dasselbe Symbol wie in Modus 4 zu erstellen.
Eingedenk dessen wird die Trellis-Rücksetzung nicht vorgenommen, und es kann ein Trellis-Codierer-Speicherwert (das heißt ein Registerwert) in Modus 4 an derselben Stelle in den Trellis-Codierer geladen werden, sodass dasselbe Symbol wie in Modus 4 in Modi 1 bis 3 erstellt werden kann. Um dies zu erreichen, werden Speicherwerte des Trellis-Codierers in Modus 4 aufgezeichnet und in Form einer Tabelle gespeichert, und können derart Trellis-codiert werden, dass sie Werte von verschiedenen Stellen der gespeicherten Tabelle aufweisen. Ebenfalls wird ein separater Trellis-Codierer, der in Modus 4 betreibbar ist, bereitgestellt, und es kann ein Wert, den man von dem Trellis-Codierer erhält, genutzt werden.
Wie vorstehend beschrieben worden ist, können die Mobildaten auf verschiedene Weisen unter Verwendung des Normaldatenbereiches und des Bereiches für bestehende Mobildaten in dem Transportstream aktiv bereitgestellt werden. Entsprechend kann im Vergleich zu dem ATSC-Standard aus dem Stand der Technik die vorliegende Erfindung einen Stream bereitstellen, der zur Sendung der Mobildaten besser geeignet ist.
Signalisierung
Wenn die neuen Mobildaten und die bekannten Daten zu dem Transportstream gemäß vorstehender Beschreibung addiert bzw. hinzugefügt werden, wird eine Technologie zum Mitteilen dieses Umstandes an den Empfänger zum Verarbeiten derartiger Daten benötigt. Das Mitteilen kann auf verschiedene Weisen erfolgen.
Bei einem ersten Verfahren kann das Vorhandensein/Nichtvorhandensein von neuen Mobildaten unter Verwendung einer Datenfeldsynchronisierung mitgeteilt werden, die zur Sendung von bestehenden Mobildaten verwendet wird.
50 ist eine Ansicht zur Darstellung eines Beispieles der Datenfeldsynchronisierungskonfiguration. Wie in 50 gezeigt ist, besteht eine Datenfeldsynchronisierung insgesamt aus 832 Symbolen. 104 von den 832 Symbolen entsprechen einem Reservebereich. Die 83. bis 92. Symbole in dem Reservebereich, das heißt 10 Symbole, entsprechen einem Enhancement- bzw. Förderbereich.
Wenn nur 1.0-Versionsdaten beinhaltet sind, ist das 85. Symbol in einem ungeradzahlig nummerierten Datenfeld auf +5 eingestellt, während die verbleibenden Symbole, das heißt die 83., 84. und 87. bis 92. Symbole auf –5 eingestellt sind. Das geradzahlig nummerierte Datenfeld weist ein entgegengesetztes Symbolvorzeichen im Vergleich zu dem ungeradzahlig nummerierten Datenfeld auf. Dies bedeutet, dass mitgeteilt wird, ob 1.1-Versionsdaten beinhaltet sind oder das 86. Symbol nicht verwendet wird.
Ein weiteres Symbol in dem Enhancement-Bereich kann zum Informieren darüber verwendet werden, ob 1.1-Versionsdaten beinhaltet sind oder nicht. Dies bedeutet, dass durch Einstellen von einem oder einer Mehrzahl von Symbolen mit Ausnahme des 85. Symbols auf +5 oder andere Werte mitgeteilt wird, ob 1.1-Versionsdaten beinhaltet sind oder nicht. So kann beispielsweise das 87. Symbol verwendet werden.
Die Datenfeldsynchronisierung wird durch die Steuerung oder den Signalisierungscodierer von 3 oder einen separat bereitgestellten Feldsynchronisierungsgenerator (nicht gezeigt) erzeugt und wird für den Synchronisierungsmultiplexierer 470 von 4 bereitgestellt und so zu einem Stream durch den Synchronisierungsmultiplexierer 470 multiplexiert.
Bei einem zweiten Verfahren kann das Vorhandensein/Nichtvorhandensein von 1.1-Versionsdaten unter Verwendung eines TPC mitgeteilt werden. Der TPC kann aus Syntaxen gemäß nachstehender Tabelle 1 bestehen.
Tabelle 1
Es ist ein reservierter Bereich in der TPC-Information gemäß Darstellung in Tabelle 1 vorhanden. Entsprechend wird es möglich zu signalisieren, ob Mobildaten in Paketen, die Normaldaten zugeteilt sind, beinhaltet sind, das heißt ein zweiter Bereich, eine Stelle der bekannten Daten, ob neue bekannte Daten hinzugefügt werden oder nicht, und eine Stelle der hinzugefügten neuen Daten unter Verwendung von 1 Bit oder einer Mehrzahl von Bits in dem reservierten Bereich.
Die eingefügte Information kann wie in nachstehender Tabelle 2 ausgedrückt werden.

Notwendiges Feld Bits (veränderbar)

1.1-Frame-Modus 3

1.1-Mobilmodus 2

1.1-SCCC-Blockmodus 2

1.1-SCCCBM1 2

1.1-SCCCBM2 2

1.1-SCCCBM3 2

1.1-SCCCBM4 2

1.1-SCCCBM5 2
In Tabelle 2 bezeichnet der 1.1-Frame-Modus die Information, die angibt, ob Pakete, die Normaldaten zugeteilt sind, für Normaldaten als solche oder für neue Mobildaten, das heißt für 1.1-Versionsdaten verwendet werden.
Der 1.1-Mobilmodus betrifft eine Information, die angibt, in welchem Muster Mobildaten in Paketen, die Normaldaten zugeteilt sind, platziert werden. Einer von den vier Modi, nämlich Modi 1 bis 4, kann gemäß vorstehender Beschreibung durch Markieren von einem der Werte „00”, „01”, „10” und „11” unter Verwendung von 2 Bit ausgedrückt werden. Entsprechend kann der Stream in verschiedenen Formaten wie in 29, 31, 33, 35, 37,38, 39 und 40 angeordnet werden. Der Empfänger identifiziert die Mobilmodusinformation und identifiziert zudem die Platzierungsstelle der Mobildaten.
Der 1.1-SCCC-Blockmodus betrifft eine Information, die einen Blockmodus der 1.1-Versionsdaten angibt. 1.1-SCCCBM1~SCCCBM5 bezeichnen eine Information, die eine Codiereinheit von 1.1-Versionsdaten angibt.
Neben der in Tabelle 2 gezeigten Information kann eine Vielzahl von Informationen, die dem Empfänger erlauben, neue Mobildaten geeignet zu erfassen und die neuen Mobildaten zu decodieren, zusätzlich bereitgestellt werden. Die Anzahl von Bits, die jedem Stück von Information zugeteilt sind, kann je nach Bedarf geändert werden, und es kann eine Stelle eines jeden Feldes in einer anderen Reihenfolge als derjenigen von Tabelle 2 angeordnet werden.
FIC-Information kann für den Digitalrundfunkempfänger verwendet werden, der einen Stream empfängt, der neue Mobildaten beinhaltet, um zu erkennen, ob neue Mobildaten beinhaltet sind oder nicht.
Dies bedeutet, dass ein 1.1-Versionsempfänger, der neue Mobildaten empfängt und verarbeitet, in der Lage sein sollte, 1.0-Dienstinformation und 1.1-Dienstinformation gleichzeitig zu verarbeiten. Demgegenüber sollte ein 1.0-Versionsempfänger in der Lage sein, 1.1-Dienstinformation zu ignorieren.
Entsprechend kann ein Bereich zum Mitteilen des Vorhandenseins/Nichtvorhandenseins von 1.1-Versionsdaten durch Ändern einer bestehenden FIC-Segmentsyntax erhalten werden.
Zunächst kann die Syntax des bestehenden FIC-Segmentes gemäß Darstellung in nachstehender Tabelle 3 konfiguriert sein.
Tabelle 3
Das in Tabelle 3 gezeigte FIC-Segment kann geändert werden, um das Vorhandensein/Nichtvorhandensein von 1.1-Versionsdaten wie in nachstehender Tabelle 4 mitzuteilen.
Tabelle 4
Wie in Tabelle 4 gezeigt ist, können anstatt des reservierten Bereiches FIC_segment_num und FIC_last_segment_num auf 5 Bit erweitert werden.
Gemäß Tabelle 4 wird 01 zu einem Wert von FIC_segment_type addiert, sodass das Vorhandensein/Nichtvorhandensein von 1.1-Versionsdaten mitgeteilt werden kann. Dies bedeutet, dass dann, wenn FIC_segment_type auf 01 eingestellt ist, ein 1.1-Versionsempfänger FIC-Information decodiert und 1.1-Versionsdaten verarbeitet. In diesem Fall ist ein 1.0-Versionsempfänger nicht in der Lage, FIC-Information zu erfassen. Wenn demgegenüber FIC_segment_type als 00 oder Nullsegment definiert ist, decodiert der 1.0-Versionsempfänger die FIC-Information und verarbeitet bestehende Mobildaten.
Das Vorhandensein/Nichtvorhandensein von 1.1-Versionsdaten kann unter Verwendung eines Bereiches einer Syntax eines FIC-Chunks, so beispielsweise eines reservierten Bereiches, mitgeteilt werden, während die Syntax des FIC-Chunks ohne Änderung einer bestehenden FIC-Syntax erhalten bleibt.
Der FIC kann aus 16 Bit bis zum Maximum bestehen, wenn ein FIC-Chunk konfiguriert ist. Der Status der 1.1-Versionsdaten kann durch Ändern von einigen der Syntaxe des FIC-Chunks angegeben werden.
Insbesondere kann „MH-1.1-service_status” zu einem reservierten Bereich einer Dienstensembleschleife, wie in nachstehender Tabelle 5 gezeigt ist, addiert bzw. hinzugefügt werden.
Tabelle 5
Wie in Tabelle 5 gezeigt ist, kann MH1.1_service_status unter Verwendung von 2 von den 3 Bit des reservierten Bereiches angezeigt werden. MH1.1_service_status können Daten sein, die angeben, ob 1.1-Versionsdaten in einem Stream vorhanden sind oder nicht.
Neben MH1.1_service_status kann MH1.1_ensemble_indicator addiert bzw. hinzugefügt werden. Dies bedeutet, dass die Syntax des FIC-Chunks gemäß Darstellung in nachstehender Tabelle 6 konfiguriert sein kann.
Tabelle 6
Wie in Tabelle 6 gezeigt ist, ist 1 Bit von den 3 Bit des ersten reservierten Bereiches MH1.1_ensemble_indicator zugeteilt. MH1.1_ensemble_indicator bezeichnet Information im Zusammenhang mit einem Ensemble, das eine Diensteinheit von 1.1-Versionsdaten ist. Gemäß Tabelle 6 kann MH1.1_service_status_extension unter Verwendung von 2 Bit von den 3 Bit des zweiten reservierten Bereiches angezeigt werden.
Wird die Ensembleprotokollversion geändert und wird der 1.1-Versionsdienst gemäß Darstellung in Tabelle 7 bereitgestellt, so wird eine 1.1-Version unter Verwendung eines Wertes angegeben, der einem 1.0-Reservierungsbereich zugeteilt ist.
Tabelle 7
Gesendet werden können Signalisierungsdaten zudem durch Andern einer Ensembleschleifen-Header-Erweiterungslänge aus den Syntaxfeldern eines FIC-Chunk-Heads, Addieren bzw. Hinzufügen einer Ensemble-Erweiterung aus den Syntaxfeldern einer FIC-Chunk-Nutzlast und Addieren bzuw. Hinzufügen von MH1.1_service_status zu einer Dienstschleife mit 3 Bit unter den Syntaxen der FIC-Chunk-Nutzlast, wie nachstehend in Tabelle 8 gezeigt ist.
Tabelle 8
Zudem kann MH_service_loop_extenion_length aus den Syntaxfeldern des FIC-Chunk-Headers geändert werden, und es kann ein Informationsfeld über MH1.1_service_status zu einem Nutzlastfeld des FIC-Chunks addiert bzw. hinzugefügt werden.
Tabelle 9
Wie vorstehend beschrieben worden ist, können die Signalisierungsdaten für den Empfänger unter Verwendung von verschiedenen Bereichen bereitgestellt werden, so beispielsweise Feldsynchronisierung, TPC-Information und FIC-Information.
Die Signalisierungsdaten können in einem Bereich eingefügt werden, der nicht gleich den vorbeschriebenen Bereichen ist. Dies bedeutet, dass die Signalisierungsdaten in einen Paketnutzlastabschnitt von bestehenden Daten eingefügt werden können. In diesem Fall wird das Vorhandensein von 1.1-Versionsdaten oder eines Ortes zum Identifizieren der Signalisierungsdaten unter Verwendung von FIC-Information gemäß Darstellung in Tabelle 5 aufgezeichnet, und es werden die 1.1-Versionssignalisierungsdaten separat bereitgestellt, sodass ein 1.1-Versionsempfänger entsprechende Signalisierungsdaten erfassen und verwenden kann.
Die Signalisierungsdaten können als separater Stream konfiguriert und an den Empfänger unter Verwendung eines separaten Kanals, der nicht ein Streamsendekanal ist, gesendet werden.
Zudem können die Signalisierungsdaten andere Information zum Signalisieren wenigstens eines Stücks von Information beinhalten, so beispielsweise Information, die angibt, ob bestehende oder neue Mobildaten beinhaltet sind oder nicht, eine Stelle von Mobildaten, Information, die angibt, ob bekannte Daten addiert bzw. hinzugefügt sind oder nicht, eine Stelle von addierten bzw. hinzugefügten bekannten Daten, ein Platzierungsmuster von Mobildaten und bekannten Daten, ein Blockmodus und eine Codiereinheit zusätzlich zu den vorbeschriebenen verschiedenen Informationen.
Der Digitalrundfunksender, der Signalisierungsdaten verwendet, kann einen Datenvorprozessor zum Platzieren von wenigstens einem von Mobildaten und bekannten Daten in wenigstens einem Teil eines Normaldatenbereiches unter allen Paketen eines Streams und einen Multiplexierer zum Erzeugen eines Transportstreams, der Mobildaten und Signalisierungsdaten enthält, beinhalten. Eine Detailkonfiguration des Datenvorprozessors kann entsprechend einem der vorbeschriebenen exemplarischen Ausführungsbeispiele realisiert werden, und es kann ein Element weggelassen, hinzugefügt oder abgewandelt werden. Insbesondere werden die Signalisierungsdaten durch den Signalisierungscodierer, die Steuerung oder den separat bereitgestellten Feldsynchronisierungsgenerator (nicht gezeigt) erzeugt und können in dem Transportstream durch den Multiplexierer oder den Synchronisierungsmultiplexierer eingefügt werden. In diesem Fall können die Signalisierungsdaten als Daten zum Mitteilen wenigstens eines Stücks von Information darüber realisiert werden, ob die Mobildaten platziert sind oder nicht, und eines Platzierungsmusters, so beispielsweise einer Datenfeldsynchronisierung oder TPC- oder FIC-Information gemäß vorstehender Beschreibung.
Wie vorstehend beschrieben worden ist, kann dann, wenn der skalierbare Modus 11a neben dem skalierbaren Modus 11 vorhanden ist, das heißt, wenn die ersten bis fünften Modi vorhanden sind, ein Modusdarstellungsverfahren in den Signalisierungsdaten anders sein.
Entsprechend einem exemplarischen Ausführungsbeispiel kann ein Signalisierungsfeld in einem TPC-Feld den Namen eines skalierbaren Modus aufweisen, und es können vier Modi wie bei a) bis d) von 37 bis 40 als 00, 01, 10 und 11 unter Verwendung von 2 Bit definiert werden. In diesem Falle weist der vierte Modus denselben Bitwert von 11 unabhängig davon auf, ob der vierte Modus ein kompatibler Modus oder ein inkompatibler Modus ist. Gleichwohl werden der MPEG-Header und der Paritätsbereich verwendet oder nicht, und zwar entsprechend den beiden Modi, weshalb ein Gruppenformat entsprechend den beiden Modi verschieden sein kann.
Der Empfänger empfängt einen TPC eines Schlitzes, beinhaltend eine M/H-Gruppe einer M/H-Parade zum Empfangen und einen TPC der anderen Schlitze, wobei dann, wenn der skalierbare Modus von allen der Schlitze gleich 11 ist und kein CMM-Schlitz vorhanden ist, das heißt, wenn eine Normaldatenrate gleich 0 Mbps ist, der Empfänger den Bitwert von 11 als skalierbaren Modus 11 bestimmt und die Daten decodiert.
Wenn demgegenüber der skalierbare Modus von allen der Schlitze ungleich 11 ist oder wenn ein CMM-Schlitz vorhanden ist, also wenn die Normaldatenrate ungleich 0 Mbps ist, bestimmt der Empfänger den Bitwert von 11 als skalierbaren Modus 11a unter Berücksichtigung der Kompatibilität und decodiert die Daten.
Entsprechend einem weiteren exemplarischen Ausführungsbeispiel weist das Signalisierungsfeld in dem TPC-Feld den Namen eines skalierbaren Modus auf, und es können 3 Bit jenem Feld zugeteilt werden. Demzufolge beinhalten insgesamt fünf Gruppenformate drei Gruppenformate entsprechend a) bis c) von 37 bis 40, das heißt die ersten bis dritten Modi, und zwei Gruppenformate entsprechend d) von 37 bis 40, das heißt der vierte Modus und der fünfte Modus.
Dies bedeutet, wie vorstehend beschrieben worden ist, dass der gesamte Modus beinhalten kann:

(1) einen ersten Modus, in dem neue Mobildaten in 11 Paketen unter den 38 Paketen, die Normaldaten zugeteilt sind, platziert sind;
(2) einen zweiten Modus, in dem neue Mobildaten in 20 Paketen unter den 38 Paketen, die Normaldaten zugeteilt sind, platziert sind;
(3) einen dritten Modus, in dem neue Mobildaten in 29 Paketen unter den 38 Paketen, die Normaldaten zugeteilt sind, platziert sind;
(4) einen vierten Modus, in dem neue Mobildaten in allen von den 38 Paketen, die Normaldaten zugeteilt sind, platziert sind; und
(5) einen fünften Modus, in dem neue Mobildaten in allen von den 38 Paketen, die Normaldaten zugeteilt sind, und in einem Bereich entsprechend einem MPEG-Header und einer Parität unter den Bereichen mit Zuteilung an die bestehenden Mobildaten platziert sind.

Der erste Modus ist als skalierbarer Modus 000 definiert, der zweite Modus ist als skalierbarer Modus 001 definiert, der dritte Modus ist als skalierbarer Modus 010 definiert, der vierte Modus, in dem die 38 Pakete mit Mobildaten gefüllt sind und die Kompatibilität berücksichtigt werden sollte, ist als skalierbarer Modus 011 definiert, und der fünfte Modus, in dem die 38 Pakete mit Mobildaten gefüllt sind und eine Betrachtung der Kompatibilität nicht erforderlich ist, ist als skalierbarer Modus 111 definiert.
Zudem kann, um ein zusätzliches Gruppenformat zu definieren, ein Bitwert des skalierbaren Modus zugeteilt werden, oder es kann ein Signalisierungsbit addiert bzw. hinzugefügt werden.
Der Digitalrundfunksender entsprechend verschiedenen exemplarischen Ausführungsbeispielen gemäß vorstehender Beschreibung kann bestehende Mobildaten, neue Mobildaten und Normaldaten in einem Stream auf verschiedene Weisen platzieren und die Daten senden.
Wie in 4 gezeigt ist, addiert bzw. hinzufügt die Streamkonfigurationseinheit, das heißt der Gruppenformatierer 130, der in dem Datenvorprozessor 100 bereitgestellt ist, bekannte Daten, Signalisierungsdaten und Initialisierungsdaten zu einem Stream, der von dem Blockprozessor 120 verarbeitet wird, wodurch die Daten in einer Einheit einer Gruppe formatiert werden.
Wenn entsprechend der Paketformatierer eine Paketformatierung vornimmt, nimmt der Multiplexierer 200 eine Multiplexierung vor. In diesem Fall multiplexiert der Multiplexierer 200 in den ersten bis dritten Modi die Normaldaten, die von dem Normalprozessor 320 verarbeitet worden sind. Demgegenüber gibt in den vierten und fünften Modi der Normalprozessor 320 keine Normaldaten aus, und der Multiplexierer 200 gibt den Stream, der von dem Paketformatierer 140 als solches bereitgestellt wird, aus.
Digitalrundfunksender
Wie vorstehend beschrieben worden ist, kann der Digitalrundfunksender neue Mobildaten unter Verwendung von einigen oder allen der Pakete, die Normaldaten zugeteilt sind, und einigen oder allen der Pakete, die bestehenden Mobildaten zugeteilt sind, in der bestehenden Streamkonfiguration senden.
Der Digitalrundfunkempfänger empfängt wenigstens eines von den bestehenden Mobildaten, den Normaldaten und den neuen Mobildaten entsprechend der jeweiligen Version hiervon.
Dies bedeutet, dass dann, wenn der Digitalrundfunkempfänger dem Verarbeiten von bestehenden Normaldaten dient und den vorbeschriebenen Stream von verschiedenen Konfigurationen empfängt, der Digitalrundfunkempfänger Signalisierungsdaten identifiziert und die Normaldaten erfasst und decodiert. Ist der Stream ohne Normaldaten konfiguriert, so ist der Normaldaten verarbeitende Empfänger nicht in der Lage, einen Normaldatendienst bereitzustellen.
Ist der Empfänger eine 1.0-Version des Digitalrundfunkempfängers und empfängt den vorbeschriebenen Stream mit verschiedenen Konfigurationen, so identifiziert der Empfänger Signalisierungsdaten und erfasst und decodiert die bestehenden Mobildaten. Werden die 1.1-Versionsmobildaten in dem gesamten Bereich platziert, so ist der 1.0-Versionsdigitalrundfunkempfänger nicht in der Lage, einen Mobildienst bereitzustellen.
Ein 1.1-Versionsdigitalrundfunkempfänger ist in der Lage, 1.0-Versionsdaten wie auch 1.1-Versionsdaten zu erfassen und zu verarbeiten. Wenn in diesem Fall ein Decodierblock zum Verarbeiten von Normaldaten beinhaltet ist, kann ein Normaldatendienst unterstützt werden.
51 ist ein Blockdiagramm zur Darstellung eines Beispieles eines Digitalrundfunkempfängers entsprechend einem exemplarischen Ausführungsbeispiel. Der Digitalrundfunkempfänger beinhaltet Elemente entsprechend denjenigen des Digitalrundfunksenders von 2 bis 4 und ist in umgekehrter Reihenfolge angeordnet. Gleichwohl stellt 51 aus Gründen einer einfacheren Beschreibung nur diejenigen Elemente dar, die für den Empfang wesentlich sind.
Dies bedeutet, dass gemäß Darstellung in 51 der Digitalrundfunkempfänger eine Empfangseinheit 5100, einen Demodulierer 5200, einen Ausgleicher bzw. Entzerrer 5300 und eine Decodiereinheit 5400 beinhaltet.
Die Empfangseinheit 5100 empfängt einen Transportstream, der von dem Digitalrundfunksender über eine Antenne oder ein Kabel gesendet wird.
Der Demodulierer 5200 demoduliert den Transportstream, der durch die Empfangseinheit 5100 empfangen wird. Eine Frequenz eines Signals und eines Taktsignals aus dem Empfang durch die Empfangseinheit 5100 werden mit dem Digitalrundfunksender synchronisiert, wenn der Durchlauf durch den Demodulierer 5200 erfolgt.
Der Ausgleicher bzw. Entzerrer 5300 gleicht den demodulierten Transportstream aus bzw. entzerrt diesen.
Der Demodulierer 5200 und der Entzerrer 5300 können eine Synchronisierung und einen Ausgleich bzw. eine Entzerrung rascher unter Verwendung von bekannten Daten, die in dem Transportstream beinhaltet sind, und insbesondere von bekannten Daten, die zusammen mit Mobildaten neu hinzugefügt sind, vornehmen.
Die Decodiereinheit 5400 erfasst Mobildaten aus dem ausgeglichenen bzw. entzerrten Transportstream und decodiert die Mobildaten.
Die Einfügestellen und Größen der Mobildaten und der bekannten Daten können durch Signalisierungsdaten, die in dem Transportstream beinhaltet sind, oder Signalisierungsdaten, die durch einen separaten Kanal empfangen werden, mitgeteilt werden.
Die Decodiereinheit 5400 identifiziert eine Stelle von Mobildaten, die für den Digitalrundfunkempfänger geeignet ist, unter Verwendung der Signalisierungsdaten und erfasst sodann Mobildaten an jeder Stelle und decodiert die Mobildaten.
Die Decodiereinheit 5400 kann auf verschiedene Weisen entsprechend einem exemplarischen Ausführungsbeispiel realisiert werden.
Dies bedeutet, dass die Decodiereinheit 5400 zwei Decodierer beinhalten kann, die einen Trellis-Decodierer (nicht gezeigt) und einen Faltungsdecodierer (nicht gezeigt) beinhalten.
Die beiden Decodierer tauschen Decodierverlässlichkeitsinformation miteinander aus, wodurch die Leistung verbessert wird. Eine Ausgabe aus dem Faltungsdecodierer kann dieselbe wie eine Eingabe des RS-Codierers des Senders sein.
52 ist ein Blockdiagramm zur Detaildarstellung eines Beispieles eines Digitalrundfunkempfängers entsprechend einem exemplarischen Ausführungsbeispiel.
Wie in 52 gezeigt ist, kann der Digitalrundfunkempfänger eine Empfangseinheit 5100, einen Demodulierer 5200, einen Ausgleicher bzw. Entzerrer 5300, eine Decodiereinheit 5400, eine Erfassungseinheit 5500 und einen Signalisierungsdecodierer 5600 beinhalten.
Die Funktionen der Empfangseinheit 5100, des Demodulierers 5200 und des Ausgleichers bzw. Entzerrers 5300 sind dieselben wie diejenigen von 51, weshalb eine Detailbeschreibung hiervon unterbleibt.
Die Decodiereinheit 5400 kann einen ersten Decodierer 5410 und einen zweiten Decodierer 5420 beinhalten.
Der erste Decodierer 5410 nimmt ein Decodieren in Bezug auf wenigstens eines von bestehenden Mobildaten und neuen Mobildaten vor. Der erste Decodierer 5410 kann ein SCCC-Decodieren vornehmen, das in einer Einheit eines Blockes vorgenommen wird.
Der zweite Decodierer 5420 nimmt ein RS-Decodieren in Bezug auf den Stream vor, der durch den ersten Decodierer 5410 decodiert worden ist.
Die ersten und die zweiten Decodierer 5410 und 5420 können Mobildaten unter Verwendung eines Ausgabewertes des Signalisierungsdecodierers 5600 verarbeiten.
Dies bedeutet, dass der Signalisierungsdecodierer 5600 Signalisierungsdaten aus dem Stream erfasst und die Signalisierungsdaten decodiert. Insbesondere demultiplexiert der Signalisierungsdecodierer 5600 einen reservierten Bereich, einen TPC-Informationsbereich oder einen FIC-Informationsbereich von Feldsynchronisierungsdaten aus dem Transportstream. Entsprechend nimmt der Signalisierungsdecodierer 5600 ein Faltungsdecodieren und ein RS-Decodieren in Bezug auf den demultiplexierten Abschnitt vor und nimmt sodann eine Inversverwürflung vor, wodurch Signalisierungsdaten rückgewonnen werden. Die rückgewonnenen Signalisierungsdaten werden für die Elemente des Digitalrundfunkempfängers bereitgestellt, das heißt den Demodulierer 5200, den Ausgleicher bzw. Entzerrer 5300, die Decodiereinheit 5400 und die Erfassungseinheit 5500. Die Signalisierungsdaten können eine Vielzahl von Informationen zur Verwendung durch jene Elemente beinhalten, nämlich Blockmodusinformation, Modusinformation, Information über das Einfügemuster der bekannten Daten und einen Frame-Modus. Typen und Funktionen derartiger Information sind vorstehend beschrieben worden, weshalb eine erneute Detailbeschreibung unterbleibt.
Neben der vorgenannten Information kann eine Vielzahl von Informationen, so beispielsweise eine Codierrate, eine Datenrate, ein Einfügeort von Mobildaten, ein Typ eines zu verwendenden Fehlerberichtigungscodes, Information über einen primären Dienst, Information, die zum Unterstützen eines Zeit-Slicings notwendig ist, eine Beschreibung hinsichtlich Mobildaten, Information im Zusammenhang mit einer Änderung von Modusinformation und Information zur Unterstützung eines IP-Dienstes, für den Empfänger in dem Format von Signalisierungsdaten oder zusätzlichen Daten bereitgestellt werden.
Wie in 52 gezeigt ist, sind die Signalisierungsdaten in dem Stream beinhaltet. Wenn jedoch ein Signalisierungsdatensignal über einen separaten Kanal gesendet wird, decodiert der Signalisierungsdecodierer 5600 das Signalisierungsdatensignal und stellt die vorgenannte Information bereit.
Die Erfassungseinheit 5500 erfasst bekannte Daten aus dem Stream unter Verwendung von Information über das Einfügemuster bekannter Daten, die von dem Singling-Decodierer 5600 bereitgestellt wird. In diesem Fall können bekannte Daten, die zusammen mit bestehenden Mobildaten hinzugefügt werden, wie auch bekannte Daten, die zusammen mit neuen Mobildaten hinzugefügt werden, verarbeitet werden.
Insbesondere können, wie in 22 bis 36 gezeigt ist, die bekannten Daten in wenigstens einem von einem Body-Bereich und einem Head-/Tail-Bereich der Mobildaten an verschiedenen Orten und in verschiedenen Formaten eingefügt werden. Information im Zusammenhang mit einem Einfügemuster von bekannten Daten, das heißt ein Ort, ein Anfangspunkt und eine Länge von bekannten Daten, kann in den Signalisierungsdaten beinhaltet sein. Die Erfassungseinheit 5500 erfasst bekannte Daten an einem geeigneten Ort entsprechend den Signalisierungsdaten und kann die bekannten Daten für den Demodulierer 5200, den Ausgleicher bzw. Entzerrer 5300 und die Decodiereinheit 5400 bereitstellen.
53 ist eine Ansicht zur Darstellung eines Beispieles eines Digitalrundfunkempfängers im Detail entsprechend einem weiteren exemplarischen Ausführungsbeispiel.
Wie in 53 gezeigt ist, beinhaltet der Digitalrundfunkempfänger eine Empfangseinheit 5100, einen Demodulierer 5200, einen Ausgleicher bzw. Entzerrer 5300, einen FEC-Prozessor 5411, eine TCM-Decodiereinheit 5412, eine CV-Entschachtlereinheit 5412, eine äußere Entschachtlereinheit 5414, eine äußere Decodiereinheit 5415, eine RS-Decodiereinheit 5416, einen Inversverwürfler 5417, eine äußere Verschachtlereinheit 5418, eine CV-Verschachtlereinheit 5419 und einen Signalisierungsdecodierer 5600.
Da die Empfangseinheit 5100, der Demodulierer 5200, der Ausgleicher bzw. Entzerrer 5300 und der Signalisierungsdecodierer 5600 vorstehend unter Bezugnahme auf 52 beschrieben worden sind, wird eine doppelte Erläuterung vermieden. Im Gegensatz zu 52 ist die Erfassungseinheit 5500 weggelassen. Dies bedeutet, dass die Elemente bekannte Daten unter Verwendung von Signalisierungsdaten, die von dem Signalisierungsdecodierer 5600 decodiert worden sind, direkt erfassen können.
Der FEC-Prozessor 5411 nimmt eine Vorwärtsfehlerberichtigung in Bezug auf den Transportstream vor, der von dem Ausgleicher bzw. Entzerrer 5300 ausgeglichen bzw. entzerrt worden ist. Der FEC-Prozessor 5411 erfasst bekannte Daten aus dem Transportstream unter Verwendung von Information an einer Stelle oder ein Einfügemuster der bekannten Daten aus der Information, die von dem Signalisierungsdecodierer bereitgestellt wird, und verwendet die bekannten Daten beim Vornehmen der Vorwärtsfehlerberichtigung. Bei einem exemplarischen Ausführungsbeispiel kann ein zusätzliches Bezugssignal bei der Vorwärtsfehlerberichtigung nicht verwendet werden.
Wie in 53 gezeigt ist, sind die Elemente auf eine Weise angeordnet, dass das Decodieren für Mobildaten vorgenommen wird, nachdem die FEC-Verarbeitung vorgenommen worden ist. Dies bedeutet, dass eine FEC-Verarbeitung in Bezug auf den gesamten Transportstream vorgenommen worden ist. Gleichwohl können nur Mobildaten aus dem Transportstream erfasst werden, woraufhin eine FEC-Verarbeiteng nur in Bezug auf die Mobildaten vorgenommen werden kann.
Die TCM-Decodiereinheit 5412 erfasst Mobildaten aus der Transportstreamausgabe des FEC-Prozessors 5411 und nimmt ein Trellis-Decodieren in Bezug auf die Mobildaten vor. Wenn in diesem Fall der FEC-Prozessor Mobildaten bereits erfasst und eine Vorwärtsfehlerberichtigung nur in Bezug auf den erfassten Abschnitt vorgenommen hat, kann die TCM-Decodiereinheit 5412 ein Trellis-Decodieren in Bezug auf die Eingabedaten direkt vornehmen.
Die CV-Entschachtlereinheit 5413 nimmt ein Faltungsentschachteln in Bezug auf die Trellis-decodierten Daten vor. Da, wie vorstehend beschrieben worden ist, die Elemente des Digitalrundfunkempfängers den Elementen des Digitalrundfunksenders entsprechen, der einen Transportstream konfiguriert und verarbeitet, ist die CV-Entschachtlereinheit 5413 gegebenenfalls entsprechend einer Konfiguration des Senders nicht erforderlich.
Die äußere Entschachtlereinheit 5414 nimmt ein äußeres Entschachteln in Bezug auf die faltungsentschachtelten Daten vor. Anschließend nimmt die äußere Decodiereinheit 5415 ein Decodieren vor und entfernt eine Parität aus den Mobildaten.
Bei einer Gegebenheit können die Prozesse von der TCM-Decodiereinheit 5412 bis zu der äußeren Decodiereinheit 5415 ein oder mehrere Male wiederholt werden, sodass die Empfangsleistung der Mobildaten verbessert werden kann. Zum Wiederholen der Prozesse können die Decodierdaten der äußeren Decodiereinheit 5415 für die TCM-Decodiereinheit 5412 durch die äußere Verschachtlereinheit 5418 und die CV-Verschachtlereinheit 5419 als Eingabe der TCM-Decodiereinheit 5412 bereitgestellt werden. Zu diesem Zeitpunkt kann die CV-Verschachtlereinheit 5419 gegebenenfalls entsprechend einer Konfiguration des Senders nicht erforderlich sein.
Wie vorstehend beschrieben worden ist, werden die Trellis-decodierten Daten für die RS-Decodiereinheit 5416 bereitgestellt. Die RS-Decodiereinheit 5416 nimmt eine RS-Decodierung der Daten vor, und der Inversverwürfler 5417 nimmt eine Inversverwürfelung vor. Durch den vorbeschriebenen Prozess können die Mobildaten und insbesondere der Stream von neu definierten 1.1-Versionsdaten verarbeitet werden.
Wie vorstehend beschrieben worden ist, kann dann, wenn der Digitalrundfunkempfänger ein 1.1-Versionsempfänger ist, der Empfänger 1.0-Versionsdaten neben den 1.1-Versionsdaten verarbeiten.
Dies bedeutet, dass wenigstens eines von dem FEC-Prozessor 5411 und der TCM-Decodiereinheit 5412 die gesamten Mobildaten mit Ausnahme der Normaldaten erfassen und die erfassten Daten verarbeiten kann.
Ist der Digitalrundfunkempfänger ein allgemeiner bzw. gemeinsamer Empfänger, so kann der Empfänger einen Block zum Verarbeiten von Normaldaten, einen Block zum Verarbeiten von 1.0-Versionsdaten und einen Block zum Verarbeiten von 1.1-Versionsdaten beinhalten. In diesem Fall ist eine Mehrzahl von Verarbeitungswegen an einem rückwärtigen Ende des Ausgleichers bzw. Entzerrers 5300 vorgesehen, und es sind die vorbeschriebenen Blöcke jeweils in den Verarbeitungswegen platziert. Wenigstens ein Verarbeitungsweg wird entsprechend einem Steuern einer Steuerung (nicht gezeigt) ausgewählt, die separat derart bereitgestellt ist, dass die geeigneten Daten in dem Transportstream beinhaltet sind.
Wie vorstehend beschrieben worden ist, können die Mobildaten in dem Transportstream in einem verschiedenen Muster entsprechend einem Schlitz platziert werden. Dies bedeutet, dass verschiedene Schlitze, so beispielsweise ein Schlitz eines ersten Typs, der Normaldaten als solche beinhaltet, ein Schlitz eines zweiten Typs, der neue Mobildaten in einem gesamten Normaldatenbereich beinhaltet, ein Schlitz eines dritten Typs, der neue Mobildaten in einem Teil des Normaldatenbereiches beinhaltet, und ein Schlitz eines vierten Typs, der neue Mobildaten in einem Normaldatenbereich und einen gesamten bestehenden Mobilbereich beinhaltet, entsprechend einem vorbestimmten Muster wiederholt werden können.
Der Signalisierungsdecodierer 5600 decodiert die Signalisierungsdaten und teilt Frame-Modusinformation oder Modusinformation einem jeden der Elemente mit. Entsprechend erfasst jedes der Elemente und insbesondere der FEC-Prozessor 5411 oder die TCM-Decodiereinheit 5412 Mobildaten an einem definierten Ort eines jeden Schlitzes und verarbeitet die Mobildaten.
51 bis 53 zeigen keine Steuerung. Eine Steuerung zum Anwenden eines geeigneten Steuersignals auf jeden Block unter Verwendung der von dem Signalisierungsdecodierer 5600 decodierten Signalisierungsdaten kann jedoch des Weiteren beinhaltet sein. Eine derartige Steuerung kann einen Abstimmbetrieb der Empfangseinheit 5100 entsprechend der Auswahl eines Anwenders steuern.
Ist der Digitalrundfunkempfänger ein 1.1-Versionsempfänger, so kann der Empfänger 1.0-Versionsdaten oder 1.1-Versionsdaten selektiv entsprechend der Auswahl eines Anwenders bereitstellen. Wenn zudem eine Mehrzahl von 1.1-Versionsdaten bereitgestellt ist, kann der Empfänger einen von den Diensten entsprechend der Auswahl des Nutzers bereitstellen.
Insbesondere kann wie in den ersten bis vierten Modi (wobei die ersten bis vierten Modi ein kompatibler Modus sind und nur der vierte Modus ein inkompatibler Modus sein kann) oder den ersten bis fünften Modi wenigstens eines von Normaldaten, bestehenden Mobildaten und neuen Mobildaten in dem Stream platziert und gesendet werden.
In diesem Fall erfasst der Digitalrundfunkempfänger Daten an einem geeigneten Ort entsprechend einem Modus, setzt ein geeignetes Decodierverfahren ein und nimmt eine Decodierung vor.
Insbesondere bei einem exemplarischen Ausführungsbeispiel, bei dem ein Modus durch 2 Bit dargestellt ist und ein TPC-Signalisierungsfeld, das als 00, 01, 10 und 11 aufgezeichnet ist, wiedergewonnen wird, identifiziert, wenn ein Wert von 11 aus den Signalisierungsdaten identifiziert wird, der Digitalrundfunkempfänger TPCs von allen der Schlitze, die einen Schlitz beinhalten, der eine M/H-Gruppe einer M/H-Parade zum Empfangen beinhaltet. Wenn entsprechend Modusinformation von allen der Schlitze gleich 11 ist und kein CMM-Schlitz vorhanden ist, wird bestimmt, dass der vierte Modus ein inkompatibler Modus ist. Entsprechend kann der Rigitalrundfunkempfänger einen MPEG-Header und einen Paritätsbereich decodieren, worin neue Mobildaten platziert sind, so beispielsweise den vorbeschriebenen SB5-Bereich, und zwar auf dieselbe Weise wie in dem verbleibenden Body-Bereichsstream. Wenn demgegenüber der skalierbare Modus von allen der Schlitze ungleich 11 ist oder wenn ein CMM-Schlitz vorhanden ist, bestimmt der Empfänger, dass ein eingestellter Modus ein kompatibler Modus ist, das heißt der skalierbare Modus 11a, und kann den MPEG-Header und den Paritätsbereich decodieren, das heißt den SB5-Bereich, und zwar auf andere Weise im Vergleich zu dem verbleibenden Body-Bereichsstream, das heißt auf decodierende Weise entsprechend einer Codierungsweise von neuen Mobildaten. Der TPC eines jeden Schlitzes und der Modus können durch den Signalisierungsdecodierer oder eine separat bereitgestellte Steuerung identifiziert werden.
Bei einem exemplarischen Beispiel, bei dem der Modus durch 3 Bit dargestellt wird und Signalisierungsbits, so beispielsweise 000, 001, 010, 011 und 111 gesendet werden, identifiziert der Digitalrundfunkempfänger einen Modus entsprechend einem Bitwert und nimmt eine geeignete Decodierung vor.
Der Digitalrundfunksender kombiniert Normaldaten, bestehenden Mobildaten und neue Mobildaten, wodurch ein Transportstream konfiguriert wird, und sendet den Transportstream.
Entsprechend kann der Digitalrundfunkempfänger, der den Transportstream empfängt und verarbeitet, in verschiedenen Formen realisiert werden. Dies bedeutet, dass der Digitalrundfunkempfänger als Empfänger für Normaldaten zum Verarbeiten nur von Normaldaten, als Empfänger für bestehende Mobildaten zum Verarbeiten nur von bestehenden Mobildaten, als Empfänger für neue Mobildaten zum Verarbeiten nur von neuen Mobildaten und als allgemeiner bzw. gemeinsamer Empfänger zum Verarbeiten von wenigstens zweien von diesen Daten realisiert ist.
Ist der Digitalrundfunkempfänger der Normaldatenempfänger, so sind keine Daten zur Verarbeitung in dem vierten oder fünften Modus ohne Kompatibilität im Gegensatz zu dem ersten bis vierten Modus mit Kompatibilität vorhanden. Entsprechend kann der Digitalrundfunkempfänger einen Transportstream, den er nicht erkennen und verarbeiten kann, ignorieren.
Wenn demgegenüber der Digitalrundfunkempfänger der Empfänger für bestehende Mobildaten oder der allgemeine bzw. gemeinsame Empfänger mit der Fähigkeit zum Verarbeiten von bestehenden Mobildaten und Normaldaten ist, decodiert der Empfänger Normaldaten, die in einem Schlitz, der nur aus Normalpaketen besteht, oder in allen oder einigen der 38 Pakete beinhaltet sind, um die Normaldaten zu verarbeiten, und erfasst bestehende Mobildaten, die in Paketen beinhaltet sind, die nicht die 38 Pakete sind, und decodiert die bestehenden Mobildaten zur Verarbeitung der bestehenden Mobildaten. Insbesondere wenn der Schlitz neue Mobildaten enthält und der Blockmodus ein separater Modus gemäß vorstehender Beschreibung ist, ist ein primärer Ensembleabschnitt mit den bestehenden Mobildaten gefüllt, und ein sekundärer Ensembleabschnitt ist mit den neuen Mobildaten gefüllt, sodass es möglich wird, sowohl die bestehenden Mobildaten wie auch die neuen Mobildaten in einem einzelnen Schlitz zu senden. Wenn entsprechend der Modus ein skalierbarer Modus 11 ist, decodiert der Empfänger einen Body-Bereich mit Ausnahme von SB5 zum Verarbeiten der bestehenden Mobildaten. Wenn demgegenüber der Modus ein skalierbarer Modus 11a ist, so ist SB5 nicht mit neuen Mobildaten gefüllt, weshalb der Empfänger den gesamten Body-Bereich zum Verarbeiten der bestehenden Mobildaten decodiert. Ist der Blockmodus ein Paired-Modus, so ist der gesamte Block nur mit 1.1-Mobildaten gefüllt, weshalb der Empfänger einen entsprechenden Schlitz zum Verarbeiten von bestehenden Mobildaten ignoriert.
Ist der Digitalrundfunkempfänger der Empfänger für neue Mobildaten oder der gemeinsame bzw. allgemeine Empfänger mit der Fähigkeit zum Verarbeiten von neuen Mobildaten und anderen Daten zusammen, so nimmt der Empfänger ein Decodieren entsprechend einem Blockmodus und einem Modus vor. Dies bedeutet, dass dann, wenn der Blockmodus ein separater Modus ist und der Modus ein skalierbarer Modus 11 ist, ein unabhängiger Block des SB5-Bereiches und ein Block mit Zuteilung an die neuen Mobildaten bei einem Decodierverfahren entsprechend einem Codierverfahren der neuen Mobildaten decodiert werden, wobei dann, wenn der Modus ein skalierbarer Modus 11a ist, der Block, der den neuen Mobildaten zugeteilt ist, in einem Decodierverfahren entsprechend einem Codierverfahren der neuen Mobildaten decodiert wird. Wenn demgegenüber der Blockmodus ein Paired-Modus ist, werden alle Blöcke decodiert.
In 51 bis 53 identifiziert die separate Steuerung oder der Signaldecodierer den Blockmodus und den Modus und steuert das Decodieren gemäß vorstehender Beschreibung. Insbesondere wenn 2 Bit der Signalisierungsdaten den Modus angeben und ein Bitwert von 11 gesendet wird, identifiziert die Steuerung oder der Signalisierungsdecodierer TPCs von allen der Schlitze, die einen Schlitz beinhalten, der eine M/H-Gruppe einer zu empfangenden M/H-Parade beinhaltet. Wenn entsprechend festgestellt wird, dass die Normaldatenrate gleich 0 Mbps ist, wird bestimmt, dass der Bitwert von 11 den skalierbaren Modus 11 angibt, und es wird ein Decodieren durchgeführt. Wenn demgegenüber der skalierbare Modus von allen der Schlitze ungleich 11 ist und wenn ein CMM-Schlitz vorhanden ist, das heißt, wenn die Normaldatenrate ungleich 0 Mbps ist, wird bestimmt, dass der Bitwert von 11 den skalierbaren Modus 11a angibt, und es wird ein Decodieren vorgenommen.
Der Digitalrundfunkempfänger von 51 bis 53 kann durch eine Set-Top-Box oder einen Fernseher realisiert sein. Gleichwohl kann der Digitalrundfunkempfänger auch durch verschiedene Typen von tragbaren Geräten realisiert sein, so beispielsweise ein Mobiltelefon, einen Persönlichen Digitalen Assistenten (PDA), ein MP3-Abspielgerät, ein elektronisches Wörterbuch und einen Laptopcomputer. Obwohl dies in 51 bis 53 nicht gezeigt ist, kann zudem ein Element zum geeigneten Skalieren oder Umwandeln von decodierten Daten und Ausgeben der Daten auf einem Schirm in Form von Audio- oder Video-Daten beinhaltet sein.
Ein Verfahren zum Konfigurieren eines Streams eines Digitalrundfunksenders und ein Verfahren zum Verarbeiten eines Streams eines Digitalrundfunkempfängers entsprechend einem exemplarischen Ausführungsbeispiel können unter Bezugnahme auf die vorbeschriebenen Blockdiagramme und Streamkonfigurationsansichten beschrieben werden.
Dies bedeutet, dass das Verfahren zum Konfigurieren des Streams des Digitalrundfunksenders im Allgemeinen ein Platzieren von Mobildaten in wenigstens einigen der Pakete, die Normaldaten zugeteilt sind, unter allen Paketen eines Streams und ein Einfügen von Normaldaten in einem Stream, in dem die Mobildaten platziert sind, wodurch ein Transportstream konfiguriert wird, beinhaltet.
Der Vorgang des Platzierens der Mobildaten kann von dem Datenvorprozessor 100 gemäß Darstellung in 2 bis 4 vorgenommen werden.
Die Mobildaten können an verschiedenen Orten solitär oder zusammen mit den Normaldaten und den bestehenden Mobildaten gemäß Beschreibung bei den vorgenannten exemplarischen Ausführungsbeispielen platziert werden. Dies bedeutet, dass die Mobildaten und die bekannten Daten auf verschiedene Weisen gemäß Erläuterung in 15 bis 40 platziert werden können.
Zudem kann bei dem Vorgang des Konfigurierens des Streams der Transportstream durch Multiplexieren der Normaldaten mit separater Verarbeitung der Mobildaten zusammen mit den Mobildaten konfiguriert werden.
Der Transportstream durchläuft verschiedene Prozesse, so beispielsweise ein RS-Codieren, Verschachteln, Trellis-Codieren, Synchronisierungsmultiplexieren und Modulieren und wird sodann an den Empfänger gesendet. Der Vorgang des Verarbeitens des Transportstreams kann von den Elementen des Digitalrundfunksenders gemäß Darstellung in 4 vorgenommen werden.
Die verschiedenen Ausführungsbeispiele des Verfahrens zum Konfigurieren des Streams sind mit verschiedenen Vorgängen des Digitalrundfunksenders gemäß vorstehender Beschreibung verwandt. Entsprechend wird auf ein Flussdiagramm des Verfahrens zum Konfigurieren des Streams verzichtet.
Beinhalten kann das Verfahren zum Verarbeiten des Streams des Digitalrundfunkempfängers entsprechend einem exemplarischen Ausführungsbeispiel ein Empfangen eines Transportstreams, der in einen ersten Bereich, der bestehenden Mobildaten zugeteilt ist, und einen zweiten Bereich, der Normaldaten zugeteilt ist, unterteilt ist und in dem Mobildaten in wenigstens einem Teil des zweiten Bereiches separat von den bestehenden Mobildaten platziert werden, ein Demodulieren des empfangenen Transportstreams, ein Ausgleichen bzw. Entzerren des demodulierten Transportstreams und ein Decodieren von wenigstens einem von den bestehenden Mobildaten und den Mobildaten aus dem ausgeglichenen bzw. entzerrten Transportstream.
Der Transportstream, der bei diesem Verfahren empfangen wird, kann ein Transportstream sein, der von dem Digitalrundfunksender entsprechend verschiedenen exemplarischen Ausführungsbeispielen konfiguriert wird und von dem Digitalrundfunksender gesendet wird. Dies bedeutet, dass in dem Transportstream die Mobildaten auf verschiedene Weisen gemäß Darstellung in 15 bis 21 sowie in 29 bis 40 platziert werden können. Zudem können die bekannten Daten in verschiedenen Formaten gemäß Darstellung in 22 bis 28 platziert werden.
Die verschiedenen exemplarischen Ausführungsbeispiele des Verfahrens zum Verarbeiten des Streams sind mit den vorbeschriebenen verschiedenen exemplarischen Ausführungsbeispielen des Digitalrundfunkempfängers verwandt. Entsprechend wird auf ein Flussdiagramm des Verfahrens zum Verarbeiten des Streams verzichtet.
Die Konfigurationsbeispiele des Streams gemäß Darstellung in 15 bis 40 sind nicht fixiert und können auf eine andere Konfiguration entsprechend der jeweiligen Situation umgestellt werden. Dies bedeutet, dass die Mobildaten und die bekannten Daten durch Anwenden von verschiedenen Frame-Modi, Modi und Blockmodi entsprechend einem Steuersignal, das von einer separaten Steuerung eingegeben wird, die in dem Datenvorprozessor 100 bereitgestellt ist, oder einem Steuersignal, das aus einer äußeren Quelle eingegeben wird, platziert und blockcodiert werden können. Entsprechend ist ein Digitalrundfunkbereitsteller in der Lage, gewünschte Daten, insbesondere Mobildaten mit verschiedenen Größen bereitzustellen.
Zudem können die vorbeschriebenen neuen Mobildaten, das heißt die 1.1-Versionsdaten dieselben wie die bestehenden Mobildaten sein, das heißt die 1.0-Versionsdaten, oder können auch andere Daten sein, die aus einer anderen Quelle eingegeben werden. Zudem kann eine Mehrzahl von 1.1-Versionsdaten in einem einzelnen Schlitz beinhaltet und zusammen gesendet werden. Entsprechend kann ein Anwender des Digitalrundfunkempfängers Daten in verschiedenen Formaten je nach seinem/ihrem Betrachtungswunsch betrachten.
Blockverarbeitungsverfahren
Die vorbeschriebenen exemplarischen Ausführungsbeispiele können verschieden modifiziert werden.
So kann beispielsweise der Blockprozessor 120 von 4 gemäß vorstehender Beschreibung eine Blockcodierung durch geeignetes Kombinieren von bestehenden Mobildaten, Normaldaten, neuen Mobildaten und bekannten Daten mit Platzierung in einem Stream vornehmen. Die neuen Mobildaten und die bekannten Daten können in nicht nur wenigstens einem Teil des Normaldatenbereiches, der den Normaldaten zugeteilt ist, sondern auch in wenigstens einem Teil eines Bereiches für bestehende Mobildaten, der den bestehenden Mobildaten zugeteilt ist, platziert sein. Dies bedeutet, dass die Normaldaten, die neuen Mobildaten und die bestehenden Mobildaten koexistieren.
54 zeigt ein Beispiel eines Streamformats nach dem Verschachteln. Wie in 54 gezeigt ist, besteht ein Stream, der eine Mobildatengruppe beinhaltet, aus 208 Datensegmenten. Die ersten fünf Datensegmente entsprechen RS-Paritätsdaten und sind daher aus der Mobildatengruppe ausgeschlossen. Entsprechend ist die Mobildatengruppe der 203 Datensegmente in 15 Mobildatenblöcke unterteilt. Insbesondere beinhaltet die Mobildatengruppe Blöcke B1 bis B10 und Blöcke SB1 bis SB5. Unter den Blöcken können die Blöcke B1 bis B10 den Mobildaten entsprechen, die in dem bestehenden Mobildatenbereich gemäß Darstellung in 8 platziert sind. Demgegenüber können die Blöcke SB1 bis SB5 den neuen Mobildaten entsprechen, die dem bestehenden Normaldatenbereich zugeteilt sind. Der Block SB5 beinhaltet einen MPEG-Header und eine RS-Parität aus Gründen der Rückwärtskompatibilität.
Jeder der Blöcke B1 bis B10 besteht aus 16 Segmenten, jeder der Blöcke SB1 und SB4 besteht aus 31 Segmenten, und jeder der Blöcke SB2 und SB3 besteht aus 14 Segmenten
Diese Blöcke, das heißt die Blöcke B1 bis B10 und die Blöcke SB1 bis SB5 werden durch ein Kombinieren in verschiedenen Formaten blockcodiert.

Dies bedeutet, dass, wie vorstehend beschrieben worden ist, der Blockmodus auf verschiedene Werte eingestellt werden kann, so beispielsweise auf 00 und 01. Die nachfolgende Tabelle zeigt SCB-Blöcke und eine SCCC-Ausgabeblocklänge (SCCC Output Block Length SOBL) und eine SCCC-Eingabeblocklänge (SCCC Input Block Length SIBL) eines jeden SCB-Blockes, wenn der Blockmodus auf „00” eingestellt ist. Tabelle 10

SCCC-Block	SOBL	SIBL
SCCC-Block	SOBL	1/2-Rate	1/4-Rate
SCB1 (B1)	528	264	132
SCB2 (B2)	1536	768	384
SCB3 (B3)	2376	1188	594
SCB4 (B4)	2388	1194	597
SCB5 (B5)	2772	1386	693
SCB6 (B6)	2472	1236	618
SCB7 (B7)	2772	1386	693
SCB8 (B8)	2508	1254	627
SCB9 (B9)	1416	708	354
SCB10 (B10)	480	240	120

Wie in Tabelle 10 gezeigt ist, werden die Blöcke B1 bis B10 zu den Blöcken SCB1 bis SCB10.

Ist der Blockmodus auf „01” eingestellt, so sind jeder SCB-Block und eine SOBL und eine SIBL eines jeden SCB-Blockes wie folgt: Tabelle 11

SCCC-Block	SOBL	SBBL
SCCC-Block	SOBL	1/2-Rate	1/4-Rate
SCB1 (B1 + B6)	3000	1500	750
SCB2 (B2 + B7)	4308	2154	1077
SCB3 (B3 + B8)	4884	2442	1221
SCB4 (B4 + B9)	3804	1902	951
SCB5 (B5 + B10)	3252	1626	813

Wie in Tabelle 11 gezeigt ist, werden die Blöcke B1 und B6 zum Konfigurieren des Blockes SCB1 kombiniert, und es werden die Blöcke B2 und B7, die Blöcke B3 und B8, die Blöcke B4 und B9 und die Blöcke B5 und B10 zum Konfigurieren der Blöcke SCB2, SCB3, SCB4 beziehungsweise SCB5 kombiniert. Zudem ist die Eingabeblocklänge in Abhängigkeit davon verschieden, ob eine Datenrate gleich einer 1/2-Rate oder einer 1/4-Rate ist.
Der Vorgang des Konfigurierens des SCB-Blockes durch Kombinieren der Blöcke B1 bis B10 kann vorgenommen werden, wenn keine neuen Mobildaten platziert werden, das heißt in dem CMM-Modus.

In einem SFCMM-Modus, in dem neue Daten platziert werden können, werden die Blöcke verschieden zum Konfigurieren des SCB-Blockes kombiniert. Dies bedeutet, die der SCCC-Blockcodierung durch Kombinieren der bestehenden Mobildaten und der neuen Mobildaten vorgenommen werden kann. In Übereinstimmung mit Tabellen 12 und 13 ist ein Beispiel von Blöcken gezeigt, die entsprechend einem RS-Frame-Modus und einem Schlitzmodus verschieden kombiniert sind.

RS-Frame-Modus	00		01
SCCC-Blockmodus	00	01	00	01
Beschreibung	Separate-SCCC-Blockmodus	Paired-SCCC-Blockmodus	Separate-SCCC-Blockmodus	Paired-SCCC-Blockmodus
SCB	SCB-Eingabe, M/H-Blöcke	SCB-Eingabe, M/H-Blocks	SCB-Eingabe, M/H-Blöcke	SCB-Eingabe, M/H-Blöcke
SCB1	B1	B1 + B6 + SB3	BI	B1 + SB3 + B9 + SB1
SCB2	B2	B2 + B7 + SB4	B2	B2 + SB4 + B10 + SB2
SCB3	B3	B3 + B8	B9 + SB1
SCB4	B4	B4 + B9 + SB1	B10 + SB2
SCB5	B5	B5 + B10 + SB2	SB3
SCB6	B6		SB4
SCB7	B7
SCB8	B8
SCB9	B9 + SB1
SCB10	B10 + SB2
SCB11	SB3
SCB12	SB4

Wie in Tabelle 12 gezeigt ist, bezeichnet der RS-Frame-Modus Information, die angibt, ob ein Schlitz ein Ensemble beinhaltet (für den Fall eines RS-Frame-Modus 00) oder ob ein Schlitz eine Mehrzahl von Ensembles beinhaltet, so beispielsweise ein primäres Ensemble und ein sekundäres Ensemble (für den Fall eines RS-Frame 01). Zudem bezeichnet der SCCC-Blockmodus eine Information, die angibt, ob eine individuelle SCCC-Blockverarbeitung vorgenommen wird oder ob eine SCCC-Blockverarbeitung durch Kombinieren einer Mehrzahl von Blöcken wie bei dem vorbeschriebenen Blockmodus vorgenommen wird.
Tabelle 12 gibt einen Fall an, in dem ein Schlitzmodus gleich 00 ist. Der Schlitzmodus ist Information, die ein Kriterium angibt, auf Grundlage von welchem ein Beginn und ein Ende eines Schlitzes voneinander unterschieden werden. Dies bedeutet, dass dann, wenn der Schlitzmodus gleich 00 ist, ein Abschnitt, der die Blöcke B1 bis B10 und die Blöcke SB1 bis SB5 für denselben Schlitz wie sie in einem Schlitz definiert sind, beinhaltet, und dann, wenn der Schlitzmodus gleich 01 ist, die Blöcke B1 und B2 an einen vorherigen Schlitz gesendet werden, und die Blöcke B1 und B2 eines nachfolgenden Schlitzes in einem aktuellen Schlitz beinhaltet sind, sodass ein Abschnitt, der aus insgesamt 15 Blöcken besteht, als ein Schlitz definiert ist. Der Schlitzmodus kann verschiedene Namen entsprechend der Version eines Standarddokumentes aufweisen. So kann der Schlitzmodus beispielsweise als Blockerweiterungsmodus bezeichnet werden. Dies wird nachstehend beschrieben.
Wie in Tabelle 12 gezeigt ist, werden dann, wenn der RS-Frame-Modus gleich 00 ist und der SCCC-Block-Modus gleich 00 ist, die Blöcke B1 bis B8 als Blöcke SCB1 beziehungsweise SCB8 verwendet, die Blöcke B9 und SB1 werden zum Konfigurieren des Blockes SCB9 kombiniert, die Blöcke B10 und SB2 werden zum Konfigurieren des Blockes SCB10 kombiniert und die Blöcke SB3 und SB4 werden jeweils als Blöcke SCB11 beziehungsweise SCB12 konfiguriert. Wenn demgegenüber der SCCC-Blockmodus gleich 1 ist, werden die Blöcke B1, B6 und SB3 kombiniert und werden als Block SCB1 verwendet, wobei B2 + B7 + SB4 als Block SB2 verwendet wird und wobei B3 + B8, B4 + B9 + SB1 und B5 + B10 + SB2 als Blöcke SCB3, SCB4 beziehungsweise SCB5 verwendet werden.
Wenn demgegenüber das RS-Frame gleich 01 ist und der SCCC-Blockmodus gleich 00 ist, werden die Blöcke B1, B2, B9 + SB1, B10 + SB2, SB3 und SB4 jeweils als Blöcke SCB1 bis SCB6 verwendet. Ist der SCCC-Blockmodus gleich 01, so wird B1 + SB3 + B9 + SB1 als Block SCB1 verwendet, und es wird B2 + SB4 + B10 + SB2 als Block SCB2 verwendet.

Ist der Schlitzmodus gleich 01 und sind die neuen Mobildaten entsprechend den ersten bis dritten Modi entsprechend vorstehender Beschreibung platziert, so kann der SCCC-Block folgendermaßen kombiniert werden. Tabelle 13

RS-Frame-Modus	00		01
SCCC-Blockmodus	00	01	00	01
Beschreibung	Separate-SCCC-Blockmodus	Paired-SCCC-Blockmodus	Separate-SCCC-Blockmodus	Paired-SCCC-Blockmodus
SCB	SCB-Eingabe, M/H-Blöcke	SCB-Eingabe, M/H-Blöcke	SCB-Eingabe, M/H-Blöcke	SCB-Eingabe, M/H-Blöcke
SCB1	B1 + SB3	B1 + B6 + SB3	B1 + SB3	B1 + SB3 + B9 + SB1
SCB2	B2 + SB4	B2 + B7 + SB4	B2 + SB4	B2 + SB4 + B10 + SB2
SCB3	B3	B3 + B8	B9 + SB1
SCB4	B4	B4 + B9 + SB1	B10 + SB2
SCB5	B5	B5 + B10 + SB2
SCB6	B6
SCB7	B7
SCB8	B8
SCB9	B9 + SB1
SCB10	B10 + SB2

Wie in Tabelle 13 gezeigt ist, können die Blöcke B1 bis B10 und die Blöcke SB1 bis SB5 auf verschiedene Weisen entsprechend einer Einstellbedingung kombiniert werden, so beispielsweise einem RS-Frame-Modus und einem SCCC-Blockmodus.

Ist der Schlitzmodus gleich 01 und sind die neuen Mobildaten in einem gesamten Normaldatenbereich entsprechend dem vorbeschriebenen vierten Modus platziert, so können die SCB-Blöcke in verschiedenen Kombinationen folgendermaßen konfiguriert werden. Tabelle 14

RS-Frame-Modus	00		01
SCCC-Blockmodus	00	01	00	01
Beschreibung	Separate-SCCC-Blockmodus	Paired-SCCC-Blockmodus	Separate-SCCC-Blockmodus	Paired-SCCC-Blockmodus
SCB	SCB-Eingabe, M/H-Blöcke	SCB-Eingabe, M/H-Blöcke	SCB-Eingabe, M/H-Blöcke	SCB-Eingabe, M/H-Blöcke
SCB1	B1 + SB3	B1 + B6 + SB3 + SB5	B1 + SB3	B1 + SB3 + B9 + SB1
SCB2	B2 + SB4	B2 + B7 + SB4	B2 + SB4	B2 + SB4 + B10 + SB2
SCB3	B3	B3 + B8	B9 + SB1
SCB4	B4	B4 + B9 + SB1	B10 + SB2
SCB5	B5	B5 + B10 + SB2
SCB6	B6 + SB5
SCB7	B7
SCB8	B8
SCB9	B9 + SB1
SCB10	B10 + SB2

Wie vorstehend beschrieben worden ist, ist jedes von den bestehenden Mobildaten, den Normaldaten und den neuen Mobildaten in Blöcke unterteilt, und die Blöcke werden auf verschiedene Weisen entsprechend einem Modus kombiniert, wodurch ein SCCC-Block konfiguriert wird. Entsprechend werden die SCCC-Blöcke zum Konfigurieren eines RS-Frame kombiniert.
Das Kombinieren und Codieren der Blöcke kann in dem Datenvorprozessor 100 vorgenommen werden, der in den vorbeschriebenen exemplarischen Ausführungsbeispielen dargestellt wird. Insbesondere kombiniert der Blockprozessor 120 in dem Datenvorprozessor 100 die Blöcke und nimmt ein Blockcodieren vor. Die anderen Prozesse mit Ausnahme des Kombinationsverfahrens sind bei den obigen exemplarischen Ausführungsbeispielen beschrieben worden, weshalb eine doppelte Beschreibung unterbleibt.

Eine Codierrate zum Codieren der SCCC-Blöcke, das heißt eine SCCC-Außencoderate kann auf verschiedene Weisen entsprechend einem Außencodemodus bestimmt werden. Insbesondere ist die Codierrate folgendermaßen definiert: Tabelle 15

SCCC-Außencodemodus	Beschreibung
00	Die Außencoderate eines SCCC-Blockes ist eine 1/2-Rate.
01	Die Außencoderate eines SCCC-Blockes ist eine 1/4-Rate.
10	Die Außencoderate eines SCCC-Blockes ist eine 1/3-Rate.
11	reserviert

Wie in Tabelle 15 beschrieben worden ist, kann der SCCC-Außencodemodus auf verschiedene Werte eingestellt sein, so beispielsweise auf 00, 01, 10 und 11. Ist der SCCC-Außencodemodus gleich 00, so wird der SCCC-Block mit einer Codierrate von 1/2 codiert, wenn der SCCC-Außencodeblock gleich 01 ist, so wird der SCCC-Block mit einer Coderate von 1/4 codiert, und wenn der SCCC-Außencodemodus gleich 10 ist, wird der SCCC-Block mit einer Coderate von 1/3 codiert. Die Coderate kann auf verschiedene Weisen entsprechend einer Version eines Standards geändert werden. Eine neu hinzugefügte bzw. addierte Coderate kann dem SCCC-Außencodemodus 11 zugeteilt werden. Eine Abgleichbeziehung zwischen dem SCCC-Außencodemodus und der Coderate kann geändert werden. Der Datenvorprozessor 100 kann den SCCC-Block mit einer geeigneten Coderate entsprechend einer Einstellbedingung des Außencodemodus codieren. Die Einstellbedingung des Außencodemodus kann durch die Steuerung 310 oder ein anderes Element mitgeteilt werden oder kann durch einen separaten Signalisierungskanal identifiziert werden. Die Coderate von 1/3 betrifft eine Rate, bei der 1 Bit eingegeben wird und 3 Bit ausgegeben werden, wobei der Codierer auf verschiedene Weisen konfiguriert wird. So kann der Codierer beispielsweise in Kombination der Codierrate von 1/2 und der Codierrate von 1/4 konfiguriert werden. Der Codierer kann durch Punktieren (puncture) einer Ausgabe eines Vier-Zustands-Faltungscodierers konfiguriert werden.
Blockerweiterungsmodus BEM
Wie vorstehend beschrieben worden ist, werden Blöcke, die in einem Schlitz vorhanden sind, auf verschiedene Weisen entsprechend dem Schlitzmodus oder dem Blockerweiterungsmodus codiert. Ist der Blockerweiterungsmodus gleich 00, so wird ein Abschnitt mit den Blöcken B1 bis B10 und den Blöcken SB1 bis SB5 als Inhalt für denselben Block als ein Schlitz definiert, wie vorstehend beschrieben worden ist, wobei dann, wenn der Blockerweiterungsmodus gleich 01 ist, die Blöcke B1 und B2 an einen vorherigen Schlitz gesendet werden und die Blöcke B1 und B2 eines nachfolgenden Schlitzes in einem aktuellen Schlitz beinhaltet sind, sodass ein Abschnitt, der insgesamt 15 Blöcke beinhaltet, als ein Schlitz definiert ist.
Gruppenbereiche können durch Blöcke in dem Schlitz klassifiziert werden. So sind beispielsweise die vier Blöcke B4 bis B7 zu einem Gruppenbereich A gruppiert, die zwei Blöcke B3 und B8 sind zu einem Gruppenbereich B gruppiert, die zwei Blöcke B2 und B9 sind zu einem Gruppenbereich C gruppiert, und die zwei Blöcke B1 und B10 sind zu einem Gruppenbereich D gruppiert. Die vier Blöcke SB1 bis SB4, die erzeugt werden, wenn die 38 Pakete, die ein Normaldatenbereich sind, verschachtelt werden, können zu einem Gruppenbereich E gruppiert werden.
Wenn ein Blockerweiterungsmodus eines bestimmten Blockes gleich 01 ist, können die Gruppenbereiche A und B, die die Blöcke B3 bis B8 beinhalten, als primäres Ensemble definiert werden. Die Blöcke B1 und B2 werden an einen vorherigen Schlitz gesendet, während die Blöcke B9 und B10, die Blöcke SB1 bis SB4 und die Blöcke B1 und B2 eines nachfolgenden Schlitzes in den Gruppenbereichen C, D und E beinhaltet sind, wobei die Gruppenbereiche C, D und E als ein sekundäres Ensemble definiert werden können. Ähnlich zu dem primären Ensemble ist das sekundäre Ensemble in der Lage, einen Head-/Tail-Bereich mit Langtrainingsdaten einer Länge entsprechend einem Datensegment zu füllen, was das Empfangsleistungsvermögen des Head-/Tail-Bereiches bis zu einem Niveau, das gleichwertig zu demjenigen des Body-Bereiches ist, verbessern kann.
Ist ein Blockerweiterungsmodus eines bestimmten Schlitzes gleich 00, so ist das primäre Ensemble dasselbe wie für den Fall von BEM 01, nur ist das sekundäre Ensemble anders. Das zweite Ensemble kann derart definiert werden, dass die Blöcke B1 und B2 eines aktuellen Schlitzes, die Blöcke B9 und B10 und die Blöcke SB1 bis SB4 beinhaltet sind. Ein derartiges sekundäres Ensemble weist einen sägezahnförmigen Head-/Tail-Bereich im Gegensatz zu dem primären Ensemble auf und ist daher nicht in der Lage, den Head-/Tail-Bereich mit Langtrainingsdaten zu füllen. Daher ist das Leistungsvermögen des Head-/Tail-Bereiches demjenigen des Body-Bereiches unterlegen.
Sind die zwei bestimmten Schlitze benachbart zueinander in dem BEM-00-Modus befindlich, so kann ein Abschnitt, wo der sägezahnförmige Head-/Tail-Bereich der Schlitze schneidet, mit Langtrainingsdaten gefüllt werden. Wie in 64 und 65 gezeigt ist, ist in einem Bereich, in dem die Sägezähne der beiden benachbarten Schlitze des BEM-00-Modus miteinander in Eingriff sind, das segmentierte Training der Schlitze verbunden, sodass ein Langtraining mit einer Länge, die gleichwertig zu einem Datensegment ist, erzeugt werden kann. Wie in 64 und 65 gezeigt ist, werden eine Stelle für ein Trellis-Codierer-Initialisierungsbyte und eine Stelle für ein bekanntes Byte angezeigt.
Ist ein M/H-Frame entsprechend einem Diensttyp konfiguriert, so kann ein Schlitz, der mit neuen Mobildaten gefüllt ist (SFCMM-Schlitz) nahe an einem Schlitz, der mit bestehenden Mobildaten gefüllt ist (SMM-Schlitz) platziert sein, oder ein Schlitz, in dem 156 Pakete nur mit Normaldaten gefüllt sind (Vollhauptschlitz). Wenn zu diesem Zeitpunkt der BEM-Modus des SFCMM-Schlitzes gleich 00 ist, ist eine Kombination auch dann möglich, wenn der CMM-Schlitz oder der Vollhauptschlitz als benachbarter Schlitz platziert wird. Ist ein BEM-00-Schlitz unter den 16 Schlitzen in dem M/H-Unterframe in dem Schlitz #0 platziert und ist ein CMM-Schlitz in dem Schlitz #1 platziert, so wird ein Blockcodieren durch Kombinieren der Blöcke B1 bis B10 und der Blöcke SB1 bis SB4 in dem Schlitz #0 durchgeführt. Auf gleiche Weise wird in dem Schlitz #1 ein Blockcodieren durch Kombinieren der Blöcke B1 bis B10 in dem Schlitz #1 durchgeführt.
Ist der BEM-Modus des SFCMM-Schlitzes gleich 01 und ist der CMM-Schlitz oder der Vollhauptschlitz als benachbarter Schlitz platziert, so kann ein verwaister Bereich (orphan region) betrachtet werden. Der verwaiste Bereich betrifft einen Bereich, der in einem beliebigen Schlitz schwierig zu verwenden ist, da eine Mehrzahl von Schlitzen von verschiedenen Typen kontinuierlich platziert ist.
Wenn beispielsweise der BEM-01-Schlitz unter den 16 Schlitzen in dem M/H-Unterframe in dem Schlitz #0 platziert ist und der CMM-Schlitz in dem Schlitz #1 platziert ist, werden die Blöcke B1 und B2 in dem Schlitz #0 an einen vorherigen Schlitz gesendet und das Blockcodieren wird durch Einbeziehen der Blöcke B3 bis B10 und der Blöcke SB1 bis SB4 und der Blöcke B1 und B2 eines nachfolgenden Schlitzes durchgeführt. Dies bedeutet, dass zwei Schlitze, die mit Mobildaten 1.0 und Mobildaten 1.1 gefüllt sind, die nicht miteinander kompatibel sind, derart verarbeitet werden sollen, dass keine Interferenzen dazwischen durch das Blockcodierverfahren von BEM 01 auftreten.
Der Schlitz des BEM 00 und der Schlitz des BEM 01 können derart eingestellt sein, dass sie nicht kombiniert und zusammen verwendet werden können. Demgegenüber kann für den Fall des BEM-01-Modus des CMM-Modus, des BEM-01-Modus und des Vollhauptmodus Schlitze zur Verwendung kombiniert werden. In diesem Fall kann ein Bereich, der zur Verwendung infolge eines Modusunterschieds schwierig ist, als verwaister Bereich betrachtet werden.
Verwaister Bereich
Der verwaiste Bereich zur Verhinderung einer Interferenz zwischen zwei Schlitzen variiert entsprechend dem Umstand, welcher Schlitz benachbart zu dem Schlitz von BEM 01 ist oder auch entsprechend einer Reihenfolge der benachbarten Schlitze.
Zunächst gilt: Wenn ein (i)-ter Schlitz ein CMM-Schlitz ist und ein (i + 1)-ter Schlitz, der ein nachfolgender Schlitz ist, ein BEM-01-Schlitz ist, so werden die Blöcke B1 und B2 mit Existenz in einem Head-Bereich des BEM-01-Schlitzes an einen vorherigen Schlitz gesendet. Da jedoch der CMM-Schlitz nicht unter Verwendung der Blöcke B1 und B2 des nachfolgenden Schlitzes blockcodiert ist, wird ein Bereich der Blöcke B1 und B2 des (i + 1)-ten Schlitzes nicht einem beliebigen Dienst zugeteilt. Dieser Bereich ist als Waisentyp 1 (orphan type 1) definiert. Auf gleiche Weise gilt: Wenn der (i)-te Schlitz ein Vollhauptschlitz ist und der (i + 1)-te Schlitz, der ein nachfolgender Schlitz ist, ein BEM-01-Schlitz ist, ist ein Bereich der Blöcke B1 und B2 des (i + 1)-ten Schlitzes nicht einem beliebigen Dienst zugeteilt, weshalb der Waisentyp 1 ebenfalls erzeugt wird.
Zweitens gilt: Wenn der (i)-te Schlitz ein BEM-01-Schlitz ist und der (i + 1)-te Schlitz, der ein nachfolgender Schlitz ist, ein CMM-Schlitz ist, nimmt der (i)-te BEM-01-Schlitz eine Blockcodierung unter Verwendung der Blöcke B1 und B2 des nachfolgenden Schlitzes vor, weshalb der nachfolgende Schlitz nicht in der Lage ist, die Blöcke B1 und B2 zu verwenden. Dies bedeutet, dass der CMM-Schlitz, der der nachfolgende Schlitz ist, auf einen Dual-Frame-Modus eingestellt wird und einen Dienst nur einem primären Ensemble zuteilt und ein sekundäres Ensemble leert. Zu diesem Zeitpunkt werden der Block B1 und B2 des zweiten Ensembles, das aus den Blöcken B1 und B2 und den Blöcken B9 und B10 besteht, an den i-ten Schlitz, der der vorherige Schlitz ist, zur Verwendung gesendet, wobei jedoch ein Bereich der Blöcke B9 und B10 nicht einem beliebigen Dienst zugeteilt wird. Der Bereich ist als Waisentyp 2 definiert.
Schließlich gilt: Wenn der (i)-te Schlitz benachbart zu einem BEM-01-Schlitz ist und der (i + 1)-te Schlitz benachbart zu einem Vollhauptschlitz ist, wird der Waisentyp 3 erzeugt. Bringt der BEM-01-Schlitz einen Bereich entsprechend den Blöcken B1 und B2 aus dem Hauptvollschlitz, der ein nachfolgender Schlitz ist, und verwendet den Bereich, so werden Normaldaten nicht an die 32 oberen Pakete gesendet, in denen ein Bereich der Blöcke B1 und B2 unter den 156 nachfolgenden Schlitzen existiert. Dies bedeutet, dass einige der ersten 32 Pakete des nachfolgenden Schlitzes dem Bereich der Blöcke B1 und B2 entsprechen und in dem BEM-01-Schlitz verwendet werden, der der (i)-te Schlitz ist, und die verbleibenden Pakete, die nicht dem Bereich der Blöcke B1 und B2 entsprechen, nicht einem beliebigen Dienst zugeteilt sind. Der verbleibende Bereich, der nicht dem Bereich der Blöcke B1 und B2 unter den ersten 32 Paketen des nachfolgenden Schlitzes entspricht, wird über einen Teil der Gruppenbereiche A und B in einem Gruppenformat nach dem Verschachteln verteilt. Entsprechend wird der Waisentyp 3 in einem Body-Bereich des nachfolgenden Schlitzes erzeugt.
Verfahren zur Verwendung eines Waisen bzw. einer Verwaisung
Der verwaiste Bereich kann neue Mobildaten, Trainingsdaten oder ein Dummybyte beinhalten, was von der Situation abhängt. Ist der verwaiste Bereich mit neuen Mobildaten gefüllt, so können die Existenz von entsprechenden Daten und ein Typ der Daten sowie Signalisierungsinformation, die für den Empfänger zum Erkennen und Decodieren notwendig sind, addiert bzw. hinzugefügt werden.
Ist der verwaiste Bereich mit Trainingsdaten gefüllt, so wird ein Trellis-Codierer entsprechend einer Trainingssequenz zur Erzeugung initialisiert, und es wird ein bekanntes Byte derart definiert, dass der Empfänger die Trainingssequenz erkennen kann.

Tabelle 16 zeigt ein Beispiel eines Ortes eines Waisen bzw. einer Verwaisung, wenn BEM gleich 01 ist, sowie ein Verfahren zu Verwendung hierfür. Tabelle 16

Schlitz(i)	Schlitz(i + 1)	Verlust (Bytes)	Ort des Waisen	Verwendung des Waisen
CMM	BEM = 01	1850	Schlitz(i + 1) Head	Training (141/89)
BEM = 01	CMM	1570	Schlitz(i + 1) Tail	Training (195/141)
Vollhaupt	BEM = 01	1850	Schlitz(i + 1) Head	Training (141/89)
BEM = 01	Vollhaupt	3808	Schlitz(i + 1) Teil von Bereich A und B	Dummy

Ist BEM = 01, so kann der verwaiste Bereich gemäß nachstehender Tabelle 17 erzeugt werden. Tabelle 17

Typ des Waisen	Schlitz(i)	Schlitz(i + 1)	Verlust (Bytes)	Ort des verwaisten Bereiches	Verwendung des Waisen (bekannte Bytes/Initialisierungsbytes)
Typ 1	CMM-Schlitz	SFCMM-Schlitz mit BEM = 01	1618	Schlitz(i + 1) Head	Training (210/252)
Typ 2	SFCMM-Schlitz mit BEM = 01	CMM-Schlitz	1570	Schlitz(i + 1) Tail	Training (195/141)
Typ 1	M/H-Schlitz nur mit Hauptpaketen	SFCMM-Schlitz mit BEM = 01	1618	Schlitz(i + 1) Head	Training (210/252)
Typ 3	SFCMM-Schlitz mit BEM = 01	M/H-Schlitz nur mit Hauptpaketen	3808	Schlitz(i + 1) Teil von Bereichen A und B	Dummy

Wie in vorstehender Tabelle 17 gezeigt ist, kann der verwaiste Bereich an verschiedenen Orten und mit verschiedenen Größen entsprechend den Typen der zwei aufeinanderfolgenden Schlitze gebildet werden. Zudem kann ein derartiger verwaister Bereich für verschiedene Zwecke, so beispielsweise Trainingsdaten oder einen Dummy verwendet werden. Obwohl Tabellen 16 und 17 keinen verwaisten Bereich darstellen, in dem Mobildaten verwendet werden, können auch die Mobildaten in dem verwaisten Bereich verwendet werden.
Wird der verwaiste Bereich verwendet, so kann das Verfahren zum Verarbeiten des Streams des Digitalrundfunksenders beinhalten: ein Konfigurieren eines Streams, in dem eine Mehrzahl von Schlitzen verschiedener Typen, von denen wenigstens einer aus bestehenden Mobildaten, Normaldaten und neuen Mobildaten in einem anderen Format platziert ist, kontinuierlich angeordnet ist; und ein Codieren und Verschachteln des Streams zur Ausgabe als Transportstream. Der Vorgang des Sendens kann durch die Erregereinheit 400 des vorbeschriebenen Digitalrundfunksenders vorgenommen werden.
Der Vorgang des Konfigurierens des Streams kann wenigstens eines von den neuen Mobildaten, Trainingsdaten und Dummy-Daten in einem verwaisten Bereich platzieren, dem Daten infolge eines Formatsunterschieds zwischen den aufeinanderfolgenden Schlitzen nicht zugeteilt sind. Das Verfahren zum Verwenden des verwaisten Bereiches ist vorstehend beschrieben worden.
Der verwaiste Bereich kann von verschiedenen Typen sein, wie vorstehend beschrieben worden ist.
Dies bedeutet, dass dann, wenn ein CMM-Schlitz und ein SFCMM-Schlitz eines Blockerweiterungsmodus 01 in einer Sequenz bzw. Abfolge platziert sind oder wenn ein Vollhauptschlitz, der nur Normaldaten beinhaltet, und ein SFCMM-Schlitz eines Blockerweiterungsmodus 01 in einer Sequenz bzw. Abfolge platziert sind, ein verwaister Bereich von Typ 1 in einem Head-Abschnitt des SFCMM-Schlitzes erzeugt werden kann.
Wenn ein SFCMM-Schlitz eines Blockerweiterungsmodus 01 und ein CMM-Schlitz in einer Sequenz bzw. Abfolge platziert sind, kann ein verwaister Bereich von Typ 2 in einem Tail-Abschnitt des CMM-Schlitzes erzeugt werden.
Wenn ein SFCMM-Schlitz eines Blockerweiterungsmodus 01 und ein Vollhauptschlitz unter Einschluss nur der Normaldaten in einer Sequenz bzw. Abfolge platziert sind, kann ein verwaister Bereich von Typ 3 in einem Body-Abschnitt des Vollhauptschlitzes erzeugt werden.
Wie vorstehend beschrieben worden ist, ist der CMM-Schlitz ein Schlitz, in dem bestehende Mobildaten in einem ersten Bereich platziert werden, der bestehenden Mobildaten zugeteilt ist, und Normaldaten in einem zweiten Bereich, der Normaldaten zugeteilt ist, platziert sind.
Der SFCMM-Schlitz ist ein Schlitz, in dem neue Mobildaten in einem Teil eines gesamten Bereiches einschließlich des ersten Bereiches und des zweiten Bereiches entsprechend einem vordefinierten Modus platziert sind.
58 zeigt eine Streamkonfiguration, die den verwaisten Bereich von Typ 1 nach dem Verschachteln angibt, während 59 eine Streamkonfiguration zeigt, die den verwaisten Bereich von Typ 1 vor dem Verschachteln angibt.
60 zeigt eine Streamkonfiguration, die den verwaisten Bereich von Typ 2 nach dem Verschachteln angibt, während 61 eine Streamkonfiguration zeigt, die den verwaisten Bereich von Typ 2 vor dem Verschachteln angibt.
62 zeigt eine Streamkonfiguration, die den verwaisten Bereich von Typ 3 nach dem Verschachteln angibt, während 63 eine Streamkonfiguration zeigt, die den verwaisten Bereich von Typ 3 vor dem Verschachteln angibt.
Wie in diesen Figuren gezeigt ist, können die Waisen bzw. Verwaisungen an verschiedenen Stellen entsprechend einem Platzierungsmuster des Schlitzes erzeugt werden.
Der Transportstream, der von dem Digitalrundfunksender gesendet wird, wird von dem Digitalrundfunkempfänger empfangen und verarbeitet.
Dies bedeutet, dass der Digitalrundfunkempfänger eine Empfangseinheit zum Empfangen eines Transportstreams beinhaltet, der mit einer Mehrzahl von Schlitzen verschiedener Typen codiert und verschachtelt ist, worin wenigstens eines von bestehenden Mobildaten, Normaldaten und neuen Mobildaten in einem anderen Format mit kontinuierlicher Anordnung platziert ist, einen Demodulierer zum Demodulieren des Transportstreams, einen Ausgleicher bzw. Entzerrer zum Ausgleichen bzw. Entzerren des demodulierten Transportstreams und eine Decodiereinheit zum Decodieren von neuen Mobildaten aus dem ausgeglichenen bzw. entzerrten Stream. Der Transportstream kann einen verwaisten Bereich beinhalten, dem Daten infolge eines Formatsunterschiedes zwischen aufeinanderfolgenden Schlitzen nicht zugeteilt werden, wobei wenigstens eines von den neuen Mobildaten, Trainingsdaten und Dummy-Daten in dem verwaisten Bereich platziert werden kann.
Der Digitalrundfunkempfänger kann nur diejenigen Daten erfassen, die er verarbeiten kann, und zwar entsprechend einem Typ von Digitalrundfunkempfänger, das heißt entsprechend dem, ob der Digitalrundfunkempfänger ein Normaldatenempfänger, ein CMM-spezialisierter Empfänger, ein SFCMM-spezialisierter Empfänger oder ein gemeinsamer bzw. allgemeiner Empfänger ist.
Wie vorstehend beschrieben worden ist, können zudem das Vorhandensein/Nichtvorhandensein von Daten in dem verwaisten Bereich und ein Typ von Daten unter Verwendung von Signalisierungsinformation mitgeteilt werden. Dies bedeutet, dass der Digitalrundfunkempfänger des Weiteren einen Signalisierungsdecodierer zum Decodieren der Signalisierungsinformation beinhalten und das Vorhandensein/Nichtvorhandensein von Daten in einem verwaisten Bereich und einen Typ der Daten identifizieren kann.
Signalisierungsdaten
Information, so beispielsweise die Nummer bzw. Anzahl von hinzugefügten bzw. addierten bestehenden oder neuen Mobildatenpaketen oder die Coderate, können an den Empfänger als Signalisierungsinformation gesendet werden.
So kann beispielsweise eine derartige Signalisierungsinformation unter Verwendung eines reservierten Bereiches eines TPC gesendet werden. In diesem Fall sendet ein bestimmtes Unterframe Information über ein aktuelles Frame, während ein anderes Unterframe Information über ein nächstes Unterframe sendet, sodass eine „Vorabsignalisierung” (signaling in advance) realisiert werden kann.
Dies bedeutet, dass ein vorbestimmter TPC-Parameter und FIC-Daten vorab signalisiert werden können.
Insbesondere kann, wie in 55 gezeigt ist, ein M/H-Frame in fünf Unterframes unterteilt werden. TPS-Parameter, so beispielsweise sub_frame_number, slot_number, parade_id, parade_repetition_cycle_minus_1, parade_continuity_counter, fic_version und der hinzugefügte bzw. addierte Schlitzmodus gemäß vorstehender Beschreibung können Information über ein aktuelles Frame in den fünf Unterframes senden. Zudem können die TPC-Parameter, so beispielsweise SGN, number_of_groups_minus_1, FEC-Modi TNoG, die Anzahl bzw. Nummer von addierten bzw. hinzugefügten bestehenden oder neuen Mobildatenpaketen gemäß vorstehender Beschreibung und eine Codierrate verschieden entsprechend der Anzahl bzw. Nummer des Unterframes aufgezeichnet werden. Dies bedeutet, dass die Unterframes #0 und #1 Information über das aktuelle Frame senden können, während die Unterframes #2, #3 und #4 Information über das nächste Frame eingedenk eines Paradenwiederholungszyklus (Parade Repetition Cycle PRC) senden können. Für den Fall von TNoG senden die Unterframes #0 und #1 nur die Information über das aktuelle Frame, während die Unterframes #2, #3, #4 die Information über das aktuelle Frame und das nächste Frame senden.
Insbesondere kann die TPC-Information gemäß nachstehender Tabelle 18 konfiguriert sein.
Tabelle 18
Wie in Tabelle 18 gezeigt ist, wird, wenn die Anzahl bzw. Nummer des Unterframes kleiner oder gleich 1 ist, das heißt #0 oder #1, eine Vielzahl von Informationen über das aktuelle M/H-Frame gesendet, während dann, wenn die Anzahl bzw. Nummer des Unterframes größer oder gleich 2 ist, das heißt #2, #3 und #4, eine Vielzahl von Information über das nächste M/H-Frame unter Berücksichtigung von PRC gesendet werden kann. Entsprechend kann die Information über das nächste Frame vorab bekannt sein, sodass die Verarbeitungsgeschwindigkeit weiter verbessert werden kann.
Die Konfiguration des Empfängers kann entsprechend der vorbeschriebenen Abwandlung des exemplarischen Ausführungsbeispieles modifiziert sein.
Dies bedeutet, dass der Empfänger die Daten aus der Blockcodierung durch auf verschiedene Weise erfolgendes Kombinieren entsprechend dem Blockmodus decodiert, wodurch die bestehenden Mobildaten, die Normaldaten und die neuen Mobildaten zurückgewonnen werden. Zudem wird die Signalisierungsinformation über das nächste Frame vorab identifiziert, sodass das Verarbeiten entsprechend der identifizierten Information vorbereitet werden kann.
Insbesondere empfängt in dem Digitalrundfunkempfänger, der die in 51 gezeigte Konfiguration aufweist, die Empfangseinheit 5100 einen Stream, der durch Vornehmen einer SCCC-Codierung durch Kombinieren von Daten mit Platzierung in einem Bereich für bestehende Mobildaten und neuen Mobildaten mit Platzierung in einem Normaldatenbereich in einer Einheit eines Blockes empfängt.
Der Stream ist in Frames unterteilt, wobei ein Frame in eine Mehrzahl von Unterframes unterteilt ist. Einige der Unterframes beinhalten Signalisierungsinformation über ein aktuelles Frame, während die anderen Unterframes Signalisierungsinformation über ein nächstes Frame unter Berücksichtigung von PRC beinhalten. Unter den insgesamt fünf Unterframes beinhalten das Unterframe #0 und #1 Information über das aktuelle Frame, während die Unterframes #2, #3 und #4 Information über das nächste Frame unter Berücksichtigung von PRC beinhalten.
Der vorbeschriebene Stream kann ein Stream sein, der durch den Digitalrundfunksender mit einer der Raten von 1/2, 1/3 und 1/4 SCCC-codiert ist.
Wird der vorbeschriebene Stream gesendet, so demoduliert der Demodulierer 5200 den Stream, und der Ausgleicher bzw. Entzerrer 5300 gleicht den demodulierten Stream aus bzw. entzerrt diesen.
Die Decodiereinheit 5400 decodiert wenigstens eines von den bestehenden Mobildaten und den neuen Mobildaten aus dem ausgeglichenen bzw. entzerrten Stream. In diesem Fall kann das Verarbeiten für das nächste Frame vorab unter Verwendung der in jedem Unterframe beinhalteten Frame-Information vorbereitet werden.
Wie vorstehend beschrieben worden ist, kann der Digitalrundfunkempfänger den Stream geeignet verarbeiten, der von dem Digitalrundfunksender entsprechend den verschiedenen exemplarischen Ausführungsbeispielen gesendet worden ist. Das Verfahren zum Verarbeiten des Streams des Digitalrundfunkempfängers ist nicht erläutert und dargestellt.
Die Konfiguration des Empfängers entsprechend verschiedenen exemplarischen Ausführungsbeispielen gemäß vorstehender Definition ist ähnlich zu derjenigen der anderen vorbeschriebenen exemplarischen Ausführungsbeispiele, weshalb eine Darstellung und Erläuterung hiervon unterbleibt.
56 ist eine Ansicht zur Darstellung eines M/H-Gruppenformates, bevor die Daten in dem vorbeschriebenen kompatiblen Modus, das heißt dem skalierbaren Modus 11a verschachtelt werden.
Wie in 56 gezeigt ist, besteht die M/H-Gruppe, die Mobildaten beinhaltet, aus 208 Datensegmenten. Wird die M/H-Gruppe in dem M/H-Schlitz, der in einer Einheit von 156 Paketen konfiguriert ist, über die 156 Pakete verteilt, so werden die 156 Pakete über die 208 Datensegmente als Ergebnis der Verschachtelung entsprechend einer Verschachtelungsregel des Verschachtlers 430 verteilt.
Die Mobildatengruppe der insgesamt 208 Datensegmente ist in 15 Mobildatenblöcke unterteilt. Insbesondere beinhaltet die Mobildatengruppe die Blöcke B1 bis B10 und die Blöcke SB1 bis SB5. Die Blöcke B1 bis B10 können den Mobildaten entsprechen, die in dem Bereich für bestehende Mobildaten, wie in 8 gezeigt ist, platziert sind. Demgegenüber können die Blöcke SB1 bis SB5 den neuen Mobildaten entsprechen, die dem Bereich für bestehende Normaldaten zugeteilt sind. Der Block SB5 ist ein Bereich, der einen MPEG-Header und eine RS-Parität aus Gründen der Rückwärtskompatibilität beinhaltet.
Jeder der Blöcke B1 bis B10 kann aus 16 Segmenten wie der Bereich für bestehende Mobildaten bestehen, und es kann der Block SB4 aus 31 Segmenten bestehen, wobei jeder von den Blöcken SB2 und SB3 aus 14 Segmenten bestehen kann. In dem Block SB1 kann eine Länge der verteilten Segmente entsprechend einem Modus variieren. Werden Normaldaten nicht über alle Frames gesendet, das heißt, ist die gesamte Datenrate von 19,4 Mbps mit Mobildaten gefüllt, so kann der Block SB1 aus 32 Segmenten bestehen. Werden die Normaldaten teilweise gesendet, so kann der Block SB1 aus 31 Segmenten bestehen.
Der Block SB5 ist ein Bereich, in dem ein MPEG-Header und eine RS-Parität mit Existenz in den 51 Segmenten eines Body-Bereiches verteilt sind. Werden die Normaldaten nicht über alle Frames gesendet, das heißt, ist die gesamte Datenrate von 19,4 Mbps mit Mobildaten gefüllt, so kann der Block SB5 als mit Mobildaten gefüllt definiert werden. Dies entspricht dem vorbeschriebenen inkompatiblen Modus. Werden alle Daten als Mobildaten zugeteilt und muss die Kompatibilität daher nicht berücksichtigt werden, so werden der Bereich, in dem der MPEG-Header und die RS-Parität, die aus Gründen der Kompatibilität mit einem bestehenden Normaldatenempfänger existieren, verteilt sind, als Mobildaten neudefiniert.
Wie vorstehend beschrieben worden ist, können diese Blöcke, das heißt die Blöcke B1 bis B10 sowie die Blöcke SB1 bis SB5 durch eine Kombination in verschiedenen Formaten blockcodiert werden.
Dies bedeutet, dass dann, wenn der SCCC-Blockmodus gleich 00 ist (Separate-Block), der SCCC-Außencodemodus verschieden entsprechend den Gruppenbereichen A, B, C und D angewandt werden kann. Wenn demgegenüber der SCCC-Blockmodus gleich 01 ist (Paired-Block), so sollte der SCCC-Außencodemodus aller Bereiche gleich sein. Die Blöcke SB1 und SB4, die neu hinzugefügte bzw. addierte Mobildatenblöcke sind, setzen den SCCC-Außencodemodus, der für den Gruppenbereich C eingestellt ist, ein, und die Blöcke SB2 und SB3 setzen den SCCC-Außencodemodus, der für den Gruppenbereich C eingestellt ist, ein.
Schließlich setzen der Block SB5 den SCCC-Außencodemodus, der für den Gruppenbereich A eingestellt ist, ein.
Insbesondere wird der Block SB5 erzeugt, wenn ein Dienst nur mit Mobildaten durchgeführt wird. In diesem Fall kann unter Berücksichtigung der Kompatibilität zwischen einem Empfänger zum Empfangen von bestehenden Mobildaten und einem Empfänger zum Empfangen von neuen Mobildaten zusätzlich der Block SB5 verschieden codiert werden.
Ist der Blockmodus des Schlitzes, aus dem der Block SB5 erzeugt wird, ein Separate-Modus, so sollte das primäre Ensemble mit 1.0-Mobildaten gefüllt werden, und das sekundäre Ensemble sollte mit 1.1-Mobildaten gefüllt werden, sodass die Kompatibilität mit dem Empfänger zum Empfangen von Mobildaten erhalten bleiben sollte. Entsprechend kann der Block SB5 unabhängig codiert werden.
Ist der Blockmodus des Schlitzes, aus dem der Block SB5 erzeugt wird, ein Paired-Modus, so ist das Frame ein Single-Frame, das nur mit 1.1-Mobildaten gefüllt ist, weshalb die Kompatibilität mit dem Empfänger für bestehende Mobildaten nicht berücksichtigt werden muss. Entsprechend kann der Block SB5 durch Absorption in einem Teil des Body-Bereiches codiert werden.
Insbesondere wenn neue Mobildaten in dem gesamten zweiten Bereich in einem Schlitz wie in dem kompatiblen Modus, das heißt in dem skalierbaren Modus 11, platziert werden, kann der Block SB5 entsprechend einem Blockmodus verschieden codiert werden. Ist der Blockmodus, der für den entsprechenden Schlitz eingestellt ist, ein Separate-Modus, in dem bestehende Mobildaten und neue Mobildaten koexistieren, so kann der Block, der den MPEG-Header und den RS-Paritätsbereich beinhaltet, das heißt der Block SB5, unabhängig von dem Body-Bereich in dem entsprechenden Schlitz codiert werden. Wenn demgegenüber der Blockmodus ein Paired-Modus ist, in dem nur neue Mobildaten existieren, kann der Block, der den MPEG-Header und den RS-Paritätsbereich beinhaltet, das heißt der Block SB5, zusammen mit dem verbleibenden Teil des Body-Bereiches codiert werden. Wie vorstehend beschrieben worden ist, kann das Blockcodieren auf verschiedene Weisen vorgenommen werden.
Entsprechend identifiziert der Digitalrundfunkempfänger, der den Transportstream empfängt, den Modus entsprechend den Signalisierungsdaten und erfasst sodann neue Mobildaten entsprechend dem Modus und reproduziert die neuen Mobildaten. Dies bedeutet, dass dann, wenn der Blockmodus ein Paired-Modus in dem vorbeschriebenen inkompatiblen Modus ist (das heißt der fünfte Modus oder der skalierbare Modus 11) und neue Mobildaten gesendet werden, der Block SB5 gegebenenfalls nicht separat decodiert werden kann und zusammen mit den Mobildaten, die in dem bestehenden Body-Bereich beinhaltet sind, decodiert werden kann.
Wenn zudem bekannte Daten, das heißt eine Trainingssequenz gemäß vorstehender Beschreibung existieren, so sollten die Speicher in dem Trellis-Codierer initialisiert werden, bevor die Trainingssequenz Trellis-codiert wird. In diesem Fall sollte ein Bereich zum Initialisieren des Speichers, das heißt ein Initialisierungsbyte, vor der Trainingssequenz platziert werden.
56 zeigt eine Streamkonfiguration nach dem Verschachteln. Wie in 56 gezeigt ist, erscheint die Trainingssequenz in dem Body-Bereich in dem Format aus einer Mehrzahl von Langtrainingssequenzen und erscheint in dem Head-/Tail-Bereich in Form einer Mehrzahl von Langtrainingssequenzen. Insbesondere erscheinen in dem Head-/Tail-Bereich insgesamt fünf Langtrainingssequenzen. Im Gegensatz zu den ersten und fünften Trainingssequenzen beginnt in den zweiten, dritten und fünften Trainingssequenzen das Trellis-Initialisierungsbyte nicht ab dem ersten Byte eines jeden Segmentes und ist derart eingestellt, dass es nach einem vorbestimmten Byte beginnt.
Eine derartige Bewegung des Ortes des Trellis-Initialisierungsbytes ist nicht auf den Head-/Tail-Bereich beschränkt. Dies bedeutet, dass bei einigen aus der Mehrzahl von Langtrainingssequenzen, die in dem Body-Bereich beinhaltet sind, das Trellis-Initialisierungsbyte derart eingestellt werden kann, dass es nach einem vorbestimmten Byte beginnt.
Größen von PL, SOBL und SIBL entsprechend dem Blockmodus
Die Größen einer RS-Frame-Abschnittslänge (PL), einer SCCC-Ausgabeblocklänge (SOBL) und einer SCCC-Eingabeblocklänge (SIBL) können entsprechend einem Blockmodus verschieden realisiert werden. Die nachfolgende Tabelle gibt PL eines primären RS-Frames an, wenn der RS-Frame-Modus gleich 00 ist (das heißt ein einzelnes Frame), der SCCC-Blockmodus gleich 00 ist (das heißt ein Separate-Block) und der SCCC-Blockerweiterungsmodus gleich 01 ist.

Die nachfolgende Tabelle zeigt PL des primären RS-Frames, wenn der RS-Frame-Modus gleich 00 ist (das heißt ein Single-Frame), der SCCC-Blockmodus gleich 01 ist (das heißt ein Paired-Block) und der SCCC-Blockerweiterungsmodus gleich 01 ist. Tabelle 20

SCCC-Außencodemodus	PL
	skalierbarer Modus 00	skalierbarer Modus 01	skalierbarer Modus 10	skalierbarer Modus 11	skalierbarer Modus 11a
00	10440	11094	11748	13884	12444
10	6960	7396	7832	9256	8296
01	5220	5547	5874	6942	6222
andere	nicht definiert

Die nachfolgende Tabelle gibt PL des sekundären RS-Frames an, wenn der RS-Frame-Modus gleich 01 ist (das heißt Dual-Frame), der SCCC-Blockmodus gleich 00 ist (das heißt Separate-Block) und der SCCC-Blockerweiterungsmodus gleich 01 ist. Tabelle 21

SCCC-Außencodemoduskombinationen			PL
für Bereich C, M/H-Block SB1 und SB4	für Bereich D, M/H-Blöcke SB2 und SB3	für M/H-Block SB5	skalierbarer Modus 00	skalierbarer Modus 01	skalierbarer Modus 10	skalierbarer Modus 11	skalierbarer Modus 11a
00	00	00	2796	3450	4104	6240	4800
00	10	00	2494	3034	3572	5482	4122
00	01	00	2343	2826	3306	5103	3783
10	00	00	2166	2716	3268	5054	3878
10	10	00	1864	2300	2736	4296	3200
10	01	00	1713	2092	2470	3917	2861
01	00	00	1851	2349	2850	4461	3417
01	10	00	1549	1933	2318	3703	2739
01	01	00	1398	1725	2052	3324	2400
00	00	01	2796	3450	4104	6036	4800
00	10	01	2494	3034	3572	5278	4122
00	01	01	2343	2826	3306	4899	3783
10	00	01	2166	2716	3268	4850	3878
10	10	01	1864	2300	2736	4092	3200
10	01	01	1713	2092	2470	3713	2861
01	00	01	1851	2349	2850	4257	3417
01	10	01	1549	1933	2318	3499	2739
01	01	01	1398	1725	2052	3120	2400
andere			nicht definiert	nicht definiert	nicht definiert	nicht definiert	nicht definiert

Zudem gibt die nachfolgende Tabelle SOBL und SIBL an, wenn der SCCC-Blockmodus gleich 00 ist (das heißt Separate-Block), der RS-Frame-Modus gleich 00 ist (das heißt Single-Frame) und der SCCC-Blockerweiterungsmodus gleich 01 ist.
Tabelle 22
Zudem gibt die nachfolgende Tabelle SOBL und SIBL an, wenn der SCCC-Blockmodus gleich 01 ist (das heißt Paired-Block), der RS-Frame-Modus gleich 01 ist (das heißt Dual Frame), und der SCCC-Blockerweiterungsmodus gleich 01 ist.
Tabelle 23
Wie vorstehend beschrieben worden ist, können PL, SOBL und SIBL verschiedene Größen entsprechend dem Blockmodus aufweisen. Die in vorstehenden Tabellen angeführten Daten sind nur Beispiele und sollen nicht als beschränkend betrachtet werden.
Initialisierung
Wie vorstehend beschrieben worden ist, sollte dann, wenn bekannte Daten, das heißt Trainingsdaten in dem Stream beinhaltet sind, eine Initialisierung durchgeführt werden. Dies bedeutet, dass in dem ATSC-M/H-Sende-Empfangssystem der Trellis-Codierer entsprechend einer zu erzeugenden Trainingssequenz initialisiert wird, woraufhin ein bekanntes Byte definiert wird, sodass der Empfänger die Trainingssequenz erkennen kann.
In dem Gruppenformat des BEM-00-Modus wird ein Trellis-Initialisierungsbyte an einer Grenzfläche zwischen Sägezähnen platziert, und es wird ein bekanntes Byte danach verteilt. Wird die Trellis-Codierung in einer Segmentreihenfolge von oben nach unten und in einer Bytereihenfolge von links nach rechts durchgeführt, so wird das Trellis-Codieren an einer Grenzfläche zwischen Sägezähnen mit Füllung mit Daten eines anderen Schlitzes vorgenommen, sodass ein Trellis-Codierer-Speicherwert an einer Grenzfläche zwischen Sägezähnen mit Füllung mit Daten eines nächsten Schlitzes nicht vorausgesagt werden kann. Daher sollte der Trellis-Codierer an jeder Grenzfläche der Sägezähne initialisiert werden. Wie in 56 und 57 gezeigt ist, kann das Initialisierungsbyte an jeder Sägezahngrenze des Head-Bereiches, der die Blöcke B1 und B2 beinhaltet, verteilt werden, und es kann zudem das Initialisierungsbyte an jeder Sägezahngrenze des Tail-Bereiches, der die Blöcke SB1 bis SB4 beinhaltet, verteilt werden.
Sind zwei bestimmte Schlitze in dem BEM-00-Modus benachbart zueinander, so sind Kurztrainingsdaten eines jeden Head-/Tail-Bereiches an demselben Segment platziert und kontinuierlich verbunden, sodass sie als ein Langtraining dienen. Sind die beiden BEM-00-Schlitze benachbart zueinander und sind Trainingsdaten verkettet, so werden nur die ersten maximal 12 Initialisierungsbytes des Segmentes, worin die Trainingsdaten existieren, als Initialisierungsmodus verwendet, und es kann das Initialisierungsbyte, das in einem Bereich existiert, in dem die Sägezähne in Eingriff miteinander sind, wie das bekannte Byte eingegeben und Trellis-codiert werden.
Mit Ausnahme der ersten maximal 12 Initialisierungsbytes des Segmentes können die Zwischeninitialisierungsbytes, die in dem Bereich existieren, in dem die Sägezähne miteinander in Eingriff sind, als bekanntes Byte oder als Initialisierungsbyte entsprechend dem Umstand eingegeben werden, ob der BEM-00-Schlitz benachbart zu demselben Schlitz oder einem anderen Schlitz ist. Dies bedeutet, dass der Vorgang des Trellis-Codierers in dem Normalmodus oder in dem Initialisierungsmodus während des Zwischeninitialisierungsbytes multiplexiert werden kann. Da die Anzahl der erzeugten Symbole entsprechend dem Modus verschieden ist, in dem der Trellis-Codierer eine Eingabe multiplexiert, kann ein Symbolwert zur Verwendung durch den Empfänger verschieden sein. Um die Unordnung beim Empfänger zu minimieren, kann in Bezug auf ein Symbol aus der Erzeugung durch Multiplexieren eines Zwischeninitialisierungsbytes in einem bekannten Byte, wenn ein Langtraining durch zwei benachbarte BEM-00-Schlitze konfiguriert ist, ein Zwischeninitialisierungsbytewert zur Verwendung als Initialisierungsbyte, wenn der BEM-00-Schlitz nicht benachbart zu demselben Schlitz ist, bestimmt werden. Dies bedeutet, dass der Zwischeninitialisierungsbytewert zur Erstellung desselben Wertes wie der Langtrainingssymbolwert aus der Erzeugung, wenn die Schlitze verkettet werden, bestimmt werden kann. Zu diesem Zeitpunkt können die ersten beiden Symbolwerte des Zwischeninitialisierungsbytes von dem Symbolwert aus der Erzeugung, wenn die Schlitze verkettet werden, verschieden sein.
Wie vorstehend beschrieben worden ist, ist das Verfahren zum Verarbeiten des Streams des Digitalrundfunkssenders derart realisiert, dass eine Langtrainingssequenz an einer Grenze zwischen konsekutiven Schlitzen erzeugt werden kann.
Dies bedeutet, dass das Verfahren zum Verarbeiten des Streams des Senders ein Konfigurieren eines Streams, in dem Schlitze, die eine Mehrzahl von Blöcken beinhalten, kontinuierlich platziert sind, sowie ein Codieren und Verschachteln des Streams zur Ausgabe als Transportstream beinhaltet.
Beim Vorgang des Konfigurierens des Streams können dann, wenn Schlitze eines Blockerweiterungsmodus 00, in dem alle der Blöcke in entsprechenden Schlitzen verwendet werden, kontinuierlich platziert sind, bekannte Daten in einem vorbestimmten Segment eines jeden der benachbarten Schlitze platziert werden, sodass eine Langtrainingssequenz an einer Grenze zwischen den benachbarten Schlitzen mit Eingriff ineinander in einer sägezahnförmigen Konfiguration erzeugt wird. Der Blockerweiterungsmodus 00 ist ein Modus, in dem alle der Blöcke, die die Blöcke B1 und B2 beinhalten, in jenem Schlitz verwendet werden. Entsprechend sind eine Grenze eines nächsten Schlitzes, ein Sägezahn des vorherigen Schlitzes und ein Sägezahn des nachfolgenden Schlitzes in Eingriff miteinander. In diesem Fall werden bekannte Daten an einer geeigneten Segmentstelle des vorhergehenden Schlitzes und einer geeigneten Segmentstelle des nachfolgenden Schlitzes platziert, sodass die bekannten Daten miteinander an den Sägezähnen der beiden Schlitze verbunden sind. Insbesondere wenn die bekannten Daten etwa in dem 130. Segment des vorhergehenden Schlitzes und dem 15. Segment des nachfolgenden Schlitzes jeweils platziert sind, sind die bekannten Daten miteinander an der Grenze derart verbunden, dass eine einzige Langtrainingssequenz erzeugt wird.
Wie vorstehend beschrieben worden ist, können dann, wenn erste bekannte Daten mit Platzierung in dem Sägezahn des vorhergehenden Schlitzes der benachbarten Schlitze und zweite bekannte Daten mit Platzierung in dem Sägezahn des nachfolgenden Schlitzes abwechselnd miteinander an der Grenze verbunden werden, ein Wert der ersten bekannten Daten und ein Wert der zweiten bekannten Daten vorbestimmte Werte zur Erzeugung einer Langtrainingssequenz sein, die einem Digitalrundfunkempfänger bekannt ist.
Die bekannten Daten können derart eingefügt werden, dass sie dieselbe Sequenz wie die Langtrainingssequenz aufweisen, die in dem Blockerweiterungsmodus 01 verwendet wird, worin ein bzw. irgendein Block eines entsprechenden Schlitzes für einen anderen Block bereitgestellt wird.
64 zeigt eine Streamkonfiguration vor dem Verschachteln, wenn der Blockerweiterungsmodus gleich 00 ist, während 65 eine Streamkonfiguration nach dem Verschachteln zeigt, wenn der Blockerweiterungsmodus gleich 00 ist.
Wenn die bekannten Daten in dem Format einer Langtrainingssequenz platziert werden, ist eine Initialisierung eines jeden Abschnittes der bekannten Daten nicht erforderlich. Entsprechend kann in diesem Fall das Verfahren eine Initialisierung des Trellis-Codierers, bevor die bekannten Daten entsprechend einem Anfangsabschnitt der Langtrainingssequenz Trellis-codiert werden, beinhalten.
Wenn demgegenüber Schlitze von verschiedenen Blockerweiterungsmodi kontinuierlich platziert werden, so sind bekannte Daten nicht kontinuierlich an der Grenze. Entsprechend kann beim Vorgang des Sendens der Trellis-Codierer initialisiert werden, bevor bekannte Daten mit Platzierung in dem Sägezahnabschnitt an der Grenze der aufeinanderfolgenden Schlitze Trellis-codiert werden.
Sind die bekannten Daten an der Grenze in dem Format der Langtrainingssequenz platziert und werden gemäß vorstehender Beschreibung gesendet, so kann das Verfahren zum Verarbeiten des Streams des Digitalrundfunkempfängers entsprechend verwirklicht werden.
Das heißt, dass das Verfahren zum Verarbeiten des Streams des Digitalrundfunkempfängers beinhaltet: ein Empfangen eines Transportstreams, der mit Schlitzen, die eine Mehrzahl von kontinuierlich platzierten Blöcken beinhalten, codiert und verschachtelt wird, ein Demodulieren des empfangenen Transportstreams, ein Ausgleichen bzw. Entzerren des demodulierten Transportstreams und ein Decodieren von neuen Mobildaten aus dem ausgeglichenen bzw. entzerrten Stream.
Jeder Schlitz des Transportstreams kann wenigstens eines von den Normaldaten, den bestehenden Mobildaten und den neuen Mobildaten beinhalten.
Wenn Schlitze des Blockerweiterungsmodus 00, in dem alle Blöcke in einem entsprechenden Schlitz verwendet werden, kontinuierlich platziert sind, kann der Transportstream bekannte Daten aufweisen, die in einem vorbestimmten Segment eines jeden der benachbarten Schlitze derart platziert sind, dass eine Langtrainingssequenz an einer Grenze zwischen den benachbarten Schlitzen, die miteinander in einer sägezahnförmigen Konfiguration in Eingriff sind, erzeugt wird.
Wie vorstehend beschrieben worden ist, können die bekannten Daten mit Platzierung an der Grenze zwischen dem vorhergehenden Schlitz und dem nachfolgenden Schlitz kontinuierlich miteinander verbunden werden, um eine Langtrainingssequenz zu erzeugen, die dem Digitalrundfunksender und dem Digitalrundfunkempfänger bekannt ist.
Eine derartige Langtrainingssequenz kann dieselbe Sequenz wie die Langtrainingssequenz aufweisen, die in dem Blockerweiterungsmodus 01 verwendet wird, worin ein Block in einem entsprechenden Schlitz für einen anderen Block bereitgestellt ist.
Der Digitalrundfunkempfänger kann daher davon Kenntnis erhalten, ob eine derartige Langtrainingssequenz verwendet wird oder nicht, und zwar durch Identifizieren des Blockerweiterungsmodus jedes Schlitzes.
Dies bedeutet, dass das Verfahren zum Verarbeiten des Streams des Digitalrundfunkempfängers des Weiteren ein Decodieren von Signalisierungsdaten eines jeden Schlitzes und ein Identifizieren eines Blockerweiterungsmodus eines jeden Schlitzes beinhaltet. Insbesondere kann der Blockerweiterungsmodus an einem TPC eines jeden Schlitzes aufgezeichnet werden.
In diesem Fall kann sogar dann, wenn ein Schlitz empfangen worden ist, der Digitalrundfunkempfänger ein Erfassen und Verarbeiten von bekannten Daten, bis ein Blockerweiterungsmodus des nächsten Schlitzes identifiziert ist, aufschieben (defer). Dies bedeutet, dass das Verfahren ein dann, wenn das Decodieren der Signalisierungsdaten des nachfolgenden der benachbarten Schlitze beendet ist und identifiziert wird, dass der Blockerweiterungsmodus des nachfolgenden Schlitzes gleich 00 ist, erfolgendes Erfassen von bekannten Daten des Sägezahnabschnittes an der Grenze der benachbarten Schlitze als Langtrainingssequenz und ein Verarbeiten der bekannten Daten beinhalten.
Entsprechend einem weiteren exemplarischen Ausführungsbeispiel können die Signalisierungsdaten eines jeden Schlitzes zum Vorabmitteilen von Information über die umgebenden Schlitze realisiert werden.
In diesem Fall kann der Digitalrundfunkempfänger die Signalisierungsdaten des vorhergehenden der benachbarten Schlitze decodieren und die Blockerweiterungsmodi des vorherigen Schlitzes und des nachfolgenden Schlitzes identifizieren.
Das Verfahren zum Verarbeiten des Streams des Digitalrundfunksenders und des Digitalrundfunkempfängers kann in dem Digitalrundfunksender und dem Digitalrundfunkempfänger durchgeführt werden, die die verschiedenen in der Zeichnung gezeigten Konfigurationen aufweisen. So kann der Digitalrundfunkempfänger beispielsweise des Weiteren eine Erfassungseinheit zum Erfassen und Verarbeiten von bekannten Daten zusätzlich zu den Basiselementen, so beispielsweise der Empfangseinheit, dem Demodulierer, dem Ausgleicher bzw. Entzerrer und der Decodiereinheit enthalten. Wenn in diesem Fall identifiziert wird, dass zwei Schlitze des Blockerweiterungsmodus 00 empfangen werden, so erfasst die Erfassungseinheit Langtrainingsdaten mit Platzierung an der Grenze der Schlitze und verwendet die Langtrainingsdaten zum Berichtigen eines Fehlers. So kann die Erfassungseinheit ein Ergebnis der Erfassung für wenigstens eines von dem Demodulierer, dem Ausgleicher bzw. Entzerrer und der Decodiereinheit erfassen.
Trainingsdatenstelle unter Berücksichtigung der RS-Parität
Bei Betrachtung eines Segmentes mit einem bereits bestimmten RS-Paritätswert sollte der bereits berechnete RS-Paritätswert geändert werden, wenn Daten des Segmentes während der Trellis-Codierer-Initialisierung geändert werden, sodass der Empfänger nicht auf einen Fehler trifft und normal arbeitet. Für den Fall eines Paketes, in dem ein Trellis-Initialisierungsbyte existiert, gehen 20 Byte einer nichtsystematischen RS-Parität des Paketes nicht dem Trellis-Initialisierungsbyte voran. Das Trellis-Initialisierungsbyte existiert nur an einer Stelle, wo diese Bedingung erfüllt ist, und es können die Trainingsdaten durch ein derartiges Initialisierungsbyte erzeugt werden.
Wie in 64 und 65 gezeigt ist, wird zum Platzieren des Trellis-Informationsbytes vor der RS-Parität die RS-Paritätsstelle verschieden von dem Gruppenformat des BEM-01-Schlitzes geändert. Dies bedeutet, dass in dem Gruppenformat des BEM-01-Schlitzes die RS-Parität in den ersten fünf Segmenten unter den 208 Datensegmenten nach dem Verschachteln platziert ist, wobei für den Fall des BEM-00-Schlitzes die RS-Paritätsstelle derart geändert werden kann, dass ein Abschnitt unter dem Block B2 gefüllt ist, wie in 64 und 65 gezeigt ist.
Unter Berücksichtigung der geänderten RS-Parität sind die Trainingsdaten, die in dem BEM-00-Schlitz verteilt, sind derart platziert, dass die ersten, die zweiten und die dritten Trainings in den 7. und den 8. Segmenten, den 20. und den 21. Segmenten beziehungsweise den 31. und den 32. Segmenten der Blöcke B1 und B2 platziert sind. Zudem können die geänderten RS-Paritäten in den 33. bis 37. Segmenten der Blöcke B1 und B2 angeordnet sein. Zudem können in dem Tail-Bereich die ersten, die zweiten, die dritten, die vierten und die fünften Trainings in den 134. und 135. Segmenten, den 150. und den 151. Segmenten, den 163. und den 164. Segmenten, den 176. und 177. Segmenten beziehungsweise den 187. und 188. Segmenten platziert sein. Sind die beiden BEM-00-Schlitze benachbart zueinander und erzeugen ein verkettetes Langtraining, so werden das erste Training der Blöcke B1 und B2 und das dritte Training des Tail-Bereiches miteinander verbunden, es werden das zweite Training der Blöcke B1 und B2 und das vierte Training des Tail-Bereiches miteinander verbunden, und es werden das dritte Training der Blöcke B1 und B2 und das fünfte Training des Tail-Bereiches miteinander verbunden.
Wie vorstehend beschrieben worden ist, werden die Trainingsdaten auf verschiedene Weisen platziert, und es wird die Initialisierung hiervon entsprechend ausgeführt.
Der Digitalrundfunkempfänger erfasst die Trainingsdaten an der Stelle, wo die Trainingsdaten platziert sind. Insbesondere kann die Erfassungseinheit oder der Signalisierungsdecodierer von 52 Information erfassen, die die Stelle der Trainingsdaten angibt. Entsprechend werden die Trainingsdaten an der identifizierten Stelle erfasst, und es kann ein Fehler berichtigt werden.
Die vorbeschriebenen exemplarischen Ausführungsbeispiele und Vorteile sind rein exemplarisch und sollen nicht im Sinne einer Beschränkung des vorliegenden erfinderischen Konzeptes verstanden werden. Die exemplarischen Ausführungsbeispiele können ohne Weiteres auf andere Typen von Geräten übertragen werden. Die Beschreibung der exemplarischen Ausführungsbeispiele soll zudem illustrativ sein und den Umfang der Ansprüche nicht beschränken, sodass sich einem Fachmann auf dem einschlägigen Gebiet vielerlei Alternativen, Abwandlungen und Variationen erschließen.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

KR 2011/003566 [0001]

Claims

Verfahren zum Verarbeiten eines Streams eines Digitalrundfunksenders, wobei das Verfahren umfasst: Konfigurieren eines Streams, in dem Schlitze, die eine Mehrzahl von Blöcken umfassen, kontinuierlich platziert sind; und Codieren und Verschachteln des Streams und Senden des Streams als Transportstream, wobei das Konfigurieren des Streams ein dann, wenn Schlitze eines Blockerweiterungsmodus 00 kontinuierlich platziert sind, erfolgendes Verbinden von bekannten Daten, die an vorbestimmten Stellen von benachbarten Schlitzen platziert sind, miteinander zum Erzeugen einer Langtrainingssequenz umfasst.
Verfahren nach Anspruch 1, wobei erste bekannte Daten, die in einem Sägezahnabschnitt eines vorhergehenden Schlitzes der benachbarten Schlitze platziert sind, und zweite bekannte Daten, die in einem Sägezahnabschnitt eines nachfolgenden Schlitzes der benachbarten Schlitze platziert sind, abwechselnd miteinander an einer Grenze verbunden werden und ein Wert der ersten bekannten Daten und ein Wert der zweiten bekannten Daten vorbestimmte Werte zur Erzeugung einer Langtrainingssequenz sind, die dem Digitalrundfunksender und einem Digitalrundfunkempfänger bekannt ist.
Verfahren nach Anspruch 1, wobei die bekannten Daten eine selbe Sequenz wie eine Langtrainingssequenz aufweisen, die in einem Schlitz eines Blockerweiterungsmodus 01 verwendet wird, worin ein bzw. irgendein Block eines entsprechenden Schlitzes für einen anderen Schlitz bereitgestellt wird.
Verfahren nach einem der Ansprüche 1 bis 3, wobei das Senden ein Initialisieren eines Trellis-Codierers, bevor bekannte Daten, die einem Anfangsabschnitt der Langtrainingssequenz entsprechen, Trellis-codiert sind, umfasst.
Verfahren nach einem der Ansprüche 1 bis 3, wobei das Senden ein dann, wenn Schlitze von verschiedenen Blockerweiterungsmodi kontinuierlich platziert sind, erfolgendes Initialisieren eines Trellis-Codierers, bevor bekannte Daten, die in einem Sägezahnabschnitt einer Grenze zwischen den kontinuierlich platzierten Schlitzen platziert sind, Trellis-codiert werden, umfasst.
Digitalrundfunksender, umfassend: eine Streamkonfigurationseinheit, die einen Stream konfiguriert, in dem Schlitze, die eine Mehrzahl von Blöcken umfassen, kontinuierlich platziert sind; und eine Erregereinheit, die den Stream codiert und verschachtelt und den Stream als Transportstream sendet, wobei dann, wenn Schlitze eines Blockerweiterungsmodus 00 kontinuierlich platziert sind, die Streamkonfigurationseinheit bekannte Daten, die an vorbestimmten Stellen von benachbarten Schlitzen platziert sind, miteinander zur Erzeugung einer Langtrainingssequenz verbindet.
Digitalrundfunksender nach Anspruch 6, wobei erste bekannte Daten, die in einem Sägezahnabschnitt eines vorhergehenden Schlitzes der bekannten Schlitze platziert sind, und zweite bekannte Daten, die in einem Sägezahnabschnitt eines nachfolgenden Schlitzes der benachbarten Schlitze platziert sind, abwechselnd miteinander an einer Grenze verbunden sind und ein Wert der ersten bekannten Daten und ein Wert der zweiten bekannten Daten vorbestimmte Werte zur Erzeugung einer Langtrainingssequenz sind, die dem Digitalrundfunksender und einem Digitalrundfunkempfänger bekannt sind.
Digitalrundfunksender nach Anspruch 6, wobei die bekannten Daten eine selbe Sequenz wie eine Langtrainingssequenz aufweisen, die in einem Schlitz eines Blockerweiterungsmodus 01 verwendet wird, worin ein bzw. irgendein Block eines entsprechenden Schlitzes für einen anderen Schlitz bereitgestellt wird.
Digitalrundfunksender nach einem der Ansprüche 6 bis 8, wobei die Erregereinheit umfasst: eine Codiereinheit, die den Stream codiert; eine Verschachtlereinheit, die den codierten Stream verschachtelt; und eine Trellis-Codiereinheit, die den verschachtelten Stream Trellis-codiert, wobei die Trellis-Codiereinheit initialisiert wird, bevor bekannte Daten, die einem Anfangsabschnitt der Langtrainingssequenz entsprechen, Trellis-codiert werden.
Digitalrundfunksender nach Anspruch 9, wobei dann, wenn Schlitze von verschiedenen Blockerweiterungsmodi kontinuierlich platziert sind, die Trellis-Codiereinheit initialisiert wird, bevor bekannte Daten, die in einem Sägezahnabschnitt einer Grenze zwischen den kontinuierlich platzierten Schlitzen platziert sind, Trellis-codiert werden.
Verfahren zum Verarbeiten eines Streams eines Digitalrundfunkempfängers, wobei das Verfahren umfasst: Empfangen eines Transportstreams, der codiert und verschachtelt wird, wenn Schlitze, die eine Mehrzahl von Blöcken umfassen, kontinuierlich platziert sind; Demodulieren des empfangenen Transportstreams; Ausgleichen bzw. Entzerren des demodulierten Transportstreams; und Decodieren von neuen Mobildaten aus dem ausgeglichenen bzw. entzerrten Stream, wobei jeder Schlitz des Transportstreams wenigstens eines von Normaldaten, bestehenden Mobildaten und neuen Mobildaten umfasst, wobei dann, wenn Schlitze eines Blockerweiterungsmodus 00 kontinuierlich platziert sind, in dem Transportstream bekannte Daten, die an vorbestimmten Stellen von benachbarten Schlitzen platziert sind, miteinander zur Erzeugung einer Langtrainingssequenz verbunden werden.
Verfahren nach Anspruch 11, wobei erste bekannte Daten, die in einem Sägezahnabschnitt eines vorhergehenden Schlitzes der benachbarten Schlitze platziert sind, und zweite bekannte Daten, die in einem Sägezahnabschnitt eines nachfolgenden Schlitzes der benachbarten Schlitze platziert sind, abwechselnd miteinander an einer Grenze verbunden werden und ein Wert der ersten bekannten Daten und ein Wert der zweiten bekannten Daten vorbestimmte Werte zur Erzeugung einer Langtrainingssequenz sind, die einem Digitalrundfunksender und dem Digitalrundfunkempfänger bekannt sind.
Verfahren nach Anspruch 11, wobei die bekannten Daten eine selbe Sequenz als Langtrainingssequenz aufweisen, die in einem Schlitz eines Blockerweiterungsmodus 01 verwendet wird, worin ein bzw. irgendein Block eines entsprechenden Schlitzes für einen anderen Schlitz bereitgestellt wird.
Verfahren nach einem der Ansprüche 11 bis 13, des Weiteren umfassend ein Decodieren von Signalisierungsdaten eines jeden Schlitzes und ein Identifizieren eines Blockerweiterungsmodus eines jeden der Schlitze.
Verfahren nach Anspruch 14, des Weiteren umfassend ein dann, wenn das Decodieren von Signalisierungsdaten des nachfolgenden Schlitzes der benachbarten Schlitze beendet ist und identifiziert wird, dass ein Blockerweiterungsmodus des nachfolgenden Schlitzes gleich 00 ist, erfolgendes Erfassen der bekannten Daten, die in dem Sägezahnabschnitt der Grenze zwischen den benachbarten Schlitzen platziert sind, als Langtrainingssequenz und Verarbeiten der bekannten Daten.
Verfahren nach einem der Ansprüche 11 bis 13, des Weiteren umfassend ein Decodieren von Signalisierungsdaten des vorhergehenden Schlitzes der benachbarten Schlitze und ein Identifizieren von Blockerweiterungsmodi sowohl des vorhergehenden Schlitzes wie auch des nachfolgenden Schlitzes.
Digitalrundfunkempfänger, umfassend: eine Empfangseinheit, die einen Transportstream empfängt, der codiert und verschachtelt ist, wenn Schlitze, die eine Mehrzahl von Blöcken umfassen, kontinuierlich platziert sind; einen Demodulierer, der den empfangenen Transportstream demoduliert; einen Ausgleicher bzw. Entzerrer, der den demodulierten Transportstream ausgleicht bzw. entzerrt; und eine Decodiereinheit, die neue Mobildaten aus dem ausgeglichenen bzw. entzerrten Stream decodiert, wobei jeder Schlitz des Transportstreams wenigstens eines von Normaldaten, bestehenden Mobildaten und neuen Mobildaten umfasst, wobei dann, wenn Schlitze eines Blockerweiterungsmodus 00 kontinuierlich platziert sind, in dem Transportstream bekannte Daten, die an vorbestimmten Stellen von benachbarten Schlitzen platziert sind, miteinander zur Erzeugung einer Langtrainingssequenz verbunden werden.
Digitalrundfunkempfänger nach Anspruch 17, wobei erste bekannte Daten, die in einem Sägezahnabschnitt eines vorhergehenden Schlitzes der benachbarten Schlitze platziert sind, und zweite bekannte Daten, die in einem Sägezahnabschnitt eines nachfolgenden Schlitzes der benachbarten Schlitze platziert sind, abwechselnd miteinander an einer Grenze verbunden sind und ein Wert der ersten bekannten Daten und ein Wert der zweiten bekannten Daten vorbestimmte Werte zur Erzeugung einer Langtrainingssequenz sind, die einem Digitalrundfunksender und dem Digitalrundfunkempfänger bekannt sind.
Digitalrundfunkempfänger nach Anspruch 17, wobei die Langtrainingssequenz eine selbe Sequenz wie eine Langtrainingssequenz aufweist, die in einem Schlitz eines Blockerweiterungsmodus 01 verwendet wird, worin ein bzw. irgendein Block eines entsprechenden Schlitzes für einen anderen Schlitz bereitgestellt wird.
Digitalrundfunkempfänger nach einem der Ansprüche 17 bis 19, des Weiteren umfassend einen Signalisierungsdecodierer, der Signalisierungsdaten eines jeden Schlitzes decodiert und einen Blockerweiterungsmodus eines jeden der Schlitze identifiziert.
Digitalrundfunkempfänger nach Anspruch 20, des Weiteren umfassend eine Erfassungseinheit, die dann, wenn das Decodieren von Signalisierungsdaten des nachfolgenden Schlitzes der benachbarten Schlitze beendet ist und identifiziert wird, dass ein Blockerweiterungsmodus des nachfolgenden Schlitzes gleich 00 ist, die bekannten Daten, die in dem Sägezahnabschnitt der Grenze zwischen den benachbarten Schlitzen platziert sind, als Langtrainingssequenz erfasst und die bekannten Daten verarbeitet.
Digitalrundfunkempfänger nach einem der Ansprüche 17 bis 19, des Weiteren umfassend einen Signalisierungsdecodierer, der Signalisierungsdaten des vorhergehenden Schlitzes der benachbarten Schlitze decodiert und Blockerweiterungsmodi sowohl des vorhergehenden Schlitzes wie auch des nachfolgenden Schlitzes identifiziert.