DE60007829T2 - Kopfkomprimierung für General Packet Radio Service Tunnel Protokoll (GTP) - Google Patents

Kopfkomprimierung für General Packet Radio Service Tunnel Protokoll (GTP) Download PDF

Info

Publication number
DE60007829T2
DE60007829T2 DE60007829T DE60007829T DE60007829T2 DE 60007829 T2 DE60007829 T2 DE 60007829T2 DE 60007829 T DE60007829 T DE 60007829T DE 60007829 T DE60007829 T DE 60007829T DE 60007829 T2 DE60007829 T2 DE 60007829T2
Authority
DE
Germany
Prior art keywords
gtp
header
rtp
udp
field
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60007829T
Other languages
English (en)
Other versions
DE60007829D1 (de
Inventor
Mooi Monmouth Country Choo Chuah
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia of America Corp
Original Assignee
Lucent Technologies Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Lucent Technologies Inc filed Critical Lucent Technologies Inc
Application granted granted Critical
Publication of DE60007829D1 publication Critical patent/DE60007829D1/de
Publication of DE60007829T2 publication Critical patent/DE60007829T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/18—Negotiating wireless communication parameters
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/04—Large scale networks; Deep hierarchical networks

Description

  • ERFINDUNGSGEBIET
  • Die vorliegende Erfindung betrifft im allgemeinen Kommunikationen und insbesondere Paketkommunikationssysteme.
  • STAND DER TECHNIK
  • Mit der Weiterentwicklung von drahtlosen Systemen verlagern sich die Kommunikationen zwischen einer Mobilvermittlungsstelle (MSC – Mobile Switching Center) und ihren Basisstationen zu einem IP-basierenden (Internet Protcol) Transportmechanismus. (Im hiesigen Gebrauch bezieht sich der Begriff drahtlose Systeme auf z.B. CDMA (code division multiple access), GSM (Global System for Mobile Communications), das vorgeschlagene UMTS (Universal Mobile Telecommunications System) usw.) Bei der gegebenen Beschaffenheit drahtloser Kommunikationen, z.B. Echtzeitsprache, muß für jeden IP-basierenden Transport ein Protokoll benutzt werden, das Echtzeitanwendungen berücksichtigt.
  • Ein solches Protokoll ist das Echtzeitprotokoll (RTP – Real Time Protocol) (z.B. siehe H. Schulzrinne, R. Frederick, V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications" (RTP: Ein Transportprotokoll für Echtzeitanwendungen), RFC 1889). RTP ist deshalb attraktiv, weil es ein verfügbares Protokoll der IETF (Internet Engineering Task Force) zur Bearbeitung von Echtzeitströmen ist. RTP-Verkehr wird in UDP (User Datagram Protocol) und IP-Paketen verkapselt.
  • Durch die Verwendung von RTP/UDP/IP wird leider ein großer Zusatzaufwand erzeugt, wenn VoIP-Anwendungen (Voice-over-IP – Sprachübertragung via Internetprotokoll) über drahtlose Netze laufen, da die Sprachennutzlast gewöhnlich gering ist (z.B. 10 bis 20 Byte), während der RTP/UDP/IP-Kopfteil 40 Byte beträgt.
  • In GPRs und PDNs Interconnection Issues von William Delylle [On-Line] August 1998 (1998-08), Seiten 1–78, XP002168897, Abgerufen aus dem Internet: <URL:[PDF] www.ee.ucl.ac.uk/~lsacks/tcomsmsc/projects/pastproj/w_d eylle.pdf> werden die allgemeinen Netzverbindungsanordnungen mit PSDN (X.75/X.25), PDN (IP) oder zwischen zwei GPRS-Netzen untersucht und verglichen. Zur Netzverbindung gehört der gesamte Leitwegteil und die verschiedenen möglichen Szenarien zwischen einem Host und der Mobilstation. In dieser Literaturstelle wird auch betrachtet, wie IPV6 mit GPRS bei der Adressierung, Tunnelung und Komprimierung zusammenarbeitet, aber auch wie der Übergang von IPV4 zu IPV6 gehandhabt wird. Die behandelten Adressierungsfragen sind: Endbenutzeradressen, die vom Protokoll abhängig sind (X.25, IP), die Verwaltung von Leitwegtabellen und Nachschlagetabellen und die Unterstützung von IPV4-kompatiblen IPV6-Adressen. Im Tunnelteil wird das GPRS Tunneling Protocol (GTP) entwickelt, mit dem mehr Protokollpakete durch das GPRS-Backbone zwischen Paketvermittlungsstellen (GSN – GPRS Support Nodes) und Tunnelung im IPV6 durchgetunnelt werden können. Ein wichtiges Merkmal bei IP-Protokollen ist die Komprimierung und es wird gezeigt, wie sie bei GPRS angepaßt wird.
  • In Low-Loss TCP-IP Header Compression For Wireless Networks (Verlustarme TCP-IP-Kopfteilkomprimierung für drahtlose Netze) von Degermark et al. WIRELESS NETWORKS, US, ACM, Band 3, Nr. 5, 1. Oktober 1997 (1997-10-01), Seiten 375–387, XP000728935 ISSN: 1022-0038, sind neue Kopfteilkomprimierungsanordnungen für UDP/IP- und TCP/IP-Protokolle offenbart. Die Autoren zeigen, wie die Größe von UDP/IP-Kopfteilen um eine Größenordnung auf 4 bis 5 Byte verringert werden kann. Das Verfahren funktioniert über Simplexstrecken, verlustbehaftete Strecken, Mehrzugriffsstrecken und unterstützt Multicast-Kommunikation. Sie zeigen auch, wie das von Jakobsen entwickelte am meisten benutzte Verfahren für Kopfteilkomprimierung für TCP/IPv4 auf IPv6 und Mehrfach-IP-Kopfteile verallgemeinert werden kann. Leider wird durch die sich ergebende Anordnung der TCP-Durchsatz über verlustbehaftete Strecken aufgrund einer ungünstigen Wechselwirkung mit TCP-Blockierungsabwehrmechanismen verringert. Durch Zufügen von zwei einfachen Mechanismen kann jedoch der durch Kopfteilkomprimierung ermöglichte Gewinn über verlustbehaftete drahtlose Netze sowie Punkt-Punkt-Modemstrecken realisiert werden.
  • Kurze Beschreibung der Erfindung
  • Ein erfindungsgemäßes Verfahren entspricht dem Anspruch 1. Bevorzugte Ausführungsformen sind in den abhängigen Ansprüchen aufgeführt.
  • Neben dem mit RTP/UDP/IP-Kopfteilen verbundenen großen Zusatzaufwand wird diese Lage weiter durch die Verwendung von im GTP (General Packet Radio Service Tunneling Protocol) verkapselte Pakete verschlimmert. In diesem Fall beträgt der GTP/UDP/IP-Zusatzaufwand rund 980% bei einer Sprachnutzlast von 10 Byte. Der GTP/UDP/IP-Kopfteil wird daher erfindungsgemäß für die Übertragung komprimiert.
  • Bei einer Ausführungsform der Erfindung unterstützt ein UMTS-Kernnetz eine Komprimierungsstruktur, die die Komprimierung eines GTP/UDP/IP-Kopfteils ermöglicht (was hier als "GTP-Kopfteilkomprimierung" bzw. "komprimierter GTP-Kopfteil" bezeichnet wird). Zusätzlich unterstützt das UMTS-Kernnetz auch RTP/UDP/IP-Kopfteilkomprimierung (was hier als "RTP-Kopfteilkomprimierung" bzw. "komprimierter RTP-Kopfteil" bezeichnet wird), unabhängig von der GTP-Kopfteilkomprimierung. Im Ergebnis ist das UMTS-Kernnetz in der Lage, kleine Multimedien-RTP-Pakete wirkungsvoller zu transportieren.
  • KURZE BESCHREIBUNG DER ZEICHNUNG
  • 1 zeigt ein unkomprimiertes GTP-verkapseltes RTP-Paket des Stands der Technik;
  • 2 zeigt ein UMTS-Netz mit den Grundsätzen der Erfindung;
  • 3 und 4 zeigen beispielhafte Protokollprofile zur Verwendung bei einer Mobilstation;
  • 5 zeigt beispielhafte Komprimierer/Dekomprimiererstellen im UMTS-Netz der 2;
  • 6–10 zeigen beispielhafte Nachrichtenflüsse;
  • 11–13 zeigen IP-, UDP- und RTP-Kopfteilformate des Standes der Technik;
  • 14 zeigt ein beispielhaftes Format für einen komprimierten RTP-Kopfteil;
  • 15 zeigt ein beispielhaftes Format für einen komprimierten GTP-Kopfteil; und
  • 16 zeigt ein beispielhaftes höheres Blockschaltbild eines Paketservers zur Verwendung bei der Durchführung von GTP-Kopfteilkomprimierung entsprechend den Grundsätzen der Erfindung.
  • AUSFÜHRLICHE BESCHREIBUNG
  • In der 1 ist ein beispielhaftes Format eines unkomprimierten GTP-verkapselten RT-Pakets 10 nach dem Stand der Technik (Version Freigabe 97) dargestellt. Der GTP/UDP/IP-Kopfteil 11 umfaßt einen IP/UDP-Kopfteil 12 und einen GTP-Kopfteil 13. Der GTP/UDP/IP-Kopfteil 11 sitzt wie im Stand der Technik bekannt oben auf der GTP-Nutzlast 14 auf. Bei einer Sprachnutzlast, die beispielhafterweise gleich 10 Byte ist (z.B. Nutzlast 15 der 1) ergibt dies einen Zusatzaufwand von rund 980% als Ergebnis des GTP/UDP/IP-Kopfteils 11. Der GTP/UDP/IP-Kopfteil wird daher erfindungsgemäß zur Übertragung komprimiert. Aus 1 ist ersichtlich, daß die GTP-Nutzlast 14 auch einen IP-Kopfteil und einen UDP-Kopfteil transportiert. Nach dem Stand der Technik umfaßt der IP/UDP-Kopfteil 12 Ursprungs- und Zielinformationen bezüglich des Tunnels, während der IP-Kopfteil und UDP-Kopfteil der GTP-Nutzlast 14 Ursprungs- und Zielinformationen bezüglich der Kommunikationsendpunkte umfaßt. (Es ist zu beachten, daß der TID-Wert (Tunnel-ID) auf der Version der Freigabe 97 basiert, die im GSM-Dokument (Global System for Mobile Communications) 04.08, Digital Cellular Telecommunications System (Phase 2+); Mobile Radio Interface Layer 3 – Specification (digitales zellulares Telekommunikationssystem (Phase 2+); Mobilfunkschnittstellenspezifikation der Schicht 3) definiert ist. Der TID-Wert enthält 8 Byte: 12 Bit MCC (Mobile Country Code – Mobil-Landeskennzahl), 8 Bit MNC (Mobile Network Code – Mobil-Netzkennzahl), 40 Bit MSIN (Mobile Subscriber Identification Number – Mobil-Teilnehmerkennung) und 4 Bit NSAPI (Network Service Acces Point – Netzdienst-Zugriffspunkt). MCC, MNC, MSIN und NSAPI sind Teile der in der Schrift GSM 04.08 definierten IMSI (International Mobile Subscriber Identity – Internationale Mobilteilnehmerkennung)).
  • In der 2 ist ein beispielhaftes UMTS-Netz 200 dargestellt, das entsprechend den Grundsätzen der Erfindung abgeändert worden ist. Außer dem erfindungsgemäßen Konzept sind die in der 2 dargestellten Elemente wohlbekannt und werden nicht ausführlich beschrieben. Beispielsweise umfaßt das UMTS-Netz 200 ein Funkanschlußnetz (RAN – Radio Access Network), ein Kernnetz (CN – Core Network), ein Backbonenetz und einen durch den IP-End-Host 240 dargestellten beispielhaften Endpunkt. Das Backbonenetz umfaßt das Internet und das öffentliche Wählnetz (PSTN – Public Switched Telephone Network). Das RAN umfaßt die Mobilstation (MS) 205, den Knoten B 210 und die Funknetzsteuerung 215. (Obwohl bei UMTS der Begriff "Knoten B" benutzt wird, wird dies auch als eine Basisstation bezeichnet). Das CN umfaßt einen SGSN (Serving GPRS Support Node – GPRS-Abnehmernetzknoten) 220, GGSN (Gateway GPRS Support Node – GPRS-Zugangsnetzknoten) 225 und das Element 230, das einen Gatekeeper (GK) (eine Komponente in ITU H.323) und ein IP/PSTN-Gateway (GW) (zur Umsetzung zwischen H.323 und dem PSTN) umfaßt. Obwohl sie als einzelne Blockelemente dargestellt sind, enthalten die Elemente des UMTS-Netzes 200 speicherprogrammierbare Prozessoren, Speicher und entsprechende Schnittstellenkarten (die nicht gezeigt sind). Für die Zwecke der vorliegenden Beschreibung besteht eine beispielhafte Gesamtverbindung zwischen Mobilstation 205 und IP-End-Host 240 (die auch als Endpunkte bezeichnet werden). Der Begriff "Paketserver", so wie er hier benutzt wird, bezieht sich auf einen beliebigen Paketprozessor, wie beispielhafterweise die obenerwähnten Elemente von UMTS 200.
  • Erfindungsgemäß unterstützt das UMTS-Netz 200 eine Komprimierungsstruktur, die eine GTP-Kopfteilkomprimierung ermöglicht. Zusätzlich unterstützt das UMTS-Netz 200 auch RTP-Kopfteilkomprimierung unabhängig von der GTP-Kopfteilkomprimierung. (So wie sie hier benutzt werden, beziehen sich die Begriffe "GTP-Kopfteilkomprimierung" bzw. "komprimierter GTP-Kopfteil" auf die Komprimierung eines GTP/UDP/IP-Kopfteils. Auf ähnliche Weise beziehen sich die Begriffe "RTP-Kopfteilkomprimierung" bzw. "komprimierter RTP-Kopfteil" auf die Komprimierung eines RTP/UDP/IP-Kopfteils.) Da GTP-Kopfteilkomprimierung von der RTP-Kopfteilkomprimierung unabhängig ist, können sich GTP-Partner von den RTP- Partnern unterscheiden (aber dies ist nicht erforderlich). Damit wird auch eine Auslegungsflexibilität bereitgestellt, da sich mancher Multimedienverkehr nicht des RTP sondern reiner UDP-Verkapselung bedienen könnte. Im Ergebnis ist das UMTS-Netz 200 in der Lage, kleine Multimedienpakete wirkungsvoller zu transportieren. Die Beschreibung des erfindungsgemäßen Konzepts wird unten fortgesetzt.
  • Übersicht über Kopfteilkomprimierung
  • Es sollte klar sein, daß erfindungsgemäß die RTP-Kopfteilkomprimierung und GTP-Kopfteilkomprimierung unabhängig zwischen Partnern ausgehandelt werden kann (was weiter unten beschrieben wird). Außer dem erfindungsgemäßen Konzept sind Komprimierungs/Dekomprimierungsverfahren wohlbekannt und werden hier nicht beschrieben. Beispielsweise ist typischerweise ein Komprimierer/Dekomprimierer ein in einem (nicht gezeigten) Speicher, z.B. von MS 205 gespeichertes und durch einen (nicht gezeigten) speicherprogrammierbaren Mikroprozessor, z.B. von MS 205, ausgeführtes Softwaremodul. Das Softwaremodul bedient sich herkömmlicher Programmierungsverfahren, die als solche hier nicht beschrieben werden, um (unten beschriebene) geteilte Informationen zu speichern und komprimierte bzw. reduzierte Formen eines GTP/UDP/IP-Kopfteils oder eines RTP/UDP/IP-Kopfteils (wie unten beschrieben) für die Übertragung zu formatieren.
  • In bezug auf die Mobilstation, z.B. MS 205 der 2, sind in 3 und 4 zwei beispielhafte Protokollprofile mit einem Komprimierer/Dekomprimierer dargestellt. Im Protokollprofil der 3 befindet sich der RTP-Komprimierer/Dekomprimierer zwischen der IP-Schicht und der RLC/MAC-Sicherungsschicht (Radio Link Control/Media Access Control). (Der Einfachheit halber ist die physikalische Schicht des Protokollprofils nicht dargestellt). Im Protokollprofil der 4 befindet sich der RTP-Komprimierer/Dekomprimierer zwischen der Anwendungsschicht und der RLC/MAC-Sicherungsschicht (die physikalische Schicht ist wiederum nicht dargestellt). Obwohl unten eine Form von RTP-Kopfteilkomprimierung beschrieben wird, ist zu beachten, daß die Ausführungsform der 4 auch die Form von RTP-Kopfteilkomprimierung darstellt, bei der ein RTP-Kopfteil einfach in seiner Gesamtheit abgestreift wird (in 13 ist ein RTP-Kopfteil dargestellt).
  • Auf ergänzende Weise befindet sich ein entsprechender RTP-Komprimierer/Dekomprimierer und GTP-Komprimierer/Dekomprimierer im UMTS-Netz. Eine beispielhafte Ansicht der Stelle des RTP-Komprimierers/Dekomprimierers und des GTP-Komprimierers/Dekomprimierers im UMTS-Netz 200 ist in der 5 dargestellt. In der 5 befindet sich der RTP-Komprimierer/Dekomprimierer (C/D) in der MS 205 und dem IP-End-Host 240 (d.h. MS 205 und IP-End-Host 240 sind RTP-Partner), während sich der GTP-Komprimierer/Dekomprimierer (C/D) im RNC 215 und GGSN 225 befindet (d.h. RNC 215 und GGSN 225 sind GTP-Partner).
  • RTP ist ein Punkt-zu-Punkt-Protokoll. Für RTP-Kopfteilkomprimierungspartner ist daher zu beachten, daß dabei angenommen wird, daß eine Sicherungsschicht-Kennzeichnung (ID) auf jede RTP-Sitzungskennzeichnung abgebildet wird. Eine beispielhafte RTP-Sitzungskennzeichnung umfaßt die IP-Zieladresse und die IP-Zielanschlußnummer (für die Endpunkte), die SSRC-Kennzeichnung (z.B. siehe 13) und den UDP-Zielanschluß (z.B. siehe 12). Wenn ATM (Asynchronous Transfer Mode – asynchroner Übertragungsmodus) zum Transport benutzt wird, ist eine beispielhafte Sicherungsschicht-ID die zugehörige VPI/VCI (Virtual Path Identifier/Virtual Connection Identifier). Die Abbildung der Sicherungsschicht-ID und der RTP-Sitzung findet innerhalb jedes RTP-Partners statt.
  • Auch ist zu beachten, daß als Alternative ein RTP-Komprimierer/Dekomprimierer in das Funkzugangsnetz, z.B. RNC 215 oder sogar ins Kernnetz, z.B. bei SGSN 220 gesetzt werden kann.
  • Im Kernnetz ist es zu bevorzugen (obwohl nicht erforderlich), den GTP-Komprimierer/Dekomprimierer in den GGSN 225 zu setzen. Wenn sich der GTP-Komprimierer/Dekomprimierer im SGSN 220 befindet, müssen Weiterschaltungen (In der Technik auch als "handoffs" bekannt) aufgrund einer Verlegung des SRNS (Serving Radio Network Subsystem – Abnehmerfunknetz-Teilsystem) unter Umständen noch berücksichtigt werden. (Beim UMTS enthält ein SRNS nicht nur ein bestimmtes RAN, sondern auch unterstützende Elemente (z.B. eine (nicht gezeigte) Datenbank). Wenn sich jedoch der GTP-Komprimierer/Dekomprimierer im GGSN 225 befindet, ist keine Kontextübertragung erforderlich, selbst im Fall einer SRNS-Verlegung.
  • Uns nunmehr den 6–10 zuwendend sind dort beispielhafte Nachrichtenflüsse zur Verwendung von GTP-Kopfteilkomprimierung und RTP-Kopfteilkomprimierung im UMTS-Netz 200 dargestellt. Außer dem erfindungsgemäßen Konzept werden bei der folgenden Beschreibung wohlbekannte UMTS-Nachrichtenflüsse verwendet, die nicht hier beschrieben werden. Bei den 6–10 wird angenommen, daß die GTP-Kopfteilpartner RNC 215 und GGSN 225 und die RTP-Kopfteilpartner MS 205 und IP-End-Host 240 sind.
  • 6 zeigt, wie eine Mobilstation, z.B. MS 205 der 2 und 5, GTP-Kopfteilkomprimierung/-dekomprimierung aushandelt. Nach Durchführung von "Attach Procedures" (nach dem Stand der Technik) zwischen MS 205 und RNC 215 überträgt MS 205 zum SGSN 220 eine Anforderungsnachricht "Activate PDP (Packet Data Protocol) context" (PDP-Kontext aktivieren), die erfindungsgemäß abgeändert ist, um eine GTP-Kopfteilkomprimierungsanfrage zu umfassen, die durch eine vordefinierte Kennzeichnung mit der Bezeichnung "GTP Comp" dargestellt wird. Als Antwort sendet SGSN 220 eine Anforderungsnachricht "Create PDP context" (PDP-Kontext erstellen) (die abgeändert ist, um die Kennzeichnung "GTP Comp" zu enthalten) zum GGSN 225, um eine Anforderung nach GTP-Kopfteilkomprimierung anzuzeigen. GGSN 225 antwortet mit einer Antwortnachricht "Create PDP context" (PDP-Kontext erstellen) als Bestätigung (die abgeändert ist, um die Kennzeichnung "GTP Comp" zu enthalten). Bei Empfang der Antwortnachricht "Create PDP context" sendet SGSN 220 eine Antwortnachricht "Activate PDP context" (PDP-Kontext aktivieren) (die abgeändert ist, um die Kennzeichnung "GTP Comp" zu enthalten) zur MS 205.
  • Wie oben bemerkt wird, um einen GTP-Kopfteilkomprimierungskontext herzustellen, entweder eine Markierung GTP Compressed (z.B. ein vordefiniertes Bitmuster) oder ein GTP-Kopfteilkomprimierungskontext-Informationselement (IE – Information Element) dem bestehenden Nachrichtensatz hinzugefügt. Dieses GTP-Kopfteilkomprimierungskontext-IE umfaßt die vollständigen GTP-Kopfteilinformationen. Wenn dieses Element vorhanden ist, muß kein voller GTP-Kopfteil gesendet werden, um den GTP-Kopfteilkontext herzustellen. Ansonsten kann es notwendig sein, ein oder mehrere Pakete mit dem vollen GTP-Kopfteil zu senden, um den Kopfteilkontext herzustellen. (Es ist zu bemerken, daß in dem Fall, wo sich der GTP-Komprimierer/Dekomprimierer an einem SGSN befindet und eine SRNS-Verlegung eintritt, die eine Änderung des SGSN bewirkt, der neue SGSN eine GTP-Kontextanfragenachricht zum alten SGSN senden kann und der alte SGSN mit der entsprechenden GTP-Kontextantwortnachricht antworten kann, so daß der neue SGSN nunmehr der neue Komprimierer/Dekomprimiererpunkt für GTP-Kopfteilkomprimierung sein kann).
  • Uns nunmehr der 7 zuwendend sind dort beispielhafte Paketflüsse dargestellt. Zur GTP-Kopfteilkomprimierung wird mindestens ein Paket mit einem vollen GTP-Kopfteil gesendet, um den Kontext für den komprimierten GTP-Kopfteil (7(A)) zwischen den GTP-Partnern herzustellen (die hier durch RNC 215 und GGSN 225 dargestellt werden). Wie bemerkt werden Pakete unter Verwendung von GTP zwischen GGSN 225 und RNC 215 übermittelt (d.h. GTP endet bei GGSN 225 und RNC 215). Sobald die GTP-Kopfteilkomprimierung ausgehandelt worden ist, formatiert jeder GTP-Partner, z.B. GGSN 225, Datenpakete entsprechend dem GTP und komprimiert dann den GTP-Kopfteil vor Übertragung der Pakete (unten beschrieben) zu seinem GTP-Partner, in diesem Fall RNC 215, der den GTP-Kopfteil dekomprimiert und die Nutzlast (die RTP enthalten kann oder nicht) zur Übertragung zur MS 205 regeneriert. Auf ähnliche Weise wird in die andere Richtung der GTP-Kopfteil von RNC 215 zur Übertragung zu GGSN 225 komprimiert, der den GTP-Kopfteil dekomprimiert und die Nutzlast regeneriert. Pakete werden zwischen GGSN 225 und IP-End-Host 240 mit einem Sicherungsschichtkopfteil nach dem Stand der Technik übermittelt. Nach der Aushandlung der GTP-Kopfteilkomprimierung kann wahlweise eine RTP-Kopfteilkomprimierung zwischen MS 205 und IP-End-Host 240 (7(B)) auf ähnliche Weise, wie die für die GTP-Kopfteilkomprimierungsaushandlung der 6 dargestellte, ausgehandelt werden.
  • In der 8 sind beispielhafte RTP-Kopfteilkomprimierungskontextnachrichtenaustausche dargestellt. (Es wird wiederum eine Abänderung bestehender Zeichengabenachrichten angenommen. Dabei werden vordefinierte Bitwerte zu bestehenden Nachrichtensätzen hinzugefügt, um die zusätzlichen Nachrichtenerfordernisse zu kennzeichnen, z.B. daß dies eine Nachricht "RTP context set up" (RTP-Kontextherstellung) ist). Anfänglich tauschen zwei RTP-Partner Zeichengabenachrichten aus, um den RTP-Kopfteilkomprimierungskontext herzustellen. Eine Anforderungsnachricht "RTP context set up" (RTP-Kontextherstellung) wird von einem RTP-Partner, z.B. MS 205, zum anderen RTP-Partner, z.B. IP-End-Host 240 gesendet. Der Nachrichtenaustausch wird mit einer Antwortnachricht "RTP context Set up" vervollständigt. Jedesmal wenn eine Änderung im RTP-Kontext stattfindet, wird der entsprechende Kontextaktualisierungscode im ersten Byte des (unten beschriebenen) komprimierten RTP-Kopfteils benutzt, um die zusätzlichen geänderten (bzw. Delta-) Informationen anzuzeigen, die im komprimierten RTP-Kopfteil geführt werden. So ist eine Anforderungsnachricht "RTP context update" (RTP-Kontextaktualisierung) eine implizite Nachricht im komprimierten RTP-Kopfteil. Eine Antwortnachricht "RTP context update" ist jedoch wahlfrei. (Es ist zu beachten, daß die RTP-Kopfteilkomprimierung zwischen den (hier durch MS 205 und IP-End-Host 240 dargestellten) RTP-Partnern Außerband-Zeichengabenachrichten austauschen kann, um die RTP-Kopfteilkomprimierung einzuschalten. Da wiederum die GTP-Kopfteilkomprimierung und die RTP-Kopfteilkomprimierung voneinander unabhängig sind, besteht keine Notwendigkeit zur Aushandlung von RTP-Kopfteilkomprimierung (in welchem Fall die Pakete einen komprimierten GTP-Kopfteil und eine nichtkomprimierte RTP-Nutzlast umfassen). Auf ähnliche Weise besteht ungeachtet der Verwendung von RTP-Kopfteilkomprimierung keine Notwendigkeit zur Aushandlung von GTP-Kopfteilkomprimierung.
  • Zurückkehrend zu 7 werden, sobald der RTP-Kopfteilkomprimierungskontext hergestellt ist, nachfolgende Pakete unter Verwendung von GTP-Kopfteilkomprimierung und RTP-Kopfteilkomprimierung gesendet (7(C)) (wie bemerkt, vorausgesetzt, daß sowohl GTP-Kopfteilkomprimierung als auch RTP-Kopfteilkomprimierung eingeschaltet sind). Sollte RTP-Kontextneusynchronisierung erforderlich sein, kann der empfangende RTP-Partner eine Nachricht "RTP context repair" (RTP-Kontextreparatur) zum sendenden RTP-Partner senden. Dies ist in 9(D) dargestellt, wo der empfangende RTP-Partner durch IP-End-Host 240 und der sendende RTP-Partner durch MS 205 dargestellt ist. Der sendende RTP-Partner sendet dann ein oder mehrere RTP-Pakete mit vollem Kopfteil (9(E)) gefolgt von komprimierten RTP-Paketen (9(F)).
  • Auf ähnliche Weise kann der empfangende GTP-Partner, wenn GTP-Pakete verlorengegangen sind, eine Nachricht "GTP context repair" (GTP-Kontextreparatur) zum sendenden GTP-Partner senden. Dies ist in 10(G) dargestellt, wo der empfangende GTP-Partner durch GGSN 225 und der sendende GTP-Partner durch RNC 215 dargestellt ist. Der sendende GTP-Partner sendet dann ein oder mehrere Pakete mit einem vollständigen GTP-Kopfteil (10(H)) gefolgt von Paketen mit komprimierten GTP-Kopfteilen (10(I)). (Es ist zu beachten, daß in diesem Beispiel die RTP-Kopfteilkomprimierungssynchronisation nicht ausgefallen ist).
  • Der obenbeschriebene Kontextreparaturmechanismus für sowohl GTP-Kopfteilkomprimierung als auch RTP-Kopfteilkomprimierung wird jedesmal dann durchgeführt, wenn Pakete fehlen. Es ist zu beachten, daß ein vordefinierter Zeitdauerschwellwert eingestellt werden kann, nachdem eine explizite Kontextreparaturnachricht zum Sender zur Neusynchronisierung gesendet wird.
  • Jedesmal wenn ein GTP-Partner den GTP-Kontext abbauen möchte, kann er eine (nicht gezeigte) Nachricht GTP context tear down (GTP-Kontextabbau) senden. Auf ähnliche Weise können die RTP-Partner den RTP-Kontext mittels der Übertragung einer (nicht gezeigten) Nachricht RTP context tear down (RTP-Kontextabbau) abbauen.
  • RTP-Kopfteilkomprimierung
  • Obwohl sie nicht direkt auf einer UMTS-Umgebung anwendbar sind, gibt es Vorschläge, den 40-Byte-RTP/UDP/IP-Kopfteil auf 4–5 Byte zu reduzieren (z.B. S. Casner und V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links" (Komprimieren von IP/UDP/RTP-Kopfteilen für niederratige serielle Verbindungen), IETF RFC2508, und L. Jonsson und M. Degermark und H. Hannu und K. Svanbro "Robust Checksumbased Header Compression" (Robuste prüfsummenbasierende Kopfteilkomprimierung) IETF-Internetentwurf, Oktober 1999). Während 11–13 IP-, RTP- und UDP-Kopfteilformate des Standes der Technik für Bezugszwecke zeigen, werden deren Einzelheiten nicht hier beschrieben.
  • Im allgemeinen ändert sich in bezug auf einen IP-Kopfteil (bei angenommener Verwendung von IPv4, der heute benutzten IP-Version) normalerweise nur die Gesamtlänge, Paket-ID (Kennung) und Kopfteilprüfsummenfelder. Die Gesamtlänge ist jedoch redundant, da die Länge auch durch die Sicherungsschicht bereitgestellt wird. Die Paket-ID erhöht sich gewöhnlich um 1 oder eine kleine Zahl für jedes Paket. Wenn angenommen wurde, daß keine IP-Paketfragmentierung stattgefunden hat, würde dies ebenfalls nicht übermittelt werden müssen. Um jedoch eine verlustlose Komprimierung aufrechtzuerhalten, können Änderungen der Paket-ID übertragen werden.
  • In bezug auf einen UDP-Kopfteil ist das Längenfeld redundant, da das IP-Gesamtlängenfeld und die Länge durch die Sicherungsschicht angezeigt werden. Das UDP-Prüfsummenfeld wird konstant null sein, wenn sich die Quelle entscheidet, keine UDP-Prüfsummen zu erzeugen.
  • Ansonsten ist festgestellt worden, daß die UDP-Prüfsumme intakt übermittelt werden muß, um die verlustlose Komprimierung zu wahren.
  • In bezug auf einen RTP-Kopfteil ist die Kennung der SSRC (Synchronization source – Synchronisierungsquelle) in einem gegebenen Kontext konstant, da sie ein Teil dessen ist, was den bestimmten Kontext kennzeichnet. Bei den meisten Paketen ändert sich nur die Folgenummer und der Zeitstempel von Paket zu Paket. Wenn Pakete nicht verlorengehen oder stromaufwärts vom Komprimierer falsch eingeordnet sind, erhöht sich die Folgenummer um eins für jedes Paket. Bei Audiopaketen mit konstanter Dauer erhöht sich der Zeitstempel um die Anzahl von in jedem Paket übermittelten Abtastperioden. Bei Video ändert sich der Zeitstempel am ersten Paket jedes Rahmens, bleibt aber danach konstant für alle zusätzlichen Pakete im Rahmen. Wenn jeder Videorahmen nur ein Paket belegt, aber die Videorahmen mit konstanter Rate erzeugt werden, dann ist die Änderung des Zeitstempels wiederum konstant von Rahmen zu Rahmen. Es ist zu beachten, daß in jedem dieser Fälle die Differenz zweiter Ordnung der Folgenummer- und Zeitstempelfelder null beträgt und der nächste Paketkopfteil daher durch Zufügen der Differenzen erster Ordnung für diese Felder, die im Sitzungskontext zusammen mit dem vorher unkomprimierten Kopfteil gespeichert sind, aus dem vorhergehenden Paketkopfteil aufgebaut werden kann. Wenn die Differenz zweiter Ordnung nicht null ist, ist die Änderungsgröße gewöhnlich viel geringer als die volle Anzahl von Bit im Feld, so daß die Größe durch Codieren der neuen Differenz erster Ordnung und ihre Übertragung anstelle des Absolutwertes reduziert werden kann.
  • Das M-Bit ist im ersten Paket eines Sprachblocks und im letzten Paket eines Videorahmens gesetzt. Wenn es als konstantes Feld behandelt werden würde, so daß jede Änderung das Senden des vollen RTP-Kopfteils erforderte, würde dadurch der Wirkungsgrad von Kopfteilkomprimierung bedeutend reduziert werden. Wie weiter unten beschrieben, wird daher das M-Bit explizit von einem komprimierten RTP-Kopfteil geführt.
  • Wenn die Pakete durch einen RTP-Mischer fließen, am gewöhnlichsten für Audio, dann ändert sich auch die CSRC-Liste und CC-Zählung. Die CSRC-Liste bleibt jedoch typischerweise für einen Sprachblock oder länger konstant, so daß sie nur bei ihrer Änderung gesendet werden muß.
  • In der 14 wird ein beispielhaftes Format für einen komprimierten RTP-Kopfteil zur Verwendung als Teil des RTP-Kopfteilkomprimierungsprotokolls dargestellt. Wie oben bemerkt wird angenommen, daß ein RTP-Partner den komprimierten RTP-Kopfteil überträgt und eine Sammlung von geteilten Informationen (z.B. in einem (nicht gezeigten) Speicher in konsistentem Zustand zwischen Komprimierer und Dekomprimierer gespeichert) unterhält. Der komprimierte RTP-Kopfteil umfaßt folgende Felder:
    • – einen Context Update Code (ein Byte) (Kontextaktualisierungscode);
    • – ein M-Feld (ein Bit) für das RTP-M-Bit;
    • – ein Time Clicks Field (sieben Bit) (Zeittaktefeld);
    • – ein UDP-Prüfsummenfeld (zwei Byte);
    • – eine IP-Paket-ID (zwei Byte);
    • – eine CSRC-Liste (zwei Byte); und
    • – eine RTP-Kopfteilerweiterung (zwei Byte).
  • Der Wert des Feldes Context Update Code zeigt an, welche Informationen im komprimierten RTP-Kopfteil nach der Darstellung in 14 enthalten sind. Die Mindestlänge für den komprimierten RTP-Kopfteil beträgt zwei Byte. Die RTP-Zeitstempel werden durch eine Zeittaktezahl (ein Byte) ersetzt. Wenn die UDP-Prüfsumme, IPv4-Paket-ID, CSRC-Liste und RTP- Kopfteilerweiterung enthalten sein müssen, wird der komprimierte RTP-Kopfteil länger als in 14 gezeigt sein. Meistens wird jedoch der komprimierte RTP-Kopfteil nur 2 Byte umfassen (das Kontextaktualisierungscodebyte und das M+Zeittaktebyte).
  • In bezug auf die in jedem RTP-Partner gespeicherten geteilten Informationen gibt es einen getrennten Sitzungskontext für jeden IP/UDP/RTP-Paketstrom, so wie er durch eine bestimmte Kombination der IP-Quellen- und Zieladressen, UDP-Quellen- und Zielanschlüsse und des (oben beschriebenen) RTP-SSRC-Feldes definiert ist. Die Anzahl unterhaltener Sitzungskontexte kann zwischen dem Komprimierer und Dekomprimierer ausgehandelt werden. Jeder RTP-Kontext kann auf eine GTP-TID abgebildet werden (GTP Tunnelkennung) (die größte Zahl, die ausgehandelt werden kann, beträgt 65536). Jeder RTP-Kopfteilkomprimierungskontext weist seinen eigenen getrennten Folgenummerraum auf, so daß ein einziger Paketverlust nur einen Kontext ungültig machen muß.
  • Die geteilten Informationen in jedem RTP-Kopfteilkomprimierungskontext umfassen folgende Posten:
    • – die vollständigen IP-, UDP- und RTP-Kopfteile möglicherweise mit einer CSRC-Liste für das letzte vom Komprimierer gesendete oder vom Dekomprimierer regenerierte Paket, und
    • – die Differenz erster Ordnung für das IPv4-ID-Feld, initialisiert auf 1 jedesmal, wenn ein unkomprimierter IP-Kopfteil für diesen Kontext empfangen wird und aktualisiert, jedesmal, wenn ein verändertes IPv4-ID-Feld in einem komprimierten Paket empfangen wird.
  • Wie oben erwähnt und in 14 dargestellt, gibt es im komprimierten RTP-Kopfteil ein Zeittaktefeld, das das RTP-Zeitstempelfeld eines RTP-Kopfteils (z.B. siehe 13) ersetzt. Das erfordert einen Mechanismus zur Berechnung bzw. Wiedergewinnung des Zeitstempelwertes und der Folgenummer in einem RTP-Empfangspartner aus dem Zeittaktefeldwert. Dabei werden folgende Definitionen festgelegt:

    sd: Abtastwertdauer (in ms);
    TSalt: Zeitstempelnummer für das vorhergehende Paket;
    TSneu: Zeitstempelnummer für das vorliegende Paket;
    WTalt: Wanduhranzeige für das vorhergehende Paket (eine Wanduhr ist einfach ein Netzbezugstaktgeber);
    WTneu: Wanduhranzeige für das vorliegende Paket;
    TNalt: Zeittaktnummer des vorliegenden Pakets im komprimierten Kopfteil;
    TNneu: Zeittaktnummer des vorliegenden Pakets im komprimierten Kopfteil;
    SNalt: RTP-Folgenummer des vorhergehenden Pakets;
    SNneu: RTP-Folgenummer des folgenden Pakets;
    T: Zeitdauer dargestellt mit n Bit (eine Zyklusperiode), in Einheiten von Abtastwertdauer,
    T = 2n Abtastwerte (T = 2n (sd) Millisekunden (ms)); und
    M: der Wert von M Bit im komprimierten Kopfteil.
  • Die folgenden Gleichungen werden zur Berechnung bzw. Regenerierung des Zeitstempelwerts und der Folgenummer in einem RTP-Empfangspartner aus dem Zeittaktefeldwert benutzt:
    Figure 00180001
    Figure 00190001
  • Während eines Sprachblocks erhöht sich der Zeittaktefeldwert um einen Abtastwert. Während einer Sprachpause erhöht sich das Zeittaktefeld um die Pausenzeit (ausgedrückt als Anzahl von Abtastwerten).
  • Für das Zeitstempelfeld besteht das Hauptproblem darin, was zu tun ist, wenn die 7-Bit-Zeittaktenummer umläuft. Wenn während einer Sprachpause kein Paket vom Komprimierer gesendet wird, muß der Zeitablauf für die Sprachpause erkannt werden (wie viele Taktzyklen abgelaufen sind). Beispielhafterweise wird dazu eine im Stand der Technik bekannte Wanduhr (wie oben gezeigt, z.B. WTalt und WTneu) benutzt. Diese getrennte Wanduhr am Dekomprimierer (oder RTP-Empfangspartner) wird zum Zählen der Zyklen benutzt. Diese Wanduhr läuft mit Grobkörnigkeit, z.B. dreht sich nur um 1 für jede T/4-Periode, wobei T die Zeitdauer eines unter Verwendung von 7 Bit dargestellten Zyklus ist.
  • In bezug auf das RTP-Folgenummernfeld sollte, wenn Folgesteuerung erforderlich ist, ein komprimierter Kopfteil mit Folgenummer alle T/4-Abtastwerte und zu Beginn jedes Sprachblocks eingefügt werden. Wenn nötig kann eine Kontextreparaturnachricht gesendet werden, um einen vollständigen RTP-Kopfteil anzufordern. Wenn der Zeittaktwert T/4 überschreitet und es verlorene Pakete gibt, kann die RTP-Folgenummer nicht richtig aktualisiert werden, bis der RTP-Empfänger ein Paket mit Folgenummerinformation empfängt.
  • Eine Darstellung der Funktionsweise dieses Aktualisierungsalgorithmus zur Bereitstellung von Zeitstempel- und Folgenummerregenerierung ist unten gezeigt. Es wird angenommen, daß 18 Pakete von z.B. MS 205 mit aufeinanderfolgenden Folgenummern 1 bis 18 übertragen werden. Am RTP-Empfänger, z.B. IP-End-Host 240 wird nur ein Paket 18 empfangen (d.h. Pakete 7 bis 17 sind verlorengegangen).
  • Im ersten Beispiel wird angenommen, daß der Wanduhrwert 3 beträgt (nämlich 3(T/4)), wenn das Paket mit Folgenummer 6 empfangen wird, und daß TSalt = 110. Bei Empfang des Pakets 18 beträgt der Wanduhrwert 6. Der Zeittaktewert bei Empfang von Paketen 6 und 18 ist 110 bzw. 75. Unter Verwendung der obigen Gleichungen ergeben sich folgende Berechnungen:

    TSalt = 110;
    δtick = (128 + 75 – 110)modT = 93
    δwtick = (6(T/4) – 3(T/4))modT = 3(T/4) = 96;
    δ'Zyklus = ⌊(6(T/4) – 3(T/4))/T⌋ = 0
    δZyklus = 0 ; und
    TSneu = 110 + 93 = 203.
  • Im folgenden zweiten Beispiel wird angenommen, daß TSalt = 38, und daß der Wanduhrwert für das Paket 6 5 ist, während der Wanduhrwert für das Paket 18 9 ist. Der Zeittaktewert bei Empfang der Pakete 6 und 18 ist 83 bzw. 32:

    TSalt = 38
    δtick = (128 + 32 – 38)modT = 122;
    δwtick = (9(T/4) – 5(T/4))modT = 0 ;
    δZyklus = ⌊(9(T/4) – 5(T/4))/T⌋ = 1;
    δZyklus = 0; und
    TSneu = 38 + 122 = 160.
  • Im nachfolgenden dritten Beispiel wird angenommen, daß TSalt = 57, daß der Wanduhrwert für Paket 6 6 ist, während der Wanduhrwert für Paket 18 9 ist. Der Zeittaktewert bei Empfang der Pakete 6 und 18 ist 57 bzw. 28.

    TSalt = 57
    δtick = (128 + 28 – 57)modT = 29;
    δwtick = (9(T/4) – 6(T/4))modT = 3(T/4) = 96;
    δ'Zyklus = ⌊(9(T/4) – 6(T/4))T⌋ = 0 ;
    δZyklus = 1; und
    TSneu = 57 + 122 = 214.
  • GTP-Kopfteilkomprimierung
  • 15 zeigt ein beispielhaftes Format eines komprimierten GTP-Kopfteils. Der komprimierte GTP-Kopfteil umfaßt ein Versionsfeld (Vers, 3 Bit), ein Nutzlastart-Feld (PT, 1 Bit), ein Erweiterungsbitfeld (E, 1 Bit), ein Folgenummerfeld (S, 1 Bit), ein Feld Tunnelkennung (TID) vorhanden (T, 1 Bit), ein Feld SNDCP vorhanden (N, 1 Bit), ein Nachrichtenart-Feld (Msg Type, 1 Byte), ein zwei-Byte-Längenfeld, ein zwei- bis vier-Byte-Feld Tunnelkennung (TID), ein zwei-Byte-Folgenummerfeld, ein vier-Bit-Erweiterungscodefeld, ein vier-Bit-Erweiterungslängenfeld und ein Erweiterungsinhaltsfeld.
  • In bezug auf das TID-Feld wird das höchstwertige Bit zum Anzeigen der Größe des TID-Feldes benutzt. Wenn der Wert des höchstwertigen Bits 0 ist, dann beträgt die TID-Feldgröße 2 Byte. Wenn der Wert dieses Bit 1 ist, dann beträgt die TID-Feldgröße 4 Byte. Zusätzlich liegt das TID-Feld nur dann vor, wenn der Wert des T-Bit-Feldes SET ist, d.h. gleich einer binären Eins. Das E-Bit-Feld wird dazu benutzt, anzuzeigen, ob ein Erweiterungskopfteil vorliegt. Jeder Erweiterungskopfteil umfaßt ein 4-Bit-Feld Erweiterungskopfteilart (Ext. Type), ein 4-Bit-Feld Erweiterungskopfteillänge (Ext. Length) und ein Feld Erweiterungsinhalt (Ext. Content) (dessen Größe durch den Wert des Erweiterungskopfteillängenfeldes angedeutet wird). Der Wert des Erweiterungskopfteillängenfeldes wird als Mehrfache von 2 Byte ausgedrückt. Wenn beispielsweise eine UDP-Prüfsumme vorhanden sein muß, wird dafür eine entsprechende Erweiterungskopfteilart definiert und die Erweiterungskopfteillänge beträgt 1 (was bedeutet, daß die Größe des Erweiterungsinhaltsfeldes 2 Byte ist, da eine UDP-Prüfsumme 2 Byte lang ist).
  • Da das Erweiterungskopfteilartfeld 4 Bit breit ist, können 16 Erweiterungsarten definiert werden. Da das Erweiterungskopfteillängenfeld 4 Bit breit ist, weist das Erweiterungsinhaltfeld eine maximale Größe von 32 Byte (d.h. 16 zwei-Byte-Mehrfache) auf. Es ist zu bemerken, daß, wenn mehr Erweiterungsarten zugeteilt werden müssen, die Größe dieser Felder eingestellt werden kann, z.B. auf eine Größe von je einem Byte.
  • Die geteilten Informationen in jedem GTP-Kopfteilkomprimierungskontext (d.h. bei jedem GTP-Partner gespeichert) umfassen folgende Posten (diese Posten werden auf Grundlage der im anfänglichen "vollständigen" GTP-Kopfteil empfangene Werte initialisiert):
    • – die vollständigen IP- und UDP-Kopfteile (sollte eine UDP-Prüfsumme erforderlich sein, wird sie einfach vom GTP-Empfangspartner auf Grundlage der empfangenen UDP-Daten neu berechnet);
    • – das zwei-Byte-Flußettiket und die LLC-Rahmennummer; und
    • - den TID-Wert.
  • Wie oben bemerkt, unterstützt das in 15 gezeigte GTP-Kopfteilkomprimierungsformat entweder zwei oder vier Byte wahlweiser TID-Werte. (Wie oben bemerkt, beträgt eine TID der Freigabeversion 97 8 Byte. TID-Werte können jedoch in der Zukunft neu definiert werden, um weniger Byte zu umfassen (daher die Möglichkeit, entweder TID-Werte von zwei oder vier Byte im komprimierten GTP-Kopfteil aufzuweisen). Das TID-Feld im GTP-Kopfteilkomprimierungsformat der 15 wird wahlweise (über den Wert der T-Bit) zur Aktualisierung von TID-Informationen benutzt.
  • Uns kurz der 16 zuwendend wird dort ein höheres Blockschaltbild eines repräsentativen Paketservers zur Verwendung gemäß den Grundsätzen der Erfindung dargestellt. Der Paketserver 605 ist eine Speicherprogrammierbare Prozessorarchitektur und enthält den Prozessor 650, Speicher 660 (zum Speichern von Programmanweisungen und Daten, z.B. zum Kommunizieren entsprechend der obenerwähnten GTP-Kopfteilkomprimierung usw.) und Kommunikationsschnittstelle(n) 665 zum Ankoppeln an eine oder mehrere Paketkommunikationseinrichtungen, so wie sie durch den Weg 666 dargestellt werden.
  • Das obige stellt nur die Grundsätze der Erfindung dar und man wird daher erkennen, daß der Fachmann in der Lage sein wird, zahlreiche alternative Anordnungen auszuarbeiten, die, obwohl sie nicht ausdrücklich hier beschrieben sind, die Grundsätze der Erfindung verkörpern und in ihrem Rahmen liegen. Beispielsweise ist das erfindungsgemäße Konzept, obwohl es im Zusammenhang mit UMTS dargestellt ist, auf ein beliebiges drahtloses System (z.B. UMTS, usw.) oder Anwendung anwendbar, die die Verwendung eines Tunnelprotokolls erfordert.

Claims (4)

  1. Verfahren zur Verwendung in einem Paketserver, mit folgenden Schritten: Aushandeln der Komprimierung eines GTP/UDP/IP-Kopfteils eines GPRS-basierenden (General Packet Radio Service) Tunnelprotokolls "GTP" mit einem GTP-Partner, wobei der GTP/UDP/IP-Kopfteil GTP-, UDP- (User Datagram Protocol) und IP- (Internet Protocol) Kopfinformationen mit anfänglicher Übertragung des GTP/UDP/IP-Kopfteils zum GTP-Partner umfaßt; und nach Aushandlung der Übertragen einer komprimierten Version des GTP/UDP/IP-Kopfteils vor Übertragung der Pakete zum GTP-Partner.
  2. Verfahren nach Anspruch 1, wobei der komprimierte GTP/UDP/IP-Kopfteil mindestens ein Tunnelkennzeichnungsfeld umfaßt, das weniger oder gleich vier Byte Länge aufweist.
  3. Verfahren nach Anspruch 1, wobei der komprimierte GTP/UDP/IP-Kopfteil mindestens ein Erweiterungsbitfeld umfaßt, das anzeigt, ob ein Erweiterungsfeld vorhanden ist oder nicht, ein Tunnelkennzeichnung-Vorhanden-Feld, das anzeigt, ob ein Tunnelkennzeichnungsfeld vorhanden ist oder nicht.
  4. Verfahren nach Anspruch 1, weiterhin mit folgenden Schritten: Formatieren von Datenpaketen entsprechend einem Echtzeitprotokoll (RTP – Real Time Protocol) ebenfalls mit UTP- und IP-Kopfteilinformationen; und Komprimieren des RTP/UDP/IP-Kopfteils vor Übertragen der Pakete, wobei ein Feld des komprimierten RTP/UDP/IP-Kopfteils definiert, ob ein UDP-Prüfsummenfeld vorhanden ist oder nicht.
DE60007829T 2000-02-02 2000-08-29 Kopfkomprimierung für General Packet Radio Service Tunnel Protokoll (GTP) Expired - Lifetime DE60007829T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US497002 1990-03-20
US09/497,002 US6839339B1 (en) 2000-02-02 2000-02-02 Header compression for general packet radio service tunneling protocol (GTP)-encapsulated packets

Publications (2)

Publication Number Publication Date
DE60007829D1 DE60007829D1 (de) 2004-02-26
DE60007829T2 true DE60007829T2 (de) 2004-12-02

Family

ID=23975057

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60007829T Expired - Lifetime DE60007829T2 (de) 2000-02-02 2000-08-29 Kopfkomprimierung für General Packet Radio Service Tunnel Protokoll (GTP)

Country Status (5)

Country Link
US (1) US6839339B1 (de)
EP (1) EP1122925B1 (de)
JP (1) JP4602568B2 (de)
CA (1) CA2329457C (de)
DE (1) DE60007829T2 (de)

Families Citing this family (89)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1186140A1 (de) * 1999-06-04 2002-03-13 Nokia Corporation Paketdatenübertragungssteuerung
EP1083768A1 (de) * 1999-09-08 2001-03-14 TELEFONAKTIEBOLAGET LM ERICSSON (publ) Verfahren zur Erleichterung der Datenübertragung
US8463231B1 (en) 1999-11-02 2013-06-11 Nvidia Corporation Use of radius in UMTS to perform accounting functions
US6865169B1 (en) 1999-11-02 2005-03-08 Ipwireless, Inc. Cellular wireless internet access system using spread spectrum and internet protocol
US8117291B1 (en) * 1999-11-02 2012-02-14 Wireless Technology Solutions Llc Use of internet web technology to register wireless access customers
US7158491B1 (en) * 1999-11-05 2007-01-02 Nokia Corporation Terminal-based link adaptation scheme having a detector which monitors application signaling and a requestor which requests a special channel based on the detection
US6678281B1 (en) * 2000-03-08 2004-01-13 Lucent Technologies Inc. Hardware configuration, support node and method for implementing general packet radio services over GSM
US7539130B2 (en) * 2000-03-28 2009-05-26 Nokia Corporation Method and system for transmitting and receiving packets
US7283497B2 (en) * 2000-05-16 2007-10-16 Siemens Aktiengesellschaft Method for transferring a tunnel between nodes in GPRS system
US7289504B1 (en) * 2000-05-31 2007-10-30 Nokia Corporation Method and apparatus for generating a connection identification
FI112014B (fi) 2000-06-28 2003-10-15 Nokia Corp Tiedonsiirtoresurssien varaus pakettivälitteisessä tiedonsiirrossa
FI20001544A (fi) 2000-06-29 2001-12-30 Nokia Networks Oy Poikkeavan päätelaitteen tukeminen verkossa
ATE484933T1 (de) 2000-08-14 2010-10-15 Nokia Siemens Networks Oy Kommunikationssystem und verfahren zum bereitstellen eines verfahrens zur auswahl der betriebsart
DE60018927T2 (de) * 2000-09-07 2005-07-28 Matsushita Electric Industrial Co. Ltd., Kadoma Verfahren und Vorrichtung zur Datenpaketenübertragung
US20020101859A1 (en) * 2000-09-12 2002-08-01 Maclean Ian B. Communicating between nodes in different wireless networks
JP3323483B2 (ja) * 2000-09-12 2002-09-09 松下電器産業株式会社 パケット送信装置およびパケット伝送方法
US20040136380A1 (en) * 2000-09-12 2004-07-15 Daiji Ido Packet transmitter, packet receiver and packet transmission method
ATE330425T1 (de) * 2000-09-28 2006-07-15 Nokia Corp Verfahren und kompressor zur komprimierung von zeitstempelinformation von paketen
US6967964B1 (en) * 2000-10-03 2005-11-22 Telefonaktiebolaget Lm Ericsson (Publ) Context identification using header compression key at link layer
FI110739B (fi) * 2000-10-18 2003-03-14 Nokia Corp Otsikkokenttien kompressoinnin määrittäminen datapakettiyhteydelle
US7095744B2 (en) * 2000-11-22 2006-08-22 Dune Networks Method and system for switching variable sized packets
FI20002890A (fi) * 2000-12-29 2002-06-30 Nokia Corp Kompression määrittäminen pakettivälitteisessä tiedonsiirrossa
US7290063B2 (en) * 2001-01-10 2007-10-30 Nokia Corporation Relocating context information in header compression
WO2002069519A1 (en) * 2001-02-23 2002-09-06 Nokia Inc. System and method for fast gprs for ipv6 communications
US7155173B2 (en) * 2001-03-14 2006-12-26 Nokia Corporation Method and system for providing a context for message compression
FI118244B (fi) 2001-06-27 2007-08-31 Nokia Corp Otsikkokenttien kompressiotunnisteen välittäminen datapakettiyhteydellä
US8837471B2 (en) * 2001-08-01 2014-09-16 Certicom Corp. Disabling header compression over point-to-point protocol (PPP)
CA2354722C (en) * 2001-08-01 2015-11-24 Certicom Corp. Disabling header compression over point-to-point protocol (ppp)
US20030051005A1 (en) * 2001-09-13 2003-03-13 Burch Charles Carroll Apparatus for encapsulating data within a self-defining file and method thereof
JP3617967B2 (ja) 2001-09-28 2005-02-09 松下電器産業株式会社 ヘッダ圧縮パケット受信装置及び方法
US7155521B2 (en) 2001-10-09 2006-12-26 Nokia Corporation Starting a session in a synchronization system
US7336952B2 (en) * 2001-10-24 2008-02-26 Qualcomm, Incorporated Method and system for hard handoff in a broadcast communication system
KR100447060B1 (ko) * 2001-12-26 2004-09-04 유티스타콤코리아 유한회사 일반 패킷 무선 서비스 사용자 평면 터널링 프로토콜계층에서의 사용자 패킷 처리 장치 및 그 방법
US20030134651A1 (en) 2002-01-16 2003-07-17 Hsu Raymond T. Method and apparatus for flow treatment and mapping on multicast/broadcast services
TW588524B (en) * 2002-01-23 2004-05-21 Ind Tech Res Inst System and method to apply multi-protocol label switching network in GPRS
US8959230B2 (en) 2002-01-28 2015-02-17 Qualcomm Incorporated Method and apparatus for negotiation of transmission parameters for broadcast/multicast services
EP1512262B1 (de) * 2002-06-07 2005-10-12 Siemens Aktiengesellschaft Verfahren und Vorrichtung zum Übertragen von IP-Paketen zwischen einem Radio Network Controller (RNC) und einer weiteren Einrichtung eines Mobilfunknetzes
KR100497357B1 (ko) * 2002-06-26 2005-06-23 삼성전자주식회사 인터넷 프로토콜 기반 네트워크 환경에 있어서 헤더 압축및 패킷 다중화 장치와 그 방법
US7209491B2 (en) * 2002-06-28 2007-04-24 Nokia Corporation Method and system for transmitting data in a packet based communication network
US7920590B2 (en) * 2002-07-12 2011-04-05 Spyder Navigations L.L.C. Wireless communications system having built-in packet data compression and support for enabling non-standard features between network elements
JP4317403B2 (ja) * 2002-08-09 2009-08-19 パナソニック株式会社 ヘッダ圧縮装置及びヘッダ圧縮方法
KR100889864B1 (ko) * 2002-08-14 2009-03-24 엘지전자 주식회사 멀티미디어 데이터의 압축 전송 방법 및 시스템
KR100936586B1 (ko) 2002-09-19 2010-01-13 엘지전자 주식회사 멀티미디어 방송 및 멀티캐스트 서비스에서의 데이터 전송 방법 및 시스템
EP1401168A1 (de) * 2002-09-20 2004-03-24 Alcatel Verfahren zur Übertragung eines Internetpakets und Netzwerkelemente dazu
US7286536B2 (en) 2002-10-28 2007-10-23 Nokia Corporation Method and system for early header compression
CN100592733C (zh) * 2002-12-04 2010-02-24 皇家飞利浦电子股份有限公司 分层媒体比特流的打包
US20040125770A1 (en) * 2002-12-31 2004-07-01 Pitt Randall Evans Method and apparatus for transferring state information between communication networks
KR100594115B1 (ko) * 2003-07-30 2006-06-28 삼성전자주식회사 패킷 데이터 서비스의 채널 타입 변경에 따른 헤더 압축 컨텍스트 설정 장치 및 방법
US20050094670A1 (en) * 2003-08-20 2005-05-05 Samsung Electronics Co., Ltd. Method for acquiring header compression context in user equipment for receiving packet data service
US7512715B2 (en) * 2003-09-26 2009-03-31 Nokia Corporation System and method for requesting a resource over at least one network with reduced overhead
CN100505729C (zh) * 2003-10-30 2009-06-24 Ut斯达康(中国)有限公司 采用头压缩技术的实时ip分组的无线传输装置和方法
US8149880B1 (en) 2004-08-18 2012-04-03 Qualcomm Atheros, Inc. Media streaming synchronization
US7792158B1 (en) * 2004-08-18 2010-09-07 Atheros Communications, Inc. Media streaming synchronization
US7680105B2 (en) * 2004-12-03 2010-03-16 Cisco Technology, Inc. Voice over internet protocol (VOIP) subcell multiplexing
US20060153196A1 (en) * 2005-01-11 2006-07-13 Conexant Systems, Inc. Systems and methods for achieving improved ADSL data rates over USB 1.1 channel
US20100157833A1 (en) * 2005-03-10 2010-06-24 Qualcomm Incorporated Methods and systems for improved timing acquisition for varying channel conditions
US8675631B2 (en) * 2005-03-10 2014-03-18 Qualcomm Incorporated Method and system for achieving faster device operation by logical separation of control information
CN1969475B (zh) * 2005-03-25 2012-07-04 桥扬科技有限公司 用于蜂窝广播和通信系统的方法和设备
US20060268820A1 (en) * 2005-05-19 2006-11-30 Heikki Mahkonen IP header compression with IPv6 mobile node
US7623607B2 (en) 2005-10-31 2009-11-24 Qualcomm Incorporated Methods and apparatus for determining timing in a wireless communication system
US8948329B2 (en) * 2005-12-15 2015-02-03 Qualcomm Incorporated Apparatus and methods for timing recovery in a wireless transceiver
WO2008012739A2 (en) * 2006-07-28 2008-01-31 Nxp B.V. Media playback decoder tracing
US7848280B2 (en) * 2007-06-15 2010-12-07 Telefonaktiebolaget L M Ericsson (Publ) Tunnel overhead reduction
KR101236033B1 (ko) * 2008-07-21 2013-02-21 한국전자통신연구원 통신 오버헤드를 제거하는 통신 시스템
WO2010011054A2 (en) * 2008-07-21 2010-01-28 Electronics And Telecommunications Research Institute Communication system for removing transmission overhead
US8902805B2 (en) 2008-10-24 2014-12-02 Qualcomm Incorporated Cell relay packet routing
WO2010107357A1 (en) * 2009-03-20 2010-09-23 Telefonaktiebolaget L M Ericsson (Publ) Radio bearer identification for self backhauling and relaying in lte advanced
US9160566B2 (en) * 2009-04-10 2015-10-13 Qualcomm Incorporated QOS mapping for relay nodes
WO2010121416A1 (zh) * 2009-04-21 2010-10-28 华为技术有限公司 中继链路中处理数据的方法、中继节点和系统
WO2010133022A1 (zh) * 2009-05-19 2010-11-25 华为技术有限公司 语音包发送、接收的方法、装置和系统
US8588227B2 (en) 2009-07-17 2013-11-19 Qualcomm Incorporated Recursive header compression for relay nodes
US9674311B2 (en) * 2009-08-14 2017-06-06 Qualcomm Incorporated Robust header compression for relay nodes
CN102143527B (zh) 2010-02-03 2013-09-11 华为技术有限公司 嵌套协议包头的压缩方法及装置
US9769287B2 (en) * 2010-05-10 2017-09-19 Telefonaktiebolaget Lm Ericsson (Publ) Reducing protocol overhead in single-block packet access procedures
CN101860552A (zh) * 2010-07-02 2010-10-13 河南伯示麦新能源科技有限公司 基于gprs的车载语音数据实时传输方法
CN102255906B (zh) * 2011-07-08 2014-07-23 中国联合网络通信集团有限公司 数据发送和接收方法、设备及系统
US8923816B2 (en) * 2011-07-28 2014-12-30 Samsung Electronics Co., Ltd. Apparatus and method for providing seamless service between a cellular network and wireless local area network for a mobile user
US8676159B1 (en) * 2012-09-28 2014-03-18 Juniper Networks, Inc. Mobile network interoperability
US9992021B1 (en) 2013-03-14 2018-06-05 GoTenna, Inc. System and method for private and point-to-point communication between computing devices
JP2014179844A (ja) * 2013-03-15 2014-09-25 Nec Corp パケット伝送装置、パケット伝送方法及びパケット伝送システム
RU2645283C1 (ru) * 2014-05-28 2018-02-19 Хуавэй Текнолоджиз Ко., Лтд. Способ и устройство адаптации стека протоколов
US9609035B2 (en) * 2015-03-04 2017-03-28 Oracle International Corporation Compressed headers for encapsulated real-time communications
CN107026887B (zh) * 2016-02-02 2019-12-06 上海交通大学 一种多媒体系统中快速信息交互方法及网络传输方法
CN111726347B (zh) * 2016-02-26 2022-04-15 上海交通大学 一种多媒体系统中信息交互机制及网络传输方法
EP3469780B1 (de) 2016-06-08 2022-09-21 Huawei Technologies Co., Ltd. Kontextinformationsprozessor, profilverteilungseinheit und -verfahren für ein kommunikationsnetzwerk
KR102123676B1 (ko) * 2016-12-06 2020-06-29 주식회사 엘지화학 주택용 ESS에 탑재되는 직류변압기(DC-DC converter)와 배터리관리시스템(BMS) 소프트웨어의 통합관리 및 업데이트 방법
TWI776270B (zh) * 2020-11-05 2022-09-01 財團法人資訊工業策進會 基於隧道協定的中繼節點與封包封裝方法
CN112566180B (zh) * 2020-12-09 2023-03-24 东方通信股份有限公司 一种提升tetra系统分组数据传输速率的方法
CN114629963B (zh) * 2022-03-16 2023-10-20 西安电子科技大学 基于层次聚类的网络协议报头压缩方法

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08223222A (ja) * 1995-02-14 1996-08-30 Hitachi Cable Ltd リモート中継装置
FI962381A (fi) * 1996-06-07 1997-12-08 Nokia Telecommunications Oy Datan pakkaaminen tietoliikenneyhteydellä
US6104929A (en) * 1997-06-20 2000-08-15 Telefonaktiebolaget Lm Ericsson Data packet radio service with enhanced mobility management
FI972725A (fi) * 1997-06-24 1998-12-25 Nokia Telecommunications Oy Uudelleenreititys
US6032197A (en) * 1997-09-25 2000-02-29 Microsoft Corporation Data packet header compression for unidirectional transmission
US6608832B2 (en) * 1997-09-25 2003-08-19 Telefonaktiebolaget Lm Ericsson Common access between a mobile communications network and an external network with selectable packet-switched and circuit-switched and circuit-switched services
US6469998B1 (en) * 1998-10-06 2002-10-22 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for communicating data packets from an external packet network to a mobile radio station
US6438123B1 (en) * 1998-11-10 2002-08-20 Cisco Technology, Inc. Method and apparatus for supporting header suppression and multiple microflows in a network
CA2287613A1 (en) * 1998-12-07 2000-06-07 Kenneth Carl Budka Methods and apparatus for route optimization in a communications system
US6314095B1 (en) * 1999-02-11 2001-11-06 Motorola, Inc. Method and apparatus for a high-speed multimedia content switch with compressed internet protocol header
US6438108B1 (en) * 1999-03-11 2002-08-20 Telefonaktiebolaget L M Ericsson (Publ) System for improved transmission of acknowledgements within a packet data network
EP1056259B1 (de) * 1999-05-25 2005-09-14 Lucent Technologies Inc. Verfahren und Vorrichtung für Telekommunikationen mit Internet-Protokoll
US6542504B1 (en) * 1999-05-28 2003-04-01 3Com Corporation Profile based method for packet header compression in a point to point link
US6608841B1 (en) * 1999-12-30 2003-08-19 Nokia Networks Oy System and method for achieving robust IP/UDP/RTP header compression in the presence of unreliable networks

Also Published As

Publication number Publication date
JP4602568B2 (ja) 2010-12-22
EP1122925B1 (de) 2004-01-21
CA2329457C (en) 2004-07-20
CA2329457A1 (en) 2001-08-02
US6839339B1 (en) 2005-01-04
EP1122925A1 (de) 2001-08-08
JP2001244993A (ja) 2001-09-07
DE60007829D1 (de) 2004-02-26

Similar Documents

Publication Publication Date Title
DE60007829T2 (de) Kopfkomprimierung für General Packet Radio Service Tunnel Protokoll (GTP)
DE69927243T2 (de) Verfahren und Vorrichtung für Telekommunikationen mit Internet-Protokoll
DE60022391T2 (de) System und verfahren zur erzielung einer robusten ip/udp/rtp-paketkopf-komprimierung in der gegenwart unzuverlässiger netze
DE19950653B4 (de) Verfahren zum Betreiben eines Mobilfunknetzes
DE60304938T2 (de) Kompression von Protokollnachrichten in einem Mobilfunksystem
DE60108514T2 (de) Definieren einer nachrichtenkopf-datenfeldkomprimierung für eine datenpaketverbindung
DE60014852T2 (de) Headerkompression in echtzeitdiensten
DE69533740T2 (de) TCP/IP-Kopfendekompression in X.25-Netzwerken
EP1362446B1 (de) Transfer von ip-daten in einem kommunikationssystem unter verwendung mehrerer logischer verbindungen für komprimierte felder auf der grundlage verschiedener kontexte
DE60214144T2 (de) Verfahren und Vorrichtung zur bereitstellung von unterschiedlichen Dienstqualitätsstufen in einer Funkpaketdatendienstverbindung
DE60120466T2 (de) Effiziente Übertragung von RTP Paketen in einem Netzwerk
DE60102810T2 (de) Datenpaketnummerierung bei der paketvermittelten datenübertragung
DE60120793T2 (de) Verfahren und Kompressor zur Komprimierung von Zeitstempelinformation von Paketen
DE60017442T2 (de) Spärliche rückkoppelung in drahtlosen systemen die hohe verzögerung und niedrige bandbreite aufweisen
KR20060054662A (ko) 광대역 무선 통신 시스템에서 헤더 압축 장치 및 방법
CN100433841C (zh) 用于因特网协议第6版移动子协议MIPv6的鲁棒性头标压缩／解压方法
DE60204544T2 (de) Kompressionsverfahren, -sender und -empfänger für funkdatenkommunikation
KR100689473B1 (ko) 통신시스템에서 프로토콜 헤더 압축장치 및 방법
EP1236372A2 (de) Verfahren zum betreiben eines mobilfunknetzes
DE19944334C1 (de) Verfahren zum Betreiben eines Mobilfunknetzes
DE69932365T2 (de) Verfahren für Telekommunikation mit Internetprotokoll
EP1811795B1 (de) Übertragung von Datenpaketen
WO2002054805A1 (de) Verfahren zur datenübertragung zwischen verschiedenen einheiten eines funkkommunikationssystems und dafür eingerichtetes basisstationssystem und funkkommunikationssystem
Vanjire et al. Nested Tunnel header compression Protocol in wireless network with. NET technology
EP1359721A1 (de) Verfahren und Vorrichtung zum Übertragen von Datenpaketen in einem Kommunikationssystem

Legal Events

Date Code Title Description
8364 No opposition during term of opposition