WO2005062567A1 - Verfahren, netzübergangsknoten und endgerät zur paketorientierten datenübertragung - Google Patents

Verfahren, netzübergangsknoten und endgerät zur paketorientierten datenübertragung Download PDF

Info

Publication number
WO2005062567A1
WO2005062567A1 PCT/EP2004/053302 EP2004053302W WO2005062567A1 WO 2005062567 A1 WO2005062567 A1 WO 2005062567A1 EP 2004053302 W EP2004053302 W EP 2004053302W WO 2005062567 A1 WO2005062567 A1 WO 2005062567A1
Authority
WO
WIPO (PCT)
Prior art keywords
terminal
ggsn
network
identification number
address
Prior art date
Application number
PCT/EP2004/053302
Other languages
English (en)
French (fr)
Inventor
Thomas Belling
Original Assignee
Siemens Aktiengesellschaft
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Publication of WO2005062567A1 publication Critical patent/WO2005062567A1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/26—Network addressing or numbering for mobility support
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5007—Internet protocol [IP] addresses
    • H04L61/5014—Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5092—Address allocation by self-assignment, e.g. picking addresses at random and testing if they are already in use
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/167—Adaptation for transition between two IP versions, e.g. between IPv4 and IPv6
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24—Negotiation of communication capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/04—Interfaces between hierarchically different network devices
    • H04W92/06—Interfaces between hierarchically different network devices between gateways and public network devices

Definitions

  • gateway node for packet-oriented data transmission
  • the invention relates to a method and a gateway for packet-oriented data transmission between at least one terminal, in particular a mobile terminal, and a packet-oriented communication network via a gateway, a communication context being used for the data transmission to the gateway, to which a so-called subnet prefix is assigned.
  • the invention further relates to a terminal for carrying out the method according to the invention.
  • IPv ⁇ Internet Protocol
  • the last 8 bytes are used as so-called “Interface ID” (interface identification numbers) to distinguish network nodes within a subnet of the lowest hierarchical level, and the first 8 bytes as a so-called "subnet prefix” ⁇ network address for a packet-oriented subdivided communication network) used to differentiate the subnets.
  • Interface ID interface identification numbers
  • subnet prefix ⁇ network address for a packet-oriented subdivided communication network
  • IPv ⁇ Two mechanisms for auto-configuration of addresses are defined in IPv ⁇ , the so-called “Stateless Address Autoconfiguration, RFC 2462, and the so-called” Statefull Address Autoconfiguration "using the so-called” “Dynamic Host Configuration Protocol for IPv6” (DHCPv6), RFC 3315.
  • a cellular network standardized by the 3GPP can include the so-called “General Packet Radio Service (GPRS)", 3GPP TS 23.060 and TS 29.061.
  • GPRS General Packet Radio Service
  • GGSN Gateway GPRS Support Node
  • IPv6 packets can be transported within the PDP context.
  • each PDP context is assigned its own IPv ⁇ subnet, which is identified by its own 8 byte subnet 'prefix.
  • the GGSN connects this subnet as a so-called router with other IPv6 subnets, thereby connecting the mobile IPv ⁇ device to the Internet.
  • the mobile IPv ⁇ devices use IPv6 address auto configuration according to RFC 2462 or RFC 3315 to select their IPv ⁇ addresses.
  • IPv6 address auto configuration according to RFC 2462 or RFC 3315 to select their IPv ⁇ addresses.
  • PDP context and the corresponding IPv6 subnet, only one or very few mobile devices are connected to the GGSN, although 8 bytes are reserved for their differentiation.
  • IETF RFC 3177 even recommends that operators only have a much smaller address space in which they are assigned a 47 bit or somewhat shorter prefix and not a 32 bit prefix as in the example.
  • the object of the invention is to avoid a resource shortage of PDP contexts due to a limited number of IPv ⁇ 8 byte subnet prefixes.
  • An essential aspect of the invention consists in a method in which several communication contexts are assigned to the same subnet prefix in the network gateway node, an interface identification number assigned to the terminal is received or selected and stored within a communication context, and a suitable communication context is used when sending data to the terminal the saved interface identification number is selected.
  • Another aspect of the invention lies in a network node and a terminal, which are designed with means for performing the method described above.
  • the invention is also applicable in other scenarios where many IPv ⁇ subnets that use the IPv ⁇ address auto-configuration are connected to the Internet by means of one or a few network nodes.
  • An example outside of 3GPP is a so-called Internet Access Point, which enables IPv6 end devices to connect to the Internet via dial-up connections via the telephone network.
  • the inventions preferably solve the following problems:
  • FIG. 1 shows a schematically illustrated typical network configuration
  • FIG. 2 schematically shows a message flow diagram in the case of the "Stateless Address Autoconfiguration"
  • Figure 3 schematically shows a message flow diagram in the case of the "statefull address autoconfiguration".
  • FIG. 1 shows the network configuration described above.
  • the mobile IPv ⁇ terminals A, B, and C are each connected to the gateway GPRS support node GGSN by means of a suitable PDP context (PDP context A, B and C). IPv ⁇ packets are transported within the PDP contexts.
  • the GGSN connects the PDP contexts with a IPv ⁇ network.
  • the GGSN is often preceded by a so-called "edge router".
  • the mobile IPv ⁇ devices use IPv ⁇ address auto configuration according to RFC 2462 or RFC 3315 to select their IPv ⁇ addresses. In the case of statefull address auto configuration in accordance with RFC 3315, an external DHCP server is typically used.
  • the same 8 byte IPv ⁇ subnet prefix is assigned to multiple PDP contexts. Accordingly, the terminals A, B and C are all in the IPv ⁇ subnet 1, and their global IPv ⁇ address is composed of the IPv ⁇ subnet prefix 1 and an individual interface identification number (Interface ID A, Interface ID B, Interface ID C).
  • the message sequences provided with a "bracket" in FIGS. 2 and 3 can run optionally and alternatively.
  • FIG. 2 shows a typical communication sequence for stateless address auto configuration.
  • the network configuration corresponds to FIG. 1, but no DHCP server is used.
  • the mobile terminal A begins communication by activating the PDP context A (FIG. 2, step 1).
  • the GGSN decides that the stateless address autoconfiguration is used (FIG. 2, step 3).
  • the following procedures are also shown: -
  • the optional Neighbor Discovery ( Figure 2, steps 4. and 5.) can take place when establishing a connection or during the existing connection.
  • the terminal A sends an IP user packet to any recipient (FIG. 2, steps 6 to 8).
  • the terminal A receives an IP user packet from any recipient (FIG. 2, steps 9 to 11).
  • the terminal A sends one IP user packet, the terminal B in the same subnet 1 (FIG. 2, steps 12 to 16)
  • the terminal A ends the communication by deleting the PDP context A (FIG. 2, steps 17 to 19).
  • FIG. 3 shows a typical communication sequence for statefull address auto configuration.
  • the network configuration corresponds to FIG. 1, the DHCP server being used.
  • the mobile terminal A begins communication by activating the PDP context A (FIG. 3, step 1).
  • the GGSN decides that the state-filled address autoconfiguration is used (FIG. 3,
  • Step 2. The following processes are also shown: The statefull address auto-configuration of the global IPv6 address of terminal A using DHCP (FIG. 3, steps 3 to 12). Terminal A receives an IP user packet from any recipient (FIG. 3, steps 13). to 15.) - The terminal A sends an IP user packet, the terminal B in the same subnet 1 (FIG. 3, steps 16. to 20.) The terminal A ends the communication by deleting the PDP context A (FIG. 3, steps 21 to 23.)
  • the gateway GPRS support node GGSN maintains a database with used interface IDs (interface identification numbers) for a given subnet prefix, thus ensuring that the same interface IDs are not used more than once.
  • the GGSN can, for example, use a list of all Maintain the interface IDs or save the interface IDs used separately for each PDP context (communication context) ( Figure 2, step 2, 5, 7).
  • the list of all interface IDs also preferably contains information about the associated PDP context.
  • the GGSN When the PDP context is activated, the GGSN searches for an interface ID which has not yet been used and informs the UE of this in the signaling associated with the activation of the PDP context (FIG. 2, steps 1 to 3). The GGSN stores that this interface ID is used. The GGSN chooses a 'Interface ID is not used for its end of the PDP context from. The GGSN can use the same interface ID for all PDP contexts because it is only used to create a so-called link-local IPv6 address. In any case, the GGSN stores that the interface ID is used (not shown in FIG. 2).
  • the GGSN can also learn from special so-called "neighbor solicitation messages" (FIG. 2, step 4) about the interface IDs used.
  • the so-called source IP address contains the interface ID in the IP header of packets sent by the mobile Ipv ⁇ terminal (FIG. 2, step 6).
  • the GGSN also stores used interface IDs, which it learns about in these two ways.
  • the GGSN removes the corresponding interface IDs from the list (FIG. 2, step 17, 18, 19).
  • the GGSN assigns an interface ID to the mobile IPv ⁇ terminal when activating the PDP context with the help of the signaling used
  • the end device must only be used to form a so-called link-local IPv ⁇ address, but not necessarily to form a global IPv ⁇ address ( Figure 2, step 3).
  • the specification is preferably modified so that in the case of stateless address auto-configuration, the terminal must use the same interface ID for the formation of the link-local IP address and the global IPv6 address.
  • the mobile IPv6 preferably specifies in the so-called PDP Activate Request (FIG. 2, step 1) whether it also uses the interface ID provided by the GGSN in the case of stateless address auto-configuration to form the global IPv ⁇ Address will use. Otherwise the GGSN uses its own IPv ⁇ subnet for the corresponding PDP context.
  • the GGSN checks on receipt of a neighbor solicitation message for so-called “duplicate address detection" in accordance with RFC 2462 (FIG. 2, step 4), whether the interface ID specified there is already used in another PDP context or in the same PDP context by the GGSN interface. If this is the case, the GGSN replies with a so-called “Neighbor Advertisement Message” with a so-called “tentative target address", which contains the already used interface ID. As a result, according to RFC 2462, the mobile IPv6 device is prohibited from using this interface ID.
  • the mobile terminal After activating a PDP context, the mobile terminal uses a DHCP request in accordance with RFC 3315 to assign a globally unique IPv6 address from a DHCP server ( Figure 3, steps 3 to 12).
  • the DHCP server assigns IP addresses, whereby it provides the correct network prefix for each PDP context and unique interface IDs for each network prefix (FIG. 3, step 9).
  • the same network prefix can be assigned to several PDP contexts.
  • the DHCP server can be integrated in the GGSN or upstream of the GGSN (an external DHCP server is shown in FIGS. 1 and 3).
  • the DHCP server If the DHCP server is integrated in the GGSN, the DHCP server knows directly from the PDP context in which the request was received and selects the network prefix accordingly.
  • the GGSN takes over the role of a so-called DHCP relay agent, as described in TS 29.061.
  • the GGSN packages DHCP messages received within a PDP context (FIG. 3, steps 3, 7) in DHCP relay forward messages and sends these messages to the DHCP server (FIG. 3, steps 4, 8).
  • the network prefix corresponding to the PDP context as well as a so-called DHCP interface ID (not identical to the IPv6 interface ID) is given for the unique identification of the PDP context.
  • the DHCP server answers the DHCP message, encapsulating the message to the mobile IPv ⁇ terminal in a DHCP relay backward message (FIG.
  • the GGSN takes the DHCP message from the DHCP relay backward message to the mobile terminal and forwards this message in the PDP context specified with the DHCP interface ID (FIG. 3, step 6, 12). According to the invention, the GGSN takes the assigned IP address from the DHCP reply message and stores the interface ID contained therein (FIG. 3, step 11).
  • the GGSN removes the corresponding interface IDs from the list. ( Figure 3, steps 21 to 23)
  • the GGSN stores the interface IDs or complete IPv6 addresses used in a given PDP context.
  • the GGSN considers the subnet prefix and the interface ID of the complete IPv ⁇ destination address in order to select the PDP context in which it forwards the user packet (Figure 2, step 10, 15, and Figure 3, step 14 ., 19.).
  • the GGSN determines and stores the interface IDs used (FIG. 2, step 2, 5, 7).
  • the GGSN takes the assigned IPv ⁇ address from the DHCP response (FIG. 3, step 11).
  • the PDP context represents a point-to-point connection. Therefore, the mobile IPv ⁇ device sends all packets to the GGSN, even if the destination of the packets is an IP address with the same network prefix ( Figure 2, step 12. and Figure 3, step 16.). Since the PDP context as point-to-point connection does not provide any addresses on the transport level below IP, the mobile IPv ⁇ terminal will not operate an address resolution in accordance with RFC 2461.
  • the forwarding of IPv6 packets between PDP contexts with the same subnet prefix can be achieved in two ways: A. The GGSN forwards packets between PDP contexts with the same subnet prefix directly. For this purpose, the GGSN checks, on receipt of IPv ⁇ packets within a PDP context, whether the packets are directed to an IPv ⁇ globally unique destination address with the same subnet prefix and, if necessary, forwards the packets (not shown in FIGS. 2 and 3). B. The GGSN forwards all packets contained in a PDP context to a so-called edge router, regardless of the destination address (FIG. 2, step 13 and FIG. 3, step 17).
  • the edge router sends them back to the GGSN (FIG. 2, step 14 and FIG. 3, step 18).
  • the GGSN uses the mechanisms described under 2. to select the PDP context (FIG. 2, step 15 and FIG. 3, step 19).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

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, wobei für die Datenübertragung zum Netzübergangsknoten ein Kommunikationskontext verwendet wird, dem ein sogenannter 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 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.

Description

Beschreibung
Verfahren, Netzübergangsknoten und Endgerät zur paketorientierten Datenübertragung
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 (IPvβ) werden 16 ByteIP Adressen verwendet. Davon werden gemäß RFC 3513 der IETF die letzten 8 Byte als sogenannte "Interface ID" (Schnittstellenidentifikationsnummern) zur Unterscheidung von Netz- knoten 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ög- licht. In IPvβ 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 ""Dynamic 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 transpor- tiert werden. In diesem Fall wird jedem PDP Kontext ein eigenes IPvδ 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 IPvδ Endgerät mit dem Inter- net. Die mobilen IPvδ Endgeräte nutzen IPv6 Adressenautokon- figuration gemäß RFC 2462 oder RFC 3315 zur Auswahl ihrer IPvδ 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 Unterschei- d ng 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 IPvδ Endgerät ein eigener PDP Kontext und somit ein eigenes IPvδ 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 4Byte IPvδ 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ür- zerer Präfix und nicht wie im Beispiel ein 32 bit Präfix zugewiesen wird. Die Aufgabe der Erfindung besteht darin, eine einen Ressour- cenengpass von PDP Kontexten durch eine limitierte Zahl von IPvδ 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 Schnittstel- lenidentifikationsnummer 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 IPvδ Subnetze, die die IPvδ 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 IPvδ Endgeräte dürfen nicht die selbe Interface ID zur Bildung und somit die selbe IPvδ 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 IPvδ 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 Aus- führungsformen.
Die Zeichnung zeigt:
Figur 1 eine schematisch dargestellte typische Netzkonfigura- tion,
Figur 2 schematisch ein Meldungsablaufdiagramm im Falle der genannten "Stateless Adress Autoconfiguration" und
Figur 3 schematisch ein Meldungsablaufdiagramm im Falle der genannten "Statefull Adress Autoconfiguration".
Figur 1 zeigt die eingangs beschriebene Netzkonfiguration. Gemäß dem Stand der Technik werden die mobile IPvδ 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 IPvδ Pakete transportiert . Der GGSN verbindet die PDP Kontexte mit einem IPvδ Netz. Oft ist dem GGSN ein so genannter "Edge Router" vorgeschalten. Die mobilen IPvδ Endgeräte nutzen IPvδ Adres- senautokonfiguration gemäß RFC 2462 oder RFC 3315 zur Auswahl ihrer IPvδ Adressen. Im Falle der Statefull Address Au- toconfiguration gemäß RFC 3315 wird typischerweise ein externer DHCP Server verwendet.
Erfindungsgemäß wird derselbe 8 Byte IPvδ Subnet Präfix mehren PDP Kontexten zugewiesen. Entsprechend befinden sich die Endgeräte A, B und C alle im IPvδ Subnetz 1, und ihre globale IPvδ Addresse setzt sich jeweils aus dem IPvδ Subnet Präfix 1 und einer individuellen Schnittstellenidentifikationsnummer (Interface ID A, Interface ID B, Interface ID C) zusammen.
Die in den Figuren 2 und 3 mit einer "Klammer" versehenen Meldungsabläufe können optional und alternativ ablaufen.
Figur 2 stellt einen typischen Ablauf der Kommunikation bei der Stateless Address Autoconfiguration dar. Die Netzkonfiguration entspricht Figur 1, wobei kein DHCP Server verwendet wird. Das mobile Endgerät A beginnt die Kommunikation durch das Aktivieren des PDP Kontextes A (Figur 2, Schritt 1.) . Der GGSN entscheidet in seiner Antwortnachricht, dass die Stateless Address Autoconfiguration verwendet wird (Figur 2, Schritt 3.). Im Weiteren sind folgende Abläufe dargestellt: - Die optionalen Neighbor Discovery (Figur 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 (Figur 2, Schritte 6. bis 8.) - Das Endgerät A empfängt ein IP Nutzpaket von einem beliebigen Empfänger (Figur 2, Schritte 9. bis 11.) Das Endgerät A sendet ein IP Nutzpaket das Endgerät B im selben Subnetz 1 (Figur 2, Schritte 12. bis 16.) Das Endgerät A beendet die Kommunikation durch Löschen des PDP Kontextes A (Figur 2, Schritte 17. bis 19.)
Figur 3 stellt einen typischen Ablauf der Kommunikation bei der Statefull Address Autoconfiguration dar. Die Netzkonfiguration entspricht Figur 1, wobei der DHCP Server verwendet wird. Das mobile Endgerät A beginnt die Kommunikation durch das Aktivieren des PDP Kontextes A (Figur 3, Schritt 1.). Der GGSN entscheidet in seiner Antwortnachricht, dass die State- füll Address Autoconfiguration verwendet wird (Figur 3,
Schritt 2.) . Im Weiteren sind folgende Abläufe dargestellt: Die Statefull Address Autoconfiguration der globalen IPv6 Addresse des Endgerätes A mittels DHCP (Figur 3, Schritte 3. bis 12.) - Das Endgerät A empfängt ein IP Nutzpaket von einem beliebigen Empfänger (Figur 3, Schritte 13. bis 15.) - Das Endgerät A sendet ein IP Nutzpaket das Endgerät B im selben Subnetz 1 (Figur 3, Schritte 16. bis 20.) Das Endgerät A beendet die Kommunikation durch Löschen des PDP Kontextes A (Figur 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 (Figur 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 (Figur 2, Schritt 2., 5., 7.). Auch die Liste aller Interface IDs enthält vorzugsweise Informationen über den zugehörigen PDP Kontex .
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 Signali- sierung mit (Figur 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 Figur 2 dargestellt) .
Der GGSN kann gemäß RFC 2462 auch aus speziellen so genannten "Neighbor Solicitation Messages" (Figur 2, Schritt 4.) über verwendete Interface IDs lernen. Ebenso enthält die so genannte Source IP Adresse im IP Header von vom mobilen Ipvδ Endgerät gesendeten Paketen die Interface ID (Figur 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 (Figur 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 IPvδ Endgerät eine Interface ID zu, die das mobile IPvδ Endgerät aber nur zur Bildung einer so genannten link-local IPvδ Adresse, aber nicht notwendigerweise auch zur Bildung einer globalen IPvδ Adresse nützen muss (Figur 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 Ab- wärtskompatibilität zu gewährleisten, gibt das mobile IPv6 vorzugsweise in dem so genannten PDP Activate Request (Figur 2, Schritt 1.) an, ob es die vom GGSN bereitgestellte Interface ID im Falle der Stateless Adress Autoconfiguration auch zur Bildung der globalen IPvδ Adresse verwenden wird. Andern- falls verwendet der GGSN ein eignes IPvδ 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, über-' prüft der GGSN beim Erhalt einer Neighbor Solicitation Message zur sogenannten "Duplicate Address Detection" gemäß RFC 2462 (Figur 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 64bit Adressraums der Interface IDs sind solche Kollisionen sehr unwahrscheinlich. Statefull Address Autoconfiguration (Figur 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 (Figur 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 (Figur 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 Figur 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 (Figur 3, Schritt 3. , 7. ) in DHCP Relay Forward Nachrichten und schickt diese Nachrichten an den DHCP Server (Figur 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 IPvδ Endgerät in eine DHCP Relay Backward Nachrichten enkapsuliert (Figur 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 (Figur 3, Schritt 6., 12.). Erfindungsgemäß entnimmt der GGSN der DHCP Reply Message die zugewiesene IP Adresse und speichert die darin enthaltene Interface ID ab (Figur 3, Schritt 11) .
Wenn der PDP Kontext gelöscht wird, entfernt der GGSN die entsprechenden Interface IDs wieder aus der Liste. (Figur 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 IPvδ Nutzpakets betrachtet der GGSN neben dem Subnetz Präfix auch die Interface ID der vollständige IPvδ Zieladresse, um den PDP Kontext auszuwählen, in dem er das Nutzpaket weiterreicht (Figur 2, Schritt 10., 15., sowie Figur 3, Schritt 14., 19.). Für die Stateless Adress Autoconfiguration wurde bereits be- schrieben, wie der GGSN die verwendeten Interface IDs feststellt und speichert (Figur 2, Schritt 2., 5., 7.). Für die Stateful Adress Autoconfiguration entnimmt der GGSN die zugewiesene IPvδ Adresse der DHCP Antwort (Figur 3, Schritt 11) .
Lösung zu Problem 3:
Der PDP Kontext stellt eine Punkt-zu-Punkt Verbindung dar. Deswegen' sendet das mobile IPvδ Endgerät alle Pakete an den GGSN, selbst wenn das Ziel der Pakete eine IP Adresse mit dem selben Netzwerk Präfix ist (Figur 2, Schritt 12. sowie Figur 3, Schritt 16.). Da der PDP Kontext als Punkt-zu-Punkt Verbindung auch keine Adressen auf der Transportebene unterhalb IP vorsieht, wird das mobile IPvδ 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 IPvδ Paketen innerhalb eines PDP Kontextes, ob die Pakete an eine IPvδ global eindeutige Zieladresse mit der selben Subnetz Präfix gerichtet sind, und reicht die Pakete gegebenenfalls weiter (nicht in Figur 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 (Figur 2, Schritt 13. sowie Figur 3, Schritt 17.). Sollten die Pakete an eine IPvδ Zieladresse im selben Subnetz gerichtet sein, sendet sie der Edge Router zurück an den GGSN (Figur 2, Schritt 14. sowie Figur 3, Schritt 18.). Der GGSN verwendet die unter 2. beschriebenen Mechanismen, um den PDP Kontext auszuwählen Figur 2, Schritt 15. sowie Figur 3, Schritt 19.).

Claims

Patentansprüche
1. Verfahren zur paketorientierten Datenübertragung zwischen mindestens einem Endgerät (Endgerät A) . und einem paket- orientierten 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 Schnittstellen- Identifikationsnummer innerhalb eines Kommunikationskon- textes 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.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Netzübergangsknoten (GGSN) durch einen sogenannten . Gateway GPRS Support Node repräsentiert wird.
3. Verfahren nach einem der vorhergehenden Ansprüchen, dadurch gekennzeichnet, dass der Kommunikationskontext durch einen sogenannten PDP-Kontext repräsentiert wird.
4. Verfahren nach einem der vorhergehenden Ansprüchen, dadurch gekennzeichnet, dass die Schnittstellenidentifikationsnummer durch die 8 Byte Interface ID einer IPvδ- Netzadresse repräsentiert wird.
5. 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.
6. 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.
7. 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 Schnittstellenidentifika- tionsnummer zum Bilden einer globalen IPv6 Address verwendet .
8. 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 (Figur 2, Schritt 1.) ■
9. 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 IPvδ Address verwendet (Figur 2, Schritt 1.).
10. 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.
11. 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 .
12. 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 (Figur 2, Schritt 5.).
13. 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 Ursprung- saddresse enthaltene Schnittstellenidentifikationsnummer abspeichert (Figur 2, Schritt 7.).
14. Verfahren nach einem der vorhergehenden Ansprüchen, dadurch gekennzeichnet, dass der Netzübergangsknoten (GGSN) die in der DHCP Reply Nachricht enthaltene Schnittstellenidentifikationsnummer abspeichert (Figur 3, Schritt 1) .
15. 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.
16. 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 Schnittstellenidentifikationsnum- mer.
17. 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 Proto- • koll IP Version 6 über einen Netzübergangsknoten (GGSN) zu einem paketorientierten Kommunikationsnetz unter Verwendung eines Kommunikationskontextes, dem ein sogenann- ■ ter Subnetz-Präfix zugewiesen ist, aufweisend: - Mittel zum Empfangen einer Schnittstellenidentifikations--.- nummer innerhalb der der Signalisierung zum Aufbau des Kommunikationskontextes, die zum Bilden einer globalen Netzadresse, vorzugsweise einer IPvδ Adresse, verwendet wird, Mittel zur Signalisierung ob die empfangene Schnittstel- lenidentifikationsnummer zum Bilden der Netzadresse verwendet wird.
PCT/EP2004/053302 2003-12-22 2004-12-07 Verfahren, netzübergangsknoten und endgerät zur paketorientierten datenübertragung WO2005062567A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10360531A DE10360531A1 (de) 2003-12-22 2003-12-22 Verfahren, Netzübergangsknoten und Endgerät zur paketorientierten Datenübertragung
DE10360531.2 2003-12-22

Publications (1)

Publication Number Publication Date
WO2005062567A1 true WO2005062567A1 (de) 2005-07-07

Family

ID=34683763

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2004/053302 WO2005062567A1 (de) 2003-12-22 2004-12-07 Verfahren, netzübergangsknoten und endgerät zur paketorientierten datenübertragung

Country Status (2)

Country Link
DE (1) DE10360531A1 (de)
WO (1) WO2005062567A1 (de)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100444691C (zh) * 2005-12-21 2008-12-17 中国移动通信集团公司 对移动终端状态转换过程中的非接入层信令的处理方法
WO2010069181A1 (zh) * 2008-12-17 2010-06-24 华为技术有限公司 Ipv6地址配置方法和系统
CN101753633B (zh) * 2008-12-09 2013-06-05 华为技术有限公司 IPv6前缀分配方法、系统及其设备

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102009012561B4 (de) * 2009-03-11 2015-01-22 Rohde & Schwarz Gmbh & Co. Kg Verfahren und Mobilfunktester zur Erzeugung einer global gültigen Adresse für ein Mobilfunkgerät für eine Mobilfunk-Testprozedur

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010017856A1 (en) * 2000-01-20 2001-08-30 Nokia Mobile Phones Ltd. Address acquisition
US20030026230A1 (en) * 2001-08-02 2003-02-06 Juan-Antonio Ibanez Proxy duplicate address detection for dynamic address allocation

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010017856A1 (en) * 2000-01-20 2001-08-30 Nokia Mobile Phones Ltd. Address acquisition
US20030026230A1 (en) * 2001-08-02 2003-02-06 Juan-Antonio Ibanez Proxy duplicate address detection for dynamic address allocation

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100444691C (zh) * 2005-12-21 2008-12-17 中国移动通信集团公司 对移动终端状态转换过程中的非接入层信令的处理方法
CN101753633B (zh) * 2008-12-09 2013-06-05 华为技术有限公司 IPv6前缀分配方法、系统及其设备
WO2010069181A1 (zh) * 2008-12-17 2010-06-24 华为技术有限公司 Ipv6地址配置方法和系统

Also Published As

Publication number Publication date
DE10360531A1 (de) 2005-07-21

Similar Documents

Publication Publication Date Title
DE602005004291T2 (de) System und verfahren zur übermittlung von internetpaketdaten via paketfunknetze
DE60114649T2 (de) Adressvergabe an mobile stationen
DE60028254T2 (de) Steuerungsgerät und -verfahren für paketbasierte kommunikation
DE19742681C2 (de) GPRS-Teilnehmerauswahl von mehreren Internet-Dienstanbietern
DE602005003189T2 (de) Verfahren und System zum Aufbau eines bidirektionalen Tunnels
DE60308309T2 (de) System, Verfahren und Übergangseinrichtung zur dynamischen Zuordnung einer Heimnetzwerkadresse zu einem mobilen Knoten in einem Fremdnetzwerk
DE60310593T2 (de) Routing in einem datenkommunikationsnetz
DE60032229T2 (de) Automatische ip adressvergabe für mobilfunkendgeräte
EP1994677B1 (de) Verfahren zur übertragung der identität einer multicast-nachricht, verfahren und vorrichtung zur übertragung einer multicast-nachricht sowie vorrichtung zum empfangen einer multicast-nachricht
DE60033162T2 (de) Erleichterung der datenübertragung
DE112004000040T5 (de) Verfahren und System für das Erzeugen von IP-Adressen von Zugangsterminals und das Senden von Nachrichten für die Erzeugung von IP-Adressen in einem IP-System
DE60133641T2 (de) Kommunikationssystem und verfahren dafür
DE60300035T2 (de) Kommunikationssystem zum Aufbauen einer PPPoE ähnlichen Verbindung zwischen IEEE1394 basierten Peeren und IP basierten Peeren
EP1040632A2 (de) Verfahren zur unterstützung von mobilität im internet
DE60125426T2 (de) Senden einer "binding update"-nachricht, die eine "care of address" aufweist, um datenpakete über eine unidirektionale schnittstelle zu einem mobilen knoten zu übertragen
DE102012109531B4 (de) Vorrichtungen und Verfahren zur IPV6-Adress-Beschaffung
EP0998100B1 (de) Verfahren zum Einrichten eines Internet-Protokoll Netzwerkes
DE60208990T2 (de) Verfahren zur Unterscheidung von Teilnehmer eines Kommunikationssystems, Kommunikationssystem und Kommunikationsgerät
DE102005006889B4 (de) Verfahren, Kommunikationsanordnung und Kommunikationsvorrichtung zum Einrichten einer Kommunikationsbeziehung in zumindest einem Kommunikationsnetz
DE60221538T2 (de) System und verfahren zum koordinieren von netzereignissen
WO2007025905A1 (de) Kommunikationssystem, vermittlungsknoten-rechner und verfahren zur bestimmung eines kontrollknotens
DE112006001712B4 (de) Auf dem Address Resolution Protocol basierendes drahtloses Zugriffspunktverfahren und entsprechende Vorrichtung
EP1494434B1 (de) Verfahren zur Konfiguration einer Einrichtung in einem Datennetz
WO2002073932A9 (de) Verfahren und vorrichtung für ein l2tp-reconnection-handling
DE60225030T2 (de) Verfahren zur Unterstützung der IP-Mobilität, dazugehöriges System und dazugehörige Vorrichtungen

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

122 Ep: pct application non-entry in european phase