-
Technisches
Gebiet
-
Die
Erfindung bezieht sich allgemein auf Kommunikationen unter Verwendung
von Mehrraten-Codecs.
-
Hintergrund
-
Paket-basierte
Datennetzwerke werden in weitem Umfang zur Verbindung verschiedener
Arten von Netzwerkelementen verwendet, wie z.B. Personalcomputern,
Servern, Netzwerk-Telefonen, Internet-Anwendungsgeräten usw.
Beispiele von Datennetzwerken schließen private Netzwerke (wie
z.B. lokale oder Ortsbereichs-Netzwerke oder Weitbereichs-Netzwerke)
und öffentliche
Netzwerke (wie z.B. das Internet) ein. Übliche Formen von Kommunikationen
zwischen Netzwerkelementen über
Paket-basierte Datennetzwerke hinweg schließen elektronische Post, die
Dateiübertragung,
das Web-Browsen und andere Datenaustauschvorgänge ein. In letzterer Zeit
werden mit der zunehmenden Kapazität und Zuverlässigkeit
von Paket-basierten Daten-Netzwerken Audio-Kommunikationen (wie z.B. Sprachkommunikation),
Video-Kommunikation (wie z.B. Videokonferenzen) und andere Formen
von interaktiven oder Datenstrom-Echtzeit-Kommunikationen über paketbasierte
Daten-Netzwerke üblicher.
-
Mit
den Fortschritten bei drahtlosen Kommunikationsnetzwerken wurden
auch effiziente Paket-basierte Kommunikationen über drahtlose Netzwerke möglich. Traditionell
wurden drahtlose Kommunikationsnetzwerke als leitungsvermittelte
Netzwerke realisiert. In einem leitungsvermittelten Netzwerk wird
ein Kanal zwischen zwei Endpunkten (beispielsweise zwischen zwei
mobilen Einheiten) für
die Dauer der Verbindung zwischen den Endpunkten belegt. Eine derartige
Verbindung ist für
Kommunikationen, die relativ kontinuierlich sind, wie z.B. Sprache,
optimal. Leitungsvermittelte Netzwerke sind jedoch für Paket-basierte
Kommunikationen, wie z.B. E-Mail, Web-Suche und dergleichen wenig
effizient.
-
Es
wurden verschiedene Paket-basierte drahtlose Protokolle vorgeschlagen,
um effizientere Verbindungen zwischen einer Mobilstation und einem
Paket-basierten Datennetzwerk, wie z.B. einem Internetprotokoll-(IP-)Netzwerk
zu schaffen. Ein derartiges Protokoll ist das allgemeine Paketfunkdienst-(GPRS-)Protokoll, das
vorhandene GSM-(globale Mobilfunksystem-)Kommunikationssysteme ergänzt. Andere
Technologien, die auf GPRS aufbauen, sind die weiterentwickelte
GPRS-(EGPRS-)Technologie
(die auch als verbesserte Datenrate für globale Entwicklung oder
EDGE bekannt ist) und die EGPRS COMPACT-(oder EDGE COMPACT-)Technologie,
die hohe Datenraten bieten und GSM- und IS-136-Systeme ergänzen. Eine
andere Art von drahtlosem Netzwerk, das effiziente Paket-basierte
Kommunikationen unterstützen
kann, ist das drahtlose UMTS-(Universelles Mobiles Telekommunikationssystem-)Netzwerk,
das auf dem Breitband-Codemultiplex-Vielfachzugriffs-(W-CDMA-)Protokoll
beruht.
-
Sprache
und andere Formen von interaktiven Echtzeit-Kommunikationen über ein
Paket-basiertes Netzwerk (drahtgebunden oder drahtlos) sind gegenüber Verzögerungen
in Paketen oder gegenüber
dem Verlust von Paketen empfindlich. In Abhängigkeit von dem Nutzungsgrad
können
sich Paketverzögerungen
und die Rate des Paketverlustes in einem paketbasierten Netzwerk
sehr stark ändern.
Sprachpakete, die aufgrund von ungeeigneter oder nicht-verfügbarer Kapazität eines
Paket-basierten Netzwerkes (drahtgebunden oder drahtlos) verlorengehen
oder verzögert
werden, können
zu Lücken,
zu einer Sprachpause und zu einer Begrenzung des Audiosignals an
dem Empfangsende führen.
-
Um
einen gewissen Grad der Qualität
bestimmter Arten von Kommunikationen, wie z.B. Sprache oder andere
interaktive Echtzeit-Kommunikationen, sicherzustellen, können Dienstgüte-(QoS-)Mechanismen
realisiert werden. Bestimmte Arten von Verkehr, wie z.B. elektronische
Post oder Web-Browsing-Verkehr haben eine relativ geringe QoS-Anforderung
(d.h. derartige Kommunikationen sind gegenüber Transport-Verzögerungen
und gegenüber
dem Paketverlust stärker
tolerant), während
interaktive Sprach- und andere Echtzeit-Kommunikationen relativ
hohe QoS-Anforderungen stellen.
-
Die
Zuteilung von übermäßigen Ressourcen
zu interaktiven Sprach- oder anderen Echtzeit-Kommunikationen kann
jedoch dazu führen,
dass die Betriebsleistung anderer Arten von Kommunikationen leidet,
wie z.B. die elektronische Post oder Web-Browsing-Kommunikationen.
Andererseits kann die Zuteilung von zu wenig Ressourcen zu interaktiven
Echtzeit-Kommunikationen eine verringerte Betriebsleistung derartiger
Kommunikationen hervorrufen. Als Ergebnis besteht weiterhin ein
Bedarf für
ein Verfahren und eine Vorrichtung zum Ausgleich der Notwendigkeiten
von Kommunikationen mit hohen QoS-Anforderungen, wie z.B. interaktiven
Echtzeit-Kommunikationen mit den Notwendigkeiten anderer Arten von
Kommunikationen über
ein gemeinsam genutztes Transportmedium.
-
Das
US-Patent 5 537 410 beschreibt ein leitungsvermitteltes drahtloses
CDMA-Zellularsystem,
bei dem variable Datenraten über
eine drahtlose Verbindungsstrecke zwischen einem Sender und einem
Empfänger
möglich
sind. Die Datenraten-Information ist in jedem Rahmen enthalten,
der von dem Sender zu dem Empfänger übertragen
wird, so dass der Empfänger
die Datenrate kennt, mit der ein nachfolgender Rahmen zu verarbeiten
ist.
-
Zusammenfassung
-
Es
wird ein Verfahren gemäß Anspruch
1, ein Computerprogramm-Produkt gemäß Anspruch 14 und ein System
gemäß Anspruch
26 geschaffen.
-
Allgemein
umfasst gemäß einer
Ausführungsform
ein Verfahren zur Kommunikation das Bestimmen von einer von mehreren
Raten zum Codieren von Daten zur Kommunikation über ein paketvermitteltes Netzwerk
und das Einkapseln der Daten in ein Paket, das ein Dienstgüte-Anzeigefeld
aufweist. Einer von mehreren Werten wird für das Dienstgüte-Anzeigefeld
auf der Grundlage der bestimmten einen von mehreren Raten eingesetzt.
Das Dienstgüte-Anzeigefeld
spezifiziert eine Dienstgüte-Anforderung
für paketvermittelte
Kommunikationen, wobei das Dienstgüte-Anzeigefeld den Betrieb
von einem oder mehreren Routern in dem paketvermittelten Netzwerk
beeinflusst.
-
Einige
Ausführungsformen
der Erfindung können
einen oder mehrere der folgenden Vorteile haben. Eine effizientere
Bereitstellung von Ressourcen eines paketbasierten Netzwerkes, drahtgebunden
oder drahtlos, kann auf der Grundlage von Dienstgüte-Anforderungen
für Kommunikationen
von unterschiedlichen Arten von Verkehr (beispielsweise Sprachverkehr,
Verkehr besten Bemühens,
usw.) bereitgestellt werden. Durch Einstellen der Dienstgüte-Anforderungen
auf der Grundlage von Kriterien, wie z.B. der Rate der Audiodaten-Codierung,
kann eine effizientere Nutzung des paketbasierten Netzwerkes erzielt
werden, weil Ressourcen, die nicht benötigt werden, nicht zugeteilt
werden. Durch die effizientere Nutzung von Ressourcen eines gemeinsam
genutzen Transportmediums kann die effektive Bandbreite für den gesamten
Verkehr auf dem gemeinsam genutzten Transportmedium vergrößert werden.
-
Andere
oder alternative Merkmale und Vorteile werden aus der folgenden
Beschreibung, aus den Zeichnungen und aus den Ansprüchen ersichtlich.
-
Kurze Beschreibung
der Zeichnungen
-
1 ist
ein Blockschaltbild einer Ausführungsform
des Kommunikationssystems.
-
2 ist
ein Blockschaltbild von Komponenten eines Nutzer-Gerätes oder
eines Systems zur Verwendung in dem Kommunikationsnetzwerk nach 1.
-
3 ist
ein Ablaufdiagramm, das Aufgaben zeigt, die von dem Nutzer-Gerät nach 1 ausgeführt werden.
-
4 zeigt
einen Mitteilungs-Datenfluss zwischen den verschiedenen Einheiten
in dem Kommunikationsnetzwerk nach 1.
-
5 ist
ein Blockschaltbild eines Ablaufsteuerungs- und Warteschlangen-Mechanismus zur Verwendung
in einem oder mehreren Knoten in dem Kommunikationsnetzwerk nach 1.
-
6 zeigt
ein Koordinatensystem zur Darstellung der Bedeutung (I) der Dringlichkeit
(U) und der Bandbreite (B).
-
Ausführliche
Beschreibung
-
In
der folgenden Beschreibung sind vielfältige Einzelheiten angegeben,
um ein Verständnis
der vorliegenden Erfindung zu schaffen. Es ist jedoch für den Fachmann
verständlich,
dass die folgende Erfindung ohne diese Einzelheiten ausgeführt werden
kann, und dass vielfältige
Abänderungen
oder Modifikationen der beschriebenen Ausführungsformen möglich sind.
-
Gemäß 1 schließt ein Kommunikationsnetzwerk 10 ein
paketbasiertes Daten-Netzwerk 24 ein, das
mit verschiedenen Geräten
und Systemen gekoppelt ist, um Kommunikationen zwischen diesen Geräten und
Systemen zu ermöglichen.
Ein System, das mit dem Netzwerk 24 gekoppelt ist, ist
ein drahtloses Kommunikationssystem 11, das aus Elementen
aufgebaut ist, die Kommunikationen zwischen mobilen Stationen 16, 17 und
dem Netzwerk 24 ermöglichen.
Das drahtlose Kommunikationssystem 11 schließt eine
Anzahl von Zellen 12 ein, die jeweils einer Basisstation 14 zugeordnet
sind. Jede Basisstation kommuniziert mit einer mobilen Station 16 oder 17 über eine
drahtlose Verbindungsstrecke. Beispiele der mobilen Stationen 16, 17 schließen Mobiltelefone,
Mobil-Computer, persönliche
digitale Assistenten usw. ein.
-
Die
Basisstationen 14 sind mit einem oder mehreren Funkzugangs-Netzwerk-(RAN-)Steuerungen 18 gekoppelt.
Beispielsweise können
die RAN-Steuerungen 18 Basisstations-Steuerungen (BSC's) oder andere Arten
von Steuerungen sein. Bei einer Ausführungsform ist die RAN-Steuerung 18 mit
einem die Diensteversorgung übernehmenden
GPRS-(allgemeiner Paketfunkdienst)Unterstützungsknoten (SGSN) 20 gekoppelt. Der
SGSN 20 steuert die Herstellung, Verarbeitung und Beendigung
von paketbasierten Kommunikationen mit mobilen Stationen 16, 17.
Der SGSN 20 ist mit einem Überleiteinrichtungs-(Gateway-)GPRS-Unterstützungsknoten
(GGSN) 22 gekoppelt, der als die Überleiteinrichtung zwischen
dem drahtlosen Kommunikationssystem 11 und dem paketbasierten
Netzwerk 24 wirkt. Gemeinsam werden die RAN-Steuerung 18,
der SGSN 20 und der GGSN 22 als ein „drahtloses
Zugangsnetzwerk 19" bezeichnet.
-
Der
SGSN 20 und der GGSN 22 verhalten sich entsprechend
entweder gemäß dem EGPRS-(verbesserten
GPRS-) oder dem EGPRS-Kompakt-Protokoll. Alternativ kann die Betriebsweise
des SGSN 20 und des GGSN 22 entsprechend der UMTS-(Universelle
Mobile Kommunikationssystem-)Norm erfolgen.
-
Zusätzlich zu
konventionellen Datendiensten, wie z.B. elektronischer Post und
Weg-Browsing, Dateiübertragung
usw., die über
das Netzwerk 24 verfügbar
sind, sind auch Sprach- und andere Formen von Echtzeit-Datenkommunikationen
(beispielsweise Audio/Video-Datenstrom, interaktive Audio/Video-Anrufe
usw.) über
das Netzwerk 24 möglich.
Geräte,
die mit dem Netzwerk 24 gekoppelt werden können, schließen ein Netzwerk-Telefon 28,
wie z.B. das i2004-Telefon der Firma Nortel Networks Limited ein.
Ein Router 30 kann ebenfalls mit dem Netzwerk 24 gekoppelt
sein, wobei der Router 30 mit mehreren Geräten unter
Einschluss eines Computers 32 (mit Sprachverarbeitungsfähigkeiten)
und eines Netzwerk-Telefons 34 gekoppelt ist. Beispielsweise
kann auf dem Computer 32 eine i2050-Anwendung ablaufen,
um Telefonie-Kommunikationen über ein
paketbasiertes Netzwerk zu ermöglichen.
Ein auf diese Weise konfigurierter Computer kann als ein „Softphone" bezeichnet werden.
-
Das
paketbasierte Netzwerk 24 besteht aus einem oder mehreren
miteinander verbundenen Routern 26. Diese Router werden
zur Routenführung
von Datensignalen von einer Quelle zu einem Ziel auf der Grundlage
von in den Datenpaketen übertragenen
Adresseninformationen verwendet. Derartige Pakete können entsprechend
dem Internetprotokoll (IP) aufgebaut sein, das in der Aufforderung
zu Kommentaren (RFC) 791 mit dem Titel „Internetprotokoll" vom September 1981
beschrieben ist. Diese Version von IP wird als IPv4 bezeichnet.
Eine weitere Version des IP ist IPv6, das in der RFC 2460 mit dem
Titel „Internet
Protocol, Version 6 (IPv6) Spezification", Dezember 1989 beschrieben
ist.
-
Das
IP sieht paketvermittelte Kommunikationen über das Netzwerk 24 vor.
Im Gegensatz zu leitungsvermittelten Netzwerken, die einen dedizierten
Ende-zu-Ende-Kanalabschnitt
(beispielsweise einen Zeitschlitz) für die Dauer einer Anruf-Sitzung bereitstellen,
beruht ein paketvermitteltes Netzwerk auf einer verbindungslosen
Zwischennetzwerk-Schicht. Pakete oder andere Dateneinheiten, die
in ein paketvermitteltes Datennetzwerk eingeleitet werden, können sich
unabhängig über irgendeinen
Pfad (und möglicherweise über unterschiedliche
Pfade) zu einem Zielpunkt hin bewegen. Die Pakete können sogar
außerhalb
ihrer Reihenfolge ankommen.
-
Während das
IP ein verbindungsloses paketbasiertes Netzwerk definiert, ist eine
andere Art von paketbasiertem Netzwerk das verbindungsorientierte
paketbasierte Netzwerk, wie z.B. asynchrone Übertragungsbetriebsart-(ATM-)
oder Framerelay-Netzwerke.
Bei einer alternativen Ausführungsform
kann das Datennetzwerk 24 außerdem ein verbindungsorientiertes
paketbasiertes Netzwerk sein.
-
Eines
der Bedenken, das mit der Verwendung eines gemeinsam genutzen Transportmedium
verbunden ist, besteht in der Konkurrenz zwischen unterschiedlichen
Datenflüssen
für das
gemeinsam genutzte Transportmedium. Bestimmte Arten von Datenkommunikationen
sind verzögerungstolerant
(wie z.B. elektronische Post und das Web-Browsing), während andere
Arten von Kommunikationen (wie z.B. Sprache und andere Echtzeitkommunikationen)
dies nicht sind. Bei dem Beispiel nach 1 ist sowohl
das Netzwerk 24 als auch das drahtlose Zugangsnetzwerk 19 ein
gemeinsam genutztes Transportmedium. Das drahtlose Zugangsnetzwerk 19 wird
gemeinsam von mehreren Mobilstationen verwendet. Das Netzwerk 24 wird
gemeinsam von Mobilstationen in dem drahtlosen Kommunikationssystem 11 sowie
allen anderen Netzwerkgeräten genutzt,
die (direkt oder indirekt) mit dem Netzwerk 24 gekoppelt
sind. Wenn der Netzwerkverkehr zunimmt, kann die Überlastung
in einem gemeinsam genutzten Transportmedium eine Vergrößerung der
Paketverzögerungen
und der Paketverluste hervorrufen. Um eine hohe Qualität und zuverlässige Kommunikationen
sicherzustellen, können
Dienstgüte-(QoS-)Anforderungen
für Kommunikationssitzungen
bereitgestellt werden, so dass Ressourcen des gemeinsam genutzten
Transportmediums für
jede Kommunikationssitzung zugeteilt werden können.
-
Die
QoS kann entsprechend unterschiedlicher Modelle eingestellt werden:
ein differenziertes Dienstemodell (Diff-Serv) oder ein integriertes
Dienstemodell (Int-Serv).
Diff-Serv ist in der RFC 2474 mit dem Titel „Definition of the Differentiated
Services Field (DS Field) in the IPv4 and IPv6 Headers" vom Dezember 1998 und
in der RFC 2475 mit dem Titel „An
Architecture for Differenentiated Services" vom Dezember 1998 beschrieben. Das
Int-Serv-Modell beruht auf dem Ressourcen-Reservierungsprotokoll RSVP, das in
RFC 2205 mit dem Titel „Ressource
Reservation Protocol (RSVP)" vom
September 1997 beschrieben ist.
-
Eines
der Merkmale einiger der Benutzer-Geräte, wie z.B. der Mobilstationen 16, 17,
der Netzwerktelefone 28, 34 und des Softphone 32 besteht
in der Fähigkeit,
die Rate zu ändern,
mit der Echtzeit-Daten (beispielsweise Sprachdaten) codiert oder
decodiert werden, zu ändern.
Wie der Begriff hier verwendet wird, bezieht sich „Echtzeit-Daten" entweder auf Audio-Daten
und/oder Video-Daten, die in einem Datenstrom zu einem Empfangsgerät übertragen
werden. Die Bezeichnung „interaktive
Echtzeit-" Daten
oder -Verkehr bezieht sich auf Audio- und/oder Video-Daten, die zwischen
Geräten
in einer interaktiven Sitzung, wie z.B. einer Anruf-Sitzung, ausgetauscht
werden.
-
Die Änderung
der Codierungsrate von Echtzeit-Daten kann durch die Verwendung
von adaptiven Mehrraten-Codierern/Decodierern (Codecs) erfolgen.
Im mobilen Zusammenhang kann, wenn sich eine mobile Station näher an eine
Basisstation 14 heran bewegt, eine höhere Audio-Codec-Rate eingestellt
werden (so dass eine größere Menge
an Sprachdaten verarbeitet werden kann). Dies ist aufgrund der Tatsache
möglich, dass
die Stärke
von Funkfrequenz-(RF-)Signalen zunimmt, wenn sich mobile Stationen
näher an
die Basisstation heranbewegen, wodurch es ermöglicht wird, eine weniger robuste
Vorwärts-Fehlerkorrektur
zu verwenden, was es andererseits möglich macht, eine höhere Codec-Rate
zu verwenden. Wenn sich jedoch eine mobile Station von einer Basisstation
zum Rand einer Zelle 12 hin fortbewegt, wird eine niedrigere
Codec-Rate verwendet (weil schwächere
RF-Signale mehr
Verarbeitung (mehr Vorwärtsfehler-Korrekturen)
erfordern). Die Codec-Rate kann auch für Nutzer-Geräte verändert werden,
die mit einem drahtgebundenen Netzwerk verbunden sind. Obwohl in
den beschriebenen Ausführungsformen
auf Audio-Codecs Bezug genommen wird, ist festzustellen, dass andere
Ausführungsformen
Video-Codecs mit sich ändernden
Codier/Decodier-Raten verwenden können.
-
Wenn
sich die Codec-Rate ändert, ändert sich
auch die Menge von Daten, die in einem vorgegebenen Paket angeordnet
werden. Eine höhere
Codec-Rate bedingt eine größere Menge
an Daten in einem Paket, während
eine niedrigere Codec-Rate
eine geringere Menge an Daten bedingt. Somit wird gemäß mancher Ausführungsformen
bei einer Änderung
der Codec-Rate auch die QoS-Anforderung für den von dem Codec erzeugten
Datenfluss geändert.
Wenn die Codec-Rate abnimmt, dann nimmt auch die Menge an Daten
in jedem Paket ab. Entsprechend wird die Menge an Bandbreite (oder
Spitzendurchsatz), die zur Übertragung
der Pakete mit verringerter Größe benötigt wird,
ebenfalls verkleinert. Somit wird, wenn eine erste Codec-Rate verwendet
wird, eine erste QoS-Anforderung angefordert; wenn eine zweite Codec-Rate
verwendet wird, so wird eine zweite QoS-Anforderung angefordert, usw. Durch Ändern der
QoS-Anforderungen bei einer Änderung
der Codec-Raten kann eine effizientere Nutzung der gemeinsam genutzen
Transportmedien 19 und 24 erzielt werden. Wenn
ein Nutzer-Gerät
eine niedrigere QoS-Anforderung aufgrund einer niedrigeren Codec-Rate
anfordert, so wird eine größere Menge
an Bandbreite der gemeinsam genutzten Transportmedien 19 und 24 für andere
Datenströme
oder Sitzungen verfügbar.
Somit kann durch die Änderung
der QoS-Anforderungen mit sich ändernden
Codec-Raten eine „statistische
Multiplexierung" von
interaktivem Echtzeitverkehr (beispielsweise Sprachverkehr) mit
anderen Verkehrsarten erzielt werden, wie dies weiter unten erläutert wird.
-
Für die Zwecke
dieser Diskussion gibt es zwei Arten von adaptiven Mehrraten-(AMR-)Codecs: einen AMR-Schmalband-(AMR-NB-)Codec
und einen AMR-Breitband-(AMR-WB-)Codec.
Es sei jedoch bemerkt, dass es auch andere Typen von AMR-Codecs
geben kann. In einem Beispiel führt
ein AMR-NB-Codec eine 8-Kilohertz-(kHz-)Abtastung
aus, während
ein AMR-WB-Codec eine 16-kHz-Abtastung
ausführt.
Bei einer Ausführungsform
hat ein AMR-NB-Codec neun Betriebsarten, die neun unterschiedlichen
Codec-Raten (Raten der Codierung/Decodierung) entsprechen. 12,2
Kilobits pro Sekunde (kbps), 10,2 kbps, 7,95 kbps, 7,40 kbps, 6,70
kbps, 5,90 kbps, 5,15 kbps, 4,75 kbps und SID (was die Rate der
Codierung/Decodierung darstellt, wenn es eine Stille gibt – es werden
keine Sprachdaten übertragen).
Weiterhin hat gemäß einem
Beispiel ein AMR-WB-Codec
zehn Betriebsarten, die zehn unterschiedlichen Codec-Raten entsprechen:
23,85 kbps, 23,05 kbps, 19,85 kbps, 18,25 kbps, 15,85 kbps, 14,25
kbps, 12,65 kbps, 8,85 kbps, 6,6 kbps und SID. Die verschiedenen
oben angegebenen Codec-Raten
werden nur als Beispiele angegeben, weil andere Codec-Raten in anderen
Ausführungsformen
verwendet werden können.
-
In 2 sind
Beispiele von Komponenten eines Nutzer-Gerätes 100 gezeigt. Das
Nutzer-Gerät 100 kann
irgendeine der Mobilstationen 16, 17, Netzwerk-Telefone 34 und
Softphone 32 sein. Das Nutzer-Gerät 100 schließt eine
Netzwerk-Schnittstelle 102, die für eine mobile Station einen
RF-Sendeempfänger 104 einschließt, eine
Funkstrecken-Steuer-/Medienzugangs-Steuer-(RLC/MAC-)Schicht 106 und
andere Protokollschichten 108 ein, beispielsweise ein Paketdaten-Konvergenzprotokoll
(PDCP) für
UMTS. Als Alternative schließt
für ein
Nutzer-Gerät,
das mit einem drahtgebundenen Netzwerk verbunden ist (IEEE 802.3
Ethernet) die Netzwerk-Schnittstelle 102 typischerweise
einen Netzwerk-Adapter, wie z.B. einen Ethernet-Adapter ein (der
keine RLC-Schicht benötigt,
lediglich eine MAC-Schicht und eine physikalische Schicht unterhalb
der MAC-Schicht). Oberhalb der Netzwerk-Schnittstelle 102 befindet
sich eine IP-Schicht 110, die abgehende Daten in IP-Pakete
einkapselt und Nutzinformations-Daten von eingehenden IP-Paketen
ableitet. Eine Transportschicht 112 ist oberhalb der IP-Schicht 110 vorgesehen,
wobei ein Beispiel der Transportschicht entsprechend dem Benutzer-Datagramm-Protokoll (UDP) ist.
UDP ist in der RFC 769 mit dem Titel „User Datagram Protocol" vom August 1980
beschrieben.
-
Ein
Echtzeit-Protokoll-(RTP-)Modul 114 ist ebenfalls in dem
Nutzer-Gerät 100 vorgesehen.
RTP ist in der RFC 1889 mit dem Titel „RTP: A Transport Protocol
for Real-Time Applicatons" vom
Januar 1996 beschrieben. RTP definiert Ende-zu-Ende-Transportfunktionen, die für Echtzeit-Daten
geeignet sind, wie z.B. Audio, Video oder andere Daten. Das RTP-Modul 114 kapselt
abgehende Echtzeit-Daten in RTP-Pakete ein und leitet Echtzeit-Daten
aus eingehenden RTP-Paketen ab. Das RTP-Modul 114 ist mit
einem AMR-Audio-Codec 116 gekoppelt, der Audio-Daten entsprechend
einer von mehreren Raten codiert und decodiert. Die Codierungs-/Decodierungs-Rate
des AMR-Codec 116 kann durch eine Anwendung (beispielsweise
eine Sprachanwendung 124) geändert werden, die in dem Benutzer-Gerät 100 abläuft.
-
In
der abgehenden Richtung synthetisiert oder codiert der Codec 116 Daten,
wobei die codierten Daten in den Nutzerinformations-Abschnitt eines
RTP-Paketes durch das RTP-Modul 114 angeordnet werden. Auf
der Empfangsseite werden abgeleitete Nutzdaten von einem RTP-Paket
von dem Codec 116 decodiert. Der AMR-Audio-Codec 116 ist
mit einem Analog-/Digital-(A/D-) und Digital-/Analog-(D/A-)Wandler 118 gekoppelt,
der eine Umwandlung zwischen analogen und digitalen Audiosignalen
durchführt.
Audiosignale werden über
einen Lautsprecher 120 von dem Wandler 118 abgegeben,
und Eingangs-Audio-Signale werden von einem Mikrofon 122 empfangen.
-
Die
Sprachanwendung 124 sowie andere Software-Routinen oder
Module in dem Benutzer-Gerät 100 sind
auf einer oder mehreren Steuereinheiten 126 ausführbar, die
mit einem Speicher 128 gekoppelt sind.
-
Ein
RTP-Paket hat einen Kopffeld-Abschnitt und einen Nutzdaten-Abschnitt,
wobei der Nutzdaten-Abschnitt Audio-Daten überträgt, die von dem AMR-Audio-Codec 116 (oder
von Codecs, die anderen Echtzeit-Daten zugeordnet sind) codiert
wurden. In den hier erläuterten
Beispielen wird angenommen, dass das Nutzer-Gerät 100 Sprachdaten überträgt. In anderen
Anwendungen können
jedoch auch andere Echtzeit-Daten übertragen werden. Weiter entlang
der abgehenden Richtung wird das RTP-Paket in ein UDP-Paket eingekapselt,
das ein UDP-Kopffeld und einen Nutzdaten-Abschnitt enthält. Der
Nutzdaten-Abschnitt des UDP-Pakets überträgt das RTP-Paket. Das UDP-Paket
wird seinerseits in ein IP-Paket eingekapselt, das ein IP-Kopffeld
und einen Nutzdaten-Abschnitt enthält. Jedes der dem IP-Paket,
UDP-Paket und RTP-Paket zugeordneten Kopffelder hat eine vorgegebene
Größe, wie
es durch die unterschiedlichen Protokolle definiert ist (obwohl
jedes der Kopffelder auf eine veränderbare kleinere Größe komprimiert
werden kann, wobei beispielsweise die robuste Kopffeld-Kompression
(ROHC) verwendet wird, wie sie in der RFC 3095 definiert ist).
-
Wenn
sich die Codec-Rate ändert, ändert sich
auch die Länge
der RTP-Nutzdaten. Ein höhere
Codec-Rate bedingt eine größere RTP-Nutzdaten-Länge, wie
dies in den nachfolgenden Tabellen 1 und 2 gezeigt ist. Die Tabelle
1 zeigt die RTP-Nutzdaten-Längen für unterschiedliche
AMR-NB-Codec-Raten, und die Tabelle 2 zeigt die RTP-Nutzdaten-Länge für unterschiedliche
AMR-WB-Codec-Raten. Die in den Tabellen 1 und 2 gelieferten Werte
stellen lediglich Beispiele dar, und sie sollen den Schutzumfang
der Erfindung nicht beschränken.
Die RTP-Nutzdaten-Länge
schließt
den Datenteil sowie ein Oktett 0 ein (was das erste Oktett des RTP-Nutzdaten-Abschnittes
ist).
-
-
-
Wenn
sich die RTP-Paketlänge ändert, ändert sich
auch die IP-Paketgröße, weil
der Nutzdaten-Abschnitt des IP-Pakets das RTP-Paket enthält. Als
ein Ergebnis ändert
sich der Spitzendurchsatz-Bedarf mit der Codec-Rate. Eine höhere Codec-Rate, die eine größere Nutzdaten-Größe bedingt,
erfordert eine höhere
Spitzendurchsatz-Forderung. Als Ergebnis muss, wenn eine höhere Codec-Rate
verwendet wird, eine höhere Bandbreite
des gemeinsam genutzten Transportmediums zugeteilt werden.
-
Ein
Feld eines IP-Kopffeldes ist ein differenziertes Dienste-(DS-)Feld.
In einem IPv4-Kopffeld wird dieses Feld als ein Dienstetyp-Feld
bezeichnet. In einem IPv6-Kopffeld
wird dieses Feld als ein Verkehrsklassen-Feld bezeichnet. Das DS-Feld
ist einem Diff-Serv-Codepunkt (DSCP) zuzuordnen, der eine Umsetzung auf
ein bestimmtes PHB (Verhalten pro Sprungabschnitt oder Hop) von
Routern ergibt, die einen Teil des Pfades bilden, entlang dessen
das Paket übertragen
wird. PHB bezeichnet eine Kombination von Weiterleitungs-, Klassifizierungs-,
Ablaufsteuerungs- und Abwurfverhalten, die auf ein Verhaltens-Aggregat
(BA) an jedem Sprungabschnitt oder Hop angewandt werden (d.h. an
jedem Router, der ein Diff-Serv-fähiger Knoten ist). Ein Verhaltens-Aggregat
ist eine Sammlung von Paketen mit dem gleichen DSCP, die eine Verbindungsstrecke
in einer vorgegebenen Richtung durchqueren. PHB's können
in Ausdrücken
ihrer Ressource (beispielsweise Puffer, Bandbreite, usw.) ihrer
Priorität
gegenüber
anderen PHB's oder
in Ausdrücken
ihrer relativen beobachtbaren Verkehrscharakteristik (beispielsweise
Verzögerung,
Verlust, usw.) spezifiziert werden. Durch Spezifizieren mehrerer
DSCP's in dem DS-Feld,
das in jedem IP-Paket übertragen
wird, können
entsprechende unterschiedliche PHB's (und damit unterschiedliche QoS-Forderungen)
spezifiziert werden. Gemäß mancher Ausführungsformen
setzt die Anwendung 124 (2) in jedem
Benutzer-Gerät 100 einen
DSCP-Wert in dem DS-Feld eines IP-Paketes.
-
Die
PHB's können in
unterschiedliche Gruppen unterteilt werden, die als PHB-Gruppen bezeichnet werden.
Eine PHB-Gruppe ist ein Satz von einer oder mehreren PHB's, die in bedeutungsvoller
Weise gleichzeitg spezifiziert und realisiert werden können, und
zwar aufgrund einer gemeinsamen Zwangsbedingung für alle PHB's in dem Satz, wobei
ein Beispiel der Zwangsbedingung die Warteschlangen-Diensteversorgungs- oder
Warteschlangen-Verwaltungs-Richtlinie
ist. Standardisierte PHB-Gruppen schließen eine Vorgabe-PHB-(DE PHB-)Gruppe
ein, die grundlegend der Qos besten Bemühens entspricht. Bei einer
Ausführungsform
ist das Vorgabe-PHB das Weiterleitungs-Verhalten besten Bemühens, das in Routern zur Verfügung steht,
wie es in der RFC 1812 mit dem Titel „Requirements for IP Version
4 Routers" vom Juni
1995 genormt ist. Die PHB-Gruppe nächsthöherer Ebene ist eine Klassenauswahl-PHB-(CS PHB-)Gruppe,
die in RFC 2474 mit dem Titel „Definitions
of the Differentiated Series 4 (DS Field) in the IPv4 and the IPv6
Header" vom Dezember
1998 beschrieben ist. Die PHB-Gruppe nächsthöherer Ebene ist die PHB-Gruppe
mit sichergestellter Weiterleitung (AF PHB), die in der RFC 2597
mit dem Titel „Assured
Forwarding PHB Group",
vom Juni 1999 beschrieben ist. Die höchste genormte PHB-Gruppe ist
die Gruppe für
beschleunigte Weiterleitung (EF PHB), die in RFC 2598 mit dem Titel „An Expedited
Forwarding PHB" vom
Juni 1999 beschrieben ist.
-
In
einem Beispiel sind DSCP-Werte, die auf die verschiedenen PHB-Gruppen
umgesetzt werden, wie folgt. Der DE PHB-Gruppe wird ein binärer DSCP-Wert
von 00000000 zugeordnet. Der CS PHB-Gruppe werden acht unterschiedliche
DSCP-Werte zugeordnet,
die als CS0–CS7
bezeichnet werden. Die AF PHB-Gruppe hat 12 DSCP-Werte, die als
AFyx bezeichnet werden, worin y gleich 1–4 und x gleich 1–3 ist.
Je höher
der y-Wert ist, desto höher
ist die Prioritätsklasse,
und je höher
der x-Wert ist, desto höher
ist die Verwerfungs-Priorität.
Die EF PHB-Gruppe wird auf einem einzigen DSCP-Wert umgesetzt.
-
Die
verschiedenen PHB-Gruppen können
auf die verschiedenen QoS-Klassen umgesetzt werden, die durch UMTS
definiert sind: Hintergrund, interaktiv, Datenstrom und Konversation.
Die Hintergrund-Klasse kann auf die DE PHB-Gruppe umgesetzt werden, die interaktive
Klasse kann auf die CS PHB- und/oder AF PHB-Gruppe umgesetzt werden,
und die Datenstrom-Klasse kann auf die CS PHB- und/oder AF PHB-Gruppe umgesetzt
werden, und die Konversations-Klasse kann auf die EF PHB-Gruppe
umgesetzt werden. Gemäß einer
Ausführungsform
ist jedoch festzustellen, dass die EF PHB-Gruppe für nicht-adaptive,
eine konstante Rate aufweisende Echtzeit-paketvermittelte Dienste
verwendet wird (d.h. Sprachkommunikation), die keine AMR-Codecs
verwenden, sondern vielmehr Codecs mit einer festen Rate verwenden.
-
Für adaptive
Mehrraten-Sprachkommunikationen wird eine neue PHB-Gruppe definiert,
die als die AMR PHB-Gruppe gemäß irgendeiner
Ausführungsform
der Erfindung bezeichnet wird. Die AMR PHB-Gruppe schließt 19 DSC-Werte
ein, die als AMR1–AMR19
bezeichnet werden. Die DSCP's
AMR1–AMR9
setzen die neuen Codec-Betriebsarten des AMR-NB-Codec um, während die
AMR10–AMR19
auf die zehn ARM-WB-Codec-Betriebsarten umsetzen. AMR1 wird auf
die niedrigste Codec-Rate des AMR-NB-Codec (die SID-Rate) umgesetzt,
während
AMR9 auf die höchste
AMR-NB-Codec-Rate (12,20 kbps) umgesetzt wird. AMR10 ist auf die
niedrigste AMR-WB-Codec-Rate (SID) umgesetzt, während AMR19 auf die höchste AMR-WB-Codec-Rate (23,85
kbps) umgesetzt wird.
-
In 3 ist
ein von dem Nutzer-Gerät 100 nach 2 ausgeführter Prozess
gezeigt. Der AMR-Codec 116 synthetisiert (bei 202)
Sprache mit einer von mehreren Codec-Raten. Die synthetisierte Sprache
wird (bei 204) in den Nutzdaten-Abschnitt eines RTP-Paketes
durch das RTP-Modul 114 eingefügt. Das RTP-Paket wird dann
in ein UDP/IP-Paket (bei 206) von den UDP/IP-Schichten 112 und 110 gebracht.
Die Anwendung 124 setzt dann (bei 208) den DS-Feld-Wert
auf der Grundlage der Codec-Rate. Das DS-Feld wird auf eine der
AMR DSCP's (AMR1–AMR19)
gesetzt, und zwar in Abhängigkeit
davon, welche der Codec-Raten ausgewählt wird. Das IP-Paket wird
dann ausgesandt (bei 210).
-
In 4 ist
ein Mitteilungsfluss verschiedener Einheiten, die in einer Kommunikationssitzung
beteiligt sind, beschrieben. In dem Beispiel möchte der erste Host (Host A) 316 eine
Kommunikationssitzung mit einem zweiten Host (Host B) 318 aufbauen.
Der Host A kann eine mobile Station sein, während der Host B entweder ein
Netzwerk-Telefon oder ein Softphone sein kann, das mit einem drahtgebundenen
Netzwerk (beispielsweise 24) gekoppelt ist. In anderen
Beispielen können
beide Hosts 316 und 318 mobile Stationen oder
Stationen sein, die mit einem drahtgebundenen Netzwerk gekoppelt
sind. Die Kommunikationssitzung zwischen dem Host A und dem Host
B durchquert ein Funk-Zugangsnetzwerk 311,
ein Kern-Netzwerk 312 und das externe Netzwerk 24.
Das Kern-Netzwerk 312 schließt den SGSN 20 und
den GGSN 22 (sowie irgendwelche anderen Router zwischen
dem SGSN und dem GGSN) ein. Der SGSN 20 und der GGSN 22 werden
als Rand-Router (BR1 und BR2) bezeichnet. Das Funk-Zugangsnetzwerk 311 schließt einen örtlichen
Router 302 und einen Rand-Router 304 ein. Bei
einer Anordnung kann der örtliche
Router 302 in der Basisstation 14 (1)
realisiert werden, und der Rand-Router 304 kann in der
RAN-Steuerung 18 realisiert werden. Andere Router können zwischen
dem örtlichen
Router 302 und dem Rand-Router 304 vorhanden sein.
Das externe Netzwerk 24 schließt einen Rand-Router 306 sowie
andere Router zwischen dem Rand-Router 306 und dem Host
B ein. Eine Charakteristik jedes der Router 302, 304, 20, 22 und 306 (und
irgendwelcher Router zwischen diesen) besteht darin, dass sie DS-fähig sind,
d.h. diese Router sind in der Lage, DS-Felder zu verarbeiten, die
in IP-Paketen übertragen
werden. Weiterhin sind in manchen Ausführungsformen die Router (302, 304, 20, 22 und 306)
ebenfalls in der Lage, RSVP-Mitteilungen zu verarbeiten. In Abhängigkeit
von den verwendeten externen QoS-Signalisierungsmechanismen
(beispielsweise RSVP oder andere Mitteilungen) werden Dienstgüte-Vereinbarungen
(SLA's) in Kraft
gesetzt oder bei 23 vereinbart (zwischen Diensteanbietern).
-
Ein
Warteschlangen- und Ablaufsteuerungs-Mechanismus 400 (5)
kann in jedem der Router 302, 304, 20, 22 und 306 realisiert
werden. Bei einer Ausführungsform
schließt
der Warteschlangen- und Ablaufsteuerungs-Mechanismus mehrfache Eingangs-Warteschlangen
zum Empfang unterschiedlicher Arten von Verkehr ein. Beispielsweise
wird Verkehr, der zu einer PHB-Gruppe gehört, über einen ersten Satz von einer oder
mehreren Warteschlangen verarbeitet, während Verkehr, der zu einer
anderen PHB-Gruppe gehört,
durch einen zweiten Satz von einer oder mehreren Warteschlangen
verarbeitet wird.
-
Jede
Warteschlange kann als eine kombinierte Token-Bucket/Leaky-Bucket-Warteschlange realisiert werden.
Ein Token-Bucket empfängt
Verkehr in einer Eingangs-Warteschlange, wobei der Ausgang von der Eingangs-Warteschlange
durch einen Token-Bucket gesteuert wird, dem eine Tiefe von B Bytes
und eine Rate von R Bytes/Sekunde zugeordnet ist. Der Ausgang des
Token-Bucket wird an einen Leaky-Bucket weitergeleitet, der eine
vorgegebene Tiefe hat, und der Ausgangsdaten mit einer konstanten
Spitzenrate (P Bytes/Sekunde) erzeugen kann.
-
Ein
Vorteil eines Token-Buckets besteht in seiner Fähigkeit, Burst-artigen Verkehr
in effizienterer Weise aufzunehmen, während ein Vorteil eines Leaky-Bucket
seine Fähigkeit
ist, Ausgangsdaten mit einer konstanten Spitzenrate zu erzeugen.
Wenn die Spitzenrate P des Leaky-Bucket größer oder gleich der Token-Bucket-Rate
R ist, so ist die mittlere Datenrate von der kombinierten Token-Bucket/Leaky-Bucket-Warteschlange gleich
R. Die maximale Burst-Größe, die
von der Warteschlange abgewickelt werden kann, ist B. Die Warteschlangen
für die
unterschiedlichen Verkehrsströme
können
unterschiedliche Parameter R, B und P haben.
-
Das
folgende Beispiel verwendet RSVP auf dem externen Signalisierungsmechanismus.
Der Host A sendet (bei 348) eine RSVP-Pfad-Mitteilung an
den örtlichen
Router 302. Die RSVP-Pfad-Mitteilung wird verwendet, um
den Pfad oder die Route zu ermitteln, die von den RTP-Paketen zu
verwenden ist. Der örtliche Router 302 bestätigt dann
(bei 344) bei einem Funk-Zugangsnetzwerk-Bandbreiten-Broker (RANBB) 320,
ob der von dem Host A angeforderte Pfad zugelassen wird oder nicht.
Kommunikationen zwischen dem örtlichen Router 302 und
dem RANBB 320 erfolgen unter Verwendung irgendeines einer
Anzahl von genormten Richtlinien-Protokollen, wie z.B. dem gemeinsamen
offenen Richtlinien-Dienst (COPS), der in RFC 2748 und 2753 beschrieben
ist.
-
Die
Pfad-Mitteilung schließt
die Sender-Tspec-Information ein, die Informationen über das
Verkehrsprofil enthält,
das von der QoS-fähigen
Anwendung im Host A erzeugt wird. Die Information schließt Peak_Rate,
Token_Rate, Token_Bucket_Size, Max_SDU_Size usw. ein. Die Sender-Tspec-Information
definiert die Verkehrscharakteristik des Datenflusses, den der Sender
erzeugen möchte.
Beispielsweise ist für
eine RTP-Nutzinformation mit AMR-NB der Parameter Peak_Rate gleich
Token_Rate, was leicht 12,2 kbps plus Zusatzinformation ist, um
die passende Menge an Bandbreite für die höchste Codec-Rate für AMR-NB
zu reservieren. Wenn sich die AMR-NB-Codec-Rate später ändert, so
kann DSCP verwendet werden, um die Änderung des Bandbreitenbedarfs
zu übermitteln.
-
Alternativ
kann anstelle der Verwendung einer RSVP-Pfad-Mitteilung zur Reservierung
von Ressourcen eine Aktiviere-PDP-(Paketdatenprotokoll-)Kontextmitteilung
(siehe 3GPP TSG 24.007 „Mobile
Radio Interface Signaling Layer 3; General Aspects") oder andere Mitteilungen
verwendet werden, statt die gewünschten Parameter
zu übertragen,
beispielsweise Token_Rate, Peak_Rate, Token_Bucket_Size usw.
-
Als
Antwort auf die RSVP-Pfad-Mitteilung trifft der RANBB 320 eine
Pfad-Zulassungs-Steuerentscheidung.
Wenn die Anforderung verweigert wird, so wird eine Fehlermitteilung
(beispielsweise Pfad-Fehler) von dem örtlichen Router 302 zurück zum Host
A (bei 348) gesandt. In diesem Fall endet der Signalisierungsprozess.
Wenn jedoch die Anforderung von dem RANBB 320 akzeptiert
wird, so senden der örtliche
Router 302 und der Rand-Router 304 die RSVP-Pfad-Mitteilung
an den Rand-Router (SGSN) 20. Der SGSN 20 liefert
eine Bestätigung
(bei 340) an einen Kernnetzwerk-Bandbreiten-Broker (CNBB) 322,
der dem Kernnetzwerk 312 zugeordnet ist. Der CNBB 322 führt eine
Pfadzulassungs-Steuerentscheidung aus. In dem Fall, dass ein einen harten
Zustand aufweisendes Protokoll anstelle eines einen weichen Zustand
aufweisenden Protokolls wie RSVP verwendet wird, überträgt, wenn
die Anforderung verweigert wird, der CNBB seine Entscheidung an
den RANBB, um auf diese Weise den Pfad-Zustand nicht länger als
erforderlich beizubehalten. Dies könnte unter Verwendung irgendeiner
Form einer In-Band-Signalisierung
oder irgendeiner Anzahl von genormten Richtlinien-Protokollen erfolgen,
wie z.B. COPS, wie es in RFC 2748 und 2753 beschrieben ist.
-
Wenn
eine Anforderung verweigert wird, so wird eine Fehlermitteilung
(beispielsweise Pfad-Fehler) an den Rand-Router 304 und
den örtlichen
Router 302 zurückgesandt,
der dann den Host A über
die Pfadzulassungs-Steuerentscheidung von dem CNBB 322 informiert.
Wenn die Anforderung akzeptiert wird, senden der Grenz-Router 320 und
der Grenz-Router 22 (bei 23) die RSVP-Pfad-Mitteilung
an einen Rand-Router 306 Der Rand-Router 306 bestätigt bei
einem externen Bandbreiten-Broker (EBB) 32, ob der von
dem Host A angeforderte Pfad zugelassen wird oder nicht. In dem
Fall, dass ein Protokoll mit harten Zuständen anstelle eines Protokolls
mit weichen Zuständen,
wie RSVP, verwendet wird, überträgt, wenn
die Anforderung verweigert wird, der EBB (unter Verwendung irgendeiner
Form einer In-Band-Signalisierung oder einer Signalisierung gemäß einem
genormten Richtlinien-Protokoll, wie z.B. COPS) seine Entscheidung
(bei 338) an den CNBB 322, um den Pfadzustand
nicht länger
als erforderlich aufrechtzuerhalten.
-
Unter
der Annahme, dass die Anforderung akzeptiert wird, sendet der Rand-Router 306 (bei 27)
die RSVP-Pfad-Mitteilung an den Host B. Anderenfalls wird eine Pfad-Fehlermitteilung
an den Host A zurückgeliefert.
Host B sendet dann (bei 27) eine RSVP RESV-Mitteilung an
dn Rand-Router 306. Sobald der Pfad-Zustand für die RTP-Pakete
entlang des Datenpfades mit der RSVP-Pfad-Mitteilung installiert
ist, wird die RSVP RESV-Mitteilung dazu verwendet, die tatsächliche
Reservierungsanforderung zu machen. Die RESV-Mitteilung enthält Flow-Spec-Information, unter
Einschluss von R_Spec und Receiver_Tspec. R_Spec enthält Information über die
QoS-Anforderungen für
den Verkehr, der in Receiver_Tspec beschrieben ist. Empfänger_Tspec
wird dadurch geschaffen, dass die Information von der Sender_Tspec-Information
in die Pfad-Mitteilung kopiert wird.
-
Der
Rand-Router 306 bestätigt
dann (bei 336) bei dem EBB 324, ob die von dem
Host B angeforderte Reservierung zugelassen wird oder nicht. Kommunikationen
zwischen dem Rand-Router 306 und dem EBB 324 können gemäß COPS erfolgen.
Alternativ kann anstelle der Verwendung von RSVP RESV eine Aktiviere-PDP-Kontext-Annahme-Mitteilung
oder eine andere Mitteilung verwendet werden.
-
Als
Antwort auf die RSVP RESV-Mitteilung trifft der EBB 324 eine
Reservierungs-Zulassungs-Steuerentscheidung.
Wenn die Anforderung verweigert wird, wird eine RESV-Fehlermitteilung
an den Host B zurückgesandt.
In diesem Fall endet der Signalisierungsprozess. Wenn die Anforderung
jedoch von dem EBB 324 akzeptiert wird, so teilt der EBB 324 die
angeforderten Ressourcen zu und sendet (bei 23) die RSVP
RESV-Mitteilung an den Grenz-Router 22. Der Grenz-Router 22 bestätigt dann
(bei 340) bei dem CNBB 322, ob die Reservierung,
die von dem Host B angefordert wurde, zugelassen wird oder nicht.
In dem Fall, in dem ein Protokoll mit harten Zuständen anstelle
eines Protokolls mit weichen Zuständen, wie RSVP, verwendet wird, überträgt, wenn
die Anforderung verweigert wird, der CNBB 322 seine Entscheidung
(bei 334) an den EBB 324, so dass der Reservierungszustand
nicht länger
als erforderlich aufrechterhalten wird.
-
Wenn
die Anforderung verweigert wird, so wird eine RESV-Fehlermitteilung
an den Rand-Router 306 zurückgesandt, der dann den Host
B über
die Reservierungs-Zulassungs-Steuerentscheidung
informiert, die von dem CNBB 322 gemacht wurde. Wenn die
Anforderung akzeptiert wird, teilt der CNBB 322 die angeforderten
Ressourcen zu, und die Grenz-Router 20 und 22 senden
(bei 29) die RSVP RESV-Mitteilung
an den Rand-Router 304. Der Rand-Router 304 bestätigt (bei 344)
bei dem RANBB 320, ob die von dem Host B angeforderte Reservierung
zuzulassen ist oder nicht. In dem Fall, dass ein Protokoll mit hartem
Zustand anstelle eines Protokolls mit weichem Zustand, wie RSVP,
verwendet wird, überträgt, wenn
die Anforderung verweigert wird, der RANBB 320 seine Entscheidung
(bei 332) an den CNBB 322, um auf diese Weise
den Reservierungszustand nicht länger
als erforderlich aufrechtzuerhalten.
-
Unter
der Annahme, dass die Anforderung akzeptiert wird, teilt der RANBB 320 die
angeforderten Ressourcen zu, und der Rand-Router 304 und
der örtliche
Router 302 senden die RSVP RESV-Mitteilung (bei 348) an
den Host A. Anderenfalls wird eine RESV-Fehlermitteilung an den
Host B zurückgeliefert.
-
Bei
Empfang der RSVP RESV-Mitteilung kann der Host A beginnen, RTP-Pakete
zu senden, wobei der passende DSCP so gesetzt ist, dass er der AMR-NB-
oder AMR-WB-Codec-Rate entspricht, die auf einer Grundlage pro Sprachrahmen
verwendet wird. Der Host A sendet Pakete (bei 348) an den örtlichen
Router 302. Wenn die Pakete nicht der Norm entsprechen
(oder kein Profil haben) formt der örtliche Router 302 die Pakete
so, dass sie normgerecht gemacht werden. Die Pakete werden über irgendwelche
zwischenliegenden Router (bei 350) an den Rand-Router 304 gesandt,
der ebenfalls eine Klassifizierung und Neuformung des Verkehrs in
der erforderlichen Weise ausführt,
um sicherzustellen, dass die ausgehandelte Spitzen-Rate nicht überschritten
wird.
-
Die
Funktionen der Router 302, 20 und 306 (auf
der Aufwärts-Strecke)
und 306, 22 und 304 (auf der Abwärts-Strecke)
bestehen darin, (1) den Verkehr zu klassifizieren, (2) den Verkehr
zu messen, (3) den Verkehr zu markieren, (4) den Verkehr zu formen
und (5) Verkehr zu verwerfen. Ein Klassifizierer ist ein Mechanismus,
der dazu verwendet wird, das passende PHB für den Verkehrsfluss auszuwählen. Der
Hauptzweck einer Messung besteht darin, die klassifizierten Pakete
in die richtigen Dringlichkeits- (U), Bedeutungs- (I) und Bandbreiten-
(B) Grade zu sortieren. Die Paketmarkierung (d.h. das Setzen und
Neumarkieren der DSCP) setzt die Pakete in einen der verfügbaren U-,
I- und B-Grade des PHB um, das für
den Verkehrsfluss verwendet wird. Die grundlegende Idee hinter der
Verkehrsformung besteht darin, dass, wenn sie festgestellt hat,
dass ein Paket neu markiert werden sollte (d.h. wenn sie festgestellt
hat, dass der DSCP geändert
werden sollte), und zwar auf einen niedrigeren U-, I- und/oder B-Grad,
eine Alternative darin bestehen könnte, den Verkehrsprozess in
einer derartigen Weise zu formen, dass eine Neumarkierung (oder
ein Verwerfen) nicht erforderlich ist.
-
Bei
Empfang der RTP-Pakete, bei denen der passende DSCP so gesetzt ist,
dass er der AMR-NB- oder AMR-WB-Codec-Rate entspricht, überprüfen alle
die Router 302, 20 und 306 (auf der Aufwärtsstrecke) und 306, 22 und 304 (auf
der Abwärtsstrecke)
den DSCP, um das passende PHB auszuwählen (das durch den Warteschlangen-Mechanismus
nach 5 verwirklicht wird).
-
In 5 ist
der Warteschlangen- und Ablaufsteuerungsmechanismus 400 gezeigt,
der in jedem der Router nach 4 verwendet
werden kann. Der Mechanismus 400 schließt Warteschlangen 402, 404, 406, 408, 412, 414, 416, 418 und 420 ein.
Die Paket-Ablaufsteuerung 410 wählt Daten von einer der Warteschlangen
für die
Ausgabe auf ein gemeinsam genutztes Transportmedium aus. In dem
Beispiel nach 5 wird die Warteschlange 402 für Verkehr
in der Hintergrund-Klasse verwendet, die Warteschlangen 404, 406 und 408 werden
für Verkehr
in der interaktiven Klasse verwendet, die Warteschlangen 412 und 414 werden
für Verkehr in
der Datenstrom-Klasse verwendet, und die Warteschlangen 416, 418 und 420 werden
für Verkehr
in der Konversations-Klasse verwendet. Eine Steuerung 430 (die
Software, Hardware oder beides sein kann) führt verschiedene Steuerfunktionen
unter Einschluss der Auswahl einer der Warteschlangen zur Anordnung
von zu transportierenden Daten aus. Weiterhin ist die Steuerung 430 in
der Lage, dynamisch die Warteschlange auf einer Grundlage nach Bedarf
zu schaffen.
-
Wie
dies vorstehend erläutert
wurde, wird der DSCP-Wert DE auf die Hintergrund-Klasse umgesetzt. Die DSCP-Werte CS0–CS7 und/oder
AF11–AF43
werden auf die interaktiven und Datenstrom-Klassen umgesetzt. Somit
kann in einem Beispiel die Warteschlange 404 Verkehr empfangen,
der DSCP-Werten in einer ersten Teilgruppe der DSCP-Werte zugeordnet
ist (CS0–7,
AF11–AF43);
die Warteschlange 406 empfängt Verkehr, der DSCP-Werten
in einer zweiten Teilgruppe der DSCP-Werte zugeordnet ist (CS0–7, AF11–AF43), usw.,
für die
Warteschlangen 408, 412 und 414.
-
Die
Teilgruppen können
durch die folgenden Parameter (U, I und B) identifiziert werden,
wobei U die Dringlichkeit, I die Bedeutung und B die Bandbreite
darstellt (siehe 6 für eine Erläuterung der Koordinatensystem-Darstellung).
Die Dringlichkeit bezieht sich auf die Verzögerungstoleranz eines Paketes,
die Bedeutung bezieht sich auf die Priorität des Paketes, und die Bandbreite
bezieht sich auf den Spitzen-Durchsatzbedarf des Paketes. So ist
in dem Beispiel nach 5 die Warteschlange 404 DSCP-Werten
in der Teilgruppe zugeordnet, die als (U, I, B) = (1, 1, 1) in der
interaktiven Klasse identifiziert ist; die Warteschlange 406 ist DSCP-Werten
in der Teilgruppe zugeordnet, die als (U, I, B) = (1, 2, 1) in der
interaktiven Klasse identifiziert ist; die Warteschlange 408 ist
DSCP-Werten in der Teilgruppe zugeordnet, die als (U, I, B) = (1,
N, 1) in der interaktiven Klasse identifiziert ist; die Warteschlange 412 ist
DSCP-Werten in der Teilgruppe zugeordnet, die als (U, I, B) = (1,
1, 1) in der Datenstrom-Klasse zugeordnet ist; usw.
-
Die
Warteschlangen 416, 418 und 420 empfangen
Daten, die den DSCP-Werten AMR1–AMR9
für den AMR-NB-Codec
und AMR10–AMR19
für den
AMR-WB-Codec zugeordnet sind. Die Warteschlangen 416 bis 420 werden
durch die Paket-Ablaufsteuerung 410 der
höchsten
Priorität
zugeordnet. Den der Datenstrom-Klasse,
der interaktiven Klasse und der Hintergrund-Klasse zugeordneten
Warteschlangen werden Prioritäten
in absteigender Reihenfolge durch die Paket-Ablaufsteuerung 410 zugeteilt,
wenn somit Daten in einer der Warteschlangen 416 bis 420 vorhanden
sind, so werden die Daten in diesen Warteschlangen als erste von der
Paket-Ablaufsteuerung 410 für die Aussendung auf das gemeinsam
genutzte Transportmedium ausgewählt.
-
Die
Paket-Ablaufsteuerung 410 kann verschiedene Algorithmen
verwenden, um Daten von den Warteschlangen auszuwählen. Ein
Beispiel eines Algorithmus ist der gewichtete faire Warteschlangen-(WFQ-)Algorithmus.
Ein Beispiel des WFQ-Algorithmus
ist in der Veröffentlichung
von A. Demers et al., „Analysis
and Simulation of a Fair Queuing Algorithm", Journal of Internetworking Research
and Experience, Seiten 3–26 (1990),
beschrieben. Die Paket-Ablaufsteuerung 410 wertet Daten
zur Ausgabe von den Warteschlangen auf der Grundlage der DSCP-Werte aus. Wenn beispielsweise
ein WFQ-Algorithmus von der Paket-Ablaufsteuerung 410 verwendet
wird, so beruhen die Wertigkeiten, die Daten in jeder der Warteschlangen
zugeordnet werden, auf den DSCP-Werten von Paketen, die in den Warteschlangen
warten. Wenn somit die Audiocodec-Raten absinken, was bedeutet,
dass der DSCP-Wert von AMRM bis auf AMR N + 1 oder AMRN absinkt,
so ist die Paket-Ablaufsteuerung 410 in der Lage, schneller
andere Arten von Verkehr entsprechend ihrer vordefinierten PAB-Wertigkeiten
(in den Hintergrund-Interaktiven- oder Datenstrom-Warteschlangen)
zu berücksichtigen.
Durch Absenken der DSCP-Werte (und damit der Spitzen-Durchsatz-Anforderungen) für Verkehr
in der Konversations-Klasse wird eine größere Bandbreite für die anderen
Typen von Verkehr verfügbar
gemacht.
-
Dies
ergibt effektiv eine „statistische
Multiplexierung" des
Konversationsklassen-Verkehrs
und von anderem eine niedrige Priorität aufweisenden Verkehr. Ohne
die Fähigkeit,
die DSCP-Werte mit sich ändernden Codec-Raten
zu ändern,
müsste
der EF PHB-Gruppen-DSCP-Wert verwendet werden, der die maximale QoS-Forderung spezifiziert,
die für
den Konversationsklassen-Verkehr erforderlich ist. Die Spezifizierung
der maximalen QoS-Forderung für
Konversationverkehr selbst dann, wenn die Codec-Rate absinkt, ruft
die Reservierung von unnötigen
Ressourcen hervor. Durch Ändern
der DSCP-Werte mit sich ändernden
Codec-Raten gemäß einigen
Ausführungsformen
der Erfindung kann ein Teil der Ressourcen, der ansonsten dem Konversationsklassen-Verkehr
zugeteilt worden wäre,
für andere
Arten von Verkehr verwendet werden (beispielsweise Verkehr besten
Bemühens,
interaktiver Verkehr oder Datenstrom-Verkehr). Um die Verwendung
von DSCP's für unterschiedliche
AMR-Codec-Raten zu ermöglichen,
können
neun neue DSCP's
von der Internet-Nummer-Zuteilungsbehörde (IANA) für den AMR-NB-Codec
und zehn neue DSCP's
von der IANA für
den AMR-WB-Codec reserviert werden.
-
Die
verschiedenen erläuterten
Knoten und Systeme schließen
jeweils verschiedene Software-Routinen oder Module ein. Derartige
Software-Routinen oder Module sind auf entsprechenden Steuereinheiten
ausführbar.
Jede Steuereinheit schließt
einen Mikroprozessor, einen Microkontroller, eine Prozessorkarte
(unter Einschluss von einem oder mehreren Microprozessoren oder
Microkontrollern) und andere Steuer- oder Computer-Einrichtungen ein. Wie
der Begriff hier verwendet wird, bezieht sich eine „Steuerung" auf eine Hardware-Komponente,
eine Software-Komponente oder eine Kombination der beiden. Obwohl
dieser Begriff im Singular verwendet wird, kann sich eine „Steuerung" auch auf mehrere
Hardware-Komponenten, mehrere Software-Komponenten oder ein Kombination
hiervon beziehen.
-
Die
in dieser Erläuterung
genannten Speichereinrichtungen schließen ein oder mehrere maschinenlesbare
Speichermedien zum Speichern von Daten und Befehlen ein. Die Speichermedien
schließen
unterschiedliche Formen von Speicher unter Einschluss von Halbleiterspeichereinrichtungen,
wie z.B. dynamischen oder statischen Speichern mit wahlfreiem Zugriff
(DRAM oder SRAM), löschbare
und programmierbare Festwertspeicher (EPROM), elektrisch löschbare
und programmierbare Festwertspeicher (EEPROM) und Flash-Speicher,
Magnetplatten, wie z.B. Festplatten, Floppies und Wechselplatten
ein; andere magnetische Medien unter Einschluss von Bändern und
optische Medien, wie z.B. Compact Disks (CD) oder Digitale Videodisks
(DVD) können
ebenfalls verwendet werden. Befehle, die die verschiedenen Software-Routinen
oder Module in den verschiedenen Geräten oder Systemen bilden, sind
in den jeweiligen Speichereinrichtungen gespeichert. Wenn die Befehle
von einer jeweiligen Steuereinheit ausgeführt werden, so bewirken sie,
dass der entsprechende Knoten oder das entsprechende System die
programmierten Aktionen ausführt.
-
Die
Befehle der Software-Routinen oder Module werden in jeden Knoten
oder jedes System in einer von verschiedenen Weisen geladen oder
von diesen transportiert. Beispielsweise werden Code-Segmente, die Befehle
einschließen,
die auf Floppy Disks, CD- oder DVD-Medien, einer Festplatte gespeichert
sind oder über eine
Netzwerk-Schnittstellenkarte, ein Modem oder eine andere Schnittstelleneinrichtung
transportiert werden, in das Gerät
oder das System geladen und als entsprechende Software-Routinen
oder Module ausgeführt.
Bei dem Lade- oder Transportprozess werden Daten, die in Trägerschwingungen
verwirklicht sind (und über
Telefonleitungen, Netzwerkleitungen, drahtlose Verbindungsstrecken,
Kabel und dergleichen übertragen
werden) zur Kommunikation der Code-Segmente unter Einschluss von
Befehlen, an das Gerät
oder System verwendet. Derartige Trägerschwingungen weisen die
Form von elektrischen, optischen, akustischen, elektromagnetischen
oder anderen Arten von Signalen auf.
-
Obwohl
die Erfindung bezüglich
einer begrenzten Anzahl von Ausführungsformen
beschrieben wurde, wird der Fachmann vielfältige Modifikationen und Abänderungen
hiervon erkennen. Es ist daher vorgesehen, dass die beigefügten Ansprüche derartige
Modifikationen und Abänderungen
abdecken, soweit sie in den Schutzumfang der Erfindung fallen.
