-
Die
Erfindung betrifft eine Steuerung von Dienstgüte (QoS: "Quality of Service") bei Mobilkommunikationssystemen mit
einer Paketdatenübertragungsfähigkeit.
-
Ein
Mobilkommunikationssystem bezieht sich im Allgemeinen auf jedes
Telekommunikationssystem, das eine drahtlose Kommunikation ermöglicht,
wenn sich Teilnehmer innerhalb des Dienstgebiets des Systems bewegen.
Ein typisches Mobilkommunikationssystem ist ein öffentliches, landgestütztes Mobilfunknetz (PLMN: "Public Land Mobile
Network"). Ein Mobilkommunikationsnetzwerk
ist üblicherweise
ein Zugangsnetwerk, das einen Teilnehmer mit einem drahtlosen Zugang
zu externen Netzwerken, zu Hosts bzw. Leitrechnern oder mit von
speziellen Dienstanbietern angebotenen Diensten versorgt.
-
"General Packet Radio
Service" GPRS ist
ein neuer Dienst im GSM-System ("Global
System for Mobile Communications")
und ist eine der Zielrichtungen der Standardisierungsarbeit der
GSM-Phase 2+ beim ETSI ("European
Telecommunications Standards Institute"). Die GPRS-Betriebsumgebung weist einen
oder mehrere Unternetzwerk-Dienstbereiche auf, die mittels eines
GPRS-Backbone- bzw.
Basisnetzwerks miteinander verbunden sind.
-
Ein
Unternetzwerk weist eine Anzahl von Paketdatendienstknoten auf,
die als Versorgungs-GPRS-Unterstützungsknoten
SGSN bezeichnet werden, wobei jeder dieser derart mit dem GSM-Mobilkommunikationsnetzwerk
(typischerweise mit Basisstationssystemen BSS) verbunden ist, dass
er einen Paketdienst für
mobile Datenendgeräte über mehrere
Basisstationen, d.h. Zellen, bereitstellt. Das dazwischen liegende
Mobilkommunikationsnetzwerk stellt eine paketvermittelte Datenübertragung
zwischen einem Unterstützungsknoten
und mobilen Datenendgeräten
bereit. Verschiedene Unternetzwerke sind wiederum über Gateway-GPRS-Unterstützungsknoten
GGSN mit einem externen Datennetzwerk verbunden, z.B. mit einem öffentlichen
Datennetzwerk PSPDN. Der Ausdruck GSN bezieht sich häufig sowohl
auf SGSN als auch auf GGSN. Der GPRS-Dienst ermöglicht daher eine Bereitstellung
einer Paketdatenübertragung
zwischen mobilen Datenendgeräten
und externen Datennetzwerken, wenn das GSM-Netzwerk als Zugangsnetzwerk
arbeitet.
-
Zum
Zugreifen auf die GPRS-Dienste soll eine Mobilstation (MS) dem Netzwerk
zuerst ihre Anwesenheit bekannt machen, indem sie einen GPRS-Anschlussvorgang
durchführt.
Diese Funktion stellt eine logische Verknüpfung zwischen der MS und dem
SGSN her und macht die MS verfügbar
für einen
Kurznachrichtendienst (SMS: "Short
Message Service") über GPRS,
Funkruf bzw. Paging über
den SGSN und Benachrichtigung über
ankommende GPRS-Daten. Schließt
sich die MS an das GPRS-Netzwerk an, d.h. bei einem GPRS-Anschlussvorgang,
erzeugt der SGSN insbesondere einen Mobilitätsverwaltungskontext (MM-Kontext).
Die Authentisierung des Teilnehmers wird ebenfalls beim GPRS-Anschlussvorgang
durch den SGSN durchgeführt.
Zum Senden und Empfangen von GPRS-Daten soll die MS die Paketdatenadresse,
die sie verwenden möchte,
durch Anfordern eines PDP- (Paketdatenprotokoll) Aktivierungsvorgangs
aktivieren. Diese Funktion macht die MS beim entsprechenden GGSN
bekannt und eine Zusammenarbeit mit externen Datennetzwerken kann
beginnen. Insbesondere wird in der MS sowie dem GGSN und SGSN ein
PDP-Kontext erzeugt. Der PDP-Kontext definiert unterschiedliche
Datenübertragungsparameter
wie etwa den PDP-Typ (z.B. X.25 oder IP), die PDP-Adresse (z.B.
eine X.121-Adresse), die Dienstgüte
QoS und den NSAPI ("Network
Service Access Point Identifier":
Netzwerk-Dienstzugangspunktbezeichner).
Die MS aktiviert den PDP-Kontext
mit einer speziellen Nachricht, nämlich "Aktiviere PDP-Kontext Anfrage", in der sie Informationen über die
temporäre
logische Streckenkennung (TLLI: "Temporary
Logical Link Identity"),
den PDP-Typ, die PDP-Adresse,
die benötigte
QoS und NSAPI, sowie wahlweise den Zugangspunktnamen APN bereitstellt.
-
1 veranschaulicht
ein im GSM-System implementiertes GPRS-Paketfunknetzwerk. Für eine ausführlichere
Beschreibung von GPRS wird Bezug genommen auf ETSI GSM 03.60, Version
6.1.0 und die Querverweise darin.
-
Der
grundlegende Aufbau des GSM-Systems weist zwei Subsysteme auf: ein
Basisstationssystem BSS und ein Netzwerksubsystem NSS. Das BSS und
Mobilstationen MS kommunizieren miteinander über Funkstrecken. Im Basisstationssystem
BSS wird jede Zelle von einer Basisstation BTS versorgt. Eine Anzahl von
Basisstationen ist mit einer Basisstationssteuerung BSC verbunden,
die die Funkfrequenzen und Kanäle steuert,
die von der BTS verwendet werden. Basisstationssteuerungen BSC sind
mit einer Mobildienstevermittlungsstelle MSC verbunden. Im Hinblick
auf eine ausführlichere
Beschreibung des GSM-Systems
wird Bezug genommen auf die ETSI/GSM-Empfehlungen und "The GSM System for
Mobile Communications",
M. Mouly und M. Pautet, Palaiseau, Frankreich, 1992, ISBN: 2-957194-07-7.
-
Gemäß 1 weist
das mit dem GSM-Netzwerk verbundene GPRS-System ein GPRS-Netzwerk
auf, das wiederum einen Versorgungs-GPRS-Unterstützungsknoten (SGSN) und mehrere
Gateway-GPRS-Unterstützungsknoten
(GGSN) aufweist. Die unterschiedlichen Unterstützungsknoten SGSN und GGSN
sind mittels eines Betreiber-internen Backbone- bzw. Basisnetzwerks
miteinander verbunden. Im GPRS-Netzwerk kann jede beliebige Anzahl
von Versorgungs-Unterstützungsknoten
und Gateway-Unterstützungsknoten
vorhanden sein.
-
Der
Versorgungs-GPRS-Unterstützungknoten
SGSN ist ein Knoten, der die Mobilstation MS versorgt. Jeder SGSN
steuert einen Paketdatendienst innerhalb des Bereichs einer oder
mehrerer Zellen in einem zellularen Paketfunknetzwerk, und daher
ist jeder SGSN (über
eine Gb-Schnittstelle) mit einem bestimmten lokalen Element des
GSM-Systems verbunden. Diese Verbindung wird typischerweise zum
Basisstationssystem BSS hergestellt, d.h. zu Basisstationssteuerungen
BSC oder zu einer Basisstation BTS. Die sich in einer Zelle befindende
Mobilstation MS kommuniziert durch das Mobilkommunikationsnetzwerk über eine
Funkschnittstelle mit einer BTS und weiter mit dem SGSN, zu dessen
Dienstbereich die Zelle gehört.
Prinzipiell gibt das Mobilkommunikationsnetzwerk zwischen dem SGSN
und der MS nur Pakete zwischen diesen beiden weiter. Um dies zu
erreichen, stellt das Mobilkommunikationsnetzwerk eine paketvermittelte Übertragung
von Datenpaketen zwischen der MS und dem SGSN bereit. Es ist zu
beachten, dass das Mobilkommunikationsnetzwerk nur eine physikalische
Verbindung zwischen der MS und dem SGSN bereitstellt und seine exakte
Funktion und Struktur daher hinsichtlich der Erfindung nicht maßgeblich
sind. Der SGSN ist auch mit einer Signalisierungsschnittsstelle
Gs zum Besucherstandortverzeichnis VLR des Mobilkommunikationsnetzwerks
und/oder zur Mobildienstevermittlungsstelle versehen, z.B. einer
Signalisierungsverbindung SS7. Der SGSN kann Standortinformationen
zum MSC/VLR übertragen
und/oder Anforderungen bzw. Anfragen zum Suchen nach einem GPRS-Teilnehmer vom MSC/VLR
empfangen.
-
Die
Gateway-GPRS-Unterstützungsknoten
GGSN verbinden ein GPRS-Netzwerk eines Betreibers mit externen Systemen
wie etwa GPRS-Systemen anderer Betreiber, Datennetzwerken 11 wie
etwa einem IP-Netzwerk (Internet) oder einem X.25-Netzwerk, sowie Dienststellen.
Ein Grenzgateway BG stellt Zugang zu einem Zwischenbetreiber-GPRS-Backbone-
bzw. Basisnetzwerk 12 bereit. Der GGSN kann auch direkt mit einem
privaten Firmennetzwerk oder einem Host verbunden sein. Der GGSN
umfasst PDP-Adressen von GPRS-Teilnehmern und Routing-Informationen,
d.h. SGSN-Adressen. Routing-Informationen
werden zum Tunneln von Protokolldateneinheiten PDU von einem Datennetzwerk
11 zum momentanen Vermittlungspunkt der MS verwendet, d.h. zum Versorgungs-SGNS.
Die Funktionalitäten
vom SGSN und vom GGSN können
mit dem gleichen physikalischen Knoten verbunden sein.
-
Das
Heimatstandortverzeichnis HLR des GSM-Netzwerks enthält GPRS-Teilnehmerdaten
und Routing-Informationen und es bildet die Teilnehmer-IMSI auf
ein oder mehrere Paare des PDP-Typs und der PDP-Adresse ab. Das
HLR bildet auch jedes Paar von PDP-Typ und PDP-Adresse auf einen
oder mehrere GGSNs ab. Der SGSN weist eine Gr-Schnittstelle zum HLR auf (eine direkte
Signalisierungsverbindung oder über
ein internes Backbone-Netzwerk 13). Das HLR einer umherwandernden
MS und ihr Versorgungs-SGSN können
sich in unterschiedlichen Mobilkommunikationsnetzwerken befinden.
-
Ein
Betreiber-internes Backbone-Netzwerk 13, das SGSN- und GGSN-Ausrüstungen
eines Betreibers miteinander verbindet, kann mit Hilfe eines lokalen
Netzwerks implementiert werden, wie zum Beispiel mit einem IP-Netzwerk. Es sollte
beachtet werden, dass ein GPRS-Netzwerk
eines Betreibers auch ohne das Betreiber-interne Backbone-Netzwerk
implementiert werden kann, z.B. durch Bereitstellung aller Merkmale
in einem Rechner.
-
Ein
Zwischenbetreiber-Backbone-Netzwerk ermöglicht eine Kommunikation zwischen
GPRS-Netzwerken unterschiedlicher Betreiber.
-
Zum
Senden und Empfangen von GPRS-Daten soll die MS die Paketdatenadresse,
die sie verwenden möchte,
durch Anfordern eines PDP-Aktivierungsvorgangs aktivieren. Diese
Funktion macht die MS beim entsprechenden GGSN bekannt und eine
Zusammenarbeit mit externen Datennetzwerken kann beginnen. Insbesondere
wird in der MS sowie dem GGSN und dem SGSN ein PDP-Kontext erzeugt.
-
Als
Folge davon sind drei unterschiedliche MM-Zustände der MS für die Mobilitätsverwaltung
(MM) eines GPRS-Teilnehmers
typisch: Ruhezustand, Bereitschaftszustand und betriebsbereiter
Zustand. Jeder Zustand stellt eine spezielle Funktionalität und ein
spezielles Informationsniveau dar, die der MS und dem SGSN zugewiesen
wurden. Zu diesen Zuständen
in Beziehung stehende Informationsmengen, MM-Kontexte genannt, werden
im SGSN und in der MS gespeichert. Der Kontext des SGSN enthält Teilnehmerdaten
wie etwa die Teilnehmer-IMSI, TLLI, Standort- und Routing-Informationen,
usw.
-
Im
Ruhezustand kann die MS vom GPRS-Netzwerk nicht erreicht werden
und es werden keine dynamischen Informationen über den momentanen Zustand
oder Standort der MS, d.h. kein MM-Kontext, im Netzwerk beibehalten.
Im Bereitschafts- und im betriebsbereiten Zustand ist die MS an
das GPRS-Netzwerk angeschlossen. Im GPRS-Netzwerk wurde ein dynamischer
MM-Kontext für
die MS erzeugt und es wird eine logische Verknüpfung LLC ("Logical Link Control") zwischen der MS und dem SGSN in einer
Protokollschicht hergestellt. Der betriebsbereite Zustand ist der
eigentliche Datenübertragungszustand,
in dem die MS Teilnehmerdaten übertragen
und empfangen kann.
-
Im
Bereitschafts- und im betriebsbereiten Zustand kann die MS auch
einen oder mehrere PDP-Kontexte (Paketdatenprotokoll) aufweisen,
die in Verbindung mit dem MM-Kontext im Versorgungs-SGSN gespeichert
sind. Der PDP-Kontext definiert unterschiedliche Datenübertragungsparameter
wie etwa PDP-Typ (z.B. X.25 oder IP), PDP-Adresse (z.B. eine X.121-Adresse),
QoS und NSAPI. Die MS. aktiviert den PDU-Kontext mit einer speziellen
Nachricht, nämlich "Aktiviere PDP-Kontext
Anfrage", in der
sie Informationen über
den TLLI, PDP-Typ,
PDP-Adresse, benötigte
QoS und NSAPI, sowie wahlweise den Zugangspunktnamen APN bereitstellt.
Wandert die MS zum Bereich eines neuen SGSN, fordert der neue SGSN
vom alten SGSN MM- und PDP-Kontexte an.
-
Wie
gemäß 2 gezeigt
weist ein GPRS-System geschichtete Protokollstrukturen, genannt
Ebenen, zur Signalisierung und Übertragung
von Teilnehmerdaten auf. Die Signalisierungsebene besteht aus Protokollen
zur Steuerung und Unterstützung
der Übertragungsebenenfunktionen.
Die Übertragungsebene
besteht aus einer geschichteten Protokollstruktur, die eine Teilnehmerinformationsübermittlung
bereitstellt, zusammen mit zugehörigen
Informationsübermittlungs-Steuervorgängen (z.B.
Flusssteuerung, Fehlererkennung, Fehlerkorrektur und Fehlerbehebung).
Die Gb-Schnittstelle hält
die Übertragungsebene
der NSS-Plattform unabhängig
von der zugrunde liegenden Funkschnittstelle.
-
Das
GPRS-Tunnelprotokoll (GTP) tunnelt Teilnehmerdaten und Signalisierung
zwischen GPRS-Unterstützungsknoten
im GPRS-Backbone-Netzwerk. Alle PDP-PDUs sollen durch das GTP eingekapselt
werden. Das GTP stellt, falls erforderlich, Mechanismen zur Flusssteuerung
zwischen GSNs bereit. GTP ist in GSM 09.60 spezifiziert. Das Übertragungssteuerprotokoll
(TCP: "Transmission
Control Protocol")
transportiert GTP-PDUs im GPRS-Backbone-Netzwerk für Protokolle, die eine zuverlässige Datenstrecke
benötigen
(z.B. X.25), und das UDP transportiert GTP-PDUs für Protokolle,
die keine zuverlässige
Datenstrecke benötigen (z.B.
IP). Das TCP stellt eine Flusssteuerung und Schutz gegen verloren
gegangene und beschädigte GTP-PDUs
bereit. Das Teilnehmerdatagrammprotokoll (UDP: "User Datagram Protocol") stellt Schutz gegen beschädigte GTP-PDUs
bereit. Das TCP ist in RFC 793 definiert. Das UDP ist in RFC 768
definiert. Das Internetprotokoll (IP) ist das zur Leitweglenkung
bzw. zum Routing von Teilnehmerdaten und Steuersignalisierung verwendete
Protokoll des GPRS-Backbone-Netzwerks.
Das GPRS-Backbone-Netzwerk kann anfänglich auf dem IP-Protokoll
Version 4 (IPv4) basieren. Letztendlich wird IP-Version 6 (IPv6)
verwendet. IP-Version 4 ist in RFC 791 definiert.
-
Das
Unternetzwerk-abhängige
Konvergenzprotokoll (SNDCP: "Subnetwork
Dependent Convergence Protocol")
ist eine Übertragungsfunktionalität, die Netzwerkschicht-Eigenschaften auf
die Eigenschaften des zugrunde liegenden Netzwerks abbildet. Das
SNDCP ist in GSM 04.65 spezifiziert. Die logische Streckensteuerung
(LLC: "Logical Link
Control") stellt
eine hoch zuverlässige,
verschlüsselte
logische Strecke bereit. Die LLC soll unabhängig von den zugrunde liegenden
Funkschnittstellenprotokollen sein, um eine Einführung alternativer GPRS-Funklösungen mit
minimalen Änderungen
am NSS zu ermöglichen.
Die LLC ist in GSM 04.64 spezifiziert. Die Weitergabefunktion gibt
LLC-PDUs zwischen der Um- und der Gb-Schnittstelle im BSS weiter. Im
SGSN gibt die Weitergabefunktion PDP-PDUs zwischen der Gb- und der
Gn-Schnittstelle weiter. Das Basisstationssystem-GPRS-Protokoll
(BSSGP) transportiert Routing- und QoS-bezogene Informationen zwischen
BSS und SGSN. Das BSSGP ist in GSM 08.18 spezifiziert. Die Frame-Relay- bzw. Rahmenweitergabeschicht
transportiert BSSGP-PDUs.
Eine RLC/MAC-Schicht enthält
zwei Funktionen: die Funkstreckensteuerfunktion stellt eine zuverlässige Funklösungs-abhängige Strecke
bereit. Die Medienzugangssteuerfunktion steuert die Vorgänge der
Zugangssignalisierung (Anforderung und Bewilligung) für den Funkkanal
und die Abbildung von LLC-Rahmen auf den physikalischen GSM-Kanal.
RLC/MAC ist in GSM 03.64 beschrieben.
-
1 zeigt
auch den Aufbau eines Datenpakets DP. Es umfasst eine eigentliche
Teilnehmerinformationen transportierende Nutzlast PL und eine Anzahl
von Nachrichtenköpfen
bzw. Headers H für
Identifikations-, Leitweglenkungs- bzw. Routing- und Prioritätsinformationen,
usw. Jede Protokollschicht fügt
zu dem Datenpaket einen eigenen Nachrichtenkopf bzw. Header hinzu.
Der Begriff PrT wird später
erläutert.
-
Bei
GPRS werden verschiedene Identitäten
bzw. Kennungen eingesetzt. Eine eindeutige internationale Mobilteilnehmerkennung
(IMSI: „International
Mobile Subscriber Identity")
soll jedem Mobilteilnehmer in GSM zugewiesen sein. Dies ist auch
für Nur-GPRS-Mobilteilnehmer der
Fall. Ein GPRS-Teilnehmer, der durch eine IMSI identifiziert wird,
soll eine oder mehrere vorübergehend
und/oder dauerhaft zugeordnete Netzwerkschichtadressen haben, d.h.
PDP-Adressen, die mit dem standardmäßigen Adressierungsschema des
jeweiligen verwendeten Netzwerkschichtdienstes im Einklang stehen.
Eine PDP-Adresse kann eine IP-Adresse oder eine X.121-Adresse sein. PDP-Adressen
werden durch SM- ("Session
Management": Sitzungsverwaltung)
Vorgänge
aktiviert und deaktiviert.
-
Der
NSAPI und die TLLI werden zur Netzwerkschicht-Leitweglenkung verwendet. Ein Paar NSAPI/TLLI
ist innerhalb eines bestimmten Routingbereichs eindeutig. In der
MS identifiziert der NSAPI den PDP-Dienstzugangspunkt (PDP-SAP).
Im SGSN und im GGSN identifiziert der NSAPI den mit einer PDP-Adresse
in Zusammenhang stehenden PDP-Kontext.
Zwischen der MS und dem SGSN identifiziert die TLLI eindeutig die logische
Strecke. Der NSAPI ist ein Teil des Tunnelbezeichners (TID). Der
TID wird vom GPRS-Tunnelprotokoll zwischen
GSNs verwendet, um einen PDP- Kontext
zu identifizieren. Ein TID besteht aus einer IMSI und einem NSAPI.
Die Kombination von IMSI und NSAPI identifizieren eindeutig einen
einzigen PDP-Kontext. Der TID wird bei PDP-Kontextaktivierung zum
GGSN weitergeleitet, und er wird bei einer anschließenden Tunnelung von
Teilnehmerdaten zwischen dem GGSN und dem SGSN verwendet, um die
PDP-Kontexte der MS im SGSN und im GGSN zu identifizieren. Der TID
wird bei und nach einer Zwischen-SGSN-Routingaktualisierung auch
zum Weiterleiten von N-PDUs (Netzwerkschicht-Paketdateneinheiten)
vom alten SGSN zum neuen SGSN verwendet.
-
Jeder
SGSN und GGSN hat eine IP-Adresse, entweder vom Typ IPv4 oder IPv6,
zur gegenseitigen Kommunikation über
das GPRS-Backbone-Netzwerk. Für
den GGSN entspricht diese IP-Adresse
auch einem logischen GSN-Namen.
-
GPRS
transportiert PDP-PDUs transparent zwischen externen Netzwerken
und MSs. Zwischen dem SGSN und dem GGSN werden PDP-PDUs geroutet
bzw. geleitet und mit dem IP-Protokoll übermittelt. Das GPRS-Tunnelprotokoll
GTP übermittelt
Daten durch Tunnel. Ein Tunnel wird mit einem Tunnelbezeichner (TID) und
einer GSN-Adresse identifiziert. Alle PDP-PDUs werden zu GPRS-Routingzwecken eingekapselt
und entkapselt. Eine Einkapselungsfunktionalität besteht an der MS, am SGSN
und am GGSN. Eine Einkapselung ermöglicht, dass PDP-PDUs zum korrekten
PDP-Kontext in der MS, dem SGSN oder dem GGSN geliefert und diesen
zugeordnet werden können.
Es werden zwei unterschiedliche Einkapselungsschemata verwendet;
eines für
das GPRS-Backbone-Netzwerk zwischen zwei GSNs und eines für die GPRS-Verbindung
zwischen einem SGSN und einer MS.
-
Zwischen
einem SGSN und einem GGSN kapselt das GPRS-Backbone-Netzwerk eine PDP-PDU mit einem
GPRS-Tunnelprotokoll-Nachrichtenkopf
ein, und es fügt
diese GTP-PDU in eine TCP-PDU oder eine UDP-PDU ein, die wiederum
in eine IP-PDU eingefügt
wird. Die IP- und GTP-PDU-Nachrichtenköpfe enthalten die
GSN-Adressen und Tunnelendpunktbezeichner, die zum eindeutigen adressieren
eines GSN-PDP-Kontexts notwendig sind.
-
Zwischen
einem SGSN und einer MS wird ein PDP-Kontext mit einem Paar TLLI/NSAPI
eindeutig andressiert. Die TLLI wird zugeordnet, wenn die MS die
Anschlussfunktion einleitet. NSAPIs werden zugeordnet, wenn die
MS die PDP-Kontextaktivierungsfunktion
einleitet.
-
Dienstgüte (QoS: "Quality of Service") definiert, wie
die Paketdateneinheiten (PDUs) während
einer Übertragung
durch das GPRS-Netzwerk behandelt werden. Die für die PDP-Adressen definierten
QoS steuern zum Beispiel die Reihenfolge von Übertragung, Zwischenspeicherung
(die PDU-Warteschlangen) und Verwerfung der PDUs im SGSN und im
GGSN, insbesondere bei einer blockierten Situation. Daher stellen
unterschiedliche QoS-Niveaus zum Beispiel unterschiedliche Ende-zu-Ende-Verzögerungen,
Bitraten und Zahlen verloren gegangener PDUs für die Endteilnehmer dar.
-
Jeder
PDP-Adresse ist ein QoS-Profil zugeordnet bzw. assoziiert. Zum Beispiel
können
einige PDP-Adressen mit E-Mail assoziiert sein, wobei E-Mail längliche
Antwortzeiten tolerieren kann. Andere Anwendungen können Verzögerungen
nicht tolerieren und benötigen
einen sehr hohen Grad an Durchsatz, wobei interaktive Anwendungen
ein Beispiel darstellen. Diese unterschiedlichen Anforderungen werden
bei der QoS widergespiegelt. Liegt eine QoS-Anforderung jenseits
der Fähigkeiten
eines PLMN, handelt das PLMN die QoS so nahe wie möglich an
der erforderlichen QoS aus. Die MS akzeptiert entweder die ausgehandelte
QoS oder deaktiviert den PDP-Kontext.
-
Momentan
enthält
ein GPRS-QoS-Profil fünf
Parameter: Dienstvorrang, Verzögerungsklasse,
Zuverlässigkeit
sowie mittlere und Spitzenbitrate. Dienstvorrang definiert eine
Art Priorität
für die
zu einem bestimmten PDP-Kontext gehörenden Pakete (d.h. welche
Pakete im Fall einer Blockierung fallen gelassen werden). Verzögerungsklasse
definiert mittlere und maximale Verzögerungen für die Übermittlung jedes Datenpakets, das
zu diesem Kontext gehört.
Zuverlässigkeit
spezifiziert wiederum, ob auf LLC- ("Logical Link Control") und RLC- ("Radio Link Control") Schicht bestätigte oder unbestätigte Dienste
verwendet werden. Zusätzlich
legt sie fest, ob im Fall eines unbestätigten Dienstes ein gesicherter
Modus verwendet werden sollte, und ob das GPRS-Backbone TCP oder
UDP zum Übermitteln
von zu diesem PDP-Kontext gehörenden
Datenpaketen verwenden soll. Außerdem
werden diese veränderlichen
QoS-Parameter auf vier SAPIs ("Service
Access Point Identifiers": Dienstzugangspunktbezeichner)
abgebildet, die auf der LLC-Schicht verfügbar sind.
-
Das
GPRS-Netzwerk ist nicht in der Lage, die verschiedenen QoS-Anforderungen
von Internet-Anwendungen zu erfüllen.
IP- ("Internet Protocol") Verkehr findet
zwischen einem mobilen Host und einem festen Host statt, der sich
in einem externen Netzwerk befindet, z.B. im Internet. Unterschiedliche
Internet-Anwendungen erfordern unterschiedliche Arten von Diensten,
d.h. QoS, vom zugrunde liegenden Netzwerk. Verwendet der mobile
Host GPRS zum Zugang ins Internet, sollte das GPRS-Netzwerk daher
in der Lage sein, verschiedene QoS-Anforderungen von Internet-Anwendungen
zu erfüllen.
Im Grunde gibt es mindestens zwei IP-Verkehrstypen, die in Betracht
gezogen werden sollten: Realzeit- und Nichtrealzeit-Verkehr. Ein
Beispiel von Realzeit-Verkehr ist eine Sprachübertragung. E-Mail und Datentransfer
sind wiederum Beispiele von Nichtrealzeit-Anwendungen.
-
Momentan
können
QoS-Parameter nur mit einem bestimmten PDP-Kontext assoziiert werden
(d.h. einer bestimmten IP-Adresse,
falls der PDP-Typ gleich IP ist). Daher ist ein Einstellen unterschiedlicher QoS-Werte
für unterschiedliche
Anwendungen, die die gleiche IP-Adresse verwenden, nicht möglich. Dies
ist ein sehr schwerer Nachteil des derzeitigen QoS-Schemas. Die
derzeitigen GPRS-Spezifikationen definieren auch nur ein sehr statisches
QoS-Verhalten: eine Mobilstation kann nur bei Aktivierung des PDP-Kontexts
eine QoS-Verhandlung einleiten. Zur Zusammenfassung der hauptsächlichen Probleme:
das GPRS-QoS-Schema ist zu statisch, d.h. die QoS kann von der MS
oder dem GGSN nicht verändert
werden, nachdem die QoS zum ersten Mal ausgehandelt wurde, und außerdem müssen alle
Anwendungen, die die gleiche IP-Adresse
verwenden, auch das gleiche QoS-Profil verwenden, d.h. die gleichen
QoS-Werte. Dies ist offensichtlich nicht ausreichend zur Unterstützung der
Anforderungen verschiedener Internet-Anwendungen und Verkehrsströme wie etwa
Sprachübertragung,
Realzeit-Video, komprimiertes Video, E-Mail-Transfer, Dateitransfer
und Steuerinformationsaustausch hoher Priorität.
-
Das
Internet umfasst im Moment zwei unterschiedliche QoS-Schemata: „Integrierte
Dienste" und „Differenzierte
Dienste". Integrierte
Dienste bestehen aus drei Verkehrstypen: Garantierter Dienst, Dienst
kontrollierter Last und „Best-Effort-" bzw. bestmöglicher
Dienst. Garantierter Dienst ist sehr schwierig bereitzustellen, ohne
eine große
Menge an Zusatzinformationen bzw. Overhead im System einzuführen. Die
Ursache für
diesen Overhead besteht darin, dass Ende-zu-Ende-Verkehrsflüsse für unterschiedliche
Anwendungsverbindungen hergestellt werden sollten. Dies erfordert
daher große
Mengen an Datenbankverwaltung, Steuerinformationsaustausch und Verkehrsregelzuweisung
des Systems. Kontrollierte Last stellt sogar bei blockierten Situationen
ein unbelastetes Netzwerkverhalten bereit. Kontrollierte Last kann
mit Hilfe von Prioritäten
implementiert werden. Daher würde
eine Implementierung eines Dienstes kontrollierter Last wahrscheinlich
einfacher sein als Garantierter Dienst, der strenge Garantien bezüglich Übertragungsverzögerung usw.
benötigt.
-
„Best-Effort-" bzw. bestmöglicher
Dienst benötigt
keinerlei Garantien bezüglich
der QoS und ist daher in jedem Netzwerk sehr einfach zu implementieren.
-
Differenzierte
Dienste im Internet basieren auf der Idee, dass keine Datenflüsse benötigt werden,
sondern stattdessen jedes Datenpaket selbst QoS-Informationen transportiert.
Dies ermöglicht
eine sehr flexible und einfache Art und Weise zum Bereitstellen
einer bestimmter QoS für
die Anwendungen. Der Nachteil besteht darin, dass die Kapazität nicht
vollständig
garantiert werden kann, weil keine feste Kapazität jemals einem bestimmten Anwendungsfluss
zugewiesen wird. Dieses Schema ist jedoch aus Sicht der Kapazität und des
Systems sehr viel effizienter als das Schema Integrierter Dienste.
-
Ähnliche
Probleme wie vorstehend beschrieben können in jedem Mobilkommunikationsnetzwerk
auftreten.
-
Kurzfassung
der Erfindung
-
Eine
Aufgabe der Erfindung besteht darin, ein neues und verbessertes
Dienstgüte-
(QoS) Schema einzuführen,
das in Mobilkommunikationssystemen mit einer Paketdatenübertragungsfähigkeit
flexibler ist als die QoS-Schemata gemäß dem Stand der Technik.
-
Eine
weiter Aufgabe der Erfindung ist ein neues QoS-Schema, das eine Unterstützung für Internet-Anwendungen
und ihre QoS-Anforderungen für
Mobilkommunikationssysteme mit einer Paketdatenübertragungsfähigkeit
bereitstellt.
-
Die
Aufgaben der Erfindung werden mit dem Verfahren und der Vorrichtung
erreicht, die durch das gekennzeichnet sind, was in den zugehörigen unabhängigen Ansprüchen offenbart
ist. Bevorzugte Ausführungsbeispiele
der Erfindung sind in den zugehörigen
abhängigen
Ansprüchen
offenbart.
-
Gemäß der Erfindung
kann eine Mobilstation MS in Verbindung mit (d.h. während oder
nach) einer PDP-Kontextaktivierung
mehr als ein QoS-Profil innerhalb des PDP-Kontexts aktivieren. Mit
anderen Worten weist ein aktiver PDP-Kontext für eine MS mehrere QoS-Profile
auf. Übertragene
Pakete werden mit einer Profilkennzeichnung oder einem Profilindikator
ausgestattet, der angibt, auf welches Profil sich das Paket bezieht. Diese
Profilkennzeichnung hat vorzugsweise eine Länge von 2, 3 oder 4 Bits, d.h.
4, 8 oder 16 unterschiedliche Profile pro Kontext.
-
Beginnt
die MS damit, eine neue Anwendung auszuführen, die einen anderen Dienst
benötigt,
der nicht durch die bestehenden Profile bereitgestellt werden kann
(d.h. einer, der während
dieser Sitzung noch nicht verwendet wurde), muss im SGSN ein entsprechendes
Profil definiert werden. Die MS könnte zum Beispiel angeben,
dass FTP Profil 2 benötigt,
H323 Profil 3 benötigt,
usw. Wahlweise kann diese Information manuell oder durch beliebige
externe Signalisierungsverfahren konfiguriert werden, z.B. QoS-Profilherstellungsvorgang
oder RSVP- ("Resource
Reservation Protocol":
Ressourcenreservierungsprotokoll) Signalisierung.
-
Das
Dokument WO-A-9853576 (Stand der Technik im Rahmen der Bestimmungen
gemäß Art. 54(3) EPÜ) offenbart
mehrere Profile, die mit dem Übertragungspfad
(LLC) assoziiert sind, wobei jedes Profil zumindest einen QoS-Parameter
(LLSV) aufweist, wobei jeder der mehreren Flüsse mit einer Profilkennzeichnung (LLSVI)
versehen ist, die eines der mehreren Profile bezeichnet, die mit
dem in Frage stehenden Übertragungspfad
assoziiert sind, wobei die Zeitplanung und Regelzuweisung von Übertragungen
auf Grundlage des zumindest einen QoS-Parameters des Profils auf
die Datenflüsse
angewandt werden; diese Merkmale werden jedoch nicht im Zusammenhang
mit einer Datenpaketübertragung
durch das Mobilkommunikationssystem zwischen der Mobilstation und
einem externen Kommunikationssystem (wie etwa z.B. dem Internet)
eingesetzt.
-
Das
Dokument WO-A-9905828 (Stand der Technik im Rahmen der Bestimmungen
gemäß Art. 54(3) EPÜ) offenbart
eine Assoziierung mehrerer Profile mit mehreren Datenflüssen entsprechend
mehreren Anwendungen, die in der Mobilstation ausgeführt und über einen Übertragungspfad
zwischen der Mobilstation und einem externen Kommunikationssystem
wie etwa dem Internet übertragen
werden, wobei jedes Profil zumindest einen QoS-Parameter aufweist.
Die Zeitplanung (Scheduling) und Regelzuweisung (Policing) einzelner
Datenpakete auf Grundlage einer Profilkennzeichnung ist in keinem
dieser Dokumente offenbart.
-
Gemäß einem
einfachen Ausführungsbeispiel
der Erfindung wird das einzelne Profil für den PDP-Kontext gemäß dem Stand
der Technik durch mehrere Profile ersetzt, nämlich eines für jede Anwendung,
jeden Anwendungstyp oder jeden Datenfluss, oder ein vereinigtes
für mehrere
Flüsse.
Diese mehreren Profile werden als Fluss-bezogene Profile oder einfach
als Flussprofile bezeichnet. Gemäß einem
bevorzugten Ausführungsbeispiel
ist ein Hybride bzw. Mischling zwischen dem einzelnen Profil gemäß dem Stand
der Technik und dem Konzept separater Flussprofile bereitgestellt,
die durch das einfache Ausführungsbeispiel
bereitgestellt werden (d.h. ein Profil für jede Anwendung, jeden Typ
oder jeden Fluss). Dieser Hybrid besteht aus einem MS-bezogenen
Profil und mehreren Anwendungs-bezogenen Flussprofilen. Das Hybridprofil-Konzept
basiert auf der Idee, dass einige QoS-Parameter die maximalen Fähigkeiten
der MS (wie etwa eine maximale Bitrate am R-Bezugspunkt zwischen
MT und TE) oder die maximalen Rechte ihres Benutzers (wie etwa eine
maximale zulässige
Rate oder Nutzerwichtigkeit: „First
Class", "Business", usw.) kennzeichnen.
Solche maximalen Fähigkeiten
oder Rechte sind vorzugsweise in einem gemeinsamen MS-bezogenen
Profil definiert. Fehlt einem der Flussprofile ein Parameter, wird
der entsprechende Parameter des MS-bezogenen Profils (d.h. der allen Profilen
gemeinsame Wert) verwendet. Wahlweise kann es ein voreingestelltes
QoS-Profil für
einige oder alle PDP-Kontexte und/oder Vorgabewerte für das (die)
QoS-Profil e) geben.
-
Typische
Parameter für
die Flussprofile sind Zuverlässigkeit,
Spitzenbitrate, mittlere Bitrate, Vorrang- und Verzögerungsklasse
(wobei die letztere Realzeit-Eigenschaften eines bestimmten Flusses
bezeichnen kann, infolgedessen sie für jeden Fluss unterschiedlich
sein kann).
-
Anstatt
ein Profil direkt zu bezeichnen kann ein Paket eine Abbildung auf
eine externe QoS angeben (Ressourcenreservierungsprotokoll RSVP,
oder differenzierte IP-Dienste). Zum Beispiel kann eine Mobilstation bei
Empfang einer RSVP-Anforderung ein QoS-Profil (wie etwa Profil 4) für RSVP hinzufügen, wodurch
alle RSVP-Pakete in Profil 4 bezeichnende GTP-Pakete eingekapselt
werden und sie auf der LLC-Schicht der geeigneten SAPI transportiert
werden. "Geeignet" bedeutet, dass mit
jedem SAPI-Wert eine bestimmte QoS assoziiert oder vorkonfiguriert
ist. Mit anderen Worten sollte ein QoS-Profil auf den richtigen
SAPI (vierwertiger QoS-Wert) abgebildet werden. Dies setzt voraus,
dass der Spitzendurchsatz pro MS (anstatt pro Profil) definiert
werden kann. Der Spitzendurchsatz könnte auch sowohl für die fragliche
MS als auch für
jeden Fluss (oder einige von diesen) definiert werden. Dann könnte weder
der Verkehr pro Fluss noch der Gesamtverkehr der MS den entsprechenden,
ausgehandelten Spitzendurchsatz überschreiten.
Neue QoS-Profile können durch
RSVP-Signalisierung, Parameteraushandlung, Kennzeichnungszuweisungsvorgänge eingerichtet
oder eingeleitet werden, oder pro Anwendung vorab definiert werden.
-
Internet-Anwendungen
sind typischerweise asymmetrisch, d.h. Uplink- bzw. Aufwärtsstrecken-
und Downlink- bzw. Abwärtsstreckenflüsse weisen
unterschiedliche QoS-Anforderungen
auf. Bei „Video-On-Demand"-Anwendungen, Videospielen,
usw. ist der Aufwärtsstreckenverkehr
zum Beispiel typischerweise eine Signalisierungsstrecke, die eine
zuverlässige Übertragung
benötigt,
aber keinerlei strenge Verzögerungsanforderungen
aufweist. Der entsprechende Abwärtsstreckenverkehr
sind heruntergeladene Videoinformationen mit gerade den entgegengesetzten
Anforderungen: er hat einen oberen Grenzwert bezüglich der Verzögerung, aber
vermisste Rahmen können
ohne übermäßigen Schaden
ignoriert werden. Es müssen
zwei Parametermengen ausgehandelt werden (entweder als separate
QoS-Profile für
Aufwärtsstrecke
und Abwärtsstrecke, oder
ein QoS-Profil umfasst zwei separate Werte für Aufwärtsstrecke und Abwärtsstrecke).
-
Die
Erfindung ermöglicht,
dass praktisch jede beliebige Anzahl von QoS-Profilen gleichzeitig
verwendet werden kann, z.B. ein dediziertes QoS-Profil für jede von
mehreren Internet-Benutzeranwendungen, die in der Mobilstation mit
der gleichen IP-Adresse ausgeführt
werden. (Eine n-Bit-Profilkennzeichnung kann zwischen 2n unterschiedlichen
Profilen unterscheiden). Daher stellt die Erfindung eine Unterstützung für verschiedene Internet-Anwendungen
und ihre QoS-Anforderungen unter Verwendung von nur einer IP-Adresse
bereit, was unter Verwendung des momentanen QoS-Schemas von GPRS
nicht möglich
ist. Außerdem
kann weiterhin die gleiche Profilkennzeichnung verwendet werden,
falls ein QoS-Profil
neu ausgehandelt werden muss. Dies überwindet die Probleme in Bezug
auf die statischen QoS-Schemata gemäß dem Stand der Technik. Des Weiteren
führt die
Erfindung in das Mobilkommunikationssystem als Ganzes wenig Overhead
bzw. Zusatzinformationen ein.
-
Eine
Implementierung der Erfindung führt
zu einigen neuen Fragen bzw. Problemen. Eine dieser besteht darin,
wie die Randbereiche des Netzwerks die Pakete vom korrekten Fluss
oder Profil abbilden können. Gemäß einer
möglichen
Lösung
verwaltet ein Prozess im TE/MT/MS und im GGSN (oder einem beliebigen anderen
Knoten) die Fluss/Profil-Zuordnungen und verfolgt, welche Flüsse sich
auf welche Anwendungen (oder höherschichtigen
QoS-Schemata/zusammengefasste Flüsse,
wie etwa RSVP) beziehen. Dieser Prozess kann diese Zuordnungen am
TE/MT/MS bezeichnen, indem jedes Paket mit einer Fluss/Profil-Kennzeichnung
ausgestattet wird, die die MS zum Durchführen von Regelzuweisung (Policing)
und Zeitplanung (Scheduling) sowie zum Weiterleiten des Pakets unter
Verwendung der passenden Mittel (LLC bestätigt oder unbestätigt) verwendet.
In diesem Zusammenhang impliziert "geeignete Mittel" z.B. eine passende LLC-Strecke, die
einen bestimmten SAPI/QoS-Wert
verwendet (Abbildung auf zugrunde liegende Schichten basierend auf den
ausgehandelten QoS-Profilwerten und unter Verwendung der reservierten
Kapazität
für den Profilfluss). Wahlweise
kann die TE beliebige andere Mittel verwenden, und die MS kann die
Profilkennzeichnung basierend auf diesen Informationen hinzufügen. Der
TE/MT/MS leitet die Profilkennzeichnung wiederum in jedem Paket
weiter, das er überträgt.
-
An
den Randbereichen des Netzwerks (wie etwa an der MS und dem GGSN)
kann ein Prozess jedes ankommende Paket analysieren und herleiten,
mit welchem Fluss/Profil ein bestimmtes Paket assoziiert ist, und
fügt die
entsprechende Profilkennzeichnung in das Paket ein. Diese Analyse
und Herleitung kann beruhen auf einem IP-Prioritätsfeld (ToS oder DS in IPv4;
Verkehrsklasse oder DS in IPv6), Quellen- und Zieladressen, TCP/UDP-Portnummern oder
einem RSVP-Fluss (wobei ein Fluss durch seine IP-Adresse und Portnummer identifiziert
wird). Beide Randbereiche müssen
eine Tabelle beibehalten, die die Profilkennzeichnung mit den entsprechenden
Anwendungen (oder höherschichtigen
QoS-Schemata) in Verbindung bringt. Der Randbereich, der eine neue
Profilzuordnung herstellt, muss die Zuordnung an den anderen Randbereich
signalisieren. Der Mechanismus für
diese Art von Signalisierung kann ein GPRS-spezifischer Mechanismus
oder ein beliebiger anderer geeigneter Mechanismus sein, wie etwa
RSVP, das über
GPRS transportiert und auf GPRS-spezifische Signalisierungsmittel
abgebildet wird (d.h. ein neuer QoS-Profilherstellungsvorgang).
-
Die
TE im MT kann zum Signalisieren der Abbildungsinformationen zur
MS und zum Netzwerk, z.B. einer geeigneten Abbildung zwischen der
Profilkennzeichnung und den TCP/UDP-Portnummern, AT-Befehle verwenden.
Danach und nach der Profilherstellungsfunktion kann jedes Paket
auf den Fluss und das korrekte QoS-Profil abgebildet werden, das
der Portnummer sowohl im GGSN als auch in der MS entspricht. Es
können auch
einige QoS-Profile zum Transportieren von z.B. Datenpaketen, die
sich auf bestimmte Anwendungen/Portnummern beziehen, vorab eingerichtet
bzw. hergestellt werden.
-
Das
GTP verwendet Flussetiketten, die in RFC-1883 als ein Mechanismus
definiert sind, um einer Quelle zu ermöglichen, diejenigen Pakete
zu etikettieren bzw. zu kennzeichnen, für die sie eine spezielle Bearbeitung
durch die IPv6-Router anfordert, wie etwa einen nicht voreingestellten
QoS- oder Realzeitdienst. Bei einem GTP verwendenden Netzwerk könnte das
Flussetikett zum Transportieren der Profilkennzeichnungen verwendet
werden, um anzugeben, mit welchem Fluss und welchem QoS-Profil ein Paket
assoziiert ist.
-
Es
ist ebenso denkbar, dass mehrere Flüsse für jeden PDP-Kontext verwendet werden und die Pakete nicht
nur einen Flussbezeichner, sondern auch andere assoziierte QoS-Parameter transportieren.
Zum Beispiel könnte
bei GPRS der Vorrang pro Paket angegeben werden, wodurch er kein
Teil des QoS-Profils ist oder er diesen Wert des Flusses außer Kraft
setzt. Das QoS-Profil des Flusses kann jedoch weiterhin einen Vorgabewert
für den
Vorrang enthalten. Derartige Parameter können durch den Randbereich
des Netzwerks eingestellt werden, um die externen QoS-Parameter (in diesem
Fall die IP-Priorität)
abzubilden, oder weil mehr Verkehr als ausgehandelt übermittelt
wird und zusätzliche
Pakete markiert werden können.
Eine derartige Markierung ist analog zu einer Verwendung eines Verwerfungsbits.
Wahlweise könnte
eine geeignete Kennzeichnung in SNDCP- und GTP-Nachrichtenköpfe eingefügt werden.
-
Die
Erfindung ermöglicht
eine dynamische Neuaushandlung. Die mit jedem Fluss assoziierten QoS-Parameter
können
zu jeder Zeit neu ausgehandelt werden, ohne andere Flüsse zu beeinträchtigen.
Eine derartige Neuaushandlung kann durch beide Randbereiche des
Netzwerks oder durch einen dazwischen liegenden Knoten eingeleitet
werden. Sollte das Erfordernis auftreten, können die Randbereiche zusätzlich auch eine
neue Abbildung auf externe Parameter oder eine Portnummer neu aushandeln.
-
Ein
Aushandeln und Neuaushandeln eines QoS-Profils kann alle im Profil
enthaltenen Parameter, eine Untermenge der Parameter oder eine QoS-Klasse
(z.B. einen Bitvektor oder einen Ganzzahlenwert) umfassen. Der mögliche QoS-Klassenwert kann
Werte für
unabhängige
Parameter bezeichnen und auch definieren. Mit anderen Worten existieren
zwischen der Klasse und den unabhängigen Parametern wohl definierte
Beziehungen. Die Klassen können
in einer beliebigen Rangfolge A, B, usw. definiert werden, so dass
die Aushandlung wie bei LLC- und SNDCP-Parametern in einem Schritt durchgeführt werden
kann. Falls ein Netzwerkelement Klasse A unterstützt, erfordert dies, dass es
auch alle Klassen unterhalb dieser unterstützen muss, d.h. B, C. usw.
Das QoS-Profil bei der Aushandlung sollte durch ein QoS-Klassenfeld
ersetzt werden, welches nur 4 bis 8 Bits beträgt (16 bis 256 unterschiedliche
Klassen). Dies könnte
vereinfacht werden, indem gefordert wird, dass Spitzen- und mittlere
Bitraten immer MS-spezifisch (nicht Fluss-spezifisch) sind. Wird
eine derartige Forderung als zu einschränkend betrachtet, kann ein
zusätzliches
Feld oder können
zwei zusätzliche
Felder für
Bitmaps verwendet werden, die angeben, dass eine bestimmte Klassennummer
bei der (Neu-) Aushandlung eine Spitzen-/mittlere Bitrate kombiniert
mit einem MS-spezifischen Wert aufweist. Eine noch weitere Alternative
besteht darin, die Spitzen-/mittlere Bitrate von den Klassen zu
trennen und sie als einen MS-spezifischen
Parameter zu definieren, der getrennt von den Klassen ausgehandelt
wird.
-
An
beiden Randbereichen des Netzwerks entscheidet ein Prozess, wenn
eine neue externe QoS-Reservierungsanforderung
(z.B. eine RSVP-PATH-Nachricht ankommt, ob ein neuer Fluss eingerichtet
oder ein bestehender Fluss erneut verwendet (verändert, falls erforderlich)
werden sollte, um die Anzahl gleichzeitiger Flüsse zu beschränken. Ein
Fluss sollte der voreingestellte Fluss sein, mit dem Pakete assoziiert
werden, falls sie keine Flussbezeichner enthalten.
-
Eine
Regelzuweisung (Policing) von Paketen kann auf der LLC- oder der
SNDPC-Schicht durchgeführt
werden. Es könnte
pro MS oder pro Klasse oder pro Kontext durchgeführt werden. Ein Policing sollte
für N-PDUs
durchgeführt
werden, weil eine Gebührenerfassung
N-PDUs zählt.
Eine Zeitplanung (Scheduling) von Paketen kann auf der BSSGP-Schicht
durchgeführt
werden, weil sie Zellenspezifische Pipes bzw. Kommunikationskanäle sieht
und auf mehrere MSs bezogenen Verkehr wiedergewinnt. Der Scheduling-Algorithmus sollte
die Verzögerung
und den Vorrang berücksichtigen,
die im fraglichen QoS-Profil definiert sind (Teilnehmerpriorität). Eine
Zugangskontrolle sollte die Gesamtlast berücksichtigen und berechnen/entscheiden,
welche Bitraten einer einzelnen MS zugewiesen werden können. Dies
kann wie folgt zusammengefasst werden: ein Prozess auf der SNDPC-Schicht regelt bzw.
kontrolliert den Fluss und leitet die Pakete, die die Regelzuweisungseinrichtung
passieren, über
die LLC-Schicht an den Scheduler bzw. die Zeitplanungseinrichtung
auf der BSSGP-Schicht weiter. Der Scheduler sendet die Pakete an
das BSS oder verwirft sie bei einer Überlastsituation. In Verbindung
mit einer Fluss/Profil-Einrichtung berechnet die Zugangskontrolle
auf Grundlage der Gesamtlastsituation, welche Bitraten einem bestimmten
Fluss garantiert werden können.
-
Gemäß einem
bevorzugten Ausführungsbeispiel
der Erfindung umfasst das Profil, das durch die mit jedem Datenpaket
assoziierte Profilkennzeichnung bezeichnet wird, zumindest Prioritätsinformationen
und Verzögerungsanforderungen.
Die Verzögerungsklasseninformationen
weisen zwei oder mehr Werte auf, die die Wichtigkeit des Pakets
angeben und dadurch auch die Reihenfolge festlegen, in der Datenpakete
bearbeitet werden sollten. Mit anderen Worten definieren sie eine
Präferenz
zum Fallenlassen, die im Fall einer Netzwerkblockierung zu verwenden
ist. Die Prioritätsinformationen
können
auch eine Nominalbitrate definieren, wie bei einem Fall, der als
SIMA-Ansatz ("Simple
Integrated Media Access":
einfacher integrierter Medienzugang, siehe nachfolgendes Beispiel
1) bekannt ist. Es können
mindestens zwei Verkehrstypen mit unterschiedlichen Verzögerungsanforderungen
unterschieden werden: Realzeit- und Nichtrealzeit-Verkehr. Für Nichtrealzeit-Verkehrstypen
können
zum Beispiel die folgenden Untertypen unterschieden werden: Steuerverkehr,
interaktiver Verkehr, begleitete Übermittlung großer Datenmengen,
unbegleitete Datenübermittlung,
Füllverkehr, uncharakterisierter
Verkehr und nachfolgend als "Best-Effort-Verkehr" bezeichneter bestmöglicher
Verkehr. Sie können
durch Verwendung unterschiedlicher Verzögerungsklassenwerte für jeden
Typ bezeichnet werden. Der Verkehrstyp hat einen Einfluss auf Neuübertragungsstrategien
und Daten-Warteschlangenbildung im Netzwerk. Eine Neuübertragung
verloren gegangener Datenpakete wird zum Beispiel für Realzeit-Verkehr üblicherweise
nicht benötigt
und es ist oft besser, Realzeit-Datenpakete fallen zu lassen als
sie zu spät
zum Empfänger
zu senden.
-
Gemäß einem
weiteren Ausführungsbeispiel
der Erfindung ist an Stelle von oder zusätzlich zu einem Einsatz von
Zuverlässigkeit
auf einer PDP-Kontextebene, wie es momentan beim Stand der Technik
gemacht wird, Zuverlässigkeit
ebenso direkt dem Profil assoziiert, das mit dem Datenpaket assoziiert
ist. Das Kommunikationsnetzwerk ist z.B. auf der LLC-Schicht zum
Bereitstellen unterschiedlicher Verbindungen eingerichtet, von denen
jede mit einer anderen Zuverlässigkeit
und einer anderen QoS-Unterstützung
assoziiert ist. Diese Verbindungen können in jedem beliebigen oder
mehreren Abschnitten im Mobilkommunikationsnetzwerk bereitgestellt
sein, z.B. an der Funkschnittstelle und/oder auf einer Übertragungsstrecke
zwischen zwei Knoten im Netzwerk. Eine Verbindung kann zum Beispiel
ein verbindungsorientierter Pfad mit einer höheren Zuverlässigkeit
in Folge eines Neuübertragungsprotokolls
sein und eine andere Verbindung kann ein verbindungsloser Pfad (z.B.
unter Verwendung von UDP) mit einer niedrigeren Zuverlässigkeit
sein. Datenpakete werden über diese
Verbindungen basierend auf der Zuverlässigkeit und den mit dem fraglichen
Profil assoziierten QoS-Informationen
(d.h. im QoS-Profil enthalten oder durch das Paket angegeben) gemultiplext.
Die von der QoS-Profilkennzeichnung
bezeichneten Flüsse,
die eine zuverlässige Übertragung
benötigen,
sollten über
einen zuverlässigen
verbindungsorientierten Pfad gesendet werden. Die Pakete in Flüssen, die
keinen zuverlässigen
verbindungsorientierten Pfad benötigen,
sollten über
einen verbindungslosen Pfad gesendet werden. Sowohl die verbindungsorientierten
als auch die verbindungslosen Pfade können eingerichtet sein, Pakete
von nur einem PDP-Kontext
zu übermitteln,
oder sie können
von mehreren PDP-Kontexten
verwendet werden. Außerdem
kann die Einrichtung unterschiedlicher Pfade mit unterschiedlichen Zuverlässigkeitseigenschaften
dynamisch oder statisch sein (d.h. bei Bedarf, oder wenn der Tunnel
(PDP-Kontext) erzeugt wird). Dieses Konzept der Erfindung kann in
jedem Paketdatenkommunikationsnetzwerk angewandt werden, sogar in
einem, das keinerlei PDP-Kontext verwendet, wie etwa TCP/IP-, ATM-
oder X.25-Netzwerke.
-
Wie
vorstehend erwähnt
definiert der PDP-Kontext eine Art eines Übertragungstunnels mit spezifischen
Eigenschaften durch ein Mobilkommunikationsnetzwerk. Wie bei herkömmlichen
Netzwerken können die
Parameter des PDP-Kontexts
einen PDP-Typ (z.B. X.25 oder IP), eine PDP-Adresse (z.B. IP-Adresse) und einen
NSAPI beinhalten. Der PDP-Kontext kann wahlweise auch einen oder
mehrere QoS-Parameter
beinhalten. Zum Beispiel können
eine mittlere Bitrate und eine Spitzenbitrate für den gesamten PDP-Kontext verwendet
werden. Die QoS des PDP-Kontexts kann auch eine Zuverlässigkeit
beinhalten. Ist sowohl das QoS-Profil der
PDP-Ebene als auch ein zusätzliches
QoS-Profil zu verwenden, kann die Verkehrsregelzuweisung teilweise
auf den QoS-Werten beruhen, die auf den PDP-Kontext bezogen sind,
z.B. auf die mittlere Bitrate und die Spitzenbitrate. Sendet der
Teilnehmer mit einer zu hohen Geschwindigkeit, könnte die Priorität seiner
oder ihrer Datenpakete bestimmter Flüsse daher vom System vorübergehend
verringert werden. Dies stellt sicher, dass Pakete, die nicht mit
dem QoS-Vertrag der PDP-Ebene im Einklang stehen, falls erforderlich,
zuerst verworfen werden. Zusätzlich
könnten
QoS-Informationen in den zusätzlichen
QoS-Profilen innerhalb des PDP-Kontexts nur innerhalb des in Frage
stehenden PDP-Kontexts relevant sein. Ist dies der Fall, wird das QoS-Profil
eines bestimmten Flusses nur in Bezug auf das globale voreingestellte
QoS-Profil des PDP-Kontexts in Betracht gezogen.
-
Ein
weiteres Merkmal der Erfindung kann eine Abbildung der im Mobilkommunikationsnetzwerk
verwendeten QoS-Parameter
auf diejenigen sein, die bei einer Benutzeranwendung im mobilen
Paketdatenendgerät
verwendet werden, oder auf diejenigen, die in einem externen Kommunikationssystem
verwendet werden, und umgekehrt. Die Abbildung wird für jedes
Paket durchgeführt,
das in das Mobilkommunikationssystem eintritt oder dieses verlässt.
-
Die
Profilkennzeichnung in den Datenpaketen kann in einem Paketnachrichtenkopf,
in einem Nachrichtenkopf eines Protokolls niedrigerer Schicht oder
als Teil der Daten an sich angeordnet sein. Die QoS-Steuerung kann
auch beruhen auf den QoS-Informationen im QoS-Profil, das mit einem
bestimmten PDP-Kontext in Beziehung steht, den Prioritäts- und
Verkehrstypinformationen, die in den Datenpaketen enthalten sind,
oder beiden.
-
Ein
Ausführungsbeispiel
der Erfindung umfasst auch eine Abrechnung der Teilnehmer. Teilnehmer können zusätzlich zu
den normalen Attributen der PDP-Ebene auch gemäß den Attributen in unabhängigen QoS-Profilen
abgerechnet werden. Dies erfordert, dass die Knoten des Mobilkommunikationsnetzwerks,
wie etwa die GSNs bei GPRS, Informationen über die übermittelten Datenpakete und
die entsprechenden Flüsse/Profile
sammeln. Andererseits ermöglicht
die Erfindung auch Gebührenerfassungs-
bzw. Abrechnungsschemata unter Verwendung der normalen Attribute
der PDP-Ebene, wie etwa der mittleren Bitrate und der Spitzenbitrate
des PDP-Kontexts, oder eine Kombination dieser Schemata.
-
Gemäß einem
weiteren bevorzugten Ausführungsbeispiel
der Erfindung ist das Mobilkommunikationsnetzwerk ein Paketfunknetzwerk
wie etwa der Allgemeine Paketfunkdienst (GPRS: "General Packet Radio Service") von GSM oder seine
Weiterentwicklung im UMTS-System. Die Erfindung kann auch auf eine
proprietäre
bzw. herstellereigene Art und Weise implementiert werden: Nutzlasten
von Datenpaketen könnten
eine Profilkennzeichnung enthalten, obwohl immer noch das momentane
GPRS-QoS-Profil verwendet wird.
-
Diese
Erfindung kann auch auf verschiedene zukünftige Mobilnetzwerke wie etwa
UMTS angewandt werden.
-
Kurze Beschreibung
der einzelnen Darstellungen des Zeichnungssatzes
-
Im
Folgenden wird die Erfindung mit Hilfe bevorzugter Ausführungsbeispiele
unter Bezugnahme auf die begleitenden Zeichnungen ausführlicher
beschrieben, bei denen zeigen:
-
1 eine
GPRS-Netzwerkarchitektur;
-
2 eine
GPRS-Übertragungsebene
und die Verwendung der Profilkennzeichnungen gemäß der Erfindung;
-
3 eine
bevorzugte Anordnung mehrerer Profile innerhalb eines einzelnen
PDP-Kontexts;
-
4 eine
Zusammenarbeit zwischen unterschiedlichen Netzwerkelementen;
-
5 einen
Kontextaktivierungsvorgang; und
-
6 einen
Kontextänderungsvorgang.
-
Ausführliche
Beschreibung der Erfindung
-
Wie
gemäß 1 gezeigt
kann die Erfindung auf jedes Mobilkommunikationssystem mit einer
Paketdatenübertragungsfähigkeit
angewandt werden.
-
Der
Begriff "Paketdatenprotokoll" (PDP) oder "PDP-Kontext", wie er hierin verwendet
wird, sollte so verstanden werden, dass er sich allgemein auf jeden
Zustand in einer Mobilstation und in mindestens einem Netzwerkelement
oder einer Funktionalität
bezieht, wobei der Zustand einen Datenpaket-Übertragungspfad oder einen
Tunnel mit einer spezifischen Menge an Parametern durch das Mobilkommunikationsnetzwerk
bereitstellt. Der Begriff "Knoten", wie er hierin verwendet
wird, sollte so verstanden werden, dass er sich allgemein auf jedes
Netzwerkelement oder jede Funktionalität bezieht, das/die die Datenpakete
bearbeitet, die durch den PDP-Kanal übermittelt werden.
-
Die
Erfindung kann auf besonders wünschenswerte
Weise zur Bereitstellung eines allgemeinen Paketfunkdienstes GPRS
im paneuropäischen
digitalen Mobilkommunikationssystem GSM oder in entsprechenden Mobilkommunikationssystemen
wie etwa DCS1800 (auch als GSM1800 bekannt) und PCS ("Personal Communication
System") verwendet
werden. Im Folgenden werden die bevorzugten Ausführungsbeispiele der Erfindung
mit Hilfe eines GPRS-Paketfunknetzwerks beschrieben, das durch den
GPRS-Dienst und das GSM-System gebildet wird, ohne die Erfindung
auf dieses spezielle Paketfunksystem zu beschränken.
-
Ein
Datenpaket DP gemäß dem Stand
der Technik besteht aus einem Nutzlastteil PL und verschiedenen
Nachrichtenköpfen
bzw. Headers H, nämlich
einem für
jede Protokollschicht. Gemäß der Erfindung
unterhalten die Mobilstation MS und die Unterstützungsknoten SGSN, GGSN, usw.
mehrere Profile Pr, wobei jedes Profil mit einer Profilkennzeichnung
PrT markiert ist. Jedes Datenpaket DP weist auch eine Profilkennzeichnung
PrT auf, die das relevante der mehreren Profile Pr bezeichnet. Die
meisten Protokolle verwenden Nachrichtenköpfe, bei denen einige Bits
ungenutzt, redundant bzw. überflüssig oder
zur zukünftigen
Verwendung reserviert sind. Solche übrigen bzw. freien Bits können zum
Bezeichnen der Profilkennzeichnung PrT verwendet werden, da typischerweise
nur 2 bis 4 Bits benötigt
werden (4 bis 16 unterschiedliche Profile pro MS). Weisen die Nachrichtenköpfe keine
derartigen redundanten Bits auf, können die Nachrichtenköpfe erweitert
werden, oder die Profilkennzeichnung PrT kann an den Nutzlastteil
PL angehängt
werden.
-
3 veranschaulicht
das Hybridprofilkonzept der Erfindung. Für jeden PDP-Kontext existiert
ein MS-spezifisches
und/oder ein PDP-Kontext-spezifisches Vorgabeprofil Pr0,
welches Vorgabewerte für
einige oder alle der QoS-Parameter bereitstellt. Für jede Anwendung,
jeden Anwendungstyp oder jeden Fluss, der mit der MS assoziiert
ist, kann ein separates Profil Pr existieren. Die separaten Profile
Pr sind derart mit dem PDP-Kontext assoziiert, dass eine Profilkennzeichnung
mit einer geringen Anzahl von Bits (z.B. 2 bis 4 Bits) ausreichend
ist, um das relevante Profil Pr zu bezeichnen. 3 zeigt
ein derartiges Profil mit einer Kennung 2 und mit Bezug auf eine
FTP-Anwendung. Für
diese Anwendung existieren einzelne Werte für Dienstvorrang (y1), Verzögerungsklasse
(y2), Zuverlässigkeit
(y3) und mittlere Bitrate (y4). Es sind jedoch keine Werte für die Spitzenbitrate
definiert, und daher wird der Vorgabewert (x5) des Vorgabeprofils
Pro verwendet.
-
Die
QoS-Informationen, die mit dem durch die PrT bezeichneten Profil
assoziiert sind, werden in verschiedenen Knoten im GPRS-System zur
Zeitplanung (Scheduling) und Regelzuweisung (Policing) der Übertragung
der Datenpakete eingesetzt. Wie vorstehend erwähnt ist QoS bei den derzeitigen
GPRS-Spezifikationen mit dem PDP-Kontext assoziiert, was die verschiedenen
vorstehend beschriebenen Probleme verursacht. Gemäß der Erfindung
weist jedes Datenpaket DP eine Profilkennzeichnung PrT auf, wodurch
die Zeitplanung und Regelzuweisung (abhängig vom Fluss) Paket für Paket
durchgeführt
werden kann. Genauer gesagt bezeichnet das mit jedem Datenpaket
DP assoziierte Profil Pr zumindest einen QoS-Parameter, und die
Zeitplanung und die Regelzuweisung der Übertragung der Datenpakete
wird Paket für
Paket gemäß diesem
QoS-Parameter durchgeführt,
der durch das Profil bezeichnet ist, während er jedoch innerhalb eines "Übertragungstunnels" durch den PDP-Kontext definiert
ist, falls für
den fraglichen PDP-Kontext
eine derartige Voreinstellung definiert ist.
-
Gemäß einem
bevorzugten Ausführungsbeispiel
der Erfindung umfassen die QoS-Informationen, die mit dem durch
die Profilkennzeichnung bezeichneten Profil assoziiert sind, zumindest
Prioritätsinformationen und
eine Verzögerungsklasseninformation,
sowie wahlweise Zuverlässigkeitsinformationen.
Die Verzögerungsklasseninformation
weist zwei oder mehr Werte auf, die die Wichtigkeit des Pakets angeben,
und dadurch definiert sie auch die Reihenfolge, in der Datenpakete
im Fall einer Netzwerkblockierung bearbeitet werden sollten. Die
Prioritätsinformationen
können
auch wie beim SIMA-Ansatz
eine Nominalbitrate definieren oder die Verwerfungsreihenfolge von
Paketen/Flüssen
angeben. Zusätzlich
dazu, wahlweise eine mittlere Bitrate und eine Spitzenbitrate in
den Profilen zu haben, erfordert dieses bevorzugte Ausführungsbeispiel
der Erfindung typischerweise die folgenden Änderungen an GPRS-Spezifikationen:
- 1) Wie gemäß 2 gezeigt
sollten SNDCP- und GTP-Nachrichtenköpfe zusätzliche
Bits zum Übertragen einer
Profilkennzeichnung tragen (GTP-Bits werden in beiden Richtungen
benötigt,
SNDCP-Bits können
in bestimmten Fällen
nur für
Aufwärtsstreckendaten
verwendet werden). Zusätzlich
kann ein Diensttyp-Feld von IPv4 oder ein Prioritätsfeld oder
ein Verkehrsklassenfeld von IPv6 im GPRS-Backbone bzw. -Basisnetzwerk
verwendet werden, falls IP-Router usw. auch eine Priorisierung von
Paketen sowie QoS-basierte Warteschlangenbildung oder Zeitplanung
unterstützen
sollen. Innerhalb des GPRS-Backbone bzw. -Basisnetzwerks kann auch
RSVP zur Bereitstellung spezieller Flüsse mit unabhängiger QoS-Bearbeitung
verwendet werden. IPv6-Verkehrsflüsse können zur Übertragung von Daten eingerichtet
werden, die zu bestimmten Verkehrstypen gehören. Es ist auch machbar, dass
keine zusätzlichen
Bits in den GTP-Nachrichtenköpfen zugewiesen
werden, sondern die Profilinformationen von niedrigeren Schichten
transportiert werden. Unterstützt
das zugrunde liegende GPRS-Basisnetzwerk derartige Mechanismen,
können
diese Informationen zum Beispiel in einem IP-Nachrichtenkopf oder
einem beliebigen anderen Nachrichtenkopf eines Protokolls niedrigerer
Schicht enthalten sein. Ist dies der Fall, sollen der SGSN und der
GGSN fähig
sein, diese Informationen niedrigerer Schicht wiederherzustellen,
um sie erneut zu verwenden. Die Profilkennzeichnung kann zu Datenpaketen
an der Gb-Schnittstelle
ebenso wie z.B. zu BSSGP-Protokollnachrichten
hinzugefügt
werden. Dann können
die QoS-Informationen auf Frame-Relay- oder ATM-Konzepte an SGSN und
BSS abgebildet werden.
- 2) Bei Systemen gemäß dem Stand
der Technik weist ein PDP-Kontext ein einziges QoS-Profil unter
Verwendung eines einzigen SAPI auf. Mehrere PDP-Kontexte könnten den
gleichen SAPI verwenden, falls ihre QoS-Profile ähnlich sind. Gemäß der Erfindung
kann ein einziger PDP-Kontext mehrere SAPIs verwenden. Die den gleichen
SAPI verwendenden Flüsse
sollten ähnliche
QoS-Profile aufweisen. PDP-Kontexte werden über mehrere LLC-SAPIs gemultiplext
(z.B. falls Zuverlässigkeit
als einer der QoS-Parameter verwendet wird). Mit anderen Worten
sollte die SNDC-Schicht zum Multiplexen von NSAPI gemäß den QoS-Profilinformationen
auf der LLC-Schicht auf mehreren SAPIs fähig sein, wie es nachstehend
ausführlicher
beschrieben wird.
-
In
den niedrigeren Protokollen der Funkschnittstelle, wie etwa RLC,
werden Änderungen
nicht unbedingt benötigt.
Funkschnittstellenprotokolle könnten
jedoch später
durch neuere Protokolle wie etwa Breitband-CDMA (WCDMA) ersetzt
werden. Die Erfindung ist auch bei einem derartigen Fall anwendbar,
und eine der hierin beschriebenen ähnliche QoS-Unterstützung (Priorisierung,
Verkehrstyp/Verzögerungen)
kann schon an sich in diese Funkprotokolle implementiert werden.
-
4 veranschaulicht
ein Zusammenarbeiten zwischen unterschiedlichen Netzwerkelementen.
Nach diesen Änderungen
kann eine Abbildung auf Parameterebene zwischen differenzierten
Diensten im Internet und bei GPRS zum Beispiel wie folgt bereitgestellt
werden: Prioritätsinformationen
im Internet werden auf einen Dienstvorrang bei GPRS abgebildet.
-
Ein
Hinweis bezüglich
Realzeit- gegenüber
Nichtrealzeit-Anforderungen
im Internet wird auf Verzögerungsklassen- und/oder Zuverlässigkeitsinformationen
bei GPRS abgebildet: mindestens zwei Verzögerungstypen werden benötigt, aber
eine genauere Abbildung von Verkehrstypen auf mehrere Verzögerungsklassen
ist ebenfalls möglich.
-
Es
können
Zuverlässigkeitsinformationen
verwendet werden, um die Zuverlässigkeitsanforderungen jeder
Anwendung in Form einer von mindestens zwei Zuverlässigkeitsklassen
anzugeben. Wird eine zuverlässige Übertragung
(Neuübertragungen,
Prüfsummen
und/oder TCP) benötigt,
bezeichnet das mit den Datenpaketen assoziierte Profil Zuverlässigkeitsklasse
1. Wird eine zuverlässige
Lieferung über
die Funkschnittstelle benötigt,
aber ist UDP im GPRS-Basisnetzwerk ausreichend, bezeichnet das mit
den Datenpaketen assoziierte Profil Zuverlässigkeitsklasse 2. Abhängig von
den Anforderungen kann das mit den Datenpaketen assoziierte Profil
wahlweise Zuverlässigkeitsklasse
3, 4 oder 5 bezeichnen. Zuverlässigkeitsklassen
4 und 5 werden für
Realzeit-Verkehr
verwendet.
-
Ein
weiteres Merkmal der Erfindung kann eine Abbildung der im Mobilkommunikationsnetzwerk
verwendeten QoS-Parameter
auch diejenigen sein, die bei einer Benutzeranwendung im mobilen
Paketdatenendgerät
verwendet werden, oder auf diejenigen, die im externen Kommunikationssystem
verwendet werden, und umgekehrt. Die Abbildung wird für jedes
Paket durchgeführt,
das in das Mobilkommunikationssystem eintritt oder dieses verlässt. Im
Folgenden werden zwei Beispiele der Abbildung gegeben.
-
Beispiel 1
-
Ein
einfacher integrierter Medienzugang (SIMA: "Simple Integrated Media Access") ist ein neuer,
einfacher Ansatz, der von K. Kilkki, Nokia Research Center, in Juni
1997 als ein "Internet-Draft" präsentiert
wurde. Internet-Drafts sind Arbeitsdokumente der "Internet Engineering
Task Force" (IETF),
ihrer Arbeitsbereiche und Arbeitsgruppen. SIMA wird als ein Beispiel
eines Internet-QoS-Schemas verwendet, weil es zum Bereitstellen eines
gleichmäßigen Dienstkonzepts
für unterschiedliche
Bedürfnisse
fähig ist,
von Datentransferanwendungen unter Verwendung eines TCP/IP-Protokolls
ohne lockere Verzögerungs-
und Paketverlustanforderungen bis zu Realzeit-Anwendungen mit sehr
strengen Qualitäts-
und Verfügbarkeitsanforderungen.
Gemäß dem SIMA-Konzept
soll jeder Teilnehmer vor dem Verbindungsaufbau nur zwei Sachverhalte
definieren: eine Nominalbitrate (NBR) und die Auswahl zwischen Realzeit-
und Nichtrealzeit-Dienstklassen.
Die NBR kann acht Werte von 0 bis 7 aufweisen. Eine Abbildung von
Parametern von SIMA auf GPRS und umgekehrt kann zum Beispiel wie
folgt erfolgen:
Realzeit-/Nichtrealzeit-Bit: falls dieses Bit
Realzeit-Anforderungen
bezeichnet, wird es auf GPRS- Verzögerungsklasse
1 abgebildet, andernfalls wird es auf Verzögerungsklasse 4 abgebildet.
Verzögerungsklasse
3 kann jedoch für
Nichtrealzeit-Dienste verwendet werden, falls eine spezielle Art
und Weise zum Bezeichnen von Best-Effort-Verkehr besteht, z.B. muss
dieses Bit nicht immer vorhanden sein, oder eine genauere Definition
zum Unterscheiden von Realzeit-, Nichtrealzeit- und Best-Effort-Verkehr verwendet
wird. Bei GPRS kann Realzeit-Verkehr
ein niedrigerer Zuverlässigkeitsklassenwert
zugeordnet werden als Nichtrealzeit-Verkehr. Im Allgemeinen werden
bei GPRS Zuverlässigkeitsklassen
1, 2 und 3 üblicherweise
für Nichtrealzeit-Verkehr
und Klassen 3, 4 und 5 für
Realzeit-Verkehr verwendet. Für
Nichtrealzeit-Verkehr ist der für
eine Übertragung
geeignete Zuverlässigkeitsklassenwert
umso niedriger, je höher
die NBR ist.
-
-
Es
sollte beachtet werden, dass die Dienstvorrang- und die Verzögerungsklassenparameter
hierbei eine Bedeutung aufweisen, die sich einigermaßen von
den derzeitigen GPRS-Spezifikationen unterscheidet, bei denen diese
Parameter mit PDP-Kontexten und nicht mit jeder Anwendung assoziiert
sind. Daher können auch
andere Namen für
die Parameter gewählt
werden, wie etwa Priorität
oder Nominalbitrate und Verkehrstyp. Das QoS-Profil kann alle bestehenden
Parameter (Dienstvorrang, Zuverlässigkeitsklasse,
Verzögerungsklasse,
mittlere Bitrate und Spitzenbitrate) umfassen. Wahlweise kann es
nur einen Teil der Parameter umfassen, wie etwa nur die mittlere
und die Spitzenbitrate. Das QoS-Profil kann auch einen Parameter
maximaler Burstgröße umfassen,
um einen Pufferzuweisungsvorgang zu erleichtern.
-
Eine
QoS-Zeitplanung in GPRS-Netzwerkelementen (z.B. in einem SGSN und
einem GGSN) basiert auf der Verzögerungsklasse.
Dies erfordert, dass mindestens zwei Puffer bzw. Zwischenspeicher
existieren (und maximal so viele wie unterschiedliche Verzögerungsklassen
vorhanden sind): einer für
Realzeit-Pakete (wobei dieser Puffer viel kleiner sein sollte!)
und ein anderer für
Nichtrealzeit-Pakete. Realzeit-Verkehr sollte immer vor Nichtrealzeit-Verkehr
gesendet werden. Der Dienstvorrang definiert die Reihenfolge, in
der Pakete im Fall einer Netzwerkblockierung fallen gelassen werden
können.
-
Beispiel 2
-
Eine
Abbildung eines Diensttyp- (ToS: „Type of Service) Oktetts
in den Nachrichtenköpfen
von IP-PDUs auf GPRS-Attribute.
Das ToS-Oktett in einem IP-Nachrichtenkopf ist im Moment weitgehend
ungenutzt. Sein ursprünglicher
Zweck war es, Verkehrstypinformationen zu beinhalten und festzulegen,
welche Art von Dienst von der Paketlieferung benötigt wird. Weil das ToS-Oktett
heutzutage nicht in allgemeiner Verwendung ist, ist es möglich, die
Bits in diesem Oktett für
die Zwecke der Erfindung neu zu definieren. Eine Definition des
ToS-Oktetts ist in RFC 791 gegeben. Bits 0 bis 2 von ToS geben den
Vorrang an, Bits 3 bis 5 geben den vom Paket benötigten ToS an (z.B. angeforderte
Verzögerungs-,
Durchsatz- und Zuverlässigkeitsniveaus)
und Bits 6 bis 7 sind zur zukünftigen
Verwendung reserviert. RFC 1349 erweitert das ToS-Feld um ein Bit
(das von den "für die Zukunft
reservierten" Bits
genommen wird). Daher können
4 Bits verwendet werden, um einen ToS zu bezeichnen.
-
Eine
Abbildung zwischen den Vorrangbits (0 bis 2 in ToS) und einem GPRS-Dienstvorrang
kann wie folgt erfolgen:
-
Es
gibt drei unterschiedliche Arten zur Durchführung der Abbildung zwischen
den Verkehrstypinformationen (d.h. dem ToS-Feld im ToS-Oktett) und
der GPRS-Verzögerungsklasse:
Wird
nur das Bit 3 im ToS-Feld verwendet, um die Verzögerungsanforderungen im IP-Nachrichtenkopf
zu bezeichnen: Wert 0 von Bit 2 wird auf GPRS-Verzögerungsklasse
2 abgebildet und Wert 1 von Bit 2 wird auf GPRS-Verzögerungsklasse
4 ("Best-Effort") abgebildet.
-
Wird
das gesamte ToS-Feld in ToS zum Bezeichnen von Verzögerungsanforderungen
verwendet, d.h. es sind 4 Bits (Bits 3 bis 6) für diesen Zweck verfügbar, könnte eine
mögliche
Abbildung die folgende sein: Bitwert 1000 wird auf GPRS-Verzögerungsklasse
1 (d.h. auf Bitwert 000) abgebildet, Bitwert 0100 auf GPRS-Verzögerungsklasse
2 (d.h. auf Wert 001), ToS-Werte 0010 und 0001 auf GPRS-Verzögerungsklasse
3 (d.h. auf Wert 010) und der ToS-Wert 0000 auf GPRS-Verzögerungsklasse
4 (d.h. auf Wert 011).
-
Eine
andere Art und Weise zum Abbilden der ToS-Bits von IP auf GPRS-Verzögerungsklassen
wäre die
folgende: 11x auf Verzögerungsklasse
1, 10x auf Verzögerungsklasse
2, 01x auf Verzögerungsklasse
3 und 00x auf Verzögerungsklasse
4. In diesem Fall bedeutet x, dass für ToS ein oder mehrere zusätzliche
Bits verwendet werden könnten,
aber sie keinerlei Einfluss auf den Auswahlprozess der GPRS-Verzögerungsklasse haben.
Sind für
GPRS später
mehr Verzögerungsklassen
definiert, könnte
die Abbildung auch diese zusätzlichen
Bits in Betracht ziehen.
-
Momentan
existiert auch ein Bit im IP-ToS-Feld, das das gewünschte Zuverlässigkeitsniveau
festlegt. Ist dieses Bit in Zukunft immer noch verfügbar, z.B.
falls die erste vorstehende Wahlmöglichkeit gewählt wird, könnte dieses
Bit Zuverlässigkeitsinformationen
transportieren und könnte
auf die folgende Art und Weise auf eine GPRS-Zuverlässigkeitsklasse abgebildet
werden: ein Wert 0 in Bit 5 innerhalb des ToS-Oktetts wird auf die
Zuverlässigkeitsklasse
000 (abonnierte Zuverlässigkeitsklasse)
abgebildet und ein Wert 1 wird auf die Zuverlässigkeitsklasse 001 (die den
zuverlässigsten
Dienst definiert) abgebildet. Die Verwendung dieses Bits kann jedoch
zu undeutlich sein, weil GPRS auch viele andere Zuverlässigkeitsniveaus
definiert und dies nicht unter Verwendung von nur einem Bit ausgedrückt werden
kann.
-
Die
vorstehend in Beispiel 2 beschriebene Abbildung kann auf ziemlich ähnliche
Art und Weise bei IPv6 angewandt werden. Der Name des entsprechenden
Felds ist dann Verkehrsklasse statt ToS.
-
4 veranschaulicht
den Betrieb von einer GPRS-Mobilstation
und GPRS-Netzwerkelementen ebenso wie eine Verflechtung mit QoS-Konzepten
eines externen Netzwerks, wenn das erfinderische Mehrfach-QoS-Konzept
und eine Profilkennzeichnung eingesetzt wird. Die MS, oder genauer
gesagt die Software in der Endgerätevorrichtung TE (z.B. in einem
Laptop-Computer), und der GGSN stellen eine Abbildung von QoS-Anforderungen
des externen Netzwerks auf GPRS-QoS-Mechanismen und umgekehrt bereit,
wie es bei den vorstehenden Beispielen beschrieben wird. Die TE
könnte
zum Beispiel QoS-Funktionen über
eine Anwendungsprogrammschnittstelle (API: "Application Programming Interface") bereitstellen.
Die Software auf Anwendungsebene kann die QoS-Informationen oder
eine Profilkennzeichnung in die Datenpakete einfügen, z.B. in den IP-Nachrichtenkopf
selbst, oder sie kann unter Verwendung beliebiger anderer geeigneter
Mittel den korrekten Fluss bezeichnen, zu dem das Paket gehört. Sie
kann auch das RSVP verwenden, um die notwendigen Informationen über geeignete
Abbildungsschichten auf niedrigere Schichten zu überführen. Führt sie keine dieser Funktionen
durch, sollte die GPRS-spezifische Software die Datenpakete basierend
auf verfügbaren
Informationen mit einer Profilkennzeichnung ausstatten, die Prioritäts- und
Verkehrstypinformationen bezeichnet. Die Software kann das QoS-Profil
zum Beispiel basierend auf den verwendeten Quellen- und Ziel-IP-Adressen
oder auf den Quellen- und Ziel-Portnummern bestimmen.
-
Für vom Mobilgerät abgehende
(MO) Daten plant die MS Datenpakete basierend auf den Qos-Informationen
(z.B. einer Profilkennzeichnung) zeitlich ein, die von der Anwendung
oder von der GPRS-Protokollfolge bzw. -suite in der Endgerätevorrichtung
empfangen werden. Die MS plant die ankommenden MO-Pakete gemäß ihrer
Verzögerungsklasse
zeitlich ein. Auf der SNDC-Schicht wählt die MS den geeigneten LLC-SAP ("Service Access Point": Dienstzugangspunkt),
wie er während
einer PDP-Kontextaktivierung
oder -änderung durch
den SGSN bezeichnet wird.
-
5 zeigt
einen Kontextaktivierungsvorgang. In Schritt 5-1 sendet die MS eine "Aktiviere PDP-Kontext
Anfrage" (die einen
NSAPI, einen PDP-Typ, eine PDP-Adresse, einen Zugangspunktnamen,
die angeforderten QoS-Profile und eine assoziierte Profilkennzeichnung
PrT, einen Zusammenarbeitsparameter und seine assoziierte PrT und
PDP-Konfigurationsoptionen aufweist) an den SGSN. Sicherheitsfunktionen
können
in Schritt 5-2 durchgeführt
werden, aber sie sind zum Verständnis
der Erfindung nicht relevant. In Schritt 5-3 validiert der SGSN
die Anfrage 5-1. Der SGSN erzeugt einen Tunnelbezeichner TID für den angeforderten PDP-Kontext.
Der SGSN kann die angeforderten QoS-Attribute in Anbetracht seiner
Fähigkeiten,
der momentanen Last und dem abonnierten QoS-Profil beschränken. Als Nächstes sendet der SGSN in Schritt
5-3 eine "Erzeuge
PDP-Kontext Anfrage" (die
einen PDP-Typ, eine PDP-Adresse, einen Zugangspunktnamen, die ausgehandelten
QoS-Profile und eine assoziierte PrT, einen Zusammenarbeitsparameter
und seine assoziierte PrT, den TID und PDP-Konfigurationsoptionen
aufweist) an den GGSN. Der GGSN kann die angeforderten QoS-Attribute
ebenfalls in Anbetracht seiner Fähigkeiten
und der momentanen Last beschränken.
In Schritt 5-4 gibt der GGSN eine "Erzeuge PDP-Kontext Antwort" zurück (die
einen TID, eine PDP-Adresse, die ausgehandelten QoS-Profile mit
Profilkennzeichnungen PrT und PDP-Konfigurationsoptionen aufweist)
an den SGSN. Der SGSN fügt
den NSAPI mit der GGSN-Adresse in den PDP-Kontext ein. Als Nächstes wählt der SGSN
in Schritt 5-5 basierend auf jedem ausgehandelten QoS-Profil ein
Funkprioritätsniveau
aus und gibt eine "Aktiviere
PDP-Kontext Annahme" zurück (die
einen PDP-Typ, eine PDP-Adresse, einen NSAPI, die ausgehandelten
QoS-Profile mit zugehörigen
Profilkennzeichnungen PRT, ein Funkprioritätsniveau und einen SAPI für jedes
QoS-Profil, einen Zusammenarbeitsparameter und seine zugehörige PrT,
sowie PDP-Konfigurationsoptionen aufweist) an die MS. Nun ist der
SGSN zum Leiten bzw. Routen von PDP-PDUs zwischen dem GGSN und der
MS fähig.
Der SAPI gibt an, welches QoS-Profil
welchen SAPI verwendet.
-
6 zeigt
einen Kontextänderungsvorgang.
In Schritt 6-1 sendet
der SGSN eine "Aktualisiere PDP-Kontext
Anfrage" (die den
TID, die ausgehandelten QoS-Profile und eine zugehörige PrT,
einen Zusammenarbeitsparameter und seine assoziierte PrT aufweist)
an den GGSN. Diese Nachricht wird verwendet, um ein QoS-Profil eines
PDP-Kontexts hinzuzufügen,
zu ändern
bzw. zu modifizieren oder zu löschen.
Empfängt der
GGSN vom SGSN eine ausgehandelte QoS, die mit dem geänderten
PDP-Kontext nicht kompatibel ist (z.B. ist die Zuverlässigkeitsklasse
nicht ausreichend, um den PDP-Typ zu unterstützen), weist der GGSN die Anfrage
zurück.
Kompatible QoS-Profile werden durch den GGSN-Betreiber konfiguriert.
Der GGSN kann die angeforderten QoS-Attribute wiederum in Anbetracht
seiner Fähigkeiten
und der momentanen Last beschränken.
Der GGSN speichert die ausgehandelten QoS-Werte und gibt in Schritt
6-2 eine "Aktualisiere
PDP-Kontext Antwort" zurück (die
den TID, die ausgehandelten QoS-Profile und eine assoziierte PrT,
einen Zusammenarbeitsparameter und seine assoziierte PrT aufweist)
an den SGSN. Als Nächstes
sendet der SGSN in Schritt 6-3 eine "Ändern
PDP-Kontext Anfrage" (die
einen NSAPI, die ausgehandelten QoS-Profile mit assoziierten Profilkennzeichnungen
PrT, ein Funkprioritätsniveau
und einen SAPI für
jedes QoS-Profil, einen Zusammenarbeitsparameter und seine assoziierte
PrT aufweist) an die MS. In Schritt 6-4 bestätigt die MS dies durch Zurückgeben
einer Nachricht "Ändern PDP-Kontext
Annahme". Akzeptiert
die MS die ausgehandelten QoS-Profile
nicht, kann sie den (die) entsprechenden PDP-Kontext(e) unter Verwendung eines PDP-Kontextdeaktivierungsvorgangs
deaktivieren.
-
Die
Wahl, ob auf der LLC/RLC-Schicht eine Neuübertragung oder Prüfsummen
verwendet werden, hängt
von der Zuverlässigkeitsklasse
des entsprechenden Profils ab. Die Zuverlässigkeitsklasse definiert entweder
einen bestätigten
oder einen unbestätigten
Dienst von LLC, RLC und GTP. Eine Zeitplanung (Scheduling) in den
niedrigeren Schichten wird gemäß der Verzögerungsklasse
des entsprechenden Profils durchgeführt.
-
Die
MS kann ebenfalls eine Regelzuweisung (Policing) der ausgehandelten
PDP-Kontext-Attribute des QoS-Profils durchführen. Sie kann nicht konforme
Pakete fallen lassen (oder den Dienstvorrang (d.h. die Priorität) dieser
Pakete auf den schlechtest möglichen ändern, d.h.
um "Best-Effort" zu bezeichnen).
Nicht nur die MS, sondern auch ein SGSN kann wahlweise eine Verkehrregelzuweisung
gemäß dem ausgehandelten QoS-Profil
oder den PDP-Kontext-Niveauattributen
durchführen.
Netzwerkknoten können
die Durchsatzniveaus und die verwendeten Verzögerungsklassen, Zuverlässigkeitsklassen
und Dienstvorrangwerte regeln. Für
den PDP-Kontext ausgehandelte Werte können als zulässige Maximalwerte
oder als Vorgabewerte für
die Profile interpretiert werden. PDP-Kontext- oder Profilabhängige QoS-Attribute
bilden die Basis für
Gebührenerfassung
bzw. Abrechnung. Zum Abrechnen des Teilnehmers könnte zum Beispiel mit jedem
verwendeten Profil ein anderer Zähler
assoziiert sein.
-
Die
LLC stellt eine Verbindung über
einen SAPI her, wenn ein neues QoS-Profil aktiviert wird, das einen
neuen SAPI benötigt.
Dies kann bei einer PDP-Kontextaktivierung oder -änderung
(z.B. einer Erzeugung eines neuen QoS-Profils) passieren. Sind alle
den SAPI verwendenden (QoS-Profil-) Flüsse freigegeben, wird auch
die LLC-Verbindung über
diesen SAPI freigegeben bzw. gelöst.
Zwischen der MS und dem SGSN können unterschiedliche
QoS-Profile eingesetzt werden. Zum Beispiel könnte der gleiche SAPI verwendet
werden, falls der mittlere Durchsatz unterschiedlich ist, aber nicht,
falls die Verzögerungsklasse
unterschiedlich ist. Dann muss die LLC/SNDCP-Schicht mehrere NSAPIs
eines Teilnehmers auf mehrere SAPIs in der MS oder im SGSN multiplexen.
Die LLC/SNDCP-Schicht in einem SGSN entscheidet basierend auf dem
QoS-Profil, welchen SAPI sie verwenden wird, um die Pakete in einem
bestimmten Fluss zu übermitteln.
Die SNDCP-Schicht fügt
die entsprechende Profilkennzeichnung zu den Datenpaketen hinzu.
Sie kann eine Segmentierung von SN-PDUs wie üblich vornehmen. Dann übergibt
die SNDC-Schicht das Paket unter Verwendung des geeigneten SAPI
an die LLC-Schicht. Die LLC-Schicht überträgt das Paket wie üblich über die LLC/Funk-Verbindung.
Am anderen Ende empfängt
die SNDC-Schicht
Pakete von den unterschiedlichen LLEs und assoziiert sie mit den
korrekten NSAPIs und basierend auf den Profilkennzeichnungen weiter
mit den entsprechenden Profilen. Eine Beibehaltung der Reihenfolge
der Pakete, die unterschiedliche QoS-Werte/Profile verwenden, ist
nicht wesentlich, weil eine andere QoS verwendende Pakete entweder
zu anderen Anwendungsschicht-Verbindungen gehören oder gemäß ihren
QoS-Werten neu geordnet werden, was von vornherein der Zweck ist,
QoS-Werte zu haben.
-
Der
SGSN liest die QoS-Informationen, d.h. den Dienstvorrang, die Verzögerungsklasse,
die mittlere und die Spitzenbitrate und die Zuverlässigkeitsklasse
des mit dem Aufwärtsstrecken-SNDCP-Paket
assoziierten Profils und plant die Pakete basierend auf diesem QoS-Profil
zeitlich ein. Es kann für
jede zugewiesene Verzögerungsklasse
unterschiedliche Puffer bzw. Zwischenspeicher geben. Je niedriger
die Verzögerungsklasse
ist, desto kleiner sollte die Größe eines
Puffers sein, der für
eine Warteschlangenbildung der betroffenen Paketklasse zugewiesen
wird. Dies beruht darauf, dass einige Pakete verzögerungsempfindlich
sind und daher keine langen Warteschlangenverzögerungen bewältigen können. Niedrigere
Verzögerungsklassen
werden normalerweise vor allen Paketen jeder höheren Verzögerungsklasse gesendet. Jeder
Puffer, d.h. eine Warteschlange, kann einen Schwellenwert definiert
haben. Wird dieser Schwellenwert überschritten, können die
ankommenden Pakete (der betroffenen Klasse) mit einem niedrigen
Dienstvorrangwert verworfen werden. Ein SGSN kann sowohl zuverlässige als
auch unzuverlässige
Pfade zu GGSNs beibehalten. Diese Pfade können für einen bestimmten Teilnehmer/ein
bestimmtes Profil dediziert sein, oder es können wahlweise mehrere Teilnehmer
und Profile auf die gleichen Pfade gemultiplext werden. Der richtige
Pfad zum Liefern jedes Datenpakets wird basierend auf den im Profil
enthaltenen Zuverlässigkeitsklasseninformationen
oder, falls im entsprechenden Profil nicht genügend Informationen zum Treffen
einer Entscheidung vorhanden sind, basierend auf Vorgabewerten ausgewählt werden.
Für Zuverlässigkeitsklasse
1 wird ein zuverlässiger verbindungsorientierter
Pfad ausgewählt,
und für
andere Zuverlässigkeitsklassen
ein verbindungsloser Pfad. Der SGSN fügt an GTP-Nachrichtenköpfe eine
Profilkennzeichnung an. Diese Information kann im 10-ten, 19-ten
oder 20-ten Oktett des Nachrichtenkopfs (die momentan zur zukünftigen
Verwendung reserviert sind) eingefügt werden.
-
Der
GGSN stellt die Profilkennzeichnung aus dem Aufwärtsstrecken-GTP-Nachrichtenkopf
wieder her. Er kann auch eine Verkehrsregelzuweisung durchführen. Der
GGSN kann Gebührenerfassungs-
bzw. Abrechnungsfunktionen durchführen und er kann auch die QoS-Informationen
in Bezug auf das Profil zu diesem Zweck einsetzen. Der GGSN, oder
ein externen Host, kann eine Abbildung zwischen den QoS-Definitionen eines
externen Datennetzwerks und der GPRS-QoS und umgekehrt bereitstellen.
Dies gilt sowohl für
Aufwärtsstrecken-
als auch für
Abwärtsstrecken-Datenlieferung.
-
Der
gleiche Vorgang gilt für
am Mobilgerät
abschließende
(MT) Datenpakete, wobei nur die Übertragungsrichtung
umgekehrt ist. In diesem Fall wählt
der GGSN das geeignete QoS-Profil und den GTP-Pfad aus. Der SGSN
schaut in den Abwärtsstrecken-GTP-Nachrichtenkopf
hinein, um die Profilkennzeichnung zu finden, und er leitet die
QoS-Informationen aus seinem lokalen Profildatensatz her. Der SGSN
fügt auch
die Profilkennzeichnung zu Abwärtsstrecken-SNDCP-Paketen
hinzu, führt
die Zeitplanung basierend auf der Verzögerungsklasse des Flusses/Profils
durch und verwendet den korrekten LLC- SAPI, der mit dem Profil assoziiert ist.
Das Mobilendgerät
kann den IP-Nachrichtenkopf der Anwendung ändern, um die Endgerätevorrichtung (TE) über die
QoS des Abwärtsstrecken-Datenpakets
zu informieren. Wahlweise kann die MS einige GPRS- oder PPP-spezifische
Mechanismen zum Liefern der gleichen Informationen an die TE verwenden.
Zeitplanungs- und Regelzuweisungsoperationen innerhalb der Netzwerkelemente
sind in beiden Richtungen grundsätzlich
die gleichen.
-
Wie
vorstehend erwähnt ändert der
GGSN, oder ein externer Host, für
Aufwärtsstreckendaten
die GPRS-QoS-Informationen
in die QoS-Konzepte, die im externen Paketdatennetzwerk verfügbar sind.
Gleichermaßen
sollte der GGSN, oder ein externer Host, für Abwärtsstreckendaten die QoS des
externen Netzwerks in jedem Paket in die GPRS-QoS-Definitionen umsetzen.
Der GGSN, oder ein externer Host, kann wahlweise Informationen über unterschiedliche
Anwendungsverbindungen und Verkehrsflüsse beibehalten, aber dies
ist nicht erforderlich. Die Flussinformationen können zum Beispiel über eine
RSVP-Signalisierung im Netzwerk erhalten werden. Der GGSN, oder
ein externer Host, kann selbst auf externe RSVP-Nachrichten Antworten,
oder er kann die RSVP-Nachrichten auch an die MS weitergeben, die
bei der RSVP-Signalisierung teilnehmen kann. Die in RSVP-Antwortnachrichten
bezeichnete Kapazität
sollte mit der Kapazität
im Einklang stehen, die für
das entsprechende QoS-Profil im GPRS-Netzwerk reserviert ist.
-
Wie
bei den vorstehenden Beispielen beschrieben wurde, können Differenzierte
Dienste im Internet, wie etwa der SIMA-Ansatz, relativ einfach auf
diese neuen GPRS-QoS-Konzepte
abgebildet werden. Für
Differenzierte Dienste kann ein separates QoS-Profil für jeden
Verkehrstyp (d.h. Attributkombinationen, pro-Hop-Verhalten) eingerichtet
werden, der einen bestimmten Dienst vom Netzwerk benötigt. Die
Integrierten Dienste werden üblicherweise
mit Verkehrsflüssen
assoziiert, die auf unterschiedliche QoS-Profil innerhalb GPRS abgebildet
werden können.
Der Garantierte Dienst kann daher mit Hilfe von RSVP folgendermaßen definiert
werden: der GGSN, oder ein externer Host, und die MS auf der anderen
Seite können
die Abbildung zwischen QoS-Profilen und externen Verkehrsflüssen ebenso
wie die Abbildung von QoS-Parametern
bereitstellen. Während
der RSVP-Aushandlung kann das GPRS-System angeben, dass es verschiedene
Tokenblockgrößen oder
maximale Paketgrößen nicht
unterstützen
kann. Daher kann es fordern, dass diese Parameter eingestellt werden,
um mit den unterstützten
Werten im Einklang zu stehen, bevor es die RSVP-Reservierungen akzeptieren wird. Die
MS, der SGSN, der GGSN oder ein externer Host können auch die freie Kapazität im Netzwerk
wissen und basierend auf diesen Informationen eine Entscheidung über die
Annahme jeder Reservierungsanfrage treffen.
-
Auch
ATM (Asynchroner Transfermodus) oder X.25 können als externes Datennetzwerk
oder als Übertragungsmedium
zum Transportieren der GPRS-Signalisierung und des Datenverkehrs
verwendet werden. Der Konstantbitraten- (CBR) und der Realzeit-Variablenbitraten-
(r-VBR) Verkehr von ATM können
auf eine Realzeit-Verkehrsklasse abgebildet werden, und die anderen
ATM-Verkehrsklassen auf Nichtrealzeit-Verkehr. Eine Priorität kann basieren
sowohl auf der verwendeten Verkehrsklasse (Nichtrealzeit-Variablenbitrate, Alternativbitrate
oder Unspezifizierte Bitrate) als auch auf anderen verbindungsbezogenen
Parametern wie etwa mittlerer und maximaler Bitrate bestimmt werden.
-
Als
zugrunde liegendes Übertragungsnetzwerk
im GPRS-Backbone
bzw. -Basisnetzwerk werden IP-Netzwerke verwendet. Die GPRS-QoS-Konzepte
können
auf den Diensttyp-Parameter bei IPv4 oder auf das Priorität/Verkehrklassen-Feld
bei IPv6 abgebildet werden, und umgekehrt. Die Flüsse bei
IPv6 können auch
zum Reservieren einer bestimmten Kapazität und zum Bearbeiten bestimmter
Verkehrstypen, Anwendungsverbindungen oder PDP-Kontexte verwendet
werden. Setzt auch das externe Internet-Netzwerk diese Verfahren
ein, kann der GGSN, oder ein externer Host, eine Abbildung von Konzepten
gleichermaßen
zwischen dem GPRS-Netzwerk und dem Internet durchführen.
-
Die
Erfindung ist in jedem Mobilkommunikationsnetzwerk anwendbar, und
zwar im Wesentlichen wie es vorstehend mit Bezug auf GPRS beschrieben
wird. Mögliche
Mobilnetzwerke, in denen die Prinzipien der Erfindung angewandt
werden können,
sind die Mobilkommunikationssysteme der Dritten Generation, wie
etwa das Universal-Mobilkommunikationssystem
(UMTS) und das zukünftige öffentliche
Mobiltelekommunikationssystem (FPLMTS) oder IMT-2000 oder "Cellular Digital
Packet Data" (CDPD).
-
Die
Beschreibung veranschaulicht nur bevorzugte Ausführungsbeispiele der Erfindung.
Die Erfindung ist jedoch nicht auf diese Beispiele beschränkt, sondern
sie kann innerhalb des Umfangs der zugehörigen Ansprüche variieren.