DE60216791T2

DE60216791T2 - Adressenübergang und korrelation von nachrichten zwischen netzknoten

Info

Publication number: DE60216791T2
Application number: DE60216791T
Authority: DE
Inventors: Serge Haumont; Tuija Hurtta; Susanna Kallio
Original assignee: Nokia Oyj
Current assignee: Nokia Oyj
Priority date: 2001-10-05
Filing date: 2002-10-04
Publication date: 2007-10-18
Anticipated expiration: 2022-10-05
Also published as: KR100693975B1; US7818453B2; CN100542165C; PL369412A1; RU2004110040A; US20040243720A1; DE60216791D1; CA2462701A1; CN1565116A; CN101511081A; KR20040039450A; KR20060135946A; RU2273104C2; JP2005506002A; JP3834036B2; ATE348476T1; CN101511081B; WO2003032604A1

Description

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.

Claims

Verfahren zum Bereitstellen einer Adresse oder einer Netzwerkumstellung, wenn ein Verbindungspunkt an einem Ende einer Verbindung von einem ersten Netzwerkknoten zu einem zweiten Netzwerkknoten eines zellularen Netzwerks geändert wird, wobei das Verfahren die Schritte umfasst: a) Übertragen einer Adressinformation und wenigstens einer alternativen Adressinformation in einer Signalisierungsnachricht von dem ersten Netzwerkknoten an den zweiten Netzwerkknoten; b) Auswählen einer von der Adressinformation und der alternativen Adressinformation an dem zweiten Netzwerkknoten; und c) Verwenden der ausgewählten Adressinformation zum Neuaufbau der Verbindung in Richtung eines dritten Netzwerkknotens an dem anderen Ende der Verbindung.
Verfahren gemäß Anspruch 1, wobei, wenn die Verbindung aufgebaut wird, mögliche für diese Verbindung zu verwendende Adressen als die Adressinformation und die wenigstens eine alternative Adressinformation in einer Signalisierungsnachricht von dem ersten Netzwerkknoten an den dritten Netzwerkknoten übertragen werden, und Adressen des dritten Netzwerkknotens in dem ersten Netzwerkknoten gespeichert werden.
Verfahren gemäß Anspruch 1 oder 2, in dem die Adressinformation verwendet werden kann, um einen Netzwerkknoten gemäß einer alten Adressierung oder einem alten Netzwerk, das vor der Umstellung verwendet wurde, zu adressieren und die alternative Adressinformation verwendet werden kann, um einen Netzwerkknoten gemäß der neuen Adressierung oder dem neuen Netzwerk zu adressieren.
Verfahren gemäß einem der vorhergehenden Ansprüche, in dem die Signalisierungsnachricht als Teil einer Orts- oder Routingbereichsaktualisierungsnachricht oder einer Standortwechselprozedur gesendet wird.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei die Signalisierungsnachricht eine GTP-Nachricht ist.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei der erste und zweite Netzwerkknoten SGSNs sind, und der dritte Netzwerkknoten ein GGSN ist.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei die Adressinformation und die alternative Adressinformation eine Anwenderadresse und/oder Netzwerkadressen sind.
Verfahren gemäß Anspruch 7, wobei die Adressinformation und die alternative Adressinformation IPv4- oder IPv6-Adressen sind.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei die Adressinformation und die alternative Adressinformation in jeweils vorherbestimmten Feldern der Signalisierungsnachricht übertragen werden.
Verfahren gemäß Anspruch 9, wobei die vorherbestimmten Felder in einem PDP-Kontextinformationsfeld bereitgestellt werden.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei die alternative Adressinformation als eine optionale Information codiert wird, sodass ein Netzwerkknoten, der die alternative Netzwerkinformation nicht unterstützt, sie ignoriert.
Verfahren gemäß Anspruch 11, wobei die Verbindung neu aufgebaut wird mit einem alten Adressierungsmechanismus basierend auf der Adressinformation, falls der zweite Netzwerkknoten die alternative Adressinformation ignoriert.
Verfahren zum Bereitstellen einer Nachrichtenzuordnungsfunktion in einem Datennetzwerk, wobei das Verfahren die Schritte umfasst: a) Hinzufügen einer Adressinformation und wenigstens einer alternativen Adressinformation zu einer Nachricht an einen ersten Netzwerkknoten; b) Auswählen einer der Adressinformation und der alternativen Adressinformation an einem zweiten Netzwerkknoten, an den die Nachricht geleitet (geroutet) worden ist, wobei die ausgewählte Adressinformation zum Neuaufbau einer Verbindung zu einem dritten Netzwerkknoten an dem anderen Ende der Verbin dung verwendet wird; und c) Verwenden der ausgewählten Adressinformation zum Korrelieren der Nachricht mit einer Nachricht, die von dem dritten Netzwerkknoten empfangen wurde und die wenigstens eine der Adressinformation und der wenigstens einen alternativen Adressinformationen umfasst.
Verfahren gemäß Anspruch 13, wobei die Nachricht eine Rufaufzeichnung für Berechnungszwecke ist.
Verfahren gemäß Anspruch 13 oder 14, wobei der zweite Netzwerkknoten eine Berechnungs-Gateway-Funktionalität ist.
Verfahren gemäß Anspruch 13, wobei die Nachricht eine gesetzlich ermächtigte Überwachungsinformation oder eine Information einer angepassten Anwendung ist.
System, das eine Adresse oder einen Netzwerkübergang bereitstellt, wobei das System umfasst: a) einen ersten Netzwerkknoten zum Übertragen einer Adressinformation und wenigstens einer alternativen Adressinformation in einer Signalisierungsnachricht, falls ein Verbindungspunkt an einem Ende einer Verbindung geändert wird, von dem ersten Netzwerkknoten; und b) einen zweiten Netzwerkknoten zum Empfangen der Signalisierungsnachricht, falls der Verbindungspunkt zu dem zweiten Netzwerkknoten geändert wird, zum Auswählen einer der Adressinformation und der alternativen Adressinformation, und zum Verwenden der ausgewählten Adressinformation zum Neuaufbau der Verbindung in Richtung eines dritten Netzwerkknotens an dem anderen Ende der Verbindung.
Systemgemäß Anspruch 17, wobei der erste und zweite Netzwerkknoten SGSNs eines GPRS-Backbone-Netzwerks sind und wobei der dritte Netzwerkknoten ein GGSN eines GPRS-Backbone-Netzwerks ist.
System zum Bereitstellen einer Nachrichtenzuordnungsfunktion in einem Datennetzwerk, wobei das System umfasst: einen ersten Netzwerkknoten zum Hinzufügen einer Adressinformation und wenigstens einer alternativen Adressinformation zu einer Nachricht; einen zweiten Netzwerkknoten zum Empfangen der Nachricht und zum Auswäh len einer der Adressinformationen und der alternativen Adressinformation, wobei die ausgewählte Adressinformation zum Neuaufbau einer Verbindung zu einem dritten Netzwerkknoten an dem anderen Ende der Verbindung verwendet wird; und c) Verwenden der ausgewählten Adressinformation zum Korrelieren der Nachricht mit einer Nachricht, die von dem dritten Netzwerkknoten empfangen wurde und die wenigstens eine der Adressinformation und der wenigstens einen alternativen Adressinformation umfasst.
System gemäß Anspruch 19, wobei die Nachricht eine Rufaufzeichnung für Berechnungszwecke ist.
System gemäß Anspruch 19 oder 20, wobei der zweite Netzwerkknoten eine Berechungs-Gateway-Funktonalität hat.
System gemäß Anspruch 19, wobei die Nachricht eine gesetzlich ermächtigte Überwachungsinformation oder eine Information einer angepassten Anwendung ist.
Netzwerkknoten eines zellularen Netzwerks, wobei der Netzwerkknoten eingerichtet ist, eine Adressinformation und wenigstens eine alternative Adressinformation in einer Signalisierungsnachricht zu übertragen, falls ein Verbindungspunkt an einem Ende der Verbindung von dem Netzwerkknoten zu einem zweiten Netzwerkknoten geändert wird, wobei die Signalisierungsnachricht an den zweiten Netzwerkknoten übertragen wird, zu dem der Verbindungspunkt an dem einen Ende der Verbindung geändert wird, und wobei eine der Adressinformation und der alternativen Adressinformation zum Neuaufbau einer Verbindung zu einem dritten Netzwerkknoten an dem anderen der Verbindung verwendet wird.
Netzwerkknoten gemäß Anspruch 23, wobei der Netzwerkknoten angepasst ist, die Adressinformation und die alternative Adressinformation zu speichern, um verwendet zu werden, den dritten Netzwerkknoten zu adressieren.
Netzwerkknoten gemäß einem der Ansprüche 23 bis 24, wobei der Netzwerkknoten ein SGSN ist.
Netzwerkknoten eines zellularen Netzwerks, wobei der Netzwerkknoten eingerichtet ist, eine Nachricht zu empfangen, falls ein Verbindungspunkt an einem Ende einer Verbindung von einem ersten Netzwerkknoten zu einem Netzwerkknoten, der ein zweiter Netzwerkknoten ist, verändert wird, eine einer Adressinformation und einer alternativen Adressinformation, die in der Nachricht zur Verfügung gestellt werden, auszuwählen und die ausgewählte Adressinformation zu verwenden zum Neuaufbau der Verbindung in Richtung eines dritten Netzwerkknotens an dem anderen Ende der Verbindung, wobei die Nachricht von dem ersten Netzwerkknoten, von dem der Verbindungspunkt an dem einen Ende der Verbindung verändert wird, empfangen wurde.
Netzwerkknoten gemäß Anspruch 26, wobei der Netzwerkknoten eingerichtet ist, Daten und/oder Signalisierung entweder über die Adressinformation oder die alternative Adressinformation zu empfangen.
Netzwerkknoten gemäß Anspruch 26 oder 27, wobei der Netzwerkknoten ein SGSN ist.
Netzwerkknoten eines zellularen Netzwerks, wobei der Netzwerkknoten eingerichtet ist, eine Nachricht zu empfangen, falls ein Verbindungspunkt an einem Ende einer Verbindung von einem ersten Netzwerkknoten zu einem Netzwerkknoten, der ein zweiter Netzwerkknoten ist, verändert wird, eine einer Adressinformation und einer alternativen Adressinformation, die in der Nachricht zur Verfügung gestellt werden, auszuwählen und die ausgewählte Adressinformation zu verwenden zum Korrelieren der Nachricht mit einer Nachricht, die von einem dritten Netzwerkknoten empfangen wurde und wenigstens eine der Adressinformation und der alternativen Adressinformation enthält, wobei die Nachricht von dem ersten Netzwerkknoten empfangen wurde, von dem der Verbindungspunkt an dem einen Ende der Verbindung verändert wurde, und wobei eine der Adressinformation und der alternativen Adressinformation zum Neuaufbau einer Verbindung zu einem dritten Netzwerkknoten an dem anderen Ende der Verbindung verwendet wird.
Netzwerkknoten gemäß Anspruch 29, wobei der Netzwerkknoten eine Berechnungs-Gateway-Funktonalität hat und die Signalisierungsnachricht eine Berechnungsaufzeichnung ist.
Netzwerkknoten gemäß Anspruch 29, wobei die Nachricht eine gesetzlich ermächtigte Überwachungsfunktion oder eine Information einer angepassten Anwendung ist.