DE60304938T2

DE60304938T2 - Kompression von Protokollnachrichten in einem Mobilfunksystem

Info

Publication number: DE60304938T2
Application number: DE60304938T
Authority: DE
Inventors: Marlboro Mooi Choo Chuah; Highland Park Tingfang Ji; Aurora Subhasis Laha
Original assignee: Lucent Technologies Inc
Current assignee: Nokia of America Corp
Priority date: 2002-06-17
Filing date: 2003-05-22
Publication date: 2006-12-14
Anticipated expiration: 2023-05-23
Also published as: EP1376878A1; US20030233478A1; US7143191B2; DE60304938D1; EP1376878B1; KR20040002566A; JP2004096717A

Description

QUERVERWEIS AUF VERWANDTE ANMELDUNGEN
Diese Anmeldung ist mit einer gleichzeitig eingereichten Anmeldung von Chuah et al. mit dem Titel "Binary Protocol For Session Initiation in a Wireless Communications System" verwandt.
ALLGEMEINER STAND DER TECHNIK
1. Gebiet der Erfindung
Die vorliegende Erfindung betrifft Kommunikationen und spezieller die Kompression von Protokollnachrichten für ein drahtloses Kommunikationssystem.
2. Beschreibung des Standes der Technik
Von der Allgemeinheit werden gewöhnlich zwei Kommunikationstechnologien verwendet, die Zellulartelefonie und das Internet. Die Zellulartelefonie stellt ihren Benutzern die Freiheit von Mobilität zur Verfügung – die Möglichkeit, unabhängig vom Standort mit einer ausreichenden Dienstqualität erreicht zu werden. Der wichtigste Dienst, der durch Zellulartelefonie bereitgestellt wird, ist jedoch Sprache. Während Flexibilität für alle Arten von Anwendungen (Sprache, Daten, Video, Audio usw.) die Stärke des Internets war, lag sein Schwerpunkt bei fest geschalteten Verbindungen und relativ großen Endgeräten, und die Qualität einiger Dienste (wie etwa der Internettelefonie) war im Allgemeinen gering. Im Ergebnis des technischen Fortschritts verschmelzen Internet- und Zellulartechnologien. Zukünftige Zellular-"Telefone" können einen IP-Stapel (Internet-Protokoll) enthalten und Voice over IP unterstützen, zusätzlich zu Web-Browsing, E-Mail usw. Im Grunde genommen wird das Internet mobil, oder Zellularfunksysteme werden zu wesentlich mehr als Telefonie, je nachdem, von welchem Standpunkt aus man es betrachtet.
1 zeigt ein herkömmliches Netz 10, welches in ein Funkzugangsnetz (Radio Access Network, RAN) 12 und ein Kernnetz (Core Network, CN) 14 unterteilt werden kann. Das RAN 12 umfasst die Ausrüstung, die verwendet wird, um drahtlose Schnittstellen 16a-b zwischen einer drahtlosen Einheit 18a-b und dem Netz 10 zu unterstützen. Das RAN 12 enthält Node Bs oder Basisstationen 20a-c, die über Übertragungsstrecken (Iub-Übertragungsstrecken) 21a-c mit Funknetz- oder Basisstationssteuerungen (Radio Network Controllers, RNCs) 22a-c verbunden sind. Die Schnittstelle zwischen der Basisstation und der RNC wird als die Iub-Schnittstelle oder Übertragungsstrecke (Link) bezeichnet, und die Schnittstelle zwischen zwei RNCs wird als die Iur-Schnittstelle bezeichnet. Gegenwärtig basieren sowohl die Iub- als auch die Iur-Schnittstellen auf ATM (Asynchronous Transfer Mode), und zwischen Node Bs und RNCs sind ATM-Vermittlungen zulässig.
Das Kernnetz 14 enthält die Netzelemente, welche leitungsbasierte Kommunikation sowie paketbasierte Kommunikation unterstützen. Beim Aufbauen eines Leitungskanals, um leitungsbasierte Übermittlungen zwischen der drahtlosen Einheit 18b und einem öffentlichen Telefonwählnetz (Public Switched Telephone Network, PSTN) 24 oder einer anderen drahtlosen Einheit abzuwickeln, empfängt (über die Aufwärtsverbindung) und sendet (über die Abwärtsverbindung) die Basisstation 20b die codierten Informationen (leitungsvermittelte Sprache oder leitungsvermittelte Daten) über die drahtlose Schnittstelle oder Übertragungsstrecke 16b. Die RNC 22b ist für Rahmenauswahl, Verschlüsselung und Behandlung von Mobilität im Zugangsnetz verantwortlich. Die RNC 22b leitet die leitungsvermittelte Sprache oder leitungsvermittelten Daten über ein Netz wie etwa ein ATM/IP-Netz zu einer 3G Mobilfunkvermittlungsstelle (Mobile Switching Center, MSC) 30 weiter. Die 3G-MSC 30 ist für die Verbindungsabwicklung und Makromobilität auf der MSC-Ebene verantwortlich. Die 3G-MSC 30 stellt die Konnektivität zwischen der drahtlosen Einheit 18b und dem PSTN 24 her.
Gebräuchliche Begriffe auf diesem technischen Gebiet sind "all-IP" und "IP all the way". Diese Begriffe betreffen beide den Fall, in dem ein IP durchgehend verwendet wird, selbst wenn der Weg Zellularfunk-Übertragungsstrecken enthält und IP auch über den/die Funkabschnitt (e) verwendet wird. Dies wird für alle Arten von Verkehr durchgeführt, sowohl die Benutzerdaten (z.B. Sprache oder Streaming) als auch die Steuersignalisierungsdaten, entweder mit SIP (Session Initiation Protocol) oder RTSP (Real Time Streaming Protocol). Ein Vorteil hiervon ist die durch IP erreichte Dienstflexibilität, kombiniert mit der Freiheit, die durch kontinuierliche Mobilität gewährleistet wird. Der Nachteil ist der relativ große Overhead, den die IP-Protokoll-Familie normalerweise mit sich bringt, z.B. infolge von umfangreichen Headern und textbasierten Signalisierungsprotokollen.
In Zellularsystemen sollten die knappen Funkressourcen auf eine effiziente Weise genutzt werden. Es sollte möglich sein, eine ausreichende Anzahl von Benutzern pro Zelle zu unterstützen, da andernfalls die Kosten unannehmbar hoch werden. Das Frequenzspektrum und somit die Bandbreite sind bei Zellularfunk-Übertragungsstrecken kostbare Ressourcen und sollten sorgfältig genutzt werden.
Die ROHC (RObust Header Compression) Arbeitsgruppe hat das Problem der Reduzierung des Bandbreitenbedarfs für die Header-Teile von Real Time Protocol (RTP), User Datagram Protocol (UDP) und IP-Paketen erfolgreich gelöst. Nachdem dieses Hindernis beseitigt wurde, eröffnen sich neue Möglichkeiten für die Erhöhung der Leistungsfähigkeit des mobilen Internets. Eine von ihnen betrifft Anwendungs-Signalisierungsprotokolle.
Normalerweise werden Protokolle wie etwa SIP, RTSP und SDP (Session Description Protocol) verwendet, um Anwendungen in einem mobilen Internet einzurichten und zu steuern. Die Protokollnachrichten haben jedoch einen großen Umfang und verursachen aufgrund dessen, dass sie vom Typ "Anforderung/Antwort" sind, Verzögerungen. Eine Kompression dieser Nachrichten würde die Frequenzökonomie verbessern und die Durchlauf zeit verkürzen.
Das SIP ist ein Anwendungsschichtprotokoll zum Aufbauen, Ändern und Beenden von Multimediasitzungen oder -verbindungen. Zu diesen Sitzungen gehören Internet-Multimediakonferenzen, Internet-Telefonie und ähnliche Anwendungen. SIP kann entweder über TCP (Transmission Control Protocol) oder UDP verwendet werden. SIP ist ein textbasiertes Protokoll, das ISO 10646 in UTF-8-Codierung verwendet.
Das SDP kann verwendet werden, um Multimediakonferenzen bekannt zu machen und Konferenzadressen und für Konferenztools spezifische Informationen zu übermitteln. Das SDP wird auch für allgemeine Zwecke der Beschreibung von Multimediasitzungen in Echtzeit verwendet. SDP wird im Nachrichtenrumpf von SIP- und RTSP-Nachrichten transportiert. SDP ist textbasiert und verwendet den ISO 10646 Zeichensatz in UTF-8-Codierung.
Das RTSP ist ein Protokoll der Anwendungsebene zum Steuern der Zustellung von Daten mit Echtzeiteigenschaften wie etwa Audio und Video. RTSP kann UDP oder TCP (oder ein anderes Protokoll) als Transportprotokoll verwenden. RTSP ist textbasiert und verwendet den ISO 10646 Zeichensatz in UTF-8-Codierung.
Die obigen Protokolle weisen viele Ähnlichkeiten auf. Diese Ähnlichkeiten haben Auswirkungen auf Lösungen der Probleme, die sie im Zusammenhang mit dem Zellularfunkzugang erzeugen. Ihre Ähnlichkeiten beinhalten Folgendes:

• Anforderungs- und Antwort-Eigenschaften. Wenn ein Absender eine Anforderung sendet, verbleibt er im Ruhezustand, bis er eine Antwort empfangen hat; folglich werden normalerweise mehrere Umlaufzeiten benötigt, um eine SIP-, SDP- oder RTSP-Sitzung abzuschließen.
• Sie sind ASCII-basiert. Somit werden, um den Wert 230 darzustellen, 3·8 = 24 Bits verwendet. Im Vergleich hierzu würde eine binäre Darstellung desselben Wertes nur 8 Bits erfordern.
• Sie besitzen einen großen Umfang, um den Sitzungsteilnehmern die notwendigen Informationen zur Verfügung zu stellen.

SIP und RTSP haben viele Namen von Header-Feldern, Verfahren und Zustandscodes gemeinsam. Ihre Verkehrsverläufe sind ebenfalls ähnlich. Die Signalisierung wird hauptsächlich während der Phase des Verbindungsaufbaus durchgeführt. Für SIP bedeutet dies, dass der größte Teil der Signalisierung durchgeführt wird, um eine Telefonverbindung oder Multimediasitzung aufzubauen. Für RTSP bedeutet es, dass der größte Teil der Signalisierung vor der Übertragung von Anwendungsdaten durchgeführt wird.
Die Notwendigkeit, die durch die Nachrichten der Signalisierungsprotokolle verursachten Probleme zu lösen, wird klar, wenn man eine typische SIP/SDP-Verbindungsaufbau-Sequenz über einen Mobilfunkkanal mit geringer Bandbreite betrachtet und die Ergebnisse eines einfachen Beispiels der Systemkapazität studiert. Diese Ergebnisse weisen darauf hin, dass eine Erhöhung der Systemkapazität auch durch Verringerung der Größe der einzelnen Protokollnachrichten erzielt würde.
2 zeigt ein Beispiel einer SIP-Signalisierung zwischen zwei Endpunkten mit einer drahtlosen Verbindung zwischen ihnen und die resultierende Laufzeit unter bestimmten Annahmen hinsichtlich des Systems.
Die Einweg-Laufzeit (One Way Delay) wird gemäß der folgenden Gleichung berechnet: Einweg-Laufzeit = Nachrichtengröße [in bit]/Geschwindigkeit der Verbindung [in bit/s] + RTT [in s]/2 Glg. (1)wobei RTT die Umlaufzeit (Round Trip Time) ist.
Es wurden folgende Werte verwendet:

RTT/2: 70 ms

Geschwindigkeit der Verbindung 9,6 kbps
Die Formel für die Laufzeit in Glg. (1) beruht auf einer Approximation des WCDMA (Wideband Code Division Multiple Access) Funkzugangsverfahrens für Sprachdienste. Zum Beispiel werden Laufzeiten, die durch eventuelle nochmalige Übertragungen aufgrund von Fehlern verursacht werden, ignoriert.
Die Anwendung von Glg. (1) auf die einzelnen SIP/SDP-Nachrichten, die in dem Beispiel von 2 dargestellt sind, ergibt eine Gesamtlaufzeit von 4130 ms von der ersten SIP/SDP-Nachricht bis zur letzten. Das RSVP- und Sitzungs-Management (Funkträger-Aufbau), das in 2 dargestellt ist, erhöht die Gesamtlaufzeit unter Verwendung von Glg. (1) um ungefähr 1,5 Sekunden. Es kann jedoch auch RSVP- und SM-Signalisierung vor der SIP INVITE Nachricht vorhanden sein, um den Funkträger einzurichten, wodurch weitere 1,5 Sekunden hinzukommen würden.
Die TSG (Technical Specification Group) hat einen Vergleich zwischen einem GSM (Global System for Mobi les) Edge (Enhanced Data Rates for Global Evolution) Radio Access Network (GERAN) Verbindungsaufbau unter Verwendung von SIP und einem gewöhnlichen GSM Verbindungsaufbau durchgeführt. Für einen typischen GSM Verbindungsaufbau beträgt die Zeit ungefähr 3,6 Sekunden, und in dem Fall, wenn SIP verwendet wird, dauert der Verbindungsaufbau ungefähr 7,9 Sekunden.
Bei einer ersten Lösung zur Verkürzung der Dauer des Verbindungsaufbaus bei Verwendung von SIP werden ein dynamisches Wörterbuch und der LZSS (Lempel-Ziv-Storer-Szymanski) Kompressionsalgorithmus verwendet. Das dynamische Wörterbuch wird geführt, solange zu dem Kontext gehörende Pakete ankommen. Die Bestimmung, ob ein Paketfluss noch aktiv ist, kann unter Verwendung eines Timers oder ausgehend von der Semantik des Protokolls erfolgen. Bei dieser Lösung werden 2 Bytes Overhead für jede komprimierte Nachricht erzeugt.
Bei dieser ersten Lösung beinhaltet die Kompression die folgenden Schritte:

1. Die Nachricht an das Wörterbuch anhängen und die erweiterte Datei mit Hilfe von LZSS komprimieren.
2. Den Teil der komprimierten Datei, welcher dem Wörterbuch entspricht, von dem Teil trennen, welcher der Nachricht entspricht. Dies ist möglich, da LZSS die Datei von links nach rechts verarbeitet und der Teil, welcher bereits komprimiert worden ist, sich nicht ändert, wenn mit der Kompression fortgefahren wird. Das heißt, das Komprimieren des Wörterbuches selbst liefert denselben Ausgang wie das Komprimieren desselben mit einer daran angehängten Nachricht (abgesehen von der komprimierten Nachricht).

Bei dieser ersten Lösung beinhaltet die Dekompression die folgenden Schritte:

1. Die komprimierte Nachricht an das komprimierte Wörterbuch anhängen und die erweiterte Datei dekomprimieren.
2. Die Nachricht von dem Wörterbuch trennen. Dies ist möglich, weil die Grenze des Wörterbuches bekannt ist und die Nachricht an das Wörterbuch angehängt ist.

Die Leistungsfähigkeit dieser ersten Lösung ist folgende. Der Kompressionsfaktor der ersten Nachricht ist 1,5, und die Kompressionsfaktoren der nachfolgenden Nachrichten betragen zwischen 3,1 und 8,3, in Abhängigkeit vom Operationsmodus des Kompressors und des Dekompressors. In einem Modus mit begrenztem Kontakt kann der Dekompressor Nachrichten vom Kompressor quittieren, so dass der Kompressor sicherstellen kann, dass der Dekompressor dasselbe Wörterbuch hat wie der Kompressor. In einem Modus mit vollständigem Kontakt sind der Kompressor und der Dekompressor eine Entität und nutzen das Wörterbuch gemeinsam, so dass sowohl gesendete als auch empfangene Nachrichten für den Kompressionsprozess verwendet werden können.
Bei einer zweiten Lösung wird als Kompressionsalgorithmus LZJH (Lempel-Ziv-Jeff-Heath) verwendet. Bei dieser zweiten Lösung werden ein im Voraus geladenes Wörterbuch und ein Mehrpaket-Modus verwendet, wobei das Wörterbuch unter Verwendung vorhergehender Nachrichten und anschließender Verwendung des LZJH Kompressionsalgorithmus aktualisiert wird. Diese zweite Lösung kann die erste Nachricht um einen Faktor von 2,8 reduzieren.
Insgesamt beträgt, wenn SIP-Nachrichten einzeln unter Verwendung eines Algorithmus vom Lempel-Ziv-Typ komprimiert werden, der Kompressionsfaktor rund 1,5. Mit einem im Voraus geladenen statischen Wörterbuch liefern die meisten herkömmlichen Kompressionsalgorithmen einen Kompressionsfaktor von weniger als 3 für SIP-Nachrichten. Wenn ein Codebuch mittels der ersten INVITE-Nach richt belegt wird, verbessern Algorithmen vom Lempel-Ziv-Typ den Kompressionsfaktor auf Werte nahe bei 5.
Somit wird eine bessere Lösung benötigt, um Signalisierungsverzögerung und benötigte Bandbreite weiter zu verbessern, wenn sowohl Bandbreitenanforderungen des Systems als auch Dienstaufbauzeiten berücksichtigt werden.
Liefke H. et al.: "XMILL: an Efficient Compressor for XML Data", SIGMOD Record, Association for Computing Machinery, New York, USA, Bd. 29, Nr. 2, Juni 2000 (2000-06), Seiten 153-164, XP001002286 hat die Anwendung von Kompression für Daten vom XML-Typ und für spezielle Datentypen, die in einem binären Format codiert sind, zum Gegenstand, einschließlich eines Wörterbuch-Codierprozesses. In diesem Artikel wird auf Tags Bezug genommen, die in XML verwendet werden. Tags werden in XML verwendet, um die Struktur von Daten innerhalb eines Dokuments zu definieren, und XML-Dokumente bestehen aus Tags, Attributen und Datenwerten. Der Kompressionsalgorithmus, der durch diesen Artikel beschrieben wird, wird XMill genannt und basiert auf dem Komprimieren von XML-Dokumenten. Dieser Prozess beinhaltet eine XML-Datei, die aus Tags und Attributen besteht, die einer Wörterbuch-Codierung zu unterziehen sind (denen ein ganzzahliger Wert zuzuweisen ist), und End-Tags werden durch ein Token (/) ersetzt. Die Tags werden wörterbuch-codiert, während den Datenwerten Container zugewiesen werden, die alle als ganze Zahlen codiert werden.
Jian Jun Wu et al.: "Lightweight SIP/SDP Compression Scheme (LSSCS)", Proceedings of the SPIE, SPIE, Bellingham, VA, USA, Bd. 4586, 12. November 2001 (2001-11-12), Seiten 67-76, XP008005555 hat die Anwendung eines Leichten SIP/SDP Kompressionsschemas (LSSCS) zum Gegenstand. Dieser Kompressionsalgorithmus wird auf der Anwendungsschicht durchgeführt, indem er auf die SIP/SDP Datennachrichten einwirkt, indem er redundante Informationen durch Verwendung von im Voraus gecacheten Daten, die zuvor gespeichert oder in einer früheren SIP-Nachricht gesendet wurden, entfernt. Der LSSCS Prozess kann über Luftschnittstellen (RF) angewendet werden.
Bei der unter der Bezeichnung SCRIBE bekannten Skalierbaren, Robusten Effizienten wörterbuchbasierten Kompression (Scalable, Robust Efficient Dictionary-based Compression), welche von Liu Z. et al. in einer Network Working Group Internet Draft, 18. Juli 2001, XP-002274129 (http://www.watersprings.org/pub/id/draftliu-rohc-scribe-01.txt) beschrieben wird, enthält ein dreiteiliges Wörterbuch einen statischen Teil, einen profilspezifischen Teil und einen dynamischen Teil. Beim Komprimieren oder Dekomprimieren einer Nachricht benutzt das Kompressions-/Dekompressionsschema das dreiteilige Wörterbuch, um unnötige Textstrings aus einer Nachricht zu entfernen bzw. entfernte Textstrings in eine Nachricht einzufügen.
KURZDARSTELLUNG DER ERFINDUNG
Ein Verfahren gemäß der Erfindung ist so beschaffen, wie in Anspruch 1 dargelegt. Bevorzugte Ausführungsformen sind in den abhängigen Ansprüchen dargelegt.
Die vorliegende Erfindung hat eine Nachrichtenkompression zum Gegenstand, welche die Dauer des Verbindungsaufbaus durch Anwendung von Mehrpaket-Kompressionsalgorithmen zum Komprimieren der Nachrichten verkürzt.
Die vorliegende Erfindung hat außerdem ein Verfahren, eine Vorrichtung, ein System und Software zum Durchführen der Kompression von Protokollnachrichten in einem drahtlosen Kommunikationssystem zum Gegenstand. Bei der vorliegenden Erfindung wird ein Kompressionsalgorithmus benutzt, welcher binäre Codierung, Schablonen, sitzungsspezifische Codebücher und/oder herkömmliche Lempel-Ziv-basierte Algorithmen kombiniert. Bei der vorliegenden Erfindung werden außerdem eine Nachrichtenkennung und die binäre Codierung bestimmter Felder wie etwa einer Adresse des Diensteanbieters, einer Benutzerkennung des rufenden Teilnehmers, eines Benutzernamens des rufenden Teilnehmers, einer Benutzerkennung des gerufenen Teilnehmers und eines Benutzernamens des gerufenen Teilnehmers benutzt, und es wird das IPv4 Format für Domainnamen verwendet. Die vorliegende Erfindung ermöglicht außerdem das binäre Codieren numerischer Werte für bestimmte Felder. Durch die vorliegende Erfindung werden außerdem ein sitzungsspezifisches Codebuch, ein modifizierter Indizierungsmechanismus, Codebuchmanagement und Session History (Sitzungsvorgeschichte) bereitgestellt. Ferner werden durch die vorliegende Erfindung eine flexible Schablone mit Unterfeldern mit fester und variabler Länge sowie eine flexible Schablone mit optionalen Feldern bereitgestellt. Ferner wird durch die vorliegende Erfindung universelle verlustfreie Textkompression bereitgestellt. Bei einer beispielhaften Ausführungsform wird durch die vorliegende Erfindung eine bessere Kompression durch die Verwendung eines sitzungsspezifischen Codebuches und eines optionalen Wörterbuches am SIP-Server/Media Duplicator erzielt. Die binäre Codierung numerischer Felder trägt außerdem dazu bei, die Größe von IP-Adressen, Kennungen rufender Teilnehmer, Sitzungskennungen usw. zu reduzieren. Die vorliegende Erfindung beinhaltet außerdem eine flexible Schablonenstruktur und ermöglicht die Verwendung fester Längen für ausgewählte Schablonenfelder und codiert ein Feld mit variabler Länge entweder mit Längenindikatoren oder mit Begrenzern. Die vorliegende Erfindung ermöglicht außerdem, optionale Felder in Schablonen einzufügen, um die Gesamtanzahl der Schablonen, die in einem Speicher gespeichert werden müssen, zu verringern.
In einer beispielhaften Ausführungsform hat die vorliegende Erfindung ein Verfahren zum Komprimieren einer Textnachricht für eine Übertragung zum Gegenstand, welches das Parsing von Textstrings und das Codieren numerischer Werte mit der binären Darstellung und das Analysieren der Werte des Textstrings und das Belegen eines sitzungsspezifischen Codebuches mit Teilstrings aus den Werten umfasst. Bei einer anderen beispielhaften Ausführungsform hat die vorliegende Erfindung ein Verfahren zum Komprimieren einer Nachricht für eine Übertragung zum Gegenstand, welches umfasst: Parsing der Nachricht mit einer Schablone und Erzeugen mindestens eines Teilstrings, der zu übertragen ist; Parsing des mindestens einen Teilstrings mit Einträgen in einem sitzungssspezifischen Codebuch und Erzeugen eines ersten Teils der komprimierten Nachricht; Belegen des sitzungssspezifischen Codebuches mit Einträgen für unbekannte Feldwerte; Parsing eventueller Teilstrings ohne Match (Übereinstimmung) mit Einträgen aus einem ersten statischen Wörterbuch und Erzeugen eines zweiten Teils der komprimierten Nachricht; Parsing eventueller Teilstrings, die noch immer ohne Match sind, mit Einträgen aus einem zweiten statischen Wörterbuch und Erzeugen eines dritten Teils der komprimierten Nachricht; Komprimieren eines Restes der Teilstrings mit einem Kompressionsalgorithmus; und Kombinieren des ersten Teils, des zweiten Teils und des dritten Teils der komprimierten Nachricht, um eine komprimierte Nachricht zur Übertragung zu erhalten.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Weitere Aspekte und Vorteile der vorliegenden Erfindung können beim Studium der nachfolgenden ausführlichen Beschreibung und unter Bezugnahme auf die Zeichnungen ersichtlich werden, wobei:
1 ein allgemeines Blockschaltbild einer herkömmlichen Netzarchitektur zeigt;
2 Verzögerungen der SIP-Signalisierung zeigt, wenn angenommen wird, dass die Verbindungsgeschwindigkeit 9600 bps und die Umlaufzeit 140 ms beträgt;
3 eine beispielhafte Architektur zum Durchführen einer Kompression bei einer beispielhaften Ausführungsform der vorliegenden Erfindung zeigt;
4 einen beispielhaften Rahmen für die Nachrichtenkompression bei einer beispielhaften Ausführungsform der vorliegenden Erfindung zeigt;
5 eine schablonenbasierte Codierung bei einer beispielhaften Ausführungsform der vorliegenden Erfindung zeigt;
6 ein Beispiel des Herstellens einer Verbindung durch einen Benutzer A zu einem Benutzer B bei einer beispielhaften Ausführungsform der vorliegenden Erfindung zeigt;
7 die Ergebnisse der Kompression zeigt, die bei einer beispielhaften Ausführungsform der vorliegenden Erfindung erzielt wurden.
AUSFÜHRLICHE BESCHREIBUNG
3 zeigt die Umgebung, in welcher die Kompression/Dekompression von SIP-Nachrichten der vorliegenden Erfindung durchgeführt werden kann. Wie in 3 dargestellt, sind zwei Entitäten 10, 12 durch einen physikalischen Kanal 14 getrennt. Jede Entität 10, 12 enthält eine physikalische Schicht 16, eine IP-Schicht 18, eine UDP/TCP-Schicht 20, die Kompressions-/Dekompressionsschicht 22 der vorliegenden Erfindung und eine SIP-Schicht 24.
4 zeigt einen Rahmen für die Nachrichtenkompres sion bei einer beispielhaften Ausführungsform der vorliegenden Erfindung. Innerhalb der Kompressions-/Dekompressionsschicht 22 umfassen die Entitäten 10 und 12 einen Kompressor 100, ein Codebuch 102 und einen Dekompressor 104, durch welche ursprüngliche Nachrichten 106, komprimierte Nachrichten 108 und dekomprimierte Nachrichten 110 geleitet werden.
Wie in 2 dargestellt, dient der Kompressionsmechanismus der vorliegenden Erfindung als die Schicht 22 zwischen den SIP-Anwendungen 24 und dem UDP und/oder TCP 20. Der Zweck der Kompression ist es, die Gesamtmenge der über den physikalischen Kanal 14 übertragenen Daten zu verringern und somit die Verzögerung zu verringern.
Kompressionsalgorithmen funktionieren gut mit Apriori-Informationen über die ursprüngliche Nachricht. SIP-Nachrichten innerhalb einer Sitzung nutzen viele gemeinsame Informationen, wie etwa die Benutzeradressen und Portnummern.
SIP-Nachrichten weisen viele sich wiederholende Header auf, welche leicht komprimiert werden können. Kompressionsalgorithmen können entweder mit im Voraus geladenen Wörterbüchern oder mit dynamischen Wörterbüchern oder mit Schablonen arbeiten. Ein beispielhaftes statisches Wörterbuch für SIP-Nachrichten ist nachfolgend dargestellt.
In dem beispielhaften statischen Wörterbuch: sind erforderliche Zwischenräume mit <sp> bezeichnet, sind erforderliche Wagenrückläufe mit <cr> bezeichnet, sind erforderliche Zeilenvorschübe mit <lf> bezeichnet. Alle anderen möglichen Zwischenräume, Wagenrückläufe, Zeilenvorschübe usw. sind zu ignorieren, wenn dieses beispielhafte statische Wörterbuch verwendet wird.
Eine Schablone ist eine Tabelle von geordneten Strings. Im Unterschied zu Wörterbüchern müssen keine festen Header-Informationen übertragen werden, wodurch sich die Nachrichtengröße noch weiter verringert. Für jeden Typ von Nachrichten kann eine Standardschablone definiert werden. Das Folgende ist ein Beispiel einer schablonenbasierten Codierung.
5 ist ein Beispiel einer schablonenbasierten Codierung. Die Schablone weist eine Schablonenkennung (TID), vier statische Felder (ss0, ss2, ss4 und ss6) und drei leere Felder (b1, b3 und b5) auf. Es wird angenommen, dass alle leeren Felder variable Längen haben. Der Einfachheit halber werden die ausfüllenden Teilstrings (ss1, ss3 und ss5) in der Form <Länge, Wert> codiert. Ebenfalls der Einfachheit halber wird angenommen, dass der Wert die nicht komprimierte Form des ursprünglichen Teilstrings ist.
Im Vergleich zu einer wörterbuchbasierten Kompression kann mit einer schablonenbasierten Kompression eine höhere Effizienz der Kompression erzielt werden, da die Positions- und Längeninformationen der statischen Teile bereits in einer Schablone gespeichert worden sind und nicht übertragen werden müssen.
Schablonen können für jeden Typ von Nachrichten definiert werden. Wenn die Anzahl der Schablonen zunimmt, kann der mit den Schablonen zusammenhängende Speicherplatz zu einem Problem werden. Stattdessen kann auch ein zusätzliches Feld in eine Schablone eingefügt werden. Jedem Header kann einer Headerkennung (HID) zugewiesen werden. Dann kann das zusätzliche Feld in den komprimierten String als <HID|Lx|ssx> an der gewünschten Position eingefügt werden.
Wie in früheren Untersuchungen gezeigt wurde, ist der Kompressionsfaktor der ersten INVITE-Nachricht selbst bei einer schablonenbasierten Herangehensweise nicht signifikant. Da Kenntnisse über den Inhalt von SIP/SDP-Feldern vorhanden sind, ist es möglich, die Leistungsfähigkeit der Kompression gegenüber allgemeinen Kompressionsalgorithmen wie etwa Kompressionsalgorithmen vom Lempel-Ziv-Typ zu verbessern.
Für bestimmte ausgewählte Werte von SIP-Feldern kann ein optionales statisches Wörterbuch verwendet werden. Dieses Wörterbuch könnte typische SDP-Werte enthalten, wie etwa "IN IP4" für die Felder <Netztyp><Adresstyp> einer typischen Internetsitzung. Die meisten UIDs (Benutzerkennungen) können durch 4 Bytes dargestellt werden. Ein Diensteanbieter hat normalerweise weniger als 256 Millionen Teilnehmer, daher können die 4 signifikantesten Bits verwendet werden, um eine Dienstean bieterkennung darzustellen, und die restlichen Bits, um einen Benutzernamen darzustellen. Wenn in einem Feld ein numerischer Wert erwartet wird, kann eine binäre Darstellung verwendet werden.
Das Kompressionsverfahren kann bei einer beispielhaften Ausführungsform der vorliegenden Erfindung wie folgt zusammengefasst werden:

1) Die Nachricht mit einer übereinstimmenden Schablone parsen und die Teilstrings erzeugen, welche übertragen werden müssen.
2) Die Teilstrings mit einem sitzungsspezifischen Codebuch parsen (als leer initialisiert) und einen Teil der komprimierten Nachricht erzeugen.
3) Das sitzungsspezifische Codebuch mit unbekannten Feldwerten belegen.
4) Die Teilstrings ohne Match mit einem statischen Wörterbuch parsen und einen Teil der komprimierten Nachricht erzeugen.
5) Die Teilstrings ohne Match mit dem optionalen statischen Wörterbuch parsen und einen Teil der komprimierten Nachricht ausgeben.
6) Den Rest der Teilstrings mit LZSS parsen.
7) Die Ausgänge der Schritte 2) und 4)–6) zu der endgültigen komprimierten Nachricht kombinieren.

Es ist anzumerken, dass manchen Teilstrings in einer Schablone eine Standardlänge nach der Kompression zugewiesen werden kann, was eine Reduzierung um ein Byte für jedes Feld bewirkt. Es kann ein vordefiniertes Escape-Zeichen verwendet werden, um die Längenänderung zu markieren.
Der oben umrissene beispielhafte Kompressionsalgorithmus wird weiter unten auf verschiedene Beispiele angewendet, in denen eine erfolgreiche einfache SIP-zu-SIP-Verbindung aufgebaut wird, wie in 6 dargestellt.
Beispiel 1 – Details der Nachricht
Bei Anwendung von Schritt 1 wird die Nachricht einem Parsing mit einer übereinstimmenden Schablone unterzogen, und es werden die Teilstrings erzeugt, welche übertragen werden müssen. In Beispiel 1 lautet das Ergebnis von Schritt 1 wie folgt:
Wenn man die Kommentare entfernt, sind die resultierenden Teilstrings folgende:
Bei Anwendung von Schritt 2 werden die Teilstrings einem Parsing mit einem sitzungsspezifischen Codebuch (als leer initialisiert) unterzogen, um einen Teil der komprimierten Nachricht zu erzeugen. Da das sitzungsspezifische Codebuch leer ist, wird kein Ausgang erzeugt.
Bei Anwendung von Schritt 3 wird das sitzungsspezifische Codebuch mit unbekannten Feldwerten belegt. Das resultierende sitzungsspezifische Codebuch wird für die Kompression nachfolgender Nachrichten verwendet. In Beispiel 1 hat das resultierende sitzungsspezifische Codebuch die in Tabelle 1 dargestellte Form.
Tabelle 1
Zu Tabelle 1 ist anzumerken, dass jeder Header nicht auf einen einzigen Eintrag beschränkt ist. Ferner werden nicht alle unbekannten Felder verwendet, um das Codebuch zu belegen, da einige sich möglicherweise nicht wiederholen, wie etwa die Ankündigungsnummer in SDP. Das sitzungsspezifische Codebuch kann dann verwendet werden, um nachfolgende Nachrichten derselben Sitzung zu komprimieren/dekomprimieren. Es ist anzumerken, dass ein Codebuchmanagement hilfreich sein kann. Zum Beispiel wird, wenn ein Match (Übereinstimmung) mit dem Eintrag gefunden wird, ein Byte verwendet, um den Header im Sitzungsprofil anzugeben, und ein anderes Byte wird verwendet, um zu spezifizieren, für welchen Eintrag für den Header ein Match gefunden wurde.
Bei Anwendung von Schritt 4 werden die Teilstrings ohne Match einem Parsing mit einem standardmäßigen statischen Wörterbuch wie etwa dem oben angegebenen unterzogen, und es wird ein Teil der komprimierten Nachricht erzeugt. In Beispiel 1 wird, da alle Header und viele konstante Werte in der Schablone enthalten sind, kein zusätzlicher Ausgang durch Parsing mit dem standardmä ßigen statischen Wörterbuch erzeugt.
Bei Anwendung von Schritt 5 werden Teilstrings ohne Match einem Parsing mit dem statischen Wörterbuch unterzogen, und es wird ein Teil der komprimierten Nachricht ausgegeben.
Tabelle 2
In Beispiel 1 ist das Ergebnis von Schritt 5 37 oder 32 Bytes.
Es ist anzumerken, dass alle Domainnamen in dem optionalen statischen Wörterbuch bei allen SIP-Entitäten gespeichert werden können. In Beispiel 1 wird 1 Byte für jeden Domainnamen zugewiesen. Gleichzeitig kann eine Benutzeradresse von 4 Byte der sendenden SIP-Entität zugewiesen werden, wenn das Gerät initialisiert wird.
Bei Anwendung von Schritt 6 wird der Rest der Teilstrings mit einem beispielhaften Kompressionsalgorithmus wie etwa LZSS komprimiert.
Die TID kann mit 1 Byte dargestellt werden. Die Benutzerkennung (der String vor '@' in der Benutzeradresse) ist 5 Bytes lang, und der Benutzername (LittleGuy) ist 10 Bytes lang. In Beispiel 1 werden nach Kompression mit LZSS maximal 16 Bytes erzeugt.
Bei Anwendung von Schritt 7 werden die Ausgänge der Schritte 2 und 4–6 zu der endgültigen komprimierten Nachricht kombiniert. Dies ergibt 37 oder 32 Bytes, plus die 16, die nach Kompression mit LZSS erzeugt wurden. 37 + 16 = 53 Bytes, oder 32 + 16 = 48 Bytes,was einem Kompressionsfaktor von
423/53 = 8,0; 423/48 = 8.8
entspricht.
Die folgenden Beispiele beschreiben die Schritte für nachfolgende Nachrichten. Beispiel 2 – Details der Nachricht
Nach dem Decodieren der Nachricht F1 aus Beispiel 1 hat Benutzer B das Codebuch mit dem Inhalt der INVITE-Nachricht belegt.
Bei Anwendung von Schritt 1 auf Beispiel 2 werden die folgenden Teilstrings erzeugt:
Bei Anwendung von Schritt 2 auf Beispiel 2 werden die Teilstrings einem Parsing mit einem sitzungsspezifischen Codebuch unterzogen, wie in Tabelle 3 dargestellt.
Tabelle 3
Es wird eine Teilsumme von 8 Bytes erhalten.
Wenn angenommen wird, dass der Algorithmus in einem Modus mit vollständigen Kontakt ausgeführt wird, bei dem der Kompressor und der Dekompressor das Codebuch 102 gemeinsam nutzen, kann, nachdem UserA die kompri mierte INVITE-Nachricht sendet, der Dekompressor 104 bei UserA auch auf das sitzungsspezifische Codebuch zugreifen. Wenn die INVITE-Nachricht von UserB empfangen wird, belegt sie dessen sitzungsspezifisches Codebuch, welches dann identisch mit dem bei UserA ist. Daher kann, wenn die Nachricht (100 trying) komprimiert und dekomprimiert wird, das sitzungsspezifische Codebuch verwendet werden.
Bei Anwendung von Schritt 3 wird das sitzungsspezifische Codebuch belegt. In diesem Beispiel sind keine neuen Strings vorhanden.
Bei Anwendung von Schritt 4 entdeckt das standardmäßige statische Wörterbuch keine Matches, was eine zweite Teilsumme von 0 Bytes ergibt.
Bei Anwendung von Schritt 5 wird ein Parsing mit dem optionalen statischen Wörterbuch durchgeführt, das Tabelle 4 liefert, was eine dritte Teilsumme von 3 Bytes ergibt.
Tabelle 4
Bei Anwendung von Schritt 6 wird der Rest der Teilstrings mit LZSS oder einem anderen beispielhaften Kompressionsalgorithmus komprimiert.
TID ist ein Schablonenindex von einem Byte, was eine vierte Teilsumme von 1 Byte ergibt.
Bei Anwendung von Schritt 7 werden die Ausgänge kombiniert, was 8 + 0 + 3 + 1 = 12 Bytesergibt, was einem Kompressionsfaktor von 187/12 = 15,6 entspricht.
Beispiel 3 – Details der Nachricht
Bei Anwendung derselben Vorgehensweise wie oben für Beispiel 2 umfasst die resultierende Nachricht 12 Bytes, und der Kompressionsfaktor beträgt 187/12 = 15,6.
Beispiel 4 – Details der Nachricht
Bei Anwendung von Schritt 1 auf Beispiel 4 werden die folgenden Teilstrings erzeugt:
Bei Anwendung von Schritt 2 auf Beispiel 4 werden die Teilstrings einem Parsing mit dem sitzungsspezifischen Codebuch unterzogen, das in Tabelle 5 dargestellt ist, was eine erste Teilsumme von 16 Bytes ergibt:

Tabelle 5
Bei Anwendung von Schritt 3 auf Beispiel 4 wird das sitzungsspezifische Codebuch wie in Tabelle 6 angegeben belegt:
Tabelle 6
Bei Anwendung von Schritt 4 auf Beispiel 4 wird in dem statischen Wörterbuch kein Match gefunden, was eine zweite Teilsumme von 0 Bytes ergibt.
Bei Anwendung von Schritt 5 auf Beispiel 4 werden mehrere Matches entdeckt, wie unten in Tabelle 7 angegeben, was eine dritte Teilsumme von 14 Bytes ergibt.
Tabelle 7
Bei Anwendung von Schritt 6 auf Beispiel 4 wird der Rest des Teilstrings, ein Schablonenindex von einem Byte für die TID, mit LZSS komprimiert, was eine weitere Teilsumme von 1 Byte ergibt.
Das Kombinieren der Ausgänge für Beispiel 4 ergibt 16 + 14 + 1 = 31 Bytes, was einem Kompressionsfaktor von 403/31 = 13 entspricht. Beispiel 5 – Details der Nachricht
Bei Anwendung derselben Vorgehensweise wie oben für Beispiel 2 umfasst die resultierende Nachricht 12 Bytes, und der Kompressionsfaktor beträgt 197/12 = 16,4. Beispiel 6 – Details der Nachricht
Bei Anwendung von Schritt 1 auf Beispiel 6 werden die folgenden Teilstrings erzeugt:
Bei Anwendung von Schritt 2 auf Beispiel 6 werden die Teilstrings einem Parsing mit dem sitzungsspezifischen Codebuch unterzogen, das in Tabelle 8 dargestellt ist, was eine erste Teilsumme von 10 Bytes ergibt.
Tabelle 8
Bei Anwendung von Schritt 3 auf Beispiel 6 wird das sitzungsspezifische Codebuch wie in Tabelle 9 angegeben belegt.
Tabelle 9
Bei Anwendung von Schritt 4 auf Beispiel 6 werden in dem standardmäßigen statischen Wörterbuch keine Matches gefunden, was eine zweite Teilsumme von 0 Bytes ergibt. Bei Anwendung von Schritt 5 auf Beispiel 6 wird ein Parsing mit dem optionalen statischen Wörterbuch durch geführt, das Tabelle 10 liefert, was eine dritte Teilsumme von 4 Bytes ergibt.
Tabelle 10
Bei Anwendung von Schritt 6 auf Beispiel 6 wird der Rest der Teilstrings, ein Schablonenindex von einem Byte für die TID, mit LZSS komprimiert, was eine weitere Teilsumme von 1 Byte ergibt.
Das Kombinieren der Ausgänge für Beispiel 6 ergibt 10 + 4 + 1 = 15 Bytes, was einem Kompressionsfaktor von 197/15 = 13,1 entspricht.
Beispiel 7 – Details der Nachricht
Bei Anwendung derselben Vorgehensweise wie oben für Beispiel 2 umfasst die resultierende Nachricht 12 Bytes, und der Kompressionsfaktor beträgt 181/12 = 15,1.
7 zeigt die mit dem Verfahren der vorliegenden Erfindung erzielten Kompressionsfaktoren für andere Nachrichten.
Kurz zusammengefasst, wird bei früheren Untersuchungen, bei denen sitzungsspezifische Codebücher verwendet werden, das Codebuch mit den Feldern in den Nachrichten so, wie sie sind, belegt und mit dem Feld "From" ("Von") indexiert. Bei beispielhaften Ausführungsformen der vorliegenden Erfindung werden die Feldwerte zusätzlich zu dem gesamten Feld analysiert, und es werden Schlüsselwörter extrahiert. Infolgedessen erzeugt das Codebuch der vorliegenden Erfindung mehr Matches bei einer nur mäßigen Erhöhung des Speicherplatzbedarfes.
Ferner wurde bei früheren Untersuchungen ein direktes Nachschlagen der Benutzeradressen in einer Tabelle wegen des hohen Speicherplatzbedarfes und der langen Suchzeit vermieden. Ferner wird eine Nachschlagtabelle für Domainnamen in dem optionalen statischen Wörterbuch bei allen SIP-Entitäten gespeichert. Da die Anzahl der Diensteanbieter, welche einen Push-to-Talk-Dienst zur Verfügung stellen, sehr begrenzt ist, kann 1 Byte für jeden Domainnamen zugewiesen werden.
Bei einem Push-to-Talk-Dienst befindet sich der SIP-Server/Proxy-Server/Umleitungsserver auf der Netzseite, wobei angenommen wird, dass er ausreichend leistungsstark ist, um eine vollständige Benutzeradressensuche durchzuführen. Somit wird jeder Benutzeradresse eine binäre Kennung mit 4 Bytes zugewiesen. Diese 4-Byte-Kennung wird auch jeder SIP-Entität zugewiesen, wenn das Gerät initialisiert wird. Folglich kann ein mobiles Gerät in der INVITE-Nachricht einfach seine Adresse durch diese 4-Byte-Kennung ersetzen.
Ferner ist, obwohl die vorliegende Erfindung in Verbindung mit Kompression beschrieben wurde, für einen Durchschnittsfachmann leicht einzusehen, dass die Schritte bei der Dekompression umgekehrt zu den oben beschriebenen Schritten bei der Kompression auszuführen sind.
Die vorliegende Erfindung könnte außerdem ein sitzungsübergreifendes Wörterbuch-Merkmal implementieren. Wenn ein Gerät so programmiert ist, dass es die jüngere Vorgeschichte der Benutzeradressen speichert, ist eine weitere Reduzierung der INVITE-Nachricht für spätere Sitzungen zu erwarten. Außerdem können für jene Benutzer, welche Gruppendienste kaufen, Diensteanbieter eine kleine Nachschlagtabelle zur Verfügung stellen, welche eine Benutzeradresse auf eine binäre Kennung mit 4 Bytes abbildet. Bei dieser Vorgehensweise kann eine Kompression der Benutzeradresse (unter Verwendung der binären Kennung mit 4 Bytes) sogar für die erste INVITE-Nachricht erfolgen.
Bei der vorliegenden Erfindung wird ein Kompressionsalgorithmus benutzt, welcher binäre Codierung, Schablonen, ein sitzungsspezifisches Codebuch und/oder herkömmliche Lempel-Ziv-Algorithmen kombiniert. Die resultierenden komprimierten SIP-Nachrichten besitzen ungefähr 1/10 der Größe der ursprünglichen Nachrichten.
Wie oben dargelegt wurde, ist dieser Gewinn ein Ergebnis eines oder mehrerer der oben beschriebenen Merkmale der vorliegenden Erfindung. Diese Merkmale beinhalten die Verwendung einer Nachrichtenkennung, die binäre Codierung selektiver Felder wie etwa der Adresse des Diensteanbieters, der Benutzerkennung des rufenden Teilnehmers, des Benutzernamens des rufenden Teilnehmers, der Benutzerkennung des gerufenen Teilnehmers und des Benutzernamens des gerufenen Teilnehmers sowie ein IPv4-Format für Domainnamen. Diese Merkmale beinhalten außerdem die binäre Codierung ausgewählter numerischer Werte, die Verwendung eines sitzungsspezifischen Codebuches und einen modifizierten Indexierungsmechanismus. Ferner gehören zu diesen Merkmalen ein Codebuchmanagement und eine Sitzungsvorgeschichte. Ferner gehören zu diesen Merkmalen eine flexible Schablone mit Feldern mit fester und variabler Länge sowie eine flexible Schablone mit optionalen Feldern. Eine oder mehrere Kombinationen der obigen Merkmale ermöglichen es, eine universelle verlustfreie Textkompression sicherzustellen.
Ferner enthält, wie oben beschrieben, jede SIP-Entität sowohl einen Kompressor 100 als auch einen Dekompressor 104. Daher könnten Informationen von dem Kompressor 100 und dem Dekompressor 104 gemeinsam genutzt werden, um die Nachrichtengrößen weiter zu reduzieren.
Obwohl die oben angegebenen Beispiele in Verbindung mit SIP-Protokoll-Nachrichten beschrieben wurden, sind diese Beispiele ebenso für SDP, RTSP oder ein beliebiges anderes bekanntes oder später entwickeltes Protokoll anwendbar.
Ferner sind, obwohl die Merkmale der vorliegenden Verbindung in Verbindung mit einem Verfahren beschrieben wurden, diese Merkmale auch auf eine Vorrichtung, ein System und Softwareanwendungen anwendbar, und die Umsetzung der Lehren der vorliegenden Patentanmeldung in einer Vorrichtung, einem System oder Software könnte durch einen Durchschnittsfachmann realisiert werden.

Claims

Verfahren zum Komprimieren einer Textnachricht, wobei das Verfahren umfasst: Parsing der Textnachricht mit einer Schablone, um mindestens einen Teilstring zu erzeugen, der zu übertragen ist; Parsing des mindestens einen Teilstrings mit einem sitzungsspezifischen Codebuch, um einen ersten Teil einer komprimierten Nachricht zu erzeugen; Belegen des sitzungsspezifischen Codebuches mit unbekannten Feldwerten, falls der mindestens eine Teilstring nach Parsing des mindestens einen Teilstrings mit dem sitzungsspezifischen Codebuch ohne Match ist; Parsing des mindestens einen Teilstrings mit einem ersten statischen Wörterbuch, um einen zweiten Teil der komprimierten Nachricht zu erzeugen, falls der mindestens eine Teilstring nach Parsing des mindestens einen Teilstrings mit dem sitzungsspezifischen Codebuch ohne Match ist; Parsing des mindestens einen Teilstrings mit einem zweiten statischen Wörterbuch, um einen dritten Teil der komprimierten Nachricht zu erzeugen, falls der mindestens eine Teilstring nach Parsing des mindestens einen Teilstrings mit einem ersten statischen Wörterbuch noch immer ohne Match ist; Komprimieren eines Restes der Teilstrings mit einem Kompressionsalgorithmus; und Kombinieren des ersten Teils, des zweiten Teils und des dritten Teils der komprimierten Nachricht, um eine komprimierte Nachricht zur Übertragung zu erhalten.
Verfahren zum Komprimieren einer Textnachricht nach Anspruch 1, wobei für jeden Typ von Nachricht eine andere Schablone zur Verfügung gestellt wird.
Verfahren zum Komprimieren einer Textnachricht nach Anspruch 1, wobei das sitzungsspezifische Codebuch für die erste komprimierte Nachricht leer ist und Einträge hinzugefügt werden, wenn die einzelnen Nachrichten komprimiert werden.
Verfahren zum Komprimieren einer Textnachricht nach Anspruch 1, wobei die komprimierte Nachricht zur Übertragung eine Session Initiation Protocol "SIP", Session Description Protocol "SDP" oder Realtime Streamlining Protocol "RTSP" Nachricht "RTSP" ist.
Verfahren nach Anspruch 1, wobei mindestens jeweils ein Eintrag in dem ersten und dem zweiten statischen Wörterbuch binär codiert ist.
Verfahren nach Anspruch 1, wobei der Kompressionsalgorithmus ein Kompressionsalgorithmus vom Lempel-Ziv-Typ ist.