-
Die
vorliegende Erfindung betrifft die Verwendung des mobilen Internetprotokolls
im UMTS-System (Universal Mobile Telephone System) und dem GPRS
(General Packet Radio System) und bezieht sich insbesondere auf
die Unterstützung
von Benutzermobilität
innerhalb des PLMN (Public Land Mobile Network-öffentliches Landfunknetz) mittels des
mobilen Internetprotokolls.
-
Bei
der schell wachsenden Verwendung des Internetprotokolls (IP) ist
ein wirkungsvolles Verfahren zur Unterstützung der Mobilität in UMTS
und GPRS durch Verwendung von durch die IETF (Internet Engineering
Task Force-Arbeitsgruppe zur Entwicklung und Koordinierung von Internet-Protokollen) entwickelten
Protokollen höchst
wünschenswert.
-
Gegenwärtig wird,
wenn sich ein Mobilsystem (MS) innerhalb des PLMN bewegt, seine
Mobilität
durch in RFC2002 (Request For Comments 2002) definierten Bewegungserkennungsalgorithmen
unterstützt.
Diese Algorithmen umfassen den Empfang von Mobil-IP-FA-Anzeigen (Foreign
Agent-Fremdagent) (d. h. von einem Mobilgerät zu einem Satz von Netzknoten
gesendete Nachrichten zum Anzeigen, daß das Mobilgerät an dieses
Netz angeschaltet ist). Um Funkressourcen zu sparen, ist es nicht
ratsam, solche Anzeigen periodisch zu jedem MS zu senden. Anderseits
steht zur Übertragung
der Anzeigen an alle MS kein gemeinsam genutzter Kanal zur Verfügung.
-
Es
ist eine Aufgabe der Erfindung, ein Verfahren und eine Vorrichtung
bereitzustellen, mit denen Anzeigen wirkungsvoll und mit minimaler
Weiterschaltungslatenzzeit zu einem MS gesendet werden können.
-
In
gegenwärtigen
Telekommunikationsnetzen wird Paketmobilität für GPRS im Telekommunikationsstandard
(TS) GSM03.60 definiert. Internetprotokoll-Mobilitätsunterstützung ist
für IETF
in RFC2002 definiert.
-
Als
Hintergrund wird auf eine Schrift von C. Perkins mit dem Titel „RFC2002:
IP Mobility Support" (RFC2002:
IP-Mobilitätsunterstützung) IETF RFC-Request
for Comments (Kommentaranforderung) Oktober 1996 (1996-10), XP002123919
Bezug genommen.
-
Aus
einer europäischen
Patentanmeldung
EP-A-0918417 ist
es bekannt, ein Verfahren zum Unterstützen von mobilem Internetprotokoll
in einem Paketfunksystem bei Bewegung eines Mobilsystems aus einem
ehemaligen Versorgungsgebiet in einen neuen Versorgungsgebiet und
Senden einer Versorgungsgebiet-Aktualisierungsnachricht zu einem
steuernden Netzknoten bereitzustellen.
-
Gegenüber der
Offenbarung von
EP-A-0918417 ist
die vorliegende Erfindung dadurch gekennzeichnet, daß das Funksystem
ein GPRS-System (General Packet Radio System) ist und der steuernde
Netzknoten auf den Empfang einer Versorgungsgebiet-Aktualisierungsvollendungsnachricht
durch Senden einer Mobil-Internetprotokoll-Agentenanzeige zum Mobilsystem
reagiert.
-
Die
Erfindung wird nur beispielhafterweise unter Bezugnahme auf die
beiliegenden Zeichnungen beschrieben, in denen:
-
1 das
GPRS-System schematisch darstellt;
-
2 ein
Einsatzszenario darstellt, das durch Anwendung der Erfindung implementiert
werden kann;
-
3 Nachrichtenaustausch
zwischen verschiedenen Teilen des UMTS während einer Versorgungsgebietaktualisierung
zwischen Internet-GPRS- Netzknoten
darstellt;
-
4 Nachrichtenaustausch
während
einer Internet internen GPRS-Netzknoten-Versorgungsgebietsaktualisierung darstellt;
und
-
5 den
Nachrichtenaustausch während einer
Standortänderung
des bedienenden Funknetz-Teilsystems darstellt.
-
In
der 1 ist ein Mobilsystem (MS) 12 im GPRS 10 über eine
Funkschnittstelle Um mit einer Funknetzsteuerung 14 verbunden,
die durch einen Dienstenetzknoten (SGSN-Serving GPRS Support Node) 16 und
einen Zugangsnetzknoten (GGSN-Gateway GPRS Support Node) 18 mit
dem Internet 20 verbunden ist. Das MS 12, die
RNC 14 und die GSN 16 und 18 stellen
ein öffentliches
Landfunknetz dar und der SGSN 16 kann mit einem GGSN 22 eines
anderen PLMN 24 verbunden sein.
-
2 zeigt
ein erwünschtes
Szenario für Mobil-IP-Paket-Einsatz in
UMTS/GPRS. Ein PLMN-Backbone 30 weist zwei GPRS-Netzknoten 32, 34 auf,
die jeweils einen Fremdagenten (FA) 36, 38 für Internet-Zugang
durch MIP-Tunnel 40, 42 bereitstellen.
Der erste MIP-Tunnel 40 läuft zu einem Heimatagenten
(HA) 44 des Internets 46, d. h. der Tunnel bietet
direkten Zugriff zum Internet. Der zweite Tunnel 42 läuft zu einem
HA 48 eines Privatnetzes oder Heimat-ISP (Internet Service
Provider) 50, d. h. er bietet Fernzugriff zum Netz.
-
Anwendung
der Erfindung erlaubt die Implementierung dieses fortgeschrittenen
Szenarios von MIP-Einsatz ohne Änderung
von TS GSM04.08 und TS UMTS 24.008 und mit minimalen Änderungen
an bestehenden GPRS-Standards.
-
TS
GSM04.08 beschreibt unter anderen Aspekten die GPRS-Mobilitätsverwaltung.
Auf ähnliche Weise
beschreibt TS UMTS 24.008 die UMTS-Mobilitätsverwaltung. Wenn sich eine
MS aus einem RA (Routing Area-Versorgungsgebiet) in ein anderes
RA bewegt, wird vom MS eine RA-Aktualisierungsprozedur
als Teil der Mobilitätsverwaltung
durchgeführt. Dieses
Protokoll wird zwischen den MS 12 und dem SGSN 16 benutzt.
-
Die
Sitzungsaktivierung und Anfangsregistrierung sind vollständig mit
dem Fall identisch, in dem der FA an einem GGSN plaziert ist (Bezugnahme
T docs2m99036). Zur Implementierung der Erfindung wird angenommen,
daß jeder
Internet-GSN (ISGN) mit einem FA ausgerüstet ist. Der Internet-GSN
kann ein Dienste-GSN sein, der sich anders verhält, wenn von dem in der PDP-Kontextaktivierungsanforderung (Packet
Data Protocol) oder in den Subskriptionsdaten angegebenen Zugangspunktknoten
(APN – Access
Point Node) Mobil-IP-Betriebsweise
ausgewählt wird.
Anstatt eine PDP-Kontextaktivierungsanforderung
zum GGSN zu senden, wird vom IGSN eine PDP-Kontexterstellungsantwort
zum mobilen Endgerät
gesendet und ein FA zum Senden der Anzeige zu dem die Aktivierung
einer Sitzung anfordernden Mobilgerät angestoßen, auf die gleiche Weise,
wie es geschieht, wenn sich der FA am GGSN befindet.
-
Der
Unterschied bezüglich
des Falls, wo sich der FA an einem nicht am gleichen Standort wie
der SGSN befindlichen GGSN befindet, besteht darin, daß Mobilität zwischen
IGSN durch Mobil-IP behandelt wird, mit der wahlweisen Unterstützung bestehender
SGSN-spezifischer
Funktionalität
zum Übertragen
von Paketen von einem IGSN zu einem anderen bei einer Weiterschaltung.
-
In
einer unten stehenden Beschreibung, in der RA-Aktualisierungsverfahren beschrieben
sind, wird der Ansatz zum Hervorheben der Unterschiede bezüglich aktueller
Spezifikationen, insbesondere GSM TS03.60, gewählt.
-
Der
Empfang einer RA-Aktualisierungsnachricht am SGSN 16 kann
zum Auslösen
einer MIP-Agentenanzeige auf den Verkehrskanälen der die RA-Aktualisierung
durchführenden
MS benutzt werden. Auf diese Weise können bestehende MIP-Bewegungserkennungsalgorithmen
zur Erkennung der Änderung
von FA benutzt werden.
-
Eine Änderung
von FA kann mit dem Eintritt in ein neues RA verbunden sein. Ein
neues RA kann durch unterschiedlich große FA abgedeckt sein oder nicht.
Unterschiedlichen SGSN zugeordnete RA sind notwendigerweise unterschiedlichen
FA zugeordnet. Zum gleichen SGSN gehörende RA können in Abhängigkeit von der Wahl von Netzbetreiber
unterschiedlichen FA zugeordnet sein.
-
Nunmehr
auf 3 Bezug nehmend nehme man an, daß sich ein
MS 60 so bewegt, daß es
aus dem Gebiet eines alten Internet-GSN 62 in das Gebiet
eines neuen Internet-GSN 64 wechselt.
Das Heimatregister (HLR – Home
Location Register) 66 und der Heimatagent 68 des
MS 60 sind ebenfalls an der in der Figur gezeigten Nachrichtenübermittlung
beteiligt.
-
SCHRITT 1
-
Vom
MS 60 wird eine Versorgungsgebiet-Aktualisierungsanforderung
(die alte RAI (Routing Area Identity-Versorgungsgebietkennung)) alte P-TMSI-Signatur
(Packet Temporary Mobile Subscriber Identity-Temporäre Paketfunkkennung
des Teilnehmers), Update type (Aktualisierungsart) zum neuen SGSN 62 gesendet.
Die Aktualisierungsart zeigt an, ob die RA-Aktualisierung periodisch
oder nicht ist: periodische Aktualisierungen geschehen in regelmäßigen Zeitabständen, die
nichtperiodischen bei RA-Grenzüberquerung)
oder eine periodische RA-Aktualisierung. Von dem dem alten SGSN 62 zugeordneten
Basisstationssystem (BSS) wird die Cell Global Identity (globale
Identität
der Zelle) einschließlich
des RAC (Routing Area Code-Versorgungsgebietscode)
und des LAC (Location Area Code- Aufenthaltsbereichscode)
der Zelle, von der die Nachricht empfangen wurde, hinzugefügt, ehe
es die Nachricht zum neuen SGSN 64 weitergibt.
-
SCHRITT 2
-
Vom
neuen SGSN 64 wird eine SGSN-Kontextanforderung (die alte
RAI, die TLLI (Temporary Link Layer Identity- temporäre Sicherungsschichtkennung),
die alte P-TMSI-Signatur,
die neue SGSN-Adresse) zum alten SGSN 62 gesendet, um die
MM-(Mobility Management-Mobilitätsverwaltung) und
PDP-(Packet Data Protocol-Paketdatenprotokoll-)Kontexte
für das
MS 60 zu erhalten. Vom alten SGSN 62 wird die
alte P-TMSI-Signatur
validiert und mit einer zutreffenden Fehlerursache geantwortet, wenn
sie nicht dem im alten SGSN 62 gespeicherten Wert entspricht.
Dadurch wird eine Sicherheitsfunktion im neuen SGSN 64 eingeleitet.
Wenn das MS 69 korrekt von den Sicherheitsfunktionen authentifiziert wird,
wird vom neuen SGSN 64 eine SGSN-Kontextanforderungsnachricht (alte RAI,
TLLI, MS validiert, neue SGSN-Adresse) zum alten SGSN 62 gesendet. Der
Einschluß von
MS validiert zeigt an, daß das
MS 60 vom neuen SGSN 64 authentifiziert worden
ist. Wenn die alte P-TMSI-Signatur gültig war oder wenn der neue
SGSN 64 anzeigt, daß er
das MS 60 authentifiziert hat, antwortet der alte SGSN 62 mit SGSN-Kontextantwort
(MM-Kontext, PDP-Kontexte, LLC-Ack (Bestätigung der logischen Sicherungsschicht)).
Wenn das MS 60 im alten SGSN 62 nicht bekannt
ist, antwortet der alte SGSN mit einer zutreffenden Fehlerursache.
Vom alten SGSN wird die neue SGSN-Adresse gespeichert, damit der
alte SGSN Datenpakete zum neuen SGSN weiterleiten kann. LLC Ack
enthält
die Bestätigungen
für jede durch
das MS 60 benutzte LLC-Verbindung. Jeder PDP-Kontext enthält die GTP-Folgenummer
(GPRS Tunneling Protocol-GPRS-Tunnelprotokoll)
für die nächste zum
MS 60 zu sendende Abwärts-N-PDU (Network
layer Protocol Data Unit-Vermittlungsschicht-Protokolldateneinheit)
und die GTP-Folgenummer
für die
nächste über einen
Mobil-IP-Tunnel zum HA zu tunnelnde Aufwärts-N-PDU; wieder auf 2 Bezug
nehmend kann der Mobil-IP-Tunnel entweder der Tunnel 40 oder
der Tunnel 42 sein. Vom alten SGSN 62 wird ein
Zeitgeber gestartet und die Übertragung
von N-PDU zum MS 60 angehalten.
-
SCHRITT 3
-
Es
können
Sicherheitsfunktionen ausgeführt werden.
Diese Verfahren sind standardmäßig. Wenn Verschlüsselung
unterstützt
wird, wird Verschlüsselungsmodus
eingestellt.
-
SCHRITT 4
-
Vom
neuen SGSN 64 wird eine SGSN-Kontextbestätigungsnachricht
zum alten SGSN 62 gesendet. Damit wird der alte SGSN darüber informiert, daß der neue
SGSN zum Empfang von zu den aktivierten PDP-Kontexten gehörenden Datenpaketen bereit
ist. Vom alten SGSN 62 wird in seinem Kontext markiert,
daß die
MSC-VLR-Zuordnung (Mobile Switching Centre-Mobilvermittlungsstelle,
Visitor Location Register-Besuchsregister) und die Informationen im
HLR beteiligt sind. Dadurch wird die Datierung von MSC/VLR und dem
HLR ausgelöst,
wenn vom MS 60 vor Abschluß des laufenden Versorgungsgebiet-Aktualisierungsverfahrens
ein Versorgungsgebiet-Aktualisierungsverfahren
zurück
zum alten SGSN 62 eingeleitet wird. Wenn die Sicherheitsfunktionen
das MS 60 nicht korrekt authentifizieren, wird die Versorgungsgebietsaktualisierung
zurückgewiesen
und vom neuen SGSN 64 eine Zurückweisungsanzeige zum alten
SGSN 62 gesendet. Der alte SGSN 62 macht weiter,
als wenn die SGSN-Kontextanforderung nie empfangen wurde.
-
SCHRITT 5
-
Vom
alten SGSN 62 werden die gepufferten N-PDU dupliziert und
begonnen, sie zum neuen SGSN 64 zu tunneln. Zusätzliche,
vor Ablauf des im Schritt 2 beschriebenen Zeitgebers empfangene N-PDU
werden ebenfalls dupliziert und zum neuen SGSN getunnelt. N-PDU, die bereits
zum MS 60 gesendet wurden und vom MS noch nicht bestätigt worden
sind, werden zusammen mit der Nummer des LLC-Rahmens getunnelt,
der das letzte Segment der N-PDU übertrug. Nach Ablauf des im
Schritt 2 beschriebenen Zeitgebers werden keine N-PDU zum neuen
SGSN weitergeleitet.
-
SCHRITT 6
-
Vom
neuen SGSN 64 wird das HLR 66 durch Senden von
Update Location (Standortaktualisierung) (SGSN-Nummer, SGSN-Adresse,
IMSI) zum HLR über
den SGSN-Wechsel informiert.
-
SCHRITT 7
-
Vom
HLR 66 wird Cancel Location (Standort löschen) (IMSI, Cancellation
Type-Löschungsart) zum
alten SGSN 62 gesendet, wobei Cancellation Type auf Update
Procedure gesetzt ist. Wenn der in Schritt 2 beschriebene Zeitgeber
nicht läuft,
werden vom alten SGSN die MM- und PDP-Kontexte entfernt.
-
Ansonsten
werden die Kontexte nur bei Ablauf des Zeitgebers entfernt. Dadurch
kann der alte SGSN die Weiterleitung von N-PDU abschließen. Auch
wird sichergestellt, daß die
MM- und PDP-Kontexte im alten SGSN aufbewahrt bleiben, sollte das MS 60 vor
Abschluß der
laufenden Versorgungsgebietsaktualisierung zum neuen SGSN eine weitere Versorgungsgebietsaktualisierung
zwischen SGSN einleiten. Der alte SGSN bestätigt mit Cancel Location Ack
(Bestätigung
Standortlöschung)
(IMSI).
-
SCHRITT 8
-
Vom
HLR 66 wird Insert Subscriber Data (Teilnehmerdaten einfügen) (IMSI,
GPRS subscription data-GPRS-Subskritptionsdaten)
zum neuen SGSN 64 gesendet. Vom neuen SGSN wird die Gegenwart
des MS im (neuen) RA validiert. Wenn das MS aufgrund regionaler
Subskription abgewiesen wird, wird vom neuen SGSN 64 die
Versorgungsgebiet-Aktualisierungsanforderung mit entsprechender Ursache
zurückgewiesen
und eine Nachricht Insert Subscriber Data Ack (Bestätigung Teilnehmerdaten einfügen) (IMSI,
SGSN Area Restricted Due To Regional Subskription-SGSN-Bereich begrenzt
aufgrund regionaler Subskription) zum HLR 66 zurückgesendet.
Wenn alle Prüfungen
erfolgreich sind, dann wird vom SGSN ein MM-Kontext für das MS
aufgebaut und eine Nachricht Insert Subscriber Data Ack (Bestätigung Teilnehmerdaten
einfügen)
(IMSI) zum HLR zurückgesendet.
-
SCHRITT 9
-
Vom
HLR 66 wird die Update Location (Standortaktualisierung)
durch Senden von Update Location Ack (Bestätigung Standort aktualisieren) (IMSI)
zum neuen SGSN 64 bestätigt.
-
SCHRITT 10
-
Vom
neuen SGSN 64 wird die Gegenwart des MS im neuen RA validiert.
Wenn aufgrund regionaler, nationaler oder internationaler Beschränkungen
das MS sich nicht im RA anschalten darf oder Subskriptionsüberprüfung fehlschlägt, dann
wird vom neuen SGSN die Versorgungsgebietsaktualisierung mit zutreffender
Ursache zurückgewiesen.
Wenn alle Prüfungen
erfolgreich sind, dann werden vom neuen SGSN MM- und PDP-Kontexte für das MS
aufgebaut. Zwischen dem neuen SGSN und dem MS wird eine logische
Verbindung hergestellt. Der neue SGSN antwortet dem MS mit Routing
Area Update Accept (Annahme Versorgungsgebietsaktualisierung) (P-TMSI,
LLC Ack, P-TMSI-Signatur). LLC Ack enthält die Bestätigungen für jede durch das MS benutzte
LLC-Verbindung,
womit die erfolgreiche Übertragung
aller aus Mobilgeräten
stammenden N-PDU vor Beginn des Aktualisierungsverfahrens bestätigt werden.
-
SCHRITT 11
-
Vom
MS 60 wird die neue P-TMSI mit einer Routing Area Update
Complete (Versorgungsgebietsaktualisierung abgeschlossen) (P-TMSI,
LLC Ack) bestätigt.
LLC Ack enthält
die Bestätigungen
für jede vom
MS benutzte LLC-Verbindung,
wodurch alle am Mobilgerät
endenden vor Beginn des Aktualisierungsverfahrens erfolgreich übertragenen
N-PDU bestätigt
werden. Wenn durch LLC Ack der Empfang von N-PDU bestätigt wird,
die vom alten SGSN weitergeleitet wurden, dann werden diese N-PDU
durch den neuen SGSN verworfen. LLC und SNDCP im MS werden lokal
rückgesetzt.
-
SCHRITT 12
-
Über die
neu aufgebaute Verbindung zum Mobilgerät wird eine Mobil-IP-Agentenanzeige
einschließlich
von Abfrage/Antwort und NAI-Erweiterungen gesendet. Dies wird auf
irgendeine zweckdienliche Weise ausgelöst und ist implementierungsabhängig. Die
Anzeige wird nur zu dem die RA-Aktualisierung durchführenden
Mobilgerät
(d. h. MS 60) gesendet. Sie wird so gesendet, daß der von
der Mobil-IP-Spezifikation [RFC2002] vorgeschlagene Subnetzpräfix basierende
Bewegungserkennungsalgorithmus eine sofortige Mobil-IP-Registrierung
auslöst (d.
h. durch Sicherstellung, daß keine
zwei FA im PLMN Anzeigen mit identischen Subnetzpräfixen senden).
-
SCHRITT 13
-
Es
wird die normale MIP-Registrierung durchgeführt. Dies wird entsprechend
in der Registrierung ausgehandelten Zeitgebern periodisch wiederholt,
um die MIP-Sitzung am Leben zu halten. Im Falle einer zurückgewiesenen
Versorgungsgebiet-Aktualisierungsoperation
aufgrund von Versorgungsgebietsbeschränkungen wird vom neuen SGSN
kein MM-Kontext aufgebaut. Eine Zurückweisung wird zum MS 60 mit
zutreffender Ursache zurückgesendet.
Vom MS wird keine neue Versorgungsgebietsaktualisierung zu diesem
RA versucht. Der RAI-Wert wird bei Einschalten des MS gelöscht. Wenn
der im Schritt 2 beschriebene Zeitgeber abläuft und vom HLR keine Cancel
Location (Standort löschen)
(IMSI) empfangen wurde, dann werden vom alten SGSN keine weiteren
N-PDU zum neuen SGSN weiter geleitet. Wenn das Versorgungsgebiet-Aktualisierungsverfahren
eine maximale zulässige
Anzahl von Malen versagt oder wenn vom SGSN eine Nachricht Routing
Area Update Reject (Cause) (Zurückweisung
Versorgungsgebietsaktualisierung (Ursache)) zurückgesendet wird, wird das MS
veranlaßt,
in den IDLE-Zustand (Ruhezustand) einzutreten.
-
4 zeigt
die einfachere Nachrichtenübermittlung,
die bei Durchführung
einer IGSN-internen Versorgungsgebietsaktualisierung zutreffend
ist.
-
SCHRITT 1
-
Vom
MS 60 wird eine Routing Area Update Request (Versorgungsgebiet-Aktualisierungsanforderung)
(alte RAI, alte P-IMSI-Signatur, Aktualisierungstyp) zum SGSN 62 gesendet.
Aktualisierungstyp zeigt RA-Aktualisierung
an. Von dem SGSN 62 zugeordneten BSS wird die globale Identität der Zelle
einschließlich
des RAC und LAC der Zelle, wo die Nachricht vor Weiterleitung der
Nachricht zum SGSN empfangen wurde, hinzugefügt, siehe GSM 08.18.
-
SCHRITT 2
-
Es
können
Sicherheitsfunktionen ausgeführt werden.
Diese Verfahren sind standardgemäß.
-
SCHRITT 3
-
Vom
SGSN 62 wird die Gegenwart des MS im neuen RA validiert.
Wenn das MS aufgrund von regionalen, nationalen oder internationalen
Beschränkungen
sich nicht im RA anschalten darf oder Subskriptionsüberprüfung versagt,
wird vom SGSN die Versorgungsgebietsaktualisierung mit zutreffender
Ursache abgewiesen. Wenn alle Prüfungen
erfolgreich sind, wird vom SGSN der MM-Kontext für das MS aktualisiert. Es kann
eine neue P-TMSI zugeteilt werden. Zum MS 60 wird eine
Routing Area Update Accept (Annahme Versorgungsgebietsaktualisierung)
(P-TMSI, P-TMSI-Signatur)
zurückgesendet.
-
SCHRITT 4
-
Wenn
P-TMSI neu zugeteilt wurde, wird vom MS die neue P-TMSI mit Routing
Area Update Complete (Versorgungsgebietsaktualisierung abgeschlossen)
(P-TMSI) bestätigt.
-
SCHRITT 5
-
Wenn
das neue Versorgungsgebiet der Domäne eines neuen FA unterliegt,
(z. B. aus Lastteilungsgründen),
dann wird eine Mobil-IP-Agentenanzeige einschließlich von Abfrage-/Antwort-
und NAI-Erweiterungen gesendet. Dies wird auf eine beliebige zweckdienliche
Weise ausgelöst
und ist implementierungsabhängig.
Sie wird nur zu dem die RA-Aktualisierung durchführenden Mobilgerät (d. h. MS 60)
gesendet. Sie wird so gesendet, daß von dem durch die Mobil-IP-Spezifikation
[RFC2002] vorgeschlagenen Subnetzpräfix basierenden Bewegungserkennungsalgorithmus
eine sofortige Mobil-IP-Registrierung
ausgelöst
wird (d. h. durch Sicherstellung, daß keine zwei FA in PLMN Anzeigen
mit identischen Subnetzpräfixen
senden).
-
SCHRITT 6
-
Es
wird die regelrechte MIP-Registrierung durchgeführt. Dies wird entsprechend
in der Registrierung ausgehandelten Zeitgebern periodisch wiederholt,
um die MIP-Sitzung am Leben zu halten.
-
Wenn
das Versorgungsgebiet-Aktualisierungsverfahren eine maximal zulässige Anzahl
von Malen versagt oder wenn vom SGSN eine Nachricht Routing Area
Update Reject (Cause) (Rückweisung Versorgungsgebietsaktualisierung
(Ursache)) zurückgesendet
wird, tritt das MS 60 in den IDLE-Zustand (Ruhezustand)
ein.
-
Die
Lebensdauer der MIP-Registrierung sollte auf einen Wert >> periodisches RA-Aktualisierungsinterval
(Zeitgeber T3312) gesetzt werden, so daß die Notwendigkeit zum Senden
von MIP-Registrierung nicht häufiger
als periodische RA-Aktualisierungen entsteht.
-
Die
Lebensdauer einer MIP-Anzeige sollte ebenfalls auf einen Wert >> T3312 gesetzt werden, so daß Registrierungsversuche
nicht häufiger
als periodische RA-Aktualisierungen sind (eine kurze Anzeigenlebensdauer
kann das Senden von vielen Anzeigen über die Luft erfordern oder
kann sonst das Mobilgerät
zur häufigen
Neuregistrierung anstoßen, da
der Lebensdauer basierende Bewegungserkennungsalgorithmus ausgelöst werden
könnte).
Periodische RA-Aktualisierungen
sollten nicht MIP-Registrierungen auslösen.
-
Man
betrachte nunmehr einen Standortwechsel eines bedienenden Funknetz-Teilsystems (SRNS – Serving
Radio Network Subsystem) im UMTS. Wenn sich das Mobilgerät im Ruhemodus
befindet, funktionieren die für
GPRS definierten Verfahren auf die gleiche Weise im UMTS. Wenn sich
das Mobilgerät
im verbundenen Zustand befindet, findet das in 5 dargestellte
SRNS-Standortänderungsverfahren
statt. Wenn das Wort „SGSN" benutzt wird, wird
es zum Anzeigen einer Funktionalität und nicht eines physikalischen
Knotens benutzt.
-
SCHRITT 1
-
Von
UTRAN (Bezugsziffer 14 in der 1) wird
die Entscheidung getroffen, das SRNC-Standortänderungsverfahren (Serving
Radio Network Control – bedienende
Funknetzsteuerung) durchzuführen. Dazu
gehört
die Entscheidung, in welche RNC (Ziel-RNS 74) die Funktionalität bedienende
RNC umzulegen ist. Von der Ursprungs-SRNC 72 werden Nachrichten
SRNC Reloction required (Standortänderung SRNC erforderlich)
zum SGSN 76 gesendet. Diese Nachricht enthält Parameter
wie beispielsweise Ziel-RNC-Kennung und ein Informationsfeld, das transparent
zur Ziel-RNC weitergeleitet wird.
-
SCHRITT 2
-
Bei
Empfang der Nachricht SRNC Relocation required (SRNC-Standortänderung
erforderlich) bestimmt der SGSN 76 aus den empfangenen
Informationen, daß die
SRNC-Standortänderung
(im vorliegenden Beispiel) eine Änderung
von SGSN ergeben wird. Vom SGSN wird dann eine Forward SRNC Relocation
Request (Weiterleiten SRNC-Standortänderungsanforderung)
im zutreffenden SGSN, SGSN 78, mit den von der Ursprungs-RNC 72 empfangenen Informationen
und notwendigen Informationen zur Änderungen von SGSN (z. B. MM-Kontext, PDP-Kontext)
gesendet.
-
SCHRITT 3
-
Vom
SGSN 78 wird eine Nachricht SRNC-Relocation Request (SRNC-Standortänderungsanforderung)
zur Ziel-RNC 74 gesendet. Die Nachricht enthält Informationen
zum Aufbauen des von der Ursprungs-RNC 72 transparent gesendeten SRNC-Kontext
(z. B. UE-Kennung, Anzahl verbundener CN-Knoten, UE-Fähigkeitsinformationen)
und Anweisungen zum Aufstellen von Transportträgern auf der Iu-Benutzerebene.
Wenn die Transportträger auf
der Iu-Benutzerebene
hergestellt worden sind und die Ziel-RNC ihre Vorbereitungsphase
abgeschlossen hat, wird die Nachricht SRNC Relocation Proceeding
1 (SRNC-Standortänderung
im Gang 1) zum SGSN 78 gesendet.
-
SCHRITT 4
-
Wenn
die Verkehrsressourcen zwischen der Ziel-RNC 74 und den
SGSN 78 zugeteilt worden sind und der SGSN 78 für die SRNC-Verlegung
bereit ist, dann wird die Forward SRNC Relocation Response (SRNC-Standortänderungsantwort
weiterleiten) vom SGSN 78 zum SGSN 76 gesendet.
Diese Nachricht zeigt an, daß notwendige
Ressourcen für
die SRNC-Standortänderung
zugeteilt worden sind.
-
SCHRITT 5
-
Wenn
die Forward SRNC Relocation Response (SRNC-Standortänderungsantwort weiterleiten)
im SGSN 76 empfangen worden ist, wird vom SGSN 76 der
Abschluß der
Vorbereitungsphase an der CN-Seite für die SRNC-Standortänderung durch Senden der Nachricht
SRNC-Relocation
Proceeding 2 (SRNC-Standortänderung
im Gang 2) zur Ursprungs-RNC 72 angezeigt.
-
SCHRITT 6
-
Wenn
die Ursprungs-RNC 72 die Nachricht SRNC-Relocation Proceeding
2 (SRNC-Standortänderung
im Gang 2) empfangen hat, wird von der Ursprungs-RNC eine Nachricht
SRNC Relocation Commit (SRNC-Standortänderung festgelegt) zur Ziel-RNC 74 gesendet.
Von der Ziel-RNC wird Umschalten für alle Träger zum frühesten geeigneten Zeitaugenblick
ausgeführt.
-
SCHRITT 7
-
Sofort
nach erfolgreicher Umschaltung an der RNC sendet die Ziel-RNC (=SRNC)
die Nachricht SRNC Relocation Complete (SRNC-Standortänderung
abgeschlossen) zum SGSN 78. Vom SGSN wird auch eine Complete
SRNC Relocation (vollständige SRNC-Standortänderung)
zum SGSN 76 gesendet.
-
SCHRITT 8
-
Bei
Empfang von Complete SRNC Relocation wird vom SGSN 76 eine
Freigabeanzeige zur Ursprungs-RNC gesendet. Dies bedeutet die Freigabe aller
UTRAN-Ressourcen
bezüglich
dieser UE.
-
Mip
1: Über
die neu aufgebaute Verbindung zum Mobilgerät (die Ziel-RNC wirkt nunmehr
als SRNS) wird eine Mobil-IP-Agentenanzeige einschließlich von
Abfrage/Antwort und NAI-Erweiterungen gesendet. Dies wird auf jede
zweckdienliche Weise ausgelöst
und ist implementierungsabhängig. Sie
wird nur zu dem die SRNS-Standortänderung durchführenden
Mobilgerät
(d. h. MS 70) gesendet. Sie wird so gesendet, daß durch
den von Mobil-IP-Spezifikation [RFC2002] vorgeschlagenen Subnetzpräfix basierenden
Bewegungserkennungsalgorithmus eine sofortige Mobil-IP-Registrierung ausgelöst wird
(d. h. durch Sicherstellung, daß keine zwei
FA im PLMN Anzeigen mit identischen Subnetzpräfixen senden).
-
Wenn
die Ziel-RNC als Mip 2 wirkt: es wird die normale MIP-Registrierung
durchgeführt.
Dies wird periodisch gemäß in der
Registrierung ausgehandelten Zeitgebern wiederholt, um die MIP-Sitzung am
Leben zu halten.
-
SCHRITT 9
-
Von
der SRNC werden neue MM-Systeminformationen zur UE gesendet, die
z. B. relevantes Versorgungsgebiet und Standortbereich anzeigen. Zusätzliche
RRC-Informationen können
dann auch zur UE gesendet werden, z. B. neue RNTI-Identität.
-
SCHRITT 10
-
Vom
SGSN 78 wird das HLR 80 über die Änderung von SGSN durch Senden
von Update GPRS location (GPRS-Standort aktualisieren) (IMSI, neue SGSN-Adresse
usw.) zum HLR informiert. Vom HLR wird der Kontext im alten SGSN,
SGSN 76, durch Senden von Cancel Location (Standort löschen) (IMSI)
gelöscht.
Vom SGSN 76 wird der Kontext entfernt und mit Cancel Location
Ack (Standord löschen
Ack) bestätigt.
Vom HLR 80 wird Insert subscriber data (Teilnehmerdaten
einfügen)
(IMSI, Subskriptionsdaten) zum SGSN 78 gesendet. Der SGSN 78 bestätigt mit
Insert Subscriber Data Ack (Teilnehmerdaten einfügen Ack). Vom HLR wird der
Update GPRS location (GPRS-Standort aktualisieren) durch Senden
von Update GPRS Location Ack zum SGSN 78 bestätigt.
-
SCHRITT 11
-
Bei
Empfang von Insert subscriber data (Teilnehmerdaten einfügen) vom
HLR 80 wird vom SGSN 78 die Aktualisierung von
im MS 70 gespeicherten MM-Informationen eingeleitet. Dies geschieht
durch Senden des Befehls Network Initiated Routing Area Update (vom Netz
eingeleitete Versorgungsgebietsaktualisierung) zum MS 70.
Diese Nachricht enthält neue
RAI und möglicherweise
auch neue P-TMSI. Wenn das MS 70 die notwendigen Aktualisierungen durchgeführt hat,
antwortet es mit Network Initiated Routing Area Update Complete
(vom Netz eingeleitete Versorgungsgebietsaktualisierung abgeschlossen).
-
Von
den drei unter Bezugnahme auf 3, 4 und 5 beschriebenen
Verfahren kann jedes Verfahren auf einen der MIP-Tunnel 40, 42 in
der 2 angewandt werden.
-
Implementierung
der Erfindung erlaubt wirkungsvolle Nutzung von Funkressourcen und
bietet optimale Weiterschaltungsleistungen.