-
HINTERGRUND
-
1. GEBIET DER ERFINDUNG
-
Die
vorliegende Erfindung bezieht sich auf die Übertragung von Paketen in Telekommunikationsnetzen,
und insbesondere auf die Kompressionen von Headern (Anfangsblöcken) für derartige
Pakete.
-
2. VERWANDTER
SACHSTAND UND ANDERE ERWÄGUNGEN
-
In
einem typischen zellularen Funksystem kommunizieren mobile Benutzergeräteeinheiten
(UEs) über ein
Funkzugriffsnetz (RAN) mit einem oder mehreren Kernnetzen. Die Benutzergeräteeinheiten
(UEs) können mobile
Stationen sein, wie beispielsweise mobile Telefone ("zellulare" Telefone) und Laptops
mit einem mobilen Abschluss, und können somit zum Beispiel tragbare,
Taschen-gestützte,
in der Hand gehaltene, in einem Computer eingebaute, oder in einem
Fahrzeug angebrachte mobile Einrichtungen sein, die Sprache und/oder Daten
mit dem Funkzugriffsnetz kommunizieren.
-
Das
Funkzugriffsnetz (RAN) deckt ein geographisches Gebiet ab, welches
in Zellengebiete unterteilt ist, wobei jedes Zellengebiet durch
eine Basisstation abgedeckt wird. Eine Zelle ist ein geographisches
Gebiet, in dem eine Funkabdeckung durch das Funkbasisstationsgerät an einer
Basisstationsstelle bereitgestellt wird. Jede Zelle wird durch eine
einzigartige Identität
identifiziert, die in der Zelle ausgesendet wird. Die Basisstationen
kommunizieren über
die Luftschnittstelle (z.B. Funkfrequenzen) mit den Benutzergeräteeinheiten
(UE) innerhalb eines Bereichs der Basisstationen. In dem Funkzugriffsnetz
sind mehrere Basisstationen typischerweise mit einem Funknetz-Controller
(RNC) (z.B. über
Landleitungen oder Mikrowellen) verbunden. Der Funknetz-Controller,
der manchmal als ein Basisstation-Controller (BSC) bezeichnet wird, überwacht
und koordiniert verschiedene Aktivitäten der mehreren Basisstationen,
die damit verbunden sind. Die Funknetz-Controller sind typischerweise
mit einem oder mehreren Kernnetzen verbunden.
-
Ein
Beispiel eines Funkzugriffsnetzes ist das Universal Mobile Telecommunication
(UMTS) Terrestrial Radio Access Network (UTRAN). Das UTRAN ist ein
System der dritten Generation, welches in gewisser Hinsicht auf
der Funkzugriffstechnologie aufbaut, die als Global System for Mobile
communications (GSM) bekannt ist, welches in Europa entwickelt wurde.
UTRAN ist im Wesentlichen ein System mit einem breitbandigen Codeteilungs-Vielfachzugriff
(W-CDMA). Ein anderes beispielhaftes Funkzugriffsnetz ist das GPRS
EDGE Radio Access Network (GERAN).
-
Die
Welt der Telekommunikationen durchläuft eine Verschiebung des Paradigmas
von leitungsvermittelten, und verbindungsorientierten Informationstransfers
auf paketvermittelte, verbindungslose Transfers. Demzufolge nimmt
das Universal Mobile Telecommunications (UMTS) Terrestrial Radio
Access Network (UTRAN) sowohl leitungsvermittelte als auch paketvermittelte
Verbindungen auf. Zum Beispiel beinhalten in dem UTRAN die leitungsvermittelten
Verbindungen einen Funknetz-Controller (RNC), der mit einem Mobilvermittiungszentrum
(MSC) kommuniziert, welches wiederum mit einem verbindungsorientierten
externen Kernnetz verbunden ist, welches (zum Beispiel) das öffentliche
Telefonvermittlungsnetz (PSTN) und/oder das dienstintegrierte Digitalnetz
(ISDN) sein kann. Andererseits beinhalten in dem UTRAN die paketvermittelten Verbindungen
den Funknetz-Controller, der mit einem bedienenden GPRS-Unterstützungsknoten
(SGSN) kommuniziert, der wiederum über ein Backbone-Netz und einen
Gateway-GPRS-Unterstützungsknoten (GGSN)
mit paketvermittelten Netzen (z.B. dem Internet, X.25 externen Netzen)
verbunden ist.
-
Es
gibt mehrere interessante Schnittstellen in dem UTRAN. Die Schnittstelle
zwischen den Funknetz-Controllern (RNCs) und dem Kernnetz (den Kernnetzen)
wird als "Iu"-Schnittstelle bezeichnet.
Die Schnittstelle zwischen einem Funknetz-Controller (RNC) und seinen
Basisstationen (BSs) wird als die "Iub"-Schnittstelle
bezeichnet. Die Schnittstelle zwischen der Benutzergeräteeinheit
(UE) und den Basisstationen ist als die "Luftschnittstelle" oder die "Funkschnittstelle" oder "Uu-Schnittstelle" bekannt.
-
Für eine Anwendungs-Unabhängigkeit
und um Kosten für
einen Transport und eine Vermittlung zu verringern, ist es attraktiv,
das paketvermittelte Internet-Protokoll (IP) über den Weg über die
Luftschnittstelle zu dem Endbenutzergerät zu verwenden. Mit anderen
Worten, es ist vorteilhaft, die Internet-Protokolle vor der Luftschnittstelle
nicht abzuschließen.
Früher
ist ein Hauptgrund, warum Internet-Protokolle über die Luftschnittstelle nicht
verwendet wurden, der relativ große Zusatz gewesen, der bestimmten "Headern", die Sprachpaketen
gehören
(z.B. IP/UDP/RTP-Headern), auferlegt wurden.
-
Somit
ist ein Hauptproblem beim Übertragen
von Sprache unter Verwendung des Internet-Protokolls über eine drahtlose (z.B. Luft)
Schnittstelle die große
Größe von Headern
der Protokolle, die verwendet werden, wenn Sprachdaten über das
Internet gesendet werden. Zum Beispiel weist ein IPv4-Paket mit Sprachdaten
einen IP-Header, einen UDP-Header und einen RTP-Header auf, die
alle zusammen insgesamt 20 + 8 + 12 = 40 Oktette ergeben. Mit IPv6
ist der IP-Header 40 Oktette für
insgesamt 60 Oktette. Die Größe von Sprachdaten
hängt von
dem Codierer ab und kann von 14 Oktetten bis 30 Oktetten sein. Die
relativen großen Anzahlen
würden
sich zugunsten eines Abschlusses der IP-Protokolle vor der Luftschnittstelle
lohnen, da die IP/UDP/RTP-Header eine höhere Bit-Rate erfordern und
eine ineffiziente Verwendung des teuren Funkspektrums verursachen.
-
Aus
den voranstehenden Erläuterungen
ist ersichtlich, dass eine grundlegende Anforderung besteht, den
IP-Header-bezogenen Overhead über
die relativ zu Fehlern neigenden und schmalbandigen zellularen Kanäle zu verringern,
während
die Transparenz von sämtlichen
Header-Feldern beibehalten wird. Diese Anforderung ist adressiert
worden, mit unterschiedlichen Erfolgsgraden unter Verwendung von
Techniken einer Header-Kompression.
-
Während sämtliche
Header-Information in einem Sprachpaket benötigt wird, gibt es einen hohen
Grad von Redundanz zwischen Header-Feldern in den Headern von aufeinander
folgenden Paketen, die zu dem gleichen Paketstrom gehören, z.B.
dem gleichen Paketfluss. Wenn man diese Beobachtung ausnützt, versuchen
Header-Kompressionsalgorithmen typischerweise einen "Kontext" beizubehalten. Der
Kontext, der auf beiden Enden des Kanals aufrechterhalten wird, über den
die Header-Kompression ausgeführt
wird, ist im Wesentlichen die nicht-komprimierte Version des letzten übertragenen
Headers. Komprimierte Header führen
unter anderem Änderungen
an dem Kontext. Header-Kompressionsverfahren weisen typischerweise
Mechanismen zum Installieren von Kontext, zum Erfassen, wann der
Kontext abgelaufen ist, und zum Reparieren des stromabwärts liegenden
Kontexts, wenn er abgelaufen (veraltet) ist, auf.
-
Wenn
mehrere komprimierte Header-Flüsse über die
gleiche Strecke vorhanden sind, muss es irgendeine Vorgehensweise
geben, um zu bestimmen, dass ein spezifischer komprimierter Header
zu einem spezifischen komprimierten Fluss von Paketen (z.B. zu einem
bestimmten Paketstrom) gehört.
Dies ist wichtig, da der Kompressor und Dekompressor einen Zustand
(d.h., den voranstehend erwähnten
Kontext) verwenden, um zu bestimmen, wie sie den Header komprimieren/dekomprimieren
werden. In einem typischen Szenarium einer Paketübertragung empfängt der
Kompressor einen nicht-komprimierten Header, der zu einem spezifischen
Paketfluss gehört,
und verwendet den richtigen Kontext für diese Paketfluss, um diesen
Header zu komprimieren. Der komprimierte Header wird unter Verwendung
von irgendeiner Art von Mechanismus übertragen, um zu identifizieren,
zu welchem Fluss dieser spezifische Header gehört. An dem anderen Ende der
Strecke empfängt
der Dekompressor den komprimierten Header und verwendet den Mechanismus,
um festzustellen, zu welchem Fluss oder zu welchem Kontext der Header
gehört.
Der Dekompressor kann dann den identifizierten Kontext verwenden,
um den Header zu dekomprimieren.
-
Ein
frühes
Header-Kompressionsverfahren, welches hier als CTCP bekannt ist,
wurde von Jacobson, V., "Compressing
TCP/LP Headers for Low-Speed Serial Links", RFC 1144, Februar 1990, vorgeschlagen. CTCP
komprimiert den 40 Oktett großen
IP + TCP-Header auf Zwei-Vier-Oktette. Der CTCP-Kompressor erfasst
Transport-Niveau-Neuübertragungen
und sendet einen Header, der den Kontext vollständig aktualisiert, wenn sie
auftreten.
-
Ein
allgemeines IP-Header-Kompressionsverfahren, welches als IP Header
Compression (IPHC) bekannt ist, kann beliebige IP, TCP, und UDP
Header komprimieren. Wenn Nicht-TCP-Header komprimiert werden, verwendet
IPHC nicht eine Delta-Codierung und ist robust. Wenn TCP komprimiert
wird, wird der Reparaturmechanismus von CTCP mit einem Link-Level
Nacking-Verfahren ergänzt,
welches die Reparatur beschleunigt. IPHC komprimiert RTP-Header
nicht.
-
Ein
Header-Kompressionsverfahren, welches als CRTP bekannt ist, ist
für Echtzeit-IP-Dienste
vorgeschlagen worden; siehe z.B. S. Casner, V. Jacobson, "Compressing IP/UDP/RTP-Header
for Low-Speed Serial Links", RFC 2508, Februar
1999. CRTP kann 40 Oktett IPv4/UDP/RTP-Header auf ein Minimum von
2 Oktetten komprimieren. Für
eine Kontextreparatur stützt
sich CRTP auf die Existenz einer stromaufwärts gerichteten Strecke, über die
ein Dekompressor Aufforderungen zum Aktualisieren von Headern sendet.
Während
der Kontext abgelaufen ist, können
alle empfangenen Pakete nicht dekomprimiert werden.
-
Ein
Header-Kompressionsverfahren, welches als Robust Header Compression
(ROHC) bekannt ist, ist für
eine zellulare Verwendung geeignet; siehe z.B. C Borman et al, "Robust Header Compression
(ROHC)", draft-ietf-rohc-rtp-02.txt
(work in progress), September 2000. Bei dem ROHC ist eine Prüfsumme,
die den ursprünglichen
(unkomprimierten) Header abdeckt, in dem komprimierten Header eingebaut,
um eine zuverlässige
Vorgehensweise einzuführen,
um zu detektieren, wenn der Kontext abgelaufen ist, und wenn ein
Versuch zum Reparieren des Kontext lokal erfolgreich gewesen ist.
ROHC führt
unterschiedliche Kompressionsprofile ein, um unterschiedliche Arten
von RTP-Strömen
und Kanalbedingungen zu behandeln, um ein so hohes Betriebsverhalten
wie möglich
zu erzielen. Zusätzlich
baut ROHC in seinen komprimierten Header Codes ein, die den Dekompressor
mit Hinweisen darüber
versehen, wie Header-Felder sich verändert haben, z.B. als Folge eines
Verlusts über
die zellulare Strecke. In ROHC wird die Identifikation des Paket-Typs
in das Header-Kompressionsverfahren eingebaut, und somit wird diese
Funktionalität
nicht von dem Link-Layer benötigt.
Diesbezüglich
kann das ROHC Kontext-Identifizierer (CIDs) der Größe 0, 1
oder 2 Bytes aufweisen.
-
Ein
Projekt, welches als das Third Generation Partnership Project (3GPP)
bekannt ist, hat den Grundgedanken, die UTRAN und GSM-gestützten Funkzugriffsnetz-Technologien,
einschließlich
einer Header-Kompression für
UDP/IP und TCP/IP Header weiter zu entwickeln. Ein Aspekt des 3GPP-Systems,
das von Wichtigkeit für
Header-Kompressionsverfahren ist, ist das Konzept von logisch getrennten
Kanälen
oder Funkträgern
(anstelle von vollständig
gemeinsam verwendeten Kanälen
[wie beispielsweise dem Internet]). Es ist vorgeschlagen worden,
dass Kontext-Identifzierer (CIDs) verwendet werden, um zu identifizieren,
welcher Kontext verwendet werden sollte, um einen komprimierten
Header zu dekomprimieren; siehe S. Casner, V. Jacobson, "Compressing IP/UDP/RTP
Headers for Low-Speed Serial Links", RFC 2508, Februar 1999, und Mikael Degermark,
Bjorn Nordgren, Stephen Pink, "IP
Header Compression",
RFC 2507, Februar 1999. In einem 3GPP zellularen System ist bereits
eine Demultiplexierung des Verkehrs auf unterschiedliche Funkträger vorgenommen
worden, und diese Trennung reduziert die Notwendigkeit für eine Kontext-Identifikation.
Deshalb ist die Anzahl von Kontexten pro Funkträger relativ klein.
-
Die
Spezifikation 3G TS 25.323 V3.3.0 (2000-09) des Third Generation
Partnership Project (3GPP) beschreibt ein Link-Layer-Protokoll,
welches als Packet Data Convergence Protocol (PDCP) bekannt ist.
Einige der Hauptfunktionen des Packet Data Convergence Protocol
(PDCP) sind: (1) Transfer von Paketdatenprotokoll-Benutzerdaten
unter Verwendung von Diensten, die durch das Radio Link Control
(RLC) Protokoll bereitgestellt werden; und (2) eine Header-Kompression
(z.B. eine Kompression von redundanter Steuerinformation). Das Packet
Data Convergence Protocol (PDCP) stellt seine Dienste mit Hilfe
von PDCP-Einheiten an der Benutzergeräteeinheit (UE) oder an dem
Relais (an der Weitergabe) an dem Funknetz-Controller (RNC) bereit. In
seiner gegenwärtigen
Form (z.B. TS 25.323v3.3.0) in dem Packet Data Convergence Protocol
(PDCP) ist jeder Funkträger
mit einer PDCP-Einheit verbunden und eine PDCP-Einheit ist mit einer
RLC-Einheit verbunden. Jede PDCP-Einheit verwendet entweder Null,
Eins, oder mehrere Header-Kompressions-Algorithmustypen mit bestimmten
Parametern und mehrere PDCP-Einheiten können den gleichen Algorithmustyp
verwenden.
-
In
dem Packet Data Convergence Protocol (PDCP) ist das Header-Kompressionsverfahren
spezifisch für
jeden Netzschichtprotokoll-Typ. Die Header-Kompressions-Algorithmen
und deren Parameter werden durch eine Funkressourcensteuerung (RRC)
für jede
PDCP-Einheit verhandelt und dem PDCP durch einen PDCP Control Service
Access Point (RDCP-C-SAP) angezeigt. Eine vom Kompressor und vom
Dekompressor initiierte Signalisierung zwischen Peer-PDCP-Einheiten
während
eines Betriebs wird in der Benutzerebene ausgeführt.
-
Wie
in der 3GPP-Spezifikation 3G TS 25.323 V3.3.0 (2000-09) aufgeführt, umfasst
das Packet Data Convergence Protocol (PDCP) eine Protokolldateneinheit
(PDU), die eine von drei Typen sein kann. Der erste Typ ist eine
PDCP-Kein-Header PDU; der zweite Typ ist eine PDCP-Daten-PDU; und
der dritte Typ ist eine PDCP SeqNum PDU. Sowohl die PDCP Daten-PDU
als auch die PDCP SeqNum PDU umfassen ein PDU Typen-Feld von drei
Bit und ein PID Feld von fünf
Bit. Ein Wert in dem PDU Typ Feld mit drei Bit zeigt an, ob die PDU
eine PDCP Daten-PDU oder eine PDCP SeqNum PDU ist (siehe z.B. die
3GPP Spezifikation 3G TS 25.323 V3.3.0 (2000-09), Sektion 8.3.1).
Das PID Feld mit fünf
Bit zeigt die verwendete Header-Kompression und den Paket-Typ an.
-
Eine
PDCP Daten-PDU mit ihrem PDU Typen-Feld von drei Bit und dem PID
Feld von fünf
Bit, wie in der 3GPP Spezifikation 3G TS 25.323 V3.3.0 (2000-09)
aufgeführt.
Die nachstehende Tabelle 1 ist aus der 3GPP Spezifikation 3G TS
25.323 V3.3.0 (2000-09) genommen, und zwar als Beispiel einer PID
Wertzuordnung für
das PID Feld von fünf
Bit für
die PDCP Daten-PDU (siehe z.B. die 3GPP Spezifikation 3G TS 25.323 V3.3.0
(2000-09), Sektion 8.2.2 und Sektion 8.3.2).
-
-
Wie
in der 3GPP-Spezifikation 3G TS 25.323 V3.3.0 (2000-09), Sektion
5.1.1 beschrieben, startet für einen
bestimmten Algorithmus in einer PCDP-Einheit die Zuweisung von PID-Werten
von (n + 1), wobei n die Anzahl von PID-Werten ist, die bereits
anderen Algorithmen zugewiesen worden sind. Die Zuweisung wird in der
Reihenfolge durchgeführt,
in der die Algorithmen durch die Radio Ressource Control verhandelt
werden. In dem Beispiel der Tabelle 1 ist RFC2507 der erste zugewiesene
Algorithmus, das Verfahren A war der zweite Algorithmus, und das
Verfahren B war der dritte Algorithmus in dem PDCP Informationselement,
welche zwischen Peer-Radio-Resource-Control-Einheiten ausgetauscht
wurde.
-
Der
voranstehend erwähnte
Mechanismus zum Unterscheiden zwischen Kontexten kann entweder explizit
in dem Header-Kompressionsverfahren durch die Verwendung der Kontextidentifizierer
(CIDs) oder implizit durch Verwendung eines Link-Layer-Mechanismus
zum Unterscheiden der komprimierten Flüsse vor sich gehen. Die Verwendung
expliziten CIDs erfordert zusätzliche
Bits in den komprimierten Headern, wie bei der ROHC-Technik, auf
dem Header-Kompressionsniveau. Andererseits bedingt die Verwendung
einer impliziten Kontextidentifikation auf der Link-Layer-Ebene,
wie bei dem Packet Data Convergence Protocol (PDCP), zusätzliche
Kosten auf der Link-Layer-Ebene.
-
In
einem Verfahren, bei dem kein PDCP-Header vorhanden ist (siehe z.B.
die 3GPP Spezifikation 3G TS 25.323 V3.3.0 (2000-09), Sektion 8.2.1)
gibt es keine Möglichkeit,
eine Link-Layer-Identifikation von Header-Kompressionspaket-Typen
durch PDCP anzubieten. Dies bedeutet, dass die IP-Header-Kompression (RFC2507)
nicht verwendet werden kann, wenn PDCP mit der Kein-Header Option
konfiguriert ist. Jedoch kann der ROHC-Algorithmus in diesem Modus
verwendet werden, da die Identifikation des Header-komprimierten
Pakets innerhalb von ROHC erreicht wird.
-
Wohingegen
ROHC eine RTP/UDP/IP Kompression unterstützen kann, unterstützt der
RFC2507 Kompressionsalgorithmus (unter anderem) eine TCP-IP Kompression.
Bei bestimmten Anwendungen wird es wahrscheinlich in der Zukunft
der Fall sein, RTP/UDP/IP als auch TCP/IP Verkehr zu mischen, wie
bei Streaming-Diensten (z.B. zum Beispiel bei Echtzeit-Multimedia-Anwendungen).
-
Was
deshalb benötigt
wird, und eine Aufgabe der vorliegenden Erfindung ist, ist eine
Technik, die ein Mischen von Paketen mit Headern erlaubt, die durch
ein oder mehrere Kompressionsalgorithmen komprimiert werden, die
eine Pakettyp-Identifikation auf der Link-Ebene erfordern, wobei
andere Pakete Header aufweisen, die durch ein oder mehrere Kompressionsalgorithmen
komprimiert werden, die nicht eine Pakettyp-Identifikation auf der
Link-Ebene erfordern.
-
KURZE ZUSAMMENFASSUNG
DER ERFINDUNG
-
Die
Erfindung betrifft eine Einheit zur Kommunikation, umfassend eine
Einrichtung zum Senden eines Pakets mit einem komprimierten Header,
wie im Anspruch 1 aufgeführt.
Sie betrifft auch das entsprechende Verfahren, wie in dem unabhängigen Anspruch
17 aufgeführt.
Ein Knoten eines Telekommunikationsnetzes, der die Einheit aufweist,
wird im Anspruch 13 beansprucht und das entsprechende Telekommunikationssystem wird
im Anspruch 16 beansprucht. Weitere detaillierte Ausführungsformen
sind in den anderen abhängigen
Ansprüchen
definiert.
-
Ein
Telekommunikationsnetz weist erste und zweite Einheiten auf, die
durch Senden eines Pakets mit einem komprimierten Header kommunizieren.
Ein Header-Kompressionsschlüssel
gehört
zu dem Paket (z.B. ist in diesem enthalten). Der Header-Kompressionsschlüssel weist
ein erstes Feld auf, das in einem ersten Modus der Erfindung, exklusiv
zum Unterscheiden zwischen unterschiedlichen Flüssen von komprimierten Paketen
verwendet wird. In einem zweiten Modus der Erfindung kann das erste
Feld des Header-Kompressionsschlüssels
entweder zum Unterschieden zwischen den unterschiedlichen Flüssen von
komprimierten Paketen oder zum Unterscheiden zwischen unterschiedlichen
Header-Kompressions-Identifizierern
verwendet werden.
-
Ob
das erste Feld des Header-Kompressionsschlüssel exklusiv zum Unterscheiden
zwischen unterschiedlichen Flüssen
von komprimierten Paketen (dem ersten Modus) verwendet wird, oder
zum Unterscheiden zwischen unterschiedlichen Header-Kompressions-Identifizierern
(zweiter Modus) verwendet wird, hängt von dem Wert in dem zweiten
Feld des Header-Kompressionsschlüssels
ab.
-
In
dem zweiten Modus wird ein erster Untersatz von Werten für das erste
Feld des Header-Kompressionsschlüssels verwendet,
um zwischen unterschiedlichen Header-Kompressions-Identifizierern
zu unterscheiden, während
ein zweiter Untersatz von Werten für das erste Feld verwendet
wird, um zwischen den unterschiedlichen Flüssen von komprimierten Paketen
zu unterscheiden. Die Werte des zweiten Untersatzes folgen vorzugsweise
den Werten in dem ersten Untersatz.
-
In
einer illustrierten Ausführungsform
ist der Header-Kompressionsschlüssel
ein Header einer Protokolldateneinheit eines Link-Layer-Protokolls
und insbesondere ein Header für
eine Protokolldateneinheit für
ein Protokoll, welches als Packet Data Convergence Protocol (PDCP)
bekannt ist. Bei dieser Ausführungsform
ist das erste Feld ein PID Typ Feld des Headers der Protokolldateneinheit
und das zweite Feld ist ein PDU Typ Feld des Headers der Protokolldateneinheit.
Die Unterscheidung zwischen unterschiedlichen Flüssen von komprimierten Paketen
wird durch Kontextidentifizierer für einen Kompressions/Dekompressions-Algorithmus und
vorzugsweise einen Kompressions/Dekompressions-Algorithmus wie dem Robust Header Compression (ROHC)
Algorithmus ausgeführt,
der nicht eine Pakettyp-Identifikation auf einer Link-Layer-Ebene
erfordern. Für
den zweiten Modus bezeichnen die Header-Kompressions-Identifizierer
in dieser Ausführungsform
ein Header-Kompressionsverfahren und einen Pakettyp.
-
Eine
Beispielimplementierung der Erfindung ist ein zellulares Telekommunikationsnetz,
bei dem die erste Einheit eine Header-Kompressions/Dekompressions-Einheit
ist, die an einem Funknetz-Controllerknoten (RNC)
angeordnet ist, und die zweite Einheit eine Header-Kompressions/Dekompressions-Einheit
in einer Benutzergeräteeinheit
(UE), z.B. einem zellularen Telefon oder einer anderen Einheit mit
einem mobilen Abschluss, ist.
-
Die
vorliegende Erfindung erlaubt in vorteilhafter Weise einem Kompressionsebenen-Header
(z.B. einem ROHC-Header), der in einem Datenabschnitt (z.B. einem
Kein-Header-Abschnitt) der Protokolldateneinheit transportiert wird,
seinen Kontext-Identifizierer wegzulassen, da der Kontext-Identifizierer anstelle
davon in dem Header der Link-Layer-Protokolldateneinheit transportiert
wird. Somit kann die vorliegende Erfindung den Overhead, der sich
bei der Header-Übertragung
ergibt, verringern. Ferner ermöglicht
die vorliegende Erfindung in vorteilhafter Weise die Mischung von
Kompressions/Dekompressions-Techniken unabhängig davon, ob die Techniken
eine Pakettyp-Identifikation
auf der Link-Ebene erfordert, z.B. eine Mischung des Robust Header
Compression (ROHC) Algorithmus und der IP-Header-Kompressionsalgorithmen,
wie RFC2507. Eine derartige Mischung ermöglicht eine Unterstützung von
Kombinationen von komplexen Anwendungen, wie eine Mischung des RTP/UDP/IP-Verkehrs
(der ROHC verwendet) und des TCP/IP-Verkehrs (der eine RFC2507 Kompression
verwendet).
-
KURZBESCHREIBUNG
DER ZEICHNUNGEN
-
Die
voranstehenden und andere Aufgaben, Merkmale und Vorteile der Erfindung
ergeben sich aus der folgenden ausführlicheren Beschreibung von
bevorzugten Ausführungsformen,
wie in den beiliegenden Zeichnungen illustriert, in denen Bezugszeichen
auf die gleichen Teile überall
in den verschiedenen Ansichten verweisen Die Zeichnungen sind nicht
notwendigerweise im Maßstab,
wobei anstelle davon darauf geachtet wurde, die Prinzipien der Erfindung
zu illustrieren.
-
In
den Zeichnungen zeigen:
-
1 ein
diagrammartiges Funktionsblockdiagram eines Telekommunikationsnetzes,
das ein Header-Kompressionsverfahren mit einem Header-Kompressionsschlüssel gemäß einer
Ausführungsform
der vorliegenden Erfindung implementiert;
-
1A ein
diagrammartiges Funktionsblockdiagramm, das zeigt, dass ein Knoten
eines Telekommunikationsnetzes, beispielsweise von demjenigen der 1,
mehrere Konvergenzprotokolleinheiten in Übereinstimmung mit einer Ausführungsform
der vorliegenden Erfindung aufweisen kann;
-
2 eine
diagrammartige Ansicht, die ein Beispielformat einer Link-Layer-Protokolldateneinheit
mit einem Header-Kompressionsschlüssel zeigt;
-
3 eine
diagrammartige Ansicht eines beispielhaften Mobilkommunikationssystems,
in dem der Header-Kompressionsschlüssel der vorliegenden Erfindung
in vorteilhafter Weise verwendet werden kann;
-
4 ein
vereinfachtes Funktionsblockdiagramm eines Abschnitts des Systems
der 3, mit einer Benutzergeräteeinheit-(UE)-Station; einem
Funknetz-Controller; und einer Basisstation;
-
5 eine
diagrammartige Funktionsblockansicht des Telekommunikationsnetzes
der 3, wobei nähere
Einzelheiten einer Implementierung des Header-Kompressionsschlüssels gezeigt
sind;
-
6 eine
diagrammartige Ansicht, die beispielhafte Formate einer PDCP SDU
und einer PDCP PCU in Übereinstimmung
mit der Ausführungsform
der 3–5 zeigt;
-
7 eine
diagrammartige Ansicht eines beispielhaften RNC-Knotens in Übereinstimmung
mit einer Ausführungsform
der Erfindung; und
-
8 eine
schematische Ansicht eines beispielhaften Basisstationsknotens in Übereinstimmung
mit einer Ausführungsform
der Erfindung.
-
AUSFÜHRLICHE
BESCHREIBUNG DER ZEICHNUNGEN
-
In
der folgenden Beschreibung werden für die Zwecke einer Erläuterung
und nicht zur Beschränkung spezifischer
Einzelheiten aufgeführt,
wie beispielsweise bestimmte Architekturen, Schnittstellen, Techniken, etc.,
um ein gründliches
Verständnis
der vorliegenden Erfindung bereitzustellen. Jedoch werden Durchschnittsfachleute
in dem technischen Gebiet erkennen, dass die vorliegende Erfindung
in anderen Ausführungsformen
praktisch umgesetzt werden kann, die von diesen spezifischen Einzelheiten
abweichen. In anderen Fällen
werden eine ausführliche
Beschreibung von altbekannten Einrichtungen, Schaltungen und Verfahren
weggelassen, um so die Beschreibung der vorliegenden Erfindung nicht
mit unnötigen
Details zu belasten.
-
1 zeigt,
als eine beispielhafte nicht-beschränkende Ausführungsform der vorliegenden
Erfindung, ein Telekommunikationsnetz 10, welches eine
erste und zweite Konvergenzprotokolleinheit 201 , 202 aufweist, die miteinander über eine
Strecke 21 durch Senden eines Pakets 22 kommunizieren.
Wie nachstehend erläutert,
weist in Übereinstimmung
mit der vorliegenden Erfindung das Paket 22 einen Header-Kompressionsschlüssel 23,
sowie einen Datenabschnitt, der sowohl einen komprimierten Header 24' als auch eine
Nutzlast 25 einschließt,
auf.
-
In
dem Beispiel der Ausführungsform
der 1 sind erste und zweite Konvergenzprotokolleinheiten 201 , 202 an
jeweiligen Knoten 261 , 262 des Telekommunikationsnetzes angeordnet.
In dem bestimmten in 1 dargestellten Szenarium empfängt der
Knoten 261 mehrere Ströme von Paketen
PFx von einer Benutzerebene, e. g. Paketflüsse PF0–PFn. Jedes Paket der Paketflüsse PFx weist sowohl einen nicht komprimierten Header 24 als
auch eine Nutzlast 25 auf. Wenn ein Paket an dem Knoten 261 empfangen wird, werden verschiedene
Aktivitäten
ausgeführt.
Wichtig für
die vorliegende Erfindung ist ein Header-Kompressionsbetrieb, der
durch einen Kompressionseinheitssystem 211 ausgeführt wird,
das in der Konvergenzprotokolleinheit 201 des
Knotens 261 enthalten ist. In Verbindung
mit der Header-Kompression
erzeugt das Kompressionseinheitssystem 291 einen
Kontextidentifizierer (CID) für
jedes Paket 1 zeigt z.B. einen Kontextidentifizierer
CID0, der für ein Paket in dem Paketfluss
PS0 erzeugt wird, und einen Kontextidentifizierer
CIDn, der für ein Paket in dem Paketfluss
PFn erzeugt wird. Die Abbildung von PFx auf CIDy ist beliebig
(mit x und y in dem Bereich von 0 bis n), typischerweise mit x =
y.
-
Für jedes
an dem Knoten 261 ankommende Paket
erzeugt die Konvergenzprotokolleinheit 201 eine Link-Layer-Protokolldateneinheit,
die ebenfalls als Paket 22 in 1 dargestellt
ist. In der dargestellten Ausführungsform
wird die Link-Layer-Protokolldateneinheit 22 über eine
Strecke 21 übertragen,
die Layer 1 (Schicht 1) oder die niedrigste der zwei dargestellten
Schichten ist, und zwar von der Konvergenzprotokolleinheit 201 des Knotens 262 an
die Konvergenzprotokolleinheit 202 des
Knotens 262 . Die Link-Layer-Protokolldateneinheit
(Paket 22) kann einen Header aufweisen, wobei ein Teil
des Headers oder der gesamte Header auch hier als der Headerkompressionsschlüssel 23 bezeichnet
wird. Die Konvergenzprotokolleinheit 201 umfasst
eine Schlüsselformatierereinheit 1001 , die den Headerkompressionsschlüssel 23 erzeugt
oder formatiert. Wenn mehrere Paketflüsse in die Schlüsselformatierereinheit 1001 hineinfließen (z.B. IP/UDP/RTP und TCP/IP Flüsse), dann
konstruiert die Schlüsselformatierereinheit 101 einen geeigneten Headerkompressionsschlüssel 23,
der zu der Nutzlast 25 hinzugefügt wird.
-
Auf
einen Empfang hin führt
die Konvergenzprotokolleinheit 202 des
Knotens 262 verschiedene Operationen
für die
Pakete, die auf der Strecke 21 empfangen werden, aus, einschließlich der
Aufforderung an dessen Schlüssel
Entformatierer 1002 , den Headerkompressionsschlüssel 23 zu
Entformatieren, und das Auffordern seines Dekompressionssystems 292 , den Header 24' zu dekomprimieren. Nach der Dekompression kann
der Knoten 262 ein Paket an den
geeigneten Paketfluss FPx, der von dem Knoten 262 herauskommt (z.B. in Richtung auf
die Benutzerebene hin) lenken.
-
Wie
voranstehend erwähnt,
umfasst die Paket- oder Link-Layer-Protokolldateneinheit 22 den
Schlüssel 23 in
dem Link-Layer-Protokolldatenabschnitt des Pakets 22. In
einer Ausführungsform
ist der Schlüssel 23 im
wesentlichen ein Header für
die Link-Layer-Protokolldateneinheit 22 und wird durch
die Schlüsselformatfunktion 100 erzeugt,
die in der Konvergenzprotokolleinheit 201 enthalten
ist. Der Link-Protokoll-Datenabschnitt des
Pakets 22 umfasst den komprimierten Header 24' (als Folge
der Kompressionsaktivität
des Kompressionseinheitssystems 291 )
und die Nutzlast 25 des Benutzerebenenpakets.
-
2 zeigt,
etwas vergrößert, die
Link-Layer-Protokolldateneinheit 22 oder das Paket, welches
sich über
die Strecke 21 von der Konvergenzprotokolleinheit 201 des Knoten 261 an
die Konvergenzprotokolleinheit 202 des
Knotens 262 bewegt. In der dargestellten
Ausführungsform
der 2 ist der Headerkompressionsschlüssel 23 das
erste Oktett der Link-Layer-Protokolldateneinheit 22 und
umfasst zwei Felder, insbesondere ein erstes Feld 23A,
insbesondere ein erstes Feld 23A und ein zweites Feld 23B.
Es ist zufällig
so, dass in dem Headerkompressionsschlüssel 23 die fünf Bits
der niedrigsten Ordnung ein erstes Feld 23A abbilden und die
drei Bits der höchsten
Ordnung das zweite Feld 23B bilden. Es sei darauf hingewiesen,
dass sich die Platzierung und Größe in anderen
Feldern in anderen Ausführungsformen
verändern
kann.
-
Die
vorliegende Erfindung kann in vielerlei Moden betrieben werden,
wobei zwei davon in 2 als der erste Modus und der
zweite Modus dargestellt sind. Ein Wert in dem zweiten Feld 23B zeigt
an, welcher Modus der Erfindung gerade für ein gegebenes Paket verwendet
wird. Zum Beispiel kann ein 010 Bit Muster mit dem zweiten Feld 23B anzeigen,
dass der erste Knoten der Erfindung anwendbar ist, während ein
000 Bit Muster in dem zweiten Feld 23B anzeigen kann, dass
der zweite Modus der Erfindung anwendbar ist. Andere Konventionen
von Bit-Mustern für
das zweite Feld 23B können
natürlich
verwendet werden. Zusätzlich
könnte 23B den
zwischen Header-Kompressionsalgorithmus anzeigen, der mit einer
Kontextidentifikation verwendet werden soll.
-
In
dem ersten Modus der Erfindung wird der Wert in dem ersten Feld 23A exklusiv
zum Unterscheiden zwischen unterschiedlichen Flüssen von komprimierten Paketen
verwendet. Mit anderen Worten, wenn das zweite Feld 23B des
Headerkompressionsschlüssel 23 anzeigt,
dass der erste Modus in Betrieb ist, wird realisiert, dass das erste
Feld 23A einen Kontextidentifizierer (CID) enthält. In dem
ersten Modus der Erfindung sind alle Zahlen in dem ersten Feld 23A Kontextidentifizierer
(CIDs), mit dem Ergebnis, dass die Kontextidentifizierer (CID)-Numerierung
bei Null beginnen kann und um eins für jeden neuen Paketfluss ansteigen
kann.
-
In
dem zweiten Modus der Erfindung kann das erste Feld 23A des
Headerkompressionsschlüssels entweder
zum Unterscheiden zwischen unterschiedlichen Headerkompressionsidentifizierern
oder zum Unterscheiden zwischen den unterschiedlichen Flüssen von
komprimierten Paketen verwendet werden. Insbesondere wird in dem
zweiten Modus ein erster Untersatz von Werten für das erste Feld 23A des
Headerkompressionsschlüssels
verwendet, um zwischen unterschiedlichen Headerkompessionsidentifizierern
zu unterscheiden, während
ein zweiter Untersatz von Werten für das erste Feld 23A verwendet
wird, um zwischen den unterschiedlichen Flüssen von komprimierten Paketen
zu unterscheiden. Die Werte des zweiten Untersatzes folgen vorzugsweise
den Werten des ersten Untersatzes.
-
Als
ein Beispiel des zweiten Modus können
die ersten k Anzahl von Werten in dem ersten Feld 23A des
Headerkompressionsschlüssels 23 verwendet
werden, um zwischen einer Anzahl k von unterschiedlichen Headerkompressionsidentifizierern
zu unterscheiden [z.B. Headerkompressionsidentifizierer 0 bis (k – 1)]. Die verbleibenden
Werte des ersten Felds 23A können dann verwendet werden,
um zwischen den unterschiedlichen Flüssen von komprimierten Pakten
(CIDs) für
einen oder mehrere Headerkompressionsalgorithmen zu unterschieden.
Wenn somit das erste Feld 23A fünf Bits aufweist, dann können die
k + 1ten bis 32ten Werte
des ersten Felds 23A sich auf einen Kompressionskontextidentifizierer
beziehen.
-
Aus
der voranstehenden Beschreibung lässt sich entnehmen, dass dann,
wenn der Wert in dem ersten Feld 23A des Headerkompressionsschlüssels 23 einer
der ersten Anzahl k von möglichen
Werten ist, der als ein Headerkompressionsidentifizierer erkannt
wird. Wenn andererseits der Wert in dem ersten Feld 23A des Headerkompressionsschlüssels 23 außerhalb
(z.B. größer) als
die erste Anzahl k von möglichen
Werten ist, wird er als ein Flussidentifizierer (z.B. CID) erkannt.
-
1 zeigt,
dass die Erfindung mit ihrem Headerkompressionsschlüssel 23 in
einem generischen Telekommunikationsnetz mit zwei Knoten, z.B. Knoten 261 und 262 implementiert
werden kann. Eine andere beispielhafte, nicht-beschränkende Implementierung
der Erfindung ist ein zellulares Telekommunikationsnetz, bei dem
die erste Einheit eine Header-Kompressions-/Dekompressions-Einheit
ist, die an einem Funknetz-Controllerknoten (RNC) angeordnet ist,
und die zweite Einheit eine Header-Kompressions-/Dekompressions-Einheit
in einer Benutzergeräteeinheit
(UE), z.B. einem zellularem Telefon oder einer anderen Einheit mit
einem mobilen Abschluss, ist. Eine beispielhafte, nichtbeschränkende Konfiguration
für eine
derartige Implementierung ist das Universal Mobile Telecommunications
(UMTS) 3-10 System, das in 3 gezeigt
ist Ein anderes Beispiel ist GERAN oder irgendein anderes Funkzugriffsnetz,
das das PDC Abspielgerät
in seinem Luftschnittstellen-Protokollstapel verwendet.
-
In
dem Universal Mobile Telecommunications (UMTS) System 3-10 der 3 kann
repräsentatives, verbindungsorientiertes,
externes Kernnetz, welches als Wolke 3-12 gezeigt ist,
z.B. das öffentliche
Telefonvermittlungsnetz (PSTN) und/oder das dienstintegrierte Digitalnetz
(ISDN) sein. Ein repräsentatives,
verbindungsloses-orientiertes externes Kernnetz, welches als eine
Wolke 3-14 gezeigt ist, kann z.B. das Internet sein. Beide
Kernnetze sind mit ihren entsprechenden Dienstknoten 3-16 gekoppelt.
Das PSTN/ISDN verbindungs-orientierte Netz 3-12 ist mit
einem verbindungs-orientierten Dienstknoten verbunden, der als ein
Mobilvermittlungszentrum (MSC) Knoten 3-18 gezeigt ist,
der leitungsvermittelte Dienste bereitstellt. Das Internetverbindungslose-orientierte
Netz 3-14 ist mit General Packed Radio Service (GPRS) Knoten 3-20 verbunden, die
zugeschnitten sind, um Dienste eines Paketvermittelten Typs bereitzustellen,
die manchmal als die bedienenden GPRS Dienstknoten (SGSN) bezeichnet
werden.
-
Jeder
der Kernnetz-Dienstknoten 3-18 und 3-20 ist mit
einem UMTS Terrestrial Radio Access Network (UTRAN) 3-24 über eine
Funkzugriffsnetz-(RAN)-Schnittstelle verbunden, die als die Iu Schnittstelle
bezeichnet wird. Das UTRAN 3-24 umfasst ein oder mehrere
Funknetzcontroller (RNCs) 3-26. Zur Vereinfachung ist das
UTRAN 3-24 der 3 mit nur einem RNC Knoten 3-26 gezeigt.
Jeder RNC 3-26 ist typischerweise mit einer Vielzahl von
Basisstationen (BS) 3-28 verbunden. Zum Beispiel und wiederum
zur Vereinfachung ist nur eine Basisstation 3-28 gezeigt,
die mit dem RNC 3-26 verbunden ist. Es sei darauf hingewiesen,
dass eine andere Anzahl von Basisstationen von jedem RNC bedient
werden kann und dass RNCs nicht die gleiche Anzahl von Basisstationen
bedienen müssen.
-
Eine
Benutzergeräteeinheit
(UE) wie eine Benutzergeräteeinheit
(UE) 3-30, die in 3 gezeigt
ist, kommuniziert mit ein oder mehreren Basisstationen BS 3-28 über eine
Funk- oder Luftschnittstelle 3-32. Jede der Funkschnittstellen 3-32 der
Iu Schnittstelle und der Iub Schnittstelle ist mit strichpunktierten
Linien in 3 gezeigt.
-
Vorzugsweise
basiert der Funkzugriff auf einem breitbandigen Codeteilungs-Mehrfachzugriff
(Wideband Code Division Multiple Access; WCDMA) mit einzelnen Funkkanälen, die
unter Verwendung von CDMA Spreizungscodes zugeordnet werden. Natürlich können andere
Zugriffsverfahren verwendet werden, z.B. GERAN. WCDMA stellt eine
breite Bandbreite für
Multimediadienste und anderer Anforderungen mit hoher Übertragungsrate,
sowie robuste Funktionen, wie ein Diversity-Handoff und RAKE Empfänger zur
Sicherstellung einer hohen Qualität bereit. Jeder Mobilstation
oder jeder Geräteeinheit
(UE) 3-30 ist ihr eigener Verscrambelungscode zugewiesen,
damit eine Basisstation 3-28 Übertragungen von dieser bestimmten
Benutzergeräteeinheit
(UE) identifizieren kann, und außerdem damit die Benutzergeräteeinheit
(UE) Übertragungen
von der Baisstation, die für
diese Benutzergeräteeinheit
(UE) vorgesehen sind, von allen anderen Übertragungen und Rauschen,
das in dem gleichen Gebiet vorhanden ist, identifizieren kann.
-
4 zeigt
gewählte
allgemeine Aspekte einer Benutzergeräteeinheit (UE) 3-30 und
illustrative Knoten, wie den Funknetzcontroller 3-26 und
die Basisstation 3-28. Die in 4 gezeigte
Benutzergeräteeinheit (UE) 3-30 umfasst
eine Datenverarbeitungs- und Steuereinheit 3-31 zum Steuern
von verschiedenen Operationen, die von der Benutzergeräteeinheit
(UE) benötigt
werden. Die Datenverarbeitung- und Steuereinheit 3-31 der
UE stellt Steuersignale sowie Daten an einem Funk-Sender/Empfänger 3-33,
der mit einer Antenne 3-35 verbunden ist, bereit.
-
Der
beispielhafte Funknetz-Controller 3-26 und die Basisstation 3-28,
wie in 4 gezeigt, sind Funknetzknoten, die jeweils eine
entsprechende Datenverarbeitungs- und Steuereinheit 3-36 bzw. 3-37 umfassen, um
zahlreiche Funk- und Datenverarbeitungsoperationen auszuführen, die
benötigt
werden, um Kommunikationen zwischen dem RNC 3-26 und den
Benutzergeräteeinheiten
(UEs) 3-30 auszuführen.
Ein Teil des Geräts,
das durch die Basisstations-Datenverarbeitungs- und Steuereinheit 3-37 gesteuert
wird, umfasst mehrere Funk-Sender/Empfänger 3-38, die mit
einer oder mehreren Antennen 3-39 verbunden sind.
-
In
dem Universal Mobile Telecommunications Systems (UMTS) 3-10 der 3 und 4 nehmen
die Konvergenzprotokolleinheit 201 und
die Konvergenzprotokolleinheit 202 die
Form von Paketdaten-Konvergenzprotokoll (Packed Data Convergence
Protokoll; PDCP) Einheiten 201 bzw. 202 an. Die PDCP Einheiten 201 und 202 sind
jeweils an dem Funknetzcontroller-(RNC)-Knoten 3-26 und
der Benutzergeräteeinheit
(UE) 3-30 angeordnet. Somit wird in diesem Sinn die Benutzergeräteeinheit
(UE) 3-30 als ein Knoten wenigstens in Bezug auf die Link-Schicht
(Link Layer) angesehen. Wie in der Ausführungsform der 1 weisen
die PDCP Einheiten 201 und 202 jeweils Kompressionssysteme 291 bzw. 292 auf.
Ferner, in Analogie zu den Schlüsselformatierer/Entformatierer-Funktionen 100 der 1,
weIsen die PDCP Einheiten 201 und 202 die PDCP PDU Header-Formatierer/Entformatierer 1001 , 1002 auf.
-
Zu
dem Zeitpunkt, der in 3 gezeigt ist, ist nur ein Paketfluss
in der Richtung von dem Funknetzsteuerungs-(RNC)-Knoten 3-26 zu
der Benutzergeräteeinheit
(UE) 3-30 gezeigt. In diesem Moment führt die PDCP Einheit 201 gerade eine Headerkompression aus
(wobei ihr PDCP DPU Headerformatierer/Entformatierer 100 den
Headerkompressionsschlüssel 23 der
vorliegenden Erfindung einfügt),
während
die PDCP Einheit 202 gerade eine
Dekompression etc. ausführt.
Es sei jedoch darauf hingewiesen, dass der Paketfluss typischerweise
bidirektional ist und dass sich Pakete auch von der Benutzergeräteeinheit
(UE) 3-30 an den Funknetzsteuerungs-(RNC)-Knoten 3-26 bewegen,
für die
die PDCP Einheit 202 eine Headerkompression
ausführt (wobei
der PDCP DPU Headerformatierer/Entformatierer 1002 den
Headerkompressionsschlüssel 23 der
vorliegenden Erfindung einfügt,
während
die PDCP Einheit 201 die Dekompression
ausführt.
-
In
dem Beispiel der Ausführungsform
der 3 und 4 ist der Header-Kompressionsschlüssel ein Header
einer Protokolldateneinheit eines Link-Layer-Protokolls und insbesondere
ein Header für
eine Protokolldateneinheit für
ein Protokoll, welches als Packet Data Convergence Protokoll (PDCP)
bekannt ist. Wie voranstehend erwähnt, wird das mit Packet Data
Convergence Protokoll (PDCP) z.B. in der Third Generation Partnership
Project (3GPP) Spezifikation 3G TS 25.323 V3.3.0 (2000-09) beschrieben.
In der Ausführungsform
der 3 und 4 ist das erste Feld 23A des
Header-Kompressionsschlüssels 23 ein
PID Typ Feld des Headers der Protokolldateneinheit (PDU) und das
zweite Feld 23B ist ein PDU Typ Feld des Headers der Protokolldateneinheit
(PDU).
-
5 ähnelt 1,
zeigt aber den speziellen Fall der Ausführungsform der 3 und 4,
wobei der Header-Kompressionsschlüssel ein Header einer Protokolldateneinheit
(PDU) für
das Packet Data Convergence Protokoll (PDCP) ist, und wobei die
Paketflüsse
Internet-Protokoll-(IP)-Paketflüsse
sind. In dieser beispielhaften Ausführungsform wird eine Unterscheidung
zwischen unterschiedlichen Flüssen
von komprimierten Paketen durch einen Kontext-Identifizierer für einen
Kompressions/Dekompressions-Algorithmus
ermöglicht,
der in das PID-Feld (z.B. Feld 23A) des Header-Kompressionsschlüssel 23 eingefügt ist.
Vorzugsweise ist der Kontext-Identifizierer (CID) für einen
Kompressions/Dekompressions-Algorithmus,
wie beispielsweise den Rubust-Header-Compression-(ROHC)-Algorithmus,
der nicht eine Paket-Typ Identifikation auf einer Link-Layer-Ebene
erfordert.
-
Aus 5 und 6 lässt sich
ersehen, dass ein Paket, welches als eine PDCP-Dienstdateneinheit (PDCP
SDU) bekannt ist, an einer PDCP-Einheit, (wie der PDCP-Einheit 201 ) von der Benutzerebene empfangen wird.
Die PDCP SDU enthält
typischerweise einen Header 24 und eine Nutzlast 25.
Der PDCP SDU Header 24 umfasst in dieser Ausführungsform
einen IP Header, einen UDP Header und eine RTP Header, die alle zusammengenommen
als der IP Header bezeichnet wird. Eine andere Alternative ist,
dass der PDCP SDU Header 24 einen IP Header und einen TCP
Header einschließt.
Bei der Verwendung des ROHC Kompressionsalgorithmus komprimiert
die Kompressionseinheit 291 den
Header 24, um einen komprimierten Header 24' zu bilden,
der auch als der ROHC Header in 6 bezeichnet
wird. Die Nutzlast oder die Daten 25 zusammen mit dem komprimierten
Header 24' bilden
die PDCP PDU Daten. In einer beispielhaften, hier diskutierten Ausführungsform,
ist der komprimierte Header 24' ein ROHC Header, könnte aber
anstelle davon ein komprimierter Header von irgendeinem Header-Kompressionsalgorithmus
sein.
-
Die
PDCP-Einheit 201 erzeugt eine PDCP
Protokolldateneinheit (PDCP PDU). Für den Fall eines Betriebs (Fall
A, der in 6 gezeigt ist), weist die PDCP
PDU einen Header auf, der als der PDCP PDU Header bekannt ist. Aber
in einem anderen Fall des Betriebs (Fall B, der in 6 gezeigt
ist), muss die PDCP PDU nicht einen Header aufweisen (siehe z.B.
Third Generation Partnership Project (3GPP) Specification 3G TS 25.323
V3.3.0 (2000-09), Sektion 8.2.1). Für den Fall, bei dem ein PDCP
Header enthalten ist, erzeugt der PDCP DPU Header-Formattierer/Entformattierer
den PDCP Header, um den Header-Kompressionsschlüssel 23 einzubauen,
wie voranstehend beschrieben wurde. Die Ausführungsform der 3 und
der 4, die ebenfalls mit Hilfe von 5 und 6 erläutert wird,
kann (im Wesentlichen in der gleichen Weise, wie die Ausführungsform
der 1) in entweder dem ersten Modus oder dem zweiten
Modus der Erfindung arbeiten. In dem ersten Modus wird ein PID Feld 23A des
PDCP PDU Headers exklusive zur Unterscheidung zwischen unterschiedlichen
Flüssen
von komprimierten Paketen verwendet und deshalb wird irgendeine
Zahl in dem PID Feld 23A als der Kontext-Identifizierer
(CID) genommen. In dem zweiten Modus der Erfindung, wenn der Wert
in dem PID Feld 23A in einem ersten Untersatz oder einem
Bereich von Werten ist, werden die Inhalte des PID Felds 32A so
verstanden, dass sie ein bestimmter Kompressions-Identifizierer
sind. Andererseits, in dem zweiten Modus, wenn der Wert in dem PID
Feld 23A ein zweiter Untersatz oder Bereich von Werten
ist, werden die Inhalte des PID Felds 23A so verstanden,
dass sie ein bestimmter Kontext-Identifizierer (CID) zum Unterscheiden
zwischen unterschiedlichen Paketflüssen sind.
-
Wie
bei der Ausführungsform
der 1, zeigen die Inhalte des Felds 23B,
z.B. das PDU Typ Feld, an, ob eine PDCP PDU dem ersten Modus oder
dem zweiten Modus ausgesetzt ist. Bit-Muster in dem PDU Typ Feld
werden mit der Tabelle 2 erläutert.
-
-
Die
Tabelle 3 zeigt, wie groß CID
Werte dem PID Feld 23A in dem ersten Modus der Erfindung
zugewiesen werden, unter der Annahme, dass das PID Feld 23A fünf Bits
aufweist. In der Tabelle 3 kann RFCxxxx auf irgendein RFC-bezogenes
Kompressionsverfahren hinweisen, wie beispielsweise RFC2507.
-
-
Für die gleiche
Bit-Größenannahme
für das
PID Feld 23A (fünf
Bits), illustriert Tabelle 4, wie groß CID Werte dem PID Feld 23A in Übereinstimmung
mit dem zweiten Modus der Erfindung zugewiesen werden, wenn der
gleiche PDCP PDU Typ für
sowohl eine ROHC, als auch eine RFC2507 Kompression verwendet wird.
In der bestimmten Situation, die in der Tabelle 4 gezeigt ist, werden
die ersten zehn PID Werte in einer ähnlichen Weise zugewiesen,
wie in der Tabelle 1.
-
-
Wie
in 6 gezeigt ist der ROHC komprimierte Header 24' in der Lage
seinen eigenen Pakettyp zu identifizieren, so dass der PDCP Header 23 nicht
explizit benötigt
wird. Jedoch benötigt
der ROHC komprimierte Header 24' das CID Feld, um die Kontextflüsse zu identifizieren.
Das CID Feld kann acht oder sechzehn Bits lang in dem ROHC komprimierten
Header 24' sein.
Wenn der Kontext ID (CID) innerhalb eines Formats des PID Felds 23A des
Header-Kompressionsschlüssels 23 (z.B.
dem PDCP PDU Header) ausgedrückt
werden kann, kann die CID Identifikation anstelle davon in dem PDCP
PDU Header eingefügt
werden, wobei in diesem Fall das DIC Feld des ROHC komprimierten
Headers 24' eliminiert
werden kann, um Einsparungen zu realisieren.
-
Aus
der vorangehenden Beschreibung und aus Tabelle 4 lässt sich
erkennen, dass die Anzahl von ROHC Pakettypen oder Kontextidentifizierern
(CIDs) von der Größe des Felds 23A (z.B.
dem PID Feld) und dar Größe des Untersatzes
von Werten, die bereits durch die Kompressionsidentifizierer verwendet
werden (verwendet z.B: für
eine RFC2507 Kompression) abhängt.
Es wird angenommen, dass eine typische Anzahl von Kompressionsidentifizierern
für RFC2507
Pakettypen ungefähr
sechs sein würde,
wodurch dem Feld 23A erlaubt würde auch zweiundzwanzig Paketflüsse (CIDs)
aufzunehmen. In einer bevorzugten Ausführungsform, wenn ein Paketfluss
seinen CID in dem Headerkompressionsschlüssel 23 enthalten
hat (z.B. dem PID Feld des PDCP PDU Headers), muss der CIS nicht
in dem ROHC komprimierten Header 24' eingebaut werden (z.B: der ROHC
kann in seinem „=Byte-CID-Modus" laufen).
-
Für den Fall,
dass das Feld 23A nicht genug Werte in seinem zweiten Untersatz
verfügbar
hat, um die Anzahl von Paketflüssen
unterzubringen, sollte auch berücksichtigt
werden, dass ROHC auch in dem Backbone verwendet werden kann, wobei
in diesem Fall ein oder zwei Byte CID Felder verwendet werden können, um
die größere Anzahl
von Flüssen
unterzubringen, die existieren könnten.
Mit anderen Worten, die zusätzlichen
CID Werte können
in dem ROHC Paket eingebaut werden (z.B. dem komprimierten Paket 24' der Fig., zum
Beispiel).
-
7 zeigt,
mit etwas mehr Einzelheiten, einen beispielhaften nicht-beschränkenden
RNC Knoten 3-26, der mit der vorliegenden Erfindung verwendet
werden kann. Es ist so, dass der RNC Knoten 3-26 der 7 ein
vermittlungsstellengestützter
Knoten mit einer Vermittlungsstelle 3-26-120 ist. Die Vermittlungsstelle 3-26-120 dient
dazu, um andere Bestandteile des RNC Knotens 3-26 untereinander
zu verbinden. Derartige andere Bestandteile umfassen Erweiterungsterminals 3-26-1221 bis 3-26-1221 ,
sowie das Erweiterungsterminal 3-26-124. Erweiterungsterminals 3-26-1221 bis 3-26-122n dienen
im wesentlichen dazu den RNC Knoten 3-26 mit den Basisstationen 3-28 zu
verbinden, die durch den RNC Knoten 3-26 bedient wird;
das Erweiterungsterminal 3-26-124 verbindet den RNC Knoten 3-26 über die
Iu Schnittstelle mit dem Kernnetz. Obwohl nicht dargestellt, so
gibt es ein oder mehrere andere Erweiterungsterminals, um den RNC
Knoten 3-26 über einer
anderen Schnittstelle, die als Iur Schnittstelle bekannt ist, mit
anderen RNCs zu verbinden.
-
Noch
andere Bestandteile des RNC Knotens 3-26 umfassen eine
Diversity-Handover-Einheit 3-26-126; eine ALT Einheit 3-26-128;
den Codex 3-26-130, eine Timingeinheit 3-26-132;
eine Datendienste-Anwendungseinheit 3-26-134;
und einen Hauptprozessor 3-26-140. Der Durchschnittsfach
in dem technischen Gebiet wird erkennen, dass die ELT Einheit 3-26-128 eine
Einheit ist, die z.B: eine Mulitplexierung und Demultiplexierung
und (optional) eine Warteschlangenfunktion in Bezug auf verschiedene
Protokolle von Zellen bereitstellt. In dem beispielhaften RNC Knoten 3-26 der 7 ist
es der Hauptprozessor 3-26-140, der die PDCP Einheit 20 aufnimmt
und somit den PDCP DPU Headerformattierer/Entformattierer 100.
-
8 zeigt
in einer nicht-beschränkenden
Weise, weitere Details eines beispielhaften Basisstation (BS) Knotens 3-28 in Übereinstimmung
mit einer Ausführungsform
der vorliegenden Erfindung. Wie mit dem RNC Knoten 3-26 ist
der Basisstations-(BS)-Knoten 3-28 der 8 ein
vermittlungsstellengestützer
Knoten mit einer Vermittlungsstelle 3-28-220, die dazu
dient, andere Bestandelemente des Basisstations-(BS)-Knotens 3-28 untereinander
zu verbinden. Derartige andere Bestandteile umfassen ein Erweiterungsterminal 3-28-222;
eine ALT Einheit 3-28-228; einen BS Hauptprozessor 3-28-240,
und Schnittstellenboards 3-28-42.
-
Das
Erweiterungsterminal 3-28-22 verbindet den Basisstations-(BS)-Knoten 3-28 mit
dem Funknetzcontroller-(RNC)-Knoten 3-26, und umfasst somit
die Iub Schnittstelle. Wie für
den Fall des Funknetzcontroller-(RNC)-Knotens 3-26 ist
die ALT Einheit 3-28-228 eine Einheit, die z.B: eine Multiplexierung
und Demultiplexierung und (optional) eine Warteschlangenfunktion
in Bezug auf unterschiedliche Protokolle von Zellen bereitstellt.
-
Die
Ausführungsform
des Basisstations-(BS)-Knotens 3-28, der in 8 dargestellt
ist, ist in einem Einschub mit mehreren Untereinschüben untergebracht.
Jeder Untereinschub weist ein oder mehrere Boards auf, z.B. Schaltungsboards,
die darauf aufgebracht sind. Ein erster Untereinschub 3-28-250 enthält Boards
für jedes
Erweiterungsterminal 3-28-222; eine ALT Einheit 3-28-228;
einen BS Hauptprozessor 3-28-240, und Schnittstellenboards 3-28-242.
Jede der Schnittstellenboards 3-28-242 ist mit einem Board eines
anderen Untereinschubs verbunden, z.B. einem der Senderboards 3-28-260 oder
einem der Empfängerboards 3-28-270. Jedes
Empfängerboard 3-28-270 ist
verschaltet, um bestimmte Sender/Empfänger-Ressourcen in einem entsprechenden
Senderboard 3-28-260 gemeinsam zu verwenden, wobei das
Senderboard 3-28-260 mit einem entsprechenden der Verstärker- und
Filterboards 3-28-80 verbunden ist. Das Verstärker- und
Filterboard 3-28-280 ist mit einer geeigneten Antenne 3-29 verbunden.
Zum Beispiel ist das Schnittstellenboard 3-28-2421-T mit
dem Senderboard 3-28-601 verbunden,
während
das Schnittstellenboard 3-28-2421-R mit
dem Empfängerboard 3-28-2701 verbunden ist. Das Paar des Senderboards 3-28-2601 und des Empfängerboards 3-28-2701 ist wiederum mit dem Verstärker- und
Filterboard 3-28-2801 verbunden. Ähnliche
Verbindungen existieren für
eine zweite Paarbildung des Senderboards 3-28-2801 ,
und des Empfängerboards 3-28-2702 , die über das Schnittstelleboard 3-28-2422-T bzw. dem Schnittstellenboard 3-28-2422-R gekoppelt sind. Jeder Transceiver 3-38 der 4 umfasst
somit einen Untereinschub, der ein Senderboard 3-28-260,
ein Empfängerboard 3-28-270,
und eine Verstärker- und Filterkarte 3-28-280 einschließt.
-
In
einer beispielhaften Ausführungsform
ist der Basisstations-(BS)-Knoten 3-28 ein ATM-gestüzter Knoten,
mit Schnittstellenboards 3-28-242, die verschiedene ATM
Kopplungsfunktionen ausführen.
Die Senderboards 3-28-260 und die Empfängerboards 3-28-270 umfassen
jeweils mehrere Einrichtungen. Zum Beispiel umfasst jedes Senderboard 3-28-260 nicht
dargestellte Elemente, wie eine Schnittstelle, die mit ihrem entsprechenden
Schnittstellenboard 3-28-242 verbunden ist; einen Kodierer;
einen Modulator; und einen Basisbandsender. Zusätzlich umfasst das Senderboard 3-28-260 die
Sender/Empfänger-Ressourcen,
die es mit dem Empfängerboard 3-28-270 gemeinsam
verwendet, einschließlich
eines Funkfrequenzsenders. Jedes Empfängerboard 3-28-270 umfasst
nicht dargestellte Elemente, wie eine Schnittstelle, die mit ihrem
entsprechenden Schnittstellenboard 3-28-242 verbunden ist;
einen Decoder, einen Demodulator; und einen Basisbandempfänger. Jedes
Verstärker-
und Filterboard 3-28-280 umfasst Verstärker, wie MCPA und LNA Verstärker.
-
Die
vorliegende Erfindung erlaubt in vorteilhafterweise, dass ein Kompressions-Ebenenheader
(z.B. ein ROHC Header), der in einem Datenabschnitt geführt wird
(z.B. einem nicht-Header Abschnitt) der Protokolldateneinheit seinen
Kontextidentifizierer wegzulassen, das der Kontextindentifizierer
anstelle davon in dem Header der Link-Layer-Protokoll-Dateneinheit
geführt
wird. Somit kann die vorliegende Erfindung den Overhead verringern,
der an der Headerübertragung
beteiligt ist. Fernen erlaubt die vorliegende Erfindung in vorteilhafter
Weise eine Mischung von Kompressions-/Dekompressions-Techniken unabhängig davon,
ob die Techniken eine Pakettyp Identifikation auf der Link-Ebene
erfordern, z.B. eine Mischung des Robust Header Kompressions-(ROHC)-Algorithmus
und von IP Header Kompressionsalgorithmen wie RFC2507. Eine derartige
Mischung erlaubt die Unterstützung
von Kombinationen von komplexen Anwendungen, wie eine Mischung des
RTP/UDP/IP Verkehrs (der ROHC verwendet) und des TCP/IP Verkehrs
(der eine RFC2507 Kompression verwendet).
-
Zur
Vereinfachung sind die Knoten 26 in der Ausführungsform
der 1 so beschrieben worden, dass jeder nur eine Konvergenzprotokolleinheit 20 aufweist.
In ähnlicher
Weise und auch für
eine Zweckdienlichkeit, sind der RNC 3-26 und die Benutzergeräteeinheit
(UE) 3-30 in der Ausführungsform
der 3 und 4 so beschrieben worden, dass
sie nur eine PDCP Einheit 20 aufweisen. Jedoch sollte darauf
hingewiesen werden, dass jeder Knoten (z.B. RNC oder UE) tatsächlich mehrere
Einheiten 20 umfassen kann, wie in der beispielhaften Weise,
die in der 1A dargestellt ist. Zum Beispiel
weist der repräsentative
Knoten 26 der 1A drei Konvergenzprotokolleinheiten 20A bis 20C auf,
wobei jede Konvergenzprotokolleinheit ein oder mehre Kompressionseinheiten
(z.B: Kompressions-/Dekompressions-Maschinen, die jeweils unterschiedliche
Kompressions-/Dekompressions-Algorithmen ausführen) aufweist. Zum Beispiel
weist die Konvergenzprotokolleinheit 20A Kompressionseinheiten 30A1 und 30A2 auf;
eine Konvergenzprotokolleinheit 20B weist Kompressionseinheiten 30B1 und 30B2 auf;
und eine Konvergenzprotokolleinheit 20C weist eine Kompressionseinheit 30C1 auf. Ein oder mehrere Konvergenzprotokolleinheiten 20A bis 20C können die
gleichen oder ähnliche Kompressionseinheiten
aufweisen. Zum Beispiel kann die Kompressionseinheit 30C1 den gleichen Kompressionsalgorithmus
ausführen,
so wie dies die Kompressionseinheit 30A1 tut.
-
Es
sei darauf hingewiesen, unter besonderer Bezugnahme auf die generische
Ausführungsform
der 1, dass die Erfindung nicht auf die Verwendung
mit ROHC und RFCxxxx (z.B. RFC2507) Kompressionsalgorithmen beschränkt ist,
sondern dass andere Kompressionsalgorithmen vollständig innerhalb
des Umfangs der vorliegenden Erfindung sind. Wenn mit einem ROHC
gearbeitet wird, wird wenigstens ein Byte des Overheads pro ROHC
Paket gespeichert, wenn ROHC zusammen mit RFC2507 verwendet wird,
z.B. wenn TCP/IP (best effort; beste Anstrengung) Flüsse und
RTP/UDP/IP (Echtzeit) in dem gleichen PDCP Header vorhanden sind.
-
Während die
Erfindung in Verbindung mit Merkmalen beschrieben werden ist, die
gegenwärtig
als die am praktischste und am meisten bevorzugte Ausführungsform
angesehen wird, sei darauf hingewiesen, dass die Erfindung nicht
auf die offenbarte Ausführungsform
beschränkt
ist, sondern im Gegensatz dazu es beabsichtigt ist, dass sie verschiedene
Ausführungsformen
und äquivalente
Anordnungen abdeckt, die in dem Umfang der beigefügten Ansprüche enthalten
sind.