-
Gebiet der Erfindung
-
Die
vorliegende Erfindung betrifft ein Verfahren, eine Vorrichtung und
ein System zum Steuern einer Kopffeldkomprimierung und – dekomprimierung in
einem Paketdatennetzwerk, wie beispielsweise ein auf dem IP (Internet
Protocol) basierendes Netzwerk.
-
Hintergrund der Erfindung
-
In
Paketdatentransporte verwendenden Kommunikationsnetzwerken tragen
individuelle Datenpakete in einem Kopffeldbereich (Header Section) eine
Information, die zum Transportieren des Datenpakets von einer Quellanwendung
zu einer Zielanwendung benötigt
wird. Die eigentlichen zu übertragenden
Daten sind in einem Nutzlastbereich enthalten.
-
Der
Transportpfad eines Datenpakets von einer Quellanwendung zu einer
Zielanwendung beinhaltet gewöhnlich
mehrere Zwischenschritte, die durch, über Kommunikationsverbindungen
miteinander verbundene, Netzwerkknoten repräsentiert werden. Diese Netzwerkknoten,
die Paketvermittler oder Router genannt werden, empfangen das Datenpaket und
leiten es zu einem nächsten
Zwischenrouter weiter, bis ein Zielnetzwerkknoten erreicht ist,
der die Nutzlast des Datenpakets zu der Zielanwendung liefert. Aufgrund
von Beiträgen
verschiedener Protokollschichten zum Transport des Datenpakets kann
die Länge
des Kopffeldbereichs eines Datenpakets sogar die Länge des
Nutzlastbereichs überschreiten.
-
Eine
Datenkomprimierung des Kopffeldbereichs kann daher angewendet werden,
um eine bessere Ausnutzung der Verbindungsschicht zum Liefern der
Nutzlast zu einer Zielanwendung zu erhalten. Die Kopffeldkomprimierung
reduziert die Größe eines Kopffelds
durch Entfernen von Kopffeldfeldern oder durch Reduzieren der Größe von Kopffeldfeldern. Dies
wird so durchgeführt,
dass ein Dekomprimierer das Kopffeld rekonstruieren kann, falls
sein Kontextzustand identisch mit dem beim Komprimieren des Kopffelds
verwendeten Kontextzustand ist.
-
Die
Kopffeldkomprimierung kann auf Netzwerkschichtebene (z.B. für IP-Kopffelder), siehe
beispielsweise Spezifikation RFC 2507 der IETF (Internet Engineering
Task Force), auf Transportschichtebene (z.B. für User Datagram Protocol (UDP)-Kopffelder
oder Übertragungsüberwachungsprotokoll-Kopffelder
(Transport Control Protocol (TOP) header)) und auch auf Anwendungsschichtebene (z.B.
für Hyper
Text Transport Protocol (http)-Kopffelder) ausgeführt werden.
-
In
der Spezifikation RFC 3095 der IETF ist ein robustes Kopffeldkomprimierungs-Schema (Robust Header
Compression, ROHC) als ein sehr robustes und effizientes Kopffeldkomprimierungsschema
für RTP/UDP/IP
(Real Time Transport Protocol, User Datagram Protocol, Internet
Protocol)-, UDP/IP- und ESP/IP (Encapsulating Security Payload, ESP)-Kopffelder
spezifiziert. Vorhandene Kopffeldkomprimierungsschemata arbeiten
nicht gut, wenn sie über
Verbindungen mit signifikanten Fehlerraten und langen Round-Trip-Zeiten
verwendet werden. Für
viele bandbreitenbegrenzte Verbindungen, bei denen eine Kopffeldkomprimierung
wichtig ist, sind solche Eigenschaften üblich. Während der letzten Jahre sind
insbesondere zwei Kommunikationstechnologien üblicherweise von der allgemeinen Öffentlichkeit
genutzt worden: die Zellulartelefonie und das Internet. Die Zellulartelefonie
hat seinen Anwendern die revolutionäre Möglichkeit der ständigen Erreichbarkeit
mit vernünftiger
Dienstqualität
ermöglicht, gleichgültig wo
sie sich gerade befinden. Auf der anderen Seite war das Internet
von Beginn an für
mehrere Dienste ausgelegt und seine Flexibilität für jegliche Art von Verwendung
ist von jeher eine seiner Stärken.
IP-Telefonie gewinnt an Eigendynamik dank verbesserter technischer
Lösungen.
Zellulartelefone sind allzwecktauglicher geworden und können IP-Stapel
(IP-Stacks) aufweisen, die nicht nur Audio und Video unterstützen, sondern
auch Web-Browsing, E-Mail, Spiele usw. Daher können zwei miteinander kommunizierende
Mobilendgeräte über zellulare
Verbindungen mit Basisstationen verbunden sein, und die Basisstationen
können
mit einem auf IP basierenden drahtgebundenen Netzwerk verbunden sein.
Falls technisch und ökonomisch
machbar, würde
eine Lösung
mit reinem IP über
der gesamten Strecke von Terminal zu Terminal bestimmte Vorteile aufweisen.
Damit dies eine brauchbare Alternative wird, müssen allerdings eine Anzahl
von Problemen behandelt werden, insbesondere Probleme, die die Bandbreiteneffizienz
betreffen.
-
Für Zellulartelefonsysteme
ist es von entscheidender Bedeutung, die knappen Funkressourcen
auf effiziente Art zu nutzen. Eine ausreichende Anzahl von Nutzern
pro Funkzelle ist entscheidend, sonst wären die Betriebskosten untragbar.
Die Qualität
der Sprachdienste sollte auch so gut wie in den heutigen zellularen
Systemen sein. Es ist wahrscheinlich, dass selbst bei Unterstützung neuer Dienste,
eine geringere Qualität
der Sprachdienste nur dann akzeptierbar ist, wenn die Kosten wesentlich
reduziert werden.
-
Ein
Problem des IP über
zellulare Verbindungen bei dessen Verwendung für interaktive Sprachkonversationen
stellt der große
Kopffeld-Overhead dar. Aus Effizienzgründen besteht daher offensichtlich
Bedarf an einer Reduktion der Kopffeldgrößen. Allerdings haben zellulare
Verbindungen Eigenschaften, die eine Kopffeldkomprimierung weniger
als gut arbeiten lassen. Ein brauchbares Kopffeldkomprimierungsschema
für zellulare
Verbindungen muss in der Lage sein, Verluste bei der Verbindung
zwischen dem Komprimierungs- und dem Dekomprimierungspunkt sowie
Verluste vor dem Komprimierungspunkt handzuhaben.
-
Der
Kontext des Komprimierers ist der Zustand, den er beim Komprimieren
eines Kopffelds verwendet. Der Kontext des Dekomprimierers ist der Zustand,
den er beim Dekomprimieren eines Kopffelds verwendet. Jeder dieser
beiden oder beide gemeinsam werden üblicherweise als "Kontext" bezeichnet, wenn
klar ist, welcher beabsichtigt ist. Der Kontext beinhaltet relevante
Informationen vorheriger Kopffeldern in dem Paketstrom, wie beispielsweise
statische Felder und mögliche
Referenzwerte zur Komprimierung und Dekomprimierung. Darüber hinaus
sind zusätzliche
den Paketstrom beschreibende Informationen ebenfalls Teil des Kontexts,
beispielsweise Informationen darüber
wie sich das IP-Identifikatorfeld ändert und über den
typische Anstieg der Sequenznummern oder der Zeitstempel zwischen den
Paketen.
-
Im
Allgemeinen entspricht ein Paket einer Einheit der Übertragung
und des Empfangs, z.B. einer Protokolldateneinheit. Das Paket wird
z.B. durch ROHC komprimiert und dann dekomprimiert. Der Paketstrom
entspricht einer Sequenz von Paketen, wobei die Feldwerte und Änderungsmuster
von Feldwerten derart sind, dass die Kopffelder unter Verwendung
desselben Kontexts komprimiert werden können. Stimmt der Kontext des
Dekomprimierers nicht mit dem Kontext des Komprimierers überein,
so kann die Reproduktion des ursprünglichen Kopffelds durch die
Dekomprimierung fehlschlagen. Diese Situation kann eintreten, wenn
der Kontext des Dekomprimierers nicht geeignet initialisiert wurde
oder wenn Pakete zwischen Komprimierer und Dekomprimierer verloren
gegangen oder beschädigt
worden sind. Kontextreparaturmechanismen sind Mechanismen, die die
Kontexte synchronisieren, wenn sie nicht synchron waren. Dies ist
erforderlich, um übermäßigen Verlust
aufgrund von Kontextbeschädigungen
zu vermeiden.
-
Der
Hauptgrund, warum eine Kopffeldkomprimierung überhaupt durchgeführt werden
kann, ist die Tatsache, dass eine wesentliche Redundanz zwischen
Kopffeldern besteht, sowohl innerhalb desselben Paketkopffelds,
als auch insbesondere zwischen aufeinander folgenden Paketen, die
demselben Paketstrom angehören.
Durch lediglich anfängliches Senden
von statischer Feldinformationen und Verwenden von Abhängigkeiten
und Vorhersehbarkeiten für
andere Felder, kann die Kopffeldgröße für die meisten Pakete deutlich
reduziert werden. Relevante Informationen früherer Pakete werden dann im
Kontext behalten. Die Kontextinformationen werden verwendet, um
aufeinander folgende Pakete zu komprimieren oder zu dekomprimieren.
Der Komprimierer und der Dekomprimierer aktualisieren ihre Kontexte bei
bestimmten Ereignissen. Kontexte werden durch einen Kontextidentifikator
(Context Identifier, CID) identifiziert, der gemeinsam mit komprimierten
Kopffeldern und Feedback-Informationen gesendet wird. Die Feedback-Informationen
tragen Informationen vom Dekomprimierer zum Komprimierer. Eine Bestätigungsinformation
(Acknowledgement Information, ACK) wird verwendet, um eine erfolgreiche
Dekomprimierung eines Paketes zu bestätigen, was bedeutet, dass der
Kontext mit hoher Wahrscheinlichkeit auf dem aktuellsten Stand ist.
Des Weiteren wird eine Nicht-Bestätigungsinformation (Non-Acknowledgement
Information, NACK) verwendet, um anzuzeigen, dass der dynamische
Kontext des Dekomprimierers nicht synchronisiert ist. Diese Feedback-Information
wird erzeugt, wenn verschiedene aufeinander folgende Pakete nicht
korrekt dekomprimiert wurden.
-
Das
ROHC-Kopffeldkomprimierungsschema besitzt drei Betriebsmodi, genannt
unidirektionaler Modus (U-Modus), bidirektionaler optimistischer
Modus (O- Modus)
und bidirektionaler zuverlässiger
Modus (R-Modus, reliable mode). Der für den Betrieb optimale Modus
hängt von
den Eigenschaften der Umgebung des Komprimierungsprotokolls ab,
wie beispielsweise Feedback-Vermögen,
Fehlerwahrscheinlichkeiten und -verteilungen, Auswirkungen von Kopffeldgrößenvariationen
usw.
-
Im
U-Modus werden Pakete nur in einer Richtung vom Komprimierer zum
Dekomprimierer gesendet. Dieser Modus ist daher über Verbindungen nutzbar, bei
denen kein Rückkehr-Pfad
vom Dekomprimierer zum Komprimierer verfügbar oder erwünscht ist.
Im U-Modus werden Übergänge zwischen
Komprimierzuständen
nur unter Berücksichtigung
periodischer Auszeiten (Timeouts) und Unregelmäßigkeiten (Irregularities)
in den Kopffeldänderungsmustern
des komprimierten Paketstroms ausgeführt. Aufgrund der periodischen
Auffrischungen und des Mangels an Feedback zur Initiierung einer Fehlerbehebung
wird eine Komprimierung im U-Modus im Vergleich zu jedem der bidirektionalen
Modi weniger effizient sein und eine etwas höhere Verlustausbreitungswahrscheinlichkeit
aufweisen. Eine Komprimierung mit ROHC muss im U-Modus starten. Ein Übergang
zu einem der bidirektionalen Modi kann ausgeführt werden, sobald ein Paket
den Dekomprimierer erreicht hat und dieser mit einem Feedback-Paket
geantwortet hat, welches anzeigt, dass ein Modusübergang erwünscht ist.
-
Der
O-Modus ist ähnlich
dem U-Modus. Der Unterschied liegt darin, dass ein Feedback-Kanal verwendet
wird, um Fehlerbehebungsanforderungen und optional Bestätigungen
wichtiger Kontextaktualisierungen vom Dekomprimierer zum Komprimierer zu
senden. Periodische Auffrischungen werden im O-Modus nicht verwendet.
Der O-Modus zielt auf eine Maximierung der Komprimierungseffizienz
und der sparsamen Nutzung des Feedback-Kanals ab. Er reduziert die
Anzahl beschädigter
Kopffelder, die den höheren
Schichten aufgrund von Restfehlern oder Kontextaufhebungen geliefert
werden.
-
Schließlich unterscheidet
sich der R-Modus auf viele Arten von den vorigen zwei Modi. Die
wichtigsten Unterschiede sind eine intensivere Verwendung des Feedback-Kanals
und eine striktere Logik sowohl beim Komprimierer als auch beim
Dekomprimierer, die Verlust an Kontextssynchronisation zwischen
Komprimierer und Dekomprimierer verhindern, mit Ausnahme von sehr
hohen Restbitfehlerra ten. Ein Feedback wird zum Bestätigen aller
Kontextaktualisierungen gesendet. Der R-Modus zielt auf eine Maximierung
der Robustheit gegen Verlust- und Schadensausbreitung ab, d.h. auf
eine Minimierung der Wahrscheinlichkeit einer Kontextaufhebung, auch
unter Kopffeldverlust-/Fehlerbündel-Bedingungen.
-
ROHC
wurde unter der Annahme entworfen, dass Pakete zwischen dem Komprimierer
und dem Dekomprimierer beschädigt
werden können,
und dass solche beschädigte
Pakete dem Dekomprimierer geliefert werden können. ROHC erfasst beschädigte Kopffelder
unter Verwendung zyklischer Redundanzprüfungs-Codes (Cyclic Redundancy
Check Codes, CRCs) über
die ursprünglichen
Kopffelder. In den U- und O-Modi beinhalten die kleinsten Kopffelder
ein 3-Bit CRC, während
in dem R-Modus die kleinsten Kopffelder keinen CRC beinhalten. Daher wird
eine Beschädigung
der kleinsten Kopffelder im R-Modus nicht erfasst. Erfolgt der Betrieb
im U-Modus, so tragen alle komprimierten Kopffelder einen CRC, der
zur Verifikation einer Dekomprimierung genutzt werden muss.
-
Im
R-Modus wird die folgende Feedback-Logik vom Dekomprimierer verwendet.
Wenn ein aktualisiertes Paket, d.h. ein einen 7- oder 8-Bit-CRC
tragendes Paket, korrekt dekomprimiert wird, wird eine Bestätigung (ACK(R))
mit einem Modusparameter, der den R-Modus als den gewünschten
Komprimierungsmodus anzeigt, zum Komprimierer gesendet. Auf der
anderen Seite wird kein Feedback für Pakete gesendet, die nicht
den Kontext aktualisieren, d.h. für Pakete, die keinen CRC tragen.
-
Die
Entscheidung über
einen Übergang
von einem Komprimierungsmodus zu einem anderen, wird durch den Dekomprimierer
gefällt.
Für jeden Kontext
führen
der Komprimierer und der Dekomprimierer eine Variable, deren Wert
der gegenwärtige Komprimierungs-
bzw. Dekomprimierungsmodus für diesen
Kontext ist. Der Wert dieser Variablen steuert für den betreffenden Kontext,
welche Pakettypen verwendet werden, welche Aktionen durchgeführt werden
usw. Auf der Komprimiererseite werden die Parameter C_MODE und C_TRANS
bereitgestellt. Mögliche
Werte für
den C_MODE-Parameter sind "U" für unidirektional, "O" für
optimistisch und "R" für zuverlässig. Der
Parameter C_MODE muss auf "U" initialisiert werden.
Des Weiteren sind mögliche
Werte für
den Parameter C_TRANS "P" für anhängig (pending)
und "D" für fertig
(done). Der Parameter C_TRANS muss auf "D" initialisiert
werden. Wenn der Parameter C_TRANS auf "P" gesetzt
wird, ist es erforderlich, dass der Komprimierer nur Paketformate
verwendet, die allen Modi gemeinsam sind, dass eine Modusinformation
zumindest periodisch in den gesendeten Paketen enthalten ist, und
dass neue Modenübergangsanforderungen
ignoriert werden.
-
Auf
der Dekomprimiererseite werden die Parameter D_MODE und D_TRANS
bereitgestellt. Mögliche
Werte für
den Parameter D_MODE sind "U" für unidirektional, "O" für
optimistisch und "R" für zuverlässig. Der
Parameter D_MODE muss mit "U" initialisiert werden.
Des Weiteren sind mögliche
Werte für
den Parameter D_TRANS "I" für initiiert, "P" für anhängig (pending)
und "D" für fertig
(done). Der Parameter D_TRANS muss auf "D" initialisiert
werden. Ein Modenübergang
kann nur initiiert werden, wenn der Parameter D_TRANS auf "D" gesetzt ist. Während der Parameter D-TRANS
auf "I" gesetzt ist, sendet
der Dekomprimierer eine Nicht-Bestätigung (NACK) oder eine Bestätigung (ACK),
die eine CRC-Option für
jedes empfangene Paket trägt.
-
Aufgrund
der ansteigenden Größen von IP-Adressfeldern
wurde eine IP-Kopffelderweiterung für IP-Kopffelder
eingeführt,
um die Änderungen
zu minimieren, die zum Unterstützen
von IP-Adresserweiterungen erforderlich sind. Wenn allerdings ein ankommendes
Paket ein großes
IP-Erweiterungskopffeld besitzt, dann können der Komprimierer und der
Dekomprimierer aufgrund von z.B. einer Kontextbeschädigung die
gegenseitige Konsistenz verlieren, was zu Komprimierungs- und/oder
Dekomprimierungsfehlern führt.
Beispielsweise kann sich eine Kontextbeschädigung ergeben, wenn der Komprimierer
eine größere IP-Erweiterungskopffeldliste komprimiert
als der Dekomprimierer vorbereitet ist zu speichern, aufgrund der
Tatsache, dass dem Dekomprimierer für die maximale IP-Erweiterungskopffeldlistengröße nicht
ausreichend Speicher zugeteilt ist. Tritt der Kontextverlust auf,
so kann es eine lange Zeit vergehen, bis der Kontext repariert ist,
wobei während
dieser Periode viele Pakete aufgrund fehlerhafter Dekomprimierung
gelöscht
werden. Ein unkomprimierter Pakettyp wird dann verwendet, um den
Kontext wieder zu synchronisieren, was zu einer niedrigen Komprimierungseffizienz
führt.
Gemäß einer
anderen Lösung
kann dem Dekomprimierer ausreichend Speicher für die maximal dimensionierte IP-Erweiterungskopffeldliste
zugeteilt werden. Dies wird allerdings zu einem enor men Speicherverbrauch
führen,
da die maximale Größe der IP-Erweiterungskopffeldlisten
dieselbe ist, wie die maximale Größe des Eingangspakets.
-
Zusammenfassung der Erfindung
-
Es
ist daher Aufgabe der vorliegenden Erfindung, ein verbessertes Kopffeldkomprimierungsschema
bereitzustellen, mittels dem Kontextinkonsistenzen zwischen dem
Komprimierer und dem Dekomprimierer aufgrund großer IP-Erweiterungskopffelder verhindert werden
können.
-
Diese
Aufgabe wird durch ein Verfahren gemäß Anspruch 1 gelöst.
-
Des
Weiteren wird die oben genannte Aufgabe durch eine Komprimiervorrichtung
gemäß Anspruch
8 gelöst.
-
Schließlich wird
die oben genannte Aufgabe durch ein System gemäß Anspruch 10 gelöst.
-
Dementsprechend
wird ein Kopffeldkomprimierungs- und Dekomprimierungsschema bereitgestellt,
welches den Dekomprimierer und den Komprimierer in normaler Betriebsart
hält, auch
wenn ein Paket mit großem
IP-Erweiterungskopffeld
empfangen wird. Die Lösung
ist kompatibel mit dem existierenden ROHC-Standard und verhindert
Inkonsistenzen von Kontexten zwischen einem Komprimierer und einem
Dekomprimierer. Eine höhere
Komprimierungseffizienz wird erreicht, da Kontexte nicht repariert
werden müssen
und dekomprimierte Pakete korrekt zu oberen Protokollschichten geliefert
werden, ohne ein Paket zu löschen.
Darüber
hinaus kann der Speicherverbrauch der Implementierung beträchtlich reduziert
werden.
-
Die
Kopffeldkomprimierung kann auf einem ROHC-Schema basieren. In diesem
Fall kann das von der Komprimiererseite der Verbindung übertragene
Nichtreferenzpaket ein Paket ohne Erzeugungsidentifikator sein,
falls der Betriebsmodus ein U- oder ein O-Modus ist, wobei der Erzeugungsidentifikator
verwendet wird, um eine gleiche Erzeugung von Kopffelderweiterungslisten
anzuzeigen. Anderer seits kann das Nichtreferenzpaket ein ROHC-Zuverlässigkeitsmoduspaket
sein, das einen Dekomprimierungskontext nicht aktualisiert, falls
der Betriebsmodus ein R-Modus ist. Insbesondere kann dieses Zuverlässigkeitsmoduspaket
ein R-1-Moduspaket sein.
-
Im
Fall des ROHC-Schemas kann die Kopffelddekomprimierung ausgestaltet
sein, im Ansprechen auf den Empfang des großen Erweiterungskopffelds einen Übergang
zu einem zuverlässigen Modus
durchzuführen.
-
Des
Weiteren kann die Unterdrückung
beibehalten werden, bis ein Erweiterungskopffeld einer Größe kleiner
oder gleich der vorbestimmten Kopffelderweiterungsgröße empfangen
wurde.
-
Kurzbeschreibung der Zeichnungsfiguren
-
Im
Folgenden wird die vorliegende Erfindung basierend auf einem bevorzugten
Ausführungsbeispiel
mit Bezug auf die beigefügten
Zeichnungsfiguren näher
beschrieben, wobei:
-
1 eine
schematische Darstellung eines Formats eines IP-Erweiterungskopffeldes zeigt;
-
2 ein
schematisches Blockdiagramm einer Übertragungsverbindung mit einem
Komprimierer und einem Dekomprimierer gemäß dem bevorzugten Ausführungsbeispiel
zeigt;
-
3 ein
schematisches Flussdiagramm einer Komprimierungssteuerprozedur gemäß dem bevorzugten
Ausführungsbeispiel
zeigt;
-
4 ein
schematisches Flussdiagramm einer Dekomprimierungssteuerprozedur
gemäß dem bevorzugten
Ausführungsbeispiel
zeigt; und
-
5 ein
Beispiel eines Paketflussdiagramms gemäß dem bevorzugten Ausführungsbeispiel
zeigt.
-
Beschreibung des bevorzugten
Ausführungsbeispiels
-
Das
bevorzugte Ausführungsbeispiel
wird nun auf der Grundlage einer Paketdatenübertragungsverbindung zwischen
einer Sendeeinheit 200 und einer Empfangseinheit 300,
die beide ein ROHC-Schema verwenden, beschrieben, wie in 2 veranschaulicht
ist. Die Sendeeinheit 200 und die Empfangseinheit 300 können Router
eines auf IP basierenden Netzwerks sein, z.B. ein auf IP basierendes
zellulares Netzwerk.
-
Das
vorliegende Komprimier- und Dekomprimierschema gemäß dem bevorzugten
Ausführungsbeispiel
ist ausgelegt, um große
IP-Erweiterungskopffelder oder Kopffeldlisten verarbeiten zu können, die
IPv4- oder IPv6-Kopffeldern beigefügt sein können.
-
1 zeigt
eine schematische Darstellung eines Formats eines Erweiterungskopffeldes,
wie es in der IETF-Spezifikation RFC 3095 für ein ROHC-komprimiertes Paket spezifiziert ist.
Gemäß 1 umfasst
das Erweiterungskopffeld ein Kennungs-Oktett 120 zum Anzeigen
des Vorhandenseins spezifischer komprimierter Sequenznummern, die
in den nachfolgenden Oktetts 130 bereitgestellt sind. Die
1-Bit-Kennungen werden gesetzt, wenn das entsprechende Kopffeldelement
der Oktetts 120 komprimiert ist. Ist eine entsprechende
Kennung nicht gesetzt, so wird das entsprechende Kopffeldelement
unkomprimiert gesendet oder ist nicht vorhanden. Eine spezifische
erste Kennung CL zeigt das Vorhandensein einer komprimierten Kopffeldliste variabler
Länge an.
Basierend auf der ersten Kennung CL kann daher bestimmt werden,
ob die komprimierte Kopffeldliste 140 dem Erweiterungskopffeld 100 beigefügt ist.
-
3 zeigt
ein schematisches Flussdiagramm einer Komprimierungssteuerprozedur
wie sie in einer Komprimierungssteuereinheit 202 zum Steuern
einer Komprimierung eines Komprimierers 201 der in 2 gezeigten
Sendeeinheit 200 ausgeführt wird.
In ähnlicher
Weise wird in der Empfangseinheit 300 eine Dekomprimierungssteuereinheit 302 zum Steuern
der Dekomprimierung eines Dekomprimierers 301 bereitgestellt.
Die Komprimierungssteuereinheit 202 und der Komprimierer 201 der
Sendeeinheit 200 können
als eine einzelne Einheit oder als Software-Routinen eines Programms
ausgestaltet sein, welches in der Sendeeinheit 200 gespeichert ist.
Gleiches kann für
die Dekomprimierungssteuereinheit 302 und den Dekomprimierer 301 in
der Empfangseinheit 300 gelten.
-
Es
wird angemerkt, dass die in 2 gezeigte
Zwei-Leitungsverbindung, die einen Steuerkanal cch, der ein bandexterner
Kanal sein kann, und einen Datenkanal dch zum Verbinden des Komprimierers 201 und
des Dekomprimierers 301 umfasst, als eine allgemeine oder
vereinfachte Darstellung zu betrachten ist, da sich der Datenkanal
dch und der Steuerkanal cch auch auf verschiedene Signalisierungsströme oder
Paketeinheiten von verschiedenen Protokollschichten beziehen können. Aufgrund
von beispielsweise individuellen Ressourceneinschränkungen
für ROHC
werden entsprechende vorbestimmte Anzahlen oder Größen von
IP-Erweiterungskopffeldern oder Erweiterungskopffeldlisten unabhängig für die betrachtete
Verbindung eingestellt, z.B. durch den Betreiber oder eine entsprechende
Initialisierungsroutine bei der Sendeeinheit und bei der Empfangseinheit.
Somit ist die maximale Größe des Erweiterungskopffeldes
oder der Erweiterungskopffeldliste lokal an dem Komprimierer 201 und
dem Dekomprimierer 301 konfiguriert, und dem einen ist nicht
bekannt, welchen Wert der andere gerade verwendet.
-
Gemäß dem in 3 gezeigten
Flussdiagramm wird anfänglich
ein Komprimierungsmodus im Schritt S100 konfiguriert. Im Zuge dieser
Moduskonfiguration wird eine maximal erlaubte oder unterstützte Größe der Erweiterungskopffeldliste
eingestellt oder konfiguriert. Im Schritt S101 der 3 wird
ein Paket mit einem IP-Erweiterungskopffeld 140 empfangen,
das durch den Komprimierer 201 z.B. während einer Analyse des ankommenden
Pakets erfasst werden kann. Die Komprimierungssteuereinheit 202 überprüft, ob die
Größe des empfangenen
IP-Erweiterungskopffeldes 140 größer als
die zur Komprimierung bei der Sendeeinheit 200 eingestellte
konfigurierte maximale Erweiterungskopffeldlistengröße ist.
Falls nicht, wird im Schritt S102 überprüft, ob der U- oder der O-Modus
eingestellt ist. Falls dem so ist, wird dem empfangenen Paket im
Schritt S103 ein Erzeugungsidentifikator zugeteilt. Falls weder
der U- noch der O-Modus eingestellt ist, wird im Schritt S107 ein
R-Moduspaket erzeugt. Im vorliegenden Fall wird angenommen, dass
der Komprimierer sich in dem U- oder O-Modus befand, als das Paket
empfangen wurde. In diesen Modi werden Sequenzen identischer Listen
als zur selben Erzeugung gehörend
betrachtet und werden alle demselben Erzeugungsidentifikator zugeordnet.
Der Erzeugungsidentifikator wird jedes Mal um "1" erhöht, wenn
sich die Liste ändert,
und wird in komprimierten und unkomprimierten Listen geführt, die
Kandidaten für
eine Verwendung als Referenzlisten sind. In referenzbasierten Komprimierungsschemata,
d.h. auf Addition oder auf Löschung
basierende Schemata, basieren Komprimierung und Dekomprimierung
einer Liste auf der Referenzliste, die in dem Kontext sowohl des
Komprimierers 201 als auch des Dekomprimierers 301 als
vorhanden angenommen wird. Die komprimierte Liste ist eine Verschlüsselung
der Unterschiede zwischen der gegenwärtigen Liste und der Referenzliste.
Beim Empfang einer komprimierten Liste wendet der Dekomprimierer 301 die
Unterschiede zu seiner Referenzliste an, um die Originalliste zu
gewinnen. Normalerweise muss der Erzeugungsidentifikator in wenigstens
einer vorbestimmten Anzahl von Kopffeldern wiederholt werden, bevor
die Liste als Referenzliste verwendet werden kann. Allerdings können einige
Bestätigungen
in dem O- oder U-Modus gesendet werden, und immer dann, wenn eine
Bestätigung
für ein
Kopffeld empfangen wird, wird die Liste dieses Kopffelds als bekannt
betrachtet und braucht nicht weiter wiederholt werden. Weitere Details
bezüglich dieses
referenzbasierten Komprimierungsschemas können der oben genannten IETF-Spezifikation
RFC 3095 entnommen werden.
-
Im
Schritt S108 wird das verarbeitete Paket an den Dekomprimierer 301 weitergeleitet
und die Prozedur kehrt zum Schritt S101 zurück.
-
Falls
die Überprüfungsoperation
im Schritt S101 der 3 zu dem Ergebnis führt, dass
die Größe der empfangenen
IP-Erweiterungskopffeldliste größer als
die konfigurierte maximale Größe der Kopffelderweiterungsliste
ist, wird im Schritt S104 überprüft, ob sich
der Komprimierer 201 in dem U- oder in dem O-Modus befindet.
Falls im Schritt S104 festgestellt wird, dass sich der Komprimierer 201 in dem
U- oder O-Modus befindet, erzeugt der Komprimierer 201 ein
Paket mit Erweiterungskopffeldliste 140, aber ohne Erzeugungsidentifikator
(Schritt S105). Solche Listen ohne Erzeugungsidentifikator wird
kein neuer Erzeugungsidentifikator zugewiesen und sie werden nicht
als zukünftige
Referenzlisten verwendet. Somit werden sie nicht zur Aktualisierung des
Kontexts an dem Dekomprimierer 301 verwendet.
-
Falls
andererseits im Schritt S104 festgestellt wird, dass sich der Komprimierer 201 nicht
in dem U- oder O-Modus befindet, d.h. er befindet sich in dem R-Modus, so sendet
der Komprimierer 201 ein R1-*-Paket, das jeglicher Art
von in RFC 3095 definiertem R1-Paket entspricht (Schritt S106).
Solche Pakete haben kein CRC-Feld und werden daher nicht als Referenz
zum Aktualisieren des Kontexts an dem Dekomprimierer 301 verwendet.
Schließlich
wird das erzeugte Paket im Schritt S108 an den Dekomprimierer 301 weitergeleitet.
-
4 zeigt
ein schematisches Flussdiagramm einer Dekomprimierungssteuerprozedur
auf deren Grundlage die Dekomprimierungssteuereinheit 302 den
Dekomprimierer 301 auf der Empfangsseite 300 steuert.
Nach Konfiguration einer maximal erlaubten oder unterstützten Erweiterungskopffeldgröße zur Dekomprimierung
im Schritt S200, wird ähnlich
zum Schritt S100 in 3 im Schritt S201 überprüft, ob die
Größe einer
empfangenen IP-Erweiterungskopffeldliste größer als die konfigurierte maximale
Größe ist.
Falls die empfangene Größe nicht
größer als
die konfigurierte maximale Größe ist, so
kann im Schritt S202 eine normale Bestätigung zum Komprimierer 201 gesendet
werden. Es wird angemerkt, dass der Dekomprimierer 301 nicht
notwendigerweise eine Bestätigung
in diesem Schritt senden muss, da in dem U- oder dem O/R-Modus nicht jedes
Paket bestätigt
wird.
-
Falls
andererseits die empfangene Größe größer als
die konfigurierte maximale Größe ist,
so wird im Schritt S203 überprüft, ob sich
der Dekomprimierer 301 in dem U- oder O-Modus befindet.
Falls dies der Fall ist, initiiert die Dekomprimierungssteuereinheit 302 einen Übergang
zu dem R-Modus, wobei der Dekomprimierer 301 keine Bestätigung sendet, nachdem
er sich in dem R-Modus befindet (Schritt S204). Diese Unterdrückung von
Bestätigungen
dauert an, bis ein Paket mit IP-Erweiterungskopffeldlisten einer
kleineren Größe als die
konfigurierte maximale Größe empfangen
wird. Falls in dem Schritt S203 festgestellt wird, dass sich der
Dekomprimierer 301 nicht in dem U- oder O-Modus befindet,
d.h. er befindet sich in dem R-Modus, so wird die Übertragung
einer Bestätigung
im Schritt S205 unterdrückt.
Schließlich
kehrt die Prozedur nach den Schritten S202, S204 bzw. S205 zum Schritt
S201 zurück.
Dadurch werden keine Bestätigungen
von dem Dekomprimierer 301 zu dem Komprimierer 201 gesendet,
solange IP-Erweiterungskopffelder
mit übermäßiger Größe empfangen
werden.
-
5 zeigt
ein spezifisches Beispiel für
ein Paketübertragungsschema
zwischen dem Komprimierer 201 mit einer konfigurierten
maximalen Erweiterungskopffeldlistengröße IP_EXTC und dem Dekomprimierer 301 mit
einer konfigurierten maximalen Erweiterungskopffeldlistengröße IP_EXTD,
wenn ein Paket k mit großem
Erweiterungskopffeld empfangen wird.
-
In
diesem Beispiel wird angenommen, dass die konfigurierte maximale
Erweiterungskopffeldlistengröße IP_EXTC
an dem Komprimierer 201 größer als oder wenigstens gleich
ist mit der konfigurierten maximalen Erweiterungskopffeldlistengröße IP_EXTD
an dem Dekomprimierer 301. Die Erweiterungskopffeldliste
im Paket k ist größer als
die konfigurierte maximale Erweiterungskopffeldlistengröße IP_EXTD
an dem Dekomprimierer 301, aber sie ist kleiner als die
konfigurierte maximale Erweiterungskopffeldlistengröße IP_EXTC.
Da angenommen wird, dass sich der Komprimierer 210 in dem
U- oder O-Modus befindet, überträgt er das
Paket mit Erzeugungsidentifikator. Gemäß der in 4 gezeigten Prozedur
bestätigt
der Dekomprimierer 301 nicht das Paket k und sendet eine
Nicht-Bestätigung (Non-Acknowledgement)
NACK(R) mit einem Parameter, welcher einen Modusübergang zum R-Modus anzeigt.
Nachdem diese NACK(R)-Mitteilung
empfangen wurde, führt
der Komprimierer 210 auch den Übergang in den R-Modus durch,
wie mit dem Parameter C_MODE angezeigt wird. Da noch keine Bestätigung empfangen
wurde, wird darüber
hinaus der Parameter C_TRANS in den Zustand "P" gesetzt, weil
das Paket k nicht als Referenz verwendet werden kann. Dann sendet
der Komprimierer 201 einen Pakettyp 2, z.B. eine
UOR-2, welcher als eine Referenz für die nachfolgende Dekomprimierung
an dem Dekomprimierer 301 verwendet werden kann. Als Alternative
kann der Komprimierer 201 ein IR-DYN-Paket senden, welches
den dynamischen Teil des Kontexts kommuniziert, d.h. Parameter nicht-konstanter Funktionen,
wie in RFC 3095 definiert ist. Allerdings ist die Liste in diesem
Pakets stets größer als
die konfigurierte maximale Größe der Erweiterungskopffeldliste
IP_EXTD des Dekomprimierers 301.
-
Wenn
der Dekomprimierer 301, der sich jetzt in dem R-Modus und
in dem D_TRANS-Parameterzustand "P" befindet, das UOR-2-
oder IR-DYN-Paket empfängt,
sendet er keine Bestätigung,
wie im Schritt S205 von 4 gezeigt. Diese Prozedur wird fortgesetzt,
bis ein Paket N mit einer Erweiterungskopffeldliste einer Größe kleiner
oder gleich der konfigurierten maximalen Größe der Erweiterungskopffeldliste
IP_EXTD bei dem Komprimierer 201 empfangen und zu dem Dekomprimierer 301 weitergeleitet
wurde. Im Ansprechen auf den Empfang dieses Pakets mit einer erlaubten
Größe des Erweiterungskopffeldes
erzeugt der Dekomprimierer 301 eine Bestätigung ACK
und der Komprimierer 201 setzt den CTRANS-Parameter auf
den Zustand "D" und verwendet die
Liste in dem Paket N als Referenzliste für die zukünftige Komprimierung.
-
Falls
der Dekomprimierer 301 ein Paket mit einer Erweiterungskopffeldliste
größer als
die konfigurierte maximale Größe IP_EXTD
aber ohne einen Erzeugungsidentifikator in der Erweiterungskopffeldliste
zur Dekomprimierung empfängt,
wird kein Übergang
in den R-Modus initiiert. Dies kann auftreten, wenn die empfangene
Listengröße größer als
die konfigurierte maximale Größe IP_EXTD
an dem Dekomprimierer 301 und auch größer als die konfigurierte maximale
Größe IP_EXTC
ist.
-
Tritt
ein Overflow eines am Komprimierer 201 definierten gleitenden
Fensters (Sliding Window) auf, so kann er alle Elemente in dem gleitenden Fenster
beibehalten und kann ein R1-*-Paket unter Verwendung der aktuellen
Referenzliste senden. Als Alternative kann das älteste Element aus dem gleitenden
Fenster entfernt und ein Paket mit CRC eingefügt werden. Wird kein Feedback
empfangen, was bedeutet, dass die Pakete in dem gleitenden Fenster nicht
als Referenzliste verwendet werden können, so kann die aktuelle
Referenzliste immer noch zur Komprimierung verwendet werden.
-
Es
wird angemerkt, dass die vorliegende Erfindung nicht auf das obige
bevorzugte Ausführungsbeispiel
beschränkt
ist, sondern in jeder bestätigten Paketdatenübertragungsverbindung
implementiert werden kann, wo Erweiterungskopffelder variabler Größe verwendet
werden. Das bevorzugte Ausführungsbeispiel
kann daher innerhalb des Umfangs der beigefügten Ansprüche variieren.