DE69921831T2 - Kontrolle der dienstqualitäten in einem mobilkommunikationssystem - Google Patents

Kontrolle der dienstqualitäten in einem mobilkommunikationssystem Download PDF

Info

Publication number
DE69921831T2
DE69921831T2 DE69921831T DE69921831T DE69921831T2 DE 69921831 T2 DE69921831 T2 DE 69921831T2 DE 69921831 T DE69921831 T DE 69921831T DE 69921831 T DE69921831 T DE 69921831T DE 69921831 T2 DE69921831 T2 DE 69921831T2
Authority
DE
Germany
Prior art keywords
profile
qos
data
gprs
data packets
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE69921831T
Other languages
English (en)
Other versions
DE69921831D1 (de
Inventor
Serge Haumont
Mikko Puuskari
Tuomas NIEMELÄ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Oyj
Original Assignee
Nokia Oyj
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Oyj filed Critical Nokia Oyj
Application granted granted Critical
Publication of DE69921831D1 publication Critical patent/DE69921831D1/de
Publication of DE69921831T2 publication Critical patent/DE69921831T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/302—Route determination based on requested QoS
    • H04L45/308—Route determination based on user's profile, e.g. premium users
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/15—Setup of multiple wireless link connections
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/12—Wireless traffic scheduling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/50—Allocation or scheduling criteria for wireless resources
    • H04W72/56—Allocation or scheduling criteria for wireless resources based on priority criteria
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/50—Allocation or scheduling criteria for wireless resources
    • H04W72/56—Allocation or scheduling criteria for wireless resources based on priority criteria
    • H04W72/563—Allocation or scheduling criteria for wireless resources based on priority criteria of the wireless resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/12—Setup of transport tunnels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/16—Interfaces between hierarchically similar devices
    • H04W92/24—Interfaces between hierarchically similar devices between backbone network devices

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Radio Transmission System (AREA)
  • Channel Selection Circuits, Automatic Tuning Circuits (AREA)

Description

  • 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.
  • Figure 00420001
  • 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:
    Figure 00440001
  • 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.

Claims (18)

  1. Verfahren zur Übertragung von Datenpaketen (DP) in mehreren Datenflüssen zu/von einer Mobilstation (MS) in einem Mobilkommunikationssystem (HPLMN, VPLMN) mit einer Paketdatenübertragungsfähigkeit, wobei das Verfahren die Schritte aufweist: Aufbau eines Datenübertragungspfads für die Mobilstation (MS) zur Leitweglenkung von Datenpaketen (DP) durch das Mobilkommunikationssystem (HPLMN, VPLMN); Übertragung von Datenpaketen (DP) durch das Mobilkommunikationssystem (HPLMN) zwischen der Mobilstation (MS) und einem externen Kommunikationssystem (11, 12, VPLMN, HPLMN); Assoziierung von zumindest einem Profil (Pr) mit dem Datenübertragungspfad, wobei das zumindest eine Profil zumindest einen Dienstgüteparameter oder QoS-Parameter aufweist; Zeitplanung (Scheduling) und Regelzuweisung (Policing) der Übertragung der Datenpakete (DP) innerhalb zumindest eines QoS-Parameters, der durch das Profil (Pr) bezeichnet wird; gekennzeichnet durch die weiteren Schritte: Assoziierung von mehreren Profilen (Pr) mit dem Übertragungspfad, wobei jedes Profil (Pr) zumindest einen QoS-Parameter aufweist; Ausstattung von jedem der mehreren Flüsse mit einer Profilkennzeichnung (PrT), die eines der mehreren Profile (Pr) bezeichnet, die mit dem fraglichen Übertragungspfad assoziiert sind; und Zeitplanung (Scheduling) und Regelzuweisung (Policing) der Übertragung einzelner Datenpakete (DP) auf Grundlage des zumindest einen QoS-Parameters des Profils (Pr), das durch die Profilkennzeichnung (PrT) bezeichnet wird, die mit dem fraglichen Datenfluss assoziiert ist.
  2. Verfahren gemäß Anspruch 1, gekennzeichnet durch die Schritte: Ausführung von zumindest zwei Anwendungen in der Mobilstation (MS), wobei jede Anwendung zu einer Klasse/Art gehört und zumindest einen mit ihr assoziierten Fluss aufweist; Übertragung von Datenpaketen (DP) der zumindest zwei Anwendungen innerhalb eines einzigen Übertragungspfads; und Ausstattung von jedem Fluss jeder Anwendungsklasse/-art mit einer Profilkennzeichnung (PrT), die den QoS-Parameter bezeichnet, der von der Anweddungsklasse/-art benötigt wird.
  3. Verfahren gemäß Anspruch 2, gekennzeichnet durch eine Ausstattung von jedem Fluss jeder einzelnen Anwendung mit einer Profilkennzeichnung (PrT).
  4. Verfahren gemäß einem der vorhergehenden Ansprüche, gekennzeichnet durch eine Ausstattung von jedem einzelnen Datenpaket (DP) mit einer Profilkennzeichnung (PrT).
  5. Verfahren gemäß einem der vorhergehenden Ansprüche, gekennzeichnet durch eine Ausstattung von jedem Profil (Pr) mit Prioritätsinformationen, die eines von zumindest zwei Prioritätsniveaus bezeichnen, als QoS-Parameter.
  6. Verfahren gemäß einem der vorhergehenden Ansprüche, gekennzeichnet durch die Schritte: Ausstattung von zumindest einem Verbindungsabschnitt im Mobilkommunikationssystem mit zumindest zwei Pfaden mit unterschiedlichen Zuverlässigkeiten; Ausstattung von jedem Profil (Pr) mit Zuverlässigkeitsinformationen, die eine von zumindest zwei Zuverlässigkeitsklassen bezeichnen, als ein QoS-Parameter; und Multiplex der Datenpakete (DP) gemäß den Zuverlässigkeitsinformationen auf die zumindest zwei Pfade.
  7. Verfahren gemäß einem der vorhergehenden Ansprüche, gekennzeichnet durch die Schritte Bildung von zumindest einem Verbindungsabschnitt im Mobilkommunikationssystem mit einem verbindungsorientierten Pfad und einem verbindungslosen Pfad, wobei der erstere zuverlässiger ist als der letztere; Entscheidung auf Grundlage der Zuverlässigkeitsinformationen, ob ein Datenpaket (DP) über den verbindungsorientierten Pfad oder den verbindungslosen Pfad gesendet wird.
  8. Verfahren gemäß Anspruch 7, gekennzeichnet durch Multiplex von mit zwei oder mehr Profilen (Pr) assoziierten Datenpaketen (DP) auf verbindungsorientierte und verbindungslose Pfade in dem zumindest einen Verbindungsabschnitt.
  9. Verfahren gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass zumindest eines der Profile (Pr) zumindest einen weiteren QoS-Parameter aufweist, der eine weitere Beschränkung für die Zeitplanung und Regelzuweisung bezeichnet.
  10. Verfahren gemäß Anspruch 9, dadurch gekennzeichnet, dass der zumindest eine weitere QoS-Parameter eine Durchschnittsbitrate und/oder eine Spitzenbitrate und/oder einen Dienstvorrang und/oder eine Verzögerungsklasse und/oder eine Zuverlässigkeit umfasst.
  11. Verfahren gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der zumindest eine weitere QoS-Parameter eine Durchschnittsbitrate definiert; die tatsächliche, von der Mobilstation (MS) verwendete Durchschnittsbitrate überwacht wird; und Datenpakete (DP) zu/von der Mobilstation (MS) verworfen werden oder zumindest ihr Vorrang herabgesetzt wird, falls die tatsächliche Durchschnittsbitrate die durch den zumindest einen weiteren QoS-Parameter definierte Durchschnittsbitrate übersteigt.
  12. Verfahren gemäß einem der vorhergehenden Ansprüche, gekennzeichnet durch eine Abbildung von im Mobilkommunikationssystem (HPLMN, VPLMN) verwendeten QoS-Parametern auf diejenigen, die bei einer Teilnehmeranwendung in der Mobilstation (MS) verwendet werden, oder auf diejenigen, die im externen Kommunikationssystem (11, 12, VPLMN) verwendet werden, und umgekehrt.
  13. Verfahren gemäß einem der Ansprüche 2 bis 12, gekennzeichnet durch die Schritte: Einrichtung eines Vorgabeprofils (Pro), das mit dem Übertragungspfad assoziiert ist, und eines spezifischen Profils (Pr) für jede Anwendung oder Anwendungsklasse/-art, die in der Mobilstation ausgeführt wird; und Auslesung eines QoS-Parameters aus dem Vorgabeprofil (Pro), falls der entsprechende QoS-Parameter beim fraglichen spezifischen Profil fehlt.
  14. Verfahren gemäß einem der vorhergehenden Ansprüche, gekennzeichnet durch eine Assoziierung eines an sich bekannten Paketdatenprotokollkontexts mit dem Übertragungspfad.
  15. Verfahren gemäß Anspruch 13, gekennzeichnet durch eine Assoziierung der mehreren Profile (Pr) mit dem Paketdatenprotokollkontext.
  16. Vorrichtung (MS, GGSN) zur Übertragung von Datenpaketen (DP) in mehreren Datenflüssen in einem Mobilkommunikationssystem (HPLMN, VPLMN) mit einer Paketdatenübertragungsfähigkeit, wobei die Vorrichtung aufweist: eine Einrichtung, die zum Aufbau eines Datenübertragungspfads für die Mobilstation (MS) zur Leitweglenkung von Datenpaketen (DP) durch das Mobilkommunikationssystem (HPLMN, VPLMN) eingerichtet ist; eine Einrichtung, die zur Übertragung von Datenpaketen (DP) durch das Mobilkommunikationssystem (HPLMN) zwischen der Mobilstation (MS) und einem externen Kommunikationssystem (11, 12, VPLMN, HPLMN) eingerichtet ist; eine Einrichtung, die zur Assoziierung von zumindest einem Profil (Pr) mit dem Datenübertragungspfad eingerichtet ist, wobei das zumindest eine Profil zumindest einen Dienstgüteparameter oder QoS-Parameter aufweist; eine Einrichtung, die zur Zeitplanung (Scheduling) und Regelzuweisung (Policing) der Übertragung der Datenpakete (DP) innerhalb zumindest eines QoS-Parameters eingerichtet ist, der durch das Profil (Pr) bezeichnet wird; dadurch gekennzeichnet, dass die Assoziierungseinrichtung zur Assoziierung von mehreren Profilen (Pr) mit dem Übertragungspfad eingerichtet ist, wobei jedes Profil (Pr) zumindest einen QoS-Parameter aufweist; die Vorrichtung zusätzlich eine Einrichtung aufweist, die zur Ausstattung von jedem der mehreren Flüsse mit einer Profilkennzeichnung (PrT) eingerichtet ist, die eines der mehreren Profile (Pr) bezeichnet, die mit dem fraglichen Übertragungspfad assoziiert sind; und die Zeitplanungs- und Regelzuweisungseinrichtung zur Zeitplanung (Scheduling) und Regelzuweisung (Policing) der Übertragung einzelner Datenpakete (DP) auf Grundlage des zumindest einen QoS-Parameters des Profile (Pr) eingerichtet ist, das durch die Profilkennzeichnung (PrT) bezeichnet wird, die mit dem fraglichen Datenfluss assoziiert ist.
  17. Vorrichtung gemäß Anspruch 16, dadurch gekennzeichnet, dass die Vorrichtung eine mobile Funkstation (MS) ist oder aufweist.
  18. Vorrichtung gemäß Anspruch 16, dadurch gekennzeichnet, dass die Vorrichtung ein Unterstützungsknoten (SGSN, GGSN) eines Paketdatennetzwerks (HPLMN, VPLMN) ist.
DE69921831T 1998-08-10 1999-08-09 Kontrolle der dienstqualitäten in einem mobilkommunikationssystem Expired - Lifetime DE69921831T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FI981722A FI105969B (fi) 1998-08-10 1998-08-10 Palvelunlaadun hallinta matkaviestinjärjestelmässä
FI981722 1998-08-10
PCT/FI1999/000661 WO2000010357A1 (en) 1998-08-10 1999-08-09 Controlling quality of service in a mobile communications system

Publications (2)

Publication Number Publication Date
DE69921831D1 DE69921831D1 (de) 2004-12-16
DE69921831T2 true DE69921831T2 (de) 2005-10-27

Family

ID=8552281

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69921831T Expired - Lifetime DE69921831T2 (de) 1998-08-10 1999-08-09 Kontrolle der dienstqualitäten in einem mobilkommunikationssystem

Country Status (12)

Country Link
US (1) US7023825B1 (de)
EP (1) EP1104639B1 (de)
JP (1) JP3574788B2 (de)
CN (2) CN100373985C (de)
AT (1) ATE282283T1 (de)
AU (1) AU5291899A (de)
BR (1) BR9912911B1 (de)
CA (1) CA2339825C (de)
DE (1) DE69921831T2 (de)
ES (1) ES2232159T3 (de)
FI (1) FI105969B (de)
WO (1) WO2000010357A1 (de)

Families Citing this family (157)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI105969B (fi) * 1998-08-10 2000-10-31 Nokia Networks Oy Palvelunlaadun hallinta matkaviestinjärjestelmässä
FI106503B (fi) * 1998-09-21 2001-02-15 Nokia Networks Oy IP-liikkuvuusmekanismi pakettiradioverkkoa varten
FI107772B (fi) 1998-12-16 2001-09-28 Nokia Networks Oy Menetelmä ja järjestelmä tiedonsiirron palvelunlaadun rajoittamiseksi
US6490290B1 (en) * 1998-12-30 2002-12-03 Cisco Technology, Inc. Default internet traffic and transparent passthrough
CN1155203C (zh) * 1999-05-21 2004-06-23 诺基亚有限公司 第三代移动***中的分组数据传输
FI109072B (fi) 1999-06-16 2002-05-15 Nokia Corp Menetelmä ja järjestely kanavakoodaus- ja lomitusmenettelyn valitsemiseksi eräissä pakettidatayhteyksissä
MY125299A (en) * 1999-09-15 2006-07-31 Ericsson Inc Methods and systems for specifying a quality of service for communication between a mobile station and a packet wireless communications network based upon an application that is executing on the mobile station.
US6526034B1 (en) 1999-09-21 2003-02-25 Tantivy Communications, Inc. Dual mode subscriber unit for short range, high rate and long range, lower rate data communications
KR100694026B1 (ko) 1999-11-01 2007-03-12 삼성전자주식회사 광대역 무선 전송방법 및 장치
FI108593B (fi) 1999-12-31 2002-02-15 Nokia Oyj Paketinreititys monipalveluverkossa
WO2001052481A1 (fr) * 2000-01-11 2001-07-19 Fujitsu Limited Procede de traitement des appels dans un noeud de communication
US7079508B2 (en) 2000-02-23 2006-07-18 Microsoft Corporation Quality of service over paths having a wireless-link
AU2001240659A1 (en) * 2000-02-29 2001-09-12 Telefonaktiebolaget Lm Ericsson (Publ) Quality or service profile negotiation in a data packet communications system
EP1130931A1 (de) * 2000-03-03 2001-09-05 Lucent Technologies Inc. Reservierung von Netzresourcen in einem mobilen Paketdatennetz
GB0005363D0 (en) * 2000-03-06 2000-04-26 Nokia Networks Oy Interworking in a communication system
EP1133118A3 (de) * 2000-03-10 2002-02-06 Alcatel IP-/Dataverkehrzuordungsmethode um QoS beizubehalten
GB0006230D0 (en) * 2000-03-16 2000-05-03 Univ Strathclyde Mobile communications newworks
US8295269B1 (en) * 2000-04-10 2012-10-23 Nokia Corporation Technique for informing network of voice traffic
US7385917B1 (en) 2000-05-05 2008-06-10 Fujitsu Limited Method and system for providing a protection path for connectionless signals in a telecommunications network
US7133403B1 (en) 2000-05-05 2006-11-07 Fujitsu Limited Transport network and method
US7058730B2 (en) 2000-05-05 2006-06-06 Fujitsu Limited Unique address space and method for a transport network
US7047176B2 (en) 2000-05-05 2006-05-16 Fujitsu Limited Method and system for hardware simulation
US7075927B2 (en) 2000-05-05 2006-07-11 Fujitsu Limited Method and system for quality of service (QoS) support in a packet-switched network
US7173912B2 (en) 2000-05-05 2007-02-06 Fujitsu Limited Method and system for modeling and advertising asymmetric topology of a node in a transport network
US6515966B1 (en) 2000-05-05 2003-02-04 Fujitsu Network Communications, Inc. System and method for application object transport
US6654610B1 (en) 2000-05-05 2003-11-25 Lucent Technologies Inc. Two-way packet data protocol methods and apparatus for a mobile telecommunication system
US6693909B1 (en) 2000-05-05 2004-02-17 Fujitsu Network Communications, Inc. Method and system for transporting traffic in a packet-switched network
US6775229B1 (en) 2000-05-05 2004-08-10 Fujitsu Network Communications, Inc. Method and system for providing a protection path for connection-oriented signals in a telecommunications network
US7151773B1 (en) * 2000-05-05 2006-12-19 Fujitsu Limited System and method for connectionless/connection oriented signal transport
GB0011058D0 (en) * 2000-05-08 2000-06-28 Nokia Networks Oy Data bearers in a communication system
EP1154600A1 (de) 2000-05-09 2001-11-14 Lucent Technologies Inc. Ressourcenreservierung in einem funknetz der dritten oder zukünftigen generation iv
EP1154599A1 (de) * 2000-05-09 2001-11-14 Lucent Technologies Inc. Ressourcenreservierung in einem funknetz der dritten oder zukünftigen generation iii
US7162540B2 (en) 2000-05-15 2007-01-09 Catchfire Systems, Inc. Method and system for prioritizing network services
ATE272301T1 (de) * 2000-05-16 2004-08-15 Siemens Ag Verfahren zum umlegen eines tunnels zwischen knoten eines gprs-systems
JP2001326697A (ja) * 2000-05-17 2001-11-22 Hitachi Ltd 移動体通信網、端末装置、パケット通信制御方法、及び、関門装置
GB0012623D0 (en) * 2000-05-25 2000-07-12 Ericsson Telefon Ab L M Ip address allocation in a mobile telecommunications network
US6879820B2 (en) 2000-07-12 2005-04-12 Telefonaktiebolaget Lm Ericsson (Publ) Charging in communication networks having split control planes and user planes
US7103002B2 (en) 2000-07-12 2006-09-05 Telefonktiebolaget Lm Ericsson (Publ) Communication management in networks having split control planes and user planes
US7061896B2 (en) 2000-09-20 2006-06-13 George Mason Intellectual Properties, Inc. Wireless label switched packet transfer network
US9800608B2 (en) 2000-09-25 2017-10-24 Symantec Corporation Processing data flows with a data flow processor
US20110213869A1 (en) * 2000-09-25 2011-09-01 Yevgeny Korsunsky Processing data flows with a data flow processor
US9525696B2 (en) 2000-09-25 2016-12-20 Blue Coat Systems, Inc. Systems and methods for processing data flows
US20110214157A1 (en) * 2000-09-25 2011-09-01 Yevgeny Korsunsky Securing a network with data flow processing
US20070192863A1 (en) * 2005-07-01 2007-08-16 Harsh Kapoor Systems and methods for processing data flows
US20100042565A1 (en) * 2000-09-25 2010-02-18 Crossbeam Systems, Inc. Mezzazine in-depth data analysis facility
US20110219035A1 (en) * 2000-09-25 2011-09-08 Yevgeny Korsunsky Database security via data flow processing
US20020165947A1 (en) * 2000-09-25 2002-11-07 Crossbeam Systems, Inc. Network application apparatus
US8010469B2 (en) 2000-09-25 2011-08-30 Crossbeam Systems, Inc. Systems and methods for processing data flows
KR100699470B1 (ko) 2000-09-27 2007-03-26 삼성전자주식회사 멀티레이어 패킷 처리 장치
WO2002032082A1 (fr) 2000-10-13 2002-04-18 Sony Corporation Systeme de commande de la vitesse de communication de donnees, appareil emetteur et appareil recepteur
ATE375690T1 (de) * 2000-11-06 2007-10-15 Ericsson Telefon Ab L M Verfahren und gerät für die koordinierte verrechnung von diensten in einem multimedia sitzung
KR100377238B1 (ko) * 2000-12-04 2003-03-26 재단법인 충남대학교 산학연교육연구재단 비동기 이동통신 시스템을 위한 차등화 서비스 적용방법및 그 시스템
US6973054B2 (en) 2001-01-05 2005-12-06 Telefonaktiebolaget Lm Ericsson (Publ) Communication management in mobile networks having split control planes and user planes
GB2371174A (en) * 2001-01-11 2002-07-17 Ericsson Telefon Ab L M Controlling packet data flows in a telecommunications network
US6970423B2 (en) * 2001-01-18 2005-11-29 Lucent Technologies Inc. Universal mobile telecommunications system (UMTS) quality of service (QoS) supporting asymmetric traffic classes
JP4187940B2 (ja) * 2001-03-06 2008-11-26 株式会社エヌ・ティ・ティ・ドコモ パケット伝送方法及びシステム、並びにパケット送信装置、受信装置、及び送受信装置
FI111506B (fi) 2001-03-14 2003-07-31 Nokia Corp Menetelmä palvelun laatutason valitsemiseksi langattomassa tiedonsiirtojärjestelmässä
US20020184510A1 (en) * 2001-04-17 2002-12-05 At&T Wireless Services, Inc. Binding information for IP media flows
US8392586B2 (en) * 2001-05-15 2013-03-05 Hewlett-Packard Development Company, L.P. Method and apparatus to manage transactions at a network storage device
US20030039259A1 (en) * 2001-07-10 2003-02-27 Lila Madour Traffic flow template for managing packet data flows
US20030043773A1 (en) * 2001-08-31 2003-03-06 Hyokang Chang Multilink wireless access scheme for multiband operation in wireless mobile networks
US7248570B2 (en) 2001-09-17 2007-07-24 Microsoft Corporation System and method for coordinating bandwidth usage of a communication channel by wireless network nodes
US7194263B2 (en) 2001-09-17 2007-03-20 Microsoft Corporation System and method for concurrent operation of a wireless device in two disjoint wireless networks
JP4630506B2 (ja) * 2001-09-18 2011-02-09 キヤノン株式会社 通信装置、通信装置の制御方法、プログラム、記憶媒体
FR2830397B1 (fr) * 2001-09-28 2004-12-03 Evolium Sas Procede pour ameliorer les performances d'un protocole de transmission utilisant un temporisateur de retransmission
GB2380900B (en) * 2001-10-10 2003-11-26 Motorola Inc Quality of service
WO2003041334A1 (en) * 2001-11-07 2003-05-15 Cyneta Networks, Inc. Gb PARAMETER BASED RADIO PRIORITY
US7246165B2 (en) * 2001-11-28 2007-07-17 Telefonaktiebolaget Lm Ericsson (Publ) Policy co-ordination in a communications network
US7324448B2 (en) * 2001-11-28 2008-01-29 Samsung Electronics Co., Ltd. Method for classifying service classes of packet data in two way communication network
KR100469747B1 (ko) * 2001-12-06 2005-02-02 삼성전자주식회사 이동통신 시스템에서 서비스 품질에 따른 서비스 제공 및과금 방법
US6661780B2 (en) * 2001-12-07 2003-12-09 Nokia Corporation Mechanisms for policy based UMTS QoS and IP QoS management in mobile IP networks
KR100464447B1 (ko) * 2001-12-11 2005-01-03 삼성전자주식회사 이동통신시스템에서 서비스 품질에 따른 데이터 패킷의 스케줄링 방법 및 장치
US7248582B2 (en) * 2002-02-13 2007-07-24 Sun Microsystems, Inc. Method and system for labeling data in a communications system
US7369489B1 (en) 2002-03-12 2008-05-06 Cisco Technology, Inc. Unbiased token bucket
TW574806B (en) * 2002-04-19 2004-02-01 Ind Tech Res Inst Packet delivery method of packet radio network
US6888807B2 (en) * 2002-06-10 2005-05-03 Ipr Licensing, Inc. Applying session services based on packet flows
US7289480B2 (en) * 2002-06-24 2007-10-30 Telefonaktiebolaget Lm Ericsson (Publ) Applications based radio resource management in a wireless communication network
GB0215013D0 (en) 2002-06-28 2002-08-07 Nokia Corp Communications system and method
JP3989312B2 (ja) * 2002-07-05 2007-10-10 富士通株式会社 キャッシュメモリ装置およびメモリ割付方法
KR100480713B1 (ko) * 2002-07-31 2005-04-06 엘지전자 주식회사 이동통신 시스템의 호 추적 및 감시 방법
AU2002368164A1 (en) * 2002-08-05 2004-02-25 Nokia Corporation A method of speeding up the registration procedure in a cellular network
WO2004028098A1 (ja) * 2002-09-06 2004-04-01 Fujitsu Limited 無線ネットワーク制御装置
US6904058B2 (en) * 2002-09-20 2005-06-07 Intel Corporation Transmitting data over a general packet radio service wireless network
KR100481477B1 (ko) * 2002-11-19 2005-04-07 엘지전자 주식회사 Ｇｐｒｓ이동통신 시스템에서 전송변수 교환 방법
JP4083549B2 (ja) * 2002-11-26 2008-04-30 株式会社エヌ・ティ・ティ・ドコモ 無線アクセスネットワークシステム、無線アクセス方法及び制御装置
US7383048B2 (en) 2002-12-04 2008-06-03 Nokia Corporation Transmission of data packets by a node
DE10326726B4 (de) * 2003-06-10 2007-07-26 Siemens Ag Verfahren zur Datenverkehrsseparierung in einem paketorientiert arbeitenden Mobilfunknetz
EP1645101A1 (de) * 2003-07-03 2006-04-12 Siemens Aktiengesellschaft Verfahren zur steuerung von datenverbindungen
US8139585B1 (en) * 2003-07-10 2012-03-20 Sprint Spectrum L.P. Method and system for controlling sessions from a subscriber terminal
KR100825439B1 (ko) * 2003-08-06 2008-04-25 노키아 코포레이션 모바일 및 ｉｐ네트워크 사이의 인터페이스에서의서비스품질 지원
JP4188774B2 (ja) * 2003-08-14 2008-11-26 株式会社エヌ・ティ・ティ・ドコモ フレーム送受信システム、フレーム送信装置、フレーム受信装置、及びフレーム送受信方法
US8873561B2 (en) * 2003-08-18 2014-10-28 Cisco Technology, Inc. Supporting enhanced media communications using a packet-based communication link
FR2859862A1 (fr) * 2003-09-11 2005-03-18 France Telecom Procede de differenciation de la qualite de service dans les reseaux de communication mobile en mode paquets
FI20031414A (fi) * 2003-09-30 2005-03-31 Nokia Corp Datan siirtäminen langattoman pakettivälitteisen datajärjestelmän matkaviestimessä
DE10355117B4 (de) * 2003-11-24 2005-10-13 Siemens Ag Verfahren und Vorrichtung zur Versendung von Datenpaketen
US7844250B2 (en) * 2003-11-26 2010-11-30 Telefonaktiebolaget Lm Ericsson (Publ) Differentiated charging in packet data networks
GB0329221D0 (en) 2003-12-17 2004-01-21 Nokia Corp Session control in a communication system
GB0329502D0 (en) * 2003-12-19 2004-01-28 Nokia Corp Control decisions in a communication system
JP2007520131A (ja) * 2004-01-28 2007-07-19 フランス テレコム Ｕｔｒａｎ無線アクセスネットワークにおける無線リソース管理方法、コアネットワークサービスノード、および無線アクセスネットワーク制御装置
CN1918937B (zh) * 2004-02-03 2019-05-31 诺基亚技术有限公司 提供端对端服务质量的方法和设备
US7414997B2 (en) * 2004-03-12 2008-08-19 Lucent Technologies Inc. GPRS tunneling protocol path integrity protocol
GB0410624D0 (en) * 2004-05-12 2004-06-16 Nokia Corp Media component control
JP4643638B2 (ja) * 2004-07-05 2011-03-02 テレフオンアクチーボラゲット エル エム エリクソン（パブル） サービス品質を変更する方法および装置
JP4731876B2 (ja) * 2004-07-08 2011-07-27 パナソニック株式会社 通信システム、無線ｌａｎ基地局制御装置および無線ｌａｎ基地局装置
KR100620713B1 (ko) * 2004-07-28 2006-09-19 주식회사 팬택앤큐리텔 패킷 서비스 설정 제어 방법 및 이동통신 시스템
EP1782585A1 (de) * 2004-08-26 2007-05-09 Telefonaktiebolaget LM Ericsson (publ) Verfahren zum aktivieren eines pdp-kontexts
EP1892901A3 (de) * 2004-10-01 2011-07-13 Panasonic Corporation Dienstqualitätsbewusste Koordination für Aufwärtsübertragung auf dedizierten Kanälen
US20060114883A1 (en) * 2004-12-01 2006-06-01 Mehta Pratik M System and method for wireless cellular enabled information handling system router
US7551551B2 (en) * 2004-12-10 2009-06-23 Cisco Technology, Inc. Fast reroute (FRR) protection at the edge of a RFC 2547 network
KR100617814B1 (ko) * 2005-02-23 2006-08-28 삼성전자주식회사 단말기에서 연결 절차의 종료 방법
US9601015B2 (en) 2005-02-25 2017-03-21 Concaten, Inc. Maintenance decision support system and method for vehicular and roadside applications
US7355509B2 (en) 2005-02-25 2008-04-08 Iwapi Inc. Smart modem device for vehicular and roadside applications
EP1705859A1 (de) * 2005-03-24 2006-09-27 Orange SA Verfahren und System zur Aktivierung eines Kontextes für ein Packetdatenprotokoll
EP1705858A1 (de) 2005-03-24 2006-09-27 Orange SA Verfahren und System zur Aktivierung eines Kontextes für ein Paketdatenprotokoll
US20060233130A1 (en) * 2005-04-14 2006-10-19 Samsung Electronics Co., Ltd. Apparatus and method for quality of service management in a wireless network
CN101189839A (zh) * 2005-04-29 2008-05-28 艾利森电话股份有限公司 用于控制分组交换数据流中的实时连续数据的方法、***及其使用，用所述方法提供的实时连续数据服务
CA2611160A1 (en) * 2005-06-06 2006-12-14 Mobidia, Inc. System and method of controlling a mobile device using a network policy
CN100459797C (zh) * 2005-07-05 2009-02-04 华为技术有限公司 无线接入网络中提供区别服务的实现方法
US7782767B1 (en) * 2005-07-20 2010-08-24 Tektronix, Inc. Method and system for calculating burst bit rate for IP interactive applications
DE102005035237A1 (de) * 2005-07-25 2007-03-01 T-Mobile International Ag & Co. Kg Verfahren zur Steuerung von Ressourcen in Netzelementen eines Telekommunikationsnetzes
US7558201B2 (en) * 2005-12-01 2009-07-07 Nec Laboratories America, Inc. Measurement-based admission control for wireless packet data services
US9686183B2 (en) 2005-12-06 2017-06-20 Zarbaña Digital Fund Llc Digital object routing based on a service request
US7894447B2 (en) * 2005-12-06 2011-02-22 Lippershy Celestial Llc Digital object routing
US8144644B1 (en) 2006-02-07 2012-03-27 Sprint Spectrum L.P. Network-side setup of a packet-data communication session on behalf of a mobile station, followed by transfer of the communication session to the mobile station
CN101375550B (zh) * 2006-02-17 2012-10-10 艾利森电话股份有限公司 用于在通信终端处控制数据流的方法和设备
CN101128043B (zh) 2006-08-15 2011-02-02 华为技术有限公司 ***间切换或者改变时的数据处理方法
TW200826583A (en) * 2006-11-17 2008-06-16 Interdigital Tech Corp Method and apparatus for quality of service signaling and configuration
US8301179B2 (en) * 2006-12-06 2012-10-30 Research In Motion Limited Method and system for communicating a message attachment
US7782901B2 (en) * 2007-01-09 2010-08-24 Alcatel-Lucent Usa Inc. Traffic load control in a telecommunications network
US9019830B2 (en) 2007-05-15 2015-04-28 Imagine Communications Corp. Content-based routing of information content
US9030934B2 (en) * 2007-09-07 2015-05-12 Qualcomm Incorporated Host-based quality of service for wireless communications
US8284780B2 (en) * 2008-01-14 2012-10-09 At&T Intellectual Property I, L.P. Adaptive edge-implemented traffic policy in a data processing network
US8688500B1 (en) * 2008-04-16 2014-04-01 Bank Of America Corporation Information technology resiliency classification framework
US8331235B2 (en) * 2008-12-08 2012-12-11 At&T Intellectual Property I, L.P. Systems and methods to rerouting internet protocol traffic based on network user preferences
US8861445B2 (en) 2009-03-11 2014-10-14 Sony Cororation Multi-channel single radio communication in home mesh network
US8761174B2 (en) 2009-03-11 2014-06-24 Sony Corporation Quality of service traffic recognition and packet classification home mesh network
US8223786B2 (en) 2009-03-11 2012-07-17 Sony Corporation Quality of service scheduling for home mesh network
US7974297B2 (en) 2009-03-11 2011-07-05 Sony Corporation Quality of service queue management in home mesh network
US8780762B2 (en) 2009-03-11 2014-07-15 Sony Corporation Node query in ad hoc home mesh network
EP2259651A1 (de) * 2009-06-05 2010-12-08 Panasonic Corporation Qos-Multiplexen mittels Basisstation/Relaisknoten-Schnittstelle
CN101932034B (zh) * 2009-06-26 2013-10-02 华为技术有限公司 提高服务质量的方法及***和应用网网元
US9836783B2 (en) * 2009-07-24 2017-12-05 Avago Technologies General Ip (Singapore) Pte. Ltd. Method and system for content selection, delivery and payment
CN102271405B (zh) * 2010-06-04 2014-09-10 中兴通讯股份有限公司 一种承载资源分配方法及装置
KR20120067886A (ko) * 2010-12-16 2012-06-26 한국전자통신연구원 데이터 처리 방법 및 장치
CN102858029A (zh) * 2011-03-31 2013-01-02 北京新岸线无线技术有限公司 业务流删除方法及装置
CN103444228A (zh) * 2011-04-04 2013-12-11 瑞典爱立信有限公司 使用gn/gp的最大允许服务质量过程
US8937880B2 (en) * 2012-05-09 2015-01-20 Telefonaktiebolaget L M Ericsson (Publ) System and method for managing state transitions in a wireless communications network
TWI610580B (zh) * 2013-03-13 2018-01-01 微軟技術授權有限責任公司 無線網路上之多模態通信優先權
WO2015003972A1 (en) * 2013-07-10 2015-01-15 Telefonaktiebolaget L M Ericsson (Publ) A node and method for obtaining priority information in a header of a control plane message
US20150058441A1 (en) * 2013-08-20 2015-02-26 Samsung Electronics Co., Ltd. Efficient content caching management method for wireless networks
WO2015180185A1 (zh) * 2014-05-30 2015-12-03 华为技术有限公司 用户数据处理的方法及装置
JP6623279B2 (ja) * 2015-07-31 2019-12-18 コンヴィーダ ワイヤレス， エルエルシー （Ｓ）Ｇｉ−ＬＡＮにおけるＭＴＣサービス選択
US10368109B2 (en) * 2015-12-29 2019-07-30 DISH Technologies L.L.C. Dynamic content delivery routing and related methods and systems
KR102240633B1 (ko) 2018-04-28 2021-04-14 텔레폰악티에볼라겟엘엠에릭슨(펍) QoS 흐름 제어 파라미터들 시그널링
CN112313991B (zh) * 2018-06-26 2024-03-22 诺基亚技术有限公司 用于通信***中的增强型数据分组流处理的方法和装置
WO2020069742A1 (en) * 2018-10-04 2020-04-09 Huawei Technologies Co., Ltd. Network node and client device for quality-of-service change management
CN113785511A (zh) * 2019-05-02 2021-12-10 诺基亚技术有限公司 装置、方法和计算机程序

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI103005B (fi) * 1996-03-25 1999-03-31 Nokia Telecommunications Oy Lähetettävän datan priorisointi reitittimessä
FI103455B1 (fi) 1996-10-08 1999-06-30 Nokia Telecommunications Oy Pakettiverkon reititin
US6335927B1 (en) * 1996-11-18 2002-01-01 Mci Communications Corporation System and method for providing requested quality of service in a hybrid network
EP0855820A3 (de) 1996-12-13 2003-04-16 International Business Machines Corporation Verfahren und System zur Optimierung der Bandbreitebelegung von einer Datenübertragungsleitung in einer Umgebung mit Mehrfachprioritätsdatenverkehr
JPH10200536A (ja) 1997-01-09 1998-07-31 Toshiba Corp ネットワークシステム
US6061346A (en) * 1997-01-17 2000-05-09 Telefonaktiebolaget Lm Ericsson (Publ) Secure access method, and associated apparatus, for accessing a private IP network
FI105136B (fi) * 1997-04-21 2000-06-15 Nokia Mobile Phones Ltd Yleinen pakettiradiopalvelu
NO304570B1 (no) 1997-05-20 1999-01-11 Ericsson Telefon Ab L M FremgangsmÕte relatert til GPRS (General Packet Radio Service) system med pakkesvitsjede forbindelser
JP3738872B2 (ja) * 1997-06-19 2006-01-25 株式会社村田製作所 部品整列装置
US6104929A (en) * 1997-06-20 2000-08-15 Telefonaktiebolaget Lm Ericsson Data packet radio service with enhanced mobility management
FI105309B (fi) * 1997-06-24 2000-07-14 Nokia Mobile Phones Ltd Matkaviestinjärjestelmät
DE19730363B4 (de) * 1997-07-15 2011-08-11 Telefonaktiebolaget Lm Ericsson (Publ) Ortsspezifische World Wide Web Dienste in digitalen zellularen Kommunikationsnetzwerken
US6937566B1 (en) 1997-07-25 2005-08-30 Telefonaktiebolaget Lm Ericsson (Publ) Dynamic quality of service reservation in a mobile communications network
US6574221B1 (en) * 1997-12-19 2003-06-03 Telefonaktiebolaget Lm Ericsson (Publ) Asynchronous transfer mode platform for mobile communications
US6236656B1 (en) * 1998-03-19 2001-05-22 Telefonaktiebolaget Lm Ericsson (Publ) Link-efficiency based scheduling in radio data communications systems
US6721278B1 (en) * 1998-04-30 2004-04-13 Telefonaktiebolaget Lm Ericsson (Publ) Dynamic allocation of packet data channels
US6400954B1 (en) * 1998-05-15 2002-06-04 Tlelefonaktiebolaget Lm Ericsson (Publ) Methods and systems for mode selection based on access network capacity
FI105969B (fi) * 1998-08-10 2000-10-31 Nokia Networks Oy Palvelunlaadun hallinta matkaviestinjärjestelmässä
US6320873B1 (en) * 1998-08-27 2001-11-20 Qualcomm Incorporated CDMA transmission of packet-switched data
KR100901822B1 (ko) * 2007-09-11 2009-06-09 주식회사 실트론 질화갈륨 성장용 기판 및 질화갈륨 기판 제조 방법

Also Published As

Publication number Publication date
CA2339825C (en) 2004-11-02
US7023825B1 (en) 2006-04-04
BR9912911A (pt) 2001-05-08
JP2002523938A (ja) 2002-07-30
CA2339825A1 (en) 2000-02-24
CN1178546C (zh) 2004-12-01
EP1104639B1 (de) 2004-11-10
CN1545365A (zh) 2004-11-10
CN1317217A (zh) 2001-10-10
EP1104639A1 (de) 2001-06-06
DE69921831D1 (de) 2004-12-16
WO2000010357A1 (en) 2000-02-24
BR9912911B1 (pt) 2013-09-03
ATE282283T1 (de) 2004-11-15
FI981722A0 (fi) 1998-08-10
FI105969B (fi) 2000-10-31
ES2232159T3 (es) 2005-05-16
AU5291899A (en) 2000-03-06
JP3574788B2 (ja) 2004-10-06
CN100373985C (zh) 2008-03-05
FI981722A (fi) 2000-02-11

Similar Documents

Publication Publication Date Title
DE69921831T2 (de) Kontrolle der dienstqualitäten in einem mobilkommunikationssystem
DE60120354T2 (de) Rsvp-verarbeitung in 3g-netzwerken
DE69834188T2 (de) Dynamische dienstqualitätreservierung in einem mobilen kommunikationsnetz
DE60106457T2 (de) Zuteilung von datenübertragungsbetriebsmitteln bei der paketvermittelten datenübertragung
DE60314860T2 (de) Betrachtung der mobilstationsfähigkeit bei der aushandlung der dienstqualität für paketvermittelte dienste
DE60127869T2 (de) Verfahren zum zuteilen von dienstparameterwerten an übertragungen, funkzugangsnetze und netzwerkelemente
DE60003525T2 (de) Übertragung von dienstqualitätsabbildungsinformation in einem paketfunknetz
DE60115030T2 (de) Kommunikationen unter verwendung von adaptiven mehrraten kodierern/dekodierern
DE60108765T2 (de) Basis-qos-mechanismen zur drahtlosen übertragung von ip-verkehr
DE69829764T2 (de) Auswahl zwischen paketvermittelte und leitungsvermittelte dienste in einem mobilen kommunikationssystem
DE69935397T2 (de) Verfahren und Vorrichtung zur Echtzeitdatenübertragung in einem Paketfunknetz
DE60211881T2 (de) Bindungsinformation für ip mediendatenströmen
DE10302788B4 (de) Einrichtung und Verfahren zum Umordnen von TFTs in einem Mobilkommunikationssystem
DE60215026T2 (de) Verfahren für Verkehrslastmanagement basierend auf dem Austausch von dienstspezifischen Informationselementen für freie Kapazität zwischen Funkzugangsnetz-Steuerungseinheiten
DE60317992T2 (de) Verfahren zum Übertragen von GPRS Datenpaketen aus unterschiedlichen PDP Kontexten gemäss ihrer relativen Priorität
DE60008735T2 (de) Steuerung von pdp-kontexten in mobilstationen
DE69833111T2 (de) Bestimmung von trägerdiensten in einem funkzugriffsnetz
DE60034654T2 (de) System und Verfahren zur Adaption und Verwaltung von IP Dienstqualität
DE60130114T2 (de) Anwendungsbeeinflusste richtlinie
DE602004009913T2 (de) Verfahren, system und netzwerkelement zur autorisierung einer datenübertragung
DE60307097T2 (de) Datenstrombasiertes selektives Reverse Tunneling in WLAN - Zellularsystemen
DE60028862T2 (de) System zum Aufbau einer Datenverbindung in drahtlosen Netzwerken
DE60030858T2 (de) Verfahren und anordnung zur anzeige der speziellen verwendung eines pdp kontexts
DE60108514T2 (de) Definieren einer nachrichtenkopf-datenfeldkomprimierung für eine datenpaketverbindung
DE60031163T2 (de) Verfahren und vorrichtungen zum bereitstellen einer wohldefinierten servicequalität in einem paketvermittelten kommunikationsnetz

Legal Events

Date Code Title Description
8364 No opposition during term of opposition