-
HINTERGRUND
DER ERFINDUNG
-
Die Erfindung bezieht sich auf Verfahren
und Einrichtungen zur Abbildung von Datenpaketen von einer ersten
Vielzahl von Datenflüssen
in einem ersten Kommunikationssubsystem auf eine zweite Vielzahl
von Datenflüssen
in einem zweiten Kommunikationssubsystem. Insbesondere bezieht sich
die Erfindung auf ein Verfahren gemäß dem Oberbegriff von Anspruch
1, auf ein Netzelement gemäß dem Oberbegriff
von Anspruch 17, auf ein von einer Mobilstation erzeugtes digitales
Konfigurationssignal gemäß dem Oberbegriff
von Anspruch 18 und auf eine Mobilstation gemäß dem Oberbegriff von Anspruch
19. Die Verarbeitung von Datenpaketen ist beispielsweise in der
WO 99/16266, der WO 99/05828, der GB-A-2312592, der
EP 0774848 , der WO 97/36405 und der
WO 98/28938 offenbart.
-
Für
die GPRS (General Packet Radio Service) Phase 2 und UMTS(Universal
Mobile Telecommunications System)-Systeme ist eine umfangreichere
QoS-Unterstützung
erforderlich. Zu diesem Zweck müssen QoS-bezogene
Informationen an den Netzgrenzelementen aufrechterhalten werden,
beispielsweise an einer Mobilstation (MS) und einem GGSN (Gateway
GPRS Support Node).
-
Gegenwärtig ist es nicht möglich, Informationen
zu transformieren, die zur Durchführung einer QoS-Abbildung und
von Übersetzungsfunktionen
zwischen den externen Netz-QoS-Einrichtungen
und den mobilnetzspezifischen QoS-Einrichtungen erforderlich sind. Das
heißt,
dass lediglich eine sehr statische QoS-Übersetzung durch die Mobilnetz- Grenzknoten ausgeführt werden
kann. Zur Bereitstellung verschiedener QoS-Werte für verschiedene
Anwendungen (wie Echtzeit- oder Nicht-Echtzeit-Multimedia, Dateiübertragung,
Hintergrund-E-Mail-Transfer usw.) sind Einrichtungen zum Aufrechterhalten
konsistenter Informationen an der Mobilstation und den GGSN-Knoten
erforderlich.
-
Aus den GPRS-/UMTS-Netzen ist keine
Lösung
für dieses
Problem bekannt. Für
das Internet gibt es verfügbare
Einrichtungen, die zum Transportieren von QoS- oder flussspezifischen
Informationen verwendet werden können.
Allerdings werden diese Informationen durch jeden Knoten entlang
des durchgehenden Übertragungswegs
und nicht nur durch die Endpunkte (die MS und den GGSN) interpretiert.
-
KURZZUSAMMENFASSUNG
DER ERFINDUNG
-
Eine Aufgabe der Erfindung ist die
Bereitstellung einer Einrichtung zum Ermöglichen einer dynamischeren
QoS-Bereitstellung
für individuelle
Applikationen: Diese Aufgabe wird durch ein Verfahren und eine Einrichtung
gelöst,
die durch die beigefügten
unabhängigen
Patentansprüche
charakterisiert sind. Bevorzugte Ausführungsbeispiele der Erfindung
sind in den beigefügten
abhängigen
Ansprüchen
offenbart.
-
Die Erfindung beruht auf der Einsicht,
dass QoS-Abbildungsinformationen
zwischen den GPRS-/UMTS-Netzgrenzen übertragen werden müssen. Das
heißt,
die Erfindung stellt eine Einrichtung zur Abbildung mehrerer Downlink-
(an der Mobilstation beendet) IP-Flüsse (IPflow1, ... IPflown)
mit verschiedenen QoS-Anforderungen für GPRS- (oder UMTS-...) Flüsse bereit.
Die letztgenannten Flüsse
sind durch PDP(Packet Data Protocol)-Kontexte (PDP1 ... PDPm) oder
QoS-Profile (QoSpl ... QoSm) innerhalb eines die Anforderung erfüllenden
Profils definiert. Die grundlegende Idee der Erfindung besteht darin,
dass zumindest für
einige Datenflüsse
(wie Echtzeitapplikationen) die im Grenzknoten (das heißt, dem
GGSN) durchgeführte
Abbildung auf einer Filterung beruht, die (durch Auswahl oder Modifikation)
von einem Benutzer/Terminal konfigurierbar ist. Ein derartiges Filter
kann als Satz vorbestimmter Parameter und/oder Bedingungen implementiert werden,
die zum Identifizieren von Paketen oder Datenflüssen verwendet werden. Ein
Filter für
eine Mobilstation sollte zumindest die IP-Adresse der in Frage kommenden
Mobilstation umfassen. Die IP-Adresse der Mobilstation ist aus dem
PDP-Kontext-Datensatz bekannt, und sie muss nicht in der Filterspezifikation
zwischen der MS und dem GGSN übertragen
werden. (In seltenen Fällen
kann eine Mobilstation mehr als eine IP-Adresse haben). Außerdem kann
das Filter beliebige Daten umfassen, die zum Identifizieren von
Datenpaketen verwendet werden können,
die eine gewisse QoS erfordert, und die daher auf bestimmte PDP-Kontexte
multiplext werden sollten, wie eine Source Address, ein RSVP Flow
Identifier, eine Port Number (beispielsweise die verwendete TCP-
oder UDP-Anschlussnummer),
ein Upper layer protocol (beispielsweise UDP, RTP, usw.), ein Type
of Service- (IPv4), ein Connection Type- (IPv6) und/oder ein Traffic-Class-Feld
(IPv6). Das Filter kann auch den IP-Adressraum umfassen, um Paketen
von einem gemeinsamen Netz (beispielsweise einem Intranet) eine
höhere
QoS als Paketen vom üblichen
Internet zu geben.
-
Das erfindungsgemäße Filter wird zum Definieren
der Eigenschaften der IP-Flüsse
verwendet, die auf den in Frage kommenden GPRS- oder UMTS-Fluss
abzubilden sind. Das Terminal bzw. der Anschluss kann das Filter
steuern, das die Filterparameter in einem Informationselement identifiziert,
das beispielsweise in einer PDP- Kontextaktivierungs-
oder einer PDP-Kontextmodifikationsnachricht
enthalten sein kann. Das Filter kann auch in Verbindung mit einer
QoS-Profilaktivierung
oder -modifikation definiert/neu definiert werden.
-
Gemäß einem bevorzugten Ausführungsbeispiel
der Erfindung ist eine Vorgabe-QoS-Klasse definiert. Datenflüsse, die
mit keinem definierten Filter übereinstimmen,
werden auf diese Vorgabe-QoS-Klasse abgebildet.
-
Das durch die Erfindung gelöste Problem
ist für
die GPRS-Phase 2
und ihre zukünftige
Entwicklung, wie UMTS, relevant.
-
Gemäß einem Ausführungsbeispiel
sind QoS-Informationen für
das Profil/den Kontext im QoS-Profilinformationselement wie im GPRS
Phase 1 enthalten. Die Abbildungs- und Filterinformationen können im „Protokollkonfigurationsoptionen"-Informationselement,
in verkäuferspezifischen
Optionen oder in einem neuen Informationselement übertragen
werden, das zu diesem Zweck eingeführt und verwendet wird. Diese
Informationen können
Quellen- und/oder Ziel-IP-Adressen, verwendete TCP- und UDP-Anschlussnummern,
Protokollinformationen einer höheren
Schicht, möglicherweise
einen Secure Parameters Index (wenn IPSEC verwendet wird), unterschiedliche
Serviceparameter und RSVP-Filter und Flussspezifikationen oder andere
Identifizierer oder Parameter in den Paketen enthalten.
-
Ein anderes Dienstqualitäts-(QoS-)Profil
kann für
jede PDP-Adresse
angefordert werden. Beispielsweise können einige PDP-Adressen mit
E-Mail verbunden sein, das lange Antwortzeiten tolerieren kann.
Andere Applikationen, wie interaktive Applikationen, können keine
Verzögerung tolerieren,
und sie beanspruchen einen sehr hohen Durchsatzpegel. Diese unterschiedlichen
Anforderungen sind im QoS-Profil wiedergegeben. Liegt eine QoS-Anforderung über den
Möglichkeiten
eines PLMN (Public Land based Mobile Network), handelt das PLMN
das QoS-Profil so nah wie möglich
am angeforderten QoS-Profil aus. Die MS akzeptiert entweder das
ausgehandelte QoS-Profil oder deaktiviert den PDP-Kontext.
-
Ein Vorteil der Erfindung besteht
darin, dass die Netzelemente (wie die SGSN-Knoten und das Base Station
Subsystem) eines Paketfunknetzes nicht alle QoS-Einrichtungen der externen Netze (IP,
X.25 usw.) interpretieren müssen.
Statt dessen kann die Abbildung am Mobilstationsende konfiguriert
werden, und diese Konfiguration wird zu anderen Grenzknoten (das
heißt,
dem GGSN) des Paketfunknetzes transportiert. Somit muss nicht das
gesamte Paketfunknetz zum Unterstützen aller neuer QoS-Einrichtungen aktualisiert
werden.
-
Die erfindungsgemäße Einrichtung ist sehr grundlegend.
Das heißt,
sie ist in einer breiten Vielzahl von Situationen und Konfigurationen
anwendbar. Sie erlaubt einen flexiblen Zugriff, Konfiguration und
Verwendung der Filterinformationen in der GGSN-Datenbank. Die Verwendung
des erfindungsgemäßen Filters
ist vollkommen fall- und betreiberspezifisch. Der MS-Teilnehmer
erhält
Mittel, um den Gateway-Knoten an der mobilen/festen Netzgrenze anzugeben,
wie die verschiedenen Applikationen, Verbindungen, Flüsse und
anderen Attribute zu verarbeiten sind, und welche QoS im GPRS/UMTS-Netz
zum Transportieren der assoziierten Pakete verwendet werden sollte.
Vorzugsweise sollte der GGSN auch die anwendungs-/QoS/flussspezifischen Informationen
aufbewahren.
-
Ein weiterer Vorteil besteht darin,
dass die erfindungsgemäß übertragene
Fluss-/QoS-Spezifikation (das heißt, während der QoS-Profil-Errichtungsprozedur
oder bei der PDP-Kontextaktivierung oder in einer dedizierten Nachricht)
sehr flexibel ist. Sie kann Quellen- und Ziel-IP-Adressen, verwendete TCP- und UDP-Anschlussnummern,
Protokollinformationen der oberen Schicht, möglicherweise einen Secure Parameters
Index im Fall, dass IPSEC verwendet wird, unterschiedliche Serviceparameter
und RSVP-Filter und Flussspezifikationen enthalten, die alle zum
Identifizieren externer Anwendungen, Verwendungen und von Flüssen verwendet
werden, die auf bestimmte interne QoS-Klassen oder Kontexte abzubilden
sind. Ein Vorteil der Flexibilität besteht
darin, dass eine neue Anwendung nicht unbedingt einen neuen Fluss
im Paketfunknetz braucht. Statt dessen ermöglicht die Erfindung eine flexible
Neuverwendung vorhandener Flüsse
auf effiziente Art und Weise.
-
Alternativ dazu können Informationen statischer
konfiguriert werden, in welchem Fall keine dynamische Änderung
von Attributen möglich
ist. In diesem Fall konfiguriert der Betreiber statische Bedingungen
und eine Übersetzung
einer externen QoS in eine interne QoS, beispielsweise beruhend
auf den verwendeten TCP-/UDP-Anschlussnummern.
Eine weitere Option besteht darin, überhaupt keine QoS-Abbildungsfunktionen
und durchgängige
QoS auszubilden.
-
KURZBESCHREIBUNG
DER ZEICHNUNG
-
Die Erfindung wird nachstehend anhand
bevorzugter Ausführungsbeispiele
unter Bezugnahme auf die beiliegende Zeichnung näher beschrieben. Es zeigen:
-
1 die
Architektur eines bekannten GPRS-Netzes,
-
2 eine
bekannte GPRS-Übertragungsebene,
-
3 die
Zusammenarbeit zwischen verschiedenen Netzelementen,
-
4 einen
GGSN mit dem erfindungsgemäßen Filter,
-
5 die
Verwendung des erfindungsgemäßen Filters,
-
6 und 7 den Transport von Filterinformationen
jeweils in einer Kontextaktivierungs- oder Modifikationsprozedur,
und
-
8 und 9 zwei verschiedene Implementationen
zum Konfigurieren der Filterinformationen in dedizierten Nachrichten.
-
AUSFÜHRLICHE
BESCHREIBUNG DER ERFINDUNG
-
Wie es in den 1 und 2 gezeigt
ist, kann die Erfindung bei einem beliebigen Mobilkommunikationssystem
mit der Fähigkeit
einer Paketdatenübertragung
angewendet werden.
-
Der Ausdruck „Paketdatenprotokoll" (PDP) oder „PDP-Kontext", wie er hier verwendet
wird, soll sich allgemein auf einen beliebigen Zustand in einer
Mobilstation und in zumindest einem Netzelement oder Funktionalität beziehen,
wobei der Zustand einen Datenpaketübertragungsweg oder Tunnel
mit einem speziellen Satz von Parametern durch das Mobilkommunikationsnetz
bereitstellt. Der Ausdruck „Knoten" wie er hier verwendet
wird, soll sich allgemein auf ein beliebiges Netzelement oder eine
Funktionalität
beziehen, die die durch den PDP-Kanal übertragenen Datenpakete verarbeitet.
-
Die Erfindung kann insbesondere bevorzugt
zur Bereitstellung eines allgemeinen Paketfunkservice-GPRS im paneuropäischen digitalen
Mobilkommunikationssystem GSM oder in entsprechenden Mobilkommunikationssystemen,
wie DCS1800 (das auch als GSM1800 bekannt ist) und PCS (Personal
Communication System) verwendet werden. Im folgenden werden bevorzugte
Ausführungsbeispiele
der Erfindung anhand eines GPRS-Paketfunknetzes beschrieben, das
durch den GPRS-Service und das GSM-System gebildet wird, ohne die
Erfindung auf dieses besondere Paketfunksystem zu beschränken.
-
Die Erfindung ist gleichermaßen bei
mobilen Netzen der dritten Generation anwendbar, wie UMTS. In diesem
Fall wird die GSM-Luftschnittstelle durch eine UMTS-Luftschnittstelle
wie in 2 gezeigt ersetzt.
-
3 zeigt
die Zusammenarbeit zwischen verschiedenen Netzelementen. Nach diesen
Modifikationen kann eine Abbildung auf der Parameterstufe zwischen
verschiedenen Diensten und RSVP im Internet und im GPRS beispielsweise
wie folgt vorgesehen werden: Prioritätsinformationen über das
Internet werden im GPRS auf einen Service-Vorrang abgebildet. Eine
Angabe bezüglich
Echtzeit- gegenüber
Nicht-Echtzeit-Anforderungen im Internet wird auf eine Verzögerungsklasse
und/oder Zuverlässigkeitsinformationen
im GPRS abgebildet: zumindest zwei Verzögerungstypen sind erforderlich,
jedoch ist es auch möglich,
Verkehrstypen präziser
auf mehrere Verzögerungsklassen
abzubilden.
-
Zuverlässigkeitsinformationen können zur
Angabe der Zuverlässigkeitsanforderungen
jeder Anwendung in der Form einer oder von zumindest zwei Zuverlässigkeitsklassen
verwendet werden. Ist eine zuverlässige Übertragung (Neuübertragungen,
Prüfsummen
und/oder TCP) erforderlich, gibt das mit den Datenpaketen verbundene
Profil eine Zuverlässigkeitsklasse
1 an. Ist eine zuverlässige
Zustellung über
die Luftschnittstelle erforderlich, reicht aber UDP im GPRS-Backbone
aus, gibt das mit den Datenpaketen verbundene Profil eine Zuverlässigkeitsklasse
2 an. In Abhängigkeit
von diesen Anforderungen kann das mit den Datenpaketen verbundene
Profil alternativ Zuverlässigkeitsklassen
3, 4 oder 5 angeben. Die Zuverlässigkeitsklassen
4 und 5 werden für
einen Echtzeitverkehr verwendet.
-
Ein weiteres optionales Merkmal der
Erfindung ist eine Abbildung der im Mobilkommunikationsnetz verwendeten
QoS-Parameter auf
die bei einer Benutzeranwendung im Mobilpaketdatenanschluss verwendeten
oder die im externen Kommunikationssystem verwendeten und umgekehrt.
Die MS, die die Anforderungen der Anwendungen kennt, bestimmt die
entsprechenden QoS-Profilwerte, errichtet einen neuen PDP-Kontext für diese
Pakete und zeigt dem GGSN an, wie zu diesem Kontext gehörende Pakete
zu erkennen sind. Im folgenden werden zwei Beispiele der Abbildung
beschrieben.
-
Beispiel 1 (ein Beispiel, wie die
MS entscheiden kann, welche GPRS-Parameterwerte sie für den Kontext
wählt).
-
Simple Integrated Media Access (SIMA)
ist ein neuer einfacher Ansatz, der als Internet-Draft von K. Kilkki,
Nokia Research Center, Juni 1997, präsentiert wurde. Internet-Drafts
sind Arbeitsdokumente der Internet Engineering Task Force (IETF),
ihrer Gebiete und Arbeitsgruppen. SIMA wird als Beispiel eines Internet-QoS-Schemas verwendet,
da es ein gleichförmiges
Servicekonzept für
verschiedene Anforderungen von Dateiübertragungsanwendungen unter
Verwendung des TCP/IP-Protokolls
mit lockeren Verzögerungs-
und Paketverlustanforderungen bis zu Echtzeitanwendungen mit sehr
strengen Qualitäts-
und Verfügbarkeitsanforderungen
bereitstellt. Gemäß dem SIMA-Konzept
definiert jeder Benutzer lediglich zwei Dinge vor dem Verbindungsaufbau:
eine nominelle Bitrate (NBR) und eine Auswahl zwischen Echtzeit-
und Nicht-Echtzeit-Serviceklassen. Die NBR kann acht Werte von 0
bis 7 haben. Die Abbildung der Parameter von SIMA auf GPRS und umgekehrt
kann beispielsweise wie folgt aussehen:
Echtzeit-/Nicht-Echtzeit-Bit:
Gibt dieses Bit Echtzeitanforderungen an, wird es auf die GPRS Verzögerungsklasse
1 abgebildet, und sonst auf die Verzögerungsklasse 4. Allerdings
kann die Verzögerungsklasse
3 für Nicht-Echtzeit-Dienste
in einem Fall verwendet werden, wenn es eine spezielle Weise zur
Angabe eines Verkehrs nach bestem Bemühen gibt, beispielsweise muss
dieses Bit nicht immer vorhanden sein, oder es wird eine präzisere Definition
zur Unterscheidung von Echtzeit-, Nicht-Echtzeit- und Verkehr nach
bestem Bemühen verwendet.
Dem Echtzeit-Verkehr kann ein niedrigerer Zuverlässigkeitsklassenwert als dem
Nicht-Echtzeit-Verkehr
im GPRS zugeordnet werden. Im allgemeinen werden die Zuverlässigkeitsklassen
1, 2 und 3 für Nicht-Echtzeit-Verkehr
und die Klassen 3, 4 und 5 für
Echtzeit-Verkehr
im GPRS verwendet. Je höher
die NBR beim Nicht-Echtzeit-Verkehr
ist, desto geringer ist der geeignete Zuverlässigkeitsklassenwert für die Übertragung.
-
-
-
Für
die Parameter können
auch verschiedene Namen, wie Priorität oder Nominelle Bitrate und
Verkehrstyp gewählt
werden. Das QoS-Profil kann alle vorhandenen Parameter enthalten
(Servicevorrang, Zuverlässigkeitsklasse,
Verzögerungsklasse,
mittlere Bitrate und Spitzenbitrate). Alternativ dazu kann es lediglich
einige der Parameter enthalten, wie die mittlere und die Spitzenbitrate.
Das QoS-Profil könnte
auch einen Maximum-Signalbündelgröße-Parameter zur Erleichterung
der Pufferzuordnungsprozedur beinhalten.
-
Die QoS-Planung in GPRS-Netzelementen
(beispielsweise in einem SGSN und einem GGSN) beruht auf der Verzögerungsklasse.
Dies kann zumindest zwei Puffer erfordern: einen für Echtzeit-Pakete
(dieser Puffer sollte kleiner sein) und einen anderen für Nicht-Echtzeit-Pakete.
Echtzeit-Verkehr sollte immer vor Nicht-Echtzeit-Verkehr gesendet
werden. Der Service-Vorrang definiert die Reihenfolge, mit der Pakete
im Fall einer Netzstauung fallengelassen werden können.
-
Beispiel 2 (beschreibt, wie QoS-Werte
zu wählen
sind und ein spezielles Profil zur Unterstützung eines gegebenen differenzierten
Service-Codepunkts zu errichten ist, um geeignete QoS-Profilwerte
und einen differenzierten Service-Codepunktwert als Filterinformationen
zur Konfiguration des Filters auszubilden).
-
Abbildung eines Type-of-Service(ToS)-Oktetts
in den Headern der IP-PDUs (Packet Data Units) auf GPRS-Attribute.
Das ToS-Oktett in einem IP-Header ist im Moment nicht weit verbreitet.
Sein ursprünglicher Zweck
war die Aufnahme von Verkehrstypinformationen und die Bestimmung,
welche Serviceart von der Paketzustellung gefordert wird. Da das
ToS-Oktett heutzutage nicht allgemein verwendet wird, ist es möglich, die Bits
in diesem Oktett für
die Zwecke der Erfindung neu zu definieren. Eine Definition des
ToS-, Oktetts ist im RFC 791 beschrieben. Die Bits 0 bis 2 vom ToS
geben den Vorrang an, die Bits 3 bis 5 geben den vom Paket geforderten
ToS an (beispielsweise angeforderte Verzögerungs-, Durchsatz- und Zuverlässigkeitsstufen),
und die Bits 6 bis 7 sind für
eine zukünftige
Verwendung reserviert. RFC 1349 erweitert das ToS-Feld um ein Bit (das
aus den Bits „für die zukünftige Verwendung" genommen wird).
Somit können
vier Bits zur Angabe eines ToS verwendet werden.
-
Die Abbildung zwischen den Vorrangbits
(0 bis 2 bei ToS) und dem GPRS-Service-Vorrang kann folgendermaßen aussehen:
-
-
Es gibt drei verschiedene Arten,
die Abbildung zwischen den Verkehrstypinformationen (das heißt, ToS-Feld
im ToS-Oktett) und
der GPRS-Verzögerungsklasse
durchzuführen:
Wird lediglich Bit 3 im ToS-Feld zur Angabe der Verzögerungsanforderungen
im IP-Header verwendet: der Wert 0 von Bit 2 wird auf die GPRS-Verzögerungsklasse
1 oder 2 abgebildet, und der Wert 1 von Bit 2 wird auf die GPRS-Verzögerungsklasse
4 (nach bestem Bemühen)
abgebildet.
-
Wird das gesamte ToS-Feld im ToS
zur Angabe von Verzögerungsanforderungen
verwendet, das heißt,
4 Bits (Bits 3-6) sind für
diesen Zweck verfügbar,
könnte
eine mögliche
Abbildung folgende sein: der Bitwert 1000 wird auf die GPRS-Verzögerungsklasse
1 abgebildet (das heißt,
auf den Bitwert 000), der Bitwert 0100 auf die GPRS-Verzögerungsklasse
2 (das heißt,
auf den Wert 001), die ToS-Werte 0010 und 0001 auf die GPRS-Verzögerungsklasse
3 (das heißt,
auf den Wert 010), und der ToS-Wert 0000 auf die GPRS-Verzögerungsklasse
4 (das heißt,
den Wert 011).
-
Eine andere Möglichkeit der Abbildung der
IP-ToS-Bits auf die GPRS-Verzögerungsklassen
wäre folgender:
11x auf die Verzögerungsklasse
1, 10x auf die Verzögerungsklasse
2, 01x auf die Verzögerungsklasse 3
und 00x auf die Verzögerungsklasse
4. In diesem Fall bedeutet x, dass hier ein oder mehrere zusätzliche Bits
stehen können,
die für
ToS verwendet werden, die jedoch keinen Einfluss auf den Prozess
der Auswahl der GPRS-Verzögerungsklasse
haben. Werden später
mehr Verzögerungsklassen
für GPRS
definiert, könnte diese
Abbildung auch diese zusätzlichen
Bits in Betracht ziehen.
-
Gegenwärtig gibt es auch ein Bit im
IP-ToS-Feld, das die gewünschte
Zuverlässigkeitsstufe
bestimmt. Ist dieses Bit in der Zukunft immer noch verfügbar, beispielsweise,
wenn die vorstehende erste Wahl ausgewählt wird, könnte dieses Bit Zuverlässigkeitsinformationen
tragen und auf die GPRS-Zuverlässigkeitsklasse auf
folgende Weise abgebildet werden: ein Wert 0 im Bit 5 im ToS-Oktett
wird auf die Zuverlässigkeitsklasse 000
abgebildet (gebilligte Zuverlässigkeitsklasse)
und ein Wert 1 wird auf die Zuverlässigkeitsklasse 001 abgebildet
(was den zuverlässigsten
Service definiert). Die Verwendung dieses Bits kann allerdings zu
vage sein, da GPRS auch viele andere Zuverlässigkeitsstufen definiert,
und dies nicht unter Verwendung lediglich eines Bits ausgedrückt werden
kann.
-
Gemäß einem bevorzugten Ausführungsbeispiel
der Erfindung wird eine Vorgabe-QoS-Klasse definiert, und Datenflüsse, die
mit keinem Abbildungskriterium übereinstimmen,
das durch das (die) Filter definiert ist, werden auf die Vorgabe-QoS-Klasse
abgebildet.
-
Die vorstehend im Beispiel 2 beschriebene
Abbildung kann auf ziemlich ähnliche
Weise bei IPv6 angewendet werden. Der Name des geeigneten Feldes
ist dann Traffic Class anstelle von ToS.
-
3 zeigt
die Arbeitsweise einer GPRS-Mobilstation und von GPRS-Netzelementen,
sowie eine Integration mit externen Netz-QoS-Konzepten. Die MS oder
die Software in der Anschlusseinrichtung TE (beispielsweise ein
Laptopcomputer) stellt die Abbildung von externen Netz-QoS-Anforderungen
auf GPRS-QoS-Einrichtungen bereit. Die TE könnte beispielsweise QoS-Verwaltungsfunktionen über eine
Application Programming Interface (API) bereitstellen. Die Software
auf Applikationsstufe kann QoS-Informationen oder eine Profilkennzeichnung
in die Datenpakete einfügen,
beispielsweise in den IP-Header selbst, oder kann den korrekten
Fluss angeben, zu dem das Paket gehört, indem eine andere geeignete
Einrichtung verwendet wird. Sie kann auch RSVP zum Führen der
erforderlichen Informationen über
geeignete Abbildungsschichten in niedrigere Schichten verwenden.
Die Software der MS kann alternativ das QoS-Profil beispielsweise beruhend auf den
nicht verwendeten Quellen- und Ziel-IP-Adressen oder den Quellen-
und Zielanschlussnummern oder beruhend auf anderen in der MS konfigurierten
Informationen entscheiden.
-
Für
an der Mobilstation entstehende Daten (MO-Daten) plant die MS Datenpakete
beruhend auf den von der Anwendung oder von der GPRS-Protokollreihe
in der Anschlusseinrichtung empfangenen QoS-Informationen. Die MS
plant die MO-Pakete entsprechend ihrer Verzögerungsklasse. Auf der SNDC-Schicht
wählt die
MS den geeigneten LLC SAP (Service Access Point) aus, der durch
den SGSN während
der PDP-Kontextaktivierung oder -modifikation angegeben wird.
-
4 zeigt
einen GGSN mit dem erfindungsgemäßen Filter.
Der GGSN empfängt
an der MS ankommende Datenpakete von einer Vielzahl von Quellen,
die insgesamt als Service Provider SP bezeichnet werden. 4 zeigt drei typische Service
Provider bzw. Dienstanbieter: einen Internet Service Provider ISP
zur Bereitstellung eines Zugangs zum Internet; einen Company Network
Server CNS zur Bereitstellung eines Zugangs zu geschlossenen Bereichen
des Internets, die allgemein Intranets oder Extranets genannt werden;
und Content Providers CP zur Bereitstellung eines Zugangs zu verschiedenen
Unterhaltungs- und Nachrichtendiensten, wie Video-auf-Abruf, usw.
-
Der GGSN umfasst einen Scheduler/Translator
ST. Wie sein Name schon sagt, plant er die Übertragung von Paketen auf
der Grundlage der Netzbelastung, Paketpriorität, Ankunftszeit, usw. Der Schedule-Teil des
ST ist dem geneigten Leser weitgehend bekannt.
-
Der Übersetzungsteil des ST macht
vom erfindungsgemäßen Filter
Gebrauch. Er bildet Datenpakete von den IP-Netzen (Elemente 11 und 12 in 1) auf das Paketfunknetz
(Element 13 in 1)
ab. Die Erfindung liefert eine Lösung
für eine
Situation, in der mehrere Anwendungen und Datenflüsse sich
eine gemeinsame IP-Adresse teilen, aber verschiedene QoS-Werte erfordern.
-
5 zeigt
die Verwendung des erfindungsgemäßen Filters
FI am GGSN. In Schritt 5-1 empfängt
der GGSN ein an eine gegebene Mobilstation MS adressiertes Datenpaket.
Der GGSN liest die IP-Adresse der MS aus dem entsprechenden Protokollzähler und
verwendet das Filter FI zur Bestimmung des entsprechenden PDP-Kontexts
oder QoS-Profils. Die MS-IMSI
kann aus der Ziel-IP-Adresse der Pakete bestimmt werden. In Schritt
5-1 erhält
der GGSN den entsprechenden Tunnel Identifier TID. Als nächstes sendet
der GGSN in Schritt 5-3 das Datenpaket über den SGSN zur MS über diesen
bestimmten Kontext, der mit einer geeigneten QoS für dieses
Paket verbunden ist.
-
6 zeigt,
wie eine Mobilstation die QoS-Abbildung und Zusammenarbeitsvorgänge mittels
einer Kontextaktivierungsprozedur gemäß der Erfindung konfigurieren
kann. In Schritt 6-1 sendet die MS dem SGSN einen Activate PDP Context
Request mit einem NSAPI, einem PDP-Typ, einer PDP-Adresse, einem
Access Point Name, QoS Requested, einer Filterspezifikation und
PDP-Konfigurationsoptionen.
(Zum Verständnis
der Erfindung: die wichtigen Parameter sind die Filter- und QoS-Informationen). Die
MS kann die PDP-Adresse zur Angabe verwenden, ob sie die Verwendung
einer statischen oder einer dynamischen PDP-Adresse erfordert. Im
zweiten Fall soll die MS die PDP-Adresse leer lassen. Die MS kann
den Access Point Name zur Auswahl eines Bezugspunkts auf ein bestimmtes
externes Netz verwenden. Der Access Point Name ist ein logischer Name,
der sich auf das externe Paketdatennetz bezieht, mit dem der Teilnehmer
eine Verbindung wünscht. QoS
Requested gibt das gewünschte
QoS-Profil an. Die
Filter-Spezifikation gibt an, welche externen Datenpakete mit einem
bestimmten PDP-Kontext verbunden sind. Durch die Filterbedingungen
dieses Filters angegebene Pakete sollten derart betrachtet werden,
als ob sie zu diesem bestimmten PDP-Kontext gehörten. PDP-Konfigurationsoptionen können zur
Anforderung optionaler PDP-Parameter vom GGSN verwendet werden (siehe
GSM-Empfehlung 09.60).
PDP-Konfigurationsoptionen werden transparent durch den SGSN gesendet.
-
Die Verwendung einer dynamischen
Konfiguration und dynamischer PDP-Adressen beinhaltet das Problem,
wie sicherzustellen ist, dass die Kontextaktivierung den korrekten
GGSN betrifft, und wie der GGSN weiß, ob ein neuer Kontext mit
der gleichen IP-Adresse oder einer anderen Adresse zu aktivieren
ist. Es gibt drei Lösungen
für dieses
Problem:
- 1. Verwenden eines Access Point Name,
der auf einen bestimmten GGSN-Knoten zeigt und angibt, dass ein
anderer Kontext erforderlich ist, und Verwenden der gleichen IP-Adresse.
- 2. Hinzufügen
einer Angabe (wie eines neuen Informationselements) zu der Kontextaktivierungsanforderung,
die dem GGSN (und dem SGSN) angibt, dass ein anderer Kontext erforderlich
ist. Dieser Kontext hat die gleiche IP-Adresse wie der vorhergehende.
In diesem Fall wählt
der SGSN den gleichen GGSN wie für den
vorhergehenden Kontext dieses PDP-Typs.
- 3. Hinzufügen
der für
den Kontext gewünschten
PDP- und IP-Adressen
zur Kontextaktivierungsanforderungsnachricht. Diese PDP/IP-Adresse
kann einem der vorhergehenden Kontexte gegeben sein, das heißt, eine
dynamische Adresse. In diesem Fall wählt der SGSN den GGSN aus,
der die bestimmte Adresse verarbeitet.
-
In Schritt 6-2 können Sicherheitsfunktionen
durchgeführt
werden, sie sind aber zum Verständnis
der Erfindung nicht relevant.
-
In Schritt 6-3 validiert der SGSN
die Anforderung 6-1. Der SGSN erzeugt einen Tunnel Identifier TID für den angeforderten
PDP-Kontext durch Kombinieren der im MM-Kontext gespeicherten IMSI und der von der
MS empfangenen NSAPI. Der SGSN kann die angeforderten QoS-Attribute
hinsichtlich seiner Fähigkeiten, der
aktuellen Belastung und des zugesicherten QoS-Profils einschränken. Als
nächstes
sendet der SGSN in Schritt 6-3 einen Create PDP Context Request
(mit einem PDP-Typ, einer PDP-Adresse, einem Access Point Name,
den ausgehandelten QoS-Profilen, dem gewünschten Filter, dem TID und
den PDP-Konfigurationsoptionen)
zum GGSN. Der GGSN kann die angeforderten QoS-Attribute hinsichtlich
seiner Fähigkeiten
und der aktuellen Belastung gleichermaßen einschränken. Fordert die MS eine dynamische
Adresse an, veranlasst der SGSN einen GGSN zur Zuordnung der dynamischen
Adresse. Der SGSN kann die angeforderten QoS-Attribute hinsichtlich
seiner Fähigkeiten,
der aktuellen Belastung und des zugesicherten QoS-Profils einschränken. Der
SGSN sendet einen Create PDP Context Request(PDP-Typ, PDP-Adresse,
Access Point Name, ausgehandelte QoS, Filterspezifikation, TID,
Auswahlmodus, PDP-Konfigurationsoptionen)-Nachricht zu dem betroffenen
GGSN. Der Access Point Name ist der APN-Netzidentifizierer des ausgewählten APN.
Die PDP-Adresse soll leer sein, wenn eine dynamische Adresse angefordert
wird. Der GGSN kann den Access Point Name zum Senden eines externen
Netzes verwenden. Der 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 bei der Entscheidung verwenden,
ob er eine PDP-Kontextaktivierung annimmt oder ablehnt. Erfordert
ein APN beispielsweise die Teilnahme, ist der GGSN zur Annahme lediglich
der PDP-Kontextaktivierung
konfiguriert, die einen teilnehmenden APN anfordert, was durch den
SGSN mit dem Auswahlmodus angegeben ist. Der SGSN erzeugt einen
neuen Eintrag in seiner PDP-Kontexttabelle und erzeugt eine Abrechnungs-ID.
Der neue Eintrag ermöglicht
dem GGSN das Routen von PDP-PDUs
zwischen dem SGSN und dem externen PDP-Netz und das Starten der Abrechnung.
Der GGSN kann ferner die ausgehandelte QoS unter Berücksichtigung
seiner Fähigkeiten
und der aktuellen Belastung einschränken. Der GGSN hält Informationen
für eine
QoS-Abbildung und zum Multiplexen ankommender Datenpakete von dem
externen Netz auf die aktivierten PDP-Kontexte gemäß den definierten
Filterbedingungen am GGSN aufrecht. Für abgehende Pakete kann eine
bestimmte externe QoS mit den Paketen eines bestimmten PDP-Kontextes
verbunden sein. Der GGSN gibt dann eine Create PDP Context Response(TID,
PDP-Adresse, BB-Protokoll,
Reordering Required, PDP-Konfigurationsoptionen, QoS Negotiated,
Charging Id, Cause)-Nachricht zum SGSN zurück. Die PDP-Adresse ist enthalten,
wenn der GGSN eine zuweist. Das BB-Protokoll gibt an, ob TCP oder
UDP zum Transportieren von Benutzerdaten im Backbone-Netz zwischen
dem SGSN und dem GGSN zu verwenden ist. Reordering Required gibt
an, ob der SGSN die N-PDUs vor der Zufuhr der N-PDUs zur MS neu
ordnen sollte. Die PDP-Konfigurationsoptionen enthalten optionale
PDP-Parameter, die der GGSN zur MS übertragen kann. Diese optionalen
PDP-Parameter können von
der MS in der Activate-PDP-Context-Request-Nachricht angefordert
werden, oder können
vom GGSN unaufgefordert gesendet werden. Die PDP-Konfigurationsoptionen
werden durch den SGSN transparent gesendet. Die Create-PDP-Context-Nachrichten
werden über
das GPRS-Backbonenetz gesendet. Ist das vom SGSN empfangene QoS-Negotiated-Netz
zum aktivierten PDP-Kontext inkompatibel (beispielsweise ist die Zuverlässigkeitsklasse
zur Unterstützung
des PDP-Typs unzureichend),
lehnt der GGSN die Create-PDP-Context-Request-Nachricht ab. Die kompatiblen
QoS-Profile können
vom GGSN-Betreiber konfiguriert werden.
-
In Schritt 6-4 gibt der GGSN eine
Create-PDP-Context Response (mit einer TID, einer PDP-Adresse, den
ausgehandelten QoS-Profilen und PDP-Konfigurationsoptionen) zum
SGSN zurück.
Der SGSN fügt
die NSAPI mit der GGSN-Adresse
in den PDP-Kontext ein. Hat die MS eine dynamische Adresse angefordert,
wird die vom GGSN empfangene PDP-Adresse
in den PDP-Kontext eingefügt.
Der SGSN wählt
beruhend auf QoS Negotiated eine Radio Priority aus und gibt eine
Activate PDP Context Accept (PDP-Typ, PDP-Adresse, TI, QoS Negotiated,
Radio Priority, PDP-Konfigurationsoptionen)-Nachricht
zur MS zurück.
Der SGSN kann nun PDP-PDUs zwischen dem GGSN und der MS routen und
die Abrechnung starten.
-
Als nächstes wählt der SGSN in Schritt 6-5
eine Radio-Priority-Stufe
beruhend auf jedem ausgehandelten QoS-Profil aus und gibt eine Activate
PDP Context Accept (mit einem PDP-Typ, einer PDP-Adresse, NSAPI,
den ausgehandelten QoS-Profilen,
einer Radio Priority-Stufe und einer SAPI für jedes QoS-Profil, den Filter-
und PDP-Konfigurationsoptionen)-Nachricht
zur MS zurück.
Nun kann der SGSN PDP-PDUs zwischen dem GGSN und der MS routen.
SAPI gibt an, welches QoS-Profil welche SAPI verwendet.
-
7 zeigt
eine Kontextmodifikationsprozedur. In Schritt 7-1 sendet die MS
dem SGSN eine Modify-PDP-Context- Anforderung.
In Schritt 7-3 sendet der SGSN dem GGSN eine Update-PDP-Context-Anforderung.
Beide Anforderungen umfassen das Filter mit modifizierten Parametern.
Das Filter gibt an, welche externen Datenpakete mit einem bestimmten
PDP-Kontext verbunden sind. Durch die Filterbedingungen angegebene
Pakete sollten so interpretiert werden, als ob sie zu diesem PDP-Kontext
gehörten
und sie sollten mit der für
den Kontext ausgehandelten QoS versehen werden. Die Update-PDP-Context-Request-Nachricht
wird zum Hinzufügen,
Modifizieren oder Löschen
eines QoS-Profils eines PDP-Kontexts verwendet. Empfängt der GGSN
vom SGSN eine ausgehandelte QoS, die mit dem modifizierten PDP-Kontext
inkompatibel ist (beispielsweise ist die Zuverlässigkeitsklasse zur Unterstützung des
PDP-Typs unzureichend), lehnt der GGSN die Anforderung ab. Kompatible
QoS-Profile werden vom GGSN-Betreiber
konfiguriert. Der GGSN kann wiederum die angeforderten QoS-Attribute
hinsichtlich seiner Fähigkeiten
und der aktuellen Belastung beschränken. Der GGSN speichert die
ausgehandelten QoS-Werte. Der GGSN überarbeitet die QoS-Abbildungsinformationen, damit
sie mit den neuen Filterspezifikationen und dem ausgehandelten QoS-Profil
(das in der Anforderungsnachricht enthalten ist) übereinstimmen.
In den Schritten 7-4 und 7-5 wird eine positive Antwort zur MS zurückgegeben.
-
Grundversionen der Nachrichten 7-1
bis 7-5 sind aus GPRS Phase 2 bekannt. Erfindungsgemäß sind die
Nachrichten 7-1 und 7-3 zum Tragen der gewünschten Filterparameter modifiziert
(und die Nachrichten 7-4 und 7-5 sind zur Rückgabe einer geeigneten Bestätigung modifiziert).
-
Gemäß einem anderen Ausführungsbeispiel
der Erfindung kann die Filterfunktion in einer ersten Richtung (beispielsweise
Downlink) unter Verwendung von Informationen modifiziert werden,
die in den in der zweiten Richtung (beispielsweise Uplink) gesendeten
Paketen enthalten sind. Dieses Ausführungsbeispiel erfordert keine
Extrasignalisierung. Gemäß diesem
Ausführungsbeispiel
sind folgende Verkehrsklassen definiert (RT = Echtzeit, NRT = Nicht-Echtzeit):
-
-
Konversations- und Streaming-Klassen
sind echtzeitorientierte Verkehrsklassen, für die Ressourcen reserviert
sind. Interaktive und Background-Klassen sind Best-Effort-Klassen,
die keine reservierten Ressourcen haben. Für diese Klassen kann eine GPRS-Typ-Ressourcen-Zuordnung verwendet
werden, das heißt,
die MS sendet bei Bedarf Funkressourcenanforderungen.
-
Für
die Echtzeitklassen, das heißt,
die Konversations- und Streaming-Klassen, ist das vorstehend beschriebene
Verfahren sehr effizient, das heißt, die Filterinformationen
werden in PDP-Kontextoperationen zum GGSN geführt, so dass der GGSN ankommende
IP-Pakete auf die korrekte QoS-Klasse abbilden kann. Allerdings
ist damit bei interaktiven und Background-Klassen ein großer Signalisierungsaufwand
verbunden, der in manchen Situationen nicht akzeptabel sein kann.
Ein Beispiel einer derartigen Situation ist eine zu einem Domain
Name Server DNS (nicht gezeigt) gesendete Abfrage, wobei in diesem
Fall der Netzfluss aus lediglich zwei Paketen bestehen kann.
-
In diesem Beispiel wird die interaktive
Klasse als Vorgabe-QoS-Klasse
ausgewählt.
Das heißt,
dass beim Fehlen von Informationen über die QoS-Anforderung eines
ankommenden Flusses, oder bei Nichtübereinstimmen der Flussinformationen
mit den Filterbedingungen die interaktive Klasse ausgewählt wird.
Außerdem
können
zur Hintergrundklasse gehörende
Flüsse
durch den GGSN „unterwegs" identifiziert werden.
Das heißt,
dass beim Empfang eines Pakets von der MS in der Hintergrund-Klasse
durch den GGSN dieser die Flussidentifizierungsinformationen zur
Kenntnis nimmt und die mit der Hintergrundklasse verbundenen Filtereigenschaften
modifiziert, um den dem in Frage kommenden Fluss entsprechenden
Downlink-Fluss auf die Hintergrundklasse abzubilden. Kommt ein Paket
in der Downlink-Richtung, überprüft der GGSN
die mit der Hintergrundklasse verbundenen Flussidentifizierungsinformationen.
Stimmen die mit der Hintergrundklasse verbundenen Flussfilterinformationen
mit den Headerinformationen des empfangenen IP-Pakets überein, kommt
das Paket in die Hintergrundklasse.
-
Auf die Hintergrundklasse bezogene
Flussinformationen können
wie folgt verarbeitet werden. Die MS weiß um Flüsse, die unter Verwendung der
Hintergrundklasse ausgeführt
werden sollten. Der Benutzer kann diese Abbildung von Flüssen auf
die Hintergrundklasse konfigurieren. Beispielsweise kann der Benutzer
Dateiübertragungen
konfigurieren, damit sie die Hintergrundklasse verwenden, indem
eine geeignete Konfigurationsapplikation verwendet wird. Alternativ
dazu können
die Informationen beispielsweise aus einigen externen QoS-Informationen
(beispielsweise Internet-QoS-Informationen) erhalten werden. Das
heißt,
die MS hat Filterkriterien für
Flüsse
für deren
Abbildung auf die Hintergrundklasse. Ein wesentliches Merkmal dieses
Ausführungsbeispiels
besteht darin, dass die MS weiß,
welche Flüsse
auf die Hintergrundklasse gelegt werden sollten, und diese Pakete
zur entsprechenden Verbindung sendet. Empfängt der GGSN Pakete von der
MS, kennt er die QoS-Klasse, mit der die Pakete verbunden sind.
Erhält
der GGSN ein Paket der Hintergrundklasse, überprüft er, ob er bereits einen
Eintrag für
diesen Fluss in einer Liste (nicht gezeigt) hat, die Flussinformationen
aller zur Hintergrundklasse gehörenden
Flüsse
enthält.
Gibt es keinen Eintrag für
diesen Fluss in der Liste, modifiziert der GGSN das bei der Abbildung
der Downlink-Flüsse
auf die Hintergrundklasse verwendete Filter, so dass der Downlink-Fluss,
der dem Uplink-Fluss entspricht, zu dem das empfangene Paket gehört, auf
die Hintergrundklasse abgebildet wird. Dies kann durch Aufnahme
der Flussidentifikationsinformationen des Uplink-Pakets in die Flussinformationsliste
geschehen, anhand der die Downlink-Pakete auf die Hintergrundklasse
abgebildet werden. So werden zur Hintergrundklasse gehörende Flüsse im GGSN „unterwegs" identifiziert.
-
Empfängt der GGSN ein Paket vom
Internet oder von einem anderen externen Netz, überprüft er die mit den Konversations-,
Streaming- und Hintergrundklassen verbundenen Filterinformationen.
Findet der GGSN heraus, dass die Eigenschaften des Pakets mit den
relevanten Filterbedingungen übereinstimmen,
leitet er das Paket zur entsprechenden QoS-Klasse weiter. Gibt es
keinen Eintrag für
diesen bestimmten Fluss, wird das Paket zur interaktiven Klasse
weitergeleitet, die die Vorgabeklasse darstellt.
-
Dieses Ausführungsbeispiel verringert das
Signalisierungserfordernis drastisch, da die interaktive Klasse
die am häufigsten
verwendete QoS-Klasse ist. Es gibt viele Fälle, in denen IP-Pakete tatsächlich keinen Fluss
bilden, sondern statt dessen lediglich ein oder wenige IP-Pakete vorhanden
sind, die in die Uplink-Richtung laufen, und wenige Pakete, die
als Antwort aus der Downlink-Richtung
kommen. Eine DNS-Abfrage ist ein gutes Beispiel dieses Verhaltens.
Die Signalisierung der PDP-Kontext-Modifikation in diesen Fällen würde einen
relativ hohen Signalisierungsaufwand verursachen, der unter Verwendung
dieses Ausführungsbeispiels verhindert
werden kann. Statt dessen ist lediglich die anfängliche PDP-Kontextaktivierung
zum Erhalten einer IP-Adresse für
die MS erforderlich.
-
Ein verbleibendes Problem bei dem
in den 6 und 7 gezeigten Ansatz besteht
darin, dass es nicht klar sein kann, wie Filterinformationen zusätzlich zum
Filter für
den PDP-Kontext hinzuzufügen
sind, oder wie die vorhandenen Filter zu modifizieren sind, ohne
zuerst alle vorhandenen Filter zu entfernen und dann alle Filterinformationen
einschließlich
der Änderungen
neu zu senden. Das heißt,
werden die PDP-Kontext-Aktivierungs- und – Modifikationsprozeduren immer
verwendet, müssen
die gesamten Filterinformationen in den Nachrichten selbst dann
enthalten sein, wenn lediglich ein Parameterwert zu ändern ist.
Das Hinzufügen
eines neuen Filters erfordert das Senden aller Filter zur gleichen
Zeit. Dementsprechend veranschaulichen die 8 und 9 ein
bevorzugtes Ausführungsbeispiel
der Erfindung, das dieses verbleibende Problem löst.
-
Es wird vorgeschlagen, dass es zumindest
eine dedizierte Nachricht zum Konfigurieren der Filterinformationen
geben soll. In diesem Zusammenhang bedeutet „dedizierte Einrichtung", dass die Nachricht
keine PDP-Kontextinformationen
trägt.
Eine Filterabwicklung sollte zum Identifizieren eines bestimmten
Filters eines bestimmten PDP-Kontexts definiert werden. Diese Filterabwicklung
kann aus einem Tunnelidentifier TID bestehen, der den Benutzer und
den PDP-Kontext angibt, und einer Filternummer FN. Diese kann eine
durch die MS bei der Erzeugung eines Filters ausgewählte Sequenznummer
sein. Zusammenfassend können
die Filter durch die folgenden Prozeduren konfiguriert werden:
- 1. Ein oder mehrere Filter können in
Verbindung mit der PDP-Kontextaktivierungsprozedur (siehe 6) erzeugt werden. In diesem
Fall wird ein oder werden viele Filterinformationselemente in die
PDP-Kontextaktivierungsnachrichten
aufgenommen, wobei jedes Filterelement durch eine andere Filternummer identifiziert
wird (1, 2, 3, usw. )
- 2. Filter können
in Verbindung mit der PDP-Kontextmodifikationsprozedur
(siehe 7) modifiziert
werden. In diesem Fall kann ein oder können mehrere Filterparameter
eines oder mehrerer Filter durch Hinzufügen von Filterinformationselementen
in der PDP-Kontextmodifikationsanforderung
modifiziert werden. Unabhängige
Filter werden durch eine Filternummer identifiziert. Neue Filter
können
unter Verwendung dieser Prozedur genauso erzeugt werden. In diesem
Fall wird ein neues Filterinformationselement (beispielsweise eine
neue, zuvor nicht verwendete Filternummer) in die Modifikationsanforderungsnachricht
aufgenommen.
- 3. Neue Filteroperationen (eine oder mehrere dedizierte Nachrichten):
drei Operationen zwischen der MS und dem GGSN werden zur Konfiguration
der Filter vorgeschlagen: 3.1 Create filter bzw. Filter erzeugen: Diese
Nachricht trägt
TID-Informationen sowie das neue Filterelement und eine neue Filternummer.
Der GGSN erzeugt ein neues Filter entsprechend den Inhalten der
Nachricht.
- 3.2 Modify filter bzw. Filter modifizieren: Diese Nachricht
trägt TID-Informationen
sowie das neue Filterelement, das das alte ersetzt, und eine das
bestimmte zu ersetzende Filter identifizierende Filternummer. Der GGSN
ersetzt das (die) Filterattribut (e) des angegebenen Filters mit
dem (den) neuen.
- 3.3 Delete Filter bzw. Filter löschen: Diese Nachricht trägt TID-Informationen
sowie die Filternummer des zu entfernenden Filters. Der GGSN entfernt
dieses bestimmte Filter.
-
Die Operationen 3.1 bis 3.3 können zur
Verwendung lediglich einer oder zwei unterschiedlicher Nachrichttypen
kombiniert werden, es können
aber auch drei verschiedene Nachrichten (eine pro Operation) definiert
werden. Die definierten Nachrichten können GTP-Nachrichten sein,
wobei in diesem Fall neue GTP-Nachrichten definiert werden sollten
(das heißt,
neue Nachrichtidentifizierer im GTP). In diesem Fall werden die
TID-Informationen automatisch in die GTP-Paketheader aufgenommen, und es muss
kein separates Informationselement in der Nachricht geben. Alternativ
dazu kann ein neues Protokoll für
Filteroperationen zwischen der MS und dem GGSN definiert werden,
wobei in diesem Fall der SGSN für
diese Nachrichten total transparent wäre.
-
8 zeigt
eine erste Implementation der neuen Filteroperationen 3.1 bis 3.3.
In Schritt 8-0 wird ein PDP-Kontext
für die
MS aktiviert. Einzelheiten darüber
wurden bereits in Verbindung mit den vorhergehenden Figuren beschrieben.
In Schritt 8-1 sendet die MS eine CREATE-FILTER-Nachricht zum SGSN. Diese Nachricht
hat als Parameter den Tunnel Identifier TID (der den PDP-Kontext
spezifiziert) und eine Filternummer FN (die ein bestimmtes Filter
im PDP-Kontext spezifiziert). Natürlich sollte die CREATE-FILTER-Nachricht
auch die Eigenschaften des Filters enthalten. In Schritt 8-2 wird
die Nachricht vom SGSN zum GGSN weitergegeben. Die Schritte 8-3
und 8-4 sind entsprechende Bestätigungen.
In Schritt 8-5 findet eine Datenübertragung zu/von
der MS statt. Die Schritte 8-6 bis 8-9 entsprechen den Schritten
8-1 bis 8-4 abgesehen davon, dass in den letztgenannten Schritten
die MS (oder eine ausgeführte
Applikation) ein vorhandenes Filter durch Senden einer MODIFY-FILTER-Nachricht
modifiziert. In den Schritten 8-11 bis 8-14 wird ein nicht länger gebrauchtes Filter
durch Senden einer DELETE-FILTER-Nachricht gelöscht.
-
Die in 8 gezeigte
Implementation beruht auf vorhandenen Protokollen. Die Nachrichten
zwischen der MS und dem SGSN können
beispielsweise Session-Management-Nachrichten sein, und die Nachrichten zwischen
dem SGSN und dem GGSN können
beispielsweise GTP-Nachrichten sein. Wie es ersichtlich ist, ist die
Aushandlung eines Filters zwischen einer MS und einem GGSN unnötig komplex,
da es keine vordefinierten Protokolle zwischen der MS und dem GGSN
gibt.
-
Aus Klarheitsgründen wurden die Nachrichten
8-1, 8-6 und 8-11
als drei separate Nachrichten gezeigt. Alternativ dazu können all
diese Operationen lediglich eine Nachricht verwenden, beispielsweise
CONFIGURE FILTER, die einen Parameter, wie 1 = Erzeugen, 2 = Modifizieren,
3 = Löschen
enthält.
-
9 zeigt
eine alternative Implementierung, bei der es eine Protokollschicht
zwischen der MS und dem GGSN gibt, und der SGSN ein transparenter
Knoten ist, der die Nachrichten in keiner Weise interpretiert.
-
Das Ausführungsbeispiel und die verschiedenen
in den 8 und 9 gezeigten Implementierungen
liefern ein sehr flexibles Schema, bei dem unabhängige (beispielsweise applikationsspezifische)
Filter dynamisch unter Verwendung spezieller Filteroperationen hinzugefügt und modifiziert
werden können.
Ein spezieller Filterabwickler wird zum Identifizieren der unabhängigen Filter
verwendet.
-
Die Beschreibung veranschaulicht
lediglich bevorzugte Ausführungsbeispiele
der Erfindung. Die Erfindung ist allerdings nicht auf diese Beispiele
beschränkt,
sondern kann innerhalb des Schutzbereichs der beigefügten Patentansprüche variieren.
Beispielsweise ist es nicht erforderlich, dass der Empfangsanschluss eine
Mobilstation ist, sondern er kann ein beliebiges Netzelement sein.
Gleichermaßen
ist es nicht erforderlich, dass die MT-Datenpakete ihren Ursprung im IP-Netz
haben. Statt dessen ist die Erfindung beispielsweise bei einem MS-zu-MS-Ruf über einen
GGSN-Knoten anwendbar. In diesem Fall ist der Verbindungszweig von
einer MS zum GGSN ein erstes Kommunikationssubsystem und der Verbindungszweig
vom GGSN zu der anderen MS ist ein zweites Kommunikationssubsystem.