-
HINTERGRUND DER ERFINDUNG
-
Gebiet der Erfindung
-
Die
vorliegende Erfindung betrifft schnelle Initialisierung der Komprimierung
von Paketköpfen
des Internet-Protokolls.
-
Beschreibung des Stands
der Technik
-
Aufgrund
des enormen Erfolgs des Internets hat es sich zu einer anspruchsvollen
Aufgabe entwickelt, von den Internet-Protokollen (IP) über alle
Arten von Netzstrecken Gebrauch zu machen. IP bezieht sich für gewöhnlich auf
zahlreiche Paketvermittlungsprotokolle, wie IPv4 (Internet-Protokoll
Version 4), IPv6 (Internet-Protokoll Version 6), UDP (User Datagramm
Protocol, Benutzer-Datagrammprotokoll), UDP-Lite, TCP (Transport
Cantrol Protocol, Transportsteuerungsprotokoll), RTP (Real-Time
Protocol, Echtzeitprotokoll) usw. Ein IP-Paket setzt sich für gewöhnlich aus
Nutzdaten (Payload) von Informationen zusammen, die sequentiell
in einem oder mehreren IP-Protokollen eingekapselt sind. Es wird
jetzt auf die Zeichnungen Bezug genommen, in denen 1 ein beispielhaftes
IP-Paket 100 zeigt, das von Nutzdaten 100, einem
RTP-Paketkopf 140, einem UDP-Paketkopf 130 und
einem IPv4-Paketkopf 120 gebildet wird. Das IP-Paket 100 wird
als ein IPv4/UDP/RTP-Paket bezeichnet. Der Einfachheit halber werden
die Paketköpfe
(Header) 120, 130 und 140 für gewöhnlich gemeinsam
als IP-Paketköpfe 150 bezeichnet.
Es versteht sich, dass andere Sätze und
Teilsätze
von IP-Protokollen,
die jeweils andere Paketkopfkonfigurationen aufweisen, zum Bilden
des IP-Pakets 100 und der IP-Paketköpfe 150 verwendet werden
können.
Jeder Paketkopf 120, 130 und 140 der
IP-Paketköpfe 150 trägt spezifische
Informationen über
das IP-Paket 100, wobei diese Informationen von dem Ziel
des Pakets 100 zum Interpretieren der Nutzdaten 110 verwendet
werden.
-
Die
in den IP-Paketköpfen
getragenen Informationen können
den Ursprung und das Ziel des IP-Pakets 100, zugehörige Dienstgüteinformationen, eine
Sequenznummer, Prüfsummeninformationen zur
Integrität
der Nutzdaten usw. enthalten. Ein Nachteil des IP ist die beträchtliche
Größe der IP-Paketköpfe. Es
ist keine einfache Aufgabe, vom IP über Schmallbandnetzstrecken,
wie beispielsweise Mobilfunkstrecken, Gebrauch zu machen. Als ein
Beispiel kann die Verwendung der IP-Protokolle für gewöhnliche Sprachdaten (z. B.
Voiceover-IP bzw. VoIP unter Verwendung von IPv4/UPD/RTP oder IPv6/UPD/RTP)
einen Verlust von bis zu 70 % der Bandbreitenkapazität einer
gegebenen Netzstrecke ausmachen.
-
Der
Ausdruck „Headerkomprimierung" (Header Compression,
HC) umfasst die Technik des Minimierens der erforderlichen Bandbreite,
die von den IP-Paketköpfen
eingesetzt wird. Sie wird für
gewöhnlich
auf einer Pro-Hop-Basis über Punkt-zu-Punkt-Netzstrecken
durchgeführt.
Headerkomprimierungstechniken haben im Allgemeinen eine mehr als
zehn Jahre alte Geschichte in der Internetgemeinschaft. Mehrere,
häufig
eingesetzte Techniken sind in den folgenden Dokumenten beschrieben:
RFC 1144[VJ], RFC 2507[IPHC] und RFC 2508[CRTP]. Headerkomprimierung
macht sich die Tatsache zunutze, dass einige Felder in dem IP-Paketkopf
in einem Strom von Paketen, die zu einem gegebenen Paketfluss gehören, sich
nicht ändern (statisch
sind) oder sich um kleine oder vorhersehbare Werte ändern. Headerkomprimierungstechniken machen
von diesen Charakteristika Gebrauch und senden statische Informationen
nur zu Anfang, während
sich ändernde
Felder mit ihren Absolutwerten oder als Unterschiede von Paket zu
Pakte gesendet werden. Vollständig
willkürliche
Informationen müssen
ohne jegliche Komprimierung gesendet werden. Die anspruchsvolle Aufgabe
einer beliebigigen Headerkomprimierungstechnik besteht darin, beide
Enden der Netzstrecke zueinander im Einklang zu halten. Zu diesem
Zweck machen ein Kompressor an einem Ende und ein Dekompressor an
dem anderen Ende jeweils von einem Dekomprimierungskontext Gebrauch.
Die Verwendung der Dekomprimierungskontexte bezweckt, die Größe der IP-Paketköpfe so klein
wie möglich
zu halten. Dazu verwaltet jedes Ende alle Informationen, die dazu
erforderlich sind, einige Felder (vollständig oder teilweise) aus den IP-Paketköpfen an
dem Kompressor-Ende zu eliminieren und die IP-Paketköpfe an dem
Dekompressor-Ende neu aufzubauen.
-
Headerkomprimierungstechniken
sind folglich ein wichtiger Bestandteil zum Durchführen von Diensten
wie VoIP over Wireless (VoIPW), eine wirtschaftlich praktikable
Alternative zur leitungsvermittelten Sprache. Zu diesem Zweck sind
von der Robust Header Compression (ROHC) Working Group der Internet
Engineering Task Force (IETF) einige Headerkomprimierungstechniken
entwickelt worden. RFC 3095[ROHC] beschreibt einen erweiterungsfähigen Rahmen,
für den
Profile zur Komprimierung von verschiedenen Vernetzungsprotokollen
definiert werden können.
Das folgende Beispiel nimmt die in der ROHC definierte Headerkomprimierungstechnik als
ein Beispiel. In einem derartigen Fall enthalten die Dekomprimierungskontexte
sowohl des Kompressors als auch des Dekompressors relevante Informationen über frühere Pakete
und verwalten diese Informationen, wobei diese Informationen zum
Komprimieren und Dekomprimieren anschließender Pakete verwendet werden.
Genauer gesagt führt
die ROHC Folgendes aus: „Der
Kontext des Kompressors ist der Zustand, den er zum Komprimieren
eines Paketkopfs verwendet. Der Kontext des Dekompressors ist der
Zustand, den er zum Dekomprimieren eines Paketkopfs verwendet. Einer
dieser beiden oder die beiden in Kombination werden für gewöhnlich als „Kontext" bezeichnet, wenn
klar ist, welcher vorgesehen ist. Der Kontext enthält relevante
Informationen von vorherigen Paketköpfen in dem Paketstrom, wie
statische Felder und mögliche
Bezugswerte zur Dekomprimierung. Darüber hinaus sind zusätzliche
Informationen, die den Paketstrom [oder – fluss] beschreiben, ebenfalls
Teil des Kontexts, beispielsweise Informationen darüber, wie
sich das IP-Kennungs-Feld ändert und
das typische Zwischenpaket an Sequenznummern oder Zeitstempeln zunimmt."
-
Um
korrekt arbeiten zu können,
erfordert jede Headerkomprimierungstechnik eine Initialisierungsphase,
während
der der Kompressor und der Dekompressor ihren jeweiligen Dekomprimierungskontext
aufbauen. Diese Phase wird für
gewöhnlich als
die Kontextinitialisierungsphase bezeichnet. Sie bedingt für gewöhnlich,
dass der Kompressor mit einem Zustand geringer Komprimierung beginnt.
Anfangs enthalten die übertragenen
Pakete die Informationen, die zum Initialisieren mindestens des
statischen und möglicherweise
des dynamischen Teils des Dekomprimierungskontexts erforderlich
sind. Der Kompressor muss dann ausreichend Zuversicht haben, dass
der Dekompressor den korrekten Kontext hat, bevor ein Übergang
auf ein höheres
Komprimierungsverhältnis
erfolgt. Diese Zuversicht kann unter Verwendung von detailliertem
Feedback von dem Dekompressor an den Kompressor oder durch wiederholtes
Senden einer Reihe von Kontextinitialisierungspaketen für ein ausreichend
großes
Intervall erreicht werden. Die Verwendung von detailliertem Feedback
bedingt mindestens eine RTT-Zeitspanne (RTT = Round-Trip Time, Rundreisezeit),
bevor Zuversicht erlangt werden kann. Die Verwendung einer vorbestimmten
Anzahl von Paketen kann Zuversicht in weniger als einer RTT-Zeitspanne erzielen,
kann jedoch nicht unumschränkt
gewährleisten,
dass der Dekompressor den korrekten Kontext hat, sondern nicht mehr
als auf optimistische Weise erwarten, mit einem hohen Prozentsatz
erfolgreich zu sein. Das auf einer gegebenen Strecke maximal erzielbare
Komprimierungsverhältnis
hängt in
hohem Maße
von der darauf verwendeten Headerkomprimierungstechnik ab. Es dauert
jedoch mehrere Vertrauens/Übergangsphasen,
bevor das maximale Komprimierungsverhältnis einer gegebenen Komprimierungstechnik erreicht
wird.
-
Die
vorliegenden Lösungen
verursachen Probleme in Situationen, in denen ein hohes Komprimierungsverhältnis innerhalb
eines kurzen Zeitraums erreicht werden muss. Wenn auch die Kontextinitialisierungsphase
erforderlich ist, um sicherzustellen, dass eine höhere Komprimierungseffizienz
erzielt werden kann, impliziert sie eine gewisse Verzögerung,
für die
die Komprimierungseffizienz bei weitem nicht optimal ist. Im Beispiel
von VoIP-Flüssen über drahtlose
Datenstrecken mit sehr schmaler Bandbreite wirkt sich eine solche
Verzögerung
auf die wahrgenommene Sprachqualität aus, bis eine optimale Komprimierungseffizienz
erreicht wird. Auch wenn die Auswirkung bei einem konstanten Fluss
minimal ist und von den ersten Paketen des FLusses verborgen wird,
kann sie bei einem diskontinuierlicheren Fluss signifikanter sein
und muss minimiert werden.
-
Wie
man zu schätzen
wissen wird, besteht Bedarf an einer Technik zur schnellen Initialisierung der
Komprimierung von Paketköpfen
des Internet-Protokolls. Die vorliegende Erfindung stellt eine solche
Technik bereit.
-
ZUSAMMENFASSUNG
DER ERFINDUNG
-
Eine
erste Aufgabe der vorliegenden Erfindung betrifft einen IP-Paketkopf-Dekompressor-Knoten
(IP = Internet-Protokoll)
nach Anspruch 1.
-
Eine
zweite Aufgabe der vorliegenden Erfindung betrifft ein Verfahren
zur schnellen Initialisierung der Komprimierung von IP-Paketköpfen (IP
= Internet-Protokoll)
nach Anspruch 10.
-
Eine
dritte Aufgabe der vorliegenden Erfindung betrifft einen IP-Paketkopf-Manager
(IP = Internet-Protokoll) zur schnellen Initialisierung der Komprimierung
von IP-Paketköpfen nach
Anspruch 15.
-
KURZBESCHREIBUNG
DER ZEICHNUNGEN
-
Ein
vollständigeres
Verständnis
der vorliegenden Erfindung kann durch Bezugnahme auf die folgende
ausführliche
Beschreibung in Verbindung mit den begleitenden Zeichnungen erlangt
werden, in denen:
-
1 eine
schematische Darstellung eines beispielhaften IP-Pakets (IP = Internet-Protokoll) zeigt;
-
2 eine
beispielhafte grafische Darstellung des Signalflusses und der Knotenoperation
eines Internet-Protokoll-Netzes
ist, das einen Mechanismus zur schnellen Initialisierung der Komprimierung
von IP-Paketköpfen gemäß der vorliegenden Erfindung
implementiert;
-
3 eine
grafische Darstellung des Signalflusses und der Knotenoperation
eines beispielhaften CDMA2000®-Netzes ist, das den Mechanismus zur schnellen Initialisierung
der Komprimierung von IP-Paketköpfen
(IP = Internet-Protokoll) unter Verwendung des Sitzungsinitiierungsprotokolls
implementiert;
-
4 eine
beispielhafte modulare Darstellung eines Kompressor/Dekompressor-Knotens
ist, der zum Abwickeln des Mechanismus zur schnellen Initialisierung
der Komprimierung von IP-Paketköpfen
(IP = Internet-Protokoll)
ausgestattet ist; und
-
5 eine
beispielhafte modulare Darstellung eines IP-Paketkopf-Managers (IP
= Internet-Protokoll) ist, der den Mechanismus zur schnellen Initialisierung
der Komprimierung von IP-Paketköpfen
ermöglicht.
-
AUSFÜHRLICHE
BESCHREIBUNG DER ERFINDUNG
-
Die
vorliegende Erfindung zielt darauf ab, dem Kompressor und dem Dekompressor
zu ermöglichen,
die Kontextinitialisierungsphase effizienter durchzuführen. Wie
oben umrissen, ist es wünschenswert,
eine Lösung
zu finden, die die Headerkomprimierungseffizienz in einem System
weiter optimiert, bei dem die Verzögerung zum optimalen Komprimierungsverhältnis minimiert
werden muss und bei dem die Bandbreite sehr begrenzt ist. Einer der
erfinderischen Mechanismen besteht darin, Informationen, die bereits
beiden Enden einer Netzstrecke bekannt sind, während der Kontextinitialisierungsphase
wiederzuverwenden.
-
Ein
Dekomprimierungskontext weist für
gewöhnlich
zwei Komponenten auf, bei denen es sich um einen statischen Teil
und einen dynamischen Teil handelt. Beide Teile müssen initialisiert
werden, bevor sie von einem gegebenen Paketkopf-Dekompressor zum
Dekomprimieren von IP-Paketköpfen
aus einem Paketfluss, mit dem er assoziiert ist, verwendet werden.
Der statische Teil steht mit Informationen in Zusammenhang, die
sich für
die Laufzeit des assoziierten Paketflusses nicht ändern. Desgleichen
steht der dynamische Teil mit Informationen in Zusammenhang, die
sich für
die Laufzeit des assoziierten Paketflusses ändern können. Die Änderungen in dem dynamischen
Teil sind für
gewöhnlich
vorhersehbar. Jedes Ende, das den Paketfluss behandelt, muss einen Paketkopf-Dekompressor
zum Dekomprimieren von IP-Paketköpfen
aus dem Paketfluss aufweisen. Der Dekomprimierungskontext ist mit
dem Paketfluss an dem Paketkopf-Dekompressor-Ende assoziiert. Anders
ausgedrückt
weist jeder Paketkopf-Dekompressor
an jedem Ende einen damit assoziierten Dekomprimierungskontext auf.
-
Eine
erste Ausführungsform
der Lösung schlägt vor,
einige Informationen von einem oder mehreren früheren Strömen von IP-Paketen, die zwischen
dem sendenden und dem empfangenden Ende ausgetauscht wurden, wiederzuverwenden. Die
früheren
Ströme
von IP-Paketen können
von Paketkopf-Dekompressoren zum Initialisieren ihrer jeweiligen
Dekomprimierungskontexte verwendet werden. Dieser Mechanismus macht
sich die Tatsache zunutze, dass andere Abläufe (z. B. Registrierung auf dem
Netz, Verbindungsaufbau usw.) vor dem Senden eines ersten Pakets
in einer verzögerungsempfindlichen
Sitzung erfolgen. Dies ist von besonderem Interesse für Anwendungen
und Systeme, die sicherstellen können,
dass beide Paketkopf-Dekompressoren auf in den IP-Paketköpfen oder
der Nutzdaten (Payload) des früheren
Stroms von IP-Paketen enthaltene Informationen lokal zugreifen können (d.
h. ohne derartige Informationen von einem entfernten Knoten in dem
Netz anzufordern).
-
2 stellt
eine beispielhafte schematische Darstellung eines IP-Netzes (IP
= Internet-Protokoll) 200 bildlich dar, das den Mechanismus
zur schnellen Initialisierung der Dekomprimierung von IP-Paketköpfen der
vorliegenden Erfindung implementiert. 2 zeigt
einen Ursprungsknoten 210, einen Zugangsgateway 222,
einen Proxydienstknoten 224 und einen Zielknoten 230.
Der Ursprung 210 und der Zugangsgateway 222 sind über eine
komprimierte Datenstrecke 225 verbunden. Die komprimierte
Datenstrecke 225 sollte minimal und vorzugsweise mit komprimierten
IP-Paketköpfen
verwendet werden. Der Zugangsgateway 222 ist mit dem Proxydienstknoten 224 verbunden.
Sowohl der Zugangsgateway 22 als auch der Proxydienstknoten 224 befinden
sich in einer einzigen Domäne,
was ihnen ermöglicht,
Informationen bei einer hohen Bitrate auszutauschen. Sie können gemeinsam
in einem einzigen Netzknoten (nicht gezeigt) angeordnet sein oder über eine Datenstrecke,
die das IP unterstützt
(nicht gezeigt), verbunden sein. Der Proxydienstknoten 224 wiederum
ist über
eine andere Datenstrecke, die das IP unterstützt (nicht gezeigt), mit dem
Ziel 230 verbunden. In dem gegenwärtigen Beispiel werden vorausgehende
Paketflüsse 240a, 240b und 240c jeweils
zwischen dem Ursprung 210, dem Zugangsgateway 222,
dem Proxydienstknoten 224 und dem Ziel 230 ausgetauscht.
Die vorausgehenden Paketflüsse 240a, 240b und 240c können für verschiedene
Zwecke eingesetzt werden. 2 zeigt
drei vorausgehende Paketflüsse 240a, 240b und 240c zwischen dem
Ursprung 210 und dem Ziel 230. Es versteht sich
jedoch, dass eine beliebige Kombination von vorausgehenden Paketflüssen zwischen
dem Ursprung 210 und dem Ziel 230 stattfinden
kann. Zum Beispiel könnten
nur die vorausgehenden Paketflüsse 240a und 240b oder
ein einziger vorausgehender Paketfluss (nicht gezeigt) zwischen
dem Ursprung 210 und dem Ziel 230 verwendet werden.
Beispiele von vorausgehenden Paketflüssen 240a, 240b und 240c umfassen
einen zuvor komprimierten Paketfluss zwischen dem Ursprung 210 und
dem Ziel 230 (z. B. ein vorheriger VoIP-Anruf), Zeichengabe
zum Aufbau einer Sitzung (z. B. einer SIP-Sitzung, einer allgemeinen
Paketdatensitzung), die Installation eines Traffic Flow Template
(TFT), die Initialisierung des Paketdatenprotokolls (PDP) (oder
die Aktivierung von PDP-Kontext), Parameter der Initialisierung
des Löschens
von Paketköpfen
usw. Die vorausgehenden Paketflüsse 240a, 240b und 240c können verschiedene
Arten von Informationen tragen, sollten jedoch stets aus mindestens
einem IP-Paket (nicht gezeigt) mit relevanten IP-Paketköpfen (nicht
gezeigt) bestehen. Die verwendeten IP-Paketköpfe hängen von den verwendeten spezifischen
IP-Protokollen ab. Der Zugangsgateway 222 befindet sich
auf dem Weg der vorausgehenden Paketflüsse 240a und 240b.
Es ist daher dem Zugangsgateway 220 möglich, die in den IP-Paketköpfen oder
der Nutzdaten enthaltenen Informationen aus den vorausgehenden Paketflüssen 240a und 240b zu
stapeln. Der Ursprung 210 stapelt ebenfalls in dem vorausgehenden
Paketfluss 240a enthaltene Informationen. Die gestapelten
Informationen können
zu einem späteren
Zeitpunkt in dem Mechanismus zur Initialisierung von Dekomprimierungskontext
verwendet werden. Sie umfassen Informationen, die mit dem statischen
Teil eines Dekomprimierungskontexts in Zusammenhang stehen, wie IP-Adressen
sowohl des Ursprungs 210 als auch des Ziels 230,
verwendete Protokolle, Portnummern, Dienstgüte (Quality of Service, QoS),
Diensttyp (Type of Service, ToS) usw.
-
Nach
den vorausgehenden Paketflüssen 240a, 240b und 240c ist
eine Sitzung zwischen dem Ursprung 210 und dem Ziel 230 im
Begriff, aufgebaut zu werden, der Aufbau ist jedoch noch nicht abgeschlossen.
Der Ursprung 210, der Zugangsgateway 222, der
Proxydienstknoten 224 und das Ziel 230 wirken
alle am Aufbau der Sitzung mit. In dem in 2 gezeigten
Beispiel hat der Aufbau der Sitzung in den vorausgehenden Paketflüssen 240a, 240b und 240c begonnen.
Zu diesem Zeitpunkt hat der Zugangsgateway 222 die Informationen,
die zum Initialisieren des statischen Teils seines Dekomprimierungskontexts
(Schritt 244) erforderlich sind, der während der Sitzung zwischen
dem Ursprung 210 und dem Ziel 230 verwendet werden
wird. Der Schritt 244 des Initialisierens des statischen
Teils des Dekomprimierungskontexts kann gegebenenfalls von einer
Kontextinitialisierungs-Nachricht 242 eingeleitet werden, die
von dem Ursprung 210 an den Zugangsgateway 222 gesendet
wird. Um Schritt 244 durchzuführen, kann der Zugangsgateway 222 die
gestapelten Informationen der IP-Paketköpfe oder der Nutzdaten aus den
vorausgehenden Paketflüssen 240a und 240b verwenden.
Wenn die gestapelten Informationen nicht ausreichen, können der
Zugangsgateway 222 und der Ursprung 210 einander
kontaktieren (nicht gezeigt), um die Initialisierung des statischen
Teils abzuschließen.
Des Weiteren kann der Zugangsgateway 222 andere Knoten
(nicht gezeigt) in dem IP-Netz 200 zu demselben Zweck kontaktieren.
Zum Beispiel kann der Zugangsgateway 222 den statischen
Teil seines Dekomprimierungskontexts durch Kontaktieren des Proxydienstknotens 224 abschließen.
-
Nachdem
die Sitzung zwischen dem Ursprung 210 und dem Ziel 230 aufgebaut
ist 246, können
der Ursprung 210 und das Ziel 230 das Senden von
mit der Sitzung in Zusammenhang stehenden Nutzdateninformationen
beginnen. 2 zeigt das Beispiel des Ziels,
das ein mit der Sitzung in Zusammenhang stehendes erstes IP-Paket 248 über den Zugangsgateway 222 in
Richtung des Ursprungs 210 sendet. Wenn das erste IP-Paket 250 den
Zugangsgateway 222 erreicht, können beide Teile des Dekomprimierungskontexts
des Ursprungs 210 initialisiert werden. Der Zugangsgateway 222 sendet
zu diesem Zweck eine Kontextinitialisierungs-Nachricht 252 mit
relevanten Informationen an den Ursprung 210. Der Ursprung 210 führt dann
Schritt 254 des Initialisierens seines Dekomprimierungskontexts durch.
Um Schritt 254 durchzuführen,
kann der Ursprung 210 die gestapelten Informationen der
IP-Paketköpfe
oder der Nutzdaten aus dem vorausgehenden Paketfluss 240a verwenden.
Wenn die gestapelten Informationen nicht ausreichen, können der
Zugangsgateway 222 und der Ursprung 210 einander kontaktieren
(nicht gezeigt), um die Initialisierung des statischen und des dynamischen
Teils abzuschließen.
Das Paket 250, die Nachricht 252 und der Schritt 254 sind
in 2 als eine Reihe von Ereignissen 256 gezeigt.
-
Nachdem
die Sitzung aufgebaut ist 246, ist die MS bereit, das erste
IP-Paket der Sitzung zu senden (Schritt 256). Vor diesem
ersten IP-Paket sendet die MS 210 eine Kontextinitialisierungs-Nachricht 258 an
den Zugangsgateway 222, wodurch Schritt 260 des
Initialisierens des dynamischen Teils des Dekomprimierungskontexts
davon ausgelöst
wird. Der Zugangsgateway 222 führt Schritt 260 durch,
indem er die in der Kontextinitialisierungs-Nachricht 258 enthaltenen
Informationen verwendet. Der Zugangsgateway 222 und der
Ursprung 210 können
weiterhin einander kontaktieren (nicht gezeigt), um die Initialisierung
des dynamischen Teils abzuschließen. Der Schritt 256,
die Nachricht 258 und der Schritt 260 sind in 2 als
eine Reihe von Ereignissen 262 gezeigt. Die Reihe von Ereignissen 256 und
die Reihe von Ereignissen 262 sind aufeinander folgend
gezeigt. Die beiden Reihen 256 und 262 können jedoch unabhängig voneinander
sein und zu einem beliebigen Zeitpunkt, nachdem die Sitzung aufgebaut
ist 246, stattfinden.
-
Nach
Abschluss der Schritte 244, 254 und 260 des
Initialisierens der Dekomprimierungskontexte können der Ursprung 210 und
der Zugangsgateway 222 beginnen, einen Paketfluss mit komprimierten
IP-Paketköpfen 264 untereinander
auszutauschen, wobei sie demnach ihre jeweiligen Dekomprimierungskontexte
zum Dekomprimieren der IP-Pakete davon verwenden. Es versteht sich,
dass IP-Pakete (nicht gezeigt), die von dem Ursprung 210 in Richtung
des Ziels 230 ausgegeben werden, an dem Ursprung 210 komprimiert,
in dem Paketfluss mit komprimierten IP-Paketköpfen 264 gesendet,
an dem Zugangsgateway 222 unter Verwendung des Dekomprimierungskontexts
des Zugangsgateways 222 dekomprimiert und in einem Paketfluss 266 in Richtung
des Ziels 230 gesendet werden. Auf ähnliche Weise werden IP-Pakete
(nicht gezeigt), die von dem Ziel 230 in Richtung des Ursprungs 210 ausgegeben
werden, in dem Paketfluss 266 gesendet, an dem Zugangsgateway 222 komprimiert
und in dem Paketfluss mit komprimierten IP-Paketköpfen 264 gesendet.
Bei Empfang der von dem Ziel 230 ausgegebenen IP-Pakete
kann der Ursprung 210 seinen Dekomprimierungskontext zum
Dekomprimieren der IP-Pakete
verwenden, dies kann jedoch je nach dem Inhalt der IP-Pakete nicht
erforderlich sein.
-
2 zeigt
den Zugangsgateway 222 und den Proxydienstknoten 224.
In spezifischeren Beispielen könnten
sie jeweils in einen Paketdaten bedienenden Knoten (Packet Data
Serving Node, PDSN) oder Gateway-GPRS-Unterstützungsknoten (GGSN,
Gateway GPRS Support Node; GPRS = General Packet Radio Service,
allgemeiner paketorientierter Funkdienst) und einen SIP-Proxy oder
einen P-CSCF (Proxy-Call State Control Function, Proxy-Rufzustandskontrollfunktion)
aufgenommen sein. Des Weiteren zeigt 2 nur eine
komprimierte Datenstrecke 225. Es versteht sich jedoch,
dass mehrere Netzkonfigurationen den Ursprung 210 und den Zugangsgateway 222 verbinden
können,
ohne vom Gedanken der vorliegenden Erfindung abzuweichen. Zum Beispiel kann
der Ursprung 210 über
eine Luftschnittstelle mit einer Basisstation (nicht gezeigt) verbunden
sein, wobei die Basisstation weiterhin durch eine Erdverbindung
mit dem Zugangsgateway 222 verbunden ist. Auf dieselbe
Art und Weise können mehrere
Knoten (nicht gezeigt) in dem Weg zwischen dem Zugangsgateway 222 und
dem Ziel 230 angeordnet werden, solange der Paketfluss 266 dazwischen
geroutet werden kann.
-
Eine
zweite Ausführungsform
der Lösung wird
hiermit mit besonderer Bezugnahme auf das Sitzungsinitiierungsprotokoll
(SIP) in einem Telekommunikationsnetz, das den CDMA2000®-Standard einsetzt,
beschrieben. Der CDMA2000©-Standard ist auch als
Mehrträger-IMT-CDMA
oder IS-95 bekannt. Es handelt sich um eine CDMA-Version (CDMA =
Code-Division Multiple Access, Codemultiplexzugriff) des IMT-2000-Standards, der von
der International Telecommunication Union (ITU) entwickelt wurde. SIP
wird von der Internet Engineering Task Force (IETF) in den Requests
for Comments (RFC) Nummer 2543 und 3252, [RFC 2543] und [RFC 3252],
definiert, die hierin durch Bezugnahme aufgenommen sind. Es wird
in verschiedenen Arten von Telekommunikationsnetzen zum Aufbauen
einer Sitzung zwischen einem ersten und einem zweiten Knoten verwendet.
Das SIP spezifiziert Anforderungen und Antworten, die in dem Netz
zum Verwalten der Sitzung auszutauschen sind (z. B. INVITE (Einladen)
zum Starten einer neuen Sitzung und OK zum Akzeptieren einer Einladung
in die neue Sitzung). SIP spezifiziert weiterhin Charakteristika
der Sitzung durch eine Reihe von SDP-Parametern (SDP = Session Description
Protocol, Sitzungsbeschreibungsprotokoll). Typische spezifizierte
SDP-Parameter, die das SIP einsetzen, umfassen die Medienart und
das Medienformat, die in der Sitzung erlaubt sind, sowie Sitzungsinformationen,
wie eine Sitzungskennungsnummer, eine Netzart, eine Adressart und
verschiedene Adresselemente. Der Wert jedes SDP-Parameters ändert sich je nach der Art
von Verkehr, die von der Sitzung abzuwickeln ist. Es ist folglich
wichtig, dass sich alle Zwischenknoten, die an der Sitzung beteiligt
sind, auf die während
der Sitzung verwendeten SDP-Parameter einigen. Im Rahmen des vorliegenden
Beispiels beziehen sich die an der Sitzung beteiligten Zwischenknoten
auf alle Netzelemente auf Wegen zwischen allen Enden der Sitzung.
-
3 ist
eine grafische Darstellung des Signalflusses und der Knotenoperation
eines beispielhaften CDMA2000®-Netzes 300,
das den Mechanismus zur schnellen Initialisierung der Komprimierung von
IP-Paketköpfen
unter Verwendung des SIP implementiert. 3 zeigt
eine Mobilstation (MS) 310, die über ein Funkzugriffsnetz (Radio
Access Network, RAN) 312 mit einem Paketdaten bedienenden Knoten
(Packet Data Serving Node, PDSN) 314 verbunden ist. 3 zeigt
weiterhin einen SIP-Proxy 318 und einen Korrespondentenknoten
(Correspondent Node, CN) 320. Das RAN 312 ist
mit dem PDSN 314 an die MS 310 gekoppelt. Der
PDSN 314 verwaltet die Verbindung der MS 310 mit
dem Netz 300. Der SIP-Proxy 318 überwacht
alle SIP-bezogenen Austauschvorgänge
in dem Netz 300. Er ermöglicht, dass
eine Sitzung zwischen der MS 310 und dem CN 320,
der sich in dem Netz 300 befindet, geöffnet werden kann. Obgleich
der CN 320 in dem Netz 300 gezeigt ist, kann er
sich in einem entfernten Netz (nicht gezeigt) befinden, ohne sich
auf die Lehren der vorliegenden Erfindung auszuwirken.
-
Als
einen ersten Schritt baut die MS 310 eine PPP-Sitzung (PPP = Punkt-zu-Punkt-Protokoll) 322 mit
dem PDSN 314 auf. Während
des Aufbauens der PPP-Sitzung 322 wird der MS 310 eine
Hauptdienstinstanz zugewiesen, die der MS 310 einen Kommunikationskanal
zum Senden und Empfangen von Steuernachrichten und Benutzerdaten
bereitstellt. Die Hauptdienstinstanz ist im CDMA2000® als S033
bekannt. Die S033-Hauptdienstinstanz ermöglicht, dass ein Funkverbindungsprotokoll
(Radio Link Protocol, RLP) von der MS 310 in Richtung des PDSN 314 verwendet
werden kann. Zum Beispiel wird das RLP mit einem CDMA2000®-Verkehrskanal zum
Unterstützen
von CDMA-Datendiensten verwendet. Das RLP ist für das Erfassen von Frames, die
mit Fehlern empfangen werden, und für das Durchführen von Übertragungen
verantwortlich. Die MS 310 zeigt dem PDSN 314 während des
Aufbaus der PPP-Sitzung 322 außerdem ihre Headerkomprimierungsfähigkeiten
an (z. B. ROHC, LLAROHC, VJHC).
-
Der
PDSN 314 kann dann der MS 310 die Berechtigung
bestätigen,
bevor sie im Prozess voranschreitet; dies geht jedoch über den
Schutzumfang der vorliegenden Erfindung hinaus.
-
Um
eine SIP-Sitzung mit dem CN 320 zu öffnen, sendet die MS 310 dann
diesem eine „SIP
Invite"-Nachricht
(Invite = Einladung) 328. Die „SIP Invite"-Nachricht 328 enthält alle
zum Routen von dem SIP-Proxy 318 in Richtung des CN 320 erforderlichen Informationen.
Der CN 320 antwortet auf die „SIP Invite"-Nachricht 328 mit
einer „SIP: 183 Session
Progress"-Nachricht
(Session Progress = Sitzungsverlauf) 330. Wiederum enthält die „SIP: 183 Session Progress"-Nachricht 330 alle
zum Routen von dem SIP-Proxy 318 in Richtung der MS 310 erforderlichen Informationen.
Die „SIP: 183 Session
Progress"-Nachricht 330 enthält weiterhin
SDP-Parameter zur Verwendung während
der SIP-Sitzung. Der PDSN 314 kann beim Routen der „SIP: 183 Session Progress"-Nachricht 330 den statischen
Teil seines Dekomprimierungskontexts initialisieren (Schritt 332).
Wenn die vorhandenen Informationen dafür nicht ausreichen, können der
PDSN 314 und die MS 310 einander kontaktieren,
um die Initialisierung des statischen Teils des Dekomprimierungskontexts
abzuschließen.
Des Weiteren kann der PDSN 314 andere Knoten (nicht gezeigt)
in dem Netz 300 zu demselben Zweck kontaktieren. Zum Beispiel
kann er in dieser Hinsicht den SIP-Proxy 318 kontaktieren.
In einer bevorzugten Ausführungsform
der vorliegenden Erfindung kontaktiert der PDSN 314 die
MS 310 nur, wenn die erforderlichen Informationen nicht
in beliebigen anderen Knoten gefunden werden kann, auf die die Komprimierung
von IP-Paketköpfen nicht
angewendet werden soll.
-
Parallel
zum Senden der „SIP
Invite"-Nachricht 328 bestätigt die
MS 310 außerdem
deren benötigten
Ressourcen mit dem RAN 312 auf korrekte normierte Weise
in dem CDMA2000®-Netz 300.
Wiederum gehen die anverwandten Schritte und Nachrichten 334–340 über den
Schutzumfang der vorliegenden Erfindung hinaus.
-
Bei
Empfang der „SIP: 183 Session
Progress"-Nachricht
330 gibt die MS 310 eine Reihe von SIP-bezogenen Nachrichten 342, 344, 350–360 aus, um
die SIP-Sitzung mit dem CN 320 zu aktualisieren und aufrechtzuerhalten.
Parallel zu der Reihe von SIP-bezogenen Nachrichten kann die MS 310 die
Installation des Traffic Flow Template mit dem PDSN 314 durch
ein TFT-Informationselement
(TFT IE) (Nachrichten 346, 348) bestätigen. Wiederum
fallen der Inhalt derartiger SIP-bezogener
Nachrichten und TFT IE-Nachrichten außerhalb des Schutzumfangs der
vorliegenden Erfindung und sind als beispielhafte Vorgehensweisen
gezeigt.
-
Bei
Abschluss des Aufbaus der SIP-Sitzung werden die substantiellen
Informationen der SIP-Sitzung zwischen der MS 310 und dem
CN 320 in beiden Richtungen ausgetauscht. Zu diesem Zweck wird
ein Paketfluss 364 von alten IP-Paketen zwischen dem CN 320 und
dem PDSN 314 ausgetauscht. In dieser Phase hat die MS 310 genügend Informationen,
um ihren Dekomprimierungskontext zu initialisieren (Schritt 362).
Dazu verwendet die MS 310 bereits von dem PDSN 314 empfangene
Informationen, wie SDP-Parameter oder das TFT-IE. Zum Beispiel enthält das TFT-IE
Informationen, die mit einigen sich nicht ändernden Teilen der IP-Paketköpfe in Zusammenhang
stehen, wobei die Informationen wiederum zu einem Teil des Dekomprimierungskontexts
werden. Die MS 310 kann den PDSN 314 oder andere
Knoten (nicht gezeigt) in dem Netz 300 kontaktieren, um
den Schritt 362 abzuschließen. Der PDSN 314 schließt weiterhin
den dynamischen Teil seines Dekomprimierungskontexts ab (Schritt 363), indem
er lokal verfügbare
Informationen verwendet. Weiterhin wird ein Paketfluss mit komprimierten IP-Paketköpfen 366 zwischen
dem PDSN 314 und der MS 310 ausgetauscht, wodurch
ermöglicht
wird, dass die SIP-Sitzung stattfinden kann.
-
3 zeigt
ein beispielhaftes CDMA2000®-Netz.
Es versteht sich folglich, dass unter Befolgung von Standard- CDMA2000®-Vorgehensweisen
andere Knoten beteiligt sein können
und andere Schritte stattfinden können, ohne vom Gedanken der
vorliegenden Erfindung abzuweichen. Außerdem ist die Reihenfolge,
in der einige Nachrichten ausgetauscht werden und Schritte durchgeführt werden,
nur als ein Beispiel gezeigt und wirkt sich nicht auf die erfinderischen
Lehren davon aus. Darüber
hinaus könnte
eine ähnliche
Vorgehensweise in anderen Netzen, wie beispielsweise einem GPRS-Netz
(GPRS = General Packet Radio Service, allgemeiner paketorientierter
Funkdienst), mit nur geringfügigen
Unterschieden angewendet werden, solange eine Paketdatensitzung
aufgebaut wird. Derartige geringfügige Unterschiede können die
Verwendung eines anderen Protokolls zum Initialisieren der Sitzung
umfassen (z. B. H.323- oder GPRS-spezifische Zeichengabe anstelle
des SIP). Desgleichen sind die in 3 gezeigten
Netzelemente 310–320 in Übereinstimmung
mit dem CDMA2000® benannt und
können
sich ändern,
wenn sich die Netzart ändert.
Ferner könnte
der PDSN 314 in dem GPRS-Beispiel ein Gateway-GPRS-Unterstützungsknoten (GGSN,
Gateway GPRS Support Node) oder ein Dienst-GPRS-Unterstützungsknoten
(Service GPRS Support Node, SGSN) sein.
-
4 ist
eine beispielhafte modulare Darstellung eines Kompressor/Dekompressor-Knotens 400,
der zum Abwickeln des Mechanismus zur schnellen Initialisierung
der Komprimierung von IP-Paketköpfen
(IP = Internet-Protokoll)
ausgestattet ist. Der Kompressor/Dekompressor-Knoten 400 weist
ein Kommunikationsmodul 410, ein Modul zur Initialisierung
von Dekomprimierungskontext 420, ein Modul zur Komprimierung
von IP-Paketköpfen 430 und
ein Anwendungsmodul 440 auf. Das Kommunikationsmodul 410 des
Kompressor/Dekompressor-Knotens 400 ist dazu in der Lage,
die zuvor erörterte
Netzstrecke 225 zu verwalten. Es ist weiterhin dazu in
der Lage, eine große
Auswahl von Netzprotokollen zu verwalten, wie beispielsweise die
IP-Protokolle oder die zuvor beschriebene PPP-Sitzung. Das Kommunikationsmodul ist
noch weiter dazu in der Lage, am Aufbau einer Sitzung zwischen mindestens
zwei Knoten des IP-Netzes mitzuwirken. Das Modul zur Initialisierung
von Dekomprimierungskontext 420 ist dazu in der Lage, einen
Dekomprimierungskontext zu verwalten. Der Dekomprimierungskontext
kann sich in dem Kompressor/Dekompressor-Knoten 400 oder
in einem zweiten Kompressor/Dekompressor-Knoten (nicht gezeigt)
befinden. In einem derartigen Fall würde das Modul zur Initialisierung
von Dekomprimierungskontext 420 das Kommunikationsmodul 410 zum
Kommunizieren damit verwenden. Der IP-Paketkopf-Manager 430 ist
dazu in der Lage, Informationen aus IP-Paketen, die von dem Kompressor/Dekompressor-Knoten 400 ausgegeben
wurden oder diesen durchlaufen haben, zu interpretieren und zu extrahieren.
Der IP-Paketkopf-Manager 430 ist weiterhin dazu in der
Lage, Informationen aus IP-Paketköpfen aus einem oder mehreren
IP-Paketen zu interpretieren und zu extrahieren. Er ist noch weiter
dazu in der Lage, Informationen aus mehreren der IP-Pakete zu interpretieren und
zu extrahieren, wodurch eine größere Nachricht gebildet
wird. Das Anwendungsmodul 440 ist dazu in der Lage, verschiedene
Anwendungen zu verwalten, die von dem Mechanismus zur schnellen
Initialisierung der Komprimierung von IP-Paketköpfen (IP = Internet-Protokoll)
Gebrauch machen. Beispiele derartiger Anwendungen umfassen, sind
aber nicht darauf beschränkt,
VoIP und VoIPoW. In einem typischen Beispiel verwendet der Mechanismus
zur schnellen Initialisierung der Komprimierung von IP-Paketköpfen das
Kommunikationsmodul 410 zum Austauschen von Zeichengabenachrichten
mit benachbarten Knoten, um eine SIP-Sitzung aufzubauen. Die ausgetauschten
Zeichengabenachrichten werden von dem IP-Paketkopf-Manager 430 interpretiert.
Der IP-Paketkopf-Manager 430 extrahiert dann einige Informationen
daraus und leitet sie an das Modul zur Initialisierung von Dekomprimierungskontext 420. Das
Modul zur Initialisierung von Dekomprimierungskontext 420 initialisiert
den Dekomprimierungskontext, wenn es alle dafür benötigten Informationen hat. Falls
dies nicht der Fall ist, kann das Modul zur Initialisierung von
Dekomprimierungskontext 420 über das Kommunikationsmodul 410 mindestens
einen anderen Knoten kontaktieren, bevor die Initialisierung des
Dekomprimierungskontexts abgeschlossen wird. Nach abgeschlossener
Initialisierung des Dekomprimierungskontexts kann das Anwendungsmodul
davon zum Dekomprimieren von anwendungsbezogenen Paketen, die von
benachbarten Knoten empfangen wurden oder an diese addressiert waren, Gebrauch
machen.
-
5 ist
eine beispielhafte modulare Darstellung eines IP-Paketkopf-Managers 500,
der den Mechanismus zur schnellen Initialisierung der Komprimierung
von IP-Paketköpfen (IP
= Internet-Protokoll) ermöglicht.
Das Modul zur Komprimierung von IP-Paketköpfen 500 umfasst weiterhin
einen IP-Paketkopf-Reader 510, einen IP-Paketkopf-Builder 520 und einen
Dekomprimierungskontext-Manager 530. Der IP-Paketkopf-Reader 510 ist
dazu in der Lage, Informationen aus IP-Paketen, die von dem IP-Paketkopf-Manager 500 ausgegeben
wurden oder diesen durchlaufen haben, zu interpretieren und zu extrahieren.
Er ist außerdem
dazu in der Lage, Informationen aus IP-Paketköpfen aus einem oder mehreren IP-Paketen
zu interpretieren und zu extrahieren. Der IP-Paketkopf-Reader 510 ist
weiterhin dazu in der Lage, Informationen aus mehreren der IP-Pakete zu interpretieren
und zu extrahieren, wodurch eine größere Nachricht gebildet wird.
Der IP-Paketkopf-Reader
ist außerdem
dazu in der Lage, komprimierte IP-Paketköpfe von IP-Paketen zu dekomprimieren. Der
IP-Paketkopf-Builder 520 ist
dazu in der Lage, IP-Pakete in Übereinstimmung
mit verschiedenen IP-Protokollen zu konstruieren. Er ist dazu in
der Lage, IP-Pakete mit komprimierten oder dekomprimierten IP-Paketköpfen aufzubauen.
Der Dekomprimierungskontext-Manager 530 ist dazu in der
Lage, einen Dekomprimierungskontext au verwalten, der mit dem IP-Paketkopf-Manager 500 assoziiert
ist. In einem typischen Beispiel verwendet der Mechanismus zur schnellen
Initialisierung der Komprimierung von IP-Paketköpfen (IP = Internet-Protokoll) den IP-Paketkopf-Reader 510 zum
Interpretieren von IP-Paketen, die Zeichengabenachrichten betreffen.
Der IP-Paketkopf-Reader 520 extrahiert dann einige Informationen
daraus und leitet sie an den Dekomprimierungskontext-Manager 530.
Der Dekomprimierungskontext-Manager 530 initialisiert den
Dekomprimierungskontext, wenn er alle dafür benötigten Informationen hat. Falls
dies nicht der Fall ist, kann der Dekomprimierungskontext-Manager 530 mindestens einen
anderen Knoten kontaktieren, bevor die Initialisierung des Dekomprimierungskontexts
abgeschlossen wird. Nach abgeschlossener Initialisierung des Dekomprimierungskontexts
können
der IP-Paketkopf-Builder und der IP-Paketkopf-Reader davon zum Dekomprimieren
von anwendungsbezogenen Paketen, die von benachbarten Knoten empfangen wurden
oder an diese addressiert waren, Gebrauch machen.
-
Die
erfinderischen Lehren der vorliegenden Erfindung sind mit besonderer
Bezugnahme auf zahlreiche beispielhafte Ausführungsformen beschrieben worden.
Es versteht sich jedoch, dass diese Gruppe von Ausführungsformen
nur einige wenige Beispiele der vielen vorteilhaften Anwendungen
der erfinderischen Lehren der Erfindung liefert. Im Allgemeinen schränken in
der Beschreibung der vorliegenden Anmeldung gemachte Aussagen nicht
notwendigerweise etwaige der verschiedenen beanspruchten Gesichtspunkte
der vorliegenden Erfindung ein. Darüber hinaus können manche
Aussagen auf einige erfinderische Merkmale, jedoch nicht auf andere
zutreffen. In den Zeichnungen sind gleiche oder ähnliche Elemente in den verschiedenen
Ansichten mit identischen Bezugsziffern bezeichnet und die verschiedenen,
bildlich dargestellten Elemente sind nicht notwendigerweise maßstabsgerecht
gezeichnet.