-
TECHNISCHES GEBIET
-
Die
vorliegende Erfindung betrifft Paket-gestützte Kommunikationssysteme
und insbesondere ein Verfahren und eine Einrichtung für eine Header-Kompression.
-
HINTERGRUND
-
Wegen
des unglaublichen Erfolgs des Internets ist es eine herausfordernde
Aufgabe geworden das Internet Protokoll (IP) über alle Arten von Strecken
zu verwenden. Jedoch ist dies besonders schwierig für schmalbandige
Strecken, wie zellulare Strecken, da die Kopfteile (Header) der
IP Protokoll Pakete im Allgemeinen im Vergleich mit den Daten (Nutzlast)
relativ groß sind.
Wenn gewöhnliche Sprachdaten
durch die Protokolle transportiert werden, die für Voice-over-IP (VoIP) verwendet
werden, stellt beispielsweise der Header oft soviel wie 70% des
Pakets dar, was zu einer stark ineffizienten Verwendung der Strecke
führt.
-
Eine
Header-Kompression bezieht sich auf Techniken zum Minimieren der
erforderlichen Bandbreite für
Information, die in Header geführt
wird, auf einer Einzelsprung-Basis über Punkt-zu-Punkt Strecken.
Es gibt mehrere Header-Kompressionsprotokolle, einschließlich RFC
1144[1], RFC 24507[2] und RFC 2508[3]. Die Prinzipien einer Header-Kompression
nutzen die Tatsache aus, dass sich einige Header Felder innerhalb
eines Flusses nicht ändern
oder sich alternativ mit kleinen oder vorhersagbaren Werten ändern. Diese
Charakteristiken werden von den Header-Kompressionsverfahren verwendet,
die statische Information nur anfänglich senden, während sich ändernde
Felder mit ihren absoluten Werten oder als Differenzen von Paket
zu Paket gesendet werden. Vollständig
zufällige
Information muss ohne irgendeine Kompression gesendet werden.
-
Eine
Header-Kompression ist eine wichtige Komponente, um VoIP over Wireless
(VoIPoW) durchzuführen,
eine wirtschaftlich denkbare Alternative zu leitungsvermittelter
Sprache, und für
diesen Zweck sind Lösungen
für eine
robuste Header-Kompression (Robust Header Compression; ROHC) entwickelt
worden. ROHC, wie in RFC 3095[4] definiert, ist ein erweiterbares
Rahmenwerk, für
das Profile für eine
Kompression von verschiedenen Protokollen definiert werden können. Für VoIP werden
die Anwendungsdaten Ende-zu-Ende innerhalb eines IP/Benutzerdatagram-Protokolls
(IP/User Datagram Protokol; UDP)/Echtzeit-Transportprotokoll (Real-Time
Transport Protocol; RTP) Strom transportiert. Eine Header-Kompression
von IP/UDP/RTP wird durch das ROHC Profil 0x0001 (ROHC RTP) definiert und
ist für
VoIP Dienste unter anderem anwendbar. Das ROHC RTP Header-Kompressionsverfahren
ist entwickelt worden, um Header über eine beliebige Streckenschicht
effizient zu komprimieren. Die meiste Funktionalität wird von
dem ROHC RTP Verfahren selbst behandelt und außer für eine Verhandlung muss nur
eine Rahmenbildung und eine Fehlererfassung durch die Streckenschicht
(Linklayer) bereitgestellt werden.
-
ROHC
weist drei unterschiedliche Betriebsmoden auf, die für einen
spezifischen Kontext die Aktionen und die auszuführende Logik, sowie die zu verwendenden
Pakettypen während
unterschiedlichen Zuständen
des Header-Kompressionsbetriebs steuern. Zugelassene Pakettypen
und Formate verändern
sich von einem Modus zu einem anderen. Der unidrektionale Modus
[U-Mode] wird an dem Beginn von irgendeiner ROHC Kompression verwendet,
bevor ein Übergang
auf einen anderen Modus auftreten kann. Der bidirektionale optimistische
Modus [O-Mode] zielt darauf ab die Kompressionseffizienz zu maximieren und
ist mit einer dünnen
Verwendung des Rückkopplungskanals
assoziiert. Der bidirektionale zuverlässige Modus welche [R-Modus]
zielt darauf ab eine Robustheit gegenüber einer Ausbreitung von Verlusten
und einer Kontextbeschädigung
zu maximieren.
-
Wenn
sie in einem U-Modus sind, werden Pakete von dem Kompressor nur
an den Dekompressor gesendet; dieser Modus ist somit über Strecken verwendbar,
bei denen ein Rückkehrpfad
von dem Dekompressor zu dem Kompressor entweder nicht gewünscht oder
nicht verfügbar
ist, und periodische Aktualisierungen werden in diesem Modus verwendet.
Der O-Modus ist ähnlich
zu dem U-Modus mit dem Unterschied, dass ein Rückkopplungskanal verwendet
wird, um Fehlerrückgewinnungsaufforderungen
und (optional) Bestätigungen
von signifikanten Kontextaktualisierungen von dem Dekompressor an den
Kompressor zu senden. Der U-Modus und der O-Modus werden gemeinsam
oft als der U/O-Modus bezeichnet, und zwar als Folge der sehr ähnlichen Art
von diesen. Der R-Modus unterscheidet sich signifikant von den zwei
anderen Moden, nämlich
durch eine extensivere Verwendung des Rückkopplungskanals und einer
strikteren Logik zum Ausführen
von Kontextaktualisierungen. Der R-Modus verwendet auch einige wenige unterschiedliche
Pakettypen, die nur in diesem Modus verstanden werden und in diesem
Modus nützlich
sind.
-
Jeder
Betriebsmodus weist unterschiedliche Eigenschaften im Hinblick auf
die Kompressionseffizienz, die Robustheit und die Verarbeitungskomplexität auf. ROHC
spezifiziert nicht, wie und wann die jeweiligen Moden verwendet
werden sollten (mit Ausnahme davon, dass eine ROHC Kompression immer in
einem U-Modus starten muss), wobei die Logik für Modusübergänge eine Aufgabe der Implementierung wird.
Modusübergänge können nur
von dem Dekompressor initiiert werden, und in Übereinstimmung mit der gegenwärtigen Spezifikation
für eine
Robust Header Compression (RFC 3095) muss jede ROHC Implementierung
sämtliche
Betriebsmoden unterstützen.
-
Die
obigen Charakteristiken und Anforderungen für herkömmliche Header-Kompressionsverfahren
stehen in Verbindung mit einer Anzahl von Nachteilen.
-
Header-Kompressions-Verkäufer neigen dazu
deren Kompressorimplementierungen für spezifische Betriebsmoden
zu optimieren, z.B. um die Speicheranforderungen oder die benötigte Verarbeitungsleistung
zu minimieren. Deshalb gibt es keine Garantie, dass eine bestimmte
Implementierung tatsächlich
in ihrem bevorzugten Modus verwendet wird. Anstelle dazu kann sie
in eine suboptimale Operation gezwungen werden, was zu einer verringerten Kompressionseffizienz
und einem verringerten Streckenbetriebsverhalten führt.
-
Ein
anderes Problem ist, dass viel Funktionalität für eine ROHC Implementierung
benötigt
wird, um sämtliche
Kompressionsmoden zu unterstützen. Beträchtliche
Implementierungs-, Validierungs- und Testaktionen müssen ausgeführt werden,
was wiederum relativ lange Implementierungszeiten und hohe Implementierungskosten
impliziert. Sämtliche Moden
sind unter Umständen
in einer spezifischen Umgebung nicht notwendigerweise nützlich.
Um die Programmgröße und/oder
die Zeit zu minimieren, die benötigt
wird, um eine interoperable ROCH Algorithmusimplementierung aufzubauen,
würde es
ferner manchmal wünschenswert
sein nur den Modus (die Moden) zu unterstützen, die konsistent mit der
Entwicklungsstrategie eines bestimmten Implementierers ist (sind).
-
Demzufolge
ist die Header-Kompression von herkömmlichen Telekommunikationssystemen
weit von zufrieden stellend entfernt und es gibt eine starke Notwendigkeit
für ein
verbessertes Header-Kompressionsverfahrens,
insbesondere eines, welche eine Kompressionsmodus-Flexibilität anbietet.
-
Ein
herkömmliches
Verfahren und eine herkömmliche
Vorrichtung für
eine Header-Kompression ist aus der
EP
1180871 bekannt.
-
ZUSAMMENFASSUNG
-
Eine
allgemeine Aufgabe der vorliegenden Erfindung ist es eine effizientere
Header-Kompression zu erzielen. Eine spezifische Aufgabe ist Mechanismen
für eine
flexible Header-Kompression in Bezug auf Kompressionsmoden bereitzustellen.
Eine andere Aufgabe ist es einfach implementierte Header-Kompressionsverfahren
zu ermöglichen.
-
Diese
Aufgaben werden in Übereinstimmung mit
den beigefügten
Ansprüchen
gelöst.
-
Kurz
zusammengenommen erzielt die vorliegende Erfindung eine effizientere
Header-Kompression
mit Hilfe eines Mechanismus, der einem Kompressor erlaubt eine Aufforderung
von einem Dekompressor nach einer unerwünschten Modusänderung abzuweisen.
Gemäß des vorgeschlagenen
Verfahrens zeigt der Kompressor, vorzugsweise durch eine implizite
oder explizite Signalisierung, in Richtung auf den Dekompressor
an, dass die Modusänderungsaufforderung
abgewiesen/ignoriert wird. Im Ansprechen auf diese Anzeige kann
der Dekompressor danach den anfänglichen Übergang
abbrechen, und zwar mit dem Verständnis, dass der Kompressor
gültige
Gründe
hat den Modusübergang
abzulehnen. Wenn der Dekompressor Kenntnis hat über die angezeigte Abweisung
antwortet er mit einer Abweisungsbestätigungsaktion, was eine erfolgreiche
Abweisung impliziert. Die Abweisungsbestätigungsaktion kann beispielsweise
eine verringerte Neuübertragungsfrequenz
oder eine abgebrochene Neuübertragung
der Modusänderungsaufforderung
oder eine explizite Abweisungsbestätigungsnachricht beinhalten.
Der Kompressor bestimmt vorzugsweise, ob die Abweisung (Zurückweisung)
erfolgreich war, indem er das Dekompressor-Signalisierungsverhalten überwacht und
interpretiert, und für
den Fall einer erfolgreichen Zurückweisung
bleibt der Dekompressor in seinem gegenwärtigen Modus.
-
Bevorzugte
Ausführungsformen
der Erfindung erzielen eine explizite Zurückweisungssignalisierung durch
Senden einer Modusänderungs-Zurückweisungsnachricht
mit einem neu definierten Modus-Wert von dem Kompressor zu dem Dekompressor
und eine implizierte Zurückweisungssignalisierung
durch absichtliches Ignorieren der Aufforderungen für eine vorgegebene
Zeitperiode. Es sind auch Ausführungsformen
mit einer kombinierten expliziten und implizierten Zurückweisungssignalsierung
vorhanden.
-
Somit
kann ein Header-Kompressor mit Hilfe des Nachrichtenübermittlungsverfahrens
gemäß der vorliegenden
Erfindung entweder sicher eine Aufforderung von dem Dekompressor
ignorieren oder explizit eine Zurückweisung der Modusänderungsaufforderung
signalisieren. Dies ermöglicht
es für
den Dekompressor den Übergang
auf einen bestimmten Modus, wenn bevorzugt unter Berücksichtigung
von unterschiedlichen Faktoren, einschließlich einiger unbekannter für den Dekompressor,
zu deaktivieren. Sie ermöglicht
auch Kompressor-Implementierungen, die nur einen Untersatz von sämtlichen
Betriebsmoden für
die Header-Kompression unterstützen.
Insbesondere können
Implementierungen mit nur einem vorteilhaften U/O-Modus, die konsistent mit
den ROHC Spezifikationen sind, bereitgestellt werden.
-
Gemäß anderer
Aspekte der Erfindung werden ein Kommunikationssystem und eine Header-Kompressionseinheit
bereitgestellt.
-
Eine
Header-Kompression in Übereinstimmung
mit der vorliegenden Erfindung bietet die folgenden Vorteile:
- – eine
verbesserte Header-Kompressionseffizienz
- – eine
effiziente Verwendung der verfügbaren Bandbreite
- – eine
verringerte Implementierungsgröße
- – verringerte
Speicheranforderungen
- – die
Implementierung-Validierung und das Testen von weniger Funktionalität
- – eine
verbesserte Implementierungszeit und verbesserte Kosten
- – einfacher
anzubringende ROHC Produkte
- – weit
verbreitete Modus-spezifische (z.B. U/O) Implementierungen
-
KURZBESCHREIBUNG DER ZEICHNUNGEN
-
Die
Erfindung, zusammen mit weiteren Aufgaben und Vorteilen davon, lässt sich
am Besten unter Bezugnahme auf die folgende Beschreibung und die
beiliegenden Zeichnungen verstehen. In den Zeichnungen zeigen:
-
1 ein
schematisches Blockdiagramm, welches ein beispielhaftes Kommunikationsnetz
darstellt, in dem die vorliegende Erfindung verwenden werden kann;
-
2 ein
Header-Kompressionsverfahren, bei dem die vorliegende Erfindung
verwendet werden kann;
-
3 ein
Flussdiagramm eines Header-Kompressionsverfahrens gemäß einer
ersten beispielhaften Ausführungsform
der vorliegenden Erfindung; und
-
4 ein
Flussdiagramm eines Header-Kompressionsverfahrens gemäß einer
zweiten beispielhaften Ausführungsform
der vorliegenden Erfindung.
-
AUSFÜHRLICHE BESCHREIBUNG
-
1 ist
ein schematisches Blockdiagramm, welches ein beispielhaftes Global
System for Mobile communication/General Packet Radio Service (GSM/GPRS)
Kommunikationsnetz darstellt, in dem die vorliegende Erfindung verwendet
werden kann. Bin Funknetz, welches eine Anzahl von Mobilstationen/Terminals 10 umfasst,
wie beispielsweise Mobiltelefone, Laptops und drahtlose Weitergabestellen, die
mit einem Basisstations-Untersystem (BSS) über drahtlose Strecken 11 kommunizieren,
ist gezeigt. Das BSS enthält
typischerweise eine große
Anzahl von Basis-Sender/Empfänger-Stationen
(BTS) 12 und Basisstations-Controllern (BSC) 13.
Jede BTS bedient die Mobilstationen innerhalb ihres jeweiligen Abdeckungsgebiets
und mehrere BTS werden von einem BSC gesteuert, der wiederum einen
Zugang zu dem Kernnetz bereitstellt, das ein Mobilvermittlungszentrum (MSC) 14 und
ein Gateway-Mobilvermittlungszentrum (GMSC) 15 umfasst.
GSM Verkehr wird durch das MSC 14 geführt, welches mit einem Besucherregister
(Visitor Location Register VLR) assoziiert ist, welches für den gegenwärtigen Aufenthaltsort
einer Mobilstation 10 verantwortlich ist. Eine Kommunikation
zu und von externen Netzen würde durch
das GMSC 15 behandelt. Bezug nehmend auf das Paketvermittlungs-Unternetz,
dieses umfasst einen bedienenden GPRS Unterstützungsknoten (Serving GPRS
Support Node, SGSN) 16 und einen Gateway GPRS Unterstützungsknoten
(GGSN, Gateway GPRS Support Node) 17. Der GGSN arbeitet
als eine Schnittstelle in Richtung auf externe Paketdaten-Netze,
während
der SGSN verantwortlich ist für
eine Paketzustellung an und von Terminals innerhalb seines Dienstgebiets.
-
In
der Praxis umfassen die meisten Netze mehrere Netzknoten, die in
viel komplexeren Vorgehensweisen angeordnet sind, als in dem grundlegenden
Beispiel der 1. Ferner ist 1 ein
Beispiel von einem Typ von Kommunikationssystem, in dem die vorliegende
Erfindung verwendet werden kann. Die Erfindung ist auch anwendbar
auf andere Paketdaten-Kommunikationsnetze, einschließlich z.B. cdma2000
drahtlose Paketdaten-Kommunikationsnetze, sowie Systeme unter Verwendung
von anderen Funktechnologien für
drahtloses IP, wie ein WLAN.
-
Eine
Header-Kompression wird typischerweise verwendet, um die erforderliche
Bandbreite von einer oder mehreren Strecken in dem dargestellten
Kommunikationsnetz zu verringern und dadurch deren Übertragungseffizienz
und Geschwindigkeit zu verbessern. Insbesondere erfordert eine drahtlose Kommunikation
oft eine derartige Bandbreitenreduktion, aber eine Header-Kompression
kann auch für andere
Strecken nützlich
sein, einschließlich
statischen/verdrahteten Strecken. Im Allgemeinen gibt es sowohl
einen Kompressor als auch einen Dekompressor an jedem Ende einer
Strecke, bei der eine Header-Kompression
angewendet wird. In einem drahtlosen System sind sie oft in der
Mobilstation 10 für
das Terminalende der Strecke 11 angeordnet, könnten aber
auch z.B. auf jeder Seite eines Sende/Empfängers und eines Empfängers, der
als eine Weitergabestelle (Relais) verwendet wird, angeordnet sein.
Auf der Netzseite der Strecke 11 kann der Kompressor und
Dekompressor in ein oder mehreren der folgenden Knoten angeordnet
sein: Einen SGSN 16 oder GGSN 17 für ein GPRS-gestützes Paketdatensystem,
einem Paketdaten-bedienenden Knoten (Packet Data Serving Node, PDSN)
(nicht gezeigt) für
ein cdma2000 Paketdatensystem, oder in der Basisstation 12 oder
einem anderen Knoten des Funkzugriffsnetzes.
-
In 2 wird
das allgemeine Prinzip der Header-Kompression dargestellt. Eine
Header-Kompressoreinheit 20 und
eine Header-Dekompressoreinheit 22 sind gezeigt. Diese
Einheiten 20, 22 kommunizieren über eine
Strecke mit einem Vorwärtskanal
(von dem Kompressor zu dem Dekompressor), sowie einem optionalen
Rückkopplungskanal.
Außer den
tatsächlichen
Daten/der Nutzlast, besteht jedes IP Paket, das der Header-Kompressoreinheit
eingegeben wird, aus einem Header-Abschnitt (in 2 dargestellt
mit einem gestreiften Feld) mit Ursprungs- und Zieladressen, einer
Fehlerüberprüfung, Port- und
Protokollfeldern, etc.. Der Header-Abschnitt bildet oft einen größeren Teil
des Pakets als die Daten. Eine Weiterleitung des vollständigen Pakets
würde somit
eine große
Bandbreite erfordern und deshalb wird das Paket durch Beseitigen
der redundanten Header-Information in der Header-Kompressoreinheit 20 komprimiert,
bevor es über
die Strecke mit begrenzter Bandbreite (11 in 1)
transferiert wird. Die Header-Dekompressoreinheit 22 rekonstruiert das
Paket in ein dekomprimiertes Paket, welches im Wesentlichen identisch
zu dem ursprünglichen
eingegebenen Paket ist.
-
Eine
Header-Kompression stützt
sich grundlegend auf die Erkenntnis, dass zahlreich Header-Felder von Paketen,
die zu dem gleichen Strom gehören,
konstant sind oder sich kaum indem, und vollständige Header-Felder deshalb
nur gelegentlich gesendet werden müssen. Einzelheiten und Regeln über die
Header-Kompression werden in mehreren Header-Kompressorprotokollen
bereitgestellt. In dieser Offenbarung wird das Augenmerk für beispielhafte
Zwecke hauptsächlich
sich auf ROHC konzentrieren, obwohl aber die vorliegende Erfindung
sehr nützlich
in Verbindung mit ROHC und insbesondere den ROHC RTP, UDP und ESP
Profilen (RFC 3094[4]), den ROHC UDP-Lite Profil [5], dem ROHC IP-Only
Profil [6], dem LLA Profil (RFC 3242[7]) sowie der R-Modus Erweiterung
zu dem LLA Profil [8] ist, ist sie in keinerlei Weise darauf beschränkt. Andere
gegenwärtige
oder zukünftige
Header-Kompressionsverfahren,
ROHC oder nicht, liegen ebenfalls innerhalb des Umfangs der vorliegenden
Erfindung.
-
Wie
in dem Hintergrundabschnitt angedeutet gibt die Spezifikation für die Robust
Header-Compression
(Robuste Header-Kompression, RFC 3095) an, das „sämtliche ROHC Implementierungen
alle drei Betriebsmoden implementieren und unterstützen MÜSSEN". Die Modusübergänge sollen
wie folgt ausgeführt
werden.
-
Von dem U-Modus zu dem O-Modus
-
Wenn
ein Rückkopplungskanal
verfügbar
ist kann der Dekompressor entscheiden einen Modusübergang
von dem U-Modus auf den O-Modus durch Senden eines Rückkopplungspakets,
welches eine Aufforderung für
eine Modusänderung
auf den O-Modus führt,
zu initiieren. Dem Dekompressor wird erlaubt bereits auf den O-Modus überzugehen,
da die Pakettypen, die sowohl für
U- als auch O-Moden verwendet werden, die gleichen sind. Der Kompressor wird
auf den O-Modus übergehen,
sobald die Aufforderung empfangen wird.
-
Von dem O-Modus zu dem R-Modus
-
Der
Dekompressor kann einen Modusübergang
von dem O-Modus auf den R-Modus durch Senden einer Aufforderung
an den Kompressor initiieren. Sobald der Übergang initiiert ist, wird
dem Kompressor nicht erlaubt irgendwelche der Pakettypen zu verwenden,
die einen gemeinsamen Identifizierer verwenden, für die aber
die Interpretation sich zwischen dem U/O-Modus und dem R-Modus unterscheidet,
typischerweise die effizientesten Paketformate. Bis der Dekompressor
eine Bestätigung
von dem Kompressor bezüglich
der Modusänderung empfängt wird
der Dekompressor weiter diese Modusaufforderung für jedes
Paket, das von dem Kompressor empfangen wird, senden. Der Kompressor verwendet
das „Modus"Feld der spezifizierten
Pakettypen, die während
eines Übergangs
zugelassen werden, und setzt dieses auf den angeforderten Modus,
um die Änderung
zu bestätigen.
Die Bedeutungen des Modusfelds mit 2 Bit sind folgendermaßen definiert:
-
Kompressionsmodus
-
-
- 0
- = reserviert
- 1
- = unidirektional (U-Modus)
- 2
- = bidirektional optimistisch
(O-Modus)
- 3
- = bidirektional zuverlässig (R-Modus)
-
Von dem U-Modus auf den R-Modus
-
- Gleiche Prozedur wie von dem O-Modus zu dem R-Modus
-
Von dem R-Modus zu dem O-Modus
-
- Gleiche Prozedur wie von dem O-Modus zu dem R-Modus.
- Ein Übergang
zurück
auf den U-Modus ist auch immer möglich.
-
Gemäß der ROHC
(RFC 3095) muss der Kompressionsprozess in dem U-Modus starten.
Der U-Modus und
der O-Modus sind in der Praxis sehr ähnlich zueinander und werden
deshalb beide bereits unterstützt.
Da sich der R-Modus signifikant von den zwei anderen Moden unterscheidet,
würde es
in vielen Fällen
zweckdienlich sein den R-Modus auszulassen und nur U/O-Modus Implementierungen
zu verwenden.
-
Es
ist ersichtlich, dass flexible Modus Implementierungen von ROHC,
wie Implementierungen mit nur dem U/O-Modus, die ermöglichen,
dass optimierte Header-Kompressoren mit weniger Funktionalität implementiert
werden, sehr vorteilhaft sein würden.
Viele Kompressoren würden
manchmal bevorzugen nicht auf einen anderen Modus, z.B. den R-Modus, überzugehen,
sogar wenn durch den Dekompressor angefordert. Es kann auch wünschenswert
sein die Implementierungsunterstützung
für einen
bestimmten Modus (für
bestimmte Moden), z.B. den R-Modus, zu vermeiden und noch sicher
mit den ROHC Spezifikationen übereinzustimmen.
-
Jedoch
erlaubt ROHC nicht die Möglichkeit Implementierungen
mit nur einem U/O-Modus und dergleichen zu erzeugen. Gemäß [4] handelt
es sich nur um den Dekompressor, der die Modusübergänge diktiert. Dies stellt wiederum
eine Anforderung an die Kompressor-Implementierung, um immer sämtliche definierten
Moden zu unterstützen.
Ein Kompressor kann somit in einen suboptimalen Betrieb einfach deshalb
gezwungen werden, weil eine Dekompressor-Implementierung von einer
anderen Quelle einen anderen Modus als denjenigen, für den der
Kompressor optimiert war, begünstigen
kann.
-
Die
vorliegende Erfindung zielt darauf ab eine Lösung anzubieten, die die Beschränkung entfernt,
die von den ROHC Algorithmus in Richtung auf die Kompressor-Implementierung
auferlegt wird, nämlich
immer und absolut alle Betriebsmoden zu unterstützen, selbst wenn es benötigt wird
oder es wünschenswert
ist nur einen Untersatz zu unterstützen.
-
Ein
erster Gedanke würde
darin bestehen einfach die Modusänderungsaufforderung
von dem Dekompressor zu ignorieren. Für den Modusübergang von dem U- oder O-Modus
auf den R-Modus beispielsweise schreibt die gegenwärtige ROHC Spezifikation
vor „während D_TRANS
I ist, sendet der Dekompressor eine NACK oder ACK, die eine CRC
Option für
jedes empfangene Paket führt". Mit anderen Worten,
wenn der Dekompressor eine Modusaufforderung gesendet hat, sendet
der Dekompressor wieder die Aufforderung für jedes Paket, welches empfangen
wird, bis er eine Modusänderungsbestätigung von
dem Kompressor empfängt.
Ferner wird auch angegeben, dass „solange wie der Dekompressor
nicht ein UOR-2, IR-DYN, oder IR Paket mit dem Modusübergangs-Parameter
auf R gesetzt empfangen hat, muss er in dem optimistischen Modus
bleiben". Dies bedeutet,
dass dem Dekompressor nicht erlaubt wird den Modus (z.B. auf den
R-Modus) zu ändern,
bevor er eine Modusänderungsbestätigung von
dem Kompressor empfängt.
Eine Konsequenz davon ist, dass eine Dekompression sicher fortgesetzt
werden kann, bis der Dekompressor tatsächlich den Modusübergang
bestätigt
und die Aufforderungen bestätigt.
-
Da
der ROHC Dekompressor in dem U/O-Modus bleiben muss, bis eine Bestätigung über die
Modusänderung
von dem Kompressor empfangen wird, wird eine Kompressor-Implementierung, die
die Modusänderungsaufforderung
auf den R-Modus von dem Dekompressor ignoriert, den Dekompressor
nicht davon abhalten die Ausführung
einer robusten Dekompression fortzusetzen. Trotzdem wird er eine
Erhöhung
auf dem Rückkopplungskanal
als Folge der Neuübertragungen
der Aufforderung durch den Dekompressor erzeugen, was zu einer nicht
optimalen Verwendung der Bandbreite führt. In Abhängigkeit von der Dekompressor-Implementierung
kann dieses Verhalten dauernd, intermittierend oder transient sein.
Einfach eine Modusänderungsaufforderung auf
den R-Modus von dem Dekompressor zu ignorieren würde somit den Nachteil der
Erzeugung eines erhöhten
Verkehrsbetrags über
den Rückkopplungskanal
in einer weniger gesteuerten Weise und für eine spezifizierte Zeit bringen.
-
Anstelle
davon schlägt
die vorliegende Erfindung eine Nachrichtenübermittlungsprozedur vor, bei der
der Kompressor in Richtung auf den Dekompressor anzeigen kann, dass
gerade eine Modusänderungsaufforderung
zurückgewiesen
(abgewiesen) wird. Im Ansprechen auf diese angezeigte Zurückweisung
kann der Dekompressor dann den initiierten Übergang mit dem Verständnis abbrechen,
dass der Kompressor gültige
Gründe
hat den Modusübergang zurückzuweisen.
Derartige Gründe
können
beispielsweise sein, dass der Dekompressor eine bessere Kenntnis
der Streckenbedingungen hat, dass der Kompressor für den gegenwärtigen Betriebsmodus optimiert
ist, und/oder dass der angeforderte Modus nicht verfügbar ist.
-
Gemäß dem vorgeschlagenen
Verfahren zeigt ein Kompressor, der eine Aufforderung nach einer
unerwünschten
Modusänderung
empfangen hat, somit eine Zurückweisung
der Modusänderungsaufforderung
an den Dekompressor an, typischerweise durch eine explizite oder
implizierte Signalisierung. Wenn der Dekompressor die angezeigte
Zurückweisung
wahrnimmt, antwortet er durch Bestätigen der Zurückweisung,
z.B. auch ein geändertes
Signalisierungsverhalten und/oder eine explizite Nachricht. Eine
derartige Zurückweisungsbestätigungsaktion wird
als eine erfolgreiche Zurückweisung
von dem Kompressor interpretiert, der in seinem gegenwärtigen Modus
bleibt.
-
Die
vorliegende Erfindung erlaubt somit einem Kompressor entweder implizit
oder explizit eine Modusänderungsaufforderung
von einem Dekompressor zurückzuweisen.
Dies macht es für
den Kompressor möglich
den Übergang
auf einen bestimmten Modus zu deaktivieren und entfernt sogar die
Notwendigkeit für
Kompressoren sämtliche
Betriebsmoden zu implementieren.
-
Um
die Prinzipien der Erfindung zu illustrieren werden nun eine erste
und eine zweite Ausführungsform
davon unter Bezugnahme auf 3 und 4 beschrieben.
Die Beispiele adressieren hauptsächlich
einen Modusübergang
von einem U- oder O-Modus auf einen R-Modus und sind auf das voranstehend
beschriebene Kompressorverhalten gestützt, wenn eine Modusübergangsaufforderung
initiiert wird. Jedoch liegen auch Ausführungsformen mit anderen Modusänderungsaufforderungen
(bezüglich ROHC
Moden, sowie anderen Header-Kompressions-Betriebsmoden) innerhalb
des Umfangs der Erfindung. Jegliche Aufforderung für einen
Modusübergang
von einem ersten Header-Kompressionsmodus auf einen zweiten Header-Kompressionsmodus
kann somit in Übereinstimmung
mit der Erfindung behandelt werden, z.B. eine Aufforderung auf/von
Moden, die aus der Gruppe eines unidirektionalen (U) Modus, eines
bidirektionalen optimistischen (O) Modus, einem bidirektionalen
zuverlässigen
(R) Modus und einem bidirektionalen (B) Modus gewählt sind.
-
EXPLIZITE ZURÜCKWEISUNGSSIGNALISIERUNG
-
In Übereinstimmung
mit einem ersten Ansatz signalisiert der Kompressor explizit dem
Dekompressor, dass die Modusänderungsaufforderung
ignoriert/zurückgewiesen
wird. Der Dekompressor kann dann dieses Signal zum Abbrechen des
initiierten Übergangs,
zum Verbleiben in dem U/O-Modus und zum Stoppen der Aussendung von
Modusänderungsaufforderungen
verwenden.
-
Eine
bevorzugte Ausführungsform
verwendet neu definierte Modusbits, um explizit eine Zurückweisung
der Modusänderungsaufforderung
zu signalisieren. Wie voranstehend angegeben ist der Modus-Wert
in ROHC (RFC 3095) wie folgt definiert:
-
Kompressionsmodus
-
-
- 0
- = reserviert
- 1
- = unidirektional (U-Modus)
- 2
- = bidirektional optimistisch
(O-Modus)
- 3
- = bidirektional zuverlässig (R-Modus)
-
Der
Modus-Wert des UOR-2, IR-DYN oder IR Pakets von ROHC (RFC 3095)
wird gemäß dieses Ansatzes
neu definiert als:
-
Kompressionsmodus
-
-
- 0
- = Modusänderungsaufforderung
ignoriert/gelöscht
- 1
- = unidirektional (U-Modus)
- 2
- = bidirektional optimistisch
(O-Modus)
- 3
- = bidirektional zuverlässig (R-Modus)
-
Der
Wert, der vorher reserviert war (d.h. keine besondere Bedeutung
in dem Sinne hatte, dass sämtliche
Bits mit dem Wert 0 ignoriert werden sollen), wird demzufolge verwendet,
um anzuzeigen, dass die Modusänderungsaufforderung
von der Header-Kompressoreinheit zurückgewiesen/ignoriert wird.
Demzufolge sendet der Kompressor ein Paket mit dem Modus-Wert 0
an den Dekompressor im Ansprechen auf eine unerwünschte Modusänderungsaufforderung.
Vorausgesetzt, dass der Dekompressor Kenntnis über die neuen Modusdefinitionen
hat, kann er geeignete Aktionen vornehmen, wie beispielsweise das
Abbrechen von weiteren Auffoderungsübertragungen. Damit andere
Implementierungen über
das Signal Kenntnis haben kann ein gewisser Standardisierungsaufwand
benötigt
werden.
-
Es
sei darauf hingewiesen, dass die vorliegende Erfindung auch Ausführungsformen
unter Verwendung von anderen Mechanismen abdeckt, um einem Dekompressor
explizit zu signalisieren (im-Band oder
außerhalb-des-Bands),
das eine Modusänderungsaufforderung
ignoriert wird. Anstelle der bevorzugten Neudefinition des ROHC
Modus-Werts, können
somit andere Bits/Werte für
die explizite Signalisierung verwendet werden, einschließlich eines
speziellen Pakettyps, eines anderen Bitflags als das Modusbit, eine
Option innerhalb des Paketformats, eine Option innerhalb einer Erweiterung,
etc..
-
3 ist
ein Flussdiagramm eines Header-Kompressionsverfahrens gemäß einer
beispielhaften Ausführungsform
der vorliegenden Erfindung mit einer expliziten Zurückweisungssignalisierung. Im
Schritt S1 initiiert die Header-Dekompressoreinheit einen Modusübergang
und übertragt
eine Aufforderung nach einer Änderung
auf einen neuen Modus an die Header-Kompressoreinheit über die
Pakettransferstrecke. Für
den Fall, dass der Modusübergang
beispielsweise eine Änderung
auf den R- Modus
beinhaltet, wird der Kompressionsmodus der Aufforderung auf MODE
= 3 (R-Modus) gesetzt. Der Dekompressor bleibt dann in seinem gegenwärtigen Modus
und wartet auf eine Bestätigung
von dem Kompressor. Für
jedes Paket, welches bis zu der Bestätigung empfangen wird, sendet
der Dekompressor die Aufforderung erneut über den Rückkopplungskanal.
-
Der
Kompressor empfängt
die Modusänderungsaufforderung,
bevorzugt aber in dem gegenwärtigen
Betriebsmodus zu bleiben. Er signalisiert explizit eine Zurückweisung
der Modusänderungsaufforderung
an den Dekompressor, vorzugsweise durch Senden einer Modusänderungs-Zurückweisungsnachricht über die
Pakettransferstrecke (Schritt S2). In der bevorzugten Ausführungsform,
die die obige Neudefinition des Modus-Werts der ROHC Pakete verwendet,
sendet der Kompressor ein oder mehrere UOR-2, IR-DYN, oder IR Pakete
und setzt MODE = 0 (Aufforderung gelöscht).
-
Nun
nimmt die Prozedur unterschiedliche Pfade in Abhängigkeit davon, ob der Dekompressor die
Zurückweisung
der Modusänderungsaufforderung
versteht, wenn er MODUS = 0 Pakete oder andere explizite Signale
empfängt
(Schritt S3). Wenn der Dekompressor Kenntnis über das Zurückweisungssignal, z.B. die
neu definierte Semantik des Modus-Werts, hat, dann stoppt er eine
Aussendung der Modusänderungsaufforderung über den
Rückkopplungskanal
im Schritt S4. Der Modus-Übergang wird
dann abgebrochen und der Dekompressor setzt den gegenwärtigen Betriebsmodus
fort. Vorzugsweise sendet der Dekompressor auch eine Nachricht an den
Kompressor, die anzeigt, dass die Zurückweisung bestätigt wird
(Schritt S5). Eine derartige Zurückweisungsbestatigungsnachricht
kann zum Beispiel Rückkehr-ROHC-Pakete
mit dem MODUS Parameter entweder auf 0 oder auf den Wert des Modus gesetzt
umfassen, der zu der Zeit aktiv ist, als der Dekompressor die Aufforderung
für eine
Modus-Änderung,
d.h. der („erste"/"gegenwärtige") Modus, den der Kompressor aufrechterhalten
möchte,
initiiert hat.
-
Der
Kompressor bestimmt vorzugsweise, ob die Zurückweisung erfolgreich war,
indem er das Signalisierungsverhalten des Dekompressors interpretiert.
Im Allgemeinen beinhaltet dies eine Überwachung der Pakettransferstrecke
bei der Suche nach irgendeiner Art von Anzeige, dass die Zurückweisung verstanden
worden und durch den Dekompressor bestätigt worden ist. Diese Anzeige
kann die obige Zurückweisungsbestätigungsnachricht
sein. Alternativ kann die Anzeige, dass die Modusänderungs-Aufforderungszurückweisung
erfolgreich war, darin bestehen, dass der Kompressor das Empfangen
von Modusänderungsaufforderungen
mit dem neuen Modus über
den Rückkopplungskanal
mit hohem Vertrauen, dass das Signal den Dekompressor erreicht hat,
stoppt. Eine ausreichende Sicherheit würde normalerweise wenigstens
eine Umlaufzeit (Round-Trip Time; RTT) von 1 Strecke erfordern,
und typischerweise in dem Bereich von 1-2 RTT. Im Ansprechen auf
eine erfolgreiche Zurückweisung
fährt der
Kompressor unter Verwendung des gegenwärtigen Modus fort (Schritt
S6).
-
Wenn
andererseits der Dekompressor die Zurückweisungssignalisierung, z.B.
den neu definierten Modus-Wert nicht versteht, wird er ihn ignorieren und
in dem gegenwärtigen
Betriebsmodus bleiben. Eine Dekompression wird typischerweise fortgesetzt und
an sich [4] wartet der Dekompressor noch auf die Bestätigung von
dem Kompressor. In diesem Fall wird der Kompressor noch Modusänderungsaufforderungen
mit dem neuen Modus über
den Rückkopplungskanal
empfangen, obwohl höchst
zuverlässig ist,
dass das Signal den Dekompressor erreicht hat. Der Kompressor entscheidet,
dass die Zurückweisungssignalisierung
nicht erfolgreich war und der Schritt S7 fragt, ob die Aufforderung
erfüllt
werden soll. Wenn dem so ist, dann ändert der Kompressor den Kompressormodus
und führt
vorzugsweise eine Bestätigung,
wie beispielsweise ein Paket mit dem neuen Modus-Wert, an den Dekompressor
zurück (Schritt
S8), der demzufolge den Modus ändert
und eine weitere Aufforderungsübertragung
abbricht (Schritt S9). Alternativ wird die Aufforderung trotz der nicht
erfolgreichen Zurückweisung
nicht erfüllt.
Anstelle dessen fällt
der Kompressor vorzugsweise zurück
auf das Verhalten mit einer implizierten Signalisierung, die nachstehend
unter Bezugnahme auf 4 beschrieben werden wird.
-
Die
Entscheidung im Schritt S7 wird entweder durch allgemeine Implementierungs-spezifische Merkmale
oder auf Grundlage einer Interpretation von jeder bestimmten Situation
bestimmt. Wenn beispielsweise eine Implementierung den angeforderten Modus
nicht unterstützt,
ist die Erfüllung
des Modus nicht eine Option und demzufolge werden sämtliche Aufforderung
für diesen
Modus ignoriert werden. Jedoch kann ein Kompressor auch einen Übergang
auf einer Einzelfallbasis wegen Gründe denjenigen, das die Kompressorseite
gegenwärtig
geringe Verarbeitungsressourcen, ein besseres Verständnis der
Streckeneigenschaften, etc. hat, ablehnen.
-
Der
mit 3 dargestellte Ansatz weist den Vorteil auf, dass
er die effizienteste Vorgehensweise für einen Kompressor ist, um
dem Dekompressor zu signalisieren, dass eine Modusänderungsaufforderung
nicht erfüllt
werden wird, und ein Dekompressor, der in der Lage ist ein derartiges
Signal zu interpretieren, wird geeignete Aktionen vornehmen. Ein
derartiger Dekompressor bleibt in dem gegenwärtigen Modus und erhöht nicht
den Verkehr auf dem Rückkopplungskanal
durch Zurücksenden
der Modusänderungsaufforderung.
-
Ein
anderer Vorteil ist, dass ein Verfahren gemäß dieser Ausführungsform
der Erfindung interoperabel und dem Standard angepasst bleibt, wenn
ein Kompressor, der sämtliche
Moden unterstützt,
aber die U/O-Moden bevorzugt, zusammen mit einer Dekompressor-Implementierung
verwendet wird, die nicht Kenntnis über die vorgeschlagene Neudefinition
hat. Ein Dekompressor, der diese Neudefinition nicht versteht, wird
einfach diesen Wert ignorieren, wie bei den ROHC Spezifikationen.
Der Kompressor kann dann auf die implizierte Signalisierung nachstehend
zurückgreifen
oder die Modusänderungsaufforderung
erfüllen.
-
IMPLIZIERTE ZURÜCKWEISUNGSSIGNALISIERUNG
-
Ein
anderer Ansatz ist für
einen Kompressor implizit eine Zurückweisung der Modusänderungsaufforderung
anzuzeigen. In einer bevorzugten Ausführungsform wird die implizierte
Signalisierung durch absichtliches Ignorieren der Modusänderungsaufforderung
von dem Dekompressor und durch Bleiben in dem gegenwärtigen Modus,
aber nur für
eine begrenzte Zeit, erzielt. Mit anderen Worten, es wird vorgeschlagen
die Aufforderung in einer gesteuerten Weise sicher zu ignorieren,
um eine Zurückweisung davon
an dem Dekompressor anzuzeigen. Wenn die Modusänderungsaufforderungen, die über den
Rückkopplungskanal
gesendet werden, aufhören
oder nach einer bestimmten Zeitperiode intermittierend werden, kann
der Kompressor in dem gegenwärtigen Modus,
z.B. dem U/O-Modus, ohne ein Einbrechen des Betriebsverhaltens bleiben.
Ansonsten, d.h., wenn der Verkehr auf dem Rückkopplungskanal vorherrschend
ist, dann kann der Kompressor entscheiden die Modusänderung
auszuführen
und die Modusänderungsaufforderung
zu erfüllen.
-
Die
Länge der
Zeitperiode, während
der der Kompressor die Modusänderungsaufforderung
(die Modusänderungsaufforderungen)
ignorieren und auf eine mögliche
Reaktion von dem Dekompressor warten soll, ist typischerweise in
der Größenordnung
von 1-2 RTT. Der Grund dafür
ist, dass der Dekompressor allgemein erwarten kann eine „Antwort" von dem Kompressor
zu ungefähr
1 RTT (Minimum) nach Senden der Aufforderung zu empfangen. Es kann länger dauern
und die RTTs von einigen Strecken verändern sich auch mit der Zeit.
Jedoch kann in den meisten Fällen
die vorgegebene Zeitperiode für
eine implizite Zurückweisungssignalsierung
durch den Bereich von 1-2 RTT dargestellt werden.
-
4 ist
ein Flussdiagramm eines Header-Kompressionsverfahrens gemäß einer
beispielhaften Ausführungsform
der vorliegenden Erfindung mit einer impliziten Zurückweisung.
Wie zuvor initiiert die Header-Dekompressoreinheit einen Modusübergang
und sendet eine Modusänderungsaufforderung an
die Header-Kompressoreinheit (Schritt S10). Der Dekompressor bleibt
in seinem gegenwärtigen
Modus und wartet auf eine Bestätigung
von dem Kompressor. Für
jedes Paket, das bis zu der Bestätigung empfangen
wird, sendet der Dekompressor die Aufforderung erneut über den
Rückkopplungskanal.
-
Der
Kompressor empfängt
die Modusänderungsaufforderung,
bevorzugt aber in dem gegenwärtigen
Betriebsmodus zu bleiben. Der Kompressor zeigt deshalb eine Modusänderungs-Zurückweisung an,
in diesem Fall durch eine implizite Zurückweisungssignalisierung. Vorzugsweise
ignoriert er hierbei die Aufforderung und setzt den gegenwärtigen Modus
fort, und zwar zu der gleichen Zeit, wie er einen Timer startet
und den Rückkopplungskanal überwacht
(Schritt S11). Der Timer wird auf einen Wert gesetzt, für den der
Kompressor ein hohes Vertrauen erzielt, dass der Dekompressor die
fehlende Antwort auf die Modusänderungsaufforderung
bemerken kann, z.B. in dem Bereich von 1-2 RTT. Anstelle des Timers
können
alternative Mechanismen, z.B. auf Grundlage von Sequenznummern,
zum Erzielen der gesteuerten impliziten Zurückweisung verwendet werden.
-
Danach
nimmt die Prozedur unterschiedliche Pfade in Abhängigkeit davon, ob der Dekompressor Kenntnis über implizite
Zurückweisung
der Modusänderungsaufforderung
hat (Schritt S12). Wenn der Dekompressor ein hohes Vertrauen erzielt
hat, dass die Aufforderung den Kompressor erreicht hat und somit, dass
die Modusänderung
ausgeführt
werden sollte, aber noch eine Passivität/eine fehlende Antwort von dem
Kompressor bemerkt, was als Zurückweisung interpretiert
wird, dann stoppt er das erneute Senden der Modusänderungsaufforderung über den
Rückkopplungskanal
im Schritt S13. Alternativ senkt der Dekompressor die Frequenz der
Modusänderungsaufforderungs-Übertragungen
ab. Der Modusübergang
wird abgebrochen und der Dekompressor bleibt in dem gegenwärtigen Betriebsmodus.
-
Hinsichtlich
der Kompressoreinheit, diese entscheidet wiederum, ob die Zurückweisung
erfolgreich war. Vorzugsweise beinhaltet diese Interpretation des
Zurückweisungsergebnisses
die Überwachung
der Strecke und die Interpretation des Dekompressorsignalisierungsverhaltens.
Wenn der Kompressor eine niedrigere Frequenz oder eine Abwesenheit
der Modusänderungsauffoderungs-Übertragungen über den
Rückkopplungskanal
bemerkt, bevor der Timer abgelaufen ist, war die Zurückweisung
erfolgreich und der Kompressor bleibt in dem gegenwärtigen Modus
(Schritt S14).
-
Sollte
andererseits der Dekompressor keine Kenntnis über die Zurückweisung haben, dann wird der
von dem Kompressor gesetzte Timer ohne irgendeine Änderung
bei den Neuübertragungen
der Modusänderungsaufforderung über den
Rückkopplungskanal
ablaufen. Der Kompressor interpretiert dieses Verhalten als eine
nicht erfolgreiche Zurückweisung
und die Prozedur macht weiter mit dem Schritt S15, der fragt, ob
die Modusänderungsaufforderung
erfüllt
werden soll. Wenn dies der Fall ist, dann ändert der Kompressor den Kompressormodus und
gibt normal eine Bestätigung,
wie ein Paket mit dem neuen Modus-Wert an den Dekompressor zurück (Schritt
S16), der demzufolge den Modus ändert und
eine weitere Aufforderungsübertragung
abbricht (Schritt S17). Ansonsten setzt der Kompressor eine Ignorierung
der Aufforderung fort und bleibt in dem gegenwärtigen Modus (Schritt S18).
Das Ergebnis des Schritts S15 ist auf ähnliche Erwägungen wie diejenigen für den Schritt
S7 in 3 gestützt.
Der Schritt S18 würde
im Allgemeinen nicht die bevorzugte Option sein, kann aber für den Fall
nützlich
sein, dass der Kompressor nicht den Modus implementiert hat, den
der Dekompressor anfordert.
-
Dieser
Ansatz hat den Vorteil interoperabel und dem Standard angepasst
zu sein. Außerdem
erfordert er nicht irgendeine Änderung
des Standards. Das in 4 dargestellte Verfahren kann
auch als ein Ersatzmechanismus verwendet werden, wenn ein explizites
Signal verwendet wird, um Modusänderungsaufforderungen
zurückzuweisen
und der Dekompressor versteht nicht die Semantik des Signals, das
von dem Kompressor gesendet wird. Jedoch führt dies in der Tat zu einer
Erzeugung eines erhöhten
Verkehrsbetrags über
den Rückkopplungskanal, aber
in einer gesteuerten Weise und für
eine begrenzte Zeitperiode.
-
Die
mit 3 und 4 dargestellten Ausführungsformen
sind jeweils mit Vorteilen assoziiert und die Auswahl des am Besten
geeigneten Verfahrens beinhaltet Gewichtungsfaktoren, wie eine Interoperabilität und Betriebsverhalten
gegenüber
einander. Die jeweiligen Signalisierungsverfahren können getrennt
oder in Kombination verwendet werden, z.B. mit der impliziten Signalisierung
(4) als ein zusätzlicher
Ersatzmechanismus, wenn die explizite Signalisierung (3)
nicht zu einer erfolgreichen Zurückweisung
fuhren sollte.
-
Zusammengefasst
erlaubt die vorliegende Erfindung einem Header-Kompressor eine Modusänderungsaufforderung
von einem Header-Dekompressor zurückzuweisen (abzulehnen) und
unter Verwendung des gegenwärtigen
Betriebsmodus weiter zu machen, wenn dies unter Berücksichtigung
von unterschiedlichen Faktoren, einschließlich von Faktoren, die dem
Dekompressor nicht bekannt sind, als geeignet angesehen wird. Sie
ermöglicht
auch Kompressor-Implementierungen, die nur einen Untersatz von sämtlichen
Betiebsmoden für
eine Header-Kompression unterstützen.
Insbesondere ist es mit Hilfe der Erfindung möglich effiziente Implementierungen mit
nur einem U/O-Modus zu schaffen, während noch vollständig eine Übereinstimmung
mit der ROHC Spezifikation [4] besteht.
-
Die
Erfindung entfernt Kompressorabhängigkeiten
in Richtung auf den Dekompressor bezüglich Modus-Übergängen. Dies
führt zu
einer besseren Header-Kompressionseffizienz und kann auch die Speicheranforderungen,
die Implementierungszeit und die Implementierungskosten verringern.
Insbesondere durch den expliziten Signalisierungsansatz wird eine
effizientere Verwendung der verfügbaren Bandbreite
erreicht, ohne ungünstige
Auswirkungen auf das Verhalten und den Betrieb des Empfängers oder
der Anwendung. Ferner erlaubt die Erfindung weniger komplexe und
weniger aufwändige
Implementierungen von ROHC, wie beispielsweise Implementierungen,
die nur die U- und O-Moden verwenden.
-
Obwohl
die Erfindung unter Bezugnahme auf spezifische illustrierte Ausführungsformen
beschrieben worden ist, sei hervor gehoben, dass sie auch Aquivalente
für die
offenbarten Merkmale, sowie Modifikationen und Varianten, die für einen
Durchschnittsfachmann in dem technischen Gebiet offensichtlich sind,
abdeckt. Obwohl die Erfindung beispielhaft für ROHC (RFC 3095[4]) erläutert worden ist,
kann sie beispielsweise auch auf andere Header-Kompressionsverfahren
angewendet werden, einschließlich
Verfahren, die mit anderen Betriebsmoden als den beschriebenen Beispielen
assoziiert sind. Der Umfang der Erfindung wird nur durch die beigefügten Ansprüche beschränkt.
-
LITERATURSTELLEN
-
- [1] Van Jacobson, Compressing TCP/IP Headers for Low-Speed
Serial Links. IETF RFC 1144, IETF Network Working Group, February
1990.
- [2] Mikael Degermark, Björn
Nordgren, Stephen Pink. IP Header Compression. IETF RFC 2507, IETF
Network Working Group, February 1999.
- [3] Steven Casner, Van Jacobson. Compressing IP/UDP/RTP Headers
for Low-Speed Serial Links. IETF RFC 2508, IETF Network Working
Group, February 1999.
- [4] Carsten Bormann, et.al. RObust Header Compression (ROHC):
Framework and four profiles: RTP, UDP, ESP and uncompressed. IETF
RFC 3095, April 2001.
- [5] Ghyslain Pelletier. RObust Header Compression (ROHC): Profiles
for UDP-Lite, Internet draft, April 2003.
(http://www.ietf.org/internet-drafts/draft-ietf-rohc-udp-lite-00.txt)
- [6] Lars-Erik Jonsson, Ghyslain Pelletier. RObust Header Compression
(ROHC): A compression profile for IP, Internet draft, Juni 2003.
(http://www.ietf.org/internet-drafts/draft-ietf-rohc-ip-only-02.txt)
- [7] Lars-Erik Jonsson, Ghyslain Pelletier. RObust Header Compression
(ROHC): A Link-Layer
Assisted ROHC Profile for IP/UDP/RTP. IETF RFC 3242, April 2002.
- [8] Zhigang Liu, Khiem Le, 0-byte Support for R-mode in Extended
Link-Layer Assisted ROHC Profile. Internet draft, April 2002.