-
Gebiet der Erfindung
-
Die
vorliegende Erfindung betrifft ein Paketübertragungsverfahren für die Übertragung
und den Empfang von Paketen zwischen einer Vielzahl von Datenterminals,
einer Relais-Vorrichtung und einem Datenterminal, das für die Paketübertragung
genutzt wird.
-
Stand der Technik
-
In
der letzten Zeit ist der Bedarf für die Übermittlung von Daten wie Videodaten
oder Audiodaten, die eine Echtzeitübertragung benötigen, angestiegen.
-
Um
den Bedarf zu decken, wurde als Protokoll ein RTP (Realtime Transport
Protocol), herausgebracht, das von der IETF (Internet Engineering Task
Force), einer Gruppe zur Standardisierung des Internets, vorgeschlagen
wurde. Das RTP hat Funktionen wie 1) Spezifikationen für einen
Nutzungstyp, 2) Zuweisung einer Sequenznummer und 3) Zuweisung eines
Zeitstempels. Diese Regeln erlauben es, solche Informationen wie
Audio- und Video-Daten in Echtzeit über das Internet zu übertragen.
Normalerweise wird das RTP als eine obere Schicht für das IP (Internet
Protocol) auf einer Netzwerkschicht und dem UDP (User Datagram Protocol)
als Transportschicht genutzt.
-
13A zeigt den Inhalt eines RTP-Header, eines UDP-Header
und eines IP-Header (im Folgenden als "RTP/UDP/IP-Header" bezeichnet), der an Daten wie Audio-
und Video-Daten, die entsprechend dem RTP, UDP und IP übertragen
werden sollen, angefügt
ist. Im folgenden wird ein Paket, das einen RTP/UDP/IP-Header beinhaltet,
IP-Paket genannt.
-
Wie
in der Zeichnung dargestellt benötigt
der IP-Header 20 Bytes, der UDP-Header 8 Bytes und der RTP-Header
12 Bytes, so dass der Gesamtwert der RTP/UDP/IP-Header 40 Bytes
erreicht. Im Gegensatz dazu bestehen Video-Daten in einem IP-Paket
zum Beispiel ungefähr
aus 50 Bytes. Zur Übertragung
solcher Bilddaten in Form von Paketen erreicht der Overhead deshalb
nicht weniger als 44 Prozent. In ähnlicher Weise erreicht der
Overhead bei der Übertragung
von Audio-Daten, welche 20 Bytes in einem Paket beinhalten, bereits
66 Prozent. Weil eine tatsächliche Übertragung
Header für
andere Schichten zusätzlich
benötigt,
belegt der gesamte Header einen großen Prozentsatz eines Paketes
und bewirkt so eine Belastung durch eine Reduzierung der Effizienz
in der Kommunikation.
-
Als
eine Technik, um diese Beeinträchtigung zu überwinden,
zeigt die RFC2508, die vom IETF herausgegeben wurde, ein RTP-Kompressionsprotokoll zur
Komprimierung des RTP/UDP/IP-Header.
Das RTP-Kompressionsprotokoll erlaubt, den RTP/UDP/IP-Header, der
in 13A dargestellt ist, in einen Header, wie in 13B beispielhaft dargestellt (in Folgendem
als ein „komprimierter
Header" bezeichnet),
zu komprimiert. Diese Komprimierung wird im Folgenden genau beschrieben.
-
Das
Verfahren der Kompression wird zwischen zwei Knoten eines Netzwerks,
durch das beispielsweise Pakete zwischen einer Vielzahl von Datenterminals übertragen
werden, angewendet. Genauer gesagt konvertiert ein Knoten (in Folgendem als
ein "Senderknoten" bezeichnet) den RTP/UDP/IP-Header
von einem Teil der IP-Pakete, die zwischen den Datenterminals versendet
werden, in einen komprimierten Header und überträgt ihn als einen Kopfdatensatz-komprimiertes
Paket (header-compressed packet) an den anderen Knoten (in Folgendem
als ein "Empfängerknoten" bezeichnet). Gleichzeitig
sendet der Senderknoten die RTP/UDP/IP-Header der andere Teile der
IP-Pakete als ein
Paket mit einem vollständigen
Header (fullheader packet) ohne Komprimierung. Der Empfängerkonten
dekomprimiert (das heißt,
restauriert) das Kopfdatensatzkomprimierte Paket in ein IP-Paket oder
ein Paket mit einem vollständigen
Header, das von dem Senderknoten empfangen wurde, und sendet es
an den nächsten
Knoten oder ein empfangendes Datenterminal. Der vollständige Header
ist ein Header, bei welchem der Begriff „Länge", der in dem RTP/UDP/IP-Header, wie
in 13A dargestellt, enthalten ist, durch Informationen
inklusive einer CONTEXT_ID zur Identifikation der RTP-Verbindung und
einer Verbindungssequenznummer link_seq – einer Seriennummer, die in
der Reihenfolge der Übertragungen
vom Senderknoten vergeben wird – ersetzt
wird. (In Folgendem werden die Begriffe Header und Kopfdatensatz
als Synonyme benutzt).
-
Der
Inhalt des komprimierten Header, der in 13B dargestellt
ist, wird nun erklärt.
Die Daten der Sektionen mit enger Straffierung in dem RTP/UPD/IP-Header
in 13A, die eine Versionsnummer (V), eingetragen
in den IP-Header, und den Nutzungstyp, eingetragen in den RTP-Header,
beinhalten, sind für
jedes vom Senderknoten zu übertragende
Paket konstante Daten (im Folgenden als "statische Felder" bezeichnet). Deshalb enthält der komprimierter
Header, wie in 13B dargestellt, keine Daten
von statischen Feldern. Wenn der Senderknoten das erste IP-Paket
eines Paketstromes an den Empfängerknoten
sendet, sendet es ein "Full-Header"-Paket mit einem vollständigen Header
inklusive der statischen Felder. Danach konvertiert der Senderknoten
die RTP/UDP/IP-Header
der nachfolgenden IP-Pakete in komprimierte Header, der keine statische
Felder enthält.
Die so konvertierten, komprimierten Kopfdatensätze werden an den Empfängerknoten
als Kopfdatensatz-komprimierte Pakete (header-compressed packet)
gesendet. Wenn der Empfängerknoten
ein Paket mit dem vollständigen
Header, der dem ersten IP-Paket entspricht, empfängt, restauriert der Empfängerknoten
die empfangenen RTP/UDP/IP-Header mit Referenz auf den vollständigen Header
des ersten empfangenen Paketes mit einem vollständigen Header und schreibt
den so dekomprimierten Kopfdatensatz (Header) in eine interne Speichervorrichtung.
Danach nutzt der Empfängerknoten
die statischen Feldern der RTP/UDP/IP-Header, um die statischen
Feldern des komprimierten Kopfdatensatzes in den Kopfdatensatz-komprimierten
Paketen, die erfolgreich nach dem ersten Paket empfangen wurden,
zu restaurieren.
-
Die
Daten in den statischen Feldern sind nicht immer über alle
IP-Pakete konstant, sondern können
abhängig
von einem bestimmten IP-Paket geändert
werden. Wenn ein solcher Wechsel in einem bestimmten IP-Paket passiert,
wird der Senderknoten ein Paket mit einem vollständigen Header, der dem RTP/UDP/IP-Header entspricht,
an den Empfängerknoten
ohne Komprimierung übertragen.
-
Die
Daten in den Abschnitten ohne Straffierung bei dem RTP/UDP/IP-Header,
wie in 13A dargestellt, enthalten die
Sequenznummer und den Zeitstempel des RTP-Header genauso wie die
ID des IP-Header. Der Zeitstempel weist auf die Zeit hin, zu welcher
ein Paket übertragen
oder generiert wurde. Es wird erwartet, dass solche Daten konstante
Differenzwerte (Änderungsgrößen) zwischen
zwei aufeinanderfolgende IP-Pakete,
die in Folge übermittelt werden,
haben. Im Folgenden werden Felder mit solchen Daten als "Delta-Felder" bezeichnet. Wie
in 13B dargestellt, enthält der komprimierte
Basis-Header nicht die Daten in den Delta- Feldern. Wie oben beschrieben fügt der Empfängerknoten,
der RTP/UDP/IP-Header in seiner Speichervorrichtung bevorratet,
Differenzwerte hinzu, die vorher entsprechend den Werten der entsprechenden
Delta-Feldern der gespeicherten RTP/UPD/IP-Header gespeichert wurden, so dass es
dem Empfängerknoten
ermöglicht
wird, Delta-Felder von komprimierten Header, die fortlaufend danach
empfangen werden, zu dekomprimieren.
-
Dennoch
ist es nicht immer richtig, dass die Differenzwerte in den Delta-Feldern
zwischen den IP-Paketen konstant sind. Es gibt einige Fälle, wo Veränderungen
an ihren Differenzwerten gemacht werden. In solchen Fällen müssen veränderte Differenzwerte
dem Empfängerknoten
angezeigt werden. Der Empfängerknoten
ist in der Lage, die Inhalte in den Delta-Feldern, die in den RTP/UDP/IP-Header eines
jeden Kopfdatensatz-komprimierten Paketes, die danach empfangen
werden, enthalten sind, mit Referenz auf den Inhalt der RTP/UDP/IP-Header,
die in der Speichervorrichtung gehalten werden, und den angezeigten
Differenzwerten zu restaurieren. Zu diesem Zweck hat der komprimierte
Kopfdatensatz, der in 13A dargestellt
ist, Bitschalter (Flags) S, T, und I, die repräsentieren, ob die Differenzwerte
in den Delta-Feldern
geändert
wurden oder nicht. Wenn irgendein Differenzwert geändert wurde,
werden die neuen Differenzwerte zu dem komprimierten Kopfdatensatz,
wie in den gestrichelten Linien in 13B dargestellt,
hinzugefügt.
Praktisch bedeutet das, dass wenn es eine Veränderung in den Differenzwerten
der Sequenznummer des RTP-Header gibt, wird der Bitschalter S auf "1" gesetzt und ein Sequenznummerdifferenzwert
(Delta-RTP-Sequenz), der den neuen Differenzwert der Sequenznummer
anzeigt, wird zudem komprimierten Kopfdatensatz hinzugefügt, wie
es durch die gestrichelte Linie in 13B dargestellt
ist. Auf die gleiche Weise wird der Bitschalter T auf "1" gesetzt, wenn es eine Veränderung in
dem Differenzwert des Zeitstempels des RTP-Header gibt, und ein
Zeitstempeldifferenzwert (Delta-RTP-Zeitstempel), der den neuen Differenzwert des
Zeitstempels anzeigt, wird an den komprimierten Kopfdatensatz angefügt, wie
es durch die gestrichelte Linie in 13B dargestellt
ist. Ferner wird der Bitschalter I auf "1" gesetzt,
wenn es eine Veränderung in
dem Differenzwert der ID des IP-Header gibt, und ein ID-Differenzwert
(Delta-IP-ID), der den neuen Differenzwert der ID anzeigt, wird
dem komprimierten Header angefügt.
-
Wie
in 13B dargestellt, enthält der komprimierte
Kopfdatensatz zusätzlich
die CONTEXT_ID und link_seq genauso wie der vollständige Header. Der
Empfängerknoten
dekomprimiert den komprimierten Kopfdatensatz gemäß dem Inhalt
der RTP/UDP/IP-Header, die durch die CONTEXT_ID spezifiziert sind.
Der Empfängerknoten
greift auf die Verbindungssequenznummer link_seq eines jeden Paketes
(Kopfdatensatz-komprimiertes Paket oder "full-header" Paket), das in Reihenfolge von dem Senderknoten
gesendet wurde, zurück.
Wenn sich herausstellt, dass einige Verbindungssequenznummern verloren
gingen, stellt der Empfängerknoten fest,
dass die Pakete zwischen dem Sender- und dem Empfängerknoten verloren gingen.
-
Bezugnehmend
auf 14 werden nun Prozeduren, die für die Paketübertragung
zwischen dem Sender- und dem Empfängerknoten vorgesehen sind,
beschrieben. In 14 zeigt ein Feld A ein statisches
Feld des RTP/UDP/IP-Header (das heißt, irgendein Datenfeld mit
der schrägen
Schraffur in 13A), und ein Feld B zeigt ein
Delta-Feld (das heißt,
irgendein Datenfeld ohne Schraffur in 13A).
Weiterhin repräsentiert "F" in 14 ein Paket
mit einem vollständigen
Header, während "C" ein Kopfdatensatzkomprimiertes Paket
repräsentiert.
-
Wenn
ein IP-Paket a empfangen wird, das von einem sendenden Datenterminal
an ein empfangendes Datenterminal übertragen wird, speichert der Senderknoten
die RTP/UDP/IP-Header des IP-Paketes a in seine interne Speichervorrichtung.
-
Gleichzeitig
produziert der Senderknoten einen vollständigen Header durch die Substitution
von „Länge" im Header durch
eine CONTEXT_ID und eine Verbindungssequenznummer link_seq und überträgt das Paket
mit dem vollständigen
Header inklusive sowohl des produzierten vollständigen Header als auch der
Daten (nachstehend als RTP-Nutzdaten bezeichnet), die Teil des IP-Paketes
inklusive der RTP/UDP/IP-Header sind (vgl. „OP1" in 14) an
den Empfängerknoten.
Der Empfängerknoten, welcher
dieses Paket mit vollständigem
Header empfängt,
restauriert die RTP/UDP/IP-Header aus dem vollständigen Header dieses Paketes
(insb. werden CONTEXT_ID und link_seq aus dem vollständigen Header
extrahiert) und überträgt das IP-Paket
mit diesem Header an den nächsten
Knoten oder ein empfangendes Datenterminal. In diesem Vorgang werden
die dekomprimierten RTP/UDP/IP-Header in der internen Speichervorrichtung
gespeichert.
-
Der
Senderknoten konvertiert dann die RTP/UDP/IP-Header in dem IP-Paket
b, das nach dem IP-Paket a empfangen wurde, in einen komprimierten
Header und überträgt das Paket
b mit dem komprimierten Header an den Empfängerknoten (vgl. „OP2" in 14).
In das Kopfdatensatz-komprimierte Paket in dem komprimierten Header
wird ein Differenzwert ΔB
(=1) zwischen einem Wert [1] in den Datenfeld B des Paketes b und
einem Wert [0] in dem Datenfeld B des letzten Paketes a addiert,
wobei ein Wert "1" bei den Bitschaltern
(Flags S, T und I wie in 13B dargestellt),
die die Veränderung
oder Nicht- Veränderung
bei den Differenzwerten repräsentiert,
gesetzt wird.
-
Der
Empfängerknoten,
der ein Kopfdatensatz-komprimiertes Paket b empfängt, erhält die Deltafeldern B des komprimierten
Headers des Kopfdatensatz-komprimierten Paketes b durch die Addition der
Differenzwerte ΔB,
auf die in diesem Paket verwiesen wurde, zu dem Wert des Deltafeldes
B der RTP/UDP/IP-Header des letzten IP-Paketes a, das in der internen
Speichervorrichtung gespeichert ist. Der Empfängerknoten überträgt dann ein IP-Paket b, das sowohl
die RTP/UDP/IP-Header, welche die Deltafelder B enthalten, als auch
die statischen Feldern A der RTP/UDP/IP-Header des IP-Paketes a enthalten
und die RTP-Nutzdaten. Die RTP/UDP/IP-Header auf die durch die Dekomprimierung
des IP-Paketes b Bezug genommen wird (in diesem Fall die RTP/UDP/IP-Header,
die von dem letzten IP-Paket a extrahiert wurden), ist durch die
CONTEXT_ID des Kopfdatensatz-komprimierten Paketes b beschrieben.
Der RTP/UDP/IP-Header des IP-Paketes b und der Differenzwert ΔB, auf den
in diesem Paket hingewiesen wurde, werden auch in dem internen Speicher
gespeichert.
-
Wenn
als nächstes
ein IP-Paket c empfangen wird, kalkuliert der Senderknoten einen
Differenzwert zwischen Werten der Deltafelder B von sowohl dem IP-Paket
c als auch dem letzten IP-Paket b. Der Referenzwert ΔB ist in
diesem Fall [1] (= 3 – 2), welcher
der gleiche wie der vorangegangene, auf denen der Empfängerknoten
das letzte Mal hingewiesen wurde, ist. Deshalb gibt es keine Notwendigkeit den
Empfängerknoten
erneut auf den unveränderten Differenzwert
hinzuweisen. Daher überträgt der Senderknoten
an den Empfängerknoten
ein Kopfdatensatz-komprimiertes Paket c, das einen komprimierten Header
ohne Differenzwerte (das heißt,
Informationen, die durch die gestrichelte Linie in 13B dargestellt
sind, vgl. „OP3" in 14)
hat. Der Empfängerknoten,
der dieses Kopfdatensatz-komprimierte Paket c empfängt, addiert
den gespeicherten Differenzwert ΔB
zu den Deltafeldern B des vorangegangenen Paketes b, wobei die Deltafelder
B des komprimierten Header des Kopfdatensatz-komprimierten Paketes
dekomprimiert werden. Dann sendet der Empfängerknoten ein IP-Paket c, das sich
aus sowohl den RTP/UDP/IP-Header inklusive der dekomprimierten Werte
als auch der statischen Felder A, die von dem vollständigen Header
des "full-header" Paketes a extrahiert
wurden, als auch der RTP-Nutzdaten zusammensetzt. Das nächste Paket
d wird in ähnlicher
Weise verarbeitet.
-
Die
Deltafelder B des IP-Paketes e, die als nächstes von dem Senderknoten
empfangen werden, ist [5] im Wert, wie der Differenzwert von dem Deltafeld
B des letzten IP-Paketes d [2] ist. Wenn der Differenzwert ΔB auf diese
Weise verändert
wird, überträgt der Senderknoten
ein Kopfdatensatzkomprimiertes Paket e, das einen komprimierten
Header hat, bei welchem der geänderte
neue Differenzwert addiert ist und der entsprechende Bitschalter
auf [1] gesetzt ist. Der Empfängerknoten
addiert die neuerlich ausgewiesenen Differenzwerte zu den Werten der
Deltafelder B des IP-Paketes d derart, um die Deltafelder B des
Paketes e zu dekomprimieren; dann überträgt er ein IP-Paket, das die
dekomprimierten Deltafelder B enthält.
-
Der
Senderknoten empfängt
dann ein IP-Paket g, welches im statischen Feld A unterschiedlich zum
vorherigen IP-Paket e ist. In diesem Fall komprimiert der Senderknoten
die RTP/UDP/IP-Header dieses IP-Paketes nicht und überträgt ein Paket
g mit einem vollständigen
Header, in welchem die Länge
in den RTP/UDP/IP-Header des Paketes g durch die CONTEXT_ID und
link_seq ersetzt ist. Der Empfängerknoten,
der dieses „full-header" Paket g empfängt, konvertiert
den vollständigen Header
in den RTP/UDP/IP-Header und speichert ihn in den internen Speicher.
-
Das
Header-Kompressions-Verfahren, das durch den RFC2508 spezifiziert
wird, wurde oben beschrieben (nachstehend als "Verfahren A" bezeichnet). Jedoch leidet dieses Kompressionsverfahren
an einigen Nachteilen, auf die im Folgenden hingewiesen wird.
-
Wie
in 15 dargestellt wird zum Beispiel die Annahme gemacht,
dass das Kopfdatensatz-komprimierte Paket c zwischen dem Sender- und
Empfängerknoten
aus irgendeinem Grunde verloren ging. Wie oben beschrieben, addiert – wenn das
Paket d dekomprimiert wird – der
Empfängerknoten
den Differenzwert ΔB
zu den Deltafeldern B des IP-Paketes c, um die Deltafelder B des
IP-Paketes d zu dekomprimieren. Im Ergebnis ist es unmöglich, die Deltafelder
B des Kopfdatensatz-komprimierten Paketes d zu dekomprimieren, wenn
das Kopfdatensatzkomprimierte Paket c verloren ging. Der Empfängerknoten
ist deshalb gezwungen, die Pakete d, e und f, die empfangen werden
bis das nächste
Paket mit einem vollständigen
Header g empfangen wurde, zu löschen
(fallen gelassen), wie es in 15 dargestellt
ist. Mit anderen Worten bewirkt der Verlust des Paketes weitere
Verluste von einigen anderen Paketen, was zu einer Reduzierung des
Durchsatzes verglichen mit einem Verfahren, bei dem die Header-Kompression
nicht involviert ist, führt.
Gewöhnlich
ist es in den Fällen,
in denen die Sender- und Empfängerknoten über eine
drahtlose Verbindung verbunden sind, wahrscheinlich, dass ein Paket
bei der drahtlosen Verbindung verloren geht. Wenn so ein Verlust
passiert, werden andere Pakete regelmäßig bei dem Empfängerknoten
fallen gelassen. Als Technik, um derartige Probleme zu lösen, liefern
der RFC 2507 und 2508, die durch die IEFT und den Internet-Draft
vorgelegt wurden, folgende Verfahren:
-
Verfahren 1: Wiederholte Übertragung
eines Paketes mit einem vollständigen
Header (RFC 2507)
-
In
dem Fall des vorangegangenen konventionellen Verfahrens A überträgt der Senderknoten
ein Paket mit einem vollständigen
Header nur, wenn die statischen Felder eines Header sich im Wert ändern. Im
Gegensatz dazu – wie
in 16 dargestellt – selektiert dieses Verfahren
1 mehrere IP-Pakete, die übertragen
werden sollen, jede vorher festgelegte Anzahl von Paketen, egal
ob sich die statischen Felder geändert
haben oder nicht. Die selektierten IP-Pakete werden zu Paketen mit
vollständigem Header
konvertiert, und die "full-header" Pakete werden an
den Empfängerknoten übertragen,
während die
verbleibenden IP-Pakete zu Kopfdatensatz-komprimierten Paketen mit
komprimierten Header konvertiert werden. Diese Kopfdatensatz-komprimierten Pakete
werden an den Empfängerknoten übertragen. Weil
Pakete mit vollständigen
Header in dem Verfahren A solange nicht an den Empfängerknoten übertragen
werden, wie ihre statischen Felder sich nicht im Wert ändern, werden
die Pakete, die nach dem Auftreten eines Verlustes übermittelt
wurden, verworfen bzw. fallen gelassen. Im Gegensatz dazu erlaubt das
gegenwärtige
Verfahren 1 die Übertragung
von Paketen mit vollständigen
Header in Intervallen, so dass dies den Vorteil hat, dass die Anzahl
von Paketen, die auf Grund des Verlustes von Paketen fallen gelassen
werden, reduziert werden kann. Trotzdem weist das gegenwärtige Verfahren
1 Kompromisse insofern auf, als eine lange Zeitperiode zur Übertragung
von Paketen mit vollständigem
Header in einer Erhöhung
der Anzahl der Pakete, die fallen gelassen werden, resultiert, während eine
kurze Zeitperiode zur Übertragung
von Paketen mit vollständigem Header
darin resultiert, dass eine große
Anzahl von Paketen mit vollständigem
Header mit großem
Overhead übertragen
werden, wodurch die Effizienz in der Übertragung reduziert wird.
-
Verfahren 2: Anforderung
eines vollständigen
Header durch einen Rückkanal
(RFC2507 und 2508)
-
Wenn
ein Verlust eines Paketes festgestellt wird – wie in 17 dargestellt – erlaubt
das vorliegende Verfahren dem Empfängerknoten die Übermittlung
eines CONTEXT_STATE. Dabei handelte es sich um eine Nachricht, die
ein Paket mit einem vollständigen
Header von dem Senderknoten anfordert. Wenn der Senderknoten CONTEXT_STATE
empfängt, überträgt er das
nächste
IP-Paket an den Empfängerknoten
in Form eines Paketes mit einem vollständigen Header. Im Ergebnis
kann das Intervall, während
dessen einige Pakete auf Grund des Verlustes eines bestimmten Paketes
verworfen wurden, auf das Interval, das mit dem Auftreten eines
Paketverlustes beginnt und mit dem Empfang eines Paketes mit einem
vollständigen
Header, das in Antwort auf ein CONTEXT_STATE übertragen wurde, limitiert werden.
Trotzdem hat die vorliegende Methode den Nachteil, dass wenn das
Interval zwischen der Übertragung
von CONTEXT_STATE und dem Empfang eines Paketes mit einem vollständigen Header
am Empfängerknoten – das heißt die RTT
(Round Trip Time = Umlaufzeit) größer wird – die Anzahl der verworfenen
Pakete auch ansteigt. Für
Nachrichtenpakete über
eine drahtlose Verbindung wird ein solcher Nachteil fühlbar, weil
die RTT einer drahtlosen Verbindung sehr lang ist.
-
Verfahren 3: Doppel-Algorithmus
(RFC 2507)
-
Entsprechend
des vorliegenden Verfahrens 3 wird der komprimierte Header des Kopfdatensatz-komprimierten
Paketes, das nach dem Verlust eines bestimmten Paketes empfangen
wurde, unter Zuhilfenahme des RTP/UDP/IP-Header, der als letztes
vor dem Verlust des Paketes dekomprimiert wurde, dekomprimiert.
Zum Beispiel wird wie in 18 dargestellt
angenommen, dass ein Paket b ordnungsgemäß empfangen wurde, ein Paket
c verloren ging und dann ein Paket d ordnungsgemäß empfangen wurde. Wenn, wie
in dieser Situation, ein Differenzwert ΔB unverändert im Wert über die
Pakete b zu d ist, können
die Deltafelder B von dem Paket d durch Addition der doppelten Werte
von ΔB zu
den Deltafeldern B des Paketes b berechnet werden. Darüber hinaus
benötigt
das Verfahren die UDP-Prüfsumme
im komprimierten Header (vgl. 13B),
so dass die UDP-Prüfsumme
dazu genutzt wird, festzustellen, ob Pakete korrekt dekomprimiert
wurden. In Fällen
allerdings – wie
in 18 dargestellt – bei denen ein Paket k verloren
geht und sich Differenzwerte ΔB
von Deltafeldern zwischen Paketen j und k ändern, gibt es dahingehend
ein Problem, dass ein Paket l, das direkt nach dem Paketverlust
empfangen wurde, nicht korrekt dekomprimiert werden kann. Insbesondere
besteht in den Fällen,
in denen Pakete über
drahtlose Verbindungen übermittelt
werden, die Möglichkeit,
dass Pakete in Folge verloren gehen (insbesondere über lange
Intervalle). In solchen Situationen ist zu bedenken, dass sich die
Differenzwerte ΔB
möglicherweise
für eine
große
Anzahl von verlorenen Paketen ändert.
Dadurch wird sich das vorgenannte Problem verschärfen.
-
Verfahren 4, ROCCO (Internet
Draft)
-
Entsprechend
dem vorliegenden Verfahren 4, wie es beschrieben ist in JONSON L.E.
et al.: Robust Checksum-based COmpression (ROCCO), 18. Januar 2000
und über
das Internet unter <URL:http://www.ludd.luth.se/users/larsman/rocco/drafts/draft
jonsson-robust-hc-03.txt> abgerufen werden
kann, kann der Differenzwert ΔB
auf Grund eines Charakteristikums eines Mediums, durch welche Pakete übertragen
werden, abgeschätzt
werden. Zum Beispiel wird im Fall von 19 angenommen, dass
Pakete g und h verloren gingen und sich die Differenzwerte ΔB zwischen
den Paketen g und h ändern.
In diesem Fall werden Veränderungen
der Differenzwerte ΔB
auf der Basis eines Charakteristikums eines Mediums, über das
die Pakete übertragen
werden, abgeschätzt,
und ein Paket kann durch Addition der geschätzten Differenzwerte ΔB zu dem Paket
f dekomprimiert werden. Darüber
hinaus nutzt das vorliegende Verfahren einen Fehlererkennungscode
(CRC), um zu bestätigen,
ob die Dekompression richtig oder nicht durchgeführt wurde. Somit ermöglicht das
vorliegende Verfahren, auch wenn sich die Differenzwerte ΔB ändern, dass
Pakete, die nach dem Verlust eines bestimmten Paketes empfangen wurden,
dekomprimiert werden können.
Allerdings führt
das vorliegende Verfahren zu der Schwierigkeit der Abschätzung, wie
die Differenzwerte ΔB
abgeschätzt
werden können.
-
Obwohl
eine Vielzahl von Techniken – wie oben
beschrieben – vorgeschlagen
wurden, um eine Datenübertragung
effizient auszuführen,
auch wenn RTP/UDP/IP-Haeder von IP-Paketen komprimiert sind, so
haben doch alle Technikern einige Nachteile. Deshalb ist die Situation
derzeitig so, dass es eine Begrenzung dahingehend gibt, effizient
die Anzahl von Paketen, die bedingt durch den Verlust, der seine Ursache
zwischen dem Sender- und Empfängerknoten
hat, eines bestimmten Paketes fallen gelassen werden müssen, zur
reduzieren. Mit anderen Worten bedingt der Verlust von Teilen eines
Paketes während
der Paketübertragung
zwischen dem Sender und dem Empfänger
den Verlust von anderen Paketen am Empfängerknoten. Dies führt zu einem
großen
Verlust der Datenverarbeitungsnutzung der Pakete, die von dem Empfängedatenterminal
empfangen werden (z.B. Darstellung von Bildern oder Wiedergabe von
Musik, die die empfangenen Paketen nutzen).
-
Zusammenfassung der Erfindung
-
Die
vorliegende Erfindung wurde mit Hinblick auf die vorangegangenen
Umstände
gemacht. Ein Ziel der vorliegenden Erfindung ist die Bereitstellung eines
Paketübermittlungsverfahrens,
einer Ralais-Vorrichtung und eines Datenterminals, die in der Lage
sind, effizient die Anzahl der Pakete, die auf Grund des Verlustes
eines bestimmten Paketes fallen gelassen werden müssen, auch
dann zu reduzieren, wenn Header von Paketen, die gesendet und empfangen
werden, komprimiert sind.
-
Entsprechend
einem Aspekt der vorliegenden Erfindung wird ein Ziel der vorliegenden
Erfindung durch ein Paketübermittlungsverfahren
zum Senden von Paketen von einem Senderknoten an einen Empfängerknoten über ein
Netzwerk entsprechend Anspruch 1 erreicht, wobei die Schritte der Konvertierung
durch eine Kommunikationsvorrichtung, die an dem Senderknoten zur
Konvertierung von nicht komprimierten Paketen, die übertragen werden
sollen, in entweder einen Auffrischungs-Kopfdatensatz-Paket mit
einem Auffrischungs-Header,
der genug Informationen zur korrekten Dekomprimierung und Wiederherstellung
der Synchronisation am Empfängerknoten
enthält
oder ein Kopfdatensatz-komprimiertes Paket mit einem komprimierten
Header, der weniger Informationen als der Auffrischungs-Header hat,
um so einige der nicht komprimierten Pakete solange in die Auffrischungs-Header-Pakete konvertiert,
wie die Pakete wichtige Pakete sind, zur Verfügung stehen; und die Übertragung
eines Paketstromes, der das Auffrischungs-Header-Paket und des Kopfdatensatzkomprimierte
Paketes enthält.
-
In
diesem Verfahren wird ein wichtiges Paket, das die Daten, denen
eine wichtige Rolle in dem Paketstrom zufällt, als Auffrischungs-Kopfdatensatz (Auffrischungs-Header),
der immer korrekt dekomprimiert wird und die Synchronisation wiederherstellen kann, übertragen.
Dementsprechend kann der Einfluss von Paketverlusten auf die Qualität der Medien, und
zwar auf die Qualitätsminderung
der dargestellten Bilder und der wiedergegebenen Audio-Daten, reduziert
werden, weil das bestimmte Paket bedingt durch den Verlust von anderen
Paketen nicht fallen gelassen werden muss.
-
Der
Auffrischungs-Header kann ein vollständige Header inklusive dem
Inhalt des Original-Header des nicht komprimierten Paketes sein.
Der Auffrischungs-Header kann ein anderes Format haben. In Situationen
zum Beispiel, in denen die erste Paketübertragung an den Empfängerknoten
den Kompressionsstatus initiiert hat, kann der Senderknoten einen Auffrischungs-Header
senden, der in der Lage ist, den Kompressionsstatus basierend auf
dem Ergebnis der vorherigen Initialisierung aufzufrischen.
-
Die
vorliegende Erfindung kann derart ausgeführt sein, um die Relais-Vorrichtung
oder die Daten-Terminals zur Paketübertragung in Übereinstimmung
mit dem Paketübertragungsverfahren
der vorliegenden Erfindung zu produzieren oder zu verkaufen. Darüber hinaus
kann die vorliegende Erfindung so ausgeführt sein, dass das Programm,
das das Paketübermittlungsverfahren
der vorliegenden Erfindung ausführt,
auf einen für
Computer lesbaren Datenträger
schreibt oder das Programm Anwendern durch elektronische Kommunikationsnetze
zur Verfügung
gestellt.
-
Kurze Beschreibung
der Zeichnungen
-
1 ist
ein Blockdiagramm, das die Konfiguration eines Kommunikationssystems
exemplarisch darstellt, auf das das Paketübermittlungsverfahren entsprechend
des ersten Ausführungsbeispiels der
vorliegenden Erfindung angewandt wird;
-
2 ist
ein Blockdiagramm, das die Konfiguration eines Empfängerknotens,
der in dem Paketübermittlungsverfahren
genutzt wird, exemplarisch darstellt;
-
3 ist
ein Zeitdiagramm, das einen Betrieb der Paket-Relais-Vorrichtung entsprechend dem
ersten Ausführungsbeispiel
der vorliegenden Erfindung darstellt;
-
4A und 4B sind
Zeitdiagramme, die Paketübertragungen
entsprechend Abwandlungen des ersten Ausführungsbeispiels darstellt;
-
5 ist
ein Format eines Header des komprimierten übertragenen Nicht-TCP-Paketes
des zweiten Ausführungsbeispiels
der vorliegenden Erfindung;
-
6A ist
ein Zeitdiagramm, das das Übertragungsverfahren
eines Paket mit einem vollständigen
Header darstellt, wenn ein Nicht-TCP-Paket übertragen wird;
-
6B ist
ein Zeitdiagramm, das das Übertragungsverfahren
des Paketes mit einem vollständigen
Header des zugehörigen
Ausführungsbeispiel darstellt;
-
6C ist
ein Zeitdiagramm, das ein anderes Beispiel des Übertragungsverfahrens des Paketes
mit einem vollständigen
Header des zugehörigen Ausführungsbeispiels
darstellt;
-
7 stellt
einen Statusübergang
in dem Header-Kompressionsprozess
und Rekonstruktionsprozess mit Hilfe von ROHC dar;
-
8A stellt
ein Format des IR-Header in ROHC dar;
-
8B stellt
das Format des IR-DYN-Header in ROHC dar;
-
9A stellt
einen Typ-0-Header in ROHC dar;
-
9B stellt
einen Typ-1-Header in ROHC dar;
-
9C stellt
einen Typ-2-Header in ROHC dar;
-
10 stellt
Schritte der LSB-Kodierung in ROHC dar;
-
11 stellt
ein Paketübermittlungsverfahrens
des vorliegenden Ausführungsbeispiels
dar;
-
12 stellt
ein Format des IPv6-Header dar, der in den verschiedenen Beispielen
der Ausführungsbeispiele
genutzt wird;
-
13A stellt den Inhalt eines RTP/UDP/IP-Header
dar;
-
13B stellt den Inhalt des komprimierten Header
dar;
-
14 ist
ein Zeitdiagramm, das Schritte des Paketübermittlungsverfahrens entsprechend
des Standes der Technik zur vorliegenden Erfindung darstellt (Verfahren
A);
-
15 ist
ein Zeitdiagramm, das Probleme in dem Paketübermittlungsverfahren des Standes der
Technik darstellt;
-
16 ist
ein Zeitdiagramm, das Schritte eines anderen Paketübermittlungsverfahrens
entsprechend dem Stand der Technik (Verfahren 1) darstellt;
-
17 ist
ein Zeitdiagramm, das Schritte eines anderen Paketübermittlungsverfahrens
entsprechend dem Stand der Technik (Verfahren 2) darstellt;
-
18 ist
ein Zeitdiagramm, das Schritte eines anderen Paketübermittlungsverfahrens
entsprechend dem Stand der Technik (Verfahren 3) darstellt; und
-
die 19 ist
ein Zeitdiagramm, das Schritte eines weiteren Paketübermittlungsverfahrens
entsprechend dem Stand der Technik (Verfahren 4) darstellt.
-
Detaillierte Beschreibung
der Erfindung
-
Mit
Bezug auf die begleitenden Zeichnungen werden jetzt Ausführungsbeispiele
der vorliegenden Erfindung beschrieben.
-
A: Erstes Ausführungsbeispiel
-
A-1: Konfiguration des
ersten Ausführungsbeispiels
-
1 ist
ein Blockdiagramm, das bildhaft die Konfiguration eines Kommunikationssystems,
auf welches ein Paketübermittlungsverfahren
derart vorliegenden Erfindung angewendet werden kann. In einem Kommunikationssystem
sind ein Sendedatenterminal 1 und einen Empfängerdatenterminal 2 vorhanden,
um Pakete über
ein Netzwerk 3 auszutauschen. Die vorliegende Erfindung
wird in folgendem mit Hinblick auf ein Beispiel beschrieben, bei
dem das Sendeterminal 1 Pakete an ein Empfängerterminal 2 sendet.
-
Das
Netzwerk 3 beinhaltet einen Senderknoten 3a und
einen Empfängerknoten 3b.
Relais-Vorrichtungen sind am Senderknoten 3a und am Empfängerknoten 3b vorhanden.
Die Relais-Vorrichtungen
haben die Aufgabe, Pakete weiter zu reichen, welche zwischen dem
Senderdatenterminal und Empfängerdatenterminal 1 und 2 auszutauschen sind.
Obwohl das Netzwerk 3 in 11 Konfiguration mit
dem Sender- und Empfängerknoten 3a und 3b bildhaft
darstellt, ist die vorliegende Erfindung nicht durch diese Konfiguration
begrenzt. Drei oder mehr Knoten und Relais-Vorrichtungen können deshalb
in dem Netzwerk vorliegen.
-
In
dieser Konfiguration sendet das Sendedatenterminal 1 fortlaufend
Pakete durch das Netzwerk, die für
das Empfängerdatenterminal 2 bestimmt
sind. Ein Paket, das vom Sendedatenterminal 1 gesendet wird,
ist ein IP-Paket welches RTP/UDP/IP-Header, wie in 13A dargestellt, enthält. Die Relais-Vorrichtung
am Senderknoten 3a empfängt
in Folge IP-Pakete,
die vom Sendedatenterminal 1 gesendet werden, konvertiert
die empfangenen IP-Pakete entweder in Pakete mit einem vollständigen Header
oder Kopfdatensatz-komprimierte Pakete inklusive eines komprimierten
Header und sendet sie an den Empfängerknoten 3b. Wie
oben beschrieben ist ein vollständiger
Header ein Header, bei welchem ein Längenwert, der in einem IP-Header
oder einem UDP-Header oder RTP/UDP/IP-Header eines IP-Paketes enthalten ist,
durch Daten inklusive einer CONTEXT_ID oder link_seq ersetzt ist.
Auf der anderen Seite speichert die Relais-Vorrichtung am Empfängerknoten 3b die
RTP/UDP/IP-Header aus dem komprimierten Header des Kopfdatensatz-komprimierten
Paketes oder aus einem vollständigen
Header eines Paketes mit einem vollständigen Header zurück und sendet
ein IP-Paket inklusive der RTP/UDP/IP-Header an das Empfängerdatenterminal 2,
wenn ein Kopfdatensatz-komprimiertes Paket oder ein Paket mit einem
vollständigen
Header, das vom Senderknoten 3a gesendet wurde, empfangen wurde.
Das Empfängerdatenterminal 2 empfängt ein IP-Paket,
das vom Empfänger
Knoten 3b gesendet wurde, und führt eine vorbestimmte Verarbeitung (z.B.
Darstellung von Bildern, Abspielen von Sound oder dergleichen abhängig von
den RTP-Nutzdaten) entsprechend dem empfangenen IP-Paket aus.
-
Wie
bei den vorher beschriebenen, konventionellen Techniken ist mit
einem Paket mit einem vollständigen
Header ein Paket gemeint, das es ermöglicht, ein IP-Paket inklusive
RTP/UDP/IP-Header auf der Basis nur des Inhalts des vollständigen Header, der
in einem Paket mit einem vollständigen
Header enthalten ist, zu restaurieren (zurück zu speichern). Die Längenwerte,
der in den RTP/UDP/IP-Header enthalten sind, werden durch einen CONTEXT_STATE
und link_seq ersetzt; jedoch können
die Längenwerte
auch mit Referenz auf die Informationen von niedrigeren Layern zurück gespeichert werden.
Im Gegensatz dazu bedeutet ein Kopfdatensatzkomprimiert Paket ein
Paket, das zu einem IP-Paket basierend auf anderen Paketen (wie
solchen mit einem vollständigen
Header) dekomprimiert werden kann, und das nicht zu einem IP-Paket inklusive RTP/UDP/IP-Header
nur auf der Basis des komprimierten Header, der in dem Kopfdatensatz-komprimiert
Paket enthalten ist, dekomprimiert werden kann.
-
Bezug
nehmend auf 2 wird nun die Relais-Vorrichtung,
die am Senderknoten 3a zur Verfügung steht, beschrieben. Wie
in den Zeichnungen dargestellt, enthält die Relais-Vorrichtung am Senderknoten 3a einen
Empfangsteil 31a, einen Sendeteil 32a, einem Steuerteil 33a,
einen Speicherteil 34a und einem Bus 35a, der
diese Einheiten miteinander verbindet.
-
Der
Empfangsteil 31a dient als Mittel oder Einheit zum Empfangen
von IP-Paketen, die vom Sendedatenterminal 1 über eine Übertragungsstrecke
gesendet wurden, und zum Ausgeben der Pakete an einen Steuerteil 33a.
Der Sendeteil 32a dient als Mittel oder Einheit zum Übertragen
der Daten, die vom Steuerteil 33a ausgegeben wurden, über eine Übertragungsstrecke
an den Empfängerknoten 3b.
-
Ein
Steuerteil 33a ist ein Mittel oder eine Einheit zum Steuern
des Empfängerteils 31a,
des Sendeteils 33a und des Speicherteils 34a.
Praktisch führt der
Steuerteil 33a die unter Punkt a und b beschriebenen Verfahren
aus.
-
a. Entscheidung über die
Wichtigkeit eines empfangenen IP-Paketes
-
Die
Relais-Vorrichtung, die am Sendeknoten in ähnlicher Technologie wie oben
beschrieben, zur Verfügung
steht, ist so konfiguriert, das die Relais-Vorrichtung Pakete mit
einem geänderten
statischen Feld im Header, jedes Paket entsprechend einer vorher
festgelegten Anzahl ausgewählend
oder das Paket, das sofort nachdem Anfang von CONTEXT_STATE oder
link_seq übertragen
werden sollten, in ein Paket mit einem vollständigen Header ohne die Komprimierung
des Header des Paketes konvertiert hat und das Paket mit dem vollständigen Header
an den Empfängerknoten übertragen
hat. Im Gegensatz dazu ist die Ralais-Vorrichtung, die am Senderknoten 3a des
vorliegenden Ausführungsbeispiels
zur Verfügung
steht, so konfiguriert, dass die Relais-Vorrichtung IP-Pakete, die
vom Sendedatenterminal 1 gesendet wurden, empfängt und
die IP-Pakete, dessen Daten wichtig sind (im Folgenden als „wichtige
Pakete" bezeichnet)
in ein Paket mit einem vollständigen
Header ohne Komprimierung des Header konvertiert, und das Paket
mit dem vollständigen Header
an den Empfängerknoten 3b sendet.
Hierbei bezeichnet ein wichtiges Paket das Paket inklusive der Daten,
welche eine wichtige Rolle spielen, wenn das Empfängerdatenterminal 2 Audiodaten
oder Bilder wiedergibt. Insbesondere ist das wichtige Paket dasjenige
Paket, das die Daten enthält,
die merkbar die Qualität
der Audiodaten oder Bilder (z.B. die Qualität der dargestellten Bilder
oder wiedergegebenen Musik verschlechtert) am Empfängerdatenterminal 2 beeinflussen,
wenn das Paket verloren ginge. Der Steuerteil 33a am Senderknoten 3a entscheidet
in den folgenden Fällen,
die hiernach beschrieben sind, dass ein empfangenes IP-Paket wichtig
ist.
-
I. IP-Paket mit dem Marker-Bit
M im RTP-Header gesetzt oder das nächste Paket zum IP-Paket mit
gesetztem Marker-Bit M
-
Das
Marker-Bit M ist im RTP-Header des IP-Paketes, das vom Sendedatenterminal 1 gesandt wurde,
enthalten. Der Steuerteil 33a im dem Senderknoten 3a entscheidet
durch Untersuchung des Makler-Bit über die Wichtigkeit des IP-Paketes.
Die Details hierzu sind nachstehend beschrieben.
-
In
dem Fall, in dem die Daten, die vom Sendedatenterminal 1 gesendet
werden, Video-Daten inklusive mehrerer Frames (Rahmen) sind, enthalten die
ersten Daten jedes Frame sehr brauchbare Informationen zum Darstellen
der Bilder. Auf der anderen Seite ist das Marken-Bit M im RTP-Header
grundsätzlich
in dem Paket gesetzt, das die letzten Daten eines Video-Frame enthalten.
Das nächste
Paket der Pakete, bei dem das Marker-Bit M im RTP-Header gesetzt
ist, enthält
normalerweise die ersten Daten eines Video-Frame. Dementsprechend
ist der Steuerteil 33a im Senderknoten 3a so konfiguriert,
dass das nächste
Paket zum Paket mit dem im RTP-Header gesetzten Marker-Bit als das
wichtige Paket erkannt wird.
-
Darüber hinaus
kann es Fälle
geben, bei denen das Marker-Bit M im RTP-Header gesetzt ist, wenn
die Nutzdaten einige Konfigurationsinformationen wie zum Beispiel
die Datenstruktur oder ähnliches
enthält.
Auf der anderen Seite erfüllt
das Paket, das die Konfigurationsinformation enthält, eine
wichtige Rolle, wenn das Empfängerdatenterminal
die Daten nutzt, um entweder Bilder anzuzeigen oder Musik wiederzugeben.
Entsprechen kann der Steuerteil 33a im Senderknoten 3a so
konfiguriert sein, dass ein Paket mit dem im RTP-Header gesetzten
Marker-Bit als wichtiges Paket angesehen wird.
-
II. Fälle und bei denen der Zeitstempel
im RTP-Header geändert
wurde
-
In
den Fällen,
bei denen die Daten in dem IP-Paket, welche von dem Sender Datenterminal 1 gesendet
wurden, Video-Daten inklusive mehrerer Video-Frames sind, ist der
Wert des Zeitstempels jedes Paketes, die denselben Video-Frame enthalten, identisch.
Auf der anderen Seite und sind die Werte des Zeitstempels generell
unterschiedlich, wenn die Pakete, die die Daten enthalten, zu unterschiedlichen Video-Frames gehören. Dementsprechend
kann entschieden werden, dass sich die Frames verändert haben,
wenn sich der Zeitstempel ändert.
Wie oben beschrieben haben die Daten direkt hinter dem geänderten
Frame wichtige Informationen zur Darstellung der Bilder am Empfängerdatenterminal 2.
Der Steuerteil 33a am Senderknoten 3a entscheidet,
dass das empfangenen Paket wichtig ist (das heißt, das Paket, das die initialen
Informationen jedes Frame enthält), wenn
der Wert des Zeitstempels im empfangenen IP-Paket unterschiedlich
zu dem Wert des Zeitstempels des vorangegangenen Paketes ist.
-
III. Fälle, bei denen die Größe des Paketes
größer ist als
ein spezifische Wert
-
Wenn
die Nutzdaten des IP-Paketes, das vom Senderdatenterminal 1 gesendet
wurde, aus Audiodaten inklusive Sprachfolgen und stillen Anteilen
besteht, ist die Größe des Paketes,
das die Sprachenfolge enthält,
im allgemeinen größer als
die Größe des Paketes,
das die stillen Anteile enthält.
Wenn das Paket, das die Daten einer Sprachfolge enthält, nicht
korrekt am Empfängerdatenterminal 2 empfangen
wurde, ist die Qualität
der Audiodaten merklich verschlechtert gegenüber dem Fall, bei dem diejenigen
Pakete nicht korrekt empfangen worden, die Daten der stillen Anteile
enthalten. Dementsprechend untersucht der Senderknoten 3a,
ob sich die Nutzdaten (payload) jedes Paketes aus Daten einer Sprachenfolge
oder aus den Daten der Stilleanteile abhängig von der Größe des IP-Paketes
zusammensetzen, und entscheidet, dass das Paket, das die Daten der
Sprachfolge enthält,
insbesondere Pakete mit einer Größe, die
größer als
eine vorgegebene Größe ist,
das wichtige Paket ist.
-
IV. Fälle bei denen die Paketgröße geändert wurde
-
Wenn
die Nutzdaten von IP-Paketen, die von dem Senderdatenterminal 1 gesendet
wurden, Audiodaten inklusive Sprachfolgen und Stilleanteile sind, muss
das Empfängerdatenterminal 2 erkennen,
das von Sprachfolge zu Stille und von Stille zu Sprachfolge umgeschaltet
werden muss. Der Steuerteil 33a am Senderknoten 3a konvertiert
deshalb die Pakete, die direkt nach dem Umschalten von Stille zu
Sprachfolge in ein Paket mit einem vollständigen Header ohne eine Komprimierung
des Header und überträgt das Paket
mit dem vollständigen
Header an den Empfängerknoten 3b.
Praktisch bedeutet dies, dass – wenn
immer ein IP-Paket empfangen wird – der Steuerteil 33a am
Senderknoten 3a überprüft, ob die Größe des IP-Paketes
größer als
eine vorgegebene Größe ist (konstanter
Wert) oder nicht, und entscheidet, dass das IP-Paket, das dieses
Mal empfangen wurde, ein wichtiges Paket ist, wenn das Paket, das das
vorige Mal empfangen wurde eine kleinere Größe als eine vorgegebene Größe hat und
gleichzeitig das Paket, das dieses Mal empfangen wurde, eine größere Größe als eine
vorgegebene Größe hat. Ähnlich wird über ein
Paket, das dieses Mal empfangen wurden, entschieden, dass es ein
wichtiges Paket ist, für
den Fall, dass das Paket, das das vorherige Mal empfangen wurde,
größer als
ein vorgegebener Wert ist und gleichzeitig das Paket, das dieses Mal
empfangen wurde, kleiner ist als eine vorgegebene Größe.
-
A-3: Abgewandeltes Beispiel
gegenüber
dem ersten Ausführungsbeispiel
-
Obwohl
die Relais-Vorrichtung am Senderknoten 3a in dem obigen
ersten Ausführungsbeispiel nur
wichtige Pakete als Pakete mit vollständigen Header sendet, ist die
Konfiguration nicht auf das Obige begrenzt, und die folgenden Konfigurationen sind
eingeschlossen.
-
< Abwandlungsbeispiel 1 >
-
In
dem Fall, in dem der Wert in dem statischen Feld in dem RTP/UDP/IP-Header
des zu übermitteln
Paketes sich nicht ändert,
ist es möglich,
das Verfahren zum Herstellen des Paketes mit einem vollständigen Header
nur auf wichtige Pakete anzuwenden und wie im dem oben dargestellten
Ausführungsbeispiel
zu versenden. Dennoch muss der Sendeknoten 3a in den Fällen, in
denen sich der Wert des statischen Feldes änderte, nicht nur die wichtigen
Pakete sondern auch die Pakete mit dem geänderten statischen Feld in
Pakete mit einem vollständigen Header – wie im
Fall A nach dem Stand der Technik dargestellt – konvertieren. Insbesondere
bedeutet dies, dass es so konfiguriert sein kann, dass der Steuerteil 33a im
Senderknoten 3a Pakete mit vollständigen Header nicht nur für die wichtigen
Pakete sondern auch für
Pakete, bei denen sich das statischen Feld geändert hat, an den Empfängerknoten 3b sendet.
-
< Abwandlungsbeispiel 2 >
-
In
dem oben beschriebenen Fall, in denen nur wichtige Pakete als Pakete
mit vollständigen Header übertragen
werden, werden die Intervalle, in denen die Pakete mit vollständigen Header
gesendet werden, länger,
wenn die Anzahl der wichtigen Pakete, die übertragen werden sollen, im
Vergleich zur Anzahl der anderen Pakete geringer ist. In diesem
Fall muss berücksichtigt
werden, dass eine Menge von empfangenen Kopfdatensatz-komprimierten
Paketen bis zum Empfangs des Paketes mit einem vollständigen Header
wegen des Verlustes eines Kopfdatensatz-komprimierten Paketes fallen
gelassen wurden. Um die obige Situation zu vermeiden, kann so konfiguriert
werden, dass, wenn eine vorgeschriebene Zeit T ohne den Empfang
eines wichtigen Paketes nach dem Empfang des Paketes F mit dem vollständigen Header
vergangen ist (mit anderen Worten ohne das Senden des Paketes mit
dem vollständigen
Header), das nächste
zu übertragende
Paket als das Paket F mit einem vollständigen Header gesendet wird,
auch wenn – wie
in 4A dargestellt – das Paket kein wichtiges
Paket ist. Alternativ kann so konfiguriert werden, dass, wenn eine
spezifische Anzahl N von Kopfdatensatzkomprimierten Paketen ohne
den Empfang eines wichtigen Paketes nach dem Senden des Paketes
F mit einem vollständigen Header
(in anderen Worten ohne das Senden eines Paketes mit einem vollständigen Header),
gesendet wurde, das nächste
zu übertragende
Paket als Paket F mit vollständigen
Header gesendet wird, auch wenn das Paket – wie in Figur und 4A dargestellt – kein wichtiges
Paket ist. Alternativ kann so konfiguriert werden, dass, wenn eine
spezifische Anzahl N von Kopfdatensatz-komprimierten Paketen ohne
den Empfang eines wichtigen Paketes nach dem Senden des Paketes
F mit einem vollständigen
Header gesendet wurde, das Paket als Paket F mit vollständigen Header
gesendet wird, unabhängig
von der Wichtigkeit des zu übertragenden
nächsten
Paketes.
-
Darüber hinaus
kann so konfiguriert werden, dass die Relais-Vorrichtung am Senderknoten ein nichtkomprimiertes
Paket in ein Paket F mit einem vollständigen Header konvertiert und
das Paket mit dem vollständigen
Header jedes Mal, wenn eine spezifische Anzahl N von Paketen in
einer bestimmten Zeitperiode T – wie
in 4B dargestellt – an den Empfängerknoten überträgt, auch
wenn das nichtkomprimierten Paket nicht das wichtige Paket ist.
-
Durch
die Nutzung des o.g. Verfahrens ist es möglich, die Situationen zu vermeiden,
in welcher die Intervalle zum Senden der Pakete mit vollständigen Header
länger
werden, auch in den Fällen,
wenn die Anzahl der wichtigen Pakete, die in den Paketen, die gesendet
werden sollen, enthalten sind, gering ist. Es ist also insofern
vorteilhaft, als dass die Anzahl der Pakete, die auf Grund von Paketverlusten
fallen gelassen werden, verringert werden.
-
In
den Fällen,
in denen der Inhalt des statischen Feldes möglicherweise – auch wenn
die obige Konfiguration wie in der obigen Abwandlung des Beispiel
1 angewendet wurde – geändert wurde,
ist es notwendig, das Pakete mit dem Inhalt des geänderten
statischen Feldes und das Paket, das jede spezifizierte feste Anzahl
von Malen ausgewählt
wurde, als das Objekt anzusehen, zu dem der vollständige Header
hinzugefügt
werden muss.
-
< Abwandlungsbeispiel 3 >
-
Wie
bei der konventionellen Technologie des Verfahrens 2 wie
es oben beschrieben ist, kann so konfiguriert werden, dass, wenn
der Empfängerknoten 3b einen
Paketverlust zwischen dem Senderknoten 3a und dem Empfängerknoten 3b feststellt,
der Empfängerknoten
CONTEXT_STATE sendet, welches die Übertragung eines Paketes mit
einem vollständigen
Header vom Senderknoten 3a anfordert. Das heißt genauer,
das so konfiguriert werden kann, dass der Steuerteil 33a am
Senderknoten 3a das wichtige Paket als Paket mit einem
vollständigen Header
sendet, während
der Steuerteil das Paket, das direkt nach dem Empfang von CONTEXT_STATE,
das vom Empfängerknoten 3b gesendet
wurde, auch als Paket mit vollständigen Header überträgt. In dieser
Abwandlung ist es also möglich
anzunehmen, dass das Paket mit geänderten, statischen Feld mit
einem vollständiger
Header – wie
im Fall der Abwandlung des Beispiel 2 – gesendet ist.
-
< Abwandlungsbeispiel 4 >
-
Über das
IP-Paket, das als wichtiges Paket angenommen wird, gibt es über die
im obigen Ausführungsbeispiel
aufgelisteten hinaus folgende Pakete.
- a. In
den Fällen,
in denen die Paketübertragung für das Senden
von Videodaten, die aus einem Kompressions-Kodierungs-Algorithmus, der
einen Intra-Frame-Kodierungsprozess (intraframe coding process)
und einen Inter-Frame-Vorhersage-Kodierungsprozess
(inter-frame predections coding process) für animierte Bilder (zum Beispiel der
Codierungsalgorithmus für
animierte Bilder entsprechend MPEG (Moving Picture Experts Group))
enthält,
ausgelegt ist, wird das IP-Paket, das Daten, die aus dem Intra-Frame-Kodierungsprozess
hervorgegangen sind (namentlich die kodierten Daten des I Frames),
enthält,
als das wichtige Paket ausgewiesen. Der Grund dafür ist, dass die
folgenden Frames mit der Inter-Frame-Vorhersage-Kodierung
mit Referenz auf den I Frame nicht ordentlich restauriert werden
können,
es sei denn, dass der I Frame ordentlich im Empfänger zurück gespeichert wurde.
- b. In den Fällen,
in denen die Paketübertragung dafür ausgelegt
ist, um geschichtete kodierte Daten (layered coded data), die sich
aus den Daten einer Basisschicht und den Daten einer höheren Schicht
zusammensetzen, wird das IP-Paket,
das die Daten der Basisschicht enthält, als das wichtige Paket
angesehen. Die Daten der Basisschicht bezeichnen die Daten, welche
höchst
wichtig sind, um die Originalinformation zu restaurieren, wenn die
geschichteten kodierten Daten am Empfänger dekodiert werden. Darüber hinaus
werden die Daten der höheren
Schicht als die Daten angesehen, die nicht so wichtig wie die Daten
der Basisschicht sind, aber zur Erhöhung der Qualität der Wiederherstellung
der Originalinformationen dienen, wenn ordentlich dekodiert worden
wäre. Im
Kompressions-Kodierungs-Algorithmus für animierte Bilder entsprechend
MPEG-2 werden beispielsweise einer Reihe Frames, die übertragen
werden sollen, aufgeteilt in I Frame, P Frame und B Frame. Die Inter-Frame-Kodierung
wird auf den I Frame angewandt. Eine unidirektionales Inter-Frame-Vorhersage
(inter-frame predctions) wird auf den P Frame mit Referenz auf den
vorangegangenen I Frame oder P Frame angewendet. Eine unidirationale
Inter-Frame-Vorhersage-Kodierung
wird auf den B Frame mit Referenz auf den I Frame oder P Frame,
davor oder danach an kommend, angewendet. In diesem Falle sind die kodierten
Daten des I Frame und P Frame Daten der Basisschicht und die kodierten
Daten des B Frame sind die Daten der höheren Schicht. Der Decoder
kann die animierten Bilder reproduzieren, obwohl die dazugehörige Zeitauflösung niedrig
ist, solange mindestens die Daten der Basisschicht korrekt empfangen
wurden. Deshalb sind die Daten der Basisschicht wichtig, so dass
die Daten der Basisschicht als wichtige Pakete übertragen werden. Wenn die
Daten der höheren Schicht
am Decoder dekodiert werden, wird der B Frame genutzt, um den Zeitsprung
zwischen dem I Frame und dem P Frame zu kompensieren, um so die
Zeitauflösung
des animierten Bildes zu erhöhen.
-
B. Zweites Ausführungsbeispiel
-
Im
ersten Ausführungsbeispiel
ist so konfiguriert, dass die Relais-Vorrichtung, die am Senderknoten 3a zur
Verfügung
steht, die Funktion hat, das IP-Paket in ein Kopfdatensatzkomprimiertes
Paket oder ein Paket mit einem vollständigen Header zu konvertieren
(im nachfolgenden als eine "Kompressionsfunktion" bezeichnet), während die
Relais-Vorrichtung,
die am Empfängerknoten 3b zur
Verfügung steht,
die Funktion hat die Kopfdatensatz-komprimierten Pakete oder die
Pakete mit einem vollständigen
Header in ein IP-Paket zu konvertieren (im nachfolgenden als eine "Dekompressionsfunktion" bezeichnet). Im
Gegensatz dazu ist das vorliegende Ausführungsbeispiel derart konfiguriert,
dass das Sendedatenterminal 1 und der Empfängerknoten 3b in 1 kompressionsfunktion
haben, während
der Sendeknoten 3a und das Empfängerdatenterminal 2 die
Dekompressionsfunktionen haben.
-
Das
Empfängerdatenterminal 1 produziert praktisch
in Folge die zu übertragenden
IP-Pakete und entscheidet dann genauso wie im ersten Ausführungsbeispiel,
ob jedes der IP-Pakete das wichtige Paket ist oder nicht. Das Sendedatenterminal 1 sendet
das IP-Paket, von dem entschieden wurde, dass es ein wichtiges Paket
ist als Paket mit einem vollständigen
Header an den Sendeknoten 3a, während das Sendedatenterminal 1 die übrigen Pakete
als Kopfdatensatz-komprimierte Pakete an den Sendeknoten 3a überträgt.
-
Auf
der anderen Seite konvertiert die Relais-Vorrichtung, die am Senderknoten 3a,
zur Verfügung
steht, das empfangene Kopfdatensatz-komprimierten Paket oder das
Paket mit einem vollständigen
Header in ein IP-Paket und sendet es an den Empfängerknoten 3b. Darüber hinaus
entscheidet die Relais-Vorrichtung
am Empfängerknoten 3b,
ob jedes der vom Senderknoten 3a empfangenen IP-Pakete
das wichtige Paketes ist oder nicht, und sendet das Paket, von dem
entschieden wurde, dass es das wichtige Paket ist, als ein Paket
mit einem vollständigen
Header an das Empfängerdatenterminal 2,
während
die übrigen
IP-Pakete als Kopf datensatz-komprimierte Pakete an das Empfängerdatenterminal 2 gesendet
werden. Das Empfängerdatenterminal 2 restauriert
die IP-Pakete auf der Basis der vom Empfängerknoten 3b empfangenen
Pakete mit vollständigen
Header oder der Kopfdatensatz-komprimierten Pakete und zeigt dann
die Bilder an, gibt die Audiodaten wieder oder ähnliches in Abhängigkeit
von den Daten, die in jedem der Pakete enthalten sind. Es kann der
gleiche Effekt wie im ersten Ausführungsbeispiel mit der obigen
Konfiguration erreicht werden.
-
Wie
oben beschrieben kann so konfiguriert werden, dass das Sendedatenterminal
eine Funktion zum Senden der wichtigen Pakete in den zu übertragende
IP-Paketen als Pakete mit vollständigen
Header hat. Genauer gesagt bedeutete dies, dass das Paketübertragungsverfahren
der vorliegenden Erfindung auf beliebige Vorrichtungen anwendbar
ist, um die Paketübertragung
und den Empfang in einem Netzwerk zu implementieren. Mit anderen
Worten sind „der
Sender" und „der Emfänger", die in den Ansprüchen definiert
sind, nicht eingeschränkt
auf eine Paket-Relais-Vorrichtung, um das ausgetauschte Paket zwischen
den Datenterminals zu übertragen,
sondern sind das Konzept inklusive des Datenterminals, welches der
Sender des Paketes ist, und des Datenterminals, welches das Ziel
des Paketes ist.
-
Auch
in diesem Ausführungsbeispiel
kann der Sender so konfiguriert sein, dass er nicht nur das wichtige
Paket, als das übertragende
Paket mit einem vollständigen
Header bezeichnet, sondern auch das Paket, bei dem das statischen
Feld geändert wurde,
wie es in dem Abwandlungsbeispiel des ersten Ausführungsbeispiels
beschrieben wurde (Abwandlungsbeispiel 1), als auch das Paket, das
gesendet werden soll, nachdem eine spezifische Periode ohne Sendung
des IP-Paketes oder des Paketes mit einem vollständigen Header, das übertragen
werden soll, nachdem eine feste Anzahl von Kopfdatensatz-komprimierten
Paketen ohne das Senden des Paketes mit dem vollständigen Header
(Abwandlungsbeispiel 2) und ausserdem das IP-Paket, das nach dem
Empfang von CONTEXT_STATE vom Senderknoten 3a empfangen
wurde.
-
C. Drittes Ausführungsbeispiel
-
Wie
in dem Fall des vorangegangenen Ausführungsbeispiels wird in diesem
dieses Ausführungsbeispiel
vorgeschlagen, dass das Paket mittels des Nicht-TCP-Protokolls UDP übertragen
wird. RFC2507 definiert den komprimierten Nicht-TCP-Header, der
das Format wie in 5 gezeigt hat, als einem komprimierten
Header, welcher für
Nicht-TCP-Pakete genutzt werden kann, überträgt. Es gibt Fälle, in
denen die Felder für
ID von IP und RTP in dem Header des Nicht-TCP Paketes Paket für Paket
geändert
werden. Der komprimierte Nicht-TCP-Header enthält die Felder, die sich aus den
Feldern mit Daten, welche Paket für Paket geändert werden können, zusammensetzt.
Zur Vereinfachung werden die Felder, die so in dem komprimierten
Nicht-TCP-Header enthalten sind, als "Ersatzfelder" bezeichnet. ID von IP und RTP, dargestellt
in 5, sind dementsprechend Ersatzfelder. Jeder komprimierte
Nicht-TCP-Header
wird mit Referenz auf einen vorangegangenen vollständigen Header generiert.
CID, dargestellt in 5, ist die Information, die
den vollständigen
Header identifiziert, auf welchen zur Generierung des komprimierten Nicht-TCP-Header
Referenz genommen wird. Die "Generation" ist das Feld welches
aktualisiert wird, wenn eine Veränderung
in den konstanten Feldern des vollständigen Header gemacht wird.
-
Wenn
ein vom Sendeknoten gesendeter komprimierter Nicht-TCP-Header empfangen
wird, nimmt die Kommunikationsvorrichtung am Empfängerknoten
Referenz auf den komprimierten Nicht-TCP-Header als auch auf den vollständigen Header,
welcher durch CID identifiziert ist und im komprimierten Nicht-TCP-Header
enthalten ist, und generiert einen Header, der die Ersatzfelder
des komprimierten Nicht-TCP-Header und die anderen Felder des vollständigen Header
hat. Die Kommunikationsvorrichtung nutzt dann den generierten Header
zur Verarbeitung der Nicht-TCP-Pakete.
-
Es
gibt Fälle,
bei denen sogenannte Synchronisationsverluste während der Überlieferung von Nicht-TCP-Paketen
vom Senderknoten an den Empfängerknoten
passieren. In RFC2507 gibt es einen Vorschlag für ein Verfahren zur schnellen
Erholung von Synchronisationsverlusten. Entsprechend dem Vorschlag
wird der Header wiederholt nach exponentiell wachsenden Intervallen – wie in 6A dargestellt – übermittelt.
-
Das
Vorangegangene ist die Grundidee des Header-Kompressionsverfahrens für Nicht-TCP-Pakete
wie es in RFC2507 vorgeschlagen ist.
-
Das
jetzige Ausführungsbeispiel
beschreibt, dass die vorliegende Erfindung auf das oben genannte
Header-Kompressionsverfahren
für Nicht-TCP-Pakete
angewendet wird. 6B und 6C zeigen
beides Beispiele von Paketübertragungsverfahren
nach dem jetzigen Ausführungsbeispiel.
-
In
den Übertragungsverfahren
wie in 6B dargestellt wird ein Auffrischungs-Kopfdatensatz-Paket
RHP inklusive des komprimierten Nicht-TCP-Header an Stelle eines
vollständigen Header übermittelt,
wenn das wichtige Paket übertragen
wird. Der komprimierte Nicht-TCP-Header enthält alle für die Erholung von dem Synchronisationsverlust
notwendigen Informationen. Deshalb kann der gleiche Effekt wie derjenige
aus dem ersten Ausführungsbeispiel
erreicht werden, auch wenn der komprimierten Nicht-TCP-Header an
Stelle des vollständigen
Header übermittelt
wird.
-
In
den Übertragungsverfahren – wie in 6C dargestellt – wird das
wichtige Paket als Auffrischungs-Header-Paket RHP übertragen,
während das
Auffrischungs-Header-Paket intermittierend übertragen wird, bis das Auffrischungs-Header-Paket RHP,
das dem wichtigen Paket entspricht, erscheint, wenn der Synchronisationsverlust
passiert. In dem Fall, in dem die Zeitintervalle oder die Anzahl
von Paketen zwischen zwei aufeinander folgenden Auffrischungs-Header-Paketen RHP exponenziell
vergrößert werden,
werden die Auffrischungs-Header-Pakete RHP wiederholt übertragen.
-
In
diesem Ausführungsbeispiel
kann der gleiche Effekt wie im ersten Ausführungsbeispiel erreicht werden.
-
D. Viertes Ausführungsbeispiel
-
Es
gibt ein weiteres Header-Kompressionsverfahren von IP-Paketen, ROHC (Robust
Header Compression) genannt, welches als ein Internet-Draft herausgegeben
wurde. Dieses Ausführungsbeispiel
bezieht sich auf das Verfahren für
die Paketkompression und Übertragung
nach dem ROHC-Verfahren.
-
In
dem ersten der drei bereits beschriebenen Ausführungsbeispiele wird der vollständige Header, der
den Inhalt des Original-Header hat, zu der Zeit übertragen, wenn die Paketüberlieferung
beginnt; und er wird während
der Paketüberlieferung
als Auffrischungs-Header übertragen,
um die Synchronisation am Empfänger
wiederherzustellen. Im Verfahren, das die Paketkompression und -übertragung
entsprechend ROHC nutzt, wird ein Auffrischungs-Header mit einem
zu einem vollständigen
Header anderen Format vom Sender übertragen, wobei die Synchronisation
am Empfänger
wiederhergestellt wird. Nachstehend wird die Grundidee der ROHC
beschrieben, um die technische Wichtigkeit der vorliegenden Erfindung
verstehen zu helfen.
-
7 zeigt
einen Übergang
des Kompressionsstatus wie in der ROHC genutzt. Wie man von der Zeichnung
erkennt, hat die ROHC 3 Arten von Kompressionsstatusstati.
-
Wenn
die Paketablieferung, die die Header-Kompression begleitet, zwischen
dem Senderknoten und dem Empfängerknoten
durchgeführt wird,
wird der Kompressionsprozess und der Wiederherstellungsprozess von
einem Initialisierungsstatus aus im Senderknoten und im Empfängerknoten
gestartet. Darüber
hinaus müssen,
wenn der Synchronisationsverlust während der Paketübertragung
und des -empfangs passiert, der Kompressionsprozess und der Rekonstruktionsprozess
in den Initialisierungsstatus zurückkehren, um die Synchronisation zwischen
dem Senderknoten und dem Empfängerknoten
wiederherzustellen. Wenn eine bestimmte Bedingung nach dem Kompressionsprozess
und dem Rekonstruktionsprozess initialisiert sind erfüllt ist,
wird der Status des Kompressionsprozesses am Senderknoten und des
Rekonstruktionsprozesses am Empfängerknoten
auf den Differenz-Wert-Veränderungs-Status,
welcher der höhere
Status ist, überführt. Wenn
in diesen Status eine bestimmte Bedingungen erfüllt ist, wird der Prozessstatus
der Kompression und der Rekonstruktion in den Differenz-Wert-Konstant-Status überführt, welcher
der weiter oben liegende Status ist. Wenn die Prozessstati der Kompression
und Rekonstruktion in einen höheren
Status verändert
werden, wird die Größe des zu übertragenden
komprimierten Header kleiner.
-
Im
Initialisierungsstatus wird der IR-Header, wie in 8A dargestellt,
oder der IR-DYN-Header, wie in Figur und 8B dargestellt, übertragen.
-
Der
IR-Header wird aus dem ersten IP/UDP/RTP-Header des ersten Paketes
produziert, um den Kompressionsprozess und den Rekonstruktionsprozess
zu initialisieren, wenn die Paketüberlieferung, die die Header-Kompression
nutzt, startet. In 8A enthält die statischen Kette Informationen über das
statische Feld, welches nicht Paket für Paket in dem IP/UDP/RTP-Header
geändert
wird. Die dynamische Kette enthält
die Informationen der dynamischen Felder, welche Paket für Paket
in dem IP/UDP/RTP-Header geändert
werden können.
-
Der
IR-DYN-Header wird zu der Zeit produziert, wenn der Synchronisationsverlust
zwischen der Paketüberlieferung
und der notwendigen Initialisierung des Rekonstruktionsprozesses
des Header am Empfänger
passiert, nachdem die Header-Kompression
bereits gestartet und an den Empfänger gesandt wurde. Der IR-DYN-Header
enthält
nur die dynamische Kette, wie in 8B dargestellt.
Weil die dynamischen Kette alle Informationen des dynamischen Feldes
enthält,
wird die Synchronisation durch den Empfang davon am Empfängerknoten
wiederhergestellt.
-
Sowohl
der IR-Header als auch der IR-DYN-Header enthalten CRC, die aus
dem Original IP/UDP/RTP-Header berechnet werden.
-
Der
Knoten, der den IR Header und den IR-DYN-Header empfängt, kann
durch die Nutzung des CRC feststellen, ob der Header richtig zurück gespeichert
wurde oder nicht.
-
Die
Kommunikationsvorrichtung am Sendeknoten überwacht zwischen den Paketen
die Differenz des dynamischen Feldes des IP/UDP/RTP-Header für die in
Reihenfolge zu übertragenen
Pakete. Wenn es keine Veränderung
in der Differenz gibt (das heißt
Differenz-Wert-Konstant-Status), wird das Kopfdatensatz-komprimierten
Paket Typ-0 – wie
in 9A dargestellt – produziert und an den Empfängerknoten übertragen.
In 9A stellt SN die Sequenznummer des RTP dar. Der
Empfängerknoten lernt,
dass es keine Veränderung
in der Differenz des dynamischen Feldes zwischen den Paketen gibt, wenn
ein Typ-0-Header empfangen wird. Dann wird nur die dann verfügbare Differenz
in dem dynamischen Feld zu dem dann aktuellen Wert hinzugefügt, um das
dynamische Feld zu rekonstruieren.
-
Wenn
die Kommunikationsvorrichtung am Senderknoten die Veränderung
in der Differenz erkennt (das heißt Differenz-Wert-Veränderung-Status),
produziert die Kommunikationsvorrichtung am Senderknoten das Kopfdatensatzkomprimierte
Paket, das einen Typ-1-Header oder Typ-2-Header enthält, um die
neue Differenz an den Empfängerknoten zu übertragen,
und überträgt es an
den Empfängerknoten.
Das Format des Typ-1-Header ist in 9B dargestellt,
und der Typ-2-Header ist in 9C dargestellt.
In den Zeichnungen repräsentiert
SN Informationen bezüglich
der Differenz in RTP-Sequenznummern, und TS repräsentiert Informationen in Bezug
auf die Differenz im RTP-Zeitstempel. Es ist beliebig, ob der Typ-1-Header
oder der Typ-2-Header übertragen
wird.
-
Die
Informationen über
die oben genannten Differenzen wird aus einer LSB-Kodierung (least
signifikant bit) der entsprechenden Felder abgeleitet. 10 zeigt
die Schritte der LSB-Kodierung.
-
In
diesem Verfahren werden ein oder mehrere Pakete vor dem Paket, das
komprimiert werden soll, als Referenzpakete selektiert, wenn sich
die Differenz in einigen Feldern des Header zwischen den Paketen ändert. Es
ist beliebig, welche Pakete als Referenzpakete selektiert werden.
Die Felder des Header des Paketes, das komprimiert werden soll, und
das entsprechende Feld des Header des Referenzpaketes werden miteinander
verglichen, und dann werden die niedrigeren Bits übertragen.
Weil in dem Beispiel, dargestellt in 10, die
niedrigen 4 Bits unterschiedlich sind, werden die vier unteren Bits durch
den Typ-1-Header oder den Typ-2-Header an den Empfängerknoten übertragen.
Im Empfängerknoten
werden die vier unteren Bits in dem entsprechenden Feld vom Header
des Referenzpaketes durch die vier untere Bits in dem Typ-1- Header oder dem Typ-2-Header
ersetzt, so dass das Originalfeld rekonstruiert werden kann.
-
Das
vorangegangene ist die Grundidee des derzeitigen vom Internet-Draft
vorgeschlagenen ROHC.
-
11 stellt
das Paketübermittlungsverfahren
des aktuellen Ausführungsbeispiels
dar.
-
Im
jetzigen Ausführungsbeispiel
wird der IP/UDP/RTP-Header des wichtigen Paketes entweder in einen
der IR-Header, der IR-DYN-Header, der Typ-1-Header oder der Typ-2-Header
konvertiert, wenn das wichtige Paket übertragen wird, und das Auffrischungs-Header-Paket,
das den so konvertierte Header enthält, wird an den Empfängerknoten übertragen.
Nachfolgend wird eine detailliertere Beschreibung gegeben:
In
der entsprechend ROHC Kopfdatensatz-komprimierten Paketübertragung
gibt es Fälle,
in denen, wenn der Header durch die Kommunikationsvorrichtung am
Empfängerknoten
empfangen wird und der Inhalt des Header korrekt zurück gespeichert
wurde, das ACK vom Empfängerknoten übertragen
wird, um den Sendeknoten über
den Zustand zu informieren. In dem aktuellen Ausführungsbeispiel
wird der Typ-1-Header oder der Typ-2-Header vom IP/UDP/RTP-Header
des wichtigen Paketes mit Referenz auf den früheren Header, welcher bereits übermittelt
und bestätigt
wurde, generiert, wenn das wichtige zu übertragende Paket nach dem
Empfang eines solchen ACK vom Empfängerknoten generiert wird.
-
Das
Auffrischungs-Header-Paket, das den so generierten Typ-1- der Typ-2-Header
enthält,
wird dann an den Empfängerknoten übertragen.
Der so übertragene
Typ-1- oder Typ-2-Header enthält
die Daten, die auf die Differenz zwischen dem dynamischen Feld des
IP/UDP/RTP-Header des wichtigen Paketes und dem des bestätigten Paketes,
für das das
ACK bereits vom Empfängerknoten
empfangen wurde.
-
Weil
der Typ-1-Header oder der Typ-2-Header genug Informationen zur Wiederherstellung
der Synchronisation enthält,
auch wenn der Paketverlust vor der Übertragung eines wichtigen
Paketes passiert, wird der Header in dem wichtigen Paket ohne Probleme
korrekt rekonstruiert. Auf diese Weise ist das wichtige Paket von
dem Paket, das den Synchronisationsverlust auslöst, gestützt.
-
Es
gibt Fälle,
in welchen, wenn das wichtige Paket übertragen wird, es aber keinen
Header gibt, der bereits gesendet und bestätigt ist. In diesen Fällen wird
der IR-Header oder der IR-DYN-Header von dem IP/UDP/RTP-Header des
wichtigen Paketes und des an den Empfängerknoten übermittelten Ihnen enthaltenen
Auffrischungs-Header-Paketes generiert.
-
In
dem vorliegenden Ausführungsbeispiel kann
das wichtige Paket von dem Paketverlust bedingt durch den Synchronisationsverlust
geschützt werden.
-
E. Änderungsbeispiel von jedem
der oben genannten Ausführungsbeispiele
-
Jedes
der oben beschriebenen Ausführungsbeispiele
offenbart das Paketübermittlungsverfahren
angewendet auf die Übertragung
von den IPv4-Paketen. Trotzdem ist der Anwendungsbereich der vorliegenden
Erfindung nicht begrenzt auf das obige begrenzt. Die vorliegende
Erfindung kann auch angewendet werden auf Übertragungen von IPv6-Paket. 12 zeigt
das Format eines IPv6-Header. Wie die Zeichnung darstellt, hat IPv6 das
statischen Feld, welches nicht zwischen den Paketen geändert wird,
das dynamische Feld, das sich zwischen den Paketen ändern kann,
und das eliminiert Feld, welches einen bekannten Wert hat oder aus
einem anderen Feld rekonstruiert werden kann. Deshalb kann das Paketübermittlungsverfahren,
das in jedem der Ausführungsbeispiele
oder den Abwandlungen davon beschrieben ist, angewendet werden auf
das nichtkomprimierte Paket mit dem IP/UDP/RTP-Header in welchem
der IP-Teil aus dem IPv6-Header
besteht.
-
Die
vorliegende Erfindung kann durch die Speicherung des Programms zur
Ausführung
des Paketübermittlungsverfahrens
der vorliegenden Erfindung auf einem für Computer lesbaren Speichermedium,
sowie die Verteilung der Speichermedien an Nutzer oder die Bereitstellung
eines solchen Programmes durch ein elektronisches Kommunikationsnetzwerk
an Nutzer ausgeführt
sein.