-
HINTERGRUND
DER ERFINDUNG
-
Die
Erfindung bezieht sich auf das Steuern der Auswahl eines Gateway-Unterstützungsknotens in
einem paketvermittelten Netz, und insbesondere auf das Steuern der
Auswahl eines paketvermittelten Gateway-Unterstützungsknotens in einem mobilen Kommunikationsnetz.
-
Mobile
Kommunikationsnetze funktionieren als wirksame Zugangsnetze, die
den Benutzern einen Zugang zu den tatsächlichen Datennetzen für eine mobile
Datenübertragung
liefern. Eine mobile Datenübertragung
wird insbesondere gut von digitalen Mobilkommunikationssystemen,
wie dem paneuropäischen
mobilen Kommunikationssystem GSM (Globales System für Mobile
Kommunikation), unterstützt.
In dieser Anmeldung bezieht sich der Ausdruck 'Daten' auf jede Information, die in einem
digitalen Telekommunikationssystem übertragen wird. Eine solche
Information kann digital kodierte Audio- und/oder Videosignale,
Datenverkehr zwischen Computern, Telefaxdaten, kurze Abschnitte
von Programmkodes etc. umfassen.
-
Der
allgemeine Paketfunkdienst (general packet radio service, GPRS)
ist ein neuer Dienst für
das GSM-System und einer der Punkte, die vom ETSI (Europäisches Telekommunikationsnormungsinstitut)
in GSM Phase 2+ genormt sind. Der GPRS-Dienst ermöglicht eine
Paketdatenübertragung
zwischen mobilen Datenendgeräten
und externen Datennetzen, während
das GSM-Netz als ein Zugangsnetz fungiert. Eine der Bedingungen,
die beim GPRS-Dienst bestehen, ist die, dass er mit unterschiedlichen
externen Datennetzen, wie dem Internet oder X.25-Netzen, kooperieren
sollte. Mit anderen Worten, der GPRS-Dienst und das GSM-Netz sollten
fähig sein,
alle Benutzer unabhängig
vom Typ des Datennetzes, das sie über den GPRS-Dienst anfügen wollen,
zu bedienen. Dies bedeutet, dass der GPRS-Dienst verschiedene Netzadressen
und Datenpaketformen unterstützen
und verarbeiten muss. Das Verarbeiten der Datenpakete umfasst auch
ihre Lenkung in einem Paketfunknetz. Weiterhin sollten die Benutzer
fähig sein,
sich vom Heimat-GPRS-Netz zu einem besuchten GPRS-Netz zu bewegen,
von dem der Betreiber ein Hauptnetz haben kann, das ein anderes
Protokoll (beispielsweise CLNP) unterstützt als das Heimnetz (beispielsweise X.25).
Die logische Netzarchitektur des GPRS-Dienstes ist in 1 gezeigt.
-
1 zeigt
die Netzarchitektur eines GPRS-Dienstes auf einer allgemeinen Ebene,
da die detaillierte Struktur des Netzes für die Erfindung irrelevant
ist. Der GPRS-Dienst umfasst ein Zugangsnetz, das einen Funkzugang
bietet und das das Basisstationsuntersystem BSS des GSM-Systems
in 1 ist, und Unterstützungsknoten des GPRS-Dienstes
für eine
paketvermittelte Übertragung
von paketvermittelten Daten zwischen einem Paketnetz PDN und einer
Mobilstation MS. Die Unterstützungsknoten
umfassen einen bedienenden GPRS-Unterstützungsknoten
SGSN und einen Gateway-GPRS-Unterstützungsknoten
GGSN. Diese verschiedenen Unterstützungsknoten SGSN und GGSN sind
durch ein Hauptnetz miteinander verbunden. Es sollte angemerkt werden,
dass die Funktionen des SGSN und des GGSN auch physikalisch im selben Netzknoten
kombiniert werden können.
Logisch sind die Knoten jedoch getrennte Knoten.
-
Der
bedienende GPRS-Unterstützungsknoten
SGSN bedient die Mobilstation MS. Jeder Unterstützungsknoten SGSN verwaltet
einen Paketdatendienst innerhalb des Gebietes von einer oder mehreren
Zellen in einem zellularen Paketfunknetz. Für diesen Zweck ist jeder Unterstützungsknoten
typischerweise mit einem Basisstationsuntersystem BSS verbunden.
Die Mobilstation MS in einer Zelle kommuniziert mit einer Basisstation über die
Funkschnittstelle und weiter durch das Basisstationsuntersystem
mit dem Unterstützungsknoten
SGSN mit dem Dienstgebiet, zu dem die Zelle gehört.
-
Der
Gateway-GPRS-Unterstützungsknoten GGSN
verbindet den GPRS-Dienst eines Betreibers mit anderen Datennetzen
PDN, wie einem IP-Netz (Internet, Intranet) oder einem X.25 Netz.
Der GGSN umfasst die Verkehrlenkungsinformation der GPRS-Teilnehmer, das sind
die SGSN-Adressen und Adressen des externen Netzes, die sich auf
die PDP-Kontexte beziehen. Der GGSN funktioniert als ein Router
zwischen der externen Adresse und der internen Verkehrslenkungsinformation
(beispielsweise SGSN). Der GGSN kann auch Pakete von einer Mobilstation
zu einer anderen im Netz übertragen.
-
Ein
Teilnehmer des GPRS-Dienstes hat eine oder mehrere verfügbare PDP-Adressen.
Die PDP-Adresse wird für
das identifizieren eines gewissen Benutzerkontexts vom externen
Netz verwendet. Eine Mobilstation, die an den GPRS-Dienst angehängt ist,
kann Datenpakete mit einer gewissen PDP-Adresse empfangen und/oder senden, vorausgesetzt,
dass ein entsprechender Paketdatenprotokoll-PDP-Kontext in der Mobilstation,
dem bedienenden Unterstützungsknoten
und dem Gateway-Unterstützungsknoten
aktiviert ist. Die Aktivierung des PDP-Kontexts errichtet einen
Tunnel zwischen dem Unterstützungsknoten
SGSN, der die Mobilstation bedient, und dem Gateway-Unterstützungsknoten GGSN.
Der Tunnel wird errichtet unter Verwendung eines GPRS-Tunnelprotokolls
GTP zwischen dem SGSN und dem GGSN. Das Tunnelprotokoll des Stands
der Technik ist in der ETSI-Spezifikation GSM 09.60 Version 6.2.0
(Digitales zellulares Telekommunikationssystem (Phase 2+); Allgemeiner
Paketfunkdienst (GPRS); GPRS-Tunnelprotokoll
(GTP) über die
Gn- und Gp-Schnittstelle) beschrieben. Der Tunnel wird in einer
solchen Weise errichtet, dass der SGSN eine Anforderung 'Schaffe PDP-Kontext' an den GGSN sendet,
der diese entweder akzeptiert oder sie zurückweist. Wenn der GGSN die
Schaffungsanforderung akzeptiert, wird der Tunnel errichtet. Wenn
der GGSN die Schaffungsanforderung zurückweist, sendet der SGSN entweder
die Schaffungsanforderung an den nächsten GGSN (wenn er Information über ihn
besitzt) oder informiert die Mobilstation über die Tatsache, dass der
Kontext nicht aktiviert werden kann. Die Auswahl des nächsten GGSN
durch den bedienenden Unterstützungsknoten
SGSN basiert auf statischen Listen, die beispielsweise im internen
Namenserver des GPRS-Dienstes vorgehalten werden. Nachdem der Tunnel
errichtet wurde, kann der Gateway-Unterstützungsknoten GGSN nur entweder
jegliche Aktualisierungsanforderungen, die vom bedienenden Unterstützungsknoten ausgeführt werden,
zurückweisen
oder akzeptieren oder den bedienenden Unterstützungsknoten auffordern, den
Tunnel zu entfernen.
-
Ein
Problem bei der oben beschriebenen Anordnung besteht darin, dass
der Gateway-Unterstützungsknoten
GGSN an keiner Stufe einen anderen Gateway-Unterstützungsknoten
dem bedienenden Unterstützungsknoten
anzeigen kann, der ein geeigneterer Gateway-Unterstützungsknoten
sein würde.
-
Die
US 5 752 162 beschreibt
ein Satellitensystem, in welchem, wenn ein Gateway eine Verbindungsanforderung
zurückweist,
das Gateway die Anforderung an ein anderes Gateway weitergibt.
-
KURZE BESCHREIBUNG
DER ERFINDUNG
-
Eine
Aufgabe der Erfindung besteht darin, ein Verfahren und eine Vorrichtung
zu liefern, die das Verfahren implementiert, um die oben erwähnten Probleme
zu eliminieren. Die Aufgaben der Erfindung werden mit einem Verfahren,
einem Telekommunikationssystem und Unterstützungsknoten eines Paketnetzes
gelöst,
die gekennzeichnet sind, durch das, was in den unabhängigen Ansprüchen offenbart
ist. Die bevorzugten Ausführungsformen
der Erfindung sind in den abhängigen
Ansprüchen
beschrieben.
-
Die
Erfindung basiert auf der Idee, dass der Gateway-Unterstützungsknoten einen anderen
geeigneteren Gateway-Unterstützungsknoten
vorschlägt,
mit dem der Tunnel zum bedienenden Unterstützungsknoten errichtet werden
sollte. Der Gateway-Unterstützungsknoten
kann den Vorschlag machen, entweder wenn er die Anforderung für die Errichtung
eines Tunnels zurückweist,
oder wenn sich die Bedingungen ändern,
so dass es praktisch ist, den existierenden Tunnel zu entfernen.
-
Ein
Vorteil des Verfahrens, des Systems und der Unterstützungsknoten
der Erfindung besteht darin, dass der Betreiber die Last dynamisch
auf die Gateway-Unterstützungsknoten
im Netz verteilen und den Tunnel zwischen dem SGSN und dem Gateway-Unterstützungsknoten
an einen anderen Gateway-Unterstützungsknoten
in Abhängigkeit
von den Bedingungen, beispielsweise in Verbindung mit einer Übergabe
der bedienenden Unterstützungsknoten, überführen kann.
-
In
einer bevorzugten Ausführungsform
der Erfindung sind die Nachrichten, die zum bedienenden Unterstützungsknoten
gesandt werden und den geeignetsten Gateway-Unterstützungsknoten
anzeigen, Antwortnachrichten auf die Anforderung 'Schaffe PDP-Kontext'. Ein weiterer Vorteil
dieser Ausführungsform
ist der, dass sie extrem einfach zu implementieren ist: ein Parameter/Attribut
wird einer existierenden Nachricht hinzugefügt. Dies ermöglicht die allmähliche Einführung dieses
Merkmals in ein Netz, und somit können alte bedienende Unterstützungsknoten,
denen die erfinderische Funktion fehlt, und neue bedienende Unterstützungsknoten
mit der Funktion der Erfindung im Netz gleichzeitig ohne eine Störung ihrer
Funktion verwendet werden.
-
In
einer bevorzugten Ausführungsform
der Erfindung, bei der ein Ende eines existierenden Tunnels von
einem Gateway-Unterstützungsknoten
zu einem anderen zu überführen ist,
wird der Tunnel im Gateway-Unterstützungsknoten nur in Erwiderung auf
eine positive Bestätigung
entfernt. Ein weiterer Vorteil dieser Ausführungsform ist der, dass Pakete nicht
verloren gehen, wenn keine Zeit bestanden hat, einen Tunnel zwischen
dem anderen Gateway-Unterstützungsknoten
und dem bedienenden Unterstützungsknoten
aufzubauen. Diese Ausführungsform ermöglicht auch,
eine zumindest zufriedenstellende Übertragung der Pakete zu gewährleisten.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
Die
Erfindung wird detaillierter mittels bevorzugter Ausführungsformen
unter Bezug auf die begleitenden Zeichnungen beschrieben.
-
1 zeigt
die wesentlichen Teile der logischen Netzarchitektur eines Paketfunknetzes;
-
2 ist
ein Flussdiagramm, das die Funktion einer ersten bevorzugten Ausführungsform
gemäß der Erfindung
in einem bedienenden Unterstützungsknoten
zeigt;
-
3 ist
ein Flussdiagramm, das die Funktion einer zweiten bevorzugten Ausführungsform
gemäß der Erfindung
in einem bedienenden Unterstützungsknoten
zeigt;
-
4 ist
ein Signalisierungsdiagramm, das das Errichten eines Tunnels gemäß der Erfindung zeigt;
-
5 und 6 sind
Signalisierungsdiagramme, die zeigen wie ein Ende des Tunnels von
einem Gateway-Unterstützungsknoten
an einen anderen überführt wird.
-
DETAILLIERTE
BESCHREIBUNG DER ERFINDUNG
-
Die
vorliegende Erfindung ist auf jedes paketvermittelte System anwendbar,
das die Tunneltechnik zwischen dem Gateway-Unterstützungsknoten
und dem bedienenden Unterstützungsknoten verwendet.
Diese umfassen die Mobilkommunikationssysteme der dritten Generation,
wie das Universale Mobiltelekommunikationssystem (UMTS) und IMT-2000
(Internationale Mobiltelekommunikation 200), Mobilkommunikationssysteme,
die dem GSM-System entsprechen, wie das DCS 1800 (Digitales zellulares
System für
188 MHz) und PCS (Persönliches
Kommunikationssystem), und WLL-Systeme, die auf den oben erwähnten Systemen
basieren und eine Paketfunkverbindung des GPRS-Typs implementieren.
Die Erfindung wurde jedoch unter Verwendung des GPRS-Dienstes des
GSM-Systems als ein Beispiel beschrieben, wobei die Erfindung aber natürlich nicht
auf ein solches System beschränkt
ist. Die Definitionen der mobilen Kommunikationssysteme ändern sich
schnell, was zusätzliche Änderungen bei
der Erfindung notwendig machen kann. Aus diesem Grund sollten alle
Begriffe und Ausdrücke
breit interpretiert werden, und es sollte beachtet werden, dass
sie nur zur Beschreibung der Erfindung und nicht zu ihrer Begrenzung
gedacht sind.
-
Das
Unternetz BSS, die Netzelemente SGSN und GGSN und das externe Paketdatennetz PDN,
die in 1 gezeigt sind, wurden oben detaillierter beschrieben.
Die Struktur und die Funktion des GSM-Systems sind einem Fachmann
sehr vertraut. Die Struktur des GPRS-Dienstes ist beispielsweise
in der ETSI-Spezifikation 03.60, Version 6.0.0 (Digitales zellulares
Telekommunikationssystem (Phase 2+); Allgemeiner Paketfunkdienst
(GPRS); Dienstbeschreibung; Stufe 2) definiert. Das in 1 gezeigte Beispiel
zeigt die Tatsache, dass das SGSN mit dem Paketdatennetz PDN über mehrere
Gateway-Unterstützungsknoten
GGSN1, GGSN2, GGSN3 kommunizieren kann. Diese Gateway-Unterstützungsknoten können auch
in verschiedenen Mobilkommunikationsnetzen PLMN A und PLMN B angeordnet
sein. Ein GGSN kann in ähnlicher
Weise mit mehreren bedienenden Unterstützungsknoten SGSN kommunizieren,
obwohl dies in der Figur nicht dargestellt ist.
-
Zusätzlich zu
den Funktionen des Stands der Technik sind die Unterstützungsknoten
SGSN und GGSN des Systems gemäß der Erfindung
ausgelegt, um die Funktionen auszuführen, die in Verbindung mit
den 2 bis 6 erläutert werden. Sie umfassen
Prozessoren und einen Speicher, der bei den Funktionen der Erfindung
verwendet werden kann. Alle Änderungen,
die benötigt
werden, um die Erfindung zu implementieren, können als zusätzliche
oder aktualisierte Softwareroutinen ausgeführt werden.
-
Zusätzlich kann
das System Mittel für
das Speichern empfehlenswertes Gateway-Unterstützungsknoten im Speicher umfassen.
Die Speichermittel sind vorzugsweise in einer zentralisierten Datenbank
DB angeordnet. Die Speichermittel oder einige von ihnen können auch
zwischen den Netzelementen aufgeteilt werden, beispielsweise kann
jeder Gateway-Unterstützungsknoten
eine eigene Liste aufweisen. Im letzteren Fall kann es auch sein,
dass der Gateway-Unterstützungsknoten
einen zusätzlichen
Speicher benötigt.
Die Information in der Datenbank kann beispielsweise über eine
(nicht gezeigte) Netzverwaltung aktualisiert werden. Beispielsweise können die
empfohlenen Gateway-Unterstützungsknoten
so gespeichert werden, dass jeder Gateway-Unterstützungsknoten
SGSN eine eigene Liste aufweist, von der ein geeigneter Unterstützungsknoten
gewählt
wird, gemäß den Merkmalen
und verfügbaren
Ressourcen. Die Art, in welcher die Listen vorgehalten werden, oder
die Gründe,
nach denen die Auswahl ausgeführt
wird, sind für
die Erfindung irrelevant. Es ist wesentlich, dass der Gateway-Unterstützungsknoten,
wenn benötigt,
Information über
einen besseren/empfehlenswerteren Gateway-Unterstützungsknoten
empfängt.
Er kann diese Information auch direkt vom Betreiber empfangen, und
somit wird der Speicher nicht benötigt.
-
2 ist
ein Flussdiagramm, das die Funktion des Gateway-Unterstützungsknotens
GGSN gemäß der ersten
bevorzugten Ausführungsform
der Erfindung in Bezug auf einem PDP-Kontext darstellt. Im Schritt 201 wird
eine Anforderung 'Schaffe PDP-Kontext' (oder eine Anforderung 'Schaffe AA PDP-Kontext') vom bedienenden
Unterstützungsknoten
empfangen. Im Schritt 202 wird geprüft, ob der Gateway-Unterstützungsknoten
den gewünschten
Dienst unterstützt,
wie eine auf dem IP basierende Verbindung oder eine Verbindung zu
dem Netz einer gewissen Firma. Wenn der Gateway-Unterstützungsknoten
den gewünschten
Dienst unterstützt, wird
im Schritt 203 geprüft,
ob der Gateway-Unterstützungsknoten
die notwendige Kapazität,
beispielsweise die gewünschte
Qualität
des Dienstes, liefern kann. Wenn der Gateway-Unterstützungsknoten
die notwendige Kapazität
liefern kann, so wird im Schritt 204 geprüft, ob die
Last des Gateway-Unterstützungsknotens
unterhalb des Grenzwertes liegt, der vom Betreiber vorgegeben wurde.
Der Betreiber kann einen festen Grenzwert vorgeben oder ihn in Abhängigkeit
von der Belastung ändern.
Wenn beispielsweise viel Verkehr im Netz herrscht, so kann der Grenzwert
bei 95% der maximalen Belastung liegen, aber wenn die Menge des
Verkehrs klein ist, so kann der Grenzwert auf 50% der maximalen
Belastung geändert
werden. Wenn die Belastung kleiner als der Grenzwert ist, so wird
eine positive Antwort an den bedienenden Unterstützungsknoten im Schritt 205 gesendet
(Schaffe PDP-Kontext-Antwort (Anforderung akzeptiert) oder Schaffe
AAA PDP-Kontext-Antwort (Anforderung akzeptiert)). Danach wird im
Schritt 206 geprüft,
ob der PDP-Kontext
schon existiert. Wenn es keinen PDP-Kontext gibt, so wird er im
Schritt 207 geschaffen. Wenn ein PDP-Kontext existiert,
so wird er im Schritt 208 aktualisiert.
-
Von
den Schritten 207 und 208 bewegen wir uns zum
Schritt 209, wo die Situation des Gateway-Unterstützungsknotens überwacht
wird. Während
der Überwachung
wird im Schritt 210 geprüft, ob die Situation ok. ist.
Dies wird herausgefunden, indem beispielsweise die Belastung und
der Grenzwert verglichen werden. Der Grenzwert kann geändert werden,
sogar wenn ein Tunnel schon existieren würde, um die Last zwischen den
Gateway-Unterstützungsknoten
aufzuteilen. Wenn die Situation ok ist, setzen wir die Überwachung
fort. Wenn die Situation nicht ok ist, beispielsweise sich die Lastsituation ändert und
der Betreiber die Belastung aufteilen will, wird die Adresse eines
empfehlenswerteren GGSN im Schritt 211 abgerufen. Danach
wird im Schritt 212 der bedienende Unterstützungsknoten über die
Tatsache informiert, dass der Gateway-Unterstützungsknoten geändert worden
ist. Die zu sendende Information umfasst die Adresse des empfohlenen
Gateway-Unterstützungsknotens.
In der ersten bevorzugten Ausführungsform
wird der Schritt 212 durch das Senden einer negativen Antwort
ausgeführt,
die Information über
den Gateway-Unterstützungsknoten, der
vom Gateway-Unterstützungsknoten
empfohlen wird, einschließt
(Schaffe PDP-Kontextantwort (Grund GGSN2) oder Schaffe AA PDP-Kontextantwort (Grund
GGSN2)). Mit anderen Worten, in der ersten bevorzugten Ausführungsform
kann der GGSN dieselben Nachricht senden, als wenn er auf die Anforderung 'Schaffe PDP-Kontext' antwortet, sogar
wenn der PDP-Kontext aktiviert ist und der Tunnel existiert. In
anderen Ausführungsformen
können auch
andere Nachrichten gesendet werden, um das Ende des Tunnel zu transferieren.
Alternative Nachrichten umfassen die Anforderung 'Lösche PDP-Kontext (GGSN2) und 'Setze PDP-Kontext zurück, GGSN2.
In der ersten bevorzugten Ausführungsform wird
der PDP-Kontext im Schritt 213 gelöscht, nachdem die negative
Antwort gesendet wurde.
-
Wenn
im Schritt 202 bemerkt wird, dass der angeforderte Dienst
nicht unterstützt
wird, begeben wir uns zum Schritt 214, um die Adresse des
stärker empfohlenen
GGSN abzurufen. Dann wird im Schritt 215 eine negative
Antwort, die Information über
den Gateway-Unterstützungsknoten,
der vom Gateway-Unterstützungsknoten
empfohlen wird (Schaffe PDP-Kontextantwort
(Fall GGSN2) oder Schaffe AA PDP Kontextantwort (Fall GGSN2) gesendet.
Danach wird im Schritt 216 geprüft, ob ein PDP-Kontext schon
existiert, und wenn ein PDP-Kontext existiert, so wird er in Schritt 217 gelöscht. In
einigen anderen Ausführungsformen
wird der PDP-Kontext im Schritt 217 nicht notwendigerweise
gelöscht,
sondern der PDP-Kontext
wird in Abhängigkeit
vom Fall und dem Verwendungszweck entweder zurückgehalten oder gelöscht. Der
Tunnel wird jedoch entfernt. Dasselbe kann auch in Schritt 213 erfolgen.
-
Wenn
keine verfügbare
Kapazität
vorhanden ist, so bewegen wir uns vom Schritt 203 zum Schritt 214.
Wenn die Last nicht unter dem Grenzwert liegt, so bewegen wir uns
vom Schritt 204 zum Schritt 214.
-
Wenn
die Last berechnet wird, kann auch das Niveau der Dienstgüte, das
ist das QoS-Niveau, das für
den in Frage stehenden Kontext gewünscht wird, berücksichtigt
werden. In diesem Fall werden die gewünschten QoS-Parameterwerte,
die in der Anforderung gesendet werden, geprüft, und es wird in Schritt 204 ausgewertet,
ob die gewünschte Dienstgüte erreicht/garantiert
werden kann. Wenn die gewünschte
Dienstgüte
nicht erreicht oder garantiert werden kann, ist es möglich, einen
GGSN anzuzeigen, der den gewünschten
Dienst besser unterstützen
könnte.
-
Die
Schritte 203, 204 und 205 zeigen einige Bedingungen,
die der Betreiber definieren kann, um die Last zu verteilen oder
um die Gateway-Unterstützungsknoten
zu verwenden, die verschiedene Dienste unterstützen. Die Bedingungen für das Zurückweisen
des Schaffens können
sich von dem, was oben beschrieben wurde, unterscheiden. Die Bedingungen können auch
in Abhängigkeit
von der Lastsituation oder unabhängig
von der Lastsituation variiert werden. weiterhin können die
Bedingungen für
jeden Gateway-Unterstützungsknoten
getrennt definiert werden, oder die Bedingungen oder einige von
ihnen, können
gemeinsam definiert werden, beispielsweise in einer Datenbank, die
die Liste der am stärksten empfohlenen
Gateway-Unterstützungsknoten
einschließt.
Die Bedingung kann für
den Gateway-Unterstützungsknoten
spezifisch sein, wie ein unterstützter
Dienst, oder für
alle Gateway-Unterstützungsknoten
desselben Betreibers gemeinsam. Eine gebräuchliche Bedingung könnte beispielsweise sein,
dass der Tunnel einer sich auf Besuch befindlichen Mobilstation
im Heimatnetz errichtet wird. Wenn beispielsweise die Mobilstation
MS ein Teilnehmer des Netzes PLMN B in der in 1 dargestellten
Situation ist, kann die Bedingung für den GGSN1 oder den GGSN2
(oder für
diese beispielsweise in einer Datenbank) sein, dass die Teilnehmer
des PLMN B zum GGSN3 gelenkt werden. Es ist wesentlich, dass mindest
eine Bedingung definiert wurde und dem GGSN die Adresse eines anderen
GGSN gegeben wird, die dieser in die negative Antwort einschließen kann.
-
In
einigen anderen bevorzugten Ausführungsformen
der Erfindung kann die Überführung des
Tunnelendes zu einem Gateway-Unterstützungsknoten, das sind die
Schritte 209, 210, 211, 212 und 213 weggelassen
werden.
-
3 ist
ein Flussdiagramm, das die Funktion des bedienenden Unterstützungsknotens
SGSN gemäß der ersten
bevorzugten Ausführungsform
der Erfindung in Bezug auf einen PDP-Kontext zeigt. Im Schritt 301 wird
eine negative Antwort auf die Anforderung 'Schaffe PDP-Kontext' vom bedienenden Unterstützungsknoten
erhalten (Schaffe PDP-Kontextantwort (Grund) oder Schaffe AA PDP-Kontextantwort
(Grund)). Im Schritt 302 wird geprüft, ob der entsprechende PDP-Kontext
aktiv ist. Wenn er dies ist, so wird er auf das Warten auf eine
Antwort im Schritt 303 gesetzt, wonach wir uns zum Schritt 304 bewegen.
Wenn der PDP-Kontext inaktiv ist, bewegen wir uns vom Schritt 302 direkt
zum Schritt 304. Im Schritt 304 wird geprüft, ob die
Antwort die Adresse des empfohlenen Gateway-Unterstützungsknotens GGSN
zusätzlich
zum Grund enthält.
Wenn sie die Adresse enthält,
wird im Schritt 305 geprüft, ob sich dieselbe GGSN-Adresse
auf der GGSN-Liste des SGSN befindet. Wenn sie aufgelistet ist,
wird sie im Schritt 306 als gebraucht auf der eigenen Liste
SGSN markiert, wonach wir uns zum Schritt 307 bewegen. Durch
das Markieren des Knotens als gebraucht, gewährleisten wir, dass nicht zwei
Schaffensanforderungen an denselben GGSN gesendet werden. Wenn die
Liste des SGSN die GGSN-Adresse nicht enthält, gehen wir direkt zum Schritt 307,
wo eine Anforderung 'Schaffe
PDP-Kontext' an
den GGSN, der in der negativen Antwort angezeigt wird, gesandt wird.
Im Schritt 308 wird eine Antwort vom GGSN empfangen. Im
Schritt 309 wird geprüft,
ob die Antwort negativ war. Wenn sie negativ war, bewegen wir uns
zum Schritt 304, um zu prüfen, ob die Antwort zusätzlich zum
Grund die GGSN-Andresse enthält. Wenn
die Antwort positiv war (Schaffe PDP-Kontext-Anforderung (Anforderung
akzeptiert) oder Schaffe AA PDP-Kontext (Anforderung akzeptiert)), wird
im Schritt 310 ein PDP-Kontext
aktiviert, und ein Tunnel zwischen dem bedienenden Unterstützungsknoten
SGS und dem Gateway-Unterstützungsknoten
GGSN im Schritt 311 errichtet.
-
Wenn
im Schritt 304 bemerkt wird, dass die negative Antwort
die GGSN-Adresse nicht enthält, wird
im Schritt 312 geprüft,
ob es nicht verwendete GGSN-Adressen auf der GGSN-Liste des bedienenden
Unterstützungsknotens
gibt. Wenn dies der Fall ist, wird die Adresse oben in der Liste
im Schritt 313 gewählt
und im Schritt 314 als gebraucht markiert, wonach wir uns
zum Schritt 307 bewegen, um eine Anforderung 'Schaffe PDP-Kontext' zu senden. Wenn
diese Route verwendet wird, wird die Schaffensanforderung immer
an den GGSN gesandt, der von der eigenen Liste des SGSN ausgewählt wurde. Wenn
im Schritt 312 festgestellt wird, dass es keine nicht gebrauchten
GGSN-Adressen auf
der Liste des bedienenden Unterstützungsknotens gibt, wird ein Fehler
auftreten (Schritt 315), und Pakete können nicht übertragen werden.
-
In
einigen anderen bevorzugten Ausführungsformen
der Erfindung werden die Schritte 305, 306, 312, 313 und 314 überhaupt
nicht ausgeführt.
In diesem Fall ist der Gateway-Unterstützungsknoten nur
für das
Herausfinden des alternativen Gateway-Unterstützungsknotens verantwortlich.
-
Die
Schritte, die in den 2 und 3 beschrieben
sind, befinden sich nicht in einer absoluten chronologischen Reihenfolge,
und einige der Schritte können
gleichzeitig oder in einer anderen Reihenfolge ausgeführt werden.
Diese Schritte umfassen die Schritte 202, 203 und 294 und
die Schritte 314 und 307. Andere Funktionen können auch
zwischen den Schritten ausgeführt
werden, beispielsweise können in 2 Daten
des PDP-Kontexts, wie die SGSN-Adresse aktualisiert werden, oder
der PDP-Kontext kann in Erwiderung auf eine Löschanforderung, die vom SGSN
gesandt wird, gelöscht werden.
Es ist auch möglich,
auf eine Bestätigung vom
bedienenden Unterstützungsknoten
zwischen den Schritten 212 und 213 der 2 zu
warten, und den PDP-Kontext nur in Erwiderung auf die Bestätigung zu
löschen,
die anzeigt, dass ein anderer Tunnel erfolgreich errichtet wurde.
In den Ausführungsformen
der Erfindung, bei denen die negative Antwort nur verwendet wird,
wenn der Tunnel errichtet wird, wird eine andere Nachricht, beispielsweise
Löschen oder
Rücksetzen,
im Schritt 212 gesandt. In diesem Fall werden mindestens
die Schritte 302 und 303 aus dem Beispiel der 3 weggelassen,
wenn die negative Antwort empfangen wird. Wenn eine andere Nachricht
empfangen wird, werden diese Schritte ausgeführt.
-
Die 4, 5 und 6 zeigen
Beispiele der Signalisierung gemäß der Erfindung
in verschiedenen Ausführungsformen.
Die Signalisierung basiert auf der ETSI-Empfehlung GSM 09.60 Version 6.2.0.
-
4 zeigt
die Signalisierung in Bezug auf die PDP-Kontext-Aktivierung. Im Beispiel der 4 sendet
die Mobilstation MS eine Anforderung 'Aktiviere PDP-Kontext' an den bedienenden
Unterstützungsknoten
SGSN in der Nachricht 4-1. Wenn der bedienende Unterstützungsknoten
SGSN die Nachricht empfangen hat, so führen er und die Mobilstation
MS in der Nachricht 4-2 Sicherheitsfunktionen aus. Nachdem
die Sicherheitsfunktionen durchgeführt wurden, sendet der bedienende
Unterstützungsknoten
SGSN eine Anforderung 'Schaffe PDP-Kontext' an den Gateway-Unterstützungsknoten
GGSN1 in der Nachricht 4-3. Die Nachrichten 4-1, 4-2 und 4-3 erfolgen
gemäß dem Stand
der Technik. Nachdem der Gateway-Unterstützungsknoten
GGSN1 die Nachricht 4-3 empfangen hat, prüft er im
Schritt 4-4, ob die Bedingungen (oder Bedingung) für die Akzeptanz
erfüllt
sind. Wenn es notwendig ist, wird der Grenzwert, der sich auf diese
Bedingung oder auf diese Bedingungen bezieht, aus einer Datenbank
abgerufen. Dies ist in 4 jedoch nicht gezeigt. Beispiele
der Bedingungen sind in Verbindung mit 2 angegeben.
Im Beispiel der 4 wird angenommen, dass der
GGSN1 die PDP-Kontext-Anforderung
nicht akzeptieren kann. Somit fordert er die Adresse eines geeigneteren
GGSN aus der Datenbank DB in der Nachricht 4-5 an. Die
Nachricht kann Information über
die Bedingung enthalten, die die Zurückweisung verursacht hat, und
den Grund der Zurückweisung.
Die Nachricht kann auch alle Parameter und Attribute, die in der
Nachricht 4-3 übertragen wurden,
enthalten. Die Datenbank ruft die Adresse GGSN2 auf der Basis der
Information, die in der Nachricht 4-5 angegeben ist, ab
und sendet sie in der Nachricht 4-6 zurück. Die Nachrichten 4-5 und 4-6 sind
keine tatsächlichen
Signalisierungsnachrichten. Die Nachrichten 4-5 und 4-6 werden
für das
Anzeigen der Datenbanksuche, die in diesem Schritt ausgeführt wird,
verwendet. Wenn der Gateway-Unterstützungsknoten
GGSN1 die Nachricht 4-6 empfangen hat, so sendet er eine
Antwort 'Schaffe PDP-Kontext', deren Grund-Parameter sich von 'Anforderungsakzeptanzwert' unterscheidet, an
den bedienenden Unterstützungsknoten
SGSN in der Nachricht 4-7. Die Nachricht enthält auch
die Adresse des GGSN2. Der bedienende Unterstützungsknoten SGSN trennt die
Adresse von der Nachricht 4-7 im Schritt 4-8 und
sendet eine Anforderung 'Schaffe PDP-Kontext' an den Gateway-Unterstützungsknoten
GGSN2 in der Nachricht 4-9. Die Nachricht 4-9 erfolgt
gemäß dem Stand
der Technik. Wenn der Gateway-Unterstützungsknoten GGSN2 die Nachricht 4-9 erhalten
hat, so prüft
er im Schritt 4-10, ob die Bedingungen (oder Bedingung)
für die
Akzeptanz erfüllt
sind. In diesem Fall sind die Bedingungen (oder die Bedingung) erfüllt, und
der Gateway-Unterstützungsknoten
GGSN2 sendet eine Antwort 'Schaffe
PDP-Kontext', deren
Grund-Parameter 'Anforderung akzeptiert' ist, an den bedienenden
Unterstützungsknoten
SGSN in der Nachricht 4-11. Mit anderen Worten, die Nachricht 4-11 ist
eine positive Antwort. Der bedienende Unterstützungsknoten SGSN überträgt die Akzeptanz
an die Mobilstation MS gemäß dem Stand
der Technik durch das Senden einer Akzeptanz 'Aktiver PDP-Kontext' in der Nachricht 4-12. Danach
wird der PDP-Kontext von der Mobilstation aktiviert, die Pakete
senden und empfangen kann.
-
Die
Aktivierung des PDP-Kontexts, die in 4 dargestellt
ist, kann ausgeführt
werden, wenn sich die Mobilstation an das GPRS-Netz anhängt. Alternativ
kann der Benutzer den Kontext aktivieren, oder die Aktivierung kann
in Erwiderung auf eine Anforderung für eine PDP-Kontextaktivierung, die vom GPRS-Netz
empfangen wird, ausgeführt
werden.
-
5 ist
ein Signalisierungsdiagramm, das eine Situation zeigt, in welcher
ein Tunnel zwischen dem SGSN und dem GGSN2 errichtet worden ist.
Mit anderen Worten, die PDP-Kontexte
sind aktiv. Im Schritt 5-1 ändern sich die Betriebsbedingungen
des Gateway-Unterstützungsknotens.
Beispielsweise fährt
der Betreiber den Gateway-Unterstützungsknoten
nach unten, oder die Last des Gateway-Unterstützungsknotens übersteigt
den Grenzwert, da der Grenzwert sich geändert hat. Die Änderung
der Betriebsbedingungen können
auch aus einer Aktualisierung des PDP-Kontexts bestehen, der vom
bedienenden Unterstützungsknoten
empfangen wird, beispielsweise wenn sich die gewünschte Dienstgüte oder
der bedienende Unterstützungsknoten ändern. Somit
muss ein Ende des Tunnels vom GGSN2 an einen anderen Gateway-Unterstützungsknoten überführt werden.
Als Ergebnis davon sendet der Gateway-Unterstützungsknoten eine Nachricht 5-2 an
den bedienenden Unterstützungsknoten
SGSN. In Abhängigkeit
von der Ausführungsform
kann die Nachricht eine Antwort 'Schaffe
PDP-Kontex' sein, deren Grund-Parameterwert
sich vom Wert 'Anforderung akzeptiert' unterscheidet, ein 'Lösche PDP-Kontext' oder 'Setze PDP-Kontext zurück'. Unabhängig vom Typ
der Nachricht enthält
sie immer die Adresse eines neuen, geeigneteren Gateway-Unterstützungsknoten
GGSN3, die entweder vom Betreiber erhalten oder aus der Datenbank
abgerufen wird. Nachdem der GGSN2 die Nachricht gesendet hat, löscht er
den PDP-Kontext im Schritt 5-3, das heißt, er entfernt den Tunnel.
Nachdem er die Nachricht 5-2 empfangen hat, entfernt der
bedienende Unterstützungs-SGSN den
Tunnel vom GGSN2 im Schritt 5-4, trennt die Adresse von
der Nachricht 5-2 und sendet eine Anforderung 'Schaffe PDP-Kontext' an den Gateway-Unterstützungsknoten
GGSN3 in der Nachricht 5-5. Der Gateway-Unterstützungsknoten GGSN3 überprüft, nachdem
er die Nachricht 5-5 erhalten hat, ob die Bedingungen (oder
die Bedingung) für
die Akzeptanz erfüllt
sind. Zu dieser Zeit sind die Bedingungen (oder die Bedingung) erfüllt, und
der Gateway-Unterstützungsknoten
GGSN3 sendet eine Antwort 'Schaffe
PDP-Kontext', deren
Grundparameter 'Anforderung
akzeptiert' ist,
an den bedienenden Unterstützungsknoten
SGSN in der Nachricht 5-7. Danach errichtet der SGSN einen
neuen Tunnel und setzt die Übertragung
von Paketen unter Verwendung dieses neuen Tunnels fort. Die Mobilstation muss über den
neuen Tunnel nicht unterrichtet werden.
-
Wenn
die Bedingungen im Schritt 5-6 nicht erfüllt sind,
schlägt
der Gateway-Unterstützungsknoten
einen anderen Gateway-Unterstützungsknoten vor.
Wenn kein geeigneter Gateway-Unterstützungsknoten gefunden wird,
wird ein Fehler auftreten, und Pakete können nicht länger übertragen
werden.
-
6 zeigt
ein Signalisierungsdiagramm einer Situation, in der ein Tunnel zwischen
dem SGSN und dem GGSN2 errichtet worden ist. Mit anderen Worten,
die PDP-Kontexte sind aktiviert worden. Im Schritt 6-1 ändern sich
die Betriebsbedingungen. Beispielsweise überschreitet die Last des Gateway-Unterstützungsknotens
den Grenzwert, da der Grenzwert geändert wurde. Als Ergebnis davon
sendet der Gateway-Unterstützungsknoten
eine Nachricht 6-2 an den bedienenden Unterstützungsknoten SGSN.
Vorzugsweise lautet die Nachricht 'Setze PDP-Kontext zurück'. Die Nachricht 6-2 enthält die Adresse
GGSN3 eines neuen, geeigneteren Gateway-Unterstützungsknotens, die entweder
vom Betreiber erhalten oder aus der Datenbank abgerufen wird. Nachdem
der bedienende Unterstützungsknoten
die Nachricht 6-2 erhalten hat, trennt er in Schritt 6-3 die
Adresse von der Nachricht 6-2 und sendet eine Anforderung 'Schaffe PDP-Kontext' an den Gateway-Unterstützungsknoten
GGSN3 im Schritt 6-4. Nachdem der Gateway-Unterstützungsknoten GGSN3
die Nachricht 6-4 empfangen hat, prüft er in Schritt 6-5,
ob die Bedingungen (oder die Bedingung) für die Akzeptanz erfüllt sind.
Zu dieser Zeit sind die Bedingungen (oder die Bedingung) erfüllt, und
der Gateway-Unterstützungsknoten
GGSN3 sendet eine Antwort 'Schaffe
PDP-Kontext', deren
Grundparameter 'Anforderung
akzeptiert' ist,
an den bedienenden Unterstützungsknoten
SGSN in der Nachricht 6-6. Der SGSN entfernt, nachdem er
die positive Antwort in Nachricht 6-6 erhalten hat, den
Tunnel zum GGSN2 im Schritt 6-7 durch das Senden einer
positiven Bestätigung
(ResetPDPContextAck) an den GGSN2. Im Schritt 6-8 schafft
der SGSN einen neuen Tunnel mit GGSN3 und setzt die Übertragung
der Pakete unter Verwendung dieses neuen Tunnels fort. Die Mobilstation
muss über
den neuen Tunnel nicht informiert werden. Wenn der GGSN2 eine positive Bestätigung empfängt, so
löscht
er den PDP-Kontext in
Schritt 6-9.
-
Wenn
die Bedingungen in Schritt 6-5 nicht erfüllt sind,
sendet der Gateway-Unterstützungsknoten
GGSN3 eine negative Antwort (beispielsweise die Nachricht 4-7 der 4),
und der SGSN kann versuchen, einen Tunnel mit dem Gateway-Unterstützungsknoten,
der vom GGSN3 vorgeschlagen wird, zu errichten. Wenn der SGSN die
negative Antwort ohne eine Adresse eines neuen Gateway-Unterstützungsknotens
empfängt,
wird er eine negative Bestätigung
an den GGSN2 senden und den Tunnel nicht von ihm entfernen. In diesem
Fall sucht der GGSN2 nach einem anderen PDP-Kontext, den er versucht,
zu einem anderen Gateway-Unterstützungsknoten
zu transferieren, um die Last gleichmäßig zu verteilen. Alternativ
kann der SGSN, wenn er die negative Antwort vom GGSN3 empfangen
hat, immer eine negative Bestätigung
an den GGSN2 senden, der auch nach einer Adresse eines neuen Gateway-Unterstützungsknotens
suchen kann, die an den SGSN zu senden ist.
-
Eine
bevorzugte Ausführungsform
der Erfindung verwendet jede der in den 4, 5 und 6 dargestellten
Signalisierungstypen. In Abhängigkeit
von der Änderung
der Betriebsbedingungen, die im Gateway-Unterstützungsknoten detektiert werden,
wird entweder die Signalisierung 5 oder die Signalisierung 6 beispielsweise
gemäß den Anweisungen,
die von einem Betreiber gegeben wurden, ausgewählt. Die Anweisungen können in
der Bedingung eingeschlossen sein. Die Signalisierung 5 wird ausgewählt, wenn
beispielsweise der Betreiber den Gateway-Unterstützungsknoten herab fährt, wohingegen
die Signalisierung 6 in Verbindung mit der Aktualisierung
des PDP-Kontexts verwendet wird. In dieser Ausführungsform müssen sich
die Nachrichten 5-2 und 6-2 voneinander unterscheiden,
so dass der bedienende Unterstützungsknoten
weiß,
welche Signalisierung betroffen ist. Der einfachste Weg, um eine
Nachricht von der anderen zu unterscheiden, besteht darin, Nachrichten
mit unterschiedlichen Namen zu verwenden.
-
In
bevorzugten Ausführungsformen
der Erfindung ist es möglich,
nur eine oder zwei der in den 4, 5 und 6 dargestellten
Beispiele zu verwenden.
-
Die
Schritte und die Signalisierungsnachrichten, die in den 4, 5 und 6 gezeigt
sind, befinden sich nicht in einer absoluten chronologischen Reihenfolge,
und einige der Schritte können gleichzeitig
oder in einer anderen Reihenfolge ausgeführt werden. Die Signalisierungsnachrichten
sind nur beispielhaft und können
sogar mehrere getrennte Nachrichten für das Übertragen derselben Information
umfassen. Zusätzlich
können
die Nachrichten andere Information enthalten. Die Nachrichten können auch
frei kombiniert oder in mehrere Teile aufgeteilt werden. Weiterhin
können
sich die Namen der Nachrichten von den oben erwähnten unterscheiden. Es ist
wesentlich, dass der Gateway-Unterstützungsknoten
Steuerinformation an den bedienenden Unterstützungsknoten senden kann, wenn
ein anderer Gateway-Unterstützungsknoten
geeigneter ist als der aktuelle Gateway- Unterstützungsknoten. In Abhängigkeit
von der Netzstruktur können
andere Netzelemente, zwischen denen unterschiedliche Funktionen
aufgeteilt wurden, an der Datenübertragung
und der Signalisierung teilnehmen.
-
Obwohl
in Verbindung mit den 4, 5 und 6 nur
normale PDP-Kontexte als Beispiele verwendet wurden, ist dieselbe
Funktion der Erfindung auch auf PDP-Kontexte eines anonymen Benutzers
(anonymer Zugang) anwendbar.
-
Ein
Fachmann wird erkennen, dass das erfinderische Konzept, wenn sich
die Technik entwickelt, auf verschiedene Arten implementiert werden kann.
Somit sind die Erfindung und ihre Ausführungsformen nicht auf die
oben beschriebenen Beispiele begrenzt sondern können im Umfang der Ansprüche variieren.