HK1079385B - Method and apparatus for address acquiring - Google Patents

Description

Address acquisition method and equipment

The present application is a divisional application of an invention patent application having an application date of 2001, 1/15, an application number of 01806871.5, and an invention name of "address acquisition".

Technical Field

The invention relates to address acquisition. It relates particularly, but not exclusively, to address acquisition of mobile terminals in a mobile system. In one embodiment, it relates to the acquisition of internet addresses in a General Packet Radio Service (GPRS) system.

Background

The communication protocol currently used in the internet is called IPv4 (internet protocol version 4). In order for a node to be functionally interconnected with the internet, it requires an address. The address used in I Pv4 is 32 bits. The address may be specified by a server. Some nodes may have static addresses stored in the node and thus they do not need to be assigned an address by a server. Alternatively, some IPv4 nodes may use a protocol called DHCP (dynamic host configuration protocol), in which a DHCP server specifies a predetermined IP protocol.

When an IPv4 node acquires its connection via a point-to-point communication channel, it typically uses PPPv4(PPP version 4). PPPv4 has been standardized to work with 32-bit addresses, so IPv4 and PPPv4 are compatible and addresses can be negotiated between the two.

The number of addresses provided by IPv4, i.e. the number of addresses provided by 32 bits, is limited and another internet protocol IPv6 (internet protocol version 6) has been proposed. This protocol has 128-bit addresses and thus provides a much larger number of addresses than IPv 4. An IPv6 address typically includes a 64-bit network prefix (or subnet prefix) followed by a 64-bit interface identifier.

A point-to-point protocol, PPPv6, has been set to work with IPv 6. PPPv6 can operate at 64-bit addresses. In one arrangement, an IPv6 node uses PPPv6 to obtain an interface identifier, constructs a local link address based on the interface identifier and then uses the local link address to determine its global IPv6 address by sending a router solicitation and receiving a router advertisement. The router advertisement provides the subnet prefix needed to implement a global IPv6 address.

The PPPv6 and IPv6CP protocols are described in IETF RFC 24721998, month 12, "IP version 6 over PPP" ("IP version 6 over PPP", IETF RFC 2472 December 1998). The IPv6 address architecture, and in particular the local link address, is described in IETF RFC 23731998, 7 month "IP version 6 addressing architecture" ("IP version 6 addressing architecture", IETF RFC 2373, July 1998).

Two types of address autoconfiguration are supported in IPv 6: stateless and stateful. These are described below.

In stateless address auto-configuration, a unique interface identifier is generated or selected for a node, either as a random 64-bit number or as a function of some static parameter like the interface hardware address. The node then performs a neighbor discovery procedure called "duplicate detection". This is to ensure that no other node in the same subnet is using the same 64-bit interface identifier. The first step in duplicate detection is to send a multicast packet (confined within the subnet) to the multicast destination address as a function of an interface identifier. The address is multicast to see if it can elicit a response. If another node owns the interface identifier, it will respond. In this case, another interface identifier is chosen and the procedure is repeated until a unique interface identifier is chosen. If the interface identifier is unique to the subnet, then no node with an identical interface identifier will respond, after which it can obtain a subnet prefix to construct a complete IPv6 address. The subnet prefix is advertised by the router as part of a router advertisement or in response to a router solicitation. According to "IPv 6 Stateless address autoconfiguration", IETF RFC 2462 December1998, month 12, I ETF RFC 24621998, if duplicate detection is desired to be avoided, a control variable at the node dupadddrdefecttransmits is set to zero during the address specification process, so that duplicate detection does not occur.

In stateful automatic configuration, a node requests its address from a DHCP server. Because the DHCP server maintains a record of the assigned addresses, it can assign unique addresses. Therefore, duplicate detection is not absolutely required, although it may be present.

Mobile communication systems have been developed to reach users even when they are not close to a fixed telephone terminal. With the growing use of a variety of data transmission services in offices, different data services are also introduced into mobile communication systems. Portable computers enable efficient data processing by a user wherever the user moves. The mobile communication network in turn provides the user with an efficient access network to the actual data network for the transmission of mobile data. Mobile data transmission is particularly well supported by digital mobile communication systems, such as the pan-european mobile communication system GSM (global system for mobile communications).

It is increasingly desirable for mobile terminals to be able to use the internet. The General Packet Radio Service (GPRS) has been proposed for providing IP connections to mobile users.

GPRS is a new service in the GSM system and is one of the targets of GSM phase 2+ standardization work in ETSI (european telecommunications standards institute). A GPRS network architecture is shown in figure-1. The GPRS operational environment comprises one or more sub-network service areas interconnected by a GPRS backbone network. A sub-network comprises a number of packet data service nodes SN, in this application called serving GPRS support nodes SGSN, each of which is connected to a GSM mobile communication network (typically with a base station system) in such a way that: it is capable of providing packet services, that is, cells, to mobile data terminals via several base stations. The intermediate mobile communication network provides packet-switched data transmission between the support node and the mobile data terminal. The different subnetworks are in turn connected to an external data network, for example to a public switched data network PSPDN, via GPRS gateway support nodes GGSN. The GPRS service thus provides packet data transmission between the mobile data terminal and an external data network, while the GSM network acts as an access network.

In GPRS systems, layered protocol structures, known as a transport level and a signaling level, have been defined for transporting user information and signaling. A transmission stage has a layered protocol structure providing for the transmission of user information together with associated control procedures for data transmission (e.g. flow control, error detection, error correction and error recovery). One signaling level includes protocols for controlling and supporting transport level functions, such as controlling access (connection and disconnection) to the GPRS network and controlling the routing path of established network connections to support user mobility. Figure-2 illustrates the signalling level of the GPRS system between a mobile data terminal MS and an SGSN. The protocol layers of the transport level are the same as those of figure 2 up to the protocol layer SNDCP, above which there is a GPRS backbone network protocol (e.g. internet protocol IP) between the MS and the GGSN (instead of the protocol L3 MM). The protocol layers illustrated in fig. 2 are:

layer 3 mobility management (L3MM) supports mobility management functions such as GPRS attach, GPRS detach, security, route update, location update, activation of a PDP context (each numbered with a network layer service access point identifier (NSAPI)), and deactivation of a PDP context.

-the subnet dependent convergence protocol (SNDCP) supports the transmission of one network layer protocol data unit (N-PDU) between the MS and the SGSN. The SNDCP layer, for example, manages the ciphering and compression of N-PDUs.

The Logical Link Control (LLC) layer provides a reliable logical link. The LLC is independent of the radio interface protocols mentioned below.

-an LLC relay; this function forwards LLC Protocol Data Units (PDUs) between one MS-BSS interface (Um) and one BSS-SGSN interface (Gb).

Base station subsystem GPRS protocol (BSSSGP): this layer carries routing information and QoS related information between a BSS and an SGSS.

Frame relay, used on the Gb interface. A semi-permanent connection is established between the SGSN and BSS for multiplexing of LLC PDUs for several users.

Radio Link Control (RLC): this layer provides a reliable link independent of the radio solution.

-Medium Access Control (MAC): this layer controls access signaling (request and grant) associated with a radio channel and controls the mapping of LLC frames into a physical GSM channel.

The function of the LLC layer can be described as follows: the LLC layer acts above the RLC layer in the reference architecture and establishes a logical link between the MS and its serving SGSN. Regarding the functionality of LCCs, the most important requirements are a reliable management of LCC frame relay and support for point-to-point and point-to-multipoint addressing.

A Service Access Point (SAP) of the logical link layer is a point where the LLC layer provides services to a layer 3 protocol (shown in the SNDCP layer of fig. 2). The link of the LLC layer is identified by a Data Link Connection Identifier (DLCI), which is conveyed in an address field in each LLC frame. The DLCI includes two elements: a Service Access Point Identifier (SAPI) and a Terminal Endpoint Identifier (TEI). The TEI identifies a GPRS subscriber and is typically a temporary logical link identity TLLI. The TEI can also be the identity of another subscriber, for example an international mobile subscriber identity IMSI, but typically avoids transmission of the IMSI over the radio path. When a subscriber is connected to a GPRS network, a logical link is established between the MS and the SGSN. So that the MS can be said to have a call in progress. This logical link has a route between the MS and the SGSN, indicated by the TLLI identifier. Thus the TLLI is a temporary identifier where the SGSN allocates a logical link and IMSI. The SGSN sends the TLLI to the MS in connection with the establishment of a logical link, which TLLI is used as an identifier in the subsequent transmission of signalling and data via this logical link.

The data transmission via one logical link is implemented as explained below. Data from or to be transmitted to the MS is processed with an SNDCP function and transmitted to the LLC layer. The LLC layer inserts data into the information field of the LLC frame. The address field of a frame comprises, for example, a TLLI. The LLC layer forwards the data to the RLC, which deletes unnecessary information and segments the data into a form compatible with the MAC. The MAC layer activates a radio resource procedure to obtain a radio traffic path for transmission. A corresponding MAC unit on the other side of the radio traffic path receives the data and forwards it up to the LLC layer. Finally, the data is sent from the LLC layer to the SNDCP, where the user data is fully recovered and forwarded to the next protocol layer.

The GPRS system has been proposed based on IPv 4. Such a system is typically based on Mobile Stations (MS), each of which comprises user Terminal Equipment (TE) and a Mobile Terminal (MT). The TE typically comprises a PPP client and communicates with a PPP server in the MT via PPPv 4. To enable the TE to be functionally connected to the internet, the PPP client typically requests an IPv4 address from the PPP server. Upon receiving this request, the MT initiates a GPRS "activate PDP context" request without specifying a PDP address (this would be preceded by a GPRS attach request if required). This causes the SGSN to send a "create PDP context" request to a GGSN, which still carries an empty PDP address field. The GGSN selects an IPv4 address as the PDP address and returns it to the SGSN in a "create PDP context response" message, which sends it to the MT in an "activate PDP context accept". The PPP server then sends this IPv4 address to the TE in a PPP configuration confirm message.

GPRS systems supporting IPv6 have also been proposed. The protocol stack relating to such a system is shown in figure-3. As with the arrangement in IPv4, a GPRS mobile station typically comprises user Terminal Equipment (TE) and a Mobile Terminal (MT). In the case of providing an IPv6 connection for a GPRS mobile station, the goal is to negotiate an IPv6 128-bit address between the TE and the GGSN. It should be noted that the TE may be a standard computer running a standard PC operating system. Likewise, it may not be. TE and MT communicate using a point-to-point protocol such as PPPv 6. The address acquisition procedure is initiated when a PPP client running in the TE initiates PPP establishment with a PPP server running on the MT. An address negotiated between the PPP client and the PPP user is transferred to the GGSN/SGSN.

As mentioned above, in the case of IPv6, address negotiation involves duplicate detection to be implemented. So, for GPRS, this involves sending multicast packets over the radio interface. Although this is not a problem in conventional wired networks, multicast over the radio interface is undesirable in the case of GPRS and other wireless systems.

Although it has been proposed in conventional IPv6 wireline networks to set the dupadddriecttransmit variable to zero in order to avoid the occurrence of duplicate detections (see above), the GPRS system does not necessarily control TE, so it cannot be guaranteed that this is a usable option.

In addition to duplicate detection, other neighbor discovery procedures based on multicast packets may also occur. Or the GGSN or TE IPv6 stack may send the neighbor discovery message in context rather than in duplicate detection, e.g., trying to find the layer 2 (L2) address of another node in the same subnet to send a packet to it.

Disclosure of Invention

According to a first aspect of the present invention there is provided a method of acquiring a network address within a communications network, the method comprising the steps of:

establishing an entity comprising information relating to a network address within a sub-network;

creating a link between the first node and the second node, the link having a link identifier that is unique within the subnet;

determining a network address for the first node based on the link identifier;

verifying, by the entity, whether the determined network address is unique; and

accepting the network address if the determined network address is unique.

Preferably, the link identifier is generated statically based on information identifying one of the nodes. Alternatively, it may be randomly generated by one of the nodes.

Preferably, the network address is derived from the link identifier and a network prefix. Preferably, the network prefix is obtained by a router advertisement automatically sent between the first and second nodes. Alternatively, the network prefix may be obtained by a router solicitation sent between the first and second nodes. The router solicitation may be sent to a local link address. Preferably there are multiple network prefixes. Preferably multiple network addresses are created for one or more nodes.

Preferably the first node is a mobile station. Preferably the second node is a gateway. It may be a GGSN. The entity may comprise one or both of the first and second nodes.

Preferably, the information included by the entity about the network address may be a list of link identifiers or network addresses within a subnet. In such an embodiment, the entity may comprise a gateway, such as a GGSN. In this case, the list may be contained within the gateway or may be accessible by the gateway. The list may include link identifiers that have been previously assigned to the node or may include link identifiers that are unique and have not been previously assigned. In another embodiment, the entity is a mobile station. In this case, the information on the network address may be: the mobile station has an identifier that can be used to create a unique network address. This information may indicate (implicitly) that other mobile stations have different identifiers that may be used to create different network addresses.

In an embodiment of the invention, wherein the entity is a gateway, the checking of uniqueness may be performed by the gateway by referring to or selecting from a list of previously assigned link identifiers or a list of network addresses or a list of link identifiers. Preferably the uniqueness check can be performed by the gateway by referring to a routing table. Alternatively, the gateway may reference a neighboring cache. Preferably the routing table or the neighboring cache is incorporated in the gateway. In another embodiment, the uniqueness check may be performed by the gateway by referring to or selecting from a list of predetermined network addresses that have not yet been assigned. Alternatively, if the entity is a mobile terminal, the verification of uniqueness may be performed by the mobile terminal by referring to information about the network address it contains and determining that it has a link identifier that can be used to create a unique network address.

Preferably the link identifier is transmitted from a sender to a receiver between the first and second nodes.

The receiver may not verify the uniqueness of the transmitted link identifier but instead generate a different link identifier, which is verified for uniqueness. If the link identifier is not unique, the receiver may select a unique interface identifier itself and send it to the sender.

Preferably the link is a dedicated path connecting the first node and the second node. The link may exclusively connect the first node and the second node. The link may be a context such as a PDP context.

Preferably the communication network comprises a plurality of sub-networks.

Preferably the communication network is a GPRS system. The communication network may be IPv6 based. In this case, the network address is an IPv6 address.

According to a second aspect of the present invention, there is provided a communications network comprising:

a subnet;

a first node and a second node;

an entity comprising information relating to a network address within the sub-network, said entity being capable of creating a link between a first node and a second node, the link having a link identifier unique within the sub-network, and said entity being capable of determining a network address for the first node based on said link identifier;

wherein the entity is capable of verifying whether the determined network address is unique and accepting the network address if the determined network address is unique.

According to a third aspect of the present invention there is provided a mobile terminal for operation with the communications network of the second aspect of the present invention.

According to a fourth aspect of the present invention, there is provided a computer program product comprising a computer readable medium having thereon:

computer executable code means to establish an entity comprising information relating to a network address within a subnet;

computer executable code means to create a link between the first node and the second node, the link having a link identifier unique within the sub-network;

computer executable code means for determining a network address for the first node based on said link identifier;

computer executable code means to enable the entity to verify whether the determined network address is unique; and

computer executable code means to accept the network address if the determined network address is unique.

According to a fifth aspect of the present invention there is provided a method of acquiring an IP network address at a node in a GPRS system, the method comprising the steps of:

the node sending a network address request to a gateway via a wireless link requesting a unique interface identifier;

the gateway receiving the request and determining a unique interface identifier;

the gateway confirming to the node that the interface identifier is unique;

the node adopts the interface identifier;

the gateway sends a network prefix to the node; and is

The node combines the interface identifier and the network prefix to generate an IP network address.

Preferably the node generates an interface identifier and sends it in a network address request. Preferably the gateway checks whether the transmitted interface identifier is unique.

According to a sixth aspect of the present invention there is provided a method of acquiring an IP network address at a node in a GPRS system, the method comprising the steps of:

the node sending a network address request to a gateway via a wireless link requesting a unique interface identifier;

the gateway receiving the request;

the gateway sending a response to the node;

the node creates its own interface identifier;

the gateway sends a network prefix to the node; and is

The node combines the interface identifier and the network prefix to generate an IP network address.

Preferably the node selects an interface identifier and sends it to the gateway together with a network address request. Alternatively, the node does not select an interface identifier and sends a network address without such an identifier. The response to the network address request sent by the gateway preferably does not include an interface identifier. The lack of an identifier may indicate to the node that it should select its own interface identifier. The node may send the interface identifier it created to the gateway to let the gateway determine if it is unique.

Preferably the network address request is a context activation request. Preferably the interface identifier is a PDP context. Preferably the interface identifier identifies the communication link of the node. It may identify a terminal device, such as a computer, connected to a mobile terminal. The end device may be at the end of a PPPv6 connection.

Preferably the method involves negotiation between the node and a PPP server. The PPP server may be located in a mobile terminal. The node and the mobile terminal may be separate units linked together. Alternatively they may comprise one integrated unit.

Preferably the gateway acts as a proxy and intercepts requests for unique interface identifiers or any other neighbor requests and then checks whether the interface identifier is unique by referring to a routing table or neighboring cache it maintains. As a result, the transmission of multicast packets can be avoided.

According to a seventh aspect of the present invention there is provided a communications system operating in accordance with the method of the first, fifth or sixth aspects of the present invention, comprising a communications network in which the computer program according to the second aspect of the present invention or according to the fourth aspect of the present invention operates.

Preferably it is a system implementing the context (tunnel) concept. It may be a GPRS system. It may be a third generation system such as UMTS or CDMA.

According to an eighth aspect of the present invention there is provided a mobile terminal operating in accordance with the method of the first, second or third aspects of the present invention.

Preferably the mobile terminal is a GPRS mobile terminal. It can be used in a third generation system such as UMTS or CDMA.

According to a ninth aspect of the present invention there is provided a method of acquiring an IP network address at a node in a cellular telephone system, the method comprising the steps of:

said node sending a context request message to a gateway via a wireless link, said message containing information on which a unique interface identifier is to be based;

the gateway receiving the context request message and determining a unique interface identifier;

the gateway sends a context accept message containing at least one network prefix to the node;

the node adopts the interface identifier; and is

The node combines the interface identifier and the network prefix to generate an IP network address.

Drawings

The invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

figure-1 shows a GPRS system;

FIG. 2 illustrates the protocol stacks involved in the system of FIG. 1;

FIG. 3 illustrates another set of protocol stacks;

FIG. 4 illustrates an address acquisition method;

FIG. 5 illustrates another address retrieval method;

FIG. 6 illustrates a flow chart for showing the operation of the method of FIGS. 4 and 5;

FIG. 7 illustrates an address retrieval method according to another embodiment of the present invention; and

fig. 8 shows a mobile terminal.

Detailed Description

Fig. 1 to 3 have been described above.

The invention relates to the acquisition of an address of a node located in a subnet in a communication system operating according to IPv 6.

A protocol according to the present invention will now be described. A mobile station requests an IPv6 address. The mobile station either obtains a PDP address (interface identifier) from the statically configured information or generates it randomly. There are several possible sources of such statically configured information. It may be the IEEE EUI-64 identifier of its hardware interface (as specified in IETF RFC 6 addressing architecture, IETF RFC 2373, July 1998) as "IP Version 6 addressing architecture" in 7 months of 23731998) or the GPRS Tunneling Protocol (GTP) Tunnel ID (TID) based on static information within the mobile station. Alternatively, the interface identifier may be obtained from a combination of a NSAPI relating to the PDP context and a unique identifier of the mobile station, such as an International Mobile Subscriber Identity (IMSI), Mobile Station Integrated Services Digital Network (MSISDN) number or international mobile station equipment identity (IMEI). By combining NSAPI with a unique identifier of the mobile station, this means that a mobile station can have a plurality of different interface identifiers. If the interface identifier is chosen deterministically from static information already known to the mobile station and GGSN, this information does not have to be transferred during the address acquisition phase.

A randomly selected interface identifier is preferred because interface identifiers that are deterministically derived from static information can result in IPv6 addresses being linkable. This results in a loss of privacy since the source I Pv6 address used by a mobile station is visible to all its correspondents and all routers in the way it is communicating. While high privacy is not a concern for many mobile users, it may be desirable in certain circumstances. Thus, a randomly generated interface identifier may be obtained by using a standard access point name, while a deterministically derived interface identifier may be obtained by using a particular access point name as a default mode of operation. This will be described below.

Once the mobile station obtains its interface identifier, it sends an activate PDP context request to an SGSN. If the interface identifier is chosen deterministically, the PDP address field is empty and a specific access point name is used to identify the access type the user is looking for, in which case it is used to inform the GGSN how the interface identifier should be obtained. Also, using a specific access point name means that it does not have to transmit the interface identifier in a protocol message.

Depending on how the interface identifier is generated, an activate PDP context request is sent to an SGSN, the request containing either the interface identifier or a specific access point name indicating how the interface identifier can be obtained. The SGSN then sends a create PDP context request to the GGSN. At the GGSN, the PDP address is either received or generated and then it is checked against a list of already assigned addresses stored within the GGSN. If it has not already been assigned, it is assigned to that mobile station in the GGSN. It should be noted that since the interface identifier is checked in the GGSN, it is not necessary to send it to other mobile stations to check whether it is a unique address or whether an identical address exists. The GGSN responds to the PDP context request by sending a create PDP context response to the SGSN including the PDP address. The create PDP context response is received by the SGSN and is then sent to the mobile station as an activate PDP context accept including the PDP address. The mobile station receives the PDP address and adopts it as its own interface identifier. The mobile terminal then receives a router advertisement from the GGSN that includes a network prefix configured in the GGSN. The mobile station then combines the PDP address and the network prefix to generate an IPv6 address. The GGSN creates a record of the IPv6 address of the mobile station in a corresponding manner and includes an entry in its routing table indicating the correspondence between this address and the PDP context so that the message can be sent to the correct mobile station. The router advertisement is either sent periodically by the GGSN or in response to a specific request by the mobile station.

Before sending the PDP address to the GGSN, the SGSN may check it against a Home Location Register (HLR) compliant with UMTS 23.060. The reason for this is to verify that the PDP address requested by the mobile station is indeed allowed for that mobile station. However, since the present invention has a separate check for the uniqueness of the PDP address, it is not necessary to perform such a cross check with the HLR.

A method according to the invention using a mobile station arranged on the basis of the protocol stack shown in fig. 3 will now be described in more detail with reference to fig. 4.

Figure 4 depicts a specific protocol for address acquisition involving a mobile station comprising a mobile terminal MT and terminal equipment TE. figure 4 shows commands passed between TE, MT, SGSN and GGSN. The GGSN acts as a router for an IPv6 subnet, where it connects two or more subnets and forwards packets originating from one subnet to another subnet. A subnet is a group of nodes that have a direct physical link. The same GGSN may act as a router for the individual subnets. The mobile station is assigned an address belonging to this subnet.

The protocol will now be described with reference to fig. 3 and 4.

Step 1

The TE initiates an IPv6CP configuration request message with an interface identifier option. The interface identifier option contains a 64-bit tentative interface identifier selected by the TE. In this case, the interface identifier is determined randomly. However, it may be statically determined as mentioned above, in which case a specific access point name will be used.

Step 2

In this step the protocol is a PDP context activation in GPRS. The MT constructs a home link address by appending the interface identifier sent by the TE to the home link prefix (FE 80::/64). Although the local link address is similar to any other IPv6 address, it can only be used in one link, i.e., within one subnet. The MT sends an "activate PDP context request" to the SGSN with this home link address in the PDP address field to activate a new PDP context in the GGSN. The SGSN forwards the local link identifier to the GGSN in a "create PDP context request".

Step 3

The GGSN checks whether the home link address is unique for that subnet. To do this, the GGSN checks to see if this home link address is already present in the PDP context list stored in the HLR. If the GGSN determines that the home link address is unique, the GGSN creates a GTP tunnel and a PDP context corresponding to this home link address. Tunneling is the method of transporting one type of packet to another, such as an IPv6 packet within a GTP packet. GPRS defines a single protocol (GTP) such that any type of data packet protocol can be transported over the same physical backbone network. The GGSN decides which IPv6 subnet the mobile station will be assigned to. Of course, if the GGSN manages only one ip v6 subnet, then the mobile station will be assigned to this subnet. The GGSN also constructs all possible IPv6 addresses for the mobile station by combining the respective network prefixes of the selected subnets with the mobile station interface identifier extracted from the mobile station's local link address. There may be multiple prefixes. Each prefix indicates a route to the subnet for a packet sent by an external communication party. A subnet may have multiple prefixes, so that nodes in that subnet have multiple ways of being addressed, each way corresponding to a different route.

The GGSN makes appropriate local modifications, for example in its routing table, so that any packet passing through itself and entering the sub-network and destined for a particular node will be directed to the correct GTP tunnel. The GGSN then sends a positive "create PDP context response" to the SGSN, which forwards it to the MT in an "activate PDP context accept" message.

In GPRS, all mobile nodes connected to the same GGSN can be placed in the same subnet. Repeated detection is very expensive. However, according to the present invention, the GGSN is used to ensure that there is no duplication, since the GGSN involves all address assignments. Thus, in case of a duplicate, subnet multicasting is avoided by acting as a proxy by the GGSN, intercepting the duplicate detection requests and replying to them. The GGSN can also intercept other kinds of neighbor solicitations.

Although PPPv6RFC suggests that a PPP client need not perform duplicate address detection, this is not mandatory. The present invention relates to a case where one node attempts duplicate detection. In any case, the present invention also addresses these issues, as nodes may attempt to achieve neighbor discovery. In one embodiment, the GGSN plays a proxy role for neighbor discovery messages by intercepting all neighbor discovery messages with a destination address that conforms to the multicast prefix FF02::1: FF00:0000/104 of the requesting node according to IETF RFC 2373 "IP version 6 addressing architecture", checking if there is already an activated PDP context with the destination address in the message, and sending an appropriate reply. In another embodiment, the GGSN intercepts the neighbor discovery messages and sends them using unicast only to the intended recipient rather than to the entire subnet.

Whether the GGSN IPv6 stack attempts to perform neighbor discovery for a mobile node depends on how it routes packets into the GTP tunnel. In the present invention, two alternatives are proposed. In a first embodiment, each GTP tunnel has a separate entry in the routing table with a corresponding complete IPv6 address entry. The GGSN IPv6 stack does not attempt neighbor discovery for a mobile node when there is an incoming packet destined for the mobile node, because the GGSN can refer to its routing table to determine whether such a node exists. In a second embodiment, the routing table does not contain this information, so the forward transport code checks its neighboring caches in the IPv6 stack to see if an entry for the destination address already exists. If no such entry exists, the IPv6 stack implements neighbor discovery. In the present invention, neighbor discovery messages initiated by the GGSN over the radio interface are preferably blocked by inserting entries in the neighbor cache whenever a PDP context is activated, and deleting these entries when the context is deactivated. These entries are provided with a lifetime long enough so that they do not time out while the PDP context is still active.

Step 4

The MT replies with an IPV6CP configuration-acknowledge with an interface identifier option containing the same 64-bit identifier as in step 1.

Step 5

The TE generates a local link address from this interface identifier and assigns it to the interface. It then sends an IPv6 router solicitation message via this interface. In another embodiment, the router advertisement is automatically sent immediately after the PDP context is created.

Step 6

The GGSN replies with an IPv6 router advertisement message that lists all of its network prefixes for the selected subnet. The TE composes its IPv6 address by appending the interface identifier to these network prefixes and assigns the resulting address to the same interface.

If the GGSN determines that the home link address is not unique, it rejects the "Create PDP context request". In this case, the MT resends the "activate PDP context request" with an empty PDP address field. The GGSN now selects an IPv6 address and returns it with a "create PDP context response". This causes the MT to reply with an IPV6CP configuration-not-acknowledge in step 4 with an interface identifier option containing a 64-bit identifier extracted from the address selected by the GGSN. The TE then resends an IPV6CP configuration request message with this 64-bit identifier that can be accepted locally by the PPPv6 server on the MT without involving the GGGSN.

If the interface identifier is statically determined, then the MT may use this information to send the correct PPPv6 response to the TE. The GGSN can make local setup changes using the same information (so that incoming packets are correctly routed to the TE).

Existing protocol variants will now be described. In these variants, many of the features of the aforementioned protocol remain the same, such as the way in which the GGSN handles the local link address and changes its routing table or changes its neighbor cache (described in step 3).

In a first variant, the mobile station generates a PDP address (interface identifier) and it is sent to the SGSN in an activate PDP context request in one of the ways described above. However, in this variant, the GGSN has a local policy that the interface identifier must be selected by that GGSN. This is because a particular GGSN may be operated by a different operator. The GGSN does not use a PDP address generated by the mobile station and therefore when the GGSN receives such a PDP address it generates a replacement PDP address. In this way the GGSN can easily verify that the replacement PDP address it self-generates is unique. In fact, this may be the basis for the selection by the GGSN of the replacement PDP address. Therefore, this replacement PDP address is assigned to that mobile station in the GGSN. The GGSN responds to the PDP context request by sending a create PDP context response to the SGSN including the replacement PDP address. The create PDP context response is received by the SGSN and is then sent to the mobile station as an activate PDP context accept including the replacement PDP address. The mobile station receives the replacement PDP address and adopts it as its own interface identifier. The mobile terminal then receives a router advertisement from the GGSN as described above and creates an IPv6 address.

In an embodiment of the invention, in which the first variant is used with the arrangement in fig. 3, the address acquisition protocol described above in relation to fig. 4 is modified. The resulting protocol is thus described with reference to fig. 5.

In a second variant, the mobile station does not generate a PDP address (interface identifier), but only sends an activate PDP context request to an SGSN without a PDP address. The SGSN then sends a create PDP context request to a GGSN. At the GGSN, no PDP address is received, so the GGSN can easily generate a unique PDP address and assign it to that mobile station in the GGSN. Since the activate PDP context request does not contain a PDP address, a check against an HLR is not required. The GGSN responds to the PDP context request by sending a create PDP context response to the SGSN that includes the unique PDP address. The create PDP context response is received by the SGSN and is then sent to the mobile station as an activate PDP context accept containing the unique PDP address. The mobile station receives the PDP address and adopts it as its home link address. The mobile terminal then receives a router advertisement from the GGSN and generates an IPv6 address as described above.

The third variant is similar to the second variant in that the mobile station does not initially generate a PDP address (interface identifier), so it sends an "empty" activate PDP context request. However, rather than the GGSN generating a unique PDP address, the GGSN does not respond to an "empty" PDP context request by simply sending an "empty" Create PDP context response. An "empty" create PDP context response is received by the SGSN and is then sent to the mobile station as an "empty" activate PDP context accept. The mobile station receives the "empty" activate PDP context accept and generates its own PDP address (interface identifier) by one of the two methods described above. The interface identifier may then be checked for uniqueness. Assuming that the interface identifier is unique, the mobile station uses this PDP address as its interface identifier. The mobile station then receives a router advertisement from the GGSN and generates an IPv6 address as described above.

The foregoing embodiments and variations are stateless address autoconfiguration in which a portion of the mobile station generates its own address, that is, an interface identifier. However, in an embodiment of a mobile station that includes an MT and a TE, even though the TE may generate an interface identifier and send it to the MT, the MT may discard the interface identifier because the MT knows that the identifier should not be sent. In fact, in such an embodiment, the TE's IPv6 stack (or in other embodiments whichever part selects the interface identifier) believes it has selected the interface identifier.

The process runs differently if the system has an address autoconfiguration with a country. In this case, the TE does not have to know initially that this is the case, since the auto-configuration is controlled at the GGSN. The GGSN does not ensure the PDP address ID when it receives the Create PDP context request_MIs unique because of the real PDP address ID_MWill be selected later as a result of a DHCP request. The GGSN sends a Create PDP context response back to the SSGN, which sends an Activate PDP context accept to the MT. The MT sends an IPv6CP configuration confirmation to the TE. At this point, the TE does not know that a DHCP request is needed, so it will FE80:: ID_MAssigned to an interface. As with the earlier procedure, the TE then sends an IPv6 router solicitation to the GGSN. The GGSN responds to the TE local link address by sending back an IPv6 router advertisement. However, the router advertisement has the M flag field set to indicate to the TE that it needs to obtain its address from a DHCP server. Therefore, the TE sends a DHCP request to the GGSN via IPv6 and the DHCP server constitutes a full IPv6 address or as many IPv6 addresses as needed, and the GGSN modifies its routing configuration. The IPv6 address is sent to the mobile station (DHCP over IPv 6).

It should be noted that in this embodiment the DHCP server is part of the GGSN. In this case the DHCP server is controlled such that when there is a request for a PDP context address, the DHCP server generates a full IPv6 address or full IPv6 addresses and then modifies its routing table such that the selected full IPv6 address or addresses are mapped onto the corresponding GTP tunnel. Alternatively, the GGSN controls and modifies its neighbor cache.

Although neighbor discovery is not absolutely necessary in the case of using one DHCP server, it may be preferable to include it because the TE may be connected to the GPRS system and may send a request for neighbor discovery.

The processes of fig. 4 and 5 are shown in flow chart form in fig. 6.

In another embodiment of the invention, certain "router" functions may be implemented within the Mobile Terminal (MT). This embodiment reduces the number of signals or commands over the wireless interface so that there is only one two-way handshake. One method according to this implementation of the invention is shown in fig. 7.

As in the previous embodiment, a globally unique interface identifier is formed from one of the three unique numbers IMEI, IMSI or MSISDN and NSAPI.

The interface identifier will be sent over the wireless interface and since MSISDNs are generally well known, it is preferred to use it. IMEI and IMSI are generally not well known outside the GPRS system. An additional advantage of using the MSISDN is that the GGSN can convert it to a GTP TID (which is a combination of IMSI and NSAPI) without additional signaling. The GGSN knows the IMSI and MSISDN from other signals but does not know the IMEI. SSGN knows all three.

The interface identifier will be sent over the wireless interface and since MSISDNs are generally well known, it is preferred to use it. The IMEI and IMSI are generally not well known. An additional advantage of using the MSISDN is that the combination of MSISDN and NSAPI is already used as GTP TID within the GGSN and therefore it is available to the SGSN and no additional signaling is required by the GGSN. The GGSN knows the MSISDN but not the IMEI from other signals. SSGN knows the MSISDN and IMEI.

The MSISDN is a 15 digit decimal number. The interface identifier may be encoded with 64 bits such as: 0.. 1:00 (for future use), 2.. 5: NSAPI, 6.. 7:10 ("globally unique" "-single node" address), 8.. 9:00 (for future use), 10.63: MSISDN (in binary format). Bits 6 and 7 are "special" bits that are used to indicate whether the address is globally unique (bit 6 ═ 1) and whether it belongs to a single node (bit 7 ═ 0). This encoding scheme provides space for future longer MSISDN and NSAPI fields. It should be noted that the PPP client in the TE does not need to perform duplicate address detection, since this "globally unique" bit 6 indicates that this is not necessary.

Referring now specifically to fig. 7, PPP address negotiation only takes place between the TE and the MT, so messages relating to this event need not be sent out over the wireless interface. The messages sent over the radio interface are for context activation, that is the creation of a PDP context and the PDP context acceptance. The MS ISDN and NSAPI information may be sent in the create PDP context message. The network prefix (or a list of network prefixes) may be embedded as an option in the PDP context accept message.

Radius negotiation for authentication purposes takes place between the creation of the PDP context and the transmission of the PCP context accept message. Once the context has been activated, the IP pipe is opened.

The timing of the messages is not limited and the only causal relevance is that a router advertisement must wait until the PCP context has been accepted and a PDP context accept message is received so that the router advertisement cannot receive the required configuration parameters, such as router configuration and home agent for mobile IP. The router advertisement may actually be contained within the PCP context accept message. The GGSN generates an IPv6 address from the network prefix and MSISDN and NSAPI information in the same way as the TE. It is even possible that the GGSN can use the IPv6 address in the authentication message before the TE configures the final IPv6 address to its own interface.

In the handshake over the radio interface the same option as established for IPv4 for GPRS is used.

In this embodiment of the invention, since no neighbor discovery (neighbor solicitation) messages are required, the MT can silently discard them if they use a local link address and therefore they do not need to be sent from the MT to the GGSN over the radio interface.

Since NSAPIs are present in each interface identifier, a single MT can simultaneously support several independent IP sessions, each using one NSAPI. If the MT has several connectors, one for each IP address, the NSAPI represents the address of the connector. Therefore, several devices can use the same MT (one NSAPI per connector) at the same time.

To implement push services, the destination address for a particular push service needs to be known. When the destination address is generated by using the MSISDN, it is predictable, which means that a PDP context can be opened from the internet side (NRPCA). However, because NSAPIs are by default unpredictable, two ways are provided to implement a push service:

(i) a standard NSAPI value for push traffic is used. In this case, MT is the real target for push traffic. If several devices are connected to the MT, only one device corresponding to the standard NSAPI value will receive push traffic.

(ii) A non-zero value is used for unused bits in the interface identifier (see above). In this case, it is up to the MT configuration to decide which device receives the push service. The configuration is set when a push service is subscribed. In this alternative, the GGSN must still use a real NSAPI value to map IPv6 addresses into a GTP tunnel. The default NSAPI and the use of bits are mapped.

In both cases, the user can open a real PDP context from the MT side. The GGSN should not open a PDP context for any packets arriving at the access point from the internet side. Preferably, a notification is sent to the MT and let it decide whether it wants to initiate the context to receive the packet.

An important aspect of this embodiment of the invention is that the MT emulates a router and implements the following functions:

(i) it sends a router solicitation based on the network prefix it gets from the GGSN/AP.

(ii) It revokes the neighbor solicitation if they use a local link address.

(iii) It responds to the local link router solicitation with a router advertisement.

This embodiment of the present invention enables a standard PPP implementation to be used in TE and therefore does not require manipulation of its counter.

Figure-8 shows an embodiment of a mobile station MS for use in the GPRS system of figure-1 and the embodiments and methods described above. The mobile station MS comprises a Central Processing Unit (CPU)70, a transceiver 72, a memory 74 for storing GPRS-related information of the mobile station, a protocol stack 76 for controlling communication with the GPRS system, a display 78 and a memory 79 for phone-related functions of the mobile station. The operation of the transceiver 72 in making a telephone call is not described as this relates to the conventional telephony field of mobile stations MS. The CPU 70 controls the operations of the other units.

The above described method may be applied to a mobile station which does not comprise a terminal device and a mobile terminal, but only an integrated unit. In this embodiment, PPPv6 need not be used within the mobile station.

The present invention is not limited to the use of PPPv 6. Other point-to-point protocols exist such as SLIP (serial line IP). IPv4 nodes within the local area network use other layer two (L2) protocols such as "ethernet" or "token ring". Furthermore, as noted above, in some embodiments, if an integrated mobile station is used that does not have separate MTs and TEs, then a point-to-point protocol is not required.

Specific implementations and embodiments of the invention have been described. It is clear to a person skilled in the art that the invention is not restricted to details of the embodiments presented above, but can be implemented in other embodiments using equivalent equipment without deviating from the characteristics of the invention. The scope of the invention is only limited by the appended patent claims.

Claims (29)

1. A method of obtaining a network address within a communications network, the method comprising the steps of:

establishing an entity comprising information relating to a network address within a sub-network;

sending a network address request without an interface identifier from a first node to a second node;

creating a link between the first node and the second node, the link having a link identifier that is unique within the subnet;

determining a network address for the first node based on the link identifier;

verifying, by the entity, whether the determined network address is unique; and

accepting the network address if the determined network address is unique and not accepting the network address if the determined network address is not unique.

2. The method according to claim 1, wherein the link identifier is generated statically based on information identifying one of the nodes.

3. The method according to claim 1, wherein the link identifier is randomly generated by one of the nodes.

4. A method according to claim 1, wherein the information relating to network addresses is a list of link identifiers or network addresses within the sub-network.

5. A method according to claim 4, wherein said list comprises link identifiers which have been previously assigned to nodes.

6. A method according to claim 5, wherein the checking of uniqueness is achieved by the entity referring to a list of previously assigned link identifiers or network addresses.

7. A method according to claim 6, wherein the checking of uniqueness is carried out by the entity referring to a routing table.

8. A method according to claim 6, wherein the checking of uniqueness is performed by the entity referencing a neighboring cache.

9. Method according to claim 4, wherein said list comprises link identifiers which are unique and which have not been previously assigned.

10. Method according to claim 9, wherein the checking of uniqueness is performed by the gateway selecting a link identifier or a network address from a list of link identifiers or network addresses that have not been assigned.

11. A method according to claim 1, wherein said information is that the entity has an identifier which can be used to create a unique network address.

12. A method according to claim 11, wherein the checking of uniqueness is carried out by the entity referring to the information it contains relating to the network address and determining that it has a link identifier that can be used to create a unique network address.

13. A method according to claim 1, wherein said link identifier is transmitted between the first and second nodes from a sender to a receiver.

14. A method according to claim 13, wherein the recipient of the link identifier discards it and generates a different link identifier which is checked for uniqueness.

15. A method according to claim 13, wherein if said link identifier is not unique, the receiver selects a unique link identifier which it sends to the sender.

16. The method according to claim 1, wherein said network address is obtained from said link identifier and a network prefix.

17. The method according to claim 16, wherein the network prefix is obtained by a router solicitation sent between the first and second nodes.

18. The method according to claim 16, wherein the network prefix is obtained by a router advertisement automatically sent between the first and second nodes.

19. The method of claim 16, wherein there are a plurality of network prefixes used to create a plurality of network addresses for a node.

20. The method according to claim 1, wherein said communication network comprises a plurality of subnets.

21. A method according to claim 1, wherein the first node is a mobile station.

22. A method according to claim 1, wherein the second node is a gateway.

23. A method according to claim 1, wherein said communication network is a GPRS system.

24. A method according to claim 1, wherein said link is a PDP context.

25. The method of claim 1, wherein said network address is an IPv6 address.

26. A method according to claim 1, wherein said link is a mobile packet data connection.

27. A communication network comprising:

a subnet;

a first node and a second node, the first node capable of sending a network address request without an interface identifier to the second node;

an entity comprising information relating to a network address within the sub-network, said entity being capable of creating a link between a first node and a second node, the link having a link identifier that is unique within the sub-network, and said entity being capable of determining a network address for the first node based on said link identifier;

wherein the entity is capable of verifying whether the determined network address is unique and accepting the network address if the determined network address is unique and not accepting the network address if the determined network address is not unique.

28. A method for a node to obtain a network address in a communication system, the method comprising the steps of:

the node sending a network address request to the gateway requesting a unique interface identifier, wherein the network address request does not contain an interface identifier;

the node receiving a unique interface identifier from the gateway;

the node adopts the interface identifier;

the node receiving a network prefix from the gateway; and

the node combines the interface identifier and the network prefix to generate the network address.

29. A method for a gateway to specify a network address in a communication system, the method comprising the steps of:

the gateway receiving a network address request from a node requesting a unique interface identifier, wherein said network address request does not contain an interface identifier;

the gateway sending a unique interface identifier to said node for adoption by the node; and

the gateway sends a network prefix to the node to enable the node to combine the interface identifier and the network prefix to generate the network address.