-
Allgemeiner
Stand der Technik
-
Die
Erfindung betrifft das Definieren einer Nachrichtenkopf-Datenfeldkomprimierung
für eine Datenpaketverbindung,
insbesondere für
eine Komprimierung in Mobilfunksystemen.
-
Das
rasche Voranschreiten der IP-Technologie (Internet Protocol) 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 Anrufübertragungspfades
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 verarbeiten.
-
In
Mobilfunknetzen ist es besonders wichtig, die begrenzten Funkressourcen
so effizient wie möglich
zu nutzen. Das verkompliziert seinerseits die Nutzung von IP-Protokollen
in der Funkschnittstelle, weil bei IP-gestützten
Protokollen der Anteil verschiedener Nachrichtenkopf-Datenfelder
der übertragenen 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 Nachrichtenkopf-Datenfeldkomprimierungsverfahren
zu Problemen führt.
Das hat zu der Notwendigkeit geführt,
ein für
verschiedene IP-Protokolle geeignetes Nachrichtenkopf-Datenfeldkomprimierungsverfahren
zu entwickeln, das sich ganz besonders für die Datenübertragung über die Funkschnittstelle eignet:
eine effiziente Nachrichtenkopf-Datenfeldkomprimierung, 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 Nachrichtenkopf-Datenfeldkomprimierungsverfahrens
befasst, das unter der Bezeichnung Robust Header Compression – ROHC bekannt
ist. Ein Gedanke, der hinter der Entwicklung der ROHC steht, ist,
dass es sehr viel Redundanz zwischen den verschiedenen IP-Nachrichtenkopf-Datenfeldern, 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 Nachrichtenkopf-Datenfeldern ä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 Nachrichtenkopf-Datenfelder
ist es erforderlich, dass die in ihnen enthaltenen Informationen
während
der Komprimierung der Aufmerksamkeit bedürfen. 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 eine genügend
hohe Betriebszuverlässigkeit
der Stufe stets gewährleistet
ist. Die ROHC hat auch die typische Eigenschaft, dass sie verschiedenen
Sachen, die für die
Verwendung eines Komprimierungsverfahrens von wesentlicher Bedeutung
sind, durch die untere Sicherungsschicht handhaben lässt.
-
Eine
solche Sache, die durch die untere Sicherungsschicht zwischen einem
Sender und einem Empfänger,
d.h. Komprimierer und Dekomprimierer, gehandhabt wird, ist die Definition
der Länge
eines Kontextidentifikators (Context Identifier – 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 ein großer
Wert oder ein kleiner Wert sein, wobei der Kontextidentifikator
im Fall eines großen
Wertes 1 oder 2 Bytes (8 oder 16 Bits) lang ist und im Fall eines kleinen
Wertes 0 Bytes (0 Bit) lang ist. Bei einer kleinen CID-Länge (0 Bytes)
ist es somit nicht möglich, mehrere
gleichzeitige Datenströme
anhand des Kontextidentifikators CID voneinander zu unterscheiden, doch
die ROHC umfasst einen internen Mechanismus, mit dem bis zu 16 gleichzeitige
Datenströme voneinander
unterschieden werden können,
auch wenn die Länge
des Kontextidentifikatorfeldes mit 0 Bytes definiert war. Die Länge des
CID wird somit automatisch eingestellt, bevor mit der Komprimierung der
zu übertragenden
Daten begonnen wird, und die automatisch eingestellte Länge des
Kontextidentifikators CID wird anschließend sowohl in Uplink- als auch
Downlink-Richtung verwendet.
-
Ein
Problem bei der oben beschriebenen Konfiguration ist beispielsweise
eine Situation, bei der eine maximale Anzahl gleichzeitiger Datenverbindungen,
die durch die definierte Länge
des Kontextidentifikators zugelassen wird, über einen Funkträger übertragen
wird und der Nutzer des Endgerätes einen
weiteren gleichzeitigen Datenstrom herstellen will. Weil eine maximale
Anzahl Kontextidentifikatoren bereits benutzt wird, kann für den neuen
Datenstrom kein Kontextidentifikator definiert werden. Dann wird,
wenn der neue Datenstrom komprimiert übertragen werden muss, ein
bereits in Nutzung befindlicher Datenstromkontext dafür definiert.
Das bedeutet, dass zwei komprimierte Datenverbindungen mit dem gleichen
Kontextidentifikator hergestellt werden, die der Komprimierer nicht
voneinander unterscheiden kann, und es kommt in dem gesamten Komprimierungssystem
zu einer Fehlersituation. Weil die derzeitigen Verfahren der ROHC
nicht die Maßnahme
definieren, die im Fall eine neuen "zusätzlichen" Datenstroms zu ergreifen
ist, tritt das oben beschriebene Problem immer ein, wenn ein Funkträger die
maximale Anzahl an Datenverbindungen nutzt, die vom Kontextidentifikator
CID zugelassen werden, und der Nutzer des Endgerätes versucht, einen neuen Datenstrom
zu eröffnen.
Des Weiteren kann es sein, dass ein benutztes Endgerät in einigen
Situationen – beispielsweise
beim Anwenden der ROHC in Mobilfunksystemen – seine eigenen internen Beschränkungen,
beispielsweise infolge des Speicherplatzes, auf gleichzeitige Datenverbindungen
anwendet, wobei diese Beschränkungen strenger
sein können,
als die ROHC es verlangen würde.
-
Das
den Stand der Technik darstellende Dokument "MPLS/IP header compression", Berger Lou und
Mitarbeiter, Draft-IETF-MPLS-HDR-COMP-OO.txt,
Juli 2000, offenbart ein Verfahren zum Komprimieren der Nachrichtenköpfe von
IP-Datagrammen,
die über
MPLS transportiert werden. Das Dokument offenbart, wie die existierenden
IP- und IP/UDP/RTP-Nachrichtenkopfkomprimierungsverfahren dahingehend
erweitert werden, dass sie über
MPLS-Kennsatzstapeleinträge funktionieren
und MPLS-Kennsatzstapeleinträge komprimieren.
-
Das
Dokument "[ROHC]
keyword-draft cutouts (with attachment!)", Kapitel 5.7.2., "State transitions using keyword packets", Burmeister Carsten, 16.
Juni 2000, offenbart einen Mechanismus der Verwendung von Schlüsselwortpaketen
für den
sicheren Übergang
vom FO- zum SO-Zustand
bei der ROHC-Komprimierung.
-
Kurzdarstellung
der Erfindung
-
Es
ist somit eine Aufgabe der Erfindung, ein Verfahren und eine Vorrichtung
zu entwickeln, welche das Verfahren dergestalt implementiert, dass
die oben angeführten
Nachteile gemindert werden. Die Aufgabe der Erfindung wird mittels
eines Verfahrens und einer Vorrichtung 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 trotz eines Überschreitens
der Anzahl an Datenpaketverbindungen, die durch die Länge des
Kontextidentifikators zugelassen ist, die Funkträgerparameter in einer solchen
Weise definiert werden, dass wenigstens die Anzahl an Datenpaketverbindungs-Nachrichtenkopfdatenfeldern,
die durch die definierte Länge
des Kontextidentifikators zugelassen ist, komprimiert werden kann.
Gemäß einem
ersten Aspekt der Erfindung kann dies implementiert werden, indem
die maximale Anzahl gleichzeitiger Datenpaketverbindungen, die für jeden
Funkträger definiert
sind, an ein Mobilkommunikationssystem-Objekt signalisiert wird,
das beim Herstellen einer neuen Datenpaketverbindung entscheidet,
welchem Funkträger
es zugeordnet sein wird, und indem das Mobilkommunikationssystem – in Reaktion
auf ein Überschreiten
der Anzahl der Datenpaketverbindungen, die durch den Höchstwert
der Länge
des Kontextidentifikators erlaubt sind – angewiesen wird, einen neuen
Funkträger
für die
zusätzlichen
Datenpaketverbindungen zu definieren. Gemäß einem zweiten Aspekt der
Erfindung kann dies implementiert werden, indem die Konvergenzprotokollschicht oder
der darin enthaltene Komprimierer – in Reaktion auf ein Überschreiten
der Anzahl der Datenpaketverbindungen, die durch den Höchstwert
der Länge
des Kontextidentifikators erlaubt sind – angewiesen wird, die zusätzlichen
Datenpaketverbindungen ohne Nachrichtenkopf-Datenfeldkomprimierung zu übertragen.
Gemäß einer
weiteren bevorzugten Ausführungsform
der Erfindung ist wenigstens ein Wert der Länge des definierten Kontextidentifikators
für einen unkomprimierten
Datenstrom reserviert.
-
Das
erfindungsgemäße Verfahren
und das erfindungsgemäße System
bieten den Vorteil, dass in allen Situationen mindestens so viele
Datenverbindungen komprimiert werden können, wie die Länge des
Kontextidentifikatorfeldes maximal zur Übertragung über den Funkträger zulässt. Des
Weiteren bietet das erfindungsgemäße Verfahren den Vorteil, dass
eine Unterbrechung der Kompression für die Datenverbindungen, die
komprimiert übertragen
werden, vermieden wird. Ein weiterer Vorteil der Erfindung ist,
dass sie eine Nachrichtenkopf-Datenfeldkomprimierung für Datenverbindungen
in der effizientesten Weise, die möglich ist, gestattet, was für die effiziente
Ausnutzung von Funkquellen vorteilhaft ist.
-
Kurze Beschreibung
der Figuren
-
Die
Erfindung wird im Folgenden eingehender anhand bevorzugter Ausführungsformen
und unter Bezug auf die angehängten
Zeichnungen beschrieben.
-
1 ist
ein Blockschaubild von Übergängen zwischen
verschiedenen Komprimierungsstufen der ROHC.
-
2 ist
ein Blockschaubild von Übergängen zwischen
verschiedenen Betriebsarten der ROHC.
-
3 ist
ein Blockschaubild einer vereinfachten Struktur des UMTS-Systems.
-
4a und 4b zeigen
Protokollstapel des UMTS-Paketdatendienstes
zur Steuerungszeichengabe und zum Übermitteln von Nutzerdaten.
-
5a und 5b zeigen
Betriebsarten der PDCP-Schicht.
-
6 zeigt
das Definieren von Datenpaketidentifikatoren gemäß einer Ausführungsform
der Erfindung.
-
Detaillierte
Beschreibung der Erfindung
-
Im
Folgenden wird die Implementierung des in Rede stehenden Nachrichtenkopf-Datenfeldkomprimierungsverfahrens
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 04, 11.
Oktober 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 übertragendes Nachrichtenkopf-Datenfeld
zu komprimieren, und den der Dekomprimierer verwendet, um ein empfangenes
Nachrichtenkopf-Datenfeld zu dekomprimieren. Der Kontext umfasst
in der Regel eine unkomprimierte Version des vorherigen Nachrichtenkopf-Datenfeldes,
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 Nachrichtenkopf-Datenfeldern;
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 (Initiation/Refresh – IR), Erste
Ordnung (First Order – FO) und
Zweite Ordnung (Second Order – SO).
Die Übergänge zwischen
diesen Stufen sind in dem Schaubild von 1 gezeigt.
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, wenn die Nachrichtenkopf-Datenfeldkomprimierung
begonnen wird, wenn der Dekomprimierer es verlangt, oder wenn ein
Aktualisierungs-Zeitnehmer abläuft.
Auf der IR-Stufe sendet der Komprimierer IR-Nachrichtenkopf-Datenfelder
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 Nachrichtenkopf-Datenfeldern des Datenpaketstroms zu informieren.
Nach der IR-Stufe arbeitet der Komprimierer auf der FO-Stufe in
einer Situation, wo die Nachrichtenkopf-Datenfelder keine einheitliche
Struktur bilden (oder anders ausgedrückt: wo sich aufeinanderfolgende
Nachrichtenkopf-Datenfelder 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 Nachrichtenkopf-Datenfelder definiert.
Dies ist eine typische Situation, wenn beispielsweise die Übertragung
von Sprache begonnen wird, insbesondere während der ersten Spach-Bursts.
Auf der FO-Stufe sendet der Komprimierer komprimierte FO-Nachrichtenkopf-Datenfelder.
Der Komprimierer versucht auch hier, zu einer höheren Stufe zu wechseln, wenn
die Nachrichtenkopf-Datenfelder 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-Nachrichtenkopf- Datenfelder 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 Nachrichtenkopf-Datenfelder
bilden eine einheitliche Struktur, die der Komprimierer mit komprimierten
SO-Nachrichtenkopf-Datenfeldern
darstellt, die in der Praxis Folgenummern der Datenpakete sind.
Bereits auf der FO-Stufe
werden an den Dekomprimierer Informationen zu den Parametern übermittelt,
welche die einheitliche Struktur der Nachrichtenkopf-Datenfelder
definieren. Anhand der Parameter und der empfangenen Folgenummer kann
der Dekomprimierer die ursprünglichen
Nachrichtenkopf-Datenfelder
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 Nachrichtenkopf-Datenfelder 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 ist. 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 kehrt der Dekomprimierer bereits nach dem
ersten erfolgreich dekomprimierten Datenpaket 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 (Z-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 Nachrichtenkopf-Datenfelder.
-
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
den einzelnen Komprimierungsstufen infolge des Ablaufens bestimmter
Folgezähler
oder auf der Basis von Schwankungen in den Nachrichtenkopfdatenfeld-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 im O-Modus nicht. 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 Z-Modus verwendet einen Rückkanal,
um alle Kontextaktualisierungen und auch Folgenummern-Aktualisierungen
zu bestätigen.
Somit können im
Z-Modus Datenpakete nahezu vollständig zuverlässig zwischen Komprimierer
und Dekomprimierer übertragen
werden. Die Komprimierung von Nachrichtenkopf-Datenfeldern kann
im Z-Modus nicht
zum Verschwinden von Datenpaketen führen. Ein Nachteil des Z-Modus' ist, dass die Größe des Nachrichtenkopf-Datenfeldes
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 Nachrichtenkopf-Datenfelder,
wobei jede Situation die Definition des Betriebes des Komprimierers
und des Dekomprimierers und der Übertragung
von Paketen zwischen sich 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, jedem Datenpaket angehängt wird, bevor das Paket auf
den Übertragungsweg
gesandt wird.
-
Die
Länge des
Kontextidentifikators CID wird für
jeden Funkträger
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 Nachrichtenkopf-Datenfeldkomprimierung
verwendet werden, 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 Bit definiert werden. Auf einem 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 die Länge des Kontextidentifikators
CID "klein" gemacht, d. h. es
wird der Wert 0 vergeben. Doch selbst zu diesem Zeitpunkt ist es
mittels interner ROHC-Mechanismen möglich, bis zu 16 gleichzeitige Datenströme voneinander
zu unterscheiden, d.h. zusätzlich
zu dem ursprünglichen
Datenstrom können immer
15 neue Datenverbindungen eröffnet
werden, auch wenn die Länge
des Kontextidentifikators CID mit 0 definiert wurde. Dies wird in
einer solchen Weise implementiert, dass die erste Datenverbindung immer
ohne einen Kontextidentifikator übertragen wird
und dass an die nachfolgenden Datenverbindungen ein Byte angehängt wird,
dessen erste vier Bits anzeigen, dass dies ein Kontextidentifikator
ist, und wobei die nachfolgenden vier Bits den eigentlichen Wert
des Kontextidentifikators anzeigen. Wenn beim Definieren des Funkträgers klar
ist, dass mehrere Datenpaketströme
auf demselben Kanal übertragen
werden, so wird vorzugsweise ein großer Wert, d.h. entweder 1 oder
2 Bytes (8 oder 16 Bit), als die Länge des Kontextidentifikators
definiert (je nach der Anwendung, dem Datenübertragungsprotokoll und den
Kanalbedingungen, die auf dem Funkträger verwendet werden).
-
Ein
Telekommunikationssystem, bei dem das Nachrichtenkopf-Datenfeldkomprimierungsverfahren
gemäß den ROHC-Spezifikationen
Anwendung findet, ist ein Mobilfunksystem der dritten Generation,
auch als UMTS (Universal Mobile Telecommunication System) und IMT-2000
(International Mobile Telephone System) bekannt. Im Folgenden wird
der Aufbau des UMTS-Systems in einer vereinfachten Weise anhand
von 3 beschrieben.
-
3 enthält nur die
Blöcke,
die für
das Erläutern
der Erfindung wesentlich sind, doch der Fachmann erkennt sofort,
dass ein herkömmliches
Mobiltelefonsystem auch andere Funktionen und Strukturen umfasst,
auf die hier nicht näher
eingegangen zu werden braucht. Die Hauptbestandteile eines Mobiltelefonsystems
sind ein Kernnetz (Core Network) CN, ein terrestrisches UMTS-Mobiltelefonsystem-Funkzugangsnetz
(UMTS Terrestrial Radio Access Network) UTRAN, welches das Festnetz
des Mobiltelefonsystems bildet, und eine Mobilstation bzw. ein Nutzergerät (User
Equipment) UE. Die Schnittstelle zwischen CN und UTRAN wird mit
Iu bezeichnet, und die Luftschnittstelle zwischen UTRAN und UE wird
mit Uu bezeichnet.
-
Das
UTRAN umfasst in der Regel mehrere Funknetz-Teilsysteme (Radio Network Subsystems) RNS,
wobei die Schnittstelle zwischen den RNS mit Iur (nicht gezeigt)
bezeichnet wird. Ein RNS umfasst eine Funknetzsteuerung (Radio Network
Controller) RNC und eine oder mehrere Basisstationen BS, die auch
als Knoten B bezeichnet werden. Die Schnittstelle zwischen RNC und
BS wird mit Iub bezeichnet. Die Basisstation BS kümmert sich
in der Regel um die Funkpfadimplementierung, und die Funknetzsteuerung
RNC übernimmt
mindestens die Verwaltung der Funkressourcen, die Steuerung der Übergabe
von einer Zelle zur nächsten,
Leistungsjustierung, Zeitsteuerung und Synchronisierung sowie Funkrufe zum
Teilnehmer-Endgerät.
-
Das
Kernnetz CN besteht aus einer Infrastruktur, die zu einem Mobiltelefonsystem
gehört
und sich außerhalb
des UTRAN befindet. In dem Kernnetz ist eine Mobilfunkvermittlung/Besucherdatei (Mobile
Switching Centre/Visitor Location Register) 3G-MSC/VLR mit einer
Heimatdatei (Home Location Register) HLR und vorzugsweise auch mit
einem Dienstesteuerungspunkt (Service Control Point) SCP eines intelligenten
Netzes verbunden. Die Heimatdatei HLR und die Besucherdatei VLR
umfassen Informationen zu Mobilfunkteilnehmern: Die Heimatdatei HLR
umfasst Informationen zu allen Teilnehmern in einem Mobilfunknetz
und zu den Diensten, an denen sie teilnehmen, und die Besucherdatei
VLR umfasst Informationen zu Mobilstationen, die den Bereich einer
bestimmten Mobilfunkvermittlung MSC besuchen. Eine Verbindung zu
einem Abnehmerknoten eines Paketfunksystems (Serving GPRS Support
Node) 3G-SGSN wird über
eine Schnittstelle Gs' hergestellt,
und eine Verbindung zu einem Telefon-Festnetz PSTN/ISDN wird über eine
(nicht gezeigte) Eingangs-Mobilfunkvermittlung (Gateway Mobile Switching
Center) GMSC hergestellt. Eine Verbindung von dem Abnehmerknoten
3G-SGSN zu externen Datennetzen PDN wird über eine Schnittstelle Gn zu einem
Gateway-Knoten (Gateway GPRS Support Node) GGSN hergestellt, der
eine Weiterverbindung zu den externen Datennetzen PDN hat. Die Verbindung
von der Mobilfunkvermittlung 3G-MSC/VLR und von dem Abnehmerknoten
3G-SGSN zum Funknetz (UMTS Terrestrial Radio Access Network) UTRAN
wird über
die Schnittstelle Iu hergestellt. Es ist zu beachten, dass das UMTS-System
dergestalt konstruiert ist, dass das Kernnetz CN beispielsweise mit
dem Kernnetz eines GSM-Systems
identisch sein kann, wobei es in einem solchen Fall nicht notwendig ist,
die gesamte Netzinfrastruktur neu zu bauen.
-
Das
UMTS-System umfasst außerdem
ein Paketfunksystem, das zu einem Großteil wie ein GPRS-System,
das mit einem GSM- Netz
verbunden ist, implementiert ist, was den Verweis auf ein GPRS-System
in den Namen der Netzkomponenten erklärt. Das UMTS-Paketfunksystem
kann mehrere Gateway- und
Abnehmerknoten umfassen, und es sind in der Regel mehrere Abnehmerknoten 3G-SGSN
mit einem Gateway-Knoten 3G-GGSN verbunden. Sowohl die Knoten 3G-SGSN
als auch die Knoten 3G-GGSN fungieren als Router, welche die Mobilität einer
Mobilstation unterstützen,
wobei diese Router das Mobilfunksystem steuern und Datenpakete zu
Mobilstationen routen, und zwar unabhängig von ihrem Standort und
dem verwendeten Protokoll. Der Abnehmerknoten 3G-SGSN steht über das
Funknetz UTRAN mit einer Mobilstation UE in Kontakt. Eine Aufgabe
des Abnehmerknotens 3G-SGSN ist es, innerhalb seines Abnehmergebietes
Mobilstationen zu erkennen, die zu Paketfunkverbindungen befähig sind,
Datenpakete von diesen Mobilstationen zu senden und zu empfangen
und den Standort der Mobilstationen in seinem Abnahmegebiet zu verfolgen.
Des Weiteren steht der Abnehmerknoten 3G-SGSN über die Zeichengabe-Schnittstelle
Gs' mit der Mobilfunkvermittlung
3G-MSC und der Besucherdatei VLR und über die Schnittstelle Gr mit
der Heimatdatei HLR in Kontakt. Mit Paketfunkdiensten im Zusammenhang
stehende Aufzeichnungen, die teilnehmerspezifische Paketdatenprotokollinhalte
umfassen, werden ebenfalls in der Heimatdatei HLR gespeichert.
-
Der
Gateway-Knoten 3G-GGSN fungiert als Gateway zwischen dem UMTS-Netz-Paketfunksystem
und dem externen Datennetz (Packet Data Network) PDN. Zu externen
Datennetzen gehören
das UMTS- oder GPRS-Netz eines zweiten Netzbetreibers, das Internet,
ein X.25-Netz oder ein privates Lokalnetz. Der Gateway-Knoten 3G-GGSN
steht über die
Schnittstelle Gi mit den Datennetzen in Kontakt. Datenpakete, die
zwischen dem Gateway-Knoten 3G-GGSN und dem Abnehmerknoten 3G-SGSN übertragen
werden, werden immer nach dem Gateway-Durchschleusungs-Protokoll
(Gateway Tunnelling Protocol) GTP verkapselt. Der Gateway-Knoten 3G-GGSN
enthält
des Weiteren PDP-Adressen (PDP = Packet Data Protocol) der Mobilstationen
und Routing-Informationen, d.h. 3G-SGSN-Adressen. Die Routing-Informationen
werden dazu verwendet, die Datenpakete zwischen dem externen Datennetz
und dem Abnehmerknoten 3G-SGSN zu verknüpfen. Das Netz zwischen dem
Gateway-Knoten 3G-GGSN und dem Abnehmerknoten 3G-SGSN arbeitet mit
einem IP-Protokoll, vorzugsweise dem IPv6 (Internet-Protokoll, Version
6).
-
4a und 4b zeigen
UMTS-Protokollstapel, die zur Steuerungszeichengabe (Steuerungsebene)
und zur Nutzerdatenübertragung
(Nutzer-Ebene) in einem Paketfunkdienst des UMTS-Systems verwendet
werden. 4a zeigt einen Protokollstapel,
der zur Steuerungszeichengabe zwischen einer Mobilstation MS und
dem Kernnetz CN verwendet wird. Mobilitätsmanagement MM der Mobilstation
MS, Anrufsteuerung (Call Control) CC und Sitzungsverwaltung (Session
Management) SM werden auf den höchsten
Protokollschichten zwischen der Mobilstation MS und dem Kernnetz
CN dergestalt signalisiert, dass die Basisstationen BS und Funknetzsteuerung
RNC, die dazwischenliegen, für
diese Zeichengabe transparent sind. Die Funkressourcenverwaltung
von Funkverbindungen zwischen Mobilstationen MS und Basisstationen
BS erfolgt über
ein Funkressourcenverwaltungssystem (Radio Ressource Management)
RRM, das Steuerungsdaten von einer Funknetzsteuerung RNC zu Basisstationen
BS übermittelt.
Diese Funktionen, die sich auf die allgemeine Verwaltung eines Mobilfunksystems beziehen,
bilden eine Gruppe mit dem Namen "Kernnetz-Protokolle" (Core Network Protocols – CN Protocols),
auch als "Non-Access
Stratum" (Ebene
der zugangsnetzunabhängigen
Funktionen) bezeichnet. Dementsprechend erfolgt die funknetzwerksteuerungsbezogene
Zeichengabe zwischen einer Mobilstationen MS, einer Basisstationen
BS und einer Funknetzsteuerung RNC auf Protokollebenen mit dem Namen "Funkzugangsnetzprotokolle" (Radio Access Network
Protocols – RAN
Protocols), auch als "Access
Stratum" (Ebene
der zugangsnetzbezogenen Funktionen) bezeichnet. Dazu gehören Übertragungsprotokolle
auf der untersten Ebene, und die durch die Übertragungsprotokolle übertragene
Steuerungszeichengabe wird zur Weiterverarbeitung zu den höheren Ebenen übertragen.
Die wichtigste der höheren
Access-Stratum-Ebenen ist das Funkressourcensteuerungsprotokoll
(Radio Resource Control Protocol) RRC, das für das Herstellen, Konfigurieren,
Aufrechterhalten und Freigeben von Funkverbindungen zwischen der
Mobilstationen MS und dem Funknetz UTRAN und für das Übertragen von Steuerungsinformationen
vom Kernnetz CN und dem Funknetz RAN zu den Mobilstationen MS zuständig ist. Überdies
ist das Funkressourcensteuerungsprotokoll RRC dafür zuständig, das
für den
Funkträger entsprechend
den Anweisungen des Funkressourcenverwaltungssystems RRM, beispielsweise
bei der anwendungsbasierten Kapazitätszuweisung, genügend Kapazität zugewiesen
wird.
-
Ein
Protokollstapel, wie in 4b gezeigt, wird
für das Übertragen
von UMTS-paketvermittelten Nutzerdaten verwendet. An der Schnittstelle
Uu zwischen dem Funknetz UTRAN und einer Mobilstation MS erfolgt
die Datenübertragung
der unteren Ebene auf einer physikalischen Schicht gemäß einem
WCDMA- oder TD-CDMA-Protokoll.
Eine MAC-Schicht über
der physikalischen Schicht überträgt Datenpakete
zwischen der physikalischen Schicht und einer RLC-Schicht, und die
RLC-Schicht übernimmt
die logische Verwaltung der Funkverbindungen verschiedener Funkträger. Die
RLC-Funktionen umfassen beispielsweise das Segmentieren der übertragenen Nutzerdaten
(RLC-SDU) in ein oder mehrere RLC-Datenpakete RLC-PDU. IP-Nachrichtenkopf-Datenfelder
in Datenpaketen (PDCP-PDU) einer PDCP-Schicht über der RLC-Schicht kann optional
komprimiert werden. Danach werden PDCP-PDUs zur RLC-Schicht weitergeleitet,
und sie entsprechen einer RLC-SDU. Die Nutzerdaten und die RLC-SDUs
werden segmentiert und in RLC-Rahmen übertragen, die um Adress- und Verifizierungsinformationen,
die für
die Datenübertragung
wesentlich sind, ergänzt
werden. Die RLC-Schicht kümmert sich
auch um die Neuübertragung
beschädigter
Rahmen. Der Abnehmerknoten 3G-SGSN verwaltet das Routen der Datenpakete,
die von der Mobilstation MS kommen, durch das Funknetz RAN auf den
richtigen Gateway-Knoten
3G-GGSN. Diese Verbindung arbeitet mit dem Durchschleusungsprotokoll
GTP, das alle Nutzerdaten und Zeichengaben, die über das Kernnetz übertragen
werden, verkapselt und durchschleust. Das GTP-Protokoll läuft über dem
IP, das von dem Kernnetz verwendet wird.
-
5a zeigt
ein Funktionsmodell der PDCP-Schicht, wobei für jeden Funkträger eine
PDCP-Entität
definiert ist. Weil in den derzeitigen Systemen für jeden
Funkträger
ein individueller PDP-Kontext definiert ist, ist auch eine PDCP-Entität für jeden PDP-Kontext
definiert, und eine bestimmte RLC-Entität ist für jede PDCP-Entität auf der
RLC-Schicht definiert. Wie oben angesprochen, kann die PDCP-Schicht
prinzipiell auch in einer solchen Weise funktionell implementiert
werden, dass verschiedene PDP-Kontexte auf der PDCP-Schicht gemultiplext werden,
wobei in einem solchen Fall eine RLC-Entität auf der RLC-Schicht unter
der PDCP-Schicht Datenpakete von verschiedenen Funkträgern gleichzeitig erhält.
-
5b veranschaulicht
eine Situation, in der eine PDCP-Entität Datenpakete über einen
einzigen Funkträger
von zwei verschiedenen Anwendungen, A und B, empfängt. Die
Datenströme
in dem Funkträger
werden anhand von IP-Nachrichtenkopf-Datenfeldern
vor dem Nachrichtenkopf-Datenfeldkomprimierer
in der PDCP-Entität
voneinander unterschieden, woraufhin die Datenströme zum Komprimieren geschickt
werden. Der Komprimierer unterscheidet die Datenströme voneinander,
indem er für
sie separate Kontextidentifikatoren definiert, anhand derer der
Dekomprimierer des Empfängers
die Datenströme
wieder voneinander unterscheiden und sie dekomprimieren kann. Um
dies zu veranschaulichen, zeigt 5b die
Komprimierer-Entität
als zwei separate Kästen,
aber in der Praxis gibt es zwei Komprimierungskontexte innerhalb
derselben Komprimierungsentität.
Die komprimierten Datenströme
werden jedoch über
dieselbe RLC-Verbindung übertragen.
-
Jede
PDCP-Entität
kann einen oder mehrere Nachrichtenkopf-Datenfeldkomprimierungsalgorithmen
verwenden oder auf sie verzichten. Mehrere PDCP-Entitäten können auch
den gleichen Algorithmus verwenden. Die Funkressourcensteuerung
RRC stellt für
jede PDCP-Entität
automatisch einen geeigneten Algorithmus sowie Parameter ein, die
den Algorithmus steuern, und avisiert dann den gewählten Algorithmus
und die Parameter über
einen PDCP-C-SAP-Punkt
(PDCP Control Service Access Point = PDCP-Dienstesteuerungspunkt) an die PDCP-Schicht.
Das verwendete Komprimierungsverfahren richtet sich nach dem für die Verbindung
verwendeten Protokolltyp auf Netzebene, wobei der Funkressourcensteuerung
der Typ angezeigt wird, wenn der PDP-Kontext aktiviert wird.
-
Beim
UMTS-System erfolgen die Nachrichtenkopf-Datenfeldkomprimierung von übertragenen Datenpaketen
und die Dekomprimierung empfangener Datenpakete also auf der Konvergenzprotokollschicht
PDCP. Zu den Aufgaben der PDCP-Schicht gehören Funktionen im Zusammenhang
mit der Verbesserung der Kanaleffizienz, die sich in der Regel auf
verschiedene Optimierungsverfahren stützen, wie beispielsweise die
Nutzung von Komprimierungsalgorithmen für Nachrichtenkopf-Datenfelder von
Datenpaketen. Da heute die für
UMTS geplanten Protokolle auf Netzebene IP-Protokolle sind, werden jene Komprimierungsalgorithmen
verwendet, die von der IETF (Internet Engineering Task Force) standardisiert
wurden. Darum eignet sich das ROHC-Komprimierungsverfahren ganz besonders
für das UMTS-System. Die PDCP-Schicht
des Endgerätes unterstützt in der
Regel verschiedene Nachrichtenkopf-Datenfeld-Komprimierungsverfahren, um den Verbindungsaufbau
mit möglichst
vielen Protokolltypen auf Netzebene zu gestatten.
-
Wenn
die ROHC auf die Konvergenzprotokollschicht des UMTS angewendet
wird, so umfassen sowohl die sendende PDCP-Schicht als auch die empfangende PDCP-Schicht
ein Komprimierer-Dekomprimierer-Paar zum Komprimieren der gesendeten
Datenpakete und zum Dekomprimieren der empfangenen Datenpakete.
Die Konvergenzprotokollschicht PDCP stellt dem Komprimierungsverfahren ROHC
einen Mechanismus zum automatischen Einstellen der Länge des
Kontextidentifikators für
jeden Funkträger
zur Verfügung.
In der Praxis wird dieser Mechanismus in der Weise implementiert,
dass die PDCP-Schicht die Meldungen des Komprimierers und des Dekomprimierers
zur RRC weiterleitet, und die eigentliche automatische Einstellung
erfolgt durch RRC-Zeichengabe. Um die Funkressourcen so effizient
wie möglich
nutzen zu können,
wird die Länge
des Kontextidentifikators CID vorzugsweise für den Funkträger als
Null definiert.
-
Wenn
die Länge
des für
den Funkträger
definierten Kontextidentifikators CID "klein" ist, d.h. null Bytes, und alle möglichen
16 Datenverbindungen in Benutzung sind, und der Nutzer des Endgerätes einen
weiteren gleichzeitigen Datenstrom für den Funkträger mit
einer solchen Definition herstellen will, so kommt es zu einer Problemsituation,
weil 17 gleichzeitige Datenströme
nicht mit einem "kleinen" Kontextidentifikator
voneinander unterschieden werden können. Weil ein neuer Datenstrom
laut ROHC-Spezifikationen nicht anhand seines eigenen Kontextidentifikators
identifiziert werden kann, wird ein Kontextidentifikator eines existierenden
Datenstroms für
ihn definiert. In einem solchen Fall werden zwei Datenströme mit dem
gleichen Kontextidentifikator gleichzeitig übertragen, was zu einer Fehlersituation
im Dekomprimierer führt,
weil der Dekomprimierer die Datenverbindungen nicht mehr voneinander
unterscheiden kann. Ein entsprechendes Problem tritt auch mit jedem
anderen definierten Wert für die
CID-Länge
auf, wenn der Funkträger
die maximale Anzahl von Datenverbindungen nutzt, die für die Länge des
Kontextidentifikators CID vorgegeben ist, und der Nutzer des Endgerätes versucht,
einen neuen Datenstrom zu eröffnen.
Die Übertragung
mehrerer Datenströme über eine
Funkschnittstelle ohne Nachrichtenkopf-Datenfeldkomprimierung führt zu einer
nicht-optimalen Ausnutzung der Funkressourcen, was ein Hindernis
für einen
effizienten Gebrauch des gesamten Mobilfunksystems darstellt.
-
Die
oben beschriebenen Probleme können jedoch
jetzt mit dem erfindungsgemäßen Verfahren gemindert
werden, wobei die Parameter des Funkträgers dergestalt definiert werden,
dass mindestens die Anzahl der Datenpaketverbindungs-Nachrichtenkopfdatenfelder,
die durch die Länge
des definierten Kontextidentifikators zugelassen sind, komprimiert werden
kann, ungeachtet der Tatsache, dass die Anzahl der Datenpaketverbindungen,
die durch die Länge
des Kontextidentifikators zugelassen sind, überschritten wird. Auf diese
Weise kann gewährleistet werden,
dass beispielsweise, wenn die Länge
des Funkträger-Kontextidentifikators
auf Null gesetzt ist und der Nutzer des Endgerätes einen 17. gleichzeitigen
Datenstrom für
den Funkträger
herstellen will, wenigstens die ursprünglichen 16, vorzugsweise alle 17,
Datenströme
mittels der ROHC übertragen
werden können.
Analog dazu kann auch mit jedem anderen definierten CID-Längenwert
gewährleistet
werden, dass – wenn
der Funkträger
die maximale Anzahl an Datenverbindungen, die für die Länge des Kontextidentifikators
CID definiert ist, nutzt und der Nutzer des Endgerätes versucht,
einen neuen Datenstrom zu eröffnen – wenigstens
eine Anzahl, die der ursprünglichen
Anzahl an Datenverbindungen entspricht, vorzugsweise aber alle Datenströme, mittels der
ROHC übertragen
werden können.
-
Gemäß einer
ersten Ausführungsform
der Erfindung kann die oben beschriebene Definition mittels der
ROHC dergestalt erfolgen, dass der ROHC-Algorithmus dergestalt definiert
wird, dass wenigstens ein Wert, vorzugsweise der letzte, der Länge des
Kontextidentifikators CID, d.h. des CID-Raumes, der für einen Funkträger automatisch eingestellt
wird, immer für
einen unkomprimierten Datenstrom reserviert ist. Auf diese Weise
kann gewährleistet
werden, dass die bereits benutzten Datenverbindungen komprimiert übertragen
werden können
und gleichzeitig eine neue Datenverbindung ohne Komprimierung hergestellt
werden kann. Der ROHC-Algorithmus kann beispielsweise auf der Basis
der automatischen Einstellung zwischen dem Komprimierer und dem
Dekomprimierer in einer solchen Weise definiert werden, dass, wenn
die Länge des
Kontextidentifikatorfeldes auf Null gesetzt wird, die ersten 15
Datenströme
komprimiert werden, und wenn der Nutzer des Endgerätes versucht,
einen neuen (16.) Datenstrom herzustellen, so werden dieser und
alle gleichzeitigen Datenströme,
die nach ihm hergestellt werden, unkomprimiert zum Empfänger übertragen.
Ein CID-Feld wird
an die unkomprimierten Datenpakete angehängt, um den Empfänger zu informieren,
dass ihre Nachrichtenkopf-Datenfelder nicht komprimiert wurden und
somit am Dekomprimierer vorbeizuleiten sind. Es ist auch möglich, für unkomprimierte
Datenströme
mehrere Werte des CID-Raumes des für den Funkträger automatisch eingestellten
Kontextidentifikatorfeldes zu reservieren.
-
Gemäß einer
zweiten Ausführungsform
der Erfindung überwacht
die Konvergenzprotokollschicht PDCP die Anzahl der Datenverbindungen,
und wenn die Anzahl der erlaubten Datenverbindungen überschritten
wird, so informiert die PDCP-Schicht das Funkressourcensteuerungsprotokoll
RRC darüber, woraufhin
das Funkressourcensteuerungsprotokoll RRC eine Funkträger-Neukonfiguration
vornimmt, während
der die Funkträgerparameter,
insbesondere die Länge
des Kontextidentifikators, dergestalt neu definiert werden, dass
die Nachrichtenkopf-Datenfelder jedes Datenstroms gemäß der ROHC
komprimiert werden können.
Wenn beispielsweise die Länge
des Funkträger-Kontextidentifikators
auf Null gesetzt ist und die PDCP-Schicht 17 oder mehr gleichzeitige Datenströme erkennt,
so wird der Funkträger neu
konfiguriert, wodurch der maximale Wert des Kontextidentifikatorfeldes
größer als
Null definiert wird. Das erfordert, dass die PDCP-Schicht um eine neue
Funktion erweitert wird, mit der die Anzahl der Datenverbindungen
jedes Funkträgers überwacht wird.
Wenn die Anzahl der Datenverbindungen auf einem Funkträger dem
maximalen Wert der Länge
des Kontextidentifikators entspricht und eine neue Datenverbindung
hergestellt wird, so informiert die PDCP-Schicht das Funkressourcensteuerungsprotokoll RRC
darüber,
wie oben angesprochen. Es ist auch möglich, dass beispielsweise
aufgrund beschränkter Funktionalität des Endgerätes die
Anzahl gleichzeitiger Datenverbindungen durch RRC-Zeichengabe auf beispielsweise
vier Datenströme
eingestellt wird. Dann muss die PDCP-Schicht in der Lage sein, die Anzahl
gleichzeitiger Datenverbindungen überwachen zu können, wie
oben angesprochen, weil die ROHC-Mechanismen sich nicht auf Situationen
auswirken, bei denen die höchste
Anzahl gleichzeitiger Datenverbindungen geringer ist als der maximale Wert
des Kontextidentifikatorfeldes.
-
Die
erste und zweite Ausführungsform,
die oben beschrieben wurden, können
gemäß einer
bevorzugten Ausführungsform
mit Hilfe der PDCP-Schicht dergestalt verwendet werden, dass die PDCP-Schicht
gemäß der zweiten
Ausführungsform die
Anzahl der Datenverbindungen auf einem Funkträger überwacht und erforderlichenfalls
gemäß der ersten
Ausführungsform
festlegt, dass für
die zusätzlichen
Datenverbindungen, welche die Anzahl der durch den maximalen Kontextidentifikatorwert
erlaubten Datenverbindungen überschreiten,
keine Nachrichtenkopf-Datenfeldkomprimierung
erfolgt. Dadurch wird gewährleistet,
dass wenigstens die ursprünglichen
Datenströme
optimal komprimiert übertragen
werden können.
In einem solchen Fall wird, wenn beispielsweise die Länge des
Kontextidentifikators des Funkträgers
auf Null festgesetzt ist und die PDCP-Schicht 17 gleichzeitige Datenströme erkennt,
der letzte (17.) Strom ohne Nachrichtenkopf-Datenfeldkomprimierung übertragen,
und diese Funktion der PDCP-Schicht leitet den neuen Datenstrom
am Komprimierer vorbei. Gemäß einer
bevorzugten Ausführungsform
kann diese Funktion der PDCP-Schicht
auch die Datenströme
auswählen,
die komprimiert werden, wobei in einem solchen Fall der Datenstrom,
der am Komprimierer vorbeigeleitet wird, nicht automatisch der zuletzt
gebildete Datenstrom ist.
-
Gemäß einer
dritten Ausführungsform
wird die UMTS-Entität
(beispielsweise das Sitzungsverwaltungsprotokoll SM), die beim Herstellen
einer Datenverbindung entscheidet, zu welchem Funkträger die
neuen Datenströme
gehören,
beim Herstellen der Datenverbindung über die Beschränkungen
informiert, die der maximale Wert des Kontextidentifikators für die Anzahl
gleichzeitiger Datenverbindungen auferlegt, besonders wenn die Länge des
Funkträger-Kontextidentifikators
auf Null gesetzt ist. Wenn dann 16 Datenströme in Benutzung sind und ein
Bedarf an 17 oder mehr gleichzeitigen Datenströmen erkannt wird, so kann ein
neuer "zusätzlicher" Datenstrom seinen
eigenen Funkträger
definiert bekommen, oder der erste Funkträger wird neu konfiguriert, und
die Länge
des Kontextidentifikatorfeldes erhält einen Wert größer als
Null. In beiden Fällen
können die
Nachrichtenkopf-Datenfelder
jedes Datenstromes gemäß der ROHC
komprimiert werden. Auch bei dieser Ausführungsform muss man besonders
eine Situation berücksichtigen,
bei der aufgrund beschränkter
Funktionalität
des Endgerätes
die höchste Anzahl
gleichzeitiger Datenverbindungen beispielsweise nur vier Datenströme beträgt. In einem
solchen Fall ist es notwendig, dass die Entität, welche das Herstellen der
Datenverbindung steuert, in der Lage ist, die Anzahl gleichzeitiger
Datenverbindungen zu überwachen,
wie oben angesprochen.
-
Gemäß einer
vierten Ausführungsform
werden Paketidentifikatoren (Packet Identifiers – PID) in der Datenpaketstruktur
der PDCP-Schicht verwendet, um die Änderungen anzuzeigen, die in
der Länge des
Kontextidentifikators notwendig sind. Auf der PDCP-Schicht werden die
verschiedenen Komprimierungsverfahren mittels Paketidentifikatoren
PID, die den Datenpaketen PDU angehängt sind, angezeigt und voneinander
unterschieden. Für
jede PDCP-Entität
wird eine Tabelle für
die werte des Paketidentifikators PID erstellt, in der verschiedene
Komprimierungsalgorithmen verschiedenen Datenpaketen passend zugeordnet
werden, und der Wert der Paketidentifikatoren PID wird als eine
Kombination daraus festgelegt. Wenn kein Komprimierungsalgorithmus verwendet
wird, so erhält
der Paketidentifikator PID den Wert Null. PID-Werte werden für jeden
Komprimierungsalgorithmus und seine Kombination mit verschiedenen
Datenpakettypen aufeinanderfolgend definiert, dergestalt, dass die
PID-Werte für jeden Komprimierungsalgorithmus
bei n + 1 beginnen, wobei n der letzte PID-Wert ist, der für den vorangegangenen
Komprimierungsalgorithmus definiert wurde. Die Reihenfolge der Komprimierungsalgorithmen wird
in Kooperation mit der Funkressourcensteuerung RRC automatisch eingestellt.
Auf der Grundlage der PID-Wert-Tabelle
können
die PDCP-Entitäten
an beiden Enden der Paketdatenverbindung die Komprimierungsalgorithmen
von Datenpaketen identifizieren, die gesendet und empfangen werden.
-
Diese
PID-Werte können
in dieser Ausführungsform
der Erfindung dergestalt verwendet werden, dass für verschiedene
Kontextidentifikatorfeldwerte (0, 1 oder 2 Bytes) der ROHC gemäß der in 6 gezeigten
Tabelle drei PID-Werte zugewiesen werden. Alternativ können auch
zwei PID-Werte zugewiesen werden, um die CID-Raum-Werte "klein" (0 Bytes) und "groß" (1 oder 2 Bytes)
darzustellen. Dann können
bei einem "großen" CID-Raum-Wert die CID-Feld-Erweiterungsbits
dazu verwendet werden, detaillierter anzuzeigen, ob dies ein 8-
oder ein 16-Bit-CID-Feld
betrifft. Wenn nun die Länge
des Funkträger-Kontextidentifikators
auf Null gesetzt ist und die PDCP-Schicht 17 gleichzeitige Datenströme erkennt,
so kann der empfangenden PDCP-Entität mittels dieser PID-Werte
eine Änderung
der Länge des
CID-Feldes angezeigt werden. Die PID-Werte werden vorzugsweise so
lange übertragen,
bis der Funkträger
neu konfiguriert ist oder die Anzahl der Datenverbindungen auf 16
zurückgeht.
-
Gemäß einer
fünften
Ausführungsform
wird die Länge
des CID-Feldes nicht neu definiert, auch wenn der maximale Wert
des CID-Raumes überschritten
wird, sondern es kann für
verschiedene Datenverbindungen eine separate RLC-Verbindung hergestellt werden. Das kann
in der Weise implementiert werden, dass, wenn der maximale Wert
des CID-Raumes überschritten
wird, jede neue Datenverbindung eine separate RLC-Verbindung erhält, deren CID-Feldlänge vorzugsweise
Null ist. Alternativ kann auch für
jeden Datenstrom eine separate RLC-Verbindung, deren CID-Feldlänge auf
Null gesetzt ist, definiert werden. Des Weiteren können die
Datenströme
in Situationen, wo 32 Datenströme
in Benutzung sind, auf zwei RLC-Verbindungen verteilt werden, wobei
in einem solchen Fall die Datenströme auf zwei RLC-Verbindungen
verteilt werden können,
deren CID-Feldlängen
vorzugsweise auf Null gehalten werden können. Dann sollten die PDCP-Schicht-Spezifikationen dergestalt
modifiziert werden, dass eine PDCP-Entität mehrere RLC-Verbindungen
gleichzeitig verwenden darf. Für
die Ausnutzung von Funkressourcen ist diese Ausführungsform optimal, weil jeder
gleichzeitige Datenstrom ohne ein CID-Feld (CID-Länge = 0) übertragen
werden kann, wobei in einem solchen Fall der Nutzdatenanteil der übertragenen
Daten maximiert werden kann.
-
Gemäß einer
sechsten Ausführungsform werden
gleichzeitige Datenverbindungen, welche den definierten maximalen
Wert des Kontextidentifikators überschreiten,
nicht für
die Übertragung
akzeptiert. Wenn beispielsweise die Länge des Kontextidentifikators
des Funkträgers
auf Null gesetzt wurde und 16 Datenströme in Benutzung sind und ein
Versuch unternommen wird, einen 17. gleichzeitigen Datenstrom zu
bilden, so lassen die PDCP-Schicht und/oder der Komprimierer den
Aufbau der 17. Datenverbindung nicht zu, und ihre Datenpakete werden
zurückgewiesen.
-
Auf
diese Weise gewährleistet
das erfindungsgemäße Verfahren,
dass es in allen Situationen möglich
ist, wenigstens so viele Datenverbindungen, die über den Funkträger übertragen
werden, zu komprimieren, wie es die maximale Länge des Kontextidentifikatorfeldes,
das für
den Funkträger
definiert ist, erlaubt. Des Weiteren wird eine Unterbrechung der
Komprimierung von Datenverbindungen, die komprimiert übertragen
werden, mittels des erfindungsgemäßen Verfahrens vermieden. Das
erfindungsgemäße Verfahren
ermöglicht
das Anwenden der Nachrichtenkopf-Datenfeldkomprimierung auf Datenverbindungen
in der effizientesten Weise, die möglich ist, was für eine effiziente
Ausnutzung von Funkressourcen von Vorteil ist.
-
Das
erfindungsgemäße Verfahren
ist oben anhand des UMTS-Systems
als Beispiel beschrieben. Eine Nachrichtenkopf-Datenfeldkomprimierung gemäß der ROHC
ist jedoch nicht an das UMTS-System gebunden, sondern kann bevorzugt
auf jedes Telekommunikationssystem angewendet werden, das IP-Datenpakete überträgt. Das
erfindungsgemäße Verfahren
kann bevorzugt beispielsweise zur Unterstützung von Entwicklungsprojekten
auf dem Gebiet der Mobilfunksysteme der zweiten Generation, wie beispielsweise
GERAN (GSM Edge Radio Access Network), angewendet werden.
-
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.