-
Gebiet der
Erfindung
-
Die
vorliegende Erfindung betrifft Telekommunikationssysteme zum Übertragen
von Internetpaketen zwischen einer Mobilkommunikationsbenutzervorrichtung,
welche einen korrespondierenden Knoten (correspondent node) bildet,
und einem mobilen Knoten (mobile node) über ein externes Paketdatenkommunikationsnetzwerk.
Insbesondere betrifft die vorliegende Erfindung Gateway-Unterstützungsknoten
zum Übertragen
von Internetpaketen zwischen einem externen Paketdatenkommunikationsnetzwerk
und einem Paketfunknetzwerk.
-
In
einer Ausführungsform
bildet der Gateway-Unterstützungsknoten
einen Gateway für
ein allgemeines Paketfunksystem- (General Packet Radio System, GPRS-)
Netzwerk, bekannt als ein GPRS-Gateway-Unterstützungsknoten (GPRS Gateway
Support Node, GGSN).
-
Hintergrund
der Erfindung
-
Der
allgemeine Paketfunknetzwerkdienst (GPRS) wurde zum effizienten
Kommunizieren von Datenpaketen zu und von mobilen Benutzervorrichtungen über ein
mobiles Funknetzwerk der zweiten Generation, wie zum Beispiel dem
Global system for Mobiles (GSM), oder für ein Funknetzwerk der dritten Generation,
wie zum Beispiel dem Universal Mobile Telekommunications System
(UMTS), entwickelt. GPRS liefert eine Unterstützung für einen paketorientierten Dienst,
welcher versucht Netzwerke und Funkressourcen für Paketdatenübertragung,
wie zum Beispiel Internetpakete (Internet Packets, IP) zu optimieren.
Der GPRS liefert eine logische Architektur, die mit der Schaltkreis
geschalteten Architektur des Mobilfunknetzwerks der zweiten oder
dritten Generation verwandt ist.
-
Im
allgemeinen ist das GPRS-Netzwerk mit einem weiteren Paketdatentelekommunikationsnetzwerk
verbunden, welches auch mit einem weiteren Paketdatentelekommunikationsnetzwerk
verbunden sein kann. Das Netzwerk, mit dem das GPRS-Netzwerk verbunden
ist, wird in der folgenden Beschreibung als ein externes Netzwerk
bezeichnet. Das GPRS-Netzwerk zum Kommunizieren von Daten zwischen
einer Mobilkommunikationsbenutzervorrichtung (mobile communications
user equipment UE) und dem externen Netzwerk weist auf: einen Gateway-Unterstützungsknoten
(gateway support node, GGSN), der eine Schnittstelle zwischen dem externen
Netzwerk und der Benutzervorrichtung bereitstellt. Das GPRS-Netzwerk
weist auch einen Dienstunterstützungsknoten
(service support node, SGSN) auf, der so betreibbar ist, dass er
eine Übertragung
von Datenpaketen zwischen den Gateway-Unterstützungsknoten und der Benutzervorrichtung
steuert, wobei eine Funknetzwerksteuerung (radio network controller,
RNC) verwendet wird, welche die Funkressourcen des Telekommunikationsnetzwerk
steuert.
-
Das
Internetprotokoll, welches von der Internet Engineering Task Force
(IETF) entwickelt wurde, hat sich zu einer bevorzugten Übertragungsweise von
Paketdaten über
Telekommunikationsnetzwerke entwickelt. Während Version 4 des Internetprotokolls (Ipv4)
standardisiert wurde und in vielen festen Netzwerken eingebaut wurde,
wird Version 6 des Internetprotokolls entwickelt, um verbesserte
Möglichkeiten bereitzustellen.
Unter diesen Verbesserungen ist eine Möglichkeit Internetpakete zu
und von mobilen Knoten zu überfragen,
welche während
einer IP-Sitzung von einem Heimatnetzwerk in ein Fremdnetzwerk wechseln
bzw. roamen [1]. Im allgemeinen werden, einem Prozess folgend, der
als Route-Optimierung bekannt ist, welche in Kürze beschrieben werden wird,
eine Quellen- und eine Zieladresse in der Kopfzeile des IP-Datenpakets, welches
von bzw. zu einem mobilen Knoten (mobile node MN) gesendet wird,
sich als Folge davon ändern,
dass der MN in das Fremdnetzwerk wechselt.
-
Der
mobile Knoten kann Internetpakete mit einem korrespondierenden Knoten
(CN) austauschen, der mit einem GPRS-Netzwerk verbunden ist. In
der Folge muss der GGSN des GPRS-Netzwerks so eingerichtet sein,
dass er die Internetpakete über einen
passenden Träger
an den korrespondierenden Knoten routet, welcher selbst mobil sein
kann. Wenn der mobile Knoten in der Mitte einer Sitzung in ein Fremdennetzwerk
wechselt, dann muss der GGSN so eingerichtet sein, dass er die Internetpakete über einen
entsprechenden Träger
an den korrespondierenden Knoten (mobile Benutzervorrichtung) routet. Der
entsprechende Träger
wird von dem GGSN eingerichtet, wenn ein Sitzungsbeginn zu einem
Zeitpunkt etabliert wurde, wenn der mobile Knoten mit seinem Heimatnetzwerk
verbunden war. Daher wurden die Parameter für den Träger in Bezug auf eine Heimatadresse
des mobilen Knotens als der Quellenadresse gebildet. Jedoch ändert sich
wie oben beschrieben die Quellenadresse in der Kopfzeile der Internetpakete
während
der Sitzung von der Heimatadresse des mobilen Knotens, wenn dieser
mit seinem Heimatnetzwerk verbunden ist, in eine Care-of-Adresse
nachdem der mobile Knoten in das Fremdnetzwerk gewechselt ist. Ohne
Anpassung wird der GGSN daher Internetpakete mit der Care-of-Adresse
des mobilen Knotens als Quellenadresse fallen lassen statt die Pakete über den
für die Heimatadresse
des mobilen Knotens gebildeten Träger an den korrespondierenden
Knoten zu routen.
-
Es
wurde zuvor vorgeschlagen, eine Heimatadresse des mobilen Knotens
in einem Erweiterungskopfzeilenfeld bereitzustellen, welches als
das Hop-by-Hop-Feld bekannt ist. Daher ist der GGSN in der Lage
den passenden Träger
zu identifizieren, mit welchem Internetpakete an einen korrespondierenden
Knoten (CN) geroutet werden können,
der mit dem GPRS-Netzwerk
verbunden ist, da die Heimatadresse des mobilen Knotens die Quellenadresse
bereitstellt, in Bezug auf die der passende Träger eingerichtet wurde. Im
allgemeinen verbleibt jedoch ein technisches Problem, das Zusammenarbeiten
zwischen dem Internetprotokoll, insbesondere aber nicht ausschließlich Ipv6,
und einem Paketfunksystem, wie zum Beispiel aber nicht aus ausschließlich dem GPRS,
zu verbessern.
-
Dokument
US 2002/049059 A1 von
Muhonen Ahti et al. offenbart den Oberbegriff der Ansprüche 1, 16
und 27.
-
Zusammenfassung
der Erfindung
-
Gemäß der vorliegenden
Erfindung wird ein Telekommunikationssystem zum Übertragen von Internetpaketen
zwischen einer Mobilkommunikationsbenutzervorrichtung, welche einen
korrespondierenden Knoten bildet, und einem mobilen Knoten über ein
externes Paketdatenkommunikationsnetzwerk bereitgestellt. Das System
weist ein Paketfunknetzwerk auf, das so betreibbar ist, dass eine
Mehrzahl von Paketdatenträgern
zum Übertragen
der Internetpakete an Knoten, die mit dem Paketfunknetzwerk verbunden
sind, bereitgestellt werden. Jeder der Träger ist in Bezug auf eine Quellenadresse
des Internetpakets definiert, wobei das Paketfunknetzwerk einen
Gateway-Unterstützungsknoten
(GGSN) aufweist, der so betreibbar ist, dass eine Schnittstelle zwischen
dem externen Netzwerk und dem Paketfunknetzwerk bereitgestellt wird.
Der Gateway-Unterstützungsknoten
(GGSN) ist so betreibbar, dass erfasst wird, ob ein Internetpaket
dazu dient, eine bindende Aktualisierung an den korrespondierenden Knoten
einer ersten Quellenadresse des mobilen Knotens mit einer Care-of-Adresse
des mobilen Knotens bereitzustellen und wenn das Internetpaket eine bindende
Aktualisierung ist, die Ausgabe der von dem korrespondierenden Knoten
gesendeten Internetpakete, welche die Care-of-Adresse des mobilen Knotens
als die Zieladresse von dem Gateway-Unterstützungsknoten an das externe
Netzwerk aufweisen, zugelassen wird.
-
Ausführungsformen
der vorliegenden Erfindung lösen
eine technische Aufgabe, welche mit einem möglichen Dienstdiebstahl verbunden
ist, der auftreten kann, wenn ein skrupelloser Benutzer einer Mobilkommunikationsbenutzervorrichtung
versucht, Ressourcen in einem Telekommunikationsnetzwerk, wie dem
GPRS-Netzwerk oder einem anderen Datenübertragungsnetzwerk, mit dem
das GPRS-Netzwerk verbunden ist, zu verwenden. Der Diebstahl eines
Dienstes kann auftreten, wenn der Benutzer eine nichtautorisierte
Zieladresse für
Internetpakete verwendet, die von der Mobilkommunikationsbenutzervorrichtung,
welche als korrespondierender Knoten arbeitet, gesendet wurden.
Eine nichtautorisierte Adresse kann zum Beispiel eine Adresse sein,
die verwendet werden kann, um Internetpakete zu übertragen, wobei Ressourcen
auf einem GPRS/UMTS-Netzwerk oder einem anderen Netzwerk verwendet
werden, für
welches der Benutzer sich nicht registriert hat. Um einen solchen
Diebstahl eines Dienstes zu verhindern, wird eine Sicherheitsfunktion
innerhalb des GGSN verwendet, die als dienstba sierte lokale Richtlinie
(Service Based Local Policy) bekannt ist, um ein Gate zu bilden
und die so eingerichtet ist, dass sie es Internetpaketen ermöglicht durch
den Gateway-Unterstützungsknoten
nach außen
zu passieren, wenn die Zieladresse autorisiert wurde.
-
Wie
oben erklärt
ist das Hop-by-Hop Erweiterungskopfzeilenfeld eines Ipv6-Pakets
so eingerichtet, dass es die Heimatadresse eines mobilen Knotens
einschließt,
welcher in ein fremdes Netzwerk gewechselt ist und daher eine Care-of-Adresse
als die Zieladresse für
Internetpakete aufweist, die von dem korrespondierenden Knoten gesendet
wurden. Um es berechtigten Datenpaketen zu ermöglichen in ein benachbartes
Telekommunikationsnetzwerk, mit dem der Gateway-Unterstützungsknoten
verbunden ist, zu passieren, ist der Gateway-Unterstützungsknoten so eingerichtet,
dass er das Hop-by-Hop-Feld sowie das Zieladressenfeld in der Internetpaketkopfzeile
untersucht. Wenn das Hop-by-Hop-Feld oder das Zieladressenfeld eine
berechtigte Adresse aufweist, dann wird es dem Internetpaket ermöglicht durch
den Gateway-Unterstützungsknoten
in ein externes Netzwerk zu passieren. Ein technisches Problem wird
dabei beim Reduzieren der Wahrscheinlichkeit eines Diebstahls eines
Service hervorgerufen, wenn der skrupellose Benutzer vorsieht, dass
Internetpakete eine nichtautorisierte Zieladresse in dem Zieladressfeld
aufweisen, während
sie die Heimatadresse des mobilen Knotens in dem Hop-by-Hop-Feld
aufweisen. Dies ist so, da die SBLP-Funktion in dem GGSN so eingerichtet
sein sollte, dass sie Internetpakete in einer Situation fallen lässt, in
der die Zieladresse nicht autorisiert ist, sogar wenn Hop-by-Hop-Feld
eine Heimatadresse eines mobilen Knotens aufweist, die berechtigt
ist.
-
Ausführungsformen
der vorliegenden Erfindung stellen ein Telekommunikationssystem
bereit, in dem der Gateway-Unterstützungsknoten so eingerichtet
ist, dass er eine Care-of-Adresse
eines mobilen Knotens in Verbindung mit der Heimatadresse dieses
mobilen Knotens identifiziert. Die Care-of-Adresse wird nach dem
Empfang einer bindenden Aktualisierungsnachricht, welche zur Route-Optimierung
benötigt
wird identifiziert. Die Care-of-Adresse des mobilen Knotens wird
dann der Sicherheitsfunktion des Gateway-Unterstützungsknotens zur Verfügung gestellt.
Um die Wahrscheinlichkeit eines Angriffs eines Diebstahls eines
Dienstes zu reduzieren, ist eine Sicherheitsfunktion in dem Gateway-Unterstützungsknoten
so eingerichtet, dass sie es Internetpaketen ermöglicht nur zu passieren, wenn
sowohl die Heimatadresse des mobilen Knotens in dem Hop-by-Hop-Feld
als auch die Care-of-Adresse des mobilen Knotens berechtigt sind. Zu
diesem Zweck kann der Gateway-Unterstützungsknoten die von einer
bindenden Aktualisierungsnachricht in Verbindung mit der Heimatadresse des
mobilen Knotens bereitgestellte Care-of-Adresse abspeichern.
-
Verschiedene
weitere Aspekte und Merkmale der vorliegenden Erfindung sind in
den beigefügten Ansprüchen definiert.
Die Erfindung stellt einen Gateway-Unterstützungsknoten gemäß Anspruch
16, ein Verfahren zum Übertragen
von Internetpaketen gemäß Anspruch
27 und Computerprogramme gemäß den Ansprüchen 36
und 37 und ein Computerprogrammpro dukt gemäß Anspruch 38 bereit, mit verschiedenen
Ausführungsformen
wie in den abhängigen
Ansprüchen
definiert.
-
Kurze Beschreibung
der Zeichnungen
-
Ausführungsformen
der vorliegenden Erfindung werden nun nur in Form eines Beispiels
gemäß den beiliegenden
Zeichnungen erklärt,
in denen gleiche Teile mit entsprechenden Bezugszeichen versehen
sind und in denen:
-
1 schematisch
eine Beispielarchitektur eines Mobilfunknetzwerks darstellt, das
so eingerichtet ist, dass es eine Paketdatenkommunikation unterstützt,
-
2 schematisch
einen mobilen Knoten zeigt, der mit einem korrespondierenden Knoten über ein
Heimatnetzwerk kommuniziert und der nach dem Roaming in ein Fremdnetzwerk
eine Route-Optimierungsprozedur ausführt,
-
3 schematisch
Beispielinternetpakete bei verschiedenen Stufen in der Route-Optimierungsprozedur
darstellt,
-
4 eine
schematische Darstellung von Teilen eines Funkpaketkommunikationsnetzwerks bereitstellt,
-
5 eine
schematische Darstellung der in 4 gezeigten
Teile ist, welche einen Betrieb eines Gateway-Unterstützungsknotens
darstellt, um Down-Link-Pakete an einen korrespondierenden Knoten
zu übertragen,
-
6 eine
schematische Darstellung der in 4 gezeigten
Teile ist, welche einen Betrieb des Gateway-Unterstützungsknotens
zeigt, um Up-Link-Pakete zu übertragen,
die das Paketfunknetzwerk verlassen,
-
7 eine
schematische Darstellung der in 4 gezeigten
Teile ist, welche einen Betrieb eines Gateway-Unterstützungsknotens
gemäß einer
Ausführungsform
der vorliegenden Erfindung darstellt und
-
8 ein
Flussdiagramm ist, welches den Betrieb des in 7 gezeigten
Gateway-Unterstützungsknotens
darstellt.
-
Beschreibung
der bevorzugten Ausführungsformen
-
Mobilfunkpaketnetzwerkarchitektur
-
Eine
Beispielarchitektur eines Paketfunknetzwerks, welches so eingerichtet
ist, dass es Paketdatenkommunikation unterstützt, ist in 1 gezeigt
und detaillierter in Anhang 1 be schrieben. Um das Verständnis und
die Erklärung
der Ausführungsformen
der vorliegenden Erfindung und der durch solche Ausführungsformen
bereitgestellten Vorteile zu erleichtern, wird hier eine kurze Beschreibung
gegeben. Das in 1 dargestellte Paketfunknetzwerk zeigt
eine Anordnung, die mit dem GPRS/UMTS-Standard übereinstimmt und ein Paketfunknetzwerk
zum Übertragen
von Internetdatenpaketen mit Knoten bereitstellt, die mit dem Netzwerk über terrestrische
Funkträger
verbunden sind, welche als UTRAN bezeichnet werden. Das Paketfunknetzwerk
weist einen Gateway-Unterstützungsknoten
(GGSN) auf, der so betreibbar ist, was er eine Schnittstelle zwischen
einem externen Netzwerk-PDN und den mit den GPRS/UMTS-Netzwerk verbundenen
Knoten bereitstellt. Da die Knoten miteinander über die UTRAN-Funkschnittstelle
kommunizieren, können
sie im allgemeinen Mobilknoten sein. Jedoch sind in der folgenden
Beschreibung die Mobilkommunikationsbenutzervorrichtungen (UE), die
mit dem Paketfunknetzwerk verbunden sind, als korrespondierende
Knoten CN bezeichnet. Wie gleich erklärt werden wird, stellt das GPRS/UMTS-Netzwerk
eine Mehrzahl von Paketdatenträger
zum Übertragen
von Internetpaketen von den GGSN an die entsprechenden Knoten CN
und von den korrespondierenden Knoten CN an das GGSN bereit. Typischerweise
wird es den durch den GGSN von den korrespondierenden Knoten empfangenen
Paketen ermöglicht,
das Paketfunknetzwerk zu dem externen Paketkommunikationsnetzwerk PDN
zu verlassen. Diese Pakete können
für andere Knoten
bestimmt sein, die mit dem externen Netzwerk PDN verbunden sind
oder die mit anderen Netzwerken verbunden sein können, wobei die Pakete diese
Knoten über
das externe Netzwerk PDN erreichen.
-
IP-Route-Optimierung
-
Route-Optimierung
ist bekannt als Teil des Internetprotokollstandards in der Version 6 (IPV6) und
sie kann für
einen Knoten ausgeführt
werden, der von einem Heimatnetzwerk in ein Fremdnetzwerk wechselt
bzw. roamed. Die Route-Optimierung ist ein Prozess, durch welchen
ein Knoten, der seine Zuordnung von einem Heimatnetzwerk in ein
Fremdnetzwerk ändert,
so eingerichtet werden kann, dass er Internetpakete zu und von dem
Knoten über
das Fremdnetzwerk überträgt ohne
dass sie über
das Heimatnetzwerk geroutet werden. Ein Knoten, der seine Zuordnung
durch Wechseln von seinem Heimatnetzwerk in ein Fremdnetzwerk ändert, wird
in der folgenden Beschreibung als ein mobiler Knoten bezeichnet.
-
Wie
in dem Internetprotokoll üblich,
stellen Knoten, die Internetpakete miteinander austauschen, die
Zieladresse sowie die Quellenadresse in der internetpaketkopfzeile
bereit. 2 stellt eine Abbildung eines
Route-Optimierungsprozesses zwischen einem korrespondierenden Knoten
CN, der mit einem GPRS-Netzwerk verbunden ist, und einem mobilen
Knoten MN dar. In 2 überträgt der korrespondierende Knoten
CN Internetpakete zu und von dem mobilen Knoten MN während der
MN des korrespondierenden Netzwerks einem GPRS/UMTS-Netzwerk 200 zugeordnet
ist. Wie durch zwei Positionen des mobilen Knotens MN 202, 204 dargestellt,
bewegt sich der mobile Knoten, der ursprünglich Internetpakete mit dem
korrespondierenden Netzwerk CN über
sein Heimatnetzwerk 210 übertragen hat, zu einem Fremdnetzwerk 212.
Daher übertrug
der mobile Knoten MN ursprünglich
Internetpakete über
seinen Heimatagenten Home Agent HA. Wenn sich der mobile Knoten
MN bei Position 202 aus dem Heimatnetzwerk 210 in
ein Fremdnetzwerk 212 bei Position 204 bewegt,
müssten
Internetpakete gemäß einem
konventionellen Betrieb nach Ipv4 über den Heimatagenten geroutet
werden. Mit anderen Worten würde
die Zieladresse für
Pakete, die an den mobilen Knoten MN gesendet wurden, seine Heimatadresse
sein und die Quellenadresse eines von dem mobilen Knoten MN gesendeten
Pakets würde
seine Heimatadresse sein. Daher müssten Internetpakete über das
Fremdnetzwerk 212 und das Heimatnetzwerk 210 an
und von dem korrespondierenden Knoten CN über das GPRS/UMTS-Netzwerk 200 geroutet
werden. Es ist offensichtlich, dass ein Routen von Paketen über den
Heimatagenten nachdem der mobile Knoten MN in das Fremdnetzwerk
gewechselt ist, unnötigerweise
Netzwerkressourcen verbraucht und darüber hinaus die Verzögerung bei
der Übertragung
der Internetpakete erhöht.
-
Wie
oben erwähnt
ist Route-Optimierung ein Prozess, durch den Internetpakete zwischen
dem korrespondierenden Knoten CN und dem mobilen Knoten MN übertragen
werden ohne, dass sie durch den Heimatagenten HA passieren müssen, wodurch die
zum Übertrage
der Internetpakete verwendeten Ressourcen reduziert werden. Typischerweise
wird eine Verzögerung
beim Übertragen
von Paketen ebenfalls reduziert.
-
2 und 3 stellen
gewissermaßen eine
Zusammenfassung der relevanten Teile des Route-Optimierungsprozesses
dar, die nützlich
sind beim Verständnis
der Ausführungsformen
der vorliegenden Erfindung, die in Kürze beschrieben werden. 3 stellt
eine beispielhafte Abbildung von Internetpaketkopfzeilen vor und
nach einer Route-Optimierung dar. In 3 stellt
das Internetpaket 300 eine Darstellung einer Internetpaket-
(IP-) Kopfzeile dar, die von dem mobilen Knoten MN, wenn er mit
dem Heimatnetzwerk an Position 202 verbunden ist, an den
korrespondierenden Knoten CN, wenn dieser mit dem GPRS-Netzwerk 200 verbunden
ist, gesendet werden soll. Die Internetpaketkopfzeile 300 weist
die Adresse des korresponierenden Knotens CN in einem Zielfeld 302 und
die Heimatadresse des mobilen Knotens (MN) in einem Quellenadressfeld 304 auf. Die
Internetpaketkopfzeile 300 weist auch ein weiteres Feld
auf, dass als das Hop-by-Hop-Feld 306 bekannt ist, welches
in Kürze
erklärt
wird. Die IP-Kopfzeile 300 für eine Übertragung von dem mobilen
Knoten (MN) zu dem korrespondierenden Knoten (CN) ist als ein Down-Link-Internetpaket
bekannt.
-
Für den Up-Link,
das heißt
von dem korrespondierenden Knoten CN zu dem mobilen Knoten MN, ist
eine Internetpaketkopfzeile 310 so gezeigt, dass sie in
dem Zielfeld 312 die Heimatadresse des mobilen Knotens
MN aufweist und in dem Quellenadressfeld 314 die Adresse
des korrespondierenden Knotens CN.
-
Nach
der Route-Optimierung gemäß einer Änderung
der Zuordnung des mobilen Knotens, muss der mobile Knoten MN den
korrespondierenden Knoten über
seine neue Adresse informieren. Die neue Adresse, das heißt die Adresse,
die verwendet werden muss, um über
das Fremdnetzwerk auf den mobilen Knoten MN zuzugreifen, ist als
die Care-of-Adresse bekannt. Um den korrespondierenden Knoten CN über die
Care-of-Adresse des mobilen Knotens MN zu informieren, sendet der
mobile Knoten MN dem korrespondierenden Knoten CN eine bindende
Aktualisierungsnachricht.
-
Ein
Beispiel für
eine bindende Aktualisierungsnachricht ist in 3 durch
eine Darstellung einer Internetpaketkopfzeile 320 gezeigt.
Wie zuvor das Zieladressfeld 322 enthält die IP-Kopfzeile 320 die Adresse des
korrespondierenden Knotens CN, wohingegen das Quellenadressfeld 324 die
Care-of-Adresse des mobilen Knotens MN verwendet. Ein erweitertes
Kopfzeilenfeld 326 stellt einen mobilen Kopfzeilentyp (Mobile
Header, MH) bereit mit einem Wert gleich „5", was bedeutet, dass das Internetpaket
eine bindende Aktualisierung bereitstellt. Das Nutzlastfeld 328 enthält den Wert
von „0". Das bindende Aktualisierungsinternetpaket 320 wird
von dem mobilen Knoten MN an den korrespondierenden Knoten CN gesendet.
-
Als
Reaktion auf die bindende Aktualisierung aktualisiert der korrespondierende
Knoten CN seinen Adress-Cash-Speicher, der in 2 als
ein Datenspeicher 220 gezeigt ist. Der Cash speichert die
Care-of-Adresse des mobilen Knotens MN in Verbindung mit der ursprünglichen
Heimatadresse des mobilen Knotens. Der korrespondierende Knoten
CN reagiert dann auf die bindende Aktualisierung 320 durch
Senden einer bindenden Aktualisierungsbestätigung in der Form einer Internetpaketkopfzeile 332. Die
bindende Aktualisierungsbestätigung 332 enthält die Care-of-Adresse
des mobilen Knotens MN in dem Zieladressfeld 334 und die
Adresse des korrespondierenden Knotens CN in dem Quellenadressfeld 336.
Die bindende Aktualisierungsbestätigungsnachricht
ist von der bindenden Aktualisierungsnachricht durch das MH-Typfeld zu unterscheiden,
das gleich „6" gesetzt ist, wie
in dem Erweiterungskopfzeilenfeld 338 gezeigt. Wieder enthält das Datenfeld
den Wert von „0".
-
Nach
der bindenden Aktualisierung enthält die Internetpaketkopfzeile
für den
Down-Link 350 nun die Care-of-Adresse des mobilen Knotens
MN in dem Quellenfeld 352. Entsprechend enthält das Zielfeld
des an den mobilen Knoten MN gesendeten Internetpaketes die Care-of-Adresse des mobilen
Knotens in der Internetpaketkopfzeile 360.
-
Sollte
der korrespondierende Knoten selbst seine Zuordnung entweder in
dem Netzwerk oder mit einem Fremdnetzwerk ändern, dann würde entsprechend
eine bindende Aktualisierung durch den korrespondierenden Knoten
CN ausgeführt.
Wie in 2 dargestellt wird dann der Adresscashspeicher
des mobilen Knotens 230 aktualisiert, so dass er die Care-of-Adresse
des korrespondierenden Knotens CN in Verbindung mit der Adresse
des korrespondierenden Kno tens CN enthält, mit der Wirkung, dass nachfolgende
Internetpakete die Care-of-Adresse des korrespondierenden Knotens
CN anstatt der Heimatadresse des korrespondierenden Knotens verwenden.
-
Verkehrsflussvorlage (Traffic
Flow Template; TFT basierende Paketfilterung an dem GGSN
-
Eine
beispielhafte Ausführungsform
der vorliegenden Erfindung wird nun gemäß 4 beschrieben,
welche Elemente zeigt, die einen Teil des GPRS/UMTS-Netzwerks bilden,
das in 2 dargestellt ist. In 4 ist ein
Gateway-Unterstützungsknoten
(GGSN) 400 zusammen mit einem dienenden GPRS-Unterstützungsknoten
(Serving GPRS Support Node; SGSN) 402 und einem Universal
Terrestrial Radio Access Network Teil (UTRAN) 404 gezeigt. Der
GGSN 400, der SGSN 402 und das UTRAN 404 bilden
einen Teil des Funkpaketnetzwerks, so wie es in 1 dargestellt
ist, zum Übertragen
von Datenpaketen zu und von einer Mobilkommunikationsbenutzervorrichtung
(UE) 406, welche für
die anschauliche Erklärung
den korrespondierenden Knoten CN bildet. Das UTRAN 404 enthält RNCs
und einen Knoten Bs, wie in 1 dargestellt,
und stellt eine Möglichkeit
zum Übertragen
von Paketen über
eine Funkzugriffsschnittstelle bereit, welche von dem Knoten B mit
der UE 406 gebildet wird.
-
4 liefert
eine Darstellung des Protokollstapels, der in dem GGSN 400,
dem SGSN 402 und dem UTRAN 404 zum Übertragen
von Datenpaketen zu und von der Benutzervorrichtung 406 vorhanden ist.
Um die folgende Erklärung
von Ausführungsformen
der Erfindung zu unterstützen
werden die Protokollstapel kurz beschrieben.
-
Der
GGSN 400 bildet eine Schnittstelle zwischen dem GPRS/UMTS-Netzwerk 200 und
dem externen Paketdatenkommunikationsnetzwerk PDM 212,
welches in der folgenden Erklärung
das Fremdnetzwerk bildet, in das der mobile Knoten wechselt. Internetdatenpakete
werden über
eine physikalische Schicht L1/L2 410 empfangen und sie
werden bei einer mobilen IP-Schicht
empfangen, welche gemäß dem IPV6 412 arbeitet.
Um die Internetpakete, welche von dem Fremdnetzwerk 212 empfangen
wurden, zu übertragen,
verpackt eine GPRS-Tunnelprotokollschicht
(GPRS Tunnelling Protocol layer) GTP-U 414 die Internetpakete
und überträgt das IP Datenpaket
in Kombination mit einer Benutzerdatagrammprotokoll- (User Datagram
Protocol; UDP-) Schicht 416 an den SGSN über die
Schnittstelle Gn/Gp, wobei eine Internetprotokollschicht 418 und eine
physikalische Schicht L1/L2 420 verwendet wird. Entsprechend
werden in dem SGSN, um ein Routing und eine Bereitstellung von Internetprotokollpaketen
zu ermöglichen, über eine
Linkschicht L1/L2 422 empfangene Pakete über eine
entsprechende IP-Schicht 426, eine UDP-Schicht 428 und
eine GTP-U-Schicht 430 an eine mobile IP-Schicht 424 bereitgestellt.
Die mobile IP-Schicht 424 routet dann das IP-Datenpaket
an die passende Funknetzwerksteuerung (nicht gezeigt) welche in
dem UTRAN 404 enthalten ist. Daher tunnelt das IP-Datenpaket
durch eine weitere GTP-U-Schicht 440, eine UDP-Schicht 442 und
eine IP-Schicht 444 durch eine Link-Schicht L1/L2 446 über eine
Iu-ps Schnittstelle in die entsprechende Link-Schicht 450 in
dem UTRAN 404. Das IP-Datenpaket tunnelt dann entsprechend
durch die IP-Schicht 452, die UDP-Schicht 454 und
die GTP-U-Schicht 456 in die mobile IP-Schicht IPV6 460.
Das Internetpaket wird entsprechend an den passenden Knoten B (nicht
gezeigt) geroutet, in dem entsprechende Schichten einbezogen sind,
um das Datenpaket über
eine Funkzugriffträgerschicht 462 an
die mobile Benutzervorrichtung 406 zu übertragen.
-
Wie
es in der Up-Link-Richtung offensichtlich ist, das heißt von dem
korrespondierenden Knoten CN 406 zu dem GGSN, wird ein
entsprechender Tunnel verwendet, um die Internetpakete zurück zu dem GGSN
zu routen, so dass das Internetpaket aus dem GPRS/UMTS-Netzwerk 200 in
das Fremdnetzwerk 212 austreten kann.
-
Ebenfalls
enthalten in den in 4 in dem GGSN 400 gezeigten
GPRS/UMTS-Elementen
ist eine Verkehrsflussvorlagen- (Traffic Flow Template; TFT-) Steuerung 470 und
eine Service Based Policy- (SBLP-) Steuerung 472. Die TFT 470 und
die SBLP 472 arbeiten gemäß einer Ausführungsform
der vorliegenden Erfindung wie in kürze beschrieben wird, so dass
sie die Übertragung
von IP-Datenpaketen von dem GGSN an die mobile UE (CN) und von der mobilen
UE (CN) an den GGSN und nach außen
in das Fremdnetzwerk 212 verwalten.
-
In
der folgenden Beschreibung bildet der mobile UE 406 den
korrespondierenden Knoten CN, wie in 2 dargestellt,
wohingegen ein Knoten, von dem der UE 406 Internetdatenpakete
empfängt
und an den er Internetdatenpakete sendet, einen mobilen Knoten bildet,
der wie gemäß 2 erklärt in das Fremdnetzwerk 212 wechselt.
-
Um
eine Erklärung
der Ausführungsformen der
vorliegenden Erfindung bereitzustellen wird der Betrieb der TFT-Steuerung 470,
die in 4 gezeigt ist, kurz gemäß 5 beschrieben.
-
Verkehrsflussvorlagensteuerung
-
5 liefert
eine vereinfachte Darstellung von in 4 gezeigten
Elementen um eine Erklärung des
Betriebs der TFT-Steuerung bereitzustellen. In 5 ist
eine vereinfachte Darstellung des GGSN 400, des SGSN 402 und
des UTRAN 404 gezeigt, um zu illustrieren wie Internetpakete
in der Down-Link-Richtung von dem mobilen Knoten MN zu dem korrespondierenden
Knoten CN übertragen werden.
Wie in 5 gezeigt ist die TFT-Steuerung 500,
welche in der mobilen IP-Schicht 412 des GGSN arbeitet,
mit einer Liste von Quellenadressen 502 versehen, welche
verwendet werden, um die Übertragung
von IP-Datenpaketen gemäß einer
Quellenadresse, die in der Internetpaketkopfzeile enthalten ist,
zu steuern. Der TFT 500 sorgt dafür, dass IP-Datenpakete über einen
entsprechenden Träger übertragen
werden, der eingerichtet wurde, wobei die Paketdatenprotokoll Kontextaktivierung
verwendet wurde, welche durch eine Anwendung in der UE (CN) oder
auf dem mobilen Knoten MN gestartet werden kann und die analog zum
Einlogen auf einem benötigten
Ziel ist.
-
Um
einen passenden UMTS-Träger
auszuwählen
etabliert der GGSN eine Verkehrsflussvorlage gemäß den folgenden Parametern:
- • IPV4
Quelladresstyp
- • IPV6
Quelladresstyp
- • Protokollidentifizierer/Next
header Typ
- • Einzelzielanschlusstyp
- • Zielanschlussauswahltyp
- • Einzelner
Quellenanschlusstyp
- • Quellenanschlussauswahltyp
- • Sicherheitsperimeterindextyp
- • Diensttyp/Verkehrsklassentyp
- • Flussniveautyp
-
Für jeden
in einer Multimediasession zu verwendenden PDP-Kontext wir eine
Verkehrsflussvorlage von dem mobilen Terminal erzeugt und an den GGSN
gesendet, welcher nachfolgend diese Verkehrsflussvorlage verwendet,
um eingehende Pakete basierend auf Information, welche in der Vorlage
bereitgestellt wird, zu filtern. Zum Beispiel erzeugt der korrespondierende
Knoten CN für
von einem mobilen Ipv6-Knoten gesendete Pakete eine Verkehrsflussvorlage,
welche die IP-Adresse des mobilen Knotens als die Ipv6-Quellenadresse
für Pakete
in der Down-Link-Richtung erzeugt.
-
Wie
in 5 gezeigt, kann ein Internetpaket 504,
das von einem externen Paketdatenkommunikationsnetzwerk 212 auf
dem Down-Link empfangen wurde, zur Übertragung den korrespondierenden Knoten 406 die
Adresse des korrespondierenden Knotens CN in dem Zieladressfeld 506 enthalten. Das
Internetpaket kann die Heimatadresse des mobilen Knotens in dem
Quellenadressfeld 508 enthalten.
-
Im
Betrieb überprüft die TFT-Steuerung 500 die
Quellenadresse des Internetpakets mit der Liste 502 und
routet das Internetpaket über
den passenden Datenträger,
welcher in der TFT-Steuerung zum Übertragen des Internetpakets
an den entsprechenden korrespondierenden Knotens CN eingestellt
wurde. Jedoch, was passiert, wenn das mobile Netzwerk wie in
-
2 gezeigt,
von seinem Heimatnetzwerk 210 in das Fremdnetzwerk 212,
wechselt? Wie gemäß 3 erklärt, wird
nach einer Route-Optimierung die Quellenadresse für den mobilen
Knoten die Care-of-Adresse des mobilen Knotens sein. Daher wird
nachdem eine Route-Optimierung ausgeführt wurde, ein Internetpaket 510 entsprechend
dem Internetpaket 504 von dem mobilen Knoten an den GGSN
zur Übertragung
an den korrespondierenden Kno ten CN 406 gesendet. Wie gezeigt
enthält
die IP-Kopfzeile 510, die von dem mobilen Knoten MN empfangen
wurde, wenn dieser mit dem Fremdnetzwerk 212 verbunden
ist, in ihrem Zieladressfeld 512 die Heimatadresse des
korrespondierenden Knotens 406, jedoch in ihrem Quellenadressfeld
die Care-of-Adresse des mobilen Knotens 514. Die TFT hat einen
Paketträger,
welcher eingerichtet und definiert wurde zum Weiterleiten der Internetpakete
an korrespondierende Knoten in Bezug auf die Quellenadresse. Jedoch
wird das Internetpaket 510, das von dem mobilen Knoten
empfangen wurde, nachdem er in das Fremdnetzwerk 212 gewechselt
hat, nicht von der TFT-Steuerung 500 erkannt und so wird
das Paket fallengelassen, es sei denn es wird irgend eine Anpassung
des GGSN bereitgestellt. Ein angepasster GGSN bildet eine Ausführungsform
der Erfindung.
-
Eine
zuvor vorgeschlagene Lösung
zum Aufgreifen der Zusammenarbeit zwischen der TFT-Steuerung 500 in
dem GGSN nach einer Route-Optimierung ist es, die Heimatadresse
des mobilen Knotens MN in einem Erweitungskopfzeilenfeld, welches
als das Hop-by-Hop-Feld 516 bekannt ist, einzuschließen. Durch
Einschließen
der Heimatadresse des mobilen Knotens in dem Hop-by-Hop-Feld 516 kann
die TFT-Steuerung den passenden Träger identifizieren, der verwendet
werden sollte, um ein Internetpaket an den korrespondierenden Knoten
CN zu transportieren. Dies ist der Paketträger, welcher eingerichtet wurde
während
einer PDP-Kontextaktivierung
als Teil eines Sitzungsbeginns. Daher kann dann, wenn der mobile
Knoten in ein Fremdnetzwerk in der Mitte einer Sitzung wechselt,
durch bereitstellen der Heimatadresse des mobilen Knotens in dem Hop-by-Hop-Feld
die TFT-Steuerung 500 den passenden Träger identifizieren, welcher
verwendet werden soll, um die Internetpakete zu dem korrespondierenden
Knoten 406 zu versenden. Das Hop-by-Hop-Adressenfeld ist
auch als der Routingkopfzeilentyp zwei (Erweiterung der Kopfzeile
von IP6-Paketen) bekannt.
-
Zusammenfassend
kann die TFT-Steuerung 500 durch analysieren des Hop-by-Hop-Feldes in Verbindung
mit dem Quellenadressfeld den passenden Träger 520 identifizieren,
so dass Internetpakete an den korrespondierenden Knoten CN übertragen werden,
da die Liste 502 die Heimatadresse des mobilen Knotens
enthält.
Jedoch wird durch das Bereitstellen der Heimatadresse des mobilen
Knotens in dem Hop-by-Hop-Feld ein technisches Problem begründet, damit
die TFT-Steuerung 500 den passenden IP-Datenträger identifizieren
kann. Dieses Problem wird in dem folgenden Abschnitt erklärt.
-
Zusammenarbeit eines mobilen
IPV6 mit SBLP von IMS in GPRS/UMTS
-
6 liefert
ein vereinfachtes Diagramm von Teilen des in 4 gezeigten
GPRS/UMTS-Netzwerks und ist eingerichtet zum Übertragen von Datenpaketen
auf dem Up- Link
von dem korrespondierenden Knoten CN zu dem mobilen Knoten MN, wie zuvor
gemäß
-
5 für die Down-Link-Übertragungen
diskutiert.
-
In 6 wird
ein Träger 600,
der von dem korrespondierenden Knoten CN unter Verwendung einer
PDP-Kontextaktivierung ausgelöst
wurde, bereitgestellt für
Up-Link-Übertragungen
an den mobilen Knoten MN. Ein Beispiel einer Internetpaketkopfzeile 602,
die mit einem Internetpaket auf dem Up-Link übertragen wurde, wird durch
den Träger 600,
durch das UTRAN 404, den SGSN 402 an den GGSN 400 übertragen
und nach außen
in das Fremdnetzwerk 212. Jedoch wird in dem GGSN 400 der
SBLP bereitgestellt, um einen Zugriff von dem CN (mobile Benutzervorrichtung)
auf die Quality-of-serviceRessourcen in dem UMTS-Netzwerk und darüber hinaus auf das externe
Paketdatenkommunikationsnetzwerk 212 zu kontrollieren.
Wie oben erwähnt
arbeitet der SBLP 472, um eine Kontrollfunktion als ein
Kontrollentscheidungspunkt oder ein Kontrollausübungspunkt zu bewirken, um
Dienstdiebstahl-Angriffe von skrupellosen Teilnehmern zu verhindern.
Zum Beispiel könnte
ein skrupelloser Teilnehmer Zugriff auf IP-Multimediauntersystemdienste (IP
multimedia subsystem services; IMS) erreichen wollen, sogar obwohl
der Teilnehmer diese Dienste nicht aboniert hat. Eine Möglichkeit
zum Erlangen nichtautorisierten Zugriffs auf UMTS-Dienste als Dienstdiebstahl
wäre es,
eine nichtautorisierte Adresse, welche einer Quelle oder einem Ziel
zugeordnet ist, das unbekannt oder von dem GGSN-Netzwerk nicht autorisiert
ist, zu verwenden, während eine
zulässige
Adresse in dem Hop-by-Hop-Feld 306 bereitgestellt wird.
-
Für eine IMS-Sitzung,
welche von dem SBLP 472 aktiviert und autorisiert worden
ist, wird ein SBLP mit einem Datenspeicher 604 bereitgestellt,
der so eingerichtet ist, dass er Informationen speichert, welche
eine Vorlage darstellen, die eine ursprüngliche Heimatadresse eines
mobilen Knotens als die Zieladresse enthält. Der SBLP vergleicht die
Zieladresse jedes Up-Link-Datenpakets,
wenn es von dem GGSN an das externe Netzwerk 212 übertragen
wird, in Bezug auf einen Satz von autorisierten Zieladressen, die
in dem Datenspeicher 604 vorgesehen sind. Jedoch wird,
wenn der mobile Knoten MN in das Fremdnetzwerk FN wechselt, dann
die Zieladresse die Care-of-Adresse des MN. Ein Beispiel einer solchen
IP-Kopfzeile 608, welche in Folge des Wechselns des mobilen
Knotens MN während
einer Sitzung 608 die Care-of-Adresse des mobilen Netzwerks MN in
dem Zieladressfeld 610 aufweist, ist in 6 gezeigt.
Diese IP-Kopfzeile 608 enthält die Care-of-Adresse des
mobilen Netzwerks in dem Zielfeld 612.
-
Um
zu verhindern, dass der SBLP 472 ausgehende Internetpakete,
die von einem berechtigten korrespondierenden Knoten CN an einen
mobilen Knoten MN Übertragen
werden, fallengelassen werden, wird das Hop-by-Hop-Feld wieder so
benutzt, dass es die ursprüngliche
Heimatadresse des mobilen Knotens enthält. Daher ist wie in 6 gezeigt das
Up-Link-Datenpaket 608 so
eingerichtet, dass es die Heimatadresse des mobilen Knotens MN in
der Hop-by-Hop-Feldoption 610 enthält. Daher kann, da der korrespondierende
Knoten CN die Care-of-Adresse des MN verwendet, aber nicht die Heimatadresse
des mobilen Knotens MN in der Hop-by-Hop-Optionskopfzeile enthält, der
SBLP 472 in dem GGSN 400 die Adresse in dem Hop-by-Hop-Feld
mit der Liste von registrierten Adressen in dem Datenspeicher 604 vergleichen. Wenn
das Hop-by-Hop-Feld mit der Heimatadresse des mobilen Knotens MN übereinstimmt,
wird es dem Internetpaket ermöglicht,
durch den GGSN 400 in das Fremdnetzwerk 212 auszutreten.
-
Wie
oben erklärt
könnte
ein skrupelloser korrespondierender Knoten (mobile Benutzervorrichtung),
welcher arbeitet, wobei Ipv6 verwendet wird, eine IMS-Sitzung beginnen,
um auf IMS-Dienste zuzugreifen, obwohl er nicht autorisiert sein
könnte
oder er einen solchen IMS-Dienst
nicht aboniert hat. Zu diesem Zweck könnte der skrupellose Teilnehmer
die autorisierte Heimatadresse des mobilen Knotens in dem Hop-by-Hop-Feld
anordnen und dann irgendeine Adresse in dem Zieladressfeld vorsehen,
wobei das Paket an ein nicht zugelassenes Ziel gesendet werden könnte. Da
das Hop-by-Hop-Feld eine autorisierte Adresse des mobilen Knotens
MN enthält,
passiert das Paket durch den SBLP 472, wodurch es dem skrupellosen
Teilnehmer ermöglicht
wird, auf IMS-Dienste und UMTS-Ressourcen ohne Autorisierung zuzugreifen.
-
Sichere Autorisierung
zwischen der TFT mit SBLP
-
Eine
Ausführungsform
der vorliegenden Erfindung ist in 7 dargestellt. 7 liefert
eine vereinfachte Darstellung von Teilen des in 4 gezeigten
GPRS-Netzwerks. Jedoch wurde in 7 der GGSN
so angepasst, dass er eine Verbesserung bereitstellt, welche die
Wahrscheinlichkeit eines erfolgreichen Dienstdiebstahls durch einen
skrupellosen Teilnehmer reduziert. Aus diesem Grund ist die TFT-Steuerung 700 so
eingerichtet, dass sie die Care-of-Adresse des mobilen Knotens erfasst
und die Care-of-Adresse an die der SBLP-Steuerung 702 bereitstellt.
Die SBLP-Steuerung 702 ist so eingerichtet, dass sie ein
Austreten von Internetpaketen auf dem Up-Link ermöglicht wenn
sowohl das Hop-by-Hop-Feld als auch das Zieladressfeld eine berechtigte
Adresse erhalten. Der SBLP ist daher mit einer Liste von autorisierten
Adressen in einen Datenspeicher 704 versehen. Der Betrieb
der TFT-Steuerung 700 und der SBLP-Steuerung 702 gemäß einer
Ausführungsform
der vorliegenden Erfindung wird nun beschrieben.
-
Nach
einer Route-Optimierung während
einer Sitzung bildet der mobile Knoten MN, der von dem Heimatnetzwerk 210 in
das Fremdnetzwerk FN 212 wechselt, wie oben beschrieben
eine bindende Aktualisierung. Das entsprechende bindende Aktualisierungspaket 706 ist
in 7 so dargestellt wie es an dem GGSN 400 von
der TFT-Steuerung 700 empfangen wird. Die CBU verwendet
die Care-of-Adresse des MN als die Zieladresse der Basis Ipv-Kopfzeile.
Die CBU wird auch die ursprüngliche
Heimatadresse des mobilen Knotens in dem Hop-by-Hop-Feld 712 tragen,
so dass die TFT-Steuerung es der CBU ermöglicht durch den GGSN zu passieren.
-
Jedoch
wird beim Erkennen der CBU 706 als eine bindende Aktualisierung
die TFT-Steuerung 700 die Quellenadresse (Care-of-Adresse
des mobilen Knotens) in dem Adressfeld 706 im Zusammenhang mit
der ursprünglichen
Heimatadresse des mobilen Knotens in der Liste von autorisierten
Quellenadressen, die in dem Datenspeicher 720 bereitgestellt wird,
aufnehmen. Die TFT-Steuerung 700 ordnet dadurch der Care-of-Adresse
des mobilen Knotens die Heimatadresse des mobilen Knotens zu.
-
Wie
bereits erklärt
verwendet die bindende Aktualisierungsnachricht den MH-Typwert gleich „5". Wenn ein Paket
mit einer Quellenadresse, die nicht zu der passt, die in der Liste
von autorisierten Quellenadressen, die der TFT-Steuerung 700 bereitgestellt
wird, enthalten ist, wird die Quellenadresse als die Care-of-Adresse
des mobilen Knotens 706 gelesen. Danach werden alle Pakete,
die an der TFT-Steuerung 700 empfangen werden, welche die Care-of-Adresse
des mobilen Knotens 706 tragen, identifiziert und durch
den entsprechenden Träger, der
durch diese Care-of-Adresse (Quellenadresse) identifiziert ist,
gesendet, sowie dies zuvor für
die Heimatadresse des mobilen Knotens erfolgte. Jedoch kann die
TFT-Steuerung 700, um eine Authentifizierung der neuen
Care-of-Adresse des Knotens MN sicher zu stellen, in einer Ausführungsform
nach der bindenden Aktualisierungsbestätigungsnachricht von dem korrespondierenden
Knoten CN sehen. Wie oben erklärt,
wird die bindende Aktualisierungsbestätigung durch den MH-Typwert „6", wie in den MIPV6-Entwurf
in Abschnitt 6.1.8 Seite 36 definiert, identifiziert. Daher wird
die TFT-Steuerung 700 nur die Care-of-Adresse für den mobilen
Knoten verwenden, wenn die TFT-Steuerung eine bindende Bestätigung mit
einem Statuswert von „Null", welcher anzeigt,
dass die bindende Aktualisierung akzeptiert wurde, empfängt und
identifiziert.
-
In
einer alternativen Ausführungsform
kann eine sichere bindende Aktualisierung bewirkt werden durch Verwenden
der mobilen Ipv6-Return-Routeability-Prozedur zwischen dem korrespondierenden Knoten
CN und dem mobilen Knoten (beschrieben in Mobil IPV6 Abschnitt 5,
Abschnitt 9.4 und Abschnitt 14). Daher enthält für jeden gebildeten PDP-Kontext die
zugeordnete TFT die Quellenadresse des mobilen Knotens oder die
Care-of-Adresse des mobilen Knotens, wenn der mobile Knoten mit
einem Fremdnetzwerk verbunden ist.
-
Um
einen Zugriff auf UMTS-Ressourcen und eine IMS-Sitzung, in der eine
Wahrscheinlichkeit eines erfolgreichen Diebstahlangriffs durch einen
skrupellosen Teilnehmer reduziert ist, zu ermöglichen, überprüft der SBLP jedes Paket, welches
auf IMS-Dienste zugreift, auf seine Zieladresse. Die SBLP-Steuerung überprüft die Zieladresse,
die in der grundlegenden IPV6-Kopfzeile
enthalten ist, und die ursprüngliche
Heimatadresse des MN in der Hop-by-Hop-Feldoption. Das Paket kann nur aus dem
GGSN austreten wenn sowohl die Zieladresse mit der Care-of-Adresse
des mobilen Knotens übereinstimmt
als auch die Adresse in dem Hop-by-Hop-Feld mit der Heimatadresse des mobilen
Knotens als der Zieladresse in der SBLP-Informationsvorlage 704 übereinstimmt.
Der GGSM wird sonst alle Pakete, die es einer mobilen Benutzervorrichtung
(korrespondierender Knoten) gesendet werden, wobei eine nichtautorisierte
Zieladresse verwendet wird, blockieren. Aus diesem Grund wird ein Sicherheitsassociate
SA in Verbindung mit der TFT-Steuerung 700 und der SBLP-Steuerung 702 gebildet.
Der Sicherheitsassociate SA schließt die Care-of-Adresse des
mobilen Knotens ein. Nach einer bindenden Aktualisierung bewegt
sich der mobile Knoten zu der Care-of-Adresse nach einem Wechsel in
ein Fremdnetzwerk, so dass die Quellenadresse des mobilen Knotens
die Care-of-Adresse
des mobilen Knotens MN ist. Daher können Pakete nur aus dem GGSN
auf dem Up-Link
von dem SBLP gesendet werden, wenn sowohl die Hop-by-Hop-Option
der Up-Link-Paketkopfzeilen
die Heimatadresse des Ziels aufweist, welche die des mobilen Knotens
ist, oder der Sicherheitsassociate einer Care-of-Adresse für den mobilen
Knoten bereitstellt. Die Care-of-Adresse des mobilen Knotens MN
kann mit der Heimatadresse des mobilen Knotens in dem Datenspeicher 704 gespeichert
werden.
-
Zusammenfassung des Betriebs
-
8 liefert
ein Flussdiagramm, welches den Betrieb der Gateway-Unterstützung gemäß einer Ausführungsform
der Erfindung darstellt. Eine Beschreibung des in 8 gezeigten
Flusses wird wie folgt zusammengefasst:
- S1:
Durch den GGSN werden von dem externen Paketdatenkommunikationsnetzwerk
Internetpakete empfangen, welche an die mit dem Paketfunknetzwerk,
von dem der GGSN ein Teil bildet, verbundenen Knoten übertragen
werden sollen. Das Paketfunknetzwerk stellt eine Mehrzahl von Trägern zum Übertragen
der Internetpakete an die Knoten bereit.
- S2: Der GGSN identifiziert den passenden Träger zum Übertragen eines empfangenen
Internetpakets an einen korrespondierenden Knoten aus der Quellenadresse
in dem Quellenadressfeld der IP-Kopfzeile.
- S4: Jedoch untersucht, wenn der GGSN die Quellenadresse nicht
erkennt, dann der GGSN ein Hop-by-Hop-Feld in einer Erweiterung
der IP-Kopfzeile. Wenn das Hop-by-Hop-Feld eine Adresse enthält, für die einer
der Paketträger
gebildet wurde, dann wird dieser Träger verwendet um das Paket
zu transportieren.
- S6: Der GGSN empfängt
ein Internetpaket und bestimmt ob das Internetpaket eine bindende
Aktualisierung ist.
- S8: Wenn das Paket eine bindende Aktualisierung ist, dann ordnet
der GGSN die Care-of-Adresse des
mobilen Knotens, die als die Quellenadresse der bindenden Aktualisierung
bereitgestellt wird, der ursprünglichen
Quellenadresse des mobilen Knotens zu, welche die Heimatadresse
des mobilen Knotens sein kann.
- S10: Nach der Zuordnung kann der GGSN den passenden Träger zum Übertragen
von Down-Link-Paketen von der Care-of-Adresse des mobilen Knotens
an die Quellenadresse identifizieren.
- S12: Der GGSN sieht die Care-of-Adresse des mobilen Knotens
vor, die in Schritt S8 von dem bindenden Aktualisierungspaket an
eine Sicherheitsfunktion bereitgestellt wurde, wie zum Beispiel
eine Service Based Local Policy (SBLP). Dies kann zum Beispiel durch
Verwenden eines Sicherheitsassociate bewirkt werden.
- S14: Der GGSN untersucht Pakete, die von dem korrespondierenden
Knoten empfangen wurden zum Verlassen des Paketfunknetzwerks in
den externen Knoten. Der GGSN erlaubt es nur Paketen aus dem Paketfunknetzwerk
in das externe Netzwerk auszutreten, wenn sowohl die Quellenadresse
eine berechtigte Adresse enthält
als auch das Hop-by-Hop-Feld eine berechtigte Care-of-Adresse enthält.
-
Optional
kann der GGSN die in dem bindenden Aktualisierungspaket erfasste
Care-of-Adresse des
mobilen Knotens bestätigen
durch Erfassen der bindenden Aktualisierungsbestätigung, die von dem korrespondierenden
Knoten zurück
empfangen wurde. In alternativen Ausführungsformen kann eine Bestätigung bewirkt
werden durch Verwenden einer umgekehrten Routeability-Bestätigung.
-
Biographie
-
- [1] D. Johnson, C. Parkins, J. Arkko, "Mobility in Ipv6", Internet Draft, Internet Engineering
Task Force, 20. Januar 2003.
- [2] R. Steele, C-C Lee und P. Gould, "GSM, cdmaOne and 3G Systems," veröffentlicht
von Wiley International ISBN 0 471 491853.
-
ANHANG 1
-
GPRS/UMTS-Architektur
-
Die
Terminologie und Architektur, die in 1 verwendet
wird, entspricht der für
den UMTS verwendeten und der für
3G die von der 3GPP verwaltet wird, vorgeschlagenen, über die
mehr Details in [1] gefunden werden können. In 1 ist
ein Gateway GPRS-Unterstützungsknoten
(GGSN) mit einem externen Paketdatennetzwerk 102 (PDN)
verbunden. Das externe PDN kommuniziert mit Paketen, welche das
Internetprotokoll (IP) verwenden. Eine Schnittstelle 104 zwischen
dem GGSN und dem externen Netzwerk ist mit Gi bezeichnet, das standardisiert wurde
obwohl weitere Aspekte standardisiert werden. Auch ist mit dem GGSN
ein Serving-GPRS-Unterstützungsknoten
(Serving GPRS Support Node; SGSN) 106 über eine Schnittstelle 108,
die als Gn/Gp bezeichnet ist, verbunden, die ebenfalls standardisiert
ist.
-
Der
GGSN und der SGSN sind zwei Netzwerkkomponenten, die benötigt werden,
um GPRS zu unterstützen.
Der GGSN arbeitet als der Gateway in den externen Paketdatennetzwerken
(PDN) und dem mobilen Netzwerk, welches GPRS unterstützt. Der
GGSN enthält
ausreichende Informationen, um eingehende IP-Datenpakete an den
SGSN zu routen, der eine bestimmte Benutzervorrichtung (User Equipment;
UE) bedient, die mobil ist und Daten über eine Funkzugriffseinrichtung
empfängt,
die von dem mobilen Paketfunknetzwerk bereitgestellt wird. Für die beispielhafte
Ausführungsform
wird die Funkzugriffseinrichtung mit dem Universal Terrestrial Radio Access
Network-(UTRAN)-System bereitgestellt, welches gemäß dem 3GPP
Standard spezifiziert ist. Der SGSN ist mit dem GGSN über eine
Gn-Schnittstelle verbunden wenn der SGSN in dem gleichen Public
Land Mobile Network (PLMN) liegt und er ist über die Gp-Schnittstelle mit
GGSNs verbunden, die zu anderen PLMNs gehören.
-
Ein
SGSN stellt eine Mobilitätsverwaltung von
UEs bereit, welche sich in einem von dem Mobilfunknetzwerk unterstützten Gebiet
bewegen. Aus diesem Grund ist der SGSN mit einem Zugriff auf ein Heimatortregister
(Home Location Register; HLR) 110 ausgestattet. Der SGSN
ist so eingerichtet, dass er Datenpakete an Funknetzwerksteuerungen
(Radio Network Controllers; RNC) 112, 114 zur Übertragung über die
UTRAN-Funkzugriffseinrichtung an mobile Benutzer UE 116, 118 routet.
Die UTRAN-Funkzugriffseinrichtung wird bereitgestellt, wobei Node
B Vorrichtungen 120, 122, 124, 126, 128 verwendet werden,
welche effektiv Basisstationen bilden, die eine Funkabdeckung des
von dem Mobiltelekommunikationsnetzwerk bedienten Gebiets bereitstellen. Die
Schnittstelle 130, 132, 134, 136, 138 zwischen
jedem RMC 112, 114 und die Knoten B Vorrichtung 120, 122, 124, 126, 128 sind
mit Iub bezeichnet und stimmen mit einem etablierten oder sich entwickelnden
Standard überein. Ähnlich sind
die Schnittstellen 140, 142 zwischen dem SGSN
und jedem RNC 112, 114 als Iu-ps bezeichnet und
bilden einen sich entwickelnden Standard.