Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W8/00—Network data management
  • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
  • H04W8/08—Mobility data transfer
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
  • H04L63/0892—Network architectures or network communication protocols for network security for authentication of entities by using authentication-authorization-accounting [AAA] servers or protocols
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
  • H04W12/06—Authentication
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
  • H04W12/06—Authentication
  • H04W12/062—Pre-authentication
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W8/00—Network data management
  • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
  • H04W8/08—Mobility data transfer
  • H04W8/085—Mobility data transfer involving hierarchical organized mobility servers, e.g. hierarchical mobile IP [HMIP]
• • 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 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.
• 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.
• 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.
• issues 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.
• 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.
• 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
• 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
• FIG. 18 illustrates a functional flow diagram depicting the process of a
• 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
• FIG. 21 illustrates a functional flow diagram depicting the process of a Location Register of layer > 1 receiving a Lifetime update request.
• 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.
• H Bit Home Agent HA Home Agent Home ID The ID (NAI) of the mobile node assigned by its home
• 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
• LR Location Registration or Location Register a network entity in the IP network to handle mobility management
• 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
• FRN Foreign root node, the root node of the tree which is not
• 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
• 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]
• FIG. 1 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.
• RAN Radio Access Network
• RNN Radio Network Node
• CN Core Network
• 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.
• LI LR Location Register
• 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
• RNN Network Subsystem
• BTS Base Transceiver Stations
• MN Mobile Node
• 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.
• WCDMA Wideband Radio Access Network
• CDMA2000 Code Division Multiple Access 2000
• GSM Global System for Mobile Communications
• IS-95 Dual EECT
• BRAN Broadband Radio Access Network
• BLUETOOTH BLUETOOTH
• IrDA interleukin Data Access
• 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.
• NNI Network-Network Interface
• 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
• Mobility management is implemented in the LRs (Location Registers).
• the LRs 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.
• 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.
• 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.
• NAIs 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.
• 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.
• 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.”
• 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.
• 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.
• a re-assignable NAI is preferred.
• the efficiency in assigning NAI is an issue of implementation.
• UMIP supports both pre-assigned and reassigned NAIs.
• each of the LRs there is an LR table to store MN location information and for routing.
• 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.
• the mobile node is assumed to be in its home network.
• the LR table 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.
• 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.
• 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.
• the MN 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.
• 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.
• the LR communicates to the target LR the value of the nonces that will be used the next time.
• 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.
• LR1121 Home network
• LRU LRU
• a Layer i LR must maintain location information for at least the following three types of mobile users.
• 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.
• 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.
• 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.
• LR2122 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.
• Agent Advertisement must be able to be implemented on multiple layers of the hierarchical structure.
• 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
• the Agent Advertisement message for application ⁇ e.g. cellular
• 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.
• Agent Advertisement message 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
• the network entity NAI extension must appear in the Agent Advertisement message after predetermined advertisement extensions.
• 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.
• 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).
• 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.
• MN movement detection mechanism is described as follows.
• 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
• 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
• an LR 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,
• 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
• the LR 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
• the Status of the mobile user entry will be marked "active". The LR may then forward the
• each LR other than the bottom layer
• 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.
• 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 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..
• NAI identities
• 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.
• 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.
• 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.
• NAI registered Home address
• 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.
• 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).
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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
• an LR will confirm the validity of the MN if there is a local copy of MN associated security data.
• 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.
• 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.
• 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.
• appropriate security data e.g. registration key or Challenge- Reply vectors
• 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.
• the Mobile-Foreign LR Authentication extension is present in. a Universal Registration Request message
• the LR in the foreign domain will perform the authentication.
• 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.
• 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.
• the bottom layer LR receives the Universal Registration Reply, it performs a memory look up function, and relays the reply to the mobile node.
• 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.
• Billing functionality is usually partitioned between usage creation (tier 1), usage aggregation (tier 2), and invoicing (tier 3).
• 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).
• the LR will contain information about allowed time of day access, different levels of service to be provided, and credit/prepaid status.
• the LR 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.
• the visited billing invoicing system 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).
• 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.
• 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.
• an LR authentication determination is made, step 22.
• a message with the authentication failure is sent to the sending Location Register, step 24, and the process stops.
• step 32 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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
• 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.
• 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.
• the forwarding link address is set equal to LRn(2), and Lifetime.
• 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.
• LRn(2) Location Register on the new branch
• Lifetime i.e., LRn(2)
• LRn(2) Location Register on the new branch
• Lifetime 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
• 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.
• step 128 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.
• 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.
• 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.
• step 140 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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).
• the registration request is relayed to Location Register (2) at step 234, and the process stops.
• an authentication determination is made at step 242. If the authentication determination is no, the process stops.
• step 244 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.
• 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.
• Step 280 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.
• 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.
• 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.
• 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
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Computer Security & Cryptography (AREA)
• Computer Hardware Design (AREA)
• Computing Systems (AREA)
• General Engineering & Computer Science (AREA)
• Databases & Information Systems (AREA)
• Business, Economics & Management (AREA)
• Accounting & Taxation (AREA)
• Mobile Radio Communication Systems (AREA)
• Data Exchanges In Wide-Area Networks (AREA)

Applications Claiming Priority (3)

Publications (2)

Family

ID=24085507

Family Applications (1)

Country Status (6)

Families Citing this family (7)

Citations (1)

Family Cites Families (1)

• 2001
  • 2001-02-27 WO PCT/US2001/006220 patent/WO2001069948A1/en not_active Application Discontinuation
  • 2001-02-27 JP JP2001566571A patent/JP2003527008A/ja active Pending
  • 2001-02-27 AU AU2001243301A patent/AU2001243301A1/en not_active Abandoned
  • 2001-02-27 EP EP01916255A patent/EP1179268A4/en not_active Withdrawn
  • 2001-02-27 CN CN01800447A patent/CN1364389A/zh active Pending
  • 2001-02-27 KR KR1020017014302A patent/KR20020000887A/ko not_active Application Discontinuation

Patent Citations (1)

Non-Patent Citations (6)

Also Published As

Similar Documents

Legal Events