EP1179268A1

EP1179268A1 - Multiple tree hierarchical communication system and method

Info

Publication number: EP1179268A1
Application number: EP01916255A
Authority: EP
Inventors: Zhonghe Wang; Dah-Lain Almon Tang
Original assignee: Motorola Inc
Current assignee: Motorola Solutions Inc
Priority date: 2000-03-10
Filing date: 2001-02-27
Publication date: 2002-02-13
Also published as: JP2003527008A; WO2001069948A1; AU2001243301A1; CN1364389A; EP1179268A4; KR20020000887A

Abstract

A method and system for improving the registration process in a communication system, preferably an all IP communication system, wherein a set of Location Registration (LR) nodes are designed to handle mobile registration locally. When the mobile node registers with the home network from a foreign network, a Location Registration chain is established through these nodes. The information needed for the mobile node to access the network is distributed to these nodes from the home network. When the mobile node roams into a different visiting network or returns to its home network, the nearby location registration nodes then process the mobile registration and update the location chain accordingly.

Description

MULTIPLE TREE HIERARCHICAL COMMUNICATION SYSTEM AND

METHOD

Field of the Invention

The present invention is related in general to communication systems, and, more particularly, to an improved method and system for improving the registration process in an all IP communication system.

Background of the Invention

A universal personal communication system is a system enabling anyone to communicate with anyone else anywhere in the world. One of the problems of such a system would be locating millions of moving customers in an efficient manner. Existing techniques for locating moving customers in the system are paging and registration using a central database. Considering the large number of customers in a global system, the first technique, if applied without knowledge of the location of the customers, is impractical. The registration technique, which records all the movements of customers in a central database, is also impractical.

Global roaming is one of the design objectives for the next or third generation (3G) cellular networks. To efficiently support real-time applications for mobile users in these networks, signaling and payload traffic delays must be minimal. It has been identified that one of the sources causing long delays is triangle routing. That is, for example, in the registration process the registration requests have to be transmitted from a foreign agent in the visited network all the way to the home network every time the mobile node initiates a call or when the mobile node roams into a different visiting network. In addition, in the call set up process, triangle routing has been identified as a source causing long delays.

In a Mobile IP network as specified in RFC2002, a home agent serves as both a centralized location registry and as a tunneling endpoint, such that all packets destined for a mobile node must be routed to its home agent and then encapsulated and forwarded to the corresponding foreign agent. This scenario is commonly called triangle routing or tromboning, which does not make efficient use of network resources and is one of the major obstacles for IP networks to support real time applications.

The Regional Tunnel Management introduced a hierarchical foreign agent architecture to the IP network to remove triangle routing for the registration signaling. However, there are several issues when adopting Regional Tunnel Management to the 3G cellular networks. They include: inhomogeneous system architectures in home and foreign domains; triangle routing in call connection; inability to support personal (compared with device) mobility; undefined de-registration process for mobility management; and requiring heavy involvement of the mobile node in the registration process.

The proposed Universal Mobile IP (UMIP) technology is designed for next generation (3G) cellular networks. It is intended to offer integrated mobility services, with global coverage, to multiple heterogeneous Radio Access Networks for real-time and non-real time applications. The proposed technology adds features to, and is backward compatible with, the Mobile IP standard specified in RFC2002, which is a special case of UMIP. The Regional Tunnel Management is also a special case of UMIP.

Consequently, a need exists for a method and system for reducing the time required for call setup and payload routing. The present invention proposes to eliminate triangle routing in both signaling and payload traffic through a distributed hierarchical architecture in both the mobile's visiting domain and home domain.

Brief Description of the Drawings

The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objects, and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:

FIG. 1 illustrates a simplified 3G wireless network architecture in accordance with the method and system of the present invention;

FIG. 2 illustrates a communication system in accordance with the method and system of the present invention showing the hierarchical system architecture with four layers of Location Registers;

FIG. 3 illustrates a Location Register table to store mobile node location information;

FIG. 4 illustrates an example of the location chain in the hierarchical architecture in accordance with the method and system of the present invention;

FIG. 5 illustrates a functional flow diagram depicting the process of a Location Register of layer > 1 receiving a registration request;

FIGS. 6 & 7 illustrate functional flow diagrams depicting the process of a Location Register generating a registration reply;

FIG. 8 illustrates a functional flow diagram depicting the process of a

Location Register of layer > 1 receiving a registration reply;

FIG. 9 illustrates a functional flow diagram depicting the process of mobile nodes generating a registration request; FIG. 10 illustrates a functional flow diagram depicting the process of mobile nodes receiving a registration reply;

FIG. 11 illustrates a functional flow diagram depicting the process of mobile nodes generating a Lifetime update request;

FIG. 12 illustrates a functional flow diagram depicting the process of mobile nodes receiving a Lifetime update reply;

FIG. 13 illustrates a functional flow diagram depicting the process of

Location Register (1) receiving a registration request;

FIG. 14 illustrates a functional flow diagram depicting the process of a Location Register with a layer = 1 receiving a registration reply;

FIG. 15 illustrates a functional flow diagram depicting the process of a Location Register with a layer = 1 receiving a binding update;

FIG. 16 illustrates a functional flow diagram depicting the process of a Location Register with a layer = 1 receiving a de-registration;

FIG. 17 illustrates a functional flow diagram depicting the process of a Location Register with a layer = 1 receiving a Lifetime update request;

FIG. 18 illustrates a functional flow diagram depicting the process of a

Location Register with a layer = 1 receiving a Lifetime update reply;

FIG. 19 illustrates a functional flow diagram depicting the process of a Location Register of layer > 1 receiving a de-registration message;

FIG. 20 illustrates a functional flow diagram depicting the process of a Location Register of layer > 1 receiving a binding update; and

FIG. 21 illustrates a functional flow diagram depicting the process of a Location Register of layer > 1 receiving a Lifetime update request. Detailed Description of the Invention

Referring to the Figures and throughout the specification, acronyms are used for convenience. The following is a list of the acronyms used.

Bluetooth Bluetooth is the codename for a technology specification for small form factor, low-cost, short-range radio links between mobile PCs, mobile phones and other portable devices. The Bluetooth Special Interest Group is an industry group consisting of leaders in the telecommunications and computing industries that are driving development of the technology and bringing it to market.

B Bit Busy BRAN Broadband Radio Access Network BTS Base Transceiver Station CN Core IP-based Network Current ID The ID (NAI) of an LR to which the mobile node has successfully registered

DECT Digital European Cordless Telephone

DNS Domain Name Server

F Bit Foreign Agent

FA Foreign Agent

FD Foreign Domain. The coverage area that is outside the

Home Domain from which the mobile node subscribes network services

H Bit Home Agent HA Home Agent Home ID: The ID (NAI) of the mobile node assigned by its home

LR from which the MN subscribes network services.

Home Network The coverage area of the home LR from which an MN subscribes network services

HD Home Domain. The entire area covered by the top layer

LR that includes the home sub-tree where the mobile node subscribes network services IR Intelligent Routing

IrDA Infrared Data Association Location Chain A sequence of location pointers at LRs forming a routing path between MN's current LR and its home LR

Location Pointer IP address of an LR to which outbound packets are forwarded for a mobile user

LR Location Registration or Location Register, a network entity in the IP network to handle mobility management

MIN Mobile Node Identification Number MN Mobile Node NAI Network Access Identifier NE Network Entity including LR, RNN. New ID The ID (NAI) of the LR which a mobile user newly discovered and to which Universal Registration Request messages are sent

PDSN Packet Data Service Node RAN Radio Access Network RNN Radio Network Node for voice / data applications RNS Radio Network Subsystem RT Regional Tunnel

UMIP Universal Mobile IP VHE Virtual Home Environment

AA: Mobile IP Agent Advertisement message

Authen: Authentication

Cch(i): True when the MN's current and home addresses (NAI) are the same at layer i and above

Ccn*(i): True when the layer i processing node is on the current branch

Chn*(i): True when the layer i processing node is on the home branch

Cnc(i): True when the MN's new and current addresses (NAI) are the same at layer i and above Cnh(i): True when the MN's new and home addresses (NAI) are the same at layer i and above Cnn*(i): True when the layer i processing node is on the new branch

CRN: Current root node, the root node of the tree which MN is registered

DR: De-registration FL: Forwarding link address carried in messages

FRN: Foreign root node, the root node of the tree which is not

MN's home

FWD: Forwarding, indicating the Status of MN entry HB: Home branch, the branch connecting MN home LR all the way to HRN

HRN: Home root node, the root node of the tree which MN subscribes services

I: The highest layer of LR nodes in UMIP hierarchy i: Indicating the layer of the LR node, [1, 1]

LRh(i): Layer i Location Register on the home branch

LRn(i): Layer i Location Register on the new branch

LT: Lifetime

LTR: Lifetime Update Request n" The node processing the message

NACK: Negative ACKnowledgment NRN: New root node PTR: Pointer indicating the next LR in the chain toward MN Rch: The index identifies the layer where the current branch and home branch split, [0, 1]

Rnc: The index identifies the layer where the new branch and current branch split, [0, 1]

Rnh: The index identifies the layer where the new branch and home branch split, [0, 1]

RN: Root node RR: Registration Request RR FL: FL carried in Registration Request message

TA: Target address for message to be sent

A simplified 3G wireless network architecture is shown in FIG. 1. As shown, there are two separate network segments in the architecture. The first segment is the Radio Access Network (RAN) that includes the Radio Network Node (RNN), which is associated with a coverage area such as a zone, paging area or routing area. The second segment of the system is the Core Network (CN) which offers an integrated mobility solution to all the underlying heterogeneous RANs, among other functions.

FIG. 2 illustrates a UMIP system architecture with four layers of Location Registers (LRs). The RNN is the lowest layer LR (i.e., LI LR) in the hierarchy. In a preferred embodiment, either a unique NAI or an IP address identifies an LR in the hierarchy. Different wireless systems may have their own network entities that are equivalent to the RNN. For example, the Radio

Network Subsystem (RNS) is an equivalent entity in a GPRS network. The RNN is responsible for both voice and /or data applications. Each RNN is identified by a single location ID and is shared by multiple Base Transceiver Stations (BTSs) under its control. It is assumed that the RNN has a link layer connection (e.g., common control channels or the equivalent) with the

Mobile Node (MN).

The RAN is responsible for all the radio access and micro mobility management (if any) issues. The core network (CN) may support multiple radio access technologies such as WCDMA, CDMA2000, GSM, IS-95, DECT, BRAN (Broadband Radio Access Network), BLUETOOTH, IrDA, and other future technologies. For example, a CDMA user may want to talk directly to a GSM cellular user by simply dialing the called party ID. The proposed solution is able to locate the called party with the help of the distributed LR database and make an appropriate connection to the called party. As a byproduct of UMIP, the Network-Network Interface (NNI) is pushed down to the RAN-CN interface that should maximize CN reuse and system integration for mobility management. The RAN-CN interface for management functions such as mobility management is marked as "M- interface" in FIG. 2. No matter what technology is implemented for the RAN, in the preferred embodiment, the RAN-CN interface must be IP based.

Mobility management is implemented in the LRs (Location Registers).

In addition to serving as a foreign agent and replying to registration requests for the home agent, the LRs maintain and update the mobility database. The

LRs are organized in a multiple-layered architecture (The maximum layer i equals 4 in FIG. 2). The layer index is assigned in an increasing order from bottom to top of the architecture. The number of layers in different sub-trees (domains) may not necessarily be identical. Each LR may have zero or multiple child LRs in the next lower layer. Each LR may have zero (called root LR) or one immediate parent LR. All the root LRs are assumed to be able to communicate with each other to form a location chain across multiple domains. Each LR is associated with a logical coverage area. The total coverage area of a lower layer LR must be a proper sub-set of that of its parent LR. In other words, the logical boundary of a higher layer LR must not cross any boundaries of its offspring LRs.

The behavior of each LR may be different depending on the layer at which it is located. Only those LRs that have a wireless interface to a MN need to advertise their presence to MNs. It should be noted that an LR at a given layer can have subtending child LRs and an interface to a RAN. The root LR in a hierarchy can interface with the root nodes in other hierarchies.

In addition to their IP addresses, all the functional entities (i.e. LRs, RNNs and MNs), are identified by their globally unique identifiers. In the preferred embodiment, NAI (Network Access Identifier) is used as the globally unique identifier. However, those skilled in the art will appreciate that other globally unique identifiers may be used without departing from the spirit and scope of the present invention.

In the preferred embodiment, in order to have an efficient system solution, the assignment of NAIs follows the following rules: The mobile user is identified by his/her NAI. This offers an opportunity to support Personal Mobility in UMIP. The NAIs, rather than the IP addresses, of the bottom layer LRs are used as the Current, New, or Home location identifiers for the mobile nodes. The NAIs of the LRs should be assigned in a way that by comparing the mobile user's Current, New, or Home identifiers, the LR at any layer should be able to make routing decisions.

Complete specification of the NAI assignment is outside the scope of this invention. However, one method of implementation is to assign a shorter NAI for a higher layer entity, and have the assigned NAI be a postfix of the NAI assigned to its child entity of a lower layer. For example, a Layer

1 LR may have an NAI as "123.Arlington Heights.Chicago.IL US@abc." A Layer 2 LR may have an NAI as "Arlington Heights.Chicago.IL ...US@abc." A Layer 3 LR may have an NAI as "Chicago.IL US@abc." A Layer 4 LR may have an NAI as "IL_US@abc." Finally, a mobile user registered with the Layer 1 LR may have an NAI as "4567.123.Arlington Heights.Chicago.IL US@abc." It should be noted that the NAI is defined in such a flexible way that an all-numeric numbering (such as a telephone number) is a valid NAI. In addition, all existing IP, IMSI, and MIN addressing schemes could also be treated as a valid NAI. Furthermore, the NAIs of all the network entities, including LRs and mobile users, may be re-assignable for scalability considerations. The proposed solution also works for mobile users with a permanently assigned NAI. However, a re-assignable NAI is preferred. The efficiency in assigning NAI is an issue of implementation. UMIP supports both pre-assigned and reassigned NAIs.

With reference to FIG. 3, in each of the LRs, there is an LR table to store MN location information and for routing. In the preferred embodiment, and under the following conditions, there is an entry created and maintained in the LR table for a mobile user: the mobile user is outside its registered home network and the LR is on the location chain. The location chain begins at the mobile user's bottom layer LR in its Home Domain and ends at the bottom layer LR in its visited Network. In the preferred embodiment, when no entry is found in the LR table, the mobile node is assumed to be in its home network.

As seen in FIG. 3, in the preferred embodiment there are at least five entities in the LR table. They are keyed index, pointer, status of pointer, Lifetime, and replay protection, each of which, is described as follows. The first column of the LR table is the keyed index, which is the mobile user's home NAI. It is used by the LR to look up mobile information to process registration and location updates and the call connection. There must be a mechanism in the proposed solution to map from a mobile user's identification (NAI) to a routable IP address. The mapping function is performed at LR. The second column is a location pointer of the mobile user. A location pointer for a mobile user is an IP address of an LR to which the LR will forward outbound packets for that mobile user. The third column is the status of the location pointer for the mobile user. There are preferably at least three types of status. They are pending, active, and forwarding. An entry for a mobile user is marked as "pending" after an LR receives a Universal Registration Request initiated by the mobile user and before it receives a positive Reply (authenticated). The LR marks an entry as "active" after a positive Universal Registration Reply associated with the mobile user has been received. The LR marks an entry as "forwarding" after a validated de-registration message with a forwarding address is received before the associated Lifetime is expired.

The fourth column of the LR table is Lifetime. All three types of pointer status in the LR table must be associated with Lifetime (time in seconds). The Lifetime assigned to an entry with "forwarding" status should be reasonably small to prevent a large amount of entries accumulated in the LR table. UMIP must implement Lifetime Update to request extending MN's Lifetime of the binding information. The Lifetime Update may be sent by any LR on the MN's location chain or by its home LR and MN. To support Lifetime Update before the Lifetime expires, Lifetime Update Requests generated by a MN must be directed on the path leading to the Home Network of the mobile user. An LR must not make any decision based on expired information. The fifth column is the style of replay protection in use.

If a received Universal Registration Request contains a replay protection extension requiring a style of replay protection not supported by the LR, the LR must reject the Universal Registration Request and send a Universal Registration Reply with the value in the Code field set to UNSUPPORTED_REPLAY_PROTECTION.

Since the MN may perform Universal Registrations in parallel with regular registrations at its home network, the MN must keep one replay protection mechanism and sequence for the LR and a separate mechanism and sequence for the HA. When using nonces for replay protection, the identification field in the Universal Registration Request/Reply messages is used. The sender of the message is required to set the high-order 32 bits of the identification field to the value of the nonces that will be used by the LR in the next Universal Registration Request/Reply message sent to this LR node. The low-order 32 bits of the identification field are required to be set to the value of the nonces being used for this message. Thus, in each message, the LR communicates to the target LR the value of the nonces that will be used the next time. If no messages are lost in the network, the LR and the target LR can remain synchronized with respect to the nonces being used. If, however, the target LR receives a message with what it believes to be an incorrect nonce, it may resynchronize with the LR by using a Universal Registration Request.

For example, as shown in FIG. 4, if the current location of MN is LR 2122 there may be a location chain setup from LR1121 (Home network) to LR112, then to LRU, LR1, LR2, LR21, LR212 and finally to LR2122.

A Layer i LR must maintain location information for at least the following three types of mobile users. (1) Visitor: a mobile user who is registered (i.e. subscribes service) outside the coverage area of the LR and is roaming within the coverage area of the questioned LR. (2) Native Local Roamer: a mobile user who is registered within the coverage area of the LR but is currently located within a different Layer i-1 coverage area than that where it is registered. (3) Native Traveler: a mobile user that is registered inside the coverage area and roaming outside the coverage area of the questioned Layer i LR. For example as shown in FIG. 4, suppose a mobile user subscribes its service with LR1121. It is a Visitor for LR2122, LR212, LR21 and LR2 if it registers with LR2122. It is a Native local roamer for LRU if it registers with LR1111. It is a Native Traveler for LR1121, LR112, LRU and LR1 if it registers with any LR with a root other than LR1. As long as a mobile user stays within its Layer i-1 home coverage area, there is no location information needed in the Layer i LR for that mobile user. Considering the localized mobility behavior of the mobile users, the memory size, searching delay, and accordingly the complexity and cost of the LR is thus greatly reduced.

To support heterogeneous RAN technologies in the proposed solution, Agent Advertisement must be able to be implemented on multiple layers of the hierarchical structure. For example, a cellular routing area may be associated with a Layer 1 network entity and a satellite cell may be associated with a Layer 2 LR, etc. The Layer i (e.g. i - 1) network entity must announce its presence via an Agent Advertisement message for application } (e.g. cellular) mobile users where the lowest coverage area of application / is associated with the Layer i coverage area. Preferably, there is an "RT" flag in the Agent Advertisement message to distinguish whether the Regional Tunnel management is supported by the local system. The flag is inserted in one of the reserved fields, if IP protocol is used over the air.

Another Flag is "IR" indicating whether Intelligent Routing is supported. The Global Challenge must be included regularly in the Agent Advertisement message for security considerations if it is implemented by the system. The Layer i LR IP address (care-of address) and its NAI is advertised in the Agent Advertisement message. If IP is used over the air, the LR NAI extension must appear in the Agent Advertisement message after predetermined advertisement extensions.

There may be multiple care-of addresses and NAIs in the Agent Advertisement message. The first care-of address and NAI must be those for the Layer i LR. The bottom layer LR must continue to send Agent Advertisements, so that any mobile nodes already registered with it will know that they have not moved out of range of the region and that the network entity has not failed. A network entity may indicate that it is "too busy" to allow new mobile nodes to register with it, by setting the 'B' bit in its Agent Advertisements. An Agent Advertisement message must not have the 'B^! bit set if the 'F' bit is not also set, and at least one of the 'F' bit and the 'H' bit must be set in any Agent Advertisement message sent.

The advertising network entity must include its NAI in the Agent

Advertisement Message to support UMIP. If present, the network entity NAI extension must appear in the Agent Advertisement message after predetermined advertisement extensions. By comparing the domain part of the network entity's NAI with the domain part of its own NAI, the mobile node can determine whether it is in its home domain or in a visited domain, and whether it has changed domain since it last registered.

As soon as a valid Universal Registration message is received at a

Layer i LR at the bottom and above layer of the associated application, additional extensions may be added to the message. They are, not inclusive,

NEW ADDRESS (NAI) is added at the bottom layer of the application.

Hierarchical LR extensions (Layer i (above the bottom layer of the application) LR NAI and its IP address) may also be appended in the message for intelligent routing considerations.

The initial stored Layer i LR NAI (serves as Current ID) of an MN when its power is on must be its own MN NAI. The MN may register a care- of address or any other local index adopted by the associated RAN with the LR. It is noted that the newly discovered Layer i LR may be its own Home LR (HA).

Multiple addresses can be assigned to a mobile user, each for a different application. Extensions are defined to carry the active application addresses in the combined Universal Registration Request message. Receiving a Multiple address extension from a Universal Registration Request, the LR should store that information as part of the mobile user profile associated with the mobile node. The information should be accessible from the LR table of the LR.

The RAN can implement any MN movement detection mechanism adopted by the RAN system. One preferred MN movement detection mechanism is described as follows. In UMIP, the MN needs no knowledge of the core network architecture and therefore, there is no need for this type of information to be transmitted regularly over the band limited wireless channels. All an MN is concerned about, from the registration perspective, is to monitor the NAI of the bottom layer LR's common control channel associated with an application. The movement detection uses the NAI of the

LR that is sent on the common/ dedicated control channels or in the Agent Advertisement messages if IP is used over the air. The MN should lock to the identified LR, (the details of the LR identification process being outside of the scope of the present invention), and keep track of LR NAI extensions from all the Advertisements received. If the received NAI should change, the mobile node must assume that it has moved. For example. Suppose the MN of application / for a mobile user receives an Agent Advertisement from a Layer i (the lowest layer for application J) LR and discovers that it is in a new Layer i LR coverage area (paging area, routing area, and zone, etc.). The MN must initiate the registration process by sending a Universal

Registration Request to the newly discovered Layer i LR if the Agent Advertisement indicates that it supports Universal Registration. To support user authentication with Global Challenge, a reply to the Global Challenge must be included as part of the Universal Registration Request message.

Upon receipt of a validated Universal Registration Request, an LR must register the IP address of the network entity from which the Universal

Registration Request was sent. Associated information must also be stored and indexed by the mobile user's NAI. This includes the mobile user's NAI,

Status and Lifetime. The status is marked "pending." If the LR does not have the authentication information, it will relay the Universal Registration Request to the next LR on the path toward the MN's home network, and may eventually reach the home LR, for authentication. The LR will authenticate the request if it contains all the security information. After successful authentication, the Status will be marked "active". A Registration Reply message may also be generated and sent along the location chain toward the mobile node. The Registration Reply message may also include other information such as user profile (to support VHE) and security information

(to support mobile user authentication), and billing information.

Upon receipt of a Registration Reply message, the LR needs to validate the message and check if there is already an entry "pending". If the

Reply indicates that the registration request is accepted, the Status of the mobile user entry will be marked "active". The LR may then forward the

Reply message to the next LR along the path toward the MN.

On the Registration update path, each LR, other than the bottom layer

LR, may add a Hierarchical LR extension to the Registration message. This information may be used for the downstream LRs (according to the location update chain) to update their LR tables. It could also be used for further route optimization. One or more Hierarchical LR Extensions may be present in a Universal Registration Request in the Core Network. When these extensions are added to a registration request by an LR, the receiving LR sets up a pending registration record for the mobile user, using the IP address of the LR from which the Universal Registration Request is received as the location pointer for the mobile user. Furthermore, a new extension is created and the extension must be appended at the end of all the extensions that had been included by its upstream LRs as part of its registration message. If multiple Hierarchical LR Extension is not implemented, a receiving LR will replace the Hierarchical LR extension with one carrying its own information.

The Hierarchical LR Extension should only be added on its upward update path (from layer i to layer i+1). The extension of a higher layer should be appended after that of a lower layer if multiple Hierarchical LR Extension is implemented. The Hierarchical LR Extension may be defined as that specified in Mobile IP Regional Tunnel Management by E. Gustafsson, A. Jonsson, and C. Perkins, with following modifications. Collectively, the LR network must be able to set up a location chain for any of the mobile users that are outside their registered networks (HA). The location chain must begin at the bottom layer Home LR and end at the current location of the mobile user. All the pointers of the location chain are routable IP addresses. Each link of the location chain may point to its next higher layer, a next lower layer LR (or another network entity) of the same domain (sub-tree) or point to a root LR of a different domain if the LR is a root LR itself. A pointer may also point to any other LR (or network entity) for efficiency considerations. A timer is set whenever a Universal Registration Request message is sent. A retry or a Registration Failure (after N>=0 failed retries) message is sent to the appropriate party only when the timer expires.

It is highly desirable to have a fully distributed location update process in such a system dealing with global mobility management and real time applications. As soon as a Location Register receives a Universal Registration Request it will make a decision on whether it is the last hop of the journey. If it is not, it will decide the next hop for the Universal Registration message. All mobility management message routing decisions should be made based on, in the preferred embodiment, the identities (NAI) of the mobile user, previous LR and current LR..

There should be no direct involvement of a mobile node in the de- registration process. The de-registration process should be part of the location update process that is mobile user initiated and is carried out by the collective efforts of the LR network.

All the LRs that were on the location chain associated with the MN's current location of a mobile user and are no longer on the location chain associated with the mobile node's new location should be informed by a De- registration message and the database be updated accordingly.

After validating the received De-registration message, any LR may update its associated data entry indicating the new location (IP address) of the mobile user with a status "forwarding". The forwarding pointer may help, for instance, to forward the upcoming packets of the roaming mobile user to its new location. The forwarding pointer is valid before its Lifetime expires. After Lifetime has expired, the associated entry will be removed from the LR's database. At this point, all the information of the mobile user such as the user secret data, user profile, etc. should also be removed from the LR's database.

For example, suppose that a mobile subscriber has been assigned to LR1121 as its registered Home address (NAI), as shown in FIG. 4. If the mobile node remains within the coverage of LR 1121, there will be no location information in the LR hierarchy since by default the mobile user is assumed at home if there is no location information available at any LR. Next, suppose that a mobile node attempts to register within the coverage area of LR2122. A location chain will be set up beginning from its home LR and ending at LR2122. There are several potential ways to set up the location chain. One possible way is as follows. A pointer contains the IP address of next upper layer LR in each of the LRs (except the top layer) in the mobile user's Home domain. For example, a pointer exists in LR1121 pointing to LR112, etc. At the top layer LR of the mobile user's home domain there is a pointer pointing to the root node of the visiting domain (LR 2). In each of the LRs of the mobile user's Foreign domain, a location pointer exists pointing to the next lower layer LR where the mobile user is located. For example, a pointer at LR 2 indicates that LR 21 is the next hop of the associated location chain. The LR 21 has a pointer pointing to LR 212. The LR 212 has a pointer pointing to LR 2122 and the latter has a link layer connection (e.g. on common control channel) to the MN.

Another approach is to bypass some layers of the LRs. For example, the pointers of the associated LR's in the MN home domain can be the root node LR 2 of the Foreign domain to reduce the hop count. When an MN moves to a different location area after it has registered successfully, for example, it has registered with LR 2122 and now moves to the coverage area of LR 2121, the registration message doesn't have to go all the way back to LR 1121. Practically, it may be half a world away. The only change needed is to update the associated pointer in LR 212, LR 2122 and setup a new pointer in LR 2121. All these updates are performed locally.

Since the location information is locally available in the LRs of both the Home and Foreign domain of a mobile user and statistically, most of the traffic (both inbound and outbound) is generated in these domains, the time delay and the associated time jitter is thus greatly reduced. For example, a call to an MN, with Home LR 1121 and currently registered at LR 2122, is generated in the coverage area of LR 2121, which will find the called party's location by accessing LR 2121, LR 212 and LR 2122 locally.

It is possible that the communication system may be owned by multiple entities. Therefore, there are possibly two categories of neighboring LRs. The first type of LRs are those that share the same operational authority. In this case, they may share the same secret data. The second type of LRs are those that are under a different operational authority. There must be a way of security key management to support setting up security association among these LRs.

It is assumed that security associations have been set up and are able to work properly between domains (collection) of LRs from different operators. It is also assumed that the security associations have already been set up between the LRs. It is further assumed that the LRs from different domains must be compatible, that is, they must support at least one common type of encapsulation, compression mechanisms, etc. It should be noted that the security association is set up on an operator to operator basis rather than on a call to call basis.

An MN-HA Authentication extension must be included as part of a

Universal Registration Request when an MN performs a Universal Registration. Receiving a Universal Registration Request, an LR will confirm the validity of the MN if there is a local copy of MN associated security data.

It will update its location database accordingly and acknowledge the location update to its upstream (according to the location update chain) network entity if the mobile user is locally authenticated. Otherwise, it will reject the request (by ignoring the request or sending a NACK) if there is a local copy of the MN associated security data and the authentication fails. If there is no such security data locally available, the LR will relay the registration message to the next hop along the path to the mobile user's Home network asking for authentication. In the mean time, the newly updated location pointer will be marked as in a "pending" stage with a limited Lifetime until a positive reply is received from the downstream (according to the location update chain) LR. If the associated Lifetime expires or a negative reply is received for the pending information for the mobile user, the request is rejected and the associated data discarded. If a positive reply is received before the associated Lifetime expires, the associated location information will be upgraded from "pending" to "active" state and an acknowledgement message is sent to its upstream (according to the location update chain) network entity.

The authentication among LRs is implemented with the help of Authentication extensions. It shares the same format and default algorithm support requirements as the three authentication extensions defined for base Mobile IP, but is distinguished by its type. The authenticator value is computed from the stream of bytes including the shared secret, the UDP payload (that is, the Universal Registration Request or Reply message), all prior extensions in their entirety, and the type and length of this extension, but not including the authenticator field itself nor the UDP header. This extension is required to be used in any Universal Registration Request and Reply messages.

The LR that processes the location update successfully generates a Universal Registration Reply only in two conditions. The first condition is when the LR is the ending point of a forward location update process. One such example is when it is the bottom layer LR in the Home domain of the mobile user. Another example is when it is the LR that is knowledgeable of the security data of the mobile user and there is no need to further propagate the location update message in the system. The second condition to generate a Universal Registration Reply is when an LR receives a Universal Registration Reply for a pending mobile user from its downstream LR. The Universal Registration Reply will be relayed to the upstream (according to the location update chain) network entity. Generating a Universal Registration Reply message, a downstream (according to the mobile user's location updating chain) LR must direct the message to the next upstream LR IP address that is available from the Hierarchical LR extension or the New Address extension of the previously received Universal Registration Request message recorded as a pending pointer in the LR table. The LR that initiates Universal Registration Reply distributes appropriate security data (e.g. registration key or Challenge- Reply vectors) to the associated LRs. For instance, the LR may use a Mobile User Key Reply extension added to the Universal Registration Reply message, or it may use other AAA functions. User profile extension may also be included as part of the Universal Registration Reply message.

Distribution of security data and user profile information makes it locally available to the visited network which in turn reduces the time delay and the associated time jitter incurred by triangle routing (tromboning) in the process of authentication and service provisioning.

If the Mobile-Foreign LR Authentication extension is present in. a Universal Registration Request message, the LR in the foreign domain will perform the authentication. Similarly, if a Foreign-Home Authentication extension is present in a Universal Registration Request message, the authentication is performed between the LRs of the visited and home domains.

If everything works fine, all the network entities that sent out a Universal Registration Request message must receive one and only one Universal Registration Reply. When an LR generates or receives a Universal Registration Reply, it performs a memory look up function to determine where to relay this message. The bottom layer LR in the visited network must send a Universal Registration Reply to the associated MN when a successful Universal Registration Reply is received from its downstream (according to the associated location chain) LR. It should be noted that the Universal Registration Request/Reply messages may need to be re-coded on some of the legs on the location update chain due to encryption and security considerations. If, for instance, the Mobile User Key Reply extension is present, the LR that receives the Universal Registration^' Reply decrypts the security data. It may (when necessary) then add, for instance, a new Mobile User Key Reply extension to the Universal Registration Reply message, before relaying it to the next LR. The new Mobile User Key Reply extension contains the security data, encrypted with a secret shared between the LR and the next hop LR in the hierarchy.

This Universal Registration Reply relaying process is repeated in every participating LR in the hierarchy, until the message reaches the bottom layer LR where the mobile user is located. When the bottom layer LR receives the Universal Registration Reply, it performs a memory look up function, and relays the reply to the mobile node.

Existing IP encryption technologies are proposed to carry the security data. The existing IP authentication technologies (AAA and security extensions) are proposed to support the LR authentication processes. The security extensions are part of Universal Registration Request and Universal Registration Reply messages. For example, when an LR receives a Universal Registration Request from another LR, it is required to verify the authentication extension in the message, using the mobility security association it shares with the sending LR. The authentication extension is required for Universal Registration messages. If the authentication succeeds, then the location database is updated accordingly. Otherwise, an authentication exception should be raised.

Each mobile user location update triggered by a Universal

Registration Request is associated with a maximum Lifetime. When sending the Universal Registration Request message, the associated LRs should set this Lifetime to the remaining registration Lifetime. Each following location update for the same mobile user should refresh the Lifetime. Since there is an effective de-registration process, the Lifetime parameter should be set to a reasonably large value for network bandwidth efficiency considerations. Billing functionality is usually partitioned between usage creation (tier 1), usage aggregation (tier 2), and invoicing (tier 3). In UMIP, usage creation and aggregation are combined. The combined function is distributed in the LR's in layer i (i=l for the RAN, corresponding to LI in Fig. 1, or i=2 in the CN, corresponding to L2 in Fig. 1). The network operator can decide whether this combined billing functionality is in the RAN or the CN.

In addition to basic subscriber and services information, each LR on the location chain of layer i will contain subscriber billing information that is usually kept in a billing invoicing system (tier 3). For example, the LR will contain information about allowed time of day access, different levels of service to be provided, and credit/prepaid status.

Since the bearer paths flow through the LR's, the LR records the traffic generated associated with a subscriber. Subscriber traffic information, in addition to the subscriber billing information kept in the LR, will allow the LR to create the CDRs (Call Detail Records) and forward these to the billing invoicing system that generates the user invoices. The billing invoicing system contains information that is needed to generate the invoice, e.g., name, address, credit card number, billing address and phone number.

When a subscriber is in a visited network, the visited billing invoicing system will collect the subscriber's CDRs and forward these to the subscriber's home billing invoicing system.

This distributed billing scheme does not require centralized billing mediation devices that collect usage information from all network elements, since usage will be determined at the source LR (e.g., LR1121 or LR 112 in Fig. 1). In addition, a network operator will not have to deploy separate 'prepaid servers' since the prepayment status information is also available at the source LR. Fewer communication resources will be spent on sending subscriber usage data in the network, and the result will be that more bandwidth is available for user traffic.

The subscriber billing information in a visited LR is distributed to the

LR together with the Registration Reply message. Conversely, if subscriber billing data is updated in the home network's LR (e.g., a change in the levels of service provided), it will be forwarded to the current LR where the subscriber is registered.

The subscriber can access his billing information stored in the local LR where he is currently registered. The information available includes levels of service allowed, and prepaid status. This local access allows the subscriber to check in real-time his billing status.

The flowchart of FIG. 5 shows the response of an LR of layer i > 1 in the communication system operating in accordance with an embodiment of the present invention when receiving a registration request. After receiving a registration request, step 20, an LR authentication determination is made, step 22. In case the LR is not authenticated, a message with the authentication failure is sent to the sending Location Register, step 24, and the process stops. In case the LR is authenticated, then a determination is made at step 26 whether the layer i processing node is on the home branch, with i=2. If yes, then a reply is generated, step 28, and flow proceeds to FIG. 6. Otherwise, flow proceeds to step 30, where a determination is made whether an entry exists. If yes, a reply is generated at step 28, and flow proceeds to FIG. 6. If not, then flow proceeds to step 32 where a determination is made whether the node processing the message is a foreign root node. If yes, then a determination is made at step 34 whether the mobile node is from another foreign domain. If yes, then at step 36, de-registration is sent, the forward link address carried in the message is set equal to LRn(2) and the target address for the message to be sent is set equal to the current root node.

Thereafter at step 38, to send the registration request to the home root node with the forward link address equal to the node processing the message address, the target address is set equal to the home root node. Thereafter at step 40, an entry with a pending status is created. If the mobile node is not from another foreign domain at step 34, then at step 38, to send the registration request to the home root node with the forward link address equal to the node processing the message address, the target address is set equal to the home root node. If the node processing the message is not the foreign root node at step 32, then flow proceeds to step 42, where a determination is made whether the node processing the message is on the home branch. If yes, then to send the registration request home, the target address is set equal to the address of LR( -l) at step 46, and an entry with a pending status is created at step 40. If the node processing the message is not on the home branch at step 42, then to send the registration request to the parent LR, the target address is set equal to the address of LR(Ϊ^'+1) at step 44, and an entry with a pending status is created at step 40.

Thereafter, a determination is made whether the registration request with the forward link address has been received at step 48. If yes, then the pointer indicating the next Location Register in the chain toward the mobile node is set equal to the forwarding link address at step 54, the registration request with the forwarding link address is sent at step 56, and the process stops. If the registration request is received without the forwarding link address at step 48, then the pointer indicating the next Location Register in the chain toward the mobile node is set equal to the IP address of the sending Location Register at step 50, the registration request is sent without the forwarding link address at step 52, and the process stops.

The flowchart of FIGs. 6 and 7 show the response of an LR in the communication system operating in accordance with an embodiment of the present invention when generating a registration reply. After a generation reply decision is made, step 28, a determination is made whether the mobile node is authenticated at step 72. If not, then a reply with the authentication failure is sent to the sending Location Register at step 74, and the process stops. If the mobile node is authenticated at step 72, then the user profile is extracted at step 76. Thereafter, a determination is made whether the mobile node was at home network at step 78. If yes, then at step 80, an entry is created setting the pointer indicating the next Location Register in the chain equal to the forwarding link address carried in the registration request message, or the sending Location Register address, depending on the status of the pointer. Then, the target address message is set equal to the sending Location Register. Thereafter, flow proceeds to block A, step 81 of FIG. 7. If the mobile node was not at home at step 78, then a determination is made whether the mobile node is now at home at step 82. If yes, then a determination is made whether to send de-registration up at step 84. If yes, then at step 86 de-registration is sent with the forwarding link address equal to LRn(2), the target address is set equal to the address of LR(z+l), and Lifetime is set. Thereafter, Lifetime is set for RR and a reply is sent home at step 88, the entry is removed at step 90, and the process stops.

If there is no need to send up the de-registration at step 84, then at step 92, the de-registration is sent with the target address set equal to the address of the layer 1 Location Register on the home branch. Thereafter,

Lifetime is set and a reply is sent home at step 88, the entry is removed at step 90, and the process stops.

If the mobile node is not now at home at step 82, then at step 94, a determination is made whether the node processing the message is in a foreign domain. If yes, then a determination is made at step 96 whether to send de-registration. If yes, then at step 98, de-registration is sent with the target address set equal to the current pointer indicating the next Location Register in the chain, the forwarding link address is set equal to LRn(2), and

Lifetime. Thereafter at step 100, the entry is updated by setting the pointer equal to the address of the sending Location Register and by setting the target address equal to the pointer. Thereafter, flow proceeds to block B, step 101 of FIG. 7. If the de-registration is not sent at step 96, then flow proceeds to step 100 as discussed above. If the node processing the message is not in the foreign domain at step 94, then a determination is made whether the node processing the message is on the home branch at step 102. If not, the flow proceeds to step 96 as discussed above. If yes, then a determination is made whether the mobile node roams across the root node at step 104. If the mobile node does not roam across the root node at step 104, then a determination is made whether to send de-registration at step 106. If de- registration is to be sent, then flow proceeds to step 98 as discussed above. If not, then flow proceeds to step 100 as discussed above. If the mobile node does roam across the root node at step 104, then a determination is made whether the mobile node is now in a foreign domain at step 108. If yes, then flow proceeds to block C, step 109 of FIG. 7. If the mobile node roams to a foreign domain at step 108, then at step 110, de-registration is sent, and if i=ϊ, the target address is set equal to the current pointer, else the target address is set equal to the address of a parent LR z^'+l. In addition, the forwarding link address is set equal to LRn(2), and Lifetime. Thereafter, at step 112, if i is greater than 2, a binding update is sent home with the forwarding link address set equal to the node processing the message, with the target address set equal to the address of LR(z-l) on the home branch, and with Lifetime. Thereafter, flow proceeds to step 100 as discussed above.

If the determination at step 108 was yes, then a determination is made whether the mobile node roams from a foreign domain at step 120. If yes, then at step 122, a de-registration message is sent with the target address set equal to the current pointer, the forwarding link address set equal to layer 2

Location Register on the new branch (i.e., LRn(2)), and with Lifetime. If the mobile node was not in the foreign domain at step 120, then a determination is made whether to send de-registration and a binding update at step 124. If yes, then at step 126, de-registration is sent with the target address set equal to the current pointer, with the forwarding link address is set equal to layer 2

Location Register on the new branch (i.e., LRn(2)), and with Lifetime. If the determination at step 124 was not to send de-registration and a binding update, then at step 130, the entry is. updated to the pending status and the pointer is set equal to the forward link address carried in the registration request message.

After de-registration is sent, flow proceeds to step 128 where a binding update is sent home with the forwarding link address set equal to the forwarding link address carried in the registration request message, with the target address set equal to the address of LR(z^'-l) on the home branch, and with Lifetime. Thereafter, at step 130, the entry is updated to the pending status and the pointer is set pending by setting pointer equal to the forward link carried in the registration request message. At step 132, a determination is made whether to send the reply along the home branch. If yes, then the target address is set equal to the address of parent LR(z^'+l) at step 134. If not, then the target address is set equal to the pointer indicating the next Location Register in the chain at step 136. Thereafter, flow proceeds to block B, step 101, and then to step 140, where Lifetime is set, a reply is sent, and status is set equal to active. Thereafter, the process stops. If flow proceeds from block A, step 81, then at step 138, a binding update message is sent with the target address set equal to layer 1 Location Register on the home branch (i.e., LRh(l)), and with the forwarding link address set equal to the node processing the message. Thereafter, flow proceeds to step 140 where Lifetime is set, a reply is sent, and status of entry is set equal to active. The flowchart of FIG. 8 shows the response of an LR of layer z > 1 of the communication system operating in accordance with an embodiment of the present invention when receiving a registration reply. After a layer i Location Register, i being greater than 1, receives a registration reply, step 150, an LR authentication determination is made at step 152. If not authenticated, then at step 154, a message with authentication failure is sent to the Location Register that sent the reply, and the process stops.

If authenticated at step 152, then a determination is made whether the node processing the message is on the home branch at step 156. If not, then the target address is set equal to the pointer at 158. If the node processing the message is on the home branch at step 156, then a determination is made whether to send along the home branch at step 162. If not, then flow proceeds to step 158 as described above, where the target address is set equal to the pointer. If the determination at step 162 is to send along the home branch, then the target address is set equal to the address of parent LR(z+l) at step 164. After the target address is set, a positive determination is made at step 160. If the reply at step 160 is positive, then at step 166, status is set equal to active and Lifetime is updated. Thereafter, a reply is sent at step 168, and the process stops. If the reply at step 160 is not positive, then the entry in the LR table is deleted at step 170, and a determination is made whether to send a negative reply at step 172. If not, the process stops. If a negative reply is to be sent, then the reply is sent at step 168, and the process stops.

The flowchart of FIG. 9 shows the response of a mobile node in the communication system operating in accordance with an embodiment of the present invention when generating a registration request. After the mobile node receives a paging or mobile IP agent advertisement message at step 180, the new network access identifier is set equal to the received network access identifier at step 182. Thereafter, at step 184, a determination is made whether the new network access identifier equals the current network access identifier. If yes, then the process stops. If not, then the registration request is sent to Location Register (1) at step 186, and the process stops.

The flowchart of FIG. 10 shows the response of a mobile node in the communication system operating in accordance with an embodiment of the present invention when receiving a registration reply. After the mobile node receives a reply at step 190, an authentication determination is made at step 192. If the authentication determination is no, the process stops. If the authentication determination is yes, then a positive determination is made at step 194. If the reply is positive, then at step 196, the address is updated, the current network access identifier is set equal to the new network access identifier, and registration complete is indicated. Thereafter, the process stops. If the reply is not positive at step 194, then a re-send determination is made at step 198. If the re-send determination is no, then the process stops. If the re-send determination at step 198 is yes, then at step 200, a registration request message is re-transmitted, and the process stops.

The flowchart of FIG. 11 shows the response of a mobile node in the communication system operating in accordance with an embodiment of the present invention when generating a Lifetime update request. After generating a Lifetime update request at step 210, a determination is made at step 212 whether Lifetime is about to expire. If not, then the process stops. If Lifetime is about to expire at step 212, then at step 214, a Lifetime update request is sent to Location Register (1), to which the mobile node is locking, and thereafter the process stops.

The flowchart of FIG. 12 shows the response of a mobile node in the communication system operating in accordance with an embodiment of the present invention when receiving a Lifetime update reply. After the mobile node receives a Lifetime update reply at step 220, an authentication determination is made at step 222. If the authentication determination is no, the process stops. If the authentication determination is yes at step 222, then at step 224, Lifetime is updated, and the process stops.

The flowchart of FIG. 13 shows the response of an LR with a layer = 1 in the communication system operating in accordance with an embodiment of the present invention when receiving a registration request. After Location Register (1) receives a registration request at step 230, a pending entry is created at step 232 with the pointer set equal to the address of parent LR(z+l). Thereafter, the registration request is relayed to Location Register (2) at step 234, and the process stops. The flowchart of FIG. 14 shows the response of an LR with a layer = 1 in the communication system operating in accordance with an embodiment of the present invention when receiving a registration reply. After Location Register (1) receives a registration reply at step 240, an authentication determination is made at step 242. If the authentication determination is no, the process stops. If the authentication determination is yes, then a positive determination is made at step 244. If the reply is positive, then at step 246, the entry is updated by setting status equal to active, and thereafter at step 248, the reply is relayed to the mobile node. Thereafter, the process steps. If the reply is not positive at step 244, then the negative acknowledgement is processed at step 250, and a send reply determination is made at step 252. If the send reply determination is no, the process stops. If the send reply determination at step 252 is yes, then the reply is relayed to the mobile node at step 248, and the process stops.

The flowchart of FIG. 15 shows the response of an LR with a layer = 1 in the communication system operating in accordance with an embodiment of the present invention when receiving a binding update. After Location Register (1) receives a binding update at step 260, an authentication determination is made at step 262. If the authentication determination is no, the process stops. If the authentication determination is yes at step 262, then the entry is updated with the mobile node away at step 264, and the process stops.

The flowchart of FIG. 16 shows the response of an LR with a layer = 1 in the communication system operating in accordance with an embodiment of the present invention when receiving de-registration. After Location Register (1) receives de-registration at step 270, an authentication determination is made at step 272. If the authentication determination is no, the process stops. If the authentication determination at step 272 is yes, then the entry is updated with the mobile node away at step 274, and the process stops.

The flowchart of FIG. 17 shows the response of an LR with a layer = 1 in the communication system operating in accordance with an embodiment of the present invention when receiving a Lifetime update request. After

Location Register (1) receives a Lifetime update request at step 280, an authentication determination is made at step 282. If the authentication determination is no, the process stops. If the authentication determination at step 282 is yes, then at step 284, the Lifetime request is relayed to the parent LR(2+1), and thereafter, the process stops.

The flowchart of FIG. 18 shows the response of an LR with a layer = 1 in the communication system operating in accordance with an embodiment of the present invention when receiving a Lifetime update reply. After Location Register (1) receives a Lifetime update reply at step 290, an authentication determination is made at step 292. If the authentication determination is no, then the process stops. If the authentication determination at step 292 is yes, then at step 294, the entry is updated with Lifetime set equal to the received Lifetime, and at step 296 the Lifetime reply is relayed to the mobile node. Thereafter, the process stops.

The flowchart of FIG. 19 shows the response of an LR of layer i > 1 in the communication system operating in accordance with an embodiment of the present invention when receiving a de-registration message. After a layer i Location Register, i greater than 1, receives a de-registration message at step 300, an authentication determination is made at step 302. If the authentication determination is no, then at step 304, a message with the authentication failure is sent to the Location Register that sent the de- registration. Thereafter, the process stops. If the authentication determination at step 302 is yes, then a determination is made whether the node processing the message is above layer 2 at step 306. If not, then at step 308, the de-registration is sent with the target address for the message to be sent set equal to the address of LR(z^'-l) indicated by the existing pointer. If the node processing the message is above layer 2 at step 306, then a determination is made whether the node processing the message is on the home branch at step 310. If the node processing the message is not on the home branch at step 310, then the target address for the message to be sent is set equal to the current pointer at step 314. If the node processing the message is on the home branch at step 310, then a determination is made whether to send along the home branch at step 312. If yes, then the target address for the message to be sent is set equal to the address of parent

LR(z+l) at step 316. If the determination to send along the home branch at step 312 is no, then the target address is set equal to the current pointer at step 314. After setting the target address, flow proceeds to step 318, where a de-registration with carry over forwarding link address and Lifetime from the de-registration or the default Lifetime is sent. Thereafter, at step 320, a determination is made whether the node processing the message is on the home branch. If not, at step 324, status is set equal to forwarding, indicating the status of the mobile node entry, the pointer indicating the next Location Register in the chain is set equal to the forwarding link address carried in the messages, and Lifetime is updated. Thereafter, the process stops. If the node processing the message is on the home branch on step 320, then the entry is removed at step 322, and thereafter the process stops.

The flowchart of FIG. 20 shows the response of an LR of layer z > 1 in the communication system operating in accordance with an embodiment of the present invention when receiving binding update. After Location Register (i), i being greater than 1, receives the binding update at step 330, an authentication determination is made at step 332. If the authentication determination is no, at step 334, a message is sent with authentication failure to the Location Register that sent the binding update, and thereafter the process stops. If the authentication determination at step 332 is yes, then a determination is made whether to send the binding update at step 336. If yes, then at step 338, the binding update is sent with the target address for the message to be sent set equal to the address of LR(z^'-l) indicated by the existing pointer, and the forwarding link address carried in the message and Lifetime is carried over from the binding update message. Thereafter, at step 340, the pointer is set equal to the forwarding link address, and Lifetime is updated. If the determination to send the binding update at step 336 is no, then flow proceeds to step 340 as described above, where the pointer is set equal to the forwarding link address, and Lifetime is updated.

The flowchart of FIG. 21 shows the response of an LR of layer z > 1 in the communication system operating in accordance with an embodiment of the present invention when receiving a Lifetime update request. After Location Register (i), i being greater than 1, receives a Lifetime update request at step 350, an authentication determination is made at step 352. If the authentication determination is no, then an authentication failure message is sent to the Location Register that sent the Lifetime request at step 356, and the process stops. If the authentication determination at step 352 is yes, then a mobile node authentication determination is made at step 354. If the mobile node is not authenticated, then an authentication failure message is sent to the Location Register that sent the Lifetime request. If the mobile node is authenticated at step 354, then a determination is made at step 358 whether the layer i processing node is on the home branch, with z^'=2. If yes, then a determination is made whether to update Lifetime at step 360. If Lifetime is to be updated, then a new Lifetime is set at step 362 and a determination is made whether to send a Lifetime reply at step 364. If not, the process stops. If yes, then the Lifetime reply is sent with the target address for the message to be sent set equal to the address of LR(z^'-l) indicated by the existing pointer at step 366. Thereafter, the process stops. If the determination to update Lifetime at step 360 is no, the process stops. If the determination at step 358 is no, then a determination is made whether the node processing the message is a foreign root node at step 368. If yes, then at step 370, the target address for the message to be sent is set equal to the home root node, and at step 372, the Lifetime update request is sent. If the node processing the message is not the foreign root node at step 368, then a determination is made whether the node processing the message is on the home branch at step 374. If not, in order to send the Lifetime update request to the parent, the target address for the message to be sent is set equal to the address of parent LR(z^'+l) at step 376. If the node processing the message is on the home branch at step 374, then to send the Lifetime request home, the target address for the message to be sent is set equal to the address of LR(z^'-l) on the home branch at step 378. Thereafter, the Lifetime update request is sent at step 372. After sending LTR, flow proceeds to step 360 to update Lifetime as described above.

The foregoing description of a preferred embodiment of the invention has been presented for the purpose of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Obvious modifications or variations are possible in light of the above teachings. The embodiment was chosen and described to provide the best illustration of the principles of the invention and its practical application, and to enable one of ordinary skill in the art to utilize the invention in various embodiments and with various modifications as are suited to the particular use contemplated. All such modifications and variations are within the scope of the invention as determined by the appended claims when interpreted in accordance with the breadth to which they are fairly, legally, and equitably entitled.

Claims

What is claimed is:

1. A method of locating a portable transceiver in a communication system having:

a multiplicity of ports for transferring communication information through the communication system between a plurality of transceivers, the portable transceiver being a member of the plurality of transceivers , each of the plurality of transceivers being coupled to one of the multiplicity of ports;

a multiplicity of nodes for transferring information between the multiplicity of ports, each of the multiplicity of ports coupled to one of the multiplicity of nodes, each of the multiplicity of nodes having memory capable of storing data indicative of a port to which the portable transceiver is coupled; and

a plurality of node trees comprising the multiplicity of ports and the multiplicity of nodes, each of the plurality of node trees having:

a plurality of the multiplicity of ports; and

a plurality of the multiplicity of nodes structured as a hierarchical system of nodes; wherein

a root node is structured as a highest node in the hierarchical system of nodes; wherein the plurality of node trees includes:

a home tree associated with the portable transceiver, the portable transceiver having an address indicative of a home port of the home tree, and the plurality of node trees further includes:

a second tree having a second port, the method comprising the steps of:

(a) coupling the second port to the portable transceiver; and

(b) adding a first data entry to a root node of the home tree in response to step (a) of coupling, the first data entry being associated with the portable transceiver and indicative of a root node of the second tree.