-
GEBIET DER
ERFINDUNG
-
Die
vorliegende Erfindung betrifft ein Verfahren, System und ein Netzwerkelement
zum Bereitstellen einer Adressumstellung, wie zum Beispiel einer
Umstellung von einer IPv4 (Internet Protokoll Version 4)-Adresse
auf eine IPv6-Adresse, zwischen einem ersten Netzwerkknoten und
einem zweiten Netzwerkknoten eines zellularen Netzwerks, zum Beispiel
eines GPRS (General Packet Radio Services bzw. allgemeine Paketfunkdienste)-Netzwerks
und/oder einer Nachrichtenzuordnung bzw. Nachrichtenkorrelation.
-
HINTERGRUND
DER ERFINDUNG
-
UMTS
(Universal Mobile Telecommunications System bzw. universelles mobiles
Telekommunikationssystem) ist ein etwas allgemeinerer Begriff für das 3G
(dritte Generation) Telekommunikationssystem basierend auf der WCDMA-Funkschnittstelle
mit hoher Kapazität.
GSM ist das am weitesten verbreitete 2G (zweite Generation)-Telekommunikationssystem
basierend auf TDMA (Time Division Multiple Access bzw. zeitgeteilter Mehrfachzugriffs)-Funk.
Das Ziel des GPRS-Systems besteht darin, eine globale Schicht 2
(layer 2)-Anschlussfähigkeit
(Konnektivität)
eines zellularen Mobilendgeräts
(MT), manchmal auch als Mobilstation (MS) oder Anwenderausstattung
(UE) bezeichnet, das 2G- oder 3G-Funktechnologie (zum Beispiel GSM,
amerikanisches TDMA, UMTS, GERAN (GSM/EDGE Funkzugriffsnetzwerk)
verwendet, mit einem externen Paketdatennetzwerk, bereitzustellen.
GPRS kann unterschiedliche Schicht 3 (layer 3)-Protokolle (zum Beispiel
IPv4; IPv6; PPP (Punkt-zu-Punkt-Protokoll)) unterstützen.
-
Die
Hauptknoten eines GPRS-Netzwerks sind SGSN (Serving GPRS Support
Node bzw. bedienender GPRS-Unterstützungsknoten) und GGSN (Gateway
GPRS Support Node bzw. Übergangs-GPRS-Unterstützungsknoten).
SGSNs sind die Knoten, welche das MT bedienen. Jeder SGSN unterstützt GPRS
für GSM und/oder
UMTS. GGSNs sind der Knoten, der die Zusammenarbeit mit PDNs (Paketdatennetzwerken)
handhabt. Signalisierung und Daten werden zwischen SGSN und GGSN
oder SGSN und SGSN unter Verwendung des GTP (GPRS Tunneling Protocol
bzw. GPRS Tunnelprotokoll)-Protokolls ausgetauscht. Das GTP-Protokoll handhabt
Mobilität
und Aufbau, Modifizierung und Abbau von GTP-Tunnel sowie den Transfer
von Anwenderdaten zwischen GSNs. GTP ermöglicht Mehrfachprotokollpakete,
zwischen GSNs und zwischen einem SGSN und dem UMTS-landgestützten Funkzugriffsnetzwerk
(UTRAN, nicht gezeigt) zu tunneln, durch das eine Verbindung zum
betroffenen MT aufgebaut wird. Andere Systemkomponenten müssen sich
nicht des GTP bewusst sein. Typischerweise werden zwei IP-Adressen
für einen
einzelnen Tunnel verwendet, eine für die GTP-Steuernachricht (das
heißt,
für die
Signalisierung) und eine für
das GTP-Anwenderpaket
(das heißt,
für den
Transport der Anwenderdaten).
-
Beim
GPRS-Anschluss (GPRS Attach) baut der SGSN einen Mobilitätsverwaltungs
(MM)-kontext auf, der Informationen enthält, die zum Beispiel Mobilität und Sicherheit
des betroffenen MT anbelangt. Bei der Aktivierung eines PDP-Kontexts
baut der SGSN einen PDP-Kontext auf, der für Zwecke des Routings verwendet wird,
mit dem GGSN, den der Teilnehmer verwenden wird. Ein an GPRS angeschlossenes
Mobilendgerät
(Mobile Terminal, MT) kann sowohl eine statische als auch eine dynamische
IP-Adresse (auch als PDP-Adresse bezeichnet) zugeordnet werden.
Die statische Adresse wird durch den Betreiber des öffentlichen
bandgestützten
mobilen Heimatnetzwerks (bzw. Home Publish Land Mobile Network,
HPLMN) zum Zeitpunkt einer Teilnahme (Subskription) zugeordnet.
Die dynamische IP-Adresse kann durch einen GGSN (Gateway GPRS Support
Node bzw. Übergangs-GPRS-Unterstützungsknoten)
vom Betreiber entweder des HPLMN oder des besuchten PLMN (VPLMN)
zum Zeitpunkt der Aktivierung des PDP (Paketdatenprotokoll)-Kontexts
zugeordnet werden. Zusätzlich
zur Adresszuordnung setzt der GGSN die Weiterleitung von IP-Paketen
von einem GTP (GPRS Tunnelprotokoll)-Tunnel zu einem Paketdatennetzwerk
(PDN) und umgekehrt um. Es gibt zwei Arten von PLMN-Backbone-Netzwerken,
ein Intra-PLMN-Backbone-Netzwerk
und ein Inter-PLMN-Backbone-Netzwerk. Das Intra-PLMN-Backbone-Netzwerk
ist ein privates IP-Netzwerk, das nur für Daten der Paketdomäne (Paketdomänendaten)
und Signalisierung innerhalb eines PLMN vorgesehen ist, während der
Inter-PLMN-Backbone für
Roaming von einem PLMN zu einem anderen (über Grenzübergänge bzw. Border Gateways) verwendet
wird. Bedienende GPRS-Unterstützungsknoten
(SGSNs) und GGSNs verwenden das Intra-PLMN-Backbone, um Daten der
GPRS-Domäne
und Signalisierung auszutauschen.
-
Während des
Roaming werden sowohl der Intra-PLMN-Backbone des Heimat- als auch
des besuchten Netzwerks zusätzlich
zum Inter-PLMN-Backbone verwendet. Wenn ein Teilnehmer zu einem
anderen PLMN wandert bzw. in einem anderen PLMN roamt, das heißt einem
VPLMN muss sich der Anwender zuerst an das Netzwerk anschließen. Beim
GPRS-Anschluss (GPRS Attach) informiert das MT den bedienenden SGSN
von seiner Absicht, sich an das Netzwerk anzuschließen, durch
zur Verfügung
stellen von Informationen über
seine Identität,
Fähigkeiten
und seinen (Aufenthalts-) Ort. Der SGSN überprüft dann die Identität des MT und
führt eine
Authentisierungsprozedur durch, um den Übertragungsweg zu sichern.
Der Anschluss ist abgeschlossen, nachdem der SGSN Roaming-Teilnehmerdaten
vom Heimatregister (Home Location Register, HLR) des HPLMN des Teilnehmers
empfangen hat und eine Aufenthaltsortsaktualisierungsprozedur abgeschlossen
hat. Nach dem GPRS-Anschluss sendet das MT eine „Aktiviere PDP-Kontext"-Anforderung („Activate
PDP Context" Request),
in der der Zugriffspunktname (Access Point Name, APN) ein Bezug
auf den GGSN-Zugriffspunkt
(Access Point, AP) ist, der sowohl im Heimat- als auch besuchten
PLMN zu verwenden ist. Der SGSN wählt den GGSN basierend auf
einem PDP-Kontextteilnahmedatensatz
(PDP Context Subscription Record) aus und sendet die Kontextdaten
an einem ausgewählten
GGSN. Der GGSN routet dann die Pakete an die richtigen Paketdatennetzwerke
(Paket Data Network, PDN).
-
Wenn
ein Teilnehmer im VPLMN wandert bzw. roamt, gibt es die zwei folgenden
Möglichkeiten
zur Auswahl des GGSN. Als erstes kann der GGSN des Heimatnetzwerks über den
Inter-PLMN-Backbone und BGs verwendet werden. Der Heimat-GGSN routet
dann die Pakete an ihr Ziel. Als zweites kann ein GGSN einer besuchten
Domäne
zum Routen der Pakete vom VPLMN zu ihrem Ziel direkt durch ein Paketdatennetzwerk
(PDN), wie zum Beispiel dem öffentlichen
Internet, verwendet werden.
-
Es
sei angemerkt, dass es zwei Schichten (Levels) der IP-Adressierung
gibt:
- – Die
IP-Adresse des Anwenders entspricht den über das GTP-Protokoll (over
GTP protocol) gelieferten Paketen. Die entsprechende IP-Adresse
wird als PDP-Adresse
oder Anwenderadresse bezeichnet; und
- – Die
IP-Adresse des Netzwerks entspricht den unter dem GTP-Protokoll
(below GTP protocol) übertragen Paketen.
Die entsprechende IP-Adressen sind die IP-Adressen der Knoten, die verwendet werden,
um GTP-Pakete zwischen GSNs auszutauschen. Diese IP-Adressen könnten auch
für Netzwerkoperationen, wie zum
Beispiel (In)Rechnungstellung bzw. Berechnung (Charging) oder O&M, verwendet werden.
-
Anwender-
und Netzwerkadressen sind dank des GTP-Protokolls voneinander unabhängig und
könnten
sowohl entweder IPv4 oder IPv6 sein.
-
Die
GPRS-Backbone-Knoten der zweiten (2G) und dritten (3G) Generation
können
optional eine Adressierung auf Basis des IPv6 für Netzwerkadressen verwenden.
Jedoch bestehende Spezifikationen, die die Verwendung von IPv6-Adressen
erlauben, definieren nicht, wie Rückwärts- bzw. Abwärtskompatibilität mit IPv4-basierenden
Knoten erhalten wird. Ein SGSN sollte im vorhinein wissen, dass
der ausgewählte
GGSN, IPv6-Adressen unterstützt,
bevor er eine IPv6-Adresse, beispielsweise in einer „Erzeuge
PDP-Kontext"-Anforderungsnachricht
(Create PDP Context Request Message) eingefügt wird.
-
Darüber hinaus
tritt ein anderes Problemen bei den bekannten Prozeduren auf. Wenn
ein MT sich von einem IPv6-fähigen
SGSN, der mit einem IPv6-fähigen
GGSN verbunden ist, zu einem nur-IPv4-SGSN bewegt, wird die Kommunikation
abreißen,
da der neue SGSN die übertragende
IPv6-Adresse nicht verwenden kann. Ein derartiges Szenario ist sehr
wirklichkeitsnah, insbesondere wenn zwei Betreiber mit Ausstattungen von
unterschiedlichen Herstellern (oder nur unterschiedlichen Softwareversionen)
ein Roaming-Abkommen (zum Beispiel nationales Roaming) haben. Es
sei angemerkt, dass bestehende IPv4-zu-IPv6-Umstellungsmechanismen
hier nicht geeignet sind, da sie IP-Adressen, die im GTP übertragen
werden, nicht beeinflussen.
-
Zusätzlich besteht
ein praktisches Erfordernis darin, dass Protokollveränderungen
so durchgeführt werden
müssen,
dass Knoten, die auf älteren
Versionen der Spezifikationen basieren (und so die hier vorgeschlagene
Verbesserung nicht unterstützen)
die Zusammenarbeit mit neuen Knoten, die hier vorgeschlagene Verbesserung
unterstützen,
weiter zusammenarbeiten sollen.
-
PCT-Anmeldung
WO 00/22839 offenbart ein Verfahren, bei dem eine Adresse von einem
alten Vermittlungspunkt (zum Beispiel SGSN) zu einem neuen Vermittlungspunkt übertragen
wird, wenn eine Mobilstation den Routingbereich wechselt.
-
ZUSAMMENFASSUNG
DER ERFINDUNG
-
Es
ist daher eine Aufgabe der vorliegenden Erfindung, ein Verfahren
und ein System zum Bereitstellen einer Adressumstellung oder Zuordnungsfunktion,
mittels der Abwärts-
bzw. Rückwärtsadresskompatibilität erreicht
werden kann, zur Verfügung
zu stellen.
-
Diese
Aufgabe wird gelöst
durch ein Verfahren und ein System gemäß den Ansprüchen 1, 13, 17 bzw. 19.
-
Zusätzlich wird
die obige Aufgabe gelöst
durch einen Netzwerkknoten gemäß den Ansprüchen 23,
26 bzw. 29.
-
Entsprechend
soll, wenn einer der Verbindungspunkte verändert wird (zum Beispiel Inter-SGSN-Routingbereichsaktualisierung;
Wechsel des bedienenden RNC), der alte Verbindungspunkt (zum Beispiel
der alte SGSN) an den neuen Verbindungspunkt (zum Beispiel der neue
SGSN) sowohl eine erste und zweite Adresse senden, um es dem neuen
Verbindungspunkt zu ermöglichen,
die Verbindung zum anderen Ende der Verbindung (GGSN) wiederherzustellen,
selbst wenn dieser nur unter Verwendung einer der zwei Adressen
kommunizieren kann.
-
Darüber hinaus
können
Signalisierungsnachrichten, zum Beispiel Nachrichten betreffend
(In)Rechnungstellung (Charging), gesetzlich ermächtige Überwachung (Lawful Interception)
und/oder kundenspezifische Anwendungen (zum Beispiel kundenspezifische
Anwendungen für
Mobilnetzwerksarchitektur mit verbesserter Logik bzw. Customized
Applications for Mobile Network Enhanced Logik (CAMEL) Architectur),
die von unterschiedlichen Netzwerkknoten empfangen worden sind,
basierend auf den alternativen Adressen korreliert bzw. zugeordnet
werden können.
-
Vorteilhafte
Weiterentwicklungen sind in den abhängigen Ansprüchen angegeben.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
Im
Folgenden wird die Erfindung in größerem Detail basierend auf
einem bevorzugten Ausführungsbeispiel
unter Bezugnahme auf die begleitenden Zeichnungen beschrieben, in
denen:
-
1 ein
schematisches Blockdiagramm einer GPRS-Backbone-Netzwerkarchitektur zeigt, in der die vorliegende
Erfindung umgesetzt werden kann;
-
2 ein
Signalisierungsdiagramm zeigt, das eine Inter-SGSN-Routingbereichsaktualisierungsprozedur
gemäß dem bevorzugten
Ausführungsbeispiel
zeigt; und
-
3 ein
Signalisierungsdiagramm zeigt, das eine Wechselprozedur (Relocation)
für das
bedienende SRNS (Serving SRNS) gemäß dem bevorzugten Ausführungsbeispiel
anzeigt.
-
BESCHREIBUNG
DER BEVORZUGTEN AUSFÜHRUNGSBEISPIELE
-
Nun
wird das bevorzugte Ausführungsbeispiel
basierend auf einer Paketdomänen-PLMN-Backbone-Netzwerkarchitektur,
wie sie in 1 gezeigt ist, beschrieben,
in der ein IPv6-zu-IPv4-Adressenumstellungsmechanismus verwendet
wird.
-
Gemäß 1 ist
ein Paketdatennetzwerk (Paket Data Network, PDN) 10 (zum
Beispiel ein IP-Netzwerk) über
einem ersten GGSN 31 mit einem ersten PLMN 71 verbunden,
das ein erstes Intra-PLMN-Backbone-Netzwerk 51 umfasst.
Darüber
hinaus schließt
das erste PLMN 71 wenigstens einen ersten SGSN 61 und
einen zweiten SGSN 62 ein, die miteinander und mit dem
ersten GGSN 31 durch das erste Intra-PLMN-Backbone-Netzwerk 51 verbunden
sind. Zusätzlich
ist das PDN 10 gegenseitig über einen zweiten GGSN 32 mit
einem zweiten PLMN 72 verbunden, das ein zweites Intra-PLMN-Backbone-Netzwerk 52 umfasst.
Darüber
hinaus enthält
das zweite PLMN 72 wenigstens einen dritten SGSN 63,
der mit dem zweiten GGSN 32 durch das zweite Intra-PLMN-Backbone-Netzwerk 52 verbunden
ist. Das erste und zweite PLMN 71, 72 sind miteinander über ein
Inter-PLMN-Backbone-Netzwerk 20 verbunden. Die Verbindung
zwischen dem ersten PLMN 71 und dem Inter-PLMN-Backbone-Netzwerk 20 wird
durch einen ersten Grenzübergang bzw.
Grenz-Gateway (Border Gateway, BG) 41 bereitgestellt. Ähnlich wird
die Verbindung zwischen dem zweiten PLMN 72 und dem Inter-PLMN-Backbone-Netzwerk 20 durch
einen zweiten BG 42 bereitgestellt.
-
Jedes
der Intra-PLMN-Backbone-Netzwerke 51, 52 kann
ein privates IP-Netzwerk sein, das für Daten der Paketdomäne und Signalisierung
bestimmt ist. Ein privates IP-Netzwerk
ist ein IP-Netzwerk, in dem ein bestimmter Zugriffssteuermechanismus
angewandt wird, um ein erforderliches Sicherheitsniveau zu erreichen.
Das Inter-PLMN-Backbone-Netzwerk 20 kann
ein Paketdatennetzwerk, zum Beispiel das öffentliche Internet oder eine
angemietete Leitung sein, die durch einen Roaming-Vertrag einschließlich einer
BG-Sicherheitsfunktionalität
(das heißt,
typischerweise nur ein Router mit Sicherheitsfunktionen) ausgewählt sein
kann. Der erste und zweite BG 41, 42 sind im Bereich
der Paketdomäne
nicht definiert.
-
Die
GPRS-Unterstützungsknoten
(GSNs), das heißt,
die ersten bis dritten SGSNs 61 bis 63 und der erste
und zweite GGSN 31, 32 enthalten eine Funktionalität, die erforderlich
ist, um GPRS-Funktionalität
für GSM
(globales System für
mobile Kommunikation bzw. Global System for Mobile Communication)
und/oder für
UMTS zu unterstützen.
Insbesondere stellen der erste und zweite GGSNs 31, 32 Netzwerkknoten
dar, auf die durch das PDN 10 aufgrund der Auswertung der
PDP-Adresse zugegriffen wird. Sie enthält Routinginformationen für GPRS-angeschlossene
Anwender. Die Routinginformationen werden verwendet, um Paketdateneinheiten
(Packet Data Units, PDUs) an den aktuellen Anschlusspunkt des MT
zu tunneln, das heißt,
dem jeweiligen bedienenden SGSN. So sind der erste und zweite GGSN 31, 32 der
erste Punkt der PDN(Quer)verbindung mit dem ersten bzw. zweiten
PLMN 71, 72. Der erste bis dritte SGSN 61 bis 63 stellen
Knoten zum bedienen des MT dar. Jeder SGSN unterstütz GPRS
für GSM
und/oder UMTS.
-
Weitere
Einzelheiten bezüglich
der Netzwerkarchitektur und Signalisierungsprozeduren kann aus der 3GPP
(Partnerschaftsprojekt der dritten Generation bzw. 3rd Generation
Partnership Project)-Spezifikation TS 23.060 Release 4 erhalten
werden.
-
Gemäß den bevorzugten
Ausführungsbeispielen
wird ein SGSN, der eine IPv6-Adresse
verwenden will, immer eine IPv6 und außerdem eine IPv4-SGSN-Adressen
in einer zugehörigen
GTP-Signalisierungsnachricht anzeigen, die verwendet wird, um den
Aufbau (Creation) eines GTP-Tunnels zum ausgewählten GGSN anzufordern. Optional
kann der SGSN außerdem
IPv6 und außerdem
IPv4-SGSN-Adressen in einer zugehörigen GTP-Signalisierungsnachricht
anzeigen, die verwendet wird, um die Aktualisierung (Update) eines
GTP-Tunnels anzufordern. Dies ist jedoch nicht notwendig, wenn vor
dem Senden des Updates, der SGSN bereits den Typ der durch den GGSN
unterstützten
Adressen kennt. Es kann jedoch nützlich
sein, wenn der Betreiber es wünscht,
auf einer Knoten-zu-Knoten-Basis, die zu verwendende Technologie
(dies kann durch ein Zwischenlösungsnetzwerk
begründet
sein) zu konfigurieren.
-
Falls
der ausgewählte
GGSN IPv6 auf Netzwerkebene unterstützt, sollte er außerdem IPv6-Adressen in
der zugehörigen
GTP-Antwortnachricht zusammen mit IPv4- Adressen anzeigen. Die IPv4-Adressen
werden im SGSN gespeichert und für
die Übertragung
nicht verwendet. IPv6-Adressen werden für die Übertragung auf Netzwerkebene
verwendet. Im Falle einer Inter-SGSN-Übergabe bzw. eines Inter-SGSN-Handover, sollten IPv4-
und IPv6-Adressen an den neuen SGSN in einer abwärts bzw. rückwärts kompatiblen Weise zur Verfügung gestellt
werden. Wenn der neue SGSN IPv6-Adressen nicht unterstützt, verwendet
er die erhaltenen IPv4-Adressen, um den Tunnel zum GGSN zu aktualisieren.
Außerdem
kann der GGSN beginnen Anwenderdaten vom neuen SGSN zu empfangen,
bevor der Tunnel aktualisiert worden ist. Daher sollten der erste
und zweite GGSN 31, 32 bereit sein, GTP-Pakete
(Signalisierungs- oder Anwenderdaten) basierend auf sowohl IPv4-
oder IPv6-Adressen zu empfangen.
-
Es
sei angemerkt, dass in Zukunft ein neuer SGSN zur Verfügung gestellt
werden kann, der in der Lage ist, nur IPv6 auf Netzwerkebene zu
verwenden, dann würden
dieselben Prinzipien passen.
-
Als
eine Implementierungsalternative könnte der Knoten die Übertragungstechnologie
(IPv4 oder IPv6), die verwendet werden soll, basierend auf einer
Betreibereinstellung bzw. Betreiberkonfiguration auswählen.
-
Wenn
der ausgewählte
GGSN auf Netzwerkebene IPv6 nicht unterstützt, zeigt er nur IPv4-Adressen in
der zugehörigen
GTP-Antwortnachricht an. IPv4-Adressen werden dann für Übertragung
auf der Netzwerkebene, wie zur Zeit definiert, verwendet.
-
Da
vorgeschlagen wird, die IPv6-Adresse als ein neues optionales Informationselement
zu senden, kann Rückwärts- bzw.
Abwärtskompatibilität bereit
gestellt werden, um so IPv6 in zukünftigen Netzwerkknoten einzuführen und
Verbindungen auf der Netzwerkebene zu erhalten, selbst wenn ein
neuer SGSN nur IPv4 unterstützt.
-
Im
Folgenden werden Beispiele für
spezifische Signalisierungsnachrichten und die Einführung des spezifischen
Adressfelds zum Übertragen
einer alternativen Adresse unter Bezug auf 2 und 3 beschrieben.
Spezifische Einzelheiten bezüglich
der Signalisierungsnachrichten und -prozeduren kann aus den 3GPP-Spezifikationen
TS 29.060 und TS 23.060 Release 4 erhalten werden.
-
Eine
Anforderung zum Erzeugen eines PDP-Kontext (Create PDP Context Request)
wird von einem SGSN-Knoten an einen GGSN-Knoten als Teil der Aktivierungsprozedur
eines GPRS-PDP-Kontexts (GPRS PDP Context Activation) gesendet.
Eine gültige Anforderung
initiiert die Erzeugung eines Tunnels zwischen einem PDP-Kontext
in einem SGSN und einem PDP-Kontext in einem GGSN. Wenn der SGSN
bevorzugt IPv6 unter GTP verwendet, dann fügt er die IPv6-Adressen in
neuen Nachrichtenfeldern „Alternative
SGSN-Adresse" (Alternative
SGSN Address) ein und eine alternative oder äquivalente IPv4-Adresse in
bestehende Nachrichtenfelder „SGSN-Adresse" (SGSN Address).
Wenn der GGSN IPv6 unter GTP unterstützt, speichert und verwendet
er die alternativen IPv6-SGSN-Adressen für die Kommunikation mit dem
SGSN. Wenn der GGSN nur IPv4 unter GTP unterstützt, speichert und verwendet
er die IPv4-SGSN-Adressen
zur Kommunikation mit dem SGSN. Der SGSN akzeptiert Pakete unabhängig davon,
ob sie an seine IPv4- oder IPv6-Adresse gesendet werden. Der GGSN
sollte SGSN-IP-Adressen, die er nicht verwendet, nicht speichern.
Dieser Mechanismus stellt eine maximale Flexibilität zur Verfügung, da
er nicht auf einem bestimmten DNS-Merkmal basiert und dem GGSN ermöglicht,
Prozesse zu haben, die nur IPv4 verwenden und Prozesse, die sowohl
IPv4 als auch IPv6 verwenden.
-
Die
folgende Tabelle zeigt die spezifischen Informationselemente, die
in der „Create
PDP Context Request"-Nachricht
zur Verfügung
gestellt werden. Tabelle
1:
-
Die „Erzeuge
PDP-Kontext"- bzw. „Create
PDP Context"-Antwortnachricht
wird vom GGSN-Knoten an den SGSN-Knoten als Antwort auf eine „Erzeuge
PDP-Kontext"- bzw. „Create
PDP Context"-Anforderung
gesendet. Wenn der SGSN die „Create
PDP Context"-Antwort
mit dem Ursachenwert, der „Anforderung
akzeptiert" bzw. „Request
Accepted" anzeigt,
empfängt,
aktiviert der SGSN den PDP-Kontext und kann beginnen PDUs an das/von
dem MT von/zu dem externen Datennetzwerk weiterzuleiten.
-
Wenn
der GGSN IPv6 unter GTP unterstützt
und der SGSN ein IPv6-SGSN-Adresse in der Anforderung eingefügt hat,
soll der GGSN die IPv6-Adressen in den neuen Feldern für eine „Alternative
SGSN Address" bzw. „Alternative
GGSN-Adresse" und
eine äquivalente
IPv4-Adresse in den Feldern für
die GGSN-Adresse einfügen.
Der SGSN ver wendet die alternativen IPv6-GGSN-Adressen zur Kommunikation
mit dem GGSN, mit der Ausnahme, wenn der Betreiber die Verwendung
von IPv4 konfiguriert hat. Der SGSN speichert die GGSN-Adressen
und sendet diese zu einem neuen SGSN in einer PDP-Kontextantwortnachricht (bzw.
PDP Context Response) (eine Nachricht, die durch den alten SGSN
an den neuen SGSN gesendet wird, nachdem eine MS eine Routingbereichsaktualisierungsprozedur
zu einem neuen SGSN durchgeführt
hat, sodass der neue SGSN eine PDP-Kontextanforderungsnachricht
an den alten SGSN gesendet hat). Der GGSN sollte Pakete annehmen,
egal ob sie an seine IPv4- oder IPv6-Adresse gesendet werden. Dieser Mechanismus
vermeidet einen Verbindungsverlust, wenn der neue SGSN nur IPv4
unter GTP unterstützt.
-
Tabelle
2 zeigt spezifische Informationselemente, die in die „Create
PDP Context"-Antwortnachricht zur
Verfügung
gestellt werden. Tabelle
2:
-
Darüber hinaus
wird eine „Update
PDP Context" bzw. „Aktualisiere
PDP-Kontext"-Anforderungsnachricht
von einem SGSN an einen GGSN als Teil der GPRS-Inter-SGSN-Routingaktualisierungsprozedur
oder der PDP-Kontextmodifikationsprozedur oder zur Neuverteilung
von Kontexten aufgrund Lastverteilung gesendet. Der SGSN kann SGSN-IPv6-Adressen
nur verwenden, falls er eine IPv6-GGSN-Adresse von einem alten SGSN
(Fall der Inter-SGSN-Routingbereichsaktualisierung) oder GGSN (PDP-Kontextmodifikation)
empfangen hat. Im anderen Fall verwendet der SGSN SGSN-IPv4-Adressen.
-
Falls
der GGSN IPv6 unter GTP unterstützt
und der SGSN eine IPv6-SGSN-Adresse in die Anforderung eingefügt hat,
fügt der
GGSN die IPv6-Adresse in den Feldern für die „alternative GGSN-Adresse" bzw. „Alternative
GGSN-Address" ein
und eine äquivalente
IPv4-Adresse in die Felder für
die „GGSN-Adresse" bzw. „GGSN-Address" ein. Der SGSN verwendet
die alternative IPv6-GGSN-Adressen zur Kommunikation mit dem GGSN.
Der SGSN kann sowohl die IPv4- und IPv6-GGSN-Adressen speichern
und sie an einen neuen SGSN in einer PDP-Kontext-Antwortnachricht
senden. Die alternativen GGSN-Adressfelder werden nicht gesendet, wenn
das GGSN-Adressfeld nicht gesendet wird. Dieser Mechanismus garantiert,
dass der SGSN immer richtige IPv4- und IPv6-GGSN-Adressen speichert,
sodass eine Verbindung nicht verloren geht, wenn eine Bewegung zu
einem neuen SGSN stattfindet, der nur IPv4 unter GTP unterstützt.
-
In
der folgenden Tabelle 3 werden spezifische Informationselemente
in der „Update
PDP Context"-Antwortnachricht
gezeigt. Tabelle
3:
-
Darüber hinaus
soweit es die SGSN-Kontextanforderungsnachricht betrifft, sendet
der neue SGSN diese Nachricht an den alten SGSN, um die Mobilitätsverwaltung
(Mobility Management, MM) und PDP-Kontexte für das MT zu erhalten. Der alte
SGSN antwortet mit einer SGSN-Kontextantwort.
-
Der
neue SGSN fügt
eine „SGSN
Address for Control Plane" bzw.
SGSN-Adresse für
die Steuerebene hinzu. Falls der neue SGSN IPv6 unter GTP unterstützt, fügt er seine
IPv6-Adresse in das Feld „Alternative SGSN-Address
for Control Plane" bzw. „alternative
SGSN-Adresse für
die Steuerebene" ein.
Der alte SGSN wählt
dann die SGSN-Adresse
für die
Steuerebene abhängig
von seiner IPv6-Unterstützung
aus und speichert diese ausgewählte
SGSN-Adresse und verwendet sie, wenn er Steuerebenen nachrichten
für das
MT an den neuen SGSN in der SGSN-Kontextübertragungsprozedur
sendet.
-
Tabelle
4 zeigt spezifische Informationselemente, die in der SGSN-Kontext-Anforderungsnachricht
zur Verfügung
gestellt werden. Tabelle
4:
-
Der
alte SGSN sendet eine SGSN-Kontextantwortnachricht (SGSN Context
Response) an den neuen SGSN als eine Antwort auf eine vorhergehende
SGSN-Kontextanforderung
(SGSN Context Request). Der alte SGSN kann SGSN-IPv6-Adressen nur verwenden,
wenn er eine IPv6-SGSN-Adresse vom neuen SGSN empfängt. Anderenfalls
soll der SGSN SGSN-IPv4-Adressen verwenden.
-
Der
neue SGSN sendet eine SGSN-Kontextbestätigungsnachricht (SGSN Context
Acknowledge) an den alten SGSN als eine Antwort auf die SGSN-Kontextantwortnachricht
(SGSN Context Response). Nur nach Empfang der SGSN-Kontextbestätigungsnachricht
beginnt der alte SGSN Anwenderdatenpakete weiter zu leiten. Die
SGSN-Kontextbestätigung
(SGSN Context Acknowledge) zeigt dem alten SGSN an, dass der neue SGSN
die PDP-Kontextinformationen richtig empfangen hat und bereit ist,
Anwenderdatenpakete zu empfangen.
-
Der
neue SGSN verwendet eine SGSN-Adresse für Anwenderverkehr (SGSN Address
for User Traffic), die von der abweichen kann, die durch den darunterliegenden
Netzwerkdienst (zum Beispiel IP) zur Verfügung gestellt wurde. Der alte
SGSN speichert diese SGSN-Adresse und verwendet sie, wenn er in
der Abwärtsverbindung
(downlink) PDUs an den neuen SGSN für das MT sendet. Der SGSN kann
IPv6-Adressen nur verwenden, wenn er die IPv6-SGSN-Adresse für die Steuerebene
vom alten SGSN erhalten hat. Anderenfalls verwendet der SGSN SGSN-IPv4-Adressen.
-
2 zeigt
ein Signalisierungsdiagramm, das eine Inter-SGSN-Routingbereichsaktualisierungsprozedur
gemäß dem bevorzugten
Ausführungsbeispiel
zeigt.
-
In
diesem Signalisierungsbeispiel sendet das MT eine Routingbereichsaktualisierungsanforderung (Routing
Area Update Request) an einen neuen SGSN, um so eine Routingbereichsaktualisierung
(Routing Area Update) zu initiieren. In Reaktion hierauf sendet
der neue SGSN eine SGSN-Kontextanforderungsnachricht (SGSN Context
Request) einschließlich
der Felder für
die SGSN-Adresse (SGSN Address) und der Felder für die alternative SGSN-Adresse
(Alternative SGSN Address) an den alten SGSN. In Reaktion hierauf
gibt der alte SGSN eine SGSN-Kontextantwortnachricht (SGSN Context
Response) zurück,
in der der gewünschte Adresstyp
in den Feldern für
die SGSN-Adresse
für die
Steuerebene gesendet wird, und alle GGSN-IPv4- und GGSN-IPv6-Adressen werden,
falls verfügbar,
eingefügt.
Der neue SGSN antwortet mit einer SGSN-Kontextbestätigungsnachricht
(SGSN Context Acknowledge) einschließlich der verwendeten Typinformationen
für die Adresse.
Dann sendet der neue SGSN eine „Update PDP Context"- bzw. „Aktualisiere
PDP-Kontext"-Anforderungsnachricht
einschließlich
der eingestellten Typinformationen für die Adresse an den jeweiligen
GGSN. Diese Nachricht wird unter Verwendung einer GGSN-IP-Adresse,
die vom alten GGSN empfangen wurde, gesendet. Wenn der neue SGSN
und GGSN IPv6 auf der Netzwerkebene unterstützen, wird bevorzugt die IPv6-Adresse
des GGSN verwendet. Wenn entweder der SGSN oder der GGSN nicht IPv6
unterstützt,
werden IPv4-Adressen
verwendet. Hier wird angenommen, dass in einer ersten Phase der
Umstellung in Richtung IPv6 alle Knoten IPv4 unterstützen. Der
GGSN gibt eine „Update
PDP Context"- bzw. „Aktualisiere
PDP-Kontext"-Antwortnachricht
einschließlich
der Felder für
die GGSN-Adresse und der Felder für die alternative GGSN-Adresse
zurück.
Diese Adressfelder sind insbesondere in den folgenden Fällen notwendig:
- – Der
alte SGSN unterstützt
nur IPv4 und hat nicht die alternative GGSN-Adresse gespeichert,
sodass der neue SGSN sie vom GGSN empfangen muss, um in der Lage
zu sein, IPv6 für
die Verbindung zu verwenden.
- – Der
GGSN hat seine IP-Adresse verändert
(typischerweise aufgrund einer Neuzuordnung des PDP-Kontexts zu
einer neuen Verarbeitungskarte)
-
Zusätzlich,
wenn aus irgendeinem Grund, der GGSN konfiguriert ist, IPv4 zu verwenden,
um in Richtung des neuen SGSN (aufgrund eines möglichen Problems im Zwischen-IP-Netzwerk)
zu kommunizieren, wird der GGSN nur die IPv4-Adressen zurückgeben
und wird kein alternatives Adressfeld, das die IPv6-Adresse enthält, senden.
-
Schließlich wird
die erforderliche Routingbereichsaktualisierungsprozedur durchgeführt.
-
Als
eine weitere GTP-Signalisierungsnachricht ist eine „Forward
Relocation"- bzw. „Leite
Wechsel weiter"-Anforderungsnachricht
definiert, die durch einen alten SGSN an einen neuen SGSN gesendet
wird, um notwendige Informationen zu übermitteln, um eine Wechselprozedur
für das
SRNS (bedienendes Funknetzwerkuntersystem bzw. Serving Radio Network
Subsystem) zwischen dem neuen SGSN und einem Ziel-RNC (Funknetzwerksteuerung
bzw. Radio Network Controller) des UTRAN durchzuführen. In
diesem Fall fügt
der alte SGSN Informationen in ein Feld für eine SGSN-Adresse für die Steuerebene
(SGSN Adress for Control Plane) hinzu. Wenn der alte SGSN IPv6 unter
GTP unterstützt,
fügt er
seine IPv6-Adresse in dieses Feld ein: Alternative SGSN-Adresse
für die
Steuerebene (Alternativ SGSN Adress for Control Plane). Der neue
SGSN wählt
die SGSN-Adresse für
die Steuerebene (SGSN Adress for Control Plane) abhängig von
seiner IPv6-Unterstützung
aus und speichert diese ausgewählte
SGSN-Adresse und verwendet sie, wenn er Steuerebenennachrichten
für das
MT an den alten SGSN in der SRNS-Wechselprozedur sendet.
-
Tabelle
5 zeigt spezifische Informationselemente, die in der „Forward
Relocation"-Anforderungsnachricht
zur Verfügung
gestellt werden. Tabelle
5:
-
Der
neue SGSN sendet eine „Forward
Relocation"-Antwortnachricht
(Forward Relocation Response) an den alten SGSN als eine Antwort
auf eine vorhergehende „Forward
Relocation"-Anforderungsnachricht (Forward
Relocation Request). Der neue SGSN fügt SGSN-Adressinformationen
für die
Steuerebene hinzu. Der SGSN kann nur IPv6-Adressen einfügen, falls er eine IPv6-SGSN-Adresse
für die
Steuerebene von dem alten SGSN empfangen hat. Anderenfalls verwendet
der neue SGSN SGSN-IPv4-Adressen.
Der alte SGSN speichert diese SGSN-Adresse und verwendet sie, wenn
er Steuerebenennachrichten für
das MT an den neuen SGSN in der SRNS-Wechselprozedur verwendet. 3 zeigt
ein Signalisierungsdiagramm, welches eine SRNS (bedienendes Funknetzwerk
und System)-Wechselprozedur gemäß dem bevorzugten
Ausführungsbeispiel
anzeigt.
-
In
diesem Signalisierungsbeispiel entscheidet ein Quell-SRNS des UTRAN,
eine SRNS-Wechsel durchzuführen
oder zu initiieren und sendet eine „Relocation Required"- bzw. „Wechsel
erforderlich"-Nachricht an
den alten SGSN. Als Antwort darauf bestimmt der alte SGSN, ob die
SRNS-Wechsel (SRNS Relocation) eine Inter-SGSN- SRNS-Wechsel ist und, wenn dem so ist,
sendet er eine „Forward
Relocation Request"-
bzw. „Leite
Wechselanforderung weiter"-Nachricht
einschließlich
des SGSN-Adressfelds
und des alternativen SGSN-Adressfelds für die Steuerebenensignalisierung
an den jeweiligen neuen SGSN. In Antwort hierauf sendet der neue
SGSN eine Wechselanforderungs- bzw. „Relocation Request"-Nachricht an die
Zielfunknetzwerksteuerung (RNC) des UTRAN. Dann werden die Iu-Träger (bearers)
der Funkzugriffsträger
(bzw. radio access bearers, RABs) zwischen dem Ziel-RNC und dem
neuen SGSN aufgebaut, da die bestehenden Funkträger zwischen dem MT und der
Ziel-RNC neu zugeordnet werden, wenn die Ziel-RNC die Rolle des
bedienenden RNC in den neuen SRNS übernimmt. Nachdem der neue
SGSN die Wechselanforderungsbestätigungs-
bzw. „Relocation
Request Acknowledgement"-Nachricht
vom UTRAN empfangen hat, werden die GTP-Tunnel zwischen der Ziel-RNC
und den neuen SGSN aufgebaut. Dann wird die „Forward Relocation Response"- bzw. „Leiter
Wechselantwort weiter"-Nachricht
vom neuen SGSN an den alten SGSN gesendet, um dadurch anzuzeigen,
dass die Ziel-RNC bereit ist, vom Quell-SRNC (Serving RNC) des SRNS
die weitergeleiteten Paketdateneinheiten (PDUs) zu empfangen. Der
alte SGSN setzt die SRNS-Umlagerung durch Senden einer Wechselbefehl-
bzw. „Relocation
Command"-Nachricht an das
Quell SRNC fort. Das Quell-SRNC ist nun bereit, in Abwärtsverbindungsrichtung
(downlink) Anwenderdaten direkt an das Ziel-RNC weiterzuleiten.
Wenn die Datenweiterleitung abgeschlossen ist, sendet das Ziel-RNC
eine „Relocation
Detect"- bzw. „Wechsel
erfasst"-Nachricht
an den neuen SGSN. Als Antwort darauf sendet der neue SGSN eine „Update
PDP Context"- bzw. „Aktualisiere
PDP-Kontext"-Anforderungsnachricht
an einen betroffenen GGSN. Der GGSN gibt eine „Update PDP Context"-Antwortnachricht
einschließlich
der GGSN-Adressfelder und der alternativen GGSN-Adressfelder zurück. Wenn
der neue SGSN eine „Relocation
Complete"- bzw. „Wechsel
abgeschlossen"-Nachricht
von der SRNC empfängt,
wird eine „Forward
Relocation Complete"- „Leite
Wechsel abgeschlossen"-Signalisierung
zwischen dem neuen und alten SGSN ausgetauscht und anschließend initiiert
der alte SGSN eine Iu-Freigabeprozedur
an der SRNC. Schließlich,
wenn die neue Routingbereichskennung unterschiedlich ist, initiiert
das MT eine Routingbereichsaktualisierungsprozedur.
-
Darüber hinaus
enthält
ein PDP-Kontext Informationselement die Session-Managementparameter, die für eine externe
Datennetzwerkadresse definiert sind, die notwendig sind, um zwischen
SGSNs an der Inter-SGSN-Routingbereichsaktualisierungsprozedur
zu übertragen.
-
Wenn
der GGSN die Verwendung von IPv6 unter GTP mit dem alten SGNS verhandelt,
setzt der alte SGSN Felder mit der „alternativen GGSN-Adresse
für Anwenderverkehr" bzw. „Alternative
GGSN Adress for User Traffic" und
der „alternativen
GGSN-Adresse für die Steuerebene" bzw. „Alternative
GGSN Adress for Control Plane",
sodass sie die IPv6-Adressen, die zum Kommunizieren mit dem GGSN
zu verwenden sind, enthalten. Ein neuer SGSN, der nicht IPv6 unter
GTP unterstützt,
ignoriert diese alternativen GGSN-Adressen und verwendet zur Kommunikation
die Felder mit der „GGSN
Adress for User Traffic" und „GGSN-Adress
for Control Plane".
Ein neuer SGSN, der IPv6 unter GTP unterstützt, speichert die GGSN-Adresse
für Anwenderverkehr
(User Traffic) und GGSN-Adresse für die Steuerebene (Control
Plane), aber verwendet zur Kommunikation die alternative GGSN-Adresse
für Anwenderverkehr
und alternative GGSN-Adresse für
die Steuerebene.
-
In
Tabelle 6 ist ein PDP-Kontextinformationsfeld gezeigt. Tabelle
6:
-
Wenn
es erlaubt ist sowohl IPv6- oder IPv4-Adressen in der GGSN-Adresse
für die
Steuerebene zu haben, kann die GGSN-Adresse für die Steuerebene des PDP-Kontextinformationsfeld
manchmal eine IPv6-Adresse und manchmal eine IPv4- Adresse sein, während eines
aktiven PDP-Kontexts. Dies kann passieren zum Beispiel, wenn der
GGSN eine IPv6-Adresse in der GGSN-Adresse für die Steuerebene und eine IPv4-Adresse
in der alternativen GGSN-Adresse für die Steuerebene bei der Aktivierung
des PDP-Kontexts anzeigt, wohingegen ein alter SGSN eine IPv4-Adresse
in der GGSN-Adresse für
die Steuerebene an einen neuen SGSN währen einer Routingbereichsaktualisierung
anzeigt. In diesem Fall ist die GGSN-Adresse für die Steuerebene dieselbe
im GGSN und im alten SGSN, wohingegen die GGSN-Adresse für die Steuerebene unterschiedlich
zu der im neuen SGSN ist. In diesem Fall funktioniert zum Beispiel
Zuordnung einer (In)Rechnungsstellung durch Verwendung der GGSN-Adresse für die Steuerebene
nicht.
-
Gemäß dem bevorzugten
Ausführungsbeispiel
fügt ein
GGSN, der sowohl IPv6 als auch IPv4 unterstützt, sowohl IPv6-Adresse als
auch IPv4-Adresse zu CDRs (Anruf detaillierter Datensätze bzw.
Call Detailed Records), die für
einen PDP-Kontext erzeugt wurden, hinzu, das heißt zum G-CDRs. Der SGSN kann
sowohl eine IP-Adresse, das heißt
GGSN-Adresse für
die Steuerebene, oder zwei IP-Adressen, das heißt GGSN-Adresse für die Steuerebene und alternative
GGSN-Adresse für
die Steuerebene, zu den CDRs, die für den PDP-Kontext erzeugt wurden,
das heißt
zum S-CDRs, hinzufügen.
Auf diese Weise ist es möglich,
für die
CGF (Charging Gateway Funktionality bzw. (In)Rechnungsstellungs-Gateway-Funktionalität) CDRs,
die durch den GGSN erzeugt wurden (einschließlich sowohl IPv6-Adresse als
auch IPv4-Adresse), und CDRs, die durch den/die SGSN(s) (einschließlich sowohl
einer IP Adresse, IPv6 oder IPv4, oder einschließlich sowohl IPv6-Adresse als
auch IPv4-Adresse) zuzuordnen.
-
Zusätzlich zur
Berechnung bzw. (In)Rechnungsstellung (Charging) kann eine Zuordnung
zum Beispiel für
gesetzlich ermächtige Überwachung
(Lawful Interception) oder CAMEL-Nachrichten oder -Informationen benötigt werden.
Im Allgemeinen kann jede beliebige Nachricht oder Information, die
durch mehrere Knoten erzeugt wurde, basierend auf der Adressinformation
und der alternativen Adressinformation zugeordnet bzw. korreliert
werden. Für
Zuordnung einer gesetzlich ermächtigen Überwachung
(Lawful Interception) sendet der GGSN sowohl eine IPv6-Adresse als
auch eine IPv4-Adresse,
wohingegen der SGSN sowohl eine IP-Adresse, das heißt GGSN-Adresse
für die
Steuerebene oder zwei IP-Adressen, das heißt eine GGSN-Adresse für die Steuerebene
und eine alternative GGSN-Adresse für die Steuerebene, senden kann.
Der GGSN sendet so sowohl eine IPv6-Adresse als auch eine IPv4-Adresse,
wohingegen der SGSN entweder eine IPv6-Adresse oder eine IPv4-Adresse
oder beide für
die Zu ordnung gesetzlich ermächtiger Überwachung
(Lawful Interception) senden kann. Auf diese Weise ist es möglich, zum
Beispiel Informationen über
gesetzlich ermächtige Überwachung
(Lawful Interception), die durch den GGSN für den PDP-Kontext erzeugt wurden,
und Informationen über
gesetzlich ermächtige Überwachung
(Lawful Interception), die durch den/die SGSN(s) für den PDP-Kontext
erzeugt wurden, zuzuordnen bzw. zu korrelieren.
-
Es
sei angemerkt, dass die vorliegende Erfindung in jedem beliebigen
zellularen Netzwerk implementiert werden kann, um eine abwärts bzw.
rückwärts kompatible
Adress- oder Nachrichtenzuordnungsfunktion bereit
zu stellen, wenn eine Adressinformation zwischen Netzwerkknoten übertragen
wird. Die Namen der verschiedenen funktionalen Einheiten, Signalisierungsnachrichten
und Informationselemente, die im Zusammenhang mit dem bevorzugten
Ausführungsbeispiel
verwendet wurden, beabsichtigen nicht die Erfindung zu beschränken oder
zu begrenzen. Die bevorzugten Ausführungsbeispiele können daher
innerhalb des Bereichs der beigefügten Ansprüche variieren.