Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
  • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
  • H04L69/169—Special adaptations of TCP, UDP or IP for interworking of IP based networks with other networks 
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L61/00—Network arrangements, protocols or services for addressing or naming
  • H04L61/50—Address allocation
  • H04L61/5007—Internet protocol [IP] addresses
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L61/00—Network arrangements, protocols or services for addressing or naming
  • H04L61/50—Address allocation
  • H04L61/5007—Internet protocol [IP] addresses
  • H04L61/5014—Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L61/00—Network arrangements, protocols or services for addressing or naming
  • H04L61/50—Address allocation
  • H04L61/5053—Lease time; Renewal aspects
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L61/00—Network arrangements, protocols or services for addressing or naming
  • H04L61/50—Address allocation
  • H04L61/5061—Pools of addresses
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L61/00—Network arrangements, protocols or services for addressing or naming
  • H04L61/50—Address allocation
  • H04L61/5084—Providing for device mobility
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
  • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W8/00—Network data management
  • H04W8/26—Network addressing or numbering for mobility support
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
  • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]

Definitions

• the invention relates to address allocation for Internet-type protocol traffic in a mobile communications system.
• Mobile communications system refers generally to any telecommunications system which enables wireless communication when users are moving within the service area of the system.
• a typical mobile communications system is a Public Land Mobile Network (PLMN).
• PLMN Public Land Mobile Network
• the mobile communica- tions network is an access network providing a user with wireless access to external networks, hosts, or services offered by specific service providers.
• IP Internet Protocol
• NETID first field of an IP address
• Mobile IP In order to enhance mobility in the Internet, a Mobile IP protocol for IP version 4 has been introduced by the Internet Engineering Task Force (IETF) in the standard RFC2002.
• Mobile IP enables the routing of IP datagrams to mobile hosts, independently of their point of attachment in the subnetwork.
• Mobile Node MN' also called Mobile Host MH refers to a host that changes its point of attachment from one network or subnetwork to another.
• a mobile node may change its location without changing its IP address; it may continue to communicate with other Internet nodes at any location using its (constant) IP address.
• a datagram is encapsulated and routed to a known decapsulation agent, which decapsulates the datagram and then correctly delivers it to its ultimate destination.
• Each mobile node is connected to a home agent over a unique tunnel, identified by a tunnel identi- bomb which is unique to a given Foreign Agent/Home Agent pair.
• the mobile host is identified with respect to its home IP network.
• the Mobile IP solves the mobility management problem of the basic IP by adapting to the inflexibility of the IP address, but IP the mobile host is still identified with respect to its home IP network.
• the prior art mobile IP schemes are not very suitable for a mobile communication system which does not employ IP as a network protocol.
• the TETRA network which tunnels IP traffic through a non-IP protocol, is an example of such a system.
• the TETRA system is a digital mobile communication system developed primarily for professional and governmental users, such as the police, military forces, oil plants, 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 of how a DXT can be connected to the internet.
• each DXT unit may have its own direct "exit" via an adjacent router, such as router 1 for DXT1 and router 2 for DXT2 in Figure 1 , for forwarding IP packets from the TETRA network to the Internet and vice versa.
• an adjacent router such as router 1 for DXT1 and router 2 for DXT2 in Figure 1
• gateway DXTs are connected to an Internet router (e.g. DXT1 to router 1 in Figurel), the other DXTs being connected to the Internet over these gateway DXTs.
• mobile hosts are able to move from one cell to another and thereby arbitrarily roam between the DXTs.
• the mobile host may start an IP data exchange in one network and complete it in another.
• the movement of the mobile hosts among TETRA networks leads to a situation where the netid identifier in the IP address of the mobile does not necessarily correspond to the current network.
• an IP address can be allocated to the host There are two ways of how an IP address can be allocated to the host: 1) an IP address can be permanently configured in the mobile host, or 2) the host can acquire an IP address either at the system start-up or at the start of an IP service. The second way is preferable for two reasons.
• IP users There may be over sixteen thousand IP users bound to the same DXT.
• the users may be spread over a wide geographical area. If the static IP address configuration is adapted, changes to the network configuration require a manual reconfiguration of each host in the network. In other words, the IP network management becomes inflexible.
• the exponential growth of the Internet results in exhaustion of the unique IP address space. It becomes harder for organizations to acquire additional unique address space. This means that the amount of users in an organization may be higher than the amount of available IP addresses. In such a case, a dynamic IP address allocation provides most of the users with IP service.
• the DHCP is defined in RFC 1541. It is intended for use in local area networks (LANs) over a TCP/IP protocol stack, i.e. in the Internet environment, and thus it is not fully applicable to mobile communications networks which do not employ IP as a network protocol, such as the TETRA.
• LANs local area networks
• IP IP
• the DHCP communicates address information between the end host and the DHCP client, which introduces an additional load on the air interface in the TETRA.
• the DHCP utilizes the UDP protocol as a transport protocol, which adds an overhead in form of the IP and a UDP header to each DHCP message.
• the DHCP client broadcasts a DHCP DISCOVER message on its local physical subnet, which is not a normal broadcast in the TETRA infrastructure.
• the DHCP restricts address acquisition to the local network. In a mobile environment, such as the TETRA, it is worthwhile to allow address acquisition also from remote networks.
• An object of the invention is a new dynamic address allocation method and a mobile communication system which overcome or alleviate the above described problems.
• IPv4 or IPv6 addresses Each mobile communication network is assigned a set of unique IP addresses (IPv4 or IPv6 addresses, for example), so the Internet routers will see . the mobile networks as ordinary local IP networks.
• An IP address is a pair of the network and host identifiers.
• the network identifier (netid) specifies a mobile IP network and the host identifier specifies a mobile host in the mobile network.
• the addresses available under the assigned network identifier are collectively referred to as the address space. IP addresses are allocated to users from the available address spaces.
• the address space may be divided into static and dynamic address subspaces. Static IP addresses are individually assigned to particular users.
• the dynamic subspace may be further di- vided into multiple address pools.
• An address pool is defined with a pair of lower and higher edge addresses.
• the address pools may be shared by several organizations and, in such a case they are referred to as organization access rights to acquire IP addresses.
• an IP subnetwork can be formed around one or multiple switches, such as DXTs. In the latter case, several switches will be logically organized under the same netid prefix and will share the same host address space.
• the possibility to distribute the organization address space among multiple networks and to interactively acquire an IP address from them increases the robustness of the address acquisition method; the user does not depend on a single address distribution cen- ter. This also increases the address hit rate; if a particular address space is exhausted, the user may try another network.
• the mobile host is identified by a unique pair of a user identity and a data equipment identity which are bound to an IP allocated to the mobile host in the mobile communications network.
• the user identity enables to bind the allocated IP address to a specific end user or to a specific mobile station in the mobile communication network and to verify his/her permission to use the IP service.
• the user identity is a mobile subscriber identity.
• the end data equipment identity enables to distinguish between several data equipments connected to the same mobile station.
• NSAPI network service access point identifier
• the term 'end data equipment' refers to any data equipment or IP application connected to, integrated into or associated with a mobile station.
• the use of the user identity and the data terminal identity provide a unique identification for the mobile host, without any relation to the IP network. Further, in most communication systems, such as TETRA, this allows to re-use the identities already available in the communication system.
• the IP address is preferably allocated for a predetermined period, called a lease period.
• the allocated IP addresses with their associations, such as the user identity and the data equipment identity, are stored in a data structure called an address table.
• the IP address is deallocated (freed) or the allocation is renewed.
• the information about the subnets, address pools and user rights are configured to databases in the network entities.
• a network entity may have an assigned address space or not. If a network entity does not have an assigned local address space, or it is not able to allocate an IP address to a mobile host for some other reason (e.g. the local address pool is currently exhausted, or the mobile host or user is not permitted to acquire IP addresses from the local address pool), the net- work entity may acquire an IP address from a remote network entity. In the latter case the local network entity functions as a client and the remote network functions as a server from the point of view of IP address allocation. The client network entity leases the IP addresses from the remote servers on behalf of local users, i.e. mobile hosts. This minimizes signaling taking place over the air interface.
• the information about the subnets, address pools and user rights are configured to databases in the network entities but an end-to-end allocation protocol is used to communicate address information between a network entity allocating IP ad- dresses (an address server) and the mobile host itself. If the local network entity is not able to allocate an IP address (e.g., it has no local address pool, or the local address pool is exhausted), the local network entity acts like a "proxy" server trying, on behalf of the mobile host, to acquire an IP address from a remote address server. This approach requires a specific protocol entity re- siding in the end data equipment in a network layer. Further, in the worst case, more messages may be transmitted over the air interface due to the allocation process than in the first embodiment. On the other hand, mobility management may be less complex.
• Figure 1 illustrates a TETRA network connected to the Internet
• Figure 2 illustrates the difference between AIP and DAAP ap- proaches of the present invention
• Figure 3 shows an address table
• Figures 4, 5, 6 and 7 are signaling diagrams showing illustrative scenarios of the AIP address allocation
• Figure 8 is a state diagram illustrating the operation of APC
• Figure 9 is a state diagram illustrating the operation of APS
• Figure 10 illustrates the network entities and protocol entities involved with DAAP protocol
• Figures 11 , 12 and 13 are signaling diagrams showing illustrative scenarios of the DAAP address allocation
• Figure 14 is a state diagram illustrating the operation of DAAPC.
• Figure 15 is a state diagram illustrating the operation of DAAPS.
• the present invention can be generally applied to mobile communications systems for providing IP mobility.
• the invention is particularly suitable used for providing IP mobility management in a mobile telecommunications system that employs a non-IP protocol for routing IP traffic, the TETRA network being an example of such a system.
• the preferred embodiments of the invention will be described by means of the TETRA system without limiting the invention to this particular mobile communications system.
• a mobile host MH may consist of a laptop computer PC connected to a mobile station radio.
• the MH can be an integrated combination of a small computer and a cellular telephone, similar in appearance to the Nokia Communicator 9000 series.
• Yet further embodiments of the MH are various pagers, remote-control, surveillance and/or data acquisition devices, etc.
• the TETRA system may include any number of TBSs, DXTs, MHs and routers, as well as other network elements which are relevant to the present invention.
• the TETRA IP network is a collection of DXTs that share the same IP address network prefix.
• One TETRA network may be subdivided into two or more TETRA IP networks. According to the current scenarios, each TETRA network is assigned a set of unique IP addresses (IPv4 or IPv6 addresses, for example), so the Internet routers will see TETRA networks as ordinary local IP networks.
• the IPv4 address is composed of 32 bits and presented as a pair of the network and host identifiers.
• the network identifier (netid) specifies a TETRA IP network and the host identifier specifies a mobile host in the TETRA network.
• IP subnetwork can be formed around one or multiple DXTs. In the latter case, several DXTs will be logically organized under the same netid prefix and share the same host address space.
• a TETRA subnetwork 1 is formed around DXT1 and assigned a netid ' 192.1.1.0 '
• a TETRA subnetwork 2 is formed around DXT2 and assigned a netid ' 192.1.2.0 '
• Organization of IP networks around DXTs requires routing capabilities on the links between them. Each single- or multi-DXT network must be able to forward datagrams addressed to other TETRA IP networks.
• the DXT1 and the DXT2 are interconnected by a link 10.
• an Address Information Protocol (AlP) and a Dy- namic Address Allocation Protocol (DAAP).
• AlP Address Information Protocol
• DAAP Dy- namic Address Allocation Protocol
• the DAAP and the AlP apply a similar technique to dynamic address management, i.e. an address lease mechanism.
• the difference between the DAAP and the AlP lies in protocol architecture.
• the AlP protocol has been designed in compliance with the existing TETRA packet data standard, while the DAAP protocol requires a new protocol entity in the mobile host as well as new messages sent over the air interface.
• Figure 2 demonstrates the difference between the two approaches.
• the grey-coloured rectangles show the elements that the AlP or the DAAP do not see.
• the APC and APS units on local and remote DXTs maintain the address information.
• the APC leases IP ad- dresses, on behalf of local users from remote APS servers.
• the DAAP is an end-to-end protocol, which means that the address information is communicated between the address server (DAAPS) and the host itself (DAAPC).
• DAAPS address server
• DAPC host itself
• the DAAPP acts as a forwarding machine: The DAAPP simply directs the control messages to correct destinations.
• the AlP protocol manages the IP service in the TETRA and it includes IP mobility management.
• the AlP protocol resides on the top of the TETRA transport layer; consequently, it exchanges control messages with peers utilizing the underlying transport service.
• the protocol is not required to route datagrams over the shortest path.
• Local processes can request IP ad- dress information from the AlP at least in two cases. In the first case, when the user is requesting the IP service, the process that is responsible for resource allocation requests an IP address from the AlP. Second, before the TETRA routing process forwards the IP datagram, it requests the current location as- sociated with the destination IP address from the AlP.
• the location of the mobile host may be specified with the identification number of a TETRA network node. In the preferred embodiment, in the IP service, location is defined with the identity (address) of the DXT exchange.
• the AlP entities allocate IP addresses to users from the available address spaces. Allocated IP addresses 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. The static IP addresses are individually assigned to particular users.
• An AlP entity which is assigned an IP network identifier is called an Address Pool Server (APS) and an AlP entity with- out an IP network identifier is called an Address Pool Client (APC). Both the APS and APC may co-exist in the AlP process unit.
• APS Address Pool Server
• APC Address Pool Client
• the AlP entity acts as the APC in the following cases: 1) The AlP is not assigned an address space (the AlP is a pure APC), 2) the AlP is assigned an address space; however, the address pools are currently exhausted, and 3) The user has no permission to acquire IP addresses from local address pools. If for some reason the AlP can not allocate an IP address from the local address space, it may acquire an address from a remote APS.
• the APS or APC When the APS or APC issues an IP address to the user, it creates an entry in the address table storing the IP address and the user current loca- tion.
• the AlP In order to allocate an IP address, the AlP must know both the user identifier and the identifier of the end data equipment or application. The former identifier is necessary to bind the IP address either to the end user or to the end mobile station.
• the Individual Short Subscriber Identity (SSI) number may serve for this purpose.
• the latter identifier is necessary to distinguish between several data equipment (or applications) connected to the same mobile station.
• the Network Service Access Point Identifier (NSAPI) may be used for this purpose.
• An example of a possible address table with a minimal set of fields is shown in Figure 3.
• the IP Address entry field lists all of the allocated IP addresses.
• the Location DXT field indicates the current locations of the IP users.
• the Static/Dynamic field shows whether or not the address is permanently assigned to the user.
• the User Identifier field associates IP addresses with end users.
• the NSAPI (Network Service Access Point Identifier) field identifies the end data equipment. In the TETRA network, the user may simultaneously use up to 13 data equipment. Number 0 is reserved for a special use and number 15 for multicast. As a result, there may be more than one entry for the same user, i.e. the same SS1 (like SSI A in Figure 3) but different NSAPIs and IP addresses (like IP address ' 192.1.1.1 ' and NSAPI 1 as well as IP address ' 192.1.1.52 ' in Figure 3)
• the entry (entries) of a single user in the table of Figure 3 is called a user IP context of the respective user.
• the IP context of the user may contain several entries.
• the user IP context is created, when the APC or the APS issues an IP address to the user. Normally the IP address is issued in response to an address acquisition request from the user.
• the address acquisition request contains the user and data equipment identifiers SSI and NSAPI.
• the APC or APS receives the address acqui- sition request from the mobile host, it looks up the address table for an entry whose user and data equipment identifiers match with ones in the received request. If the APC or the APS finds such an entry, it completes the request process by returning the IP address back to the caller.
• the APC or the APS will attempt to allocate an IP address from the local address space. If there is no spare IP address in the address pool, the APC or APS sends an address acquisition request to the remote APS server.
• the remote APS server obtains an IP address from an address pool and sends it back to the requesting entity.
• the address may be issued for a predetermined period of time which may be renewed with a specific renewal procedure. The default period may be 12 hours, for example. However, the default time should preferably be such that the IP address would not change during the time the mobile host is registered to the system.
• the user requests the entry or the IP context in the address table to be deleted and the IP address to be returned back to the address pool. If the IP address is permanently allocated, it cannot be allocated to another mobile host.
• the IP context may also be transferred from one DXT to another in the handover situation.
• Figure 4 shows how the host acquires an IP address from the local address space (the address space on the same DXT where the user is located). The numbering refers to that used in Figure 4. 1.
• the mobile host connected to a mobile station acquires an IP address. It sends an IP address request over the air interface.
• the IP address request arrives at the DXT, at the IP context manager.
• the IP context manager forwards the address request to the local AlP.
• the local AlP after successful validation of the user permission, picks up a spare IP address from an address pool. It associates the IP address with an user identifier SSI and a network service access point identifier NSAPI, thus leasing the IP address to the mobile host for a lease period.
• the local AlP sends an IP address response back to the IP context manager. 4. On receipt of the response, the IP context manager allocates the
• IP context to the user and sends an IP address response back to the mobile host.
• Figure 5 shows how the mobile host acquires an IP address from a remote address space (an address space on a DXT other than the one where the user is located). Referring to Figure 5 the following steps take place.
• the mobile host connected to a mobile station acquires an IP address. It sends an IP address request over the air interface.
• the IP address request arrives at the DXT, at the IP context manager.
• the IP context manager forwards the address request to the local
• the local AlP after successful validation of the user permission, attempts to acquire an IP address from an address pool, but it fails.
• the local AlP obtains from the database a list of APSs from which the user may acquire an IP address.
• the local AlP interactively sends an IP address request to APSs until it receives a positive response from one of them.
• an APS On receipt of the IP address request, an APS associates the IP address with user identifier SSI and network service access point identifier NSAPI thus leasing the IP address to the AlP-sender for a total lease period. The total period of time may be twice the lease period, for example.
• the APS sends an IP address response back to the AlP-sender. 5.
• the local AlP On receipt of the IP address response, the local AlP associates the IP address with an user identifier SSI and a network service access point identifier NSAPI, thus leasing the IP address to the mobile host for the lease period.
• the local AlP sends an IP address response back to the IP context manager.
• the IP context manager allocates the IP context to the user and sends an IP address response back to the mobile host.
• Example 3 Figure 6 shows how the local AlP renews address lease (in this context, the local AlP is an APS on the same DXT where the user is located). Referring to Figure 6 the following steps take place.
• the address lease has expired.
• the local AlP sends an address use verification request to the IP context manager.
• the IP context manager sends the address use verification request to the mobile host.
• the mobile host responds with a positive response back to the IP context manager.
• the IP context manager On receipt of the response, the IP context manager sends a positive response to the local IP. The AlP leases the IP address for the next lease period. On receipt of negative response or no response, the AlP deletes the allocation of the IP address.
• Figure 7 shows how the APC renews an address leased from the APS. Referring to Figure 7 the following steps take place.
• the address lease has expired.
• the AlP sends an address use verification request to the IP context manager.
• the IP context manager sends the address use verification request to the mobile host. 3. If the IP address is in use, the mobile host responds with a positive response back to the IP context manager.
• the AlP On receipt of the positive response, the AlP sends the APS an address lease renewing request.
• the APS On receipt of the address lease renewing request, the APS re- news the total lease to the APC-sender and replies with a positive lease re- newing response. On receipt of this response, the AlP renews the address lease to the user.
• Figure 7 also shows an alternative case where the lease renewing request is lost between the local AlP and APS.
• the alternative steps are: 5 * .
• the AlP sends the APS an address lease renewing request.
• the request is lost. While waiting for a response, the AlP sets the timer to 80% of the lease period.
• the APS removes the IP address and the AlP sends the APS a second lease renewing request. The request is lost. While waiting for a response, the AlP sets the timer to 20 % of the lease period.
• the AlP deletes the IP address and sends the IP context manager an address remove request.
• the APS removes the IP address. 8 * .
• the IP context manager forwards the address remove request to the mobile host. The mobile host stops using the IP address.
• the AlP sends two messages in each address acquisition ex- change. Normally, the originator sends a request and the destination will reply to that request by sending either a positive or negative response.
• the AlP When the AlP has received a dynamic address acquisition request from the local service user it checks whether there is a spare IP address in one of its address pools. If a vacant IP address is found, the AlP will complete the request without acquiring an IP address from a remote APS server. Otherwise it must interactively send address acquisition requests to other known APSs.
• the behaviour of the originating APC, when leasing addresses from the remote APS is illustrated by a generalised state diagram shown in Figure 8.
• the NO_ENTRY state is an imaginary state that represents no state at all.
• the first state transition occurs when the server user on the local DXT invokes the AlP address acquisition function. It is assumed that the AlP will create a temporal entry associated with a local call and assign it the ACQUIRING_ADDRESS state. In this text, the temporal entry will be referred to as an address entry or an entry. If the AlP has no a spare IP address in a local address pool it will choose an APS server, and send an ADDRACQreq request to it.
• the AlP In the ACQUIRING_ADDRESS state, the AlP is waiting for a response. If a positive ADDRACQres response arrives, the AlP updates the ad- dress table entry, assigns the ASSOCIATED state and completes the local request. If the AlP receives a negative ADDRACQres, it selects another APS, if any is left, and retransmits the same ADDRACQreq.
• the AlP may receive more than one positive ADDRACQres response.
• the AlP al- ways chooses the first response arrived. If a response arrives at the ACQUIRING_ADDRESS state, the AlP moves the entry to the ASSOCIATED state, sets the lease timer, and completes the local request. If a late response arrives at the ASSOCIATED state, the AlP discards it.
• the AlP leases IP addresses to users for a certain period of time, which is referred to as a lease period.
• the default lease period is equal to 12 hours.
• the APS leases IP addresses to other AIPs for a total lease period which is twice the lease period. If the user releases an IP address before a total lease expiration, the AlP sends an address release request ADDRELreq to the appropriate APS and deletes the address table entry associated with the released address.
• the AlP When the lease timer has reached the lease period, the AlP attempts to renew the lease of the IP address. It sends an address lease renewing request ADDRENreq and moves the address table entry to the RENEWING state. Before transition to the RENEWING_1 state, the AlP must verify whether the user still has the IP address. It sends an address verification request to the user and moves the address entry to the VERIFYING_ADDRUSE state. If the AlP receives a negative address verification response in this state, it releases the IP address. Otherwise the AlP sends an address lease renew- ing request LEASRENreq to the APS, sets the address entry timer to a value that is equal to 80% the lease period, and moves the entry to the RENEWINGJ state.
• the address entry timer expiration in the RENEWING_1 state causes the AlP to send the second address lease renewing ADDRENreq re- quest, set the address entry timer to a value equal to 20% of the lease period, and move the entry to the RENEWING_2 state.
• the AlP releases the IP address by sending an address release request to the user and deleting the address entry.
• AlP in any state receives a positive lease renew request LEASRENreq, it sets the address entry timer to the lease period, and moves the entry back to the ASSOCIATED state.
• the APS when the APS receives an address acquisition request ADDRACQreq, it allocates an IP address and assigns the address entry the ASSOCIATED_REMOTE state. The APS holds the IP address in this state for the total lease period. If the APS receives a lease renewing request LEASRENreq, it resets the lease timer and responds with a LEASRENres response. On the lease timer expiration, the APS releases the IP address.
• the APS When the APS allocates an IP address to a local user, it assigns the address entry the ASSOCIATED_LOCAL state and sets its timer to the lease period. When the timer expires, the APS moves the address entry to the VERIFYING_ADDRUSE_LOCAL state, and verifies IP address usage by sending the local user an address verification request. If the APS receives a positive verification response, it returns the address entry back to the ASSOCIATED_LOCAL state. Otherwise it deletes the address entry.
• the APS On the RESTOREreq request receipt, in the ASSOCIATEDJ_OCAL state, the APS resets the entry timer, and completes the request, in the VERIFYING_ADDRUSEJ_OCAL state, the APS moves the entry to the ASSOCIATED_LOCAL state, and completes the request.
• the three entities involved in the DAAP protocol are illustrated in Figure 10: DAAP Client (DAAPC), DAAP Proxy (DAAPP), and DAAP Server (DAAPS).
• the DAAPC is a protocol entity residing on the end data equipment in the network layer.
• Figure 10 also illustrates how the DAAP protocol is situ- ated in the protocol stack in different entities.
• the DAAPC acquires an IP address from the DAAPS after a logical link between the mobile host and the mobile station has been established. The information about the subnet, address pools and user rights are configured to the network database.
• the DAAP which is assigned an IP network identifier, is called the DAAPS, and a DAAP without a network is called the DAAPP.
• the DAAP acts as the DAAPP in the following cases: 1) the DAAP is not assigned an address space (the DAAP is a pure DAAPP), 2) the DAAP is assigned an address space; however, the address pools are currently exhausted, or 3) the user has no permission to acquire IP addresses from local address pools. If for some reason an IP ad- dress cannot be allocated from the address space on the local DXT, the local DAAP entity on this DXT acts like a proxy (DAAPP) trying, on behalf of the DAAPC, to acquire an IP address from a remote DAAPS server.
• DAAPP proxy
• the DAAP on the DXT When the DAAP on the DXT has received an address acquisition request, it checks whether there is a spare IP address in one of its address pools. If a vacant IP address is found, the DAAP will complete the request without acquiring an IP address from a remote DAAPS server. Otherwise it must interactively send address acquisition requests to other known DAAPS servers.
• the DAAPS issues an IP address to the host, it creates an entry, which is called an address table, saving the IP address and the user current location.
• the DAAPS In order to allocate an IP address, the DAAPS must know both the user identifier and the identifier of the end data equipment. The former identifier is necessary to bind the IP address either to the end user or to the end mobile station.
• the Individual Short Subscriber Identity (SSI) number may serve for this purpose.
• SSI Individual Short Subscriber Identity
• the latter identifier is necessary to distinguish between several data equipment connected to the same mobile station.
• the Network Service Access Point Identifier (NSAPI) may be used for this purpose.
• the DAAPS leases the IP address to the DAAPC for a total lease period.
• the DAAPC renews the lease when the lease period has expired.
• Figures 11 , 12 and 13 show illustrative scenarios of the DAAP ad- dress allocation.
• FIG 11 shows how the mobile host acquires an IP address from the local address space (the address space on the DXT of user location). Referring to Figure 11 the following steps take place. 1. The mobile host connected to the mobile station acquires an IP address. The DAAPC sends an IP address request over the air interface.
• the IP address request arrives at the DXT.
• the local DAAPS after successful validation of the user permission, picks up a spare IP address from an address pool.
• the local DAAPS associates the IP address with user identifier SSI and network service access point identifier NSAPI, thus leasing the IP address to the mobile host for a total lease period.
• the local DAAPS sends an IP address response back to the DAAPC.
• Figure 12 shows how the mobile host acquires an IP address from a remote address space (the address space on a DXT other than the one where the user is currently). Referring to Figure 12 the following steps take place.
• the mobile host connected to a mobile station acquires an IP address.
• the DAAPC sends an IP address request over the air interface.
• the IP address request arrives at the DXT.
• the local DAAP after successful validation of the user permission, attempts to acquire an IP address from an address pool, but fails. It then acts as a DAAPP, and obtains from the database a list of DAAPS servers from which the user may acquire an 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.
• a DAAPS associates the IP address with a user identifier SSI and network service access point identifier NSAPI, thus leasing the IP address to the DAAPC for a total lease period. The total period of time may be twice the lease period, for example.
• the DAAPS sends an IP address response back to the DAAPP. 4.
• the DAAPP sends the IP address response to the DAAPC.
• Figure 13 shows how the DAAPC renews address lease from the DAAPS. Referring to Figure 13 the following steps take place. 1.
• the address lease which is a half of the total lease period, has expired.
• the DAAPC sends an address lease renew request to the DAAP on the local DXT. While waiting for a response, the DAAPC sets the timer to 30% of the total lease period.
• the DAAPP On receipt of the request, the DAAPP sends the DAAPS an ad- dress lease renew request.
• the DAAPS renews the total lease to the DAAPC and replies with a positive lease renew response.
• FIG. 13 also shows an alternative case where the lease-renewing request is lost between the local DAAPP and the DAAPS:
• the address lease which is half of the total lease period, has expired.
• the DAAPC sends an address lease renew request to the DAAP on the local DXT. While waiting for a response, the DAAPC sets the timer to 30% of the total lease period.
• the DAAPP On receipt of the request, the DAAPP sends the DAAPS an address lease renew request. The request is lost.
• the timer has expired on the DAAPC.
• the DAAPC sends sec- ond address lease renew request to the DAAPP. While waiting for a response, the DAAPC sets the timer to 20 % of the total lease period.
• the DAAPP forwards the DAAPS an address lease renew request. The request is lost. After the total lease period has elapsed, both the DAAPC and the DAAPS remove the IP address. Operation of the DAAPC
• the behaviour of the originating DAAPC when leasing addresses from the remote DAAPS is illustrated by a generalised state diagram shown in Figure 14.
• the NO_ENTRY state is an imaginary state that represents no state at all.
• the first state transition occurs when the server user on the mobile host invokes the DAAPC address acquisition function.
• the DAAPC will create an address entry and assign it the ACQUIRING_ADDRESS state.
• the DAAPC sends an address acquisition request to the DAAP on the local DXT. If that DAAP has no spare IP address in a local address pool, it will choose a DAAPS server, create an temporal address entry in the cache, assign the state ACQUISITION to it and send an ADDRACQreq request to it.
• the DAAPP waits for a response. If a positive ADDRACQres response arrives, the DAAPP deletes the temporal address entry and completes the local request by forwarding the ADDRACQres response to the DAAPC. If the DAAPP receives a negative ADDRACQres, it selects another DAAPS, if any is left, and retransmits the same ADDRACQreq. The DAAPP may receive more than one positive ADDRACQres response. The DAAPP always chooses the first response arrived and discards late responses.
• the DAAPC leases the IP address to the user for a certain period of time, which is referred to as a lease period. It obtains the value of the lease period from the ADDRACQres response.
• the default lease period is equal to 12 hours.
• the DAAPS leases IP addresses to the DAAPC for a total lease period which is twice the lease period. If the user releases an IP address before a total lease expiration the DAAPC will delete the address and send an address release request ADDRELreq to an appropriate DAAPS.
• the DAAPC After lease timer has reached lease period, the DAAPC attempts to renew the lease of the IP address. It sends an address lease renewing request ADDRENreq, moves the address table entry to the RENEWING_1 state, and sets the address entry timer to a value that is equal to 80% the lease period.
• the address entry timer expiration in the RENEWING_1 state causes the DAAPC to send the second address lease renewing ADDRENreq request, set the address entry timer to a value equal to 20% of the lease period, and move the entry to the RENEWING_2 state.
• the DAAPC releases the IP address by sending an address release request to the user and deleting the address entry.
• the DAAPC receives a positive lease renew request LEASRENreq, it sets the address entry timer to the lease period, and moves the entry back to the ASSOCIATED state.
• the DAAPS when the DAAPS receives an address acquisition request ADDRACQreq, it allocates an IP address and assigns the address entry the ALLOCATED state. The DAAPS holds the IP address in this state for the total lease period. If the DAAPS receives a lease renewing request LEASRENreq, it resets the lease timer and responds with a resonse LEASRENres. On the lease timer expiration, the DAAPS releases the IP address.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Computer Security & Cryptography (AREA)
• Mobile Radio Communication Systems (AREA)
• Data Exchanges In Wide-Area Networks (AREA)

Priority Applications (2)

Applications Claiming Priority (2)

Publications (1)

Family

ID=8555134

Family Applications (1)

Country Status (4)

Cited By (5)

Citations (5)

• 1999
  • 1999-08-10 FI FI991697A patent/FI107677B/fi active
• 2000
  • 2000-08-09 AU AU64460/00A patent/AU6446000A/en not_active Abandoned
  • 2000-08-09 WO PCT/FI2000/000674 patent/WO2001011904A1/en not_active Application Discontinuation
  • 2000-08-09 EP EP00951564A patent/EP1203500A1/en not_active Withdrawn

Patent Citations (5)

Also Published As

Similar Documents

Legal Events