-
HINTERGRUND
-
Das
Internet verändert
stark die Art und Weise der Kommunikation von Unternehmen und Einzelpersonen.
Unternehmen haben typischerweise die Ressourcen, um Zugriff auf
Hochgeschwindigkeits-Verbindungen zum Internet mit großer Bandbreite
au erlangen. Für
Einzelpersonen war dies jedoch, auf Grund der Komplexität und der
Kosten nicht der Fall. CATV-Netze
haben begonnen, diese Lücke
zu füllen
und stellen Hochgeschwindigkeits-Zugriff mit großer Bandbreite auf das Internet
bereit. Als das Internet für
viele Verbraucheranwendungen beliebter wurde, wurde die Verwendung
eines CATV-Netzes für
den Zugriff auf das Internet noch mehr verstärkt. Wenn die Menge von Daten,
die über
ein CATV-Netz übertragen
wird, mit den Benutzeransprüchen
zunimmt, ist es demgemäß wichtig,
dass CATV-Netze konfiguriert werden, um diese Ansprüche zu erfüllen.
-
Gegenwärtige CATV-Set-Top-Terminals
benutzen zweckgebundene Datenkanäle
(wie beispielsweise einen Dienstdatenkanal) und die Bildaustastlücke (VBI)
eines Inbandvideosignals, um Daten zu senden. Die Datenkanäle sind
für die
Datenübertragung
zweckgebunden und stehen mit keinen Inbandvideokanälen in Verbindung.
Im Gegensatz zu einem Inbandvideokanal, der von einem Inhaltanbieter
ausgeht, sind die zweckgebundenen Datenkanäle Außerband-Kanäle, die von der Kopfstelle
des CATV-Systems ausgehen und Informationen, die für das CATV-System spezifisch
sind, wie beispielsweise Daten für
den Videoprogrammführer, Set-Top-Terminal
adressierbare Daten und andere Steuerinformationen, bereitstellen.
Obwohl zweckgebundene Datenkanäle
ein effektives Verfahren zum Übertragen
von Daten an einen Set-Top- Terminal
bereitstellen, zwingen sie einen CATV-Netzanbieter, einen Anteil
des CATV-Spektrums nur für
Datenübertragung
zu reservieren.
-
Ein
Artikel mit dem Titel "A
Digital High-Performance Multistandard Video Data Slicer" offenbart ein zweites
Verfahren zum Übertragen
von Daten. Dieses Verfahren überträgt die Daten
innerhalb einer der Zeilen der VBI, was Teil jedes Rahmens eines
Inbandvideosignals ist. 1 zeigt eine Verwendung des
Stands der Technik der VBI zur Datenübertragung. In jedem Inbandvideosignal,
das über
den Inbandkanal gesendet wurde, sind spezifische Informationen eingeschlossen.
Das vollständige
Videobild, das Rahmen genannt wird, besteht aus zwei Teilbildern,
wobei jedes 262½ horizontale
Abtastlinien (für
ein NTSC-System) enthält.
Nachdem jedes Teilbild von 262½ horizontalen
Linien abgetastet ist, kehrt der Abtaststrahl zum oberen Ende des
Bildschirms zurück,
um das Abtasten des nächsten
Teilbilds zu beginnen. Die Rücklaufzeit
wird VBI genannt. Während
der VBI sind keine Programmvideoinformationen in dem zusammengesetzten
Videosignal eingeschlossen. Die VBI dauert 21 horizontale Zeilen
(oder 1333,5, μS),
wobei jede Zeile eine Anzahl von Bit von Informationen umfasst.
-
Die
VBI kann spezielle Referenzsignale umfassen, die sich auf ausgewählten Zeilen
der VBI befinden. Verschiedene gemeinsame Signale, die sich in der
VBI befinden, umfassen das Prüfzeilenmesssignal
auf Zeilen 17 und 18, das Prüfzeilenreferenzsignal
auf Zeile 19 und das geschlossene Kennungssignal auf Zeile 21. Die
VBI kann jedoch nicht die großen
Mengen von Daten übertragen,
die gegenwärtig
von heutigen Anwendungen gebraucht werden.
-
Im
Allgemeinen können
gegenwärtige
Teletextempfänger
nur ein einzelnes Datenformat oder einen einzelnen Videostandard
empfangen. Unterschiedliche Standards erfordern typischerweise unterschiedliche Hardware
oder unterschiedliche Hardwarekomponenten. Deshalb werden mehrfache
gleichzeitige Standards im Allgemeinen nicht unterstützt. Ebenfalls
können
die Merkmale, die Inbanddatenempfänger bereitstellen, auf einfachen
Datenpaketempfang mit wenig oder keiner Datenfilterung beschränkt sein.
Zum Beispiel erfordert Paketfilterung das Eingreifen von dem Hauptsystemprozessor.
-
Demgemäß existiert
ein Bedarf an einem System, das große Mengen von Daten überträgt, um die heutigen
Datenanwendungen zu unterstützen,
und das auch einen CATV-Netzbetreiber mit Flexibilität beim Verwalten
des Netzspektrums bereitstellt.
-
ZUSAMMENFASSUNG
-
Die
vorliegende Erfindung beinhaltet ein System zum Empfangen von Hochgeschwindigkeitsdaten
innerhalb eines CATV-Videosignals über ein CATV-Netz. Das System
beinhaltet einen Datendetektor zum Empfangen des CATV-Videosignals
und zum Entnehmen der Daten aus dem CATV-Videosignal; einen Datenprozessor zum
Festlegen der Zieladresse der Daten; und einen Speicher zum selektiven
Speichern von Daten, bis sie vom Datenprozessor gebraucht werden.
Das System ist an unterschiedliche Videostandards und Datenformate
anpassbar.
-
KURZE BESCHREIBUNG DER
ZEICHNUNG(EN)
-
1 ist
ein Diagramm der Bildaustastlücke,
die gemäß dem Stand
der Technik verwendet wird.
-
2 ist
die Architektur für
unterschiedliche Arten von Inbandbenutzerdatenpaketen.
-
3 ist
ein Blockdiagramm der EIBD, das gemäß der vorliegenden Erfindung
gemacht wurde.
-
4 ist
ein Blockdiagramm des EIBD-Datendetektors.
-
4A ist
ein Blockdiagramm des EIBD-Rahmenerkennungscode-Korrelators.
-
5 ist
ein Blockdiagramm eines Netzroutingfilters.
-
6 ist
ein Flussdiagramm der logischen EIBD-Unterkanäle.
-
DETAILLIERTE BESCHREIBUNG
DER BEVORZUGTEN
-
AUSFÜHRUNGSFORM(EN)
-
Die
vorliegende Erfindung wird mit Bezug auf die Figuren der Zeichnungen
beschrieben werden, in denen gleiche Bezugszahlen durchweg gleiche
Elemente darstellen. Der verbesserte Inbanddaten(EIBD)-Empfänger verarbeitet
sowohl Benutzerdaten als auch Nicht-Benutzerdaten. Nicht-Benutzerdaten
umfassen Daten, die mit dem Dienstdatenkanal (SDC) in Verbindung
stehen. Diese Daten weisen eine feste Bitrate, ein vorbestimmtes
Format und einen vorbestimmten Rahmenerkennungscode auf.
-
Im
Gegensatz zu den Daten, die mit dem SDC in Verbindung stehen, können Benutzerdaten
viele unterschiedliche Formate, variierende Bitraten aufweisen und
können
unterschiedliche Arten von Protokollen verwenden. Wie hiernach genauer
erklärt
werden wird, können
die EIBD gemäß der vorliegenden
Erfindung in dem festen Format, das mit dem SDC in Verbindung steht,
Daten akzeptieren und sind auch auf viele unterschiedliche Arten
von Benutzerdaten konfigurierbar.
-
Mit
Bezug auf 2 ist die Architektur für die unterschiedlichen
Arten von Inbandbenutzerdatenpaketen, die von der vorliegenden Erfindung
verarbeitet werden, gezeigt. Es sollte beachtet werden, dass diese
Architekturen nur beispielhaft sind und nicht als Einschränkung der
Erfindung gesehen werden sollten. Die Anzahl der Byte 600 in
jedem Paket wird durch die Legende entlang des oberen Endes von 2 angezeigt.
Die EIBD der vorliegenden Erfindung können mit den folgenden Arten
von Datenpaketarchitekturen benutzt werden: 1) North American Broadcast
Teletext Specification(NABTS)-Daten 602; 2) World System
Teletext(WST)-Daten, die sowohl 525-Zeilenpakete 604 als
auch 625-Zeilenpakete 606 umfassen; 3) Japanische Teletext-Daten 608;
und 4) SDC-Daten (nicht gezeigt). Wie gezeigt, umfasst jede Art
von Datenpaketarchitektur eine Taktsynchronisierung 610,
einen Rahmenerkennungscode 612, einen Paketkopf 614 und
eine Nutzlast 616. Zur Einfachheit der Erklärung sind
die Hamming codierten Byte schattiert. Japanische Teletext-Daten 608, die
nicht Hamming codiert sind, umfassen ein Fehlerkorrekturfeld 618.
-
Die
ersten zwei Byte jeder Art von Benutzerdatenpaketarchitektur beinhalten
die Taktsynchonisierung 610, die auch als „Einfahren" bekannt ist. Diese
zwei Byte beinhalten ein alternierendes Muster von Einsen und Nullen.
Wenn dieses Muster durch einen Tiefpassfilter verläuft, wird
ein Gleichspannungssignal erhalten, das eine Datenschwelle etabliert.
Videoabtastwerte, die einen Wert, der über dem Schwellenwert liegt,
aufweisen, werden als eine logische Eins angesehen, und Videoabtastwerte,
die einen Wert, der unter dem Schwellenwert liegt, aufweisen, werden
als eine logische Null angesehen. Wie hiernach genauer erklärt werden
wird, wird die Taktsynchronisierung 610 verwendet, um den
Schwellenwert für
jedes Paket von Daten bereitzustellen. Es sollte beachtet werden,
dass jede Videozeile ein einzelnes Paket von Daten umfasst.
-
Der
Rahmenerkennungscode 612 ermöglicht der EIBD 400,
die Bytegrenzen festzulegen. Es gibt im Allgemeinen zwei Arten von
Rahmenerkennungscodes 612: 1) Bytesynchronisierung; und
2) einzelnes Wort. Eine Bytesynchronisierung, wie in 2 gezeigt,
ist ein einzelner Byte-Rahmenerkennungscode, der mit den Benutzerdatenpaketarchitekturen
verwendet wird. Ein einzelnes Wort ist ein Vier-Byte-Rahmenerkennungscode,
der in Verbindung mit der Übertragung
von Nicht-Benutzerdatenpaketarchitekturen, wie beispielsweise SDC-Daten,
benutzt wird.
-
Der
Paketkopf 614 wird verwendet, um unterschiedliche logische
Datenströme
zu unterscheiden. Diese Ströme
können
letztendlich für
separate Benutzer oder mehrere Anwendungen für einen einzelnen Benutzer,
wie beispielsweise Internetbrowsing, Aktualisieren eines Videoprogrammführers, Online-Spielen
etc., bestimmt sein. Der Datenblock 616 oder die Nutzlast
sind die Daten, die von einer bestimmten Anwendung verwendet werden.
-
Mit
Bezug auf 3 wird ein Blockdiagramm der
EIBD 400 gemäß der vorliegenden
Erfindung gezeigt. Die EIBD 400 umfassen einen Datendetektor 402,
einen Datenprozessor 404 (einschließlich eines zugehörigen ROM 406 und
eines sicheren RAM 416), zwei SRAMs 408, 410,
einen DMA-Manager 412 und eine Prozessorschnittstelle 414.
Die EIBD 400 akzeptieren den Ausgang von einem Basisband-Videoprozessor (BVP) 426.
Die EIBD 400 verbinden auch verschiedene externe Geräte, einschließlich eines
Benutzerprozessors (EUP) 424, eines sicheren Prozessors
(ESP) 422 und eines DRAM-Kontrollers 418, der
ferner mit einem DRAM 420 gekoppelt ist.
-
Der
BVP 426 akzeptiert das abwärts gerichtete CATV-Videosignal
von der CATV-Übertragungsanlage (nicht
gezeigt), verarbeitet das Signal und gibt ein digitalisiertes Videosignal
bei 27 Mbps aus. Wie dem Fachmann wohlbekannt, umfasst das von dem
BVP 426 durchgeführte
Verarbeiten das Entwürfeln
des Eingang-CATV-Videosignals; das Abtasten des Eingang-CATV-Video-Signals
nach oben von 13,5 Mbps bis 27 Mbps; und die Erzeugung von verschiedenen
Steuersignalen für
die EIBD 400, was die Videozeilenanzahl, das Einfahr-Fenster
(der Ort in einer Videozeile, an dem die Taktsynchronisierung 60 erwartet
wird), den geraden oder ungeraden Teilbildstatus und den „gesperrten" Videostatus umfasst,
aber darauf beschränkt
ist. Diese Signale werden von dem BVP 426 an den Datendetektor 402 ausgegeben.
-
Die
EIBD 400 benutzt zwei Grundmodi der Bedienung: 1) Akquisitionsmodus;
und 2) Videosperrmodus. Während
des Akquisitionsmodus suchen die EIBD 400 nur nach Hochgeschwindigkeits-SDC-Daten, die notwendig
sind, damit die Videosperre auftritt. Die EIBD 400 suchen
auf allen eingehenden Videoabtastwerten nach SDC-Daten. Wie hiernach
genauer erklärt
werden wird, werden die SDC-Daten, wenn sie erkannt werden, zur
Erzeugung eines Takt-Referenzsignals, das dem BVP 426 ermöglicht,
das eingehende Videosignal zu synchronisieren und den Videosperrmodus
zu erreichen, verwendet.
-
Wenn
der BVP 426 auf das eingehende Videosignal synchronisiert
ist und in den Videosperrmodus eintritt, stellt der BVP 426 die
EIBD 400 mit einem schmalen Einfahrfenster bereit, wobei
die Wahrscheinlichkeit von falscher Erkennung minimiert wird. Während des
Videosperrmodus können
die EIBD 400 nach allen Arten von Inbanddaten, nicht nur
SDC-Daten, suchen. Die EIBD 400 empfangen entwürfeltes
Video und die Einfahrsignale von dem BVP 426, was ein schmales
Suchfenster zum Lokalisieren der Inbanddaten darstellt. Das Suchfenster
ist auf jeder Videozeile während
der Zeit aktiv, in der es der Inband-Taktsynchronisierung 610 und
dem Rahmenerkennungscode 612 entspricht, wie mit Bezug
auf 4 hiernach genauer erklärt werden wird.
-
Mit
Bezug auf 4 beinhaltet der Datendetektor 402 einen
Daten-Slicer 528 und eine Erkennungslogik-Einheit 530.
Der Daten-Slicer 528 funktioniert auf der Taktsynchronisierung 610 eines
Datenpakets und die Erkennungslogik 530 funktioniert sowohl
auf der Taktsynchronisierung 610 als auch auf dem Rahmenerkennungscode 612.
Der Daten-Slicer 528 beinhaltet einen Tiefpassfilter 502,
ein Register 506 und einen Komparator 508.
-
Mit
Bezug auf den Daten-Slicer 528 wird das eingehende digitalisierte
Video 500 vom BVP 426 zum Tiefpassfilter 502 und
zum Komparator 508 geleitet. Der Tiefpassfilter 502 filtert
die Taktsynchronisierung 610 der eingehenden Videoabtastwerte,
um den Schwellenwert, mit dem die folgenden Videoabtastwerte des
Datenpakets verglichen werden, festzulegen. Die Schwelle wird in
dem Register 506 gepuffert und dann an den Komparator 508 weiter
gesendet. Der Komparator 508 vergleicht den Schwellenwertausgang
von dem Register 506 mit jedem Videoabtastwert nach der
Taktsynchronisierung 610. Jene Videoabtastwerte, die eine
Amplitude aufweisen, die größer als
der Schwellenwert ist, werden als eine logische Eins festgelegt,
und jene Videoabtastwerte, die eine Amplitude aufweisen, die kleiner
ist als die Schwelle, werden als logische Null angesehen. Diese
binären
Abtastwerte 532 werden an die Erkennungslogik-Einheit 530 ausgegeben.
-
Die
Erkennungslogik-Einheit 530 umfasst ein Schieberegister 510,
eine Taktsynchronisierungs-Detektorbank 511, die eine Vielzahl
von Komparatorschaltkreisen 512, 514, 516,
eine Rahmenerkennungscode-Detektorbank 513,
eine Steuerlogik-Einheit 520, zwei Steuerbusse 522, 523 und
einen Datenbus 524 beinhaltet. Die Erkennungslogik-Einheit 530 führt die
Erkennung der Taktsynchronisierung auf den eingehenden binären Abtastwerten 532,
die in das Schieberegister 510 bei 27 Mbps verschoben werden,
durch. Der Taktsynchronisierungsdetektor 511 verwendet
alle der Komparatorschaltkreise 512, 514, 516,
um nach einem spezifischen Muster innerhalb des Schieberegisters 510 zu
suchen. Das Muster hängt
von der Beziehung zwischen der Datenbitrate einer bestimmten Datenart
und der 27 Mbps-Videoabtastwertrate ab. Mit Bezug auf Tabelle 1
weist zum Beispiel jede Art von Daten eine unterschiedliche Bitrate
auf.
-
-
In
diesem Beispiel wird der erste Komparatorschaltkreis 512 nach
525-Zeilen-NABTS-,
WST- und Japanischen Daten bei einer Bitrate von 5,72 Mbps suchen;
der zweite Komparatorschaltkreis 514 wird nach 625-Zeilen-WST-Daten bei einer
Bitrate von 6,93 Mbps suchen; und der dritte Komparatorschaltkreis 516 wird nach
SDC-Daten bei einer Bitrate von 5,4 Mbps suchen. Wenn die binären Abtastwerte 532,
die in das Schieberegister 510 verschoben wurden, eine
der vorher erwähnten
Bitraten aufweisen, wird einer der Komparatorschaltkreise 512, 514, 516 ein
passendes Muster erkennen. Der Komparatorschaltkreis gibt ein Steuersignal an
die Steuerlogik-Einheit 520 aus, die dann ein Signal 526 an
das Register 506 ausgibt, um den Schwellenwert zu halten.
Abhängig
davon, welcher Komparatorschaltkreis 512–516 das
passende Muster gefunden hat, wird der Steuerschaltkreis 520 die
Datenbitrate der Daten in dem Schieberegister 510 kennen.
Das Register 506 wird den Schwellenwert für den Rest
des Pakets halten.
-
Während des
Akquisitionsmodus wird nur der dritte Komparatorschaltkreis 516,
der nach den SDC-Daten sucht, aktiviert. Die anderen zwei Komparatorschaltkreise 512, 514 werden
nicht aktiviert bis die EIBD 400 in den Videosperrmodus
eintreten. Wenn ein passendes Muster gefunden wurde, werden der
Datenschwellenwert, auch als Datenslicewert bekannt, und die Bitkanten
bekannt. Die Erkennung verschiebt sich dann von der Erkennung der
Taktsynchronisierung 610 zur Erkennung der Rahmensynchronisierung über das Steuersignal 526,
das von der Steuerlogik-Einheit 530 zum Register 506 gesendet
wurde. Der Datenschwellenwert wird anschließend für den Rest des Pakets konstant
gehalten und wird verwendet, um die verbleibenden Datenbitwerte
festzulegen. Ein Modulo-Zähler
(nicht gezeigt) wird verwendet, um die relative Bitkantenposition
innerhalb der eingehenden Videoabtastwerte zu verfolgen. Auf der
Basis des Werts des Modulo-Zählers wird
der sich am weitesten im Zentrum befindende Videoabtastwert, innerhalb
jedes Bitintervall mit dem Datenschwellenwert verglichen und das
Ergebnis (d. h. eine logische Eins oder eine logische Null) stellt
den Datenbitwert dar.
-
Rahmenerkennungscode-Erkennung
beinhaltet vor allem das Korrelieren des eingehenden binären mit
dem erwarteten Rahmenerkennungscode. Wenn der Ausgang eine bestimmte
Schwelle überschreitet,
wird die Rahmenerkennungscode-Erkennung angegeben. Rahmenerkennungscode-Erkennung
wird innerhalb der Rahmenerkennungscode-Detektorbank 513 durchgeführt. Die
Rahmenerkennungscode-Detektorbank 513 beinhaltet vier separate
Korrelatoren 517a–d,
wobei jeder mit dem Rahmenerkennungscode eines bestimmten Unterkanals
korreliert. Da die EIBD 400 gemäß der vorliegenden Erfindung
vier Unterkanäle
beinhalten, wobei jeder Unterkanal potentiell einen unterschiedlichen
Rahmenerkennungscode aufweist, werden vier Rahmenerkennungscode-Korrelatoren
gebraucht. Es sollte vom Fachmann erkannt werden, dass, wenn zusätzliche
Unterkanäle
erwünscht
sind, zusätzliche
Rahmenerkennungscode-Korrelatoren
hinzugefügt
werden würden. Wenn
ein Mehrfach-Code-Rahmenerkennungscode-Korrelator
verwendet wird, können
auch die Funktionen der Vielzahl von Rahmenerkennungscode-Korrelatoren 517a–d von
einem einzelnen Mehrfach-Code-Rahmenerkennungscode-Korrelator durchgeführt werden.
In der vorliegenden Erfindung sind drei der Rahmenerkennungscode-Korrelatoren
8-Bit breite Korrelatoren, die den Benutzerunterkanälen entsprechen.
Einer der Rahmenerkennungscode-Korrelatoren 517d ist
zum Korrelieren mit dem Rahmenerkennungscode der SDC-Daten, der
32 Bit beträgt,
32 Bit breit.
-
Mit
Bezug auf 4A werden die Rahmenerkennungscode-Korrelatoren 517a–d genauer
gezeigt. Der Rahmenerkennungscode-Korrelator 517a beinhaltet
Eingänge
für einen
eingehenden Rahmenerkennungscode 540 und einen erwarteten
Rahmenerkennungscode 542, einen bitweisen XNOR 544,
einen Addierer 546, einen Komparator 548 und ein
Schwellenwertregister 549. Obwohl nur ein Rahmenerkennungscode-Korrelator 517a gezeigt
wird, werden alle der Korrelatoren konfiguriert und funktionieren
auf gleiche Art und Weise. Der Rahmenerkennungscode-Korrelator 517a vergleicht
den eingehenden Rahmenerkennungscode 540, der von dem Schieberegister 510 ausgegeben
wird, mit einem erwarteten Rahmenerkennungscode 542. Der
erwartete Rahmenerkennungscode 542 ist ein konfigurierbarer
Wert, der von dem EUP 424 für einen bestimmten Unterkanal
eingestellt werden kann. Bei hexadezimaler Schreibweise kann zum
Beispiel der erwartete Rahmenerkennungscode 542 für einen
ersten Unterkanal E7 sein, und ein erwarteter Rahmenerkennungscode 542 für einen
zweiten Unterkanal kann A6 beinhalten. Sowohl der eingehende Rahmenerkennungscode 540 als
auch der erwartete Rahmenerkennungscode 542 werden in einen
bitweisen XNOR 544 eingegeben, der die zwei Rahmenerkennungscodes 540, 542 auf
einer bitweisen Basis vergleicht, um festzulegen, wie viele der
Bits den gleichen Wert aufweisen. Der Ausgang, der N-Bits beinhaltet,
wird an einen Addierer 546, der die Anzahl von Bits, die
den gleichen Wert aufweisen, aufaddiert, weiter gesendet. Dieser
Ausgang, der M-Bits beinhaltet, wird an den Komparator 548,
der den Ausgang des Addierers 546 mit einem Schwellenwert
vom Schwellenregister 549 vergleicht, weiter gesendet.
Wenn die Anzahl von Bits den in dem Schwellenregister 549 gespeicherten
Schwellenwert überschreitet,
wurde festgelegt, dass der Rahmenerkennungscode 612 erkannt
wurde. Die Schwelle des Korrelators 517 ist konfigurierbar,
damit der Benutzer bessere Sensitivität bei der Störanfälligkeit
gegen mehr Schutz gegen falsche Erkennung abwägen kann. Wenn die Rahmenerkennungscode-Erkennung
auftritt, werden die Datenbytegrenzen bekannt. Von diesem Punkt
an können
die Daten in Byte oder Wörter
paketiert werden und über
den Datenbus 524 zum SRAM 2 410 übertragen
werden. Die Steuereinheit 520 gibt ein Steuersignal 522 aus,
das die Datenart, die von dem Schieberegister 510 ausgegeben
werden soll, anzeigt. Die Daten in dem Schieberegister 510 werden
anschließend auf
den Datenbus 524 ausgegeben.
-
Um
die Zeilen, die Daten zum Erkennen aufweisen, innerhalb eines Videorahmens
festzulegen, benutzt der Datendetektor 402 ein Zeilenverzeichnis,
das aus einem Pixelmuster, das definiert, welche Zeilen außerhalb
der VBI Daten enthalten, besteht. Der Datendetektor 402 wird
nur nach Daten innerhalb der VBI und auf den aktiven Videozeilen,
die in dem von dem Zeilenverzeichnis spezifizierten Teilbild enthalten
sind, suchen. Die Zeilenverzeichnisfunktion beinhaltet zwei registrierte
Blöcke:
1) Zeilenadressmodusregister; und 2) Zeilenadresspixelmuster. Das
Zeilenadressmodusregister definiert, welche Teilbilder nach Daten
suchen sollen und beinhaltet hauptsächlich vier Auswahlmöglichkeiten:
1) keine; 2) ungerade; 3) gerade und 4) beide. Das Zeilenverzeichnispixelmuster
definiert, welche aktiven Videozeilen nach Daten suchen sollen.
-
Wenn
das Modusregister zum Beispiel ein ungerades Teilbild aktiviert
und das Zeilenverzeichnispixelmuster Zeilen 50–60 aktiviert,
suchen die EIBD 400 nur nach Daten auf Zeilen 50–60 auf
dem ungeraden Teilbild und nach Daten in der VBI beider Teilbilder.
-
Bei
der Initialisierung der EIBD 400 werden die Zeilenverzeichnisinformationen
von dem CAN-Netzbetreiber an der Kopfstelle zu den EIBD 400 gesendet,
die in dem Speicher (nicht gezeigt), der dem EUP 424 entspricht,
gespeichert sind. Die Zeilenverzeichnisinformationen existieren
für jeden
Kanal in dem Spektrum. Wenn der Set-Top-Terminal auf einen gegenwärtigen Kanal
eingestellt wird, sendet der EUP 424 den Anteil des Zeilenverzeichnisses
für den
gegenwärtigen
Kanal SRAM 1 408, wo er gespeichert ist, weiter. Die Steuerlogik-Einheit 520 benutzt
diese Informationen, um den Daten-Slicer 528 nur auf jenen Zeilen
zu aktivieren, bei denen durch das Zeilenverzeichnis angezeigt wird,
dass sie Daten aufweisen. Zusätzlich
zeigt der Einfahr-Fenstersignalausgang vom BVP 426 auf
dem Steuerbus 523 den Ort an, an dem die Taktsynchronisierung 610 gefunden
werden kann. Obwohl das Zeilenverzeichnis die EIBD 400 darüber informiert,
dass es Daten in einer bestimmten Videozeile gibt, gibt es keine
zusätzlichen
Informationen über
die Art von Daten auf der Videozeile.
-
Der
Datenausgang auf dem Datenbus 524 von dem Datendetektor 402 wird
in den SRAM 2 410 eingegeben. SRAM2 410 wird wirksam,
um die Daten 524, die von dem Datendetektor 402 ausgegeben
werden, bevor auf sie entweder von dem Datenprozessor 404 oder
dem DMA-Manager 412 eingewirkt wird, zu puffern.
-
Die
empfangenen Daten werden zum DRAM 420 unter Verwendung
des DMA-Managers 412 übertragen,
wodurch die Beteiligung des EUP 424 minimiert wird. Der
DMA-Manager 412 ist vollkommen konfigurierbar, so dass
die Daten zu einem beliebigen Speicherort des DRAM 420 übertragen
werden können.
Die Rate, bei der dem EUP 424 über eingehende Daten mitgeteilt
wird, ist vollkommen konfigurierbar, so dass der EUP 424 Puffergröße gegen
Datenlatenzzeit abwägen
kann. Zum einen kann der DMA-Manager 412 konfiguriert werden,
um den EUP 424 zu unterbrechen, nachdem jedes Datenpaket
empfangen wurde. Zum anderen kann der DMA-Manager 412 konfiguriert
werden, um den EUP 424 oder einmal pro Teilbild zu unterbrechen.
Der erstgenannte Fall ermöglicht
niedrige Latenzzeit und niedrige Pufferanforderungen auf Kosten
von größerem Prozessor-Overhead.
Der letztere Fall bewirkt höhere
Latenzzeit und Pufferanforderungen mit dem Vorteil von wenig Prozessor-Overhead.
Alle Fälle
zwischen diesen zwei Extremen werden auch unterstützt.
-
SRAM
2 ist ein Puffer-RAM, der verwendet wird, um eingehende Daten zu
puffern. Es hält
die Daten, so dass sie von dem Datenprozessor 404, bevor
sie an den EUP 424 übertragen
werden, verarbeitet werden können.
Der Datenprozessor 404 wirkt auf die Daten, die im SRAM
2 410 gepuffert werden, und legt fest, ob die Daten verworfen
oder weiter verarbeitet werden. Der Datenprozessor 404 führt auch
verschiedene Integritätsüberprüfungen auf
den Daten durch, um festzulegen, ob es Fehler gibt, und wenn es
Fehler gibt, ob sie korrigierbar sind.
-
Verschiedene
Parameter der EIBD 400 werden sowohl von dem EUP 424 als
auch dem ESP 422 konfiguriert. Der EUP 424 handhabt
typischerweise Konfigurationsparameter der EIBD 400, die
sich auf die Benutzeranwendungen beziehen. Der ESP 422 handhabt
Sicherheitsaspekte der EIBD 400, die von dem Benutzer nicht
zugänglich
sind. Alle empfangenen Daten, die an den EUP 424 übertragen
werden sollen, werden durch den DMA-Manager 412 und den
DRAM-Kontroller 418 im DRAM 420 durchgeführt.
-
Auf
Grund der großen
Bandbreite von Daten, die von den EIBD 400 empfangen werden
können,
ist es wünschenswert,
dass eine bestimmte Menge an Verarbeitung in der Hardware durchgeführt wird,
um die Last auf dem Benutzerprozessor 424 zu minimieren.
Die Datenverarbeitung, die in der Hardware durchgeführt wird, hängt von
der Unterkanalkonfiguration und der Art der empfangenen Daten ab,
kann aber aus einem beliebigen der Folgenden bestehen: 1) Netzroutingfilter;
2) Datenintegritätsfilter;
3) Nulldatenfilter; (4) Dienstcodefilter für die Zugangssteuerung; und
5) Datenentschlüsselung.
-
Mit
Bezug auf 5 umfasst der Datenprozessor 404 einen
Netzroutingfilter 552, der eine Vielzahl von Hamming-Decodierer 554, 556, 558, 560,
einen Multtplexer 562, einen Komparator 564 und
einen Filter 566 aufweist. Es gibt auch Steuerregister 568, 570, 572,
die jeweils mit dem Multiplexer 562, dem Komparator 564 und
dem Filter 566 in Verbindung stehen. Diese Steuerregister 568, 570, 572 werden
letztendlich von dem EUP 524 definiert.
-
Es
versteht sich, dass die vorliegende Erfindung eine Vielzahl Filterschritte
beinhaltet, wobei jeder davon dazu führen kann, dass die Daten verworfen
werden. Wenn die EIBD 400 den Hamming-Code 612 zum Beispiel
nicht erkennen, wird das Datenpaket verworfen. Dieser Ablauf des
Filterns gewährleistet,
dass nur richtige Daten an die speziellen Anwendungen geleitet werden.
-
Da
einige der Datenpaketköpfe,
die von den EIBD 400 gemäß der vorliegenden Erfindung
verarbeitet werden, Hamming codiert oder nicht Hamming codiert (wie
in 2 gezeigt) sein können, sieht der Netzroutingfilter 552 zwei
Datenwege vor; einen Weg 574 für Hamming codierte Daten und
einen Weg 576 für
die nicht Hamming codierte Daten. Der Fachmann sollte erkennen,
dass das Hammingcodieren Robustheit gegen Fehler bereitstellt, die
während
der Übertragung
in die Daten einfließen
können.
Das Hammingcodieren ermöglicht das
Erkennen von bis zu 2-Bit-Fehlern und das Korrigieren von 1-Bit-Fehlern.
Datenpakete, die durch den Hamming codierten Datenweg 574 laufen,
werden von dem Eingang 550 an die Hammingdecodierer 554–560 geleitet
und werden an den Multiplexer 562 ausgegeben. Nicht Hamming
codierte Daten werden vom Eingang 550 direkt an den Multiplexer 562 durch
den nicht Hamming codierten Weg 576 geleitet.
-
Das
Steuerregister 568 steuert den Multiplexer 562,
um einen der Eingänge 574, 576 auszuwählen. Wenn
die Daten Hamming codiert sind, wird der Multiplexer 562 den
Hamming codierten Weg 574 auswählen. Im Fall von nicht Hamming
codierten Daten, wie beispielsweise der japanische Teletext 608,
wählt der
Multiplexer den nicht Hamming codierten Datenweg 576 aus.
Der EUP 424 stellt diesen Wert auf der Grundlage der Daten,
die von den speziellen Benutzeranwendungen erforderlich sind, ein.
Das Steuerregister 568 kennt die Datenart, da die Datenart
von der Erkennungslogik-Einheit 530 festgelegt wurde (wie
vorher mit Bezug auf 4 beschrieben).
-
Der
Ausgang vom Multiplexer 562 beinhaltet 16 Bits Daten, die
dem Komparator 564 zugeführt werden. Der bitweise XNOR 564 vergleicht
die eingehenden 16-Bit Daten mit einem in dem Wertregister 570 gespeicherten
Wert, der einen bestimmten logischen Datenstrom, der sich auf eine
Anwendung bezieht, betrifft. Da der Netzroutingfilter 522 für eine Vielzahl
verschiedener Datenpaketarchitekturen 602, 604, 606, 608 benutzt
wird, ist der Netzroutingfilter 522 mittels einer weiteren
Konfigurierbarkeit auf den Paketkopf 614 für die spezielle
Paketarchitektur konfigurierbar.
-
Zum
Beispiel benutzt NABTS-Datenpaketarchitektur 602 einen
3-Bit-Paketkopf;
wohingegen die japanischen Teletextdatenpakete 608 14 Bits
für den
Paketkopf benutzen. Der Ausgang von dem bitweisen XNOR 564 wird
in einen selektiven Filter 566 eingegeben. Abhängig von
der Datenart, die analysiert wird, blockiert der Filter 566 die
Bits, die nicht für
die Analyse notwendig sind. Zum Beispiel wird das Maskenregister 572 für japanische
Teletextdatenpakete 608 eine 14-Bit-Maske zu dem Filter 566 definieren;
die verbleibenden 2 Bit werden maskiert und vernachlässigt. Als
weiteres Beispiel werden Pakete, die die NABTS-Datenpaketarchitektur 602 aufweisen,
eine 12-Bit-Adresse nach dem Hammingdecodieren aufweisen. Demgemäß definiert das
Maskenregister 572 eine 12-Bit-Maske, die von dem Filter 566 verwendet
werden soll, und die verbleibenden 4 Bits werden vernachlässigt. Der
Ausgang von dem selektiven Filter 566 ist ein „Treffer", wenn der Maskenvergleich
herausfindet, dass alle der nicht maskierten Bits übereinstimmen.
-
Mit
Bezug auf 6 wird die logische Unterkanalstruktur 700,
die gemäß der bevorzugten
Ausführungsform
der vorliegenden Erfindung verwendet wird, gezeigt. Die logische
Unterkanalstruktur 700 umfasst vier elementare Unterkanäle: 1) Benutzerunterkanal
A 702; 2) Benutzerunterkanal B 704; 3) CDC-Unterkanal 706;
und 4) SDC-Unterkanal 708. Wie vorher beschrieben wurde,
legen die Datenrate und der Rahmenerkennungscode der eingehenden
Daten den Unterkanal 702–708 fest, auf den
die eingehenden Daten geleitet werden sollen.
-
Mit
Bezug auf den Rahmenerkennungscode 612 wird, wenn eine
bestimmte Anwendung initiiert wird, ein Rahmenerkennungscode 612 mit
der Anwendung in Verbindung gebracht, wie vorher erwähnt. Als
ein Beispiel kann ein Rahmenerkennungscode B7 mit dem Benutzerunterkanal
A 702, der eine Anwendung für Internetbrowsing unterstützt, in
Verbindung gebracht werden. Wenn dieser Rahmenerkennungscode erkannt
wird, werden die Daten, die mit dem Rahmenerkennungscode B7 in Verbindung
stehen, an den Benutzerunterkanal A 702 weiter geleitet
werden. Auf eine derartige Art und Weise können unterschiedliche Anwendungen
mit einem der Benutzerunterkanäle
A, B 702, 704 in Verbindung stehen.
-
Der
CDC-Unterkanal 706 ist ein Unterkanal mit einer festen
Bitrate und einem festen Rahmenerkennungscode, so dass alle zugehörigen Daten,
die die Bitrate und den Rahmenerkennungscode des CDC-Unterkanals 706 aufweisen,
an den CDC-Unterkanal 706 weiter geleitet werden. Der CDC-Unterkanal 706 ist
angelegt, um Inband-CDC-Daten zu empfangen. Da das CDC-Datenformat
fest ist, erfordert der CDC-Unterkanal 706 viel weniger
Konfiguration als die Benutzerunterkanäle 702, 704 und
ist viel weniger flexibel. Der Unterkanal 706 entspricht
einem Benutzerunterkanal mit der folgenden Konfiguration: 1) Netzroutingfilter
für Paketadressfilterung
(d. h. 12-Bit-Maske) konfiguriert; 2) NABTS-Verarbeitung aktiviert; und 3) spezifische
Datenverarbeitung aktiviert.
-
Wie
die Benutzerunterkanäle
wird der CDC-Unterkanal 706 standardgemäß immer nach Daten in der VBI
suchen, es sei denn ein Zeilenverzeichnis zeigt an, dass Daten im
aktiven Video existieren. Der CDC-Unterkanal 706 ist nur
während
des Videosperrmodus aktiv. Der Paketadressfilter 706a für den CDC-Unterkanal 706 führt die
gleiche Funktion durch wie die Netzroutingfilter 702a–n, 704a–n,
außer
dass der Filter 706a fest ist, da die Datenart, das Format
und der Bitrateneingang durch den CDC-Unterkanal 706 fest
ist.
-
Wenn
keiner der Rahmenerkennungscodes, die mit einem beliebigen Unterkanal 702–708 in
Verbindung stehen, durch die EIBD 400 erkannt wird, werden
die Daten verworfen.
-
Der
Dienstdatenkanal(SDC)-Unterkanal 708 ist angelegt, um Motorola
Hochgeschwindigkeits-SDC-Daten zu empfangen, die durch sowohl den
ESP 422 als auch den EUP 424 konfigurierbar sind.
Im Gegensatz zu anderen Unterkanälen
funktioniert der SDC-Unterkanal 708 sowohl während des
Akquisitionsmodus als auch des Videosperrmodus. Der SDC-Unterkanal 708 wird
verwendet, um die notwendigen Informationen zu erfassen, damit die
Synchronisierung auftritt. Im Akquisitionsmodus sucht der SDC-Unterkanal 708 in
dem gesamten Videoteilbild nach Daten. Wenn die Videosperre erreicht
ist, beschränkt
der SDC-Unterkanal 708 seine Suche nach Daten auf der VBI,
ungeachtet des Zeilenverzeichnisses. Ein weiterer Unterschied zwischen
dem SDC-Unterkanal 708 und
anderen Unterkanälen
ist, dass die SDC-Daten ein „einzelnes Wort" anstatt Bytesynchronisierung
als ihren Rahmenerkennungscode verwenden.
-
Jeder
Benutzerunterkanal 702, 704 ist konfiguriert,
damit er jeweils eine einzelne Datenart verarbeiten kann. Wenn verschiedene
Benutzer-Unterkanäle 702, 704 vorhanden
sind, kann die vorliegende Erfindung Flexibilität bei der Unterstützung einer
Vielzahl von unterschiedlichen Anwendungen bereitstellen. Zum Beispiel
kann der Benutzerunterkanal A 702 eine Vielzahl von Anwendungen
unter Verwendung von NABTS-Datenpaketarchitektur 602 unterstützen. Die
unterschiedlichen logischen Datenströme werden von den Netzroutingfiltern 702a–n an
die Zielanwendung geleitet, wie hier vorher mit Bezug auf 5 erläutert wurde.
-
Da
die Benutzerunterkanäle 702, 704 anfangs
konfiguriert sind, um eine einzelne Datenart zu empfangen, und wenn
der Benutzerunterkanal A 702 konfiguriert ist, um die NABTS-Datenpaketarchitektur 602 zu empfangen,
kann der Benutzerunterkanal A 702 beispielhaft die japanische
Teletextdatenpaketarchitektur 608 nicht gleichzeitig verarbeiten.
-
Demgemäß kann diese
Architektur 608 von dem Benutzerunterkanal B 704 erzeugt
werden. Es sollte vom Fachmann verstanden werden, dass, obwohl hier
nur zwei Benutzerunterkanäle 702, 704 beschrieben wurden,
viele Unterkanäle
entsprechend der Notwendigkeit bereitgestellt werden können. Da
die Benutzerunterkanäle 702, 704 konfigurierbar
sind, können
zusätzlich,
wenn der Benutzer wünscht,
dass sowohl der Benutzerunterkanal A 702 als auch der Benutzerunterkanal
B 704 die japanische Teletextdatenpaketarchitektur 608 verarbeitet,
die EIBD 400 auf eine derartige Weise konfiguriert werden.
Die Benutzerunterkanäle 702, 704 können konfiguriert
sein, um viele unterschiedliche Datenformate zu empfangen. Zum Beispiel
können
die Benutzerunterkanäle
konfiguriert sein, um zwei deutliche Datenformate zu empfangen oder
vielleicht kombiniert, um eine große Anzahl von Datenströmen des
gleichen Formats bereitzustellen.
-
Benutzerunterkanäle A und
B 702, 704 empfangen Daten, die von Anwendungen
in dem EUP 424 verwendet werden sollen.
-
Die
Benutzerunterkanäle
A, B sind nur während
des Videosperrmodus aktiv. Jeder Benutzerunterkanal kann Daten,
die in einer beliebigen Kombination von Videozeilen bis zu einem
vollständigen
Teilbild von Daten eingegeben wurden, empfangen. Daten können entweder
auf dem ungeraden Videoteilbild, dem geraden Videoteilbild oder
beiden Teilbildern empfangen werden. Standardmäßig suchen die Unterkanäle 702, 704 immer
nach Daten auf dem VBI-Anteil beider Teilbilder.
-
Jeder
Benutzerunterkanal kann unabhängig
konfiguriert werden, um die folgenden Datenarten zu verarbeiten:
a) „Unrsprungs-"Daten (einschließlich WST,
japanischer Teletext, etc.); b) generische NABTS; und c) Motorola
NABTS-Format. Ursprungsdaten beziehen sich auf eine beliebige Art
von Daten, die sich nicht dem NABTS-Standard für Inband-Daten anpassen, aber mindestens 16 Bit
Taktsynchronisierung und mindestens 8 Bit Bytesynchronisierung enthalten.
Obwohl viele internationale Teletextformate, wie beispielsweise
WST und japanischer Teletext wohl-definierte Datenformate sind,
werden sie als Ursprungsdaten zum Zweck des EIBD-Empfängers klassifiziert.
Die Verarbeitung, die auf Ursprungsdaten durchgeführt wird,
ist auf Netzfilterung beschränkt.
NABTS-Daten beziehen sich auf Daten, die dem NABTS-Standard an der
Datenpaketschicht und optional an der Datengruppenschicht entsprechen.
Neben der Netzfilterung stellen NABTS-Unterkanäle Datenintegritätfilterung
bereit.
-
Keine
Datenverarbeitung wird auf dem SDC-Unterkanal 708 durchgeführt. Die
Unterkanäle 702–708 ermöglichen
den EIBD 400, konfiguriert zu werden, um gleichzeitig unterschiedliche
Datenarten zu empfangen. Obwohl es für ein Datenpaket auf einer
vorgegebenen Videozeile möglich
ist, auf mehreren Unterkanälen erkannt
zu werden, werden die EIBD 400 nur eine Kopie jedes empfangenen
Pakets verarbeiten, als ob es in einem einzelnen Unterkanal gemäß der folgenden
Priorität
empfangen wurde: 1) SDC-Unterkanal 708; 2) CDC-Unterkanal 706;
3) Benutzerunterkanal A 702; und 4) Benutzerunterkanal
B 704.
-
Auf
Grund des eingebetteten Prozessordesigns können die EIBD 400 noch
mehr hochwertige Datenverarbeitung bereitstellen, als die soweit
erläuterte
Netzroutingfilterung. Hochgradige Funktionen, wie beispielsweise
Vorwärtsfehlerkorrektur
(FEC), Datenentschlüsselung,
Authentifizierung und Zugangssteuerung können alle in der EIBD-Hardware implementiert
sein, wodurch Systemprozessorlast weiter minimiert wird.
