DE60125422T2

DE60125422T2 - Abbildung von paketen auf pdp-kontexte bei vielfach-verbindungen

Info

Publication number: DE60125422T2
Application number: DE60125422T
Authority: DE
Inventors: Serge Haumont
Original assignee: Nokia Inc
Current assignee: Nokia Inc
Priority date: 2001-06-15
Filing date: 2001-06-15
Publication date: 2007-10-11
Anticipated expiration: 2021-06-16
Also published as: ATE349142T1; EP1400136B1; US20040153551A1; EP1400136A1; WO2002104046A1; DE60125422D1; US7802011B2

Description

GEBIET DER ERFINDUNG
Die vorliegende Erfindung bezieht sich auf die dynamische Konfiguration einer Benutzereinrichtung bzw. der Anwendungen in der Benutzereinrichtung, die mit einer Vielfalt externer Netze (beispielsweise dem Internet, einem Intranet) über eine Zugangstechnik verbunden werden kann, die eine Vielzahl von Dienstgüte-(QoS-)Flüssen unterstützt. Die Erfindung ist insbesondere für die Abbildung von Paketdaten auf PDP-Kontexte für GPRS-(General Packet Radio Service, Allgemeiner Paketfunkdienst)Teilnehmer mit Mehrfachsitzungen und gleichzeitig aktiven Anwendungen relevant.
HINTERGRUND DER ERFINDUNG
Auf typische Netze wie ein Internet-Netz kann auf vielerlei Wegen (GPRS, WLAN, ADSL-Modem, usw.) zugegriffen werden. Außerdem unterstützen viele Zugangstechnologien eine Vielzahl von Qos-Flüssen (GPRS, ADSL, RSVP, usw.). Gleichzeitig wird dieselbe Benutzereinrichtung oft zum Zugreifen auf verschiedene Netze verwendet. Ein typisches Beispiel ist ein GPRS-Netz, wo eine Benutzereinrichtung mit dem Internet oder einem Intranet unter Verwendung verschiedener Zugangspunkte verbunden werden kann. GPRS ist die in GSM und UMTS (unter Verwendung von WCDMA(Wideband Code Division Multiple Access, Breitband-Codemultiplex-Zugang)-Funk) verwendete Pakettechnik. In GPRS ist jeder QoS-Fluss mit einem PDP-Kontext (einer logischen Verbindung von der Benutzereinrichtung zum externen Netz) assoziiert, siehe beispielsweise WO 99/05828.
In einer in 1 gezeigten PDP-(Packet Data Protocol, Paketdatenprotokoll)Kontext-Aktivierungsprozedur sendet eine MS (Mobilstation) eine PDP-Kontext-Aktivierungsanforderungsnachricht mit PDP-Typ, PDP-Adresse, APN (Access Point Name, Zugangspunktname) und QoS (Quality of Service, Dienstgüte) angefordert zu einem SGSN (Serving GPRS Support Node, bedienender GPRS-Unterstützungsknoten) in einem PLMN (Public Land Mobile Network, öffentliches Fernsprechnetz). QoS angefordert gibt das gewünschte QoS-Profil an. Der SGSN validiert die PDP-Kontext-Aktivierungsanforderung optional unter Verwendung von PDP-Typ, PDP-Adresse und APN.
Kann eine GGSN-(Gateway GPRS Support Node, Gateway-GPRS-Unterstützungsknoten)Adresse erhalten werden, sendet der SGSN eine PDP-Kontext-Erzeugungsanforderungsnachricht mit PDP-Typ, PDP-Adresse, APN und QoS ausgehandelt zu dem betroffenen GGSN. Der GGSN kann den APN zum Herausfinden eines externen Netzes verwenden. Ein Auswahlmodus gibt an, ob ein teilnehmender APN ausgewählt wurde, oder ob ein durch die MS gesendeter nicht teilnehmender APN oder ein durch den SGSN ausgewählter nicht teilnehmender APN ausgewählt wurde. Der GGSN kann den Auswahlmodus zum Entscheiden darüber verwenden, ob die PDP-Kontext-Aktivierung angenommen oder verworfen werden soll. Fordert beispielsweise ein APN eine Teilnahme an, ist der GGSN zum Annehmen lediglich der PDP-Kontext-Aktivierung eingerichtet, die einen teilnehmenden APN anfordert, wie es vom SGSN mit Auswahlmodus angegeben ist. Der GGSN erzeugt einen neuen Eintrag in seiner PDP-Kontext-Tabelle und erzeugt eine Abrechnungs-ID. Der neue Eintrag ermöglicht dem GGSN das Lenken von PDP PDUs (Packet Data Units, Paketdateneinheiten) zwischen dem SGSN und dem externen PDP-Netz und das Beginnen der Gebührenerfassung. Der GGSN gibt eine PDP-Kontext-Erzeugungsantwortnachricht mit PDP-Adresse, QoS ausgehandelt und Gebühren-ID zum SGSN zurück.
Ist die vom SGSN empfangene ausgehandelte QoS mit dem aktivierten PDP-Kontext inkompatible, verwirft der GGSN die PDP-Kontext-Erzeugungsanforderungsnachricht.
Der SGSN gibt eine PDP-Kontext-Aktivierungsannahmenachricht zu der MS zurück. Der SGSN kann nun PDP PDUs zwischen dem GGSN und der MS lenken und die Gebührenerfassung beginnen.
GPRS kann verschiedene QoS-Flüsse für eine eindeutige PDP-Adresse (beispielsweise eine IPv4- oder IPv6-Adresse) unterstützen, die jeweils einem PDP-Kontext entsprechen. In 3GPP Release 99 verwendet das QoS-Verfahren einen Satz an Filtern, die Traffic Flow Template (TFT, Verkehrsflussmaske) genannt werden, und Informationen im IP-Header, wie ein Diensttyp(Type of Service, ToS)-Feld oder eine UDP-(User Datagram Protocol, Benutzerdatagrammprotokoll)Portnummer zum Bestimmen, zu welchem PDP-Kontext ein IP-Paket gehört.
Die MS bildet Uplink-Pakete auf den richtigen PDP-Kontext ab, und der GGSN bildet Downlink-Pakete auf den richtigen PDP-Kontext unter Verwendung der TFT ab. Es ist anzumerken, dass die MS die GGSN TFT konfiguriert.
Obwohl dieses QoS-Verfahren eine Unterscheidung des Verkehrs ermöglicht, ist es aus verschiedenen Gründen nicht immer leicht anzuwenden:

– Anwendungen verwenden nicht immer feste Portnummern,
– eine durchgängige Verschlüsselung kann die UDP-Portnummer für den GGSN unzugänglich machen,
– ToS-Werte werden durch den Betreiber ausgewählt, so dass eine Anwendung verschiedene ToS-Werte in verschiedenen Netzen haben kann, und/oder
– ToS-Werte können durch Rand-Router am Punkt der Verbindung zwischen zwei ISPs (Internet-Serviceprovidern) geändert werden.

Ein typisches Anwendungsbeispiel ist ein H323-Ruf. Ein Verlass auf die Portnummer ist nicht sinnvoll, da manche Protokolle der H323-Familie, beispielsweise H245, einen dynamischen Port verwenden. Die Verwendung der Portnummer wird gerade unmöglich, wenn Verschlüsselung verwendet wird.
Üblicherweise ist der Endpunkt einer IP-Verbindung der Benutzereinrichtung ein Server in einem IP-Netz, der durch den Betreiber des IP-Netzes gesteuert wird, beispielsweise ein Callserver, oder der Endpunkt ist ein Server im Internet oder im Intranet, der nicht durch den IP-Netzbetreiber gesteuert wird. Allerdings kann eine Kommunikation auch zwischen zwei Benutzereinrichtungen (beispielsweise ein VoIP-Ruf), die über verschiedene Betreibernetze verbunden sind, errichtet werden.
Das allgemeine Problem ist daher, wie QoS für Anwendungen richtig konfiguriert werden kann, die über verschiedene Zugänge und mit verschiedenen Netzen verbunden werden können, insbesondere die durch die Zugangstechnik verwendeten QoS-Parameter, das zur Auswahl des geeigneten QoS-Flusses verwendete Filter, und die in dem Netz verwendeten QoS-Parameter (beispielsweise ToS), wo die Verbindung errichtet wird, richtig konfiguriert werden können. Ein weiteres Problem besteht darin, wie Filter für Anwendungen einzustellen sind, die keine feste Portnummer verwenden, oder bei denen die Portnummer aufgrund von Verschlüsselung nicht gelesen werden kann.
Ein weiteres Problem besteht darin, dass ToS-Einstellungen oft proprietär sind.
KURZZUSAMMENFASSUNG DER ERFINDUNG
Aufgabe der Erfindung ist das Lösen der vorstehend angeführten Probleme und die Bereitstellung einer QoS-bezogenen Konfiguration für jede Anwendung, selbst wenn Verschlüsselung verwendet wird.
Erfindungsgemäß wird diese Aufgabe durch ein System nach Anspruch 1 gelöst. Die Aufgabe wird auch durch eine Konfigurationseinrichtung nach Anspruch 14 gelöst. Außerdem wird die Aufgabe durch ein Verfahren nach Anspruch 19 gelöst.
Erfindungsgemäß umfasst ein Paketdatennetzsystem zum Lenken von Paketen, die zu verschiedenen Dienstgüteflüssen gehören, eine Teilnehmereinrichtung zum Initiieren von Anwendungen mit assoziierten Dienstgüteflüssen in einer Mehrfachsitzungsverbindung. Die Teilnehmereinrichtung kann einen Laptop oder dergleichen und ein „Modem" oder eine Zugangseinrichtung (beispielsweise ein ADSL-Modem oder eine Mobilstation) zum Senden von Datenpaketen zu einem Paketdatennetz wie einem Betreiber-IP-Netz umfassen. Die Teilnehmereinrichtung kann auch die Anwendung und das Modem in derselben Einrichtung integrieren, wie im Nokia-Communicator.
Die Unterscheidung von zwei Fällen ist wichtig:

– die Anwendung ist mit der Zugangstechnik eng integriert, so dass sie die erforderliche QoS und den QoS-Fluss, den sie verwenden sollte, angeben kann. Dies ist im Fall einer integrierten Einrichtung typisch aber nicht notwendig.
– die Anwendung ist nicht eng mit der Zugangstechnik integriert, so dass sie die erforderliche QoS unter Verwendung eines generischen API angeben kann, und den QoS-Fluss, den sie verwenden sollte, nicht direkt identifizieren kann. Stattdessen muss das Modem den von verschiedenen Anwendungen empfangenen Verkehr auf verschiedene QoS-Flüsse unter Verwendung seiner eigenen Filter abbilden. Dies ist bei einer separaten Einrichtung typischerweise, aber nicht unbedingt der Fall.

Das System umfasst ferner eine Konfigurationseinrichtung wie einen Konfigurationsserver (beispielsweise einen Policy-Server), der in dem Betreiber-IP-Netz platziert sein kann. Die Konfigurationseinrichtung erhält für jede initiierte Anwendung Diensttypinformationen eines Netzknotens, der die Anwendung leitet, wie eines Betreiberanwendungsserver, Medien-Gateway, H323-Gatekeeper, Laptop, usw. Dann stellt die Konfigurationseinrichtung die Konfigurationsinformationen der Teilnehmereinrichtung zur Verfügung. Diese Informationen werden aus den erhaltenen Diensttypinformationen und möglicherweise aus der Betreiberpolitik hergeleitet. Diese Informationen enthalten QoS-Parameter, die einen QoS-Fluss (beispielsweise ein GPRS QoS-Profil), Filter für Uplink und Downlink (beispielsweise TFT) und durch die Anwendung zu verwendende Parameter (ToS oder Portnummer) definieren.
Das System umfasst ferner einen Gateway-Knoten, wie einen GGSN, der die Zugangstechnologie mit dem Betreiber-IP-Netz verbindet, um Pakete zwischen dem Netz und der Teilnehmereinrichtung auszutauschen. Dieser Gateway sollte den richtigen QoS-Fluss für jede Anwendung unter Verwendung der Filter unter Verwendung beispielsweise des ToS-Feldes ankommender Pakete auswählen. Die Teilnehmereinrichtung verwendet die erhaltenen Konfigurationsinformationen zum Einstellen der Filter und des assoziierten Dienstgüteflusses im Gateway-Knoten. Der Gateway-Knoten kann die Pakete in den richtigen QoS-Fluss auf der Grundlage des durch die Benutzereinrichtung eingestellten Filters und des Paket-Headers (beispielsweise ToS-Feld) lenken. Es ist anzumerken, dass die Benutzereinrichtung das Filter im Gateway-Knoten einstellt, da dann, wenn keine dynamische Konfiguration angewendet wird, die Anwendung in der Benutzereinrichtung die einzige Größe ist, die das Filter geeignet einstellen kann. Dies ist der Fall in GPRS, wo die MS die TFT einstellt. Es wird angenommen, dass dasselbe generische Verfahren bei der dynamischen Konfiguration beibehalten wird, so dass die Filter des Gateway-Knotens durch die Benutzereinrichtung eingestellt werden.
Die Diensttypinformationen (oder ein anderes vom Filter verwendetes Feld), die in den durch eine Anwendung gesendeten Paketen markiert sind, können durch einen Betreiber des Netzes bestimmt werden, der diese Anwendung leitet. Bei einem bevorzugten Ausführungsbeispiel wird dieses ToS durch dieselbe Konfigurationseinrichtung in den verschiedenen Anwendungen eingestellt. In diesem Fall erhält die Konfigurationseinrichtung diese Parameter direkt. Befindet sich die Anwendung in einem anderen Netz, das über einen Rand-Router verbunden ist, der die Diensttypinformationen der IP-Pakete ändern kann, kann die gleiche Konfigurationseinrichtung den Rand-Router konfigurieren und den Servicetyp erhalten, der von der Anwendung im anderen Netz verwendet wird. Die Konfigurationseinrichtung weiß dann, mit welchen Diensttypinformationen das Paket markiert sein wird, das zu einer bestimmten Anwendung gehört, die am Gateway-Knoten ankommt.
Kann die Konfigurationseinrichtung die durch die Anwendung eingestellten Parameter direkt konfigurieren (beispielsweise die Anwendung implementiert keine dynamische Konfiguration), kann die Konfigurationseinrichtung ferner Einstellungen, wie Diensttyp-(ToS)Informationen (beispielsweise DiffServ Codepunkte) der Anwendung(en) in der Teilnehmereinrichtung erhalten und der Teilnehmereinrichtung die Konfigurationsinformationen zuführen. Diese Konfigurationsinformationen sind vorzugsweise Filter beruhend auf den Diensttypinformationen und geeigneten QoS-Parametern. Dies ist in 2 gezeigt, wo unter Kenntnis der Einstellungen der Anwendung und der Betreiberpolitik (hier verwenden Netscape und Q931 interaktive Klassen, Email verwendet Hintergrundklassen und UDP/RTP verwendet Konversationsklassen) die Konfigurationseinrichtung die geeigneten Filter der Teilnehmereinrichtung (beispielsweise der Mobilstation) angeben kann. Die Teilnehmereinrichtung verwendet dann das ToS-Feld der von einer Anwendung kommenden IP-Pakete und das Filter zum Abbilden dieses Uplink-Pakets auf den geeigneten QoS-Fluss (beispielsweise PDP-Kontext). Die Teilnehmereinrichtung sendet Pakete zum Netz für jede initiierte Anwendung entsprechend dem assoziierten Dienstgütefluss, der in der Teilnehmereinrichtung abgebildet ist.
Zum geeigneten Konfigurieren des Gateway (beispielsweise GGSN) muss die Teilnehmereinrichtung eventuell die Abbildung für die Downlink-Richtung kennen. Dieser Filtersatz (beispielsweise TFT) wird zuerst von der Konfigurationseinrichtung zu der Teilnehmereinrichtung und dann von der Teilnehmereinrichtung zum Gateway gesendet. Der Gateway kann dann jedes Downlink-Paket in den richtigen QoS-Fluss senden.
Die Konfigurationseinrichtung kann Einstellinformationen auf vielerlei Wegen erhalten:
Zum Einen sind Einstellungen oft sehr statisch. Beispielsweise verwendet ein bestimmter Anwendungstyp einen festen UDP-Port. Einige andere Anwendungen verwenden eventuell immer dieselben ToS-Informationen. In diesem Fall sind die Einstellinformationen lediglich öffentliches Wissen. Bei einem zweiten Ausführungsbeispiel kann die Anwendung konfigurierbare Einstellungen aufweisen. In diesem Fall kann der Betreiber zum Bereitstellen dieser Konfiguration für den Benutzer fähig sein. Er kann sie vor dem Verkauf der Anwendung an den Benutzer vorkonfigurieren, oder er kann eine Fernkonfiguration anwenden, oder er kann eine Übereinkunft mit der Informationsverwaltungs-(Information Management, IM)Abteilung einer Firma haben, die geeignete Einstellungen installiert. Im letzten Fall wird angenommen, dass die Firma eine spezielle Übereinkunft mit dem Betreiber hat.
Die Erfindung stellt ein Verfahren zur dynamischen Konfiguration einer Benutzereinrichtung und einer Anwendung in der Benutzereinrichtung bereit, so dass Paketverkehr der Anwendung über einen geeigneten QoS- Fluss unter Verwendung geeigneter QoS-Parameter gesendet wird.
Pakete werden in dem geeigneten QoS-Fluss unter Verwendung von Filtern geroutet. Diese Filter verwenden Informationen im Paket-Header, wie ToS-Informationen zum Abbilden von Paketen auf assoziierte QoS-Flüsse (beispielsweise PDP-Kontexte). So wird der QoS-Pegel bereitgestellt, der von einer Anwendung verlangt wird. Die Erfindung stellt eine Einrichtung zum Konfigurieren von Uplink- und Downlink-Filtern und ihres assoziierten QoS-Flusses für jede von einer Benutzereinrichtung verwendete Anwendung oder Protokoll bereit.
Die Erfindung wird nachstehend anhand bevorzugter Ausführungsbeispiele unter Bezugnahme auf die beiliegenden Zeichnungen beschrieben.
KURZBESCHREIBUNG DER ZEICHNUNGEN
1 zeigt eine PDP-Kontextaktivierungsprozedur.
2 zeigt ein schematisches Blockschaltbild eines Netzsystems mit einem erfindungsgemäßen Konfigurationsserver.
3 zeigt ein System, in dem ein Policy-Server COPS zum dynamischen Konfigurieren der Benutzereinrichtung verwendet.
4 zeigt ein System, in dem ein Konfigurationsserver WAP zum dynamischen Konfigurieren der MS verwendet.
BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSBEISPIELE
2 zeigt ein Netzsystem gemäß GPRS. Eine Mobilstation (MS), mit der ein Laptop verbunden werden kann, kann Mehrfachsitzungen zum Verwenden von Anwendungen oder Protokollen initiieren, die beispielsweise in einem Betreiber-IP-Netz durch einen Betreiberanwendungsserver, Medien-Gateway und/oder H323-Gatekeeper geleitet werden. Für jede Sitzung wird ein PDP-Kontext mit einer angeforderten QoS durch die MS in einem (nicht gezeigten) SGSN in Richtung eines GGSN im Betreiber-IP-Netz aktiviert. Der GGSN muss dann zu den verschiedenen Anwendungen oder Protokollen gehörende Downlink-Pakete auf die geeigneten PDP-Kontexte oder QoS-Flüsse abbilden.
Erfindungsgemäß verfolgt ein dedizierter, netzspezifischer Konfigurationsserver die ToS-Einstellungen von im Netzsystem geleiteten Anwendungen.
Gemäß einem Ausführungsbeispiel der Erfindung weiß der Konfigurationsserver, wie der Laptop die ToS-Bits für jede Anwendung einstellt. Der Konfigurationsserver erhält dieses Wissen vom Firmen-IT-(Information Technology)Personal oder anhand der Software, die der Betreiber für den Benutzer (bevorzugt ferngesteuert) bereitstellt. Im Fall einer Communicator ähnlichen integrierten MS kennt der Betreiber die ToS-Einstellung anhand des Mobiltyps oder Herstellers und versieht den Konfigurationsserver mit diesem Wissen.
Gemäß einem anderen Ausführungsbeispiel kann der Betreiber zum Konfigurieren der Mobileinstellungen, d.h., der Abbildung zwischen der Anwendung und den ToS-Bits fähig sein. Dies kann durch Anwenden eines Vorgabestandards oder eines abgemachten Standards ausgeführt werden.
Der Konfigurationsserver wird mit den ToS-Informationen der im Betreibernetz geleiteten Anwendungen versehen. Beispielsweise weiß der Konfigurationsserver, wie der Anwendungsserver die ToS-Bits einstellt. Dabei handelt es sich um eine direkte Konfiguration, wenn der Anwendungsserver dem Betreiber oder einem Betreiberpartner gehört. Die Einstellung kann auch bekannt sein, wenn der Anwendungsserver durch Firmenpersonal aufgebaut wird und der Betreiber eine Übereinkunft mit der Firma hat. Ein besonders wichtiger Anwendungsserver ist ein Callserver, der voraussichtlich vom Betreiber verwaltet wird. Das Wissen um die Einstellung kann auch aus einem Vorgabestandard oder abgemachten Standard hergeleitet werden.
Initiiert der Teilnehmer eine Sitzung zum Anwenden einer Anwendung, die in dem in 2 gezeigten Betreiber-IP-Netz geleitet wird, versieht der Konfigurationsserver dieses IP-Netzes die MS mit ToS-Informationen der Anwendung, um die MS darüber zu informieren, wie sie ihre eigene TFT und die GGSN TFT konfigurieren sollte. Der Betreiber kann MExE (Mobile application Execution Environment, Mobil-Anwendungs-Ausführungsumgebung) zum Aktualisieren der MS-Konfiguration verwenden, d.h., zum Abbilden von ToS auf den PDP-Kontext. Konfiguriert die MS die im GGSN zu verwendende TFT für diese Sitzung, kann sie die richtigen ToS-Informationen bestimmen, und der GGSN kann die ToS-Informationen beim Routen von Paketen zu mehreren gleichzeitigen Sitzungen desselben Teilnehmers verwenden.
Alternativ können die ToS-Informationen zu Beginn vom Konfigurationsserver zu der MS über eine Einzelsitzungsverbindung vom Teilnehmer zur Anwendung geliefert werden, wenn es für den GGSN offensichtlich ist, welcher PDP-Kontext zu verwenden ist.
Gibt es Rand-Router, die mit durchgehenden ToS-Informationen interferieren, muss die Konfigurationsserveranwendung die Art der Interferenz kennen und dieser Interferenz entgegenwirken können. Im Fall eines Rand-Routers des Betreibers kann der Konfigurationsserver dessen Verhalten leicht kennen und dagegen wirken.
2 zeigt ein Beispiel von ToS-Einstellungen und PDP-Kontextabbildungen. Der Konfigurationsserver kennt die ToS-Einstellungen des Laptops für Netscape (= ToS4), Email (= ToS3), Q931 (= ToS5) und User Datagram Protocol (UDP)/Real Time Protocol (RTP, Echtzeitprotokoll) (= ToS11), und versieht die MS mit diesen ToS-Einstellungen und informiert die MS, wie sie ihre TFT konfigurieren soll, d.h., wie der Uplink-ToS auf einen PDP-Kontext abzubilden ist. Wie in 2 gezeigt, bildet die MS ToS4 auf PDP-Kontext 1 (interaktiv), ToS3 auf PDP-Kontext 2 (Hintergrund), ToS5 auf PDP-Kontext 1 (interaktiv) und ToS11 auf PDP-Kontext 3 (Konversation) ab.
Desweiteren kennt der Konfigurationsserver die ToS-Einstellungen des Betreiberanwendungsservers (Netscape = ToS8, Email = ToS3) und des Medien-Gateway (Q931 = ToS7, UDP/RTP = ToS13), die die initiierten Anwendungen leiten. Der Konfigurationsserver stellt diese Einstellungen für die MS bereit und informiert die MS über die Konfiguration der GGSN TFT, d.h., die Abbildung des Downlink-ToS auf einen PDP-Kontext. Die MS konfiguriert die GGSN TFT entsprechend, so dass der GGSN ToS3 auf PDP-Kontext 2, ToS8 auf PDP-Kontext 1, ToS13 auf PDP-Kontext 3 und ToS7 auf PDP-Kontext 1 abbildet. Somit werden die Downlink-Pakete durch den GGSN auf den gleichen PDP-Kontext wie die entsprechenden Uplink-Pakete abgebildet.
Ein unterschiedlicher Signalisierungsfluss, der zeigt, wie die Mobilstation konfiguriert wird, ist in den 3 und 4 gezeigt.
3 zeigt eine PDP-Kontext-Aktivierung, in der der GGSN die Autorisierung von einem Policy-Server unter Verwendung einer COPS-Pull-Anforderung (Kommunikation 3 in 3) überprüft. Die COPS-Pull-Anforderung enthält eine Benutzeridentität, eine Benutzer-IP-Adresse, eine angeforderte QoS, eine TFT, ein Autorisierungs-Token, eine Angabe einer beabsichtigten Verwendung des PDP-Kontext, wenn verfügbar (beispielsweise Signalisierungs-PDP-Kontext), eine MS-Fähigkeit und andere relevante Parameter. Autorisiert der Policy-Server den PDP-Kontext, sendet der Policy-Server eine COPS-Entscheidung zum GGSN (Kommunikation 4 in 3), und kann ferner Konfigurationsinformationen direkt zu der MS unter Verwendung von COPS-Push senden (Kommunikation 7 in 3). Diese Konfigurationsinformationen enthalten eine Liste von Filtern, und verbunden mit jedem Filter: Diffserv-Markierung, UMTS QoS-Profil, TFT und APN. Außerdem kann eine Anwendungsserver-IP-Adresse gesendet werden, die von verschiedenen Anwendungen zu verwenden ist. APN kann auf Platzhalter gesetzt sein, was anzeigt, dass jeder APN akzeptiert wird. Diese Informationen sind nicht auf die durch eine Anwendung erforderlichen Konfigurationsinformationen begrenzt, sondern können alle Anwendungen abdecken, die die MS abwickeln darf und kann. Die Fähigkeiten werden aus einem neuen Informationselement „MS-Fähigkeit" hergeleitet, das ein Zusatz der in dieser Anmeldung vorhandenen PDP-Kontextaktivierungsprozedur ist. „MS-Fähigkeit" deckt eine QoS-Unterstützung (maximale von der MS unterstützte Bitrate; Liste unterstützter Verkehrsklassen) und eine Liste von in der MS installierten Anwendungen ab. Diese Informationen werden von der MS empfangen.
Die Anwendungsserver-IP-Adresse (wie eine WAP-Gateway-Adresse, die gegenwärtig fest programmiert ist) kann dann dynamisch in der MS eingestellt werden.
Gemäß einem ersten Ausführungsbeispiel wird der Fall beschrieben, in dem eine Anwendung nicht durch die MS konfigurierbar ist, d.h., typischerweise auf einer separaten Einrichtung implementiert ist.
Gemäß dem ersten Ausführungsbeispiel verhält sich die MS auf folgende Weise. Wird ein Uplink-Paket durch die MS empfangen, überprüft die MS es zuerst gegenüber dem Filter (beispielsweise UDP-Port 8080). Das Filter zeigt der MS, mit welchen Diffserv-Codepunkten dieses Uplink-Paket zu markieren ist, und mit welchem UMTS QoS-Profil es über den Funkweg zu senden ist. Die MS überprüft dann, ob ein geeigneter PDP-Kontext vorhanden ist (ähnliche QoS und selber PDP-Typ, annehmbarer APN), um das Paket direkt zu senden. Wird ein derartiger PDP-Kontext gefunden, wird das Paket in diesem PDP-Kontext gesendet. Ist kein geeigneter PDP-Kontext vorhanden, aktiviert die MS einen geeigneten PDP-Kontext. Nach der PDP-Kontext-Aktivierung wird das Paket in diesem PDP-Kontext gesendet. Der PDP-Kontext kann entfernt werden, nachdem während einer bestimmten Zeit kein Verkehr gesendet wurde.
Gemäß einem zweiten Ausführungsbeispiel wird der Fall beschrieben, in dem eine Anwendung durch die MS konfigurierbar ist, die typischerweise in der MS implementiert ist.
Gemäß dem zweiten Ausführungsbeispiel verwendet die MS die in Kommunikation 7 in 3 empfangenen Konfigurationsinformationen zum Konfigurieren der Anwendung. Die Anwendung markiert das IP-Paket geeignet beruhend auf den in der COPS-Push-Nachricht gesendeten Markierungsinformationen. Muss die Anwendung ein Paket senden, fordert sie zuerst eine PDP-Kontext-Aktivierung mit einer geeigneten QoS, einem geeigneten APN und einer geeigneten TFT an.
4 zeigt ein System, in dem ein Konfigurationsserver WAP-(Wireless Application Protocol, drahtloses Anwendungsprotokoll)Push zum dynamischen Konfigurieren der Anwendung in der MS verwendet. WAP-Push enthält in seiner Adressierung die Anwendungs-ID, und ist daher zum direkten Adressieren einer Anwendung gut geeignet.
Wird ein PDP-Kontext erzeugt, sendet der GGSN eine RADIUS-Startkontonachricht (Kommunikation 3 in 4) mit einer Benutzeridentität (beispielsweise IMSI, MSISDN), Benutzer-IP-Adresse, angeforderter QoS, einer Angabe einer beabsichtigten Verwendung des PDP-Kontexts, wenn verfügbar (beispielsweise Signalisierungs-PDP-Kontext), MS-Fähigkeit und anderen relevanten Parametern zu einem Konfigurationsserver. Wird der PDP-Kontext deaktiviert, wird zu dem Konfigurationsserver auch eine RADIUS-Stoppkontonachricht gesendet. Daher weiß der Konfigurationsserver, ob die MS verbunden ist oder nicht.
Der Konfigurationsserver sendet eine Bestätigungsnachricht zu dem GGSN (Kommunikation 4 in 4) und sendet ferner eine WAP-Push-Nachricht direkt zu der Anwendung (den Anwendungen), die er konfigurieren muss (Kommunikation 7 in 4). Diese Nachricht enthält Konfigurationsinformationen wie Filter (Abbildung für Uplink), Diffserv-Markierung, UMTS QoS-Profil, TFT (Abbildung für Downlink), APN und Anwendungsserver-IP-Adresse, die durch diese Anwendung zu verwenden sind.
Obwohl die Erfindung unter Bezugnahme auf bevorzugte Ausführungsbeispiele beschrieben wurde, ist die Beschreibung nur eine Veranschaulichung der Erfindung und soll die Erfindung nicht einschränken.

Claims

Paketdatennetzwerksystem zum Lenken von Paketen, die zu verschiedenen Dienstgüteflüssen gehören, mit einer mobilen Teilnehmereinrichtung zum Initiieren von Anwendungen mit zugehörigen Dienstgüteflüssen in einer Mehrfachsitzungsverbindung, gekennzeichnet durch eine Konfigurationseinrichtung zum Erhalten von Einstellungen eines Netzwerkknotens für jede initiierte Anwendung, der die Anwendung betreibt, und zum Bereitstellen von Konfigurationsinformationen beruhend auf diesen Einstellungen für die mobile Teilnehmereinrichtung, und einen Gateway-Knoten zum Austauschen von Paketen zwischen dem Netzwerksystem und der mobilen Teilnehmereinrichtung, wobei die mobile Teilnehmereinrichtung zum Bereitstellen der Konfigurationsinformationen für den Gateway-Knoten eingerichtet ist, und der Gateway-Knoten zum Lenken der Pakete entsprechend den Konfigurationsinformationen eingerichtet ist.
System nach Anspruch 1, wobei die Konfigurationsinformationen Dienstgüteparameter umfassen, die einen Dienstgütefluss definieren.
System nach Anspruch 1, wobei die Konfigurationsinformationen Filter für Uplink und Downlink umfassen.
System nach Anspruch 1, wobei die Konfigurationsinformationen durch die Anwendung zu verwendende Parameter umfassen.
System nach Anspruch 1, wobei die Einstellungen Dienstartinformationen umfassen.
System nach Anspruch 1, wobei die Konfigurationseinrichtung ferner zum Herleiten der Konfigurationsinformationen auf der Grundlage der Betreiberstrategie eingerichtet ist.
System nach Anspruch 1, wobei der erforderliche Dienstgütefluss durch die Anwendung direkt bestimmt wird.
System nach Anspruch 1, wobei die Konfigurationseinrichtung ferner zum Erhalten von Einstellungen der mobilen Teilnehmereinrichtung für jede initiierte Anwendung und zum Bereitstellen von Konfigurationsinformationen beruhend auf diesen Einstellungen für die mobile Teilnehmereinrichtung eingerichtet ist, und die mobile Teilnehmereinrichtung zum Senden von Paketen zu dem Netzwerksystem für jede initiierte Anwendung entsprechend den Konfigurationsinformationen eingerichtet ist.
System nach Anspruch 1, wobei die Einstellungen des Netzwerkknotens, der die Anwendung betreibt, durch einen Betreiber des Netzwerkknotens bestimmt werden.
System nach Anspruch 1, wobei die Einstellungen einer Anwendung fest sind.
System nach Anspruch 1, wobei die Einstellungen einer Anwendung durch einen Betreiber bestimmt werden.
System nach Anspruch 1, wobei dann, wenn der Gateway-Knoten zum Lenken der Pakete auf der Grundlage der Einstellungen des betreibenden Netzwerkknotens eingerichtet ist, die Konfigurationseinrichtung zum Bereitstellen der Konfigurationsinformationen für die mobile Teilnehmereinrichtung über eine Einzelsitzungsverbindung von der mobilen Teilnehmereinrichtung zum dem betreibenden Netzwerkknoten eingerichtet ist.
System nach Anspruch 1, ferner mit e inem Randnetzwerkknoten, der zum Ändern der Einstellungen eines betreibenden Netzwerkknotens eingerichtet ist, wobei die Konfigurationseinrichtung zum Erhalten von Einstellungen des Randnetzknotens und zum Bereitstellen von Konfigurationsinformationen beruhend auf den Randnetzwerkknoteneinstellungen eingerichtet ist.
Konfigurationseinrichtung zum Unterstützen einer Abbildung von Paketen auf Dienstgüteflüsse in einem Paketdatennetzwerksystem, mit einer Einrichtung zum Erhalten von Einstellungen eines Netzwerkknotens für jede durch eine mobile Teilnehmereinrichtung initiierte Anwendung mit einem zugehörigen Dienstgütefluss in einer Mehrfachsitzungsverbindung, wobei der Netzwerkknoten die Anwendung betreibt, und einer Einrichtung zum Bereitstellen von Konfigurationsinformationen beruhend auf diesen Einstellungen für die mobile Teilnehmereinrichtung, um der mobilen Teilnehmereinrichtung die Abbildung von Einstellungsinformationen auf den zugehörigen Dienstgütefluss zu ermöglichen.
Konfigurationseinrichtung nach Anspruch 14, ferner mit einer Einrichtung zum Herleiten der Konfigurationsinformationen auf der Grundlage der Betreiberstrategie.
Konfigurationseinrichtung nach Anspruch 14, ferner mit einer Einrichtung zum Erhalten von Einstellungen der mobilen Teilnehmereinrichtung für jede initiierte Anwendung und zum Bereitstellen von Konfigurationsinformationen beruhend auf diesen Einstellungen für die mobile Teilnehmereinrichtung, um der mobilen Teilnehmereinrichtung das Senden von Paketen zu dem Netzwerksystem für jede initiierte Anwendung entsprechend den Konfigurationsinformationen zu ermöglichen.
Konfigurationseinrichtung nach Anspruch 14, wobei dann, wenn ein Gateway-Knoten zum Lenken von Paketen auf der Grundlage der Einstellungen des betreibenden Netzwerkknotens eingerichtet ist, die Konfigurationseinrichtung eine Einrichtung zum Bereitstellen der Konfigurationsinformationen für die mobile Teilnehmereinrichtung über eine Einzelsitzungsverbindung von der mobilen Teilnehmereinrichtung zu dem betreibenden Netzwerkknoten umfasst.
Konfigurationseinrichtung nach Anspruch 14, ferner mit einer Einrichtung zum Erhalten von Einstellungen eines Randnetzwerkknotens, der zum Ändern der Einstellungen eines betreibenden Netzwerkknotens eingerichtet ist, und zum Bereitstellen von Konfigurationsinformationen beruhend auf den Randnetzwerkknoteneinstellungen.
Verfahren zum Lenken von Paketen, die zu verschiedenen Dienstgüteflüssen gehören, in einem Paketdatennetzwerksystem, gekennzeichnet durch die Schritte Erhalten von Einstellungen eines Netzwerkknotens für jede durch eine mobile Teilnehmereinrichtung initiierte Anwendung mit zugehörigen Dienstgüteflüssen in einer Mehrfachsitzungsverbindung, wobei der Netzwerkknoten die Anwendung betreibt, Bereitstellen von Konfigurationsinformationen beruhend auf diesen Einstellungen für die mobile Teilnehmereinrichtung, Bereitstellen der Konfigurationsinformationen für einen Gateway-Knoten zum Austauschen von Paketen zwischen dem Netzwerksystem und der mobilen Teilnehmereinrichtung, und Lenken der Pakete entsprechend den Konfigurationsinformationen.
Verfahren nach Anspruch 19, ferner mit den Schritten Erhalten von Einstellungen der mobilen Teilnehmereinrichtung für jede initiierte Anwendung und Bereitstellen von Konfigurationsinformationen beruhend auf diesen Einstellungen für die mobile Teilnehmereinrichtung, wobei Pakete von der mobilen Teilnehmereinrichtung zu dem Netzwerksystem für jede initiierte Anwendung entsprechend den Konfigurationsinformationen gesendet werden.