stochastic clustering and self-organization of gross

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

A Distributed Database Architecture for GlobalRoaming in Next-Generation Mobile Networks

Zuji Mao, Member, IEEE, and Christos Douligeris, Senior Member, IEEE

Abstract—The next-generation mobile network will support ter-minal mobility, personal mobility, and service provider portability,making global roaming seamless. A location-independent personaltelecommunication number (PTN) scheme is conducive to imple-menting such a global mobile system. However, the nongeographicPTNs coupled with the anticipated large number of mobile usersin future mobile networks may introduce very large centralizeddatabases. This necessitates research into the design and perfor-mance of high-throughput database technologies used in mobilesystems to ensure that future systems will be able to carry effi-ciently the anticipated loads. This paper proposes a scalable, ro-bust, efficient location database architecture based on the loca-tion-independent PTNs. The proposed multitree database architec-ture consists of a number of database subsystems, each of whichis a three-level tree structure and is connected to the others onlythrough its root. By exploiting the localized nature of calling andmobility patterns, the proposed architecture effectively reduces thedatabase loads as well as the signaling traffic incurred by the lo-cation registration and call delivery procedures. In addition, twomemory-resident database indices, memory-resident direct file andT-tree, are proposed for the location databases to further improvetheir throughput. Analysis model and numerical results are pre-sented to evaluate the efficiency of the proposed database architec-ture. Results have revealed that the proposed database architecturefor location management can effectively support the anticipatedhigh user density in the future mobile networks.

Index Terms—Database architecture, location management, lo-cation tracking, mobile networks.

I. INTRODUCTION

THE next-generation mobile network will be an integratedglobal system that provides heterogeneous services across

network providers, network backbones, and geographicalregions [1]. Global roaming is a basic service of the futuremobile networks, where terminal mobility, personal mobility,and service provider portability must be supported. A non-geographic personal telecommunication number (PTN) foreach mobile user is desirable to implement these types ofmobile freedom. With location-independent PTNs, users canaccess their personalized services regardless of terminal orattachment point to the network; they can move into differentservice provider’s network and continue to receive subscribedservices 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/ACMTRANSACTIONS ON NETWORKING Editor N. Vaidya.

Z. Mao is with the Integrated Network Solutions Group, Lucent TechnologiesInc., 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 ofcapacity than the location-dependent numbering scheme wherethe capacity of the subscriber number (SN) may be exhaustedin a highly populated area, whereas the SN’s capacity iswasted in a sparsely populated area [22]. However, using thelocation-independent numbering plan may introduce largecentralized databases into a mobile system. To make thingsworse, each call may require an interrogation to the centralizeddatabases, thus signaling traffic will grow considerably and callsetup time may increase dramatically. The large centralizeddatabases may become the bottleneck of the global mobilesystem, thus necessitating research into the design and per-formance of high-throughput database technologies as used inmobile networks to meet future demands.

Location management is one of the most important func-tions to support global roaming. Location management proce-dures involve numerous operations in various databases. Thesedatabases record the relevant information of a mobile user, tracethe user’s location by updating the relevant database entries,and map the user’s PTN to its current location. In current cel-lular networks location tracking is based on two types of loca-tion databases [13], [17]: the home location register (HLR) andthe visitor location register (VLR). In general, there is an HLRfor each mobile network. Each mobile subscriber has a serviceprofile stored in the HLR. The user profile contains informa-tion such as the service types subscribed, the user’s current lo-cation, etc. The VLR where a mobile terminal (MT) resides alsokeeps a copy of the MT’s user profile. A VLR is usually colo-cated with a mobile switching center (MSC), which controls agroup of registration areas (RAs). Whenever an MT changes itsRA, the HLR is updated to point to the new location, and theMT is deregistered from the old VLR. As an incoming call ar-rives, the called MT’s HLR is queried to get the location of theserving VLR of the MT, then a routing address request messageis sent to the MSC/VLR. The MSC allocates a temporary localdirectory number (TLDN) to the called MT and sends back theTLDN to the HLR, which in turn relays this information to thecalling MSC. A connection to the called MSC then can be setup through the SS7 network. An MSC/VLR may not know theaddress of an MT’s HLR, and a global title translation (GTT) isneeded to get the address of the MT’s HLR. With the two-levelHLR-VLR database architecture, the HLR needs to be accessedfor each location update or call delivery. Due to an expectedmuch higher user density in the future mobile networks, the up-dating and querying loads on the location databases will be veryheavy [14] and the two-level database architecture will becomeinfeasible.

1063-6692/04$20.00 © 2004 IEEE

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

In this paper, a distributed hierarchical database architecturebased on the location-independent PTN plan is proposed to sup-port location tracking in a global mobile system. Before furtheraddressing the proposed database architecture, we describe re-lated work first.

A. Previous Work

There is a growing literature into studying alternatives to thecurrent two-level database architecture. Two main categories ofstrategies have been proposed in the previous studies [1]: auxil-iary strategies based on the two-level database architecture anddistributed strategies employing the hierarchical database archi-tecture.

The auxiliary strategies try to exploit the spatial and temporallocality in each user’s calling and mobility patterns to reduce thesignaling traffic and database loads. Examples include the for-warding 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 thenew VLR of an MT to avoid a location update at the HLR as theMT changes its RA. When a call for the MT arrives, the HLR isqueried first to determine the first VLR which the MT was reg-istered at, and a forwarding pointer chain is followed to locatethe MT in its current VLR. The forwarding strategy reduces lo-cation update signaling but increases the call setup delay. Thus,the length of the forwarding point chain needs to be limited. Itis shown that this scheme may not always result in a cost sav-ings as compared to the standard IS-41 scheme. The forwardingscheme is effective only when the call arrival rate is low rela-tive to the mobility rate for an MT. With the anchoring strategy[7], location updates are performed at a nearby VLR (i.e, localanchor) for an MT to reduce signaling traffic between the HLRand the VLRs. The HLR maintains a pointer to the MT’s localanchor. As an incoming call occurs, the HLR forward the callto the local anchor, which in turn queries the serving VLR ofthe MT for a TLDN. The call delivery time is increased due toone extra database query to the local anchor. Similar to the for-warding scheme, the local anchoring scheme is efficient onlywhen an MT’s call arrival rate is low relative to its mobility rate.With the caching strategy [9], an MT’s location obtained from aprevious call is cached and re-used for subsequent calls to thatMT. After a cache entry of the MT’s location information is cre-ated at a signal transfer point (STP), if another call for the MTis received by the STP, the STP will forward the call to the VLRas specified by the cache. If the MT is still in the same VLR,a hit occurs and the call is successfully delivered. However, ifthe MT has moved to another VLR, a miss occurs and the IS-41call delivery process has to be followed to find the MT, thus in-curring a much longer setup delay. When an MT changes its lo-cation more often than receiving calls, the caching scheme maybecome 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 thesereplicated databases can be routed without querying the HLR.When the MT changes its location, all replicated databases needto be updated for the MT, thus incurring a high database updateload and signaling traffic, especially for highly mobile users.In summary, each auxiliary strategy outperforms the IS-41 only

under certain calling and mobility parameters. As the cell sizesbecome smaller to support an increasing user density and thenumber of mobile subscribers increases, even these augmenta-tions will not be sufficient to meet the future demands of mobilenetworks.

It becomes obvious that reducing the access rate to the cen-tralized HLR is a critical step to support an increasing numberof mobile subscribers. The hierarchical database architecturecan reduce the access load on an upper-level database by dis-tributing query load into the lower-level databases, thus it hasbeen 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 currentcellular systems. The DR periodically computes the location in-formation distribution strategy for each associated MT in orderto achieve a reduced access rate to the HLR. The performanceof this scheme depends on the availability and accuracy of theuser’s calling and mobility parameters. It is usually computa-tionally intensive to obtain these parameters. Given the largenumber of MTs, the burden on the DRs would be very heavy.A multilevel hierarchical database architecture was introducedin [23] for location tracking in personal communications sys-tems (PCSs). However, the numbering plan used to identify anMT is location-dependent, which is similar to the telephonenumber plan, thus the MT needs to be allocated a new numberwhenever it changes its home service area. In [15], a distributeddatabase architecture based on the IEEE 802.6 MAN was pro-posed, only suitable for MAN-wide mobile systems. In [18],a three-level hierarchical database architecture for mobile net-works was presented based on the location-independent num-bering plan. There is a common drawback with the database ar-chitectures proposed in these previous studies. The whole data-base system had only one centralized root database, where alluser profiles were maintained. For a worldwide-scale mobilesystem, it would be impractical to store and manage subscriberinformation in a single centralized database due to the expectedhuge number of subscribers. Furthermore, the crash of the rootdatabase may paralyze the entire system. We will compare inmore detail our proposed database architecture with the one-rootarchitecture in Sections I-B and V. In [4], a set-ary butterflystructure was adopted to replace the root and some of the higherlevels of the tree structure, relieving the burden on the root data-base while increasing the robustness of the database system. Inessence, this structure spread the database loads through the useof additional nodes as well as of extra node connections, thusincurring a higher maintenance cost than the pure tree struc-ture, especially in a global mobile system where the extra nodesneed to be deployed across different countries and internationaltrunks 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 subsys-tems (DSs), each of which is a three-level tree structure. Morethan three levels may be adopted in a DS. However, addingmore levels will introduce longer delays in location registrationand call delivery. These DSs communicate with each other onlythrough their root databases, DB0s, which are connected to


Fig. 1. Proposed multitree database architecture.

the others by the public switched telephone network (PSTN),ATM networks, or other networks. The proposed databasearchitecture is motivated by the following.

1) A location-independent PTN provides a basis for globalroaming in the next-generation mobile networks whereterminal mobility, personal mobility, and service providerportability will be implemented. A mobile subscriber canretain its lifelong PTN regardless of its location and ser-vice provider.

2) The multitree database architecture is much more robustthan the one-root hierarchical architecture. In the pro-posed architecture, an MT’s profile is stored in one ofthe root databases according to its current location. Thus,each root database only maintains a small portion of theuser profiles in the global mobile system. The crash ofone root database will not disrupt the operation of otherroot databases, and the recovery of the failed root data-base is much easier than in the one-root database archi-tecture where all user profiles need to be recovered oncethe root is crashed.

3) The multitree database architecture is scalable, which iscrucial to support continuously increasing number of mo-bile subscribers in future mobile networks. When the ca-pacity of a root database is saturated, a new DS is readilyadded. More importantly, the end-to-end delay in loca-tion registration and call delivery will not increase dueto such an expansion in the mobile network. On the otherhand, with the one-root structure, when the capacity of theroot or a high-level database is saturated, more levels ofdatabases need to be added in order to reduce the burdenon the root or high-level databases. This will increase thedelays in location registration and call delivery.

4) The proposed multitree database system is easy to expandand maintain in the multioperator environment of a globalmobile system. With the multitree architecture, each ser-vice provider can have its own DSs and it is straight-forward for a service provider to expand its service cov-

erage by adding new DSs. It is also easy to operate andmanage a DS when the DS is wholly owned by a singleservice provider. The one-root architecture, however, maynot have such advantages.

5) No GTT is required in the proposed database architecture,where a signaling message is only sent from a databaseto another database in an adjacent level within the samesubtree or from a DB0 to another DB0. Since a messagesender always contains the address of the receiver in itsdatabase, no GTT is required. This greatly simplifies theimplementation of the proposed architecture.

In addition to the multitree location database architecture,this paper also proposes indexing schemes for each type oflocation databases and analyzes their efficiency and cost interms of database access time and storage requirement. Thelocation registration and call delivery procedures based on theproposed database structure are also given. Analysis modelsare developed to study the service response time of each typeof databases in the proposed multitree architecture as wellas the end-to-end delays incurred by the proposed locationregistration and call delivery procedures. The proposed archi-tecture is compared with the one-root architecture as well asthe HLR-VLR architecture in terms of the signaling loads dueto location registration and call delivery. Numerical resultshave demonstrated that the proposed database architectureoutperforms the one-root architecture and the HLR-VLRarchitecture, and can effectively cope with the anticipated highaccess rates to various location databases in future mobilenetworks while meeting the end-to-end delay requirements forlocation registration and call delivery. The remainder of thispaper is organized as follows. Section II describes the proposeddistributed database architecture for location tracking as wellas the indices of the location databases. Section III presentsthe database searching strategies associated with the locationupdate and call delivery procedures. Section IV describes theanalytic model for performance evaluation of the proposeddatabase architecture. Numerical results are presented inSection 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 isa multitree structure, where each subsystem is a three-level ar-chitecture (Fig. 1), referred to as a database subsystem (DS) inthis paper. Various DSs may represent networks operated pos-sibly by different service providers. All these DSs are intercon-nected together via a fixed network, such as PSTN or ATM net-work, and communicate with each other only through their rootdatabases. This architecture can support a multioperator envi-ronment which is expected in future mobile networks. In eachDS, databases DB0 and DB2 may correspond to the HLR andthe VLR in the two-level database system, respectively. EachDB2 may control an RA where a user can roam freely withouttriggering registrations. Each DB2 is colocated with an MSC,which performs call processing on origination or terminationcalls. A number of DB2s are grouped into one DB1 and several


DB1s are connected to a single DB0. Each DB1 and DB0 alsoneeds a switch, called the STP, that provides routing function-ality for message exchange between various location databases.The DB0 maintains the service profile for each user currentlyresiding in its service area, and maintains an entry for each userin the global mobile system. The entry contains either a pointerto another DB0 where the user is residing or a pointer to the userrecord that contains a pointer to the DB1 with which the user iscurrently associated. Each DB1 has an entry for every currentlyresiding user, storing a pointer to the DB2 the user is currentlyvisiting. Every DB2 has a copy of the service profiles of theusers currently roaming within its area. With this architecture,the frequency of queries to the higher level databases is greatlyreduced 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 databaseDB0—need to be visited. This increases the end-to-end delaysin call setup and location registration. In addition, as thenumber of mobile subscribers increases, the access time ofeach database is increased, which also increases the end-to-enddelays. To meet the delay demands in call setup and locationregistration, the number of database levels in a DS has to belimited. Moreover, to support a larger amount of mobile sub-scribers while keeping the end-to-end delays low, it is criticalto reduce the access times to the databases. Thus, investigationinto efficient database access indices for the location databasesis as important as research into the overall location databasearchitecture.

B. Two Efficient Database Indices

A database usually consists of two parts: an index file anda data file. The index file contains an access structure calledindex, which provides search paths for locating the records inthe data file. The index determines the database access time,thereby being the critical component for improving databasethroughput. Efficient indices should be based on applicationcharacteristics 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 varietyof databases in mobile systems. There are two classes ofindices: the disk-oriented index, such as the B -tree, and thememory-resident index, such as the AVL-tree and the T-tree.While the disk-oriented indices are designed primarily to mini-mize the number of disk block accesses and to minimize diskspace, the memory-resident indices aim to reduce computationtime while using as little memory as possible. For real-timeapplications, the memory-resident indices are preferred due totheir much faster access times than the disk-resident indices.The indices can also be classified into the following twocategories: the order-preserving indices and the randomizingindices. The primary order-preserving indices include arrays,B-trees, AVL-trees, T-trees, and direct files. The randomizingindices include various hashing indices. Essentially, the directfile is a special form of hashing indices. We can call the directfile perfect hashing due to its collision-free property and useit in the DB0s due to its fast response time and easy imple-mentation. The hashing indices have been applied in various

Fig. 2. (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 mul-tiple GTT servers by distributing users’ PTN-to-HLR addressmappings evenly among the GTT servers. In the peer-to-peersystems [19], [21], hash-based techniques were used to mapfile names to their locations in the peer-to-peer systems whilebalancing the query load amongst all nodes. The hardest taskof applying hashing techniques is to design efficient hash func-tions that can minimize collisions while keeping memory usagelow. On the other hand, the order-preserving indices are mucheasier to implement and provide guaranteed upper boundson the search time while keeping memory usage efficient.It has been shown in [12] that among the order-preservingindices-array, B-tree, AVL-tree, and T-tree, the T-tree providesthe best overall performance for a mix of searches, inserts,and deletes at a relatively low storage cost. Inserts and deletesincurred by location update as well as searches required by calldelivery in the DB1 and the DB2 make the T-tree suitable forthese databases. On the contrary, the biggest drawback with thearray is that data movement is for each update, thus thearray seems only suitable for a read-only environment [12]. TheAVL-tree has poor storage utilization since each node storesonly one data item while requiring two pointers and some othercontrol information. As mentioned earlier, we also suggest thatthe memory-resident direct file be used as the index for largedatabases such as DB0, etc., due to its much faster speed thanthe other order-preserving indices.

1) T-Tree: The T-tree, which evolved from the AVL-treeand the B-tree, is a binary tree in which each node calledT-node contains a number of data items, a parent pointer, aleft-child pointer, a right-child pointer, and some other controlinformation (Fig. 2). The T-tree is fast since it retains theintrinsic binary search nature of the AVL-tree. On the otherhand, unlike the AVL-tree that holds only one data item in eachnode, the T-tree contains a number of data items in each nodesimilar to the B-tree, thus having good storage utilization. Ina T-node, the data items are arranged in increasing order of


their keys. To find a value in the T-tree, a search algorithm forthe T-tree is needed. According to [12], one efficient searchalgorithm for the T-tree can be described as follows: 1) eachsearch begins with the root node; 2) if the search value is lessthan the minimum value of the node, then the left-child nodeis searched. Otherwise, the current node is marked for futureconsideration and the search goes down the subtree pointed toby the right-child pointer. When the search reaches a leaf, thelast marked node is searched using a binary search. The searchfails when the search value is not found in the marked nodethat bounds the search value (this node is called the boundingnode) 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 relation-ship between the record key and its storage location. The fastestsearching method to access a direct file is direct addressing [2].The key value is used as a relative record number that can betranslated into a hardware address by the system. When the di-rect file is memory resident, the hardware address is the memoryaddress. One potential disadvantage of direct addressing is thatspace must be reserved for every possible key value, resultingin wasting large amounts of storage. However, when the numberof possible key values is relatively close to the number of actualkey values, direct addressing is very cost effective. Wheneveraccess time is the vital criterion, even lower packing densitiesare acceptable. To use direct addressing, the key values must benumeric, in ascending order, and the records must have fixedlength. The location-independent PTN numbering plan makesdirect addressing quite suitable for large centralized databasesin mobile networks.

C. Organizations of Location Databases

1) Organization of DB0: The DB0 consists of an index fileand a data file. With the location-independent numbering planbeing adopted, every subscriber in the whole mobile system hasan entry in the index file. If the direct file is used, each indexentry only contains a pointer. When a user is residing in the cur-rent DS area, the pointer is pointing to the user’s service profilestored in the data file. The user service profile contains a pointerto the DB1 where the user is visiting. When the user is stayingin another DS, the pointer in the user’s index entry points to theDB0 associated with that DS. All entries in the index file are al-located the same size of storage and stored in increasing order ofthe users’ PTNs so that direct addressing can be used to retrievea record from the index file. Note that the PTN does not needto be stored in the index entry. On the other hand, the T-tree orthe B -tree needs to include the PTN in each index entry andstore other index management information, thus requiring morememory capacity than the direct file. Therefore, the direct fileis 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 recordto store the user’s service profile. Note that the access time ofthe DB0 is independent of the database size when the direct filetechnique is employed (but the access time is affected by theaccess frequency of the DB0). This scalability feature is veryuseful for future mobility applications since the number of sub-scribers is expected to increase steadily.

2) Organization of DB1: Each DB1 consists only of onepart: the index file, in which each user currently residing in theDB1 area has a data item. Each data item in the index file con-sists of two fields: the user’s PTN and a pointer to the DB2 theuser is currently visiting. No other user information is storedin the DB1. Results from Section V reveal that the T-tree is apreferable technique for the index file of DB1.

3) Organization of DB2: Each of the database DB2s con-sists of two parts: the index file and the data file. Each user cur-rently residing in the DB2 area has an entry in the index. Eachentry in the index consists of two fields: the user’s PTN and apointer to the user record in the data file that stores the serviceprofiles for each user currently visiting this DB2 area. Resultsfrom Section V show that the T-tree is a preferable techniquefor the index file of DB2.

The choice of suitable indices for the DB0, DB1, and DB2will 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 asthe proposed database organizations. Location tracking consistsof two procedures: the location registration procedure and thecall delivery procedure. Location registration is the procedurethrough which a user reports its location to the network when-ever the user enters a new location. As an incoming call arrives,the call delivery procedure is invoked to deliver the call to theuser. For simplicity, in this paper, it is assumed that a DB2 onlycontrols one RA. In real applications, a DB2 may control sev-eral RAs.

A. Location Registration Procedure

With the previously defined file structures of DB0, DB1, andDB2 as well as the proposed multitree location database archi-tecture, the location update procedure in a global mobile systemcan be described as follows.

1) When a user enters a new RA, a registration request mes-sage is sent to the associated DB2 which in turn sends aregistration request message to the DB1 controlling thisarea. 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 indicatesthat the new DB2 is within the same DB1 area as theold DB2. A pointer to the new DB2 replaces the old onein the user’s entry in the DB1. No further query to theDB0 is needed. The DB1 sends a registration cancellationmessage to the old DB2, then go to step 8.

3) The fact that the user has no entry in this DB1 indicatesthat the user has moved to a new DB1 area. In the newDB1 an index entry is added to contain a pointer to thenew DB2 of the user. An update request is also sent to theassociated DB0.

4) The DB0 is checked to see if it contains the user’s serviceprofile. If no, this means that the user enters a new DS,then go to step 5a; otherwise, the DB0 updates the user’s


service profile to point to the new DB1 and sends a reg-istration cancellation message to the old DB1, then go tostep 7.

5)

a) The new DB0 sends a query to the old DB0 to re-quest the user’s service profile.

b) The new DB0 stores the user’s service profile andupdates the service profile to point to the new DB1.A copy of the user’s service profile is also sent tothe new DB2.

6)

a) The old DB0 sends the user’s service profile to thenew DB0.

b) The old DB0 updates the user’s entry in the indexfile to point to the new DB0, and deletes the userservice profile from its data file. A registration can-cellation message is sent to the old DB1.

7) The old DB1 deletes the user’s index entry, and sends aregistration cancellation message to the old DB2.

8) If the old DB2 is in the same DS as the new DB2, a copyof the user’s service profile is sent to the new DB2. Theuser’s index entry as well as the user’s service profile isremoved from the old DB2.

9) After receiving the user’s service profile, the new DB2sets up an index entry for the user and creates the user’sservice profile. The location registration procedure iscompleted.

Fig. 3 shows the flow chart of the location registration pro-cedure. Note that when a user changes its DS, with the pre-ceding location registration procedure, only the old DB0 pointsto the new DB0 directly. All other DB0s (except for the newDB0) still point to the old DB0. A forwarding pointer chaincorresponding to each of these DB0s is generated, like in thegeneral forwarding strategy [8]. The length of these forwardingpointer chains will increase as the user continues to changeits DS. As a result, the end-to-end setup delay will increasefor inter-DS calls. Compared to the single root structure, theproposed multitree structure achieves its robustness, scalability,maintainability, etc., at the expense of the necessary of synchro-nizing the DB0s to contain the call setup delay as an MT changesits DS. There exists a tradeoff between the overhead of DB0 syn-chronization and the call setup delay of inter-DS calls. Specifi-cally, if the “always synchronization” strategy is employed, i.e.,the index files in all DB0s are updated to point to the new DB0upon each DS change, a large amount of signaling traffic as wellas database access load will be triggered within a short time ifthe number of DSs is large, but the setup delay of inter-DS callsis minimized. On the other hand, if the “never synchronization”strategy is adopted, i.e., the index file of a DB0 is never updatedupon DS changes, the length of the forwarding chain continuesto increase as an MT changes its DS, so does the setup delayof inter-DS calls. One solution to this issue is to adjust the for-warding pointer chain during call delivery, called on-demandsynchronization. Specifically, when an inter-DS call has to tra-verse a forwarding chain going through more than two DB0s,the calling DB0 updates the callee’s index entry to point to thecalled 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. An-other DB0 synchronization strategy is to update a group of se-lected DB0s that generate relatively high call rates to the movingMT as the MT changes its DS. The rest of DB0s are updatedduring the first inter-DS calls. We refer to this strategy as partialsynchronization. Compared to the on-demand synchronizationstrategy, this strategy achieves a smaller expected setup delayof inter-DS calls by modestly increasing the synchronizationtraffic. This approach essentially combines the advantages ofthe forwarding strategy and the replication strategy. Note thatthe performance of the discussed DB0 synchronization strate-gies is closely related to the call-to-mobility ratio of an MT. Dueto limited space, this issue will be addressed in future study.

Another issue that needs to be addressed is the securityand privacy of the user’s service profile when it is transferredbetween DB0s. If the involved DB0s belong to the sameservice provider, no problem exists. If the user’s service profileis moved between two DSs operated by different serviceproviders, security issues should be considered. The security


issue is out of the scope of this paper and will not be addressedfurther.

B. Call Delivery Procedure

When an incoming call arrives, the call delivery procedure forthe callee can be performed in the following steps:

1) When a call is detected in the caller’s MSC, the caller’sDB2 is checked to see if an index entry for the calleeexists. If yes, go to step 5, and no further queries to theDB1 and the DB0 are required. Otherwise, a query is sentto the associated DB1, then go to step 2.

2) The DB1 examines if the callee has an entry in its indexfile. If yes, go to step 4, and no further query to the DB0is required. Otherwise, a query is sent to the associatedDB0, then go to step 3.

3) The DB0 examines if the callee is associated with one ofits DB1s. If yes, the DB0 sends a routing address requestmessage to the DB1, then go to step 4; otherwise, go tostep 7.

4) The DB1 determines the callee’s DB2 and sends a queryto 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 thecalling MSC.

6) After receiving the TLDN, the calling MSC sets up a con-nection to the called MSC associated with the callee’scurrent DB2. Then the call delivery process stops.

7) If the callee is residing in another DS, a query is sent to theassociated DB0. The searching process is repeated fromstep 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 theproposed database architecture. This will simplify the deploy-ment of the proposed strategy while reducing the overall systemcost.

IV. ANALYTIC MODEL

In this section, the access rates to the location databases aswell as the end-to-end delays in location registration and calldelivery of the proposed database architecture are given. In ad-dition, the access costs of the T-tree and the B -tree are eval-uated while formulas for the response times of the direct file,T-tree, and B -tree as well as their storage capacity require-ments are presented. Finally, the signaling load of location reg-istration and call delivery is evaluated for the multitree architec-ture, 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 bufferingqueue. The database provides service to queries using thefirst-come-first-served (FCFS) principle. For simplicity, thewait queue is usually assumed to be infinite. Due to the largenumber of users in future mobile networks, it has been shownin [18] that the arrival traffic to a database can be approximatedby a Poisson process. We also assume that the service time ofa database follows a general distribution. Thus, each database

Fig. 4. Flow chart of call delivery procedure.

can be modeled as an queue. The whole databasesystem forms a queueing network. The service response timeof database , denoted by , which consists of the waitingtime 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 hi-

erarchical database system structure is assumed, even thoughan unbalanced tree structure is likely in real applications. Forclarity, in this paper only the queries related to the location up-date and call delivery procedures are taken into account. Notethat the acknowledgment messages do not require any searchingor update at the database so that they can be omitted while calcu-lating the database access rate. It is observed that all queries to adatabase are started from the lowest-level database DB2 whereall the call and location update requests are originated. The loadson a database DB2 consist of two parts: the external query traffictriggered by the users residing in this DB2 area and the internalquery traffic routed by other databases in the system. The loadsentering the DB0 and the DB1s come from other databases. No


external query traffic enters the DB0 or DB1s directly. For sim-plicity, it is assumed that the queries to the databases in the samelayer are uniformly distributed, even though in real applicationssome databases may need to deal with a higher access load thantheir peers due to unbalanced user load across the system. Somenotation 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 anRA.Probability that a user enters a different DB0 area.Probability that a user enters a new DB1 area withinthe same DB0 area.Probability that the caller and the callee are in dif-ferent DB0 areas.Probability that the caller and the callee are in thesame DB0 area but different DB1 areas.Probability that the caller and the callee are in thesame DB1 area but different DB2 areas.

Based on the location update procedure and the call deliveryprocedure given in Section III, the arrival rates to the DB0, DB1,and DB2, , , 1, 2, can be derived as

(2)

where is the average length of the forwarding pointer chaintraversing the DB0s. can be calculated as

(3)

where is the length of the forwarding chain the first inter-DScall has to traverse and is the number of inter-DS calls fromthe calling DS to the called MT during the period that the calledMT resides in the called DS, which may be initiated by differentusers in the calling DS. Note that after the first inter-DS call, thecalling DB0 points to the called DB0 directly, thus the length ofthe 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 simplythe summation of the response time incurred by each databaseon the path which it traverses and the transmission delay in-curred by the signaling path. In this paper, only the transmis-sion delays incurred by international links are considered forsimplicity. Let denote the transmission delay incurred by aninternational link between two DB0s. According to the locationupdate procedure and call delivery procedure described in Sec-tion III, the end-to-end location update delay is

(4)

and the end-to-end call delivery delay is

(5)

where for an inter-DS call, the transmission delay incurred bythe international links along the forwarding chain is , andthe transmission delay of sending the TLDN from the calledDB2 to the calling DB2 is . Note that the called DB2 sendsthe TLDN to the calling DB2 directly. are givenin (1). To obtain , and need to be evaluatedfirst; this depends on the index of a database and is addressed inSections IV-C and D.

C. Evaluation of Database Access Cost

The database access cost mainly consists of the followingcomponents: 1) access cost to secondary storage; 2) computa-tion cost; and 3) communication cost. The first part is the costinvolved in accessing the disk-resident part of a database. Thecomputation cost refers to the cost of performing in-memoryoperations on the memory-resident part of a database. The com-munication cost is the cost of transferring the queries and theirresults between the queried database sites and the sites origi-nating these queries. For large databases on disk, the access costto secondary storage dominates the overall cost of a query. Thenumber of disk block accesses is then used as the cost measure-ment. For memory-resident databases, the computation cost be-comes the main concern. In distributed databases, the commu-nication cost must be considered and minimized as well. How-ever, it is difficult to consider all these cost components in asingle cost function due to the difficulty of assigning appro-priate weights to various cost components. For our application,we use the number of disk block accesses as the cost measurefor the disk-resident files and the computation cost as the costmeasure for the memory-resident files, respectively. The trans-mission delay incurred by the international links between DB0sis considered as the main communication cost involved in thedistributed database system, which is included in the evaluationof the end-to-end delays in Section IV-B.

1) Access Cost of the T-Tree: Let be the number of dataentries in a T-node and be the number of nodes in the T-tree.To keep the probability of node creation and deletion low, eachnode should be lightly loaded, i.e., have some free space on theaverage. A node is assumed to be full; the expectednumber of data items held in the T-tree, denoted by , is

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

(6)

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


into the T-tree because most of the steps invoked by these twoprocedures are similar. In the following, an update is referredto as an insert or a delete. Let be the time for anupdate; then

(7)

where is the time for the other steps, excluding thesearch procedure involved in an update procedure.

In location databases, only searches, inserts, and deletes arerequired. The expected value of the service time of is

(8)

where is the probability that searches are invoked andis the probability that updates are invoked among all databaseoperations. 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 thefollowing four operations, compared to : copying a value be-tween two memory locations, T-node creating/deleting, tree bal-ance checking, and tree rotation.

Once and are available, the response time ofis obtained using (1).

2) Access Cost of the B -Tree: Let be the number of levelsin a B -tree. If the searched user record is residing in a data-base using B -tree as its index, the number of block accessesrequired to retrieve this user record is (one disk block ac-cess for each level plus one more block access to retrieve thedata record). If the searched user record is not in the database,the number of block accesses invoked by the search is . Notethat does not count the root node of the B -tree because theroot node can be held in main memory. The number of levels inthe B -tree, can be derived as

(11)

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

. See [5] for details about theB -tree.

D. Selection of Indices for Location Databases

In this section, we study various database indices that can pro-vide high throughput for the mobility applications. The candi-date indices for the location databases are the T-tree, B -tree,and direct file. From Section V-B, we will see that in terms ofspeed, the memory-resident direct file is the best, the T-tree thesecond, the disk-resident direct file the third, and the B -tree theslowest. If speed is the most desirable characteristic, the fastestindex that can meet the storage capacity requirement is chosen.On the other hand, if more than one indices can meet the speedrequirement of a database, the most economic one should be se-lected. In the following, we discuss the response time and thestorage capacity requirement of each of the indices mentionedabove. For convenience, our discussion is based on the locationdatabases. 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, ).

Note that for the DB0, for all types of indicesdiscussed below. Also note that for the same database, the valueof may be different with various indices.

1) Memory-Resident Direct File: The direct file requiresthat each user in the mobile system has an entry in the indexregardless of its presence within the corresponding databaseservice area. That is, for DB0, DB1, and DB2. Toimplement the direct file, we must have

(12)

For the DB0, if the searched MT is within the DB0 area, theservice time of the DB0 is (one access to the index fileplus one access to the data file), where is the memory accesstime; otherwise, . Thus, the expected service time ofDB0, , is

(13)

The variance of is derived as

(14)Applying (13) and (14) in (1), the response time for DB0, ,can be computed.

For the DB1, the service time is fixed, i.e., . Thus,. 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

(15)

The variance of is derived as

(16)

2) T-Tree: Let be the size of a node pointer and bethe size of the pointer to the minimum (or maximum) elementin a node. Then, the size of a node is . Toimplement the T-tree in the , we must have

(17)

For DB1 and DB2, .The expectation and variance of the service time of a database

can be calculated using (8) and (9), where and can bereadily derived from (2). For database , denoting andby and , respectively, we have

Given the values of , , , , , , , and , we cancompute the response time for a location database employingthe T-tree as its index using (1).

3) Disk-Resident Direct File: The discussion of thememory-resident direct file is applicable to the disk-residentdirect 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-noted by , is

For DB1 and DB2, . Note that for DB1, should bereplaced by the pointer to the DB2. To implement the B -treein , we should have .

The number of levels of a B -tree required for is

(18)

For DB0, replaces in the above expression. If the searchedMT 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

It turns out that is the same as in (14) where isreplaced by for the B -tree.

For the DB1, and . For the DB2,if the inquired MT is residing in the DB2 area, the service timeis ; otherwise, . Similar to (15), theexpectation of the service time of DB2 can be derived as

It turns out that is the same as in (16) where isreplaced by for the B -tree.

After obtaining and , we can compute the re-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 signifi-cant impact on the traffic loads of the signaling links. In this sub-section, the proposed database architecture is compared with theHLR-VLR architecture and the one-root hierarchical architec-ture in terms of the amount of signaling traffic within the wire-line signaling network, generated by the location registrationand call delivery procedures. For call delivery, only MT-to-MTcalls are considered. The total amount of signaling loads foreach database architecture is estimated on a per-DS basis, wherethe signaling loads on the local links within a DS and the sig-naling loads on the international trunks connecting DSs are cal-culated separately.

1) Multitree Architecture: By the assumption of symmetryof the distributed database system, all links connecting the DB0and its DB1s can be considered to carry the same amount ofsignaling traffic. Similarly, all links between a DB1 and its DB2sshare the same amount of signaling loads. Let be the totalamount of signaling loads on the links between the DB1s andthe DB2s and be the total amount of signaling loads on thelinks between the DB0 and the DB1s. As pointed out earlier, itis assumed that one DB2 or VLR serves one RA. We have

(19)

where is the number of bytes in the message transferred bya location update request from one database to another databaseand is the number of bytes in the message transmitted bya call delivery request message. Note that the signaling trafficincurred by the message via which the called MSC/DB2 sendsback 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 totalamount of signaling traffic on the local links within a DS is

(20)


TABLE ISYSTEM PARAMETER VALUES

where the last term represents the signaling traffic incurred bysending the user’s service profile (whose size is ) from theold DB2 (when an MT changes its RA within the same DS) orthe new DB0 (when an MT moves into a new DS) to the newDB2 during the location update process. Note that the signalingpath between the new DB2 and the old DB2 or the new DB0 canbe a direct route.

The total amount of signaling traffic on the internationaltrunks between DB0s is

(21)

where when an MT moves into a new DS, the service profilerequest message sent from the new DB0 to the old DB0 isbytes, and the service profile sent back from the old DB0 to thenew DB0 is bytes. represents the route request trafficalong the forwarding chain incurred by an inter-DS call.

2) One-Root Hierarchical Architecture: It is assumed thatwithin a DS, the one-root structure has the same database sub-system as in the multitree structure, and all DB0s are connectedto a centralized root database (RDB). The RDB is located in acertain country, called the home country, so that all DB0s ratherthan the DB0 located in the home country are connected to theRDB via international links. Under the same assumptions for themultitree architecture, the one-root architecture incurs the sameamount of signaling traffic within a DS, i.e., . Butthe total amount of signaling traffic on the international trunksbetween DB0s is different, which is given by

(22)

where as an MT changes its DS, the new DB0 sends a serviceprofile request message to the RDB , which sends a copyof the service profile to the new DB0 . The RDB also sendsa registration cancellation message to the old DB0 , whichremoves the MT’s service profile and sends back a cancellationacknowledgment message to the RDB . When an inter-DScall occurs, the calling DB0 sends a route request message to theRDB , which relays this message to the called DB0 .

3) HLR-VLR Architecture: It is assumed that the HLR andthe VLRs in an HLR-VLR database system correspond to theDB0 and the DB2s in a DS in the multitree architecture. Thetotal amount of signaling traffic on the local links within anHLR-VLR database system consists of three parts: 1) locationregistration cost incurred by MTs that change RAs within theHLR-VLR system, ; 2) registrationcancellation cost invoked to remove the service profiles in theold VLRs in the HLR-VLR system by MTs that move into an-other HLR-VLR system, ; and 3) call delivery cost,

. Thus, the total amount of sig-naling loads on the local links within an HLR-VLR databasesystem is

(23)

With the HLR-VLR architecture, the signaling traffic on theinternational trunks consists of three parts: 1) the cost incurredby MTs moving from a VLR in the home country to a VLR ina visited country, ; 2) the cost incurred byMTs from other countries that change RAs within the visitedcountry, , where it is assumed that

of the MTs in an RA come from other countries; and 3) thecost incurred by delivering inter-DS calls, , where itis assumed that the called MT is in its home country. If the calledMT is in a visited country, this cost would be doubled. Thus, thetotal amount of signaling loads on the international trunks in theHLR-VLR architecture is

(24)

Numerical results derived based on the analytic model of thesignaling 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 up-date and call delivery, the average location update rate gener-ated by an RA, , and the call rate originating from an RA,

, should be determined first. To accomplish this, the simpleuniform fluid flow model is used [17]. If of the users hasspeed , of them has speed , the rest of them does notmove, and the direction of movement is uniformly distributedover , the average arrival rate of location updates gener-ated in an RA is [18]

(25)

where is the user density and is the length of the RAboundary.

Assuming that the average call origination rate per terminalper 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 thesystem parameter values used in [17] and [18] as well as otherderived values in Table I. These parameter values are used in


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 mobilenetwork is estimated to be users/km [17], while inour examples users/km is used. For the B -tree, wealso assume that bytes, bytes, bytes,

bytes, and bytes.1) Response Times of Location Databases: Fig. 5 shows the

response times of DB0, DB1, and DB2 with various indices,where , , , s, ,

, , , s, , and

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

ms. From Fig. 5 we can see that the disk-resident in-dices incur much larger response times than the memory-resi-dent indices, and the response times decrease in the followingorder for all location databases: B -tree, disk-resident directfile, T-tree, and memory-resident direct file. As the user den-sity approaches certain values, the B -tree and the disk-resi-dent direct file are saturated. On the other hand, the responsetimes of the T-tree and the memory-resident direct file increasevery slowly as the user density increases. This can be readily ex-plained from (1). First, for allfour types of indices. Second, over the range of considered inFig. 5, for the memory-resident direct file and the T-tree, the uti-lization of database , , is much less than 1 because

due to the fast memory access time , thus the re-sponse time of database , , is mainly determined byin (1), while for the disk-resident direct file and the B -tree, theutilization approaches 1 as approaches certain values due toa much larger disk block access time, , thus the value of thesecond term in (1) approaches infinity. Therefore, for all loca-tion databases, DB0, DB1, and DB2, in terms of response time,only the memory-resident direct file and the T-tree can supporta user density users/km .

2) Storage Requirement of Location Databases: Fig. 6 il-lustrates the relationship between the storage capacity requiredin each location database and the user density, in which

users and bytes. Only the memory-residentdirect file and the T-tree are considered, since the disk-residentdirect file and the B -tree cannot support the high user densityin future mobile systems. From Fig. 6, the following points areobserved.

1) For DB0, the T-tree consumes a larger amount of memorythan the memory-resident direct file. This is because forboth the direct file and the T-tree, each user in the wholemobile system has an entry in the index file, but the T-treeneeds to store the PTN in each entry as well as extra con-trol information in each T-node, and reserve some freespace for future inserts, thus consuming more storage thanthe direct file.


2) For DB1, the T-tree requires a much smaller memorysize than the direct file, e.g., for user density

users/km , the memory capacities required bythe 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 setup index entries in the index file for the users currentlystaying in the service area of a DB1, while the direct fileneeds to keep an index entry in the index file for eachuser in the whole mobile system even though most ofthem are not visiting the coverage area of the DB1.

3) For DB2, the T-tree requires a much smaller memorycapacity than the direct file, e.g., for user density

users/km , the memory capacities required by theT-tree and the direct file are about 6.0 MB and 7.0 GB, re-spectively. The reason is that the T-tree only needs to setup index entries in the index file for the users currentlyresiding in the service area of a DB2, while the direct fileneeds to keep an index entry in the index file for each userin the whole mobile system.

Note that the index entry size of the direct file in DB1 and DB2has a different value, i.e., 1 byte for the DB1 is sufficient todistinguish 256 different DB2s controlled by a DB1, and 7 bytesfor the DB2 are needed to store the pointer to a user record.Thus, the DB2 would waste much more memory than the DB1if the direct file is adopted. It becomes obvious that the T-tree ispreferred for the DB1s and DB2s, especially in a future globalmobile system, where the number of DB1s and DB2s could bevery large and the extra storage required to implement the directfile would be huge.

Based on the results from Figs. 5 and 6, the following policiesare suggested to select the index for each location database.

1) The disk-resident direct file and the B -tree are not suit-able for location databases because they cannot support ahigh user density.

2) The memory-resident direct file is implemented as theindex 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 be-cause it provides a speed fast enough to meet the delay re-strictions for call delivery and location registration whileconsuming much less memory than the memory-residentdirect file. For this choice, in order to support a user den-sity of 400 users/km and a total number of 1 billionusers in a global mobile system, DB0 requires 7.73-GBmemory while DB1 and DB2 each need less than 10-MBmemory. In future mobile networks, such memory de-mands should be able to be met.

3) End-to-End Delays in Location Registration and Call De-livery: It is important for the end-to-end delays in location reg-istration and call delivery of the proposed database architec-ture to meet the delay requirement in telephone networks. InFig. 7, we study the impact of the length of the forwarding chaintraversing DB0s, , on the end-to-end location update delayand the end-to-end call delivery delay . The following param-eters are used: users/km , ms, while the othersystem parameters use the same values as in Section V-B-I. Aspointed out earlier, the DB0 uses the memory-resident direct fileas 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 isnegligible, because only one international trunk, i.e., the trunkbetween the old DB0 and the new DB0, needs to be traversedwhenever an MT changes its DS, and the change of the servicetime of DB0, , due to a varying is fairly small. On theother hand, the call delivery delay increases as increases,because more DB0s need to be queried and more internationaltrunks between DB0s need to be traversed while delivering thefirst inter-DS call. After the first inter-DS call, all subsequentinter-DS calls from the same calling DS to the called MT canbe routed from the calling DB0 to the called DB0 directly. How-ever, even with a relatively high , say, 10, the average call de-livery delay is still small. Therefore, the proposed databasearchitecture can meet the end-to-end delay requirements for callsetup and location registration with a very high user density aswell as a very large total number of mobile subscribers.

4) Signaling Load Comparison Between Three Database Ar-chitectures: Fig. 8 compares the signaling loads on local linkswithin a DS due to registration and call delivery in the proposedmultitree architecture with those in the one-root architecture andthe two-level HLR-VLR architecture. As pointed out earlier, itis assumed that the one-root architecture has the same struc-ture of a DS as the multitree architecture, thus these two ar-chitectures have the same amount of signaling loads on locallinks within a DS. For the HLR-VLR architecture, the numberof VLRs in a DS equals the number of DB2s in a DS of the multi-tree architecture. For demonstration purposes, it is assumed that

bytes and bytes. Other system pa-rameters are given in Table I. From Fig. 8, it can be seen thatthe signaling load on the local links within a DS due to locationupdate and call delivery is smaller in the proposed multitree ar-chitecture than in the HLR-VLR architecture, and the signalingload difference increases as the user density increases.

Fig. 9 compares the signaling loads on the international linksbetween DSs due to location registration and call delivery forthe three database architectures. To study the effect of the lengthof the forwarding chain on the performance of the proposedmultitree architecture, two values of , 1 and 10 are consid-


Fig. 8. Comparison of signaling loads on local links within a DS.

Fig. 9. Comparison of signaling loads on international links between DSs.

ered. For the HLR-VLR architecture, two values of , 5% and10% are considered. Other system parameters are the same asin Fig. 8. From Fig. 9, we can see that over the given parameterrange, the HLR-VLR architecture incurs the largest amount ofinternational signaling traffic due to location tracking, which in-creases as increases. The proposed multitree architecture in-curs the smallest amount of international signaling traffic, whichincreases as increases. The international traffic due to lo-cation tracking in the one-root architecture is smaller than thatin the HLR-VLR architecture but larger than that in the multi-tree architecture. The signaling load differences between thesethree architectures increase as the user density increases. Thepreceding observations can be explained as follows. With themultitree architecture and the one-root architecture, as an MTchanges its RA (i.e., DB2 area) within a DS, no internationalsignaling traffic is invoked, whereas in the HLR-VLR archi-tecture, as an MT is roaming in a visited country, its locationchange needs to be reported to its home country where the HLRis located. As a result, the HLR-VLR structure incurs a higher

international traffic than the proposed structure and the one-rootstructure. On the other hand, , , and play a major rolein determining the international traffic in the proposed struc-ture and the one-root structure. While the proposed multitreearchitecture incurs a higher inter-DS call delivery cost than theone-root architecture when , the one-root architectureincurs a higher location registration and deregistration trafficthan the multitree architecture due to the fact that in the one-rootsystem, the root, the old DB0, and the new DB0 are most likelylocated in three different countries, thus invoking four interna-tional messages among these databases as an MT changes itsDS. With the multitree architecture, the old DB0 and the newDB0 can communicate with each other directly, thus invokingonly two international messages between the two DB0s as anMT changes its DS. Thus, the multitree architecture is more ef-fective than the one-root architecture while handling inter-DSmovements.

VI. CONCLUSION

A distributed multitree database architecture has beenproposed for location management in a global mobile system,where the location-independent PTNs are employed to supportseamless global roaming. To support the anticipated largenumber of mobile users in the future mobile system, twoefficient database access structures—the memory-residentdirect file and the T-tree—were proposed to achieve highdatabase throughput, so that the end-to-end delays in locationregistration and call delivery can meet the delay requirementsin mobile networks. The proposed database architecture isscalable, robust, and efficient. Compared to the existingtwo-level location database architecture, the proposed databasearchitecture can support a much higher user density whilereducing signaling load significantly. Compared to the one-roottree architecture, the proposed architecture provides betterscalability and reliability while supporting a larger user pop-ulation at a lower signaling cost. For performance evaluation,analysis model was developed. Numerical results have revealedthat the proposed database architecture can effectively handlethe anticipated high update and query rates to the locationdatabases in future mobile networks. The proposed databaseaccess structures are also suitable for other large centralizeddatabases in mobile networks, such as the authentication centerand the equipment identity register.

ACKNOWLEDGMENT

The authors would like to thank the anonymous reviewers fortheir comments, which have significantly improved the qualityof 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 strate-gies for reducing location management cost in mobile networks,”ACM/Baltzer J. Mobile Netw. Applicat., vol. 6, no. 2, pp. 105–115,2001.


[4] S. Dolev, D. K. Pradhan, and J. L. Welch, “Modified tree structure forlocation 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, 2nded. Menlo Park, CA: Addison-Wesley, 1994.

[6] J. S. M. Ho and I. F. Akyildiz, “Dynamic hierarchical database archi-tecture 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 personalcommunicaations networks,” IEEE/ACM Trans. Networking, vol. 4, pp.709–725, Oct. 1996.

[8] R. Jain and Y.-B. Lin, “An auxiliary user location strategy employingforwarding pointers to reduce network impacts of PCS,” ACM-BaltzerJ. 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 reducenetwork 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 forPCS 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 mainmemory database management systems,” in Proc. 12th Int. Conf. VeryLarge Data Bases, Aug. 1986, pp. 294–303.

[13] Y.-B. Lin and I. Chlamtac, Wireless and Mobile Network Architec-ture. New York: Wiley, 2001.

[14] C. N. Lo and R. S. Wolff, “Estimated network database transactionvolume 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, “Networkarchitecture and signaling for wireless personal communications,” IEEEJ. Select. Areas Commun., vol. 11, pp. 830–840, Aug. 1993.

[16] Z. Mao, “Location management strategies for personal communicationsservices 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 com-munications services,” IEEE Pers. Commun., pp. 42–50, First Quarter1994.

[18] X. Qiu and V. O. K. Li, “Performance analysis of PCS mobility manage-ment database system,” in Proc. IEEE IC3N, Sept. 1995, pp. 434–441.

[19] S. Ratnasamy, P. Francis, M. Handley, and R. Karp, “A scalable con-tent-addressable network,” in Proc. ACM SIGCOMM, Aug. 2001, pp.161–172.

[20] N. Shivakumar, J. Jannink, and J. Widom, “Per-user profile replicationin 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 applica-tions,” in Proc. ACM SIGCOMM, Aug. 2001, pp. 149–160.

[22] E. D. Sykas and M. E. Theologou, “Numbering and addressing in IBCNfor mobile communications,” Proc. IEEE, vol. 79, pp. 230–240, Feb.1991.

[23] J. Z. Wang, “A fully distributed location registration strategy foruniversal personal communication systems,” IEEE J. Select. AreasCommun., vol. 11, pp. 850–860, Aug. 1993.

Zuji Mao (M’00) received the B.E. and M.E. degreesin electrical engineering from Tsinghua University,Beijing, China, in 1989 and 1994, respectively, andthe Ph.D. degree in electrical engineering from theUniversity of Miami, Coral Gables, FL, in 2000.

He is currently a Senior Software Engineer withthe Integrated Network Solutions Group, LucentTechnologies Inc., Westford, MA. He was withthe Department of Physics, Tsinghua University,from 1989 to 1991 and with the Department of Au-tomation, Tsinghua University, from 1994 to 1996.

His current research interests include mobility management and multiserviceswitch software.

Dr. Mao received the joint Best Paper Award for the IEEE LCN 2003. He wasa recipient of the Graduate School Fellowship from the University of Miamifrom 1996 to 1999.

Christos Douligeris (S’82–M’89–SM’95) receivedthe Diploma in electrical engineering from theNational 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 ofElectrical and Computer Engineering, Universityof Miami, Coral Gables, FL, where he reached therank of Associate Professor and was the AssociateDirector for Engineering of the Ocean Pollution

Research Center. He is currently an Associate Professor in the Departmentof Informatics, University of Piraeus, Piraeus, Greece. He has served ontechnical program committees of several conferences. His main technicalinterests lie in the areas of performance evaluation of high-speed networks,neurocomputing in networking, resource allocation in wireless networks andinformation management, and risk assessment and evaluation for emergencyresponse operations.

Dr. Douligeris is an editor of the IEEE Communications Letters, ComputerNetworks, IEEE Network, a former technical editor of the IEEE Communica-tions Magazine, and a member of the ACM and the Technical Chamber ofGreece.

stochastic clustering and self-organization of gross

Documents