DE69712901T2

DE69712901T2 - Verfahren zur übertragung von rechnernetzdaten als teil des vertikalen austastintervalls

Info

Publication number: DE69712901T2
Application number: DE69712901T
Authority: DE
Inventors: David Feinleib
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 1996-10-07
Filing date: 1997-10-07
Publication date: 2002-11-21
Anticipated expiration: 2017-10-08
Also published as: AU4735297A; DE69712901D1; EP0929973A1; JP3999273B2; US6037932A; JP2001502135A; WO1998016066A1; EP0929973B1

Description

Diese Erfindung betrifft Verfahren zum Senden von Computernetzwerkdaten und insbesondere Internet-Protokoll-(IP)-Daten als Teil des vertikalen Austastintervalls eines Rundsendungsvideosignals (z. B. eines konventionellen Fernsehsignals).

Hintergrund der Erfindung

Konventionelle Rundsendungsfernsehsignale werden in einem Datenformat übertragen, das verwendet wird, um einzelne Fernsehbilder zu konstruieren. Jedes Bild umfasst Videobilddaten (d. h. Pixeldaten), die verwendet werden, um Bilder auf dem Fernsehbildschirm zu erzeugen, und Kontrollinformationen, wie z. B. Synchronisierungs- und Timing-Informationen, die verwendet werden, um die Darstellung des Bildes au kontrollieren. Das Videoaustastintervall (VBI) sind die oberen 21 Linien eines typischen Fernsehbildes. Diese VBI-Linien werden auf dem Fernseher nicht dargestellt" sondern werden stattdessen verwendet, um die Fernsehkontrollinformationen zu tragen. Bis zu zehn VBI-Linien können getrennt von, den Fernsehbildkontrollinformationen und zusätzlich zu diesen zur Übertragung von Daten verwendet werden. Zusätzlich wird Linie 21 des VBI zur Übertragung von verdeckten Titelinformationen verwendet.
Ein Standardformat zum Senden von Daten als Teil der VBI-Linien wird spezifiziert im Dokument EIA-516 (Mai, 1988) der Electronic Industries Association: "Joint EIA/CVCC Recomrnended Practice for Teletext: North American Basic Teletext Specification (NABTS)". Die NABTS-Spezifikation definiert ein Format, um übermäßig lange Datenströme in Datenpakete fester Länge aufzuteilen. Diese Datenpakete werden in das VBI kodiert und über das Rundsendungsnetzwerk übertragen.
Fig. 1 zeigt ein VBII-kompatibles Datenpaket 20, das aus 33 Acht-Bit-Bytes besteht. Das VBI-Datenpaket 20 umfasst einen Datenblock 22, der bis zu 28 Bytes lang sein kann: und ein fünf Bytes umfassende§ Präfix oder einen fünf Bytes umfassenden Header 24. Der Datenblock 22 variiert in der Länge in Abhängigkeit von der Größe eines optionalen, dem Datenblock folgenden Suffixes oder Nachspanns 26. Der Nachspann 26 kann eine Länge von 0, 1, 2 oder 28 Bytes aufweisen. Dementsprechend kann der Datenblock eine Länge von 0, 26, 27 oder 28 Bytes aufweisen. Unterschiedliche Kodierer haben unterschiedliche Modi, die die Länge des Nachspanns 26 und infolgedessen die Länge der tatsächlichen, im Datenblock 22 gespeicherten Daten diktieren. Der optionale Nachspann 26 stellt Platz für spezifizierende Fehlererkennungs- oder Fehlererkennungs- und Korrekturdaten, die von Empfängern verwendet werden können, zur Verfügung. Der fünf Bytes umfassende Header 24 besteht aus drei Paket-Adressen-Bytes, ein Kontinuitäts-Index-Byte und ein Paket- Struktur-Byte.
Gegenwärtige VBI-Kodierungs- und Dekodierungstechnologie stellt ein geeignetes und verlässliches Verfahren zum Senden von Daten als Teil des VBI eines Fernsehsignals zur Verfügung. Heute wird das VBI zur Übertragung einer Anzahl von Datenformen wie bspw. Aktienkursen und Wetterdaten verwendet. Viele Jahre war es ungewöhnlich für Benutzer, auf ihren Computern fernzusehen. In jüngerer Zeit ist es jedoch gebräuchlicher geworden, dass sich Benutzer auf ihren Computern Fernsehsignale anschauen. Eine wachsende Anzahl von Zuschauern/Benutzern wird für die Zukunft erwartet. Angesichts einer derartigen Konvergenz zwischen Fernsehen und Computergebrauch wird erwartet, dass Zuschauer in der Lage sein wollen, die im VBI übertragenen Daten leicht zu nutzen, besonders auf ihren Computern. Unglücklicherweise sind die meisten Computeranwendungen heutzutage nicht so konfiguriert, dass sie mit den VBI-Daten kompatibel wären. Um die VBI-Daten zu empfangen, müssen Anwendungsentwickler ihre Produkte spezialisieren. Dies ist insbesondere der Fall für Entwickler, die Anwendungen für ein Windows®-basiertes Betriebssystem erstellen, welches von Microsoft produziert und vertrieben wird, da solche Anwendungen konfiguriert sein müssen, spezialisierte Funktionen aufzurufen, die nicht ein Standardteil des Windows®-Betriebssystems sind.
Es wäre nützlich, einen globaleren Ansatz zur Übertragung von VBI-Daten vorzusehen, so dass sie einfach in Computeranwendungen verwendet werden können, ohne spezialisierte Funktionen aufzurufen.
In der Netzwerkumgebung verwenden Computeranwendungen Standardsätze von Application Programming Interfaces (APis), um Daten über Netzwerke und über das lnternet zu übertragen und zu empfangen. Z. B. verwenden Anwendungen, welche gestaltet wurden, um auf Windows -basierten Betriebssystemen zu laufen, einen Standardsatz von APIs, die in der Windows-Sockets-Specification, einer bekannten Spezifikation, definiert sind. Diese APIs sind von Industrieausschüssen definiert und sind weitläufig in Verwendung. Die Sockets-APIs stellen einen netzwerkunabhängigen Weg zum Senden und Empfangen von Daten zur Verfügung, ganz gleich welches Computernetzwerk zugrundeliegt (z. B. Ethernet, asynchroner Transfermodus (ATM), Satellit, etc.). Computeranwendungen brauchen nicht speziell geschrieben zu sein, um Daten von einem bestimmten Netzwerk zu empfangen. Stattdessen schreibt ein Entwickler den Code für eine Anwendung, der die Schnittstelle zum Windows®- Sockets-API bildet, wodurch die Anwendung in die Lage versetzt wird, Daten über eine Anzahl von unterschiedlichen Netzwerken, die von der Hardware des Computers unterstützt werden, zu senden und zu empfangen.
Ein gebräuchlicher und weitläufig verwendeter Typ von Netzwerkdaten wird Internet- Protokoll-(IP)-Daten genannt. IP-Daten definieren ein Standardformat, um Daten über im Wesentlichen jedes zugrundeliegende Netzwerk, einschließlich des Ethernets und des Internets, zu übertragen. Der IP-Standard definiert ein Paket, das zur Einkapselung der Daten verwendet wird, und IP-Daten sind immer in diesem Paket eingekapselt, ungeachtet des Übertragungsnetzwerks.
Der Erfinder hat eine Technik zum Neuverpacken von Netzwerkdaten, wie z. B. IP- Daten, in ein VBI-kompatibles Formät konzipiert, das als Teil eines traditionellen Rundsendungsfernsehsignals übertragen werden kann. Am Empfänger werden die Netzwerkdaten aus dem VBI-Signal extrahiert und - besser über einen Standardsatz von existierenden APIs als über geschützte oder nicht standardisierte Funktionen, die nur einzelnen monolithischen Client-Anwendungen bekannt sind - zu der Computeranwendung weitergeleitet.
EP 0 723 369 offenbart ein Zugangsverfahren zu und von dem Internet-World-Wide- Web-Protokoll und den Videotext-Protokollen von Prestel, Minitel und Cept. Dieses erlaubt es Videotextbenutzern; sich unter Benutzung ihres Telefons und ihrer Ferrf seher Internet-Informationen anzuschauen. Dies wird durch Unterdrückung der grafischen Information und Umformung der Hypertext-Navigationsönstruktionen in Menüsteuerung erreicht.

Zusammenfassung der Erfindung

Diese Erfindung betrifft ein Verfahren zur Kodierung von Internet-Protokoll-(IP)-Daten in ein Format zur Übertragung als Teil des vertikalen Austastintervalls (VBI) eines Rundsendungsvideosignals und umfasst die folgenden Schritte:
Empfangen eines IP-Pakets, welches einen IP-Datenblock und eine IP- Headerinformation aufweist,
Kodieren des IP-Pakets in ein Datengruppenpaket variabler Länge, welches einen Datengruppenpaket-Datenblock und eine Datengruppenpaket-Headerinformation aufweist, so dass der Datengruppenpaket-Datenblock das IP-Paket aufweist, und
Kodieren des Datengruppenpakets variabler Länge in ein oder mehrere VBIkompatible Pakete fester Länge, wobei jedes VBI-kompatible Paket eine VBIkompatibles-Paket-Headerinformation und einen VBI-kompatibles-Paket-Datenblock umfasst, der zumindest einen Teil des Datengruppenpakets aufweist.
Ein IP-Paket weist einen Datenblock variabler Länge und eine Headerinformation fester Länge in der Form eines IP-Headers und eines UDP-(User Datagram Protocol)-Headers auf.
Das Datengruppenpaket variabler Länge ist vorzugsweise ein NABTS-kompatibles Datengruppenpaket.
In einer Ausführungsform umfasst die Headerinformation für das Datengruppenpaket einen zwei Bytes umfassenden Typen-Header, der einen Typ von Netzwerkdaten identifiziert, welcher im Datenblock des Datengruppenpakets enthalten ist, und einen sechs Bytes umfassenden reservierten Zwischenraum-Header, der für eine zukünftige Definition durch den Entwickler reserviert wird. Eine mögliche Verwendung des reservierten Zwischenraum-Headers ist für eine Media Access-Control-(MAC)- Adresse, typischerweise gleichbedeutend mit der physikalischen Adresse. Die MAG- Adresse wird normalerweise unter Bezugnahme auf die Hardware-Protokolle auf unterer Ebene benutzt, welche verwendet werden, um auf ein bestimmtes Netzwerk zuzugreifen. In einer zweiten Ausführungsform weist die Headerinformation für das Datengruppenpaket einen NABTS-kompatiblen Satz-Header auf, welcher normalerweise fünf Bytes umfasst.
Die VBI-kompatiblen Pakete sind vorzugsweise die 33 Bytes umfassenden Pakete, die an der Netzwerkschicht des NABTS-Standards definiert sind. Jedes VBI-kompatible Faket hat das Potential, bis zu 28 Bytes an Daten zu speichern. Das Datengruppenpaket ist untergliedert und in den Datenblöcken der VBI-kompatiblen Pakete untergebracht.
Unter Verwendung dieses Verfahrens werden Daten, die über ein Datennetzwerk (d. h. Ethernet oder Internet) empfangen werden, für Rundsendungen als Teil des VBI eines Fernsehsignals neu gepackt. Die gepackten Netzwerkdaten bleiben unabhängig von dem zugrundeliegenden Netzwerk und können am Empfänger leicht zum Gebrauch durch Computeranwendungen extrahiert werden.
Auf diese Weise werden Netzwerkdaten über das VBI übertragen, ohne dass sie ihr bekanntes Format verlieren. Eine Computeranwendung kann Standard-APIs, wie die von der Windows-Sockets-Specification vorgeschriebenen, verwenden, um die Netzwerkdaten zu benutzen. Durch die Übertragung von eingekapselten Netzwerkdaten in einem VBI-kompatiblen Paket werden Inhalte-Verteiler in der Lage sein, einen großen neuen Umfang an Anwendungen zu unterstützen. Anwendungsentwickler werden es leicht finden, von den Netzwerkdaten Gebrauch zu machen, weil sie über Standard-Schnittstellen, mit denen sie schon vertraut sind, verfügbar sind.

Kurze Beschreibung der Zeichnung

Fig. 1 ist eine schematische Darstellung einer Paketstruktur nach dem Stand der Technik, welche gemäß des North American Basic Teletext Specification (NABTS)- Standards konstruiert ist.
Fig. 2 ist eine schematische Darstellung eines Rundsendungsübertragungssystems.
Fig. 3 ist ein Flussdiagramm eines Verfahrens zum Senden von Netzwerkdaten über das Rundsendungsübertragungssystem.
Fig. 4 ist eine schematische Darstellung einer Datenübertragungsstruktur, die verwendet wird, um Netzwerkdaten in einem VBI-kompatiblen Paket gemäß einer ersten Ausführungsform zu tragen.
Fig. 5 ist eine schematische Darstellung einer Datenübertragungsstruktur, die verwendet wird, um Netzwerkdaten in einem VBI-kompatiblen Paket gemäß einer zweiten Ausführungsform zu tragen.
Fig. 6 zeigt ein Blockdiagramm einer Empfangs- und Dekodierungseinheit.
Detaillierte Beschreibung der bevorzugte Ausführungsform Die folgende Diskussion geht davon aus, dass der Leser mit dem Standardformat zum Senden von Daten als Teil der VBI-Linien - wie es in der NABTS-Spezifikation (Dokument EIA-5116 (Mai, 1988) der Electronic Industries Association: "Joint EIAlCVCC Recomrnended Practice for Teletext: North American Basic Teletext Specification (NABTS)") näher beschrieben wird - vertraut ist.
Fig. 2 zeigt ein Rundsendungsübertragungssystem 30 zum Zuführen von Videosignalen von einem Inhalte-Provider 32 (z. B. Kabel-Kopfstelle, Fernsehrundsendungsstationvetc.) zu multiplen Empfängern 34; 36. Zum Zwecke dieser Diskussion wird das Rundsendungsübertragungssystem 30 im Zusammenhang mit einem traditionellen Rundsendungsfernsehsystem beschrieben, welches Fernsehsignale zu vielen Wohnungen überträgt.
Die Videosignale, wie z. B. traditionelle Fernsehsignale, werden über ein Rundsendungsverteilungsnetzwerk verteilt. Zwei Beispielnetzwerke sind in Fig. 2 gezeigt: Ein traditionelles analoges VHF- oder UHF-Rundsendungsnetzwerk 38 und ein Kabelnetzwerk 40. Das VHF-/UHF-Rundsendungsnetzwerk 38 umfasst einen drahtlosen Sender 42 in Form eines beim Inhalte-Provider 32 angeordneten Fernsehturms, der die Fernsehsignale 44 überträgt. Ein Empfänger 46 in Form einer bei einzelnen Wohnungen angeordneten Antenne empfängt die Fernsehsignale 44.
Das Kabelnetzwerk 40 umfasst einen beim Inhalte-Provider 32 angeordneten Kabelsender 48. Der Kabelsender 48 sendet Signale über eine Kabelverteilungsstruktur 50 (z. B. Glasfaserkabel, Koaxialkabel, verdrillte Doppelleitung, etc.) zu einem bei den einzelnen Wohnungen angeordneten Kabelempfänger 50. In Fig. 2 ist der Empfänger 70 als "Set-Top-Box" dargestellt.
Es wird bemerkt, dass andere Netzwerkausführungsformen, wie z. B. Satellitenkommunikationen, RF-Kommunikation oder eine Kombination aus drahtlosen und drahtgestützten Technologien, verwendet werden können.
In der dargestellten Ausführungsform werden zu Beispielzwecken zwei unterschiedliche Arten von Sichtanzeigeeinheiten gezeigt. In der Wohnung 34 wird die Sichtanzeigeeinheit durch einen rundsendungsfähigen Personal Computer 60, oder kurz "Rundsendungs-PC", verkörpert. Der Rundsendungs-PC 60 umfasst einen großen VGA-Monitor 62, eine Prozessoreinheit 64 und Eingabevorrichtungen in Form einer Fernbedienungstastatur 66 und eines Fernbedienungshandapparats 68. Die Fernbedienungstastatur 66 und der Handapparat 68 sind über einen drahtlosen Datenübermittlungsabschnitt, wie bspw. Infrarot (IR) oder Radio (RF), an die Prozessoreinheit 64 ferngekoppelt. Anstelle der Tastatur und des Handapparats, oder zusätzlich hierzu, können andere Arten von Eingabevorrichtungen (z. B. Mouse, Trackball, Pen, etc.) verwendet werden.
In der Wohnung 36 wird die Sichtanzeigeeinheit durch eine "Set-Top-Box" 70 verkörpert, die mit einem konventionellen Fernseher 72 verbunden ist. Ein Fernbedienungshandapparat 74 wird verwendet, um die "Set-Top-Box" und den Fernseher über einen drahtlosen Datenübermittlungsabschnitt fernzubedienen. In einer anderen Ausführungsform kann die Funktionalität in der "Set-Top-Box" 70 in den Fernseher 72 eingegliedert werden.
Der Inhalte-Provider 32 ist konfiguriert, um die Rundsendungsvideosignale als separate Bilder, welche Bilddaten und VBI-Daten enthalten, zu erzeugen. Der Inhalte- Provider 32 weist einen NABTS-Kodierer 80 auf, der VBI-Daten in die konventionellen, 33 Bytes umfassenden, VBI-kompatiblen Datenpakete kodiert, welche in dem Abschnitt "Hintergrund der Erfindung" mit Bezug auf Fig. 1 beschrieben sind.
Der Inhalte-Provider 32 umfasst weiterhin einen Netzwerkpaket-Kodierer 82, der mit einem Datennetzwerk 84, wie z. B. einem Ethernet oder dem Internet, verbunden ist. Der Netzwerkpaket-Kodierer 82 empfängt ein Netzwerkdatenpaket vom Netzwerk 84 und konvertiert es in eine Form, die vom NABTS-Kodierer 80 verwendet wird. Der Netzwerkpaket-Kodierer 82 kann in Software, Hardware oder in einer Kombination implementiert werden. Als ein Beispiel kann der Netzwerkpaket-Kodierer 82 als Router implementiert werden.
Fig. 3 zeigt ein Verfahren zum Betreiben des Rundsendungsübertragungssystems 30, so dass es Netzwerkdaten während des VBI-Intervalls trägt. Dieses Verfahren wird unter Bezugnahme auf die Fig. 2 und 4 bis 6 beschrieben.
In Schritt 100 empfängt der Netzwerkpaket-Kodierer 80 ein Netzwerkdatenpaket vom Datennetzwerk 84. Als ein Beispiel liegt das Netzwerkdatenpaket in Form eines Internet-Protokoll-(IP)-Pakets vor. Die Fig. 4 und 5 zeigen ein IP-Paket 120. Es umfasst eine Daten-Nutzinformation 122 variabler Länge (N-Bytes), einen Transport- Protokoll-Header 124 fester Länge (A-Bytes) und einen IP-Header 126 fester Länge (B-Bytes). Die Daten-Nutzinformation 122 enthält die aktuellen Netzwerkdaten. Der Transport-Protokol-Header 124 bestimmt die Transport-Schichten-Protokolle für das Datennetzwerk. Beispiele des Transport-Protokolls umfassen das Transmission Control Protocol (TCP) und das User Datagram Protocol (UDP). In den Fig. 4 und 5 weist das IP-Paket 120 einen UDP-Header 124 auf, welcher eine Länge von acht Bytes umfasst.
Der IP-Header 126 stellt die Adressierungsinformation zur Verfügung, die nötig ist, um die Daten von der Quelle zum Ziel zu übermitteln. In diesem Beispiel umfassfer eine Länge von 20 Bytes.
In Schritt 102 in Fig. 3 kodiert der Netzwerkpaket-Kodierer 82 das Netzwerkdatenpaket in ein Datengruppenpaket variabler Länge. Die Fig. 4 und 5 zeigen zwei unterschiedliche Ausführungsformen des Schritts 102 für das Beispiel-IP-Paket 120. In Fig. 4 wird das IP-Paket 120 in ein Datengruppenpaket 130 variabler Länge kodiert. In dieser Ausführungsform umfasst das Datengruppenpaket 130 einen Datenblock variabler Länge oder Daten-Nutzinformation 132 variabler Länge (M-Bytes), einen Typen-Header 134 fester Länge (C-Bytes) und einen reservierten Zwischenraum- Header 136 fester Länge (D-Bytes). Das IP-Paket 120 ist in seiner Gesamtheit (einschließlich beider Header) in die Daten-Nutzinformation 132 eingefügt.
Der Typen-Header 134 fester Länge des Datengruppenpakets 130 zeigt den Datentyp an, den die folgende Daten-Nutzinformation 132 umfasst. In diesem Beispiel ist der Typen-Header 134 fester Länge ein zwei Bytes umfassender Header, der auf 0 · 08, 0 · 00 gesetzt ist, um zu spezifizieren, dass IP-Daten folgen. Neben IP-Daten können andere Datentypen spezifiziert werden. Um bspw. zu spezifizieren, dass ein ARP-Paket folgt, könnte der Typen-Header 0 · 08, 0 · 06 aufweisen.
Der reservierte Zwischenraum-Header 136 des Datengruppenpakets 130 ist eigens für zukünftigen Gebrauch reserviert. In dieser Ausführungsform ist der reservierte Zwischenraum-Header 136 ein sechs Bytes umfassender Header, der besonders zur Speicherung der MAC-Adresse geeignet ist. Wie bereits erwähnt, wird die MAC- Adresse verwendet, um hardwarespezifische Information zu speichern, insbesondere eine physikalische Hardwareadresse (siehe z. B. Comer, Douglas E., Internetworking with TCP/IP Volume 1, Third Edition, Prentice Hall: Upper Saddle River, New Jersey, 1995). Gegenwärtig wird dieser Zwischenraum nicht verwendet, da die Bandbreite relativ gering ist und aus diesem Grund eine Filterung nicht auf einer Hardwareebene durchgeführt zu werden braucht: Die gesamte Filterung wird soft waremäßig ausge führt. Wenn der reservierte Zwischenraum unbenutzt bleibt, wird jedes der sechs Bytes auf 0 · 00 gesetzt.
Das Datengruppenpaket 130 umfasst ferner optionale Stopfbits 138, um ein Kodieren des letzten Teils des Datenblocks 132 in die VBI-kompatiblen Pakete fester Größe zu ermöglichen, wie weiter unten ausführlicher beschrieben wird.
In der in Fig. 5 dargestellten Ausführungsform wird das IP-IPaket 120 in eine leicht unterschiedliche Konfiguration eines Datengruppenpakets 140 variabler Länge kodiert. Hier umfasst das Datengruppenpaket 140 einen Datenblock variabler Länge oder Daten-Nutzinformation 142 variabler Länge (M-Bytes) und einen Satz-Header 144 fester Länge. Das IP-Paket 120 ist in seiner Gesamtheit (einschließlich beider Header) in die Daten-Nutzinformation 142 des Datengruppenpakets 140 eingefügt. Stopfbits 146 können optional verwendet werden, um - wie weiter unten beschrieben - die Konformität mit dem Format des VBI-kompatiblen Datenpakets sicherzustellen.
Der Satz-Header 144 ermöglicht die Anpassung an die in der NABTS-Spezifikation definierte Satz-Schicht. Die Satz-Header-Spezifikation wurde definiert, als Kodierer noch primitiver waren. Diese Schicht wird nun selten, wenn überhaupt, in der Industrie verwendet, während der Bundle Sack Mode (der das Satz-Format nicht interpretiert) heute beinahe universell verwendet wird. Zur Anpassung an diesen Mode fügt der Netzwerkpaket-Kodierer 82 der Daten-Nutzinformation 142 einen vordefinierten fünf Byte umfassenden Satz-Header 144 an. Da dieser Mode erwartungsgemäß nicht zur Übertragung bei hoher Bandbreite verwendet wird, ist kein Zwischenraum für die MAC-Adresse reserviert, wie dies in der in Fig. 4 dargestellten Ausführungsform getan wurde.
Jedes Byte des Satz-Headers 144 umfasst vier Bits (eine 4-Bit-Einheit) b2, b4, b6 und b8, und die alternierenden vier ungeraden Bits b1, b3, b5, b7 werden als Hamming-codierter Schutz für die vier geraden Bits verwendet. Die ersten zwei Bytes bezeichnen den Satz-Typen (RT) und den Satz-Header-Bezeichner (RD). Diese Typen werden in Kapitel 5 der NABTS-Spezifikation genauer beschrieben. Den RT- und RD-Bytes folgen drei Adressen-Zwischenraum-Bytes A1, A2 und A3, die das Format der Daten spezifizieren, die in der Daten-Nutzinformation 142 getragn werden Für IP-Daten werden die drei Bytes als A1 = 0 · 8, A2 = 0 · 0 und A3 = 0 · 0 spezifiziert. Andere Felder des Satz-Headers, die in der NABTS-Spezifikation vorgeschrieben sind - die Satz-Adressen-Erweiterung, Sätz-Verknüpfung, Klassifikationssequenz und Header-Erweiterungs-Feld -, werden als fehlend spezifiziert.
In Schritt 104 der Fig. 3 kodiert der NABTS-Kodierer 80 das vom Netzwerkpaket- Kodierer 82 ausgegebene Datengruppenpaket 130, 140 in ein oder mehrere VBIkompatible Datenpakete 20 fester Länge (33-Bytes). Wie im "Hintergrund der Erfindung" beschrieben, umfasst jedes VBI-kompatible Datenpaket 20 einen Datenblock 22 und einen fünf Bytes umfassenden Header 24. Insbesondere ist das Datengruppenpaket 130, 140 in 26, 27 oder 28 Bytes umfassende Segmente aufgeteilt und in den Datenblock 22 eingefügt. Die Stopfbits 138, 146 stellen sicher, dass das Datengruppenpaket 130, 140 gleichmäßig in den 28 Bytes umfassenden Datenblock 22 hineinpasst. Der Header 24 umfasst drei Paket-Adressen-Bytes P1, P2, P3, ein Kontinuitäts-Index-Byte Cl und ein Paket-Struktur-Byte PS.
Mit Bezug auf Schritt 104 des Verfahrens aus Fig. 3 werden die zwei unterschiedlichen Datengruppenpakete 130, 140 - wie durch Kapitel 4 der NABTS-Spezifikation vorgeschrieben - als NABTS-kompatible Datengruppenpakete variabler Länge behandelt. Diese Datengruppenpakete sind gemäß bekannter, konventioneller Techniken, die in der NABTS-Spezifikation definiert sind, in die VBI-kompatiblen Datenpakete 20 segmentiert.
Es wird bemerkt, dass der Netzwerkpaket-Kodierer 82 und der NABTS-Kodierer 80 in Hardware, Software oder einer Hardware/Software-Kornbination implementiert werden können. In Hardware wird das Netzwerkdatenpaket anfänglich in einem Register angeordnet. Die entsprechenden Header werden hinzugefügt, um das Datengruppenpaket zu bilden, welches dann in einem anderen Register gespeichert wird. Das Datengruppenpaket kann an ein Schieberegister im NABTS-Kodierer 80 weitergegeben werden, aus dem es zu einer Zeit mit jeweils 33 Bytes herausgeschoben wird, um die VBI-kompatiblen Datenpakete 20 zu bilden. In einer Software- Ausführungsform wird das Netzwerkdatenpaket im Speicher gecached, zu dem die entsprechenden Header später hinzugefügt werden. Die Software segmentiert die Informationen dann in die VBI-kofnpatiblen Datenpakete.
In Schritt 106 der Fig. 3 werden die VBI-kompatiblen Datenpakete 20 zu dem entsprechenden Übertrager (z. B. Turmsender 42 oder Kabelsender 48) übertragen und über das Rundsendungsmedium als Teil des VBI innerhalb des analogen Fernsehsignals gesendet. Die einzelnen Wohnungen 34, 36 sind mit einer Empfangseinheit (z. B. Antenne 46, "Set-Top-Box" 70; etc.) ausgerüstet, um die VBI-kompatiblen Pakete 20 von dem Rundsendungsverteilungsmedium (Schritt 108 der Fig. 3) zu empfangen. Die 33 Bytes umfassenden Datenpakete werden zu einer Dekodiereinheit übertragen.
Fig. 6 zeigt eine Empfangs- und Dekodiereinheit 150 detaillierter. Sie weist ein Empfängerbrett 152 auf, welches die VBI-kompatiblen Pakete 20 des analogen Fernsehsignals empfängt. Das Empfängerbrett 152 kann als, Teil der Abstimmvorrichtung konfiguriert werden, welche in der Lage ist, auf einen bestimmten Kanal abzustimmen. In einer Ausführungsform ist das Empfängerbrett 152 konfiguriert, um Vorwärtsfehlerkorrektur (FEC) und Datenpaket-Wiederzusammenbau, genauso wie andere Funktionen, die in Kapitel 3 der NABTS-Spezifikation näher beschrieben werden, durchzuführen.
Ein Miniport-Treiber 154 und ein geschichteter Miniport-Treiber 156 sind verbunden, um die VBI-kompatiblen Pakete 20 vom Empfängerbrett 152 zu empfangen. In dem erläuterten Beispiel sind die Treiber VBI-Netzwerk-Schnittstellen-Karten-(NIC)- Treiber - wie durch Schnittstellenschicht 158 dargestellt -, die der Network Device Interface Specification (NDIS) 4.0 entsprechen. In einer Ausführungsform ist der geschichtete Miniport-Treiber 156 ein geschichteter 802.3-Miniport-Treiber. Diese Treiber unterstützen die in dem NDIS-Dokument definierten VBI-Erweiterungen. Die VBI- NIC-Treiber 154, 156 erfüllen die folgenden drei Funktionen:
1. Verbindungsmanagement über die NDIS-Bibliothek unter Verwendung spezieller VBI-Objekt-IDs und eines VBI-Media-Typs,
2. Daten-Ein-/Ausgabe über die NDIS-Bibliothek (NDIS. SVS), und
3. Unterstützung für die UDP/IP-Multicast-Pakete.
Falls das Empfängerbrett 152 auf Hardwareebene die in der NABTS-Spezifikation definierte Funktionalität nicht unterstützt, können die Gerätetreiber zusätzlich auch die Vorwärtsfehlerkorrektur und den Datenpaket-Wiederzusammenbau, wie in der NABTS-Spezifikation in Kapitel 3 näher beschrieben, ausführen.
Paket-Wiederzusammenbau, ob hardwaremäßig am Empfängerbrett 152 oder softwaremäßig an den Miniport-Treibern 154, 156 ausgeführt, umfasst zunächst ein Rekonstruieren des Datengruppenpakets 130, 140 aus den VBI-kompatiblen Paketen 20 fester Länge (Schritt 110 aus Fig. 3). Nachdem das Datengruppenpaket wieder hergestellt ist, wird das Netzwerkdatenpaket (z. B. IP-Paket 120) aus der Daten- Nutzinformation des Datengruppenpakets extrahiert (Schritt 112 aus Fig. 3). Wenn das Datengruppenpaket das Format der Ausführungsform aus Fig. 4 aufweist, wird der Typen-Header zunächst gelesen, um zu identifizieren, welchen Typ von Netzwerkdaten die Daten-Nutzinformation aufweist, bevor mit dem Datenextraktionsschritt fortgefahren wird.
Sobald das Netzwerkdatenpaket extrahiert ist, ist es für die Anwendung gebrauchsfertig. In der in Fig. 6 dargestellten Ausführungsform ist das Netzwerkpaket ein IP- Paket, das zur Netzwerkprotokoll-Softwareschnittstelle weitergeleitet wird. Typischerweise unterstützt diese Softwareschnittstelle sowohl TCP (Transmission Control Protocol, ein verlässliches, wechselseitiges Übertragungsverfahren) als auch UDP (User Datagram Protocol, ein einseitig gerichtetes, nicht garantiertes Verfahren zum Senden von Daten). Für den Fall, dass IP-Daten im VBI übertragen wurden, akzeptiert der Client IP-Daten, wobei die UDP-Softwareschnittstelle 160 verwendet wird, welche einige rudimentäre Fehlerkontrollen (z. B. CRC) und Filterungen durchführt. An diesem Funkt ist das IP-Paket in Ordnung, um von der Winsock-Schicht 162, einer softwaremäßig implementierten Schnittstelle, die der Windows-Sockets- Specification entspricht, behandelt zu werden. Die Windows-Sockets-Specification definiert einen bekannten Standardsatz von APIs, die einen netzwerkunabhängigen Weg zum Senden und Empfangen von Daten bereitstellen. Eine Anwendung 164 verwendet die IP-Datenpakete durch verschiedene von der Winsock-Schicht 162 instrumentierte API-Aufrufe.
Diese Erfindung ist dahingehend nützlich, dass sie eine Technik zur Übertragung von Netzwerkdaten über das VBI vorschreibt, ohne dass diese ihr bekanntes Format verlieren. Eine Computeranwendung beim Empfänger kann Standard-APIs verwenden, wie z. B. die von der Windows-Sockets-Specification vorgeschriebenen, um die Netzwerkdaten zu verwenden.
In Übereinstimmung mit dem Gesetz wurde die Erfindung in einer, was strukturelle und methodische Eigenschaften betrifft, mehr oder weniger spezifischen Sprache beschrieben. Es versteht sich jedoch, dass die Erfindung nicht auf die beschriebenen spezifischen Merkmale eingeschränkt ist, da die hierin offenbarten Mittel bevorzugte Formen zur Umsetzung der Erfindung umfassen. Die Erfindung wird daher in beliebigen Formen und Modifikationen innerhalb des angemessenen Umfangs der angehängten Ansprüche - geeignet gemäß der Äquivalenzlehre interpretiert - beansprucht.

Claims

1. Verfahren zur Kodierung von Internet-Protokoll-(IP)-Daten in ein Format zur Übertragung als Teil des vertikalen Austastintervalls (VBI) eines Rundsendungsvideosignals, welches die folgenden Schritte umfasst:

Empfangen eines IP-Pakets (120), welches einen IP-Datenblock (122) und eine IP-Headerinformation (126) aufweist,

Kodieren des IP-Pakets (120) in ein Datengruppenpaket (130) variabler Länge, welches einen Datengruppenpaket-Datenblock (132) und eine Datengruppenpaket-Headerinformation aufweist, so dass der Datengruppenpaket-Datenblock (132) das IP-Paket aufweist, und

Kodieren des Datengruppenpakets (130) variabler Länge in ein oder mehrere VBI-kompatible Pakete (20) fester Länge, wobei jedes VBI-kompatible Paket (20) eine VBI-kompatibles-Paket-Headerinformation (24) und einen VBI-kompatibles-Paket-Datenblock (22) umfasst, der zumindest einen Teil des Datengruppenpakets (130) aufweist.

2. Verfahren nach Anspruch 1, weiter umfassend den Schritt des Konfigurierens des Datengruppenpakets (130) mit einem sechs Bytes umfassenden ersten Header (136) und einem zwei Bytes umfassenden zweiten Header (134).

3. Verfahren nach Anspruch 1, weiter umfassend den Schritt des Konfigurierens des Datengruppenpakets (130) mit einem reservierten Zwischenraum-Header (136) fester Länge und einem Typen-Header (134) fester Länge, der anzeigt, dass der Datenblock variabler Länge IP-Daten enthält.

4. Verfahren nach einem der Ansprüche 1 bis 3, weiter umfassend den Schritt des Konfigurierens des Datengruppenpakets (130) mit einem zur North American Basic Teletext Specification (NABTS) kompatiblen Satz-Header.

5. Verfahren nach einem der Ansprüche 1 bis 4, weiter umfassend den Schritt des Übertragens des VBI-kompatiblen Pakets (20) fester Länge.

6. Videosignal, das die VBI-kompatiblen Pakete (20) fester Länge trägt, welche gemäß der einzelnen Schritte des Verfahrens nach Anspruch 5 erzeugt wurden.

7. Speichermedium, das das Datengruppenpaket (130) variabler Länge speichert, welches gemäß der einzelnen Schritte des Verfahrens nach einem der Ansprüche 1 bis 4 erzeugt wurde.

8. Computer, welcher so programmiert ist, dass er jeden Schritt des Verfahrens nach einem der Ansprüche 1 bis 5 durchführt.

9. Computerlesbarer Speicher, der einen Computer anweist, jeden Schritt des Verfahrens nach einem der Ansprüche 1 bis 5 durchzuführen.