Data packet routing to a mobile user is a problem in the UMTS or GPRS network. This is because the mobile users' data network address typically has a static routing mechanism, while the mobile station can roam from one subnetwork to another. One approach for data packet routing in a mobile environment is the concept of mobile IP (Internet Protocol), as described e.g. in “IP Mobility Support” by C. Perkins, RFC 2002, October 1996. Mobile IP enables the routing of IP datagrams to mobile hosts, independent of the subnetwork point of attachment. Another approach is taken in the system for cellular digital packet data (CDPD), where the routing to mobile hosts is handled internally by the network.
With GPRS, the infrastructure consists of support nodes, such as the GPRS gateway support node (GGSN), and the GPRS serving support node (SGSN). These nodes have corresponding functions in the mobile IP concept as the home agent (HA) and the foreign agent (FA). The main functions of GGSN involve interaction with the external data network. The GGSN updates the location directory using routing information supplied by the SGSNs about a mobile station's path, and routes an external data network protocol packet encapsulated over the GPRS backbone to the SGSN currently serving the mobile station. It also decapsulates and forwards external data network packets to the appropriate data network and handles the charging of data traffic.
From the standpoint of the data network, the GPRS network resembles a subnetwork in the data network. For example, in the Internet, the GGSN acts like an IP router behind which the entire GPRS network is hidden. A computer in the Internet network then sees the GPRS network as an IP subnetwork to which messages are sent, as if the GPRS network were a completely standard Internet implementation. The routing mechanism in the data network is exactly the same as with the normal Internet receiver case.
The GPRS network encapsulates all data network protocols into its own encapsulation protocol. This is done to ensure security in the backbone network and to simplify the routing mechanism and the delivery of data over the GPRS network.
In order to access the GPRS services, a mobile station first makes its presence known to the network by performing a GPRS attach. This operation establishes a logical link between the mobile station and the SGSN, and makes the mobile station available for services like SMS (Short Message Service) over GPRS, paging via the SGSN and notification of incoming GPRS data.
In order to send and receive GPRS data, the mobile station activates the packet data address it wants to use. This operation makes the mobile station known in the corresponding GGSN, and interworking with external data networks can commence.
User data is transferred transparently between the mobile station and the external data network with a method known as encapsulation and tunnelling, wherein data packets are equipped with GPRS-specific protocol information and transferred between the mobile station and the GGSN. This transparent transfer method lessens the requirement for the GPRS network to interpret external data protocols, and enables easy introduction of additional interworking protocols in the future. GPRS supports interworking with networks based on the Internet protocol (IP) which is defined in the specification RFC 791.
The GPRS Tunnelling Protocol (GTP) defines the way data packets are passed between various GPRS support nodes (GSNs). When an SGSN and a GGSN establish a communication tunnel for user data packets between each other, they both create a data structure, i.e. a PDP (Packet Data Protocol) context, which contains information about e.g. usage time and user address and the like. The structure is associated to a single communication tunnel with a four-octet identifier. This identifier is then sent to the other GSN at the other end of the tunnel, which will then add that identifier to every data packet related to the tunnel. A Tunnel Endpoint Identifier (TEID) allows for a quick look up of the correct PDP context. Typically, the identifier notifies the position of the PDP context in a preallocated table of PDP context structures.
The PDP context look-up must be very quick. The quickest possible way to associate a structure to a four-octet identifier is to adapt the identifier to the structure's position in a table. In its initialisation phase, the application allocates a PDP context table of maximum number of simultaneous PDP contexts. Then, a so-called “free slot list”, i.e. a linked list of free PDP context locations, is provided, which initially contains all slots or PDP context locations in the table. When a tunnel is created, an identifier is popped from the beginning of the list. When a tunnel is destroyed, the associated identifier is pushed to the end of the list. Thus, the free slot list will roll over after some time, such that identifiers associated to an old connection destroyed earlier are allocated to a new connection. This might lead to the problem that some late data packets associated to a destroyed connection are routed to a new completely different connection, because the new tunnel endpoint of the new connection has been given the same identifier as the previous old connection. Thus, data packets may be routed to wrong users.
Furthermore, in case of a connection to an external network, one or more network layer addresses, i.e. PDP addresses, are temporarily and/or permanently allocated to a GPRS subscriber or user. These PDP addresses conform to the standard addressing scheme of the respective network layer service used, e.g. IP version 4 (IPv4), IP version 6 (JPv6) and X.121. The PDP contexts are activated and deactivated through mobility management procedures. When dynamic addressing is used, it is the responsibility of the GGSN to allocate and release the dynamic PDP address.
The need for IPv6 addresses in mobile phones is getting more and more important. IPv6 defines that the nearest router to which a node is connected provides an address to the node. The address has to be globally unique. It is the responsibility of the router to make sure that the address is unique. In particular, the IPv6 address consists of a pre-configured prefix and a suffix that is generated on the fly. The prefix guarantees uniqueness as a subnet. The suffix has to be unique within that subnet.
A unique IPv6 address can be calculated from a globally unique parameter which is associated with the mobile user, e.g. the telephone number, IMSI (International Mobile Subscriber Identity) or the like. However, such schemes reveal the user's identity to the access network, which is in many cases considered to be an attack on privacy. Therefore, non-identifying dynamic addresses are preferred. Since dynamic addresses cannot use a globally unique source, uniqueness must be guaranteed in another way. If a context is activated using the address of a previous context, immediately after it has been deactivated, the new context could receive messages that were intended for the old one, as already described in connection with the GTP protocol. There can be many such messages, e.g. since the corresponding hosts of a previous context may still be sending status requests and keep-alive messages. Then, the recipient would have to pay for receiving these bandwidth wasting datagrams, even though they are unsolicited, which causes problems with fair billing. The problem can be even more severe due to the fire-wall between the users and the Internet. A fire wall with “stateful inspection” checks the data traffic in both directions, and maintains an internal state which depends on use patterns and which influences the filtering decisions. This may cause problems for a new user, since the internal state is inherited from the old one. The same problem is evident in case there is any other kind of intelligence along the route, e.g. different qualities of service may be supported.
The above problems associated with the early reuse of a user identification, e.g. tunnel identifier or PDP address, can be alleviated by introducing a sufficient delay between deactivating a user identification and reactivating it for another user. This can be achieved by putting the user identifications on a pool that circulates, so that a deactivated identification will not be activated before the other identifications in the pool have been used. However, in the case of IPv6, a large number of addresses would have to be stored, possibly millions for a transparent Internet access point (AP). Thus, a large memory would be required. Moreover, the delay time may be inadequate for highly dynamic environments.
Alternatively, a delay counter may be allocated to each user identification, which prevents an early activation. However, this adds complexity to the address manager, because each address counter has to be updated and driven by a real time clock. One counter is required for each possible identification, such that the counter array requires almost as much memory as the address pool.
USPTO Backgrounds
USPTO Backgrounds