DE60113906T2 - Verfahren und Vorrichtung zur Paketübertragung mit Paketenkopfkompression - Google Patents

Verfahren und Vorrichtung zur Paketübertragung mit Paketenkopfkompression Download PDF

Info

Publication number
DE60113906T2
DE60113906T2 DE2001613906 DE60113906T DE60113906T2 DE 60113906 T2 DE60113906 T2 DE 60113906T2 DE 2001613906 DE2001613906 DE 2001613906 DE 60113906 T DE60113906 T DE 60113906T DE 60113906 T2 DE60113906 T2 DE 60113906T2
Authority
DE
Germany
Prior art keywords
packet
header
compressed
whole
packets
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE2001613906
Other languages
English (en)
Other versions
DE60113906D1 (de
Inventor
Takeshi Yokohama-shi Yoshimura
Toshiro Yokosuka-shi Kawahara
Takashi Yokosuka-shi Suzuki
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NTT Docomo Inc
Original Assignee
NTT Docomo Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NTT Docomo Inc filed Critical NTT Docomo Inc
Application granted granted Critical
Publication of DE60113906D1 publication Critical patent/DE60113906D1/de
Publication of DE60113906T2 publication Critical patent/DE60113906T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/38—Flow control; Congestion control by adapting coding or compression rate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

  • HINTERGRUND DER ERFINDUNG
  • GEBIET DER ERFINDUNG
  • Die vorliegende Erfindung bezieht sich auf ein Paketübertragungsverfahren zum Übertragen und Empfangen von Paketen unter einer Vielzahl von Datenendgeräten, und auf ein Weiterübertragungsgerät und ein Datenendgerät, die für die Paketübertragung verwendet werden.
  • BESCHREIBUNG DER VERWANDTEN TECHNIK
  • In neuester Zeit ist eine Nachfrage für ein Übertragen durch das Internet solcher Daten, wie Videodaten oder Audiodaten, die eine Echtzeitübertragung benötigen, intensiviert worden.
  • Als Protokoll, um der Nachfrage zu begegnen, wird ein RTP (Echtzeittransportprotokoll, englisch: Real-Time Transport Protocol) durch die RFC (Request For Comment) 1889 angeordnet, das von der IETF (Internet Engineering Taskforce) ausgegeben wurde, einer Gruppe zum Standardisieren des Internets. Das RTP hat Funktionen, wie zum Beispiel 1) Spezifizierung einer Nutzlastart, 2) Bestimmen einer Sequenznummer bzw. Abfolgenummer und 3) Bestimmen eines Zeitstempels. Diese Regeln erlauben solch einer Information, wie Audio- und Videodaten, in Echtzeit im Internet übertragen zu werden. Gewöhnlich wird das ERTP als eine obere Schicht für das IP (Internet-Protokoll) auf einer Netzwerkschicht und das UDP (Benutzerdatengrammprotokoll) auf einer Transportschicht verwendet.
  • 11A zeigt Inhalte eines RTP-Headers bzw. RTP-Kopfes, UDP-Headers und IP-Headers (hier im folgenden als "RTP/UDP/IP-Header" bezeichnet (die an Daten angefügt sind, wie zum Beispiel Audio- und Videodaten, die gemäß dem RTP, UDP und IP zu übertragen sind. Hier im folgenden wird ein Paket mit den RTP/UDP/IP-Headern ein IP-Paket genannt.
  • Wie in der Zeichnung gezeigt, braucht der IP-Header 20 Bytes, der UDP-Header 8 Bytes und der RTP-Header 12 Bytes, daher erreicht die Gesamtsumme der RTP/UDP/IP-Header 40 Bytes. Im Gegensatz umfassen in einem IP-Paket enthaltene Videodaten beispielsweise ungefähr 50 Bytes. Zum Übertragen solcher Bilddaten in Form von Paketen, erreicht der Overhead deshalb nicht weniger als 44%. Ähnlich erreicht der Overhead zum Übertragen von Audiodaten, die 20 Bytes in einem Paket umfassen, bis zu 66%. Da eine praktische Übertragung Header für andere hinzuzufügende Schichten braucht, besetzen die ganzen Header einen großen Prozentteil eines Pakets, was einen Nachteil beim Reduzieren der Effizienz in Kommunikationsvorgängen hervorruft.
  • Als eine Technik, diesen Nachteil zu überwinden, zeigt der durch die IETF ausgegebene RFC 2508 ein RTP-Kompressionsprotokoll, um die RTP/UDP/IP-Header zu komprimieren. Das RTP-Kompressionsprotokoll erlaubt, dass die in 11A gezeigten RTP/UDP/IP-Header in einen Header komprimiert werden, der beispielhaft in 11B dargestellt ist (hier im folgenden als ein "komprimierter-Header" bezeichnet). Diese Kompression sieht im Detail wie folgt aus.
  • Das Verfahren der Kompression wird zwischen zwei Knoten an einem Netzwerk, durch das Pakete übertragen werden unter einer Vielzahl von Datenendgeräten beispielsweise angewandt. Genauer gesagt, von den zwei Knoten, konvertiert ein Knoten (hier im folgenden als "Senderknoten" bezeichnet), die RTP/UDP/IP-Header eines Teils der IP-Pakete, die zwischen den Datenendgeräten kommuniziert werden, in einen komprimierten-Header, und überträgt ihn als ein Header-komprimiertes Paket, an den anderen Knoten (hier im folgenden als "Empfängerknoten" bezeichnet. Gleichzeitig überträgt der Senderknoten die RTP/UDP/IP-Header des anderen Teils der IP-Pakete an den Empfängerknoten als ein Ganz-Header-Paket bzw. Voll-Kopfpaket ohne irgendeine Kompression. Der Empfängerknoten dekomprimiert (das heißt, Wiederherstellung) zu einem IP-Paket das Header-komprimierte Paket oder das Ganz-Header-Paket empfangen von dem Senderknoten, und sendet es an den nächsten Knoten oder ein Empfangsdatenendgerät. Der Ganz-Header bzw. ganze Header ist ein Header, in dem Längen, enthalten in den in 11A gezeigten RTP/UDP/IP-Headern, ersetzt werden durch Information einschließlich einer CONTEXT_ID zum Identifizieren der RTP-Verbindung und einer Verbindungssequenznummer link_seq, einer Seriennummer, die in der Reihenfolge der Übertragung von dem Senderknoten ausgegeben wird.
  • Der in 11B gezeigte Inhalt des komprimierten-Headers wird nun erklärt. Die Daten der Abschnitte mit dichtem Hatching, das in den RTP/UDP/IP-Headern in 11a angewendet wird, was eine Versionsnummer (V) beinhaltet, die in den IP-Header geschrieben ist, und die Nutzlastart, die in den RTP-Header geschrieben ist, sind konstante Daten (hier im folgenden als "statische Felder" bezeichnet), die für jedes Paket von dem Senderknoten zu übertragen sind. Daher enthält der komprimierte Header nicht Daten der statischen Felder. Wenn der Senderknoten das erste IP-Paket des Paketstroms an den Empfängerknoten sendet, sendet er ein Voll-Headerpaket bzw. Ganz-Header-Paket, das einen vollen Header aufweist, einschließlich den statischen Feldern. Danach konvertiert der Senderknoten die RTP/UDP/IP-Header der nachfolgenden IP-Pakete in einen komprimierten-Header mit keinen statischen Feldern. Der so konvertierte komprimierte Header wird dann an den Empfängerknoten als ein Header-komprimiertes Paket gesendet. Wenn der Empfängerknoten das Ganz-Header-Paket entsprechend dem ersten IP-Paket empfängt, stellt der Empfängerknoten die empfangenen RTP/UDP/IP-Header bezüglich dem Ganz-Header in dem ersten empfangenen Ganz-Header-Paket wieder her, und schreibt die so dekomprimierten-Header in ein internes Speichergerät. Danach verwendet der Empfängerknoten die statischen Felder der RTP/UDP/IP-Header, derart, dass die statischen Felder des komprimierten-Headers in dem Header-komprimierten Paketen wiederhergestellt werden, die sukzessiv nach dem ersten Paket empfangen werden.
  • Die Daten in den statischen Feldern sind nicht immer konstant über die IP-Pakete, aber können sich in einem gewissen IP-Paket ändern. Falls solch eine Änderung in einem gewissen IP-Paket auftritt, wird der Senderknoten ein Ganz-Header-Paket einschließlich einem ganzen Header entsprechend zu dem RTP/UDP/IP-Header des IP-Pakets an den Empfängerknoten ohne Kompression übertragen.
  • Die Daten in den Abschnitten, auf die kein Hatching in den RTP/UDP/IP-Headern angewandt wird, wie in 11A gezeigt, enthalten die Sequenznummer und einen Zeitstempels des RTP-Headers, sowie die ID des IP-Headers. Der Zeitstempel kennzeichnet die Zeit, zu der ein Paket übertragen oder erzeugt wird. Von solchen Daten wird erwartet, dass sie konstante Unterschiedswerte (geänderte Mengen) zwischen zwei hintereinanderfolgenden IP-Paketen aufweisen, die der Reihe nach übertragen werden. Hier im folgenden werden solche Felder, die solche Daten bereitstellen, als "Delta-Felder" bezeichnet. Wie in 11B gezeigt, enthält der grundlegende komprimierte Header nicht die Daten in den Delta-Feldern. Wie oben beschrieben, fügt der Empfängerknoten, der die RTP/UDP/IP-Header in seinem Speichergerät hält, Unterschiedswerte hinzu, die vorher erhalten wurden, entsprechend zu den Werten in den entsprechenden Delta-Feldern der gespeicherten RTP/UDP/IP-Header, wobei er dabei in die Lage versetzt wird, Delta-Felder der komprimierten-Header zu dekomprimieren, die hintereinanderfolgend danach empfangen werden.
  • Jedoch ist es nicht immer wahr, dass die Unterschiedswerte in den Delta-Feldern zwischen allen IP-Paketen konstant sind. Es gibt einige Fälle, wo Änderungen an ihren Unterschiedswerten gemacht werden. In solchen Fällen müssen geänderte Unterschiedswerte dem Empfängerknoten mitgeteilt werden. Der Empfängerknoten ist in der Lage, die Inhalte in den Delta-Feldern wiederherzustellen, die in den RTP/UDP/IP-Headern jedes Header-komprimierten Pakets enthalten sind, das danach empfangen wird, mit Bezug auf die Inhalte der RTP/UDP/IP-Header, die in dem Speichergerät gehalten werden, und den neu mitgeteilten Unterschiedswerten. Zu diesem Zweck weist der komprimierte Header, wie in 11A gezeigt, Flags bzw. Flaggen S, T and I auf, die repräsentieren, ob die Unterschiedswerte in den Delta-Feldern geändert werden oder nicht. Falls ein Unterschiedswert geändert wird, werden neue Unterschiedswerte an den komprimierten-Header hinzugefügt, wie durch die gepunktete Linie in 11B gezeigt. Praktisch wird, falls es keine Änderung in dem Unterschiedswert der Sequenznummer des RTP-Headers gibt, "1" für die Flag S gesetzt, und ein Sequenznummerunterschiedswert (Delta-RTP-Sequenz), der den neuen Unterschiedswert der Sequenznummer zeigt, wird an den komprimierten-Header hinzugefügt, wie durch die punktierte Linie in 11B gezeigt. Ähnlich wird, falls es eine Änderung in dem Unterschiedswert des Zeitstempels des RTP-Headers gibt, "1" für die Flag T gesetzt, und ein Zeitstempelunterschiedswert (Delta-RTP-Zeitstempel), der den neuen Unterschiedswert des Zeitstempels zeigt, wird in den komprimierten-Header eingefügt, wie durch die punktierte Linie in 11B gezeigt. Ferner wird, falls es eine Änderung in dem Unterschiedswert der ID des IP-Headers gibt, "1" für die Flag I gesetzt, und ein ID-Unterschiedswert (Delta-IP-ID), der den neuen Unterschiedswert der ID zeigt, wird dem komprimierten-Header angefügt.
  • Wie in 11B gezeigt, enthält der komprimierte-Header ferner die CONTEXT_ID und link_seq, wie der ganze Header. Der Empfängerknoten komprimiert den komprimierten-Header gemäß den Inhalten der RTP/UDP/IP-Header, spezifiziert durch die CONTEXT_ID. Der Empfängerknoten bezieht sich auf die Link-Sequenznummer link seq von jedem Paket (Header-komprimierten Paket oder Ganz-Header-Paket), das in der Reihenfolge von dem Senderknoten gesendet wird. Wenn herausgefunden wird, dass einige Link-Sequenznummern bzw. Verbindungssequenznummer fallengelassen werden, bestimmt der Empfängerknoten, dass die Pakete zwischen dem Sender- und Empfängerknoten verloren sind.
  • Unter Bezugnahme auf 12 werden nun für Paketübertragung zwischen dem Sender- und Empfängerknoten durchgeführte Verfahren beschrieben. In 12 zeigt ein Feld A ein statisches Feld der RTP/UDP/IP-Header (das heißt, irgendwelche der Daten, auf die das dichte Hatching in 11A angewandt wird), und ein Feld B zeigt ein Delta-Feld (das heißt, irgendwelche der Daten, auf die kein Hatching in 11A angewandt wird). Ferner repräsentiert in 12 "F" ein Ganz-Header-Paket, während "C" ein Header-komprimiertes Paket repräsentiert.
  • Beim Empfangen eines IP-Pakets a, das von einem Senderdatenendgerät an ein Empfängerdatenendgerät übertragen wird, speichert der Senderknoten die RTP/UDP/IP-Header des IP-Pakets a in seinem internen Speichergerät. Gleichzeitig produziert der Senderknoten einen ganzen Header durch Substituieren von Längen in den Headern für eine CONTEXT_ID und Verbindungssequenznummer link_seq, und überträgt an den Empfängerknoten das Ganz-Header-Paket einschließlich sowohl des produzierten ganzen Headers als auch Daten (die im folgenden als eine "RTP-Nutzlast" bezeichnet werden), die den Teil des IP-Pakets darstellen, OHNE die RTP/UDP/IP-Header (bezugnehmend auf "OP1" in 12). Der Empfängerknoten, der dieses Ganz-Header-Paket empfängt, stellt die RTP/UDP/IP-Header von dem ganzen Header dieses Pakets wieder her (nämlich die CONTEXT_ID und link_seq werden von dem ganzen Header extrahiert), und überträgt das IP-Paket mit diesem Header an den nächsten Knoten oder ein Empfängerdatenendgerät. In diesem Betrieb werden die dekomprimierten RTP/UDP/IP-Header in ihrem internen Speichergerät gespeichert.
  • Der Senderknoten konvertiert dann die RTP/UDP/IP-Header in ein IP-Paket b, empfangen nach dem IP-Paket a, in einen komprimierten-Header und überträgt das Paket b mit dem komprimierten-Header an den Empfängerknoten (bezugnehmend auf "OP2" in 12). In dem komprimierten-Header in dem Header-komprimierten Paket wird ein Unterschiedswert ΔB(= 1) zwischen einem Wert [1] in den Delta-Feldern B des Pakets b und ein Wert [0] in den Delta-Feldern B des letzten Pakets a hinzugefügt, während ein Wert von "1" für die Flags (Flags S, T und I, gezeigt in 11B) gesetzt wird, die Änderungen oder Nicht-Änderungen in dem Unterschiedswert darstellen.
  • Der Empfängerknoten, der das Header-komprimierte Paket b empfängt, erhält die Delta-Felder B des Pakets b durch Hinzufügen des Unterschiedswerts ΔB, der in diesem Paket mitgeteilt wird, zu den Werten der Delta-Felder B der RTP/UDP/IP-Header des letzten IP-Pakets a, das in dem internen Speicher gespeichert wird. Der Empfängerknoten überträgt dann ein IP-Paket b mit sowohl den RTP/UDP/IP-Headern, die die Delta-Felder B enthalten als auch den statischen Feldern A der RTP/UDP/IP-Header, die von dem IP-Paket a extrahiert werden, und der RTP-Nutzlast. Die RTP/UDP/IP-Header, erwähnt beim Dekomprimieren des IP-Pakets b (in diesem Fall die RTP/UDP/IP-Header des letzten IP-Pakets a), werden durch die CONTEXT_ID des Header-komprimierten Pakets b spezifiziert. Die RTP/UDP/IP-Header des IP-Pakets b und der Unterschiedswert ΔB, der in diesem Paket mitgeteilt wird, werden auch in dem internen Speicher gespeichert.
  • Beim nächsten Empfangen eines IP-Pakets c berechnet der Senderknoten einen Unterschiedswert zwischen Werten der Delta-Felder B von sowohl dem IP-Paket c, als auch dem letzten IP-Paket b. Der Unterschiedswert ΔB ist [1](= 3 – 2) in diesem Fall, welches der gleiche ist, wie der vorher dem Empfängerknoten zur letzten Zeit mitgeteilte. Deshalb gibt es keinen Bedarf, dem Empfängerknoten den unveränderten Unterschiedswert mitzuteilen. Daher überträgt der Senderknoten an den Empfängerknoten ein Header-komprimiertes Paket c mit einem komprimierten-Header mit keinem Unterschiedswert (das heißt, Information, die durch die gepunktete Linie in 11B (bezugnehmend auf "OP3" in 12) gezeigt ist. Der Empfängerknoten, der dieses Header-komprimierte Paket c empfängt, fügt den gespeicherten Unterschiedswert ΔB an die Delta-Felder B des vorherigen Pakets b hinzu, wodurch ein Dekomprimieren der Delta-Felder B dieses komprimierten-Headers des Header-komprimierten Pakets durchgeführt wird. Dann sendet der Empfängerknoten ein IP-Paket c, das aus sowohl RTP/UDP/IP-Header mit dem dekomprimierten Wert, als auch den statischen Feldern A, extrahiert von dem ganzen Header des Ganz-Header-Pakets a zusammengesetzt ist, und der RTP-Nutzlast. Das nächste Paket d wird ähnlich verarbeitet.
  • Die Delta-Felder B eines IP-Pakets e, das als nächstes von dem Senderknoten empfangen wird, hat den Wert [5], wobei der Unterschiedswert von den Delta-Feldern B des letzten IP-Pakets d [2] ist. Wenn der Unterschiedswert ΔB auf diese Weise verändert wird, überträgt der Senderknoten ein Header-komprimiertes Paket e mit einem komprimierten-Header, in dem der geänderte neue Unterschiedswert hinzugefügt ist, und die entsprechende Flag wird auf [1] gesetzt. Der Empfängerknoten fügt den neuen mitgeteilten Unterschiedswert zu den Werten der Delta-Felder B des IP-Pakets d so hinzu, dass die Delta-Felder B des Pakets e dekomprimiert werden, dann überträgt er ein IP-Paket, das die dekomprimierten Delta-Felder B enthält.
  • Der Senderknoten empfängt dann ein IP-Paket g, das sich in dem statischen Feld A von dem letzten IP-Paket e unterscheidet. Daher komprimiert, in diesem Fall, der Senderknoten die RTP/UDP/IP-Header dieses IP-Pakets nicht, und überträgt ein Ganz-Header-Paket g mit einem ganzen Header, in dem die Längen in den RTP/UDP/IP-Headern des Pakets g ersetzt werden durch die CONTEXT_ID und link_seq. Der Empfängerknoten, der dieses Ganz-Header-Paket g empfangen hat, konvertiert den ganzen Header in die RTP/UDP/IP-Header und speichert diese in dem internen Speicher.
  • Das Header-Kompressionsverfahren, das durch den RFC2508 geregelt ist, wurde oben beschrieben (hier im folgenden als ein "Verfahren A" bezeichnet). Jedoch litt dieses Verfahren an einigen Nachteilen, die im folgenden beschrieben werden.
  • Beispielsweise wird, wie in 13 gezeigt, eine Vermutung gemacht, dass das Header-komprimierte Paket c zwischen dem Sender- und Empfängerknoten aus irgendeinem Grund verloren ist. Wie oben beschrieben, fügt, beim Dekomprimieren des Pakets d, der Empfängerknoten den Unterschiedswert ΔB an die Delta-Felder B des IP-Paket c hinzu, um die Delta-Feld B des IP-Pakets d zu dekomprimieren. Als Ergebnis ist, wenn das Header-komprimierte Paket c verloren ist, es möglich, die Delta-Feld B des Header-komprimierten Pakets d zu dekomprimieren. Der Empfängerknoten wird daher dazu gebracht, Pakete d, e und f, die in 13 gezeigt sind, fallen zu lassen, die bis zum nächsten Ganz-Header-Paket g empfangen werden. In anderen Worten führt der Verlust der Pakete zu aufeinanderfolgenden Verlusten einiger anderer Pakete, was dazu führt, dass ein Durchsatz reduziert wird, verglichen zu einem Verfahren, in dem die Header-Kompression nicht involviert ist. Insbesondere ist, in Fällen, wo Sender- und Empfängerknoten durch eine drahtlose Verbindung verbunden sind, es für ein Paket wahrscheinlich, dass es in der drahtlosen Verbindung verloren geht. Falls solch ein Verlust auftritt, werden einige andere Pakete häufig bei dem Empfängerknoten fallengelassen. Als eine Technik zum Lösen solch eines Problems, stellen die RFC2507 und 2508, die von der IETF und dem Internet-Draft ausgegeben werden, folgende Verfahren zur Verfügung.
  • Verfahren 1: Wiederholende Übertragung von Ganz-Header-Paketen (RFC2507)
  • In dem Fall des vorhergehenden herkömmlichen Verfahrens A, überträgt der Senderknoten ein Ganz-Header-Paket nur, wenn die statischen Felder eines Headers sich im Wert ändern. Im Gegensatz wählt, wie in 14 gezeigt, dieses Verfahren 1 mehrere zu übertragende IP-Pakete bei jeder vorbestimmten Anzahl von Paketen aus, unabhängig davon, ob die statischen Felder sich im Wert ändern oder nicht. Und die ausgewählten IP-Pakete werden zu den Ganz-Header-Paketen mit ganzen Headern konvertiert, und die Ganz-Header-Pakete werden an den Empfängerknoten übertragen, während die übrigbleibenden IP-Pakete zu Header-komprimierten Paketen, mit komprimierten-Headern konvertiert werden, und die Header-komprimierten Pakete werden an den Empfängerknoten übertragen. In dem Verfahren A werden, da Ganz-Header-Pakete nicht an den Empfängerknoten übertragen werden, solange ihre statischen Felder sich im Wert nicht ändern, alle nach dem Auftreten eines Verlusts eines Pakets übertragenden Paketen verworfen. Im Gegensatz dazu erlaubt das vorliegende Verfahren 1, dass ein Ganz-Header-Paket bei Intervallen derart zu übertragen ist, dass es den Vorteil aufweist, dass die Anzahl von fallengelassenen Paketen, die zum Verlust der Pakete beitragen, verringert werden kann. Jedoch weist das vorliegende Verfahren 1 Kompromisse auf, dass eine längere Periode zum Übertragen von Ganz-Header-Paketen darin resultiert, dass die Anzahl von fallgelassenen Paketen erhöht wird, während eine kurze Periode zum Übertragen von Ganz-Header-Paketen darin resultiert, dass eine große Anzahl von Ganz-Header-Paketen mit großen Overheads übertragen wird, was eine Effizienz in der Kommunikation verringert.
  • Verfahren 2: Anforderung für ganze Header durch Back-Channel bzw. Rückkanal (RFC2507 und 2508)
  • Wie in 15 gezeigt, erlaubt, beim Detektieren des Verlusts eines Pakets, das vorliegende Verfahren 2 dem Empfängerknoten, ein CONTEXT_STATE zu übertragen, eine Nachricht zum Anfordern eines Ganz-Header-Pakets für den Senderknoten. Beim Empfangen des CONTEXT_STATE, überträgt der Senderknoten das nächste IP-Paket an den Empfängerknoten in der Form eines Ganz-Header-Pakets. Als Ergebnis kann ein Intervall, indem einige Pakete fallengelassen werden aufgrund des Verlusts eines gewissen Pakets, auf das Intervall zwischen dem Auftreten des Paketverlusts und dem Empfang eines Ganz-Header-Pakets begrenzt werden, das in Ansprechen auf den CONTEXT_STATE übertragen wird. Trotzdem weist das vorliegende Verfahren einen Nachteil darin auf, dass, wenn das Intervall zwischen der Übertragung des CONTEXT_STATE und dem Empfang eines Ganz-Header-Pakets bei dem Empfängerknoten, das heißt, eine RTT (Rundlaufzeit, englisch: Round Trip Time), größer wird, wird die Anzahl der fallengelassenen Pakete auch erhöht. Zum Kommunizieren von Paketen mittels einer drahtlosen Verbindung, wird solch ein Nachteil ersichtlich, weil die RTT der drahtlosen Verbindung sehr lang ist.
  • Verfahren 3: Zweimal-Algorithmus bzw. Twice Algorithm (RFC2507)
  • Gemäß dem vorliegenden Verfahren 3, werden die komprimierten-Header von Header-komprimierten Paketen, die nach dem Verlust eines gewissen Paketes empfangen werden, dekomprimiert unter Verwendung der RTP/UDP/IP-Header, die am spätesten dekomprimiert werden vor dem Auftreten eines Verlusts des Paketes. Beispielsweise, wie in 16 gezeigt, wird angenommen, dass, nachdem ein Paket b in der Reihenfolge empfangen wird, ein Paket c verloren geht, und dann ein Paket d in der Reihenfolge empfangen wird. In dieser Situation kann, wenn ein Unterschiedswert ΔB unverändert im Wert ist, hinsichtlich der Pakete b bis d, das Delta-Feld B des Pakets d berechnet werden durch Hinzufügen eines Werts eines verdoppelten ΔBs zu den Delta-Feldern B des Pakets b. Über dies hinaus braucht das vorliegende Verfahren die UDP-Prüfsumme, die in einem komprimierten-Header (bezugnehmend auf 11B), enthalten ist, so dass die UDP-Prüfsumme verwendet wird, um zu bestimmen, ob Pakete korrekt dekomprimiert wurden. Jedoch gibt es, wie in 16 gezeigt, in Fällen, wo ein Paket k verloren geht und Unterschiedswerte ΔB der Delta-Felder zwischen Paketen j und k sich ändern, das Problem, das ein Paket l sofort empfangen wird, nachdem der Paketverlust nicht korrekt dekomprimiert werden kann. Insbesondere gibt es eine Möglichkeit, in dem Fall, dass Pakete über eine drahtlose Verbindung kommuniziert werden, dass Pakete in der Sequenz (nämlich über ein langes Intervall) verloren gehen. Bei solch einer Situation wird angenommen, dass Unterschiedswerte ΔB sich wahrscheinlich bei einer großen Anzahl von verlorenen Paketen ändern. Deshalb wird das vorhergehende Problem verstärkt.
  • Verfahren 4, ROCCO (Internet-Entwurf), beispielsweise Jonsson L.E. et al., 18. Januar 2000 (2000-01-18), XP002251736, abgerufen aus dem Internet:
    • <URL:http://www.ludd.luth.se/users/larsman/rocco/draft/draft-jonsson-robust-hc-03.txt>.
  • Gemäß dem vorliegenden Verfahren 4 kann der Unterschiedswert ΔB für eine Charakteristik eines Mediums durch das Pakete übertragen werden, abgeschätzt werden. Beispielsweise wird in dem Fall von 17 angenommen, dass Pakete g und h verloren sind, und Unterschiedswerte ΔB zwischen den Paketen g und h sich ändern. In diesem Fall werden Änderungen in Unterschiedswerten ΔB für eine Charakteristik eines Mediums, durch welches Pakete übertragen werden, abgeschätzt, und ein Paket kann dekomprimiert werden, durch Hinzufügen des abgeschätzten Unterschiedswerts ΔB zu dem Paket f. Zusätzlich verwendet das vorliegende Verfahren einen Fehlerdetektiercode (CRC), um zu bestätigen, ob die Dekomprimierung korrekt ausgeführt wird oder nicht. Daher erlaubt das vorliegende Verfahren, sogar wenn der Unterschiedswert ΔB sich ändert, dass nach dem Verlust eines gewissen Pakets empfangene Pakete dekomprimiert werden. Jedoch beinhaltet das vorliegende Verfahren eine Schwierigkeit darin, wie der Unterschiedswert ΔB abgeschätzt wird.
  • Wie oben beschrieben, hat, obwohl eine Vielzahl von Techniken vorgeschlagen wurde, um eine Datenkommunikation effizient durchzuführen, sogar wenn RTP/UDP/IP-Header von IP-Paketen komprimiert werden, jede Technik einige Nachteile. Daher gibt es die vorliegende Situation, dass es eine Begrenzung beim effektiven Verringern der Anzahl von zu fallenlassenden Paketen gibt, die zu dem Verlust eines gewissen Pakets beitragen, der zwischen dem Sender und Empfängerknoten hervorgerufen wurde.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Die vorliegende Erfindung wurde durchgeführt hinsichtlich der vorausgehenden Umstände. Eine Aufgabe der vorliegenden Erfindung ist es, ein Paketübertragungsverfahren bereitzustellen, ein Weiterübertragungsgerät und ein Datenendgerät, die in der Lage sind, die Anzahl von zu fallenlassenden Pakete zu verringern, aufgrund des Verlusts eines gewissen Pakets, selbst wenn Header von zu übertragenden und empfangenen Paketen komprimiert werden.
  • Gemäß einem Aspekt der vorliegenden Erfindung, wird eine Aufgabe der vorliegenden Erfindung durch ein Paketübertragungsverfahren nach Anspruch 1 gelöst.
  • In dem Verfahren werden Header-komprimierte Pakete, die bis zu dem frühsten Empfang eines Ganz-Header-Pakets nach dem Verlust eines Pakets empfangen werden, beibehalten, und die komprimierten Header der Header-komprimierten Pakete, die daher behalten werden, werden basierend auf den Inhalten des Ganz-Header-Pakets dekomprimiert. Als Ergebnis kann, verglichen zu dem vorhergehenden Stand der Technik, die Anzahl von Paketen, die aufgrund des Paketsverlusts fallengelassen werden, verringert werden.
  • Die vorliegende Erfindung stellt des weiteren ein Paketempfangsverfahren gemäß Anspruch 9 bereit.
  • Die vorliegende Erfindung kann so verkörpert werden, dass die Weiterübertragungsvorrichtungen gemäß Anspruch 7 oder die Datenendgeräte gemäß Anspruch 8 zum Übertragen von Paketen gemäß dem Paketübertragungsverfahren der vorliegenden Erfindung produziert oder verkauft werden können. Des weiteren kann die vorliegende Erfindung so verkörpert werden, dass das Programm, das das Paketempfangsverfahren der vorliegenden Erfindung nach Anspruch 10 ausführt, in dem Speichermedium aufgezeichnet werden kann, das lesbar durch den Computer nach Anspruch 11 ist, und die Medien an Benutzer liefern kann oder das Programm an Benutzer durch elektronische Kommunikationsschaltungen bereitstellt.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • 1 zeigt ein Blockdiagramm, das beispielhaft ist für die Konfiguration eines Kommunikationssystems gemäß einer ersten Ausführungsform der vorliegenden Erfindung.
  • 2 zeigt ein Blockdiagramm, das beispielhaft ist für die Konfiguration eines Empfängerknotens in dem Kommunikationssystem.
  • 3 zeigt ein Zeitdiagramm bzw. Zeitverhaltendiagramm, das einen Betrieb zeigt, der durch das Kommunikationssystem ausgeführt wird.
  • 4A und 4B stellen ein Flussdiagramm dar, das einen Betrieb mit Paketverlust zeigt, der durch den Empfängerknoten des Kommunikationssystem ausgeführt wird.
  • 5A und 5B stellen ein Flussdiagramm dar, das einen Betrieb mit Paketverlust zeigt, der in einer Variation der ersten Ausführungsform ausgeführt wird.
  • 6A, 6B und 6C zeigen die Konfiguration eines ganzen Headers, der in einer zweiten Ausführungsform der vorliegenden Erfindung verwendet wird.
  • 7 zeigt ein Timing-Diagramm bzw. Zeitdiagramm, das einen Betrieb zeigt, der durch das Kommunikationssystem ausgeführt wird.
  • 8A und 8B stellen ein Flussdiagramm dar, das einen Betrieb mit Paketverlust zeigt, der durch die Weiterübertragungsvorrichtung auf dem Empfängerknoten des Kommunikationssystems ausgeführt wird.
  • 9 zeigt eine Darstellung, die beispielhaft ist für einen gespeicherten Inhalt eines Speichers in dem Empfängerknoten in dem Fall, dass ein Paket in dem Kommunikationssystem verloren geht.
  • 10 zeigt ein Zeitdiagramm, das einen Betrieb eines Kommunikationssystems gemäß der dritten Ausführungsform der vorliegenden Erfindung zeigt.
  • 11A repräsentiert Inhalte von RTP/UDP/IP-Headern und 11B repräsentiert die Inhalte eines komprimierten Headers.
  • 12 zeigt ein Zeitdiagramm, das beispielhaft ist für Verfahren eines herkömmlichen Paketübertragungsverfahrens (herkömmliches Verfahren A).
  • 13 zeigt ein Zeitdiagramm, das einen Nachteil des herkömmlichen Paketübertragungsverfahrens darstellt.
  • 14 zeigt ein Zeitdiagramm, das beispielhaft ist für Verfahren eines herkömmlichen Paketübertragungsverfahrens (Verfahren 1).
  • 15 zeigt ein Zeitdiagramm, das beispielhaft ist für Verfahren eines herkömmlichen Paketübertragungsverfahrens (Verfahren 2).
  • 16 zeigt ein Zeitdiagramm, das beispielhaft ist für Verfahren eines herkömmlichen Paketübertragungsverfahrens (Verfahren 3).
  • 17 zeigt ein Zeitdiagramm, das beispielhaft ist für Verfahren eines herkömmlichen Paketübertragungsverfahrens (Verfahren 4).
  • DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
  • Mit Bezug auf die begleitenden Zeichnungen, werden nun Ausführungsformen der vorliegenden Erfindung beschrieben.
  • A: Erste Ausführungsform
  • A-1: Konfiguration der ersten Ausführungsform
  • 1 zeigt ein Blockdiagramm, das bildlich beispielhaft ist für eine Konfiguration eines Kommunikationssystems, in dem ein Paketübertragungsverfahren der vorliegenden Erfindung angewendet werden kann. In dem Kommunikationssystem werden ein Senderdatenendgerät 1 und ein Empfängerdatenendgerät 2 so bereitgestellt, dass sie Pakete durch ein Netzwerk 3 austauschen. Die vorliegende Erfindung wird hier im folgenden mit Bezug auf ein Beispiel beschrieben, in dem das Senderendgerät 1 Pakete an das Empfängerendgerät 2 sendet.
  • Das Netzwerk 3 enthält einen Senderknoten 3a und einen Empfängerknoten 3b. Weiterübertragungsvorrichtungen werden bereitgestellt bei dem Senderknoten 3a und dem Empfängerknoten 3b. Die Weiterübertragungsvorrichtungen haben eine Funktion zum Weiterübertragen von Paketen, die zwischen den Sender- und Empfängerdatenendgeräten 1 und 2 auszutauschen sind. Obwohl das Netzwerk 3 der 1 beispielhaft ist für eine Konfiguration mit dem Sender- und dem Empfängerknoten 3a und 3b, ist die vorliegende Erfindung nicht auf diese Konfiguration beschränkt. Drei oder mehr Knoten und Weiterübertragungsvorrichtungen, die daran bereitgestellt sind, können in dem Netzwerk enthalten sein.
  • In dieser Konfiguration sendet das Senderdatenendgerät 1 der Reihe nach Pakete, die für das Empfängerdatenendgerät 2 bestimmt sind, durch das Netzwerk 3. Ein von dem Senderdatenendgerät 1 zu sendendes Paket ist ein IP-Paket mit RTP/UDP/IP-Headern, die in 11A gezeigt sind. Die Weiterübertragungsvorrichtung an dem Senderknoten 3a empfängt der Reihe nach IP-Pakete, die von dem Senderdatenendgerät 1 gesendet werden, konvertiert die empfangenen IP-Pakete in entweder Ganz-Header-Pakete mit jeweils einem ganzen Header oder Header-komprimierte Pakete mit jeweils einem komprimierten Header und sendet sie an den Empfängerknoten 3b. Wie vorher beschrieben, ist der ganze Header ein Header, in dem ein Längenwert, der in einem IP-Header oder UDP-Header der RTP/UDP/IP-Header eines IP-Pakets enthalten ist, ersetzt wird durch Daten mit CONTEXT_ID oder link_seq. Andererseits stellt, beim Empfangen des Header-komprimierten Pakets oder Ganz-Header-Pakets, das von dem Senderknoten 3a übertragen wird, die Weiterübertragungsvorrichtung an dem Empfängerknoten 3b die RTP/UDP/IP-Header von dem komprimierten Header des Header-komprimierten Pakets oder von dem ganzen Header des Ganz-Header-Pakets wieder her, und sendet ein IP-Paket mit den RTP/UDP/IP-Headern an das Empfängerdatenendgerät 2. Das Empfängerdatenendgerät 2 empfängt ein IP-Paket, das von dem Empfängerknoten 3b gesendet wird, und führt eine vorbestimmte Verarbeitung aus (beispielsweise ein Anzeigen von Bildern, Abspielen von Ton oder ähnlichem gemäß einer RTP-Nutzlast) gemäß dem empfangenen IP-Paket.
  • Wie bei der vorher beschriebenen herkömmlichen Technik, steht das Ganz-Header-Paket dafür, einem Paket zu ermöglichen, ein IP-Paket mit RTP/UDP/IP-Headern wiederherzustellen, basierend auf nur Inhalten des ganzen Headers, enthalten in dem Ganz-Header-Paket. Die Längenwerte, die in den RTP/UDP/IP-Headern enthalten sind, werden durch eine CONTEXT_ID und link_seq ersetzt, jedoch können die Längenwerte wiederhergestellt werden bezüglich der Information hinsichtlich unteren Schichten. Im Gegensatz steht das Header-komprimierte Paket für ein Paket, das dekomprimiert zu einem IP-Paket werden kann, basierend auf anderen Paketen (wie zum Beispiel Ganz-Header-Paket), und kann nicht zu einem IP-Paket mit RTP/UDP/IP-Headern dekomprimiert werden, basierend nur auf dem komprimierten-Header, der in dem Header-komprimierten Paket enthalten ist.
  • Bezugnehmend auf 2 wird nun die Weiterübertragungsvorrichtung beschrieben, die an dem Empfängerknoten 3b bereitgestellt wird. Wie in der Zeichnung gezeigt, enthält die Weiterübertragungsvorrichtung an dem Empfängerknoten 3b ein Empfangsteil 31b, Übertragungsteil 32b, Steuerteil 33b, Speicherteil 34b und einen Bus 35b, der diese Einheiten miteinander verbindet.
  • Das Empfangsteil 31b dient als eine Einrichtung oder Einheit zum Empfangen eines Ganz-Header-Pakets oder eines Header-komprimierten Pakets, das von dem Senderknoten 3a durch eine Kommunikationsleitung gesendet wird und Ausgeben des Pakets an das Steuerteil 33b. Das Übertragungsteil 32b dient als eine Einrichtung zum Übertragen der Daten, die von dem Steuerteil 33b durch eine Kommunikationsleitung an das Empfängerdatenendgerät 2 ausgegeben werden.
  • Das Steuerteil 33b enthält eine CPU oder eine andere Verarbeitungseinheit und Funktionen als Einrichtung zum Steuern jeder Einheit des Empfängerknotens 3b durch Ausführen eines Programms, das in dem Speicherteil 34b gespeichert ist. Genauer gesagt, weist das Steuerteil 33b eine Funktion zum Konvertieren bzw. Umwandeln eines Ganz-Header-Pakets oder eines Header-komprimierten Pakets auf, das über das Empfangsteil 31b von dem Senderknoten 3a empfangen wird, in ein IP-Paket und zum Übertragen desselben an das Empfängerdatenendgerät 2 durch das Übertragungsteil 32b. Zusätzlich ist das Steuerteil 33b der vorliegenden Ausführungsform in der Lage zum Detektieren des Verlustes eines Pakets, der auf dem Kommunikationspfad von dem Senderknoten 3a an den Empfängerknoten 3b aufgetreten ist. Wenn der Paketverlust detektiert wird, ist das Steuerteil 33b in der Lage, einen CONTEXT_STATE zu übertragen, um die Übertragung eines Ganz-Header-Pakets an den Senderknoten 3a anzufordern.
  • Übrigens, bei der vorhergehenden verwandten Technik der vorliegenden Erfindung, in Fällen, in denen ein Paket auf dem Kommunikationspfad von dem Senderknoten and den Empfängerknoten verloren geht, wurden die Pakete, die während des Intervalls zwischen dem Auftreten eines Paketverlusts und Empfangs des frühsten Ganz-Header-Pakets nachdem der Paketverlust auftritt, empfangen. Im Gegensatz schreibt das Steuerteil 33b der Weiterübertragungsvorrichtung an den Empfängerknoten 3b gemäß der vorliegenden Erfindung der Reihe nach, in das Speicherteil 34b, Header-komprimierte Pakete, die während einem Intervall empfangen wurden, zwischen der Detektion eines Paketverlusts und dem Empfang des frühsten Ganz-Header-Pakets nach dem Verlust. Beim Empfangen eines Ganz-Header-Pakets nach dem Paketverlust, dekomprimiert die Weiterübertragungsvorrichtung an dem Empfängerknoten 3b dann die komprimierten Header der Header-komprimierten Pakete, die in dem Speicherteil 34b gespeichert sind, basierend auf den Inhalten des ganzen Headers des empfangenen Ganz-Header-Pakets, so dass die ursprünglichen IP-Pakete erstellt werden, und überträgt die erstellten IP-Pakete an das Empfängerdatenendgerät 2. Die Verarbeitung, die durch das Steuerteil 33b ausgeführt wird, wird detailliert in ihrem Betrieb später beschrieben.
  • Die Weiterübertragungsvorrichtung an dem Senderknoten 3a ist ähnlich zu der vorhergehenden Weiterübertragungsvorrichtung an dem Empfängerknoten 3b konfiguriert. In anderen Worten, die Weiterübertragungsvorrichtung an dem Senderknoten 3a enthält ein Empfangsteil 31b zum Empfangen von IP-Paketen von dem Senderdatenendgerät 1, ein Steuerteil 33a zum Steuern jeder Einheit dieses Knotens 3a, ein Speicherteil 34a und ein Übertragungsteil 32a zum Übertragen von IP-Paketen, die von dem Steuerteil 33a an den Empfängerknoten 3b ausgegeben werden. In der vorliegenden Ausführungsform überträgt das Steuerteil 33a der Weiterübertragungsvorrichtung an diesen Knoten 3a jedoch an den Empfängerknoten 3b, sowohl mindestens das erste der IP-Pakete, die von dem Senderdatenendgerät 1 übertragen werden, als Ganz-Header-Paket, als auch andere IP-Pakete als Header-komprimierte Pakete. Des weiteren konvertiert, beim Empfangen des CONTEXT_STATEs von dem Empfängerknoten 3b, das Steuerteil 33a der Weiterübertragungsvorrichtung an den Senderknoten 3a ein sofort zu übertragendes IP-Paket nach dem Empfang, in ein Ganz-Header-Paket und überträgt das Ganz-Header-Paket an den Empfängerknoten 3b.
  • A-2: Betrieb der ersten Ausführungsform
  • Die 3 zeigt ein Zeitdiagramm, das beispielhaft ist für einen Betrieb für das Paketübertragungsverfahren der vorliegenden Ausführungsform.
  • Wie in der Zeichnung gezeigt, konvertiert, beim Empfangen des ersten IP-Pakets a von dem Senderdatenendgerät 1, das Steuerteil 33a der Weiterübertragungsvorrichtung an den Senderknoten 3a das Paket a in ein Ganz-Header-Paket und überträgt das Ganz-Header-Paket an den Empfängerknoten 3b. Genauer gesagt, schreibt das Steuerteil 33a die RTP/UDP/IP-Header des IP-Pakets in das Speicherteil 34a, und erstellt einen ganzen Header, in dem Längenfelder, die in den RTP/UDP/IP-Headern enthalten sind, ersetzt werden durch Informationsstücke mit der CONTEXT_ID und link_seq. Das Steuerteil 33a bildet dann ein Ganz-Header-Paket a einschließlich sowohl dem erstellten ganzen Header und einer RTP-Nutzlast in dem IP-Paket und sendet das Ganz-Header-Paket an den Empfängerknoten 3b.
  • Dann konvertiert, beim Empfangen eines IP-Paket b von dem Senderdatenendgerät 1, das Steuerteil 33a, das IP-Paket b in ein Header-komprimiertes Paket und überträgt das Header-komprimierte Paket an den Empfängerknoten 3b. Praktisch schreibt das Steuerteil 33a die RTP/UDP/IP-Header des IP-Pakets b in das Speicherteil 34a und berechnet auch Unterschiedswerte zwischen dem Wert in den Delta-Feldern der geschriebenen RTP/UDP/IP-Header des IP-Pakets b und den Wert in Delta-Feldern der RTP/UDP/IP-Header des IP-Pakets a, gespeichert in dem Speicherteil 34a. Das Steuerteil 33a erstellt dann einen komprimierten Header einschließlich der berechneten Unterschiedswerte und überträgt ein Header-komprimiertes Paket einschließlich der erstellten Header und eine RTP-Nutzlast des IP-Pakets b. Dann schreibt, beim Empfangen eines IP-Pakets c von dem Senderdatenendgerät 1, das Steuerteil 33a die RTP/UDP/IP-Header des IP-Pakets b in das Speicherteil 34a. Ferner berechnet das Steuerteil 33a Unterschiedswerte zwischen dem Wert in den Delta-Feldern der geschriebenen RTP/UDP/IP-Header des IP-Pakets c und dem Wert in den Delta-Feldern der RTP/UDP/IP-Header des IP-Pakets b, gespeichert in dem Speicherteil 34a. Das Steuerteil 33a bestimmt, ob die berechneten Unterschiedswerte gleich den Unterschiedswerten sind, die in dem Speicherteil 34a gespeichert sind (das bedeutet, Unterschiedswerte zwischen dem IP-Paket b und dem IP-Paket a). Falls bestimmt wird, dass beide der Unterschiedswerte die gleichen sind, ist es nicht notwendig, den Empfängerknoten 3b wieder über die Unterschiedswerte zu benachrichtigen. In diesem Fall erstellt das Steuerteil 33a einen komprimierten-Header ohne die Unterschiedswerte und überträgt ein Header-komprimiertes Paket c mit dem komprimierten-Header an den Empfängerknoten 3b. Wenn bestimmt wird, dass die vorhergehenden Unterschiedswerte nicht gleich zu den vorherigen sind, wird es andererseits verlangt, die neuberechneten Unterschiedswerte nun mitzuteilen. Daher wird, beim Betrieb des Steuerteils 33a, ein komprimierter-Header mit den Unterschiedswerten erstellt, und ein Header-komprimiertes Paket, das den so erstellten komprimierten-Header enthält, und eine RTP-Nutzlast des IP-Pakets c werden an den Empfängerknoten 3b übertragen. Zusätzlich aktualisiert das Steuerteil 33a die Unterschiedswerte (das heißt, die Unterschiedswerte zwischen den IP-Paketen a und b), die bis jetzt in dem Speicherteil 34a gespeichert wurden, zu den dieses Mal neuerhaltenen Unterschiedswerten.
  • Hier im folgenden wird, beim Empfangen von IP-Paketen d, e und f, die von dem Empfängerdatenendgerät 2 gesendet werden, die identische Verarbeitung zu dem IP-Paket c für solche IP-Pakete ausgeführt, und entweder ein Header-komprimiertes Paket mit Unterschiedswerten oder ein Header-komprimiertes Paket ohne Unterschiedswerte wird an den Empfängerknoten 3b gesendet.
  • In dem Fall eines in 3 gezeigten Beispiels, wird eine Situation angenommen, in der das CONTEXT_STATE von dem Empfängerknoten 3b sofort vor einem Empfangen eines IP-Pakets g von dem Senderdatenendgerät 1 empfangen wird. In diesem Fall überträgt das Steuerteil 33a in dem Senderknoten 3a das sofort zu übertragende IP-Paket g nach dem Empfang des CONTEXT_STATEs, als ein Ganz-Header-Paket g. Danach überträgt das Steuerteil 33a in dem Senderknoten 3a an den Empfängerknoten 3b auf ähnliche Weise Pakete h bis l, als Header-komprimierte Pakete und ein zu übertragendes Paket m sofort nach dem Empfang des CONTEXT_STATEs, als ein Ganz-Header-Paket.
  • Andererseits dekomprimiert, beim Empfangen des Ganz-Header-Pakets a das Steuerteil 33b in dem Empfängerknoten 3b die RTP/UDP/IP-Header von dem ganzen Header, der in diesem Paket enthalten ist. Das Steuerteil 33b überträgt dann das IP-Paket a mit den dekomprimierten RTP/UDP/IP-Headern an das Empfängerdatenendgerät 2 und speichert diese Header in dem Speicherteil 34b. Dann bezieht sich, beim Empfangen des nächsten Header-komprimierten Pakets b, das Steuerteil 33b auf die Inhalte der RTP/UDP/IP-Header des IP-Pakets a, die in dem Speicherteil 34b gespeichert sind. Durch diese Bezugnahme stellt das Steuerteil 33b die RTP/UDP/IP-Header von dem komprimierten Header des Header-komprimierten Pakets b wieder her und überträgt das so erhaltene IP-Paket b an das Empfängerdatenendgerät 2.
  • 3 ist beispielhaft für eine Situation, in der ein Header-komprimiertes Paket c, das von dem Senderknoten 3a übertragen wird, aus irgendeinem Grund verloren geht. In diesem Fall empfängt das Steuerteil 33b in dem Empfängerknoten 3b das nächste Header-komprimierte Paket d, das nach dem verlorenen einen c übertragen wird und erkennt die Diskontinuität zwischen dem link_seq des Pakets d und dem von dem Paket b. Daher erlaubt diese Erkennung dem Steuerteil 33b, die Tatsache zu detektieren, dass das Paket c verloren ist. Wenn der Verlust des Pakets c detektiert wird, überträgt das Steuerteil 33b den CONTEXT_STATE an den Senderknoten 3a und schreibt der Reihe nach, in das Speicherteil 34b, Header-komprimierte Pakete, die während dem Intervall empfangen werden, zwischen dem Paketverlust und dem Empfang des frühesten Ganz-Header-Pakets nach dem Verlust. In dem Beispiel von 3 werden Header-komprimierte Pakete d bis f zwischen dem Auftreten eines Verlusts des Pakets c und dem Empfang eines Ganz-Header-Pakets g empfangen. Diese so empfangenen Header-komprimierten Pakete werden nacheinanderfolgend in das Speicherteil 34b eingeschrieben. Das Steuerteil 33b empfängt dann das Ganz-Header-Paket g, das von dem Senderknoten 3a gesendet wird, in Ansprechen auf den CONTEXT_STATE. In der vorliegenden Ausführungsform subtrahiert das Steuerteil 33b einen Unterschiedswert Δ der Reihe nach von den Werten in den Delta-Feldern des Ganz-Header-Pakets g, womit es ermöglicht wird, die Delta-Felder der Header der Pakete d bis f zu dekomprimieren. Praktisch führt, wie in 3 gezeigt, die Subtraktion des Unterschiedswerts Δ von den Werten in den Delta-Feldern der Ganz-Header-Pakete g zu einem Dekomprimieren von Inhalten in den Delta-Feldern des Pakets f, dann führt die Subtraktion des Unterschiedswerts Δ von den dekomprimierten Werten in den Delta-Feldern des Ganz-Header-Pakets f zu einem Dekomprimieren von Inhalten in den Delta-Feldern des Pakets e, und so weiter. In der vorliegenden Ausführungsform werden, basierend auf den Inhalten der RTP/UDP/IP-Header des IP-Pakets b, das in dem Speicherteil 34b gespeichert ist, die Inhalte in den statischen Feldern der Pakete d bis f dekomprimiert. Deshalb werden die RTP/UDP/IP-Header der Pakete d bis f bezüglich der Inhalte dekomprimiert. Hier im folgenden wird, mit Bezug auf ein in den 4A und 4B gezeigtes Flussdiagramm, die durch das Steuerteil 33b der Weiterübertragungsvorrichtung an dem Empfängerknoten ausgeführte Verarbeitung zum Komprimieren der vorhergehenden Kompressions-Header im Detail beschrieben.
  • Zuerst setzt, beim Detektieren des Verlusts des Pakets c mittels des Fehlers der durch die link_seq repräsentierte Anzahl, das Steuerteil 33b [0] auf ein Register N (Schritt S1). Dann erhöht das Steuerteil 33b den Wert des Registers N um [1] (Schritt S3).
  • Dann dekomprimiert, in den RTP/UDP/IP-Headern, die basierend auf dem Header-komprimierten Paket d dekomprimiert werden sollten, das Steuerteil 33b die statischen Felder, Längenwerte, UDP-Prüfsumme und Markierungs-Bit. Im einzelnen liest das Steuerteil 33b die RTP/UDP/IP-Header des IP-Pakets b, das in dem Speicherteil 34b gespeichert wird, und bringt die statischen Felder des RTP/UDP/IP-Headers des Pakets d dazu, dass sie mit den statistischen Feldern identisch sind, die in dem so gelesenen Header enthalten sind. Die UDP-Prüfsumme und das Markierungs-Bit werden in einen komprimierten-Header eingefügt, wie in 11B dargestellt. Die Längenwerte können mittels der Information von den unteren Schichten erhalten werden. In dem Fall, dass ein neuer Unterschiedswert in das Paket d eingefügt wird (das heißt, in dem Fall, dass irgendwelche Daten, die durch die gepunktete Linie in 11B umschlossen sind, eingefügt werden), extrahiert das Steuerteil 33b den Unterschiedswert (Schritt S4).
  • Dann werden, in dem Schritt S4, die RTP/UDP/IP-Header, die teilweise dekomprimiert werden (hinsichtlich der statischen Felder oder ähnlichem) und ein Inhalt der RTP-Nutzlast, die in dem Header-komprimierten Paket d enthalten ist, in dem Speicherteil 34b als Daten-IP (1) gespeichert. Ferner werden ein vorliegender Unterschiedswert der ID des IP-Headers und vorliegende Unterschiedswerte der Sequenznummer und des Zeitstempels des RTP-Headers in das Speicherteil 34b eingeschrieben als ΔIP_ID(1), ΔRTP_SN(1) bzw. ΔRTP_TS(1) (Schritt S5). Diese vorliegenden Unterschiedswerte für die ID, Sequenznummer und Zeitstempel werden abgeschätzt durch Verwenden entweder neuer Unterschiedswerte, falls ein neuer Unterschiedswert hinzugefügt wird zu dem Paket d oder in dem Speicherteil 34b momentan gespeicherte Unterschiedswerte, falls nicht enthalten.
  • Ferner wird, bezüglich der Header-komprimierten Pakete e und f (n = 2 bis 3), die empfangen werden, bis das Ganz-Header-Paket g empfangen wird, die Verarbeitung in den Schritten S2 bis S5 ähnlich wiederholt.
  • Beim Empfangen des Ganz-Header-Pakets g, speichert das Steuerteil 33b den RTP/UDP/IP-Header, der von einem ganzen Header erhalten wird, der darin als IP(4) enthalten ist, in den Speicherteil 34b (Schritt S6). Dann bestimmt, bei der Annahme, dass die Unterschiedswerte zwischen Paket f und dem Ganz-Header-Paket g unverändert bleiben, das Steuerteil 33b die Unterschiedswerte von ID, SN und TS zwischen dem Paket f und dem Ganz-Header-Paket g; das sind, ΔIP_ID(4), ΔRTP_SN(4) unde ΔRTP_TS(4) als die Unterschiedswerte von ID, SN und TS zwischen den Paketen e und f; das sind ΔIP_ID(3), ΔRTP_SN(3) und ΔRTP_TS(3) (Schritt S7). In anderen Worten, werden die Operationen ausgeführt von ΔIP_ID(4) = ΔIP_ID(3), ΔRTP_SN(4) = ΔRTP_SN(3), und ΔRTP_TS(4) = ΔRTP_TS(3).
  • Dann subtrahiert das Steuerteil 33b von jedem Wert in den Delta-Feldern des Ganz-Header-Pakets g, jeden der Werte, die als die Unterschiedswerte zwischen den Paketen f und g betrachtet werden, das heißt, die vorhergehenden ΔIP_ID(4), ΔRTP_SN(4) und ΔRTP_TS(4), womit Inhalte in den Delta-Feldern des Pakets f dekomprimiert werden (Schritt S8). Genauer gesagt, werden, bezüglich des Pakets f, Werte in der ID des IP-Headers und der Sequenznummer (SN) und Zeitstempels (TS) des RTP-Headers, die zu dekomprimierende Ziele sind, ausgedrückt durch IP(3).IP_ID, IP(3).RTP_SN und IP(3).RTP_TS, während bezüglich des Pakets g Werte in der ID des IP-Headers und der Sequenznummer (SN) und Zeitstempels (TS) des RTP-Headers ausgedrückt werden durch IP(4).IP_ID, IP(4).RTP_SN und IP(4).RTP_TS. Die Inhalte der Delta-Felder des Pakets f können durch Berechnung, wie unten gezeigt, dekomprimiert werden. IP(3).IP_ID = IP(4).IP_ID – ΔIP_ID(4) IP(3).RTP_SN = IP(4).RTR_SN – ΔRTP_SN(4) IP(3).RTP_TS = IP(4).RTR_TS – ΔRTP_TS(4)
  • Nachdem die RTP/UDP/IP-Header des Pakets f dekomprimiert wurden, geht das Steuerteil 33b dazu über, zu bestimmen, ob die dekomprimierten Ergebnisse korrekt sind oder nicht, unter Verwendung der UDP-Prüfsumme, die in dem Paket f enthalten ist (Schritt S9). Wenn die Bestimmung derart ist, dass die dekomprimierten Ergebnisse korrekt sind, wird der Wert des Registers N um [1] verringert (Schritt S10). Dann werden die Pakete e und d auch der gleichen Verarbeitung wie in den Schritten S8 und S9 ausgesetzt.
  • Andererseits wird, wenn in dem Schritt S9 bestimmt wird, dass die dekomprimierten Ergebnisse nicht korrekt sind, die Verarbeitung sofort angehalten, und zu Schritt S11 vorgerückt, weil es unmöglich ist, die vor dem Paket f empfangenen Pakete korrekt zu dekomprimieren. Zusätzlich bedeutet es, wenn die Verringerung von N um [1] in Schritt S11 in N = 0 (Schritt S12) resultiert, dass die Dekomprimierung aller der zu dekomprimierenden Pakete abgeschlossen wurde. Demgemäss schreitet die Verarbeitung fort zu Schritt S11.
  • In dem Schritt S11 überträgt das Steuerteil 33b jedes der korrekt dekomprimierten Pakete der Reihe nach an das Empfängerdatenendgerät 2 in der Reihenfolge der Sequenznummer des RTP-Headers, der in jedem Paket enthalten ist. Im Gegensatz dazu werden Pakete, die nicht korrekt dekomprimiert wurden, fallengelassen.
  • Das Kommunikationssystem der vorliegenden Ausführungsform arbeitet in dieser Weise.
  • Wie oben beschrieben, werden, in dem Paketübertragungsverfahren der vorliegenden Ausführungsform, nach dem Auftreten eines Verlusts eines Pakets, empfangene Header-komprimierte Pakete gespeichert, und ihre Header werden dekomprimiert, basierend auf den Inhalten eines nächsten Ganz-Header-Pakets, das nach dem Verlust empfangen wird. Im Gegensatz gab es ein Problem, in dem Fall von jedem oben beschriebenen herkömmlichen Verfahren, in dem einige Pakete, die während dem Intervall zwischen dem Auftreten eines Paketverlusts und dem Empfang eines frühesten Ganz-Header-Pakets nach dem Verlust empfangen werden, fallengelassen werden sollten, selbst wenn diese Pakete richtig empfangen wurden. Die vorliegende Ausführungsform verbessert diesen Punkt, so dass einige Pakete, die während einem solchen Intervall empfangen werden, effektiv verwendet werden können. Verglichen zu der verwandten Technik der vorliegenden Erfindung, kann der Einfluss des Paketverlusts auf ein Datenabspielen oder ähnlichem bei dem Empfängerdatenendgerät verringert werden.
  • A-3: Variation der ersten Ausführungsform
  • Die vorhergehende erste Ausführungsform wurde derart aufgebaut, dass statische Felder der Pakete d bis f, die während dem Intervall von dem Auftreten eines Verlusts des Pakets c zu dem Empfang des frühesten Ganz-Header-Pakets g nach dem Verlust, empfangen werden, gemäß der Inhalte der RTP/UDP/IP-Header des IP-Pakets b dekomprimiert werden, das vor dem Verlust des Pakets c empfangen wird. Jedoch ist die Dekomprimierung nicht auf solch einen Aufbau beschränkt. Beispielsweise können die statischen Felder dieser Pakete d bis f dekomprimiert werden hinsichtlich der Inhalte des Ganz-Header-Pakets g, das am frühesten empfangen wird. Die 5A und 5B stellen ein Flussdiagramm dar, das einen Betrieb einer Paketdekomprimierung in der vorliegenden Variation zeigt. Dieses Flussdiagramm ist das gleiche, wie das, das in den 4A und 4B gezeigt wird, mit der Ausnahme, dass die statischen Felder jedes Pakets, die dekomprimiert werden sollten, dekomprimiert werden basierend auf den Inhalten des Ganz-Header-Pakets g, das nach den zu dekomprimierenden Paketen empfangen wird. Daher werden nur verschiedene Konfigurationen von den 4A und 4B unten beschrieben.
  • In der ersten Ausführungsform wird die Verarbeitung in dem Schritt S4 derart ausgeführt, dass eine Information über die statischen Felder der Header-komprimierten Pakete, die nach dem Paketverlust empfangen werden, dekomprimiert werden, unter Verwendung der statischen Felder der RTP/UDP/IP-Header der IP-Pakete b, die schon empfangen und in dem Speicherteil 34b gespeichert wurden. Jedoch werden in der vorliegenden Variation die statischen Felder nicht in Schritt S4' dekomprimiert. In anderen Worten, werden nur die Längenwerte, UDP-Prüfsumme und das Markierungs-Bit M dekomprimiert. Deshalb sind in dem nächsten Schritt S5, diese, die in dem Speicherteil 34b als ein IP-N gespeichert sind, Pakete, die jeweils sowohl RTP/UDP/IP-Header mit den statischen Feldern und Delta-Felder ausgenommen, aufweisen, sowie eine RTP-Nutzlast des Header-komprimierten Pakets, das zu dieser Zeit empfangen wird.
  • Zusätzlich werden die statischen Felder der zu dekomprimierenden Pakete dekomprimiert, basierend auf den Inhalten des Ganz-Header-Pakets g. Genauer gesagt, werden, wie in Schritt S8' in 5A und 5B unterstrichen, die statischen Felder der zu dekomprimierenden Pakete betrachtet, als in den Inhalten gleich zu sein, wie diese des Ganz-Header-Pakets, das sofort nach diesen Paketen empfangen wird. Beispielsweise werden, angenommen, dass der obengenannte Prozess unter Verwendung der Situation erläutert wird, wie in 3 beispielhaft gezeigt, die Inhalte der statischen Felder des Pakets f unter der Annahme dekomprimiert, dass die statischen Felder des Pakets f die gleichen hinsichtlich der Inhalte sind, wie diese des Ganz-Header-Pakets g, das sofort nach dem Paket f empfangen wird. Auch werden die Inhalte der statischen Felder des Pakets e unter der Annahme dekomprimiert, dass die statischen Felder des Pakets e die gleichen hinsichtlich der Inhalte sind, als diese des so dekomprimierten Pakets f.
  • Auch wird in dieser Variation schließlich die UDP-Prüfsumme verwendet zum Bestimmen, ob die Dekomprimierung korrekt ausgeführt wird oder nicht. Nur die Pakete, die korrekt dekomprimiert wurden, werden an das Empfängerdatenendgerät gesendet. Demgemäss ist die vorliegende Variation in der Lage, den identischen Vorteil, zu dem der ersten Ausführungsform, bereitzustellen.
  • B: Zweite Ausführungsform
  • B-1: Konfiguration der zweiten Ausführungsform
  • In jeder obenbeschriebenen Ausführungsform werden, durch den Empfängerknoten 3b des Netzwerks 3, Header-komprimierte Pakete, die nach dem Auftreten eines Paketverlusts empfangen werden, aufbewahrt, und die aufbewahrten Header-komprimierten Pakete werden dekomprimiert hinsichtlich der Inhalte basierend auf den Inhalten eines Ganz-Header-Pakets, das nach dem Paketverlust empfangen wurde. In dem oben erwähnten Fall, wird jedoch die Dekomprimierung unter der Annahme ausgeführt, dass die Delta-Felder des Ganz-Header-Pakets, das nach dem Paketverlust empfangen wird, unverändert bleichen, in den Unterschiedswerten von diesen eines Header-komprimierten Pakets, sofort nach dem Ganz-Header-Paket (bezugnehmend auf Schritt 57 in 4B). Dies bedeutet, dass, falls der Unterschiedswert sich ändert, ein Problem hervorgerufen wird, bei dem die beibehaltenen Header-komprimierten Pakete nicht länger korrekt dekomprimiert werden. Die vorliegende Ausführungsform bezieht sich auf ein Paketweiterübertragungsverfahren, das in der Lage ist, das Problem zu lösen.
  • In der vorliegenden Ausführungsform sind das Kommunikationssystem, wie auch die Weiterübertragungsvorrichtungen an dem Senderknoten 3a und Empfängerknoten 3b identisch zu den in 1 und 2 gezeigten. Jedoch gibt es einen Unterschied in Arten von Paketen, die von dem Senderknoten 3a an den Empfängerknoten 3b zwischen der vorhergehenden Ausführungsform und der vorliegenden Ausführungsform gesendet werden. Genauer gesagt, werden in der vorhergehenden Ausführungsform, Ganz-Header-Pakete und Header-komprimierte Pakete gesendet, während in der vorliegenden Ausführungsform auch Ganz-Header-Pakete mit Unterschiedswerten, die in einem bestimmten Fall hinzugefügt werden, gesendet werden, zusätzlich zu Ganz-Header-Paketen und Header-komprimierten Paketen. Praktisch überträgt, in den Fällen, in denen ein IP-Paket, das von dem Senderdatenendgerät 1 empfangen wird, als ein Ganz-Header-Paket übertragen werden sollte, und dass Unterschiedswerte zwischen den Delta-Feldern des IP-Pakets und denen des vorhergehenden IP-Pakets, das sofort vor dem IP-Paket empfangen wird, unterschiedlich von den Unterschiedswerten sind, die in dem Speicherteil 34a gespeichert sind (das heißt, die Unterschiedswerte werden verändert), der Senderknoten 3a ein Ganz-Header-Paket mit den neuen Unterschiedswerten an den Empfängerknoten 3b.
  • 6A zeigt bildhaft die Inhalte eines Ganz-Header-Pakets mit Unterschiedswerten. Wie durch die punktierte Linie darin gezeigt, enthält, falls eines der Delta-Felder der RTP/UDP/IP-Header verändert wird (nämlich eines der ID des IP-Headers und der Sequenznummer und Zeitstempel des RTP-Headers verändert wird), das Ganz-Header-Paket den neuen Unterschiedswert. Wie bei den vorhergehenden Ausführungsformen wird der ganze Header des Ganz-Header-Pakets erstellt durch Einfügen der CONTEXT_ID und link_seq in die Längenfelder der IP- und UDP-Header (Teile mit Hatching in 6A). Zusätzlich enthält, wie in den
  • 6B und 6C gezeigt, das Ganz-Header-Paket mit den Unterschiedswerten, Flags S, T und I, sowie die CONTEXT_ID und link_seq. Jedes Flag zeigt, ob jedes Delta-Feld einer Änderung eines Unterschiedswerts ausgesetzt wird. Beispielsweise wird, wenn ein Unterschiedswert für die Sequenznummer des RTP-Headers verändert wird, der neue Unterschiedswert ΔRTP_SN zu dem Header hinzugefügt, wie durch die punktierte Linie in 6A gezeigt, und "1" wird in der Flag S gesetzt. Wenn ein Unterschiedswert für die ID des IP-Headers verändert wird, wird der neue Unterschiedswert ΔIP_ID zu dem Header hinzugefügt, und "1" wird in der Flag I gesetzt. Auch wird, wenn ein Unterschiedswert für den Zeitstempel des RTP-Headers verändert wird, der neue Unterschiedswert ΔRTP_TS zu dem Header hinzugefügt, und "1" wird in der Flag T gesetzt. Beim Empfangen eines Ganz-Header-Pakets, in welches die Unterschiedswerte hinzugefügt werden, überprüft der Empfängerknoten 3b die Flags, um irgendeine Veränderung der Delta-Felder zu detektieren (IP ID, Sequenznummer und Zeitstempel). Diese Operation ermöglicht dem Knoten 3b, einen neuen Unterschiedswert zwischen dem Ganz-Header-Paket und seinem vorherigen Paket zu erhalten.
  • B-2: Betrieb der zweiten Ausführungsform
  • Unter Bezugnahme auf 7 wird nun ein Betrieb der vorliegenden Ausführungsform beschrieben. Wie bei der ersten Ausführungsform, wird ein Fall beispielhaft dargestellt, wo der Senderknoten 3a ein in ein Ganz-Header-Paket verarbeitetes IP-Paket an den Empfängerknoten 3b überträgt, in Ansprechen auf ein Empfangen des CONTEXT_STATEs von dem Empfängerknoten 3b.
  • Die IP-Pakete a bis f, die von dem Senderdatenendgerät 1 gesendet werden, werden der Reihe nach durch den Senderknoten 3a empfangen. Das Steuerteil 33a des Knotens 3a sendet das erste IP-Paket a an dem Empfängerknoten 3b als ein Ganz-Header-Paket und sendet die IP-Pakete b und c als Header-komprimierte Pakete an den Knoten 3b. Diese Operationen sind identisch zu den in der ersten Ausführungsform beschriebenen, deshalb werden sie bei der Erklärung im Detail weggelassen.
  • In 7 wird eine Situation aufgezeigt, in der das Steuerteil 33a des Senderknotens 3a den CONTEXT_STATE von dem Empfängerknoten 3b empfängt, sofort vor einem Empfangen eines IP-Pakets g von dem Senderdatenendgerät 1. In Ansprechen auf den Empfang überträgt das Steuerteil 33a an den Empfängerknoten 3b ein IP-Paket g, das von dem Senderdatenendgerät 1 empfangen wird, sofort nach einem Empfangen des CONTEXT_STATEs, als ein Ganz-Header-Paket mit keinem Unterschiedswert oder mit Unterschiedswerten. Die praktischen Verfahren sind wie folgt.
  • Zuerst schreibt das Steuerteil 33a die RTP/UDP/IP-Header des IP-Pakets g, das zu dieser Zeit empfangen wird, in das Speicherteil 34a. Und das Steuerteil 33a erhält die Unterschiedswerte zwischen den in den Delta-Feldern der RTP/UDP/IP-Header enthaltenen Werten, und denen der RTP/UDP/IP-Header, die in dem Speicherteil 34a gespeichert sind (die Header des IP-Pakets f). Das Steuerteil 33a bestimmt dann, ob die erhaltenen Unterschiedswerte gleich den in dem Speicherteil 34a gespeicherten sind oder nicht. Wenn die erhaltenen Unterschiedswerte gleich sind zu den gespeicherten, ist es nicht nötig, den Empfängerknoten 3b über die zu dieser Zeit erhaltenen Unterschiedswerte zu benachrichtigen, weil sie schon dem Knoten 3b gegeben wurden. Demgemäss erstellt das Steuerteil 33a einen ganzen Header, in dem die Längen in den RTP/UDP/IP-Headern des IP-Pakets g ersetzt werden durch Information einschließlich der CONTEXT_ID und link_seq. Das Steuerteil 33a sendet dann das Ganz-Header-Paket g einschließlich sowohl dem erstellten ganzen Header und einer RTP-Nutzlast des IP-Pakets g an den Empfängerknoten 3a.
  • Im Gegensatz dazu sendet, wenn die erhaltenen Unterschiedswerte ungleich zu den gespeicherten sind, das Steuerteil 33a ein Ganz-Header-Paket mit den Unterschiedswerten an den Empfängerknoten 3b, so dass Unterschiedswerte, die zu dieser Zeit erhalten werden, dem Knoten 3b mitgeteilt werden. Dieser Betrieb kann im Detail wie folgt erklärt werden. Das Steuerteil 33a ersetzt die Längen, die in die RTP/UDP/IP-Header des IP-Pakets g geschrieben sind, mit Daten, die die CONTEXT_ID, link_seq und irgendeine Flag zum Kennzeichnen der Existenz der neuen Unterschiedswerte der entsprechenden Delta-Felder enthalten (bezugnehmend auf 6C). Das Steuerteil 33a erstellt dann einen ganzen Header einschließlich irgendwelcher neuer Unterschiedswerte (entsprechend zu einem durch die punktierte Linie in 6A gezeigten Abschnitt) und sendet das Ganz-Header-Paket g einschließlich des erstellten ganzen Headers und einer RTP-Nutzlast des IP-Pakets g an den Empfängerknoten 3b. 7 zeigt ein Beispiel, in dem es eine Änderung bei Unterschiedswerten gibt, zwischen den Delta-Feldern von beiden IP-Paketen f und g, und das IP-Paket g wird als ein Ganz-Header-Paket g einschließlich der Unterschiedswerte übertragen.
  • Für den Fall, in dem IP-Pakete h bis n hintereinander von dem Senderdatenendgerät 1 empfangen werden, wird eine Verarbeitung ähnlich zu dem obigen wiederholt. Dies bedeutet, dass entweder Header-komprimierte Pakete oder Ganz-Header-Pakete mit keinem Unterschiedswert oder mit Unterschiedswerten passend von dem Senderknoten 3a an den Empfängerknoten 3b gesendet werden.
  • Wenn das Steuerteil 33b des Empfängerknotens 3b Pakete von den Senderknoten 3a, wie oben beschrieben empfängt, arbeitet das Steuerteil 33b wie folgt.
  • Zuerst extrahiert, beim Empfangen des ersten Ganz-Header-Pakets a, das von dem Senderknoten gesendet wird, das Steuerteil 33b Informationen, wie zum Beispiel die CONTEXT_ID und link_seq von dem ganzen Header des Pakets a und schreibt die Information in das Speicherteil 34b. Zusätzlich ersetzt das Steuerteil 33b diese Stücke an Information in dem ganzen Header mit Längen, die von den unteren Schichten erhalten werden, und dekomprimiert die RTP/UDP/IP-Header des Pakets a. Das Steuerteil 33b schreibt dann die RTP/UDP/IP-Header in das Speicherteil 34b entsprechend der vorher gespeicherten CONTEXT_ID und link_seq und sendet ein IP-Paket a mit den RTP/UDP/IP-Headern an das Empfängerdatenendgerät 2.
  • Dann schreibt, beim Empfangen des Header-komprimierten Pakets b von dem Empfängerknoten 3a, das Steuerteil 33b die Unterschiedswerte, die in dem Header-komprimierten Paket b enthalten sind, in das Speicherteil 34b. Das Steuerteil 33b sucht dann die gleiche CONTEXT_ID, wie die, die in einem komprimierten Header des Pakets b enthalten ist, von dem Speicherteil 34b und liest RTP/UDP/IP-Header (in diesem Fall die RTP/UDP/IP-Header des Pakets a, die der gesuchten CONTEXT_ID entsprechen. Das Steuerteil 33b erstellt dann RTP/UDP/IP-Header und setzt sie in den Delta-Feldern der gelesenen RTP/UDP/IP-Header, wobei die so erstellten RTP/UDP/IP-Header die Delta-Felder enthalten, zu denen die zu dieser Zeit erhaltenen Unterschiedswerte hinzugefügt werden, und die statischen Felder der RTP/UDP/IP-Header des IP-Pakets a. Dann aktualisiert das Steuerteil 33b die RTP/UDP/IP-Header des IP-Pakets a, das schon in dem Speicherteil 34b gespeichert ist, in den zu dieser Zeit neu erhaltenen RTP/UDP/IP-Headern und sendet ein IP-Paket b mit den aktualisierten RTP/UDP/IP-Headern an das Empfängerdatenendgerät 2.
  • Der in 7 gezeigte Fall ist beispielhaft für eine Situation, wo ein Header-komprimiertes Paket c, das von dem Senderknoten 3a geliefert wird, aus irgendeinem Grund verloren geht. Daher detektiert das Steuerteil 33b des Empfängerknotens 3b den Verlust des Header-komprimierten Pakets c aufgrund der Diskontinuität zwischen der link_seq des Header-komprimierten Pakets d und der des Header-komprimierten Pakets b. Bezugnehmend auf das in den 8A und 8B gezeigte Flussdiagramm, wird nun ein Betrieb beschrieben, der durch das Steuerteil 33b in Ansprechen auf die Detektion des Paketverlusts ausgeführt wird.
  • Das Steuerteil 33b setzt zuerst [0] in einem Register n (Schritt S21) und bestimmt, ob das nach dem Verlust empfangene letzte Paket (das bedeutet, das nächste Paket zu dem verlorenen Paket) ein Header-komprimiertes Paket ist oder nicht (Schritt S22). In dem in 7 gezeigten Fall, ist ein soft nach dem Paketverlust empfangenes Paket ein Header-komprimiertes Paket d, somit ist die Bestimmung "Ja". Das Steuerteil 33b dekomprimiert dann die statischen Felder, Längenwerte, UDP-Prüfsumme und Markierungs-Bit (M-Bit) dieses komprimierten-Pakets d und speichert sowohl die dekomprimierte Information als auch eine RTP-Nutzlast des Header-komprimierten Pakets d, das zu dieser Zeit empfangen wird, in dem Speicherteil 34b, als Daten-IP (n) (Schritt S23). In anderen Worten, werden Felder, mit Ausnahme der Delta-Felder, in dem IP-Paket d in dem Speicherteil 34b als Daten-IP (0) gespeichert. Diese Dekomprimierung kann auf ähnliche Art und Weise ausgeführt werden, wie in der ersten Ausführungsform.
  • Das Steuerteil 33b speichert dann die momentanen Unterschiedswerte in den Unterschiedkonstantfeldern, das sind, ein Unterschiedswert von ID des IP-Headers, ein Unterschiedswert der Sequenznummer des RTP-Headers und ein Unterschiedswert des Zeitstempels des RTP-Headers, in dem Speicherteil 34b, als ΔIP_ID(n), ΔRTP_SN(n) bzw. ΔRTP_TS(n), (hier im folgenden verallgemeinert als "Δ(n)") (Schritt S24). Falls das zu dieser Zeit empfangene Header-komprimierte Paket neue Unterschiedswerte aufweist, stellen diese neuen die momentanen Unterschiedswerte bereit, während, falls das zu dieser Zeit empfangene Header-komprimierte Paket keine Unterschiedswerte aufweist, die Unterschiedswerte, die zu dieser Zeit in dem Speicherteil 34b gespeichert werden, die momentanen Unterschiedswerte bereitstellen.
  • Beim Empfang des nächsten Pakets (Schritt S25), erhöht das Steuerteil 33b den Wert des Registers n um [1] (Schritt S26). Die vorhergehenden Verfahren der Schritte S22 bis S26 werden ausgeführt, wenn die Header-komprimierten Pakete e und f empfangen werden. Als Ergebnis werden, bezüglich der Header-komprimierten Pakete d bis f, Informationsstücke, die in 9 gezeigt sind (das sind IP(n) und Δ(n)) in dem Speicherteil 34b gespeichert.
  • Andererseits wird, beim Empfangen eines Ganz-Header-Pakets bei Schritt S25, die Bestimmung in dem folgenden Schritt S22 "Nein", womit er gezwungen wird, zu Schritt S27 zu gehen. Das Steuerteil 33b erstellt nämlich die RTP/UDP/IP-Header durch Ersetzen der CONTEXT_ID, link_seq und anderen, die in dem ganzen Header des empfangenen Ganz-Header-Pakets g enthalten sind mit Längen, und erstellt ein IP-Paket, das aus den erstellten RTP/UDP/IP-Headern und einer RTP-Nutzlast des zu dieser Zeit empfangenen Ganz-Header-Pakets besteht. Das erhaltene IP-Paket wird dann in dem Speicherteil 34b als IP(3) gespeichert (Schritt S27). Wie in 9 gezeigt, enthalten die RTP/UDP/IP-Header des IP-Pakets (das ist IP(3)), erhalten von dem Ganz-Header-Paket, Werte in den Delta-Feldern (das sind die ID, Sequenznummer und Zeitstempel).
  • Das Steuerteil 33b speichert dann einen Unterschiedswert in jedem Delta-Feld zwischen dem Ganz-Header-Paket und dem Header-komprimierten Paket, das vor dem Ganz-Header-Paket empfangen wird, in dem Speicherteil 34b als Δ(n). In dem Beispiel von 7 kann dieses Speichern wie folgt erklärt werden. Das Steuerteil 33b bestimmt, ob das Ganz-Header-Paket g, das zu dieser Zeit empfangen wird, neue Unterschiedswerte enthält oder nicht (Schritt S28). Diese neuen Unterschiedswerte sind durch die punktierte Linie in 6A dargestellt. Falls mindestens eines der Delta-Felder einen neuen Unterschiedswert enthält, werden der neue Unterschiedswert für das entsprechende Delta-Feld und die Unterschiedswerte, die schon in dem Speicherteil 34b für die anderen Delta-Felder gespeichert sind, in dem Speicherteil 34b als Δ(3) gespeichert (Schritt S29). Im Gegensatz dazu werden, falls das Ganz-Header-Paket g nicht einen neuen Unterschiedswert enthält, die Unterschiedswerte, die schon in dem Speicherteil 34b gespeichert sind, wieder in dem Speicherteil 34b als Δ(3) gespeichert (Schritt S30).
  • Gemäß der obigen Operationen werden die Information bezüglich der Pakete d bis g in dem Speicherteil 34b abgebildet, wie es in 9 gezeigt ist. In diesem Stadium enthält das IP-Paket g, das als IP(3) abgebildet wird, die Delta-Felder, aber die IP-Pakete d bis f, die als IP(0) bis IP(2) abgebildet werden, enthalten nicht solche Delta-Felder. Daher werden die Verfahren zum Wiederbeschaffen solcher Delta-Felder dann auf die folgende Weise ausgeführt.
  • Zuerst verringert das Steuerteil 33b einen Wert des Registers n, um "1" (Schritt 32). Das Steuerteil 33b subtrahiert dann die Unterschiedswerte, die oben erhalten werden, von den Werten in den Delta-Feldern der RTP/UDP/IP-Header, die von dem Ganz-Header-Paket dekomprimiert werden, wobei die Delta-Felder des Header-komprimierten Pakets, das sofort vor dem Ganz-Header-Paket empfangen wird, dekomprimiert werden (Schritt S33). In dem Beispiel von 7 wird der Unterschiedswert in jedem Delta-Feld, abgebildet als Δ(3), von jedem Wert in jedem Delta-Feld enthalten in dem IP(3), gespeichert in den Inhalten des Ganz-Header-Pakets g, subtrahiert, wobei die Delta-Felder des Header-komprimierten Pakets f dekomprimiert werden. Praktisch werden, beim Aufnehmen der Werte der ID, der Sequenznummer und Zeitstempel, die jeweils in der IP(3) enthalten sind, als IP(3).IP_ID, IP(3).RTP_SN bzw. IP(3).RTP_TS, Werte IP(2).IP_ID, IP(2).RTP_SN und IP(2).RTP_TS der Delta-Felder des Header-komprimierten Pakets f erhalten durch Berechnen der folgenden Gleichungen (bezugnehmend auf 9. IP(2).IP_ID = IP(3).IP_ID – ΔIP_ID(3) IP(2).RTP_SN = IP(3).RTP_SN – ΔRTP_SN(3) IP(2).RTP_TS = IP(3).RTP_TS – ΔRTP_TS(3)
  • Wenn die Werte der Delta-Felder dekomprimiert wurden, kombiniert das Steuerteil 33b die dekomprimierten Delta-Felder und die anderen in dem Speicher als IP(2) gespeicherten Felder, womit ein IP-Paket f erstellt wird. Das Steuerteil 33b bestimmt dann, ob die Dekomprimierung korrekt durchgeführt wurde oder nicht, unter Verwendung der UDP-Prüfsumme, die in dem IP-Paket f enthalten ist (Schritt S34). Wenn bestimmt wird, dass die korrekte Bestimmung durchgeführt wurde, speichert das Steuerteil 33b das IP-Paket f in dem Speicherteil 34b (Schritt S35). Ferner wiederholt das Steuerteil 33b die ähnlichen in Schritten S32 bis S35 gezeigten Verfahren, so dass die Delta-Felder der übrigbleibenden Header-komprimierten Pakete e und d dekomprimiert werden.
  • Wenn der Wert des Registers n [0] null wird bei Schritt S31, bedeutet dies, dass die Dekomprimierung aller der Header-komprimierten Pakete, die gespeichert wurden, beendet wurde. In diesem Fall werden die IP-Pakete (mit IP-Paketen, die von dem Ganz-Header-Paket erhalten werden), die in dem Speicherteil 34b bis jetzt gespeichert wurden, sequenziell an das Empfängerdatenendgerät in der Reihenfolge der Sequenznummer in dem RTP-Header gesendet.
  • Im Gegensatz dazu, falls bestimmt wird, dass die Dekomprimierung nicht korrekt durchgeführt wurde, wird angenommen, dass die Header-komprimierten Pakete, die vor dem inkorrekt dekomprimierten Paket empfangen werden, auch nicht korrekt dekomprimiert werden. Demgemäss werden alle übrigbleibenden, zu dekomprimierenden IP-Pakete fallengelassen (Schritt S36), während nur IP-Pakete, die korrekt dekomprimiert wurden, an das Empfängerdatenendgerät 2 gesendet werden (Schritt S37).
  • In der vorliegenden Ausführungsform ist der Betrieb wie oben.
  • Gemäß der vorliegenden Ausführungsform werden, für Änderungen in den Unterschiedswerten, die Unterschiedswerte an Ganz-Header-Pakete, sowie Header-komprimierte Pakete hinzugefügt, und die Pakete mit den Unterschiedswerten werden gesendet. Deshalb ist, sogar wenn Unterschiedswerte verändert werden, zwischen einem als ein Ganz-Header-Paket zu übertragenden IP-Paket und seinem vorigen IP-Paket (Header-komprimiertes Paket), der Empfängerknoten 3b in der Lage, die Inhalte des Header-komprimierten Pakets zu dekomprimieren.
  • C: Dritte Ausführungsform
  • In jeder der vorhergehenden Ausführungsformen ermöglicht die sequenzielle Subtraktion bzw. Subtrahierung der Unterschiedswerte betreffend ein Header-komprimiertes Paket, das nach einem Paketverlust empfangen wird, von den Werten in den Delta-Feldern des Ganz-Header-Pakets, das am frühestens nach dem Paketverlust empfangen wird, dass die gespeicherten Header-komprimierten Pakete in IP-Pakete dekomprimiert werden. Jedoch ist die Technik des Komprimierens von Header-komprimierten Paketen basierend auf einem Ganz-Header-Paket, das nach dem Paketverlust empfangen wird, nicht begrenzt auf das in den vorhergehenden Ausführungsformen beschriebene. Eine dritte Ausführungsform, die hier beschrieben wird, bezieht sich auf ein Beispiel solcher Techniken. In der folgenden Erklärung werden jetzt nur die Konfigurierungen beschrieben, die verschieden sind von denen in den vorhergehenden Ausführungsformen.
  • In den vorhergehenden Ausführungsformen arbeitet, in Fällen, wo die Unterschiedswerte in den Delta-Feldern eines IP-Pakets geändert werden, der Senderknoten 3a, um die neuen Unterschiedswerte in den komprimierten-Header eines Header-komprimierts einzufügen. Im Gegensatz dazu werden, in der vorliegenden Ausführungsform, anstatt der Unterschiedswerte, einige niedrigere Bits (hier im folgenden als "LSBs (niederwertigste Bits)") von jedem Delta-Feld in den komprimierten-Header eines Header-komprimierten Pakets eingefügt.
  • Genauer gesagt, berechnet, beim Empfangen eines gewissen IP-Pakets, das als ein Header-komprimiertes Paket gesendet werden sollte, von dem Senderdatenendgerät 1, der Senderknoten 3a Unterschiedswerte zwischen den Werten in den Delta-Feldern des gewissen IP-Pakets und denen des IP-Pakets (das gerade vor dem gewissen IP-Paket empfangen wurde), das in dem Speicherteil 34a gespeichert ist. Und der Knoten 3a vergleicht die berechneten Unterschiedswerte mit den Unterschiedswerten, die in dem Speicher gespeichert sind. Falls irgendeiner der Unterschiedswerte der Delta-Felder verändert wird, extrahiert das Steuerteil 33a des Senderknotens 3a die LSBs von dem entsprechenden Delta-Feld des zu dieser Zeit empfangenen IP-Pakets. Und das Steuerteil 33a erstellt einen komprimierten-Header mit sowohl den LSBs und der entsprechenden Flag, in der "1" gesetzt wird, um die Existents der LSBs zu kennzeichnen. Eine der Flags S, T und I in 11B kann für diesen Zweck verwendet werden. Das Steuerteil 33a sendet ein Header-komprimiertes Paket mit diesem komprimierten-Header an den Empfängerknoten 3b. Andererseits werden, falls der vorhergehende Vergleich zeigt, dass die Unterschiedswerte zwischen den berechneten Unterschiedswerten und den Unterschiedswerten, die in dem Speicher gespeichert sind, miteinander übereinstimmen, die LSBs nicht in das Header-komprimierte Paket eingefügt, das von dem zu dieser Zeit empfangenen IP-Paket dekomprimiert wird.
  • Die Anzahl von Bits, die als die LSBs übertragen werden, hängt von den Eigenschaften der zu übertragenden Daten und Delta-Feldern (der ID, Sequenznummer und Zeitstempel und ähnlichem) ab, und wird gemäß dieser Bedingungen ausgewählt. Beispielsweise werden die oberen Bits, von denen nicht erwartet wird, dass sie sich ändern, ausgeschlossen und die übrigbleibenden niedrigeren Bits werden übertragen, um die Änderung des entsprechenden Delta-Felds zu kennzeichnen.
  • Bezugnehmend auf 10, wird nun ein Betrieb der vorliegenden Ausführungsform erklärt. Wie in der ersten Ausführungsform beschrieben, enthalten die Delta-Felder die ID des IP-Headers und die Sequenznummer und Zeitstempel des RTP-Headers, aber sie sind als ein "Delta-Feld" aufgrund der Vereinfachung verallgemeinert.
  • Zuerst empfängt der Senderknoten 3a IP-Pakete von dem Senderdatenendgerät 1. Gleichzeitig mit dem Empfang sendet der Knoten 3a das erste empfangene IP-Paket a als das Ganz-Header-Paket an den Empfängerknoten 3b und sendet dann die Pakete b bis f als Header-komprimierte Pakete. In 10 wird angenommen, dass der CONTEXT_STATE von dem Empfängerknoten 3b genau vor einem Empfangen eines IP-Pakets g empfangen wird. Daher sendet der Senderknoten 3a das IP-Paket g als ein Ganz-Header-Paket an den Empfängerknoten 3b. Wie oben dargelegt, enthalten, unter den komprimierten Headern der Header-komprimierten Pakete, nur komprimierte Header, von denen die Delta-Felder hinsichtlich Werten verändert werden, die LSBs. In 10 ist der Fall basierend auf der Bedingung gezeigt, in der die Header-komprimierte Pakete b, d und f die LSBb, LSBd bzw. LSBf enthalten, während das Header-komprimierte Paket e nicht solche LSBs enthält.
  • Andererseits dekomprimiert das Steuerteil 33b des Empfängerknotens 3b ein IP-Paket a, basierend auf dem Ganz-Header-Paket a, das zuerst von dem Senderknoten 3a empfangen wird. Das Steuerteil 33b speichert das dekomprimierte IP-Paket in dem Speicherteil 34b und sendet dann das IP-Paket a and das Empfängerdatenendgerät 2. Das Steuerteil 33b arbeitet, um das als nächstes empfangene Header-komprimierte Paket b unter Verwendung des IP-Pakets a zu dekomprimieren. Genauer gesagt, wie in 10 gezeigt, werden die Delta-Felder des IP-Pakets a, gespeichert in dem Speicherteil 34b, ausgelesen. Und die LSBa der Delta-Felder werden durch die LSBb ersetzt, die in dem Header-komprimierten Paket b enthalten sind, so dass die Delta-Feld des Header-komprimierten Pakets b dekomprimiert werden (bezugnehmend auf "OP1", gezeigt in 10). Das Steuerteil 33b erstellt ein IP-Paket b mit diesen Delta-Feldern. Das Steuerteil 33b speichert das erstellte IP-Paket b in dem Speicherteil 34b und sendet es an das Empfängerdatenendgerät 2.
  • In 10 ist der Fall unter der Annahme dargestellt, dass das Header-komprimierte Paket c, das von dem Senderknoten 3a gesendet wird, aus irgendeinem Grund verloren geht, bevor es durch den Empfängerknoten 3b empfangen wird. Das Steuerteil 33b des Empfängerknotens 3b detektiert den Verlust des Header-komprimierten Pakets c durch Empfangen des Header-komprimierten Pakets d, als nächstes nach dem Header-komprimierten Paket b. In Ansprechen auf diese Detektion, wird das Steuerteil 33b den CONTEXT_STATE an den Senderknoten 3a senden.
  • Nach dem Verlust des Pakets c speichert das Steuerteil 33b der Reihe nach die Header-komprimierten Pakete d bis f in dem Speicherteil 34b, bis das nächste Ganz-Header-Paket g empfangen wird. Praktisch wird, wenn ein Header-komprimiertes Paket mit den LSBs empfangen wird, das Header-komprimierte Paket in dem Speicherteil 34b mit den LSBs gespeichert. Wenn ein Header-komprimiertes Paket mit keinen LSBs empfangen wird, wird das Header-komprimierte Paket, das als letztes vor einem Empfangen des Header-komprimierten Pakets mit keinen LSBs empfangen wurde, und die LSBs enthält, ausgewählt, und die LSBs werden gespeichert in dem Speicherteil 34b mit dem Header-komprimierten Paket mit keinen LSBs. Beispielsweise hat das in Header-komprimierte Paket e in dem in 10 gezeigten Fall keine LSBs. Die LSBd des Header-komprimierten Pakets d, das genau vor dem Paket e empfangen wurde und die LSBs enthält, wird als das LSBe gehandhabt und in dem Speicherteil 34b zusammen mit dem Header-komprimierten Paket e gespeichert.
  • Dann führt, beim Empfangen des Ganz-Header-Pakets g, das von dem Senderknoten 3a gesendet wird, in Ansprechen auf den CONTEXT_STATE, der an den Senderknoten 3a vorher übertragen wurde, das Steuerteil 33b die Verfahren zum Dekomprimieren der Header-komprimierten Pakete d bis f aus, die in dem Speicherteil 34b gespeichert wurden, basierend auf den Inhalten des Ganz-Header-Pakets g. Hier im folgenden wird nun das Dekomprimierungsverfahren beschrieben.
  • Zuerst dekomprimiert das Steuerteil 33b das Ganz-Header-Paket g in ein IP-Paket g und speichert das IP-Paket in dem Speicherteil 34b. In 10 werden die LSBs und die anderen Bits durch "LSBg" bzw. "G" in dem Delta-Feld des IP-Pakets g vermerkt.
  • Das Steuerteil 33b liest dann die Delta-Felder des IP-Pakets g von dem Speicherteil 34b aus und dekomprimiert die Delta-Felder des Header-komprimierten Pakets f. Die LSBg der Delta-Felder des Pakets g werden nämlich durch die LSBf des entsprechenden Delta-Felds des Header-komprimierten Pakets f ersetzt, das in dem Speicherteil 34b gespeichert ist, womit die Delta-Felder des Pakets f dekomprimiert werden (bezugnehmend auf "OP2" in 10). Das Steuerteil 33b erstellt ein IP-Paket f mit sowohl den dekomprimierten Delta-Feldern, als auch den statischen Feldern des IP-Pakets g. Das Steuerteil 33b bestimmt dann, dass die Komprimierung korrekt ausgeführt wurde oder nicht, unter Verwendung der Prüfsumme, die in dem IP-Paket f enthalten ist.
  • Wenn das IP-Paket f korrekt dekomprimiert wurde, wird dieses IP-Paket f verwendet zum Dekomprimieren des Header-komprimierten Pakets e. Genauer gesagt, ersetzt das Steuerteil 33b die LSBf der Delta-Felder des IP-Pakets f mit den LSBe (identisch zu LSBd in Inhalten) des Header-komprimierten Pakets e, das in dem Speicherteil 34b gespeichert ist, so dass die Delta-Felder des Header-komprimierten Pakets e dekomprimiert werden (bezugnehmend auf "OP3" in 10). Im Gegensatz dazu wird, wenn das IP-Paket f korrekt dekomprimiert wurde, das Header-komprimierte Paket e dekomprimiert, unter Verwendung des IP-Pakets g, das als ein Ganz-Header-Paket empfangen und dekomprimiert wird. Dies bedeutet, dass das Steuerteil 33b die untere Bit-Folge LSBg der Delta-Felder des IP-Pakets g mit dem LSBe entsprechend dem Header-komprimierten Paket e ersetzt, das in dem Speicherteil 34b gespeichert ist, so dass die Delta-Felder des Header-komprimierten Pakets e dekomprimiert werden.
  • Nach Beendigung der Delta-Felder des Header-komprimierten Pakets e, basierend auf den Inhalten des IP-Pakets f oder g, schreitet das Steuerteil 33b zu dem Erstellen eines IP-Pakets e. Praktisch kombiniert das Steuerteil 33b die dekomprimierten Delta-Felder mit den statischen Feldern des IP-Pakets f oder g, wobei das IP-Paket e erstellt wird. Und das Steuerteil 33b bestimmt, ob die Dekomprimierung korrekt ausgeführt wurde oder nicht, unter Verwendung der Prüfsumme, die in dem Header-komprimierten Paket e enthalten ist.
  • Das Steuerteil 33b wird weiter die gleichen Verfahren bei allen der Header-komprimierten Pakete ausführen, die während dem Intervall zwischen einem Detektieren des Verlust des Pakets c und Empfangen des Ganz-Header-Pakets g empfangen werden. Bei Beendigung des Verfahrens bei allen der Header-komprimierten Pakete, sendet das Steuerteil 33b alle korrekt dekomprimierten IP-Pakete and das Empfängerdatenendgerät 2, der Reihe nach, in der Reihenfolge der Sequenznummer, die in jedem RTP-Header enthalten ist.
  • Jedoch werden die IP-Pakete fallengelassen, die nicht korrekt dekomprimiert wurden.
  • Deshalb gibt es, wie bei den vorhergehenden Ausführungsformen, den zu den vorhergehenden Ausführungsformen identischen Vorteil, weil Header-komprimierte Pakete, die nach einem Paketverlust empfangen werden, nacheinanderfolgend dekomprimiert werden, basierend auf einem Ganz-Header-Paket, das am frühesten nach dem Paketverlust empfangen wird. Ferner kann in der vorliegenden Ausführungsform ein gewisses Header-komprimiertes Paket dekomprimiert werden, unter Verwendung von entweder einem Ganz-Header-Paket, das am frühesten nach einem Paketverlust empfangen wird, oder einem IP-Paket, das sofort nach dem Header-komprimierten Paket dekomprimiert wird. Beispielsweise kann in 10 entweder das IP-Paket g, das durch Dekomprimieren des Ganz-Header-Pakets g gebildet wird, oder das IP-Paket e, das durch Dekomprimieren des Header-komprimierten Pakets e gebildet wird, zum Dekomprimieren des Header-komprimierten Pakets d verwendet werden. Als Ergebnis kann, sogar wenn das Header-komprimierte Paket e, das gerade vor dem zu dekomprimierenden Header-komprimierten Paket dekomprimiert werden sollte, nicht in der Reihenfolge dekomprimiert wird, das Header-komprimierte Paket d dekomprimiert werden, basierend auf den Inhalten des IP-Pakets g. Die vorliegende Ausführungsform der Erfindung ist deshalb in der Lage, die Effizienz in der Dekomprimierung zu verbessern, selbst verglichen zu den vorhergehenden Ausführungsformen.
  • Wie in den vorhergehenden Ausführungsformen gesehen, bezieht sich die vorliegende Erfindung auf das Verfahren mit der Einrichtung zum Wiederherstellen der Inhalte eines Header-komprimierten Pakets, das nach einem Verlieren eines Pakets empfangen und gehalten wird, basierend auf den Inhalten eines Ganz-Header-Pakets, das am frühesten nach dem Paketverlust empfangen wird. Dies bedeutet, dass eine Technik eines Verwendens eines Ganz-Header-Pakets, das am frühesten nach einem Paketverlust empfangen wird, zum Dekomprimieren von Header-komprimierten Paketen, die nach dem Paketverlust empfangen werden, nicht auf Verfahren beschränkt ist, die in den vorhergehenden Ausführungsformen beschrieben werden, aber eine Vielzahl von anderen Arten auch verwendet werden können.
  • D: Vierte Ausführungsform
  • Die vorhergehenden Ausführungsformen stellen nicht nur eine Funktion eines Erlaubens der Weiterübertragungsvorrichtung bei dem Senderknoten 3a bereit, um ein IP-Paket in ein Header-komprimiertes Paket oder ein Ganz-Header-Paket (hier im folgenden wird solch eine Funktion "Komprimierungsfunktion" genannt) zu konvertieren bzw. umzuwandeln, aber auch eine Funktion der Weiterübertragungsvorrichtung an den Empfängerknoten 3b, um zu erlauben, dass das Header-komprimierte Paket oder das Ganz-Header-Paket in ein IP-Paket (hier im folgenden wird solch eine Funktion "Dekomprimierungsfunktion" genannt) konvertiert wird. Im Gegensatz dazu stellt die vierte Ausführungsform eine Konfigurierung bereit, in der sowohl das Senderdatenendgerät 1, als auch der Empfängerknoten 3b die Komprimierungsfunktion aufweisen, während sowohl der Senderknoten 3a und das Empfängerdatenendgerät 2 die Dekomprimierungsfunktion aufweisen.
  • Praktisch stellt das Senderdatenendgerät 1 sequenziell zu übertragende IP-Pakete. Durch Übertragen der IP-Pakete, sendet das Endgerät 1 an den Senderknoten 3a, als Ganz-Header-Pakete, sowohl das erste IP-Paket als auch ein IP-Paket, das sofort nach dem Empfangen des CONTEXT_STATEs von dem Empfängerknoten 3a übertragen werden sollte.
  • Hinsichtlich der übrigbleibenden IP-Pakete sendet das Endgerät 1 diese als Header-komprimierten Pakete an den Senderknoten 3a. Die Weiterübertragungsvorrichtung an dem Senderknoten 3a arbeitet auf eine ähnliche Weise, wie die Weiterübertragungsvorrichtung an dem Empfängerknoten 3b, die in der ersten Ausführungsform erklärt ist. Dieser Betrieb führt dazu, dass die Ganz-Header-Pakete und Header-komprimierten Pakete, die von dem Senderdatenendgerät 1 gesendet werden, in IP-Pakete dekomprimiert werden, und so an den Empfängerknoten 3b gesendet werden. In Ansprechen auf dieses Senden, empfängt der Empfängerknoten 3b diese IP-Pakete und konvertiert diese in Ganz-Header-Pakete oder Header-komprimierte Pakete, vor einem Übertragen von diesen an das Empfängerdatenendgerät 2.
  • Das Empfängerdatenendgerät empfängt die Ganz-Header-Pakete oder Header-komprimierten Pakete von dem Empfängerknoten 3b und konvertiert diese in IP-Pakete. Beim Detektieren eines Paketverlusts, der zwischen dem Empfängerknoten 3b und dem Empfängerdatenendgerät 2 auftritt, speichert das Empfängerendgerät 2 in seinem internen Speicher Header-komprimierte Pakete, die während des Intervalls zwischen dem Paketverlust und des frühesten Empfangs eines Ganz-Header-Pakets nach dem Paketverlust empfangen werden. Dann dekomprimiert, beim Empfangen solch eines Ganz-Header-Pakets, das Endgerät 2 die komprimierten-Header der Header-komprimierten Pakete, die in dem Speicher gespeichert werden, unter Verwendung von Inhalten des ganzen Headers des empfangenen Ganz-Header-Pakets. Dann arbeitet das Empfängerdatenendgerät 2, um eine Verarbeitung mit einem Anzeigen von Bildern und Ausgeben von Ton auszuführen, basierend auf Daten, die durch die empfangenen IP-Pakete bereitgestellt werden. Dieser Konfigurierung ist es deshalb möglich, die gleichen Vorteile aufzuweisen, wie den Konfigurierungen, die in den vorhergehenden Ausführungsformen beschrieben werden.
  • Wie beschrieben, ist das Empfängerdatenendgerät in der Lage, die Funktion zum Dekomprimieren von Inhalten der komprimierten-Header der Header-komprimierten Pakete aufzuweisen, die bis zu einem Empfang eines Ganz-Header-Pakets am frühesten nach einem Paketverlust empfangen werden, unter Verwendung von Inhalten des ganzen Headers, der in dem Ganz-Header-Paket enthalten ist. Dies bedeutet, dass das Paketübertragungsverfahren gemäß der vorliegenden Erfindung auf irgendeine Vorrichtung zum Übertragen und Empfangen von Paketen an einem Netzwerk angewandt werden kann. Dies heißt, dass die Konzepte des "Senders" und "Empfängers", die in den Ansprüchen der vorliegenden Erfindung dargelegt sind, Datenendgeräte enthalten, von denen Pakete gesendet werden, sowie Datenendgeräte, an die Pakete gesendet werden, wie auch Paketweiterübertragungsgeräte, die Paketumwandlungen zwischen Datenendgeräten austauschen.
  • E: Variationen
  • (Variation 1)
  • In den vorhergehenden Ausführungsformen wurde der Senderknoten 3a derart konfiguriert, dass ein IP-Paket, das sofort nach dem Empfangen eines CONTEXT_STATE von dem Empfängerknoten 3b gesendet werden sollte, an den Empfängerknoten 3b als ein Ganz-Header-Paket gesendet wird. Jedoch sind die Bedingungen für ein Senden solcher IP-Pakete nicht auf die oben erwähnte Bedingung begrenzt. IP-Pakete, die von dem Senderknoten 3a als Ganz-Header-Pakete gesendet werden, können wie folgt verschiedene Formen annehmen.
  • a. Erste Form
  • Wenn die statischen Felder der RTP/UDP/IP-Header eines zu übertragenden IP-Pakets nicht in Werten verändert werden, ist es für den Senderknoten 3a möglich, wie in den vorhergehenden Ausführungsformen erwähnt, Ganz-Header-Pakete nur für sowohl ein IP-Paket, das zuerst übertragen werden sollte, als auch ein IP-Paket, das sofort nach Empfangen des CONTEXT_STATE von dem Empfängerknoten übertragen werden sollte, zu übertragen. Jedoch wird verlangt, falls die statischen Felder in den Werten verändert werden, ein Paket, bei dem statische Felder in den Inhalten verändert werden, als ein Ganz-Header-Paket zu senden, wie auch in dem herkömmlichen Verfahren A erwähnt, zusätzlich zu diesen Paketen. Um dieses zusätzliche Senden zu realisieren, wird das Steuerteil 33a des Senderknotens 3a konfiguriert zum Senden, als ein Ganz-Header-Paket, eines Pakets, bei dem statische Felder hinsichtlich der Inhalte verändert werden. Alternativ können, anstatt von IP-Paketen, die sofort nach dem der CONTEXT_STATE empfangen wurde, gesendet werden, nur IP-Pakete als Ganz-Header-Pakete gesendet werden, bei denen statische Felder hinsichtlich der Inhalte verändert werden.
  • b: Zweite Ausführungsform
  • Der Senderknoten 3a kann konfiguriert werden zum Auswählen, wie gezeigt in dem Verfahren 1 in der Erläuterung des Stands der Technik, bestimmter Pakete von Paketen, die der Reihe nach von dem Senderdatenendgerät 1 übertragen werden, bei jeder vorbestimmten Anzahl von Teilen, und zum Senden dieser als Ganz-Header-Pakete an den Empfängerknoten 3b.
  • Die obige erste und zweite Form ist daher ähnlich zu den vorhergehenden Ausführungsformen, dass der Empfängerknoten 3b Pakete aufbewahren kann, die empfangen werden, bis ein Ganz-Header-Paket nach dem Verlust eines Pakets von dem Senderknoten 3a empfangen wird, und dass die aufbewahrten Pakete hinsichtlich Inhalten des Ganz-Header-Pakets dekomprimiert werden können.
  • (Variation 2)
  • Das Ganz-Header-Paket und das Header-komprimierten Paket sind nicht notwendig begrenzt auf die oben beschriebenen Pakete. Pakete irgendeiner Konfigurierung sind nämlich anwendbar auf das "Ganz-Header-Paket" der vorliegenden Erfindung, falls sie eine Funktion für ein Synchronisieren des Inhalts des Komprimierungsbetriebs in dem Senderknoten mit dem Inhalt des Dekomprimierungsbetriebs in dem Empfängerknoten aufweisen. Genauer gesagt, wird es nicht immer verlangt, dass ein Ganz-Header-Paket in der Lage ist, ein nicht-komprimiertes Paket basierend auf den Inhalten des Ganz-Header-Pakets selbst wiederherzustellen. Überdies hinaus wird von einem Ganz-Header-Paket nicht immer verlangt, dass es basierend auf einem IP-Header erstellt werden kann. Eher ist es für ein Ganz-Header-Paket genug, die obige Funktion aufzuweisen. Andererseits ist jede Konfigurierung für einen komprimierten Header verfügbar, falls ein Header-komprimiertes Paket komprimiert werden kann, basierend auf den Inhalten von anderen Paketen, wie zum Beispiel IP-Paketen, die dekomprimierte Ganz-Header-Pakete oder Header-komprimierte Pakete aufweisen.
  • (Variation 3)
  • Die Prüfsumme, die an einem komprimierten-Header-Paket angebracht ist, und zum Überprüfen der Richtigkeit des komprimierten-Headers verwendet wird, ist nicht auf die UDP-Prüfsumme begrenzt. Das bedeutet, dass irgendeine Prüfsumme, die von den Originalpaketen oder von den RTP/UDP/IP-Headern berechnet wird, und an ein komprimiertes-Header-Paket angebracht wird, zum Prüfen der Richtigkeit des dekomprimierten-Header verwendet werden kann.
  • (Variation 4)
  • Die vorliegende Erfindung kann so verkörpert werden, dass das Programm, das den Paketempfang ausführt, der durch die Weiterübertragungsvorrichtung an dem Empfängerknoten ausgeführt wird, wie in den Ausführungsformen beschrieben, in einem computerlesbaren Speichermedium aufgezeichnet werden kann, und das Medium an Benutzer geliefert werden kann, oder das Programm Benutzern durch elektronische Kommunikationsschaltungen bereitgestellt werden kann.

Claims (11)

  1. Ein Paketübertragungsverfahren, umfassend die Schritte: ein Paketversenden durch eine Kommunikationsvorrichtung bereitgestellt bei einem Senderknoten (3a) in einem Netzwerk, wobei das Paketversenden eine Operation enthält zum Konvertieren einer Vielzahl von zu sendenden nicht-komprimierten Paketen in entweder ein Ganz-Header-Paket bzw. Voll-Kopfpaket mit einem ganzen Header oder einem Header-komprimierten Paket mit einem komprimierten Header und Senden eines konvertierten Pakets zu einem Empfängerknoten (3b) im Netzwerk; und ein Paketempfang durch eine Kommunikationsvorrichtung bereitgestellt an dem Empfängerknoten, wobei der Paketempfang eine Operation enthält zum Empfangen (S2, S6) des Ganz-Header-Pakets oder des Header-komprimierten Pakets, das von dem Sender gesendet wurde und eine Umwandlung zum Konvertieren eines empfangenen Pakets zu einem dekomprimierten Paket, wobei die Umwandlung enthält: eine Operation zum Beibehalten (S5), im Fall, dass ein Ganz-Header-Paket oder ein Header-komprimiertes Paket verloren geht, während es von dem Senderknoten an den Empfängerknoten gesendet wird, von mindestens einem Header-komprimierten Paket, das während eines Intervalls zwischen einem Auftreten eines Paketverlustes und eines Empfangs eines nächsten Ganz-Header-Pakets empfangen wird, gekennzeichnet durch eine Operation zum Dekomprimieren (S4, S8; S4', S8') eines komprimierten Headers des Header-komprimierten Pakets, womit es in einer Reihenfolge umgekehrt zu der Reihenfolge eines Aufbewahrens beibehalten wird, basierend auf einem Inhalt eines ganzen Headers des Ganz-Header-Pakets, das nach dem Paketverlust empfangen wird.
  2. Ein Paketübertragungsverfahren nach Anspruch 1, wobei die Operation zum Dekomprimieren bei dem Paketempfang ferner eine Operation enthält zum Dekomprimieren von Delta-Information (S8; S8') in den beibehaltenen Header-komprimierten Paketen durch Verringern eines Differenzwertes von der Delta-Information, die in dem ganzen Header des Ganz-Header-Pakets enthalten ist, das nach dem Paketverlust empfangen wird, wobei die Delta-Information eine Information ist, die sich durch den Differenzwert zwischen jedem der nicht-komprimierten Pakete entsprechend ändert.
  3. Ein Paketübertragungsverfahren nach Anspruch 1, wobei die Paketübertragung ferner eine Operation enthält zum Hinzufügen, an mindestens einen Teil der ganzen Header eines von dem nicht-komprimierten Paket konvertierten Ganz-Header-Pakets, eines Differenzwertes der Delta-Information zwischen dem nicht-komprimierten Paket und einem anderen nicht-komprimierten Paket, wobei die Delta-Information eine Information ist, die sich durch den Differenzwert zwischen jedem der nicht-komprimierten Pakete entsprechend ändert, sowie die Operation zum Dekomprimieren beim Paketempfang ferner eine Operation enthält zum Dekomprimieren, wenn ein Ganz-Header-Paket mit einem Differenzwert nach dem Paketverlust empfangen wird, der Delta-Information in dem beibehaltenen Header-komprimierten Paket, unter Verwendung des Differenzwertes und der Delta-Information, die in einem ganzen Header des empfangenen Ganz-Header-Pakets enthalten sind.
  4. Ein Paketübertragungsverfahren nach Anspruch 3, wobei, in Fällen, dass ein zu einem nicht-komprimierten Paket entsprechendes Ganz-Header-Paket übertragen wird und eine Delta-Information zwischen dem nicht-komprimierten Paket und einem nicht-komprimierten Paket genau vor dem nicht-komprimierten Paket sich in einem Differenzwert von der Delta-Information anderer nicht-komprimierter Pakete unterscheidet, die Kommunikationsvorrichtung an dem Senderknoten (3a) einen Differenzwert zu dem Ganz-Header-Paket hinzufügt.
  5. Ein Paketübertragungsverfahren nach Anspruch 1, wobei der Paketempfang ferner eine Operation umfasst zum Dekomprimieren von statischer Information (S4; S8') der beibehaltenen Header-komprimierten Pakete, basierend auf statischer Information, die in einem ganzen Header eines Ganz-Header-Pakets enthalten ist, das genau vor oder nach dem Paketverlust empfangen wird, wobei die statische Information eine Information ist, die in nicht-komprimierten Headern von nicht-komprimierten Paketen enthalten ist, und zwischen den nicht-komprimierten Paketen identisch ist.
  6. Ein Paketübertragungsverfahren nach Anspruch 1, wobei jeder nicht-komprimierte Header der nicht-komprimierten Pakete Delta-Information enthält, die sich durch einen Differenzwert zwischen den nicht-komprimierten Paketen ändert, während ein komprimierter Header von mindestens einem Teil der Header-komprimierten Pakete partielle Bits enthält, die Teil von die Delta-Information des nicht-komprimierten Headers darstellenden Bits sind, und der Paketempfang ferner eine Operation umfasst zum Dekomprimieren von Delta-Information der beibehaltenen Header-komprimierten Pakete durch Ersetzen eines Teils der Bits, die Delta-Information darstellen, die in einem ganzen Header eines Ganz-Header-Pakets enthalten ist, das nach dem Paketverlust empfangen wird, wobei partielle Bits in einem vorher erhaltenen Header-komprimierten Paket enthalten sind.
  7. Ein Weiterübertragungsgerät platziert zwischen einer Vielzahl von Datenendgeräten (1, 2) und das Pakete überträgt, die zwischen den Datenendgeräten (1, 2) ausgetauscht werden, umfassend: eine Empfangseinrichtung (31b) zum Empfangen eines Ganz-Header-Pakets mit einem ganzen Header oder eines Header-komprimierten Pakets mit einem komprimierten Header; eine Dekompressionseinrichtung (33b) zum Konvertieren eines empfangenen Pakets in ein dekomprimiertes Paket; eine Beibehaltungseinrichtung (34b) zum Behalten, in den Fällen, dass das Ganz-Header-Paket oder das Header-komprimierte Paket verloren geht bevor es durch die Empfangseinrichtung empfangen ist, von Header-komprimierten Paketen, die während eines Intervalls zwischen einem Verlust des Pakets und einem Empfang eines nächsten Ganz-Header-Pakets nach dem Verlust empfangen werden, dadurch gekennzeichnet, dass die Dekompressionseinrichtung (33b) auch dazu ausgebildet ist, zum Dekomprimieren eines komprimierten Headers jeder der Header-komprimierten Pakete, die von der Beibehaltungseinrichtung (34b) in einer Reihenfolge behalten werden, die umgekehrt zu der Aufbewahrungsreihenfolge ist, basierend auf einem Inhalt eines ganzen Headers eines nach dem Verlust des Paketes empfangenen Ganz-Header-Pakets.
  8. Ein Datenendgerät (2), das in der Lage ist, Pakete über ein Netzwerk mit anderen Datenendgeräten auszutauschen, umfassend: eine Empfangseinrichtung (31b) zum Empfangen eines Ganz-Header-Pakets mit einem ganzen Header oder eines Header-komprimierten Pakets mit einem komprimierten Header; eine Dekompressionseinrichtung (33b) zum Konvertieren eines empfangenen Pakets in ein dekomprimiertes Paket; eine Beibehaltungseinrichtung (34b) zum Behalten, in Fällen, dass das Ganz-Header-Paket oder Header-komprimierte Paket verloren geht bevor es durch die Empfangseinrichtung (31b) empfangen wird, von Header-komprimierten Paketen, die während eines Intervalls zwischen dem Verlust des Pakets und einem Empfang eines nächsten Ganz-Header-Pakets nach dem Verlust empfangen werden, dadurch gekennzeichnet, dass die Dekompressionseinrichtung (33b) auch ausgebildet ist zum Dekomprimieren eines komprimierten Headers jeder der Header-komprimierten Pakete, die von der Beibehaltungseinrichtung (34b) in einer Reihenfolge beibehalten werden, die umgekehrt ist zu der Reihenfolge einer Aufbewahrung, basierend auf einem Inhalt eines ganzen Headers eines Ganz-Header-Pakets, das nach dem Verlust des Paketes empfangen wird.
  9. Ein Paketempfangsverfahren, umfassend die Schritte: Empfangen (S2, S6) eines Ganz-Header-Pakets mit einem ganzen Header oder eines Header-komprimierten Pakets mit einem komprimierten Header, und Konvertieren eines empfangenen Pakets in ein dekomprimiertes Paket; wobei die Umwandlung enthält Beibehalten (S5), in Fällen, dass das Ganz-Header-Paket oder das Header-komprimierte Paket verloren geht bevor es empfangen wird, von Header-komprimierten Paketen, die während einem Intervall zwischen dem Verlust des Pakets und einem Empfang eines nächsten Ganz-Header-Pakets nach dem Verlust empfangen werden, gekennzeichnet durch Dekomprimieren (S4, S8; S4', S8') eines komprimierten Headers jeder der Header-komprimierten Pakete, die in einer Reihenfolge beibehalten werden, die umgekehrt ist zu der Reihenfolge einer Aufbewahrung, basierend auf einem Inhalt eines ganzen Headers eines Ganz-Header-Pakets, das nach dem Verlust des Pakets empfangen wird.
  10. Ein Programm, um auf einem Computer ein Ausführen eines Paketempfangsverfahrens hervorzurufen, umfassend die Schritte: Empfangen (S2, S6) eines Ganz-Header-Pakets mit einem ganzen Header oder eines Header-komprimierten Pakets mit einem komprimierten Header und Konvertieren eines empfangenen Pakets in ein dekomprimiertes Paket; wobei die Umwandlung enthält Beibehalten (S5), in Fällen, dass das Ganz-Header-Paket oder das Header-komprimierte Paket verloren geht bevor es empfangen wird, von Header-komprimierten Paketen, die während eines Intervalls zwischen dem Verlust des Pakets und einem Empfang eines nächsten Ganz-Header-Pakets nach dem Verlust empfangen werden, gekennzeichnet durch Dekomprimieren (S4, S8; S4', S8') eines komprimierten Headers von jedem der Header-komprimierten Pakete, die in einer Reihenfolge beibehalten werden, die umgekehrt ist zu der Reihenfolge einer Aufbewahrung, basierend auf einem Inhalt eines ganzen Headers eines Ganz-Header-Pakets, das nach dem Verlust des Pakets empfangen wird.
  11. Ein computerlesbares Speichermedium, das ein Programm speichert, um in einem Computer ein Ausführen eines Paketempfangsverfahrens hervorzurufen, umfassend die Schritte: Empfangen (S2, S6) eines Ganz-Header-Pakets mit einem ganzen Header oder eines Header-komprimierten Pakets mit einem komprimierten Header und Konvertieren eines empfangenen Pakets in ein dekomprimiertes Paket; wobei die Umwandlung enthält Beibehalten (S5), in Fällen, dass das Ganz-Header-Paket oder das Header-komprimierte Paket verloren geht bevor es empfangen wird, von Header-komprimierten Paketen, die während eines Intervalls zwischen dem Verlust des Pakets und einem Empfang eines nächsten Ganz-Header-Pakets nach dem Verlust empfangen werden, gekennzeichnet durch Dekomprimieren (S4, S8; S4', S8') eines komprimierten Headers von jedem der Header-komprimierten Pakete, die in einer Reihenfolge beibehalten werden, die umgekehrt ist zu der Reihenfolge einer Aufbewahrung, basierend auf einem Inhalt eines ganzen Headers eines Ganz-Header-Pakets, das nach dem Verlust des Pakets empfangen wird.
DE2001613906 2000-03-03 2001-02-26 Verfahren und Vorrichtung zur Paketübertragung mit Paketenkopfkompression Expired - Lifetime DE60113906T2 (de)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
JP2000059368 2000-03-03
JP2000059368 2000-03-03
JP2000132685 2000-05-01
JP2000132685 2000-05-01
JP2000146787 2000-05-18
JP2000146787A JP3730835B2 (ja) 2000-03-03 2000-05-18 パケット伝送方法、中継装置およびデータ端末

Publications (2)

Publication Number Publication Date
DE60113906D1 DE60113906D1 (de) 2005-11-17
DE60113906T2 true DE60113906T2 (de) 2006-07-06

Family

ID=27342580

Family Applications (1)

Application Number Title Priority Date Filing Date
DE2001613906 Expired - Lifetime DE60113906T2 (de) 2000-03-03 2001-02-26 Verfahren und Vorrichtung zur Paketübertragung mit Paketenkopfkompression

Country Status (7)

Country Link
US (1) US6385199B2 (de)
EP (1) EP1137237B1 (de)
JP (1) JP3730835B2 (de)
KR (1) KR100359703B1 (de)
CN (1) CN1165140C (de)
DE (1) DE60113906T2 (de)
SG (1) SG100624A1 (de)

Families Citing this family (67)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI107000B (fi) * 1999-02-17 2001-05-15 Nokia Mobile Phones Ltd Otsikon pakkaaminen reaaliaikaisissa palveluissa
US6754231B1 (en) 1999-06-18 2004-06-22 Telefonaktiebolaget Lm Ericsson (Publ) Robust header compression in packet communications
US6791982B2 (en) * 1999-09-29 2004-09-14 Telefonaktiebolaget Lm Ericsson Segmentation protocol that supports compressed segmentation headers
US6711164B1 (en) * 1999-11-05 2004-03-23 Nokia Corporation Method and apparatus for performing IP-ID regeneration to improve header compression efficiency
US6535925B1 (en) * 1999-11-09 2003-03-18 Telefonaktiebolaget L M Ericsson (Publ) Packet header compression using division remainders
EP1146713B1 (de) * 2000-03-03 2005-04-27 NTT DoCoMo, Inc. Verfahren und Vorrichtung zur Paketübertragung mit Paketenkopfkompression
US20020001315A1 (en) * 2000-03-21 2002-01-03 Tran Hung V. Method and apparatus for compressing IP/UDP/RTP headers in a lossy environment
US20040136380A1 (en) * 2000-09-12 2004-07-15 Daiji Ido Packet transmitter, packet receiver and packet transmission method
JP3323483B2 (ja) * 2000-09-12 2002-09-09 松下電器産業株式会社 パケット送信装置およびパケット伝送方法
EP1374524A1 (de) * 2001-03-29 2004-01-02 BRITISH TELECOMMUNICATIONS public limited company Protokollübersetzung
JP3512177B2 (ja) 2001-05-16 2004-03-29 松下電器産業株式会社 パケット受信装置及びパケット伝送方法
JP3617967B2 (ja) 2001-09-28 2005-02-09 松下電器産業株式会社 ヘッダ圧縮パケット受信装置及び方法
US6954460B2 (en) 2001-10-05 2005-10-11 Ericsson Inc. Method and apparatus for compressing packet headers
JP4549610B2 (ja) * 2001-11-08 2010-09-22 ソニー株式会社 通信システム、通信方法、送信装置および方法、受信装置および方法、並びにプログラム
US7814068B2 (en) * 2001-11-16 2010-10-12 Gemalto Sa Identifying changed records in a file stored on an electronic token
KR100765122B1 (ko) * 2001-11-24 2007-10-11 엘지전자 주식회사 패킷의 헤더압축을 지원하는 통신 시스템에서전체헤더패킷과 압축헤더패킷의 전송 제어 장치와 방법
DE60229482D1 (de) * 2001-11-24 2008-12-04 Lg Electronics Inc Verfahren zur Übertragung von Paketdaten in komprimierter Form in einem Kommunikationssystem
KR100425745B1 (ko) * 2001-11-24 2004-04-06 엘지전자 주식회사 패킷의 헤더압축을 지원하는 통신 시스템에서 패킷의전송방법
KR100443012B1 (ko) * 2001-12-22 2004-08-04 엘지전자 주식회사 압축데이터의 바이트열 복원 방법
US6760345B1 (en) * 2002-01-16 2004-07-06 Raytheon Company Compressing cell headers for data communication
US20030196081A1 (en) * 2002-04-11 2003-10-16 Raymond Savarda Methods, systems, and computer program products for processing a packet-object using multiple pipelined processing modules
JP3857611B2 (ja) * 2002-05-20 2006-12-13 富士通株式会社 データ圧縮プログラム、データ圧縮方法、およびデータ圧縮装置
CA2432594C (en) * 2002-06-12 2011-01-11 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for increased internet protocol (ip) headers compression performance by reporting cause of missing packets
KR100497357B1 (ko) * 2002-06-26 2005-06-23 삼성전자주식회사 인터넷 프로토콜 기반 네트워크 환경에 있어서 헤더 압축및 패킷 다중화 장치와 그 방법
JP4317403B2 (ja) * 2002-08-09 2009-08-19 パナソニック株式会社 ヘッダ圧縮装置及びヘッダ圧縮方法
US7647421B2 (en) * 2002-08-20 2010-01-12 Nokia Corporation Extension header compression
KR100663586B1 (ko) * 2002-08-28 2007-01-02 삼성전자주식회사 헤더 압축에 의한 패킷 데이터의 송신 방법 및 장치
KR20040040724A (ko) * 2002-11-07 2004-05-13 엘지전자 주식회사 무선 이동 통신 시스템의 상향 공통채널 및 그 운용 방법
JP4406816B2 (ja) * 2002-12-11 2010-02-03 ソニー株式会社 受信装置および受信方法、記録媒体、並びにプログラム
US7386013B1 (en) * 2003-01-03 2008-06-10 Juniper Networks, Inc. Systems and methods for compressing packet headers
US20040225748A1 (en) * 2003-05-09 2004-11-11 Chong Huai-Ter Victor Systems and methods for deleting transactions from multiple fast data streams
GB2403877A (en) * 2003-07-09 2005-01-12 Motorola Inc Packet communication with header compression
US7450586B2 (en) * 2003-07-22 2008-11-11 Motorola, Inc. Network header compression arrangement
US7512715B2 (en) * 2003-09-26 2009-03-31 Nokia Corporation System and method for requesting a resource over at least one network with reduced overhead
US7372841B2 (en) 2004-07-12 2008-05-13 Research In Motion Limited Packet-based communication system and method
KR100703494B1 (ko) * 2004-08-09 2007-04-03 삼성전자주식회사 이동통신 시스템에서 사용자 데이터 프로토콜 체크섬을 포함하는 음성패킷망의 패킷 송/수신 방법 및 장치
US8165104B2 (en) * 2004-12-08 2012-04-24 Qualcomm Incorporated Methods and systems for enhancing local repair in robust header compression
US7864701B2 (en) * 2005-03-31 2011-01-04 Intel Corporation Apparatus, system and method capable of decreasing management frame size in wireless networks
US7602778B2 (en) * 2005-06-29 2009-10-13 Cisco Technology, Inc. System and methods for compressing message headers
US9031071B2 (en) 2005-08-26 2015-05-12 Alcatel Lucent Header elimination for real time internet applications
KR100748342B1 (ko) 2005-09-14 2007-08-09 매그나칩 반도체 유한회사 씨모스 이미지 센서의 제조방법
US7948989B2 (en) * 2006-05-04 2011-05-24 Qualcomm, Incorporated Methods and systems for enhancing local repair in robust header compression
JP4954622B2 (ja) 2006-06-29 2012-06-20 京セラ株式会社 受信装置および復号方法
CN101479985B (zh) * 2006-06-29 2012-05-30 京瓷株式会社 内容数据、发送装置、接收装置以及解码方法
US7616568B2 (en) * 2006-11-06 2009-11-10 Ixia Generic packet generation
US7899025B2 (en) * 2006-12-26 2011-03-01 Alcatel-Lucent Usa Inc. Header suppression in a wireless communication network
US8027328B2 (en) * 2006-12-26 2011-09-27 Alcatel Lucent Header compression in a wireless communication network
JP4937005B2 (ja) * 2007-06-13 2012-05-23 三菱電機株式会社 音声伝送装置
US7885294B2 (en) * 2007-08-23 2011-02-08 Cisco Technology, Inc. Signaling compression information using routing protocols
US8059651B2 (en) * 2007-12-17 2011-11-15 Motorola Solutions, Inc. Method for recovering lost header
US8559463B2 (en) * 2008-02-20 2013-10-15 General Dynamics C4 Systems, Inc. Systems and methods for providing efficient bandwidth utilization in packet switched networks
US7898985B1 (en) * 2008-04-23 2011-03-01 Juniper Networks, Inc. Composite next hops for forwarding data in a network switching device
JP4985565B2 (ja) * 2008-06-30 2012-07-25 富士通株式会社 送受信回路、受信回路及び送受信回路の制御方法
KR101236033B1 (ko) * 2008-07-21 2013-02-21 한국전자통신연구원 통신 오버헤드를 제거하는 통신 시스템
US8014317B1 (en) 2008-08-21 2011-09-06 Juniper Networks, Inc. Next hop chaining for forwarding data in a network switching device
WO2010032318A1 (ja) * 2008-09-19 2010-03-25 富士通株式会社 パケットの送信方法及びノード
US7899056B2 (en) * 2009-01-13 2011-03-01 Fujitsu Limited Device and method for reducing overhead in a wireless network
US8023513B2 (en) * 2009-02-24 2011-09-20 Fujitsu Limited System and method for reducing overhead in a wireless network
WO2010124472A1 (zh) * 2009-04-30 2010-11-04 华为技术有限公司 一种数据的传输方法、相关设备和通信系统
US8509237B2 (en) * 2009-06-26 2013-08-13 Wisconsin Alumni Research Foundation Architecture and system for coordinated network-wide redundancy elimination
CN102484643B (zh) 2009-07-08 2015-11-25 汤姆森特许公司 后向鲁棒性首标压缩接收器
CN101764811B (zh) * 2009-12-30 2013-02-13 飞天诚信科技股份有限公司 数据流的生成方法
CN113301015A (zh) * 2011-12-20 2021-08-24 华为技术有限公司 网际协议头置换映射关系的获取方法及网络节点
US20140153580A1 (en) * 2013-02-15 2014-06-05 Comtech Ef Data Corp. Reference encoding and decoding for improving network header compression throughput for noisy channels
JP6654136B2 (ja) * 2014-08-08 2020-02-26 京セラ株式会社 受信端末及び送信端末
US11073822B2 (en) * 2014-09-25 2021-07-27 Siemens Aktiengesellschaft Provision of process values in a process installation
JP6524771B2 (ja) * 2015-03-23 2019-06-05 日本電気株式会社 通信装置、パケット伝送方法、及び、プログラム

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB9617553D0 (en) * 1996-08-21 1996-10-02 Walker Christopher P H Communication system with improved routing switch
US5987022A (en) * 1996-12-27 1999-11-16 Motorola, Inc. Method for transmitting multiple-protocol packetized data
JPH10247935A (ja) * 1997-03-05 1998-09-14 Yazaki Corp データ通信システムに用いられるデータフォーマット
US6032197A (en) * 1997-09-25 2000-02-29 Microsoft Corporation Data packet header compression for unidirectional transmission
US6111924A (en) * 1998-02-03 2000-08-29 Videoserver, Inc. Error-correction-code synchronization in a videoconferencing gateway
US6092120A (en) * 1998-06-26 2000-07-18 Sun Microsystems, Inc. Method and apparatus for timely delivery of a byte code and serialized objects stream

Also Published As

Publication number Publication date
EP1137237A2 (de) 2001-09-26
EP1137237A3 (de) 2003-10-15
JP2002026963A (ja) 2002-01-25
US6385199B2 (en) 2002-05-07
KR100359703B1 (ko) 2002-11-04
EP1137237B1 (de) 2005-10-12
DE60113906D1 (de) 2005-11-17
JP3730835B2 (ja) 2006-01-05
US20010030963A1 (en) 2001-10-18
CN1165140C (zh) 2004-09-01
SG100624A1 (en) 2003-12-26
KR20010087314A (ko) 2001-09-15
CN1311591A (zh) 2001-09-05

Similar Documents

Publication Publication Date Title
DE60113906T2 (de) Verfahren und Vorrichtung zur Paketübertragung mit Paketenkopfkompression
DE60131890T2 (de) Dynamische Delta-Kopierung für Kabelmodemkopffeldunterdrückung
DE60110303T2 (de) Verfahren und Vorrichtung zur Paketübertragung mit Paketenkopfkompression
DE60026577T2 (de) Einrichtung zum senden/empfangen eines bitstroms in einem netzwerk, sowie verfahren dazu
DE69930992T2 (de) Verfahren und Rechnerprogrammprodukt zum effizienten und sicheren Senden von kleinen Datennachrichten von einem Sender zu einer grossen Anzahl von Empfangssystemen
DE69736713T2 (de) Anordnung und verfahren zur übertragung von ip-daten über ein satellitennetz
DE69924732T2 (de) Quellknoten fuer ein breitbandnetzwerk mit atm zellen
DE60208466T2 (de) Verfahren und Vorrichtung zur Fehlerkorrektur der statischen Informationen im Kopffeld eines empfangenen Packets
DE60014852T2 (de) Headerkompression in echtzeitdiensten
DE602005005219T2 (de) Paketzusammenführung
DE69931215T2 (de) Verfahren und Rechnerprogrammprodukt zum effizienten und sicheren Senden von kleinen Datennachrichten von einem Sender zu einer grossen Anzahl von Empfangssystemen
DE69126604T2 (de) Anpassungseinrichtung und Verfahren zur wirksamen Verbindung von Datenverarbeitungseinrichtungen und Netzwerken
DE69935554T2 (de) Verfahren und Rechnerprogrammprodukt zum effizienten und zuverlässigen Übertragen von kleinen Datennachrichten von einem Sendesystem zu einer grossen Anzahl von Empfangssystemen
DE60131605T2 (de) Verfahren und Vorrichtung zur Paketkopfkompression
DE60025286T2 (de) Datenübertragungsverfahren, -vorrichtung und Datenempfangsvorrichtung
DE69938094T2 (de) Paketwiederübertragungskontrolle mit Prioritätsinformationen
DE60316094T2 (de) Verfahren, Vorrichtung und System für die Komprimierung von verlängerten Kopffeldern
DE60130944T2 (de) Verfahren zur Datenübertragung
DE112018005252T5 (de) System und verfahren zum klassifizieren und zeitstempeln von paketen
DE60128409T2 (de) Verfahren und Vorrichtung zur Entkomprimierung von Paket-Kopfdaten
DE60205092T2 (de) Kopfteilkompressionspaketempfangsvorrichtung und verfahren
DE60300354T2 (de) Methode zur Rekonstruktion paketisierter Nachrichten, die über ein oder mehrere Netzwerke verschickt wurden
EP0762694A1 (de) Lokales, nach dem asynchronen Transfermodus (ATM) arbeitendes Netzwerk mit wenigstens zwei Ringsystemen
EP1405422A2 (de) Verfahren zur optimierten nutzung von sctp (stream control transmission protocol) in mpls (multi protocol label switching) netzen
DE60029576T2 (de) Verfahren und einrichtung zur digitalen datenübertragung

Legal Events

Date Code Title Description
8364 No opposition during term of opposition