-
ALLGEMEINER STAND DER TECHNIK
-
Die
Erfindung betrifft das Definieren eines Kontextidentifikators beim
Komprimieren von Kopfdatenfeldern von Datenpaketen.
-
Das
rasche Voranschreiten der IP(Internet Protocol)-Technologie in den vergangenen Jahren hat
auch die Möglichkeiten
der Verwendung verschiedener IP-gestützter Anwendungen außerhalb der
herkömmlichen
Internet-Datenübertragung
erweitert. Insbesondere IP-gestützte
Telefonie-Anwendungen haben sich mit hohem Tempo entwickelt, wodurch
ein sich ständig
erweiternder Teil des Rufübertragungsweges
selbst in herkömmlichen
Telefonnetzen (Public Switched Telephone Network – PSTN [öffentliches
Fernsprechwählnetz]
und Integrated Services Digital Network – ISDN [Digitales Netz mit
integrierten Diensten]) und Mobilfunknetzen (Public Land Mobile
Network – PLMN
[Mobilkommunikationsnetz]) im Prinzip unter Verwendung von IP-Technologie
implementiert werden kann.
-
Insbesondere
in Mobilfunknetzen bietet die IP-Technologie zahlreiche Vorteile,
weil Mobilfunknetze zusätzlich
zu den herkömmlichen
Sprachdiensten von Mobilfunknetzen, die mittels verschiedener IP-Sprachanwendungen
angeboten werden konnten, immer mehr andere Datendienste anbieten, wie
beispielsweise Browsen im Internet, E-Mail-Dienste, Spiele usw.,
die in der Regel ganz besonders bevorzugt als paketvermittelte IP-gestützte Dienste
implementiert werden. Auf diese Weise konnten in Mobilfunksystemprotokollen
angeordnete IP-Schichten sowohl Audio-/Videodienste als auch verschiedene
Datendienste erbringen.
-
In
Mobilfunknetzen ist es besonders wichtig, die begrenzten Funkressourcen
so effizient wie möglich
zu nutzen. Das verkompliziert seinerseits die Nutzung der IP-Protokolle
in der Funkschnittstelle, weil bei IP-gestützten
Protokollen der Anteil verschiedener Kopfdatenfelder der gesendeten
Daten sehr groß ist
und der Nutzdatenanteil dementsprechend gering ist. Des Weiteren
können
die Bitfehlerrate (Bit Error Rate – BER) der Funkschnittstelle
und die kombinierte Umlaufzeit (Round Trip Time – RTT) der Uplink- und Downlink-Richtung
unter schlechten Bedingungen stark zunehmen, was bei den meisten
bekannten Kopfdatenfeldkomprimierungsverfahren zu Problemen führt. Das
hat zu der Notwendigkeit geführt,
ein für
verschiedene IP-Protokolle geeignetes Kopfdatenfeldkomprimierungsverfahren
zu entwickeln, das sich ganz besonders für die Datenübertragung über die Funkschnittstelle eignet:
eine effiziente Kopfdatenfeldkomprimierung, die jedoch auch unter
Bedingungen verwendet werden kann, in denen Bitfehlerraten und Umlaufzeiten
stark zunehmen.
-
Zu
diesem Zweck hat sich die IETF (Internet Engineering Task Force)
unlängst
mit der Standardisierung eines Kopfdatenfeldkomprimierungsverfahrens
befasst, das unter der Bezeichnung ROHC (Robust Header Compression)
bekannt ist. Ein Gedanke, der hinter der Entwicklung der ROHC steht,
ist, dass es sehr viel Redundanz zwischen den verschiedenen IP-Kopfdatenfeldern,
die für
den Datenpakettransfer verwendet werden, gibt, und zwar nicht nur
in den Datenpaketen, sondern auch zwischen ihnen. Oder anders ausgedrückt: Eine
große
Menge der Informationen in den Kopfdatenfeldern ändert sich während der
Datenpaketübertragung
nicht im Geringsten und lässt
sich daher auf einfache Weise rekonstruieren, selbst wenn sie nicht übertragen
werden. Nur bei einem kleinen Teil der Kopfdatenfelder ist es erforderlich,
dass die in ihnen enthaltenen Informationen während der Komprimierung beachtet
werden müssen.
Des Weiteren umfasst die ROHC mehrere Komprimierungsstufen, wodurch
die Effizienz der Komprimierung zunimmt, wenn ein Übergang
zu einer höheren
Stufe erfolgt. Die ROHC versucht immer, die effizienteste Komprimierung
zu verwenden, die möglich
ist, jedoch in einer solchen Weise, dass vor dem Übergang
zur nächsten
Stufe immer eine genügend
hohe Betriebszuverlässigkeit
der Stufe gewährleistet
ist. Die ROHC hat auch die typische Eigenschaft, dass sie verschiedene
Angelegenheiten, die für
die Verwendung eines Komprimierungsverfahrens von wesentlicher Bedeutung
sind, durch die untere Sicherungsschicht handhaben lässt.
-
Eine
solche Angelegenheit, die durch die untere Sicherungsschicht zwischen
einem Absender und einem Empfänger,
d. h. Komprimierer und Dekomprimierer, automatisch eingestellt wird,
ist die Definition der Länge
eines Kontextidentifikators (CID), der bei einer bestimmten Funkverbindung
verwendet wird. Der Kontextidentifikator CID dient dazu, mehrere
Paketdatenströme,
die über
dieselbe Funkverbindung übertragen
werden, voneinander zu unterscheiden. Die Länge des Kontextidentifikators
CID kann 0, 1 oder 2 Bytes (0, 8 oder 16 Bits) betragen, und der Wert
null wird verwendet, wenn die Verbindung nur einen einzigen Datenstrom
hat. Die Länge
des CID wird somit automatisch eingestellt, bevor mit der Komprimierung
der zu sendenden Daten begonnen wird, und die automatisch eingestellte
Länge des Kontextidentifikators
CID wird anschließend
sowohl in der Uplink- als auch in der Downlink-Richtung verwendet.
-
Ein
Problem bei der oben beschriebenen Anordnung ist die Unflexibilität der Länge des
Kontextidentifikators CID. Da die Länge des CID vor dem Beginn
der Komprimierung automatisch eingestellt wurde, kann ihr Wert nur
durch eine erneute automatische Einstellung zwischen Komprimierer
and Dekomprimierer geändert
werden, wobei in diesem Fall die Komprimierung angehalten werden
muss. Ein weiteres Problem ist, dass, wenn ein einzelner Funkträger verwendet
wird, die gleiche CID-Länge
sowohl in der Uplink- als auch in der Downlink-Richtung verwendet
werden muss. Jedoch ist in Mobilfunksystemen zum Beispiel eine bevorzugte
CID-Länge
in der Uplink-Richtung deutlich kürzer als in der Downlink-Richtung.
Wenn bei einer Lösung
des Standes der Technik die CID-Länge für einen Funkträger auf der
Basis des Bedarfs in der Downlink-Richtung definiert wird, so werden dann
die Funkressourcen der Uplink-Richtung nicht optimal genutzt. Wenn
die CID-Länge
nur unter Berücksichtigung
der Uplink-Richtung
definiert wird, so kommt es bei der Dekomprimierung in der Downlink-Richtung
zu Problemen, weil die benötigte
CID-Länge
größer ist
als die automatisch eingestellte CID-Länge.
-
Das
Dokument von M. Degermark und Mitarbeitern, "IP Header Compression", RFC 2507, offenbart
ein Verfahren zum Bestimmen der Länge des CID durch ein separates
Längenfeld
(ein Bit), das in dem Paketzellkopf enthalten ist. Wenn jedoch die Länge des
CID während
der Sitzung gemäß dem Dokument
geändert
wird, so muss die Struktur des gesamten Paketzellkopfes neu definiert
werden, da das separate Längenfeld,
das in dem Paketzellkopf enthalten ist, die Länge des CID definiert. Des
Weiteren müssen
bei der Dekomprimierung der Paketzellköpfe gemäß dem Dokument der gesamte
Paketzellkopf und seine Felder analysiert werden, um die Länge und
den Wert des CID aufzulösen.
-
Kurzdarstellung der Erfindung
-
Es
ist somit eine Aufgabe der Erfindung, ein Verfahren und eine Vorrichtung
zu entwickeln, die das Verfahren dergestalt implementieren, dass
die oben angeführten
Probleme gelöst
werden. Die Aufgabe der Erfindung wird mittels eines Verfahrens
und eines Systems erreicht, die dadurch gekennzeichnet sind, was
in den unabhängigen
Ansprüchen
angeführt
ist. Bevorzugte Ausführungsformen der
Erfindung sind in den abhängigen
Ansprüchen
dargelegt.
-
Die
Erfindung basiert auf dem Gedanken, dass, wenn eine Notwendigkeit
detektiert wird, eine Länge
eines Kontextidentifikators für
einen Datenpaketstrom – in
der Regel als eine Neudefinierung – zu definieren, diese Definition
an das nächste
zu sendende Datenpaket, vorzugsweise an sein Kontextidentifikatorfeld,
angehängt
wird, wobei die neue Länge
des Kontextidentifikators durch ein oder mehrere Bits definiert
wird. Gemäß einer
bevorzugten Ausführungsform
der Erfindung wird diese Definition an jedes gesendete Datenpaket
angehängt,
wodurch die Länge
des Kontextidentifikators von jedem Datenpaket überprüft wird. Gemäß einer
zweiten bevorzugten Ausführungsform
der Erfindung wird diese Definition nur an das erste zu sendende
Datenpaket angehängt,
woraufhin diese Kontextidentifikatorlänge in dem Datenpaketstrom
verwendet wird, bis sie wieder entsprechend neu definiert wird.
-
Das
Verfahren und das System der Erfindung bieten den Vorteil, dass
die Länge
des Kontextidentifikators für
die Uplink- und die Downlink-Richtung unterschiedlich definiert
werden kann, wodurch die Nutzung der Datenübertragungsressourcen effizienter
gestaltet wird. Des Weiteren bietet das erfindungsgemäße Verfahren
den Vorteil, dass es nicht erforderlich ist, die Komprimierung und
die Dekomprimierung anzuhalten und die Länge des Kontextidentifikators
jedes Mal neu einzustellen, wenn die Länge geändert werden muss. Ein weiterer
Vorteil der Erfindung ist, dass sie es auch ermöglicht, Datenpakete mit unterschiedlich
langen Kontextidentifikatoren zur selben Datenübertragungsverbindung zu multiplexieren.
-
Kurze Beschreibung der Figuren
-
Die
Erfindung wird im Folgenden eingehender anhand bevorzugter Ausführungsformen
und unter Bezug auf die angehängten
Zeichnungen beschrieben, in denen Folgendes zu sehen ist:
-
1 ist
ein Blockschaubild von Übergängen zwischen
verschiedenen Komprimierungsstufen der ROHC.
-
2 ist
ein Blockschaubild von Übergängen zwischen
verschiedenen Komprimierungsmodi der ROHC.
-
3 ist
ein Blockschaubild einer Problemsituation, die durch eine zum Stand
der Technik gehörende
ROHC mit unterschiedlichen Längen
eines Kontextidentifikatorfeldes im Vorwärts- und im Rückkanal
verursacht wird.
-
4 zeigt
ein Datenpaket, das ein Kontextidentifikatorfeld einer bevorzugten
Ausführungsform der
Erfindung zeigt.
-
Detaillierte Beschreibung
der Erfindung
-
Im
Folgenden wird die Implementierung des in Rede stehenden Kopfdatenfeldkomprimierungsverfahrens
ROHC für
die Teile, die für
die Erfindung wesentlich sind, beschrieben. Für eine eingehendere Beschreibung
des in Rede stehenden Komprimierungsverfahrens wird auf einen noch
unfertigen Internet-Entwurf mit dem Titel "Robust Header Compression (ROHC)", Version 02, 18.
September 2000, verwiesen.
-
Bei
anderen Komprimierungsverfahren wird normalerweise ein Kontext sowohl
für den
Komprimierer als auch für
den Dekomprimierer definiert, wobei der Kontext ein Zustand ist,
den der Komprimierer verwendet, um ein zu sendendes Kopfdatenfeld
zu komprimieren, und den der Dekomprimierer verwendet, um ein empfangenes
Kopfdatenfeld zu dekomprimieren. Der Kontext umfasst in der Regel
eine unkomprimierte Version des vorherigen Kopfdatenfeldes, das über eine
Datenübertragungsverbindung übermittelt
(Komprimierer) oder empfangen (Dekomprimierer) wurde. Des Weiteren
kann der Kontext Informationen umfassen, die einen Datenpaketstrom identifizieren,
wie beispielsweise Folgenummern oder Zeitstempel von Datenpaketen.
Somit umfasst der Kontext in der Regel sowohl statische Informationen,
die für
den gesamten Datenpaketstrom unverändert bleiben, als auch dynamische
Informationen, die sich während
des Datenpaketstroms verändern, was
sie aber oft gemäß einem
bestimmten Muster tun.
-
Die
ROHC verwendet drei Komprimierungsstufen in einer solchen Weise,
dass die Komprimierung auf der niedrigsten Stufe begonnen wird und schrittweise
zu den höheren
Stufen voranschreitet. Das Grundprinzip ist, dass eine Komprimierung
immer auf der höchstmöglichen
Stufe stattfindet, jedoch in einer solchen Weise, dass der Komprimierer
genügend
Gewissheit über
die Tatsache besitzt, dass der Dekomprimierer über genügend Informationen verfügt, um eine
Dekomprimierung auf der betreffenden Stufe vornehmen zu können. Faktoren,
welche den Wechsel zwischen verschiedenen Komprimierungsstufen beeinflussen,
sind: Schwankungen bei aufeinanderfolgenden Kopfdatenfeldern; positive
und negative Bestätigungen
vom Dekomprimierer; und – wenn
keine Bestätigungen
kommen – das
Ablaufen bestimmter Folgezähler.
Es ist möglich,
entsprechend von einer höheren
Komprimierungsstufe zu einer niedrigeren Stufe zu wechseln.
-
Die
Komprimierungsstufen, welche die ROHC in Verbindung mit dem IP-Protokoll
(Internet Protocol), dem UDP-Protokoll
(User Datagram Protocol) und dem RTP-Protokoll (Real-Time Protocol) verwendet,
sind Initiierung/Auffrischung (IR), Erste Ordnung (FO) und Zweite
Ordnung (SO), und der Wechsel zwischen diesen Stufen ist in dem
Schaubild von 1 beschrieben. Die IR-Stufe
wird dazu verwendet, den Kontext für den Dekomprimierer zu erzeugen
oder eine Wiederherstellung nach einer Fehlersituation vorzunehmen.
Der Komprimierer geht zur IR-Stufe über, wenn die Kopfdatenfeldkomprimierung
begonnen wird, wenn der Dekomprimierer es verlangt, oder wenn ein
Aktualisierungs-Zeitnehmer abläuft.
Auf der IR-Stufe sendet der Komprimierer IR-Kopfdatenfelder in einem
unkomprimierten Format. Der Komprimierer versucht, zu einer höheren Stufe
zu wechseln, wenn sicher ist, dass der Dekomprimierer die Aktualisierungsinformationen
erhalten hat.
-
Die
FO-Stufe dient dazu, den Empfänger über Unregelmäßigkeiten
in den Kopfdatenfeldern des Datenpaketstroms zu informieren. Nach
der IR-Stufe arbeitet der Komprimierer auf der FO-Stufe in einer
Situation, wo die Kopfdatenfelder keine einheitliche Struktur bilden
(oder anders ausgedrückt: wo
sich aufeinanderfolgende Kopfdatenfelder willkürlich dergestalt ändern, dass
sich die Änderungen nicht
vorhersagen lassen), oder wo der Komprimierer nicht sicher sein
kann, dass der Dekomprimierer die Parameter erhalten hat, welche
die einheitliche Struktur der Kopfdatenfelder definiert. Dies ist
eine typische Situation, wenn beispielsweise Sprache übertragen
wird. Auf der FO-Stufe sendet der Komprimierer komprimierte FO-Kopfdatenfelder.
Der Komprimierer versucht auch hier, zu einer höheren Stufe zu wechseln, wenn
die Kopfdatenfelder eine einheitliche Struktur bilden und es sicher
ist, dass der Dekomprimierer die Parameter erhalten hat, welche die
einheitliche Struktur definieren. Die FO-Stufen-Datenpakete umfassen in der Regel Kontextaktualisierungsinformationen.
Das bedeutet, dass eine erfolgreiche Dekomprimierung auch eine erfolgreiche Übertragung
aufeinanderfolgender FO-Kopfdatenfelder erfordert. Der Erfolg des
Dekomprimierungsprozesses hängt somit
davon ab, ob FO-Stufen-Pakete verloren gegangen oder beschädigt worden
sind.
-
Auf
der SO-Stufe ist die Komprimierung optimal. Die Kopfdatenfelder
bilden eine einheitliche Struktur, die der Komprimierer mit komprimierten SO-Kopfdatenfeldern
darstellt, die in der Praxis Folgenummern der Datenpakete sind.
An den Dekomprimierer werden Informationen zu Parametern übermittelt,
welche die einheitliche Struktur der Kopfdatenfelder definieren,
und anhand der Parameter und der empfangenen Folgenummer kann der
Dekomprimierer die ursprünglichen
Kopfdatenfelder extrapolieren. Weil die auf der SO-Stufe gesandten
Datenpakete in der Praxis voneinander unabhängig sind, ist die Fehlerempfindlichkeit
der Dekomprimierung ebenfalls gering. Wenn die Kopfdatenfelder keine einheitliche
Struktur mehr bilden, so kehrt der Dekomprimierer zur FO-Stufe zurück.
-
Die
Dekomprimierung hat ebenfalls drei Stufen, die an die Kontextdefinition
des Dekomprimierers gebunden sind. Der Dekomprimierer beginnt seine
Arbeit stets von der niedrigsten Stufe aus, wenn noch kein Kontext
definiert wurde (Kein Kontext). Der Dekomprimierer hat dann noch
keine Datenpakete dekomprimiert. Wenn der Dekomprimierer das erste Datenpaket
dekomprimiert hat, das sowohl statische als auch dynamische Kontextinformationen
umfasst, so kann er über
die mittlere Stufe (Statischer Kontext) direkt zur obersten Stufe
(Voller Kontext) wechseln. Infolge verschiedener Fehlersituationen
auf der obersten Stufe wechselt der Dekomprimierer auf die mittlere
Stufe, aber in der Regel bringt schon ein einziges erfolgreich dekomprimiertes
Datenpaket den Dekomprimierer auf die oberste Stufe zurück.
-
Neben
verschiedenen Komprimierungsstufen hat die ROHC noch drei verschiedene
Betriebsmodi: den unidirektionalen Modus (U-Modus), den bi-direktionalen
optimistischen Modus (O-Modus) und den bi-direktionalen zuverlässigen Modus (R-Modus),
die in dem Schaubild von 2 gezeigt sind. Wie in 2 dargestellt,
funktioniert jede der oben beschriebenen Komprimierungsstufen (IR,
FO, SO) in jedem Betriebsmodus, aber jeder Modus funktioniert auf
jeder Stufe in seiner eigenen Weise und trifft auch Entscheidungen
zu Übergängen zwischen den
Stufen in seiner eigenen Weise. Die Auswahl des Modus' für jede Komprimierungssituation
hängt von den
Parametern der verwendeten Datenübertragungsverbindung
ab, wie beispielsweise die Möglichkeit,
einen Rückkanal
zu verwenden, Fehlerwahrscheinlichkeiten und -verteilung oder die
Auswirkungen von Schwankungen bei der Größe der Kopfdatenfelder.
-
Im
unidirektionalen Modus werden Datenpakete nur vom Komprimierer zum
Dekomprimierer übertragen,
so dass der U-Modus der ROHC in Situationen nützlich ist, wo die Verwendung
eines Rückkanals
nicht möglich
oder nicht zweckmäßig ist.
Im U-Modus erfolgen Übergänge zwischen
verschiedenen Komprimierungsstufen infolge des Ablaufens bestimmter
Folgezähler
oder auf der Basis von Schwankungen in den Kopfdatenfeld-Strukturen. Weil
kein Rückkanal
verwendet wird, ist eine Komprimierung im U-Modus weniger effizient, und das Verschwinden
von Datenpaketen auf dem Übertragungsweg
ist wahrscheinlicher, als in den beiden bi-direktionalen Modi. Die
ROHC beginnt immer im U-Modus, und der Wechsel zu einem der beiden bi-direktionalen
Modi kann erfolgen, wenn der Dekomprimierer wenigstens ein Paket
erhalten hat; und in Reaktion auf dieses Paket zeigt der Dekomprimierer
an, dass ein Moduswechsel erforderlich ist.
-
Der
bi-direktionale optimistische Modus ähnelt dem unidirektionalen
Modus, mit der Ausnahme, dass im O-Modus ein Rückkanal verwendet wird, um Fehlersituationen
zu korrigieren und wichtige Kontextaktualisierungen vom Dekomprimierer
zum Komprimierer zu bestätigen.
Sequenzielle Aktualisierungen erfolgen nicht im O-Modus. Der O-Modus
eignet sich besonders für
Verbindungen, die eine optimale Komprimierungseffizienz mit geringem
Rückkanalverkehr
erfordern. Der O-Modus ermöglicht
einen hinlänglich
zuverlässigen
Datenpakettransfer, bei dem die Synchronisation zwischen Komprimierer
und Dekomprimierer in der Regel gut aufrecht erhalten werden kann
und Datenpakete nur selten verloren gehen, und wenn sie verloren
gehen, dann nur in vernachlässigbarer
Zahl. Bei sehr hohen Bitfehlerraten können Datenpakete allerdings
auf dem Übertragungsweg
verloren gehen.
-
Der
bi-direktionale zuverlässige
Modus unterscheidet sich deutlich von den oben erwähnten Modi.
Der R-Modus verwendet einen Rückkanal,
um alle Kontextaktualisierungen und auch Folgenummern-Aktualisierungen
zu bestätigen.
Somit können im
R-Modus Datenpakete nahezu vollständig zuverlässig zwischen Komprimierer
und Dekomprimierer übertragen
werden. Die Komprimierung von Kopfdatenfeldern kann im R-Modus nicht
zum Verschwinden von Datenpaketen führen. Ein Nachteil des R-Modus' ist, dass die Größe des Kopfdatenfeldes
in einigen Fällen
geringfügig
größer ist
als bei den oben genannten Modi und dass der Rückkanalverkehr deutlich zunimmt.
-
Die
drei Betriebsmodi und die drei Komprimierungsstufen der ROHC bilden
unterschiedliche Betriebssituationen für die Komprimierung der Kopfdatenfelder,
wobei jede Situation die Definition des Betriebes des Komprimierers
und des Dekomprimierers und der Übertragung
von Paketen zwischen ihnen erfordert. Die ROHC verwendet in unterschiedlichen
Betriebssituationen verschiedene Pakete. Derzeit sind sechs verschiedene
Datenpakettypen für die
ROHC definiert, von denen vier für
die Übertragung
vom Komprimierer zum Dekomprimierer und zwei als Rückkanal-Datenpakete
vom Dekomprimierer zum Komprimierer verwendet werden. Die Anzahl der
verwendeten Datenpakettypen kann sich in der Zukunft ändern, aber
alle Datenpakettypen sind dadurch gekennzeichnet, dass ein Kontextidentifikator CID,
der den zu jedem Zeitpunkt verwendeten Kontext definiert, an den
Anfang jedes Datenpaketes angehängt
wird, bevor das Paket an den Übertragungsweg
gesendet wird.
-
Die
Länge des
Kontextidentifikators CID wird für
jeden Datenpaketstrom separat durch den Komprimierer und Dekomprimierer
automatisch eingestellt. Entsprechend den ROHC-Definitionen muss die
untere Protokollschicht (Sicherungsschicht), die jeweils verwendet
wird, einen Mechanismus für
die automatische Einstellung der Parameter, wie beispielsweise die
Länge des
Kontextidentifikators, die bei der Kopfdatenfeldkomprimierung verwendet
wird, enthalten. Die Parameter werden vor Beginn der Komprimierung
automatisch eingestellt, und in dieser Verbindung kann die Länge des
Kontextidentifikators des Datenpaketstroms wie im Stand der Technik
mit 0, 8 oder 16 Bits definiert werden. Auf einem einzelnen logischen
Datenübertragungskanal
können gleichzeitig
mehrere Datenpaketströme übertragen werden,
deren Kontexte mittels des Kontextidentifikators CID identifiziert
und voneinander unterschieden werden. Wenn beispielsweise nur ein
einziger Datenpaketstrom über
den Kanal übertragen
wird, was für
verschiedene VOIP-Anwendungen
(Voice over IP) typisch ist, so wird der Länge des Kontextidentifikators
CID der Wert 0 gegeben. Wenn mehrere Datenpaketströme auf demselben
Kanal übertragen werden,
so wird die Länge
des Kontextidentifikators in Abhängigkeit
von der genutzten Anwendung, dem Datenübertragungsprotokoll und den
Kanalbedingungen mit 8 oder 16 Bits für jeden Datenpaketstrom definiert.
-
Die
Länge des
Kontextidentifikators CID, die in den oben beschriebenen bi-direktionalen
Betriebsmodi (O-Modus und R-Modus) automatisch eingestellt wird,
wird auch auf dem Rückkanal
verwendet. Jedoch würde
es in Mobilfunksystemen zum Beispiel oft bevorzugt sein, einen längeren Kontextidentifikator
auf dem Rückkanal
(Downlink) als auf dem Vorwärtskanal
(Uplink) zu verwenden, weil speziell bei der Nutzung von Paketdatendiensten
weit mehr Daten in der Downlink-Richtung als in der Uplink-Richtung übertragen
werden. Dann muss bei Verwendung einer Kopfdatenfeldkomprimierung
gemäß der ROHC
die Länge
des Kontextidentifikators in der Regel entsprechend den Erfordernissen
des Rückkanals
dimensioniert sein, wobei in diesem Fall der Vorwärtskanal
von dem Komprimierer zum Dekomprimierer ineffizient genutzt wird.
-
Das
Blockschaubild von 3 beschreibt ein Problem, das
auftreten würde,
wenn bei dem hier besprochenen ROHC-Verfahren ein 8-Bit-Kontextidentifikator
für den
Vorwärtskanal
definiert werden würde
und ein 16-Bit-Kontextidentifikator
für den Rückkanal
definiert werden würde.
Zum Beispiel haben bei Mobilfunksystemen der Uplink- und der Downlink-Kanal
ihre eigenen Komprimierer-Dekomprimierer-Paare,
und zwar in einer solchen Weise, dass das Endgerät zum Beispiel einen Komprimierer C1
hat und in der Uplink-Richtung auf der Netzseite sich ein Dekomprimierer
D1 befindet. Dementsprechend gibt es in der Downlink-Richtung auf
der Netzseite einen Komprimierer C2, der sein Gegenstück, einen
Dekomprimierer D2, in dem Endgerät
hat. Somit sendet der Komprimierer C1 Datenpakete (300), die
einen 8-Bit-Kontextidentifikator
auf dem Uplink- Kanal umfassen, an den Dekomprimierer D1. Auf einer
bestimmten Stufe, zum Beispiel beim Wechseln der Komprimierungsstufe,
sendet der Netzdekomprimierer D1 eine Bestätigung an das Endgerät auf dem Downlink-Kanal,
wobei diese Bestätigung
durch Übertragen
des Datenpaketes an den Komprimierer C2 (302) erfolgt,
der den 8-Bit-Kontextidentifikator zu der Bestätigung hinzufügt, weil
beide Kanäle
gemäß den derzeitigen
ROHC-Definitionen die gleiche Kontextidentifikatorlänge verwenden.
Der Komprimierer C2 hängt
dieses Bestätigungspaket
an den Datenstrom (304) an, der auf dem Downlink-Kanal
an das Endgerät übertragen
wird. Der Dekomprimierer D2 überprüft das Bestätigungspaket,
aber weil der Dekomprimierer Datenpakete erwartet, die einen 16-Bit-Kontextidentifikator
haben, interpretiert er das erste Byte des Kopfdatenfeldes des Datenpaketes
im Anschluss an das 8-Bit-Kontextidentifikatorfeld als Teil des
Kontextidentifikators CID, was eine Fehlersituation entweder in
der Interpretation des Bestätigungspaketes
oder in seiner Dekomprimierung verursacht.
-
Das
oben beschriebene Problem könnte
im Prinzip bei dem zum Stand der Technik gehörenden Verfahren vermieden
werden, indem man die Komprimierung jedes Mal unterbricht, wenn
eine Bestätigung
von dem Dekomprimierer auf dem Rückkanal eintrifft,
und indem man die Länge
des Kontextidentifikators des Vorwärtskanals neu einstellt. Das
würde allerdings
die Datenstromübertragung
so stark verlangsamen, dass die Nutzung der ROHC in der Praxis bei
mehreren Anwendungen unmöglich
werden würde.
In der Praxis würde
die Lösung
darin bestehen, die Komprimierung anzuhalten und ein 16-Bit-Kontextidentifikatorfeld
für beide
Richtungen einzustellen, was auch wieder dazu führen würde, dass die Datenübertragungsressourcen
nicht optimal genutzt werden.
-
Die
oben beschriebenen Probleme können nun
gemäß dem erfindungsgemäßen Verfahren
vermieden werden, das die Länge
des Kontextidentifikators in dem Kontextidentifikatorfeld eines
Datenpaketes in Reaktion auf die Tatsache definiert, dass die Länge des
Kontextidentifikators geändert
werden muss. Das kann vorzugsweise dadurch geschehen, dass man ein
oder mehrere Bits des Kontextidentifikatorfeldes reserviert, um
die Länge
des Kontextidentifikators des Datenpaketes anzuzeigen, und der eigentliche
Kontextidentifikator kann vorzugsweise im Anschluss an diese Bits
hinzugefügt
werden. Die Länge
des Kontextidentifikators kann somit vorzugsweise für jedes
Datenpaket separat definiert werden, wobei in diesem Fall jedes
Datenpaket in einem Datenpaketstrom, und insbesondere ihre Kontextidentifikatorfelder,
Informationen umfassen, welche die Länge definieren. Dieses Verfahren,
bei dem Informationen, welche die Kontextidentifikatorlänge definieren,
an jedes Datenpaket angehängt
werden, vorzugsweise an die ersten Bits seines Kontextidentifikatorfeldes,
gewährleistet,
dass der neue Kontextidentifikator an den Empfänger übertragen wird. Alternativ
kann auch die Länge
des Kontextidentifikators in der oben beschriebenen Weise so definiert
werden, dass nur das erste Datenpaket, das nach der Neudefinierung
der Kontextidentifikatorlänge übertragen
wird, die Informationen, welche die Länge definieren, umfasst, aber
das ist kein so zuverlässiges Verfahren
zum Übertragen
der neuen Kontextidentifikatorlänge
an den Dekomprimierer.
-
Die
Definition der Kontextidentifikatorlänge ist in der Tabelle von 4 veranschaulicht,
die beispielhaft ein Datenpaket zeigt, das eine erfindungsgemäße Kontextidentifikatorfeld-Struktur
zeigt. Ein Kontextidentifikatorfeld (CID) ist gemäß ROHC an den
Anfang des Datenpaketes als das erste Byte angehängt, worauf das Paketkopfinformationsfeld
(PHI) des Datenpaketes und die Nutzdaten des Datenpaketes folgen.
Jedoch umfasst das Kontextidentifikatorfeld auch im Wesentlichen
in jedem Datenpaket ein Feld, das die Länge (CID_len) des Kontextidentifikators
des betreffenden Datenpaketes definiert. In dem Beispiel von 4 beträgt die Länge des
Feldes, das die Länge
definiert, zwei Bits, aber sie kann bevorzugt zwischen 1 und 8 Bits
variieren. Die Länge des
Kontextidentifikators für
das betreffende Datenpaket wird somit durch die Informationen in
dem Feld bestimmt, das die Kontextidentifikatorlänge angibt, und die Längeninformationen
in dem nächsten
Datenpaket definieren die Länge
des Kontextidentifikators wieder für das betreffende Datenpaket
neu. Der eigentliche Kontextidentifikator (CID) kann erforderlichenfalls
mehrere Bytes umfassen, auch mehr als zwei.
-
Auf
diese Weise macht es das erfindungsgemäße Verfahren möglich, verschiedene
Kontextidentifikatorlängen
für den
Vorwärts-
und den Rückkanal zu
definieren, wodurch der Gebrauch der Datenübertragungsressourcen effizienter
wird. Des Weiteren kann mittels des erfindungsgemäßen Verfahrens
das Anhalten der Komprimierung und der Dekomprimierung und das erneute
Einstellen der Kontextidentifikatorlänge jedes Mal, wenn die Länge geändert werden
muss, vermieden werden. Das erfindungsgemäße Verfahren macht es außerdem möglich, Datenpakete,
die unterschiedliche Längen
des Kontextidentifikators haben, in dieselbe Datenübertragungsverbindung
zu multiplexieren.
-
Das
oben beschriebene Verfahren kann vorzugsweise zum Beispiel auf Mobilfunksysteme
der dritten Generation namens UMTS (Universal Mobile Telecommunication
System) und IMT-2000 (International Mobile Telephone System) und
auf die Weiterentwicklungsprojekte der Mobilfunksysteme der zweiten
Generation, wie zum Beispiel GERAN (GSM Edge Radio Access Network),
angewendet werden. Zum Beispiel ist beim Paketdatendienst des UMTS-Systems
einer der Parameter, die den Funkträger definieren, das Komprimierungsverfahren
der Datenpaketkopfdatenfelder, das von dem Endgerät benutzt
wird. Das Komprimieren der Kopfdatenfelder von zu sendenden Datenpaketen
und das Dekomprimieren empfangener Datenpakete erfolgen in dem UMTS-System
auf der Paketdatenkonvergenzprotokoll(PDCP)-Schicht, die zu dem Paketdatenprotokoll gehört. Die
Aufgaben der PDCP-Schicht beinhalten Funktionen im Zusammenhang
mit dem Verbessern der Kanaleffizienz, die in der Regel auf verschiedenen
Optimierungsverfahren basieren, wie zum Beispiel die Nutzung von
Komprimierungsalgorithmen von Datenpaket-Kopfdatenfeldern. Weil derzeit die Protokolle
auf Netzebene, die für
UMTS ausgelegt sind, IP-Protokolle sind, sind die verwendeten Komprimierungsalgorithmen
jene, die durch die IETF (Internet Engineering Task Force) standardisiert
wurden. Somit ist das ROHC-Komprimierungsverfahren besonders
gut für
das UMTS-System geeignet. Die PDCP-Schicht des Endgerätes unterstützt in der
Regel mehrere Kopfdatenfeldkomprimierungsverfahren, um das Herstellen
einer Verbindung zu so vielen Typen von Protokollen auf Netzebene
wie möglich
zu gestatten.
-
Die
Datenmengen, die in der Uplink- und in der Downlink-Richtung in Anwendungen übertragen werden,
die insbesondere im Paketdatendienst des UMTS-Systems verwendet
werden, unterscheiden sich in der Regel erheblich voneinander, so
dass deutlich mehr Daten in der Downlink-Richtung übertragen
werden als in der Uplink-Richtung.
Somit verbessert die Konfiguration der Erfindung, bei der der Kontextidentifikator
in der Downlink-Richtung länger definiert
werden kann als in der Uplink-Richtung, die Nutzung von Funkressourcen
in dem UMTS-System.
-
Dem
Fachmann ist klar, dass trotz des Voranschreitens der technologischen
Entwicklung der Grundgedanke der Erfindung auf viele verschiedene Arten
implementiert werden kann. Die Erfindung und ihre Ausführungsformen
sind daher nicht auf die oben beschriebenen Beispiele beschränkt, sondern können innerhalb
des Geltungsbereichs der Ansprüche
variieren.