DE10360531A1 - Method, network gateway node and terminal for packet-oriented data transmission - Google Patents

Abstract

The invention relates to a method and a network gateway node (GGSN) for packet-oriented data transmission between at least one terminal (terminal A), in particular a mobile terminal, and a packet-oriented communication network via a gateway node, DOLLAR A being used for the data transmission to the gateway node a communication context, the a so-called subnet prefix is assigned. Preferably, the IP version 6 protocol is used for data transmission. An essential aspect of the invention is a method in which DOLLAR A - in the gateway node the same subnet prefix is assigned a plurality of communication contexts, DOLLAR A - an interface identification number assigned to the terminal is received or selected and stored within a communication context, DOLLAR A - and upon transmission from data to the terminal a suitable communication context is selected based on the stored interface identification number. DOLLAR A Another aspect of the invention lies in a gateway node and a terminal, which are designed with means for performing the method described above.

Description

The The invention relates to a method and a gateway node for packet-oriented data transfer between at least one terminal, in particular a mobile device, and a packet-oriented communication network via a gateway node, being for the data transmission to the gateway node a communication context is used to which a so-called subnet prefix is assigned is. Furthermore, the invention relates to a terminal for carrying out the inventive method.

at Version 6 of the Internet Protocol (IPv6) becomes 16-byte IP addresses uses. Of these, according to RFC 3513 the IETF the last 8 bytes as so-called "Interface ID" (interface identification numbers) for distinguishing 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 divided communication network) to distinguish the subnets uses. This will allow autoconfiguration of the IPv6 address. In IPv6 are two mechanisms for autoconfiguration of addresses defined, the so-called "Stateless Address Autoconfiguration, RFC 2462, and the so-called "Statefull Address Autoconfiguration" with the help of the so called "dynamite Host Configuration Protocol for IPv6 "(DHCPv6), RFC 3315.

One 3GPP standardized mobile network can be the so-called "General Packet Radio Service (GPRS) ", 3GPP TS 23.060 and TS 29.061. Here is the mobile Endge advises means a so-called "PDP Context "(communication context) with a gateway node, preferably connected to a so-called "Gateway GPRS Support Node" (GGSN). Within the PDP context can IPv6 packets are transported. In this case, every PDP context assigned its own IPv6 subnet, which uses its own 8 Byte subnet prefix is identified. The GGSN connects this subnet as so-called Router with other IPv6 subnets, thereby connecting the mobile IPv6 terminal with the Internet. The mobile IPv6 terminals use IPv6 address autoconfiguration according to RFC 2462 or RFC 3315 to select their IPv6 addresses. By means of a PDP Context and the corresponding IPv6 subnet are only one or very few mobile devices connected to the GGSN, though for their distinction 8 bytes are reserved.

It is expected that a lot of mobile devices from 3GPP Mobile networks supported Need to become, being for almost every mobile IPv6 device a separate PDP context and thus a separate IPv6 subnet is needed. In certain configurations of a 3GPP mobile network, it may this will lead to a shortage of subnet prefixes. For example the operator of a 3GPP mobile network a 4 byte IPv6 address prefix for his network and the operator uses another 2 bytes for the distinction his GGSNs, the operator only has 2 bytes per GGSN (65536) to distinguish the PDP contexts. IETF RFC 3177 even recommends Operators only have a much smaller address space available give them a 47-bit or slightly shorter prefix and not as in the example a 32 bit prefix is assigned.

The The object of the invention is a resource shortage of PDP contexts by a limited number of IPv6 8-byte subnet prefixes too avoid.

The Task is by a method and by a device of a Network gateway node as well a terminal solved according to the independent claims. advantageous Further developments of the invention are specified in the dependent claims.

• – 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.

An essential aspect of the invention is a method in which

• In the gateway node, assigning multiple communication contexts to the same subnet prefix,
• An interface identification number assigned to the terminal is received or selected and stored within a communication context,
• - And when sending data to the terminal a suitable communication context is selected based on the stored interface identification number.

One Another aspect of the invention resides in a gateway node as well as a terminal that with means for performing of the method described above are configured.

The Invention is also applicable to other scenarios where many IPv6 Subnets that use the IPv6 address autoconfiguration by means of one or a few network nodes are connected to the Internet. One Example outside 3GPP is a so-called Internet access point that allows IPv6 terminals via dial-up connections via the Telephone network to connect to the Internet.

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

Preferably, the inventions solve the following problems:

• Problem 1: Two IPv6 devices should not use the same interface ID for the formation and thus the same IPv6 address.
• Issue 2: The GGSN must forward received packets to the correct PDP context.
• Problem 3: Transport of packets between mobile IPv6 terminals in different PDP contexts with the same subnet prefix must be possible.

Further Advantages of the invention will become apparent from the below-described illustrated by a drawing Embodiments.

The Drawing shows:

1 a schematically illustrated typical network configuration,

2 schematically a message flow diagram in the case of said "Stateless Address Autoconfiguration" and

3 schematically a message flow diagram in the case of said "stateful address autoconfiguration".

1 shows the network configuration described above. According to the prior art, the mobile IPv6 terminals A, B, and C are each connected by means of their own PDP context (PDP Context A, B and C) to the gateway GPRS Support Node GGSN. Within the PDP contexts, IPv6 packets are transported. The GGSN connects the PDP contexts with an IPv6 network. Often, the GGSN is preceded by a so-called "edge router." The mobile IPv6 terminals use IPv6 address autoconfiguration to select their IPv6 addresses according to RFC 2462 or RFC 3315. In the case of Statefull Address Autoconfiguration according to RFC 3315, an external DHCP server is typically used.

According to the invention is the same 8 bytes IPv6 subnet prefix assigned to multiple PDP contexts. Accordingly are the terminals A, B and C all in IPv6 subnet 1, and their global IPv6 address consists of the IPv6 subnet prefix 1 and an individual one Interface identification number (Interface ID A, Interface ID B, Interface ID C) together.

The in the 2 and 3 Message sequences provided with a "parenthesis" may be optional and alternative.

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

2 represents a typical flow of communication in stateless address autoconfiguration. The network configuration is the same 1 , where no DHCP server is used. The mobile terminal A starts the communication by activating the PDP context A ( 2 , Step 1 .). The GGSN decides in its reply message that the stateless address autoconfiguration is used ( 2 , Step 3.). The following processes are shown below:

• - The optional Neighbor Discovery ( 2 , Steps 4. and 5.) can occur during connection setup or during the existing connection.
• The terminal A sends an IP user packet to any receiver ( 2 , Steps 6. to 8.)
• The terminal A receives an IP user packet from any receiver ( 2 , Steps 9 to 11)
• The terminal A sends an IP user packet to the terminal B in the same subnet 1 ( 2 , Steps 12. to 16.)
• The terminal A terminates the communication by deleting the PDP context A ( 2 , Steps 17. to 19.)

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

3 represents a typical flow of statefull address autoconfiguration communication. The network configuration is the same 1 using the DHCP server. The mobile terminal A starts the communication by activating the PDP context A ( 3 , Step 1 .). The GGSN decides in its reply message that the statefull address autoconfiguration is used ( 3 , Step 2 .). The following processes are shown below:

• The statefull address autoconfiguration of the global IPv6 address of the terminal A by means of DHCP ( 3 , Steps 3 to 12)
• The terminal A receives an IP user packet from any receiver ( 3 , Steps 13 to 15)
• The terminal A sends an IP user packet to the terminal B in the same subnet 1 ( 3 , Steps 16 to 20)
• The terminal A terminates the communication by deleting the PDP context A ( 3 , Steps 21. to 23.)

The solutions to the problems outlined above are based on the figures in the following details:

Solution to problem 1:

Stateless Address Autoconfiguration ( 2 )

The Gateway GPRS Support Node GGSN maintains a database of used Interface IDs for a given subnet prefix, thus ensuring that the same interface IDs are not used multiple times. The GGSN can, for example, keep a list of all the used interface IDs or separately store the used interface IDs for each PDP context (communication context) ( 2 , Step 2., 5., 7.). The list of all interface IDs also preferably contains information about the associated PDP context.

When activating the PDP context, the GGSN searches for an interface ID that has not yet been used and forwards it to the UE in the signaling for activating the PDP context ( 2 , Step 1 to 3). The GGSN stores that this interface ID is used. The GGSN also selects an unused Interface ID for its end of the PDP context. The GGSN can use the same interface ID for all PDP contexts, as it is only used to create a so-called link-local IPv6 address. The GGSN always saves that the interface ID is used (not in 2 ) Shown.

According to RFC 2462, the GGSN can also be used for special "Neighbor Solicitation Messages" ( 2 , Step 4.) learn about used interface IDs. Likewise, the so-called source IP address in the IP header of packets sent by the mobile Ipv6 terminal contains the interface ID ( 2 , Step 6.). The GGSN also stores used interface IDs, through which it learns in these two ways.

When the PDP context is deleted, the GGSN removes the corresponding interface IDs again from the list ( 2 , Step 17., 18., 19.).

According to TS 29.061, when activating the PDP context with the aid of the signaling used, the GGSN assigns an interface ID to the mobile IPv6 terminal, but the mobile IPv6 terminal only to form a so-called link-local IPv6 address, but not necessarily also for education a global IPv6 address ( 2 , Step 3.).

Preferably, the specification is modified such that in the case of stateless address autoconfiguration the terminal must use the same interface ID for the formation of the link-local IP address and the global IPv6 address. To ensure backwards compatibility, the mobile IPv6 is preferably in the so-called PDP Activate Request ( 2 , Step 1.) whether it will also use the interface ID provided by the GGSN in the case of stateless address autoconfiguration to form the global IPv6 address. Otherwise, the GGSN uses its own IPv6 subnet for the corresponding PDP context.

In order to exclude misconduct, and also in the event that the change in the specification is not possible, the GGSN checks on receipt of a Neighbor Solicitation Message for so-called "Duplicate Address Detection" according to RFC 2462 ( 2 , Step 4), whether the interface ID specified there is already used in another PDP context or in the same PDP context from the GGSN interface. If this is the case, the GGSN answers with a so-called "Neighbor Advertisement Message" with a so-called "tentative target address", which contains the interface ID already used. As a result, RFC 2462 prohibits the mobile IPv6 terminal from using this interface ID.

At the Receiving IP packets with one in another PDP context already used interface ID, the GGSN deactivates the PDP context. On The reason for the 64 bit address space of the interface IDs are such collisions very unlikely.

Stateful Address Autoconfiguration ( 3 )

After activating a PDP context, the mobile terminal requests the assignment of a globally unique IPv6 address from a DHCP server using a DHCP request according to RFC 3315 ( 3 , Step 3 to 12). The DHCP server assigns IP addresses, providing the correct network prefix for each PDP context. For each network prefix, unique interface IDs ( 3 , Step 9). In this case, according to the invention, the same network prefix can be assigned to several PDP contexts. The DHCP server can be integrated into the GGSN or upstream of the GGSN (In 1 and 3 an external DHCP server is shown).

If the DHCP server is integrated into the GGSN, the DHCP server knows directly from the PDP context in which the request was received and selects that Network prefix corresponding.

If the DHCP server was upstream of the GGSN, the GGSN takes over the task of a so-called DHCP Relay Agent, as described in TS 29.061. The GGSN packs DHCP messages received within a PDP context ( 3 , Step 3., 7.) in DHCP Relay Forward messages and sends these messages to the DHCP server ( 3 , Step 4., 8.). Within the DHCP relay forward messages, the network prefix corresponding to the PDP context and also a so-called DHCP interface ID (not identical to the IPv6 interface ID) are specified for unambiguous identification of the PDP context. The DHCP server answers the DHCP message, encapsulating the message to the mobile IPv6 terminal in a DHCP Relay Backward message ( 3 , Step 5., 10.), which also has the same DHCP interface ID ent holds. The DHCP server behaves in accordance with RFC 3315 and requires no special customization, and no knowledge of PDP contexts. The GGSN takes the DHCP message to the mobile terminal from the DHCP Relay Backward message and passes this message on in the PDP context specified with the DHCP Interface ID ( 3 , Step 6, 12). According to the GGSN the DHCP Reply Message takes the assigned IP address and stores the contained interface ID ( 3 , Step 11).

When the PDP context is deleted, the GGSN removes the corresponding interface IDs from the list again. ( 3 , Step 21. to 23.)

Solution to problem 2:

According to the invention, the GGSN stores the interface IDs or complete IPv6 addresses used in a given PDP context. Upon receiving an IPv6 payload packet, the GGSN considers, in addition to the subnet prefix, also the interface ID of the full IPv6 destination address to select the PDP context in which it forwards the payload packet ( 2 , Step 10, 15, as well 3 , Step 14., 19.).

For the stateless address autoconfiguration it has already been described how the GGSN detects and saves the used interface IDs ( 2 , Step 2., 5., 7.). For the stateful address autoconfiguration the GGSN retrieves the assigned IPv6 address of the DHCP response ( 3 , Step 11).

Solution to problem 3:

The PDP context represents a point-to-point connection. Therefore, the mobile IPv6 terminal sends all packets to the GGSN even if the destination of the packets is an IP address with the same network prefix ( 2 , Step 12 as well 3 , Step 16.). Since the PDP context does not provide addresses at the transport level below IP as a point-to-point connection, the mobile IPv6 terminal will not operate an address resolution according to RFC 2461.

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

The passing of IPv6 packets between PDP contexts with the same subnet prefix can be achieved in two ways:

• A. The GGSN passes packets directly between PDP contexts with the same subnet prefix. To do this, upon receiving IPv6 packets within a PDP context, the GGSN checks to see if the packets are directed to an IPv6 globally unique destination address with the same subnet prefix, and optionally passes the packets on (not in 2 and 3 ) Shown.
• B. The GGSN passes all packets contained in a PDP context, independent of the destination address, to a so-called edge router ( 2 , Step 13 as well 3 , Step 17.). If the packets are directed to an IPv6 destination on the same subnet, the Edge Router sends them back to the GGSN ( 2 , Step 14. as well 3 , Step 18.). The GGSN uses the mechanisms described under 2. to select the PDP context 2 , Step 15. as well 3 , Step 19.).

Claims (17)

Method for packet-oriented data transmission between at least one terminal (terminal A) and a packet-oriented communication network via a gateway node (GGSN), which preferably uses the IP version 6 protocol for data transmission, wherein a communication context is used for the data transmission to the gateway node (GGSN) is assigned to the so-called subnet prefix, characterized in that - in the gateway node (GGSN) the same subnet prefix several communication contexts is assigned, - the terminal (terminal A) associated interface identification number within a communication context is received or selected and stored, - and when sending from data to the terminal (terminal A) an appropriate communication context is selected based on the stored interface identification number. Method according to claim 1, characterized in that that the interworking node (GGSN) represented by a so-called Gateway GPRS Support Node becomes. Method according to one of the preceding claims, characterized characterized in that the communication context by a so-called PDP context represents becomes. Method according to one of the preceding claims, characterized characterized in that the interface identification number by the 8-byte interface ID of an IPv6 network address is represented. Method according to one of the preceding claims, characterized characterized in that the terminal (terminal A) is a standardized by the 3GPP so-called "user equipment", which is the so-called UTRAN (= UMTS Terrestrial Radio Access Network) air interface uses. Method according to one of the preceding Claims, characterized in that the terminal (terminal A) is a so-called "Mobile Station" standardized by the 3GPP, which uses the so-called GERAN (= GSM EDGE Radio Access Network) air interface. Method according to one of the preceding claims, characterized characterized in that the terminal (terminal A) in the case of the so-called stateless address autoconfiguration those from the gateway node (GGSN) associated interface identification number for forming a global IPv6 Address. Method according to one of the preceding claims, characterized in that the terminal (terminal A) when activating the communication context tells a network connection node whether it uses in the case of the so-called stateless address autoconfiguration the network interface node (GGSN) to ordered interface identification number for forming the global IPv6 address ( 2 , Step 1.). Method according to the preceding claim, characterized in that a parameter is introduced in the "Create PDP Context Request" and "Activate PDP Context Request" messages, indicating that the terminal (terminal A) in the case of Stateless Address Autoconfiguration is the one from the interworking node (GGSN) used to form the global IPv6 address ( 2 , Step 1.). Method according to one of the preceding claims, characterized characterized in that the network connection node in the case of Stateless Address Autoconfiguration the same subnet prefix only then multiple communication context assigns when the terminals have indicated that they have the associated interface identification number for Make use of the global IPv6 address. Method according to one of the preceding claims, characterized characterized in that the interworking node (GGSN) assigned to the terminal when activating the communication context Save interface identification number. Method according to one of the preceding claims, characterized in that the network gateway node (GGSN) stores the interface identification number received during the so-called neighbor discovery ( 2 , Step 5.). Method according to one of the preceding claims, characterized in that the network gateway node (GGSN stores data received as IP packets from the terminal data stored in the original address interface identification number ( 2 , Step 7). Method according to one of the preceding claims, characterized in that the network gateway node (GGSN) stores the interface identification number contained in the DHCP reply message ( 3 , Step 1 ). Method according to one of the preceding claims, characterized characterized in that the interworking node Packets transmitted by a first terminal (terminal A) in a communication context and to a second terminal (terminal B) in the same subnet, however addressed to another communication context, directly to the second terminal (terminal B). Network gateway node (GGSN) to carry out of the method according to any one of the preceding claims, preferably designed for a data transfer according to the protocol IP version 6 between a terminal (terminal A) and a packet-oriented Communication network using a communication context, a so-called subnet prefix is assigned, comprising: - Means to select or Receive, and for storing a mobile terminal (terminal A) associated Interface identification number within a communication context, - Medium for assigning multiple communication contexts to the same subnet prefix and - Medium to choose a suitable communication context for sending data to terminal (terminal A) based on the stored interface identification number. terminal (terminal A) to carry out of the method according to any one of the preceding claims, preferably designed for a data transfer according to the protocol IP version 6 over a gateway node (GGSN) to a packet-oriented communication network using a Communication context to which a so-called subnet prefix assigned is, comprising: - Medium for receiving an interface identification number within the signaling to the structure of the communication context, the for forming a global network address, preferably an IPv6 address, is used, - Medium for signaling whether the received interface identification number is used to form the network address.