FI107677B - Allocation of an IP address in a mobile telecommunications system - Google Patents

Abstract

The invention relates to mobility management in an Internet-type protocol traffic in a mobile communications network. At least one of mobile exchanges (DXT1, DXT2) in the mobile communication network is arranged to dynamically allocate an IP address to a mobile host (MH) from an address space of the mobile communications network for a lease period and to associate the allocated IP address with a user identity (SSI) and a data equipment identity (NSAPI) used for identifying the mobile host (MH) in the mobile communication network.

Description

107677 IP Address Allocation in Mobile System

Field of the Invention

The invention relates to address allocation for Internet-based protocol traffic in a mobile communication system.

Background of the Invention

A mobile communication system generally refers to any communication system that enables wireless communication as users move within the service area of the system. A typical mobile communication system is the Public Land Mobile 10 Network (PLMN). Often, a mobile network is an access network that provides the user with wireless access to external networks, hosts, or services provided by specific service providers.

One of the main goals in the development of mobile networks is to provide the user with an IP (Internet Protocol) service, i.e., access to the Internet via a mobile-15 network. It is hoped that the IP will be implemented over the mobile network while maintaining backward compatibility with existing systems and assuming minimal changes to current standards. The problem, however, is that the basic IP concept does not support user mobility. IP addresses are assigned (allocated) to network interfaces depending on their physical location-20. In fact, the first field (NETID) of the IP address is common to all interfaces that are linked to the same Internet subnet. This principle prevents the user (mobile host) from retaining his or her address: * · *: when moving across different Internet subnets, i.e., when switching physical border; the surface.

25 To improve mobility on the Internet, the Internet Engineering Task • · r .. 'Force (IETF) has introduced RFC2002 Mobile IP Protocol for IP Verification 4 ... Mobile IP allows IP datagrams to be routed to mobile • · «hosts regardless of the access point on the subnet. A mobile node MN (also called a mobile host MH) refers to a host that changes its access point-30 from one network or subnet to another. The mobile node can change location without changing its IP address; it can continue to communicate with other Internet nodes at any location using its (fixed) IP [···] address. In the Mobile IP concept, the datagram is encapsulated and routed to a · · Ί * known decapsulation agent, which decapsulates the datagram (de- • ·: 35 encapsulates it) and then correctly transmits it to its final destination. Each mobile node is connected to a home agent over a unique tunnel, which is identified by a tunnel identifier unique to a particular guest agent / home agent pair. In Mobile IP, the mobile host is identified relative to its home IP network. Thus, Mobile IP solves the basic IP mobility management problem by adapting to the inflexibility of the IP-5 address, but the mobile host is identified relative to its home IP network.

These prior art Mobile IP principles are not very suitable for a mobile communication system that does not use IP as a network protocol. A TETRA network that tunnels IP traffic through a non-IP protocol is an example of such a system. The TETRA system is a digital mobile communication system primarily developed for professional and government users, such as police, armies, oilfields, etc. Figure 1 illustrates one scenario of a TETRA network connected to the Internet. The TETRA network comprises digital exchanges DXT and TETRA base stations TBS. There are two possible configurations for connecting the DXT to the Internet. In the first configuration, each DXT unit may have its own direct "exit" path through an adjacent router, such as router 1 for DXT1 and router 2 for DXT2 in Figure 1, for transmitting IP packets from the TETRA network to the Internet and vice versa. In another configuration, only one 20 or a few DXTs, referred to herein as gateway DXT exchanges, are connected to an Internet router (e.g., DXT1 to router 1 in Figure 1), and other DXTs are connected to the Internet by their gateway DXTs. through centers.

: m "In mobile systems, mobile hosts are able to move from one cell to another, and thus arbitrarily move between DXT exchanges.

The mobile host can start IP data transfer on one network and complete it on another. The movement of mobile hosts between TETRA networks results in a t: T situation where the netid identifier in the mobile host's IP address may not match the current network.

There are two ways in which an IP address can be allocated to the host: 1) The IP address can be statically configured on the mobile host, or 2) • · The host can request an IP address either at system boot or at the start of the IP service. This second method is preferable for two ♦ · reasons.

35 More than sixteen thousand X X users can be linked to the same DXT exchange. Users may be dispersed over a wide geographic area »» · M »· • · 3 107677. If a static IP address configuration is enabled, changes to the network configuration will force each host to manually reconfigure the network. In other words, IP network management becomes inflexible.

The exponential growth of the Internet will lead to the end of the unique IP address space. It will be harder for organizations to get more unique address space. This means that the number of users in your organization may be greater than the number of available IP addresses. In such a case, dynamic IP address allocation provides the majority of users with an IP service.

10 There is a dynamic address allocation method called Dynamic Host Configuration Protocol (DHCP). DHCP is defined in RFC 1541. DHCP is intended for use on local area networks (LANs) over the TCP / IP protocol stack, i.e., the Internet environment, and is thus not fully applicable to mobile networks such as TETRA, which does not use IP as a network protocol. For example, DHCP communicates address information between the end host and the DHCP client, which puts additional load on the air interface at TETRA. Second, the DHCP utilizes the UDP protocol as a transport protocol, which brings an overhead of IP and UDP headers to each DHCP message. Additionally, due to air link failures, some of the DHCP server's responses are likely to be lost, which often results in address reallocation. Third, the DHCP client broadcasts the DHCP DISCOVER message on its local physical subnet. This broadcast is not natural to TETRA- * ... infrastructure. Additionally, the DHCP limits the request for the address to the local network.

• · · * · *. * 25 In a mobile communication environment such as TETRA, it makes sense to allow address requesting from remote networks as well.

• «

Summary of the Invention

It is an object of the invention to provide a novel dynamic address allocation method and a mobile communication system that eliminate or alleviate the above problems.

This and other objects of the invention are achieved by a method and system characterized by what is defined in the appended independent claims. · · - in the claims. Preferred embodiments of the invention are described in the appended dependent claims.

; . * ·. 35 Each mobile network is assigned a set of unique IP addresses (such as IPv4 or IPv6 addresses) so that Internet routers see • · 4 107677 mobile networks as ordinary local IP networks. An IP address is a pair of network and host identifiers. The network identifier (netid) specifies the IP-mat mobile communication network and the host identifier specifies the mobile host on the mobile communication network. All addresses that are available under the given network identifier 5 are called the address space. IP addresses are allocated to users from this available address space. The address space can be divided into static and dynamic address subspaces. Static IP addresses are assigned individually to specific users. The dynamic subspace may be further subdivided into many address pools. The address pool is defined by a pair formed by a lower edge address and an upper edge address. Multiple organizations can share address pools, in which case they are called the organization's access rights to request IP addresses. In a mobile communication network, an IP subnet may be formed around one or more exchanges, such as DXTs. In the latter case, multiple exchanges may be logically organized under the same netid prefix 15 and share the same host address space. The ability to share an organization's address space among many networks and interactively request an IP address from them to increase the resilience of the address request method; the user is not dependent on a single address distribution center. This also increases the hit frequency of the address; if a particular address space is exhausted, 20 users may attempt another network.

The mobile host is identified by a unique pair consisting of a user identifier and a data device identifier associated with the mobile host ·. to the IP address allocated in the mobile network. The user identifier allows the allocated IP address to be assigned to a particular end user or to a specific mobile device on the mobile network and authenticates his or her permission to use the IP * *, · * service. In a preferred embodiment of the invention, the user identifier is a mobile subscriber identifier. The end-data device identifier allows the separation of several data devices connected to the same * ·· 'mobile station. In the preferred embodiment of the invention, the network service access point identifier (NSAPI) is used for this purpose: *: * ·. As used herein, the term "" terminal data device "refers to any data device or *** application that is connected, integrated, or associated with a mobile station.

• · ·. *. The use of the user identifier and the data terminal identifier provides unique identification of the mobile host without any relationship to the IP network. In addition, in most communication systems such as TETRA, this allows re-use of tags already available in a communication system.

Preferably, the 107677 IP address is allocated for a predetermined period of time, called a lease period. The allocated IP addresses, along with their associations, such as the user identifier and the data device identifier, are stored in a data structure called an address table. After the end of the lease period, the IP address is deallocated (released) or the allocation is renewed.

In accordance with a first embodiment of the invention, information on subnets, address pools and user rights is configured in databases of network units. The network unit may or may not have a given address space. If the network unit does not have a given local address space or if it is unable to allocate an IP address to the mobile host for any other reason (for example, the local address pool is currently exhausted or the mobile host or user is not allowed to request IP addresses from this local address pool) requests an IP address from a network unit further away. In the latter case, the local network unit 15 acts as a client and the remote network unit acts as a server for IP allocation. The client network unit leases IP addresses from remote servers on behalf of local users, i.e., mobile hosts. This minimizes signaling over the air interface.

According to another embodiment of the invention, the sub-databases of the network units are configured with information about subnets, address pools, and user rights, but using an end-to-end allocation protocol to communicate address information between% IP address allocating network unit (address server) and the mobile host itself. If the LAN does not * ... ** be able to allocate an IP address (eg it does not have a local address pool or • · · · 1/25 of the local address pool is exhausted), the LAN acts like * ·· ♦ 1 "proxy" - the server trying, on behalf of the mobile host, to request a remote IP address from the server. This approach requires a special protocol unit, the j-v being in the network layer of the terminal data device. In addition, in the worst case, more messages 30 are transmitted over the air interface due to the allocation process than in the first embodiment. On the other hand, mobility management may be less complicated.

BRIEF DESCRIPTION OF THE DRAWINGS: The invention will now be explained in more detail by means of preferred embodiments with reference to the accompanying drawings, in which Figure 1 illustrates a TETRA network connected to the Internet. Fig. 2 illustrates the difference between the AIP and DAAP approaches of the present invention, Fig. 3 shows an address table, Figs. 4, 5, 6 and 7 are signaling diagrams showing exemplary AlP-address-5 teallocation scenarios, Fig. 8 is a state diagram. FIG. 9 illustrates an APC operation, FIG. 9 is a state diagram illustrating APS operation, FIG. 10 illustrates a network unit and protocol units associated with the DAAP protocol, FIGS. Figure 14 is a state diagram illustrating the operation of the DAAPC, and Figure 15 is a state diagram illustrating D AAPS activities.

PREFERRED EMBODIMENTS OF THE INVENTION The present invention is generally applicable to mobile communication systems for providing IP mobility. The invention can be particularly advantageously used to provide IP mobility management in a mobile communication system using a non-IP protocol for routing IP traffic. The TETRA network is an example of such a system. In the following, preferred embodiments of the invention will be described by means of the TETRA system without limiting the invention to this particular mobile communication system.

The MH may consist of a laptop computer PC connected to a mobile radio station. Alternatively, the MH may be an integrated combination of a small computer and a cellular telephone * * · · *, similar in appearance to the Nokia Communicator 9000 series * ·:. * 25. Still other embodiments of MH are various pagers, remote controls, monitoring and / or data loggers, etc.

* · · • V · An example of a possible TETRA architecture is described above with reference to Figure 1. It should be understood that Figure 1 shows only one simplified architecture suitable for the description of the present invention.

30 In practice, the TETRA system can contain any number of TBSs, ···. DXT, MH, and routers, as well as other elements that are relevant to the present invention. As used herein, a TETRA IP network is a collection of DXTs that share a network prefix (IP prefix) for the same IP address.

···: ... ϊ One TETRA network can be divided into two or more TETRA IP networks. 35 sizes. Under current scenarios, each TETRA network is assigned a set of unique IP addresses (such as IPv4 or IPv6 addresses) so that · · 7 107677

Internet users see TETRA networks as standard local IP networks. The IPv4 address consists of 32 bits and is represented as a pair of network and host identifiers. The network identifier (netid) specifies the TETRA IP network and the host identifier specifies the mobile host on the TETRA network. In a TETRA network, an IP subnet 5 may be formed around one or more DXT exchanges. In the latter case, multiple DXTs are logically organized under the same netid prefix and share the same host address space. In the example illustrated in Figure 1, the TETRA subnet 1 is formed around DXT1 and given a netid Ί92.1.1.0 ', and the TETRA subnet 2 is constructed around DXT2 and given a netid Ί92.1.2.0 '. The organization of IP networks around DXTs requires routing capabilities with links between them. Each network consisting of one or more DXT exchanges must be able to forward datagrams to other TETRA IP networks. In Figure 1, DXT1 and DXT2 are connected to each other by link 10.

Two different approaches for implementing the present invention will be described below: the Address Information Protocol (AIP) and the Dynamic Address Allocation Protocol (DAAP). Both DAAP and AIP apply similar techniques to dynamic address management: the address leasing mechanism is included in both cases. The difference between DAAP and AIP is in protocol architectures. The AlP protocol is designed to be consistent with the existing TETRA packet data standard, while the DAAP protocol requires a new protocol unit on the mobile host ·. as well as new messages sent over the air interface. Figure 2 de- ··· * ... illustrates the difference between the two approaches. Gray rectangles Ύ 25 (black boxes) represent elements that AIP or DAAP do not see. In the case of AIP protocol, the APC and APS units in the local and remote DXT exchanges maintain the address information. APC leases IP-M · v addresses from remote APS servers on behalf of local users. In contrast, DAAP is an end-to-end protocol * *, which means that address information is communicated between the address server 30 (DAAPS) and the host itself (DAAPC). DAAPP acts as a proxy: ····· DAAPP only redirects control messages to the correct destinations.

. * ··. The AIP and DAAP protocols will now be explained in more detail.

• ·: · ί · I ALP protocol f * · 35 The ALP protocol manages the IP service in TETRA and includes IP mobility management. The AlP protocol is located on top of the TETRA transport layer; as a result, it exchanges control messages with the peer units using the transport service below. This protocol does not need to route data grams through the shortest route. Local processes can request IP address information from the AlP protocols in at least two cases. In the first 5 cases, when the user requests an IP service, the process responsible for resource allocation requests an IP address from the ALP protocol. In the second case, before the TETRA routing process forwards the IP datagram, it requests the AIP for the current location associated with the destination IP address. The location of the mobile host may be defined by the TETRA network node identification number. In the preferred embodiment, the location in the IP service is defined by a DXT exchange identifier (address).

The ΑΙΡ units allocate IP addresses from the available address spaces. The allocated IP addresses, together with their associations, are stored in a data structure called an address table. The address space may be divided into static and dynamic address subspaces. Static IP addresses are individually assigned to specific users. The ΑΙΡ entity assigned an IP network identifier is called an Address Pool Server (APS, Address

Pool Server) and a ΑΙΡ unit that does not have an IP network identifier is called an Address Pool Client (APC). Both APS and APC can reside in the same AlP process unit. The ΑΙΡ unit acts as an APC in the following cases: 1) AlPr is not given an address space (AIP is APC only), 2) ·. The AIP is given an address space, but the address pools are currently depleted, and 3) the user is not allowed to request IP addresses from local * V expensive address pools. If for some reason the AIP cannot allocate an IP address from the local address space, it may request the address from the remote APS.

'When APS or APC assigns an IP address to a user, it creates an export address • · ·; table that stores the IP address and the user's current location. In order to allocate an IP address, the AIP must know both the user ID and the ID of the end data device or application. The previous identifier is required to bind the IP address: ··· 30 to either the end user or the end mobile station. Unique lick · **. The Individual Short Subscriber Identity (SSI) number may be. ·. used for this purpose. The latter identifier is needed to distinguish between multiple data devices (or applications) connected to the same * · «: y 'mobile station. The Network Service Access Point Identifier (NSAPI, Network Access Point Identifier) can be used for this purpose. An example of a possible address table with the smallest possible number of fields is shown in Figure 9 107677. The IP-Address export field lists all allocated IP addresses. The Location DXT field indicates the current locations of IP users. The Static / Dynamic field indicates whether the address is permanently assigned to the user. The User Identifier field assigns IP addresses to end users. The NSAPI (Network Service Access Point Identi-5 tier) field identifies the end data device. In a TETRA network, a user can access up to 13 data devices simultaneously. Number 0 is reserved for special use and number 15 is for multicast. As a result, there may be more than one export for the same user, i.e. the same SSI (like SSI A in Figure 3) but different NSAPIs and IP addresses (such as IP address' 192.1.1.1 'and NSAPI 1 and IP address 10' 192.1.1.52 'in Figure 3).

The export (s) of a single user in Table 3 are referred to herein as the user IP context of the corresponding user. A user's IP context may contain multiple exports. As stated above, the user IP context is created when the APC or APS gives the user an IP address. Normally, the IP address is provided in response to an address request from 15 users. The address lookup request contains the user and data device identifiers SSI and NSAPI. When an APC or APS receives an address lookup request from a mobile host, it subsequently searches the address table for an export whose user and data device identifiers match those received in the request. If the APC or APS finds such an export, it will complete the request by returning the IP address to the caller. Otherwise, the APC or APS will try to allocate the IP address from the local address space. If there is no free IP address in the address pool, the APC or APS sends: ** ·· an address lookup request to the remote APS server. This remote APS server obtains an IP · ·· v: address from the address space and sends it back to the requesting unit. Address:. ·. * · 25 You may be given a predetermined period of time that may be renewed ·: ··: under a particular renewal procedure. For example, the default period can be 12 hours. However, the default time should preferably be that the IP address is not. ·: ·. change while the mobile host is registered on the system. When the user no longer needs the IP address, the user requests to delete the export or IP <30 context in the address table and return the IP address back to the address book! .. *. If the IP address is permanently allocated, it cannot be allocated to another mobile V · »·; · * host. The IP context may also have been transferred from one DXT to another in a handover:

Figures 4, 5, 6 and 7 show an exemplary AlP address allocation scheme. \ 35 items.

«· · • · • • 10 107677

Example 1

Figure 4 shows how a host retrieves an IP address from a local address space (address space in the same DXT exchange where the user is located). The numbering refers to the numbering used in Figure 4.

1. The mobile host connected to the mobile station requests an IP address. It sends an IP address request message over the air interface.

2. The IP address request arrives at the DXT exchange, the IP kon text manager. The IP context manager forwards the address request to the local AIP.

10 3. The local AIP, after successful validation of user rights, extracts the free IP address from the address pool. It associates the IP address with the user identifier SSI and the network service access point identifier NSAPI, thereby leasing the IP address to the mobile host for the duration of the lease. The local AIP sends the IP address response message back to the IP context manager.

4. When receiving the response, the IP context manager re-allocates the IP context and sends the IP address response message back to the mobile host.

Example 2

Figure 5 illustrates how a mobile host requests an IP address from an address space further away 20 (an address space different from the DXT exchange than the exchange where the user is located). Referring to FIG. errors.

• · · * 1. The mobile host connected to the mobile station requests an IP address. It sends an IP address request message over the air interface.

25 2. The IP address request arrives at the DXT exchange, the IP manager text manager. The IP context manager forwards the address request to the alpha, costly.

• · ·: 3. The local AIP, after successfully validating the user privileges, attempts to retrieve the IP address from the address pool, but fails. Local *: ··: 30 AIP retrieves from the database a list of APSies for which the user can request an IP address.

♦ ** ': The local AIP sends an IP address request message interactively to APSi, • · ·. *. until it receives a positive response from one of them.

·;! / 4. Upon receipt of the IP address request message, APS associates the SSI and the IPS: 35 NSAPI with the IP address user ID, thus leasing the IP address to the ALP sender for a total of 11 107677. This total time can be, for example, twice the rental period. The APS sends the IP address response message back to the AlP sender.

5. Upon receiving the IP address response message, the local AIP associates the IP address with the user identifier SSI and the network service access point identifier NSAPI, thus leasing the IP Address to the mobile host for the lease period. The local AIP sends the IP address response message back to the IP context manager.

6. Upon receiving the response, the IP context manager allocates the IP context to the user and sends the IP address response message back to the mobile host.

Example 3

Figure 6 shows how the local AIP renews the address lease (in this case the local AIP is the APS in the same DXT exchange where the user is located). Referring to Figure 6, the following steps take place.

15 1. The address rental has expired. The local AIP sends an address use verification request message to the IP context manager.

2. The IP context manager sends an address use verification message to the mobile host.

3. If the IP address is enabled, the mobile host responds with a positive 20 responses to the local AI Pi.

4. Upon receiving the response, the IP context manager sends a positive response to the local IP. AIP leases the IP address for the next lease term. When a negative response is received or no legal response is received, the AIP • destroys the IP address allocation.

• · · 1 25 Example 4 * .. * Figure 7 shows how an APC renews an address leased from ♦ ♦ · * γ * APS. Referring to Figure 7, the following steps take place.

· ;; 1. The rental of the address has expired. AIP sends an address use verification request message to the IP context manager.

2. The IP context manager sends an address use verification request- · * '*: message to the mobile host.

• · · 3. If the IP address is enabled, the mobile host responds with a positive T.Y response back to the IP context manager.

• · **: ** 4. Upon receipt of a positive response, AIP will send APS a \\ mll 35 address lease Renewing request message.

► ···· • · 12 107677 5. Upon receipt of the address lease Renewing Request message, APS will renew the total rent for the APC transmitter and respond with a positive rent response. Upon receipt of this response, AIP will renew the address of the rental user.

Figure 7 also shows an alternative case where the lease Rene wing request message disappears between the local AIP and the APS. Alternative steps are: 5 *. AIP sends APS an address lease Renewing request message. This request will be lost. While awaiting a response, AIP will set the timer 10 to 80% of the rental time.

* 6. When the timer is up, APS deletes the IP address and AIP sends another lease Renewing request message to APS. This request will be lost. While awaiting a response, AIP will set the timer to 20% of the rental time.

* 7. When the timer runs out, the AIP destroys the IP address and sends an address remove request to the IP-15 context mate. When the timer runs out with APS, APS deletes the IP address.

* 8. Upon receipt of the address remove request, the IP context manager sends an address remove request to the mobile host. The mobile host stops using the IP address.

Operation of the APC The AIP sends two messages at each address lookup event. Normally, the starting point sends a request and the destination responds to this request:. by sending either a positive or a negative response.

• · · 25 When AIP receives a dynamic address lookup request from a local service user, it checks to see if it * has any IP address available in its own address book. If a free IP address is found, AIP completes the request without asking for the IP address from the APS server further away. Otherwise, it must interactively send address lookup requests to other known 30 APSs.

The behavior of the source APC when leasing addresses from a remote APS:. is illustrated by the generalized state diagram of Figure 8. The NO_ENTRY state is an imaginary state that does not represent any state. The first state change occurs when the service user initiates the AIP-: 35 address lookup function at the local DXT exchange. By default, AIP creates a temporary export associated with a local call and gives it ACQUIRING_ADDRESS status. In this text, this temporary export is referred to as address export or export only. If AIP does not have a free IP address in the local address pool, it selects the APS server and sends an ADDRACQreg request to it.

When AIP is in ACQUIRING_ADDRESS mode, it waits for a response.

5 If a positive ADDRACQ response arrives, the AIP updates the address table export, assigns an ASSOCIATED state, and completes the local request. If the AIP receives a negative ADDRACQreq response, it selects another APS, if any, and resends the same ADDRACQreq request.

In both ACQUIRING_ADDRESS and ASSOCIATED mode, AIP can receive more than one positive ADDRACQres response. AIP always selects the first incoming response. If the response arrives in ACQUIRING_ ADDRESS mode, AIP shifts the export to ASSOCIATED mode, sets the rental timer, and completes the local request. If the delayed response arrives in ASSOCIATED mode, the AIP will reject it.

15 AIP leases IP addresses to users for a period of time known as the Lease Period. The default rental period is 12 hours. On the other hand, APS leases IP addresses to other AlPies for a total rental period of twice the rental period. If the user releases the IP address before the total lease period expires, the AIP sends an address release request ADD-20 RELreq to the appropriate APSi and destroys the table export associated with the released address.

After the rental timer has reached the rental period, AIP attempts to renew the IP address lease. It sends the address to the new • · · *. request ADDRENreq and put the address table export into RENEWING_1 mode.

25 Before entering RENEWING_1 mode, AIP must ensure that the user still holds the IP address. It sends the user an address authentication * ·:: request and puts the address export into VERIFYING_ADDRUSE mode. Her AIP counter- · · ·; returns a negative address authentication response in this state, it releases the IP address. Otherwise, AIP will send an address lease renewal request to LE- *: ··: 30 ASRENreq for APS, set the address export timer to · ”*: 80% of rental time, and move export to RENEWING_1.

· »·. \ Triggering the address export timer in RENEWING 1 causes the AIP to send another address lease update request ADD- • · * ·; ♦ * RENreq, sets the address export timer to 20% of the rental time, and: 35 moves export to RENEWING 2 mode.

14 107677 In RENEWING_2 mode, when the timer is triggered, AIP releases the IP address by sending an address release request to the user and destroying the address export.

If the AIP in any mode receives a positive reservation request for renewal 5 in LEASRENreq, it sets the address export timer for the lease period and moves the export back to ASSOCIATED mode.

Operation of APS

Referring to Figure 9, when the APS receives the ADDRACQreq address lookup request, it allocates the IP address and gives ASSOCIATED_10 REMOTE status to the address export. APS keeps the IP address in this mode for the total rental period. If APS receives a LEASRENreq rental renewal request, it resets the rental timer and responds with a LEASRENres response. If the rental timer expires, APS releases the IP address.

When APS allocates an IP address to a local user, it gives ASSOCIATED LOCAL status to the address-15 server and sets its timer for the rental period. When the timer expires, APS puts the address export into VERIFYING_ADDRUSE_LO-CAL mode and verifies the use of the IP address by sending a request to the local user to verify the address. If APS receives a positive authentication response, it will return the address export back to ASSOCIATED_LOCAL. 20 Otherwise, it will destroy the address export.

When receiving a RESTOREreq request in ASSOCIATED_LOCAL mode, ASP resets the export timer and completes the request, while in VERIFYING_ADDRUSE_LOCAL mode, APS moves the export to ASSO- · · · CIATED_LOCAL mode and completes the request.

***. 25 II DAAP protocol The three units associated with the DAAP protocol are shown in Figure 10: DAAP Client (DAAPC), DAAP Proxy (DAAPP), and DAAP Server (DAAPS).

• · *; The DAAPC is a protocol unit located on the network layer in the terminal data device. Figure 10 also illustrates how the DAAP protocol is located in the proto-30 collapse stack in different units. The DAAPC requests the IP address from the DAAPS after the logical link is established between the mobile host and the mobile station.

• M

Information about the subnet, address pools, and user rights is configured in the network database. A DAAP that is assigned an IP network identifier is called * ·; · * DAAPS, and a non-networked DAAP is called a DAAPP. Both DAAPS and: 35 DAAPP are located simultaneously in the DAAP protocol unit. DAAP acts as a ·; ··· DAAPP in the following cases: 1) DAAP is not given an address key, but (DAAP is DAAPP only), 2) DAAP is given an address space, but the address halves are currently exhausted, or 3) the user is not authorized to request IP addresses from local address pools. If, for some reason, the IP address cannot be allocated from the address space at the local DXT exchange, the 5 local DAAPs in this DXT exchange will act as a proxy (DAAPP) trying, on behalf of the DAAPC, to retrieve the IP address from the DAAPS remote server. When a DAAP receives a request for an address in a DXT exchange, it checks to see if one of its address pools has an available IP address. If a free IP address is found, the DAAP completes the request without retrieving the IP address from the remote DAAPS server. Otherwise, it must interactively send address lookup requests to other known DAAPS servers. When DAAPS assigns an IP address to a host, it creates an export, called an address table, that stores the IP address and the user's current location. In order to allocate the IP address, the DAAPS server must know both the user ID and the end data device identifier. 15 The previous identifier is required to bind the IP address to either the end user or the end mobile station. An Individual Short Subscriber Identity (SSI) number can serve this purpose. The latter identifier is necessary to distinguish between several data devices connected to the same mobile station. NSAPI (Network Service Access Point Identifier) may be used for this purpose. 20 The DAAPS leases the IP address to the DAAPC for a total lease term. DAAPC will renew your rental once the rental period has expired.

Figures 11, 12, and 13 illustrate exemplary DAAP address allocation scenarios.

• · ·

Example 5 Figure 11 shows how a mobile host requests an IP address from a local address space (DXT exchange address space of the user's location). The following steps take place with reference to Figure 11.

'· **: 1. The mobile host connected to the mobile station requests an IP address. The DAAPC sends an IP address request over the air interface.

*: ** ·: 30 2. The IP address request arrives at the DXT exchange. The local DAAPS, after successful validation of the user's right, picks up a free IP address. \ t I do the address pool. The local DAAPS associates the IP address with the user identifier SSI and the network service access point identifier NSAPI, leasing the IP - **; · 'address in this way to the mobile host for the total lease period. Local 35 DAAPS sends the IP address response back to the DAAPC.

• · 16 107677

Example 6

Figure 12 illustrates how a mobile host requests an IP address from a remote address space (an address space in a DXT exchange other than the one currently used by the user). Referring to Figure 12, the following 5 steps occur.

1. The mobile host connected to the mobile station requests an IP address. The DAAPC sends an IP address request over the air interface.

2. The IP address request arrives at the DXT exchange. After successful validation of the user right, the local DAAP attempts to retrieve the IP address from the 10 address pool, but fails. It then acts as DAAPP, retrieves from the database a list of DAAPS servers from which the user can retrieve the IP address. The local DAAP interactively sends an IP address request to the DAAPS servers until it receives a positive response from one of them.

3. Upon receiving the IP address request, DAAPS associates the IP address-15 user ID with the SSI and the network service access point identifier with NSAPI, thus leasing the IP address to the DAAPC for a total lease period. For example, the total rental period can be twice the rental period. DAAPS sends the IP address response back to DAAPP.

4. Upon receiving the IP address response, the DAAPP sends the IP address-20 response to the DAAPC.

Example 7 *. Figure 13 shows how DAAPC renews address leasing from · · · DAAPS. Referring to Figure 13, the following steps take place.

1. The rental of the address, which is half the total rental time, is • · · '**. 25 completed. DAAPC sends a request for renewal of the address lease locally

to the DAAP in that DXT exchange. While awaiting a response from DAAPC

• · · * · · sets the timer to 30% of your total rental time.

• · ·: 2. Upon receipt of a request, DAAPP will send its lease request to DAAPS.

*: 1 ·: 30 3. Upon receipt of an address lease renewal request · ***: DAAPS will renew the total lease period to DAAPC and respond with a positive lease # #. 1. rausha's renewal response.

♦ · ·:; j .: 4. Upon receiving this response, the DAAPP forwards it to the DAAPC. Upon receipt of the response, DAAPC will reset the rental timer.

· «· · ♦ 17 107677

Figure 13 also shows an alternative case where the lease renewal request disappears between the local DAAPP and the DAAPS: 1 *. The rental of the address, which is half of the total rental period, has ended. DAAPC sends an address lease renewal request to DAAP 5 at the local DXT exchange. While awaiting a response, DAAPC sets the timer to 30% of your total rental time.

* 2. Upon receipt of the request, DAAPP will send a request for renewal of the address lease to DAAPS. This request will be lost.

* 3. The timer has tripped in DAAPC. The DAAPC sends a request to renew the address lease to the DAAPP. While awaiting a response, DAAPC sets the timer to 20% of its total rental time.

* 4. DAAPP forwards the lease request for address lease to DAAPS. This request will be lost. After the total rental time has elapsed, both DAAPC and DAAPS will delete the IP address.

15 Operation of DAAPC The behavior of the source DAAPC when it leases addresses from remote DAAPS is illustrated by the generalized state diagram shown in Figure 14. The NO_ENTRY state is an imaginary state that does not represent any state. The first state change occurs when the service user initiates 20 DAAPC address request functions on the mobile host. DAAPC creates an address export and gives it ACQUIRING_ADDRESS status. DAAPC sends an address lookup request to DAAP at your local DXT exchange. If this DAAP does not have free IP · *: *. address in the local address pool, it selects the DAAPS server, creates a proxy. . ·. early address export to the cache memory, give it ACQUISITION status, and send.! **: 25 an ADDRACQreq request to it.

• · # ... t In ACQUISITION mode, DAAPP is waiting for a response. If a positive ADDRACQres response arrives, the DAAPP destroys the temporary address export and • · · passes the ADDRACQres response to the DAAPC to complete the local request. If the DAAPP receives a negative ADDRACQres response, it selects another DAAPS, if any, and resends ** · * ... · * the same ADDRACQreq request.

:! ·. DAAPP can receive more than one ADDRACQres • · · response. DAAPP always selects the first incoming response and rejects • · ♦ T subsequent responses.

18 107677 The DAAPC leases the IP address to the user for a period of time called the rental period. It receives the rental value from the ADDRACQres response. The default rental period is 12 hours.

On the other hand, DAAPS leases IP addresses to DAAPC for a total lease-5 period of twice the rental period. If the user releases the IP address before the total lease period expires, the DAAPC destroys the address and sends the address release request to ADDRELreq to the DAAPS concerned.

Once the rental timer has reached the rental period, DAAPC will attempt to renew the lease of the IP address. It sends the address lease renewal-10 request to ADDRENreq, puts the address table export into RENEWING_1, and sets the address export timer to a value equal to 80% of the renter.

Triggering the address export timer in RENEWING_1 mode causes DAAPC to send another address lease request to -15 non ADDRENreq, set the address export timer to a value equal to 20% of the renter, and move the export to RENEWING_2 mode.

In RENEWING_2 mode, when the timer expires, the DAAPC releases the IP address by sending an address release request to the user and destroying the address export.

20 In any mode, if the DAAPC receives a LEASRENreq positive lease renewal request, it sets the address export timer to the lease period and moves the export back to ASSOCIATED mode.

How DAAPS Works ♦ · ·

Referring to FIG. 15, when DAAPS receives an ADDRACQreq address request request, it allocates an IP address and assigns an ALLOCA ... TED state to the address export. DAAPS maintains the IP address in this mode for the total rental period.

• · «*;] / If DAAPS receives a LEASRENres rental renewal request, it will • 1 · reset the rental timer and respond with a LEASRENres response. When the lease-in timer expires, the DAAPS releases the IP address.

• ·. ♦ ··. The specification merely illustrates preferred embodiments of the invention.

However, the invention is not limited to these examples, but may vary within the spirit and scope of the appended claims.

··· • 1 • · ··· • · ♦ * · · 2 ♦ 1 · 3 ·

Claims (13)

107677 Patent Claims A method for allocating an Internet Protocol type, or IP type, address to a mobile host in a mobile communication network comprising mobile switching centers (DXT1, DXT2) and a plurality of mobile hosts (MH), said method comprising dynamically allocating an IP address to a mobile to the host (MH) of the cellular network address space during the lease period, associating the allocated IP address with a user identifier (SSI) and a data device identifier (NSAPI) used to identify the mobile host 10 (MH) in the mobile communication system. The method of claim 1, characterized by the steps of determining the location of the mobile host with the identifier of the mobile switching center (DXT1, DXT2) currently serving the mobile host (MH), associating the location information of the mobile host with the allocated IP address. A method according to claim 1 or 2, characterized by the steps of transmitting an IP address request from the mobile host to a serving mobile switching center (DXT) serving as an address allocation server, unable to allocate IP addresses, allocating an IP address from the address pool for said lease period. allocated IP address of mobile host (MH):; *; with a user identifier (SSI) and a data device identifier (NSAPI), • · · 25 transmitting said allocated IP address to the mobile host (MH). A method according to claim 1, 2 or 3, characterized by the 11 u steps • · · '* requesting an IP address from the mobile host to a serving mobile switching center (DXT) acting as an address allocation client 30 incapable of allocating the IP. * ... · * sending a new IP address request from the serving mobile switching center to the remote PBX server, ···. allocating an IP address from the address pool during said lease period and associating said allocated IP address with a mobile host (MH) user ID: 35 point (SSI) and a data device identifier (NSAPI), • * 107677 sending said allocated IP address to the serving mobile switching center ( DXT), associating said allocated IP address with a mobile host (MH) user identifier (SSI) and a data device identifier (NSAPI) in the serving mobile switching center, transmitting said allocated IP address to the mobile host (MH). A method according to claim 4, characterized by allocating said IP address to said remote address allocation server for a second lease period longer than said 10 lease times used in the serving mobile switching center. The method of claims 1 to 5, characterized by sending an address use authentication request to the mobile host at the end of said lease period, re-allocating the IP address during said lease period when receiving a positive address use authentication response from the mobile host, destroying the IP address allocation when no deprecation response is received. A method according to claim 6, characterized by sending, as a result of said positive address use authentication response, an address update request to said further address allocation server, renewing said second lease period to said IP address, · · Its. A method according to claim 1, 2 or 3, known from the steps of * ... · * placing an address allocation protocol (DAAP) client on a mobile:] ·, host, • »I] ··· [placing an address allocation protocol server in said allocation system. · *. ** server, · ·: 35 establishes a logical connection between the DAAP client and the DAAP server *: ··, 107677 uses the DAAP protocol to access the DAAP client and the DAAP server over said logical connection. The method of claim 8, characterized by a mobile switching center serving step 5, which is unable to provide the mobile host requesting the IP locally, acting as a proximity server for transmitting communication between the remote DAAP server and the DAAP client. A method according to claim 8 or 9, characterized by the steps 10 transmitting an address usage renewal message from the DAAP client to the DAAP server in response to using a predetermined portion of said lease period, renewing said lease period to said IP address on said DAAP server, sending an resetting the rental period timer in the DAAP client in response to receiving a positive response, deleting the IP address in the serving mobile switching center in the DAAP client in response to receiving a negative response or not responding 20. The method according to claim 10, characterized by ·. that the user identifier is a Mobile Subscriber Identity (SSI) and the data device • • * * ... node is a network service access point identifier (NSAPI). • · · • 7 12. Mobile network comprising • * · **: · * 25 numerous mobile hosts (MH, mobile switching centers (DXT1, DXT2), and • · ·; Internet Protocol type or IP type service for mobile • V: hosts, characterized in that at least one of the mobile switching centers (DXT1, DXT2) is arranged · · · · dynamically allocate the IP address of the mobile host (MH) from the mobile network address space to the lease period and associate this allocated IP -i: ···: you with a user identifier (SSI) and a data device identifier (NSAPI) used to identify a mobile host (MH) in the mobile communication system. The network of claim 12, characterized in that the user identifier is a mobile subscriber identifier (SSI) and the data device identifier is a network service access point identifier (NSAPI). * ·· «** · <· · • • • • • • • • • • • · · · · · ·········································································································· · «• · · •« * · f • ♦ ♦ ··· · • ♦ • 1 • M • «· •» I • · · 2 ♦ · 107677