DE69932365T2

DE69932365T2 - Verfahren für Telekommunikation mit Internetprotokoll

Info

Publication number: DE69932365T2
Application number: DE69932365T
Authority: DE
Inventors: Jin Swindon Yang
Original assignee: Lucent Technologies Inc
Current assignee: Nokia of America Corp
Priority date: 1999-05-25
Filing date: 1999-05-25
Publication date: 2007-08-02
Anticipated expiration: 2019-05-26
Also published as: DE69932365D1

Description

Abkürzungen
Die folgenden Abkürzungen werden in dem Entwurf häufig verwendet:

PSTN:: Public Switched Telephone Network (öffentliches Telefonnetz)
TCP:: Transport Control Protocol (Übertragungssteuerungsprotokoll)
UDP:: User Datagram Protocol
RTP:: Real Time Protocol (Echtzeitprotokoll)
IP:: Internet Protocol (Internetprotokoll)
VoIP:: Voice Over IP (Sprachkommunikation mittels IP)
CD:: compressor/de-compressor (Komprimierer/Dekomprimierer)
CDMA:: Code Division Multiplexing Access (Codemultiplex-Vielfachzugriff)
MAC:: Medium Access Control (Medienzugriffssteuerung)
RLC:: Radio Link Control
GSM:: Global System for Mobile Communication (Globales System für mobile Kommunikation)
GPRS:: General Packet Radio Service (Allgemeiner paketorientierter Funkdienst)

1. Gebiet der Erfindung
Diese Erfindung betrifft ein Verfahren für Telekommunikationen unter Verwendung des Internetprotokolls, und betrifft insbesondere eine vorteilhafte Datenkomprimierungsanordnung.
In drahtlosen Telekommunikationsnetzwerken, die mit einer Paketvermittlungstechnik arbeiten, wäre es vorteilhaft, Sprach- und Datendienste unter Verwendung des Internets anbieten zu können, aber die Notwendigkeit, die kombinierten Kopffelder des Real-Time Transport Protocol (Echtzeit-Übertragungsprotokolls – RTP), User-Datagram-Protokolls (UDP) und Internetprotokolls (IP) in jedem Paketkopffeld zu übertragen, ist ein Nachteil. Die drei Kopffelder weisen 20, 8 beziehungsweise 12 Bytes pro Paket auf, und diese 40 Byte-Last ist annähernd die doppelte Sprachnutzlast von 23 Bytes für 20 Millisekunden in dem Sprachkodiersystem, das als GSM FR bekannt ist. Es ist allgemein bekannt, dass drahtlose Ressource/Bandbreite teurer ist als Landleitungsanordnungen, und die Überlast der großen Kopffeldlast einen ernsthaften Nachteil bedeutet.
2. Kurze Beschreibung des Standes der Technik
Eine Lösung, wie von S. Casner und V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC2508, ftp://ftp.isi.edu/in-notes/rfc2508.txt, offenbart, ist die Komprimierung der RTP/UDP/IP-Kopffelder. Ein Protokoll ist zum Komprimieren und Dekomprimieren der Kopffelder definiert, und es kann eine Verringerung zwischen 2 und 5 Bytes erreicht werden. Ein wesentlicher Nachteil ist jedoch, dass, wenn ein komprimiertes Paket verloren geht, es erneut übertragen werden muss, und die Bereitstellung einer Fehlerkorrektureinrichtung wesentlich ist, und daher die Umlaufzeit kurz sein muss, wenn die Qualität gesichert sein soll. Ferner ist es für viele Funknetze, in welchen die Radio Bearer Capacity (Basisdienstekennung) für den Circuit-Voice-Dienst so gestaltet ist, dass die Sicherungsschicht-PDU-Größe an die Sprachnutzlast angepasst ist, schwierig, auch nur 2 bis 5 mehr Bytes in einen Medium Access Control (MAC) Block zu stellen, so dass ein Sprach-Frame mit seinem komprimierten Kopffeld in zwei MAC-Blöcken übertragen werden müsste, so dass eine zusätzliche Funkressource erforderlich wäre oder es zu einem Verlust an Sprachqualität käme; auch hier könnte eine Umschaltung den Komprimierungs-/Dekomprimierungspunkt im Netz ändern, wodurch der Komprimierungszustand wieder hergestellt werden muss, so dass eine CONTEXT STATE-Nachricht gefolgt von einem FULL HEADER-Paket gesendet werden muss, was zu einer Verzögerung und einem Paketverlust führt.
In S. Petrack, Ed. Ellesson, Framedwork for Compressed RTP, Preliminary IETF draft, angeführt auf der rem-con Mailinglist Feb. 1996, http://www.mbone.com/lists/remconf.1996Q1/0259.html, wird vermutet, dass die zwei zeitbezogenen Felder (RTP-Folgenummer und Zeitstempel) unter Verwendung einer 1-Byte "timeclick_number" komprimiert werden können, und von einer separaten RTP-Sitzungssteuerung wird angenommen, dass sie die statischen Teile der Außerband-Kopffelder signalisiert, aber es werden keine Einzelheiten angeführt, wie dies zu erreichen ist.
3. Kurzdarstellung der Erfindung
Gemäß der Erfindung wird ein Verfahren zum Komprimieren und Dekomprimieren von Kopffeldern für ein Paketvermittlungsnetz bereitgestellt, mit Bereitstellung in jedem komprimierten Kopffeld einer zyklisch zurückgesetzten timeclick_number, die die Abtastzeit der Paketnutzlast darstellt, Erhöhen der timeclick_number um 1 für jede Abtastdauer, Zählen der rückgesetzten Zyklen und aus der Zählung rückgesetzter Zyklen und einer empfangenen timeclick_number Bereitstellen einer Folgenummer und eines Zeitstempels zum Bereitstellen eins dekomprimierten Kopffeldes.
4. Kurze Beschreibung der Zeichnungen
Die Erfindung wird nun anhand eines Beispiels unter Bezugnahme auf die beiliegenden Zeichnungen beschrieben, wobei:
1 ein drahtloses Paketvermittlungsnetz auf der Basis des UMTS-Modells zeigt.
2a und 2b zwei Ausführungsformen der Erfindung in einem mobilen Sender/Empfänger zeigen.
3 einen gesamten Kommunikationskanal zeigt;
4 einen Komprimierungsalgorithmus zeigt;
5 das Herstellen oder Wiederherstellen eines Komprimierungszustandes zeigt; und
6 eine Umschaltung zwischen Komprimierungspunkten zeigt.
5. Beschreibung einer bevorzugten Ausführungsform einer Mobilstation und eines Netzwerks
In 1 umfasst ein drahtloses Telekommunikationssystem 10 eine Anzahl mobiler Stationen (MS) 12 und eine Anzahl von Sender/Empfänger-Basisstationen (Knoten B) 14, die durch eine RNC (Radio Network Controller) 16 (alle im Radio Access Network RAN 18) mit einem Paket-Core-Network (CN) 20 verbunden sind, das aus zwei Elementen besteht: einem SGSN (Serving GPRS Support Node) 22 und einem GGSN (Gateway GPRS Support Node) 24. Das CN ist über ein IP/PSTN-Gateway 26 mit dem PSTN (Public Switched Telephone Network) 30 und dem Internet 28 verbunden.
In dieser Figur basiert die Netzwerkarchitektur auf dem UMTS-Referenzmodell.
Es wird angenommen, dass das Netzwerk 10 im Paketvermittlungsmodus arbeitet. Eine Möglichkeit, einen Sprachdienst zu implementieren, ist die Verwendung der VoIP-Technologie, wobei eine VoIP-Applikation von der mobilen Station 12 als allgemeine IP-Applikation behandelt wird, und kodierte Sprache in RTP/UDP/IP-Pakete zerlegt und durch die Luft, das RAN 18 und das CN 20 zu dem Internet 28 oder über das IP/PSTN-Gateway 26 zum PSTN 30 übertragen wird.
An der mobilen Station 12 können die Rufsignalisierung auf IP-Basis und die Graphical User Interface (graphische Benutzerschnittstelle) der voIP-Applikation auf dieselbe Weise laufen wie auf einem normalen IP-Endgerät. Der Sprachverkehr wird als Sicherungsschichtnutzlast gesendet, mit komprimierten oder entfernten RTP/UDP/IP-Kopffeldinformationen, wie in der Folge ausführlicher erklärt wird.
Unter Bezugnahme auf 2a ist die Aufwärtsrichtung von einer mobilen Station 60 zum Netzwerk definiert. In der mobilen Station befindet sich eine VoIP-Applikationsschicht 68, von der Rufsignalisierungsdaten zu einer TCP-Schicht 66 und einer UDP/IP-Schicht 65 gesendet werden. Sprachdaten werden zu einer RTP/UDP-Schicht 67 und einer IP-Schicht 65 übertragen.
Sowohl Rufsignalisierungsdaten wie auch Sprachdaten in Paketen werden einem Komprimierer 64 bereitgestellt, der die kombinierten RTP/UDP/IP-Kopffelder komprimiert, wobei aber der Komprimierer die Rufsignalisierungsdaten nicht komprimiert. Die zwei Arten von Paketen 62, 63 (komprimiert und nicht komprimiert) werden in ein RLC/MAC-Protokoll gebracht und gehen über die Luftschnittstelle 61.
Für den Empfang von Sprache und Rufsignalisierungsdaten (Abwärtsrichtung) ist der Prozess umgekehrt.
In der alternativen Anordnung für eine mobile Einheit 70, wie in 2b dargestellt, sendet/empfängt der Komprimierer 74 die Sprachdaten 63/zu/von der VoIP-Applikation 78, während Rufsignalisierungsdaten 62 durch normale IP-Schichten 75, 76 gehen.
Es ist erkennbar, dass in beiden Anordnungen die Sprach- und Rufsignalisierungsdaten getrennt sind.
3 zeigt ein gesamtes System, in dem eine mobile Einheit 60 mit ihrem Komprimierer 64 durch die Luftschnittstelle 61 sequenziell an ein Radio Access Network (RAN) 81, das Daten zwischen der Luftschnittstelle 61 und dem Core Network 84 tunnelt oder weiterleitet, und einen Dekomprimierer CD 83 im CN 84 angeschlossen ist, der über das Internet an einen IP-Host 85 angeschlossen ist.
In den Anordnungen, die in 2a, 2b und 3 dargestellt sind, wird angenommen, dass die IP/UDP/RTP-Kopffeldinformationen nicht zum Routen usw. von der mobilen Station 60 zu dem CD 83 im CN 84 verwendet werden; stattdessen werden alle Daten, die Sprachpakete enthalten, weitergeleitet/getunnelt. Es wird angenommen, dass die Pakete der Reihe nach zwischen der mobilen Station 60 und dem CD 83 geliefert werden. Es wird ferner angenommen, dass ein gewisser Mechanismus imstande ist, komprimierte (Sprach-) Pakete von normalen (unkomprimierten) Paketen unterscheiden kann, und diese Unterscheidung aufrechterhalten werden kann, bis das CN 84 erreicht ist.
Die beschriebene Anordnung kann ein Maß an Funkeffizienz erreichen, das ähnlich dem Maß eines leitungsvermittelten Sprachdienstes ist, der von drahtlosen Telekommunikationssystemen, wie GSM, geboten wird.
Es ist ein weiterer Vorteil, dass kein Fehlerkorrekturmechanismus erforderlich ist, und es keine Abhängigkeit zwischen Paketen von einer Dekomprimierung gibt, so dass ein Paketverlust keine Fehlfunktion des Komprimierungspunktes verrusacht.
Die VoIP-Applikationen 68, 78 laufen, als ob sie auf ein normales IP-Netzwerk zugriffen, obwohl die Sprachpakete entlang ihres Reisepfades von der MS 60 zu dem CN 84 anders behandelt werden. Ebenso werden vom Standpunkt des anderen IP-Endpunktes 85 (einem Benutzerendgerät oder einem IP/PSTN-Gateway) die Elemente im RAN 81 (MS 60, Knoten B und RNC 80) insgesamt als Endpunkt behandelt, da die Sprach-Frames (Daten 63) einen relativ langen Weg zurücklegen müssen, bevor sie beim CD 83 einem RTP-Framing unterzogen werden.
Allgemeine Nutzen der Anordnung sind, dass eine höhere Komprimierungsverstärkung vorhanden ist und Ressourcen gespart werden; dass das System arbeitet, wenn die Umlaufzeit zwischen Komprimierung und Dekomprimierung lange ist, und dass die Vorteile einer Rufsignalisierung auf IP-Basis beibehalten werden können.
6. Beschreibung bevorzugter Algorithmen
Es gibt einen Komprimierungsalgorithmus für IP/UDP/RTP-Kopffelder, der als "Best-Effort verlustbehaftete Komprimierung" charakterisiert ist. Der Algorithmus beruht auf der Tatsache, dass IP/UDP/RTP-Kopffelder zwischen der MS 64 und dem CN 84 nicht verwendet werden.
6a. Bevorzugter Algorithmus
Das Ziel ist, die wechselseitige Abhängigkeit komprimierter Pakete aufzubrechen. Anstatt relative Werte in den komprimierten Kopffeldern (durch Differenzialcodierung) zu senden, werden Absolutwerte (timeclick numbers) gesendet, wie von Petrack nahegelegt wird. Da es kein wechselseitiges Verhältnis zwischen komprimierten RTP-Paketen gibt, beendet ein Paketverlust die Dekomprimierung nicht.

– Unter Verwendung des ersten Algorithmus kann das komprimierte Kopffeld nur 1 Byte sein, im Vergleich zu 2 bis 5 Bytes in einer bekannten Anordnung. Die wichtigsten Informationen im RTP-Kopffeld, die zwei zeitbezogenen Felder – Zeitstempel und Folgenummer, müssen erhalten bleiben. Wie in der obengenannten Arbeit von Petrack betont wird, können diese zwei Felder durch eine "timeclick_number" (in einem Byte) ersetzt werden. Diese Nummer unterstützt den Dekomprimierer, einen richtigen Zeitstempel (der die Abtastzeit an der mobilen Station 60 wiedergibt) und eine richtige Folgenummer festzulegen. Die Veröffentlichung schlägt vor, dass anstelle des herkömmlichen Zeitstempels und der RTP-Nummer eine einzige 1 Byte "timeclick number" mit jedem Paket gesendet wird. In der vorigen Veröffentlichung wird jedoch nicht offenbart, wie der Zeitstempel und die Folgenummer erhalten werden, oder wie die Außerband-Komprimierungszustände hergestellt werden.
– Es wird angenommen, dass es pro Endgerät nur eine VoIP-Sitzung gibt, die einer Komprimierung bedarf, so dass keine CID-(Context ID) Bits erforderlich sind. Das M-Bit im RTP-Kopffeld bleibt erhalten und wird mit jedem komprimierten Paket gesendet.

Komprimierungszustand. Der Komprimierungszustand enthält die folgenden Informationen für einen zu komprimierenden Anruf (bestehend aus zwei RTP-Sitzungen): Für jedes Ende eines Anrufs: IP-Adresse, zwei Port-Nummern (ursprüngliche und eintreffende), SSRC usw., für den Anruf: den verwendeten Codec und seine Parameter (z.B. Abtastrate und Abtastdauer). Der Codec wird für beide Richtungen als derselbe angenommen. (Wenn nicht, müssen sie getrennt gespeichert werden).
Die Herstellung des Komprimierungszustandes erfolgt über ein Außerbandprotokoll, das mit dem Rufsignalisierungsprotokoll zusammenarbeiten kann, und wird später beschrieben. Dieses Protokoll hilft auch bei der Migration der Statusinformationen von einem CD zu einem anderen im Falle eines Umschaltens zwischen CDs.
Komprimierungsverfahren: Durch die Komprimierung werden drei Felder auf fast verlustfreie Weise beibehalten: Zeitstempel, Folgenummer und das M-Bit. Ein Byte (8 Bits) wird für das komprimierte Kopffeld verwendet: das erste Bit wird für das M-Bit verwendet und die anderen 7 Bits für die timeclick_number, die die Abtastzeit der Sprachnutzlast darstellt, die im Paket enthalten ist. Sie wird jede Abtastdauer um 1 erhöht, z.B. 20 ms für die GMS6.10 Codierung. Sie wird selbst in der stillen Periode weiter erhöht, wenn tatsächlich keine Pakete ausgesendet werden.
Die Felder, deren Informationen durch die Komprimierung ungenau werden können, sind:

– Die Paket-ID im IP v4. Es wird angenommen, dass das Paket ID-Feld immer um 1 höher wird, so dass es nicht übertragen werden muss. Wenn ein Paketverlust erfasst wird, wird der ID-Wert entsprechend eingestellt. Da nicht jeder Paketverlust erfasst werden kann, kann somit der ID-Wert ungenau werden.
– UDP-Prüfsummenfeld. Das Prüfsummenfeld wird vom mobilen Endgerät 60 nicht verwendet (auf 0 gestellt). Wenn es auf der Abwärtsrichtung verwendet wird, wird es von dem CD im Netzwerk auf 0 gestellt (und dann wird die Ende-zu-Ende-Fehlererfassung für Applikationen, die diese benötigen, gesperrt). Somit wird die Fehlerkorrektur, die die UDP-Prüfsumme verwendet, gesperrt.
– RTP-CSRC-Liste. Für die Aufwärtsrichtung sollte die CSRC-Liste immer leer sein. Für die Abwärtsrichtung kann sie sich ändern (z.B. im Falle eines Konferenzgesprächs). Für ein Gespräch unter zwei Teilnehmern bleibt sie unverändert (leer).
– Folgenummer. Im Falle eines Paketverlustes zwischen der mobilen Station und dem RTP-Proxy, und wenn dieser nicht vom Dekomprimierer erfasst wird, ist die Folgenummer, die vom RTP-Proxy gewonnen wird, unrichtig, was die Genauigkeit des statistischen Ergebnisses der Paketverlustrate beeinflussen könnte.

Es gibt zwei Zugriffsmoden für den Komprimierungsdienst. Einer ist der direkte Zugriff durch die voIP-Applikation (wie in 2(b) dargestellt) unter Umgehung der Transport- und Netzwerkschichten. Der offensichtliche Vorteil ist die Effizienz, wobei aber eine Änderung der Applikation oder eine Einbettung der Transportschicht notwendig sein könnte. Die Dienstzugangsgrundoperation für den Komprimierer kann wie folgt sein:
Komprimieren (M, timeclick_number, Sprachnutzlast)
Es ist unkompliziert, ein komprimiertes RTP-Paket mit diesen drei Dateninhalten zu erzeugen.
Als Alternative kann auf den Komprimierungsdienst über die Netzwerkschicht transparent zugegriffen werden (wie in 2(a) dargestellt ist), und somit ist allen oberen Schichten die Komprimierung unbekannt. In diesem Fall werden bei Empfang eines Pakets von der oberen Schicht die Felder Ursprung/Zielort-IP und Portnummer wie auch die Ursprung-SSRC geprüft. Diese fünf Felder identifizieren eine RTP-Sitzung und durch die Prüfung dieses Feldes gegen die Komprimierungszustandstabelle wird entschieden, entweder das Paket (wenn es ein RTP-Paket ist, dessen Komprimierungszustand bereits hergestellt wurde) zu komprimieren, oder es wie ein normales Nicht-RTP-Paket zu behandeln. wenn es ein zu komprimierendes RTP-Paket ist, wird das Zeitstempelfeld in eine timeclick_number umgesetzt. Dann kann die obengenannte Dienstgrundoperation aufgerufen werden.
Wenn für die Abwärtsrichtung die UDP-Prüfsumme verwendet wird (nicht Null), wird sie ignoriert.

– Nach dem Erzeugen eines komprimierten RPT-Pakets wird es in ein Sicherungsschichtpaket gestellt, gemeinsam mit einem Marker, der es als Sprachdatenpaket ausweist. Jedes andere, nicht komprimiertes Paket wird in ein Sicherungsschichtpaket gestellt, das als allgemeines Datenpaket gekennzeichnet ist.

Dekomprimierungsprozess
Mit Ausnahme der zeitbezogenen RTP-Kopffelder erfolgt eine Wiederherstellung der anderen Felder von der Komprimierung mit einer ähnlichen Methode wie RFC 2508.
Für das Zeitstempelfeld: das zu lösende Hauptproblem ist, dass das Feld für die timeclick_number nur 7 Bits ist. Die Click-Zählung wird fortgesetzt und kann leicht während eines einzigen Telefongesprächs einen Umlauf erfahren (periodisch zurückgesetzt werden). Wenn während einer stillen Periode kein Paket vom Komprimierer gesendet wird, muss die Zeit, die für diese stille Periode verstrichen ist (im Sinne der Anzahl verstrichener Zyklen) erfasst werden.
Im ersten Algorithmus gemäß der Erfindung wird eine Computeruhr beim CD 84 zum Zählen der Zyklen verwendet, und die timeclick_number wird unter Bezugnahme auf die Zeitablesung zur Einstellung des Zeitstempelfeldes verwendet. Die Uhr kann bei einer gröberen Einstellung laufen. Zum Beispiel kann sie jede T/4-Periode um 1 erhöht werden, unter der Annahme, dass die maximale Phasenschwankung (Jitter) geringer als T/4 ist, was eine sichere Annahme ist, wobei T die Zeitperiode eines Zyklus ist, der durch 7 Bits dargestellt wird. Sie beträgt für gewöhnlich einige Sekunden, abhängig von den Codec-Parametern.
Bei Betrachtung nun der Folgenummer wird diese Nummer für gewöhnlich für jedes konsekutive Paket um 1 erhöht. Sie wird vorwiegend zur Wiedergabe des Paketverlustes verwendet. Im ersten Algorithmus gemäß der Erfindung wird ein heuristisches Verfahren zum Erfassen des Paketverlustes durch Prüfen sowohl der Erhöhung der timeclick_number wie auch des M-Bits verwendet. Wenn die timeclick_number um eine kleine Zahl, die nicht Eins ist (zum Beispiel Zwei, Drei, usw.) erhöht wird, aber das M-Bit nicht gesetzt ist, ist wahrscheinlich ein gewisser Paketverlust vorhanden. In diesem Fall wird die Folgenummer um die Differenz der timeclick_number erhöht. Wenn das Paket, das das gesetzte M-Bit trägt, verloren geht (dann ist die größere Erhöhung der timeclick_number normal, da es eine stille Periode ist), sollte die Folgenummer dennoch um 1 erhöht werden. Die Wahrscheinlichkeit, dass diese Situation eintritt, ist ziemlich gering. Selbst wenn dies eintritt und die Folgenummer versehentlich erhöht wird, beeinflusst dies das statistische Ergebnis der Paketverlustrate, die von dem anderen RTP-Ende wahrgenommen wird (nur wenig mehr Pakete werden als verloren angegeben), in geringem Maße.
Begriffserklärung

sd:

Abtastdauer, der Wert sollte sich aus der Gesprächsaufbauprozedur ergeben, z.B. 20 ms (Sprache in jedem Paket)

sr:

Abtastrate, der Wert sollte sich aus der Gesprächsaufbauprozedur ergeben, z.B. 8000

nb:

Anzahl von Bits, die für die timeclick_number verwendet werden

TSlast:

Zeitstempelnummer für das vorangehende Paket

TSthis:

Zeitstempelnummer für dieses Paket

WTlast:

Ablesung der real verstrichenen Zeit für das vorangehende Paket

WTthis:

Ablesung der real verstrichenen Zeit für dieses Paket

TNlast:

timeclick_number für das vorangehende Paket im komprimierten Kopffeld

TNthis:

timeclick_number für dieses Paket im komprimierten Kopffeld

SNlast:

RTP-Folgenummer für das vorangehende Paket

SNthis:

RTP-Folgenummer für dieses Paket

T:

Zeitperiode, die unter Verwendung von nb Bits (einer Zyklusperiode) dargestellt wird, in Einheiten der Abtastdauer (sd) T = 2**nb

M:

Der Wert des "M"-Bits, im komprimierten Kopffeld

Berechnen des Zeitstempels und der Folgenummer:
Tsthis = Tslast + 1, wenn M = 0 und delta_tick = 1
= Tslast + (delta_cycle*(2**nb) + delta_tick)*sd*sT/1000,
wobei sonst:
delta tick = (T + Tnthis – Tnlast) mod T
delta_wtick = Wtthis – Wtlast mod T
delta_cycle = (Wtthis – Wtlast)/T/*ganzzahliger Teil*/

delta_cycle = delta_cycle' – 1, wenn delta wtick <
delta tick und delta tick-delta wtick ≥ T/2
= delta_cycle' + 1, wenn delta_tick < delta wtick und delta wtick – delta tick ≥ T/2
= delta_cycle', sonst
Snthis = Snlast + delta tick, wenn delta tick! = 1 und delta_tick < 4 und M! = 1
Während der bevorzugte Algorithmus unter Bezugnahme auf ein paketvermittelndes Funknetz beschrieben wurde, kann der Algorithmus auch unter anderen Umständen angewendet werden, wenn die folgenden Merkmale gelten:

– Der erste Schenkel zwischen einer mobilen Station und dem IP-Netzwerk ist eine Punkt-Punkt-Verbindung, über die die IP-Kopffelder nicht verwendet werden.
– Der erste Verbindungsschenkel garantiert eine ordnungsgemäße Lieferung und eine geringe Phasenschwankung. Eine gewisse Ungenauigkeit im Kopffeld, die zuvor besprochen wurde, ist für diese Applikation annehmbar.

7a. Bevorzugtes Verfahren zur Herstellung und Wiederherstellung eines Komprimierungszustandes
Das Verfahren zur Herstellung des Komprimierungszustandes wird aus mehreren Gründen/bei mehreren Gelegenheiten verwendet:

– Zu Beginn einer RTP-Sitzung muss der Komprimierungszustandes hergestellt werden, um mit dem Komprimieren und Dekomprimieren zu beginnnen.
– Wenn eine Umschaltung zwischen CDs stattfindet, muss der Komprimierungszustand zu dem neuen CD vom mobilen Endgerät und/oder vom alten CD migriert werden.

Der Komprimierungszustand enthält die folgenden Informationen: IP-Adresse und SSRC für beide Gesprächsenden, zwei Paare von RTP-(UDP-)Portnummern, Art der Nutzlast, Abtastrate, Abtastdauer, usw.
Es wird angenommen, dass die Sprachcodierung für beide Richtungen dieselbe ist, andernfalls müssen sie getrennt gespeichert werden.
Das Herstellen und Wiederherstellen des Komprimierungszustandes erfolgt unter Verwendung eines Außerbandprotokolls, das in 5 dargestellt ist, die einen Komprimierer der mobilen Station 90 zeigt, der an eine VoIP-Rufsteuerschicht 92 unter der Steuerung einer dritten Partei angeschlossen ist; einen CD 94 des dienstleistenden Netzes und einen anderen Netzkomprimierer 96; und die Netz-CDs 94, 96 sind direkt durch eine Außerbandverbindung 98 verbunden und auch an eine VoIP-Rufsteuerschicht 100 und eine Mobilitätsmanagementschicht 102 unter der Steuerung einer dritten Partei angeschlossen.
Alle CDs 90, 94, 96 sind in Wahrheit Komprimierer/Dekomprimierer.
Die CDs 90 an der mobilen Station und 94 im Netzwerk haben eine Steuerungsschnittstelle. Beide CDs hören auf einem bekannten Port zur Annahme von Anweisungen, um mit der Komprimierung zu beginnen/zu enden, und Statusinformationen von der dritten Partei zu empfangen. Für gewöhnlich kommen die Anweisung und Informationen von der Sprachapplikation an der MS und/oder dem Signalisierungs-Gateway (z.B. einem 4.323 Gatekeeper oder SIP (Session Initiation Protocol) Server) im Netzwerk. (Es wird angenommen, dass die IP-Adresse des dienstleistenden CD dem Signalisierungs-Gateway bekannt ist.)
Es gibt sechs Nachrichten, die zwischen dem CD und einer Steuerung der dritten Partei oder zwischen zwei CDs definiert sind (ohne die Bestätigungsnachrichten):

1. STATE_START. Diese Nachricht gibt an, dass eine neue Komprimierungssitzung und ihr Zustand herzustellen sind. Sie sollte eine Identität der MS enthalten, die an der Sitzung beteiligt ist. Als Option kann sie ein volles (nicht komprimiertes) RTP-Paket enthalten, so dass die Komprimierungszustandinformation daraus ermittelt werden kann.
2. STATE_INPUT. Diese Nachricht stellt Werte von Zustandsattributen bereit oder modifiziert diese. Sie enthält eine Liste von (attribute name value) Paaren.
3. STATE_ENQRY und STATE_ENQRY RPL. Diese beiden Nachrichten können zur Abfrage der Statusinformationen verwendet werden, und um festzustellen, ob es möglich ist, Komprimierungs-/Dekomprimierungsaufgaben auszuführen.
4. STATE_HANDOVER. Diese Nachricht informiert einen derzeit dienstleistenden CP, Statusinformationen zu einem neuen CP zu senden, oder fordert einen neuen dienstleistenden CP auf, Statusinformationen von einem vorangehenden CP zu erlangen. Die Nachricht enthält Informationen über die IP-Adresse alter und neuer CPs und die Identität der beteiligten MS.
5. STATE_STOP. Diese Nachricht löscht einen Komprimierungszustand. Eine Komprimierung kann bei Bedarf auch vom Komprimierer selbst gelöscht werden.

Die Nachricht STATE_INPUT wird auch zwischen dem Komprimierer 90 an der MS und dem CD 94, 96 im Netzwerk zum Austausch von Zustandsinformationen verwendet. Somit stehen durch die Verwendung dieses Protokolls die Informationen, die an einem Ende verfügbar sind, am anderen Ende zur Verfügung.
Die Nachrichten STATE_INPUT und STATE_ENQRY werden auch zum Bewegen von Zustandsinformationen von einem CD zu einem anderen beim Umschalten verwendet. Abgesehen von den obengenannten Zustandselementen werden einige zusätzliche Informationen, wie die örtliche Zeitablesung, auch zu dem neuen CD geleitet.
Es ist möglich, dass der Komprimierer Werte aufnimmt oder Vorgabewerte für einige Attribute unter einigen Umständen verwendet.
Dieser Prozess unterstützt auch die Zustandswiederherstellung zwischen CDs bei der MS und im Netzwerk. Dies ist notwendig, wenn die Zustandsinformationen an einer Seite beschädigt werden oder verloren gehen. Sobald der Komprimierer beim CD oder bei der MS für ein Gerät das Fehlen oder die Unvollständigkeit von Zustandsinformationen erfasst, kann er STATE_ENQRY verwenden, um die Zustandsinformationen vom anderen Ende zu erhalten.
Während der erfindungsgemäße Prozess zum Herstellen oder Wiederherstellen des Komprimierungszustandes unter Bezugnahme auf ein paketvermittelndes Funktelekommunikationsnetz beschrieben wurde, kann der Prozess auch für jeden Komprimierungsprozess für eine verbindungsorientierte Applikation wie VoIP und Multimediasitzungen verwendet werden.
8. Zwei bevorzugte Prozesse für ein Umschalten zwischen zwei Komprimierungspunkten
Ein Problem, das Komprimierungsschema, das in RFC2508 dargestellt ist, in drahtlosen Netzwerken zu verwenden, ist die Auswirkung der Mobilität. Wenn ein Umschalten erfolgt, ist es möglich, dass sich der dienstleistende CD ändert. Somit müssen die Komprimierungszustände, die im CD vor dem Umschalten gespeichert sind, zu dem neuen CD bewegt oder dort wiederhergestellt werden.
Zur Lösung dieses Problems werden zwei alternative Methoden vorgeschlagen:

• Erstens kann eine gewisse Kommunikation zwischen zwei CDs hergestellt werden, so dass diese Komprimierungszustände austauschen können, wie in 6 dargestellt ist, in der eine mobile Station mit einem Komprimierer 104 von einem dienstleistenden CD im Netzwerk 106 zu einem neuen CD 108 im Netzwerk umgeschaltet wird. Die dienstleistenden und neuen CDs 106, 108 sind mit einem Außerbandkommunikationskanal 110 bereitgestellt.
– Eine Möglichkeit, die Komprimierungszustandsinformationen unter einer Gruppe von CDs zu teilen, (die möglicherweise zum dienstleistenden CD nach dem Umschalten werden), so dass, wenn das Umschalten erfolgt, der notwendige Komprimierungskontext bereits in dem neuen CD vorhanden ist. Die Kosten dieser Methode ist die CPU-Zeit und der Speicher, der zum Empfangen/Speichern des Kontextes notwendig ist, der möglicherweise überhaupt nicht verwendet wird.
– Eine andere Möglichkeit ist der Austausch der Kontaktinformationen während des Umschaltens. Zur Anwendung dieser Methode ist eine Mitarbeit vom Umschaltmechanismus notwendig, so dass der Austausch von Komprimierungszustandsinformationen eingeleitet werden kann, wenn der CD geändert wird.
– Eine dritte Möglichkeit ist die Nutzung eines sanften Umschaltmerkmals, das in CDMA Netzwerken verfügbar ist. Der Austausch von Kontext kann während der sanften Umschaltperiode ausgeführt werden. Diese Methode erfordert die Mitwirkung vom Funknetz, so dass die zwei CDs informiert werden können, wenn ein sanftes Umschalten erfolgt.
Damit der Dekomprimierungsprozess bei dem neuen CD möglich ist, sollte der Austausch der Komprimierungszustandsinformationen den Zeitstempelwert und den Folgenummerwert in dem letzten, von dem vorigen CD dekomprimierten RTP-Paket enthalten. Die zwei Computeruhren bei dem vorigen und neuen CD müssen synchronisiert sein. Wenn der neue CD beginnt, die umgeschaltete RTP-Sitzung zu bedienen, liest er seine eigene Uhr und verwendet die Ablesung als Zeitablesung für das letzte Paket.
• Zweitens wird, wie in einer UMTS- und GPRS- Situation, das Benutzer-IP bis zu dem Punkt nicht verwendet, an dem das CN für ein Fernnetz verlassen wird (ein Tunnelling-Protokoll wird für den Transport des Benutzerpakets zwischen BSS und CN verwendet). Daher können wir dieses Merkmal nutzen, und das CP an den Rand des CN stellen, zum Beispiel beim GGSN, so dass das CP für das Umschalten transparent ist. Insbesondere können beim Bewegen des CP in das CN das CP und das IP/PSTN-Gateway, das zur Nutzung des VoP-Dienstnetzes erforderlich ist, integriert werden. Der Nachteil dieser Methode ist der mögliche Leistungsengpass beim CP im Netzwerk

Für den Fachmann werden angesichts der vorangehenden Offenbarung einige Modifizierungen der vorliegenden Erfindung sofort offensichtlich. Daher sollte der Umfang der vorliegenden Erfindung aus den folgenden Ansprüchen interpretiert werden, wobei diese Ansprüche im Lichte der Offenbarungen zu lesen sind.

Claims

Verfahren zum Komprimieren (64) und Dekomprimieren (83) von Kopffeldern für ein Paketvermittlungsnetz (10) mit Bereitstellung in jedem komprimierten Kopffeld einer zyklisch rückgesetzten timeclick_number, die die Abtastzeit der Paketnutzlast darstellt, Erhöhen der timeclick_number um 1 für jede Abtastdauer, Zählen der rückgesetzten Zyklen und aus der Zählung rückgesetzter Zyklen und einer empfangenen timeclick_number Bereitstellen einer Folgenummer und eines Zeitstempels zum Bereitstellen eines dekomprimierten Kopffeldes.
Verfahren nach Anspruch 1, weiterhin mit Einschließen in jedem komprimierten Kopffeld eines M-Bits und Dekomprimieren eines Kopffeldes, wenn kein M-Bit empfangen wird, durch Erhöhen der Paketfolgenummer des dekomprimierten Kopffeldes um den Unterschied der timeclick_numbers zwischen dem Paket, für das kein M-Bit empfangen wird, und dem letzten vorher empfangenen Paket mit einem M-Bit.