Stanford University, CA Abstract. Increasing demand for wireless mobile communications, coupled with limited network resources,

Transcription

1 Eæcient PCS Call Setu Protocols æ Yingwei Cui 1, Derek Lam 2, Jennifer Widom 3, Donald C. Cox 4 Comuter Science & Electrical Engineering Dets. Stanford University, CA Abstract Increasing demand for wireless mobile communications, couled with limited network resources, has motivated investigation into alternative eæcient mobility management solutions. In this aer, we consider wireless PCS call setu rotocols. We roose a Lightweight Location Looku Protocol, which signiæcantly reduces the network signaling and setu delay during call setu. As an alternative, we extend the Reverse Virtual Call Setu technique of ë6ë and roose a Reverse Connection Setu rotocol that also erforms eæcient call setu, while minimizing the cost of failed call attemts. The two new rotocols have diæerent advantages, in articular when combined with location management techniques including HLRèVLR, HLRèVLR with artial relication, and HLRèVLR with caching. We study combinations of call setu rotocols with location management techniques and comare their erformance. Both analytical and simulation results are resented. ëkey Wordsë Location Management Technique, Call Setu Protocol. ëtechnique Areasë Personal Communications Services, Wireless Network Protocols, Mobile Communications Managements. 1 Corresonding author. Gates 444, Stanford, CA Tel: 415è cyw@cs.stanford.edu. 2 Tel: 415è Fax: 415è dlam@wireless.stanford.edu. 3 Tel: 415è Fax: 415è widom@cs.stanford.edu. 4 Tel: 415è Fax: 415è dcox@wireless.stanford.edu. æ Research artially suorted by the National Science Foundation under grantèncr and bypaciæc Bell Cororation. 1

2 1 Introduction Mobility management is a challenging roblem in wireless Personal Communication Services èpcsè ë2ë. In a PCS system, mobile users are located in system-deæned areas called cells that are groued into registration zones. Every user connects with the base station in his cell through the wireless medium. Base stations are connected by a æxed wired network and exchange data to erform call setus and deliver calls between diæerent cells. Mobility management allows the PCS system to track users' current locations for delivering incoming calls. Solutions to the mobility management roblem have two dimensions. One is the Location Management Technique èlmtè emloyed, which governs where user location information is stored, and how it is retrieved and udated. The other dimension is the Call Setu Protocol ècspè, which deænes the stes taken during call setus, such as retrieving the user location information, notifying the user of incoming calls, and setting u the circuit connection through the wired and wireless network aths. In ærst-generation wireless systems, such as the North American Advanced Mobile Phone Service èampsè ë12ë, the system ages every cell within the network to locate a user for call setu. Because of the radio bandwidth ineæciency of this method, second-generation systems, such as the Global System for Mobile ègsmè communication and the North American Digital Cellular, emloy a diæerent aroach as deæned in the GSM ë15ë and IS-41 ë22ë standards. In the IS-41 standard, each user is assigned a ermanent home zone. At any given time, the user location information is stored in a databases in the user's home zone èthe Home Location Register or HLRè, and also in a database in his current zone èthe Visitor Location Register or VLRè. We call LMTs relying on this database structure HLRèVLR. According to the call setu rotocol stated in the IS-41 standard, during a call setu, the system ærst erforms database lookus to ænd the user location information, called location looku. It then sets u the circuit connection from caller to callee, and ages the callee in his cell. While the IS-41 aroach eliminates system-wide aging, which vastly reduces the radio link signaling, it introduces remote database lookus that may incur a large amount of wired network traæc and long call setu delay ë13ë. Much eæort has been dedicated to develoing LMTs to imrove location looku erformance, as discussed in Section 1.1 below. In this aer, we consider the entire PCS call setu rocess, and we roose alternative CSPs to imrove the overall call setu erformance. We believe that as PCS systems scale to very large numbers of users, network bandwidth will become a signiæcant bottleneck. Thus, our goal is to minimize the extra network signaling and call setu delay introduced by the IS-41 style location lookus. At the same time, we can reduce the cost of failed call attemts èsuch as when the callee is not reachableè. Our contributions are: 1. A comlete seciæcation of the call setu rocess using æow charts. We consider a variety of CSPs including the currently existing and newly roosed ones, combined with diæerent HLRèVLR-based LMTs. 2

3 2. A new call setu rotocol, called Lightweight Location Looku Protocol èlillpè, that signiæcantly reduces the network signaling and setu delay associated with the PCS call setu rocess. The advantage of LiLLP is articularly clear when integrated with an HLRèVLR technique that uses artial relication ë19ë. 3. The Reverse Connection Setu èrecsè rotocol, an extended version of the Reverse Virtual Call Setu èrvcè technique of ë6ë. ReCS erforms eæcient call setus and minimizes the cost of failed call attemts, without requiring the global aging techniques that are necessary for RVC. 4. Performance analysis and simulation work that exlores the interactions between diæerent CSPs and LMTs, and extracts the best CSP-LMT air under what we believe to be realistic system conditions. 1.1 Related Work Much eæort has been focused on exloring eæcient location management techniques èlmtsè. Extensions to standard HLRèVLR techniques, such as HLRèVLR with artial relication ë1, 14, 19ë, and HLRèVLR with caching ë7ë, have been develoed to imrove wireless call setu erformance. The local anchoring scheme ë4ë has been roosed to limit database udate cost in HLRèVLR. The hierarchical database architecture ë21ë has been considered to achieve location indeendent or lifelong numbering. Extensions to the hierarchical scheme, such as HiPER ë8ë and HOPPER ë10ë, also have been studied to imrove location management system erformance èin work erformed by our grou at Stanfordè. The idea of Reverse Virtual Call Setu was ærst roosed in ë6ë. The rotocol reduces PCS call setu delay and network cost for failed call attemts using an overlaid global aging network and a reverse connection setu strategy. In this aer, we devise new CSPs and combine existing HLRèVLR-based LMTs with them. Our goal is to exlore the CSP-LMT combinations that achieve the best call setu erformance, while eliminating the requirement of a global aging network. 1.2 Paer Outline In Section 2, we describe the PCS environment and establish terminology. In Section 3, three CSPs are seciæed: the IS-41 standard, our Lightweight Location Looku ProtocolèLiLLPè, and our Reverse Connection Setu èrecsè rotocol. We use event æow charts to secify these rotocols combined with three LMTs: HLRèVLR, HLRèVLR with artial relication ë19ë, and HLRèVLR with caching ë7ë. Section 4 gives an analytical comarison of average call setu erformance for the nine CSP-LMT combinations. Simulation results are shown in Section 5. We conclude in Section 6. 3

4 2 PCS Environment and Terminology In a wireless PCS system, mobile users are located in wireless cells groued into registration zones, and they communicate with nearby base stations through the wireless medium. Base stations are connected to a wired network via Mobile Switching Centers èmscsè to exchange data among diæerent cells. When a call is made, the callee's location information indicating the user's current zone is retrieved. The callee's routing information also is needed, in order for the system to set u the circuit connection. Routing information includes the MSC ort the callee is connected to èthe MSC addressè and his temorary user ID for contacting the MSC èthe Tem addressè. Finally, status information, such as if the callee is busy or if the callee's handset is oæ, also may be used. Location Management Techniques èlmtsè maintain user information in databases in order to erform eæcient call setu. The current LMT standards are HLRèVLR schemes, as introduces in Section 1. In these schemes, each user's routing information is stored in VLR database at his current zone. In addition, an identiæer for the user's VLR èthe VLR addressè, which also indicates the user's current location, is stored in the HLR database at the user's home zone. Each user's HLR address is encoded in his hone number. Therefore, the system can always locate a user's HLR from the hone number, then locate his VLR, and ænally retrieve the routing information. Entries in the HLR and VLR can be combined for users currently located in their home zone. HLRèVLR with artial relication ë1, 19ë èhereafter called the Relication LMTè is one extension of the HLRèVLR standards. It relicates some users' VLR addresses in additional registration zones, so that callers from those zones can obtain the user's VLR address with one local looku, thereby reducing the overall database lookus and network messages. The relicas are ket uto-date by the system. HLRèVLR with caching ë7ë èhereafter called the Caching LMTè is another extension of HLRèVLR schemes. If it is discovered that a zone has many calls directed to a given user, the user's VLR address is cached in the local database. This also increases local looku ratio and saves network messages before the cached entry becomes out-of-date. Figure 1 shows the infrastructure of a PCS system that emloys HLRèVLR-based techniques. The tables in Figure 1 indicate the user information databases, which combine the HLR, VLR, and cache or relication deository of a zone into one database. In the ægure, we can see that user Y is visiting zone 3, and therefore his routing and status information is stored in the database there èthe ærst row in HLRVLR-3è. Zone 2 is Y 's home zone, and stores Y 's VLR address in its local database èthe ærst row in HLRVLR-2è. In addition, a coy of Y 's VLR address is stored in zone 1's cache èthe second row in HLRVLR-1è. User X is currently located in his home zone, zone 1. His HLR entry and VLR entry are combined, and stored in zone 1 èthe ærst row in HLRVLR-1è. Call Setu Protocols ècspsè coordinate information exchange during the call setu rocess. The call setu rocess has two stages: the location looku stage, in which the system ænds the callee's current location èossibly with routing and statusè information, and the connection setu stage that sets u the hysical circuit connections between caller and callee. To otimize the call 4

5 Registration Zone 1 (X s current zone) user curr. curr. tem. Busy ID VLR MSC addr. Status X N Y X MSC 1.1 MSC 1.2 HLR/VLR-1 user ID curr. curr. VLR MSC Y tem. Busy addr. Status - HLR/VLR-2 Wireline Network MSC 2.1 user ID curr. curr. tem. VLR MSC addr. Busy Status Registration Zone 2 (Y s home zone) Y N Y HLR/VLR-3 MSC 3.1 MSC Cell Base Station Registration Zone Mobile Switching Center Registration Zone 3 (Y s current zone) HLR/VLR Home & Visiting Location Register Figure 1: PCS Network Architecture setu rocess, it is imortant to consider the two stages together, in order to utilize the location information most eæectively. In current CSP standards, including that in IS-41, location looku queries are sent from the caller's MSC to his VLR, then to the callee's HLR and then VLR, until the callee's routing information is retrieved. The connection is then set u from the caller to the callee accordingly. In this aer, we develo new CSPs and exlore how they interact with various HLRèVLRbased LMTs in the entire call setu rocess. 3 Call Setu Protocols In this section, we describe two new CSPs: the Lightweight Location Looku Protocol èlillpè and the Reverse Connection Setu èrecsè rotocol. We also study the IS-41 standard CSP for comarison. We combine each CSP with the three LMTs introduced in Section 2: HLRèVLR, Relication, and Caching. We secify each of the nine CSP-LMT combination schemes in a æow chart. The database and network erformance of each combination is studied in later sections of the aer. We secify our rotocols based on the following general scenario, in which PCS user X is calling user Y in the system shown in Figure 1. We assume: 5

6 æ X is currently located in zone 1. æ Y has home zone 2 and is currently located in zone 3. æ HLR and VLR are combined as database HLRèVLR-i in zone i, i =1::3. In the rest of the aer, we refer the database at the user's home zone as HLRi, and the user's current zone's database as VLRi. æ The distance between zone 1 and zone 2 is l network hos. èl = 0 means X is in Y 's home zone.è æ The distance between zone 1 and zone 3 is m network hos. èm = 0 means X and Y are in the same zone.è æ The distance between zone 2 and zone 3 is n network hos. èn = 0 means Y is at home.è 3.1 Call Setu Procedures Several stes are taken during a call setu, and we deæne each ste as a searate rocedure. For each rocedure, the number of database lookus, wired network messages, and network hos are counted to measure call setu erformance. When a database is queried for user location information, it counts as one database looku. Every remote database looku, connection setu request, or acknowledgment contributes one network message. An inter-zone message may take multile network hos to reach its destination. We do not include wireless signaling èe.g., agingè or local messages èe.g., messages between the local VLR and MSCè in our analysis. Figure 2 lists the call setu rocedures. Event counters formatted as ëdatabase lookus, network messages, network hosë are resented in the right column, to cature the cost of each ste. Total network and database costs are calculated for each rocedure. Diæerent sets of rocedures are used in diæerent call setu rotocols: we secify the IS-41's CSP in Section 3.2, LiLLP in Section 3.3, and ReCS in Section IS-41 In the IS-41 standard, when X calls Y, X initiates a local looku at his own VLR èvlr1è for Y 's information. If Y 's information is not found, VLR1 sends query to Y 's home HLR èhlr2è where Y 's VLR address is always stored. HLR2 then retrieves Y's routing and status information from Y 's current VLR èvlr3è and sends it back to VLR1. If Y is not busy, the connection request is sent from X's MSC to Y 's MSC, and the network ath is reserved. Y is then aged in his cell. The call setu is comleted once X receives resonse from Y; otherwise the call setu fails. Figure 3 illustrates the call setu rocess in IS-41. 6

7 Location Looku Procedures: Procedure P1: X does local looku in VLR1 èaè X sends location looku message to local VLR1. èbè VLR1 looks u Y 's location information. ècè VLR1 relies to X. Procedure P2: VLR1 queries VLR3 èaè VLR1 sends location looku message to VLR3. èbè VLR3 looks u Y 's MSC and Tem address. ècè VLR3 relies to VLR1. Procedure P3: VLR1 queries HLR2 èaè VLR1 sends location looku message to HLR2. èbè HLR2 looks u Y 's VLR address. ècè HLR2 relies to VLR1. Procedure P4: HLR2 queries VLR3 èaè HLR2 sends location looku message to VLR3. èbè VLR3 looks u Y 's MSC and Tem address. ècè VLR3 relies to HLR2. total! ë1; 0; 0ë! ë0; 0; 0ë! ë0; 0; 0ë! ë0; 0; 0ë total! ë1; 2; 2lë! ë0; 1; lë! ë1; 0; 0ë! ë0; 1; lë total! ë1; 2; 2më! ë0; 1; më! ë1; 0; 0ë! ë0; 1; më total! ë1; 2; 2në! ë0; 1; në! ë1; 0; 0ë! ë0; 1; në Connection Setu Procedures: Procedure P5 èp8è: X connects to Y èx, Y in same zoneè. èaè X sends connection setu request to Y 's MSC. èbè Y 's MSC ages Y. ècè Y 's MSC relies to X if Y is reachable. Procedure P6: X connects to VLR3 èaè X sends connection setu request to VLR3. èbè VLR3 looks u Y 's MSC and Tem address. ècè VLR3 forwards connection setu message to Y 's MSC. èdè Y 's MSC ages Y. èeè Y 's MSC relies to X if Y is reachable. Procedure P7 èp9è: Y connects to X èx, Y in same zoneè. èaè Y sends connection setu request to X's MSC. èbè X's MSC relies to Y. total! ë0; 2; 2lëèë0; 0; 0ëè! ë0; 1;lëèë0; 0; 0ëè! ë0; 0; 0ëèë0; 0; 0ëè! ë0; 1;lëèë0; 0; 0ëè total! ë1; 2; 2lë! ë0; 1; lë! ë1; 0; 0ë! ë0; 0; 0ë! ë0; 0; 0ë! ë0; 1;lë total! ë0; 2; 2lëèë0; 0; 0ëè! ë0; 1; lëèë0; 0; 0ëè! ë0; 1;lëèë0; 0; 0ëè Figure 2:Call Setu Procedures 7

8 6 7 Y X Zone 3: Y s current zone 4 5 Zone 1: X s current zone Zone 2: Y s home zone Figure 3: IS-41 Call Setu Process We are interested in how the CSPs interact with diæerent LMTs during call setu. Thus, we rovide æow charts in Figures 9, 10, and 11 èin the Aendixè that secify call setu rocesses using IS-41's CSP combined with HLRèVLR, Relication, and Caching, resectively. The æowcharts resent the entire call setu rocess, from the ëstart" of the location looku stage to the ëend" of the connection setu stage. Each oval in the charts indicates the invocation of a rocedure from Figure 1. Both the rocedure name and event counters for the rocedure are noted to indicate the activities and cost of the ste. The diamonds indicate conditional oints that lead to diæerent execution branches under diæerent situations, with ëëyë" indicating the ositive èyesè branch and ëënë" indicating the negative ènoè branch. The terms on the edges, such as ëq" and ë1, q", indicate the robability assumtions for our analysis and will be discussed further in Section 4. HLRèVLR-based LMTs store only the user's current VLR address in his HLR, so that the HLR need not be udated when the user moves between diæerent cells within one registration zone. However, with such a scheme, if the call setu rotocol insists on obtaining full routing information before setting u the connection, then it must query both the callee's HLR and VLR, which may be in diæerent zones, during the location looku stage èas shown in Figure 3è. This may lead to long setu delay and heavy network traæc. In our roosed rotocols, we show that it is ossible to reduce the location looku stage, without signiæcantly increasing the connection setu stage, thereby decreasing overall setu delay and network load. 3.3 LiLLP In our Lightweight Location Looku Protocol èlillpè, the location looku stage in the call setu from X to Y retrieves only Y 's VLR address, instead of his entire routing information, thereby reducing the tasks of the location looku stage. After obtaining Y's VLR address, the system sends a connection setu request to Y's VLR and reserves network aths. Uon receiving the connection setu request, Y 's VLR forwards the request to Y 's MSC, according to the routing information stored in the VLR. Y 's MSC, which is co-located with the VLR in most current systems, ages Y in his cell. The connection setu is comleted once Y resonds. Figure 4 8

9 shows the LiLLP call setu rocess. As in IS-41, LiLLP can be combined with diæerent LMTs. 5 Y X Zone 3: Y s current zone 3 Zone 1: X s current zone Zone 2: Y s home zone Figure 4: LiLLP Call Setu Process Figures 12, 13, and 14 èin the Aendixè secify the entire call setu rocesses of LiLLP integrated with the three LMTs. Eæectively, LiLLP omits the remote database lookus for the detailed routing information during the location looku stage èmessages 3 and 4 in Figure 3è and instead obtains the information ëalong the way" during connection setu. As we will see, this aroach can reduce overall network signaling and setu delay. The advantage of our lightweight scheme is articularly clear when integrated with the Relication LMT. We can see from Figure 4 that if X's VLR has Y 's current VLR address relicated in its database, then X can obtain the address with one local looku and directly set u the connection with Y 's VLR. Thus, only two network messages are needed to comlete the entire setu rocess. Since LiLLP reserves network aths before retrieving Y's status information, LiLLP may waste network resources by reserving connections to unavailable users. The robability that a user is busy is likely to be small, but the robability that a user's handset is oæ may be signiæcant in today's systems. In fact, the same roblem occurs in IS-41, and is addressed by the Reverse Connection Setu Protocol roosed in the next section. 3.4 ReCS The technique of Reverse Virtual Call Setu èrvcè was introduced in ë6ë. The authors roosed that during call setu, the caller's request should be sent to the callee's HLR, which invokes global aging of the callee from there. If the callee answers the age, connection setu is initiated. Otherwise, a message indicating the failure is sent back to the caller. This scheme reduces the cost of failed call attemts and call setu delay. However, it requires another overlaid global aging network and introduces extra wired or wireless signaling. We roose an alternative to RVC, in which the system ages the callee in his current visiting zone during the location looku stage. We call this new rotocol the Reverse Connection Setu èrecsè rotocol. In the ReCS rotocol, when a call is made from X to Y, the system ærst ænds Y 's current VLR address èvlr3è in X's local database or Y 's HLR, and sends the location looku request 9

10 to VLR3. VLR3 then looks at its database for Y 's routing information, and directly ages Y instead of sending the routing information back tox as in IS-41. The circuit connection setu is initiated from Y to X automatically èwhich is the reverse of the call request directionè after Y answers. Figure 5 shows the call setu rocess using ReCS. Figures 15, 16, and 17 èin the Y X Zone 3: Y s current zone 3 2 Zone 1: X s current zone Zone 2: Y s home zone Figure 5: ReCS Call Setu Process Aendixè secify ReCS combined with the three LMTs. By doing reverse connection setu, messages that notify the caller of the callee's routing information èmessages 4 and 5 in Figure 3è are eliminated. This leads to lower setu delay and signaling than the rotocol emloyed in IS-41. Also, since the ReCS rotocol ages the callee before setting u the connection, no network ath is reserved if the callee 's handset is oæ 1.Thus, the cost of failed call attemts is signiæcantly reduced. 4 Analytical Comarison In this section, we erform analytical comarisons between the three CSPs èour roosed LiLLP and ReCS, and the standard IS-41è, when combined with the three diæerent LMTs. We only consider average call setu èi.e. location looku + connection setuè erformance here. Emirical comarisons of overall system erformance of database and network activities for the CSP-LMT schemes, including location lookus and udates, are shown by simulation results in Section 5. Figure 6 summarizes the network message exchanges between the caller and callee HLR and VLRs during the call setu rocess for the three CSPs. We notice immediately that at least two messages are saved by using LiLLP or ReCS. Assuming each message takes the same time to reach its destination, LiLLP and ReCS can achieve much shorter setu delay. However, the scenario becomes more comlicated with diæerent traæc conditions, and when the CSPs are combined with diæerent LMTs. Thus, we consider the robabilities of diæerent situations as following: æ The robability that Y 's handset is oæ be o. 1 We are assuming here and in the rest of the aer that the user is unreachable only when his handset is oæ. However, there may be other reasons, such as the user is out of range, that can cause the unreachability of a user. 10

11 Caller Callee Callee Caller Callee Callee Caller Callee Callee VLR HLR VLR VLR HLR VLR VLR HLR VLR Time IS-41 LiLLP ReCS Location Looku Messages; Connection Setu Messages; Figure 6: Call Setu Network Messages æ The robability that Y is busy be. æ The robability that Y is in the same zone as X be q. æ The robability that Y is in his home zone be s. æ The robability that X is in Y 's home zone be t. In addition, for the Relication and Caching LMTs, we assume: æ The robability that X has a relica or cache of Y 's VLR address is r. æ The robability of a cache hit is h. These robabilities are indicated in the æowcharts of Figures 10í18. We calculate for each CSP-LMT combined scheme the average number of network messages and database lookus er call setu based on the æow charts, and resent the results in Tables 1 and 2. The numbers are reresented as formulas based on the robabilities seciæed above. They are indicative of the call setu delay, and artly decide the network and database loads associated with call setu. We use the following shorthands in the formulas: çh =1, h, ço =1, o, ç =1,, çq =1, q, çr =1, r, çs =1, s, ç t =1, t, rh =1, rh. We see from Table 2 that LiLLP and ReCS incur the same number of database lookus as IS-41. We comare the network erformance of LiLLP and ReCS with the IS-41 standard by resenting 11

12 IS-41 LiLLP ReCS HLRèVLR 2çqè1 + çsç t +çè 2çqè1 + çs t ç +çstè ç çqè1 + çs t ç +2çoçè Relication 2çqè1 + çrçsç t +çè 2çqè1 + çrçs t ç +ççrstè ç çqè1 + çrçs ç t +2çoçè Caching 2çqè1 + rhçsç t + ç hrt ç +çè 2çqè1 + rhçs t ç + hr ç t ç +çrhst ç + hçrtè ç çqè1 + rhçs t ç + ç hrt ç +2çoçè Table 1: Average Network Messages er Call Setu HLRèVLR Relication Caching IS-41, LiLLP, or ReCS 1+çqè1 + çsç tè 1+çqè1 + çrçsç tè 1+çqè1 + rhçsç t + ç hrtè ç Table 2: Average Database Reads er Call Setu the diæerences of the numbers of call setu network messages in Table 3. We can see that each formula in the table has a ositive value èbased on the fact that all the robabilities are ç 1è, which means that LiLLP and ReCS incur a strictly smaller average number ofnetwork messages er call setu than IS-41, regardless which LMT is used. IS-41, LiLLP IS-41, ReCS HLRèVLR 2ççqè1, sç tè çqè1 + çs ç t +2oçè Relication 2ççqè1, çrsç tè çqè1 + çrçs ç t +2oçè Caching 2ççqèt + rhçsç tè çqè1 + rhçs ç t + r ç h ç t +2oçè Table 3: Performance Comarison Between CSPs The relative erformance of LiLLP and ReCS relies on seciæc robability assumtions. To further investigate the analytical formulas, let us make the following assumtions about the system conditions: = 1 8, q = 1 8, s = 1 2, t = 3 8, r = 1 2, h = 7 8. We learned from simulations that the caching èor relicationè ratio r = 1 can be achieved with 2 fewer than æve relicas for each user. For the robability that a user's handset is oæ, we consider two ossible scenarios. One is the ideal o = 0 in which handsets are always on. The other is o = 1 2 roosed in ë18ë, which is more realistic in today's systems due to ower limitations. Tables 4 and 5 show the average numbers of network messages and database reads er call setu under the above default assumtions. We have seen in Table 3 that the larger the robability o is, the more network messages ReCS saves. Table 4 further shows that when o = 1 2, ReCS schemes achieve the best network 12

13 IS-41 LiLLP ReCS èo =0è ReCS èo = 1è 2 HLRèVLR 3:82 2:78 2:68 1:91 Relication 3:55 2:26 2:54 1:78 Caching 3:66 2:81 2:44 1:83 Table 4: Average Network Messages Per Call Setu èunder default assumtionsè IS-41, LiLLP or ReCS HLRèVLR 2:15 Relication 2:01 Caching 2:06 Table 5: Average Database Reads er Call Setu èunder default assumtionsè erformance, reducing u to 1è2 of the network messages in IS-41. However, when o = 0, the scheme combining LiLLP with the Relication LMT achieves better erformance in the average number of network messages and database lookus. Since the Caching LMT always connects to the cached VLR address before connection setu to ensure that the cached address is correct, it incurs one extra remote VLR looku for each call setu in LiLLP and loses its advantage. Therefore, using caching in LiLLP is not worthwhile. The numbers in Tables 4 and 5 will certainly change as the robability assumtions vary. For examle, the higher the relication ratio, the better the Relication scheme erforms. However, udate cost increases when more relicas are added. Neither LiLLP nor ReCS itself incurs extra udate cost, but the Relication LMT may introduce extra udate cost in order to kee the relicated VLR addresses u-to-date. The overall database and network erformance is studied via simulations in the next section. 5 Simulations We have studied the erformance of the call setu rotocols, including our roosed LiLLP and ReCS rotocols, by simulations. As in the revious sections, we combine the call setu rotocols with diæerent location management techniques, and comare their erformance with resect to database accesses and network activity. Our simulations take into account the udate cost when users move across zones, which was not considered when analyzing the average call setu erformance in Section 4. In this section, we ærst introduce our Pleiades simulator ë8, 9ë used to erform our simulations. The toology models and network traæc models that we used to simulate the PCS environment are also brieæy resented. Finally, simulation results comaring the schemes are shown. 13

14 5.1 Pleiades Simulator We erform simulations using our PCS system simulator, Pleiades ë17ë. Pleiades is a highly conægurable discrete event simulator develoed at Stanford. The simulator models PCS location management and call setu rocesses. An inut scrit æle is used to describe the geograhical and network toology models as well as diæerent user call and mobility models. The statistics of the network and database activities are written to an outut æle for analysis. Our simulation models are described in ë9, 11ë and summarized here. Our system toology is modeled after the ten largest cities of the United States. Each city is divided into a number of registration zones and wireless cells according to the city size. Each registration zone is aroximately 400 square miles with about 20,000 subscribers. We used a hierarchical network toology, in which cells in each city are ærst connected with each other, then connected to other cities through higher-level network nodes. We have catured realistic traæc conditions by using time-varying traæc models. The call model includes various call traæc tyes, call volume changes throughout the day, and also incororates callee distribution. We have instantiated our call models with arameters that were derived from call traæc data obtained from our local university telehone exchange ë20ë. The Metroolitan Mobility Model èmetmodè and the National Mobility Model ènatmodè ë9ë are used for modeling movements within and between the cities. They are derived from transortation surveys ë5ë, vehicle traæc data ë16ë and commercial airline data ë3ë. 5.2 Results In our simulations, we consider nine CSP-LMT combinations as discussed in Sections 3 and 4. For Relication and Caching, user i's VLR address is eligible to be relicated or cached in zone j only if the local call to mobility ratio èlcmr ij è is higher than the otimal thresholds ë7, 19ë. A maximum of æve VLR address relicas for each user are allowed in the Relication LMT. We also assume the ideal situation where users are always reachable by the system èo =0èinour simulations. We erformed multi-day simulations and show results for a reresentative 24-hour eriod after start-u transients. Figures 7 and 8 deict the total network traæc and total database accesses er second versus simulation time. The eaks in the ægures indicates the eak calling and movement activities during the simulated day. Our grahs cature all database and network events, including location lookus and udates as well as connection setus, for all subscribers' calling and mobility activities. From Figure 7, we see that LiLLP integrated with Relication incurs the least network signaling, and is about 2è3 of the signaling in the IS-41 schemes. ReCS also achieves good erformance. In Figure 8, we can see that LiLLP and ReCS don't incur extra database accesses, and the database erformance achieved by using the three diæerent LMTs are also similar. These results are consistent with our analysis in Section 4. 14

15 Network Message Hos / Second HLR/VLR in LiLLP Caching in LiLLP Relication in ReCS HLR/VLR in ReCS Caching in ReCS Relication in LiLLP Relication in IS-41 HLR/VLR in IS-41 Caching in IS Time (Hours) Figure 7: Total Network Signaling Hos 3000 Database Accesses (Read & Write) / Second HLR/VLR in IS-41 HLR/VLR in LiLLP HLR/VLR in ReCS Caching in IS-41 Caching in LiLLP Caching in ReCS Relication in IS-41 Relication in LiLLP Relication in ReCS Time (Hours) Figure 8: Total Database Accesses 15

16 6 Conclusions We have roosed two new rotocols for PCS call setu: the Lightweight Location Looku Protocol èlillpè and Reverse Connection Setu èrecsè rotocol. We comared our rotocols with the existing call setu rotocol in the IS-41 standard. We carefully illustrated the interactions between the call setu rotocols and diæerent location management techniques using æow charts. Through analysis and simulations, we have shown that the newly roosed rotocols can reduce the setu delay and decrease network signaling in the call setu rocess by u to 1è2, while no extra database accesses or udate costs are required. We also discussed the best CSP-LMT schemes under what we believe to be realistic system conditions. Acknowledgments We are grateful to Bora Akyol, Jan Jannink, and Narayanan Shivakumar for numerous fruitful discussions. References ë1ë B. R. Badrinath and T. Imielinski. Relication and mobility. In Second Worksho on the Management of Relicated Data, ages 9í12. IEEE, November ë2ë D. C. Cox. Wireless ersonal communications: What is it? IEEE Personal Communications, ages 20í35, Aril ë3ë Origin and destination survey, t-100 domestic market data. Deartment of Transortation. Dataset for eriods 10è91-12è91 and 10è93-12è93. ë4ë J.S.M. Ho and I.F. Akyildiz. Local anchor scheme for reducing location tracking costs in PCN. In 1st ACM International Conference on Mobile Comuting and Networking èmobi- COM'95è, ages 170í180, Berkeley, California, ë5ë P. S. Hu and J. Young NPTS Databook: Nationwide Personal Transortation Survey. Federal Highway Administration, November ë6ë C.-L. I, G. P. Pollini, and R. D. Gitlin. PCS mobility management using the reverse virtual call setu algorithm. IEEEèACM Transactions on Networking, 5è1è:13í23, February ë7ë R. Jain, Y.-B. Lin, C. Lo, and S. Mohan. A caching strategy to reduce network imacts of PCS. IEEE Journal on Selected Areas in Communications, 12è8è, October ë8ë J. Jannink, D. Lam, N. Shivakumar, J. Widom, and D. C. Cox. Eæcient and æexible location management techniques for wireless communication systems. In 2nd ACM International 16

17 Conference on Mobile Comuting and Networking èmobicom'96è, ages 38í49, Rye, New York, November ë9ë D. Lam, D. C. Cox, and J. Widom. Teletraæc modeling for Personal Communications Services. IEEE Communications Magazine Secial Issue on Teletraæc Modeling, Engineering and Management in Wireless and Broadband Networks, 35è2è:79í87, February ë10ë D. Lam, Y. Cui, D. Cox, and J. Widom. A location management technique to suort lifelong numbering in Personal Communication Services. IEEE Global Telecommunications Conference, November To aear. ë11ë D. Lam, J. Jannink, D. C. Cox, and J. Widom. Modeling location management for Personal Communication Services. In Proceedings of 1996 IEEE International Conference on Universal Personal Communications èicupc96è, ages 596í601, Setember ë12ë W. C. Y. Lee. Mobile Cellular Telecommunications Systems. McGraw-Hill, ë13ë K. K. Leung and Y. Levy. Data relication schemes for global network. In 15th Internation Teletraæc Congress èitc15è, ages 211í222, June ë14ë K. K. Leung and Y. Levy. Global mobility management by relicated databases in Personal Communication Networks. IEEE Journal On Selected Areas In Communications, ë15ë M. Mouly and M.-B. Pautet. The GSM System for Mobile Communications. Palaiseau, France, ë16ë 1990 commute summary. Metroolitan Transortation Commission, Lotus 123 format sreadsheet, August S.F. Bay area transortation measurements. ë17ë Peiades homeage: htt:èèwww-db.stanford.eduèleiadesè. Stanford University. ë18ë G. P. Pollini, S. Meier-Hellstern, and D. J. Goodman. Signaling traæc volume generated by mobile and ersonal communications. IEEE Communication Magazine, ages 60í65, June ë19ë N. Shivakumar and J. Widom. User roæle relication for faster looku in mobile environments. In 1st ACM International Conference on Mobile Comuting and Networking èmo- BICOM'95è, ages 161í169, Berkeley, California, ë20ë Telehone call traæc data set, 3è95í9è95. S. Phillis, ersonal communication, October Encryted ID numbers. ë21ë J. Z. Wang. A fully distributed location registration strategy for universal ersonal communication systems. IEEE Journal on Selected Areas in Communications, 11è6è:850í860, August

18 ë22ë J. I. Yu. ISí41 for mobility management. In First International Conference on Universal Personal Communications, èicupc92è. IEEE,

19 A Flow charts Start P1: X local looku VLR1 [1,0,0] q Is Y in X s Zone? 1 - q Is X at Y s Home? 1-t t P3: VLR1 queries HLR2 [1,2,2m] s Is Y at Home? 1 - s P4: HLR2 queries VLR3 [1,2,2n] P8: X connects to Y [0,0,0] P5: X connects to Y [0,2,2l] End Figure 9: HLRèVLR in IS-41 19

20 Start P1: X local looku VLR1 [1,0,0] q Is Y in X s Zone? 1 - q 1 - t Is X at Y s Home? t r Y s relica in VLR1? 1 - r P2: VLR1 queries VLR3 [1,2,2l] P3: VLR1 queries HLR2 [1,2,2m] s Is Y at Home? 1 - s P4: HLR2 queries VLR3 [1,2,2n] P8: X connects to Y [0,0,0] P5: X connects to Y [0,2,2l] End Figure 10: HLRèVLR with Relication in IS-41 20

21 Start P1: X local looku VLR1 [1,0,0] q Is Y in X s Zone? 1 - q 1 - t Is X at Y s Home? t r Y s cache in VLR1? 1 - r P2: VLR1 queries VLR3 [1,2,2l] Cache Hit? h 1 - h P3: VLR1 queries HLR2 [1,2,2m] s Is Y at Home? 1 - s P4: HLR2 queries VLR3 [1,2,2n] P8: X connects to Y [0,0,0] P5: X connects to Y [0,2,2l] End Figure 11: HLRèVLR with Caching in IS-41 21

22 Start P1: X local looku VLR1 [1,0,0] q Is Y in X s Zone? 1 - q 1 - t Is X at Y s Home? t P3: VLR1 queries HLR2 [1,2,2m] Is Y at Home? 1 - s 1 - s 1 - P6: X connects VLR3 [1,2,2l] P8: X connects to Y [0,0,0] P5: X connects to Y [0,2,2l] End Figure 12: HLRèVLR in LiLLP 22

23 Start P1: X local looku VLR1 [1,0,0] q Is Y in X s Zone? 1 - q 1 - r Is X at Y s Home? 1 - t Y s relica in VLR1? t r P3: VLR1 queries HLR2 [1,2,2m] Is Y at Home? 1 - s s P6: X connects VLR3 [1,2,2l] P8: X connects to Y [0,0,0] P5: X connects to Y [0,2,2l] End Figure 13: HLRèVLR with Relication in LiLLP 23

24 Start P1: X local looku VLR1 [1,0,0] q Is Y in X s Zone? 1 - q r Is X at Y s Home? 1-t Y s cache in VLR1? t 1 - r P2: VLR1 queries VLR3 [1,2,2n] Cache Hit? 1 - h h P3: VLR1 queries HLR2 [1,2,2m] 1 - s s Is Y at Home? P6: X connects VLR3 [1,2,2l] P8: X connects to Y [0,0,0] P5: X connects to Y [0,2,2l] End Figure 14: HLRèVLR with Caching in LiLLP 24

25 Start P1: X local looku VLR1 [1,0,0] q Is Y in X s Zone? 1 - q Is X at Y s Home? 1-t t P3-ste(a,b): VLR1 queries HLR2 [1,1,m] s Is Y at Home? 1 - s P4-ste(a,b): HLR2 queries VLR3 [1,1,n] 1 - P5-ste(b): VLR3 ages Y [0,0,0] o Is Y Off? q 1 - o Is Y in X s Zone? 1 - q P9: Y connects to X [0,0,0] P7: Y connects to X [0,2,2l] End Figure 15: HLRèVLR in ReCS 25

26 Start P1: X local looku VLR1 [1,0,0] q Is Y in X s Zone? 1 - q 1 - t Is X at Y s Home? t r Y s relica in VLR1? 1 - r P2-ste(a,b): VLR1 queries VLR3 [1,1,l] P3-ste(a,b): VLR1 queries HLR2 [1,1,m] s Is Y at Home? 1 - s P4-ste(a,b): HLR2 queries VLR3 [1,1,n] 1 - P5-ste(b): VLR3 ages Y [0,0,0] o Is Y Off? 1 - o q Is Y in X s Zone? 1 - q P9: Y connects to X [0,0,0] P7: Y connects to X [0,2,2l] End Figure 16: HLRèVLR with Relication in ReCS 26

27 Start P1: X local looku VLR1 [1,0,0] q Is Y in X s Zone? 1 - q 1 - t t Is X at Y s Home? r Y s cache in VLR1? 1 - r P2-ste(a,b): VLR1 queries VLR3 [1,1,l] Cache Hit? h 1 - h P3-ste(a,b): VLR1 queries HLR2 [1,1,m] s Is Y at Home? 1 - s P4-ste(a,b): HLR2 queries VLR3 [1,1,n] 1 - P5-ste(b): VLR3 ages Y [0,0,0] o Is Y Off? 1 - o q Is Y in X s Zone? 1 - q P9: Y connects to X [0,0,0] P7: Y connects to X [0,2,2l] End Figure 17: HLRèVLR with Caching in ReCS 27