-
HINTERGRUND
DER ERFINDUNG
-
Die
Erfindung betrifft den Transfer von IP-(Internet Protocol)-Daten in einem Telekommunikationssystem
und insbesondere in einem System, das die Komprimierung von IP-Datenkopffeldern
bereitstellt.
-
Die
sich schnell entwickelnde IP-Technologie hat das Einsatzgebiet verschiedener
IP-basierter Anwendungen über
den herkömmlichen
Internetdatentransfer hinaus ausgedehnt. Insbesondere kam es zu einer
rapiden Entwicklung IP-basierter Telefonanwendungen, die dazu führt, dass
ein ständig
wachsender Anteil des Transferwegs der Anrufe mit Hilfe von IP-Technologie
implementiert werden kann. Insbesondere bilden mobile Kommunikationsnetzwerke einen
Bereich, bei dem davon ausgegangen wird, dass die IP-Technologie
eine Fülle
von Vorteilen bieten wird, da zusätzlich zu herkömmlichen
Sprachdiensten, die mit Hilfe verschiedener IP-basierter Sprachanwendungen
bereitgestellt werden könnten, mobile
Kommunikationsnetzwerke zunehmend verschiedene Datendienste, wie
beispielsweise Browsen im Internet und elektronische Maildienste
anbieten werden, welche in der Regel vorteilhafterweise als paketvermittelte
IP-basierte Dienste hergestellt werden. Daher könnten IP-Schichten, die an
die Protokolle des mobilen Kommunikationssystems angepasst sind,
zum Bereitstellen sowohl von Audio/Videodiensten als auch verschiedener
Datendienste verwendet werden.
-
In
mobilen Kommunikationssystemen ist es insbesondere von Bedeutung,
dass die begrenzten Funkressourcen so effizient wie möglich genutzt
werden können.
Dies macht die Verwendung von IP-Protokollen auf den Funkschnittstellen
andererseits komplizierter, da der Anteil verschiedener Kopffelder in
den zu übertragenden
Daten in IP-basierten Protokollen groß ist und in der Folge der
Anteil, der für
die Nutzlast übrig
bleibt, gering ist. Aufgrund der beschränkten Funkressourcen muss dieses
Verhältnis verringert
werden. Zu diesem Zweck wurden Kopffeld-Komprimierungsverfahren
entwickelt, wie beispielsweise ROHC (Robust Header Compression) von
IETF (Internet Engineering Task Force). In dieser Anmeldung wird
der Begriff „Nutzlast" für Daten
verwendet, welche für
die eingesetzte Anwendung im Wesentlichen nützlich sind, und „Kopffelder" wird für Felder
verwendet, die zu der Nutzlast hinzugefügt werden, indem niedrigere
Schichten sich um den Datentransfer der Anwendung kümmern. In
Sprachanwendungen umfasst die Nutzlast beispielsweise Sprachproben
und Steuerdaten, wobei es sich bei den Kopffeldern in der Netzwerkschicht
beispielsweise um RTP-, UDP- und IP-Kopffelder handelt.
-
Die
vorgeschlagenen Komprimierungsverfahren erfordern das Übertragen
unkomprimierter Kopffelder zu Beginn einer Verbindung und möglicherweise
auf periodische Weise. ROHC verwendet mehrere Komprimierungszustände, wobei
die Effizienz der Komprimierung zunimmt, wenn der Betrieb zu einem
höheren
Zustand übergeht.
Ein grundlegendes Prinzip besteht darin, dass die Komprimierung
immer in dem höchstmöglichen
Zustand ausgeführt
wird, vorausgesetzt jedoch, dass der Komprimierer ausreichend Gewissheit
darüber
hat, dass der Dekomprimierer über
genügend
Informationen über das
Ausführen
der Dekomprimierung in demselben Zustand verfügt.
-
Eine
logische Verbindung ist in der Regel einer Konvergenzeinheit zugeordnet,
die die Übertragung
des Anwendungschichtdatenstroms zu dem mobilen Kommunikationsnetzwerk
einerseits und zu der Konvergenzeinheit des RNC andererseits bereitstellt,
wobei die logische Verbindung zur Übertragung von IP-Paketen zu der physikalischen
Schicht verwendet wird. Gemäß den Standards
des Mobilkommunikationssystems UMTS (Universal Mobile Telecommunications
System) der dritten Generation verwendet die Schicht des Paketdatenkonvergenzprotokolls
(PDCP) immer eine Funkstreckensteuer-(RLC)-Schicht-Verbindung zum Übertragen
eines Datenstroms. Wenn die RLC-Verbindung und somit die logische
Verbindung zugewiesen wird, werden Parameter verhandelt, die die
Eigenschaften der logischen Verbindung, wie beispielsweise die Dienstgüte (Quality
of Service, QoS) der Verbindung bestimmen.
-
Bei
der Übertragung
insbesondere von Voice-over-IP (VoIP) benötigen Kopffelder möglicherweise
erheblich mehr Bits als die Nutzlast. Einige der zu übertragenden
Kopffelder können
komprimiert werden und daher kann die Größe der Kopfteile in den zu übertragenden
IP-Paketen erheblich variieren. Da die Nutzlast der IP-Pakete und
die auf verschiedene Weise komprimierten Kopffelder auf derselben
logischen Verbindung entsprechend den verhandelten Parameter übertragen
werden, wird in der Datenübertragung
keine optimale Ausnutzung der Funkressourcen erreicht. Ein großer Teil
der Kapazität
muss insbesondere für
einen IP-Paketdatenstrom reserviert werden, der von einem für UMTS entwickelten
Breitbandsprachcode WB AMR (Wideband Adaptive Multirate Codec) erzeugt
wird, was zu unökonomischer
Verwendung des Codebaums führt.
-
Mit
Bezug auf den Stand der Technik wird der folgende Hintergrund als
nützlich
zum Verständnis der
Erfindung angesehen:
WO 00/76112 betrifft eine Technik zum
Codieren von Kanälen
für EDGE-Netzwerke
und offenbart ein Verfahren, in dem eine erste Einheit von zu codierenden Bits
und eine zweite Einheit von Bits, die uncodiert bleiben sollen,
zu einem einzigen codierten Block codiert werden. Außerdem kann
ein neuer Kopf übertragenen
Sprachpaketen zugefügt
werden, wobei der neue Kopf ein Fehlerfeld enthält, das abhängig nur von den im Kopf enthaltenen
Bits erzeugt wird.
-
WO
99/66736 offenbart ein Trägerverwaltungsverfahren
für Mobiltelekommunikationssysteme der
dritten Generation. Ein Datenstrom von der L3-Schicht wird in mehrere
Komponentendatenströme
gedemultiplext, wodurch jeder Komponentendatenstrom eine spezifische
Dienstgüte-Anforderung aufweisen
kann. Die Datenströme
werden in Gruppen angeordnet, wobei die Dienstgüte-Anforderung eines Datenstroms
in einer Gruppe ähnlich
der anderen Datenströme
in der Gruppe ist. Die Datenströme werden
zum Ausgeben an die MAC-Schicht gruppenweise gemultiplext. Die Kopfkomprimierung
ist eine Verarbeitungsoption für
die Datenströme.
-
Gionardi,
A. et al. "Improved
header compression for TCP/IP over wireless links", ELECTRONIC LETTERS,
Bd. 36, Nr. ISSUE 23, 9. November 2000, S. 1958–1960, XP002950230, offenbart
Kopfkomprimierungsverfahren für
TCP/IP-Datentransfer über
drahtlose Strecken. Zwei neue Kopfkompressionsschemata werden vorgeschlagen.
-
KURZE BESCHREIBUNG
DER ERFINDUNG
-
Es
ist daher eine Aufgabe der Erfindung, ein Verfahren und ein Gerät bereitzustellen,
die das Verfahren implementieren, welches es IP-Daten ermöglicht,
effizienter über
die Funkschnittstelle übertragen zu
werden. Die Aufgaben der Erfindung werden mit einem Verfahren, einer
Mobilstation und einer Funknetzwerksteuerung erzielt, welche durch
das gekennzeichnet sind, was in den unabhängigen Ansprüchen dargelegt
wird. Die bevorzugten Ausführungsformen
der Erfindung sind in den abhängigen Ansprüchen offenbart.
-
Die
grundlegende Idee der Erfindung besteht darin, dass Kopffelder von
zu übertragenden
IP-Paketen von der Nutzlast getrennt werden, wonach auf der Basis
verschiedener Kontexte komprimierte Kopffelder auf getrennten logischen
Verbindungen, die ihnen zugewiesen sind, übertragen werden. Ein Kontext
stellt die gegenwärtigen
Eigenschaften der Komprimierung, d.h. der Komprimierung der Kopffelder,
dar. Es sei darauf hingewiesen, dass auch ein Komprimierungskontext
möglich
ist, nach dem die Kopffelder überhaupt
nicht komprimiert werden. An dem Empfangsende können die auf den verschiedenen
logischen Verbindungen empfangenen komprimierten Kopffelder rekonstruiert
und mit den Nutzlasten kombiniert werden. Der Begriff „logische
Verbindung" bezieht
sich auf eine Datenverbindungsschicht-(L2)-Verbindung, die zum Übertragen
von Daten zwischen einer Mobilstation und einem Paketfunknetzwerk
verwendet wird.
-
Dies
stellt insofern einen erheblichen Vorteil dar, als logische Verbindungen
für verschiedene Merkmale
zu verschieden komprimierten Kopffeldern zugeordnet werden können, was
eine optimalere Übertragung
von Daten und eine effizientere Ausnutzung der Funkkanalkapazität in einem
drahtlosen Telekommunikationssystem ermöglicht.
-
Gemäß einer
bevorzugten Ausführungsform der
Erfindung werden logische Verbindungen Kopffeldern verschiedener
Komprimierungszustände
zugewiesen. Dies ermöglicht
es Kopffeldern, die zu einem unterschiedlichen Umfang komprimiert
wurden, auf verschiedenen Arten von logischen Verbindungen übertragen
zu werden.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
Im
Folgenden wird die Erfindung ausführlicher in Verbindung mit
bevorzugten Ausführungsformen
beschrieben und mit Bezug auf die beigefügten Zeichnungen, in denen:
-
1 ein
Blockdiagramm ist, das eine schematische Ansicht der Struktur von
UMTS zeigt;
-
2a und 2b Protokollstapel
eines UMTS-Paketdatendienstes
zur Steuerung des Signalisierens und der Sendung von Nutzerdaten
veranschaulicht;
-
3 ein
Blockdiagramm ist, das zwischen verschiedenen Komprimierungszuständen von ROHC
stattfindende Übergänge darstellt;
-
4 RLC-
und PDCP-Schichten in einem System gemäß einer bevorzugten Ausführungsform der
Erfindung darstellt; und
-
5 ein
Flussdiagramm ist, das ein Verfahren gemäß einer bevorzugten Ausführungsform
der Erfindung darstellt.
-
AUSFÜHRLICHE
BESCHREIBUNG DER ERFINDUNG
-
Im
Folgenden wird das erfindungsgemäße Verfahren
mit Hilfe eines Beispiels beschrieben, das sich auf UMTS bezieht.
Die Erfindung kann jedoch in jedem Telekommunikationssystem verwendet
werden, das die Komprimierung von Kopffeldern von zu übertragenden
IP-Paketen einsetzt.
Das erfindungsgemäße Verfahren
kann vorteilhafterweise zum Beispiel in Projekten für die weitere
Verbesserung von als Mobilkommunikationssysteme der zweiten Generation
bekannten Systemen angewendet werden, beispielsweise GERAN (GSM/Edge
Radio Access Network).
-
1 umfasst
nur die UMTS-Systemblocks, die zur Beschreibung der Erfindung wesentlich
sind, einem Fachmann wird jedoch ersichtlich sein, dass ein herkömmliches
Mobilkommunikationssystem auch andere Funktionen und Elemente, die
hier nicht im Detail beschrieben werden müssen, umfasst. Die Hauptteile
des mobilen Kommunikationssystems sind ein Kernnetzwerk CN und ein
UMTS Terrestrial Radio Access Network UTRAN, welche das feste Netzwerk
für das
Mobilkommunikationssystem bilden, und eine Mobilstation oder ein
Nutzergerät
UE. Die Schnittstelle zwischen CN und UTRAN wird als Iu bezeichnet
und die Luftschnittstelle zwischen UTRAN und UE als Uu.
-
UTRAN
umfasst in der Regel eine Vielzahl von Funknetzwerkuntersystemen
RNS, wobei die Schnittstelle zwischen den Untersystemen als Iur (nicht
gezeigt) bezeichnet wird. RNS umfasst eine Funknetzwerksteuerung
RNC und eine oder mehrere Basisstationen BS, die auch als Knoten
B bezeichnet werden. Die Schnittstelle zwischen RNC und BS wird als
Iub bezeichnet. Eine Basisstation BS ist in der Regel für die Funkwegimplementierung
verantwortlich, wobei die Funknetzwerksteuerung RNC mindestens Folgendes
verwaltet: Funkressourcenverwaltung, Steuerung der Übergabe
zwischen den Zellen, Stromanpassung, Zeitgebung und Synchronisierung,
Paging des Nutzergeräts.
UE und BS umfassen Sender/Empfänger,
die die Datenübertragung über den Funkweg
bereitstellen.
-
Das
Kernnetzwerk CN besteht aus einer Infrastruktur, die zu den mobilen
Kommunikationssystemen gehört
und UTRAN-extern ist. In dem Kernnetzwerk wird ein Mobilschaltzentrum/Besucherpositionsregister
3G-MSC/VLR an ein Heimpositionsregister HLR und vorzugsweise ebenfalls
an einen Dienststeuerpunkt SCP eines intelligenten Netzwerks angeschlossen.
Das Heimpositionsregister HLR und das Besucherpositionsregister
VLR umfassen Informationen über
mobile Teilnehmer: Das Heimpositionsregister HLR umfasst Informationen über alle
Teilnehmer in dem mobilen Kommunikationsnetzwerk und die Dienste,
an denen sie teilnehmen; und das Besucherpositionsregister VLR umfasst
Informationen über
Mobilstationen, die den Bereich eines bestimmten Mobilschaltzentrum
MSC besuchen. Eine Verbindung mit einem Dienstknoten eines Paketfunksystems
3G-SGSN (Serving GPRS Support Node) wird über eine Schnittstelle Gs' und zu einem festen
Telefonnetzwerk PSTN/ISDN über
ein Gatewaymobilschaltzentrum GMSC (Gateway MSC, nicht gezeigt)
geformt. Die Verbindung von sowohl den Mobilschaltzentren 3G-MSC/VLR
als auch den Dienstknoten 3G-SGSN zu dem Funknetzwerk UTRAN (UMTS
Terrestrial Radio Access Network) wird über die Schnittstelle Iu aufgebaut.
Es sei darauf hingewiesen, dass UMTS so ausgelegt ist, dass das Kernnetzwerk
CN identisch beispielsweise mit dem Kernnetzwerk von GSM sein kann,
wobei in diesem Fall keine Notwendigkeit besteht, die gesamte Netzwerkinfrastruktur
neu aufzubauen.
-
UMTS
umfasst somit ein Paketfunksystem, das zu einem großen Ausmaß gemäß einem GPRS-System,
das an ein GSM-Netzwerk angeschlossen ist, implementiert wird, was
die Bezugnahme auf GPRS-Systeme in den Bezeichnungen der Netzwerkelemente
erklärt.
Das UMTS-Paketfunksystem kann mehrere Gateway- und Dienstknoten
umfassen, wobei mehrere Dienstknoten 3G-SGSN in der Regel an einen
Gatewayknoten 3G-GGSN angeschlossen sind. Der Dienstknoten 3G-SGSN
ist für das
Erkennen von Mobilstationen, welche zu Paketfunkverbindungen in
seinem Dienstbereich in der Lage sind, für das Übertragen und Empfangen von Datenpaketen
von den Mobilstationen und für
das Überwachen
der Positionen der Mobilstationen in seinem Dienstbereich verantwortlich.
Außerdem
befindet sich der Dienstkonten 3G-SGSN über eine Schnittstelle Gr in
Kontakt mit dem Heimpositionsregister HLR. Datensätze, die
den Paketfunkdienst entsprechen und Teilnehmerspezifische Paketdatenprotokollinhalte
umfassen, werden ebenfalls in dem Heimpositionsregister HLR gespeichert.
-
Der
Gatewayknoten 3G-GGSN fungiert als Gateway zwischen dem UMTS-Netzwerkpaketfunksystem
und dem externen Datennetzwerk PDN (Packet Data Network). Externe
Datennetzwerke enthalten das UMTS- oder GPRS-Netzwerk eines anderen Netzwerkbetreibers,
des Internets, eines X.25-Netzwerks oder eines privaten Local-Area-Netzwerks. Der
Gatewayknoten 3G-GGSN kommuniziert über die Schnittstelle Gi mit
den Datennetzwerken. Die zwischen dem Gatewayknoten 3G-GGSN und
dem Dienstknoten 3G-SGSN übertragenen
Datenpakete werden immer gemäß dem Gateway-Tunnelprotokoll GTP
eingekapselt. Der Gatewayknoten 3G- GGSN umfasst außerdem die Adressen von PDP-(Packet Data
Protocol)-Kontexten, die für
die Mobilstationen aktiviert sind, und ihre Routinginformationen,
d.h. 3G-SGSN-Adressen.
Die Routinginformationen werden somit verwendet, um die Datenpakete
zwischen den externen Netzwerken und dem Dienstknoten 3G-SGSN zu
verbinden. Das Netzwerk zwischen dem Gatewayknoten 3G-GGSN und dem
Dienstknoten 3G-SGSN setzt ein IP-Protokoll, vorzugsweise das IPV6
(Internet Protocol Version 6) ein.
-
Die 2a und 2b zeigen
UMTS-Protokollstapel, die für
die Steuersignalgebung (Steuerebene) und die Übertragung von Nutzerdaten
(Nutzerebene) in dem von UMTS bereitgestellten Paketfunkdienst verwendet
werden. 2a zeigt den für
die Steuersignalgebung zwischen den Mobilstationen MS und dem Kernnetzwerk
CN verwendeten Protokollstapel. Die Mobilitätsverwaltung MM, die Anrufsteuerung
CC und die Sitzungsverwaltung SM der Mobilstation MS werden auf
den höchsten
Protokollschichten zwischen der Mobilstation MS und dem Kernnetzwerk
CN dergestalt signalisiert, dass die Basisstationen BS und die Funknetzwerksteuerung RNC,
die dazwischen angeordnet sind, gegenüber dieser Signalgebung transparent
sind. Die Funkressourcenverwaltung von Funkstrecken zwischen Mobilstationen
MS und Basisstationen BS wird mittels eines Funkressourcenverwaltungssystems
RRM ausgeführt,
welches Steuerdaten von der Funknetzwerksteuerung RNC zu den Basisstationen
BS übermittelt.
Diese der allgemeinen Verwaltung eines Mobilsystems zugeordneten
Funktionen bilden eine Gruppe, die Kernnetzwerkprotokolle (CN-Protokolle) genannt
werden, auch bekannt als Nicht-Zugriffs-Stratum.
Dementsprechend wird die Signalgebung bezüglich der Funknetzwerksteuerung
zwischen der Mobilstation MS, der Basisstation BS und der Funknetzwerksteuerung
RNC auf Protokollschichten ausgeführt, die Funkzugriffsnetzwerkprotokolle
(RAN-Protokolle),
d.h. Zugriffs-Stratum genannt werden. Diese enthalten Transferprotokolle
der untersten Schicht, deren Steuersignalgebung für die Weiterverarbeitung
auf den höchsten
Pegeln übertragen
wird. Die wichtigste der höheren
Zugriffs-Stratum-Schichten ist das Funkressourcensteuerprotokoll
RRC, das beispielsweise für
das Herstellen, Konfigurieren, Ausrichten, Erhalten und Freigeben
logischer Verbindungen zwischen der Mobilstation MS und dem Funknetzwerk
UTRAN und für
das Übermitteln
von Steuerinformationen von dem Kernnetzwerk CN und dem Funknetzwerk
RAN zu den Mobilstationen MS verantwortlich ist. Außerdem ist
das Funkressourcensteuerprotokoll RRC verantwortlich dafür, gemäß den Anweisungen
des Funkressourcenverwaltungssystems ARM, einer Nutzerendgerätverbindung
beispielsweise in einer anwendungsbasierten Kapazitätszuweisung
ausreichend Kapazität zuzuweisen.
-
UMTS-paketvermittelte
Nutzerdaten werden mittels eines in 2b gezeigten
Protokollstapels übermittelt.
An der Schnittstelle Uu zwischen dem Funknetzwerk UTRAN und der
Mobilstation MS wird Datenübertragung
geringeren Niveaus auf der physikalischen Schicht gemäß einem
WCDMA- oder TD-CDMA-Protokoll
ausgeführt.
Eine MAC-Schicht oberhalb der physikalischen Schicht übermittelt
Datenpakete zwischen der physikalischen Schicht und einer RLC-(Radio
Link Control)-Schicht, wobei die RLC-Schicht die Verwaltung der
Funkstrecken der verschiedenen logischen Verbindungen handhabt. Die
RLC-Funktionen umfassen beispielsweise die Segmentierung der zu übertragenden
Nutzerdaten (RLC-SDU) in ein oder mehrere RLC-Datenpakete (RLC-PDU).
Die IP-Kopffelder in Datenpaketen (PDCP-PDU) der PDCP-Schicht oberhalb
RLC kann optional komprimiert werden. Die PDCP-PDUs werden dann
ar. RLC übergeben
und sie entsprechen einem RLC-SDU. Die Nutzerdaten und die RLC-SDUs
werden segmentiert und in RCL-Rahmen übermittelt, welchen Adress-
und Verifizierungsinformationen, die für die Datenübertragung wesentlich sind,
zugefügt
werden. Die RLC-Schicht kümmert
sich auch um die Wiederübertragung
beschädigter
Rahmen. PDCP, RLC und MAC bilden die Datenstreckenschicht. Der Dienstknoten
3G-SGSN ist für
das Routen von Datenpaketen verantwortlich, welche von der Mobilstation
MS kommen, durch das Funknetzwerk RAN zu dem korrekten Gatewayknoten
3G-GGSN. Diese Verbindung verwendet Tunnelprotokolle GTP, welche alle über das
Kernnetzwerk zu übertragende
Nutzerdaten und Signalgebung einkapselt und tunnelt. Das GTP-Protokoll
läuft auf
dem von dem Kernnetzwerk verwendeten IP.
-
Im
Folgenden wird ein Kopffeldkomprimierungsverfahren ROHC einer bevorzugten
Ausführungsform
der Erfindung beschrieben. Hinsichtlich einer detaillierteren Beschreibung
des in Frage stehenden Komprimierungsverfahrens wird auf einen unvollendeten
Internetentwurf „Robust
Header Compression (ROHC)",
Version 4, 11.10.2000, Bezug genommen.
-
Eine
der zugrundeliegenden Ideen der ROHC-Entwicklungsarbeit ist, dass es zwischen
den zahlreichen Kopffeldern, die zum Übermitteln von Datenpaketen
verwendet werden, sehr viel Redundanz gibt, nicht nur innerhalb
der Datenpakete, sondern auch zwischen ihnen. Anders ausgedrückt ändert sich
ein Großteil
der Kopffeldinformationen während
der Übermittlung
der Datenpakete überhaupt nicht,
so dass die Informationen leicht zu rekonstruieren sind, selbst
wenn sie überhaupt nicht
gesendet werden. Nur ein geringer Teil der Kopffelder enthält Informationen,
denen während
der Komprimierung besondere Aufmerksamkeit gewidmet werden muss.
-
In
den verschiedenen Komprimierungsverfahren wird in der Regel ein
Kontext sowohl für
den Komprimierer als auch für
den Dekomprimierer definiert, wobei es sich bei dem Kontext um einen
Zustand handelt, gemäß dem der
Komprimierer das zu übermittelnde
Kopffeld komprimiert, und der Dekomprimierer das empfangene Kopffeld
dekomprimiert. Der Kontext umfasst in der Regel eine unkomprimierte
Version des vorherigen (von dem Komprimierer) gesendeten oder des
(von dem Dekomprimierer) über
die Datenübertragungsverbindung
empfangenen Kopffelds. Außerdem
kann ein Kontext verschiedene Daten umfassen, die den Datenpaketstrom kennzeichnen,
wie beispielsweise Sequenznummern und Zeitstempel der Datenpakete.
Der Kontext umfasst somit in der Regel sowohl statische Informationen,
die für
den gesamten Datenstrom dieselben bleiben, als auch dynamische Informationen,
die sich während
des Datenpaketstroms ändern,
wenn auch oftmals gemäß eines
vorbestimmten Musters. Der Kontext umfasst Informationen über den
Komprimierungszustand und den Komprimierungsmodus.
-
ROHC
umfasst mehrere Komprimierungszustände, wobei die Effizienz der
Komprimierung zunimmt, wenn der Betrieb zu einem höheren Zustand übergeht.
ROHC versucht immer, die effizienteste mögliche Komprimierung zu verwenden,
vorausgesetzt jedoch, dass vor Eintritt in einen neuen Zustand bestätigt wird,
dass die Betriebssicherheit dieses Zustands ausreicht. Bei den Komprimierungszuständen, die
von ROHC in Verbindung mit der Komprimierung der Kopffelder von
IP (Internet Protocol), UDP (User Datagram Protocol) und RTP (Real-Time Protocol) verwendet
werden, handelt es sich um Initiation/Refresh (IR), First Order
(FO) und Second Order (SO), wobei die Übergänge zwischen den Zuständen in
dem Diagramm aus 3 beschrieben werden. Der IR-Zustand wird zum
Herstellen eines Kontexts für
den Dekomprimierer oder zum Wiedergewinnen in einer Fehlersituation
verwendet. Der Komprimierer geht zu dem IR-Zustand über, wenn
die Komprimierung von Kopffeldern beginnt, entweder auf Anforderung
des Dekomprimiers oder weil ein Aktualisierungstimer ausläuft. In
dem IR-Zustand sendet der Komprimierer IR-Kopffelder in einem unkomprimierten
Zustand. Nach bestätigtem
Empfang von Aktualisierungsinformationen durch den Dekomprimierer versucht
der Komprimierer in einen höheren
Zustand überzugehen.
Faktoren, die eine Auswirkung auf den Übergang von einem Komprimierungszustand
zu einem anderen haben, sind Variationen in aufeinanderfolgenden
Kopfelementen, positive und negative Bestätigungen, die von dem Dekomprimierer
empfangen werden, und in Abwesenheit von Bestätigung, das Auslaufen von vorbestimmten
Zyklenzählern. Analog
ist ein Übergang
von höheren
Komprimierungszuständen
zu niedrigeren möglich,
wenn notwendig.
-
Der
FO-Zustand wird verwendet, um den Empfänger über etwaige Unregelmäßigkeiten
in den Kopffeldern des Datenpaketflusses zu informieren. Nach dem
IR-Zustand wird der Komprimierer in dem FO-Zustand in einer Situation
betrieben, in der die Kopfelemente kein gleichmäßiges Muster bilden (anders
ausgedrückt,
aufeinanderfolgende Kopffelder ändern
sich zufällig
und die Änderungen
können nicht
vorhergesehen werden) oder der Komprimierer nicht sicher sein kann,
dass der Dekomprimierer Parameter empfangen hat, die ein gleichmäßiges Muster
für die
Kopffelder definieren. Dies ist eine typische Situation beispielsweise,
wenn die Übertragung
von Sprache initiiert wird, insbesondere während der ersten Sprachbursts.
In dem FO-Zustand sendet der Komprimierer komprimierte FO-Kopffelder.
Wenn die Kopffelder ein gleichmäßiges Muster
bilden und nachdem der Empfang der gleichmäßigen Kopffeldmuster durch
den Dekomprimierer bestätigt
wurde, versucht der Komprimierer erneut, in einen höheren Zustand überzugehen.
Die Datenpakete in dem FO-Zustand umfassen in der Regel Kontextaktualisierungsinformationen,
so dass eine erfolgreiche Dekomprimierung somit erfordert, dass
auch aufeinanderfolgende FO-Kopffelder erfolgreich übermittelt werden.
In der Folge ist der Erfolg des Dekomprimierungsprozesses anfällig für verlorene
oder beschädigte
FO-Zustandspakete.
-
In
dem FO-Zustand ist die Komprimierung optimal. Die Kopffelder bilden
ein gleichmäßiges Muster,
das der Komprimierer mit Hilfe von komprimierten FO-Kopffeldern
beschreibt, welche in der Praxis Sequenznummern der Datenpakete
sind. Informationen über
die Parameter, die das gleichmäßige Kopffeldmuster
definieren, werden zu dem Dekomprimierer bereits in dem FO-Zustand übertragen und
auf der Basis dieser Parameter und der empfangenen Sequenznummern
ist der Dekomprimierer in der Lage, die originalen zu extrapolieren.
Da die Datenpakete, die in dem FO-Zustand übertragen wurden, in der Praxis
unabhängig
voneinander sind, ist die Wahrscheinlichkeit von Fehlern in der
Dekomprimierung ebenfalls gering. Wenn die Kopffelder kein gleichmäßiges Muster
mehr bilden, bewegt sich der Komprimierer zurück in den FO-Zustand.
-
Auch
für die
Dekomprimierung werden drei verschiedene Zustände definiert, wobei die Zustände dem
für den
Dekomprimierer definierten Kontext zugeordnet sind. Der Betrieb
des Dekomprimierers beginnt immer in dem niedrigsten Zustand, in
dem noch kein Kontext definiert worden ist (kein Kontext). In diesem
Zustand verfügt
der Dekomprimierer noch über
keine Datenpakete. Wenn der Dekomprimierer das erste Datenpaket
dekomprimiert hat, welches sowohl statische als auch dynamische
Kontextinformationen umfasst, kann der Dekomprimierer den mittleren
Zustand (statischer Kontext) überspringen
und direkt in den höchsten
Zustand (voller Kontext) eintreten. Aufgrund mehrerer Fehlerzustände, die
in dem höchsten
Zustand auftreten, bewegt sich der Dekomprimierer in dem mittleren
Zustand, aber selbst ein einzelnes erfolgreich dekomprimiertes Datenpaket
bewegt den Dekomprimierer zurück
in den höchsten
Zustand.
-
Zusätzlich zu
den verschiedenen Komprimierungszuständen sind drei verschiedene
Betriebsmodi für
ROHC definiert: unidirektionaler Modus (U-Modus), bidirektionaler
optimistischer Modus (O-Modus) und bidirektionaler betriebssicherer
Modus (R-Modus). Jeder der oben beschriebenen Komprimierungszustände (IR,
FO, SO) funktioniert in jedem Modus, aber jeder Modus funktioniert
in jedem Zustand auf seine eigene Weise und trifft die Entscheidungen über die Übergänge zwischen
den Zuständen
auf seine eigene Weise. Die Wahl der Betriebsmodi für eine bestimmte
Komprimierungssituation hängt
von dem Parametern der zu verwendenden Datenübertragungsverbindung ab, wie
beispielsweise der Möglichkeit,
einen Rückkehrkanal
zu verwenden, der Wahrscheinlichkeit von Fehlern und ihrer Verteilung,
der Auswirkungen von Variationen auf Kopffeldgrößen usw.
-
Die
drei Betriebsmodi von ROHC und die drei Komprimierungszustände bilden
verschiedene Betriebssituationen bezüglich der Komprimierung von
Kopffeldern, wobei jede Situation erfordert, dass der Betrieb des
Komprimierers und Dekomprimierers sowie die Übertragung von Paketen zwischen
ihnen definiert ist. ROHC verwendet verschieden Pakete für die verschiedenen
Zwecke, die die verschiedenen Situationen erfordern. Gegenwärtig gibt
es sechs verschiedene Datenpaketarten, die für ROHC definiert sind, von
denen vier für
die Übertragung
von dem Komprimierer zu dem Dekomprimierer und zwei als Rückkehrkanaldatenpakete
von dem Dekomprimierer zu dem Komprimierer verwendet werden. Obwohl
die Anzahl von zu verwendenden Datenpaketen sich in Zukunft ändern kann,
ist ein gemeinsames Merkmal aller Datenpaketarten, dass jedes Datenpaket
mit einer Kontextkennzeichnung CID versehen werden kann, die den
in jedem speziellen Fall zu verwendeten Kontext definiert, bevor
ein Paket an den Übertragungsweg
gesendet wird.
-
4 veranschaulicht
RLC- und PDCP-Schichten in UMTS gemäß einer bevorzugten Ausführungsform
der Erfindung. Jedem PDP-Kontext wird eine PDCP-Einheit zugewiesen.
Der sendende PDCP und das empfangende PDCP umfassen ein Komprimierer/Dekomprimierer-Paar
zum Komprimieren der zu übertragenden
Datenpakete und zum Dekomprimieren der empfangenen Datenpakete.
Die PDCP-Einheit
kann einen oder mehrere Kopffeldkomprimierungsalgorithmen verwenden
oder muss nicht notwendigerweise einen verwenden. Mehrere PDCP-Einheiten können auch
einen gemeinsamen Algorithmus verwenden. In UMTS findet die Komprimierung
der Kopffelder der zu übertragenden
Datenpakete und die Dekomprimierung der empfangenen Datenpakete
somit auf der Konvergenzprotokollschicht PDCP statt. Zusätzlich zu
dem oben beschriebenen ROHC unterstützt PDCP vorzugsweise andere
Komprimierungsalgorithmen, wie beispielsweise den Algorithmus, der
RFC2507 von IETF entspricht, wobei eine Komprimierung auch mehrere Kontexte
umfassen kann.
-
Die
PDCP-Einheiten kann auf mehrere RLC-Einheiten abgebildet sein, was
es ermöglicht, dass
mehrere logische Verbindungen LC1-LC3 einer PDCP-Einheit angeboten
werden. Getrennte logische Verbindungen LC1-LC3 werden der Nutzlast und
den verschieden komprimierten (verschiedene Kontexte) Kopffelder
zugewiesen. Die Nutzlast und die Kopffelder der zu übertragenden
IP-Pakete werden getrennt und nach der Komprimierung werden die
verschieden komprimierten Kopffelder auf getrennten logischen Verbindungen
LC1-LC3 übertragen.
Dies ermöglicht
es der PDCP-Einheit, getrennte logische Verbindungen für auf der
Basis verschiedener Kontexte (mindestens zwei hauptsächlich verschiedene
Komprimierungszustände
und/oder Modi) komprimierte Kopffelder zu versenden. Die Nutzlast kann
auch mittels mehrerer getrennter logischer Verbindungen übertragen
werden.
-
Gemäß einer
bevorzugten Ausführungsform der
Erfindung werden getrennte logische Verbindungen den verschiedenen
Komprimierungszuständen zugewiesen.
In der bevorzugten Ausführungsform wird
LC1 den Kopfelementen in dem Initiierungs-/Auffrischungszustand
zugewiesen, LC2 der Nutzlast und LC3 den FO/SO-Kopffeldern der ersten und
zweiten Zustände.
Dies ermöglicht
es, dass unkomprimierte Initiierungs-/Auffrischungszustandskopffelder
von den komprimierten Kopffeldern getrennt werden. Es ist außerdem möglich, dass
eine getrennte Verbindung zum Signalisieren von Daten zugewiesen
wird.
-
Anders
als in 4 kann ein PDP-Kontext zum Übertragen von Daten verschiedener
Anwendungen verwendet werden, in welchem Fall die Datenströme auf der
PDCP-Schicht getrennt
werden müssen
und sie müssen
getrennte Komprimierungskontexte aufweisen. Grundsätzlich ist
es auch möglich,
die PDCP-Schicht betriebsmäßig so zu
implementieren, dass mehrere PDP-Kontexte auf der PDCP-Schicht gemultiplext
werden, wodurch eine RLC-Einheit der RLC-Schicht Daten von mehreren verschiedenen
Anwendungen empfängt.
In diesem Fall können
verschieden komprimierte Kopffelder aus getrennten logischen Verbindungen übertragen
werden.
-
5 ist
ein Flussdiagramm, das ein Verfahren gemäß einer bevorzugten Ausführungsform
der Erfindung darstellt. Ein PDP-Kontext wird zwischen der Mobilstation
UE und dem UMTS-Netzwerk aktiviert (501) durch die Initiative
von höheren
Kernnetzwerkprotokollen. In Verbindung mit der Aktivierung des PDP-Kontexts
wird den RRC-Einheiten ein Protokolltyp auf Netzwerkebene angezeigt,
auf dessen Basis die RRC-Einheiten, die den in der PDCP-Einheit
zu verwendenden Komprimierungsalgorithmus und die den Algorithmus
leitenden Parameter auswählen
(502). Die zuzuweisenden logischen Verbindungen und ihre
Parameter werden zwischen den RRC-Protokolleinheiten bestimmt (503).
Die Netzwerkfunkressourcenverwaltungseinheit (RRM) schließt, beispielsweise
auf anwendungsspezifischer Basis, wie die logischen Verbindungen
ausgewählt werden
sollen und leitet dann die RRC-Einheit. Die logischen Verbindungen
werden in der Mobilstation UE mittels RRC-Signalgebung von der RNC
bestimmt. Die Parameter werden gemäß den Eigenschaften der zu übertragenden
Daten bestimmt 503, wodurch die Funkressourcen so optimal
wie möglich ausgenutzt
werden. Mindestens verschiedene Funkträgerparameter werden für Kopffelder
reserviert, die verschiedenen Kontexten entsprechen. Dies ermöglicht es,
dass die Größe der Funkrahmen,
die auf den verschiedenen logischen Verbindungen verwendet werden,
angepasst wird. Beispielsweise kann eine logische Verbindung, die
höhere
Bandbreite und ein höheres
Bitfehlerverhältnis
anbietet, unkomprimierten Kopffeldern zugewiesen werden als komprimierten
Kopffeldern.
-
Die
RRC-Einheit kommuniziert mit der PDCP-Einheit über ein PDCP-Steuerdienstzugriffspunkt (PDCP-C-SAP),
der in 4 gezeigt wird, wobei die PDCP-Einheit dann über den
zu verwendenden Komprimierungsalgorithmus informiert wird und die logischen
Verbindungen auf die PDCP-Einheit abgebildet werden 504.
-
Wenn
Daten übertragen
werden, werden die zu übertragenden
Kopffelder und die Nutzlast des Pakets in der Konvergenzeinheit
PDCP getrennt 505. Die Kopffelder werden gemäß dem verhandelten Komprimierungsalgorithmus
und dem Komprimierungskontext komprimiert 506. Anders ausgedrückt handelt
es sich bei dem in Frage stehenden Paket vorzugsweise um ein IP-Paket
und daher werden mindestens das IP-Kopffeld und das TCP- oder UDP-Kopffeld
komprimiert. Wenn eine Echtzeit-Anwendung, die RTP verwendet, betroffen
ist, befindet sich das RTP-Kopffeld ebenfalls unter den zu komprimierenden
Kopffeldern. Der PDCP kontrolliert den Kontext des komprimierten
Kopffelds und überträgt 507 das
komprimierte Kopffeld an eine logische Verbindung, die dem Kontext
entspricht, d.h. vorzugsweise dem Komprimierungszustand. Die Nutzlast wird
auf mindestens einer ihr zugewiesenen logischen Verbindung überragen 507.
-
Die
Kopffelder der empfangenen Daten werden in der Konvergenzeinheit
PDCP gemäß dem ausgewählten Komprimierungsalgorithmus
und dem Komprimierungskontext dekomprimiert 508. Die Kopffelder
und die Nutzlast werden in der Konvergenzeinheit des Empfängers kombiniert 509.
Die Gesamt-IP-Pakete werden auf höheren Ebenen übertragen 510.
-
Die
logischen Verbindungen können
wenn notwendig rekonfiguriert werden. Wenn die Konvergenzprotokolleinheit
entfernt wird, werden die logischen Verbindungen in der Regel freigegeben.
Mehrere logische Verbindungen können
auch der Nutzlast zugeordnet werden, wobei die Verbindungen zum Übertragen
geteilter Nutzlastteile verwendet werden, welche dann beim Empfang
kombiniert werden.
-
Um
sicherzustellen, dass die Daten korrekt kombiniert werden, muss
das Empfangsende mit Pufferung versehen sein, oder andere Maßnahmen müssen getroffen
werden, um die Verzögerungsdifferenzen
von auf verschiedenen logischen Verbindungen übertragenen Daten zu minimieren.
Gemäß einer
bevorzugten Ausführungsform
der Erfindung werden die für
die logischen Verbindungen verwendeten Kanäle synchronisiert. Für den Transfer
von Daten in Echtzeitanwendungen bieten Maßnahmen, die getroffen werden,
um Datensimultaneität
bereitzustellen, eine bessere Lösung
als die Pufferung.
-
Zur
Kombination des Kopffelds und der Nutzlast von ein und demselben
IP-Paket müssen
die logischen Verbindungen einen zuverlässigen Datentransfer bereitstellen,
beispielsweise durch Einsetzen von Sequenznummern oder Bestätigungen.
Auf der anderen Seite ist die Verzögerung in Echtzeitanwendungen
kritisch und daher reicht es aus, die Pakete mit fehlerhaften oder
fehlenden Nutzlasten und/oder Kopffeldern zu erfassen. Solche Pakete
können
dann unübermittelt
bleiben, in welchem Fall die Kopffelder und die Nutzlast verschiedener
Pakete nicht kombiniert werden (509). Für diesen Zweck können die
PDCP-Einheiten von RNC und MS mit Fehlersteuerung versehen sein,
welche auf der Basis erfasster Fehler entscheidet, ob die Daten
zu den oberen Schichten übertragen
werden sollen oder nicht. Eine separate Fehlerprüfung kann für jede logische Verbindung
bereitgestellt werden.
-
Die
Erfindung kann auf den Transfer von Daten in jeder Anwendung angewendet
werden. Die insbesondere von dem WB AMR Code benötigte Kapazität kann wesentlich
reduziert werden, indem die Nutzlast und die Kopffelder auf mehreren
separaten logischen Verbindungen übertragen werden.
-
Die
Erfindung stellt außerdem
einen Vorteil bezüglich
der Verwendung von ROHC bereit. Da die Komprimierung von Daten mehrerer
Anwendungen, die denselben PDP-Kontext verwenden, durch ein und
dieselbe Komprimierungseinheit ausgeführt werden kann, müssen die
verschiedenen Datenströme voneinander
mit verschiedenen Kontextkennzeichnungen CID getrennt werden. Nun
können
die Kopffelder und die Nutzlast verschiedener Anwendungen jedoch
auf getrennten logischen Verbindungen übertragen werden. Dies reduziert
die Verwendung von Funkstellenressourcen, da die CID-Kennzeichnungen
nicht benötigt
werden.
-
Die
Erfindung kann durch Software in der Mobilstation und in der Funknetzwerksteuerung
RNC unter Verwendung ihrer Prozessoren, ihres Speichers und ihrer Schnittstellen
umgesetzt werden. Es können
auch Hardwarelösungen
eingesetzt werden.
-
Für einen
Fachmann ist ersichtlich, dass mit Fortschritt der Technik die Grundidee
der Erfindung auf verschiedene Weisen implementiert werden kann.
Die Erfindung und ihre Ausführungsformen sind
daher nicht auf die oben beschriebenen Beispiele beschränkt, sondern
sie können
innerhalb des Umfangs der Ansprüche
variieren.