WO2002017667A1

WO2002017667A1 - Renewal of ip address lease in a mobile network

Info

Publication number: WO2002017667A1
Application number: PCT/EP2000/008098
Authority: WO
Inventors: Juha A. RÄSÄNEN
Original assignee: Nokia Corporation
Priority date: 2000-08-18
Filing date: 2000-08-18
Publication date: 2002-02-28
Also published as: AU2000265718A1

Abstract

The invention proposes a method for controlling the validity of an address of a network node, comprising the steps of waiting (S2) for elapsing of a first predetermined period of time (Tb); sending (S3) a check message (CM) to a predetermined network node (TE); deciding (S4) whether an address of the predetermined network node (TE) is still valid based on whether a response sent from the network node (TE) is received or not. By this method, it can easily be determined whether a temporarily allocated address of a certain network node is still valid or not. The invention also proposes a corresponding network control device.

Description

RENEWAL OF IP ADDRESS LEASE IN A MOBILE NETWORK

Field of the invention

The present invention relates to a network control device and a method for controlling the validity of an address of a network node.

BACKGROUND OF THE INVENTION

The invention relates to dynamic allocation of network addresses. This is performed because there is an insufficient number of unambiguous addresses available for network hosts in some network technologies such as Internet Protocol version 4 (Ipv4), partially due to careless address allocation in history by the address allocation authorities and the explosion-like growth of the Internet. Hence, only a limited number of addresses are available. Thus, in order to obtain unambiguous addresses in a sufficient number, addresses are temporarily allocated. The allocation mechanism guarantees not to reallocate a certain address within a requested period of time. This period over which a network address is allocated to a client is referred to as a "lease".

The above described dynamic allocation of network addresses is carried out by using the Dynamic Host Configuration Protocol (DHCP), for example. A network entity which allocates the network addresses is referred to as a DHCP server, while a network entity which requests an allocation of a network address is referred to as a DHCP client.

Thus, the "leasing" (i.e., allocation) of a dynamic IP (Internet Protocol) address by a mobile node is carried out using a DHCP (Dynamic Host Configuration Protocol) operation. The leasing is valid for a certain period of time after which it shall be renewed, if the mobile node still wants to be operative in its foreign location, i.e., wi^'th the allocated IP address. When the leasing is renewed, the address allocated by the DHCP server to the mobile node may change, i.e. the address may be different than the address of the previous leasing period.

A more detailed description of DHCP can be found in document IETF RFC2131 (1997), "Dynamic host configuration protocol", for example.

There is no mechanism to inform the nodes of the mobile packet network (SGSN (Serving GPRS Support Node), GGSN (Gateway GPRS Support Node) in UMTS and GSM) of the new IP address, i.e. the IP address changed during the renewal of the leasing period. The nodes of a mobile packet network can only get to know the addresses of the IP address during a so-called PDP (Packet Data Protocol) context activation. An address which is no longer valid can be deleted by performing a so-called PDP context deactivation. After the PDP context activation and registration phase, the messages between the mobile node's DHCP client and the DHCP server are transparent (i.e. relayed ignoring the contents) traffic to the mobile network nodes.

Therefore, in order to inform the mobile network nodes about the new IP address of the mobile node, the currently active PDP context should be cleared and a new PDP context should be created, with the related IP address leasing process that updates the IP address information in the mobile network nodes. A detailed description is given in document 3GPP TSG-CN3 Tdoc N3- 000382, "PDP Context Deactivation due to DHCP renewal procedure", discussion document, for example.

This situation is described in the following by referring to Figs. 1 and 2. Fig. 1 shows the protocol stack, whereas Fig. 2 shows the signaling between different network nodes. As an example, signaling between a mobile station MS and a Gateway GPRS Support Node (GGSN) is illustrated. The mobile station MS comprises Terminal Equipment (TE) and Mobile Terminal (MT) . The TE and MT exchange several AT commands via the R interface. As derivable from Fig. 1, the TE is able to operate with the Point-to-Point Protocol (PPP) , whereas the MT is not.

The mobile station MS is connected to a Serving GPRS Support Node (SGSN) which in turn is connected to the GGSN. For signaling between the TE and the GGSN, Point- to-Point Protocol (PPP) is used. As illustrated, interworking between the GGSN and a DHCP server (which is in this example a LT2P Network Server (LNS) ) is effected by using the Layer Two Tunneling Protocol (L2TP) . Also, the User Datagram Protocol (UDP) and the Internet Protocol (IP) can be used. It is noted that the protocol stack is described in more detail in document 3G TS 29.061, "Interworking between the Public Land Mobile Network (PLMN) supporting Packet Based Services and Packet Data Networks (PDN) (Release 1999)", for example.

As derivable from Fig. 1, the DHCP packets are regarded by the MT as user packets. That is, the MT cannot be aware of any IP address changes which are notified within the DHCP packets. Hence, as illustrated in Fig. 2, exchange of the DHCP packets is only effected between the TE and the LNS. That is, after the above-mentioned lease period has elapsed, only the TE (terminal equipment with the mobile DHCP client) and the DHCP server know if the IP address of the terminal changes during the lease renewal process. Thus, the message exchange between the mobile DHCP client (in TE) and the DHCP server is transparent (i.e. relayed ignoring the contents) to the intermediate network nodes.

The PDP context is set up between the MT (mobile termination) and the GGSN. Only by setting up the PDP context, the GGSN and the MT are able to obtain the actual IP address of the TE. That is, only the elements MT and GGSN are able to set up the PDP context. However, since these elements can not detect DHCP messages, they are not aware when a change of the IP address has occurred. That is, the elements MT and GGSN being able to clear and set up a PDP context and requiring the address information do not know anything about a possible IP address change and the possibly related need to clear the active PDP context.

Heretofore, two solution were discussed, which are described in the following.

First, the operation of the DHCP client in the TE could be changed. That is, the operation could be changed such that the DHCP client could easily recognize the change of its IP address and clear the PDP context and activate the setup procedure with the address update in the network nodes or in some other way tell its new IP address to the network nodes. However, this solution would result in the problem that the operation of the DHCP client based on the IETF RFC2131 would have to be changed. That is, the IETF RFC2131 would have to be updated and implementations based on it should be updated in order to make them usable in the UMTS/GSM mobile environment.

This would lead to complicated updating procedures and is not desirable. Hence, this solution is considered to be less feasible.

As a second solution it was proposed that the GGSN could monitor the data traffic in order to recognize messages between DHCP clients and servers and to compare the addresses in leasing renewals to the old addresses. If the IP address changes during the leasing renewal process, the GGSN could adopt the new address and deliver it further to the SGSN or possibly clear the PDP context if a complete setup procedure is required.

However, this leads to the problem that the processor loading would increase and the traffic handling capacity would heavily decrease due to the continuous monitoring. This solution is not considered good enough.

SUMMARY OF THE INVENTION

Therefore, the object underlying the invention resides in removing the above drawbacks of the prior art.

According to a first aspect of the invention, this object is solved by a method for controlling the validity of an address of a network node, comprising the steps of waiting for elapsing of a first predetermined period of time; sending a check message to a predetermined network node; deciding whether an address of the predetermined network node is still valid based on whether a response sent from the network node is received or not.

Alternatively, the object is solved by a network control device for controlling the validity of an address of a network node, comprising a first timer for waiting for elapsing of a first predetermined period of time; a sending means for sending a check message to a predetermined network node after elapsing of the first predetermined period of time; and a deciding means for deciding whether an address of the predetermined network node is still valid based on whether a response sent from the network node is received or not.

By the method and the network control device according to the invention, it is possible to check easily whether a temporarily (or also permanently) allocated address of a network node is still valid.

According to the invention, less processing power is required. Thus, the traffic handling capacity of the relevant network nodes is not wasted.

Sending of the check message can be repeated for a predetermined number of times in case no response is received. That is, before finally deciding that no response is received, several trials are allowed. Thus, possible lost of the check message due to transmission problems can be considered.

Before deciding that no response is received, it can be waited for another predetermined period of time before finally deciding that no response is received. Thus, transmission time and reacting time of the network node to react on the check message (i.e., to send the response) can be considered. Thus, a more reliable decision is possible.

The first predetermined period of time can be increased or decreased to adapt to changing conditions. That is, the first predetermined period of time can be made variable such that different conditions can be taken into account. For example, a case can be considered in which high traffic load in the network occurs, and the first predetermined period of time can accordingly be increased in order to ease the traffic load.

Furthermore, above-described method can further comprise the steps of waiting for elapsing of a second predetermined period of time; sending a check message to the predetermined network node; deciding whether an address of the predetermined network node is still valid based on receiving a response from the network node or not; wherein thereafter the waiting step for waiting for elapsing of the first predetermined period, the sending step and the deciding step are performed repeatedly until it is decided that no response is received.

Correspondingly, the above described network control device may further comprise a second timer for waiting for elapsing of a second predetermined period of time; wherein the sending means is adapted to send a check message after elapsing of the second predetermined period of time, and wherein the first timer, the sending means and the deciding means are adapted to repeatedly measure the first predetermined period of time, to send a check message and to decide whether a response has been received until the decision means decides that no response is received.

Thus, before the above-mentioned steps are performed, a second predetermined period of time can be awaited. Thus, a lease time can be considered and less message -traffic is required since the repetition of sending of the check messages with the first predetermined period can be started only after elapsing of the first time period.

Hence, the second predetermined period may be selected to be longer than the first predetermined period .

The second predetermined period may be selected in accordance with a lease time period allocated to the address of the network node.

The network node may be a Dynamic Host Configuration Protocol (DHCP) client which receives its address using the DHCP.

The check message may be sent to the network node via the Packet Data Protocol (PDP) .

After the deciding that no response has been received,

Packet Data Protocol (PDP) context may be deactivated and a new PDP context may be activated, and a new address allocated to the network node may be obtained from the new PDP context.

The network control device may be a Gateway GPRS Support Node (GGSN) , whereas the network node may be a a network element such as Terminal Equipment (TE) being a part of a mobile station (MS) . However, also the network node may be an entity such as GGSN or HLR (Home Location Register) .

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be more readily understood with reference to the accompanying drawings in which:

Fig. 1 shows a protocol stack for access with DCHP end- to-end,

Fig. 2 network nodes in which the protocol stack shown in

Fig. 1 is applied,

Fig. 3 network nodes according to a first embodiment,

Fig. 4 a flowchart illustrating a procedure according to the first embodiment,

Fig. 5 network nodes according to a second embodiment, and

Fig. 6 a flowchart illustrating a procedure according to the second embodiment.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

In the following, preferred embodiments of the invention is described in more detail with reference to the accompanying drawings .

Fig. 3 shows a network system according to a first embodiment. Apart from the GGSN, the network nodes concerned and the connections between them are similar to those shown in Fig. 2, thus a detailed description thereof is omitted.

The GGSN of Fig. 3 differs from that according to Fig. 2 in that the GGSN comprises a timer B. Furthermore, the GGSN is adapted to send a check message CM to the TE. This can be effected via the Point-to-Point Protocol as shown in Fig. 1, for example. The function of the timer B and the 'check message is described in the following with respect to the flowchart shown in Fig. 4.

The process illustrated in the flowchart of Fig. 4 is started after the PDP (Packet Data Protocol) context activation and registration procedure, i.e., immediately after the current IP address of the TE is known. In step SI the timer B is started. The time period Tb to be measured by the timer B is set during an initialization procedure (for example, during start-up of the GGSN) to an appropriate value. This value may later be dynamically changed for example due to changing traffic load conditions in the network element or node.

In step S2 it is checked whether the timer B has elapsed, i.e., whether the predetermined time period Tb has elapsed. If the time period Tb has elapsed, the process proceeds to step S3.

In step S3, the GGSN sends a check message CM to the TE. This message should be a message requiring a response, for example, an ICMP (Internet Control Message Protocol) echo request. In this way, the GGSN can check whether the TE still recognizes its old IP address. Thus, in step S4 the GGSN checks whether a response from the TE is received. Preferably, a certain transmission and response time on the TE side should be allowed. That is, in step S4 an appropriate period should be awaited. This can be realized by another timer in the GGSN.

In case a response from the TE is received in step S4, the GGSN judges that the TE still recognizes its old IP address. Hence, the process returns to step SI again, such that the steps SI to S4 are repeated.

However, in case no response is received in step S4, the GGSN judges that the TE does not recognize its old IP address anymore, i.e., the IP address has changed. Thus, in step S5, the GGSN initiates clearing (i.e., deactivation) of the PDP context. Thereafter, a new PDP context set up (activation) and IP address lease procedure is initiated. In step S6, the new IP address of the TE is obtained from the new PDP context. After this, the process returns to step SI, in which the process is repeated.

As a modification of the first embodiment, the case can be considered that the check message may just have disappeared on its way due to transmission problems or the like. In this case, the IP address may still be valid although the GGSN now judges that the address is no longer recognized by the TE. Thus, before step S5 is carried out, the steps S3 and S4 can be repeated a few times. In this way, it can be assured that non-receiving of a response of the TE is indeed caused by the fact that the IP address of the TE has changed.

According to the first embodiment described above, the check messages are sent periodically to the TE after the activation of the PDP context. The period is determined by the timer B, i.e., the time period Tb, and this period has to be set sufficiently small in order to detect an IP address change before excessive user data packets get lost. This is a process which is uncomplicated and easily to be implemented. However, it causes more message traffic since the check messages have to be sent relatively often.

Thus, according to a second embodiment, also the lease time is considered. Hence, less message traffic is required. The second embodiment is described in the following with reference to Figs. 5 and 6.

Fig. 5 shows the network nodes according to the second embodiment. The nodes are the same as those shown in Fig. 3, with the exception that the GGSN comprises an additional timer, the timer A.

The process according to the second embodiment is described with reference to the flowchart shown in Fig. 6.

Here, the GGSN takes the lease time value from the registration message (which is described in documents IETF RFC2131 and 3G TS 29.061, for example) in the PDP context activation and registration procedure. The lease time value is Tl as defined in RFC2131. This lease time value, i.e., the period of time during which¹ the ' IP address is reserved for the TE, is utilized for determining the time period Ta which is to be measured by the timer A. For example, Ta is set larger than half of the lease time and shorter that the lease time (half the lease time > Ta > lease time) . The time period Ta is utilized in order to be aware when the DHCP client (i.e., the TE) is going to start renewing its address lease from the DHCP server.

In step Sll, the timer A is started. In step S12, it is checked whether the time period Ta has elapsed. If the time period Ta (i.e., the timer A) has elapsed, the process advances to step S13, in which a check message CM is sent to the TE. In step S14, it is checked whether a response is received from the TE.

It is noted that the check message CM according to the second embodiment can be the same as in the first embodiment. Furthermore, also the modifications described in the second embodiment with respect to sending the check message and waiting for a response can be applied. That is, a certain delay for responding of the TE can be allowed, and in addition, the check message can be sent several times in order to make sure that the check message does not get lost on its way.

In case a response is received in step S14, it means that the TE still has its old IP address. The TE either has not yet renewed its address lease or has got its old address on the renewal. Thus, the process advances to step S15. The steps S15 to S18 fully correspond to the steps SI to S4 according to the first embodiment, thus, a description thereof is omitted here. It is noted that also the modification of the first embodiment is applicable in the second embodiment.

That is, after the timer Ta has elapsed, the check messages CM are sent periodically according to the timer value Tb, as in the first embodiment. In case no response is received from the TE either in step S14 or in step S18, the process advances to step S19. As in step S5 according to the first embodiment, the present PDP context is deactivated and a new PDP context is activated.

In step S20, the new IP address of the TE and the lease time value of the new IP address is obtained from the new PDP context. Thereafter, the process returns to step Sll and is repeated.

The above description and accompanying drawings only illustrate the present invention by way of example. Thus, the embodiments of the invention may vary within the scope of the attached claims. For example, also the following modifications are possible.

The GGSN can always deactivate the PDP context after the expiration of the timer Ta (i.e. just before the lease time renewal is supposed to be initiated by the TE) .

Moreover, the MT can monitor the message traffic going through it, study the IP address renewal messages, find out the change of the address and generate a deactivation of the PDP context. This requires that the MT is adapted to have an IP protocol stack in the current architecture.

Furthermore, the MT could monitor the PDP context activation and IP address lease messages and use the timers and send an address checking message to the TE as the GGSN in the primary solution above, and generate a deactivation of the PDP context. Again, this requires that the MT comprises an IP protocol stack in the current architecture . Alternatively, the MT can always generate a deactivation of the PDP context after the expiration of the timer Ta (i.e. just before the lease time renewal is supposed to be initiated by the TE) . This procedure would be very easy to implement since no check messages would have to be sent.

It is noted that the above described procedures according to the first and second embodiments and the modifications thereof can be preferably applied to a case in which addresses are dynamically allocated using a DHCP operation. However, the invention is not limited thereto and can be applied to every case in which an address change of a certain network element cannot be easily detected.

Claims

1. A method for controlling the validity of an address of a network node, comprising the steps of waiting (S2) for elapsing of a first predetermined period of time (Tb) ; sending (S3) a check message (CM) to a predetermined network node (TE) ; deciding (S4) whether an address of the predetermined network node (TE) is still valid based on whether a response sent from the network node (TE) is received or not.

2. The method according to claim 1, wherein the sending step (S3) is repeated for a predetermined number of times in case no response is received in the deciding step (S4) .

3. The method according to claim 1, wherein the deciding step (S4) waits another predetermined period of time before it is decided that no response is received.

4 . The method according to claim 1, wherein the first predetermined period of time (Tb) is increased or decreased to adapt to changing conditions.

5. The method according to claim 1, further comprising the steps of waiting (S12) for elapsing of a second predetermined period of time (Ta) ; sending (S13) a check message (CM) to the predetermined network node (TE) ; deciding (S14) whether an address of the predetermined network node (TE) is still valid based on receiving a response from the network node (TE) or not; wherein thereafter the waiting step (S16) for waiting for elapsing of the first predetermined period (Tb) , the sending step (S17) and the deciding step (S18) are performed repeatedly until it is decided that no response is received.

6. The method according to claim 5, wherein the second predetermined period (Ta) is selected to be longer than the first predetermined period (Tb) .

7. The method according to claim 5, wherein the second predetermined period (Ta) is selected in accordance with a lease time period allocated to the address of the network node (TE) .

8. The method according to claim 1, wherein the network node is a Dynamic Host Configuration Protocol (DHCP) client which receives its address using the DHCP.

9. The method according to claim 1, wherein the check message (CM) is sent to the network node via the Packet Data Protocol (PDP) .

10. The method according to claim 9, wherein after the deciding step (S4; S14, S18) has decided that no response has been received, a step (S5; S19) of deactivating a Packet Data Protocol (PDP) context and activating a new PDP context, and a step (S6) of obtaining a new address allocated to the network node (TE) from the new PDP context are performed.

11. A network control device for controlling the validity of an address of a network node, comprising a first timer (B) for waiting (S2) for elapsing of a first predetermined period of time (Tb) ; a sending means for sending a check message (CM) to a predetermined network node (TE) after elapsing, of the first predetermined period of time (Tb) ; and a deciding means for deciding whether an address of the predetermined network node (TE) is still valid based on wheth-er a response sent from the network node (TE) is received or not.

12. The network control device according to claim 11, wherein the sending means repeats sending the check message a predetermined number of times in case no response is received by the deciding means.

13. The network control device according to claim 11, wherein the deciding means waits a predetermined period of time before it is decided that no response is received.

14. The method according to claim 11, wherein the first predetermined period of time (Tb) is increased or decreased to adapt to changing conditions.

15. The network control device according to claim 11, further comprising a second timer (A) for waiting for elapsing 'of a second predetermined period of time (Ta) ; wherein the sending means is adapted to send a check message (CM) after elapsing of the second predetermined period of time (Ta) , and wherein thereafter the first timer (B) , the sending means and the deciding means are adapted to repeatedly measure the first predetermined period of time (Tb) , to send a check message (CM) and to decide whether a response has been received until the decision means decides that no response is received.

16. The network control device according to claim 15, wherein the second predetermined period (Ta) is selected to be longer than the first predetermined period (Tb) .

17. The network control device according to claim 15, wherein the second predetermined period (Ta) is selected in accordance with a lease time period allocated to the address of the network node (TE) .

18. The network control device according to claim 11, wherein the network node is a Dynamic Host Configuration Protocol (DHCP) client which receives its address using the DHCP.

19. The network control device according to claim 11, wherein the check message is sent to the network node via the Packet Data Protocol (PDP) .

20. The network control device according to claim 19, wherein the network control device is adapted to deactivate a Packet Data Protocol (PDP) context and to activate a new PDP context after deciding that no response has been received, and to obtain a new address allocated to the network node (TE) from the new PDP context.