DE69736713T2

DE69736713T2 - Anordnung und verfahren zur übertragung von ip-daten über ein satellitennetz

Info

Publication number: DE69736713T2
Application number: DE69736713T
Authority: DE
Inventors: J. Kenneth Bellevue BIRDWELL; Brian K. Issaquah MORAN; David Kirkland FEINLEIB
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 1996-10-09
Filing date: 1997-10-08
Publication date: 2007-05-16
Anticipated expiration: 2017-10-09
Also published as: US20050099991A1; JP2001502142A; US7058043B2; US7664092B2; DE69736713D1; US20010024435A1; US6993008B2; JP3897822B2; US20050105506A1; AU4753097A; WO1998016046A1; EP0931405B1; EP0931405A1; US6172972B1

Description

Technisches Gebiet
Die Erfindung betrifft Verfahren zum Senden von Computernetzwerkdaten, insbesondere IP (Internet Protocol)-Daten, über ein Satellitennetzwerk. Die Erfindung betrifft ferner eine Mehrpakettransport-Struktur („multi-packet transport structure"), die Netzwerkdaten in für die Übertragung über das Satellitennetzwerk ebenso wie über andere Arten von Netzwerken geeigneten Größen unterstützt.
Hintergrund der Erfindung
Gebräuchliche Satellitensysteme übertragen Daten in digitalen Paketen mit standardisierter Größe. Als ein Beispiel überträgt ein Satellitennetzwerk, das als digitales Satellitensystem oder DSS-Netzwerk bezeichnet wird, Daten in Paketen mit 147 Byte Größe.
1 zeigt ein gebräuchliches DSS-Datenpaket 20. Es weist einen 3 Byte großen Header 22, eine 127 Byte große Nutzinformation 24 und einen 17 Byte großen Trailer 26 auf. Der Header 22 enthält vier Flag-Bits, 12 Adressbits für die Identifikationsnummer für den Dienstkanal („Service Channel Identification Number", SCID), vier Sequenzbits und vier Typenbits. Die Nutzinformation 24 enthält die tatsächlich zu übertragenden Daten. Der Trailer 26 enthält Vorwärtsfehlerkorrektur („Forward Error Correction", FEC)-Informationen, um bei der Verifikation hinsichtlich der Fehlerfreiheit der übertragenen Pakete behilflich zu sein.
Die in jedem digitalen Satellitenpaket enthaltenen Daten befinden sich in den 127 Byte Nutzinformation 24. Eine übliche Verwendung der DSS-Pakete ist das Übertragen von Video- und Audiosignalen, wie sie bei satellitenbasiertem Fernsehen verwendet werden. Video- und Audiosignale benötigen einen kontinuierlichen Datenstrom bei einer bestimmten Rate, um eine gleichmäßige ununterbrochene Darstellung von Bildern und Tönen zu erzeugen. Zum Konvertieren des kontinuierlichen Datenstroms in einzelne Pakete wird der Datenstrom in gleich große Blöcke von 127 Bytes Größe heruntergebrochen. Jeder Block wird in eine Nutzinformation 24 eines DSS-Pakets 20 eingefügt. Die einzelnen Pakete werden dann über das Satellitensystem zu dem Standort eines Nutzers übertragen. Die Datensegmente werden aus den DSS-Paketen extrahiert und zum Wiederherstellen des kontinuierlichen Datenstroms genutzt. Diese Schritte des Packens, Übertragens, Empfangens und Wiederherstellens werden bei einer ausreichend hohen Datenrate ausgeführt, um eine Wiedergabe der Video-/Audiosignale in Echtzeit bei dem Standort des Empfängers zu ermöglichen.
Innerhalb der Netzwerkgemeinschaft werden Daten ebenfalls über Datennetzwerke, wie beispielsweise LANs (Local Area Networks) und WANs (Wide Area Networks), in diskreten digitalen Paketen übertragen. Eine übliche und weit gebrauchte Art von Netzwerkdaten wird als IP (Internet Protocol)-Daten bezeichnet. IP-Daten definieren ein Standardformat zum Übertragen von Daten über im Wesentlichen jedes unterliegende Netzwerk, einschließlich dem Ethernet und dem Internet. Der IP-Standard definiert ein Paket, das zum Kapseln der Daten verwendet wird. Die IP-Daten werden immer in dieses Paket gekapselt, unabhängig von dem Übertragungsnetzwerk, wodurch das Übertragen der IP-Daten über viele verschiedene Netzwerke ermöglicht wird.
Gebräuchliche Netzwerkdaten werden typischerweise in Pakete gekapselt, die sehr viel größer als 127 Byte sind. Das stellt ein Problem für Satellitenübertragung dar, da die Größe eines Netzwerkdatenpakets die Größe der Nutzinformation eines Satellitenpakets, beispielsweise den 127 Byte Nutzinformation des DSS-Pakets 20, übersteigt. Überdies kann die Größe des Netzwerkdatenpakets drastisch variieren. Daher ist das Definieren einer Formel zum Konvertieren einer Art von Paketen direkt in eine andere Art von Paketen nicht besonders brauchbar. Das gleiche Problem bleibt für andere Netzwerkdatenformate außer IP und anderen Satellitenformaten außer DSS erhalten.
Es wäre vorteilhaft, eine Transportschicht zur Verfügung zu stellen, die das Übertragen von Netzwerkdatenpaketen mit variabler Länge in Satellitenpakete mit fester Größe ebenso wie andere Arten von Netzwerkpaketen zu ermöglichen.
Ein anderes Problem betrifft die Verwendung der Daten nach der Übertragung über das Satellitennetzwerk. Computeranwendungen verwenden Standardsätze von APIs (Application Programming Interfaces) zum Übertragen und Empfangen von Daten über Netzwerke und über das Internet. Beispielsweise verwenden Anwendungen, die zum Laufen auf einem Windows-basierten Betriebssystem entworfen wurden, einen Standardsatz von APIs, die in der Windows-Sockets-Spezifikation – einer gut bekannten Spezifikation – definiert sind. Diese APIs sind von Industriekomitees definiert worden und sind weithin in Gebrauch. Die Sockets-APIs stellen einen vom Netzwerk unabhängigen Weg zum Senden und Empfangen von Daten zur Verfügung, unabhängig welches unterliegende Computernetzwerk (beispielsweise Ethernet, ATM (Asynchronous Transfer Mode), etc.) verwendet wird. Computeranwendungen müssen nicht speziell für den Empfang von Daten aus einem bestimmten Netzwerk geschrieben sein. Stattdessen schreibt ein Entwickler Code für eine Anwendung, die die Windows-Sockets-API als Interface nutzt, wodurch die Anwendung zum Senden und Empfangen von Daten über etliche verschiedene von der Computerhardware unterstützte Netzwerke befähigt wird.
Es wäre vorteilhaft eine Technik zum Umpacken eines Netzwerkdatenpakets, wie beispielsweise eines IP-Datenpakets, in ein Format zur kompatiblen Übertragung über ein Satelliten- oder anderes Netzwerksystem auszugestalten, ohne die Identität des IP-Datenpakets zu verlieren. Auf diese Weise kann das Netzwerkdatenpaket durch die Computeranwendung durch einen Standardsatz von existierenden APIs eher als durch proprietäre oder nicht standardisierte Funktionen, die lediglich einzelne monolithische Client-Anwendungen kennen, verwendet werden.
„A Shared-Memory Virtual Channel Queue for ATM Broadband Terminal Adaptors" von Chao H J et al. aus International Journal of Digital and Analog Communication Systems, Band 5, 1. Januar 1992, Seite 29 bis 37, XP000390817 offenbart ein System mit einem ATM (Asynchronous Transfer Mode)-Netzwerk, über das ein Paket übertragen werden soll. Das Paket wird in eine Dateneinheit (eine CS-PDU) durch Hinzufügen eines Headers und eines Trailers umgewandelt. Die Einheit wird in feste Datenlängen, die als SAR-PDU (Segmentation And Reassembly Protocol Unit) bekannt sind, segmentiert, zu denen ein weiterer Header und Trailer hinzugefügt wird. Um dies zu erreichen, verwendet das System eine zyklische Redundanzüberprüfung („Cyclic Redundancy Check", CRC), die über das SAR-PDU mit fester Länge berechnet wird.
„Multiprocessor System for Interconnection of Ethernet and FDDI Networks using ATM via Satellite" von Lutas D et al. aus IEE Proceedings: Computers and Digital Techniques, Band 143, Nr. 1, 1. Januar 1996, Seite 69 bis 78, XP000554822, offenbart das Untereinanderverbinden von verteilten Netzwerken über Satellitenverbindungen unter Verwendung einer ATM-zellenbasierten Übertragung.
Das Patent EP 0 721 267 , das am 10. Juli 1996 veröffentlicht wurde, offenbart ebenso ein System, in dem Anwendungsdaten zuerst in eine AAL CS-PDU und dann in ATM-Zellen kodiert werden. FEC-Korrektur-Bytes werden für die CS-PDU berechnet, die in vier separaten ATM-Zellen übertragen werden.
Zusammenfassung der Erfindung
Ein Aspekt der Erfindung betrifft ein Verfahren zum Kodieren von Netzwerkdaten, wie beispielsweise IP (Internet Protocol)-Daten, in ein Format für die Übertragung über ein Satellitensystem. Die Netzwerkdaten sind in einem Paket mit einem Datenblock und Header-Information zusammengestellt. Als ein Beispiel weist ein IP-Paket einen Datenblock mit variabler Länge auf, der aus den IP-Daten und einem den IP-Header und einen UDP (User Datagram Protocol)-Header enthaltenden Header mit fester Länge besteht.
Nach einem ersten Aspekt der Erfindung gibt es ein Verfahren zum Kodieren von IP (Internet Protocol)-Daten in ein Format zur Übertragung über ein Satellitensystem, das die folgenden Schritte umfasst: Empfangen eines IP-Pakets mit einem IP-Datenblock und Header-Information, Kodieren des IP-Pakets in ein MPT (Multi Packet Transport)-Frame mit variabler Länge, der einen Daten-Frame und Header-Information enthält, derart, dass der Datenframe des MPT-Frames das IP-Paket umfasst, und Kodieren des MPT-Frames mit variabler Länge in eine Vielzahl von MPT-Pakete mit fester Länge, wobei jedes MPT-Paket einen Datenfragmentblock aufweist, der zumindest einen Teil des MPT-Frames und zugehörige Header-Information zum Kennzeichnen, welcher Teil des MPT-Frames in dem Datenfragmentblock enthalten ist, umfasst, worin lediglich eines der Vielzahl der MPT-Pakete Frame-Fehlerkorrekturinformation enthält, die mit dem gesamten Datenframe innerhalb des MPT-Frames mit variabler Länge in Verbindung gebracht wird.
Nach einem zweiten Aspekt der Erfindung gibt es ein Verfahren zum Dekodieren von Computernetzwerkdaten aus einem Satellitenübertragungssignal, das die folgenden Schritte umfasst: Empfangen mehrerer Satellitenpakete, wobei die einzelnen Satellitenpakete eine Datennutzinformation aufweisen, Entfernen der Datennutzinformationen aus den Satellitenpaketen, wobei jede Datennutzinformation ein MPT (Multi-Packet Transport)-Paket mit fester Länge aufweist, das einen Datenfragmentblock und zugehörige Header-Information aufweist, Verwenden der Header-Information des MPT-Pakets zum Anordnen der MPT-Pakete in ein MPT-Frame mit variabler Länge, worin lediglich eines der MPT-Datenpakete in dem MPT-Frame mit variabler Länge Frame-Fehlerkorrekturinformation enthält, wobei die Fehlerkorrekturinformation mit dem gesamten Datenframe innerhalb des MPT-Frames mit variabler Länge in Verbindung gebracht wird, Wiederherstellen des MPT-Frames aus den Datenfragmentblöcken der MPT-Pakete, Extrahieren der Netzwerkdaten aus den wiederhergestellten MPT-Frames und Extrahieren der Fehlerkorrekturinformation und Verwenden dieser zum Überprüfen der Netzwerkdaten hinsichtlich Fehler.
Nach einem dritten Aspekt der Erfindung wird eine Kodiereinheit zum Kodieren von Netzwerkdatenpaketen in ein Format zur Übertragung über ein Satellitensystem zur Verfügung gestellt, wobei die Kodiereinheit umfasst: Mittel zum Hinzfügen eines Headers an ein Netzwerkdatenpaket zum Bilden eines Multipaket-Transport-MPT-Frames mit variabler Länge und Mittel zum Segmentieren des MPT-Frames in eine Vielzahl von Datenfragmentblöcke, Mittel zum Berechnen von Fehlerkorrekturinformation für die MPT-Pakete aus dem gesamten Daten-Frame innerhalb des MPT-Frames mit variabler Länge, Mittel zum Hinzufügen der Fehlerkorrekturinformation an lediglich eines der MPT-Pakete und Mittel zum Hinzufügen eines Headers an jeden Datenfragmentblock zum Bilden von MPT-Paketen mit fester Länger und mit einer für die Übertragung über das Satellitensystem geeigneten Größe.
Nach einem vierten Aspekt der Erfindung wird ein Satellitenübertragungssystem zur Verfügung gestellt, das umfasst: Eine Kodiereinheit zum Kodieren eines Computernetzwerkdatenpakets in eines oder mehrere Satellitenpakete, wobei die Kodiereinheit nach dem dritten Aspekt der Erfindung zusätzlich dazu ausgestaltet ist, Header-/Trailer-Information zu jedem MPT-Paket zum Bilden eines oder mehrerer Satellitenpaketen hinzuzufügen, eine Satellitenübertragungseinheit, die zum Empfangen der Satellitenpakete von der Kodiereinheit verbunden ist, wobei die Satellitenübertragungseinheit die Satellitenpakete über ein Satellitennetzwerk überträgt, eine Empfangseinheit zum Empfangen der Satellitenpakete aus dem Satellitennetzwerk und eine Dekodiereinheit, die mit der Empfangseinheit verbunden ist, wobei die Dekodiereinheit ausgestaltet ist zum: (i) Wiedererlangen der MPT-Pakete aus den Satellitenpaketen, (ii) Wiederherstellen des MPT-Frames aus den MPT-Paketen, (iii) Extrahieren der Fehlerkorrekturinformation aus einem der MPT-Pakete, (iv) Überprüfen des gesamten Datenframes innerhalb des MPT-Frames mit variabler Länge hinsichtlich Fehler unter Verwendung der Fehlerkorrekturinformation und (v) Extrahieren des Netzwerkdatenpakets aus dem MPT-Frame.
Das Netzwerkdatenpaket wird in ein MPT (Multi-Packet Transport)-Frame mit variabler Länge kodiert. Das MPT-Frame umfasst ein Daten-Frame und Header-Information. Das IP-Paket wird in seiner Gesamtheit in das Daten-Frame des MPT-Frames eingefügt.
Das MPT-Frame mit variabler Länge wird dann in ein oder mehrere MPT-Pakete mit fester Länge kodiert. Jedes MPT-Paket weist einen Datenfragmentblock mit einem Teil des MPT-Frames und zugehöriger Header-Information auf, um zu kennzeichnen, welcher Teil des MPT-Frames in dem Datenfragmentblock enthalten ist. In einer Implementierung ist der Header des MPT-Pakets ein 1 Byte langer Header, der ein den Frame-Anfang kennzeichnendes Bit und ein das Frame-Ende kennzeichnendes Bit umfasst. Diese beiden Bits kennzeichnen, ob die in dem zugehörigen Datenfragementblock des MPT-Pakets enthaltenen Daten den An fangsteil des MPT-Frames, den Endteil des MPT-Frames oder einen Mittelteil des MPT-Frames umfassen. Insbesondere wird das den Frame-Anfang kennzeichnende Bit gesetzt, wenn der Datenfragmentblock den Anfangsteil des MPT-Frames enthält. Das das Frame-Ende kennzeichnende Bit wird gesetzt, wenn der Datenfragmentblock den Endteil des MPT-Frames enthält. Beide Bits werden zurückgesetzt, wenn der zugehörige Datenfragmentblock den Mittelteil des MPT-Frames enthält. Auf diese Art und Weise unterstützt die Header-Information das Wiederzusammenfügen der Datenfragmente in das MPT-Frame.
Die MPT-Pakete besitzen eine zum Übertragen über das Satellitensystem geeignete Größe. In einer Implementierung wird die Größe der MPT-Pakete auf 127 Byte festgelegt. Bei dieser Größe wird das gesamte MPT-Paket in die 127 Byte Datennutzinformation eines gebräuchlichen 147 Byte langen DSS-Pakets eingebettet.
Unter Verwendung dieses Verfahrens werden die über ein Datennetzwerk (d.h. Ethernet oder Internet) in großen Netzwerkdatenpaketen empfangenen Daten in kleinere durch den Mehrpakettransport definierte Pakete heruntergebrochen. Diese Pakete werden dann als die Datennutzinformation innerhalb Standardpaketen mit fester Länge, die zur Übertragung über ein bestimmtes Verteilnetzwerk geeignet sind, untergebracht.
Kurze Beschreibung der Zeichnungen
1 ist eine schematische Darstellung einer DSS (Digital Satellite System)-Paketstruktur gemäß Stand der Technik.
2 ist eine schematische Darstellung eines Satellitenübertragungssystems.
3 ist ein Flussdiagramm eines Verfahrens zum Senden von Netzwerkdaten über das Satellitenübertragungssystem.
4 ist eine schematische Darstellung einer MPT (Multi-Packet Transport)-Struktur, die zum Übertragen der Netzwerkdaten verwendet wird.
5 ist eine schematische Darstellung eines MPT-Pakets, das innerhalb eines satellitenübertragbaren DSS-Pakets eingebettet ist.
6 ist eine schematische Darstellung von verschiedenen Paketstrukturen, die das Wiederzusammenfügen des Netzwerkpakets aus den MPT-Paketen zeigt.
7 ist ein Blockdiagramm eines Interfaces einer Satellitenempfänger-/Betrachtungseinheit, das den Datenfluss von Netzwerkpaketen zu auf der Betrachtungseinheit laufenden Anwendungen zeigt.
Detaillierte Beschreibung der bevorzugten Ausführungsform
2 zeigt ein Satellitenübertragungssystem 30 zum Liefern von Signalen von einem Anbieter 32 von Inhalten (beispielsweise eine Kabelkopfstation, Fernsehsenderstation, Internetdienste-Anbieter, etc.) zu einem Empfängerstandort 34 über ein Satellitennetzwerk 38. Das Satellitennetzwerk 38 umfasst einen Satellitensender 40, der bei dem Inhaltsanbieter 32 angeordnet ist. Der Satellitensender 40 sendet Signale in Form von einzelnen digitalen Paketen zu einem umkreisenden Satelliten, der die digitalen Pakete wieder zurück zu einem Satellitenempfänger 44 sendet, der an dem Empfängerstandort lokalisiert ist. Ein Beispiel eines geeigneten Satellitennetzwerks 38 ist ein DSS (Digital Satellite System)-Netzwerk, das Video- und Audiosignale von einem Inhaltsanbieter zu einzelnen Satellitenempfängern sendet, die in den Häusern der Teilnehmer lokalisiert sind. In einem DSS-Netzwerk umfasst der Satellitenempfänger 44 eine kleine 18''-Schüssel, die zum Empfangen der über den Satelliten übertragenen Signale geeignet ist. Das DSS-Netzwerk unterstützt Shows, Filme, Spiele und dergleichen über Satellitenfernsehrundfunk.
Allgemeiner können Satellitensignale viele verschiedene Datentypen einschließlich Video, Audio, Animation, Text oder dergleichen enthalten. In der dargestellten Implementierung werden die Satellitensignale von dem Satellitenempfänger 44 zu einem von zwei verschiedenen Arten von Anzeigeeinheiten an dem Empfängerstandort 34 gesendet. Eine Anzeigeeinheit ist als ein zum Rundfunk befähigter Personalcomputer 50 (oder einfach „Rundfunk-PC") ausgeführt. Der Rundfunk-PC 50 weist einen großen VGA-Monitor 52, eine Verarbeitungseinheit 54 und Eingabegeräte in Form einer entfernten Tastatur 56 und eines Fernbedienungshandapparats 58 auf. Die entfernte Tastatur 56 und der Handapparat 58 werden entfernt an die Verarbeitungseinheit 54 über eine drahtlose Datenverbindung, wie beispielsweise Infrarot (IR) oder Funk, gekoppelt. Andere Arten von Eingabegeräten (beispielsweise Maus, Trackball, elektronischer Stift, etc.) können statt oder zusätzlich zu der Tastatur und dem Handapparat verwendet werden.
Die andere Anzeigeeinheit ist als eine Set-Top-Box 60 ausgeführt, die mit einem gebräuchlichen Fernseher 62 verbunden ist. Ein Fernbedienungshandapparat 64 wird verwendet, um die Set-Top-Box und den Fernseher entfernt über eine drahtlose Datenverbindung zu steuern. In einer anderen Ausführungsform kann die Funktionalität in der Set-Top-Box 60 in den Fernseher 62 aufgenommen sein.
Der Inhaltsanbieter 32 ist dazu ausgestaltet, die Signale in digitale Pakete mit fester Länge zu packen. Als ein Beispiel weist ein DSS-Paket eine Größe von 147 Byte auf, wie es in dem Abschnitt „Hintergrund der Erfindung" mit Bezug auf 1 beschrieben wurde. Der Inhaltsanbieter 32 umfasst eine Kodiereinheit zum Kodieren der Netzwerkdatenpakete in ein Format zur Übertragung über das Satellitensystem 38. In der dargestellten Implementierung umfasst die Kodiereinheit bei dem Inhaltsanbieter einen MPT (Multi Packet Transport)-Kodierer 70, der mit einem Datennetzwerk 72, wie beispielsweise einem Ethernet oder dem Internet, verbunden ist. Der MPT-Kodierer 70 empfängt Netzwerkdatenpakete (beispielsweise TCP/IP-Pakete oder UDP/IP-Pakete) aus dem Datennetzwerk 72, packt sie in ein MPT-Frame-Format ein und spaltet dann den MPT-Frame in MPT-Pakete auf, die für die Satellitenübertragung geeignet dimensioniert sind. Als ein Beispiel kann der MPT-Kodierer als ein Netzwerkrouter implementiert sein. Die MPT-Frame- und -Paket-Strukturen werden unten detaillierter beschrieben. MPT- Pakete werden einem Satellitenmultiplexer-Interface 74 übergeben, wo sie in satellitenübertragbare Pakete kodiert werden. Die Satellitenpakete werden dann in der Aufwärtsstrecke dem Satellitensender 40 übergeben.
3 zeigt ein Verfahren zum Betrieb des Satellitenübertragungssystems 30 zum Übertragen der Netzwerkdaten als Teil der Satellitenübertragung. Dieses Verfahren wird mit Bezug auf die 2 und 4 bis 7 beschrieben.
In Schritt 100 empfängt der MPT-Kodierer 70 ein Netzwerkdatenpaket aus dem Datennetzwerk 72. Als ein Beispiel liegt das Netzwerkdatenpaket in der Form eines IP (Internet Protocol)-Pakets vor, obwohl andere Formen von Paketen genutzt werden können.
4 zeigt ein IP-Paket 120. Es weist eine Datennutzinformation 122 mit variabler Länge (N Byte), einen Transportprotokoll-Header 124 mit fester Länger (A Byte) und einen IP-Header 126 mit fester Länger (B Byte) auf. Die Datennutzinformation 122 enthält die eigentlichen Netzwerkdaten. Der Transportprotokoll-Header 124 kennzeichnet die Transportschichtprotokolle für das Datennetzwerk. Beispiele für Transportprotokolle umfassen TCP (Transmission Control Protocol) und UDP (User Datagram Protocol). In 4 weist das IP-Paket 120 ein UDP-Header 124 auf, der 8 Byte lang ist. Der IP-Header 126 stellt die zum Liefern der Daten von der Quelle zu dem Ziel notwendigen Adressinformationen zur Verfügung. In diesem Beispiel weist der IP-Header 126 eine Länge von 20 Byte auf.
In Schritt 102 in 3 kodiert der MPT-Kodierer 70 die Netzwerkdatenpakete in einen MPT-Frame 130 mit variabler Länge. Der MPT-Frame 130 weist einen Datenblock oder Datennutzinformation 132 mit variabler Länge (M Byte) und einen Typen-Header 134 mit fester Länge (C Byte) auf. Das IP-Paket 120 wird in seiner Gesamtheit (einschließlich beider Header) in die Datennutzinformation 132 des MPT-Frames eingefügt. Als eine beispielhafte Implementierung enthält der Header 134 eine zwei Byte lange Protokollidentifizierung, die für IP-Daten einen Wert von 0x0800 hat. Der Header 134 könnte ebenso optionale Bytes zum Kennzeichnen von Protokolloptionen enthalten.
Das MPT-Frame 130 könnte ebenso einen Trailer 136 aufweisen, der an die Datennutzinformation 132 angefügt wird. Der Trailer 136 umfasst ein oder mehrere optionale Füll-Bytes 136, die die Gesamtzahl der Bytes für den letzten Teil des MPT-Frames 130 auf eine zum Einfügen in ein MPT-Paket mit fester Länge geeignete Größe – wie es unten detaillierter beschrieben wird – bringen. Der Trailer 136 könnte auch Platz für weiteren Gebrauch ebenso wie Längendaten, die die Länge des tatsächlichen Datenframes 132 spezifizieren und die optionalen Bytes für Protokolloptionen, kennzeichnen.
In Schritt 104 in 3 kodiert der MPT-Kodierer 70 den MPT-Frame 130 mit variabler Länge in ein oder mehrere MPT-Pakete 140(1), 140(2), ..., 140(n) mit fester Länge. In der dargestellten Implementierung besteht jedes MPT-Paket 140 aus 127 Byte. Jedes MPT-Paket 140 weist einen Datenblock 142, der in Abhängigkeit von den Paketinhalten in der Größe variieren kann, und mindestens einen Flag-Header 144 auf.
Während des Kodierens wird das MPT-Frame 130 in Datenfragmente heruntergebrochen, die die Datenfragmentblöcke 142(1), 142(2), ..., 142(n) der MPT-Pakete 140(1), 140(2), ..., 140(n) bilden. Die Flag-Header 144(1), 144(2), ..., 144(n) werden dann vor den entsprechenden Datenfragmentblöcken 142(1), 142(2), ..., 142(n) angefügt. In der dargestellten Implementierung weist jeder Flag-Header 144 eine Größe von einem Byte auf. Der Flag-Header 144 enthält zwei Flag-Bits 146, vier undefinierte Bits 148, ein den Frame-Anfang (SOF, Start-Of-Frame) kennzeichnendes Bit 150 und ein das Frame-Ende (EOF, End-Of-Frame) kennzeichnendes Bit 152. Das SOF-Bit und das EOF-Bit sind die niederwertigsten Bits („least significant bits") des Flag-Headers.
Das SOF- und das EOF-Bit 150 und 152 kennzeichnen, ob das Datenfragment aus dem MPT-Frame, das innerhalb des entsprechenden Datenblocks 142 enthalten ist, ein Anfangsteil, ein Endteil oder ein Mittelteil des MPT-Frames ist. Insbesondere wird das SOF-Bit 150 gesetzt, wenn das entsprechende Datenfragment 142 von dem Anfangsteil des MPT-Frames 130 stammt. Das EOF-Bit 152 wird gesetzt, wenn das Datenfragment 142 von dem Endteil des MPT-Frames 130 stammt. Sowohl das SOF- als auch das EOF-Bit werden zurückgesetzt, wenn das Datenfragment aus dem Mittelteil des MPT-Frames 130 stammt.
In 4 ist das MPT-Paket 140(1) ein beispielhaftes vorderes Paket, das das Anfangsdatenfragment des MPT-Frames 130 enthält. Entsprechend ist das SOF-Bit auf eine binäre „1" gesetzt und das EOF auf eine binäre „0" zurückgesetzt, wie es durch den Kasten 154 repräsentiert ist. Das letzte MPT-Paket 140(n) ist ein beispielhaftes Endpaket, das das Enddatenfragment des MPT-Frames 130 enthält. Als ein Ergebnis ist das SOF-Bit auf eine binäre „0" zurückgesetzt und das EOF-Bit auf eine binäre „1" gesetzt, wie es durch den Kasten 156 repräsentiert ist. Das MPT-Paket 140(2) ist ein beispielhaftes mittleres Paket, das ein mittleres Datenfragment des MPT-Frames 130 enthält, und daher ist sowohl das SOF- als auch das EOF-Bit auf eine binäre „0" zurückgesetzt, wie es durch den Kasten 158 repräsentiert ist.
Das vordere MPT-Paket 140(1) weist einen Adress-Header 160 auf, der vor dem Datenblock 142(1) positioniert ist. In der Beispielimplementierung besteht der Adress-Header 160 aus einem sechs Byte langen Wert. Dieser wird in Kombination mit der bestehenden Servicekanalidentifikationsnummer (SCID, Service Channel Identification Number) verwendet und ist als ein „Sub-SCID" bekannt. Als ein Ergebnis umfasst das vordere MPT-Paket 140(1) einen ein Byte langen Flag-Header 144(1), einen sechs Byte langen Adress-Header 160 und einen 120 Byte langen Datenblock 142(1).
Das letzte MPT-Paket 140(n) weist einen Fehlerkorrektur-Trailer 162 auf, der nach dem Datenblock 142(n) positionierte Fehlerkorrekturdaten enthält. Als ein Beispiel enthält der Fehlerkorrektur-Trailer 162 einen 32 Bit langen CRC (Cyclic Redundancy Check)-Wert, der für alle vorhergehenden MPT-Pakete 140(1) bis 140(n) berechnet wird, was durch die Bytes innerhalb des gestrichelten Kastens 164 repräsentiert wird. CRC-Fehlerüberprüfen ist ein Vorgang, der zum Überprüfen hinsichtlich Fehler in der Datenübertragung genutzt wird. Es bringt eine komplexe Berechnung mit sich, einen auf die übermittelten Daten basierenden Wert zu erzeugen. Ein CRC-Wert wird bei dem Sender berechnet und als Teil des übermittelten Pakets angefügt. Der Empfänger wiederholt die Berechnung und vergleicht das Ergebnis mit dem angefügten CRC-Wert. Wenn die Berechnung des Empfängers und der angefügte CRC-Wert übereinstimmen, wird die Übertragung der Daten als fehlerfrei angenommen. CRC ist gut bekannt und weit verbreitet. Es sei erwähnt, dass andere Arten von Fehlerkorrekturwerten alternativ eingesetzt werden können.
Das letzte MPT-Paket 140(n) umfasst daher einen ein Byte langen Flag-Header 144(n), einen 122 Byte langen Datenblock 142(n) und einen vier Byte langen Fehlerkorrektur-Trailer 162. Alle mittleren MPT-Pakete 140(2), ..., 140(n-1) umfassen einen ein Byte langen Flag-Header 144 und einen 126 Byte langen Datenblock 142.
Tabelle 1 fasst die vier möglichen Pakettypen basierend auf die Werte des SOF- und EOF-Bits des Flag-Byte-Headers zusammen.
In Schritt 106 der 3 bettet das Satellitenmultiplexinterface 74 die MPT-Pakete 140 in Satellitenpakete mit fester Länge zur Übertragung über das Satellitennetzwerk 38 ein. Zum Zwecke der weiteren Diskussion wird dieser Schritt im Zusammenhang mit DSS-Datenpaketen beschrieben, die eine feste Länge von 147 Byte aufweisen.
5 zeigt ein MPT-Paket 140 und seine Beziehung zu einem 147 Byte langen DSS-Paket 20, welches das gleiche Paket wie das in Bezug auf 1 beschriebene ist. In dieser Implementierung sind die ersten beiden Flag-Bits 146 des Flag-Header 144 zu 0 gesetzt, um ein DSS-Paketformat zu repräsentieren. Das gesamte 127 Byte lange MPT-Paket 140 wird in die 127 Byte Datennutzinformation 24 des konventionellen DSS-Paket 20 eingefügt. Ein drei Byte langer DSS-Header 22 wird vor der Datennutzinformation 24 angefügt. Der Header 22 umfasst vier Flag-Bits, 12 Adress-Bits für die Servicekanalidentifikationsnummer (SCID, Service Channel Identification Number), vier Sequenz-Bits und vier Typen-Bits. Ein 17 Byte langer Trailer 26 wird an das Ende der Datennutzinformation 24 angefügt und enthält Vorwärtsfehlerkorrektur (FEC, Forward Error Correction)-Information, die gemäß üblicher Techniken berechnet wird.
Es sei bemerkt, dass der MPT-Kodierer 70 in Hardware, Software oder einer Kombination von Hardware und Software implementiert sein kann. Bei einer Implementierung in Hardware wird das von dem Datennetzwerk 72 empfangene Netzwerkdatenpaket zuerst in einem Register platziert. Ein Header 134 und optionale Füllung 136 werden zum Bilden des MPT-Frames 130, der in einem anderen Register gespeichert wird, hinzugefügt. Der MPT-Frame 130 wird dann einem Schieberegister in dem MPT-Kodierer 70 übergeben. Die ersten 120 Byte werden herausgeschoben und ein ein Byte langer Flag-Header 144 und ein sechs Byte langer Adress-Header 160 werden dazu zum Bilden eines vorderen MPT-Pakets 140(1) hinzugefügt. Das vordere MPT-Paket 140(1) wird in einem separaten Register gespeichert. Danach wird das MPT-Frame 130 zu je 126 Byte herausgeschoben, während ein Flag-Header 144 zu jedem hinzugefügt wird, um die mittleren MPT-Pakete 140(2), ..., 140(n-1) zu bilden. Wenn das Ende des MPT-Frames 130 erreicht ist, werden die letzten Datenbytes herausgeschoben und ein ein Byte langer Flag-Header 144(n) zum Bilden des letzten MPT-Pakets 140(n) hinzugefügt. Ein CRC-Wert wird dann unter Verwendung aller in den verschiedenen Registern gespeicherter MPT-Pakete berechnet. Der CRC-Wert wird als ein vier Byte langer Trailer 162 zu dem letzten MPT-Paket 140(n) hinzugefügt.
In einer Softwareimplementierung wird das Netzwerkdatenpaket in einem Cache-Speicher zwischengespeichert. Der MPT-Frame-Header und die Ausfüllung werden um das Netzwerkdatenpaket herumgepackt. Die Software segmentiert. dann den MPT-Frame in geeignet dimensionierte Datenfragmente und fügt den Flag-Header hinzu. Der Adress-Header wird zu dem ersten MPT-Paket hinzugefügt. Die Software berechnet dann einen CRC-Wert und fügt diesen als ein Trailer an das letzte MPT-Paket an.
In Schritt 108 in 3 werden die Satellitenpakete von dem Inhaltsanbieter 32 über das Satellitennetzwerk 38 zu dem Empfängerstandort 34 übertragen. Die DSS-Pakete werden auf mehreren SCIDs übertragen und der Satellitenempfänger 44 unterstützt den Empfang auf mehreren SCIDs gleichzeitig. Der Satellitenempfänger 44 unterstützt Breitbandpaketsynchronisation (d.h. eine Technik zum Verarbeiten von aus dem Satellitennetzwerk empfangenen Daten) zum Erkennen der Grenzen der DSS-Pakete.
Sobald der Satellitenempfänger 44 die Satellitenpakete empfängt (Schritt 110 in 3), verwendet er die letzten 17 Byte zum Durchführen einer FEC (Forward Error Correction)-Analyse, um sicherzustellen, dass das DSS-Paket intakt ist. Der Satellitenempfänger 44 filtert dann die DSS-Pakete unter Verwendung der SCID-Adresse in den ersten drei Bytes des 147 Byte langen DSS-Pakets. Ungewünschte Pakete werden verworfen. Die annehmbaren Pakete werden zu einer Dekodiereinheit weitergereicht, die als Teil des Satellitenempfängers und vorzugsweise in Software implementiert ist.
6 zeigt die Zwischendatenstrukturen während des Wiederzusammensetzens des Netzwerkdatenpakets innerhalb des Satellitenempfängers und ihre Umwandlung in ein Paket, das mit dem Ethernet-Protokoll übereinstimmt. Der Satellitenempfänger 44 schneidet zunächst den 17 Byte langen FEC-Trailer von dem Satellitenpaket zum Extrahieren des MPT-Pakets ab (Schritt 112 in 3). Der drei Byte lange DSS-Paket-Header 22 kann oder kann nicht als ein Teil des extrahierten MPT-Pakets 140' verbleiben. Nachdem die SCID-Adresse zum anfänglichen Gruppieren und Filtern der DSS-Pakete verwendet wurde, werden die in dem drei Byte langen DSS-Paket-Header enthaltenen Informationen irrelevant und können daher fallengelassen werden.
Bei dem MPT-Paket 140' wurde der Flag-Header 144 (und Adress-Header für das erste Paket) ebenso wie die fragmentierten Daten in dem Datenblock 142 unversehrt belassen. Der Satellitenempfänger filtert ungewünschte MPT-Pakete unter Verwendung der Sub-SCID-Adressen, die in dem vorderen MPT-Paket enthalten sind. Die Sub-SCID-Adressen sind 48 Bits lang und in dem vierten bis neunten Byte in dem MPT-Paket positioniert. Die Sub-SCID-Adressen werden über die zum Übertragen der MPT-Pakete genutzten SCIDs synchronisiert, allerdings wird das Filtern auf den Sub-SCID-Adressen ohne Bezug auf die SCID für das Satellitenpaket durchgeführt.
In einer beispielhaften Ausführungsform filtert der Satellitenempfänger auf mindestens 16 verschiedenen Sub-SCIDs gleichzeitig. Ungewünschte MPT-Pakete werden verworfen, während die MPT-Pakete mit entsprechenden Sub-SCID-Adressen behalten werden. Es ist wünschenswert, auf so vielen Sub-SCIDs wie möglich zu filtern. Viele Satellitensysteme zur Datenverbreitung sind zum Filtern auf 32 verschiedenen Sub-SCIDs in der Lage. Zusätzlich sollte der Satelliten empfänger auch einen „vermischten" Modus unterstützen, in dem er nicht irgendwelche Sub-SCIDs herausfiltert, eher Pakete von allen ausgewählten SCIDs durchlaufen. Hinsichtlich der Effizienz und des Durchsatzes können die Sub-SCID-Adressen innerhalb von zehn Millisekunden geladen und mit einer einzelnen Operation deaktiviert und aktiviert werden.
In Schritt 114 in 3 rekonstruiert die Dekodiereinheit bei dem Satellitenempfänger den MPT-Frame 130' aus der Vielzahl von MPT-Paketen 140' (6). Der Flag-Header jedes MPT-Pakets wird ausgelesen, um zu bestimmen, ob es sich um das vordere MPT-Paket (beispielsweise SOF = 1, EOF = 0), ein mittleres MPT-Paket (beispielsweise SOF = 0, EOF = 0) oder das letzte Paket (beispielsweise SOF = 0, EOF = 1) handelt.
Das Folgende ist ein Beispiel eines IP-Datenpakets, das durch MPT-Pakete übertragen wird, um die Byte-Reihenfolge und Ausgaben zu veranschaulichen. In den unten angeführten Beispielen werden die Daten exakt so repräsentiert, wie sie aus dem Satellitennetzwerk ankommen, ebenso wie sie im Speicher gespeichert werden, Byte für Byte. Beispiel 1 zeigt ein MPT-Frame mit einem einzelnen Paket.
Das erste Byte „3F" ist der Flag-Header und der Wert „F" deutet an, dass sowohl das SOF- als auch das EOF-Bit auf „1" gesetzt ist. Entsprechend hat das MPT-Paket sowohl einen Adress-Header als auch einen CRC-Trailer.
Beispiel 2 zeigt ein Multipaket-MPT-Frame. In diesem Beispiel enthält der MPT-Frame zwei Pakete.
Der Flag-Header in dem ersten Paket ist „3E", was andeutet, dass das niederwertigste Bit (d.h. das EOF-Bit) eine „0" ist und das nächste Bit (d.h. das SOF-Bit) eine „1" ist. Auf diese Weise deuten die EOF- und SOF-Bits an, dass das erste Paket ein vorderes MPT-Paket ist. Der Flag-Header von „3D" in dem zweiten Paket legt ein SOF = 0 und EOF = 1 fest, was andeutet, dass das zweite Paket ein letztes MPT-Paket ist.
Da die MPT-Pakete beginnend mit dem vorderen MPT-Paket angeordnet sind, beginnt der Satellitenempfänger mit dem Erarbeiten eines CRC-Wertes. Multipaket-CRCs werden verwendet, um verlorene Pakete ebenso wie Pakete, die die FEC-Analyse passiert haben, jedoch noch undetektierte Fehler enthalten, zu detektieren. Unter den meisten Umständen werden aus dem Satellitennetzwerk mit Fehlern ankommende Pakete durch die FEC-Analyse detektiert und geeignete Maßnahmen unternommen. In einigen Fällen kommen jedoch Pakete an, die zu viele Fehler für das FEC zum Korrigieren enthalten, und die Fehler treten derartig auf, dass das FEC fehlerhafter Weise berichtet, dass alle Fehler korrigiert worden sind. Dieses Ereignis geschieht mit einer Rate von 1/N!, wobei N die Zahl der Bytes ist, die korrigiert werden kann. Bei dem DSS-System liegt die Wahrscheinlichkeit des Nichtdetektierens dieses Zustands und fehlerhaften Berichtens eines gültigen Pakets bei 2,48·10^–5. Eine wesentlich geringere Fehlerrate von weniger als 2,07·10^–17 wird gewünscht. Der 32 Bit lange CRC-Wert, der für jeden MPT- Frame zur Verfügung gestellt wird, ist geeignet für Signalbedingungen bei „Video-Schwellwerten" und wird die strenge Fehlerrate erreichen.
Der Sattelitenempfänger akkumuliert den CRC über eine Vielzahl von Paketen. Die CRC-Berechnung ist unabhängig von dem Sub-SCID-Filtern. Das letzte MPT-Paket ist erreicht, wenn das EOF in dem Flag-Header auf „1" gesetzt ist. Der CRC wird für alle Bytes in dem MPT-Frame 130' akkumuliert mit Ausnahme des vier Byte langen Trailers 162, der den CRC-Wert enthält. Der CRC-Wert umfasst dadurch die Flag-Header, die Datenfragmente und die sechs Byte lange Sub-SCID-Adresse des ersten MPT-Pakets. Dies entspricht dem vierten bis 130. Byte eines jeden DSS-Pakets (außer dem einen, das das letzte MPT-Paket enthält), das bei dem Satellitenempfänger empfangen wird. Der CRC wird in der Reihenfolge akkumuliert, Byte für Byte, von jedem DSS-Paket.
Wenn die EOF-Bedingung detektiert wird, wird der berechnete CRC-Wert mit dem als Trailer 162 in dem letzten MPT-Paket angefügten CRC-Wert verglichen. Als ein Beispiel wird der CRC-Wert in dem MPT-Paket in dem Network-Byte-Order-Format gespeichert, das auch als „Big Endian" bezeichnet wird. Dies bedeutet, dass das höchstwertige Byte des CRC in dem ersten Byte des CRC-Trailers 162 (d.h. im 127. Byte des DSS-Pakets) und das niederwertigste Byte des CRC in dem letzten Byte des CRC-Trailers 162 (d.h. dem 130. Byte des DSS-Pakets) enthalten ist. Ein Übereinstimmen des durch den Satellitenempfänger berechneten CRCs und dem als vier Byte langen Trailer 162 in dem letzten MPT-Paket angefügten CRC bescheinigt eine fehlerfreie Übertragung.
In einer Implementierung kann der Satellitenempfänger lediglich einen CRC-Akkumulator zum Berechnen des CRC-Werts unterstützen. MPT-Pakete, die zu verschiedenen MPT-Frames gehören (und daher unterschiedliche Sub-SCIDs aufweisen) werden nicht verschachtelt. Pakete für das nächste MPT-Frame werden erst genommen, nachdem das letzte MPT-Paket für das vorangegangene MPT-Frame erreicht worden ist. Auf der anderen Seite könnte in einer anderen Implementierung, bei der der Satellitenempfänger den Empfang von MPT-Paketen auf mehreren SCIDs unterstützt, jedes SCID einen entsprechenden CRC-Akkumulator aufweisen, einen für jedes MPT-Paket, das derzeit empfangen wird. Mehrere CRC-Akkumulatoren sind nützlich, da es keine Möglichkeit geben kann, das Beginnen und Beenden mehrerer MPT-Frames zwischen SCIDs zu synchronisieren.
Als eine beispielhafte Implementierung ist der durch einen DSS-kompatiblen Satellitenempfänger verwendete CRC-Algorithmus der gleiche CRC-Algorithmus, wie er durch den MPEG-2-Transportstrom – wie durch den Standard ISO/IEC 13818-1 definiert – verwendet wird. Der Algorithmus besteht aus dem Polynom:
1 + D + D² + D⁴ + D⁵ + D⁷ + D⁸ + D¹⁰ + D¹¹ + D¹² + D¹⁶ + D²² + D²³ + D²⁶ + D³²
Wie in der ISO/IEC 13818-1-Spezifikation ist der Anfangszustand der Summe 0xFFFFFFFF. Dies ist nicht der gleiche Algorithmus, der durch Ethernet verwendet wird.
In der oberen Diskussion wird die CRC-Berechnung durch den Satelliten-Empfänger durchgeführt. Alternativ kann die CRC-Berechnung durch einen Prozessor in den optischen Anzeigeeinheiten berechnet werden. Dies ist unten detaillierter beschrieben. Das Durchführen der CRC-Berechnung unter Verwendung des Prozessors verbraucht jedoch eine große Menge an verfügbaren Berechnungsressourcen. Entsprechend ist es bevorzugt, dass der CRC durch den Satellitenempfänger durchgeführt wird.
Falls die CRC-Analyse positiv ausfällt, besteht der nächste Schritt 116 der 3 in dem Extrahieren des Netzwerkdatenpakets 120' aus dem MPT-Frame 130'. In dem fortgesetzten Beispiel ist bei dem IP-Paket 120' die N Byte lange Datennutzinformation 122, der acht Byte lange UDP-Header 124 und der 20 Byte lange IP-Header 126 unversehrt geblieben. Zum Sicherstellen, dass das IP-Paket 120' mit dem Ethernet-Protokoll übereinstimmt, wird der in dem ersten MPT-Paket 140(1) gefundene Sub-SCID-Adress-Header 160 an den Anfang des IP-Pakets als ein Netzwerkzieladresse 170 (beispielsweise eine Ethernet-Zieladresse) platziert. Eine Netzwerkquelladresse 172 wird mit einer festen, gültigen Adresse (beispielsweise einer Ethernet-Quelladresse) aufgefüllt. Ein zwei Byte langes Protokoll 174 wird mit dem Protokoll aus dem Header 134 des MPT-Pakets 130' ohne Veränderung aufgefüllt. Irgendwelche Protokolloptionen aus dem Header 134 werden an das IP-Paket 120' ebenso wie alle folgenden MPT-Pakete angefügt, bis eine EOF-Bedingung erreicht ist.
Sobald die EOF-Bedingung erreicht ist, wird die CRC wie oben beschrieben überprüft und, falls der Vergleich erfolgreich war, die wahre Länge der Daten erfasst, das simulierte IP-Paket in den Speicher der optischen Anzeigeeinheit geschrieben und die optische Anzeigeeinheit informiert, dass ein IP-Paket angekommen ist.
Ein Alternativverfahren wäre, wenn die Netzwerkdatenpakete innerhalb des Prozessors der optischen Anzeigeeinheit wieder zusammengefügt werden. Die MPT-Pakete werden in den Hauptspeicher in der Reihenfolge geschrieben, in der sie ankommen. Das gesamte MPT-Paket 140' wird in den Speicher geschrieben. Zum Erhöhen der Leistung werden die Pakete in 128 Byte langen Blöcken angepasst, eher als einen Datenstrom von 127 Byte langen MPT-Paketen auszuschreiben. Das erste Byte wird in der Form von Füll- oder internen Flags geschrieben, das durch die Satellitenempfängerkarte zu welchem internen Zweck auch immer verwendet werden kann. Für Zwecke der Netzwerkdatenrekonstruktion wird dieses erste Byte jedoch als „don't care" angesehen. Die verbleibenden 127 Byte umfassen den Flag- und Adress-Header 144, 160 (falls ein erstes Paket vorliegt, sonst lediglich den ein Byte langen Flag-Header) und einen das Datenfragment enthaltenden Datenblock 142. Speicherpuffer sind vorzugsweise in Vielfachen von 128 Byte ausgestaltet. MPT-Pakete werden zum Anpassen an vier Byte lange Double-Word- oder „DWORD"-Grenzen geschrieben. Durch Schreiben der MPT-Pakete auf diese Art und Weise und durch Anpassen der Bytes auf vorhersagbare DWORD-Grenzen kann die auf gewöhnlichen Prozessoren laufende Software in einem höheren Maße optimiert werden, als dies durch Nichtanpassen der Daten möglich wäre.
Sogar in dem Fall, in dem die optische Anzeigeeinheit das Wiederzusammenfügen durchführt, ist es bevorzugt, dass der Satellitenempfänger die CRC-Berechnungen durchführt. Dies wird wegen der Berechnungsbelastung gewünscht, die entsteht, wenn von der Videoanzeigeeinheit das Durchführen dieser Berechnungen verlangt wird. Die Videoanzeigeeinheit wird zum Durchführen zeitkritischer Nutzerinterface aufgaben ebenso wie anderer Datenbearbeitungsaufgaben benötigt und jede unnötige Belastung wird bemerkt.
Der Satellitenempfänger stellt fest, ob der CRC durch das Einschließen der CRC-Bytes in die CRC-Berechnungen und das Schreiben des Ergebnisses statt des ursprünglichen CRC-Bytes gescheitert ist. Falls der CRC-Wert, der über die ursprünglichen Daten berechnet wurde, durch den CRC-Algorithmus als zusätzliche vier Bytes zugeführt wird, wird das neue CRC-Ergebnis den Wert 0 bei Erfolg und ungleich 0 bei Scheitern aufweisen.
Die Videoanzeigeeinheit führt dann die gleichen Operationen wie der Satellitenempfänger durch, um ein Paket zu erzeugen, das mit dem IP-Paket übereinstimmt.
7 zeigt das Interface zwischen dem Satellitenempfänger und Dekodiereinheit und einer Softwareanwendung, die auf dem Computer bei der optischen Anzeigeeinheit läuft. Eine Satellitenempfängerbaugruppe 200 platziert die wiederhergestellten Netzwerkdatenpakete auf dem PC-Bus 202. Ein Miniport-Treiber 204 und ein geschichteter Miniport-Treiber 206 („layered miniport driver") sind zum Empfangen der Pakete aus dem PC-Bus 202 verbunden. In dem dargestellten Beispiel genügt der Treiber der Spezifikation NDIS (Network Device Interface Specification) 4.0, was durch die Interfaceschicht 208 dargestellt ist.
Das wieder zusammengesetzte Netzwerkdatenpaket wird dem IP-Software-Interface 210 weitergegeben, das einige rudimentäre Fehlerprüfungen auf Netzwerkdatenpaketebene (beispielsweise Header-Prüfsumme) und Filtern durchführt. An diesem Punkt ist das Netzwerkdatenpaket in der Reihenfolge, um durch die Winsock-Schicht 212 – einem durch Software implementierten Interface, das der Windows-Sockets-Spezifikation entspricht – gehandhabt zu werden. Die Windows-Sockets-Spezifikation definiert einen bekannten Standardssatz von APIs, die eine netzwerkunabhängige Methode zum Senden und Empfangen von Daten zur Verfügung stellt. Eine Anwendung 214 verwendet die Netzwerkdatenpakete durch verschiedene API-Aufrufe, die durch die Winsock-Schicht 212 geordnet werden.
Die Erfindung ist dahingehend vorteilhaft, dass sie eine Technik zum Übertragen von Netzwerkdaten über ein Satellitensystem ohne den Verlust seines bekannten Formats vorschreibt. Eine Computeranwendung bei dem Empfänger kann Standard-APIs – wie beispielsweise die durch die Windows-Sockets-Spezifikation vorgeschriebenen APIs – für den Zugriff und das Nutzen der Netzwerkdaten verwenden.
Es sei bemerkt, dass Aspekte der Erfindung für andere Netzwerkarten als Satellitennetzwerke verwendet werden kann. Die MPT-Frame- und MPT-Paket-Struktur kann für die Verwendung mit anderen Netzwerken, einschließlich Ethernet und Internet, modifiziert werden.
Gemäß den Statuten ist die Erfindung in einer mehr oder weniger auf die strukturellen und methodologischen Merkmale zugeschnittenen Sprache beschrieben worden. Es ist Jedoch zu verstehen, dass die Erfindung durch den Umfang der angehängten Ansprüche beschränkt ist.

Claims

Verfahren zum Kodieren von IP (internet protocol)-Daten in ein Format zur Übertragung über ein Satellitensystem (30), das die folgenden Schritte umfasst: Empfangen eines IP-Pakets (120) mit einem IP-Datenblock (142(1), (2), ..., (n)) und Header-Information, Kodieren des IP-Pakets (120) in ein MPT (multi-packet transport)-Frame (130) mit variabler Länge, das einen Datenframe und Header-Information enthält, derart, dass der Datenframe des MPT-Frames das IP-Paket (120) umfasst und Kodieren des MPT-Frames (130) mit variabler Länge in eine Vielzahl von MPT-Pakete (140(1), (2), ..., (n)) mit fester Länge, wobei jedes MPT-Paket (140(1), (2), ..., (n)) einen Datenfragmentblock (142) aufweist, der zumindest einen Teil des MPT-Frames (130) und zugehörige Header-Information zum Kennzeichnen, welcher Teil des MPT-Frames (130) in dem Datenfragmentblock (142(1), (2), ..., (n)) enthalten ist, umfasst, worin lediglich das eine aus der Vielzahl der MPT-Pakete (140(1), (2), ..., (n)), das den Endteil des MPT-Frames enthält, Fehlerkorrekturinformation für den Frame enthält, die mit dem gesamten Datenframe innerhalb des MPT-Frames (130) mit variabler Länge in Verbindung gebracht werden.
Verfahren nach Anspruch 1, worin die Header-Information jedes MPT-Pakets (140(1), (2), ..., (n)) kennzeichnen, ob die Daten, die in dem zugehörigen Datenfragmentblock (142(1), (2), ..., (n)) enthalten sind, von einem Anfangsteil des MPT-Frames (130), einem Endteil des MPT-Frames (130) oder einem Mittelteil des MPT-Frames (130) stammen.
Verfahren nach Anspruch 2, worin die Header-Information eines jeden MPT-Pakets (140(1), (2), ..., (n)) einen ein Byte langen Header (144) mit einem den Frame-Anfang kennzeichnenden Bit (150), das in dem Fall gesetzt wird, dass die in dem zugehörigen Datenfragmentblock des MPT-Pakets (140(1), (2), ..., (n)) enthaltenen Daten den Anfangsteil des MPT-Frames (130) umfassen, und mit einem das Frame-Ende kennzeichnenden Bit (152) umfasst, das in dem Fall gesetzt wird, dass die in dem zugehörigen Datenfragmentblock (142(1), (2), ..., (n)) des MPT-Pakets (140(1), (2), ..., (n)) enthaltenen Daten den Endteil des MPT-Frames (130) umfassen, wobei das den Frame-Anfang kennzeichnende Bit (150) und das das Frame-Ende kennzeichnende Bit (152) beide zurückgesetzt werden, falls die in dem zugehörigen Datenfragmentblock (142(1), (2), ..., (n)) des MPT-Pakets (140(1), (2), ..., (n)) enthaltenen Daten den Mittelteil des MPT-Frames (130) umfassen.
Verfahren nach Anspruch 2 oder 3, worin die Header-Information jedes MPT-Pakets (140(1), (2), ..., (n)) eine mehrere Byte lange Adresse in einem Fall umfasst, dass die in dem zugehörigen Datenfragmentblock (142(1), (2), ..., (n)) enthaltenen Daten den Anfangsteil des MPT-Frames (130) umfassen.
Verfahren nach einem der vorangegangenen Ansprüche, das zusätzlich den Schritt des Berechnens der Fehlerkorrekturinformation für all die MPT-Pakete (140(1), (2), ..., (n)), in die der MPT-Frame kodiert worden ist, umfasst.
Verfahren nach einem der vorangegangenen Ansprüche, das zusätzlich den Schritt des Anhängens der Fehlerkorrekturinformation lediglich an das eine der MPT-Pakete (140(1), (2), ..., (n)), das den Endteil des MPT-Frames enthält, umfasst.
Verfahren nach einem der vorangegangenen Ansprüche, das zusätzlich den Schritt des Hinzufügens eines Headers, der eine Adresse umfasst, und eines Trailers (162) mit Fehlerkorrekturinformation an jedes MPT-Paket (140(1), (2), ..., (n)) mit fester Länge umfasst, um satelliten-transportable Pakete zu bilden.
Verfahren nach Anspruch 7, das zusätzlich den Schritt des Übertragens der satelliten-transportablen Pakete umfasst.
Verfahren nach Anspruch 1, worin die Header-Information des MPT-Frames umfasst: einen Transportprotokoll-Header (124) und einen IP-Header (126) und worin der Schritt des Kodierens des IP-Pakets (120) umfasst die Schritte: des Aufbauens des MPT-Frames (130) mit variabler Länge, der einen Daten-Frame (122) und einen Header aufweist, des Einfügens des gesamten IP-Pakets (120) in den Daten-Frame (122) des MPT-Frames (130) und des Aufbauens eines oder mehrerer mehrere Byte langer MPT-Pakete (140(1), (2), ..., (n)) fester Größe aus dem MPT-Frame (130), wobei jedes MPT-Paket (140(1), (2), ..., (n)) zumindest einen Header zum Kennzeichnen, welcher Teil des MPT-Frames (130) in dem MPT-Paket (140(1), (2), ..., (n)) enthalten ist, umfasst.
Verfahren nach Anspruch 9, das zusätzlich den Schritt des Berechnens der Fehlerkorrekturinformation für all die MPT-Pakete (140(1), (2), ..., (n)), in die der MPT-Frame kodiert worden ist, umfasst.
Verfahren nach Anspruch 9 oder 10, das zusätzlich den Schritt des Anhängens der Fehlerkorrekturinformation als einen mehrere Byte langen Trailer (162) lediglich an das eine der MPT-Pakete (140(1), (2), ..., (n)), das den Endteil des MPT-Frames enthält, umfasst.
Verfahren nach einem der vorangegangenen Ansprüche, das zusätzlich den Schritt des Übertragens der MPT-Pakete (140(1), (2), ..., (n)) umfasst.
Verfahren nach Anspruch 1, wobei das Verfahren die folgenden Schritte umfasst: Hinzufügen eines Headers zu einem Netzwerkdatenpaket (120) zum Bilden eines MPT-Frames (130) mit variabler Länge, Segmentieren des MPT-Frames (130) in einen oder mehrere Datenfragmentblöcke (142(1), (2), ..., (n)) und Hinzufügen eines Headers an jeden Datenfragmentblock (142(1), (2), ..., (n)) zum Bilden von MPT-Paketen (140(1), (2), ..., (n)) mit fester Länge und mit einer zur Übertragung über ein Verteilsystem geeigneten Größe.
Verfahren nach Anspruch 13, worin der Header jedes MPT-Pakets (140(1), (2), ..., (n)) kennzeichnet, ob die in einem zugehörigen Datenfragmentblock (142(1), (2), ..., (n)) enthaltenen Daten von einem Anfangsteil des MPT-Frames (130), einem Endteil des MPT-Frames (130) oder einem Mittelteil des MPT-Frames (130) stammt.
Verfahren nach Anspruch 13 oder 14, worin der Header jedes MPT-Pakets (140(1), (2), ..., (n)) einen ein Byte langen Header (144(1), (2), ..., (n)) mit einem den Frame-Anfang kennzeichnenden Bit (150), das in dem Fall gesetzt wird, dass die in dem zugehörigen Datenfragmentblock (142) des MPT-Pakets (140(1), (2), ..., (n)) enthaltenen Daten den Anfangsteil des MPT-Frames (130) umfasst, und mit einem das Frame-Ende kennzeichnenden Bit (152) umfasst, das in dem Fall gesetzt wird, dass die in dem zugehörigen Datenfragmentblock (142) des MPT-Pakets (140(1), (2), ..., (n)) enthaltenen Daten den Endteil des MPT-Frames (130) umfasst, wobei das den Frame-Anfang kennzeichnende Bit (150) und das das Frame-Ende kennzeichnende Bit (152) beide zurückgesetzt werden, falls die in dem zugehörigen Datenfragmentblock (142) des MPT-Pakets (140) enthaltenen Daten den Mittelteil des MPT-Frames (130) umfassen.
Verfahren nach einem der Ansprüche 13 bis 15, das zusätzlich den Schritt des Hinzufügens von Füllbits als einen Trailer (136) an das Netzwerkdatenpaket (122) zum Bilden des MPT-Frames (130) umfasst.
Verfahren nach einem der Ansprüche 13 bis 16, worin der Schritt des Hinzufügens eines Headers zu jedem Datenfragmentblock den Schritt des Hinzufügens eines Headers umfasst, der kennzeichnet, welcher Teil des MPT-Frames (130) in dem Datenfragmentblock (142(1), (2), ..., (n)) enthalten ist.
Verfahren nach einem der Ansprüche 13 bis 17, das zusätzlich den Schritt des Hinzufügens einer Adresse zu dem Datenfragmentblock (142(1), (2), ..., (n)), der den Anfangsteil des MPT-Frames enthält, umfasst.
Verfahren nach einem der Ansprüche 13 bis 18, das zusätzlich den Schritt des Berechnens der Fehlerkorrekturinformation für all die MPT-Pakete (140(1), (2), ..., (n)), in die der MPT-Frame kodiert worden ist, umfasst.
Verfahren nach einem der Ansprüche 13 bis 19, das zusätzlich den Schritt des Anhängens der Fehlerkorrekturinformation lediglich an das eine der MPT-Pakete (140(1), (2), ..., (n)), das den Endteil des MPT-Frames enthält, umfasst.
Verfahren nach einem der Ansprüche 13 bis 20, das zusätzlich den Schritt des Hinzufügens eines Headers, der eine Adresse umfasst, und eines Trailers mit Fehlerkorrekturinformation (162) zu jedem MPT-Paket (140(1), (2), ..., (n)) mit fester Länge zum Bilden von satelliten-transportablen Paketen umfasst.
Verfahren nach Anspruch 21, das zusätzlich den Schritt des Übertragens der satelliten-transportablen Pakete über ein Satellitenverteilsystem umfasst.
Verfahren zum Dekodieren von Computernetzwerkdaten aus einem Satellitenübertragungssignal, das die folgenden Schritte umfasst: Empfangen mehrerer Satellitenpakete, wobei die einzelnen Satellitenpakete (20) eine Datennutzinformation (24) aufweisen, Entfernen der Datennutzinformationen (24) aus den Satellitenpaketen (20), wobei jede Datennutzinformation (24) ein MPT-Paket (140(1), (2), ..., (n)) mit fester Länge aufweist, das einen Datenfragmentblock (142(1), (2), ..., (n)) und zugehörige Header-Informationen (144(1), (2), ..., (n)) aufweist, Verwenden der Header-Informationen (144(1), (2), ..., (n)) des MPT-Pakets zum Anordnen der MPT-Pakete (140(1), (2), ..., (n)) in einen MPT-Frame (130) mit variabler Länge, worin der MPT-Frame mit variabler Länge aus einem Header und einem die Computernetzwerkdaten enthaltenden Datenframe besteht und worin lediglich das eine der MPT-Datenpakete (140(1), (2), ..., (n)), das den Endteil des MPT-Frames mit variabler Länge enthält, Fehlerkorrekturinformation für den Frame umfasst, wobei die Fehlerkorrekturinformation mit dem gesamten Daten-Frame innerhalb des MPT-Frames (130) mit variabler Länge in Verbindung gebracht werden, Wiederherstellen des MPT-Frames (130) aus den Datenfragmentblöcken (142(1), (2), ..., (n)) der MPT-Pakete (140(1), (2), ..., (n)), Extrahieren der Computernetzwerkdaten aus dem wiederhergestellten MPT-Frame (130) und Extrahieren der Fehlerkorrekturinformation und Verwenden dieser zum Überprüfen der Computernetzwerkdaten hinsichtlich Fehler.
Kodiereinheit (70) zum Kodieren von Netzwerkdatenpaketen in ein Format zur Übertragung über ein Satellitensystem (30), das umfasst: Mittel zum Hinzufügen eines Headers (134) zu einem Netzwerkdatenpaket, zum Bilden eines MPT-Frames (130) mit variabler Länge und Mittel zum Segmentieren des MPT-Frames (130) in eine Vielzahl von Datenfragmentblöcke (142(1), (2), ..., (n)), Mittel zum Hinzufügen eines Headers (144(1), (2), ..., (n)) zu jedem Datenfragmentblock (142(1), (2), ..., (n)) zum Bilden von MPT-Paketen (140(1), (2), ..., (n)) mit fester Länge und mit einer für die Übertragung über das Satellitensystem (30) geeigneten Größe, Mittel zum Berechnen von Fehlerkorrekturinformation für die MPT-Pakete (140(1), (2), ..., (n)) aus dem gesamten Daten-Frame innerhalb des MPT-Frames (130) mit variabler Länge und Mittel zum Hinzufügen der Fehlerkorrekturinformation zu lediglich dem einen der MPT-Pakete (140(1), (2), ..., (n)), das den Endteil des MPT-Frames enthält.
Kodiereinheit (70) nach Anspruch 24, worin der Header für die MPT-Pakete (140(1), (2), ..., (n)) kennzeichnet, welcher Teil des MPT-Frames (130) in dem Datenfragmentblock (142(1), (2), ..., (n)) enthalten ist.
Kodiereinheit (70) nach Anspruch 24 oder 25, die zusätzlich Mittel zum Hinzufügen von Füllbits als einen Trailer (162) zu dem Netzwerkdatenpaket zum Bilden des MPT-Frames (130) umfasst.
Kodiereinheit (70) nach einem der Ansprüche 24 bis 26, die zusätzlich Mittel zum Hinzufügen einer Adresse zu den Datenfragmentblock (142), der den Anfangsteil des MPT-Frames enthält, umfasst.
Kodiereinheit (70) nach einem der Ansprüche 24 bis 27, die zusätzlich Mittel zum Hinzufügen eines Headers, der eine Adresse umfasst, und eines Trailers (162) mit Fehlerkorrekturinformation zu jedem MPT-Paket (140(1), (2), ..., (n)) zum Bilden von satelliten-transportablen Paketen umfasst.
Satellitenübertragungssystem (30), das umfasst: eine Kodiereinheit (70) zum Kodieren eines Computernetzwerkdatenpakets in eines oder mehrere Satellitenpakete, wobei die Kodiereinheit (70) gemäß Patentanspruch 24 zusätzlich dazu ausgestaltet ist, Header-/Trailer-Information (162) zu jedem MPT-Paket (140(1), (2), ..., (n)) hinzuzufügen, um eines oder mehrere Satellitenpakete (20) zu bilden, eine Satellitenübertragungseinheit (40), die zum Empfangen von Satellitenpaketen (20) von der Kodiereinheit (70) verbunden ist, wobei die Satellitenübertragungseinheit (40) die Satellitenpakete (20) über ein Satellitennetzwerk (38) überträgt, eine Empfangseinheit (44) zum Empfangen der Satellitenpakete (20) von dem Satellitennetzwerk (38) und eine Dekodiereinheit, die mit der Empfangseinheit verbunden ist, wobei die Dekodiereinheit ausgestaltet ist zum (i) Wiedererlangen der MPT-Pakete (140(1), (2), ..., (n)) aus den Satellitenpaketen, (ii) Wiederherstellen des MPT-Frames (130) aus den MPT-Paketen (140(1), (2), ..., (n)), (iii) Extrahieren der Fehlerkorrekturinformation, die mit dem gesamten MPT-Frame in Verbindung gebracht werden, aus dem einen der MPT-Pakete (140(1), (2), ..., (n)), das den Endteil des MPT-Frames enthält, (iv) Überprüfen des gesamten Datenframes innerhalb des MPT-Frames (130) mit variabler Länge hinsichtlich Fehler unter Verwendung der Fehlerkorrekturinformation und (v) Extrahieren des Computernetzwerkdatenpakets aus dem MPT-Frame (130).
System nach Anspruch 29, worin die Empfangseinheit dazu ausgestaltet ist, die Satellitenpakete aus einer vertikalen Austastlücke („Verticle Blanking Interval", VBI) eines Rundfunkvideosignals zu empfangen.
System nach Anspruch 29 oder 30, worin die Empfangseinheit umfasst: einen Empfänger zum Empfangen mehrerer Satellitenpakete, wobei die einzelnen Satellitenpakete eine Datennutzinformation (132) aufweisen, die ein MPT-Paket (140) mit fester Länge umfasst, wobei jedes MPT-Paket (140) einen Datenfragmentblock (142) und zugehörige Header-Informationen umfasst und einen Gerätetreiber, der mit dem Empfänger verbunden ist, wobei der Empfänger oder der Gerätetreiber zum Entfernen der MPT-Pakete (140) aus den Satellitenpaketen und zum Verwenden der Header-Informationen des MPT-Pakets (140) zum Anordnen der MPT-Pakete (140) in einem MPT-Frame (130) mit variabler Länge ausgestaltet ist, wobei der Empfänger oder der Gerätetreiber zum Wiederherstellen des MPT-Frames (130) aus den Datenfragmentblöcken (142) der MPT-Pakete (140) und zum Extrahieren des Computernetwerkdatenpakets aus dem wiederhergestellten MPT-Frame (130) ausgestaltet ist.