[go: up one dir, main page]

DE60020117T2 - Verfahren und Vorrichtung zur Datenpaketenübertragung - Google Patents

Verfahren und Vorrichtung zur Datenpaketenübertragung Download PDF

Info

Publication number
DE60020117T2
DE60020117T2 DE60020117T DE60020117T DE60020117T2 DE 60020117 T2 DE60020117 T2 DE 60020117T2 DE 60020117 T DE60020117 T DE 60020117T DE 60020117 T DE60020117 T DE 60020117T DE 60020117 T2 DE60020117 T2 DE 60020117T2
Authority
DE
Germany
Prior art keywords
packets
context
update
header
packet
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
DE60020117T
Other languages
English (en)
Other versions
DE60020117D1 (de
Inventor
Carsten Monzastrasse 4c Burmeister
Rolf Monzastrasse 4c Hakenberg
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.)
Panasonic Corp
Original Assignee
Matsushita Electric Industrial Co Ltd
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 Matsushita Electric Industrial Co Ltd filed Critical Matsushita Electric Industrial Co Ltd
Application granted granted Critical
Publication of DE60020117D1 publication Critical patent/DE60020117D1/de
Publication of DE60020117T2 publication Critical patent/DE60020117T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04Protocols for data compression, e.g. ROHC
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22Parsing or analysis of headers

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

  • Die Erfindung betrifft allgemein ein Verfahren und eine Vorrichtung zum Übertragen von Datenpaketen über einen unzuverlässigen Kanal und insbesondere zum Übertragen von Datenpaketen mit komprimierten Headern.
  • Es bestehen verschiedene Kommunikationstechnologien zum Übertragen von Daten von einem Endgerät zu einem anderen Endgerät. Die am häufigsten genutzten Techniken sind die Mobilfunk-Telefonie und das Internet. Weitere Entwicklungen sind Media-on-demand und Gesprächsdienste wie die Internet-Telefonie. Die meisten dieser Dienste erfordern den Transport von Echtzeitdaten mit Audio- und Videoinhalten.
  • In diesem Zusammenhang wird das RTP (Real-time Transport Protocol) verwendet. RTP ist ein Internet-Protokoll zum Übertragen von Daten in Echtzeit bzw. beinahe in Echtzeit. Das RTP selbst garantiert keine Echtzeit-Übertragung von Daten, bietet jedoch die Mechanismen für die sendenden und empfangenden Anwendungen, um ein Daten-Streaming zu unterstützen. Gewöhnlich wird RTP über dem UDP-Protokoll ausgeführt. Das UDP (User Datagram Protocol) ist ein verbindungsloses Protokoll, das ähnlich wie TCP auf IP-Netzwerken ausgeführt wird. Im Gegensatz zu TCP/IP, umfasst UDP/IP keine Fehlerkorrekturdienste, sondern bietet statt dessen eine direkte Möglichkeit zum Senden und Empfangen von Datagrams über ein IP-Netzwerk.
  • RTP wurde für Festnetze entwickelt, kann aber auch in Mobilnetzen verwendet werden. Ein Problem bei der Verwendung von RTP über Mobilnetzen besteht jedoch in der beschränkten Bandbreite des Mobilkanals. Der Grund dafür besteht darin, dass jedes der Protokolle RTP, UDP und IP einen eigenen Header aufweist. Ein Paket weist dann zusätzlich zu dem Link-Layer-Framing einen IP-Header von 20 Bytes, einen UDP-Header von 8 Bytes und einen RTP-Header von 12 Bytes auf, was zusammen mindestens 40 Bytes ergibt.
  • Der Header ist stark redundant, wobei zur Reduktion der Übertragungslast verschiedene Komprimierungsmechanismen für den Header entwickelt wurden. Die Protokolle für die Header-Komprimierung entfernen die Redundanz des Headers und codieren die Information auf eine effiziente Weise. Dies kann im besten Fall zu einer Komprimierung der Original-Headers bis auf ein Byte führen.
  • Ein System mit einem Header-Komprimierungsprotokoll ist in 1 gezeigt. Der Sender umfasst einen Komprimierer 100, der zum Komprimieren des Original-Headers verwendet wird. Der komprimierte Header wird dann zu dem Empfänger gesendet und dort durch den Entkomprimierer 110 entkomprimiert.
  • Der Kontext 120 ist der Zustand, den der Komprimierer verwendet, um den Header zu komprimieren. Der Kontext ist ein Satz von Variablen und besteht im Wesentlichen aus einer unkomprimierten Version der Header-Felder des letzten Headers. Neben den tatsächlichen Header-Feldern, umfasst der Kontext zusätzliche Variablen wie etwa Differenzen der ersten Ordnung zwischen Header-Feldem, die für eine Reihe von aufeinander folgenden Paketen als konstant befunden wurden. Der Kontext kann auch zusätzliche Informationen enthalten, die den Paketstrom beschreiben, zum Beispiel die typische Zunahme zwischen Paketen in Sequenznummern oder Zeitstempeln.
  • Während des Betriebs müssen der Komprimierer 100 und der Entkomprimierer 110 einen gemeinsamen Kontext aufrechterhalten. Wenn der Kontext 130 des Entkomprimierers 110 nicht mit dem Kontext 120 des Komprimierers 100 übereinstimmt, schlägt die Entkomprimierung des Headers fehl. Diese Situation kann auftreten, wenn Datenpakete über unzuverlässige, z.B. drahtlose, Kanäle übertragen werden, weil die Pakete dann zwischen dem Komprimierer 100 und dem Entkomprimierer 110 verloren gehen oder beschädigt werden können.
  • Es ist deshalb erforderlich, eine Resynchronisationsprozedur einzuleiten, sobald der Kontext 130 des Entkomprimierers 110 ungültig wird. Zu diesem Zweck werden Aktualisierungspakete (UP) zum Übertragen von Informationen im Kontext 120 des Komprimierers 100 an den Entkomprimierer 110 vorgesehen. Unter Verwendung der UP-Pakete wird der Kontext 130 aktualisiert.
  • Die Leistung eines Header-Komprimierungsschemas kann durch zwei Parameter, nämlich die Komprimierungseffizienz und die Robustheit, beschrieben werden. Ein robustes Schema toleriert Fehler in der Verbindung, über die eine Header-Komprimierung erfolgt, ohne zusätzliche Pakete zu verlieren, zusätzliche Fehler einzuführen oder eine größere Bandbreite zu nutzen. Die Verwendung der UP-Pakete erhöht auf der einen Seite die Robustheit, vermindert aber auf der anderen Seite die Komprimierungseffizienz, weil die UP-Pakete groß sind. Deshalb werden zusätzlich zu den UP-Paketen auch nicht-Aktualisienangspakete (NUP) verwendet, die sehr klein sind und nur von dem vorausgehenden UP-Paket abhängen. Die NUP-Pakete aktualisieren ihren Kontext nicht, sodass, wenn ein NUP-Paket verloren geht, der Kontext 130 des Entkomprimierers gültig bleibt und der Empfänger die folgenden Pakete weiterhin entkomprimieren kann.
  • Der zu komprimierende Paketstrom verhält sich gewöhnlich regelmäßig. Die meisten Header-Felder sind konstant und ändern sich während der Lebensdauer des Stroms nicht. Einige Felder ändern sich mit jedem Paket (z.B. die Sequenznummer und der Zeitstempel). Wenn die Werte dieser Felder mit der Sequenznummer synchronisiert werden und deshalb aus dieser Nummer errechnet werden können, ist der Strom regelmäßig. Unregelmäßigkeiten in diesen Feldern stören die Synchronisation, weil zum Beispiel ein nichtlinearer Sprung in dem RTP-Zeitstempelfeld vorliegt. Bei einer Unregelmäßigkeit können die Werte der geänderten Felder nicht aus der Sequenznummer berechnet werden. Diese Unregelmäßigkeiten können ziemlich häufig auftreten, z.B. durchschnittlich jede Sekunde bei einem Gesprächs-Audiostrom.
  • Die Länge von NUP-Paketen nimmt aus den folgenden beiden Gründen mit der Zeit zu. Wenn der Strom Unregelmäßigkeiten aufweist, sind die gesendeten NUP-Pakete größer, weil die Unregelmäßigkeiten aufgenommen werden müssen. Auch wenn keine Unregelmäßigkeiten im Strom auftreten, kann sich die Länge der NUP-Pakete vergrößern, weil größere Differenzen zu den letzten Aktualisierungspaketen vorliegen. Um die Länge der NUP-Pakete zu reduzieren, muss eine Aktualisierung durchgeführt werden, d.h. es wird eine Anzahl von UP-Paketen gesendet, wobei bei korrektem Empfang der Kontext aktualisiert wird.
  • Eine Schwierigkeit besteht darin, die für eine Aktualisierung zu sendende Anzahl von UP-Paketen zu bestimmen. Wenn zu viele gesendet werden, ist der Kontext bereits aktualisiert und gültig, während noch weitere UP-Pakete gesendet werden. Dadurch wird die Anzahl der übertragenen Bits unnötig erhöht und die Effizienz vermindert, weil die UP-Pakete größer als die NUP-Pakete sind. Wenn dagegen nicht genug UP-Pakete gesendet werden, erhöht sich das Risiko eines Kontextverlusts, weil die Wahrscheinlichkeit zunimmt, dass keines der gesendeten UP-Pakete empfangen wird.
  • Wenn also die Anzahl von UP-Paketen zu hoch ist, wird die Komprimierungseffizienz herabgesetzt. Und wenn die Anzahl von UP-Paketen zu niedrig ist, kann der Entkomprimierer den Kontext verlieren, sodass alle Pakete verworfen werden müssen, bis das nächste UP-Paket korrekt empfangen wird.
  • Bei unzuverlässigen Kanälen wie etwa in drahtlosen Netzwerken variiert die Kanalqualität gewöhnlich beträchtlich. Dies wird im Folgenden ausführlicher mit Bezug auf 2a bis 2c beschrieben.
  • In diesen Beispielen wird angenommen, dass ein Burstfehler auftritt. Burstfehler sind Fehler, durch die mehrere aufeinander folgende Pakete verloren gehen. In den Beispielen von 2a bis 2c wird angenommen, dass drei Pakete verloren gehen. Wie in 2a gezeigt, können ein UP-Paket und zwei NUP-Pakete nicht durch den Entkomprimierer empfangen werden. Weil der Entkomprimierer jetzt einen ungültigen Kontext aufweist, müssen die folgenden NUP-Pakete verworfen werden, sodass insgesamt ein Verlust von neun Paketen am Empfänger auftritt (10).
  • In 2b wurde die Anzahl der aufeinander folgenden UP-Pakete auf drei erhöht. Während das Senden einer Anzahl von aufeinander folgenden UP-Paketen gewöhnlich zuverlässiger ist, ist die Wahrscheinlichkeit hoch, dass wenigstens eines dieser UP-Pakete korrekt empfangen wird (15), wobei jedoch die Komprimierungseffizienz vermindert ist. Außerdem hat sich in 2b die Robustheit tatsächlich nicht verbessert, weil aufgrund der Natur des Fehlers wiederum neun Pakete nicht am Empfänger entkomprimiert werden können.
  • Ein Ansatz zur Beseitigung der Probleme von Burstfehlern besteht in der Verwendung eines Sparse-Modus, siehe (20) in 2c. Bei einem Sparse-Modus werden UP und NUP-Pakete in einer fixen Reihenfolge gesendet, wodurch das Senden aller UP-Pakete in einer Reihe vermieden wird. In dem Beispiel von 2c ist diese Sequenz die folgende: UP-NUP-UP-NUP-UP-NUP-UP-NUP-UP-NUP-UP-...
  • Wie aus 2c deutlich wird, kann auch das Senden von Paketen im Sparse-Modus zu einem wesentlichen Verlust von Datenpaketen 25 führen.
  • EP2081910A wurde nach dem Einreichungsdatum dieser Anmeldung veröffentlicht und betrifft eine Datenübertragungsvorrichtung zum sequentiellen Senden von Daten in Einheiten von Paketen, die jeweils Übertragungsdaten für ein Empfangsende enthalten. Das Dokument gibt ein Paket an, dass mittels eines Paketdatenübertragungsverfahrens zwischen mehreren Datenverarbeitungsvorrichtungen vorgesehen wird, in denen Daten in Entsprechung zu vorbestimmten Paketen am Sendeende komprimiert werden und die komprimierten Daten in Entsprechung zu diesen Paketen am Empfangsende wiederhergestellt werden.
  • Weiterhin beschreibt der Artikel von Degemark et al. „Low-loss TCP/IP header compression for wireless networks" in Wireless Network, US ACM, Vol. 3, No. 5, October 1997, auf den Seiten 375–387 ein Header-Komprimierungsschema für das UDP/IP- und TCP/IP-Protokoll. Das Dokument gibt an, wie die Größe der UDP/IP-Header auf 4 oder 5 Bit reduziert werden kann. Insbesondere wird eine Verallgemeinerung des am häufigsten verwendeten Verfahrens für die Header-Komprimierung für TCP/IPv4 von Jacobson zu IPv6 und mehreren IP-Headern angegeben. Das resultierende Schema sieht zwei einfache Mechanismen vor, um eine potentielle Verstärkung aus der Header-Komprimierung über verlustbehaftete drahtlose Netzwerke und Punkt-to-point-Modemverbindungen zu erhalten.
  • Die Techniken aus dem Stand der Technik bieten keine gute Lösung für die Komprimierungseffizienz und die Robustheit. Es stellt vielmehr ein schwerwiegendes Problem dar, die optimalen Bedingungen zu bestimmen.
  • Es ist deshalb eine Aufgabe der Erfindung, ein Verfahren und eine Vorrichtung zum Übertragen von Datenpaketen über einen unzuverlässigen Kanal anzugeben, wobei sowohl die Effizienz als auch die Robustheit verbessert werden können.
  • Diese Aufgabe wird durch die Erfindung gemäß dem Gegenstand der unabhängigen Ansprüche gelöst.
  • Gemäß der Erfindung wird die Anzahl der aufeinander folgenden UP-Pakete in Übereinstimmung mit der Kanalqualität gesetzt. Bei einem Kanal mit hoher Qualität kann also die Anzahl der UP-Pakete reduziert werden. Wenn eine hohe Fehlerrate auf dem Kanal vorliegt, wird die Anzahl der UP-Pakete erhöht, sodass eine robuste Verbindung zwischen dem Sender und dem Empfänger vorhanden ist.
  • Die Erfindung ist vorteilhaft, weil sie eine dynamische Anpassung des Übertragungs- und Komprimierungsmechanismus an die aktuelle Kanalqualität erlaubt. Insbesondere ermöglicht die Erfindung eine dynamische Steuerung der Aktualisierung des Kontexts für den Entkomprimierer in Übereinstimmung mit der Kanalqualität. UP-Pakete werden nur in der Anzahl gesendet, die erforderlich ist, um einerseits eine große Robustheit und andererseits eine bessere Komprimierungseffizienz sicherzustellen. Dadurch wird die mittlere Header-Größe auch dann reduziert, wenn die Kanalqualität variiert.
  • Bevorzugte Ausführungsformen der Erfindung sind in den abhängigen Ansprüchen definiert.
  • Indem die Gesamtanzahl der während deiner Kontextaktualisierungsphase übertragenen UP- und NUP-Pakete in Übereinstimmung mit der Rount-Trip-Time gesetzt wird, kann eine Anpassung dieser Anzahl auch bei Kanälen mit guter Qualität häufig durchgeführt werden. Dies gestattet eine präzisere Steuerung zum Finden des besten Kompromisses zwischen der Komprimierungseffizienz und der Übertragungsrobustheit.
  • Wenn die Anzahl der NUP-Pakete auf der Basis der Codec-Eigenschaften bestimmt wird, passen sich die Mechanismen der Erfindung nicht nur den aktuellen Eigenschaften des Kanals, sondern auch dem Typ des Paketstroms an. In dem die Sequenz der UP- und NUP-Pakete sowohl von der Kanalqualität als auch von den Eigenschaften des Paketstroms abhängig gemacht wird, kann ein noch besserer Kompromiss zwischen der Komprimierungseffizienz und der Übertragungsrobustheit erreicht werden.
  • Die Erfindung wird im Folgenden mit Bezug auf die beigefügten Zeichnungen beschrieben.
  • 1 zeigt ein Komprimierer/Entkomprimierer-System, in dem UP- und NUP-Pakete verwendet werden.
  • 2a2c zeigen Zeitdiagramme von UP-NUP-Sequenzen im Fall eines Burstfehlers.
  • 3 zeigt die UP-NUP-Sequenz während einer Kontextaktualisierungsphase gemäß der Erfindung.
  • 4a und 4b zeigen Komprimierer/Entkomprimierer-Systeme, in denen die Erfindung vorzugsweise verwendet werden kann.
  • 5 zeigt ein allgemeines Flussdiagramm des Kontextaktualisierungsprozesses gemäß der Erfindung.
  • 6a und 6b sind Flussdiagramme, die bevorzugte Ausführungsformen des Prozesses zum Setzen der Anzahl der UP-Pakete in jeder Teilsequenz zeigen.
  • 7 ist ein Flussdiagramm, das den Prozess zum Setzen der Gesamtanzahl von Paketen in der Sequenz gemäß einer bevorzugten Ausführungsform der Erfindung zeigt.
  • Im Folgenden werden Ausführungsformen der Erfindung ausführlicher beschrieben.
  • Wie in 3 gezeigt, kann die Sequenz der UP- und NUP-Pakete während der Kontextaktualisierungsphase in eine Anzahl von Teilsequenzen unterteilt werden. Jede Teilsequenz enthält eine Anzahl von UP-Paketen, auf die eine Anzahl von NUP-Paketen folgt. Die folgenden Parameter werden zur Beschreibung der UP-NUP-Sequenz gemäß der Erfindung verwendet.
  • Der Parameter p beschreibt die Gesamtanzahl von Paketen in der Kontextaktualisierungsphase. In diese Phase wird eingetreten, wenn eine Aktualisierung des Kontexts als erforderlich oder zumindest als nützlich betrachtet wird, d.h. zum Beispiel im Falle eines Kontextverlusts oder allgemeiner, wenn eine Unregelmäßigkeit in dem Datenstrom festgestellt wurde. Die Dauer der Kontextaktualisierungsphase wird ausreichend lange gewählt, damit der Entkomprimierer seinen Kontext aktualisieren kann.
  • Der Parameter k ist die Anzahl der Pakete in jeder Teilsequenz. In der bevorzugten Ausführungsform von 3 ist der Parameter in jeder Teilsequenz identisch.
  • Der Parameter m; beschreibt die Anzahl von UP-Paketen in der i-ten Teilsequenz. Der Wert dieses Parameters kann sich von Teilsequenz zu Teilsequenz unterscheiden, wobei in einer bevorzugten Ausführungsform der Erfindung der Parameter von Teilsequenz zu Teilsequenz um eins dekrementiert wird, d.h. mi = m–1-1.
  • Schließlich beschreibt der Parameter n; die Anzahl von NUP-Paketen in der i-ten Teilsequenz.
  • 4a und 4b zeigen Komprimierer/Entkomprimierer-Systeme, in denen die Erfindung vorzugsweise angewendet werden kann. Wie in 4a gezeigt, empfängt der Komprimierer Messwerte zu der Kanalqualität von der Messeinheit 400. Die Messeinheit 400 kann eine beliebige Einheit wie zum Beispiel eine physikalische Schicht sein, die für den Komprimierer 100 Messwerte zu der Kanalqualität vorsieht. Derartige Werte können zum Beispiel die Rauscheigenschaften in den Kanal oder Bit- bzw. Blockfehler angeben. Wenn keine Messungen verfügbar sind, kann die Messeinheit 400 auch eine Steuereinheit des Senders sein, die Aktionen durchführen kann, die wenigstens zu geschätzten Qualitätswerten führen.
  • In dem System von 4b kann der Entkomprimierer NACK (non-acknowledgement)-Meldungen an den Komprimierer senden, wenn die UP-Pakete einer Teilsequenz verloren gehen. Die Verwendung der NACKs wird durch die folgenden Erläuterungen verdeutlicht.
  • Das Flussdiagramm von 5 zeigt die Aktualisierung des Kontexts 130, wobei der Prozess die Schritte 500 bis 530 zum Setzen jedes der Parameter mi, k, ni und p umfasst. Dem Fachmann sollte deutlich sein, dass die Reihenfolge der in 5 gezeigten Schritte geändert werden kann. Zum Beispiel können die Parameter p oder k zuerst gesetzt werden. Weiterhin kann der Prozess zum Aktualisieren des Kontexts gemäß der Erfindung auch das Setzen von einigen Parametern vorsehen, während die restlichen Parameter konstant gewählt werden oder auf Standardwerte gesetzt werden.
  • Das Setzen der Parameter gemäß der Erfindung wird im Folgenden ausführlicher beschrieben. In Schritt 400 wird die Anzahl mi von UP-Paketen in jeder Teilsequenz gesetzt. Wie zuvor genannt, wird diese Anzahl vorzugsweise von Teilsequenz zu Teilsequenz um eins vermindert. Bei diesem Schema wird berücksichtigt, dass die Wahrscheinlichkeit des korrekten Empfangs von wenigstens einem UP-Paket mit dem Wert von i steigt. Dann ist es tatsächlich lediglich erforderlich, einen optimalen Startwert m1 zu finden.
  • Eine bevorzugte Ausführungsform zum Setzen von m1 ist in 6a gezeigt. In Schritt 600 erhält der Komprimierer 100 den aktuellen Wert des Parameters m1. Dann wird in Schritt 610 ein Maximum- und ein Minimumwert für m1 gelesen. Die Minimum- und Maximumwerte können zum Beispiel auf jeweils zwei und sechs gesetzt werden.
  • Wenn der Komprimierer zu Beginn der Sitzung keinen aktuellen Wert des Parameters m, erhalten kann, verwendet der Komprimierer in Schritt 600 statt dessen einen Startwert. Der Startwert kann vorzugsweise auf einen mittleren Wert zwischen dem Minimum und dem Maximum gesetzt werden.
  • Sobald der aktuelle Wert und die Grenzwerte erhalten wurden, empfängt der Komprimierer Messwerte von der Messeinheit 400, die oben mit Bezug auf 4A beschrieben wurde. Die in Schritt 620 erhaltenen Werte sind vorzugsweise Messwerte zu dem Signal/Rauschen-Verhältnis SNR oder der Blockfehlerrate BLER in dem Kanal. Wenn der SNR-Wert niedrig und damit BLER hoch ist, ist ein höherer Wert für m1 erforderlich, um die Wahrscheinlichkeit des korrekten Empfangs der Datenpakete am Entkomprimierer zu erhöhen.
  • Es wird dann in Schritt 630 unter Verwendung des erhaltenen Messwerts bestimmt, ob sich der Kanalzustand geändert hat. Wenn dies der Fall ist, wird der Parameter m1 in Schritt 640 aktualisiert. Weil sich der Kanalzustand sehr schnell und häufig ändern kann, wird der Wert m1 graduell angepasst, d.h. er wird um eine feste Größe in übereinstimmung damit geändert, ob die Kanalqualität sich verbessert oder verschlechtert hat.
  • Eine andere bevorzugte Ausführungsform zum Setzen der Anzahl m1 von UP-Paketen in der ersten Teilsequenz ist in 6b gezeigt. Dieser Ansatz wird vorzugsweise dann verwendet, wenn keine Messwerte von der Messeinheit 400 verfügbar sind. Nachdem der aktuelle Wert und die Minimum- und Maximumwerte erhalten wurden, bestimmt der Komprimierer in Schritt 650, ob eine NACK-Meldung empfangen wurde. Wenn wenigstens ein UP-Paket der ersten Teilsequenz korrekt empfangen wurde, sendet der Entkomprimierer 110 keine NACK-Meldung. Wenn also der Komprimierer 100 während der gesamten Prozedur keine NACK-Meldung empfängt, wird der Parameter m1 für die nächste Aktualisierungsprozedur um eins reduziert (Schritt 660). Wenn jedoch eine NACK-Meldung empfangen wird, wird der Parameter m1 in Schritt 670 erhöht. Dies kann vorzugsweise durchgeführt werden, indem entweder ein vorbestimmter Wert addiert wird oder der aktuelle Wert mit einem vorbestimmten Faktor multipliziert wird.
  • In den oben erläuterten Ausführungsformen wird nur der Wert von m1 direkt in Übereinstimmung mit der Kanalqualität gesetzt, während die Anzahl der UP-Pakete in den restlichen Teilsequenzen in Übereinstimmung mit der Gleichung m1 = mi-1-1 gesetzt wird. Es können jedoch alternativ hierzu nicht nur m1, sondern auch ein Teil oder alle Parameter mi unabhängig voneinander gesetzt werden.
  • Im Folgenden wird das Setzen des Parameters k, d.h, der Anzahl von Paketen in jeder Teilsequenz ausführlicher beschrieben (Schritt 510). Wie zuvor genannt, wird dieser Parameter für alle Blöcke konstant gewählt. Gemäß einer bevorzugten Ausführungsform der Erfindung wird dieser konstante Wert in Übereinstimmung mit den Codec-Eigenschaften gesetzt.
  • Der Grund hierfür liegt darin, dass einige Medien-Codecs (z.B. Sprach-Codecs) einen Paketverlust in gewissem Umfang tolerieren. Wenn der Codec zum Beispiel einen Paketverlust von bis zu x Paketen kompensieren kann, ohne dass der Hörer den Paketverlust bemerkt, wird der konstante Parameter k niedriger als diese Zahl x gesetzt. Zu diesem Zweck kann der Komprimierer zum Beispiel das Nutzlast-Feld des RTP-Headers lesen, um den verwendeten Codec festzustellen. Alternativ hierzu kann der Komprimierer eine verfügbare Bandabweichungs-Signalisierung verwenden.
  • Wenn der Komprimierer ausreichende Informationen zu den allgemeinen Eigenschaften des Codec festgestellt hat, wird der Parameter k entsprechend gesetzt. Die allgemeinen Eigenschaften von Codcs können zu diesem Zweck z.B. in einer Nachschlagetabelle des Komprimierers gespeichert werden. Wenn der Komprimierer keine geeigneten Informationen feststellen kann, wird der Parameter k auf einen Wert gesetzt, der die empfangende Anwendung nicht beeinträchtigen kann. In diesem Fall wird vorzugsweise ein eher pessimistischer Ansatz verwendet. Wenn weiterhin keine Informationen zu dem verwendeten Codec verfügbar sind, können die Parameter mi etwas erhöht werden, um trotzdem eine Robustheit sicherzustellen.
  • Schließlich umfasst der Prozess zum Aktualisieren des Kontexts mit dem Schritt 530 eine Prozedur zum Setzen der Gesamtanzahl p von Paketen in der Sequenz. Diese Prozedur ist in 7 ausführlicher dargestellt. Der Parameter p wird in der bevorzugten Ausführungsform der Erfindung auf einen Wert gesetzt, der ausreichend groß ist, damit der Entkomprimierer genügend Zeit hat, um auf einen Verlust von Datenpaketen mit einer NACK-Meldung zu reagieren. Der Parameter kann vorzugsweise in Übereinstimung mit der Round-Trip-Time RTT und vorzugsweise auf ein kleines Vielfaches derselben gesetzt werden. Aus diesem Grund sieht der Prozess von 7 eine Schätzung des aktuellen RTT-Werts vor.
  • Gemäß der Erfindung leitet der Prozess einen Kontextverlust in einer ruhigen Periode ein. Eine ruhige Periode ist eine Zeitperiode, während der keine Pakete gesendet werden. Gewöhnlich stellt der Komprimierer eine ruhige Periode zum Beispiel dann fest, wenn er für eine bestimmte Zeitdauer kein RTP-Paket empfangen kann.
  • Zuerst wird in Schritt 700 festgestellt, ob Pakete gesendet werden. Wenn eine ruhige Periode festgestellt wird, wird in Schritt 720 ein falsches Paket gesendet. Ein falsches Paket ist ein Paket, das keinen korrekt komprimierten Header enthält, sodass dieses Paket den Kontext 130 des Entkomprimierers 110 ungültig macht. Der Entkomprimierer wird dann unmittelbar eine NACK-Meldung zurücksenden, die durch den Komprimierer in Schritt 730 empfangen wird. Der Komprimierer schätzt den RTT-Wert in Schritt 740, indem er die Zeitdifferenz zwischen der Empfangszeit der NACK-Meldung und der Sendezeit des falschen Pakets berechnet. Wenn in Schritt 750 bestimmt wird, dass sich der RTT-Wert geändert hat, wird der Parameter p in Schritt 760 aktualisiert. Vorzugsweise wird der Parameter p proportional zu dem RTT-Wert gewählt.
  • Der beschriebene Prozess zum Setzen der Gesamtanzahl p von Paketen in der Sequenz ist vorteilhaft, weil dieser Prozess durchgeführt wird, wenn ohnehin eine Aktualisierungsprozedur nach einer ruhigen Periode gestartet wird, weil einige unerwartete Lücken in dem Zeitstempel aufgetreten sind. Es besteht also kein zusätzliches Risiko für einen Verlust des Kontexts 130.
  • Außerdem ist die beschriebene Prozedur zum Schätzen des RTT-Werts durch das Senden eines falschen Pakets vorteilhaft, weil der Prozess immer dann durchgeführt werden kann, wenn eine ruhige Periode festgestellt wird. Das Auftreten einer ruhigen Periode ist unabhängig von einem Kontextverlust, sodass eine Anpassung des Parameters p also auch bei Kanälen mit guter Qualität häufig vorgenommen werden kann.
  • Weiterhin ist die RTT-Schätzung gemäß der Erfindung deshalb vorteilhaft, weil sie eine präzise Steuerung des Parameters p gestattet. Wenn die Messung zum Beispiel nur unter Verwendung von NACK-Meldungen durchgeführt werden würde, ohne einen Kontextverlust durch das Senden eines falschen Pakets einzuleiten, würde die Messung den RTT-Wert plus eine zusätzliche Zeitdauer ergeben, während der wenigstens ein Paket verloren geht und ein anderes Paket empfangen wird. Diese zusätzliche Zeitdauer kann sehr hoch sein und kann nicht berechnet werden.

Claims (5)

  1. Verfahren zum Übertragen von Datenpaketen über einen Kanal von einem Sender zu einem Empfänger, wobei die Datenpakete komprimierte Header aufweisen, und das Verfahren folgende Schritte umfasst: Komprimieren eines Headers unter Verwendung eines Kontexts (120), Senden einer Sequenz aus einer Anzahl von Paketen mit einer Anzahl von Aktualisierungspaketen (UP), die den Kontext (120) aktualisieren, und einer Anzahl von nicht-Aktualisierungspaketen (NUP), die den Kontext (120) nicht aktualisieren, weiterhin gekennzeichnet durch die folgenden Schritte: Bestimmen (740) der Paket-Rount-Trip-Time (RTT) zwischen dem Sender und dem Empfänger, Setzen (760) der Anzahl von Aktualisierungs- und nicht-Aktualisierungspaketen in der Sequenz in Übereinstimmung mit der Round-Trip-Time (RTT).
  2. Verfahren nach Anspruch 1, weiterhin gekennzeichnet durch die folgenden Schritte: Feststellen (700) einer ruhigen Periode, in der keine Pakete durch den Sender gesendet werden, Senden (720) eines Datenpakets mit einem nicht korrekt komprimierten Header, Empfangen (730) einer NACK-Meldung, und Setzen (740) der Round-Trip-Time (RTT) auf die Zeitdifferenz zwischen dem Senden (720) des Datenpakets mit dem nicht korrekt komprimierten Header und dem Empfangen (730) der NACK-Meldung.
  3. Verfahren nach einem der Ansprüche 1 bis 2, weiterhin gekennzeichnet durch einen Schritt zum Bestimmen der Anzahl von nicht-Aktualisierungspaketen auf der Basis von Codec-Eigenschaften und der Anzahl von Aktualisierungspaketen.
  4. Vorrichtung zum Senden von Datenpaketen über einen Kanal, wobei die Datenpakete komprimierte Header aufweisen, wobei die Vorrichtung umfasst: einen Komprimierer (100) zum Komprimieren eines Headers unter Verwendung eines Kontexts (120), eine Übertragungseinrichtung zum Senden einer Sequenz aus einer Anzahl von Paketen mit einer Anzahl von Aktualisierungspaketen (UP), die den Kontext (120) aktualisieren, und einer Anzahl von nicht-Aktualisierungspaketen (NUP), die den Kontext nicht aktualisieren, weiterhin gekennzeichnet durch eine Einrichtung zum Bestimmen der Paket-Round-Trip-Time (RTT) zwischen dem Sender und dem Empfänger, und eine Einrichtung zum Setzen der Anzahl von Aktualisierungs- und nicht-Aktualisierungspaketen in der Sequenz in Übereinstimmung mit der Rount-Trip-Time (RTT).
  5. Vorrichtung nach Anspruch 4, weiterhin gekennzeichnet durch eine Einrichtung zum Durchführen der Schritte des Verfahrens gemäß einem der Ansprüche 2 oder 3.
DE60020117T 2000-09-07 2000-09-07 Verfahren und Vorrichtung zur Datenpaketenübertragung Expired - Lifetime DE60020117T2 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP00119571A EP1187417B1 (de) 2000-09-07 2000-09-07 Verfahren und Vorrichtung zur Datenpaketenübertragung

Publications (2)

Publication Number Publication Date
DE60020117D1 DE60020117D1 (de) 2005-06-16
DE60020117T2 true DE60020117T2 (de) 2005-10-06

Family

ID=8169785

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60020117T Expired - Lifetime DE60020117T2 (de) 2000-09-07 2000-09-07 Verfahren und Vorrichtung zur Datenpaketenübertragung

Country Status (6)

Country Link
US (1) US6967930B2 (de)
EP (1) EP1187417B1 (de)
JP (1) JP3535852B2 (de)
CN (1) CN1156123C (de)
CA (1) CA2353263C (de)
DE (1) DE60020117T2 (de)

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1177668A2 (de) * 1999-05-10 2002-02-06 Nokia Corporation Headerkomprimierung
DE60018927T2 (de) * 2000-09-07 2005-07-28 Matsushita Electric Industrial Co. Ltd., Kadoma Verfahren und Vorrichtung zur Datenpaketenübertragung
US7359372B2 (en) * 2002-06-12 2008-04-15 Telefonaktibolaget Lm Ericsson (Publ) Method and apparatus for fast change of internet protocol headers compression mechanism
JP3643360B2 (ja) * 2002-08-12 2005-04-27 松下電器産業株式会社 受信装置及び通信方法
EP1432196A1 (de) * 2002-12-20 2004-06-23 Matsushita Electric Industrial Co., Ltd. Kompressionsmethode für den Steuerungsverkehr in der Übertragung von Mediendaten
DE10320157B3 (de) * 2003-05-06 2004-11-11 Infineon Technologies Ag Kanalqualifizierung und -selektion in einem mehrkanaligen Funksystem durch Paketfehlerraten-Messung
DE10320176B3 (de) * 2003-05-06 2004-12-09 Infineon Technologies Ag Verfahren zur Selektion der Frequenzkanäle eines ein Frequenzsprungverfahren verwendenden Funksystems
US7602778B2 (en) * 2005-06-29 2009-10-13 Cisco Technology, Inc. System and methods for compressing message headers
WO2007050593A2 (en) * 2005-10-25 2007-05-03 William Marsh Rice University Method and apparatus for signal detection, classification, and estimation from compressive measurements
US8396041B2 (en) * 2005-11-08 2013-03-12 Microsoft Corporation Adapting a communication network to varying conditions
US8381047B2 (en) * 2005-11-30 2013-02-19 Microsoft Corporation Predicting degradation of a communication channel below a threshold based on data transmission errors
CN1992671B (zh) * 2005-12-28 2010-08-11 上海原动力通信科技有限公司 第三代演进系统中传输ip头压缩数据包的方法
US20090034529A1 (en) * 2007-07-30 2009-02-05 Motorola, Inc. Method and apparatus for routing packets via header-compression channels
US7885294B2 (en) * 2007-08-23 2011-02-08 Cisco Technology, Inc. Signaling compression information using routing protocols
US20090249172A1 (en) * 2008-03-26 2009-10-01 Qualcomm Incorporated Methods and apparatus for improved decoding of bursts that include multiple concatenated protocol data units
US8126014B2 (en) * 2008-04-09 2012-02-28 Qualcomm Incorporated Methods and apparatus for improved decoding of hybrid automatic repeat request transmissions
EP2328295B1 (de) * 2008-09-19 2014-09-24 Fujitsu Limited Paketübertragungsverfahren und knoten
US8705537B1 (en) * 2012-06-10 2014-04-22 Andrei Teodor Borac Eventually-consistent data stream consolidation
US20140149611A1 (en) * 2012-11-26 2014-05-29 Qualcomm Incorporated CHANNEL CONDITION AWARE USB DATA DELIVERY OVER Wi-Fi WITH DIFFERENTIAL TREATMENT ON DISTINCT USB ENDPOINTS
CN104782097A (zh) * 2013-10-22 2015-07-15 华为技术有限公司 一种广播系统中发送的编码数据包数量的计算方法和设备
CN114978430B (zh) * 2017-02-06 2024-10-15 中兴通讯股份有限公司 数据发送方法及终端设备
CN113890897B (zh) * 2021-11-04 2023-11-17 中国互联网络信息中心 一种报文处理方法和相关装置
CN114222269A (zh) * 2021-11-30 2022-03-22 深圳市领创星通科技有限公司 一种增强多节点传输可靠性的方法

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS5777214A (en) * 1980-11-04 1982-05-14 Nissan Motor Co Ltd Air conditioner for vehicle
US6556587B1 (en) * 1999-02-26 2003-04-29 Telefonaktiebolaget Lm Ericsson (Publ) Update of header compression state in packet communications
CN1349702A (zh) * 1999-02-26 2002-05-15 艾利森电话股份有限公司 分组通信的自适应头标压缩
EP1601157B1 (de) * 1999-08-06 2020-01-15 Godo Kaisha IP Bridge 1 Datensende- und -empfangsgerät und verfahren
US6300887B1 (en) * 1999-11-09 2001-10-09 Nokia Networks Oy Efficient handoff procedure for header compression
US6608841B1 (en) * 1999-12-30 2003-08-19 Nokia Networks Oy System and method for achieving robust IP/UDP/RTP header compression in the presence of unreliable networks
DE60018927T2 (de) 2000-09-07 2005-07-28 Matsushita Electric Industrial Co. Ltd., Kadoma Verfahren und Vorrichtung zur Datenpaketenübertragung

Also Published As

Publication number Publication date
US6967930B2 (en) 2005-11-22
JP2002124989A (ja) 2002-04-26
EP1187417A1 (de) 2002-03-13
CA2353263A1 (en) 2002-03-07
DE60020117D1 (de) 2005-06-16
JP3535852B2 (ja) 2004-06-07
EP1187417B1 (de) 2005-05-11
CN1156123C (zh) 2004-06-30
CA2353263C (en) 2007-01-23
CN1343056A (zh) 2002-04-03
US20020027882A1 (en) 2002-03-07

Similar Documents

Publication Publication Date Title
DE60020117T2 (de) Verfahren und Vorrichtung zur Datenpaketenübertragung
DE60022391T2 (de) System und verfahren zur erzielung einer robusten ip/udp/rtp-paketkopf-komprimierung in der gegenwart unzuverlässiger netze
DE60110303T2 (de) Verfahren und Vorrichtung zur Paketübertragung mit Paketenkopfkompression
DE60028399T2 (de) Robuste header-komprimierung bei paketbasierter kommunikation
DE60018927T2 (de) Verfahren und Vorrichtung zur Datenpaketenübertragung
DE60027875T2 (de) Aktualisierung des Headerkompressionszustands in Paketübertragung
DE60014852T2 (de) Headerkompression in echtzeitdiensten
DE60305793T2 (de) Verfahren, Sender und Empfänger zur Anpassung der Kodierrate an eine wechselnde Übertragungsrate
DE60130479T2 (de) Definieren einer kontextkennung bei der kopffeldkomprimierung
DE60214796T2 (de) Paketkopfkompression
DE19635116C2 (de) Verfahren zur Videokommunikation
DE60307505T2 (de) Verfahren zur verbesserung der qualität einer medienstromübertragung
EP0827312A2 (de) Verfahren zur Änderung der Konfiguration von Datenpaketen
DE60128409T2 (de) Verfahren und Vorrichtung zur Entkomprimierung von Paket-Kopfdaten
DE60017442T2 (de) Spärliche rückkoppelung in drahtlosen systemen die hohe verzögerung und niedrige bandbreite aufweisen
DE60116998T2 (de) In zugangstechnologie integrierte header-komprimierung
EP1063807B1 (de) Gemeinsame Quellen- und Kanalcodierung
DE60029576T2 (de) Verfahren und einrichtung zur digitalen datenübertragung
DE60129417T2 (de) Effiziente kopfteilunterdrückungskontext-aktualisierung bei der paketkommunikation
DE10105888B4 (de) Verfahren zum Steuern der Ziel-Bitfehlerrate für jedes Paket in leitungsgebundenen und drahtlosen Videokommunikationssystemen
DE10297176T5 (de) Verfahren und Anordnungen in ein Digital-Kommunikationssystem betreffenden Anwendungen
EP2309797B1 (de) Verfahren zum betreiben eines Mobilfunknetzes
DE60100173T2 (de) Verfahren und Vorrichtung zur drahtloser Übertragung unter Verwendung einer Kodierung mit vielfacher Quellendarstellung
EP1326357A1 (de) Verfahren zur Prüfung und Aufrechterhaltung einer vorbestimmten physikalischen Bitrate einer Leitungsverbindung
EP2385682B1 (de) Verfahren zum Optimieren einer paketorientierten Datenübertragung und Computerprogramm-Produkt

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8327 Change in the person/name/address of the patent owner

Owner name: PANASONIC CORP., KADOMA, OSAKA, JP