DE10360531A1

DE10360531A1 - Verfahren, Netzübergangsknoten und Endgerät zur paketorientierten Datenübertragung

Info

Publication number: DE10360531A1
Application number: DE10360531A
Authority: DE
Inventors: Thomas Dr. Belling
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2003-12-22
Filing date: 2003-12-22
Publication date: 2005-07-21
Also published as: WO2005062567A1

Abstract

Die Erfindung betrifft ein Verfahren und einen Netzübergangsknoten (GGSN) zur paketorientierten Datenübertragung zwischen mindestens einem Endgerät (Endgerät A), insbesondere einem mobilen Endgerät, und einem paketorientierten Kommunikationsnetz über einen Netzübergangsknoten, DOLLAR A wobei für die Datenübertragung zum Netzübergangsknoten ein Kommunikationskontext verwendet wird, dem ein so genannter Subnetz-Präfix zugewiesen ist. Vorzugsweise wird zur Datenübertragung das Protokoll IP Version 6 verwendet. Ein wesentlicher Aspekt der Erfindung besteht in einem Verfahren, bei dem DOLLAR A - im Netzübergangsknoten demselben Subnetz-Präfix mehrere Kommunikationskontexte zugewiesen wird, DOLLAR A - eine dem Endgerät zugeordnete Schnittstellenidentifikationsnummer innerhalb eines Kommunikationskontextes empfangen oder ausgewählt und gespeichert wird, DOLLAR A - und beim Senden von Daten zum Endgerät ein geeigneter Kommunikationskontext anhand der gespeicherten Schnittstellenidentifikationsnummer ausgewählt wird. DOLLAR A Ein weiterer Aspekt der Erfindung liegt in einem Netzübergangsknoten sowie einem Endgerät, die mit Mitteln zum Durchführen des oben beschriebenen Verfahrens ausgestaltet sind.

Description

Die Erfindung betrifft ein Verfahren und einen Netzübergangsknoten zur paketorientierten Datenübertragung zwischen mindestens einem Endgerät, insbesondere einem mobilen Endgerät, und einem paketorientierten Kommunikationsnetz über einen Netzübergangsknoten, wobei für die Datenübertragung zum Netzübergangsknoten ein Kommunikationskontext verwendet wird, dem ein sogenannter Subnetz-Präfix zugewiesen ist. Des weiteren betrifft die Erfindung ein Endgerät zur Durchführung des erfindungsgemäßen Verfahrens.

Bei Version 6 des Internet Protokolls (IPv6) werden 16 Byte IP Adressen verwendet. Davon werden gemäß RFC 3513 der IETF die letzten 8 Byte als sogenannte „Interface ID" (Schnittstellenidentifikationsnummern) zur Unterscheidung von Netzknoten innerhalb eines Subnetzes der tiefsten Hierarchiestufe verwendet, und die ersten 8 Byte als sogenannter „Subnet Präfix" (Netzadresse für ein paketorientiertes unterteiltes Kommunikationsnetz) zur Unterscheidung der Subnetze verwendet. Damit wird eine Autokonfiguration der IPv6 Adresse ermöglicht. In IPv6 sind zwei Mechanismen zur Autokonfiguration von Adressen definiert, die sogenannte „Stateless Address Autoconfiguration, RFC 2462, und die sogenannte „Statefull Address Autoconfiguration" mit Hilfe des so genannten „Dynamit Host Configuration Protocol for IPv6" (DHCPv6), RFC 3315.

Ein von der 3GPP standardisiertes Mobilfunknetz kann den sogenannten „General Packet Radio Service (GPRS)", 3GPP TS 23.060 und TS 29.061, beinhalten. Hier wird das mobile Endge rät mittels eines sogenannten „PDP Kontextes" (Kommunikationskontextes) mit einem Netzübergangsknoten, vorzugsweise mit einem sogenannten „Gateway GPRS Support Node" (GGSN) verbunden. Innerhalb des PDP Kontextes können IPv6 Pakete transportiert werden. In diesem Fall wird jedem PDP Kontext ein eigenes IPv6 Subnetz zugewiesen, das mittels einer eigenen 8 Byte Subnet Präfix identifiziert wird. Der GGSN verbindet dieses Subnetz als sogenannter Router mit anderen IPv6 Subnetzen, und verbindet dadurch das mobile IPv6 Endgerät mit dem Internet. Die mobilen IPv6 Endgeräte nutzen IPv6 Adressenautokonfiguration gemäß RFC 2462 oder RFC 3315 zur Auswahl ihrer IPv6 Adressen. Mittels eines PDP Kontextes und dem entsprechenden IPv6 Subnetz sind nur ein oder sehr wenige mobile Endgeräte mit dem GGSN verbunden, obwohl für ihre Unterscheidung 8 Byte reserviert sind.

Es ist damit zu rechnen, dass sehr viele mobile Endgeräte von 3GPP Mobilfunknetzen unterstützt werden müssen, wobei für fast jedes mobile IPv6 Endgerät ein eigener PDP Kontext und somit ein eigenes IPv6 Subnetz benötigt wird. Bei bestimmten Konfigurationen eines 3GPP Mobilfunknetzes kann es dadurch zu einer Knappheit von Subnetz Präfixen kommen. Wird beispielsweise dem Betreiber eines 3GPP Mobilfunknetzes ein 4 Byte IPv6 Adress-Präfix für sein Netz zugeteilt, und verwendet der Betreiber weitere 2 Byte für die Unterscheidung seiner GGSNs, so bleiben dem Betreiber pro GGSN nur 2 Byte (65536) zur Unterscheidung der PDP Kontexte. IETF RFC 3177 empfiehlt sogar, Betreibern nur einen wesentlich kleineren Adressraum zur Verfügung zu stellen, in dem ihnen einen 47 bit oder etwas kürzerer Präfix und nicht wie im Beispiel ein 32 bit Präfix zugewiesen wird.

Die Aufgabe der Erfindung besteht darin, eine einen Ressourcenengpass von PDP Kontexten durch eine limitierte Zahl von IPv6 8 Byte Subnetz-Präfixen zu vermeiden.

Die Aufgabe wird durch ein Verfahren und durch eine Vorrichtung eines Netzübergangsknotens sowie eines Endgerätes gemäß der unabhängigen Patentansprüche gelöst. Vorteilhafte Weiterbildungen der Erfindung sind in den abhängigen Ansprüchen angegeben.

Ein wesentlicher Aspekt der Erfindung besteht in einem Verfahren, bei dem

– im Netzübergangsknoten demselben Subnetz-Präfix mehrere Kommunikationskontexte zugewiesen wird,
– eine dem Endgerät zugeordnete Schnittstellenidentifikationsnummer innerhalb eines Kommunikationskontextes empfangen oder ausgewählt und gespeichert wird,
– und beim Senden von Daten zum Endgerät ein geeigneter Kommunikationskontext anhand der gespeicherten Schnittstellenidentifikationsnummer ausgewählt wird.

Ein weiterer Aspekt der Erfindung liegt in einem Netzübergangsknoten sowie einem Endgerät, die mit Mitteln zum Durchführen des oben beschriebenen Verfahrens ausgestaltet sind.

Die Erfindung ist auch bei anderen Szenarien anwendbar, wo viele IPv6 Subnetze, die die IPv6 Adressen-Autokonfiguration nützen, mittels eines oder wenigen Netzknoten mit dem Internet verbunden sind. Ein Beispiel außerhalb von 3GPP ist ein sogenannter Internet Access Point, der IPv6 Endgeräten ermöglicht, sich mittels Wählverbindungen über das Telefonnetz mit dem Internet zu verbinden.

Vorzugsweise werden mit der Erfindungen folgende Probleme gelöst:

Problem 1: Zwei IPv6 Endgeräte dürfen nicht die selbe Interface ID zur Bildung und somit die selbe IPv6 Adresse nützen.
Problem 2: Der GGSN muss empfangene Pakete an den richtigen PDP Kontext weiter leiten.
Problem 3: Ein Transport von Paketen zwischen mobilen IPv6 Endgeräten in verschiedenen PDP Kontexten mit dem selben Subnetz Präfix muss möglich sein.

Weitere Vorteile der Erfindung ergeben sich aus den nachstehend beschriebenen, anhand einer Zeichnung erläuterten Ausführungsformen.

Die Zeichnung zeigt:

1 eine schematisch dargestellte typische Netzkonfiguration,

2 schematisch ein Meldungsablaufdiagramm im Falle der genannten „Stateless Adress Autoconfiguration" und

3 schematisch ein Meldungsablaufdiagramm im Falle der genannten „Statefull Adress Autoconfiguration".

1 zeigt die eingangs beschriebene Netzkonfiguration. Gemäß dem Stand der Technik werden die mobile IPv6 Endgeräte A, B, und C jeweils mittels eines eignen PDP Kontextes (PDP Kontext A, B und C) mit dem Gateway GPRS Support Node GGSN verbunden. Innerhalb der PDP Kontexte werden IPv6 Pakete transportiert. Der GGSN verbindet die PDP Kontexte mit einem IPv6 Netz. Oft ist dem GGSN ein so genannter „Edge Router" vorgeschalten. Die mobilen IPv6 Endgeräte nutzen IPv6 Adressenautokonfiguration gemäß RFC 2462 oder RFC 3315 zur Auswahl ihrer IPv6 Adressen. Im Falle der Statefull Address Autoconfiguration gemäß RFC 3315 wird typischerweise ein externer DHCP Server verwendet.
Erfindungsgemäß wird derselbe 8 Byte IPv6 Subnet Präfix mehren PDP Kontexten zugewiesen. Entsprechend befinden sich die Endgeräte A, B und C alle im IPv6 Subnetz 1, und ihre globale IPv6 Addresse setzt sich jeweils aus dem IPv6 Subnet Präfix 1 und einer individuellen Schnittstellenidentifikationsnummer (Interface ID A, Interface ID B, Interface ID C) zusammen.
Die in den 2 und 3 mit einer „Klammer" versehenen Meldungsabläufe können optional und alternativ ablaufen.
2 stellt einen typischen Ablauf der Kommunikation bei der Stateless Address Autoconfiguration dar. Die Netzkonfiguration entspricht 1, wobei kein DHCP Server verwendet wird. Das mobile Endgerät A beginnt die Kommunikation durch das Aktivieren des PDP Kontextes A (2, Schritt 1.). Der GGSN entscheidet in seiner Antwortnachricht, dass die Stateless Address Autoconfiguration verwendet wird (2, Schritt 3.). Im Weiteren sind folgende Abläufe dargestellt:

– Die optionalen Neighbor Discovery (2, Schritte 4. und 5.) kann beim Verbindungsaufbau oder während der bestehenden Verbindung ablaufen.
– Das Endgerät A sendet ein IP Nutzpaket an einen beliebigen Empfänger(2, Schritte 6. bis 8.)
– Das Endgerät A empfängt ein IP Nutzpaket von einem beliebigen Empfänger (2, Schritte 9. bis 11.)
– Das Endgerät A sendet ein IP Nutzpaket das Endgerät B im selben Subnetz 1 (2, Schritte 12. bis 16.)
– Das Endgerät A beendet die Kommunikation durch Löschen des PDP Kontextes A (2, Schritte 17. bis 19.)

3 stellt einen typischen Ablauf der Kommunikation bei der Statefull Address Autoconfiguration dar. Die Netzkonfiguration entspricht 1, wobei der DHCP Server verwendet wird. Das mobile Endgerät A beginnt die Kommunikation durch das Aktivieren des PDP Kontextes A (3, Schritt 1.). Der GGSN entscheidet in seiner Antwortnachricht, dass die Statefull Address Autoconfiguration verwendet wird (3, Schritt 2.). Im Weiteren sind folgende Abläufe dargestellt:

– Die Statefull Address Autoconfiguration der globalen IPv6 Addresse des Endgerätes A mittels DHCP (3, Schritte 3. bis 12.)
– Das Endgerät A empfängt ein IP Nutzpaket von einem beliebigen Empfänger (3, Schritte 13. bis 15.)
– Das Endgerät A sendet ein IP Nutzpaket das Endgerät B im selben Subnetz 1 (3, Schritte 16. bis 20.)
– Das Endgerät A beendet die Kommunikation durch Löschen des PDP Kontextes A (3, Schritte 21. bis 23.)

Die Lösungen zu den oben dargestellten Problemen werden anhand der Figuren im folgenden genauer beschrieben:
Lösung zu Problem 1:
Stateless Address Autoconfiguration (2)
Der Gateway GPRS Support Node GGSN unterhält eine Datenbasis mit verwendeten Interface IDs (Schnittstellenidentifikationsnummern) für einen gegeben Subnetz Präfix, und stellt so sicher, dass die selben Interface IDs nicht mehrfach verwendet werden. Der GGSN kann beispielsweise eine Liste aller verwen deten Interface IDs unterhalten oder für jeden PDP Kontext (Kommunikationskontext) die verwendeten Interface IDs getrennt abspeichern (2, Schritt 2., 5., 7.). Auch die Liste aller Interface IDs enthält vorzugsweise Informationen über den zugehörigen PDP Kontext.
Der GGSN sucht bei der Aktivierung des PDP Kontextes eine noch nicht verwendete Interface ID auf und teilt sie dem UE in der zur Aktivierung des PDP Kontextes gehörenden Signalisierung mit (2, Schritt 1. bis 3.). Der GGSN speichert, dass diese Interface ID verwendet wird. Der GGSN sucht sich auch eine noch nicht verwendete Interface ID für sein Ende des PDP Kontextes aus. Der GGSN kann hierfür bei allen PDP Kontexten dieselbe Interface ID verwenden, da sie nur zur Bildung einer sogenannten link-local IPv6 Adresse verwendet wird. Der GGSN speichert in jedem Fall, dass die Interface ID verwendet wird (nicht in 2 dargestellt).
Der GGSN kann gemäß RFC 2462 auch aus speziellen so genannten „Neighbor Solicitation Messages" (2, Schritt 4.) über verwendete Interface IDs lernen. Ebenso enthält die so genannte Source IP Adresse im IP Header von vom mobilen Ipv6 Endgerät gesendeten Paketen die Interface ID (2, Schritt 6.). Der GGSN speichert auch verwendete Interface IDs ab, über die er auf diese beiden Arten erfährt.
Wenn der PDP Kontext gelöscht wird, entfernt der GGSN die entsprechenden Interface IDs wieder aus der Liste (2, Schritt 17., 18., 19.).
Gemäß TS 29.061 weist der GGSN beim Aktivieren des PDP Kontextes mit Hilfe der dabei verwendeten Signalisierung dem mobilen IPv6 Endgerät eine Interface ID zu, die das mobile IPv6 Endgerät aber nur zur Bildung einer so genannten link-local IPv6 Adresse, aber nicht notwendigerweise auch zur Bildung einer globalen IPv6 Adresse nützen muss (2, Schritt 3.).
Vorzugsweise wird die Spezifikation so abgewandelt, dass das Endgerät im Falle der stateless Adress Autoconfiguration dieselbe Interface ID für die Bildung der link-lokal IP Adresse und der globalen IPv6 Adresse verwenden muss. Um eine Abwärtskompatibilität zu gewährleisten, gibt das mobile IPv6 vorzugsweise in dem so genannten PDP Activate Request (2, Schritt 1.) an, ob es die vom GGSN bereitgestellte Interface ID im Falle der Stateless Adress Autoconfiguration auch zur Bildung der globalen IPv6 Adresse verwenden wird. Andernfalls verwendet der GGSN ein eignes IPv6 Subnetz für den entsprechenden PDP Kontext.
Um Fehlverhalten auszuschließen, und auch für den Fall, dass die Änderung in der Spezifikation nicht möglich ist, überprüft der GGSN beim Erhalt einer Neighbor Solicitation Message zur sogenannten „Duplicate Address Detection" gemäß RFC 2462 (2, Schritt 4), ob die dort angegebene Interface ID bereits in einem anderen PDP Kontext oder im selben PDP Kontext vom GGSN Interface verwendet wird. Sollte dies der Fall sein, antwortet der GGSN mit einer so genannten „Neighbor Advertisement Message" mit einer so genannten „tentative target address", die die schon verwendete Interface ID enthält. Dadurch wird gemäß RFC 2462 dem mobilen IPv6 Endgerät untersagt, diese Interface ID zu verwenden.
Beim Erhalt von IP Paketen mit einem in einem anderen PDP Kontext bereits verwendeten Interface ID deaktiviert der GGSN den PDP Kontext. Auf Grund des 64 bit Adressraums der Interface IDs sind solche Kollisionen sehr unwahrscheinlich.
Statefull Address Autoconfiguration (3)
Nach dem Aktivieren eines PDP Kontextes verlangt das mobile Endgerät mit Hilfe eines DHCP Requests gemäß RFC 3315 die Zuordnung einer global eindeutigen IPv6 Adresse von einem DHCP Server (3, Schritt 3. bis 12.). Der DHCP Server vergibt IP Adressen, wobei er für jeden PDP Kontext den richtigen Network Präfix liefert für jeden Network Präfix eindeutige Interface IDs (3, Schritt 9). Hierbei kann erfindungsgemäß der selbe Network Präfix mehreren PDP Kontexten zugeordnet sein. Der DHCP Server kann in den GGSN integriert sein oder dem GGSN vorgeschaltet sein (In 1 und 3 ist ein externer DHCP Server dargestellt).
Falls der DHCP Server in den GGSN integriert ist, weiß der DHCP Server direkt von dem PDP Kontext, in dem der Request empfangen wurde, und wählt den Network Präfix entsprechend.
Falls der DHCP Server dem GGSN vorgeschaltet wurde, übernimmt der GGSN die Aufgabe eines so genannten DHCP Relay Agents, wie in TS 29.061 beschrieben. Der GGSN verpackt innerhalb eines PDP Kontextes empfangene DHCP Nachrichten (3, Schritt 3., 7.) in DHCP Relay Forward Nachrichten und schickt diese Nachrichten an den DHCP Server (3, Schritt 4., 8.). Innerhalb der DHCP Relay Forward Nachrichten wird der dem PDP Kontext entsprechende Netzwerk Präfix sowie zur eindeutigen Identifizierung des PDP Kontextes auch eine so genannte DHCP Interface ID (nicht identisch zur IPv6 Interface ID) angegeben. Der DHCP Server beantwortet die DHCP Nachricht, wobei er die Nachricht an das mobile IPv6 Endgerät in eine DHCP Relay Backward Nachrichten enkapsuliert (3, Schritt 5., 10.), die auch die selbe DHCP Interface ID ent hält. Der DHCP Server verhält sich gemäß RFC 3315 und benötigt keine spezielle Anpassung, und kein Wissen über PDP Kontexte. Der GGSN entnimmt der DHCP Relay Backward Nachricht die DHCP Nachricht an das mobile Endgerät und reicht diese Nachricht in dem mit der DHCP Interface ID angegebenen PDP Kontext weiter (3, Schritt 6., 12.). Erfindungsgemäß entnimmt der GGSN der DHCP Reply Message die zugewiesene IP Adresse und speichert die darin enthaltene Interface ID ab (3, Schritt 11).
Wenn der PDP Kontext gelöscht wird, entfernt der GGSN die entsprechenden Interface IDs wieder aus der Liste. (3, Schritt 21. bis 23.)
Lösung zu Problem 2:
Der GGSN speichert erfindungsgemäß die in einem gegebenen PDP Kontext verwendeten Interface IDs oder vollständigen IPv6 Adressen ab. Beim Empfang eines IPv6 Nutzpakets betrachtet der GGSN neben dem Subnetz Präfix auch die Interface ID der vollständige IPv6 Zieladresse, um den PDP Kontext auszuwählen, in dem er das Nutzpaket weiterreicht (2, Schritt 10., 15., sowie 3, Schritt 14., 19.).
Für die Stateless Adress Autoconfiguration wurde bereits beschrieben, wie der GGSN die verwendeten Interface IDs feststellt und speichert (2, Schritt 2., 5., 7.). Für die Stateful Adress Autoconfiguration entnimmt der GGSN die zugewiesene IPv6 Adresse der DHCP Antwort (3, Schritt 11).
Lösung zu Problem 3:
Der PDP Kontext stellt eine Punkt-zu-Punkt Verbindung dar. Deswegen sendet das mobile IPv6 Endgerät alle Pakete an den GGSN, selbst wenn das Ziel der Pakete eine IP Adresse mit dem selben Netzwerk Präfix ist (2, Schritt 12. sowie 3, Schritt 16.). Da der PDP Kontext als Punkt-zu-Punkt Verbindung auch keine Adressen auf der Transportebene unterhalb IP vorsieht, wird das mobile IPv6 Endgerät keine Address Resolution gemäß RFC 2461 betreiben.
Das Weiterreichen von IPv6 Paketen zwischen PDP Kontexten mit dem selben Subnetz Präfix kann auf zwei Arten erreicht werden:

A. Der GGSN reicht Pakete zwischen PDP Kontexten mit dem selben Subnetz Präfix direkt weiter. Dazu prüft der GGSN bei Erhalt von IPv6 Paketen innerhalb eines PDP Kontextes, ob die Pakete an eine IPv6 global eindeutige Zieladresse mit der selben Subnetz Präfix gerichtet sind, und reicht die Pakete gegebenenfalls weiter (nicht in 2 und 3 dargestellt).
B. Der GGSN reicht alle in einem PDP Kontext enthaltenen Pakete unabhängig von der Zieladresse an einen so genannten Edge Router weiter (2, Schritt 13. sowie 3, Schritt 17.). Sollten die Pakete an eine IPv6 Zieladresse im selben Subnetz gerichtet sein, sendet sie der Edge Router zurück an den GGSN (2, Schritt 14. sowie 3, Schritt 18.). Der GGSN verwendet die unter 2. beschriebenen Mechanismen, um den PDP Kontext auszuwählen 2, Schritt 15. sowie 3, Schritt 19.).

Claims

Verfahren zur paketorientierten Datenübertragung zwischen mindestens einem Endgerät (Endgerät A) und einem paketorientierten Kommunikationsnetz über einen Netzübergangsknoten (GGSN), das zur Datenübertragung vorzugsweise das Protokoll IP Version 6 verwendet, wobei für die Datenübertragung zum Netzübergangsknoten (GGSN) ein Kommunikationskontext verwendet wird, dem ein sogenannter Subnetz-Präfix zugewiesen ist, dadurch gekennzeichnet, dass – im Netzübergangsknoten (GGSN) demselben Subnetz-Präfix mehrere Kommunikationskontexte zugewiesen wird, – eine dem Endgerät (Endgerät A) zugeordnete Schnittstellenidentifikationsnummer innerhalb eines Kommunikationskontextes empfangen oder ausgewählt und gespeichert wird, – und beim Senden von Daten zum Endgerät (Endgerät A) ein geeigneter Kommunikationskontext anhand der gespeicherten Schnittstellenidentifikationsnummer ausgewählt wird.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Netzübergangsknoten (GGSN) durch einen sogenannten Gateway GPRS Support Node repräsentiert wird.
Verfahren nach einem der vorhergehenden Ansprüchen, dadurch gekennzeichnet, dass der Kommunikationskontext durch einen sogenannten PDP-Kontext repräsentiert wird.
Verfahren nach einem der vorhergehenden Ansprüchen, dadurch gekennzeichnet, dass die Schnittstellenidentifikationsnummer durch die 8 Byte Interface ID einer IPv6-Netzadresse repräsentiert wird.
Verfahren nach einem der vorhergehenden Ansprüchen, dadurch gekennzeichnet, dass das Endgerät (Endgerät A) ein von der 3GPP standardisiertes so genanntes „User Equipment" ist, das die so genannte UTRAN (= UMTS Terrestrial Radio Access Network) Luftschnittstelle verwendet.
Verfahren nach einem der vorhergehenden Ansprüchen, dadurch gekennzeichnet, dass das Endgerät (Endgerät A) ein von der 3GPP standardisierte so genannte „Mobile Station" ist, die die so genannte GERAN ( = GSM EDGE Radio Access Network) Luftschnittstelle verwendet.
Verfahren nach einem der vorhergehenden Ansprüchen, dadurch gekennzeichnet, dass das Endgerät (Endgerät A) im Falle der sogenannten Stateless Address Autoconfiguration die vom Netzübergangsknoten (GGSN) zugeordnete Schnittstellenidentifikationsnummer zum Bilden einer globalen IPv6 Address verwendet.
Verfahren nach einem der vorhergehenden Ansprüchen, dadurch gekennzeichnet, dass das Endgerät (Endgerät A) beim Aktivieren des Kommunikationskontextes einem Netzverbindungsknoten mitteilt, ob es im Falle der sogenannten Stateless Address Autoconfiguration die vom Netzübergangsknoten (GGSN) zu geordnete Schnittstellenidentifikationsnummer zum Bilden der globalen IPv6 Address verwendet (2, Schritt 1.).
Verfahren nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, dass ein Parameter in die „Create PDP Context Request" und „Activate PDP Context Request" Nachrichten eingeführt wird, der anzeigt, dass das Endgerät (Endgerät A) im Falle der Stateless Address Autoconfiguration die vom Netzübergangsknoten (GGSN) zugeordnete Schnittstellenidentifikationsnummer zum Bilden der globalen IPv6 Address verwendet (2, Schritt 1.).
Verfahren nach einem der vorhergehenden Ansprüchen, dadurch gekennzeichnet, dass der Netzverbindungsknoten im Falle der Stateless Address Autoconfiguration denselben Subnetz-Präfix nur dann mehreren Kommunikationskontextes zuweist, wenn die Endgeräte angezeigt haben, dass sie die zugeordnete Schnittstellenidentifikationsnummer zum Bilden der globalen IPv6 Address verwenden.
Verfahren nach einem der vorhergehenden Ansprüchen, dadurch gekennzeichnet, dass der Netzübergangsknoten (GGSN) die beim Aktivieren des Kommunikationskontextes dem Endgerät zugewiesene Schnittstellenidentifikationsnummer abspeichert.
Verfahren nach einem der vorhergehenden Ansprüchen, dadurch gekennzeichnet, dass der der Netzübergangsknoten (GGSN) die bei der so genannten Neighbor Discovery empfangene Schnittstellenidentifikationsnummer abspeichert (2, Schritt 5.).
Verfahren nach einem der vorhergehenden Ansprüchen, dadurch gekennzeichnet, dass der der Netzübergangsknoten (GGSN bei vom Endgerät empfangenen Daten als IP Paketen die in der Ursprungsaddresse enthaltene Schnittstellenidentifikationsnummer abspeichert (2, Schritt 7.).
Verfahren nach einem der vorhergehenden Ansprüchen, dadurch gekennzeichnet, dass der Netzübergangsknoten (GGSN) die in der DHCP Reply Nachricht enthaltene Schnittstellenidentifikationsnummer abspeichert (3, Schritt 1).
Verfahren nach einem der vorhergehenden Ansprüchen, dadurch gekennzeichnet, dass der Netzübergangsknoten Pakete, die von einem ersten Endgerät (Endgerät A) in einem Kommunikationskontext empfangen werden und an ein zweites Endgerät (Endgerät B) im selben Subnetz aber einem anderen Kommunikationskontext gerichtet sind, direkt an das zweite Endgerät (Endgerät B) weitersendet.
Netzübergangsknoten (GGSN) zur Durchführung des Verfahrens nach einem der vorhergehenden Ansprüche, vorzugsweise ausgestaltet für eine Datenübertragung gemäß dem Protokoll IP Version 6 zwischen einem Endgerät (Endgerät A) und einem paketorientierten Kommunikationsnetz unter Verwendung eines Kommunikationskontextes, dem ein sogenannter Subnetz-Präfix zugewiesen ist, aufweisend: – Mittel zum Auswählen oder Empfangen, und zum Speichern einer dem mobilen Endgerät (Endgerät A) zugeordneten Schnittstellenidentifikationsnummer innerhalb eines Kommunikationskontextes, – Mittel zum Zuweisen von mehreren Kommunikationskontexten zu demselben Subnetz-Präfix und – Mittel zum Auswählen eines geeigneten Kommunikationskontextes zum Senden von Daten zum Endgerät (Endgerät A) anhand der gespeicherten Schnittstellenidentifikationsnummer.
Endgerät (Endgerät A) zur Durchführung des Verfahrens nach einem der vorhergehenden Ansprüche, vorzugsweise ausgestaltet für eine Datenübertragung gemäß dem Protokoll IP Version 6 über einen Netzübergangsknoten (GGSN) zu einem paketorientierten Kommunikationsnetz unter Verwendung eines Kommunikationskontextes, dem ein sogenannter Subnetz-Präfix zugewiesen ist, aufweisend: – Mittel zum Empfangen einer Schnittstellenidentifikationsnummer innerhalb der der Signalisierung zum Aufbau des Kommunikationskontextes, die zum Bilden einer globalen Netzadresse, vorzugsweise einer IPv6 Adresse, verwendet wird, – Mittel zur Signalisierung ob die empfangene Schnittstellenidentifikationsnummer zum Bilden der Netzadresse verwendet wird.