-
Gebiet der Erfindung
-
Die
vorliegende Erfindung betrifft ein System und Verfahren zum Übertragen
von Internetpaketdaten über
Paketfunknetzwerke, wie beispielsweise ein Netzwerk, welches gemäß dem allgemeinen
Paketfunkdienst (General Packet Radio Service – GPRS) arbeitet.
-
Hintergrund der Erfindung
-
Das
GPRS wurde entwickelt, um Internetpakete über eine Funkzugriffsschnittstelle
zu übertragen.
Ein GPRS-Netzwerk kann unter Verwendung eines globalen Mobilfunksystem-(GSM-) oder eines universalen
mobilen Telekommunikationssystem-(UMTS-)Backbone-Netzes gebildet
werden. GPRS stellt Unterstützung
für paketorientierte
Dienste bereit und versucht, Netzwerk- und Funkressourcen für Paketdatenübertragungen,
die beispielsweise das Internetprotokoll (IP) verwenden, zu optimieren. Das
GPRS stellt eine logische Architektur bereit, die mit der paketvermittelten
Architektur eines Mobilfunksystems zusammenhängt.
-
Die
Internet Engineering Task Force (IETF) ist eine Körperschaft,
die für
die Entwicklung von Internetprotokollen zur Vereinfachung von Übertragungen über das
Internet verantwortlich ist. Beispielsweise ist ein gut etabliertes
Internetprotokoll das Internetprotokoll Version 4 (IPV4), das für Personal-Computer
für den
Zugang zum Internet entwickelt und standardisiert wurde. Die IETF
hat auch einen weiteren Standard entwickelt, der als das Internetprotokoll Version
6 (IPV6) bekannt ist und der in Bezug auf IPV4 eine Verbesserung
im Hinblick auf eine Vereinfachung der Mobilkommunikation und vermehrte Adressierungsoptionen
für eine
Benutzerausrüstung bereitstellt.
Obwohl es Ähnlichkeiten
zwischen IPv4 und IPv6 gibt, erwartet ein Paketfunknetzwerk, das errichtet
bzw. eingerichtet wurde, um IPv4 zu unterstützen, Internetpakete gemäß dem IPv4
und nicht IPv6.
-
Das
veröffentlichte
Patentdokument
WO 01/93540 ,
6. Dezember 2001, beschreibt die Bildung von IPv6-Adressen, die
eine Komponente mit wenigstens einem Teil eines Tunnelling-Endpunkt-IDentifizierers
(TEID) als PDP-Kontextadresse eines IPv6-basierten GPRS-Netzwerks
umfassen. Daher wird die Internetprotokoll-Kompatibilität der gebildeten
Adresse durch das Internetprotokoll des PDP-Kontextaktivierungsverfahrens
bestimmt.
-
Zusammenfassung der Erfindung
-
Gemäß der vorliegenden
Erfindung werden ein Telekommunikationssystem, ein Verfahren, ein Computerprogramm
und eine Vorrichtung zum Übertragen
von Internetpaketdaten in Übereinstimmung mit
einem ersten Internetprotokoll (IPv6) über ein Paketfunknetzwerk,
welches in Übereinstimmung
mit einem zweiten Internetprotokoll (IPv4) betreibbar ist, bereitgestellt.
Das System beinhaltet eine Benutzerausrüstung, die so betreibbar ist,
daß sie
einen Träger
für die Übertragung
von Internetprotokolldaten gemäß dem zweiten
Internetprotokoll (IPv4) zu und von einem Gateway-Unterstützungsknoten
des Paketfunknetzwerks anfordert. Der Gateway-Unterstützungsknoten
ist so betreibbar, daß er
einen Tunnellingprotokollträger
für die Übertragung
der Internetpaketdaten zu und von der Benutzerausrüstung über das
Paketfunknetzwerk errichtet. Die Benutzerausrüstung ist in Kombination mit
dem Gateway-Unterstützungsknoten
so betreibbar, daß sie
eine Adresse bildet, die mit dem ersten Internetprotokoll (IPv6) kompatibel
ist, wobei die Adresse einen Schnittstellenidentifizierer beinhaltet,
der einen Tunnel(ling)endidentifizierer des Tunnellingprotokollträgers aufweist, der
an dem Gateway-Unterstützungsknoten
des Paketfunknetzwerks endet. Die Internetpaketdaten werden zu und
von einem korrespondierenden Knoten über den Gateway-Unterstützungsknoten
und den errichteten Träger
unter Verwendung einer Internetprotokolladresse, die mit dem ersten
Internetprotokoll (IPv6) kompatibel ist, übertragen.
-
Systeme
gemäß der vorliegenden
Erfindung sind so ausgestaltet, daß sie eine Adresse erzeugen, die
mit einem ersten Internetprotokoll kompatibel ist, das verwendet
werden kann, um Internetpaketdaten über ein Paketfunknetzwerk zu übertragen,
welches dafür
ausgestaltet wurde, Internetpaketdaten in Übereinstimmung mit einem zweiten
Internetprotokoll zu unterstützen.
Die Adresse wird mit einer Schnittstellenidentifiziereradreßkomponente
gebildet, die einen Tunnellingendidentifizierer beinhaltet, der
von einem zugeordneten Paketdatenträger des Paketfunknetzwerks
erfaßt
wurde. Der Tunnellingendidentifizierer identifiziert das Ende eines
durch das Paketfunknetzwerk zugeordneten Tunnellingprotokollträgers. Der
Tunnellingendidentifizierer stellt eine quasi einmalige Adresse
innerhalb des Paketfunknetzwerks bereit, die, wenn sie zu einer
Adresse ausgebildet wurde, die mit dem ersten Internetprotokoll kompatibel
ist, verwendet werden kann, um Internetpaketdaten über das
Paketfunknetzwerk zu übertragen.
-
Durch
Bilden der kompatiblen Adresse mit dem Tunnellingendidentifizierer
kann der Ga teway-Unterstützungsknoten
in einigen Ausführungsformen
so ausgestaltet werden, daß er
den Träger zum Übertragen
der Internetpaketdaten von dem korrespondierenden Knoten zu der
Benutzerausrüstung über das
Paketfunknetzwerk unter Verwendung des Tunnellingendidentifizierers
identifiziert. Das heißt, Internetpakete
werden von dem korrespondierenden Knoten zu der Benutzerausrüstung über das
Paketfunknetzwerk durch den Gateway-Unterstützungsknoten unter Verwendung
des Tunnellingendidentifizierers, um den zugeordneten Träger zu identifizieren,
geleitet bzw. geroutet. Das Tunneln über das Paketfunknetzwerk erfolgt
dadurch im wesentlichen automatisch. Ein TFT (Traffic-Flow-Template)
in dem Gateway-Unterstützungsknoten,
das üblicherweise verwendet
wird, um Internetpaketdaten unter Verwendung der Quelladresse zu
der Benutzerausrüstung
zu leiten bzw. zu routen, kann umgangen werden. Dies ist deshalb
der Fall, weil der Träger,
der errichtet wurde, um Internetpaketdaten über das Paketfunknetzwerk zu
tragen, nur Internetpakete in Übereinstimmung
mit dem zweiten Internetprotokoll erkennt. Der korrespondierende
Knoten überträgt jedoch
Internetpaketdaten in Übereinstimmung
mit dem ersten Internetprotokoll (IPv6). Daher erkennt das TFT beispielsweise
nur eine IPV4-Adresse. Durch Identifizieren des Trägers aus
dem Tunnellingendidentifizierer können die Internetpakete über den
IPv4-Träger
geleitet werden, und das TFT kann umgangen werden.
-
In
einigen Ausführungsformen
kann der Schnittstellenidentifizierer aus einer Kombination des Tunnellingendidentifizierers
des Paketfunknetzwerks und einem Firmenidentifizierer gebildet werden.
Der Firmenidentifizierer wird verwendet, um eine Adreßkomponente
des Schnittstellenidentifizierers zu bilden. Der Firmenidentifizierer
identifiziert einen Betreiber des Paketfunknetzwerks. In Kombination
mit dem Tunnellingidentifizierer kann die kompatible Adresse mit
globaler Signifikanz versehen werden. Die Adresse kann dann verwendet
werden, um die erste link-lokale Internetprotokolladresse zu konstruieren,
und kann dann von der Benutzerausrüstung verwendet werden, um
Anwendungen und Dienste innerhalb des Paketfunknetzwerks anzufordern.
Die kompatible Adresse kann auch verwendet werden, um eine global
einmalige und routbare bzw. (weiter)leitbare Adresse anzufordern,
die in Übereinstimmung
mit dem ersten Internetprotokoll gebildet ist.
-
Die
kompatible Adresse kann auch ein Feld beinhalten, welches anzeigt,
ob die Adresse für
das Paketfunknetzwerk lokal oder global ist. Wenn das Feld mit einem
Wert versehen ist, der anzeigt, daß die Adresse lokal ist, erlaubt
der Gateway-Unterstützungsknoten
nicht, daß Internetpakete
das Paketfunknetzwerk verlassen. Ein Wert in dem Feld jedoch, der
anzeigt, daß die
Adresse allein zu betrachten ist, macht die Adresse möglicherweise
nicht global einmalig. Dementsprechend kann in einigen Ausführungsformen
die kompatible Adresse auch ein Präfix beinhalten, welches in Übereinstimmung
mit dem ersten Internetprotokoll gebildet wird. Das Präfix kann
in Übereinstimmung
mit dem ersten Internetprotokoll erfaßt werden. Dies ist deshalb
der Fall, weil ein(e) UE/Host ein IPv6-Präfix erfassen kann, ohne notwendigerweise
die volle IPv6-Adresse
erfassen zu müssen.
Die kompatible Adresse, die eine IPv6-Adresse ist, wird mit der
Schnittstellen-ID, einschließlich
der Firmen-ID und dem Tunnelendidentifizierer, gebildet. Das erste
Internetprotokollpräfix kann
von einem Adreßzuordnungsserver
oder durch Empfangen der Router-Ankündigungsnachrichten bzw. Router-Advertisement-Nachrichten
in Übereinstimmung
mit der Neighbour Discovery für
IP Version 6 (RFC2461) erworben bzw. erfaßt werden.
-
In
anderen Ausführungsformen
kann die Präfixkomponente
der Adresse auf einer statischen Basis im Vorfeld zugeordnet werden.
Die Benutzerausrüstung
bildet daher die kompatible Adresse aus dem statisch zugeordneten
Präfix
und dem Schnittstellenidentifizierer, der den Tunnellingendidentifizierer
beinhaltet.
-
Durch
Kombinieren des Schnittstellenidentifizierers, der aus dem Tunnellingendidentifizierer
und dem Firmenidentifizierer gebildet wurde, mit dem Präfix, das
in Übereinstimmung
mit dem ersten Internetprotokoll gebildet wurde, wird eine global
einmalige Adresse bereitgestellt, die verwendet werden kann, um
Internetpaketdaten über
das externe Paketdatennetzwerk zu leiten. Diese Adresse kann verwendet
werden, um die Benutzerausrüstung
für Internetprotokollanwendungen
gemäß dem ersten
Internetprotokoll zu identifizieren. Die Benutzerausrüstung kann
daher auf Dienste zugreifen, die das erste Internetprotokoll verwenden.
in einigen Ausführungsfor men
ist die kompatible Adresse, die gebildet wird, eine global einmalige
Adresse. Auf die Benutzerausrüstung
kann daher über
das externe (IPv6-)Paketdatennetzwerk zugegriffen werden. In anderen
Ausführungsformen
kann auf die kompatible Adresse, die nicht global einmalig, aber
dennoch lokal einmalig ist, nur innerhalb des öffentlichen landgestützten Mobilfunknetzes
(Public Land Mobile Network – PLMN) unter
Verwendung der link-lokalen IPv6-Adresse zugegriffen werden.
-
In
einigen Ausführungsformen
kann das erste Internetprotokoll das Internetprotokoll Version 6 (IPV6)
sein und das zweite Internetprotokoll kann das Internetprotokoll
Version 4 (IPv4) sein. Die kompatible Adresse (das heißt, eine
Adresse, die mit dem ersten Internetprotokoll kompatibel ist) kann
so ausgestaltet werden, daß sie
global einmalig ist, indem der Schnittstellenidentifizierer mit
einer Präfixadreßkomponente
gemäß dem ersten
Internetprotokoll versehen wird. In einigen Ausführungsformen ist die Benutzerausrüstung mit
der Präfixkomponente
versehen, wobei die kompatible Adresse mit einem statischen Präfix gebildet
wird. In anderen Ausführungsformen
wird die Präfixkomponente
dynamisch erfaßt, indem
eine IPV6-Präfixkomponente
erfaßt
wird und die kompatible Adresse aus dem Schnittstellenidentifizierer
und der Präfixkomponente
gebildet wird.
-
Ausführungsformen
der vorliegenden Erfindung können
eine Einrichtung für
eine Benutzerausrüstung
bereitstellen, um Anwendungsprogramme auszuführen, die die Verwendung von
Internetprotokollübertragungen
gemäß einem
Internetprotokoll unter Verwendung eines Paketfunksystemnetzwerks erfordrn,
welches dafür
ausgestaltet wurde, Internetpakete in Übereinstimmung mit einem anderen
Internetprotokoll zu übertragen.
Das Paketfunknetzwerk kann beispielsweise ein allgemeines Paketfunkdienst-(GPRS-)Netzwerk
sein.
-
Verschiedene
weitere Aspekte und Merkmale der vorliegenden Erfindung sind in
den anhängenden
Ansprüchen
definiert, wobei unterstützende
Ausführungsformen
unten beschrieben werden.
-
Kurze Beschreibung der Zeichnungen
-
Ausführungsformen
der Erfindung werden nun lediglich beispielhaft unter Bezugnahme
auf die begleitenden Zeichnungen beschrieben, in denen gleiche Teile
mit korrespondierenden Bezugszeichen versehen sind und wobei:
-
1 ein
schematisches Blockdiagramm eines Telekommunikationssystems, welches
ein GPRS-Netzwerk beinhaltet, ist.
-
2 ist
ein schematisches Blockdiagramm von Teilen des GPRS-Netzwerks, die
einen Tunnellingträger
für die Übertragung
von Internetpaketen bilden.
-
3a ist
ein Diagramm, welches einen Tunnelendpunktidentifizierer für die Datenübertragung
veranschaulicht, und 3b ist ein entsprechendes Diagramm
für Daten
der Steuerungsebene.
-
4a veranschaulicht
schematisch ein Adreßformat
für eine
erste lokal einmalige GAT-ID (GAT_ID_I), und 4b veranschaulicht
schematisch ein Adreßformat
für eine
erste global einmalige GAT-ID (GAT_ID_I).
-
5 veranschaulicht
schematisch ein Adreßformat
für eine
zweite GAT-ID (GAT_ID_II).
-
6 veranschaulicht
schematisch ein Adreßformat
für eine
IPv6-Adresse, die durch eine PDP-Kontextaktivierung zugeordnet wurde.
-
7 veranschaulicht
schematisch ein allgemeines Adreßformat für automatisches GTP-Tunnelling.
-
8a veranschaulicht
schematisch ein Adreßformat
für eine
link-lokale Adresse für
automatisches GTP-Tunneln, und 8b veranschaulicht schematisch
eine korrespondierende Adresse für eine
site-lokale Adresse.
-
9 veranschaulicht
schematisch ein Adreßformat
für eine
kompatible IPv6-Adresse einschließlich eines IPv6-Präfixes und
einer zweiten GAT-ID (GAT_ID_II).
-
10 ist
ein schematisches Blockdiagramm von Teilen des GPRS-Netzwerks, die
dazu dienen, einen Funkzugriffsträgertunnel zu bilden.
-
11 ist
ein schematisches Blockdiagramm von Teilen des GPRS-Netzwerks, die
dazu dienen, einen GTP-Tunnel zu bilden.
-
12 ist
ein schematisches Blockdiagramm einer vereinfachten Version des
in 1 gezeigten Telekommunikationssystems, welches
das automatische Tunnelling veranschaulicht.
-
13 ist
ein Flußdiagramm,
welches ein Verfahren zum Bilden einer GAT-Adresse veranschaulicht.
-
14 ist
ein Flußdiagramm,
welches ein Verfahren zum Bilden einer global routbaren IPv6-GAT-Adresse
veranschaulicht.
-
15 ist
ein Flußdiagramm,
welches zwei Optionen zum Erzeugen verschiedener GAT-Adreßschnittstellenidentifizierer
veranschaulicht.
-
16 ist
ein Flußdiagramm,
welches ein Verfahren für
das Kommunizieren über
das GPRS-Netzwerk unter Verwendung der GAT-Adresse veranschaulicht.
-
17 ist
ein Beispiel eines allgemeinen Formats einer IPv6-Adresse.
-
18 ist
ein Beispiel einer IPv6-Adresse, die ein Subnetz-Präfix aus
n Bits zeigt.
-
19 ist
ein Beispiel eines Schnittstellenidentifizierers im modifizierten
EUI-64-Format.
-
20 ist
ein Beispiel einer globalen IPv6-Unicast-Adresse.
-
21 ist
ein Beispiel einer IPv6-Adresse mit einer eingebetteten IPv4-Adresse.
-
22 ist
ein zweites Beispiel einer IPv6-Adresse mit einer eingebetteten
IPv4-Adresse.
-
23 ist
ein Beispiel einer site-lokalen IPv6-Adresse.
-
24 ist
ein Beispiel einer link-lokalen IPv6-Adresse und
-
25 ist
ein Flußdiagramm,
welches einige der Verfahrensschritte veranschaulicht, die erforderlich
sind, um einen Träger
für Internetpakete über ein GPRS-Netzwerk
zu errichten.
-
Beschreibung der beispielhaften Ausführungsformen
-
Die
unten beschriebenen Ausführungsformen
liefern Mechanismen zum Unterstützen
des IPv6-Verkehrs über
ein Nur-IPv4-GPRS/UMTS-Netzwerk. Ein 3G-Betreiber kann dadurch ein
IPv6-Netzwerk unter Verwendung eines bestehenden Nur-IPv4-UMTS unterstützen, und
somit können
Risiken, die mit einer frühen
Einführung
von IPv6-IMS einhergehen, minimiert werden.
-
1. Beispiel eines GPRS-Netzwerks
-
1 stellt
ein schematisches Blockdiagramm eines Systems für die Übertragung von Internetpaketen
in Übereinstimmung
mit einem ersten (IPv6-)Internetprotokoll über ein Paketfunksystemnetzwerk 1,
das entwickelt wurde, um die Übertragung
von Internetpaketen in Übereinstimmung
mit einem zweiten (IPv4-)Internetprotokollstandard zu unterstützen, bereit.
In 1 ist eine Benutzerausrüstung (UE) 2 so ausgestaltet,
daß sie
ein Anwendungsprogramm hostet, das beispielsweise einem Benutzer
einen Multimediadienst bereitstellt. Das Anwendungsprogramm kann
beispielsweise den Zugriff auf ein Internetprotokoll-Multimedia-Subsystem (IMS),
wie z. B. das von der 3GPP entwickelte, erfordern, um Benutzern
Multimediadienste unter Verwendung eines UMTS-Backbone-Netzes bereitzustellen.
-
Für das vorliegende
Beispiel ist das Paketfunksystemnetzwerk 1 ein allgemeines
Paketfunkdienst-(GPRS-)Netzwerk. Der Einfachheit halber zeigt 1 Elemente
eines GPRS-Netzwerks, die ein GPRS-Gateway-Dienstknoten (GGSN) 3,
bedienende GPRS-Unterstützungsknoten
(SGSN) 4, Funknetzwerksteuerungen (RNC) 8 und
Knoten B-Elemente 10 sind.
-
Die
vorliegende Technik betrifft Internetprotokollübertragungen zwischen einem
korrespondierenden Knoten (CN) 12 und einer UE 2,
die an das GPRS-Netzwerk 1 angeschlossen ist. Der CN 12 ist in 1 so
gezeigt, daß er
an ein Paketdatennetzwerk (PDN) 15 angeschlossen ist, das
mit dem GPRS-Netzwerk verbunden ist. Um Internetpaketdaten zwischen
dem CN und der UE zu übertragen, wird
ein Träger über das
GPRS-Netzwerk errichtet, wie es in 2 veranschaulicht
ist.
-
In 2 ist
ein Träger 14 zwischen
dem GGSN 3 und der UE 2 errichtet, um Internetpakete 5, die
eine Kopfzeile 7, die eine Adresse und Nutzdaten 9 enthält, aufweisen,
zu und von der UE 2 und dem CN 12 zu übertragen.
Im allgemeinen sind der GGSN 4 und der SGSN 6 Teile
eines Kernnetzwerks, CN. Für
das Kernnetzwerk wird der Träger
durch einen GPRS-Tunnellingprotokoll-(GTP-)Träger gebildet. Die
Funknetzwerksteuerung RNC 8 und der Knoten B10 sind Teil
eines Funknetzwerks RN. Für
das Funknetzwerk RN wird der Träger
aus einem Funkzugriffsträger-(RAB-)Tunnellingprotokollträger gebildet.
Der Träger
ist so ausgestaltet, daß er
Internetpakete 16 zwischen der UE und dem GGSN überträgt. Die
Internetpakete haben eine Adresse 18 und Nutzdaten 20.
-
Für das vorliegende
Beispiel führt
die UE 2 ein Anwendungsprogramm aus, welches die Unterstützung beispielsweise
von IMS-Diensten erfordert. IMS wurde jedoch in Übereinstimmung mit dem IPv6-Internetprotokollstandard
entwickelt und standardisiert, wohingegen das GPRS-Netzwerk 1 entwickelt
wurde, um IPv4-Internetprotokollübertragungen zu
unterstützen.
Wie in Kürze
erläutert
wird, wird gemäß der vorliegenden
Technik ein Träger
für die
UE 2 errichtet, um IPv6-Internetpakete über das GPRS-Netzwerk zu dem
CN 12 zu befördern.
Zu diesem Zweck ist die vorliegende Technik so ausgestaltet, daß sie ein
Internetprotokoll erzeugt, das verwendet werden kann, um über den
Träger 14,
der ansonsten dafür
ausgestaltet ist, IPv4-Kommunikationen zu unterstützen, zu
kommunizieren.
-
Um
eine Ausgestaltung bereitzustellen, durch die die Benutzerausrüstung UE
Internetpakete in Übereinstimmung
mit dem IPv6-Internetprotokoll über
ein GPRS-Netzwerk, welches in Übereinstimmung
mit dem IPv4-Internetprotokoll arbeitet, senden und empfangen kann,
wird eine Adresse konstruiert, die automatisch über das GPRS-Netzwerk getunnelt werden
kann. Die Konstruktion von Adressen wird im nachfolgenden Abschnitt
erläutert.
Allgemeinere Informationen betreffend die Konstruktion von IPv6-Adressen
werden in Anhang 1 bereitgestellt.
-
2. Konstruieren der link-lokalen IPv6-Adresse
für automatisches
Tunnelling bzw. Tunneln über GPRS/UMTS
-
Die
vorliegende Technik verwendet einen Tunnelendpunktidentifizierer
eines GPRS-Tunnellingprotokollträgers, um
einen Schnittstellenidentifizierer zu definieren, aus dem eine link-lokale IPv6-Adresse
gebildet werden kann. Der Schnittstellenidentifizierer kann verwendet
werden, um eine IPv6-kompatible Adresse zu bilden, die durch das GPRS-Netzwerk
automatisch getunnelt werden kann, und wird somit als die Schnittstellen-ID
des automatischen GPRS-Tunnellings (GAT) bezeichnet. Die GAT-Schnittstellen-ID
wird unter Verwendung eines GPRS-Tunnellingprotokoll-Tunnelendpunktidentifizierers
definiert, der als (TS29.060) definiert ist. Die Form des TEID ist
in 3a für
die Datenübertragung
und in 3b für Daten der Steuerungsebene
gezeigt.
-
Konstruieren einer Schnittstellen-ID unter
Verwendung des TEID-GAT-ID I
-
Ein
erstes Beispiel eines Schnittstellenidentifizierers, der verwendet
werden kann, um eine Adresse zu bilden, die mit IPv6 in Übereinstimmung
mit der IPv6-Adressierungsarchitektur (RFC2373, Anhang A) kompatibel
ist, verwendet der TEID in Kombination mit einem Firmenidentifizierer.
Der Schnittstellenidentifizierer hat 64 Bits und verwendet ein modifiziertes
IEEE-EUI-64-Format.
Der TEID wird verwendet, um den RFC2373-konformen Schnittstellenidentifizierer
zu konstruieren. Die Adresse wird konstruiert, wie es in den 4a und 4b gezeigt
ist, wo "c" der Firmen-ID zugeordnet
ist und "g" ein Feld ist, das die
Einzel-/Gruppensignifikanz bereitstellt. Es gibt zwei Formen von
GAT_ID_I-Adressen; eine ist eine lokal einmalige IEEE-EUI-64-Adresse,
wie in 4a gezeigt, und die andere ist
eine global einmalige IEEE-EUI-64-Adresse, wie in 4b gezeigt.
-
Die Definition des GAT-Identifizierers-GAT-ID
II
-
Ein
zweites Beispiel eines Schnittstellenidentifizierers, der verwendet
werden kann, um eine IPv6-kompatible Adresse zu konstruieren, verwendet die
IPv4-Adresse, die als Teil einer PDP-Kontextaktivierungsanforderung
zugeordnet wurde. Zuordnungen eines Trägers und einer IPv4-Adresse
durch den GGSN werden in Anhang 2 ausführlicher beschrieben. Auf der
Steuerungsebene spezifiziert GTP ein Tunnelsteuerungs- und -verwaltungsprotokoll (GTP-C),
welches es dem SGSN erlaubt, Paketdatennetzwerkzugriff für eine UE
bereitzustellen. Die Signalisierung der Steuerungsebene wird verwendet, um
Tunnel zu erzeugen, zu modifizieren und zu löschen. Auf der Benutzerebene
verwendet GTP einen Tunnellingmechanismus (GTP-U), um einen Dienst für das Tragen
von Benutzerdatenpaketen bereitzustellen.
-
Die
Schnittstellen-ID des automatischen GPRS-Tunnellings (GAT) ist als
der GTP-Tunnelendpunktidentifizierer definiert, der definiert ist
als (TS29.060), in Kombination mit dem Indikator des GAT-Identifizierers
(0xFF, 11111111), gefolgt von einer 32-Bit-iPv4-Adresse der UEs.
Da die GAT-ID durch den GGSN zugeordnet wird, der die Sitzungen mit
den UEs verwaltet, hat sie nur lokalen Umfang.
-
Der
TEID wird als Komponente der GAT-Schnittstellen-ID (GAT-ID) beim
Konstruieren der link-lokalen IPv6-Adresse verwendet, wie in 5 veranschaulicht.
In 5 ist das erste Oktett bzw. Achtbitzeichen der
GAT-ID der GTP-Typ. Für GTP
für Daten
(GTP_U) ist der GTP-Typ
16 (00010000). Für
GTP für
Steuerinformationen (GTP_U) ist der GTP-Typ 17 (00010001). Ein Extra-Bit
T ist in diesem GTP-Typ-Oktett als das Bit definiert, "um anzuzeigen, ob
die IPv4-Adresse
privat oder öffentlich
ist". Bit "T" wird auf 1 gesetzt, wenn IPv4 öffentlich
und global einmalig ist. Ansonsten wird es auf Null gesetzt.
-
Übertragen von TEIDs zu UEs
-
Also
muß, um
die GAT_ID zu konstruieren, die UE über den TEID des GTP-Trägers, der
durch den GGSN errichtet wird, informiert werden. In der "konventionellen" PDP-Kontextaktivierung
wird der TEID für
den lokalen Gebrauch innerhalb des RNC, SGSN und GGSN verwendet.
Aufgrund der Notwendigkeit auf Seiten der UE, die Schnittstellen-ID
unter Verwendung des TEID zu konstruieren, muß der TEID an die UEs weitergegeben
bzw. geleitet werden. In einem ersten Beispiel wird der TEID direkt
an die UE weitergegeben. In diesem Fall kann der SGSN auswählen, ob
er eines der oder alle drei Paare von TEID (6 insgesamt) unter Verwendung
des Protokolikonfigurationsoption-(PCO-)Feldes in der PDP-Kontextaktivierungsakzeptanz
an die UE weitergibt.
-
In
einem zweiten Beispiel verwendet der GGSN einen seiner TEID, um
eine IPv6-Adresse in Übereinstimmung
mit seinen Adressierungsverfahren bzw. -grundsätzen zu konstruieren, und gibt
sie dann an den SGSN in dem PCO-Feld der PDP-Kontext-Erzeuge-Antwort-Nachricht
weiter. Der SGSN wiederum gibt diese durch den GGSN konstruierte IPv6-Adresse
unter Verwendung des PCO-Feldes der PDP-Kontextaktivierungsakzeptanz-Nachricht
an die UE weiter.
-
Die Bildung einer GAT-Adresse
-
Beispiele
von GAT-Adressen, die gemäß der vorliegenden
Technik gebildet werden können,
beinhalten das Bilden der GAT-Adresse aus einer Kombination einer
zugewiesenen IPv4-Adresse
und dem TEID und das Bilden der Adresse unter Verwendung einer modifizierten
EUI-64-Adresse mit
einem GTP-TEID. Diese Beispiele werden wie folgt ausführlicher
beschrieben:
-
Verwendung von eingebetteten IPv4-Adressen
-
Nach
der erfolgreichen PDP-Kontextaktivierung wird der UE eine IPv4-Adresse
zugeordnet. So kann diese IP-Adresse dazu verwendet werden, eine IPv6-Adresse
in irgendeinem der in 6 gezeigten Formate zu konstruieren.
Die in 6 gezeigten Formate werden auch als die IPv6-Adressen
bezeichnet, die mit einer binären
0 beginnen. Diese Formate sollen in dem Fall durch die UE verwendet
werden, wenn das PDN auf IPv4 basiert und dort ein IPv6-über-IPv4-Tunnelling über das
PDN benötigt, ehe
es eine IPv6-Domain erreicht.
-
Verwendung eines modifizierten EUI-64-Ansatzes mit
GTP-TEID, um Unicast-Adressen
(GAT-I) zu erzeugen
-
Ein
weiteres Beispiel einer Adresse ist eine modifizierte EUI-64-Adresse,
die eine link-lokale IPv6-Unicast-Adresse
ist, die durch Hinzufügen
eines Adreßpräfixes plus
der GAT-Schnittstellen-ID konstruiert
wurde. Eine allgemeine Form einer gemäß dieser beispielhaften Technik
gebildeten Adresse ist in 7 gezeigt.
Für dieses
Beispiel benötigt das
(Netzwerk-)Präfix
den Rest der 8 Bytes. Für GAT_ID_I
benötigt
das Präfix
8 Bytes. In GAT_ID_II benötigt
das Netzwerkpräfix
6 Bytes, weil die GAT_ID_II 10 Bytes verwendet. Es gibt zwei mögliche Formate
des in 7 gezeigten allgemeinen Adreßformats, die in den 8a und 8c gezeigt sind.
- • Fall I:
Eine globale Unicast-Adresse wird mit einem Präfix, das ein globales Routingpräfix ist, plus
der Subnetz-ID versehen, d. h. die n + m Bits sind 8 Oktette. Die
Erfassung dieser Adresse wird in einem späteren Abschnitt erläutert.
- • Fall
II: Eine site/link-lokale Unicast-Adresse wird mit einem Format,
wie in 8a gezeigt, für link-lokale
Adressen und, wie in 8b gezeigt, für eine site-lokale
Adresse versehen. Gemäß RFC2373
darf ein IPv6-Paket mit site-lokalen oder link-lokalen Quell- oder
Zieladressen nicht durch Router außerhalb der Site weitergeleitet werden.
Die Adressen sollen für
Zwecke wie beispielsweise automatische Adreßkonfiguration, Nachbarsuche
oder für
den Fall, daß keine
Router vorhanden sind, verwendet werden.
-
Im
Falle von GPRS/UMTS können
die beiden lokalen Adressen der 8a und 8b für Kommunikationen
bzw. Übertragungen
innerhalb des öffentlichen
landgestützten
Mobilfunknetzes (PLMN) zwischen UEs verwendet werden, d. h. die
UE-Peers befinden sich in demselben PLMN und es werden keine Pakete über die
Gi-Schnittstelle zum PDN aus 1 nach außen geroutet.
-
Verwendung von GAT_ID_II, um eine global
einmalige IPv6-Adresse zu konstruieren
-
Eine
allgemeine Form einer IPv6-Adresse, die unter Verwendung der GAT_ID_II
plus ein IPv6-Präfix
erzeugt wird, ist in 9 gezeigt. Der Vorteil der Verwendung
von GAT_ID_II besteht darin, daß automatisches
IPv6-über-IPv4-Tunnelling
ermöglicht
wird, wo IPv6 nicht verfügbar
ist, wie in dem Fall, wenn die Pakete über die Gi-Schnittstelle zu
einem IPv4-Paketdatennetzwerk gehen. Dies ist deshalb der Fall,
weil die GAT_ID_II das automatische IPv6-über-IPv4-Tunnelling ermöglicht, da in der IPv6-Adresse
eine IPv4-Adresse eingebaut ist.
-
3. Die GAT-Tunnelling-Verfahren
-
Abschließen der IPv6-Adreßerfassung
-
In
Abhängigkeit
von der Wahl der erzeugten IPv6-kompatiblen Adresse muß die UE
möglicherweise
noch weitere Maßnahmen
ergreifen, um die Konstruktion einer globalen Unicast-Adresse abzuschließen, falls
dies notwendig ist. Beispielsweise ist die Adresse möglicherweise
global einmalig, jedoch nicht global routbar. Für diese Fälle kann die UE die Adressen
verwenden, die entweder ein Präfix
erfordern, damit sie global routbar sind, oder die nicht routbar
sind, wie beispielsweise diejenigen, die die lokalen Site/Link-Adressen
verwenden, wie oben beschrieben.
-
Um
eine global routbare IPv6-Adresse zu erzeugen, nachdem die Erzeuge-PDP-Kontext-Anforderung empfangen
wurde, kann der GGSN einen der folgenden Abläufe durchführen:
- • Zuordnen
eines Präfixes
(entweder lokal oder von einem IPv6-DHCP angefordert) und dann Weitergeben
desselben an den GGSN und dann vom SGSN zur UE unter Verwendung
des PCO-Feldes in den PDP-Kontextnachrichten.
- • Konstruieren
der site/link-lokalen Adressen, wie in 8a und 8b gezeigt,
für die
UE und Verwendung derselben, um ein Präfix von einem IPv6-DHCP anzufordern.
Dann kann der GGSN entweder das Präfix plus die GAT_ID_I oder
die gesamte global einmalige IPv6-Adresse senden, wie in den 4a und 4b gezeigt.
- • Alternativ
kann den UEs ein Präfix
statisch zugeordnet sein; in diesem Fall kennt die UE immer ihr Präfix.
- • Alternativ
kann die UE die link-lokale Adresse verwenden, um sich die Router-Ankündigungsnachricht
anzuhören,
die das Präfix
enthält (RFC2461,
Nachbarsuche für
IP Version 6).
-
Automatisches GPRS-Tunnelling von IPv6-Operationen
(GAT)
-
Der
GAT-Tunnel besteht aus zwei Abschnitten, dem RAB-Tunnel (RAB_T)
und dem GTP-Tunnel (GTP_T).
Der RAB_T wird durch das in 10 gezeigte
Diagramm veranschaulicht. Der RAB_T liegt zwischen der UE und der
RNC und ist durch eine RLC-Schicht getunnelt, wobei die Tunnelendpunkte der
RLC-Einheiten bzw. -Instanzen innerhalb der UE bzw. der RNC liegen.
Tatsächlich
ist die RLC die Link-Schicht des IPv6-Pakets. In diesem Fall ist
das IPv6-Paket, das unter Verwendung der GAT-Adresse als seine IPv6-Adresse
konstruiert wurde, die SDU der RLC.
-
Der
GTP_T ist in 11 veranschaulicht. Das GTP
erlaubt ein Tunneln von Multiprotokoll-Paketen durch das UMTS/GPRS-Backbone-Netz
zwischen GSNs und zwischen SGSN und UTRAN. Das GTP-U-Protokoll wird
durch SGSNs und GGSNs in dem UMTS/GPRS-Backbone und durch Funknetzwerksteuerungen
(RNCs) in dem UTRAN implementiert. SGSNs und GGSNs in dem UMTS/GPRS-Backbone
implementieren das GTP-C-Protokoll. Es müssen keine weiteren Systeme
von dem GTP wissen. UMTS/GPRS-UEs sind an einen SGSN angeschlossen,
ohne von GTP zu wissen. 11 veranschaulicht
die Verwendung von GTP_U für
das automatische Tunneln von IPv6-Paketen, die entweder Benutzungsdaten
oder Steuer-/Signalisierungsinformationen tragen. Alternativ wird
GTP_T unter Verwendung von automatischem Tunnelling von GTP_C für IPv6-Pakete
verwendet, die Netzwerksteuerungs-/-signalisierungsdaten tragen,
und GTP_T unter Verwendung von GTP_U wird für IPv6-Pakete verwendet, die
Benutzerdaten tragen.
-
4. Zusammenfassung des Betriebs
-
12 stellt
Veranschaulichungen von Systemen bereit, die gemäß der vorliegenden Technik
arbeiten. Wie in 12 dargestellt, liefert die
vorliegende Technik eine Ausgestaltung, durch die der GPRS/UMTS-Träger als
die Link-Schicht von IPv6 IPv6-Pakete unter Verwendung von GPRS/UMTS-Frames
tragen kann. Zu diesem Zweck fordert die UE einen IPv4-PDP-Kontext
an, wie in Anhang 2 beschrieben. Die UE kann entweder eine statische
IPv4-Adresse verwenden oder ihr kann als Ergebnis einer erfolgreichen
PDP-Kontextaktivierung eine dynamische IPv4-Adresse zugeordnet werden.
-
Dann
konstruiert die UE die GAT-Adresse gemäß der in Abschnitt 4 beschriebenen
Definition und ordnet sie wenigstens einer (und nur einer) Schnittstelle
der UEs zu. Diese Schnittstelle mit der GAT-Adresse wird verwendet,
um Internetpakete zu senden.
-
Falls
die UEs mehr als eine GAT-Adresse unter Verwendung verschiedener
GAT-Schnittstellen-IDs
konstruieren, kann die UE GAT-Adressen mehreren Schnittstellen zuordnen
bzw. zuweisen, wobei jeweils eine nur einer Schnittstelle zugeordnet wird.
Eine GAT-Adresse wird nur einmal einer Schnittstelle zugeordnet,
jedoch können
einer Schnittstelle mehr als eine verschiedene GAT-Adressen zugeordnet
werden.
-
Bei
Aktivierung einer IPv6-Anwendung (auf Basis von TCP oder UDP) wird
eine GAT-Adresse verwendet,
und die korrespondierende(n) Schnittstelle(n) wird bzw. werden ausgewählt, um
die IPv6-Pakete über
die Schnittstelle(n) zu senden und zu empfangen.
-
Der
Betrieb des oben beschriebenen Systems, das so ausgestaltet ist,
daß es
einer Benutzerausrüstung
eine IPv6-kompatible Adresse bereitstellt, wird unter Bezugnahme
auf die Flußdiagramme
in den 13, 14 und 15 zusammengefaßt. 13 liefert
eine Zusammenfassung eines allgemeinen Verfahrens, das mit einer
kompatiblen Adresse ausgeführt
wird, die einen Schnittstellenidentifizierer beinhaltet, der von
dem GPRS-Netzwerk erkannt werden kann, wohingegen 14 ein
Verfahren veranschaulicht, durch das die Adresse global routbar
gemacht wird, indem ein Präfix
gemäß dem IPv6-Standard
bereitgestellt wird. Das Verfahren zum Bilden der GAT-Schnittstellen-ID,
wie in 13 veranschaulicht, wird wie
folgt zusammengefaßt:
-
S1:
Die Benutzerausrüstung
fordert einen Träger
für die Übertragung
von Internetpaketdaten über
das Paketfunknetzwerk (GPRS-Netzwerk) an, indem sie eine Paketdatenprotokoll-(PDP-)Kontextanforderung
an den GGSN sendet. Als Teil der PDP-Kontextaktivierung aktiviert
der GGSN einen Träger über das
GPRS-Netzwerk, der natürlich
ein Träger
gemäß dem IPv4-Standard sein wird.
-
S2:
Der GGSN empfängt
die PDP-Kontextaktivierungsanforderung und errichtet einen Träger für die Übertragung
von Internetpaketdaten zwischen der UE und dem GGSN. Der Träger beinhaltet einen
Tunnellingprotokollträger
in Übereinstimmung mit
dem GPRS-Tunnellingprotokoll (GTP) für das Tunnelling von Internetpaketen über Kernnetzwerkkomponenten
des GPRS-Netzwerks. Der Träger
beinhaltet auch einen Funkzugriffsträger (RAB) für das Tunnelling von Internetpaketdaten über das
Funkzugriffsnetzwerk von der RNC über die Knoten B-Elemente zu
der UE.
-
S4:
Entweder in dem GGSN oder in der UE wird eine Adresse gebildet,
die eine Schnittstellen-ID-Komponente und eine Präfixadreßkomponente
beinhaltet.
-
S8:
Die Schnittstellen-ID wird daher aus dem Tunnellingendidentifizierer
gebildet, der das Ende des GTP-Trägers identifiziert. Die gebildete
Adresse hat daher innerhalb des GPRS-Netzwerks eine lokale Signifikanz.
-
Optional
muß die
Adresse, um die Adresse global signifikant und über einen IPv6-Router routbar zu
machen, ein IPv6-Präfix
erfassen bzw. erwerben. Dieses Verfahren ist in 14 veranschaulicht. 14 wird
wie folgt zusammengefaßt:
-
S10:
Die UE erhält
eine IPv6-Adreßpräfixkomponente.
Beispielsweise kann die IPv6-Präfixadresse
der UE statisch zugeordnet sein. Alternativ kann die link-lokale
Adresse mit der Schnittstellen-ID einschließlich des Tunnellingendidentifizierers
gebildet werden, um eine IPv6-Adresse
von einem DHCP-Server anzufordern.
-
S12:
Sobald die UE die IPv6-Adresse von dem DHCP-Server angefordert hat,
kann die UE das Präfix
aus der erfaßten
IPv6-Adresse ersetzen, wodurch die kompatible Adresse mit ei nem
IPv6-Präfix versehen
wird. Die EU bildet daher eine IPv6-kompatible Adresse aus der Schnittstellen-ID
und der IPv6-Präfixadresse.
-
S14:
Die UE kann dann unter Verwendung der IPv6-kompatiblen Adresse Internetpaketdaten zwischen
der UE und dem CN übertragen.
-
Die Übertragung
der Internetpaketdaten zwischen der UE und dem CN wird durch das
Flußdiagramm
in 16 zusammengefaßt, welches in Kürze ausführlicher
erläutert
wird.
-
Wie
unter Bezugnahme auf Schritt S4 in 10 erläutert wurde,
kann die vorliegende Technik verschiedene Optionen verwenden, um
eine kompatible Adresse mit dem Tunnellingendidentifizierer zu errichten.
Die Adresse kann innerhalb des GGSN, der an die UE übertragen
wurde, gebildet werden, oder die Adresse kann in der UE aus Adreßdaten gebildet
werden, die von dem GGSN übertragen
wurden. Zwei Optionen für
den Fall, wenn die Adresse innerhalb der UE gebildet wird, werden
durch das in 15 gezeigte Flußdiagramm
zusammengefaßt. 15 wird
wie folgt zusammengefaßt:
-
S14:
Der GGSN versieht die UE mit Adreßdaten, beispielsweise als
Teil der PDP-Kontextzuordnung,
innerhalb des PCO-Feldes der PDP-Kontextakzeptanz. Die Adreßdaten werden
verwendet, um die Schnittstellen-ID der kompatiblen Adresse zu bilden.
-
S16:
In dem ersten Beispiel stellt der GGSN eine IPv4-Adresse bereit,
die durch den GGSN der UE mit dem TEID zugeordnet wird.
-
S18:
Die UE bildet die Schnittstellen-ID mit dem TEID und der IPv4-Adresse.
Die gebildete Adresse ist daher global einmalig, obwohl, um sie über ein
IPv6-Netzwerk global routbar zu machen, dann die IPv6-Präfixadresse
erforderlich ist, wie unter Bezugnahme auf 9 veranschaulicht.
-
S20:
Alternativ stellt der GGSN einen Firmenidentifizierer mit dem TEID
als Teil der Adreßdaten, die
als Teil der PDP-Kontextaktivierung übertragen wurden, bereit. Die
UE bildet dann die Schnittstellen-ID aus dem TEID und dem Firmenidentifizierer.
-
S22:
Als Teil der kompatiblen Adresse beinhaltet die Adresse ein globales/lokales
Benutzer-Signifikanzfeld. Wenn die Adresse nur lokal innerhalb des
GPRS-Netzwerks verwendet werden soll, wird das Signifikanzfeld auf
Null gesetzt. Ansonsten wird, wenn das Signifikanzfeld global, d.
h. außerhalb
des GPRS-Netzwerks, verwendet werden soll, das Signifikanzfeld auf
Eins gesetzt.
-
16 liefert
eine Veranschaulichung eines Verfahrens zum Übertragen von Internetpaketdaten unter
Verwendung der kompatiblen Adresse über das GPRS-Netzwerk. 16 wird
wie folgt zusammengefaßt:
-
S30:
Die UE überträgt Internetpakete
an den CN unter Verwendung der kompatiblen Adresse über den
Funkzugriffsträgertunnel
und den GTP-Tunnel, was ansonsten nicht von der Form der Adresse
in der Internetpaketkopfzeile abhängig ist.
-
S32:
Für Downlink-Übertragungen
empfängt der
GGSN Internetpaketdaten von dem korrespondierenden Knoten CN. Die
Internetpakete sind IPv6-Internetpakete. Da das GPRS- Netzwerk jedoch so
ausgestaltet wurde, daß es
IPv4-Internetübertragungen
unterstützt,
hat der GGSN einen IPv4-Träger errichtet.
Im Ergebnis erkennt ein TFT (Traffic-Flow-Template), das verwendet
wird, um Internetkommunikationen bzw. -übertragungen zu regulieren,
nur eine IPv4-Adresse
als die Quelladresse des korrespondierenden Knotens. Das heißt, der
Träger wurde
in Bezug auf eine IPv4-Quelladresse errichtet. Der GGSN als solcher
ist modifiziert mit dem Effekt, daß der TFT-Ablauf umgangen wird,
und der GGSN identifiziert den geeigneten Träger aus dem Tunnellingendidentifizierer
TEID.
-
S36:
Der GGSN identifiziert den Träger,
welcher der GTP-Träger
ist, aus dem TEID in der Schnittstellen-ID der kompatiblen Adresse
der UE, die die Zieladresse des Internetpakets ist. Somit wird das
Tunnelling im wesentlichen automatisch gemacht.
-
S38:
Der GGSN überträgt die Internetpakete über den
GTP-Träger
und den RAB-Träger, identifiziert
durch den TEID, an die UE.
-
Verschiedene
weitere Aspekte und Merkmale der vorliegenden Erfindung sind in
den anhängenden
Ansprüchen
definiert. Verschiedene Modifikationen können an den hier beschriebenen
Ausführungsformen
vorgenommen werden, ohne vom Schutzumfang der vorliegenden Erfindung
abzuweichen. Beispielsweise kann, obwohl die obigen Ausführungsformen
für ein
erstes Internetprotokoll als IPv6 und das zweite Internetprotokoll
(Übertragung über das
Paketfunksystemnetzwerk) als IPv4 beschrieben wurden, in anderen
Ausführungsformen
das erste Protokoll IPv4 sein, und das zweite Protokoll (für die Übertragung über das
Paketfunksystemnetzwerk) kann IPv6 sein. Des weiteren können auch
andere Internetprotokolle für
das erste und das zweite Internetprotokoll verwendet werden.
-
5. Anhang 1: IPv6-Adressierungsschemata
-
Diese
Adressierungsschemata sind in RFC 3513 "Internet Protocol Version 6 (IPv6) Addressing Architecture" ausführlicher
zusammengefaßt.
-
IPv6-Unicast-Adressen
sind kompatibel mit Präfixen
beliebiger Bitlänge, ähnlich wie
IPv4-Adressen unter
klassenlosem Routing. Es gibt verschiedene Typen von Unicast-Adressen
in IPv6, insbesondere globales Unicast, site-lokales Unicast und
link-lokales Unicast. Es gibt auch einige Spezial-Subtypen von globalem
Unicast, wie z. B. IPv6-Adressen mit eingebetteten IPv4-Adreßtypen oder
codierte NSAP-Adressen. Zusätzliche
Adreßtypen
oder Subtypen können
in der Zukunft definiert werden.
-
IPv6-Knoten
können
in Abhängigkeit
von der Rolle, die der Knoten spielt (beispielsweise Host im Vergleich
zu Router), beträchtliche
oder wenig Kenntnis von der inneren Struktur der IPv6-Adresse haben.
Zumindest kann ein Knoten berücksichtigen, daß Unicast-Adressen
(einschließlich
seiner eigenen) keine innere Struktur haben. Ein Beispiel hierfür ist in 17 gezeigt.
Ein etwas weiter entwickelter bzw. fortgeschrittenerer (jedoch noch
immer recht einfacher) Host kann zusätzlich Kenntnis von Subnetz-Präfix(en)
für den
Link (die Links), an den bzw. die er angeschlossen ist, haben, wobei
unterschiedliche Adressen unterschiedliche Werte für das (die) Subnetz-Präfix(e),
das bzw. die ersten n Bits besetzt (besetzen), haben können, wie
in 18 gezeigt. Die in 10 gezeigte
Adresse kann verwendet werden, um die IPv6-Adresse, genannt GAT-Adresse,
für automatisches
Tunnelling zu konstruieren. Die Schnittstellenidentifizierer in
IPv6-Unicast-Adressen werden verwendet, um Schnittstellen auf einem
Link zu identifizieren. Sie müssen
innerhalb eines Subnetz-Präfixes
einmalig sein.
-
Konstruktion einer Schnittstellen-ID einer IPv6-Adresse
-
Für alle Unicast-Adressen
mit Ausnahme derjenigen, die mit dem Binärwert 000 beginnen (die Adressen,
die eingebettete IPv4-Adressen verwenden), müssen Schnittstellen-IDs 64
Bits lang sein und im modifizierten EUI-64-Format (IEEE, "Guidelines for 64-bit
Global Identifier (EUI-64)
Registration Authority" http://standards.ieee.org/regauth/oui/tutorial/EUI64.html,
März 1997)
konstruiert sein.
-
Schnittstellenidentifizierer
auf Basis des modifizierten EUI-64-Formats können globalen Umfang haben,
wenn sie von einem globalen Schlüssel
bzw. Token (z. B. IEEE 802 48-Bit MAC oder IEEE EUI-64-Identifizierer)
abgeleitet sind, oder sie können
lokalen Umfang haben, wo ein globales Token nicht verfügbar ist
(z. B. serielle Links bzw. Verknüpfungen,
Tunnelendpunkte usw.) oder wo globale Tokens nicht wünschenswert
sind (z. B. temporäre
private Tokens).
-
Schnittstellenidentifizierer
im modifizierten EUI-64-Format werden gebildet durch Invertieren des "u"-Bits (universales/lokales Bit in der
IEEE EUI-64-Terminologie), wenn der Schnittstellenidentifizierer
aus IEEE EUI-64-Identifizierern gebildet wird. In dem resultierenden
modifizierten EUI-64-Format wird das "u"-Bit
auf "1" gesetzt, um den
globalen Umfang anzuzeigen, und es wird auf "0" gesetzt,
um lokalen Umfang anzuzeigen. Die ersten drei binären Oktette
eines IEEE EUI- 64-Identifizierers
sind in 19 gezeigt. Wie in 19 gezeigt
ist, hat die Adresse Felder, die in Internet-Standard-Bitreihenfolge
geschrieben sind, wobei "u" das universale/lokale Bit
ist, "g" das Einzel/Gruppen-Bit
ist und "c" die Bits der Firmen-ID
sind. Beispiele werden in RFC3513 bereitgestellt.
-
Wenn
kein spezifischer eingebauter Schnittstellenidentifizierer, wie
die seriellen Links oder die konfigurierten Tunnel (sie werden als
Links ohne Identifizierer bezeichnet), verfügbar ist, müssen Schnittstellenidentifizierer
ausgewählt
werden, die innerhalb eines Subnetz-Präfixes einmalig sind.
-
Wenn
auf einem Link kein eingebauter Identifizierer verfügbar ist,
besteht der bevorzugte Ansatz darin, einen globalen Schnittstellenidentifizierer
von einer anderen Schnittstelle oder einen, der dem Knoten selbst
zugeordnet ist, zu verwenden.
-
Wenn
kein globaler Schnittstellenidentifizierer zur Verwendung auf dem
Link verfügbar
ist, ist es erforderlich, einen Schnittstellenidentifizierer mit
lokalem Umfang zu erzeugen.
-
Globale IPv6-Unicast-Adressen
-
Ein
Beispiel einer globalen IPv6-Unicast-Adresse ist in 20 gezeigt.
-
IPv6-Adressen mit eingebetteten IPv4-Adressen
-
Um
den Wechsel bzw. Übergang
von IPv4 zu IPv6 zu vereinfachen, gibt es eine Technik für Hosts und
Router, um IPv6-Pakete über
IPv4-Infrastruktur dynamisch zu tunneln. IPv6-Knoten, die diese Technik verwenden,
werden spezielle IPv6-Unicast-Adressen mit einer eingebetteten globalen IPv4-Adresse
in den 32 Bits niedrigerer Ordnung zugeordnet. Ein Beispiel ist
in 21 gezeigt, welches als eine "IPv4-kompatible IPv6-Adresse" beschrieben werden
kann.
-
Ein
weiterer Typ von IPv4-Adresse wird als "IPv4-abgebildete IPv6-Adresse" bezeichnet, die
ein Adreßformat
hat, wie es in 22 veranschaulicht ist. Sie
kann verwendet werden, um die IPv4-Knoten unter Verwendung von IPv6-Adressen
zu repräsentieren.
-
Lokal verwendete IPv6-Unicast-Adressen
-
Zwei
Typen von Adressen mit lokaler Benutzung sind in den 23 und 24 veranschaulicht. Diese
sind eine site-lokale Adresse und eine link-lokale Adresse. Site-lokale
Adressen sind für
eine Adressierung innerhalb einer Site ohne die Notwendigkeit eines
globalen Präfixes
ausgestaltet. Das Format der site-lokalen Adresse ist in 23 gezeigt.
-
Die
link-lokale Adresse ist für
eine Adressierung auf einem einzigen Link für die automatische Adreßkonfiguration,
für die
Nachbarsuche oder für den
Fall, daß keine
Router vorhanden sind, ausgestaltet. Das Format der site-lokalen
Adresse ist in 24 gezeigt. Es gibt andere Typen
von Adressen, wie Anycast-Adressen, Multicast-Adressen, Loopback-Adressen
usw.
-
6. Anhang 2: IPv4-UMTS-Trägerinitilerung
unter Verwendung von PDP-Kontextaktivierung
-
Der
IP-Verkehr (IPv6 oder IPv4) wird über das UMTS-Netzwerk (zwischen
UE und GGSN) über UMTS-Träger transportiert.
Ein UMTS-Träger
wird als die Errichtung von POP-(Paketdatenprotokoll-)Kontext beschrieben.
Eine Benutzerausrüstung UE
sendet IPv4- oder IPv6-Pakete über das UMTS-Netzwerk,
indem ein IPv4-PDP-Kontext oder ein IPv6-PDP-Kontext errichtet wird.
IPv6-PDP-Kontexte werden nur in einem IPv6-fähigen UMTS-Netzwerk unterstützt, insbesondere
SGSN und GGSN sowie UE, die die IP6-bezogenen Funktionen (Routing, Sicherheit)
in seinem Netzwerkprotokollstapel unterstützen können.
-
Ein
Nur-IPv4-UMTS-Netzwerk unterstützt nur
IPv4-PDP-Kontext, obwohl es keinen expliziten Unterschied zwischen
den Errichtungsverfahren für IPv4-PDP-Kontext
und IPv6-PDP-Kontext
gibt. Die Adreßverwaltung
und die Sicherheit innerhalb einer PDP-Kontextaktivierung werden
in der nachfolgenden Zusammenfassung unter Bezugnahme auf ein Flußdiagramm
in 25 beleuchtet. Das Flußdiagramm von 25 repräsentiert
gleichermaßen
IPv4 für
IPv4-PDP-Kontext
und IPv6 für
IPv6-PDP-Kontext für
ein IPv6-fähiges
UMTS.
-
S90:
Die Benutzerausrüstung
UE sendet eine Aktiviere-PDP-Kontext-Anforderung (NSAPI, TI, PDP-Typ,
PDP-Adresse, Name des Zugriffspunkts, angeforderte QoS, PDP-Konfigurationsoptionen)-Nachricht
an den SGSN. Die Benutzerausrüstung
UE verwendet eine PDP-Adresse, um anzuzeigen, ob sie die Benutzung
einer statischen PDP-Adresse benötigt
oder ob sie die Benutzung einer dynamischen PDP-Adresse benötigt. Die
Benutzerausrüstung
UE läßt die PDP-Adresse
leer, um eine dynamische PDP-Adresse anzufordern.
-
S92:
Der SGSN validiert die Aktiviere-PDP-Kontext-Anforderung unter Verwendung
von PDP-Typ (optional), PDP-Adresse (optional) und Name des Zugriffspunkts
(optional), die durch die Benutzerausrüstung UE und die PDP-Kontext-Subscriptions-Einträge bereitgestellt
werden.
-
Wenn
keine GGSN-Adresse abgeleitet werden kann oder wenn der SGSN bestimmt
hat, daß die Aktiviere-PDP-Kontext-Anforderung
gemäß den Regeln
nicht gültig
ist, weist der SGSN die PDP-Kontextaktivierungsanforderung zurück.
-
Wenn
eine GGSN-Adresse abgeleitet werden kann, erzeugt der SGSN einen
TEID für
den angeforderten PDP-Kontext. Wenn die Benutzerausrüstung UE
eine dynamische Adresse anfordert, läßt der SGSN einen GGSN die
dynamische Adresse zuordnen. Der SGSN kann die Attribute der angeforderten
QoS in Anbetracht seiner Kapazitäten
und der gegenwärtigen
Belastung beschränken,
und er beschränkt
die angeforderten QoS-Attribute in Übereinstimmung mit dem abonnierten
QoS-Profil.
-
Der
SGSN sendet eine Erzeuge-PDP-Kontext-Anforderung (PDP-Typ, PDP-Adresse,
Name des Zugriffspunkts, ausgehandelte QoS, TEID, NSAPI, MSISDN,
Auswahlmodus, Ladecharakteristika, Trace-Referenz, Trace-Typ, Trigger-ID,
OMC-Identität,
PDP-Konfigurationsoptio nen)-Nachricht an den betreffenden GGSN.
Die PDP-Adresse soll leer sein, wenn eine dynamische Adresse angefordert
wird.
-
S94:
Der GGSN erzeugt einen neuen Eintrag in seiner PDP-Kontexttabelle
und erzeugt eine Charging-ID. Der neue Eintrag erlaubt es dem GGSN, PDP-PDUs
zwischen dem SGSN und dem externen PDP-Netzwerk zu routen und den
Ladevorgang zu starten. Die Art und Weise, wie der GGSN Ladecharakteristika
handhabt, die er möglicherweise
von dem SGSN empfangen hat, ist in 3G TS 32.015 [4] definiert. Der
GGSN gibt dann eine Erzeuge-PDP-Kontext-Antwort (TEID, PDP-Adresse,
PDP-Konfigurationsoptionen, ausgehandelte QoS, Charging-ID und Grund)-Nachricht
an den SGSN zurück.
Eine PDP-Adresse ist enthalten, wenn der GGSN eine PDP-Adresse zugeordnet
hat. Wenn der GGSN von dem Betreiber so konfiguriert wurde, daß er die
externe PDN-Adreßzuordnung
für den
angeforderten APN verwendet, soll die PDP-Adresse auf 0.0.0.0 gesetzt werden,
was anzeigt, daß die
PDP-Adresse durch die Benutzerausrüstung UE mit dem externen PDN
ausgehandelt werden soll, nachdem das PDP-Kontextaktivierungsverfahren
abgeschlossen ist. Der GGSN soll diese Aushandlungen weitergeben,
modifizieren und überwachen,
solange der PDP-Kontext im ACTIVE-Zustand ist, und das GGSN-initiierte PDP-Kontextmodifizierungsverfahren
verwenden, um die derzeit verwendete PDP-Adresse an den SGSN und
die Benutzerausrüstung
UE zu übertragen.
PDP-Konfigurationsoptionen enthalten optionale PDP-Parameter, die
der GGSN an die Benutzerausrüstung
UE übertragen
kann. Diese optionalen PDP-Parameter können von der Benutzerausrüstung UE
in der Aktiviere-PDP-Kontext-Anforderung-Nachricht
angefordert werden oder sie können
unaufgefordert von dem GGSN gesendet werden. PDP-Konfigurationsoptionen
werden transparent durch den SGSN gesendet. Die Erzeuge-PDP-Kontext-Nachrichten
werden über
das Backbone-Netz gesendet.
-
S96:
Ein Funkzugriffsträger
wird in Übereinstimmung
mit der PDP-Aktivierung, einschließlich QoS-Aushandlung, errichtet.
Die PDP-Kontextanforderung wird dann von dem SGSN zu dem GGSN aktualisiert
(S97), und der GGSN antwortet bzw. reagiert auf die Aktualisierung
(S98).
-
S99:
Wenn die Benutzerausrüstung
UE eine dynamische Adresse angefordert hat, wird die von dem GGSN
empfangene PDP-Adresse in den PDP-Kontext eingefügt. Der SGSN wählt Funkpriorität und Paketfluß-ID auf
Basis der ausgehandelten QoS und gibt eine Aktiviere-PDP-Kontext-Akzeptanz (PDP-Typ,
PDP-Adresse, TI, ausgehandelte QoS, Funkpriorität, Paketfluß-ID, PDP-Konfigurationsoptionen)-Nachricht
an die Benutzerausrüstung
UE zurück.
Der SGSN kann nun PDP-PDUs zwischen dem GGSN und der Benutzerausrüstung UE
routen und den Ladevorgang starten. NSAPI (zusammen mit TI) wird
verwendet, um sekundäre
PDP-Kontexte zu unterscheiden.
-
7. Literaturstellen
-
- [1] RFC2893
- [2] RFC2766 unter Verwendung von SIIT (RFC 2765)
- [3] R. Steele, C.-C. Lee und P. Gould, "Gsm, cdmaOne and 3G Systems", veröffentlicht
von Wiley International ISBN 0 471 491853
- [4] 3G TS 32.015
- [5] 3GPP TS 26.202 V5.1.0 (2002-09)
- [6] 3GPP TS 23.107
- [7] RFC2461 Neighbor Discovery for IP Version 6 (IPv6), Dezember
1998
- [8] RFC 3513 Internet Protocol Version 6 (IPv6) Addressing Architecture,
April 2003
- [9] RFC3315 Dynamic Host Configuration Protocol for Ipv6 (DHCPv6)
- [10] RFC3633 Ipv6 Prefix Options for Dynamic Host Configuration
Protocol (DHCP) version 6.
- [11] RFC2460 Internet Protocol, Version 6 (IPv6) Specifications.