DE10031494A1 - Verfahren zum Multiplexen einer Vielzahl von Datenpaketen mehrerer Datenströme innerhalb des PDCP-Protokolls eines UMTS-Funkkommunikationsystems - Google Patents

Abstract

Zum Multiplexen einer Vielzahl von Datenpaketen mehrerer Datenströme (DS300, DS310, DS320, DS330) auf eine zugeordnete RLC-Einheit (radio link control) (RLC600) innerhalb des PDCP-Protokolls (packet data convergence protocol) eines UMTS-Funkkommunikationssystems werden die verschiedenen Datenströme (DS300, DS310, DS320, Ds330) vor ihrem Multiplexen mit unterschiedlichen Datenkompressionsverfahren beaufschlagt. Dabei wird zwischen der jeweiligen Datenkompressionseinheit (CA400, CA410) und der Multiplexereinheit (MUP1) jeweils mindestens eine individuelle Kennzeichnung des jeweilig in die Multiplexereinheit (MUP1) einlaufenden Datenstroms (DS400*, DS410*, DS330) vorgenommen.

Description

Die Erfindung beschäftigt sich mit dem Problem, in einem Funkkommunikationssystem, das insbesondere nach dem UMTS- Standard ausgebildet sein kann, den Austausch von Datenströ­ men zwischen dessen Teilnehmergeräten, insbesondere Mobil­ funkgeräten, und Funknetzwerkeinheiten, insbesondere Funkkon­ trolleinheiten zu verbessern.

Dies wird durch die Merkmale des Anspruchs 1 und/oder durch die Merkmale des Anspruchs 5 gelöst.

Durch dieses Multiplexen einer Vielzahl von Datenpaketen meh­ rerer Datenströme innerhalb des PDCP-Protokolls eines UMTS- Funkkommunikationssystems nach einer der beiden oder zugleich nach beiden Lösungsvarianten wird der Datenaustausch zwischen dessen Teilnehmergeräten und Funkkontrolleinheiten effizien­ ter.

Die Erfindung betrifft weiterhin ein UMTS- Funkkommunikationssystem, in dem der Austausch von Datenströ­ men zwischen dessen Teilnehmergeräten, insbesondere Mobil­ funkgeräten, und Netzwerkeinheiten, insbesondere Funkkon­ trolleinheiten, nach mindestens einem der erfindungsgemäßen Multiplexverfahren vorgenommen wird.

Sonstige Weiterbildungen der Erfindung sind in den Unteran­ sprüchen wiedergegeben.

Die Erfindung und ihre Weiterbildungen werden nachfolgend an­ hand von Zeichnungen näher erläutert.

Es zeigen:

Fig. 1 in schematischer Darstellung den Aufbau eines Funk­ kommunikationssystems, vorzugsweise Mobilfunknet­ zes, das insbesondere nach dem UMTS-Standard auf­ gebaut ist und nach dessen PDCP-Protokoll (packet data convergence protocol) arbeitet,

Fig. 2 in schematischer Darstellung die Protokollschichten zwischen einem Teilnehmergerät, insbesondere einer Mobilfunkstation, einer Basisstation und einer Funkkontrolleinheit (radio network controller) des Funkkommunikationssystems nach Fig. 1, und

Fig. 3 in schematischer Darstellung zwei erfindungsgemäße Multiplexverfahren für eine Vielzahl von Datenpake­ ten mehrerer Datenströme, wie sie im jeweiligen Teilnehmergerät und der jeweiligen Funkkontrollein­ heit einzeln oder zusammen durchgeführt werden.

Elemente mit gleicher Funktion und Wirkungsweise sind in den Fig. 1 mit 3 jeweils mit denselben Bezugszeichen versehen.

In vielen Datenübertragungssystemen werden Daten paketweise erzeugt (bspw. Web-Browsing) und paket-orientiert übertragen. Dazu werde die von einer oder mehreren Applikationen (Pro­ grammen) erzeugten Paketdaten in verschiedenen, nacheinander durchlaufenen Protokollen für die Übertragung in paketorien­ tierten Netzen manipuliert.

Für eine fehlerminimierte, paketorientierte Datenübertragung werden beispielsweise häufig die Protokolle TCP (RFC793, Transmission Control Protocol (TCP), IETF September 1981,
http:/ /www.ietf.org/rfc.html) und IP (RFC791, Internet Pro­ tocol (IP), IETF September 1981,
http:/ /www.ietf.org/rfc.html) verwendet:
Dabei werden die von einer Applikation in einer ersten Ein­ heit des Datenübertragungssystems (Sender) erzeugten Paketda­ ten zusammen mit einer Angabe über das Ziel der Daten zu­ nächst dem TCP Protokoll im Sender übergeben. Den Paketdaten werden vom TCP Protokoll Kontrolldaten (TCP header) vorrange­ stellt, die unter anderem Informationen über die Quell- Applikation, von der die Daten stammen, (Source Port), die Ziel-Applikation, für die die Daten bestimmt sind, (Destina­ tion Port) und Daten zur Fehlerbehebung und -erkennung ent­ halten. Der TCP header ist in (RFC793, Transmission Control Protocol (TCP), IETF September 1981,
http:/ /www.ietf.org/rfc.html (p.14)) beschrieben. Er ist min­ destens 160 bit (5 Oktetts) lang und bildet zusammen mit den Paketdaten das TCP Paket.

Das TCP Paket wird dann an das IP Protokoll im Sender überge­ ben, welches dem TCP Paket IP Kontrolldaten (IP header) vor­ ranstellt, die unter anderem Informationen über die Sender- (Source IP-Address) und Empfänger-Einheit (Destination IP- Address), die geforderte Übertragungsqualität und das zuvor genutzte Protokoll (in diesem Beispiel TCP) enthalten. Der IP header ist in (RFC791, Internet Protocol (IP), IETF Septem­ ber 1981, http:/ /www.ietf.org/rfc.html (p.10)) beschrieben. Er ist mindestens 160 bit (5 Oktetts) lang und bildet zusam­ men mit dem TCP Paket das IP Paket.

Das so zusammengestellte IP Paket, bestehend aus Paketdaten, TCP header und IP header, wird in Abhängigkeit von der in dem Datenübertragungssystem genutzten Übertragungstechnik eventu­ ell über mehrere Systemeinheiten zu der in der Destination IP-Address des IP headers adressierten Ziel-Einheit (Empfän­ ger) übertragen. Im Empfänger entfernt dann zunächst das IP Protokoll den IP header von dem IP Paket und übergibt das so erhaltene TCP Paket dem TCP Protokoll. Dieses entfernt den TCP header und übergibt die so erhaltenen Paketdaten der durch den Destination Port im TCP header gekennzeichneten Ap­ plikation.

Beide hier erwähnten Protokolle (TCP und IP) können die Da­ tenpakete eventuell auch auf andere Weise manipulieren (bei­ spielsweise durch Segmentierung aus einem großen Paket mehre­ re kleinere generieren), jedoch ist hier insbesondere nur das Prinzip der TCP/IP header relevant.

Für Echtzeit-Datenübertragungen werden häufig insbesondere die Protokolle RTP (RFC, Real Time Protocol (RTP), IETF), UDP (RFC768, User Datagram Protocol (UDP), August 1980,
http:/ /www.ietf.org/rfc.html), und IP (RFC791, Internet Pro­ tocol (IP), IETF September 1981,
http:/ /www.ietf.org/rfc.html) verwendet. Das Prinzip der Da­ tenübertragung ist dabei dem oben beschriebenen sehr ähnlich:
Im Sender werden Paketdaten generiert, die zunächst dem RTP Protokoll im Sender übergeben werden. RTP stellt den Daten dann den RTP header voran und bildet mit den eigentlichen Da­ ten das RTP Paket. Diesem wird dann vom UDP Protokoll der UDP header vorangestellt und das so erhaltene UDP Paket wird vom IP Protokoll ebenso wie ein TCP Paket übertragen. Im Empfän­ ger werden dann alle Kontrolldaten wieder entfernt, um die Paketdaten zu erhalten und sie an die das RTP Protokoll nut­ zende Applikation zu übergeben.

Das IP Protokoll stellt ein sehr häufig in Paketdatennetzen benutztes Protokoll der Netzwerkschicht dar, aber auch andere Protokolle können Verwendung finden (bspw. X.25 (RFC, X.25, IETF). Der allgemeine, in UMTS benutzte Begriff ist das soge­ nannte Paketdatenprotokoll (PDP), die zum Routen der Paketda­ ten verwendete Adresse, in obigem Beispiel also die IP Address, wird insbesondere PDP Address genannt.

Besteht das Datenübertragungssystem, in dem die Paketdaten übertragen werden sollen, ganz oder teilweise aus einem Mo­ bilfunksystem, insbesondere UMTS-Funkkommunikationssystem, so ist es vorteilhaft, die wie oben beschrieben erzeugten Pa­ ketdaten (bspw. IP Pakete) von den verschiedenen UMTS Proto­ kollen für eine effiziente Übertragung durch das Mobilfunk­ system aufzubereiten. Insbesondere ist es zweckmäßig, den er­ heblichen Anteil an TCP, RTP, UDP und IP Kontrolldaten in den verschiedenen headern (320 bit pro Paket bei TCP/IP) der Da­ tenpakete zu reduzieren.

Dazu werden die Paketdaten eines PDP zunächst dem PDCP Proto­ koll (3G TS 25.323, Packet Data Convergence Protocol (PDCP), 3GPP März 2000,
http:/ /www.3gpp.org/ftp/Specs/March_00/25_series/25323- 310.zip)
übergeben. Dieses Protokoll ist vor der Datenübertragung vom RRC Protokoll (3G TS 25.331, Radio Resource Control (RRC), 3GPP März 2000,
http:/ /www.3gpp.org/ftp/Specs/March_00/25_series/25331- 320.zip)
instanziiert und konfiguriert worden. Es manipuliert nun die Paketdaten zweckmäßigerweise so, daß sie effizient über die UMTS Luftschnittstelle des jeweiligen Teilnehmergeräts und/oder der jeweiligen Funkkontrolleinheit des UMTS-Funk­ kommunikationssystems übertragen werden können. Dazu wird e­ ventuell eine Kompression der Paketkontrolldaten (header compression) zur Datenreduktion und eine Numerierung der Da­ tenpakete zur Datenverlust- und -vervielfachungserkennung durchgeführt. Je nachdem wie das PDCP Protokoll konfiguriert wurde, stellt es den Paketdaten einen PDCP header voran oder nicht. Zusammen mit diesem header (wenn vorhanden) bilden die durch PDCP aufbereiteten Paketdaten dann ein PDCP Paket, wel­ ches dem RLC Protokoll übergeben wird.

Das RLC Protokoll hat insbesondere die Aufgabe die PDCP Pake­ te, welche eine Größe zwischen 0 und 1502 Oktetts aufweisen können, auf Pakete aufzuteilen, deren Größe vorzugsweise an die Übertragung über die Luftschnittstelle angepaßt ist. Da­ bei kann es zu einer Segmentierung der Pakete oder zu einem Zusammenfügen mehrerer Pakete zu einem größeren Paket kommen.

Je nach Konfiguration des RLC Protokolls, kann RLC den so entstandenen RLC Paketen einen RLC header voran setzen oder nicht. RLC nutzt dann die Dienste der MAC Schicht (3G TS 25.321, Medium Access Control (MAC), 3GPP März 2000,
http:/ /www.3gpp.org/ftp/Specs/March_00/25_series/25321- 330.zip), um die RLC Pakete über die Luftschnittstelle zu ü­ bertragen.

Die Protokollarchitektur der UMTS Luftschnittstelle des je­ weiligen Teilnehmergeräts und/oder der jeweiligen Funkkon­ trolleinheit des UMTS-Funkkommunikationssystems ist insbe­ sondere in 3G TS 25.301, UMTS Protocol Architecture, 3GPP März 2000,
http:/ /www.3gpp.org/ftp/Specs/March_00/25_series/25301- 340.zip beschrieben. Grundsätzlich bezeichnet man die Dienst­ zugangspunkte, an denen die UMTS Luftschnittstelle den Schichten darüber, speziell den Paketdatenprotokollen (PDPs), ihren Dienst zur Verfügung stellt, als Radio Bearer. Dieser Begriff bezeichnet also einen Dienst, der die transparente Übertragung von Daten vom Mobilfunkendgerät bzw. Teilnehmer­ geät (= User Equipment = UE) über eine oder mehrere Basisista­ tionen (Node B) zu einer Mobilfunknetzwerkeinheit, insbeson­ dere Funkkontrolleinheit (Radio Network Controler, RNC) er­ möglicht. Radio Bearer ist also insbesondere ein Träger­ dienst, um Daten über die Luftschnittstelle des UMTS-Funk­ kommunikationssystems zu übertragen. Es ist möglich, mehrere Radio Bearer in einem UE, d. h. Teilnehmergerät, zu nutzen, beispielsweise dann, wenn zwei Applikationen ihr Daten mit unterschiedlichen Dienstqualitäten übertragen wollen und dazu zwei unterschiedliche Radio Bearer aufbauen. Der Aufbau und die Konfiguration der Radio Bearer, ebenso wie die Konfigura­ tion aller beteiligten Protokolle und die Aushandlung der Konfigurationsparameter der Luftschnittstelle wird vorzugs­ weise von einem übergeordneten Protokoll wie z. B. RRC (3G TS 25.331, Radio Resource Control (RRC), 3GPP März 2000,
http:/ /www.3gpp.org/ftp/Specs/March_00/25_series/25331- 320.zip) gesteuert.

Im Rahmen der Erfindung ist insbesondere die Funktionsweise der PDCP Schicht von UMTS von besonderem Interesse, die hier im Detail nachfolgend beschrieben wird.

In der PDCP-Schicht ist für jeden Radio Bearer, der Paketda­ ten übertragen soll, zweckmäßigerweise genau eine PDCP Proto­ kollinstanz vorhanden. Beim Aufbau eines solchen Radio Bea­ rers wird also eine PDCP Protokollinstanz initiiert und kon­ figuriert. Die möglichen Aufgaben einer solchen PDCP Instanz sind beispielsweise:

• - Header Compression (Kontrolldatenreduktion)
• - Datenpaketnumerierung (zur Erkennung von Paketverlusten oder -duplizierungen in bestimmten Fällen)
• - Datenübertragung (das Weitergeben der ggf. manipulierten Daten vom PDP an die RLC-Schicht zum weiteren Transfer)
• - Entsprechende Funktionen in der PDCP Empfängerseite (Hea­ der Decompression, Übertragung empfangener Daten von RLC and das PDP).

Zur Header Compression können in einer PDCP Instanz insbeson­ dere null (keine Kompression), ein oder mehrere verschiedene Kompressionsverfahren mit entsprechenden Algorithmen durch ein oder mehrere entsprechend implementierte Datenkompressi­ onseinheiten benutzt werden. In der augenblicklich gültigen Form des UMTS Standards ist nur ein möglicher Algorithmus zur TCP/IP header compression nach RFC2507 spezifiziert (RFC­ 2507, IP Header Compression, IETF Februar 1999,
http:/ /www.ietf.org/rfc.html), jedoch wird es in Zukunft al­ ler Voraussicht nach noch mehrere andere Kompressionsverfah­ ren in PDCP (z. B. auch für RTP/UDP/IP header compression) ge­ ben. Kompressionsverfahren zur Kontrolldatenreduktion funkti­ onieren dabei insbesondere in etwa nach folgendem Prinzip:
PDCP Sender und Empfänger legen zur Laufzeit der Datenüber­ tragung eine identische Datenbank von gespeicherten Kontroll­ datenköpfen oder Teilen davon an. Diese Datenbank ist am An­ fang der Datenübertragung (also direkt nachdem der Radio Bea­ rer und damit die PDCP Instanz aufgebaut wurde) leer und wird mit der Zeit gefüllt. Jedesmal wenn PDCP im Sender ein Daten­ paket (bspw. IP Paket) von einer höheren Schicht bekommt, vergleicht die zugeordnete Datenkompressionseinheit deren Kontrolldatenkopf (oder Teile davon) mit den in der Datenbank gespeicherten Kontrolldatenköpfen. Findet er eine weitgehende Übereinstimmung, dann ersetzt er den gesamten Kontrolldaten­ kopf oder Teile davon durch einen oder mehrere Verweise auf die Datenbank. Der Dekompressionsalgorithmus im Empfänger des jeweiligen Teilnehmergeräts und/oder der jeweiligen Netzwerk­ einheit wie z. B. radio network controller kann dann mit die­ sem Verweis in seiner Datenbank nach den entsprechenden In­ formationen suchen und mit ihrer Hilfe den ursprünglichen Kontrolldatenkopf wiederherstellen. Findet die Steuer-/Rechen­ einheit im Sender jedoch keine Übereinstimmung, dann sendet dieser einen Full Header, also einen unveränderten Kontrolldatenkopf. Sender und Empfänger tragen diesen in ihre Datenbank zur späteren Verwendung ein. Um dem Empfänger das Erkennen der Art der empfangenen Kontrolldaten zu ermögli­ chen, wird den Daten die Information zweckmäßigerweise mitge­ schickt werden, welcher Art die Kontrolldaten sind. In dem hier beschreibenen Prinzip wäre das also z. B. die Information "Full Header" oder "Verweis auf Datenbank". Diese Information heißt in PDCP insbesondere Packet Identifier (PID).

Es gibt bei effizienten Kompressionsalgorithmen darüberhinaus weitaus mehr Alternativen als nur das Senden eines Full Hea­ ders oder eines Verweises. Bei dem im Augenblick verwendeten Kompressionsverfahren nach RFC2507, IP Header Compression, IETF Februar 1999, http:/ /www.ietf.org/rfc.html gibt es ins­ besondere folgende PIDs:
Full header, Compressed TCP, Compressed TCP nondelta, Com­ pressed non-TCP, Context state.

Es gibt vorzugsweise zwei ähnliche, aber im Sinne des PDCP Protokolls unterschiedliche Arten, die PID zu versenden:
Entweder die jeweilige Datenkompressionseinheit, wie der in RFC2507, IP Header Compression, IETF Februar 1999,
http:/ /www.ietf.org/rfc.html spezifizierte, tauscht ggf. den Kontrolldatenkopf gegen die entsprechenden Daten aus der Datenbank aus und signalisiert dem PDCP Protokoll, welcher Art diese Daten sind. Dann ist das PDCP Protokoll dafür zuständig, diese Information (also die PID) an das Empfänger PDCP Protokoll zu schicken, damit dieses der jeweiligen De­ kompressionseinheit die Art der empfangenen Kontrolldaten signalisieren kann. Oder die jeweilige Datenkompressionsein­ heit tauscht ggf. den Kontrolldatenkopf gegen die entspre­ chenden Daten aus der Datenbank und die Signalisierung der Art dieser Daten aus. In diesem Fall ist es nicht erforder­ lich, daß das PDCP Protokoll eine weitere Signalisierung an die Empfängerseite übermittelt, da die jeweilig zugeordnete Dekompressionseinheit diese Information aus den übermittelten Daten entnehmen kann.

Um im PDCP Protokoll den Einsatz beider Verfahren zu ermögli­ chen, wurden für dieses Protokoll insbesondere mehrere Forma­ te für die PDCP Paketdateneinheiten (PDCP Paket Data Units, PDU, das sind die Paketeinheiten die im jeweiligen Sender von PDCP an RLC übergeben und im jeweilig zugeordneten Emp­ fänger von RLC an PDCP übergeben werden) spezifiziert.

Dabei enthält ein erstes, vorteilhaftes PDCP PDU Format nur die von der jeweiligen Datenkompressionseinheit erzeugten Da­ ten (PDCP-No-Header-PDU). Diese werden in das Feld "Data" eingetragen (siehe Tabelle 4 aus 3G TS 25.323, Packet Data Convergence Protocol (PDCP), 3GPP März 2000,
http:/ /www.3gpp.org/ftp/Specs/March_00/25_series/25323- 310.zip). Diese ist schematisch wiedergegeben:

Tabelle 4

PDCP-No-Header PDU

Ein anderes vorteilhaftes PDCP PDU Format enthält darüberhin­ aus noch Informationen über die PID und ein Feld, das das Format dieser PDU von weiteren PDU Formaten unterscheidet (siehe Tabelle 5 aus 3G TS 25.323, Packet Data Convergence Protocol (PDCP), 3GPP März 2000,
http:/ /www.3gpp.org/ftp/Specs/March 00/25 series/25323- 310.zip, die nachfolgend schematisch wiedergegeben ist).

Tabelle 5

PDCP-Data-PDU format

Beim Aufbau oder der Rekonfiguration eines Radio Bearers wird vom RRC Protocol unter anderem ausgehandelt, ob die zu diesem Radio Bearer gehörende PDCP Instanz dem Feld Data noch eigene Kontrolldaten hinzufügt oder nicht. Wenn nicht, dann kann PDCP nur das in Tabelle 4 gezeigte PDCP PDU Format verschi­ cken. Wenn PDCP den Daten einen eigenen Kontrolldatenkopf hinzufügt, kann es in vorteilhafter Weise mehrere alternative PDU Formate nutzen, die im Empfänger jeweils durch das Feld "PDU type" (immer die ersten 3 bit) unterschieden werden kön­ nen.

Werden mehrere verschiedene Datenkompressionsverfahren für einen Radio Bearer in einer PDCP genutzt, so ist es insbeson­ dere die Aufgabe des Sender PDCP Protokolls, für jedes Daten­ paket von einem PDP ein geeignetes Datenkompressionsverfahren auszuwählen und dem Empfänger das verwendete Datenkompressi­ onsverfahren zu signalisieren. Das geht insbesondere dann, wenn die PDCP Instanzen für die Verwendung der PDU Formate mit PDCP Kontrolldatenkopf konfiguriert wurden. Das verwende­ te Datenkompressionsverfahren wird dann in dem PID Feld zweckmäßigerweise wie folgt mitsignalisiert: Die PID Werte, die das erste der Datenkompressionsverfahren benutzt, werden den ersten PID Werten zugeordnet. Die PID Werte, die das zweite Datenkompressionsverfahren benutzt, werden fortlaufend weiteren PID Werten zugeordnet. Der PID Wert Null ist dabei immer für die Signalisierung eines nicht komprimierten Pakets verwendet, was auch als eine Kompression, nämlich als Null- Kompression betrachtet werden kann. Sind beispielsweise das Datenkompressionsverfahren nach RFC2507, IP Header Compres­ sion, IETF Februar 1999, http:/ /www.ietf.org/rfc.html mit den oben genannten PIDs und ein weiteres Datenkompressionsverfah­ ren (Method A) mit den PIDs A1, A2 und A3 für eine PDCP In­ stanz vergeben, dann wird das Feld PID in dieser PDCP Instanz wie folgt kodiert (nach Tabelle 1 aus 3G TS 25.323, Packet Data Convergence Protocol (PDCP), 3GPP März 2000,
http:/ /www.3gpp.org/ftp/Specs/March_00/25_series/25323- 310.zip)

Tabelle 1

Example of the PID value allocation table

Die PDCP Empfängerinstanz kann nun durch Auslesen des PID Wertes sowohl das verwendete Datenkompressionsverfahren als auch die Art der Kodierung innerhalb eines Datenkompressions­ verfahrens ermitteln.

Eine weitere Funktion des PDCP Protokolls kann die Nummerie­ rung von PDCP PDUs sein, wenn dies vom RRC Protokoll so kon­ figuriert wurde. Die dann mit jeder PDCP PDU assoziierte Num­ mer wird im Allgemeinen nicht mit der PDCP PDU über die Luft­ schnittstelle gesendet, sondern dient zur Paketverlust- oder Paketduplikationserkennung im Falle einer sogenannten SRNS (serving radio network subsystem). Im Zusammenhang mit dieser Erfindung ist dabei insbesondere nur die Existenz der Nume­ rierungsfunktion, jedoch nicht die genaue Funktionsweise, re­ levant.

Im General Paket Radio System (GPRS) stellt das SNDCP Proto­ koll (3G TS 24.065, Subnetwork Dependant Convergence Protocol (SNDCP), 3GPP März 2000,
http:/ /www.3gpp.org/ftp/Specs/March_00/24_series/24065- 310.zip) eine ähnliche Funktionalität dar, wie das PDCP Pro­ tokoll in UMTS: Die Anpassung von PDP Datenpaketen an die Ü­ bertragung über die Luftschnittstelle. Dazu wird auch in SNDCP ein Kontrolldatenkompression, aber auch einige andere Funktionalitäten angewendet. Insbesondere ist es in der SNDCP Schicht möglich, die Daten von mehreren PDPs (also z. B. von verschiedenen IP Protokollen) auf denselben von SNDCP genutz­ ten Kanal zu multiplexen. Das vorteilhafte Verfahren dazu ist im Folgenden beschrieben:
Ein Network Service Access Point Identifier (NSAPI) wird beim Aufbau einer logischen GPRS Datenverbindung (PDP context ac­ tivation) für jedes Paketdatenprotokoll (PDP) vergeben, das die SNDCP Schicht nutzt. Dieser NSAPI hat einen Wertebereich von 0 . . . 15 und wird mit jedem versendeten Datenpaket in ei­ nem Kontrolldatenkopf mitgeschickt. SNDCP auf der Empfänger­ seite kann mit Hilfe dieses Wertes dann den Nutzer der SNDCP Schicht (also das entsprechende PDP) ausmachen und ihm die Daten nach dem Demultiplexen und ggf. anderen Datenmanipula­ tionen übergeben.

Um nun einen effizienten Datenaustausch zwischen den Funkti­ onseinheiten wie z. B. Teilnehmergeräten, Funkkontrolleinhei­ ten, etc. zu ermöglichen, werden erfindungsgemäß in der je­ weiligen Sendeeinheit Paketdaten verschiedener Radio Bearer innerhalb der PDCP Schicht von UMTS als Teil des PDCP Proto­ kolls vorzugsweise auf eine Funkkontrolleinheit, insbesondere RLC Einheit, gemultiplext. In der jeweilig zugeordneten Emp­ fangseinheit wird korrespondierend dazu ein entsprechendes Demultiplexen der empfangenen Datenpakete vorgenommen.

Als Sendeeinheit kann vorzugsweise ein Teilnehmergerät, ins­ besonders Mobilfunkgerät, oder ein RNC-Controller (Radio Net­ work Controller) verwendet sein. Als Empfangseinheit kann vorzugsweise ein Teilnehmergerät, insbesondere Mobilfunkge­ rät, oder ein RNC-Controller (Radio Network Controller) ver­ wendet sein.

Es wird dazu gemäß der Erfindung ein Multiplex-Modell vorge­ stellt, daß mit möglichst geringen Änderungen am bestehenden UMTS-System (wichtig für die Akzeptanz im Standardisie­ rungsprozeß) ein möglichst effizientes Multiplexen zuläßt:
Das Multiplexen erfolgt dabei auf zwei unterschiedliche Ar­ ten, je nachdem was für PDCP PDU Formate für das PDCP Proto­ koll konfiguriert wurden:

1. Multiplexen mit Signalisierung

In dem Fall, dass für die PDCP Protokoll Instanz die Verwen­ dung von PDCP eigenen Protokolldatenköpfen konfiguriert wur­ de, und dass verschiedene Radio Bearer nicht den gleichen Kom­ pressionsalgorithmus nutzen, wird das bestehende PID Feld für die zum Multiplexen nötige Signalisierung verwendet:
Es wird jedem Radio Bearer, der die PDCP Protokoll Instanz nutzt, mindestens ein PID Wert zugeordnet. Solchen Radio Bea­ rern, für die Datenkompressionsverfahren in PDCP konfiguriert wurden, die die PID Signalisierung durch PDCP fordern, werden nach im Stand der Technik bekannten Verfahren bereits PID Werte zugeordnet.
Radio Bearern, die keine Kompressionsverfahren nutzen, oder für die Datenkompressionsverfahren konfiguriert wurden, die keine PID Signalisierung fordern, werden erfindungsgemäß nun dennoch stets PID Werte (genau einer pro Radio Bearer) zuge­ ordnet.
Da das PDCP Protokoll so konfiguriert ist, dass es jedem Da­ tenpaket einen Kontrolldatenkopf voranstellt, der das PID Feld enthält, ist somit in vorteilhafter Weise die Informati­ on zum Demultiplexen in jeder PDCP PDU enthalten. Die empfan­ gende PDCP Instanz liest das PID Feld aus und nutzt es unter anderem, um den richtigen Empfänger der Daten (das richtige PDP) zu bestimmen.

Bei diesem Multiplexverfahren mit Signalisierung finden die konfigurierten Kompressionsverfahren vor dem Multiplexen An­ wendung. Dabei sind die verwendeten. Kompressionsverfahren un­ terschiedlich, weil nur dann die PID Werte neben den verwen­ deten Datenkompressionsverfahren und ggf. der Kompressionsart auch eindeutig einen Radio Bearer (also ein PDP) identifizie­ ren können.

Dieses Verfahren hat insbesondere den Vorteil, dass die PDCP Protokoll Instanz die Daten auch in komprimierter Form oder Pakete von verschiedenen PDP Typen eindeutig einem Radio Bea­ rer zuordnen kann, obwohl sie die PDP Adresse nicht auslesen kann, da sie entweder komprimiert ist oder das PDCP Protokoll keine Kenntnis über den PDP Typen hat.

Ein weiterer Vorteil liegt insbesondere darin, dass das im Stand der Technik vorhandene PID Feld genutzt wird, um die Multiplex-Informationen zu transportieren und dass zusätzli­ che Werte aus dem Wertebereich des PID Feldes nur solchen Ra­ dio Bearern zugeordnet werden, die nach dem Stand der Technik keine PID nutzen.

2. Multiplexing ohne Signalisierung

In dem Fall, dass für die PDCP Protokoll Instanz die Verwen­ dung der PDCP-No-header-PDU (immer ausschließlich) konfigu­ riert wurde, oder das mehrere Radio Bearer dasselbe Kompres­ sionsverfahren nutzen, wird die PDP Adresse für die Vertei­ lung der Pakete auf verschiedene Radio Bearer verwendet.

Da in der PDCP PDU kein Feld für vom PDCP Protokoll generier­ te Daten vorhanden ist, oder Radio Bearer, die das gleiche Kompressionsverfahren nutzen, nicht eindeutig durch das PID Feld identifiziert werden können, verläßt sich PDCP vorzugs­ weise auf die Signalisierung in den PDP eigenen Kontrollda­ ten. Es werden also in der PDCP Instanz im Sender den Paket­ daten keine Kontrolldaten hinzugefügt, so dass im Empfänger aus den Paketdaten die PDP-Adresse ausgelesen und für das Weiterleiten zu dem entsprechenden Radio Bearer genutzt wird.

Bei diesem Verfahren ist der PDCP Protokoll Instanz die Art des PDP (z. B. IP) bekannt. Da diese nicht signalisiert wird, können bei diesem Verfahren durch ein PDCP Protokoll nur Ra­ dio Bearer von gleichen PDP gemultiplext werden. Desweiteren nutzen - wenn header compression genutzt wird - alle Radio Bearer zweckmäßigerweise dasselbe Kompressionsverfahren, da eine Unterscheidung zwischen Radio Bearern erst nach der De­ kompression gemacht werden kann.

Eine weitere Bedingung, die jedoch in UMTS immer erfüllt ist, ist, dass die Radio Bearer, die zusammen gemultiplext werden sollen, eine unterschiedliche PDP-Adresse haben. In UMTS kann zwar ein PDP (also eine PDP-Adresse) mehrere Radio Bearer nutzen, jedoch unterscheiden diese sich immer in der genutz­ ten Dienstequalität (QoS); da gemultiplexte Radio Bearer die gleiche RLC Einheit nutzen, nutzen sie auch den gleichen QoS. Deshalb werden Radio Bearer mit gleicher PDP-Adresse nicht auf dieselbe RLC Einheit gemultiplext, um deren Daten­ ströme später wieder eindeutig klassifizieren und den radio bearern zuordnen zu können.

Dieses Verfahren hat insbesondere den Vorteil, daß es ohne weitere Signalisierung über die Luftschnittstelle das Multip­ lexen von (theoretisch) beliebig vielen Radio Bearern auf ei­ nen Datenstrom zuläßt.

Die beiden oben beschriebenen Verfahren werden zweckmäßiger­ weise jeweils allein oder gemeinsam in PDCP verwendet, abhän­ gig davon wie die PDCP Protokoll Instanz konfiguriert wurde:
Wenn das PID Feld in der PDCP PDU vorhanden ist, dann wird es vorzugsweise zum Multiplexen für solche Radio Bearer genutzt, die eindeutig durch das PID Feld zu identifizieren sind: Das sind solche Radio Bearer denen eindeutige PID Werte zugewie­ sen werden können, die also keine Kompressionsverfahren nut­ zen, die auch von anderen Radio Bearern genutzt werden, son­ dern deren Datenströme mit verschiedenen Kompressionsverfah­ ren beaufschlagt werden (vgl. Fig. 3, linke Hälfte, Daten­ ströme DS300, DS310, DS320, DS330).

Ist das PID Feld nicht vorhanden (weil die PDCP-No-header-PDU konfiguriert wurde) oder nutzen Radio Bearer dengleichen Kom­ pressionsalgorithmus, dann wird das Multiplexing zweckmäßi­ gerweise nach den PDP-Adressen angewendet (vgl. Fig. 3 rech­ te Hälfte, Datenströme DS340, DS350, DS360).

Fig. 1 zeigt ein Mobilfunknetz in dem eine Mobilfunkstation MP über eine erste Funkverbindung FV mit einer Basisstation BS verbunden ist, welche wiederum über eine Festnetzverbin­ dung MNV1 mit einer ersten Netzwerkeinheit FC, im UMTS Stan­ dard als Radio Network Controler (= RNC) bezeichnet, verbunden ist. Eine weitere Festnetzverbindung MNV2 verbindet den RNC dann mit einer höheren Netzwerkeinheit GPRS, gemäß UMTS Stan­ dard als Serving GPRS Support Node bezeichnet. Diese kommuni­ ziert schließlich über eine weiter Festnetzverbindung MNV3 mit einer nächst höheren, insbesondere höchsten Netzwerkein­ heit GW, die im UMTS Standard als Gateway GPRS Support Node bezeichnet wird. Im folgenden sind jedoch nur die Mobilfunk­ station, Basisstation und RNC von Interesse.

Fig. 2 zeigt die Protokollschichten dieser 3 Einheiten MP, BS, FC. Die Mobilfunkstation MP weist die physikalische Schicht (physical layer) PL100, die Zugangskontrolleinheit MAC110 (Medium Access Control), sowie die Funkverbindungskon­ trolleinheit RLC120 (Radio Link Control) und das Paketdaten­ konvergenzprotokoll PDCP130 (Packet Data Convergence Proto­ col) auf. Über die Funkverbindung FV ist das Teilnehmergerät, insbesondere die Mobilfunkstation MP mit der Basisstation BS verbunden, die die physikalische Schicht PL140 beinhaltet und über die Festnetzverbindung MNV1 mit der Funkverbindungskon­ trolleinheit FC, insbesondere radio network controller, ver­ bunden ist. Diese enthält ihrerseits eine Zugangskontrollein­ heit MAC150, eine Funkverbindungskontrolle, insbesondere ra­ dio link control, RLC160 sowie eine Paketdatenkonvergenz­ schicht PDCP170 nach PDCP-Protokoll. Zwischen gleichen, ein­ ander entsprechenden Protokollen gibt es dabei logische Ver­ bindungen, insbesondere Kommunikationskanäle LV200, LV210, LV220 und LV230.

Die zu übertragenden Datenpakete werden in der Mobilfunksta­ tion MP vorzugsweise von der jeweils höheren Schicht an die unter ihr liegende Schicht weitergegeben und schließlich über die Funkverbindung FV an die jeweils zugeordnete Basisstation wie z. B. BS übertragen. Diese gibt die Pakete über die Fest- Netzverbindung MNV1 an die Funkkontrolleinheit FC weiter, in der die Pakete wiederum von einer Schicht an die nächst höhe­ re Schicht weitergegeben werden. Auf gleiche Weise durchlau­ fen auch die von der Funkkontrolleinheit FC zu versendenden Pakete deren verschiedene Protokolle bzw. Funktionseinheiten wie z. B. MAC150, RLC160, PDCP170.

Fig. 3 zeigt nun beispielhaft die aneinandergrenzenden Pa­ ketdatenkonvergenz- und Funkverbindungskontrollprotokolle, wie sie beispielsweise im Mobilfunkgerät HP und in der Funk­ kontrolleinheit FC der Basisstation BS der Aufenthalts- Funkzelle des Mobilfunkgeräts vorhanden sind.

Beim Aufbau eines Radio Bearers werden die RLC und PDCP Pro­ tokolle in der Mobilfunkstation MP und in der Funkkontroll­ einheit FC vorzugsweise identisch konfiguriert. Beim Aufbau des ersten Radio Bearers RB300 wird für die Datenpakete des­ sen Datenstroms DS300 beispielsweise ein Datenkompressions­ verfahren in einer Datenkompressionseinheit CA400 verwendet, das vorzugsweise dem in RFC2507 (request for comments, Stan­ darddokument), IP Header Compression, IETF Februar 1999,
http:/ /www.ietf.org/rfc.html beschriebenen Kompressionsver­ fahren entspricht. Nach RFC2507 sorgt die Datenverbindungs­ schicht, in diesem Fall also das PDCP Protokoll 130 in vor­ teilhafter Weise dafür, daß insbesondere zwischen folgenden Pakettypen unterschieden werden kann:
Full header, Compressed TCP, Compressed TCP nondelta, Com­ pressed non TCP, Context state, Uncompressed TCP/IP, Com­ pressed TCP/IP.

Somit wird zweckmäßigerweise der in Tabelle 5 aus 3G TS 25.323, Packet Data Convergence Protocol (PDCP), 3GPP März 2000, http:/ /www.3gpp.org/ftp/Specs/March_00/25_series/25323- 310.zip dargestellte PDCP-Data-PDU Paketdaten-Type verwendet. Dabei werden den Pakettypen der Datenströme DS300 des radio bearers RB300 die PID Werte 1 bis 7 (1 = Full Header, 2 = Compressed TCP, . . ., 7 = Compressed TCP/IP) als individua­ lisierende Kennzeichen zugewiesen. Weiterhin wird für diesen Radio Bearer RB300 in vorteilhafter Weise festgelegt, daß er den RLC Zugangspunkt (SAP = Service Access Point) SAP500 ver­ wenden soll, der in der Fig. 3 als Ellipse dargestellt ist und den Zugang zu der RLC-Einheit RLC600 darstellt (RLC = ra­ dio link control).

In Datenflußrichtung vom radio bearer RS300 zur RLC-Einheit RLC600 betrachtet werden ausgehend vom radio bearer RB300 die Datenpakete dessen Datenstroms DS300 in der nachfolgenden Da­ tenkompressionseinheit CA400 zunächst einem spezifisch zuge­ ordneten Datenkompressionsverfahren unterworfen. Zugleich o­ der anschließend wird für diesen komprimierten Datenstrom DS400* eine spezifische Kennzeichnung in einer nachfolgenden Kennzeichnungseinheit KE400 vorgenommen. Erst danach wird der derart individualisierte Datenstrom DS400* einer nachgeordne­ ten Multiplexereinheit MUP1 zugeführt. Mit deren Hilfe wird der komprimierte und gekennzeichnete Datenstrom des radio bearers RB300 zusammen mit den Datenpaketen anderer Daten­ ströme weiterer radio bearers wie z. B. RB310, RB320, RB330 gemultiplext der RLC-Einheit RLC600 übermittelt.

Der zweite Radio Bearer RB310 verwendet zweckmäßigerweise e­ benfalls den RLC SAP500. Die Komprimierung der Protokollkon­ trolldaten der Datenpakete seines Datenstroms DS310 wird je­ doch mit einem Datenkompressionsverfahren in einer Datenkom­ pressionseinheit CA410 durchgeführt. Für die Datenpakete die­ ses Datenstroms DS310 wird hier im Ausführungsbeispiel ange­ nommen, daß keine Signalisierung durch die Funkverbindungs­ schicht zur Unterscheidung der Datenpakete notwendig ist. Dennoch wird nach dem Datenkompressionsverfahren einer Daten­ kompressionseinheit CA410 mit Hilfe einer Kennzeichnungeine­ heit KE410 dem Datenstrom aus der Kompressionseineheit CA410 ein bestimmter PID Wert wie z. B. 8 in eindeutiger Weise zuge­ wiesen.

Ein dritter, anschließend aufgebauter Radio Bearer RB320 ver­ wendet ebenfalls wie der Datenstrom DS310 des radio bearers RB310 das Datenkompressionsverfahren der Datenkompressions­ einheit CA410 sowie den RLC SAP500. Da das Kompressionsver­ fahren der Datenkompressionseinheit DS410 beim Aufbau des Ra­ dio Bearers RB320 bereits existiert, wird kein weiterer PID Wert vergeben, sondern derselbe wie für den Datenstrom DS310 verwendet. Mit anderen Worten heißt das, daß die beiden Da­ tenströme DS310 und DS320 der beiden radio bearer RB310 und RB320 jeweils mit demselben Datenkompressionsverfahren in der Datenkompressionseinheit CA410 beaufschlagt werden. Anschlie­ ßend wird für den, aus der Kompressionseinheit CA410 kommen­ den Datenstrom DS410* in einer nachgeordneten Kennzeichnungs­ einheit eine spezifische Kennzeichnung vorgenommen. Erst dann wird dieser individualisierte Datenstrom auf den Multiplexer MUP1 gegeben, um ihn effizient an die RLC-Einheit RLC600 zu schicken.

Für einen vierten Radio Bearer RB330 wird angenommen, daß die Protokollkontrolldaten nicht komprimiert werden sollen, er jedoch auch RLC SAP500 verwenden soll. Erfindungsgemäß wird dem Radio Bearer daher ein weiterer, bestimmter PID Wert wie z. B. 9 als individualisierende Kennzeichnung zugewiesen, der vom PID-Wert der anderen Datenkomprimierungseinheiten CA400, CA410 verschieden ist. Auf Mobilfunkstations- und Funkkon­ trolleinheitsseite findet dabei die Zuweisung zweckmäßiger­ weise identisch statt.

Auf diese Weise werden dem Multiplexer MUP1 Datenströme zuge­ führt, die mit unterschiedlichen, d. h. voneinander verschie­ denen Kompressionsverfahren beaufschlagt sind. Erst nachdem sie mit einem Kennzeichen wie z. B. einem unterscheidbaren PID-Wert individualisiert, d. h. unterscheidbar gemacht worden sind, werden sie einem nachfolgenden Multiplexverfahren zur Datenzufuhr an eine RLC-Einheit unterworfen. Unter Kompressi­ onsverfahren wird dabei auch eine Null-Kompression verstan­ den. Der nichtkomprimierte Datenstrom wird dabei ebenfalls mit einer invidualisierenden Kennzeichnung versehen. Allge­ mein ausgedrückt wird also unabhängig davon, ob das jeweilig verwendete Datenkompressionsverfahren einen PID-Kennzeichner verlangt oder nicht, bei Datenströmen, die gemischten Kom­ pressionsverfahren unterworfen werden, stets ein Kennzeichner an den jeweiligen Datenstrom vergeben, bevor dieser nach sei­ ner Komprimierung an den Multiplexer MUP1 übergeben wird.

Im folgenden wird nun im einzelnen die Paketdatenübertragung von der Mobilfunkstation MP an die Funkkontrolleinheit FC be­ schrieben. Dafür stellt Fig. 3 zunächst die RLC und PDCP Protokolle 120, 130 in der jeweiligen Sendeeinheit einer Mo­ bilfunkstation oder sonstigen Netwerkeinheit, insbesondere Funkkontrolleinheit dar. Werden von höheren Schichten Daten­ pakete über den ersten Radio Bearer RB300 an das PDCP Proto­ koll weitergegeben, werden die Paketkontrolldaten gemäß RFC­ 2507 mit Hilfe der Kompressionseinheit CA400 komprimiert. Das komprimierte Paket DS400* wird in das Feld "Data" des in Tabelle 5 aus 3G TS 25.323, Packet Data Convergence Protocol (PDCP), 3GPP März 2000,
http:/ /www.3gpp.org/ftp/Specs/March_00/25_series/25323- 310.zip dargestellten PDCP-Data-PDU Pakets eingefügt. Das PDCP Protokoll setzt dann das PID Feld z. B. auf einen Wert zwischen 1 bis 7, je nachdem welche Art von komprimierten Pa­ ket in das Feld "Data" eingefügt wurde. Dadurch ist eine in­ dividualisierende Kennzeichnung des komprimierten Datenstroms DS400* bereitgestellt. Dies ist in der Fig. 3 dadurch ange­ deutet, daß nach der Kompressionseinheit CA400 und vor der Multiplexereinheit MUP1 die Kennzeichnungseinheit KE400 ein­ gefügt ist. Diese vergibt an die Datenpakete des komprimier­ ten Datenstroms DS400*, der von der Kompressionseinheit CA400 zur Multiplexereinheit MUP1 weitergeschickt wird, jeweils ein individuelles Kennzeichen wie z. B. einen PID-Codewert. Wird von höheren Schichten ein Datenpaket über den zweiten oder dritten Radio Bearer RB310, RB320 an das PDCP Protokoll wei­ tergeben, setzt PDCP das PID-Feld z. B. auf denselben Wert 8. Um dieses individualisierende Kennzeichen den Datenpaketen des aus der Komprimierungseinheit CA410 kommenden Datenstroms DS410* anhängen zu können, ist der Komprimierungseinheit CA410 unmittelbar die Kennzeichnungseinheit KE410 nachgeord­ net. Erst danach wird dieser gekennzeichnete Datenstrom DS410* der Multiplexereinheit MUP1 ebenfalls zugeführt. Die Kennzeichnungseinheit CA410 ist also zwischen der Komprimie­ rungseinheit CA400 und der Multiplexereinheit MUP1 angeord­ net. Gelangt das Paket über den vierten Radio Bearer RB330 an PDCP, wird das PID Feld z. B. auf 9 gesetzt. Diese individua­ lisierende Kennzeichnung wird dabei zweckmäßigerweise mit Hilfe der eigens zugeordneten Kennzeichnungseinheit KE330 vorgenommen. Erst anschließend wird dieser individualisierte Datenstrom DS330* der gemeinsamen Multiplexereinheit MUP1 zu­ geführt. Diese schickt die Datenpakete des Datenstroms DS330* über den RLC Zugangspunkt SAP500 an die RLC-Einheit RLC600 weiter, welche das Paket weiterverarbeitet und schließlich an das unter RLC liegende Zugangskontrollprotokoll MAC über ei­ nen sogenannte logischen Kanal LOC700 weiterleitet. MAC gibt das Paket wiederum an die physikalische Schicht weiter und schließlich wird das Paket über die Funkverbindung FV an die Basisstation BS gesendet, welche das Datenpaket an die Funk­ kontrolleinheit FC weitergibt.

Im Empfangsbetrieb erfolgt die Verarbeitung der empfangenen Datenpakete in umgekehrter Weise beispielsweise folgenderma­ ßen: In Fig. 3 sind dazu die RLC und PDCP Protokolle 160, 170 in der jeweiligen Empfangseinheit eines Mobilfunkgeräts oder einer Funkkontrolleinheit dargestellt. Das jeweilig emp­ fangene Datenpaket wird z. B. in der Funkkontrolleinheit FC über den logischen Kanal LOC700 an die RLC-Einheit RLC600 ü­ bergeben, welche das Paket über den RLC SAP500 an das PDCP Protokoll weiterleitet. Das PDCP Protokoll kennt in vorteil­ hafter Weise die Möglichkeiten, wie das Paket weitergeleitet werden kann. Um das Paket nun korrekt weiterzuleiten, wird zweckmäßigerweise das PID-Feld ausgewertet. Hat das PID-Feld z. B. einen Wert zwischen 1 und 7, wird das Paket an die Kom­ pressionseinheit CA400 weitergegeben, wo das Paket dekompri­ miert und anschließend an Radio Bearer 300 weitergeleitet wird. Ist der Wert des PID-Feldes gleich 8 wird das Paket an die Kompressionseinheit CA410 weitergeleitet und dort de­ komprimiert. Nach der Dekompression wird die Paketdatenproto­ koll-(PDP-)Adresse ausgewertet und an Hand dieser Auswer­ tung das Paket entweder an Radio Bearer RB310 oder RB320 wei­ tergegeben. Ist der Wert des PID-Feldes 9 wird das Paket di­ rekt an den Radio Bearer RB330 weitergegeben.

Im Fall, daß das PID-Feld beim Datenstrom des jeweiligen ra­ dio bearers nicht vorhanden ist, (weil z. B. die PCDP-No- Header-PDU konfiguriert wurde) oder eine Gruppe von mehreren radio bearern das gleiche Kompressionsverfahren nutzt, jedoch die verschiedenen Datenströme aufgrund unterschiedlicher PDP Adressen unterscheidbar sind, wird zweckmäßigerweise folgen­ dermaßen vorgegangen (vgl. dazu rechten Strang von Fig. 3):
Da in der PDCP PDU kein Feld für vom PDCP Protokoll generier­ te Daten vorhanden ist, oder Radio Bearer, die dengleichen Kompressionsalgorithmus nutzen, nicht eindeutig durch das PID Feld identifiziert werden können, wird zur individualisieren­ den Kennzeichnung der Datenströme wie z. B. DS340, DS350, DS360 mehrerer radio bearer wie z. B. RB340, RB350, RB360 in Fig. 3 in PDCP vorzugsweise die Signalisierung in den PDP eigenen Kontrolldaten herangezogen. Es werden also in der PDCP Instanz im Sender den Paketdaten keine Kontrolldaten ei­ gens, d. h. extra hinzugefügt, so dass im Empfänger aus den Paketdaten lediglich die bereits sowieso vorhandene PDP- Adresse ausgelesen und für das Weiterleiten zu dem entspre­ chenden Radio Bearer genutzt wird.

In der Fig. 3 werden deshalb die Datenströme, die inhärent durch jeweils eine unterscheidbare PDP-Adresse gekennzeichnet sind und dadurch voneinander unterscheidbar gemacht sind, auf einen gemeinsamen Multiplexer MUP2 gegeben. Die individuali­ sierende Kennzeichnung jedes Datenstroms liegt also bereit vor dem Multiplexer MUP2 vor. Dies ist in der Fig. 3 durch den verschiedenen Datenströmen zugehörige Kennzeichnungsmit­ tel KE340, KE350, KE360 angedeutet.

Beim Aufbau z. B. des Radio Bearers RB340 wird festgelegt, daß die Protokollkontrolldaten, die von höheren Schichten an das PDCP Protokoll weitergegeben werden, mit dem Kompressionsver­ fahren der nachgeordneten Kompressionseinheit CA420 kompri­ miert werden sollen. Außerdem soll der Radio Bearer RB340 den RLC SAP510 verwenden. Für dieses Ausführungsbeispiel wird weiter angenommen, daß das Kompressionsverfahren der Kompres­ sionseinheit CA420 keine Signalisierung durch die Datenver­ bindungsschicht, also PDCP, erfordert, weshalb keine Paketun­ terscheidung durch PDCP erfolgen muß, somit auch kein PID- Wert als Extrakennzeichnung vergeben werden muß und vorzugs­ weise der in Tabelle 4 aus 3G TS 25.323, Packet Data Conver­ gence Protocol (PDCP), 3GPP März 2000,
http:/ /www.3gpp.org/ftp/Specs/March_00/25_series/25323- 310.zip dargestellte PDCP-No-Header-PDU Paket-Type verwendet werden kann. Die Datenströme DS350 und DS360 der Radio Bearer RB350 und RB360 werden ebenfalls der Kompressionseinheit CA420 zugeführt und somit demselben Komprimierungsverfahren unterworfen. Die derart komprimierten Datenströme werden dann gemeinsam über den RLC SAP510 an die RLC-Einheit RLC610 wei­ tergeschickt. Da das Multiplexen auf den RLC SAP510 und somit auf die RLC-Einheit RLC610 vorzugsweise ausschließlich vor der Kompression mit Hilfe der Multiplexereinheit MUP2 statt­ findet, wird weiterhin in vorteilhafter Weise kein PID Wert benötigt und es wird weiterhin der PDCP-No-Header-PDU Paket- Type verwendet.

Im folgenden wird nun die Paketübertragung von der Mobilfunk­ station zur Funkkontrollschicht im einzelnen beispielhaft er­ läutert: Zunächst soll Fig. 3 daher wieder die RLC und PDCP Protokolle 120, 130 in der Mobilfunkstation darstellen. Wird nun ein Paket von höheren Schichten über einen der Radio Bae­ rer 340, 350 oder 360 an das PDCP Protokoll gegeben, wird das Paket komprimiert und das komprimierte Paket in das Feld "Da­ ta" des in Tabelle 4 dargestellten "PDCP-No-Header-PDU" Pa­ kets eingefügt und anschließend über den RLC SAP510 an die RLC-Einheit RLC610 weitergegeben. Diese bearbeitet das Paket evtl. weiter und gibt es schließlich über den logischen Kanal LOC710 an das MAC Protokoll weiter, welches das jeweilige Da­ tenpaket ihrerseits an die physikalische Schicht weiterlei­ tet; von dieser wird letztendlich das jeweilige Datenpaket über die Funkverbindung an die Basisstation gesendet, welche das Datenpaket an die Funkkontrolleinheit FC weiterleitet.

Im folgenden wird nun die Paketübertragung in umgekehrter Richtung, d. h. von der Funkkontrollschicht zur Mobilfunksta­ tion näher erläutert: Fig. 3 soll dazu nun die RLC und PDCP Protokolle 160, 170 der Funkkontrolleinheit darstellen. Das jeweilige Datenpaket wird in der Funkkontrolleinheit von un­ ten nach oben durch die Schichten gegeben und gelangt schließlich über den logischen Kanal LOC710 zur RLC-Einheit RLC610, welche das Paket über den RLC SAP510 an PDCP weiter­ gibt. Das PDCP Protokoll gibt alle Pakete, die von dem RLC SAP510 kommen an die Kompressionseinheit CA420, die jetzt ei­ ne Dekomprimierung vornimmt. Nach der Dekompression wird dann wieder die PDP Adresse ausgewertet, um das jeweilige Paket an den korrekten, zugeordneten Radio Bearer weiterzugeben.

Allgemein ausgedrückt wird also bei einem ersten erfindunges­ gemäßen Verfahren zum Multiplexen einer Vielzahl von Datenpa­ keten mehrerer Datenströme (DS300, DS310, DS320, DS330) auf eine zugeordnete Netzwerkeinheit (RLC600) innerhalb des PDCP- Protokolls (packet data convergence protocol) mindestens ei­ ner Sendeeinheit eines UMTS-Funkkommunikationssystems die ver­ schiedenen Datenströme (DS300, DS310, DS320, DS330) vor ihrem Multiplexen mittels einer Multiplexereinheit (MUP1) mit un­ terschiedlichen Datenkompressionsverfahren verschiedener Da­ tenkompressionseinheiten (CA400, CA410) beaufschlagt. Dabei wird zwischen der jeweiligen Datenkompressionseinheit (CA400, CA410) und der Multiplexereinheit (MUP1) jeweils mindestens eine individuelle Kennzeichnung des jeweilig in die Multiple­ xereinheit (MUP1) einlaufenden Datenstroms (DS400*, DS410*, DS330) mittels einer zugeordneten Kennzeichnungseinheit (KE400, KE410, KE330) vorgenommen, so daß die in mindestens einer Empfangseinheit des PDCP-Protokolls empfangenen Daten­ pakete eindeutig den ursprünglich eingespeisten Datenströmen (DS300, DS310, DS320, DS330) der Sendeeinheit zuordenbar sind.

Nach einem zweiten erfindungsgemäßen Verfahren zum Multiple­ xen einer Vielzahl von Datenpaketen mehrerer Datenströme (DS340, DS350, DS360) auf eine zugeordnete Netzwerkeinheit (RLC610) innerhalb des PDCP-Protokolls (packet data conver­ gence protocol) mindestens einer Sendeeinheit eines UMTS- Funkkommunikationsystems werden die verschiedenen Datenströme (DS340, DS350, DS360) nach ihrem Multiplexen mittels einer Multiplexereinheit (MUP2) in einer gemeinsamen Datenkompres­ sionseinheit (CA420) mit demselben Datenkompressionsverfahren beaufschlagt. Dabei wird vor der Multiplexereinheit (MUP2) jeweils mindestens eine individuelle Kennzeichnung des jewei­ lig in die Multiplexereinheit (MUP2) einlaufenden Datenstroms (DS340, DS350, DS360) mittels einer zugeordneten Kennzeich­ nungseinheit (KE340, KE350, KE360) vorgenommen, so daß die in mindestens einer Empfangseinheit des PDCP-Protokolls empfan­ genen Datenpakete eindeutig den ursprünglich eingespeisten Datenströmen (DS340, DS350, DS360) der Sendeeinheit zuorden­ bar sind. Die individualisierende Kennzeichnung des jeweiligen Datenstroms vor der Multiplexereinheit kann dabei bereits in­ härent durch dessen PDF-Feld vordefiniert sein.

Als Sendeeinheit kann dabei vorzugsweise ein Teilnehmergerät, insbesonders Mobilfunkgerät (MP), oder ein RNC-Controller (Radio Network Controller) verwendet werden. Als Empfangsein­ heit kann ebenfalls vorzugsweise ein Teilnehmergerät, insbe­ sondere Mobilfunkgerät (MP), oder ein RNC-Controller (Radio Network Controller) verwendet sein. Als Netzwerkeinheit wird vorzugsweise eine Funkkontrolleinheit (FC), insbesondere RLC- Einheit (radio link control), gewählt.

Claims (6)

1. Verfahren zum Multiplexen einer Vielzahl von Datenpaketen mehrerer Datenströme (DS300, DS310, DS320, DS330) auf eine zugeordnete Netzwerkeinheit (RLC600) innerhalb des PDCP- Protokolls (packet data convergence protocol) mindestens ei­ ner Sendeeinheit eines UMTS-Funkkommunikationssystems, wobei die verschiedenen Datenströme (DS300, DS310, DS320, DS330) vor ihrem Multiplexen mittels einer Multiplexereinheit (MUP1) mit unterschiedlichen Datenkompressionsverfahren verschiede­ ner Datenkompressionseinheiten (CA400, CA410) beaufschlagt werden, und wobei zwischen der jeweiligen Datenkompressions­ einheit (CA400, CA410) und der Multiplexereinheit (MUP1) je­ weils mindestens eine individuelle Kennzeichnung des jeweilig in die Multiplexereinheit (MUP1) einlaufenden Datenstroms (DS400*, DS410*, DS330) mittels einer zugeordneten Kennzeich­ nungseinheit (KE400, KE410, KE330) vorgenommen wird, so daß die in mindestens einer Empfangseinheit des PDCP-Protokolls empfangenen Datenpakete eindeutig den ursprünglich einge­ speisten Datenströmen (DS300, DS310, DS320, DS330) der Sende­ einheit zuordenbar sind.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß als Sendeeinheit ein Teilnehmergerät, insbesonders Mobil­ funkgerät (MP), oder ein RNC-Controller (Radio Network Cont­ roller) verwendet wird.

3. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß als Empfangseinheit ein Teilnehmergerät, insbesondere Mo­ bilfunkgerät (MP), oder ein RNC-Controller (Radio Network Controller) verwendet wird.

4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß als Netzwerkeinheit eine Funkkontrolleinheit (FC), insbe­ sondere RLC-Einheit (radio link control), verwendet wird.

5. Verfahren zum Multiplexen einer Vielzahl von Datenpaketen mehrerer Datenströme (DS340, DS350, DS360) auf eine zugeord­ nete Netzwerkeinheit (RLC610) innerhalb des PDCP-Protokolls (packet data convergence protocol) mindestens einer Sendeein­ heit eines UMTS-Funkkommunikationssystems, wobei die verschie­ denen Datenströme (DS340, DS350, DS360) nach ihrem Multiple­ xen mittels einer Multiplexereinheit (MUP2) in einer gemein­ samen Datenkompressionseinheit (CA420) mit demselben Daten­ kompressionsverfahren beaufschlagt werden, und wobei vor der Multiplexereinheit (MUP2) jeweils mindestens eine individuel­ le Kennzeichnung des jeweilig in die Multiplexereinheit (MUP2) einlaufenden Datenstroms (DS340, DS350, DS360) mittels einer zugeordneten Kennzeichnungseinheit (KE340, KEB50, KE360) vorgenommen wird, so daß die in mindestens einer Emp­ fangseinheit des PDCP-Protokolls empfangenen Datenpakete ein­ deutig den ursprünglich eingespeisten Datenströmen (DS340, DS350, DS360) der Sendeeinheit zuordenbar sind.

6. UMTS-Funkkommunikationssystem, in dem der Austausch von Datenströmen zwischen dessen Teilnehmergeräten, insbesondere Mobilfunkgeräten (MP), und Netzwerkeinheiten, insbesondere Funkkontrolleinheiten (FC), nach einem der vorhergehenden An­ sprüche vorgenommen wird.