-
Die
Erfindung bezieht sich allgemein auf Paketkommunikationen, und genauer
auf Headerkomprimierung in Paketkommunikationen.
-
Der
Begriff Headerkomprimierung (HC, header compression) verweist auf
die Technik zum Minimieren der notwendigen Bandbreite für Information, die
in Paketheadern übertragen
wird auf einer Basis pro Sprung über
Punkt-zu-Punkt-Verknüpfungen. Headerkomprimierung
wird gewöhnlich
durch Senden statischer Information nur am Anfang realisiert. Semi-statische
Information wird dann durch Senden nur der Änderung von dem vorherigen
Header transferiert und vollständig
zufällige
Information kann ohne Komprimierung gesendet werden. Daher wird Headerkomprimierung
gewöhnlich
mit einer Zustandsmaschine realsiert.
-
Ein
konventionelles VoIP-Paket (Sprache über IP, Voice over IP) besteht
im wesentlichen aus drei Teilen mit unterschiedlichen Qualitätsanforderungen,
wie in 1 gezeigt. Die drei Teile sind:
- (1)
ein komprimierter oder nicht-komprimierter Header 11. Für Echtzeitsprache
wird z.B. häufig ein
konventioneller IP/UDP-/RTP-Header verwendet;
- (2) die Sprachcodec-Bits in Teil 12, die die wichtigsten
für die
Sprachqualität
sind. In dem Sprachcodec voller Rate für GSM gibt es z.B. drei Klassen
von Bits: 1A, 1B und 2, wobei Sprachcodec-Bits von Klasse 1A und
Klasse 2 jeweils die wichtigsten und am wenigsten wichtigsten für die Sprachqualität sind;
und
- (3) die Sprachcodec-Bits in Teil 13 sind für die Sprachqualität am wenigsten
wichtig, z.B. Bits von Klasse 2 in GSM.
-
Ein
konventionelles Headerkomprimierungsschema für IP/UDP/RTP, wie etwa das
eine, das in dem Internet-Draft "Compressing
IP/UDP/RTP Headers for Low-Speed Serial Links" von S. Cosner und V. Jacobson, 27.
Juli 1998 offenbart wird, hat typischerweise eine weiche Zustandscharakteristik
derart, dass der Zustand der HC von vorherigen Headern abhängen kann.
Ein Fehler in einem komprimierten Header kann zu einem Verlust des
entsprechenden Paketes führen.
Da jeder Header gewöhnlich
als eine Änderung
von dem vorherigen Header dargestellt wird (Delta-Kodierung), ist
ein Fehler in einem komprimierten Header ein fehlerhafter Zustand, der
bewirken wird, dass nachfolgende Pakete verloren gehen, bis der
weiche Zustand der HC aktualisiert wird. Falls die Nutzlast für die Pakete
mit den komprimierten Headern einen Echtzeitdienst überträgt, kann
der Verlust von mehreren aufeinanderfolgenden Paketen für die Qualität dieses
Echtzeitdienstes katastrophal sein. Z.B. wird sich die Qualität eines
Echtzeit-Sprachdienstes mit aufeinanderfolgenden verlorenen Sprachrahmen
wesentlich verschlechtern. Falls die Sprachrahmen-Fehlerrate eine häufungsartige
Charakteristik aufweist, wird die Sprachqualität schlechter als für das gleiche
Sprachrahmen-Fehlerverhältnis
sein, aber mit einer weniger korrelierten Rahmenfehlercharakteristik.
-
Die
Effekte von Bitfehlern können
abhängig davon,
wo in dem VoIP-Paket die Bitfehler auftreten, unterschiedlich sein:
- (1) Bitfehler in Teil 13 von 1 (die
am wenigsten wichtigen Sprachcodec-Bits) werden zu einer leicht
verschlech terten Qualität
für die
Sprache führen,
die durch dieses spezifische Paket übertragen wird.
- (2) Bitfehler in Teil 12 von 1 (die wichtigsten Sprachcodec-Bits)
können
zu einer Sprachqualitätsverschlechterung
führen,
die so schwer ist, dass das Paket als nutzlos beurteilt wird und
nicht in dem Sprachdecoder verwendet wird. Daher kann dieses spezifische
Paket wegen Bitfehlern in Teil 12 des Paketes verloren
sein.
- (3) Bitfehler in Teil 11 von 1 (dem Header, komprimiert
oder nicht) wird wahrscheinlich zu dem Verlust dieses spezifischen
Paketes führen, da
es nicht zu den oberen Schichten des Protokollstapels transferiert
werden kann. Ferner kann es auch zu einer Zahl von aufeinanderfolgenden verlorenen
zukünftigen
Paketen führen,
da der weiche Zustand der Headerkomprimierung nun beschädigt ist.
Dies sind die schwersten Fehler, da Bitfehler in einem Paket zu
dem Verlust einer Zahl von nachfolgenden Paketen führen können.
-
Die
konventionellen Headerkomprimierungsalgorithmen sind für ein enges
Band, verdrahtete Kanäle
gemacht, worin die Fehlerrate des Kanals eher stationär und klein
ist. Ferner beeinträchtigt
die Verwendung des Kanals nicht die anderen Benutzer mit ähnlichen
Kanälen.
Dies ist für
einen drahtlosen Kanal nicht der Fall. Die Qualität eines
drahtlosen Kanals kann sich rasch ändern und die Verwendung des Kanals
beeinträchtigt
andere Benutzer im Sinne von Interferenz. In einem Headerkomprimierungsschema für einen
drahtlosen Kanal wird die Wahrscheinlichkeit für Fehler in den komprimierten
Headern groß sein
und der Effekt dieser komprimierten Headerfehler muss reduziert
werden.
-
Es
gibt zwei allgemeine Ansätze,
um dieses Problem zu vermeiden, entweder die Zeit minimieren, die
es braucht, um den weichen Zustand der HC zu aktualisieren, oder
die Wahrscheinlichkeit für
Bitfehler in komprimierten Headern zu minimieren.
-
Ein
bekannter Weg zum Aktualisieren des weichen Zustands der HC besteht
darin, vollständige Header
regelmäßig und
häufig
zu senden. Z.B. kann ein vollständiger
Header in jedem fünften
Sprachpaket gesendet werden, während
komprimierte Header in den anderen Paketen gesendet werden. Falls
ein Kanal mit einer festen Bitrate zu verwenden ist, wird die Bitrate
dieses Kanals typischerweise mit Bezug auf die größte Paketgröße ausgewählt, da
Verzögerungsschwankungen
nicht erwünscht
sind. Daher wird die Bitrate des Kanals gemäß einem Paket mit einem vollständige Header
ausgewählt,
was zu einer Verschwendung von Ressourcen (z.B. Funkressourcen)
führt.
Um Robustheit in einem derartigen Headerkomprimierungsschema zu
erreichen, muss ferner die Häufigkeit
von vollständigen
Headern eher groß sein,
was den Komprimierungsgrad und die Effizienz des Headerkomprimierungsschemas
verringert. Daher werden regelmäßige Aktualisierungen des
Headerkomprimierungszustands mit vollständigen Headern entweder zu
einer ineffizienten Headerkomprimierung oder einer effizienten Headerkomprimierung
ohne die notwendige Robustheit gegenüber z.B. Bitfehlern führen.
-
Ein
anderer Weg, um den weichen Zustand der Headerkomprimierung zu aktualisieren,
besteht für
das Headerkomprimierungsschema darin, eine Aktualisierung des weichen
Zustands zu fordern, wann immer es notwendig ist. Dieser Ansatz
erfordert jedoch einen Duplexkanal mit einer kurzen Rundlaufzeit,
um die Perioden des beschädigten
weichen Zustands klein zu halten. Ferner erfordert ein derartiges Schema
auch, dass der Rückkanal,
der die Aktualisierungsanforderung des weichen Zustands überträgt, allgemein
zuverlässig
ist.
-
Angesichts
des Vorangehenden ist es wünschenswert,
eine Aktualisierung des weichen Zustands eines Headerkomprimierungsschemas
vorzusehen, während
die zuvor erwähnten
Nachteile von Ansätzen
des Standes der Technik vermieden werden.
-
Die
vorliegende Erfindung sieht Aktualisierung des weichen Zustands
eines Headerkomprimierungsschemas in einem Kommunikationssystem
vor, das Paketverkehr überträgt einschließlich eines Echtzeit-Kommunikationssignals.
Der Headerkomprimierungszustand kann während Perioden aktualisiert
werden, wenn das Kommunikationssignal inaktiv ist. Auch sieht eine
Ausführungsform
außerdem Aktualisierung
des Headerkomprimierungszustands durch Entwenden von Bits von dem
Kommunikationssignal vor, um die Headeraktualisierungsinformation
zu übertragen.
Falls das Kommunikationssignal quellencodierte Daten enthält, sieht
eine Ausführungsform
außerdem
Aktualisierung des Headerkomprimierungszustands selektiv basierend
auf der Bitrate eines Codec vor, der die quellencodierten Daten
erzeugt hat. Diese Operation kann Aktualisierung des Headerkomprimierungszustands
ohne Entwenden beliebiger der quellencodierten Daten gestatten.
-
Gemäß einem
ersten Aspekt der vorliegenden Erfindung kann ein Verfahren vorgesehen
werden zum Übertragen
eines Kommunikationssignals von einer ersten Kommunikationsstation
zu einer zweiten Kommunikationsstation, umfassend: während Perioden
von Kommunikationssignalaktivität, Senden
von der ersten Station zu der zweiten Station von Kommunikationssignalpaketen,
die Headerinformation und Kommunikationssignalinformation enthalten;
wobei die erste Station eine Abwesenheit von Kommunikationssignalaktivität erfasst;
und reagierend auf die erste Station, die eine Abwesenheit von Kommunikationssignalaktivität erfasst,
Senden von der ersten Station zu der zweiten Station eines Aktualisierungspaketes,
enthaltend Header aktualisierungsinformation, die durch die zweite
Station verwendet werden kann, um Headerinformation in nachfolgenden
Kommunikationssignalpaketen zu interpretieren, die von der ersten
Station zu der zweiten Station gesendet werden.
-
Gemäß einem
zweiten Aspekt der vorliegenden Erfindung kann eine Kommunikationsvorrichtung vorgesehen
werden zum Übertragen
eines Kommunikationssignals zu einer zweiten Kommunikationsvorrichtung,
umfassend: eine Paketeinheit mit einem Eingang zum Empfangen von
Kommunikationssignalinformation während Perioden von Kommunikationssignalaktivität, und mit
einem Ausgang zum Senden zu der zweiten Vorrichtung von Kommunikationssignalpaketen,
die Kommunikationssignalinformation und Headerinformation enthalten;
eine Headereinheit, die mit der Paketeinheit gekoppelt ist, zum
Vorsehen dazu der Headerinformation und auch zum Vorsehen dazu von
Headeraktualisierungsinformation, die durch die zweite Vorrichtung
verwendet werden kann, um Headerinformation in nachfolgenden Kommunikationssignalpaketen
zu interpretieren, die von der Paketeinheit zu der zweiten Vorrichtung
gesendet werden; und die Paketeinheit, die auf eine Abwesenheit
von Kommunikationssignalaktivität
reagiert, zum Senden von dem Ausgang zu der zweiten Vorrichtung
eines Aktualisierungspaketes, das die Headeraktualisierungsinformation
enthält.
-
Für ein besseres
Verständnis
der vorliegenden Erfindung und um zu zeigen, wie die selbige zur Wirkung
gebracht werden kann, wird nun auf dem Weg eines Beispiels auf die
folgenden Zeichnungen verwiesen, in denen:
-
1 ein
beispielhaftes Paketformat veranschaulicht, das in Verbindung mit
der vorliegenden Erfindung verwendet werden kann;
-
1A ein
Schattierungsschlüssel
zur Verwendung mit 1 ist;
-
2 und 3 schematisch
Beispiele von DTX- (diskontinuierliche Übertragung, Discontinuous Transmission)
Schemata veranschaulicht, die durch konventionelle Sprachcodecs
implementiert werden;
-
4 und 5 beispielhafte
Arten veranschaulichen, auf denen die konventionellen DTX-Operationen
von 2 und 3 genutzt werden können, um
Aktualisierungsinformation eines weichen Zustands von Headerkomprimierung
zu übertragen;
-
5A ein
Schattierungsschlüssel
zur Verwendung mit 2–5 ist;
-
6 beispielhafte
Operationen veranschaulicht, die mit den Headerkomprimierungs-Aktualisierungsschemata
in Verbindung stehen, die in 4 und 5 veranschaulicht
sind;
-
7 Beispiele
von Bitentwendungsoperationen schematisch veranschaulicht, um Aktualisierungen
eines weichen Zustands von Headerkomprimierung zu gestatten;
-
7A ein
Schattierungsschlüssel
zur Verwendung mit 7 ist;
-
8 beispielhafte
Operationen veranschaulicht, die mit dem Bitentwendungsschema von 7 in
Verbindung stehen;
-
9 ein
beispielhaftes Paket veranschaulicht, das in Verbindung mit den
DTX-Aktualisierungsschemata von 4 und 5 verwendet
werden kann;
-
10 ein
beispielhaftes Paket veranschaulicht, das in Verbindung mit dem
Bitentwendungsschema von 7 verwendet werden kann;
-
11 beispielhafte
Operationen veranschaulicht, die in Unterstützung von weicher Aktualisierung
von HC durchgeführt
werden können,
wenn Pakete empfangen werden;
-
12 passende
Abschnitte einer beispielhaften Kommunikationsstation veranschaulicht;
-
13 beispielhafte
Operationen veranschaulicht, die in Unterstützung von weicher Aktualisierung
von HC durchgeführt
werden können,
wenn die Paketnutzlastinformation quellencodierte Daten enthält.
-
Beispielhafte
Ausführungsformen
der Erfindung können
mit DTX-Techniken
kooperieren, die in den meisten konventionellen digitalen Sprachdiensten
verwendet werden. DTX (diskontinuierliche Übertragung) umfasst Techniken
zum Erfassen von Nicht-Sprache-
(stummen) Perioden und Senden nur von Ruhedeskriptoren (SID-Rahmen)
während
dieser Perioden, um Komfortrauschen in dem empfangenden Ende zu
erzeugen. Dieses Komfortrauschen sieht die Illusion kontinuierlicher Übertragung
von Klang vor. Während
Nicht-Sprachperioden haben somit die übertragenen Pakete ein Format,
das dem in 1 gezeigten ähnlich ist, mit Ausnahme dessen, dass
der Nutzlastabschnitt (in 12 und 13) einen SID-Rahmen
enthält. 2 und 3 zeigen
konventionelle DTX-Schemata, nämlich
die ursprüngliche
DTX (2) und die sogenannte weiche DTX (3).
-
Gemäß einer
beispielhaften Ausführungsform
der vorliegenden Erfindung kann Headeraktualisierungsinformation
einem SID-Rahmen
von 2 hinzugefügt
werden oder kann einen SID-Rahmen von 2 ersetzen.
In GSM werden z.B. SID-Rahmen (siehe 21 in 2)
regelmäßig während Ruheperioden übertragen
(einmal alle 0,48 Sekunden). Die gewünschte Aktualisierung des Headerkomprimierungszustands
kann durch Senden der Headeraktualisierungsinformation, z.B. eines
vollständigen Headers,
zusammen mit (siehe 41) oder an Stelle von (siehe 42)
einem SID-Rahmen bewerkstelligt werden, wie in 2 und 4 gesehen
wird. In einer anderen Ausführungsform
wird die Aktualisierung vom Headerkomprimierungszustand in Verbindung mit
der konventionellen weichen DTX-Technik erreicht (wie in "Continuous and Dis-Continuous
Power Reduced Transmission of Speech Inactivity for the GSM System", Stefan Bruhn et
al., GlobeCom 98 beschrieben), was in 3 veranschaulicht
wird. Die weiche DTX-Technik macht es möglich, während Nicht-Sprachperioden einen Strom geringer
Bitrate von SID-Rahmen 31 zu realisieren, der nicht viel
Interferenz mit anderen Verknüpfungen
einführt.
Daher könnte
weiche DTX verwendet werden, um Headeraktualisierungsinformation
während
Nicht-Sprachperioden
zu übertragen,
wie in 5 gezeigt wird.
-
Ein
Beispiel der oben beschriebenen Verwendung von DTX, um Aktualisierungen
vom weichen Zustand von HC vorzusehen, wird in 6 gezeigt.
Wenn eine Aktualisierung in 61 erwünscht wird, wird in 62 bestimmt,
ob eine DTX-Operation auftritt. Falls ja, dann wird die Headeraktualisierungsinformation
in 63 gesendet, entweder zusätzlich zu den SID-Rahmen (siehe 5 und 41 von 4)
oder an Stelle eines SID-Rahmens (siehe 42 in 4).
-
In
konventioneller Videokodierung gibt die übertragende Station eine Sequenz
von Rahmen aus, die jeder z.B. Information enthalten, die eine Differenz
zwischen einem aktuellen eingefangenen Bild und dem Bild, das unmittelbar
vor dem aktuellen Bild eingefangen wird, anzeigt. Während Perioden,
wenn sich das Bild, das in der übertragenden
Station gesehen wird, nicht ändert,
sendet die übertragende
Station Rahmen eines "statischen
Bildes", die anzeigen, dass
sich das aktuellen Bild von dem unmittelbar vorangehenden Bild nicht
unterscheidet (oder mindestens nicht über eine vorbestimmte Grenze
hinaus unterscheidet). Die Rahmen des "statischen Bildes" sind somit allgemein den zuvor erwähnten SID-Rahmen
dadurch analog, dass sie mit Perioden eines "statischen Video" in Verbindung stehen, worin keine (oder
keine wesentliche) Bildänderung
auftritt. Entsprechend sind die Techniken, die oben mit Bezug auf 2–6 beschrieben
werden, auch auf Videopaketausführungsformen
anwendbar, wobei die Headeraktualisierungsinformation entweder zusätzlich zu
den Rahmen eines "statischen
Bildes" oder an Stelle
eines Rahmens eines "statischen
Bildes" während einer
Periode eines "statischen
Video" gesendet wird.
-
Weitere
beispielhafte Ausführungsformen der
Erfindung ersetzen außerdem
Paketnutzlastbits, z.B. Sprachrahmenbits, Videorahmenbits oder Nutzlastbits,
die beliebige gewünschte
Information darstellen, mit Headerkomprimierungszustands-Aktualisierungsinformation.
Falls der Headerkomprimierungszustand beschädigt ist (z.B. wegen Bitfehlern
in vorherigen komprimierten Headern), werden die Nutzlastbits (siehe
z.B. 12 und 13 in 1) nicht
zu der Anwendungsschicht abgegeben, bis der Headerkomprimierungszustand
wiederhergestellt ist. Bis der Headerkomprimierungszustand wiederhergestellt
ist, sind daher die Nutzlastbits auf jeden Fall nutzlos. Unter Verwendung
von Sprachrahmen als eine Nutzlastbeispiel können durch Ersetzen irgendeines
Teils der Sprachdaten durch Headerkomprimierungsaktualisierungsinformation
unmittelbar zukünftige Sprachrahmen
zu der Anwendungsschicht abgegeben werden. Teile eines Sprachrahmens
oder der gesamte Sprachrahmen können
mit Headeraktualisierungsinformation ersetzt werden. Dieser Austausch von
Nutzlastbits wird auch als "Bitentwendung" bezeichnet, da Nutzlastbits "entwendet" und stattdessen
verwen det werden, um Headeraktualisierungsinformation zu übertragen.
-
Wenn
entschieden wird, welche Sprachrahmenbits mit Headeraktualisierungsinformation
zu ersetzen sind, können
die Charakteristika des Sprachcodecs in Betracht gezogen werden.
Die meisten konventionellen Sprachcodecs klassifizieren ihre Ausgabebits
nach relativer Wichtigkeit. Wie z.B. oben erwähnt, hat der Sprachcodec voller
Rate von GSM drei Klassen von Bits mit unterschiedlicher Wichtigkeit:
Klasse 1A, 1B und Klasse 2. Bits von Klasse 1A sind die wichtigsten,
und Bits von Klasse 2 sind die am wenigsten wichtigen. Somit würden Headeraktualisierungsinformationsbits
Bits von Klasse 2 ersetzen, wo verfügbar, da diese Bits für die resultierende
Sprachqualität
am wenigsten wichtig sind. 7 zeigt
Beispiele davon, wie dies bewerkstelligt werden kann.
-
In 71 in 7 werden
alle Bits mit Ausnahme der wichtigsten Bits entwendet, und in 72 werden
alle Bits entwendet. Bei Betrachtung der Aktualisierungen, die in 73 und 74 gezeigt
werden, werden weniger Bits für
eine längere
Zeit in 73 entwendet, während
mehr Bits für
eine kürzere
Zeit in 74 entwendet werden.
-
Obwohl
die Bitentwendungstechniken zum Auswählen unter Bits variierender
Grade von Wichtigkeit oben mit Bezug auf das Beispiel eines Sprachcodecs
beschrieben werden, der seine Ausgabebits nach relativer Wichtigkeit
klassifiziert, sind diese Bitentwendungstechniken auf einen beliebigen
Typ eines Codecs anwendbar, der seine Ausgabebits nach relativer
Wichtigkeit klassifiziert. Ein Video-Codec ist auch für diesen
Typ eines Codecs beispielhaft.
-
In
Ausführungsformen,
wo die Nutzlast quellencodierte Daten enthält, kann der weiche Zustand von
Headerkomprimierung außerdem
in Verbindung mit Variationen der Bitrate eines Codecs, der die quellencodierten
Daten erzeugt hat, und ohne Entwenden beliebiger der quellencodierten
Datenbits aktualisiert werden. Z.B, senkt ein konventioneller Codec,
wie etwa ein Sprach- oder Video-Codec, typischerweise seine Bitrate
aus zwei beispielhaften Gründen
ab: (1) der Codec kann seine Bitrate an Kanalbedingungen anpassen
(sogenannter Kanaladaptivmodus), wobei die Bitrate abgesenkt wird,
wenn der Kanal verstopft ist; und (2) der Codec kann seine Bitrate
an das Verhalten der Quelle anpassen (sogenannter Quellenadaptivmodus),
wobei seine Bitrate abgesenkt wird, wenn die Quelle (z.B. ein Sprach- oder
ein Video-Codec) weniger Quellenanregungsinformation (d.h. mehr
Perioden von Stille oder "statisches
Video") erzeugt.
Die abgesenkte Bitrate im Quellenadaptivmodus ist zum Senden von
Headeraktualisierungsinformation vorteilhaft, da weniger Bits verwendet
werden, um die Quellenanregung darzustellen, wobei mehr Bits belassen
werden, um für
Headeraktualisierungsinformation verwendet zu werden.
-
13 veranschaulicht
beispielhafte Operationen, die durchgeführt werden können, um
die oben beschriebene Verwendung einer abgesenkten Codec-Bitrate
zu implementieren, um Aktualisierungen vom weichen Zustand von Headerkomprimierung
in quellencodierten Datenpaketausführungsformen zu unterstützen, z.B.
Sprach- oder Videopaket-Ausführungsformen.
Wenn eine Aktualisierung eines weichen Zustands von HC in 121 gewünscht wird,
wird danach in 122 bestimmt, ob die Codec-Bitrate unter einem
Schwellenpegel TH ist. Der Schwellenpegel TH kann empirisch bestimmt
werden, um gewünschtes
Leistungsverhalten bereitzustellen. Falls die Codec-Bitrate in 122 unter
TH ist, dann kann Headeraktualisierungsinformation in 126 in
einem Paket zusammen mit den quellencodierten Daten gesendet werden.
-
Falls
in 122 die Codec-Bitrate nicht unter TH ist, dann kann
in 124 bestimmt werden, ob der Codec anzuweisen ist oder
nicht, seine Bitrate unter TH abzusenken. Falls ja, dann wird der
Codec in 125 angewiesen, seine Bitrate unter TH abzusenken,
und die Headeraktualisierungsinformation kann in 126 in
einem Paket zusammen mit den quellencodierten Daten gesendet werden.
In Ausführungsformen,
wo der Codec nicht anzuweisen ist, seine Bitrate abzusenken, kann
die Operation von 124 zurück zu 122 fließen.
-
Nachdem
Headeraktualisierungsinformation in 126 gesendet ist, kann
die Codec-Bitrate in 127 wiederhergestellt werden, falls
erforderlich (d.h. falls sie in 125 abgesenkt wurde).
-
Eine
Ausführungsform
der Erfindung stellt auch teilweise Aktualisierung des Headerkomprimierungszustands
bereit. Z.B. kann entschieden werden, nur ein Feld (oder wenige
Felder) in dem Header zu einer gegebenen Zeit zu aktualisieren.
Falls ein gegebener Sprachrahmen nicht genug Bits zum Entwenden
verfügbar
hat, um eine vollständige
Headerzustandsaktualisierung zu gestatten, dann würde als ein
spezifisches Beispiel vielleicht nur die RTP-Sequenzzahl des RTP-Anteils
eines IP/UDP-/RTP-Headers in diesem Sprachrahmen aktualisiert. Die
Verwendung von weniger Bits, um teilweise Aktualisierungsinformation
zu senden, kann in einigen Fällen eine
ausreichende Aktualisierung eines weichen Zustands von HC bereitstellen,
kann aber in anderen Fällen
bewirken, dass ein Abschluss der gewünschten Aktualisierung mehr
Zeit braucht (siehe z.B. 73 in 7).
-
8 veranschaulicht
beispielhafte Operationen, die durchgeführt werden können, um
ein Bitentwendungsschema zu implementieren. Falls eine Aktualisierung
in 81 gewünscht
wird, wird in 82 bestimmt, ob genug Bits verfügbar sind
um entwendet und verwendet zu werden, um die vollständige Headeraktua lisierungsinformation
zu senden. Falls ja, dann werden in 83 die Bits entwendet
und verwendet, um die vollständige
Headeraktualisierungsinformation zu senden. Falls nicht genug Bits
in 82 verfügbar sind,
z.B. nicht genug Sprachbits von Klasse 2 in GSM, oder nicht genug
Nutzlastbits insgesamt, dann werden in 84 die verfügbaren Bits
entwendet und verwendet, um einen Teil der Headeraktualisierungsinformation
zu senden.
-
Wie
durch unterbrochene Linien in 6, 8 und 13 gezeigt,
können
die jeweiligen Operationen, die darin gezeigt werden, verschieden kombiniert
werden. Z.B. können
in Sprach- oder Video-Ausführungsformen,
falls eine Aktualisierung in 6 gewünscht wird,
aber eine DTX- (oder "statisches
Video") Operation
in 62 nicht auftritt, dann entweder die Bitentwendungsoperation
von 8 oder die auf den Codec bezogenen Operationen
von 13 durchgeführt
werden. Als ein anderes Beispiel können, falls die Operationen
von 13 nicht zum Senden von Headeraktualisierungsinformation führen, dann
entweder die Bitentwendungsoperationen von 8 oder die
Operationen von DTX/"statisches
Video" von 6 durchgeführt werden.
Die Entscheidung, ob eine Aktualisierung gewünscht wird (siehe 61, 81 und 121),
kann unter Verwendung konventioneller Kriterien durchgeführt werden.
-
Bezug
nehmend erneut auf die Aktualisierungstechniken von DTX/"statisches Video" von 4 und 5,
wird ein Beispiel eines Paketes, das die Aktualisierungsinformation
enthält,
die während
der Periode Nicht-Sprache/"statisches
Video" gesendet
wird, in 9 gezeigt. Das beispielhafte Paket
von 9 enthält
einen konventionellen Header (komprimiert oder nicht), ein Aktualisierungstag des
weichen Zustands 91 und einen Headeraktualisierungsinformationsanteil 93.
Das Aktualisierungstag des weichen Zustands 91 macht es
für eine
Kommunikationsstation, die das Paket von 9 empfängt, möglich zu
erkennen, dass das Paket Headeraktualisierungsinfor mation 93 enthält, wodurch
die empfangende Kommunikationsstation das Paket von 9 nicht
als ein konventionelles Sprach- (oder Video-) Paket oder ein konventionelles
SID- (oder "statisches Bild") Rahmenpaket missverstehen
wird. Wie durch unterbrochene Linien in 94 in 9 gezeigt, können die
Headeraktualisierungsinformation 93 und das Tag 91 auch
in einem Paket mit einem SID- (oder "statisches Bild") Rahmen enthalten sein, wie oben mit
Bezug auf 5 und 41 von 4 erörtert wird.
-
10 veranschaulicht
ein Beispiel eines Paketes, das verwendet werden kann, um die Headeraktualisierungsinformation
zu übertragen,
wenn die Technik zum Entnehmen von Nutzlastbits und ihr Verwenden,
um die Headeraktualisierungsinformation zu übertragen, verwendet wird.
Das Paket von 10 enthält einen konventionellen Header
(komprimiert oder nicht), ein Aktualisierungstag eines weichen Zustands 110 und
Headeraktualisierungsinformation 111. Das Tag 110 ist
so vorgesehen, dass eine empfangende Kommunikationsstation erkennen wird,
dass das Paket von 10 Headeraktualisierungsinformation
zusätzlich
zu (oder an Stelle von) Nutzlastdaten enthält. Das Beispiel von 10 zeigt in
unterbrochenen Linien an, dass ein Anteil 112 der Nutzlast,
z.B. die signifikantesten Sprachcodecbits in 12 von 1,
in dem Paket zusammen mit der Headeraktualisierungsinformation 111 enthalten
sein können.
-
Das
Paket von 10 ist auch für ein Paket beispielhaft,
das verwendet werden kann, um Headeraktualisierungsinformation gemäß der auf
einen Codec bezogenen Technik von 13 zu übertragen.
In diesem Fall kann die gesamte Nutzlast in 112 enthalten
sein, da die Schwelle TH für
die abgesenkte Codecbitrate wie benötigt eingestellt werden kann, um
zu gestatten, dass die Headeraktualisierungsinformation 111 hinzu gefügt (eingefügt) wird,
ohne beliebige Nutzlast- (d.h. quellencodierte Daten) Bits zu entnehmen.
-
11 veranschaulicht
beispielhafte Operationen, die in Unterstützung von Aktualisierung eines weichen
Zustands von HC durchgeführt
werden können,
wenn Pakete empfangen werden. Nachdem ein Paket in 101 empfangen
ist, wird in 103 bestimmt, ob das Paket ein Aktualisierungstag
eines weichen Zustands (z.B. in 91 in 9 oder 110 in 10)
enthält
oder nicht. Falls nicht, gibt es keine Aktualisierung eines weichen
Zustands von HC. Falls ja, dann wird die Headeraktualisierungsinformation
(siehe 93 in 9 oder 111 in 10)
in 104 abgerufen und in 105 verwendet, um die
Aktualisierung eines weichen Zustands von HC durchzuführen.
-
12 veranschaulicht
entsprechende Abschnitte von beispielhaften Ausführungsformen einer Kommunikationsstation,
die zum Durchführen
der beispielhaften Operationen fähig
ist, die oben mit Bezug auf 1–11 und 13 beschrieben
werden. Die beispielhafte Kommunikationsstation von 12 kann
eine drahtlose Station sein, z.B. ein mobiler Funktransceiver, wie
etwa ein zellulares Telefon, oder ein Funktransceiver festen Standorts.
Die Kommunikationsstation von 12 kann
auch eine drahtgebundene Kommunikationsstation zur Verwendung mit
Drahtkanälen
sein, z.B. ein Host für
eine Videokonferenz.
-
Die
Kommunikationsstation von 12 enthält einen
Kommunikationsport 131 zum Bereitstellen substanzieller
Information (z.B. Sprach- oder Videoinformation) zu einer Paketeinheit 132,
und zum Empfangen substanzieller Information von der Paketeinheit 132.
Der Kommunikationsport 131 stellt auch Headerinformation
einer Headereinheit 133 bereit. Die Headereinheit 133 kann
konventionelle Techniken verwenden, um Header (komprimiert oder
nicht) aus der Headerinformation zu erzeugen, die durch den Kommunikationsport 131 bereitgestellt wird.
Die Headereinheit 133 stellt ausgehende Header der Paketeinheit 132 bereit,
und empfängt
auch eingehende Header von der Paketeinheit 132.
-
Die
Paketeinheit 132 ist konventionell betriebsfähig, die
Headerbits, die von der Headereinheit 133 empfangen werden,
und die substanziellen Informationsbits (d.h. Nutzlastbits), die
von dem Kommunikationsport 131 empfangen werden, zusammenzubauen,
um ein ausgehendes Paket zu bilden, wie z.B. in 1 veranschaulicht.
Die Paketeinheit 132 kann dann das zusammengebaute Paket
zu einer Funkeinheit 134 weiterleiten, die das Paket über eine Funkverknüpfung 135 überträgt. In anderen
Ausführungsformen
(z.B. einem Host für
Videokonferenzen) kann die Paketeinheit 132 Pakete zu einem
Drahtkommunikationskanal ausgeben (z.B. einem Datennetz, wie etwa
dem Internet), wie in unterbrochenen Linien gezeigt. Die ausgehenden
Pakete in 12 können durch eine Empfangsstation
(nicht gezeigt) empfangen werden, die z.B. eine Struktur und Funktionalität analog
zu der Kommunikationsstation von 12 aufweisen
kann.
-
Die
Paketeinheit 132 empfängt
von der Funkeinheit 134 auch eingehende Pakete, die durch
die Funkeinheit über
die Funkverknüpfung 135 empfangen
werden. Die Paketeinheit 132 zerlegt konventionell die
eingehenden Pakete und stellt die substanzielle Information von
jedem eingehenden Paket dem Kommunikationsport 131 für eine konventionelle
Verwendung bereit. Die Paketeinheit stellt auch die Header von den
eingehenden Paketen der Headereinheit 133 bereit, die sie
je nach Notwendigkeit unter Verwendung konventioneller Techniken
dekomprimiert, und dann die Headerinformation zu dem Kommunikationsport 131 weiterleitet.
-
Die
Paketeinheit 132 kann auch von dem Kommunikationsport 131 eine
DTX-Angabe (d.h. keine Sprachaktivität) oder eine Angabe "statisches Video" (d.h. keine Videoaktivität) empfangen,
worauf die Paketeinheit 132 durch Ausgeben von Paketen antworten
kann, die SID-/"statisches
Bild" Rahmen enthalten,
wie allgemein in 2 und 3 gezeigt.
-
Die
Paketeinheit kann auch mit einem Codec (nicht gezeigt) kommunizieren,
um von dort Bitrateninformation zu empfangen und dorthin Anweisungen bereitzustellen,
die Bitrate abzusenken/wiederherzustellen, wie oben mit Bezug auf 13 beschrieben.
-
Die
Headereinheit 133 ist gekoppelt, um Headeraktualisierungsinformation
mit der Paketeinheit 132 auszutauschen, und um der Paketeinheit 132 zu
signalisieren, wenn es gewünscht
wird, Headeraktualisierungsinformation in einem ausgehenden Paket
zu senden. Als Reaktion auf Empfang eines Signals, Headeraktualisierungsinformation
in einem ausgehenden Paket zu senden, kann die Paketeinheit 132 die
Operationen durchführen,
die in 6 veranschaulicht sind, entweder einzeln oder
in Kombination mit den Operationen, die in 8 und 13 veranschaulicht
sind, je nach Wunsch, wie oben erörtert wird. Es kann ein Paket,
wie etwa in 9 veranschaulicht, erzeugt werden,
falls eine Operation von DTX/"statisches
Video" auftritt,
und es kann ein Paket erzeugt werden, wie etwa in 10 veranschaulicht,
falls eine DTX-Operation nicht auftritt.
-
Wenn
die Kommunikationsstation von 12 ein
eingehendes Paket empfängt,
kann sie die beispielhaften Operationen durchführen, die in 11 veranschaulicht
sind. Wenn die Paketeinheit 132 ein Aktualisierungstag
erfasst, wie etwa in 91 in 9 oder 110 in 10 veranschaulicht,
kann die Paketeinheit die Headeraktualisierungsinformation abrufen,
und diese Headeraktualisierungsinformation der Headereinheit 133 zusammen
mit einem Signal bereitstellen, das die Header einheit lenkt, den
weichen Zustand von HC zu aktualisieren. Falls z.B. die Headeraktualisierungsinformation
einen vollständigen
Header enthält,
kann die Headereinheit dann den vollständigen Header auf eine konventionelle Weise
verwenden, um ihre Headerkomprimierungszustandsmaschine (nicht gezeigt)
zurückzusetzen (d.h.
zu aktualisieren).
-
Einem
Techniker wird offensichtlich sein, dass die oben beschriebene Erfindung
durch geeignete Modifikationen in Hardware, Software oder beiden
in z.B. einem Paketkommunikationsabschnitt einer konventionellen
drahtlosen oder drahtgebundenen Kommunikationsstation implementiert
sein kann.
-
Wie
aus der vorangehenden Erörterung
gesehen wird, stellt die vorliegende Erfindung die folgenden beispielhaften
Vorteile gegenüber
dem Stand der Technik bereit: eine kontinuierliche Aktualisierung des
Headerkomprimierungszustands kann mit einem Kanal konstanter Bitrate
auf eine ressourceneffiziente Weise realisiert werden; die Zeit,
während
der das Headerkomprimierungsschema in einem beschädigten Zustand
ist, wird auf eine ressourceneffiziente Weise reduziert; und die
Zahl von verlorenen Paketen wegen dem beschädigten Headerkomprimierungszustand
wird reduziert, wodurch die Qualität von Echtzeitdiensten verbessert
wird.
-
Obwohl
beispielhafte Ausführungsformen der
vorliegenden Erfindung oben detailliert beschrieben wurden, begrenzt
dies nicht den Bereich der Erfindung, die in einer Vielfalt von
Ausführungsformen praktiziert
werden kann.