DE69933312T2

DE69933312T2 - Auswahlsteuerung eines gateway-unterstützungsknotens

Info

Publication number: DE69933312T2
Application number: DE69933312T
Authority: DE
Inventors: Mikko Puuskari
Original assignee: Nokia Oyj
Current assignee: Nokia Oyj
Priority date: 1998-12-31
Filing date: 1999-12-28
Publication date: 2007-09-13
Anticipated expiration: 2019-12-29
Also published as: ES2272094T3; FI982855A; DE69933312D1; EP1142370B1; US7649837B1; WO2000041414A1; EP1142370A1; FI982855A0; ATE340487T1; AU3048200A; FI107980B

Description

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.

Claims

Verfahren zum Steuern einer Auswahl eines Gateway-Supportknotens, der in einem Telekommunikationssystem verwendet werden soll, welches mindestens einen Supportknoten, der einen Teilnehmer des Telekommunikationssystem bedient, einen ersten und einen zweiten Gateway-Supportknoten umfasst, dadurch gekennzeichnet, dass das Verfahren die Schritte umfasst: Definieren mindestens einer Bedingung für den ersten Gateway-Supportknoten, durch die ermittelt werden kann, ob der zweite Gateway-Supportknoten zum Übertragen von Paketen geeigneter ist als der erste Gateway-Knoten, so dass wenn die Bedingung erfüllt ist, der zweite Gateway-Supportknoten geeigneter zum Übertragen von Paketen ist, Erkennen (202, 203, 204, 210), dass die Bedingung erfüllt ist, und Empfehlen des zweiten Gateway-Supportknoten durch den ersten Gateway-Supportknoten durch Senden (212, 215) einer ersten Nachricht, die den zweiten Gateway-Supportknoten angibt, an den bedienenden Supportknoten.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das Verfahren weiter die Schritte umfasst: Empfangen (201) einer zweiten Nachricht in dem ersten Gateway-Supportknoten, die angibt, dass ein Tunnel zum Übertragen von Paketen zwischen dem Teilnehmer und einem externen Datennetz zwischen dem bedienenden Supportknoten und dem ersten Gateway-Supportknoten aufgebaut werden soll, Überprüfen (202, 203, 204) der Bedingung, und Übertragen (215) einer ersten Nachricht an den bedienenden Supportknoten, wenn die Bedingung erfüllt ist, oder Aufbauen (207) eines Tunnels, wenn die Bedingung nicht erfüllt ist.
Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass wenn der Tunnel zwischen dem bedienenden Supportknoten und dem ersten Gateway-Supportknoten aufgebaut wird, das Verfahren weiter die Schritte umfasst: Erkennen (210) einer Änderung von Betriebsbedingungen in dem ersten Gateway-Supportknoten, Überprüfen der Bedingung, und Übertragen (212) einer dritten Nachricht, die den zweiten Gateway-Supportknoten angibt, an den bedienenden Supportknoten, und Entfernen des Tunnels in dem ersten Gateway-Supportknoten, wenn die Bedingung erfüllt ist.
Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass das System ein GPRS-System (PLMN A, PLMN B) ist und die erste und dritte Nachricht Antwortnachrichten auf eine „Create PDP Context"-Anforderung sind.
Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass wenn der Tunnel zwischen dem bedienenden Supportknoten und dem ersten Gateway-Supportknoten aufgebaut wird, das Verfahren weiter die Schritte umfasst: Erkennen (6-1) einer Veränderung von Betriebsbedingungen in dem ersten Gateway-Supportknoten, Überprüfen der Bedingung, und Ausführen der nächsten Schritte, wenn die Bedingung erfüllt ist: Übertragen (6-2) einer vierten Nachricht, die den zweiten Gateway-Supportknoten angibt, an den bedienenden Supportknoten, Warten auf eine Bestätigung für die vierte Nachricht, Empfangen (6-8) der Bestätigung, und Entfernen (6-10) des Tunnels in dem ersten Gateway-Supportknoten in Reaktion auf eine positive Bestätigung.
Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass das System ein GPRS-System (PLMN A, PLMN B) ist, und die erste und vierte Nachricht Antwortnachrichten auf eine „Create PDP Context"-Anforderung sind.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das Verfahren weiter die Schritte umfasst: Aufbauen (207) eines Tunnels zwischen dem bedienenden Supportknoten und dem ersten Gateway-Supportknoten, Erkennen (209) einer Änderung von Betriebsbedingungen in dem ersten Gateway-Supportknoten, Überprüfen (210) der Bedingung, und Übertragen (212) einer ersten Nachricht an den bedienenden Supportknoten, wenn die Bedingung erfüllt ist.
Verfahren nach Anspruch 7, gekennzeichnet durch Entfernen des Tunnels in dem ersten Gateway-Supportknoten in Reaktion auf die Übertragung der ersten Nachricht, wenn die Erfüllung der Bedingung erkannt wird (210).
Verfahren nach Anspruch 7, gekennzeichnet durch, wenn die Erfüllung der Bedingung erkannt wird: Warten auf eine Bestätigung für die erste Nachricht, Empfangen (6-8) der Bestätigung, und Entfernen des Tunnels in Reaktion auf eine positive Bestätigung.
Paketvermitteltes Telekommunikationssystem, umfassend einen Supportknoten (SGSN), der den Teilnehmer des Telekommunikationssystems bedient, einen ersten und einen zweiten Gateway-Supportknoten (GGSN1, GGSN2, GGSN3), dadurch gekennzeichnet, dass in Reaktion auf die Erfüllung einer vordefinierten Bedingung, durch die bestimmt werden kann, ob der zweite Gateway-Supportknoten zum Übertragen von Paketen geeigneter ist als der erste Gateway-Supportknoten, der erste Gateway-Supportknoten (GGSN1) dazu eingerichtet ist, den zweiten Gateway-Supportknoten zu empfehlen, durch Senden einer ersten Nachricht an den bedienenden Supportknoten (SGSN), die den zweiten Gateway-Supportknoten (GGSN2, GGSN3) angibt, der zum Übertragen von Paketen geeigneter ist, und in Reaktion auf das Empfangen der ersten Nachricht der bedienende Supportknoten (SGSN) eingerichtet ist, den Aufbau des Tunnels zu aktivieren, der bei der Übertragung von Paketen mit dem angegebenen zweiten Gateway-Supportknoten (GGSN2, GGSN3) verwendet werden soll.
Telekommunikationssystem nach Anspruch 10, dadurch gekennzeichnet, dass das Telekommunikationssystem eine Datenbank (DB) umfasst, in der Informationen über die zweiten Gateway-Supportknoten (GGSN2, GGSN3), die für den ersten Gateway-Supportknoten (GGSN1) definiert sind, vorgehalten werden, und der erste Gateway-Supportknoten (GGSN1) eingerichtet ist, den am besten geeigneten zweiten Gateway-Supportknoten (GGSN2) aus der Datenbank abzurufen, wenn die vordefinierte Bedingung erfüllt ist.
Telekommunikationssystem nach Anspruch 10 oder 11, dadurch gekennzeichnet, dass der erste Gateway-Supportknoten (GGSN1) eingerichtet ist, mindestens eine vordefinierte Bedingung zu überprüfen, in Reaktion auf das Empfangen einer Nachricht, die einen Aufbau eines Tunnels anfordert, von dem bedienenden Supportknoten (SGSN).
Telekommunikationssystem nach Anspruch 10, 11 oder 12, dadurch gekennzeichnet, dass das Telekommunikationssystem einen Tunnel aufweist, der zum Übertragen von Paketen zwischen dem bedienenden Supportknoten (SGSN) und dem ersten Gateway-Supportknoten (GGSN1) verwendet wird, und der erste Gateway-Supportknoten (GGSN1) eingerichtet ist, eine Änderung von Betriebsbedingungen zu erkennen und mindestens eine der vordefinierten Bedingungen in Reaktion auf ein Erkennen der Änderung zu überprüfen.
Gateway-Supportknoten (GGSN1, GGSN2, GGSN3) eines Paketnetzes, der eingerichtet ist, mit dem Supportknoten (SGSN) zu kommunizieren, der einen Teilnehmer des Paketnetzes bedient, dadurch gekennzeichnet, dass, der Gateway-Supportknoten (GGSN1) eingerichtet ist, einen anderen Gateway-Supportknoten zu empfehlen, in Reaktion auf die Erfüllung einer vordefinierten Bedingung, durch welche ermittelt werden kann, ob ein anderer Gateway-Supportknoten zum Übertragen von Paketen geeigneter ist als der erste Gateway-Knoten, durch Senden einer ersten Nachricht an den bedienenden Supportknoten (SGSN), die den anderen Gateway-Supportknoten (GGSN2, GGSN3) angibt, der zum Übertragen von Paketen geeigneter ist.
Gateway-Supportknoten nach Anspruch 14, dadurch gekennzeichnet, dass der Gateway-Supportknoten (GGSN1) eingerichtet ist, mindestens eine vordefinierte Bedingung zu überprüfen in Reaktion auf das Empfangen einer Nachricht, die einen Aufbau eines Tunnels anfordert, von dem bedienenden Supportknoten (SGSN).
Gateway-Supportknoten nach Anspruch 14 oder 15, dadurch gekennzeichnet, dass ein Tunnel vorhanden ist, der zum Übertragen von Paketen zwischen dem Gateway-Supportknoten (GGSN1, GGSN2, GGSN3) und dem bedienenden Supportknoten (SGSN) verwendet wird, und der Gateway-Supportknoten (GGSN1, GGSN2, GGSN3) eingerichtet ist, eine Änderung von Betriebsbedingungen zu erkennen und mindestens eine vordefinierte Bedingung in Reaktion auf das Erkennen der Änderung zu überprüfen.
Supportknoten (SGSN), der einen Teilnehmer eines Paketnetzes bedient, welcher eingerichtet ist, mit mindestens einem ersten und einem zweiten Gateway-Supportknoten (GGSN1, GGSN2, GGSN3) des Paketnetzes zu kommunizieren, dadurch gekennzeichnet, dass der bedienende Supportknoten eingerichtet ist, in Reaktion auf die Adresse des zweiten Gateway-Supportknotens, die in einer Nachricht eingeschlossen ist, die von dem ersten Gateway-Supportknoten (GGSN1) empfangen wurde, einen Aufbau eines Tunnels, der zum Übertragen von Paketen verwendet wird, mit dem zweiten Gateway-Supportknoten (GGSN2, GGSN3) zu aktivieren.
Bedienender Supportknoten nach Anspruch 17, dadurch gekennzeichnet, dass er eingerichtet ist, den bestehenden Tunnel zu dem ersten Gateway-Supportknoten (GGSN1), in Reaktion auf die Aktivierung eines Tunnelaufbaus mit dem zweiten Gateway-Supportknoten (GGSN2, GGSN3) zu entfernen.
Bedienender Supportknoten nach Anspruch 17, dadurch gekennzeichnet, dass er eingerichtet ist, den bestehenden Tunnel zu dem ersten Gateway-Supportknoten (GGSN1) in Reaktion auf einen erfolgreichen Aufbau eines Tunnels zu dem zweiten Gateway-Supportknoten (GGSN2, GGSN3) zu entfernen.