A Distributed Database Architecture for Global Roaming in Next

146

IEEE/ACM TRANSACTIONS ON NETWORKING, VOL. 12, NO. 1, FEBRUARY 2004

A Distributed Database Architecture for Global Roaming in Next-Generation Mobile Networks Zuji Mao, Member, IEEE, and Christos Douligeris, Senior Member, IEEE

Abstract—The next-generation mobile network will support terminal mobility, personal mobility, and service provider portability, making global roaming seamless. A location-independent personal telecommunication number (PTN) scheme is conducive to implementing such a global mobile system. However, the nongeographic PTNs coupled with the anticipated large number of mobile users in future mobile networks may introduce very large centralized databases. This necessitates research into the design and performance of high-throughput database technologies used in mobile systems to ensure that future systems will be able to carry efficiently the anticipated loads. This paper proposes a scalable, robust, efficient location database architecture based on the location-independent PTNs. The proposed multitree database architecture consists of a number of database subsystems, each of which is a three-level tree structure and is connected to the others only through its root. By exploiting the localized nature of calling and mobility patterns, the proposed architecture effectively reduces the database loads as well as the signaling traffic incurred by the location registration and call delivery procedures. In addition, two memory-resident database indices, memory-resident direct file and T-tree, are proposed for the location databases to further improve their throughput. Analysis model and numerical results are presented to evaluate the efficiency of the proposed database architecture. Results have revealed that the proposed database architecture for location management can effectively support the anticipated high user density in the future mobile networks. Index Terms—Database architecture, location management, location tracking, mobile networks.

I. INTRODUCTION

T

HE next-generation mobile network will be an integrated global system that provides heterogeneous services across network providers, network backbones, and geographical regions [1]. Global roaming is a basic service of the future mobile networks, where terminal mobility, personal mobility, and service provider portability must be supported. A nongeographic personal telecommunication number (PTN) for each mobile user is desirable to implement these types of mobile freedom. With location-independent PTNs, users can access their personalized services regardless of terminal or attachment point to the network; they can move into different service provider’s network and continue to receive subscribed services without changing their PTNs. Another advantage of Manuscript received September 28, 2001; revised February 27, 2002, September 13, 2002, and December 27, 2002; approved by IEEE/ACM TRANSACTIONS ON NETWORKING Editor N. Vaidya. Z. Mao is with the Integrated Network Solutions Group, Lucent Technologies Inc., Westford, MA 01886 USA (e-mail: [email protected]). C. Douligeris is with the Department of Informatics, University of Piraeus, Piraeus, 18534 Greece (e-mail: [email protected]). Digital Object Identifier 10.1109/TNET.2003.820435

the flat PTN scheme is that it is much more efficient in terms of capacity than the location-dependent numbering scheme where the capacity of the subscriber number (SN) may be exhausted in a highly populated area, whereas the SN’s capacity is wasted in a sparsely populated area [22]. However, using the location-independent numbering plan may introduce large centralized databases into a mobile system. To make things worse, each call may require an interrogation to the centralized databases, thus signaling traffic will grow considerably and call setup time may increase dramatically. The large centralized databases may become the bottleneck of the global mobile system, thus necessitating research into the design and performance of high-throughput database technologies as used in mobile networks to meet future demands. Location management is one of the most important functions to support global roaming. Location management procedures involve numerous operations in various databases. These databases record the relevant information of a mobile user, trace the user’s location by updating the relevant database entries, and map the user’s PTN to its current location. In current cellular networks location tracking is based on two types of location databases [13], [17]: the home location register (HLR) and the visitor location register (VLR). In general, there is an HLR for each mobile network. Each mobile subscriber has a service profile stored in the HLR. The user profile contains information such as the service types subscribed, the user’s current location, etc. The VLR where a mobile terminal (MT) resides also keeps a copy of the MT’s user profile. A VLR is usually colocated with a mobile switching center (MSC), which controls a group of registration areas (RAs). Whenever an MT changes its RA, the HLR is updated to point to the new location, and the MT is deregistered from the old VLR. As an incoming call arrives, the called MT’s HLR is queried to get the location of the serving VLR of the MT, then a routing address request message is sent to the MSC/VLR. The MSC allocates a temporary local directory number (TLDN) to the called MT and sends back the TLDN to the HLR, which in turn relays this information to the calling MSC. A connection to the called MSC then can be set up through the SS7 network. An MSC/VLR may not know the address of an MT’s HLR, and a global title translation (GTT) is needed to get the address of the MT’s HLR. With the two-level HLR-VLR database architecture, the HLR needs to be accessed for each location update or call delivery. Due to an expected much higher user density in the future mobile networks, the updating and querying loads on the location databases will be very heavy [14] and the two-level database architecture will become infeasible.

1063-6692/04$20.00 © 2004 IEEE

MAO AND DOULIGERIS: DISTRIBUTED DATABASE ARCHITECTURE FOR GLOBAL ROAMING IN NEXT-GENERATION MOBILE NETWORKS

In this paper, a distributed hierarchical database architecture based on the location-independent PTN plan is proposed to support location tracking in a global mobile system. Before further addressing the proposed database architecture, we describe related work first. A. Previous Work There is a growing literature into studying alternatives to the current two-level database architecture. Two main categories of strategies have been proposed in the previous studies [1]: auxiliary strategies based on the two-level database architecture and distributed strategies employing the hierarchical database architecture. The auxiliary strategies try to exploit the spatial and temporal locality in each user’s calling and mobility patterns to reduce the signaling traffic and database loads. Examples include the forwarding strategy, the anchoring strategy, the caching strategy, and the replication strategy. In the forwarding strategy [3], [8], a forwarding pointer is set up in the old VLR pointing to the new VLR of an MT to avoid a location update at the HLR as the MT changes its RA. When a call for the MT arrives, the HLR is queried first to determine the first VLR which the MT was registered at, and a forwarding pointer chain is followed to locate the MT in its current VLR. The forwarding strategy reduces location update signaling but increases the call setup delay. Thus, the length of the forwarding point chain needs to be limited. It is shown that this scheme may not always result in a cost savings as compared to the standard IS-41 scheme. The forwarding scheme is effective only when the call arrival rate is low relative to the mobility rate for an MT. With the anchoring strategy [7], location updates are performed at a nearby VLR (i.e, local anchor) for an MT to reduce signaling traffic between the HLR and the VLRs. The HLR maintains a pointer to the MT’s local anchor. As an incoming call occurs, the HLR forward the call to the local anchor, which in turn queries the serving VLR of the MT for a TLDN. The call delivery time is increased due to one extra database query to the local anchor. Similar to the forwarding scheme, the local anchoring scheme is efficient only when an MT’s call arrival rate is low relative to its mobility rate. With the caching strategy [9], an MT’s location obtained from a previous call is cached and re-used for subsequent calls to that MT. After a cache entry of the MT’s location information is created at a signal transfer point (STP), if another call for the MT is received by the STP, the STP will forward the call to the VLR as specified by the cache. If the MT is still in the same VLR, a hit occurs and the call is successfully delivered. However, if the MT has moved to another VLR, a miss occurs and the IS-41 call delivery process has to be followed to find the MT, thus incurring a much longer setup delay. When an MT changes its location more often than receiving calls, the caching scheme may become inefficient in reducing cost. In the replication strategy [20], an MT’s location is replicated at selected local databases, so that calls to the MT originating from the service area of these replicated databases can be routed without querying the HLR. When the MT changes its location, all replicated databases need to be updated for the MT, thus incurring a high database update load and signaling traffic, especially for highly mobile users. In summary, each auxiliary strategy outperforms the IS-41 only

147

under certain calling and mobility parameters. As the cell sizes become smaller to support an increasing user density and the number of mobile subscribers increases, even these augmentations will not be sufficient to meet the future demands of mobile networks. It becomes obvious that reducing the access rate to the centralized HLR is a critical step to support an increasing number of mobile subscribers. The hierarchical database architecture can reduce the access load on an upper-level database by distributing query load into the lower-level databases, thus it has been studied extensively in previous research. In [6], an extra level of databases called directory registers (DRs), was added between the HLR and the VLRs of current cellular systems. The DR periodically computes the location information distribution strategy for each associated MT in order to achieve a reduced access rate to the HLR. The performance of this scheme depends on the availability and accuracy of the user’s calling and mobility parameters. It is usually computationally intensive to obtain these parameters. Given the large number of MTs, the burden on the DRs would be very heavy. A multilevel hierarchical database architecture was introduced in [23] for location tracking in personal communications systems (PCSs). However, the numbering plan used to identify an MT is location-dependent, which is similar to the telephone number plan, thus the MT needs to be allocated a new number whenever it changes its home service area. In [15], a distributed database architecture based on the IEEE 802.6 MAN was proposed, only suitable for MAN-wide mobile systems. In [18], a three-level hierarchical database architecture for mobile networks was presented based on the location-independent numbering plan. There is a common drawback with the database architectures proposed in these previous studies. The whole database system had only one centralized root database, where all user profiles were maintained. For a worldwide-scale mobile system, it would be impractical to store and manage subscriber information in a single centralized database due to the expected huge number of subscribers. Furthermore, the crash of the root database may paralyze the entire system. We will compare in more detail our proposed database architecture with the one-root architecture in Sections I-B and V. In [4], a set-ary butterfly structure was adopted to replace the root and some of the higher levels of the tree structure, relieving the burden on the root database while increasing the robustness of the database system. In essence, this structure spread the database loads through the use of additional nodes as well as of extra node connections, thus incurring a higher maintenance cost than the pure tree structure, especially in a global mobile system where the extra nodes need to be deployed across different countries and international trunks are required to connect these extra nodes. B. Motivations The proposed database system is a multitree structure (Fig. 1), consisting of a number of distributed database subsystems (DSs), each of which is a three-level tree structure. More than three levels may be adopted in a DS. However, adding more levels will introduce longer delays in location registration and call delivery. These DSs communicate with each other only through their root databases, DB0s, which are connected to

148

Fig. 1. Proposed multitree database architecture.

the others by the public switched telephone network (PSTN), ATM networks, or other networks. The proposed database architecture is motivated by the following. 1) A location-independent PTN provides a basis for global roaming in the next-generation mobile networks where terminal mobility, personal mobility, and service provider portability will be implemented. A mobile subscriber can retain its lifelong PTN regardless of its location and service provider. 2) The multitree database architecture is much more robust than the one-root hierarchical architecture. In the proposed architecture, an MT’s profile is stored in one of the root databases according to its current location. Thus, each root database only maintains a small portion of the user profiles in the global mobile system. The crash of one root database will not disrupt the operation of other root databases, and the recovery of the failed root database is much easier than in the one-root database architecture where all user profiles need to be recovered once the root is crashed. 3) The multitree database architecture is scalable, which is crucial to support continuously increasing number of mobile subscribers in future mobile networks. When the capacity of a root database is saturated, a new DS is readily added. More importantly, the end-to-end delay in location registration and call delivery will not increase due to such an expansion in the mobile network. On the other hand, with the one-root structure, when the capacity of the root or a high-level database is saturated, more levels of databases need to be added in order to reduce the burden on the root or high-level databases. This will increase the delays in location registration and call delivery. 4) The proposed multitree database system is easy to expand and maintain in the multioperator environment of a global mobile system. With the multitree architecture, each service provider can have its own DSs and it is straightforward for a service provider to expand its service cov-


erage by adding new DSs. It is also easy to operate and manage a DS when the DS is wholly owned by a single service provider. The one-root architecture, however, may not have such advantages. 5) No GTT is required in the proposed database architecture, where a signaling message is only sent from a database to another database in an adjacent level within the same subtree or from a DB0 to another DB0. Since a message sender always contains the address of the receiver in its database, no GTT is required. This greatly simplifies the implementation of the proposed architecture. In addition to the multitree location database architecture, this paper also proposes indexing schemes for each type of location databases and analyzes their efficiency and cost in terms of database access time and storage requirement. The location registration and call delivery procedures based on the proposed database structure are also given. Analysis models are developed to study the service response time of each type of databases in the proposed multitree architecture as well as the end-to-end delays incurred by the proposed location registration and call delivery procedures. The proposed architecture is compared with the one-root architecture as well as the HLR-VLR architecture in terms of the signaling loads due to location registration and call delivery. Numerical results have demonstrated that the proposed database architecture outperforms the one-root architecture and the HLR-VLR architecture, and can effectively cope with the anticipated high access rates to various location databases in future mobile networks while meeting the end-to-end delay requirements for location registration and call delivery. The remainder of this paper is organized as follows. Section II describes the proposed distributed database architecture for location tracking as well as the indices of the location databases. Section III presents the database searching strategies associated with the location update and call delivery procedures. Section IV describes the analytic model for performance evaluation of the proposed database architecture. Numerical results are presented in Section V, and conclusions are given in Section VI. II. MULTITREE DATABASE ARCHITECTURE FOR LOCATION TRACKING A. Multitree Location Database Architecture The proposed database architecture for location tracking is a multitree structure, where each subsystem is a three-level architecture (Fig. 1), referred to as a database subsystem (DS) in this paper. Various DSs may represent networks operated possibly by different service providers. All these DSs are interconnected together via a fixed network, such as PSTN or ATM network, and communicate with each other only through their root databases. This architecture can support a multioperator environment which is expected in future mobile networks. In each DS, databases DB0 and DB2 may correspond to the HLR and the VLR in the two-level database system, respectively. Each DB2 may control an RA where a user can roam freely without triggering registrations. Each DB2 is colocated with an MSC, which performs call processing on origination or termination calls. A number of DB2s are grouped into one DB1 and several


DB1s are connected to a single DB0. Each DB1 and DB0 also needs a switch, called the STP, that provides routing functionality for message exchange between various location databases. The DB0 maintains the service profile for each user currently residing in its service area, and maintains an entry for each user in the global mobile system. The entry contains either a pointer to another DB0 where the user is residing or a pointer to the user record that contains a pointer to the DB1 with which the user is currently associated. Each DB1 has an entry for every currently residing user, storing a pointer to the DB2 the user is currently visiting. Every DB2 has a copy of the service profiles of the users currently roaming within its area. With this architecture, the frequency of queries to the higher level databases is greatly reduced due to the locality of calling and mobility patterns. However, when a call or a location update is not local, more databases—including the large centralized database DB0—need to be visited. This increases the end-to-end delays in call setup and location registration. In addition, as the number of mobile subscribers increases, the access time of each database is increased, which also increases the end-to-end delays. To meet the delay demands in call setup and location registration, the number of database levels in a DS has to be limited. Moreover, to support a larger amount of mobile subscribers while keeping the end-to-end delays low, it is critical to reduce the access times to the databases. Thus, investigation into efficient database access indices for the location databases is as important as research into the overall location database architecture. B. Two Efficient Database Indices A database usually consists of two parts: an index file and a data file. The index file contains an access structure called index, which provides search paths for locating the records in the data file. The index determines the database access time, thereby being the critical component for improving database throughput. Efficient indices should be based on application characteristics such as the types of storage devices available, the affordable storage capacity, the types of queries required, the available keys, etc. In this paper, we focus on the indices suitable for a variety of databases in mobile systems. There are two classes of indices: the disk-oriented index, such as the B -tree, and the memory-resident index, such as the AVL-tree and the T-tree. While the disk-oriented indices are designed primarily to minimize the number of disk block accesses and to minimize disk space, the memory-resident indices aim to reduce computation time while using as little memory as possible. For real-time applications, the memory-resident indices are preferred due to their much faster access times than the disk-resident indices. The indices can also be classified into the following two categories: the order-preserving indices and the randomizing indices. The primary order-preserving indices include arrays, B-trees, AVL-trees, T-trees, and direct files. The randomizing indices include various hashing indices. Essentially, the direct file is a special form of hashing indices. We can call the direct file perfect hashing due to its collision-free property and use it in the DB0s due to its fast response time and easy implementation. The hashing indices have been applied in various

Fig. 2.

149

(a) T-node. (b) T-tree.

computer and communications systems. For example, in [10], a hash function was used to balance the query load across multiple GTT servers by distributing users’ PTN-to-HLR address mappings evenly among the GTT servers. In the peer-to-peer systems [19], [21], hash-based techniques were used to map file names to their locations in the peer-to-peer systems while balancing the query load amongst all nodes. The hardest task of applying hashing techniques is to design efficient hash functions that can minimize collisions while keeping memory usage low. On the other hand, the order-preserving indices are much easier to implement and provide guaranteed upper bounds on the search time while keeping memory usage efficient. It has been shown in [12] that among the order-preserving indices-array, B-tree, AVL-tree, and T-tree, the T-tree provides the best overall performance for a mix of searches, inserts, and deletes at a relatively low storage cost. Inserts and deletes incurred by location update as well as searches required by call delivery in the DB1 and the DB2 make the T-tree suitable for these databases. On the contrary, the biggest drawback with the for each update, thus the array is that data movement is array seems only suitable for a read-only environment [12]. The AVL-tree has poor storage utilization since each node stores only one data item while requiring two pointers and some other control information. As mentioned earlier, we also suggest that the memory-resident direct file be used as the index for large databases such as DB0, etc., due to its much faster speed than the other order-preserving indices. 1) T-Tree: The T-tree, which evolved from the AVL-tree and the B-tree, is a binary tree in which each node called T-node contains a number of data items, a parent pointer, a left-child pointer, a right-child pointer, and some other control information (Fig. 2). The T-tree is fast since it retains the intrinsic binary search nature of the AVL-tree. On the other hand, unlike the AVL-tree that holds only one data item in each node, the T-tree contains a number of data items in each node similar to the B-tree, thus having good storage utilization. In a T-node, the data items are arranged in increasing order of

150

their keys. To find a value in the T-tree, a search algorithm for the T-tree is needed. According to [12], one efficient search algorithm for the T-tree can be described as follows: 1) each search begins with the root node; 2) if the search value is less than the minimum value of the node, then the left-child node is searched. Otherwise, the current node is marked for future consideration and the search goes down the subtree pointed to by the right-child pointer. When the search reaches a leaf, the last marked node is searched using a binary search. The search fails when the search value is not found in the marked node that bounds the search value (this node is called the bounding node) or when the bounding node does not exist in the T-tree. Refer to [12] for details about the T-tree. 2) Direct File: In the direct file, there is a direct relationship between the record key and its storage location. The fastest searching method to access a direct file is direct addressing [2]. The key value is used as a relative record number that can be translated into a hardware address by the system. When the direct file is memory resident, the hardware address is the memory address. One potential disadvantage of direct addressing is that space must be reserved for every possible key value, resulting in wasting large amounts of storage. However, when the number of possible key values is relatively close to the number of actual key values, direct addressing is very cost effective. Whenever access time is the vital criterion, even lower packing densities are acceptable. To use direct addressing, the key values must be numeric, in ascending order, and the records must have fixed length. The location-independent PTN numbering plan makes direct addressing quite suitable for large centralized databases in mobile networks. C. Organizations of Location Databases 1) Organization of DB0: The DB0 consists of an index file and a data file. With the location-independent numbering plan being adopted, every subscriber in the whole mobile system has an entry in the index file. If the direct file is used, each index entry only contains a pointer. When a user is residing in the current DS area, the pointer is pointing to the user’s service profile stored in the data file. The user service profile contains a pointer to the DB1 where the user is visiting. When the user is staying in another DS, the pointer in the user’s index entry points to the DB0 associated with that DS. All entries in the index file are allocated the same size of storage and stored in increasing order of the users’ PTNs so that direct addressing can be used to retrieve a record from the index file. Note that the PTN does not need to be stored in the index entry. On the other hand, the T-tree or the B -tree needs to include the PTN in each index entry and store other index management information, thus requiring more memory capacity than the direct file. Therefore, the direct file is the best choice for the index file of the DB0. In the data file, each user residing in the current DS area is allocated a record to store the user’s service profile. Note that the access time of the DB0 is independent of the database size when the direct file technique is employed (but the access time is affected by the access frequency of the DB0). This scalability feature is very useful for future mobility applications since the number of subscribers is expected to increase steadily.


2) Organization of DB1: Each DB1 consists only of one part: the index file, in which each user currently residing in the DB1 area has a data item. Each data item in the index file consists of two fields: the user’s PTN and a pointer to the DB2 the user is currently visiting. No other user information is stored in the DB1. Results from Section V reveal that the T-tree is a preferable technique for the index file of DB1. 3) Organization of DB2: Each of the database DB2s consists of two parts: the index file and the data file. Each user currently residing in the DB2 area has an entry in the index. Each entry in the index consists of two fields: the user’s PTN and a pointer to the user record in the data file that stores the service profiles for each user currently visiting this DB2 area. Results from Section V show that the T-tree is a preferable technique for the index file of DB2. The choice of suitable indices for the DB0, DB1, and DB2 will be further addressed in Section V. III. LOCATION REGISTRATION AND CALL DELIVERY PROCEDURES In this section, the location tracking procedures are described, based on the proposed multitree database architecture as well as the proposed database organizations. Location tracking consists of two procedures: the location registration procedure and the call delivery procedure. Location registration is the procedure through which a user reports its location to the network whenever the user enters a new location. As an incoming call arrives, the call delivery procedure is invoked to deliver the call to the user. For simplicity, in this paper, it is assumed that a DB2 only controls one RA. In real applications, a DB2 may control several RAs. A. Location Registration Procedure With the previously defined file structures of DB0, DB1, and DB2 as well as the proposed multitree location database architecture, the location update procedure in a global mobile system can be described as follows. 1) When a user enters a new RA, a registration request message is sent to the associated DB2 which in turn sends a registration request message to the DB1 controlling this area. If the user has no entry in this DB1, go to step 3; otherwise, go to step 2. 2) The fact that the user has an entry in this DB1 indicates that the new DB2 is within the same DB1 area as the old DB2. A pointer to the new DB2 replaces the old one in the user’s entry in the DB1. No further query to the DB0 is needed. The DB1 sends a registration cancellation message to the old DB2, then go to step 8. 3) The fact that the user has no entry in this DB1 indicates that the user has moved to a new DB1 area. In the new DB1 an index entry is added to contain a pointer to the new DB2 of the user. An update request is also sent to the associated DB0. 4) The DB0 is checked to see if it contains the user’s service profile. If no, this means that the user enters a new DS, then go to step 5a; otherwise, the DB0 updates the user’s


151

service profile to point to the new DB1 and sends a registration cancellation message to the old DB1, then go to step 7. 5) a) The new DB0 sends a query to the old DB0 to request the user’s service profile. b) The new DB0 stores the user’s service profile and updates the service profile to point to the new DB1. A copy of the user’s service profile is also sent to the new DB2. 6) a) The old DB0 sends the user’s service profile to the new DB0. b) The old DB0 updates the user’s entry in the index file to point to the new DB0, and deletes the user service profile from its data file. A registration cancellation message is sent to the old DB1. 7) The old DB1 deletes the user’s index entry, and sends a registration cancellation message to the old DB2. 8) If the old DB2 is in the same DS as the new DB2, a copy of the user’s service profile is sent to the new DB2. The user’s index entry as well as the user’s service profile is removed from the old DB2. 9) After receiving the user’s service profile, the new DB2 sets up an index entry for the user and creates the user’s service profile. The location registration procedure is completed. Fig. 3 shows the flow chart of the location registration procedure. Note that when a user changes its DS, with the preceding location registration procedure, only the old DB0 points to the new DB0 directly. All other DB0s (except for the new DB0) still point to the old DB0. A forwarding pointer chain corresponding to each of these DB0s is generated, like in the general forwarding strategy [8]. The length of these forwarding pointer chains will increase as the user continues to change its DS. As a result, the end-to-end setup delay will increase for inter-DS calls. Compared to the single root structure, the proposed multitree structure achieves its robustness, scalability, maintainability, etc., at the expense of the necessary of synchronizing the DB0s to contain the call setup delay as an MT changes its DS. There exists a tradeoff between the overhead of DB0 synchronization and the call setup delay of inter-DS calls. Specifically, if the “always synchronization” strategy is employed, i.e., the index files in all DB0s are updated to point to the new DB0 upon each DS change, a large amount of signaling traffic as well as database access load will be triggered within a short time if the number of DSs is large, but the setup delay of inter-DS calls is minimized. On the other hand, if the “never synchronization” strategy is adopted, i.e., the index file of a DB0 is never updated upon DS changes, the length of the forwarding chain continues to increase as an MT changes its DS, so does the setup delay of inter-DS calls. One solution to this issue is to adjust the forwarding pointer chain during call delivery, called on-demand synchronization. Specifically, when an inter-DS call has to traverse a forwarding chain going through more than two DB0s, the calling DB0 updates the callee’s index entry to point to the called DB0 directly. With this method, only the setup delay of

Fig. 3. Flow chart of location registration procedure.

the call adjusting the forwarding pointer chain is increased. Another DB0 synchronization strategy is to update a group of selected DB0s that generate relatively high call rates to the moving MT as the MT changes its DS. The rest of DB0s are updated during the first inter-DS calls. We refer to this strategy as partial synchronization. Compared to the on-demand synchronization strategy, this strategy achieves a smaller expected setup delay of inter-DS calls by modestly increasing the synchronization traffic. This approach essentially combines the advantages of the forwarding strategy and the replication strategy. Note that the performance of the discussed DB0 synchronization strategies is closely related to the call-to-mobility ratio of an MT. Due to limited space, this issue will be addressed in future study. Another issue that needs to be addressed is the security and privacy of the user’s service profile when it is transferred between DB0s. If the involved DB0s belong to the same service provider, no problem exists. If the user’s service profile is moved between two DSs operated by different service providers, security issues should be considered. The security

152


issue is out of the scope of this paper and will not be addressed further. B. Call Delivery Procedure When an incoming call arrives, the call delivery procedure for the callee can be performed in the following steps: 1) When a call is detected in the caller’s MSC, the caller’s DB2 is checked to see if an index entry for the callee exists. If yes, go to step 5, and no further queries to the DB1 and the DB0 are required. Otherwise, a query is sent to the associated DB1, then go to step 2. 2) The DB1 examines if the callee has an entry in its index file. If yes, go to step 4, and no further query to the DB0 is required. Otherwise, a query is sent to the associated DB0, then go to step 3. 3) The DB0 examines if the callee is associated with one of its DB1s. If yes, the DB0 sends a routing address request message to the DB1, then go to step 4; otherwise, go to step 7. 4) The DB1 determines the callee’s DB2 and sends a query to the DB2 to request the routing address. 5) The DB2 searches for the callee. If the callee is found, a TLDN is allocated to the callee and sent back to the calling MSC. 6) After receiving the TLDN, the calling MSC sets up a connection to the called MSC associated with the callee’s current DB2. Then the call delivery process stops. 7) If the callee is residing in another DS, a query is sent to the associated DB0. The searching process is repeated from step 3. Fig. 4 shows the flow chart of the call delivery procedure. It is worthwhile to point out that no GTT is required in the location registration and call delivery procedures based on the proposed database architecture. This will simplify the deployment of the proposed strategy while reducing the overall system cost. IV. ANALYTIC MODEL In this section, the access rates to the location databases as well as the end-to-end delays in location registration and call delivery of the proposed database architecture are given. In addition, the access costs of the T-tree and the B -tree are evaluated while formulas for the response times of the direct file, T-tree, and B -tree as well as their storage capacity requirements are presented. Finally, the signaling load of location registration and call delivery is evaluated for the multitree architecture, the one-root architecture, and the HLR-VLR architecture. A. Access Rates to Location Databases Each database can be modeled as a server with a buffering queue. The database provides service to queries using the first-come-first-served (FCFS) principle. For simplicity, the wait queue is usually assumed to be infinite. Due to the large number of users in future mobile networks, it has been shown in [18] that the arrival traffic to a database can be approximated by a Poisson process. We also assume that the service time of a database follows a general distribution. Thus, each database

Fig. 4. Flow chart of call delivery procedure.

can be modeled as an queue. The whole database system forms a queueing network. The service response time , denoted by , which consists of the waiting of database time spent in the queue and the service time , is given by [11] (1) where is the arrival rate to . To evaluate the access rate to each database, a symmetric hierarchical database system structure is assumed, even though an unbalanced tree structure is likely in real applications. For clarity, in this paper only the queries related to the location update and call delivery procedures are taken into account. Note that the acknowledgment messages do not require any searching or update at the database so that they can be omitted while calculating the database access rate. It is observed that all queries to a database are started from the lowest-level database DB2 where all the call and location update requests are originated. The loads on a database DB2 consist of two parts: the external query traffic triggered by the users residing in this DB2 area and the internal query traffic routed by other databases in the system. The loads entering the DB0 and the DB1s come from other databases. No


external query traffic enters the DB0 or DB1s directly. For simplicity, it is assumed that the queries to the databases in the same layer are uniformly distributed, even though in real applications some databases may need to deal with a higher access load than their peers due to unbalanced user load across the system. Some notation is introduced as follows. Number of DB2s in a DB0 area. Number of DB2s in a DB1 area. Call rate originating from an RA. Location update request rate originating from an RA. Probability that a user enters a different DB0 area. Probability that a user enters a new DB1 area within the same DB0 area. Probability that the caller and the callee are in different DB0 areas. Probability that the caller and the callee are in the same DB0 area but different DB1 areas. Probability that the caller and the callee are in the same DB1 area but different DB2 areas. Based on the location update procedure and the call delivery procedure given in Section III, the arrival rates to the DB0, DB1, and DB2, , , 1, 2, can be derived as

(2) is the average length of the forwarding pointer chain where can be calculated as traversing the DB0s. (3) where is the length of the forwarding chain the first inter-DS is the number of inter-DS calls from call has to traverse and the calling DS to the called MT during the period that the called MT resides in the called DS, which may be initiated by different users in the calling DS. Note that after the first inter-DS call, the calling DB0 points to the called DB0 directly, thus the length of the forwarding chain is one. B. End-to-End Location Update and Call Delivery Delays The end-to-end delay suffered by a service request is simply the summation of the response time incurred by each database on the path which it traverses and the transmission delay incurred by the signaling path. In this paper, only the transmission delays incurred by international links are considered for simplicity. Let denote the transmission delay incurred by an international link between two DB0s. According to the location update procedure and call delivery procedure described in Secis tion III, the end-to-end location update delay

153

and the end-to-end call delivery delay is

(5) where for an inter-DS call, the transmission delay incurred by , and the international links along the forwarding chain is the transmission delay of sending the TLDN from the called DB2 to the calling DB2 is . Note that the called DB2 sends are given the TLDN to the calling DB2 directly. in (1). To obtain , and need to be evaluated first; this depends on the index of a database and is addressed in Sections IV-C and D. C. Evaluation of Database Access Cost The database access cost mainly consists of the following components: 1) access cost to secondary storage; 2) computation cost; and 3) communication cost. The first part is the cost involved in accessing the disk-resident part of a database. The computation cost refers to the cost of performing in-memory operations on the memory-resident part of a database. The communication cost is the cost of transferring the queries and their results between the queried database sites and the sites originating these queries. For large databases on disk, the access cost to secondary storage dominates the overall cost of a query. The number of disk block accesses is then used as the cost measurement. For memory-resident databases, the computation cost becomes the main concern. In distributed databases, the communication cost must be considered and minimized as well. However, it is difficult to consider all these cost components in a single cost function due to the difficulty of assigning appropriate weights to various cost components. For our application, we use the number of disk block accesses as the cost measure for the disk-resident files and the computation cost as the cost measure for the memory-resident files, respectively. The transmission delay incurred by the international links between DB0s is considered as the main communication cost involved in the distributed database system, which is included in the evaluation of the end-to-end delays in Section IV-B. be the number of data 1) Access Cost of the T-Tree: Let entries in a T-node and be the number of nodes in the T-tree. To keep the probability of node creation and deletion low, each node should be lightly loaded, i.e., have some free space on the full; the expected average. A node is assumed to be number of data items held in the T-tree, denoted by , is

The average number of comparisons involved in a search of [12]. Let be the time for a search the T-tree is be the time for a comparison. We have of the T-tree and (6)

(4)

For simplicity, we assume that deleting a value from the T-tree consumes the same amount of time for inserting a value

154


into the T-tree because most of the steps invoked by these two procedures are similar. In the following, an update is referred be the time for an to as an insert or a delete. Let update; then (7) where is the time for the other steps, excluding the search procedure involved in an update procedure. In location databases, only searches, inserts, and deletes are is required. The expected value of the service time of

(8) where is the probability that searches are invoked and is the probability that updates are invoked among all database operations. The variance of is readily derived as (9) where

is derived in [16] and is given by

(10) where , , , and are the relative cost coefficients of the following four operations, compared to : copying a value between two memory locations, T-node creating/deleting, tree balance checking, and tree rotation. and are available, the response time of Once is obtained using (1). 2) Access Cost of the B -Tree: Let be the number of levels in a B -tree. If the searched user record is residing in a database using B -tree as its index, the number of block accesses required to retrieve this user record is (one disk block access for each level plus one more block access to retrieve the data record). If the searched user record is not in the database, the number of block accesses invoked by the search is . Note that does not count the root node of the B -tree because the root node can be held in main memory. The number of levels in the B -tree, can be derived as

D. Selection of Indices for Location Databases In this section, we study various database indices that can provide high throughput for the mobility applications. The candidate indices for the location databases are the T-tree, B -tree, and direct file. From Section V-B, we will see that in terms of speed, the memory-resident direct file is the best, the T-tree the second, the disk-resident direct file the third, and the B -tree the slowest. If speed is the most desirable characteristic, the fastest index that can meet the storage capacity requirement is chosen. On the other hand, if more than one indices can meet the speed requirement of a database, the most economic one should be selected. In the following, we discuss the response time and the storage capacity requirement of each of the indices mentioned above. For convenience, our discussion is based on the location databases. Some notation is defined as follows. Total number of users in the whole mobile system. Storage capacity available for . Number of user entries in the index file of . Size of a user entry in the index. Number of users currently residing in the area. Size of a user service profile (for DB1, ). for all types of indices Note that for the DB0, discussed below. Also note that for the same database, the value may be different with various indices. of 1) Memory-Resident Direct File: The direct file requires that each user in the mobile system has an entry in the index regardless of its presence within the corresponding database for DB0, DB1, and DB2. To service area. That is, implement the direct file, we must have (12) For the DB0, if the searched MT is within the DB0 area, the service time of the DB0 is (one access to the index file plus one access to the data file), where is the memory access . Thus, the expected service time of time; otherwise, , is DB0,

(11) where is the number of record pointers held by the B -tree, are the orders for internal nodes and leaf nodes, and and respectively. The nodes are assumed to be 69% full since under this condition node splitting and combining rarely happen, thus insertion and deletion are very efficient [5]. Assume bytes long, a block pointer is bytes, a that a PTN is bytes, the disk block size is bytes, and record pointer is the size of the space reserved for control information is bytes. It can be derived that and . See [5] for details about the B -tree.

(13) The variance of

is derived as

(14) Applying (13) and (14) in (1), the response time for DB0, , can be computed. . Thus, For the DB1, the service time is fixed, i.e., . For DB2, if the inquired MT is residing in the


DB2 area, the service time is ; otherwise, The expectation of the service time of DB2 is given by

.

155

For DB0, replaces in the above expression. If the searched MT is within the DB0 area, the service time of DB0 is , where is the disk block access time; otherwise, . Similar to (13), the expected service time of DB0 can be derived as

(15) The variance of

is derived as (16)

be the size of a node pointer and be 2) T-Tree: Let the size of the pointer to the minimum (or maximum) element . To in a node. Then, the size of a node is , we must have implement the T-tree in the (17) For DB1 and DB2, . The expectation and variance of the service time of a database and can be can be calculated using (8) and (9), where , denoting and readily derived from (2). For database by and , respectively, we have

Given the values of , , , , , , , and , we can compute the response time for a location database employing the T-tree as its index using (1). 3) Disk-Resident Direct File: The discussion of the memory-resident direct file is applicable to the disk-resident direct file except that the disk block access time, denoted by , replaces the memory access time, , in all relevant formulas. 4) B -Tree: The total storage required for the B -tree, de, is noted by

It turns out that is the same as in (14) where is for the B -tree. replaced by and . For the DB2, For the DB1, if the inquired MT is residing in the DB2 area, the service time ; otherwise, . Similar to (15), the is expectation of the service time of DB2 can be derived as

It turns out that is the same as in (16) where is replaced by for the B -tree. and , we can compute the reAfter obtaining sponse times for DB0, DB1, and DB2 using (1). E. Signaling Load of Location Update and Call Delivery The proposed distributed database architecture has a significant impact on the traffic loads of the signaling links. In this subsection, the proposed database architecture is compared with the HLR-VLR architecture and the one-root hierarchical architecture in terms of the amount of signaling traffic within the wireline signaling network, generated by the location registration and call delivery procedures. For call delivery, only MT-to-MT calls are considered. The total amount of signaling loads for each database architecture is estimated on a per-DS basis, where the signaling loads on the local links within a DS and the signaling loads on the international trunks connecting DSs are calculated separately. 1) Multitree Architecture: By the assumption of symmetry of the distributed database system, all links connecting the DB0 and its DB1s can be considered to carry the same amount of signaling traffic. Similarly, all links between a DB1 and its DB2s be the total share the same amount of signaling loads. Let amount of signaling loads on the links between the DB1s and be the total amount of signaling loads on the the DB2s and links between the DB0 and the DB1s. As pointed out earlier, it is assumed that one DB2 or VLR serves one RA. We have

(19)

For DB1 and DB2, . Note that for DB1, should be replaced by the pointer to the DB2. To implement the B -tree , we should have . in The number of levels of a B -tree required for is (18)

where is the number of bytes in the message transferred by a location update request from one database to another database is the number of bytes in the message transmitted by and a call delivery request message. Note that the signaling traffic incurred by the message via which the called MSC/DB2 sends back the TLDN to the calling MSC/DB2 is omitted in this paper, because this cost would be the same for the multitree structure, the one-root structure, and the HLR-VLR structure. The total amount of signaling traffic on the local links within a DS is (20)

156


TABLE I SYSTEM PARAMETER VALUES

where the last term represents the signaling traffic incurred by sending the user’s service profile (whose size is ) from the old DB2 (when an MT changes its RA within the same DS) or the new DB0 (when an MT moves into a new DS) to the new DB2 during the location update process. Note that the signaling path between the new DB2 and the old DB2 or the new DB0 can be a direct route. The total amount of signaling traffic on the international trunks between DB0s is (21) where when an MT moves into a new DS, the service profile request message sent from the new DB0 to the old DB0 is bytes, and the service profile sent back from the old DB0 to the new DB0 is bytes. represents the route request traffic along the forwarding chain incurred by an inter-DS call. 2) One-Root Hierarchical Architecture: It is assumed that within a DS, the one-root structure has the same database subsystem as in the multitree structure, and all DB0s are connected to a centralized root database (RDB). The RDB is located in a certain country, called the home country, so that all DB0s rather than the DB0 located in the home country are connected to the RDB via international links. Under the same assumptions for the multitree architecture, the one-root architecture incurs the same . But amount of signaling traffic within a DS, i.e., the total amount of signaling traffic on the international trunks between DB0s is different, which is given by (22) where as an MT changes its DS, the new DB0 sends a service profile request message to the RDB , which sends a copy of the service profile to the new DB0 . The RDB also sends , which a registration cancellation message to the old DB0 removes the MT’s service profile and sends back a cancellation . When an inter-DS acknowledgment message to the RDB call occurs, the calling DB0 sends a route request message to the , which relays this message to the called DB0 . RDB 3) HLR-VLR Architecture: It is assumed that the HLR and the VLRs in an HLR-VLR database system correspond to the DB0 and the DB2s in a DS in the multitree architecture. The total amount of signaling traffic on the local links within an HLR-VLR database system consists of three parts: 1) location registration cost incurred by MTs that change RAs within the ; 2) registration HLR-VLR system, cancellation cost invoked to remove the service profiles in the old VLRs in the HLR-VLR system by MTs that move into an; and 3) call delivery cost, other HLR-VLR system,

. Thus, the total amount of signaling loads on the local links within an HLR-VLR database system is (23) With the HLR-VLR architecture, the signaling traffic on the international trunks consists of three parts: 1) the cost incurred by MTs moving from a VLR in the home country to a VLR in ; 2) the cost incurred by a visited country, MTs from other countries that change RAs within the visited , where it is assumed that country, of the MTs in an RA come from other countries; and 3) the , where it cost incurred by delivering inter-DS calls, is assumed that the called MT is in its home country. If the called MT is in a visited country, this cost would be doubled. Thus, the total amount of signaling loads on the international trunks in the HLR-VLR architecture is (24) Numerical results derived based on the analytic model of the signaling loads will be given in Section V. V. NUMERICAL PERFORMANCE RESULTS A. Mobility Model In order to estimate the end-to-end delays due to location update and call delivery, the average location update rate generated by an RA, , and the call rate originating from an RA, , should be determined first. To accomplish this, the simple of the users has uniform fluid flow model is used [17]. If speed , of them has speed , the rest of them does not move, and the direction of movement is uniformly distributed , the average arrival rate of location updates generover ated in an RA is [18] (25) where is the user density and is the length of the RA boundary. Assuming that the average call origination rate per terminal per hour is , we get the call rate originating from an RA (26) where

is the area of an RA.

B. Performance Evaluation and Numerical Examples To get meaningful numerical results, we summarize the system parameter values used in [17] and [18] as well as other derived values in Table I. These parameter values are used in


157

Fig. 6. Storage capacity required in DB0, DB1, and DB2 with various indices.

Fig. 5. Response time of location databases with various indices. (a) DB0. (b) DB1. (c) DB2.

Figs. 5–9. Note that the expected user density in future mobile network is estimated to be users/km [17], while in users/km is used. For the B -tree, we our examples bytes, bytes, bytes, also assume that bytes, and bytes. 1) Response Times of Location Databases: Fig. 5 shows the response times of DB0, DB1, and DB2 with various indices, , , , s, , where , , , s, , and

ms. From Fig. 5 we can see that the disk-resident indices incur much larger response times than the memory-resident indices, and the response times decrease in the following order for all location databases: B -tree, disk-resident direct file, T-tree, and memory-resident direct file. As the user density approaches certain values, the B -tree and the disk-resident direct file are saturated. On the other hand, the response times of the T-tree and the memory-resident direct file increase very slowly as the user density increases. This can be readily exfor all plained from (1). First, four types of indices. Second, over the range of considered in Fig. 5, for the memory-resident direct file and the T-tree, the uti, , is much less than 1 because lization of database due to the fast memory access time , thus the re, , is mainly determined by sponse time of database in (1), while for the disk-resident direct file and the B -tree, the utilization approaches 1 as approaches certain values due to a much larger disk block access time, , thus the value of the second term in (1) approaches infinity. Therefore, for all location databases, DB0, DB1, and DB2, in terms of response time, only the memory-resident direct file and the T-tree can support users/km . a user density 2) Storage Requirement of Location Databases: Fig. 6 illustrates the relationship between the storage capacity required in each location database and the user density, in which users and bytes. Only the memory-resident direct file and the T-tree are considered, since the disk-resident direct file and the B -tree cannot support the high user density in future mobile systems. From Fig. 6, the following points are observed. 1) For DB0, the T-tree consumes a larger amount of memory than the memory-resident direct file. This is because for both the direct file and the T-tree, each user in the whole mobile system has an entry in the index file, but the T-tree needs to store the PTN in each entry as well as extra control information in each T-node, and reserve some free space for future inserts, thus consuming more storage than the direct file.

158


2) For DB1, the T-tree requires a much smaller memory size than the direct file, e.g., for user density users/km , the memory capacities required by the T-tree and the direct file are about 2.3 MB and 1 GB, respectively. It is true because the T-tree only needs to set up index entries in the index file for the users currently staying in the service area of a DB1, while the direct file needs to keep an index entry in the index file for each user in the whole mobile system even though most of them are not visiting the coverage area of the DB1. 3) For DB2, the T-tree requires a much smaller memory capacity than the direct file, e.g., for user density users/km , the memory capacities required by the T-tree and the direct file are about 6.0 MB and 7.0 GB, respectively. The reason is that the T-tree only needs to set up index entries in the index file for the users currently residing in the service area of a DB2, while the direct file needs to keep an index entry in the index file for each user in the whole mobile system. Note that the index entry size of the direct file in DB1 and DB2 has a different value, i.e., 1 byte for the DB1 is sufficient to distinguish 256 different DB2s controlled by a DB1, and 7 bytes for the DB2 are needed to store the pointer to a user record. Thus, the DB2 would waste much more memory than the DB1 if the direct file is adopted. It becomes obvious that the T-tree is preferred for the DB1s and DB2s, especially in a future global mobile system, where the number of DB1s and DB2s could be very large and the extra storage required to implement the direct file would be huge. Based on the results from Figs. 5 and 6, the following policies are suggested to select the index for each location database. 1) The disk-resident direct file and the B -tree are not suitable for location databases because they cannot support a high user density. 2) The memory-resident direct file is implemented as the index of DB0 since it is faster and smaller than the T-tree. 3) The T-tree is used as the index of both DB1 and DB2 because it provides a speed fast enough to meet the delay restrictions for call delivery and location registration while consuming much less memory than the memory-resident direct file. For this choice, in order to support a user density of 400 users/km and a total number of 1 billion users in a global mobile system, DB0 requires 7.73-GB memory while DB1 and DB2 each need less than 10-MB memory. In future mobile networks, such memory demands should be able to be met. 3) End-to-End Delays in Location Registration and Call Delivery: It is important for the end-to-end delays in location registration and call delivery of the proposed database architecture to meet the delay requirement in telephone networks. In Fig. 7, we study the impact of the length of the forwarding chain traversing DB0s, , on the end-to-end location update delay and the end-to-end call delivery delay . The following parameters are used: users/km , ms, while the other system parameters use the same values as in Section V-B-I. As pointed out earlier, the DB0 uses the memory-resident direct file as its index, while the DB1s and DB2s use the T-tree as their in-

Fig. 7.

End-to-end delays T and T versus L .

dices. From Fig. 7, it can be seen that the effect of on is negligible, because only one international trunk, i.e., the trunk between the old DB0 and the new DB0, needs to be traversed whenever an MT changes its DS, and the change of the service is fairly small. On the time of DB0, , due to a varying increases as increases, other hand, the call delivery delay because more DB0s need to be queried and more international trunks between DB0s need to be traversed while delivering the first inter-DS call. After the first inter-DS call, all subsequent inter-DS calls from the same calling DS to the called MT can be routed from the calling DB0 to the called DB0 directly. However, even with a relatively high , say, 10, the average call deis still small. Therefore, the proposed database livery delay architecture can meet the end-to-end delay requirements for call setup and location registration with a very high user density as well as a very large total number of mobile subscribers. 4) Signaling Load Comparison Between Three Database Architectures: Fig. 8 compares the signaling loads on local links within a DS due to registration and call delivery in the proposed multitree architecture with those in the one-root architecture and the two-level HLR-VLR architecture. As pointed out earlier, it is assumed that the one-root architecture has the same structure of a DS as the multitree architecture, thus these two architectures have the same amount of signaling loads on local links within a DS. For the HLR-VLR architecture, the number of VLRs in a DS equals the number of DB2s in a DS of the multitree architecture. For demonstration purposes, it is assumed that bytes and bytes. Other system parameters are given in Table I. From Fig. 8, it can be seen that the signaling load on the local links within a DS due to location update and call delivery is smaller in the proposed multitree architecture than in the HLR-VLR architecture, and the signaling load difference increases as the user density increases. Fig. 9 compares the signaling loads on the international links between DSs due to location registration and call delivery for the three database architectures. To study the effect of the length of the forwarding chain on the performance of the proposed , 1 and 10 are considmultitree architecture, two values of


159

international traffic than the proposed structure and the one-root , , and play a major role structure. On the other hand, in determining the international traffic in the proposed structure and the one-root structure. While the proposed multitree architecture incurs a higher inter-DS call delivery cost than the , the one-root architecture one-root architecture when incurs a higher location registration and deregistration traffic than the multitree architecture due to the fact that in the one-root system, the root, the old DB0, and the new DB0 are most likely located in three different countries, thus invoking four international messages among these databases as an MT changes its DS. With the multitree architecture, the old DB0 and the new DB0 can communicate with each other directly, thus invoking only two international messages between the two DB0s as an MT changes its DS. Thus, the multitree architecture is more effective than the one-root architecture while handling inter-DS movements. Fig. 8.

Comparison of signaling loads on local links within a DS.

VI. CONCLUSION

Fig. 9.

Comparison of signaling loads on international links between DSs.

ered. For the HLR-VLR architecture, two values of , 5% and 10% are considered. Other system parameters are the same as in Fig. 8. From Fig. 9, we can see that over the given parameter range, the HLR-VLR architecture incurs the largest amount of international signaling traffic due to location tracking, which increases as increases. The proposed multitree architecture incurs the smallest amount of international signaling traffic, which increases. The international traffic due to loincreases as cation tracking in the one-root architecture is smaller than that in the HLR-VLR architecture but larger than that in the multitree architecture. The signaling load differences between these three architectures increase as the user density increases. The preceding observations can be explained as follows. With the multitree architecture and the one-root architecture, as an MT changes its RA (i.e., DB2 area) within a DS, no international signaling traffic is invoked, whereas in the HLR-VLR architecture, as an MT is roaming in a visited country, its location change needs to be reported to its home country where the HLR is located. As a result, the HLR-VLR structure incurs a higher

A distributed multitree database architecture has been proposed for location management in a global mobile system, where the location-independent PTNs are employed to support seamless global roaming. To support the anticipated large number of mobile users in the future mobile system, two efficient database access structures—the memory-resident direct file and the T-tree—were proposed to achieve high database throughput, so that the end-to-end delays in location registration and call delivery can meet the delay requirements in mobile networks. The proposed database architecture is scalable, robust, and efficient. Compared to the existing two-level location database architecture, the proposed database architecture can support a much higher user density while reducing signaling load significantly. Compared to the one-root tree architecture, the proposed architecture provides better scalability and reliability while supporting a larger user population at a lower signaling cost. For performance evaluation, analysis model was developed. Numerical results have revealed that the proposed database architecture can effectively handle the anticipated high update and query rates to the location databases in future mobile networks. The proposed database access structures are also suitable for other large centralized databases in mobile networks, such as the authentication center and the equipment identity register. ACKNOWLEDGMENT The authors would like to thank the anonymous reviewers for their comments, which have significantly improved the quality of this paper. REFERENCES [1] I. F. Akyildiz, J. Mcnair, J. S. M. Ho, H. Uzunalioglu, and W. Wang, “Mobility management in next-generation wireless systems,” Proc. IEEE, vol. 87, pp. 1347–1384, Aug. 1999. [2] B. G. Claybrook, File Management Techniques. New York: Wiley, 1983. [3] I.-R. Chen, T.-M. Chen, and C. Lee, “Agent-based forwarding strategies for reducing location management cost in mobile networks,” ACM/Baltzer J. Mobile Netw. Applicat., vol. 6, no. 2, pp. 105–115, 2001.

160

[4] S. Dolev, D. K. Pradhan, and J. L. Welch, “Modified tree structure for location management in mobile environments,” Comput. Commun., vol. 19, no. 4, pp. 335–345, 1996. [5] R. Elmasri and S. B. Navathe, Fundamentals of Database Systems, 2nd ed. Menlo Park, CA: Addison-Wesley, 1994. [6] J. S. M. Ho and I. F. Akyildiz, “Dynamic hierarchical database architecture for location management in PCS networks,” IEEE/ACM Trans. Networking, vol. 5, pp. 646–660, Oct. 1997. [7] , “Local anchor scheme for reducing signaling costs in personal communicaations networks,” IEEE/ACM Trans. Networking, vol. 4, pp. 709–725, Oct. 1996. [8] R. Jain and Y.-B. Lin, “An auxiliary user location strategy employing forwarding pointers to reduce network impacts of PCS,” ACM-Baltzer J. Wireless Netw., vol. 1, no. 2, pp. 197–210, July 1995. [9] R. Jain, Y.-B. Lin, C. Lo, and S. Mohan, “A caching strategy to reduce network impacts of PCS,” IEEE J. Select. Areas Commun., vol. 12, pp. 1434–1444, Oct. 1994. [10] R. Jain, S. Rajagopalan, and L. F. Chang, “Phone number portability for PCS systems with ATM backbones using distributed dynamic hashing,” IEEE J. Select. Areas Commun., vol. 15, pp. 96–105, Jan. 1997. [11] L. Kleinrock, Queueing Systems: Vol. I—Theory. New York: Wiley, 1976. [12] T. J. Lehman and M. J. Carey, “A study of index structures for main memory database management systems,” in Proc. 12th Int. Conf. Very Large Data Bases, Aug. 1986, pp. 294–303. [13] Y.-B. Lin and I. Chlamtac, Wireless and Mobile Network Architecture. New York: Wiley, 2001. [14] C. N. Lo and R. S. Wolff, “Estimated network database transaction volume to support wireless personal data communications application,” in Proc. IEEE Int. Conf. Communications, May 1993, pp. 1257–1263. [15] A. D. Malyan, L. J. Ng, C. M. Leung, and R. W. Donaldson, “Network architecture and signaling for wireless personal communications,” IEEE J. Select. Areas Commun., vol. 11, pp. 830–840, Aug. 1993. [16] Z. Mao, “Location management strategies for personal communications services networks,” Ph.D. dissertation, Dept. Electr. Comput. Eng., Univ. Miami, Miami, FL, 2000. [17] S. Mohan and R. Jain, “Two user location strategies for personal communications services,” IEEE Pers. Commun., pp. 42–50, First Quarter 1994. [18] X. Qiu and V. O. K. Li, “Performance analysis of PCS mobility management database system,” in Proc. IEEE IC3N, Sept. 1995, pp. 434–441. [19] S. Ratnasamy, P. Francis, M. Handley, and R. Karp, “A scalable content-addressable network,” in Proc. ACM SIGCOMM, Aug. 2001, pp. 161–172. [20] N. Shivakumar, J. Jannink, and J. Widom, “Per-user profile replication in mobile environments: Algorithms, analysis, and simulation results,” ACM/Baltzer J. Mobile Netw. Applicat., vol. 2, no. 2, pp. 129–140, Oct. 1997. [21] I. Stoica, R. Morris, D. Karger, M. F. Kaashoek, and H. Balakrishnan, “Chord: A scalable peer-to-peer lookup service for Internet applications,” in Proc. ACM SIGCOMM, Aug. 2001, pp. 149–160.


[22] E. D. Sykas and M. E. Theologou, “Numbering and addressing in IBCN for mobile communications,” Proc. IEEE, vol. 79, pp. 230–240, Feb. 1991. [23] J. Z. Wang, “A fully distributed location registration strategy for universal personal communication systems,” IEEE J. Select. Areas Commun., vol. 11, pp. 850–860, Aug. 1993.

Zuji Mao (M’00) received the B.E. and M.E. degrees in electrical engineering from Tsinghua University, Beijing, China, in 1989 and 1994, respectively, and the Ph.D. degree in electrical engineering from the University of Miami, Coral Gables, FL, in 2000. He is currently a Senior Software Engineer with the Integrated Network Solutions Group, Lucent Technologies Inc., Westford, MA. He was with the Department of Physics, Tsinghua University, from 1989 to 1991 and with the Department of Automation, Tsinghua University, from 1994 to 1996. His current research interests include mobility management and multiservice switch software. Dr. Mao received the joint Best Paper Award for the IEEE LCN 2003. He was a recipient of the Graduate School Fellowship from the University of Miami from 1996 to 1999.

Christos Douligeris (S’82–M’89–SM’95) received the Diploma in electrical engineering from the National Technical University of Athens, Athens, Greece, in 1984 and the M.S., M.Phil., and Ph.D. degrees from Columbia University, New York, NY, in 1985, 1987, and 1990, respectively. He has held positions with the Department of Electrical and Computer Engineering, University of Miami, Coral Gables, FL, where he reached the rank of Associate Professor and was the Associate Director for Engineering of the Ocean Pollution Research Center. He is currently an Associate Professor in the Department of Informatics, University of Piraeus, Piraeus, Greece. He has served on technical program committees of several conferences. His main technical interests lie in the areas of performance evaluation of high-speed networks, neurocomputing in networking, resource allocation in wireless networks and information management, and risk assessment and evaluation for emergency response operations. Dr. Douligeris is an editor of the IEEE Communications Letters, Computer Networks, IEEE Network, a former technical editor of the IEEE Communications Magazine, and a member of the ACM and the Technical Chamber of Greece.