Reducing Capacity Requirement for Mobility Database in Wireless ATM

全文

(1)Cover Page The paper is associated with Workshop on Computer Networks. Title: Reducing Capacity Requirement for Mobility Database in Wireless ATM Abstract: In wireless ATM, Visitor Location Register (VLR) is the database that supports mobility management. In case the number of roaming users exceeds that the VLR supports, the arriving users cannot receive any service. This phenomenon is called VLR overflow. To solve such a problem, the Random Replacement (RR) policy randomly selects a victim record in VLR to be replaced with the record of the arriving user. The quality of services for the victim user will certainly drop. Therefore, the proportion of affected users is not allowed to exceed a tolerable threshold. Apparently, VLR size is the key factor of the threshold. The cost for maintaining a VLR increases significantly as its size grows. So, how to utilize the capacity efficiently is an important issue in VLR planning. We propose a Second-Chance Replacement (SCR) policy to reduce the requirements for VLR capacity. Compared with the RR policy, discrete-event simulation results show that the SCR policy can save 2.5\% to 20\% VLR size under various QoS thresholds. Authors: Kuen-Liang Sue and Chi-Chun Lo The authors are with Institute of Information Management, National Chiao Tung University, Hsinchu, Taiwan, R.O.C. Addr: 1001 TA HSUEH ROAD, HSINCHU, TAIWAN 30050,ROC Tel: 03-5712121-31909; Mobile: 0926-666-286; Fax: 03-5723792 E-mail: klsue@csie.nctu.edu.tw; cclo@cc.nctu.edu.tw. Contact author: Kuen-Liang Sue Keywords: Visitor location register, Database overflow, Mobility management, QoS, Discrete-event simulation.

(2) Reducing Capacity Requirement for Mobility Database in Wireless ATM Kuen-Liang Sue∗ and Chi-Chun Lo. Abstract In wireless ATM, Visitor Location Register (VLR) is the database that supports mobility management. In case the number of roaming users exceeds that the VLR supports, the arriving users cannot receive any service. This phenomenon is called VLR overflow. To solve such a problem, the Random Replacement (RR) policy randomly selects a victim record in VLR to be replaced with the record of the arriving user. The quality of services for the victim user will certainly drop. Therefore, the proportion of affected users is not allowed to exceed a tolerable threshold. Apparently, VLR size is the key factor of the threshold. The cost for maintaining a VLR increases significantly as its size grows. So, how to utilize the capacity efficiently is an important issue in VLR planning. We propose a Second-Chance Replacement (SCR) policy to reduce the requirements for VLR capacity. Compared with the RR policy, discrete-event simulation results show that the SCR policy can save 2.5% to 20% VLR size under various QoS thresholds. Keywords: Visitor location register, Database overflow, Mobility management, Discreteevent simulation. 1. Introduction. Cellular communication systems make voice and limited data services more and more popular. Broadband multimedia services like video conference, video on demand, and network ∗. Contacting Author: Kuen-Liang Sue is with the Institute of Information Management, National Chiao Tung University, Hsinchu, Taiwan, R.O.C.; Tel: +886-3-5712121-31909; Fax: +886-3-5723792; E-mail: klsue@csie.nctu.edu.tw.. 1.

(3) telephony come true as the broadband network getting familiar. Now, there is a growing interest in the research supporting wireless access to the fixed Asynchronous Transfer Mode (ATM) networks [1, 2]. One of the important issues in wireless ATM (WATM) is mobility management [3, 4, 5]. A user of WATM may roam everywhere from time to time. Therefore, the terminal used by a roaming user is not fixed to the traditional ATM networks. Mobility management for WATM enables a roaming user to receive services (send or receive ATM cells), no matter where he/she goes. A two-tier database scheme employing the IS-41/GSM MAP-based techniques is proposed to manage this issue [3, 5]. The region covered by WATM networks is divided into some Location Areas (LA). For simplification, we suppose that each LA has one location database. Every user belongs to just one home LA where he/she is registered permanently. The Home Location Register (HLR) is the mobility database of the home LA. Except HLR, the mobility databases in other LAs are called Visitor Location Registers (VLR). Each user has one record in HLR to store his/her profile, current location, and validation time, etc. To store the information for handling call connections of a visiting user , a temporary record is created in the related VLR while a roaming user arrives in some LA. When the user leaves the LA, the associated VLR record will be deleted. In WATM, the roaming users from different LAs may randomly visit some LA or depart. At that time, the number of the records in the VLR changes dynamically. The VLR may overflow if too many roaming users visit the LA in a short period of time (e.g. disaster happened in neighborhood area). In case the VLR is full as a visiting user arrives, the system will fail to create a record for the user who thus cannot receive any service. This phenomenon is called VLR overflow. An overflow control scheme with Random Replacement (RR) policy from cellular systems is adapted to overcome such problem in WATM. The RR policy randomly selects a victim record to be replaced when VLR overflow occurs. Obviously, VLR capacity is the main factor that affect the probability of VLR overflow. The larger VLR capacity, the lower overflow probability and replacement frequency. The RR policy is the simplest but not smart. The replacement frequency may increase if the record of an active user is selected. In other words, the essential VLR size to maintain a tolerable replacement rate will be over-estimated through the RR policy. In this paper,. 2.

(4) ATM backbone. BSC. HLR. BS. MS. BWSC. SW TS SW. BS. BWSC BSC. SW VLR. MS BS. signaling transport user data transport. UNI. Figure 1: The system architecture in WATM. a more efficient method called Second Chance Replacement (SCR) policy is presented to reduce the requirement for VLR capacity. Based on simulation results, the SCR policy can save VLR capacity up to 28% than that needed in RR policy. Section II illustrates the WATM architecture and mobility management strategy based on two-tier databases in WATM. The SCR policy is introduced in section III. Section IV provides the discrete-event simulation model for the SCR policy. According to various QoS requirements and system parameters, the numerical analysis is investigated in section V.. 2. Mobility Management in WATM. 2.1. System Architecture. Before introducing the mobility management in WATM, a brief description about WATM is given in this subsection. The system architecture for WATM is illustrated in Fig. 1. The system has three major network components [2, 4]. • The wireless access network • The ATM backbone network • Mobility databases The wireless access network comprises Mobile Stations (MS), Base Stations (BS), and Base Station Controllers (BSC). An MS is a terminal (e.g. PDA, notebook, and mobile 3.

(5) phone) whose position may change from time to time. A BS is responsible for the transmission and reception of radio signals to/from MSs. A BSC is the interface between some BSs and the ATM network. That is, ATM cells from backbone network terminate at the BSC, which then converts the cells into the data format of the existing air interface standards (e.g. GSM or PACS) and forwards them to a certain MS through the corresponding BS, or vice versa. The important functions of a BSC also include managing radio functions at multiple BSs and interacting with the mobility databases (i.e. HLR and VLR) through Broadband Wireless Switching Center (BWSC) for mobility management. The inerface between the BSC and BWSC is an ATM User-Network Interface (UNI). The ATM backbone network includes BWSCs and regular ATM switches (SW). A BWSC is a special ATM switch that provides support for both wired and wireless services. Except the basic function of an ordinary ATM SW, it is also responsible for connection rerouting during inter-BSC handoff and location management such as registration and call delivery. The mobility database consists of Home Location Register (HLR), Visitor Location Register (VLR), and Translation Server (TS). The HLR is responsible for managing account and maintaining user’s service profiles. The VLR maintains the roaming user’s profile to provide service to the visiting user. Signal Transfer Points (STP) doing address translation in a cellular telephone system do not exist in WATM system. Hence, A TS is required for the number translation when ATM backbone is employed. The TS is a database to translate a Non Geographic Personal Number (NGPN) into the ATM address of the HLR serving the owner of this number.. 2.2. Mobility Management Under Normal Condition. There are four procedures cooperating for mobility management based on two-tier location database in WATM [3, 2, 5]. When a user u1 moves from location area LA1 to another location area LA2 , the registration procedure is performed to inform V2 (the VLR for LA2 ) about u1 ’s arriving. The signal flow for registration procedure is illustrated in Fig. 2. Procedure I. Registration Step 1. The MS of u1 sends a registration message to BSC. 4.

(6) MS. BSC. BWSC. VLR2(V2). TS. HLR. VLR1(V1). REG(NGPN) REG(NGPN) REG_Req(NGPN) Trans_Req(NGPN) Trans_Ack(NGPN, HLRaddr) creat a record REG_Req(NGPN) REG_Req_Ack(NGPN, profile) REG_Req_Ack(NGPN) REG_Ack. Cancel(NGPN) Cancel_Ack(NGPN). REG_Ack. Cancellation Procedure. Figure 2: The signal flow for registration procedure and cancellation procedure. Step 2. The BSC places this registration message into ATM cells which are sent to the BWSC along with u1 ’s NGPN. Step 3. The BWSC forwards the registration request to V2 through an ATM PVC (Permanent Virtual Connection). Step 4. V2 requests TS to translate the NGPN into the address of u1 ’s HLR. Step 5. V2 creates a temporary VLR record for u1 . Step 6. V2 forwards the registration request to u1 ’s HLR. Step 7. The HLR updates the location information about u1 ’s MS, and sends u1 ’s profile to V2 . Step 8. The MS receives an acknowledgement for this registration. Since u1 has moved from LA1 to LA2 , u1 ’s VLR record in V1 (the VLR for LA1 ) becomes obsolete. The following procedure is executed to delete the obsolete record in V1 . The signal flow for cancellation procedure is shown as the dotted box in Fig. 2. Procedure II. Cancellation Step 1. The HLR sends a cancellation message to V1 . Step 2. V1 removes u1 ’s record and sends a cancellation acknowledgement to the HLR. 5.

(7) Source MS. BSC1. BWSC1. VLR1(V1). TS. HLR. VLR2(V2). BWSC2 BSC2. Dest MS. Call_Orig Call_Orig Orig_Req(NGPN) Call grant Trans_Req(NGPN) Trans_Ack(NGPN, HLRaddr) Orig_Ack(NGPN, HLRaddr) ATM SVC Setup LOC_Req(NGPN) Route_Req(NGPN) Route_Req(NGPN) Ack(NGPN, BSCaddr) Ack(NGPN, BSCaddr) LOC_Ack(NGPN, BSCaddr) Call_Ack(NGPN, BSCaddr) ATM SVC Setup Alerting. Call_Ack. Figure 3: The signal flow for call origination procedure and call delivery procedure. If a wireless user u1 would like to set up a connection with other terminals, the following procedure is executed. For simplicity, the authentication process is omitted. Procedure III. Call Origination Step 1. The MS of u1 sends a call origination request to BSC. Step 2. The BSC forwards the origination request to VLR through BWSC. Step 3. The VLR checks u1 ’s profile and grants the request. Step 4. The BWSC judges whether the called party is a wireless terminal or not. Step 5. If it is a wired terminal, an ATM connection will be set up to the destination switch serving the fixed party. Otherwise, a call delivery procedure for wireless users is executed. To deliver a call to a wireless user u1 , the following procedure is proceeded. Without loss generality, we assume that the calling party is also a wireless user. Under such condition, the signal flow for call origination procedure and call delivery procedure is illustrated in Fig. 3. 6.

(8) Procedure IV. Call Delivery Step 1. BWSC1 (the source BWSC) forwards the call request from calling party to the related VLR (i.e. V1 ). Step 2. Upon receiving the call request, the V1 launches a translation query to TS. Step 3. As TS returns the address of u1 ’s HLR, V1 forwards the address to BWSC1 . Step 4. BWSC1 sets up an ATM SVC (Switched Virtual Connection) to u1 ’s HLR, and sends a location query to it. Step 5. The HLR identifies the current VLR of u1 (i.e. V2 ), and sends V2 a query message to obtain the ATM address of BSC2 (the BSC serving u1 now). Step 6. The V2 forwards the address query to BWSC2 , and receives an acknowledgement along with the requested address. Step 7. The V2 returns the ATM address of BSC2 to the HLR. Step 8. The HLR returns the ATM address to originating BWSC1 . Step 9. The BWSC1 passes the address to BSC1 . Step10. Based on the address, BSC1 sets up an ATM SVC to BSC2 . Step11. BSC2 pages u1 and the connection is established. If the calling party is a wired terminal, the procedure is very similar. The only difference is that BWSC1 will be replaced with an ordinary ATM switch.. 2.3. Mobility Management Under Overflow Condition. When VLR overflow occurs, the incoming users cannot register by using Procedure I. There are similar problems in cellular communication system. Lin proposed an overflow control scheme to solve this problem [6]. We make some adaptions to fit our research in wireless ATM. In order to allow incoming users to receive services while VLR is full, Procedure O-I, O-II, O-III, and O-IV are proposed to replace Procedure I, II, III, and IV, respectively. Suppose that the user u1 moves from location area LA1 to location area LA2 . If V2 (the VLR for LA2 ) is not full, the procedure I is executed; otherwise, procedure O-I is executed.. 7.

(9) Procedure O-I. Registration Step 1-4. These steps are the same as those in Procedure I. Step 5. Since V2 cannot create a temporary VLR record for u1 , it randomly selects a record to be replaced with the u1 ’s record.1 The selected user (e.g. u2 ) is called a victim user in our research. Step 6. V2 forwards the registration request to u1 ’s HLR. V2 also inform u2 ’s HLR that u2 ’s record is deleted due to database overflow. Step 7. The HLR of u1 updates u1 ’s location record, and sends u1 ’s profile to V2 . Step 8. The HLR of u2 sets the victim flag in u2 ’s record. If u1 is not a victim user, the Procedure II is executed to remove the obsolete record in V1 . On the contrary, the only thing to do is reset the victim flag of u1 ’s HLR record in Procedure O-II. Procedure O-II. Cancellation Step 1. The victim flag of u1 ’s HLR record is reset. If a victim user u1 would like to originate a call connection, the following procedure is executed. Procedure O-III. Call Origination Step 1-2. These steps are the same as those in Procedure III. Step 3. The VLR cannot find u1 ’s profile and denies the call request. Step 4. A registration procedure is initiated by u1 ’s MS to rebuild u1 ’s record. Step 5. The normal call origination Procedure III is executed. If a call for the victim user u1 arrives, the following procedure is performed to deliver the call to u1 . 1 The replacement policy can use other heuristic functions. The random replacement policy is just the most straightforward one.. 8.

(10) Procedure O-IV. Call Delivery Step 1-4. These steps are the same as those in Procedure IV. Step 5. Because of the set victim flag, u1 ’s HLR recognizes that u1 is a victim user and sends a query message to obtain the ATM address of BSC2 (the BSC serving u1 now). The u1 ’s profile information is attached in the query message. Step 6. If V2 is not full, a record for u1 is created. If V2 is full, a randomly selected record (e.g. u2 ’s record) is replaced with u1 ’s record. Besides, V2 forwards the address query from HLR to BWSC2 for the BSC2 ’s address. Step 7. The V2 returns the ATM address of BSC2 to the HLR. Moreover, the replacement information will be sent to inform u2 ’s HLR. Step 8-11. The remainder steps are the same as those in Procedure IV. With the four procedures described previously, the incoming user can still receive services even if the number of total users exceeds the capacity of a VLR.. 3. Second-Chance Replacement Policy. The active users are the mobile subscribers with high probability to make call connections. According to the Procedure O-III and Procedure O-IV, these active users are not the proper targets to be replaced. They have higher probability to cause another replacement after they were replaced. However, the RR policy has 50% probability to select them as victims. The main idea of the SCR policy is that the inactive users are the better targets for replacement. In this method, the records in VLR are linked into a circular list. A pointer points to the head record of this circular list. The record associated with each new arriving user is inserted into the tail of the circular list. If a user issues/receives one call connection, the reference bit in his VLR record will be set. When record replacement is required due to overflow control, the victim is chosen following the order of records in the circular list. If the reference bit of the chosen record equals 1, the reference bit will be cleared and the record should be skipped. Otherwise, the chosen record will be replaced with the record of the incoming user. The new record becomes the new tail of the circular list.. 9.

(11) reference bit. pointer. +: Call connection. *: New arrival. 0. 0. 0. 1. 1. 1. 0. 1. 0. +. 0. *. 1. 1. 0. 0. 1. 0. 0. 0. 0. 0 Victim. 1. 1. 0. 0. VLR database (a). VLR database. 1. 1. VLR database (c). VLR database (d). (b). Figure 4: An illustrative example of the SCR policy. An illustrative example in Fig. 4 is provided to show how this policy works. As Fig. 4(a) shown, all records are linked into a circular queue. A pointer indicates which record is the head of the queue. The head will be considered first while the next replacement request arrives. If one call connection to/from the user of the third record arrives/issues, the related reference bit will be set as Fig. 4(b). When a new user arrives and the VLR is not full, his/her record with a set reference bit will be inserted into the tail of the circular queue as that in Fig. 4(c). While a replacement is required, the record pointed by the pointer is considered first. If the reference bit of the pointed record is zero, then it is selected to be the victim. Otherwise, the pointer advances itself until it finds a record with a zero reference bit. As the pointer advances, it clears the reference bits that it passes through. The resulting situation is shown as Fig. 4(d) . As you can infer, if a user makes call connections often enough to keep the reference bit always 1, the record associated with this user will never be replaced. By giving a second chance to the active users, this policy tends to select the inactive users for replacement. These inactive users have lower probability to request services after they have been replaced. Consequently, the SCR policy is expected to reduce the number of replacements happened. 10.

(12) in the overflow system. For a fixed tolerable replacement rate, the SCR policy needs less VLR capacity than the RR policy.. 4. Discrete-event Simulation Model for the SCR Policy. This section describes the simulation model for the SCR policy. In our experiments, we make the following assumptions. • There are two classes of mobile users. Class 1 users have a low call connection rate λc,1 , and class 2 users have a high call arrival rate λc,2 . • The user arrival rates of the class 1 and class 2 users are λu,1 and λu,2 , respectively. • The call connections are assumed to be Poisson processes [8]. • The user arrivals are assumed to be Poisson processes, too. • The VLR residence time of all users has Gamma distribution with mean 1/λm and variance Vm [9, 10]. The second and third assumptions can be easily relaxed to fit general distributions in our simulation experiments. The data structure used in the SCR simulation model is shown in Fig. 5. A circular linked list is used to represent the VLR database. Each record in the VLR list has two pointers and one reference bit as follows: Event pointer (ep) : it points to the event object whose associated user is currently using this record. Link pointer (next) : it is used to maintain the circular link list. Reference bit (ref ) : it indicates whether its owner had call connection recently or not. The VLR list contains a victim record pointer (vrp). The vrp always points to the record that is the first target for replacement. When a replacement is needed, vrp advances itself until a victim record with zero reference bit is found. The reference bit of each record met by vrp is cleared. In the worst case, when the reference bits of all VLR records equal 1, the vrp cycles the whole circular VLR list. In such condition, the reference bits of all 11.

(13) VLR list. The event list e c e0 c. 1. vrp. 0. d. 1. a. 0. a: User_Arrival event c: Call_Connection event d: User_Departure event. Figure 5: Data structure used in the SCR simulation model. records are cleared and the record pointed by vrp in the beginning is finally selected as the victim. There are three types of events in our simulation model: User Arrival, Call Connection, and User Departure. Each record in the event list has the following fields to represent an incoming event. Fig. 5 shows only three related fields (Type, rp, next) for simplification. Type : the type of the event Class : the class type of the associated user Timestamp : the time when the event occurs Dt : the time when the user leaves the VLR rp : pointer that points to the associated VLR record next : pointer used to maintain the event list fa : a flag which indicates whether the user’s VLR record was ever replaced or not. fb : a flag which indicates whether the user ever makes call connection after his/her VLR record was replaced.. 12.

(14) If the corresponding user was a victim due to a replacement, an event e has no associated record object in the VLR list. That is, e.rp is set to NULL (e.g. event eo in Fig. 5). Otherwise (i.e. not overflow), the associated event e and the related VLR record points to each other (e.g. event e in Fig. 5). Fig. 6 illustrates the flowchart for the SCR simulation model. The events are inserted/generated into an event list, and removed/processed in the non-decreasing timestamp order. The simulation program maintains a system clock. The clock value is the timestamp of the event being processed. For the stable simulation result, 1,000,000 incoming users are simulated in each simulation run. In our simulation model, Na is the number of total user arrivals. Nα represents the number of users that have been replaced. Nβ is the number of users that had been replaced and had call activities before they left the VLR area. Initially, Na , Nα , and Nβ are set to zero and we generate a User Arrival event for each user class. The next event is removed from the event list at Step 3, and is processed according to its type at Step 4. Finally, the output of the simulations are probabilities α and β that can be computed as α = 1 − Nα /Na and β = 1−Nβ /Na . The flowchart provides very clear description about our simulation. We don’t go through it, but the additional remarks for key steps are supplemented as follows: User Arrival Event Step 8: According to the inter-user arrival time distribution, the next User Arrival event is generated. Step 10: If vrp.ref equals zero, then vrp is the victim record. Otherwise, vrp.ref is cleared and vrp is moved to the next record. Repeat Step 10 until a victim record with zero reference bit is found. Step 11: The flag fa in the event e associating with the victim user is set to indicate that he/she was ever replaced. Step 13: The associated event e and the related VLR record r have to point to each other. Moreover, the reference bit is set. Step 15-18: The next event for the user u is determined and inserted into the event list. 13.

(15) Start End. (1) Na=0, Nα=0, Nβ=0. (25) α=1-Nα/Na β=1-Nβ/Na. (2) Generate a User_Arrival event for each class of users and insert them into the event list.. (24) For each record e in event list If e.fa=1 Nα= Nα+1; If e.fb=1 Nβ= Nβ+1;. (3) Remove next event e from event list. Assume that the user of event e is u.. Yes User_Arrival. (5) Na=1000000?. (4) What kind of event is e?. User_Departure. Call_Connection. No. (6) Na=Na+1 (7) Compute u’s departure time and save it in e.dt. (8) Compute arrival time of next user. Generate the next User_Arrival event and insert it into the event list.. Yes. (9) Is VLR full?. (10) Select the first record r whose reference bit equals 0 as the victim for replacement. (11) Set r.ep.fa=1. (19) Is u an overflow user?. No. Yes (20) Set r.ep.fb=1. No. (12) Generate a new record r whose reference bit is set, and insert it to the tear of the circular VLR list.. (13) Set e.rp=r, r.ep=e, and r.ref=1 (14) Calculate u’s next Call_Connection time ct.. Yes. (15) Is ct < e.dt?. (16) Change event e to a Call_ Connection event.. No. (17) Change event e to a User_ Departure event.. (21)Release the associated VLR record, if it exists (22) If e.fa=1 Nα= Nα+1; If e.fb=1 Nβ= Nβ+1; (23) Remove event e.. Na: number of user arrivals. Nα: number of users that were ever replaced Nβ: number of users that were ever replaced and had call activity after replacement α: probability that a user is never replaced due to VLR overflow β: probability that a user’s call activity is never affected by VLR overflow control scheme e.fa: the flag that indicates whether the user was ever replaced or not e.fb: the flag that indicates whether the user’s call activity was ever affected or not r.ep.fa: it functions as e.fa r.ep.fb: it functions as e.fb e.rp: pointer that points to the associated VLR record r.ep: pointer that points to the associated event record r.ref: reference bit. (18) Insert event e into the event list.. Figure 6: Flowchart for the SCR simulation model. 14.

(16) Call Connection Event Step 19: If e.rp equals NULL, the associated user u is an overflow user. Step 20: The flag fb is set to indicate that u ever had call connections after his/her record was replaced. User Departure Event Step 21: If e.rp=r6=NULL, then record r is released. Step 22: According to flag fa and fb, the counter Nα and Nβ are increased by 1, respectively. Step 23: Finally, event e is removed from the event list. The RR Simulation model is similar but more straightforward. Except for Step 10, the flowchart of the RR simulation model is almost the same as Fig. 6. When a record replacement is necessary, the RR policy randomly select a victim from the VLR list.. 5. Numerical Analysis. As mentioned above, the VLR residence time distributions for both classes of users are assumed to have the Gamma distribution with mean 1/λm and variance Vm . In our simulation, Vm =1/λ2m is considered. We also assume that the total user arrival rate λu to a VLR area is a fixed value 2000λm , where λu = λu,1 + λu,2 . Vsize represents the VLR size and N is the expected number of roaming users. Fig. 7 plots αscr as functions of N where λc,1 = 0.1λm , λc,2 = 10λm , and θ = 0.5. This figure shows that for a fixed. Vsize N. ratio, the probabilities αscr are the same for various sizes. of the VLR databases. The same tendency is shown in Fig. 8 which plots βscr as functions of N . Simulation result shows that αrr and βrr are also independent of N for a fixed. Vsize N. ratio. Thus, we only consider N = 2000 in the remainder of this section. The same results can be obtained for larger N with the same. Vsize N. ratio.. The effects of λu,1 and λu,2 are shown in Fig. 9. It plots αscr and αrr as functions of the ratio θ, where θ =. λu,1 λu,1 +λu,2 .. Obviously, the SCR policy performs better than the RR. policy. If θ < 0.1 or θ > 0.9, the difference between two policies becomes small. As θ < 0.1, 15.

(17) . αscr. . Vsize/N= 6/10 Vsize/N= 8/10 Vsize/N= 10/10.

(18) The expected number N of users (Unit : 100 persons). Figure 7: Effects of. Vsize N. βscr. on αscr (λc,1 = 0.1λm , λc,2 = 10λm , λu,1 = λu,2 = 1000λm ). . Vsize/N= 6/10 Vsize/N= 8/10 Vsize/N= 10/10.

(19) The expected number N of users (Unit : 100 persons). Figure 8: Effects of. Vsize N. αscr αrr. on βscr (λc,1 = 0.1λm , λc,2 = 10λm , λu,1 = λu,2 = 1000λm ).

(20)

(21) The RR policy. The SCR policy. θ=λu,1/(λu,1+λu,2). Figure 9: Effects of θ on αscr and αrr (λc,1 = 0.1λm , λc,2 = 10λm , N = 2000). 16.

(22) βscr βrr.

(23)

(24)

(25) The RR policy. The SCR policy. θ=λu,1/(λu,1+λu,2). Figure 10: Effects of θ on βscr and βrr (λc,1 = 0.1λm , λc,2 = 10λm , N = 2000). αscr αrr. . The RR policy.

(26) The SCR policy. The expected number N of users (Unit : 100 persons). Figure 11: Effects of N on αscr and αrr (λc,1 = 0.1λm , λc,2 = 10λm , θ = 0.5). βscr βrr. . The RR policy The SCR policy.

(27)

(28) The expected number N of users (Unit : 100 persons). Figure 12: Effects of N on βscr and βrr (λc,1 = 0.1λm , λc,2 = 10λm , θ = 0.5). 17.

(29) Table 1: The saving rates of VLR size for α=80%, 90%, and 95% The required VLR capacity (Unit : records) under different requirement for α θ=0.5, N=2000 Vsizescr. α=80%. α=90%. α=95%. 1625. 1824. 1927. Vsizerr. 1795. 1908. 1976. Saving Rate (%). 9.47075. 4.40252. 2.47976. most users are class 1 users. No matter what policy used, there is almost one class of users being chosen in such condition. Therefore, the SCR policy and the RR policy have not much difference in performance. However, the normal condition is that both classes of users coexist in the system (i.e. 0.1 < θ < 0.9). The SCR policy outperforms the RR policy significantly in normal condition. If β is considered, Fig. 10 shows the same conclusion. To consider α, the effect of the expected number N of the roaming users are revealed in Fig. 11 . In this experiment, we assume that 50% of roaming users are class 1 and the others are class 2. This figure demonstrates that the SCR policy needs less VLR size than the RR policy to achieve a certain α vlaue. Fig. 12 plots β as functions of N where θ = 0.5. The SCR policy outperforms the RR policy more significantly. That is, it can save more VLR capacity than the RR policy for a fixed tolerable β value. Based on simulation results, we summarize the improvement made by the SCR policy. Table 1 concludes the different requirements for VLR capacity between the SCR policy and the RR policy. If system allows 5% of users whose VLR records are ever replaced during their residence in the LA, the SCR policy can save 2.5% VLR size. As the allowable α reaches 20%, the saving rate in VLR size is up to 9.5%. While β is considered, Table 2 summarizes the performance difference between the two replacement policies. In case system does not permit that more than 1% of users are affected in their call activities due to VLR overflow, the VLR size saved by using SCR policy is 12.8%. If the allowable β increases to 20%, the saving rate is up to 28.3%.. 18.

(30) Table 2: The saving rates of VLR size for β=95%, 98%, and 99% The required VLR capacity (Unit : records) under different requirement for β. 6. θ=0.5, N=2000 Vsizescr. β=95%. β=98%. β=99%. 1369. 1591. 1806. Vsizerr. 1909. 1990. 2071. Saving Rate (%). 28.28706. 20.05025. 12.79575. Conclusion. In WATM, the roaming users may visit or leave an LA from time to time. Due to the limited capacity, VLR overflow may occur if too many roaming users arrive in a short period of time. During the period of VLR overflow, an overflow control scheme takes the place of the normal mobility management procedures. Every roaming user can still receive services via the scheme. However, the side effect is the drop in the quality of services (e.g. longer connection setup time) provided to the victim users. To keep up the quality of services, system should not allow the replacement probability or the proportion of affected users over a tolerable threshold. Apparently, the VLR capacity is the key factor to affect the probability of VLR overflow and the number of victim users. Since the cost for maintaining such a mobility database increases significantly as its size is enlarged, the capacity of a VLR is not permitted to grow unlimitedly. The Random Replacement policy randomly select a victim record to be replaced while VLR overflow occurs. The replacement frequency and the number of victim users may be raised if the record of an active user is selected. In other words, the RR policy needs some unnecessary VLR space to achieve the tolerable QoS threshold. In this paper, we propose a more efficient strategy called Second-Chance Replacement policy. By giving chances to the active users, the inactive users are given precedence to be replaced. Such arrangement can reduce effectively the requirement for VLR capacity. Compared with the RR policy, simulation results demonstrate that the SCR policy can save considerable VLR size for various QoS thresholds. For example, if system requires that 99% 19.

(31) of roaming users are never affected in their call activities, the VLR size saved by the SCR policy is 12.8%. As the requirement lessens to 95%, the VLR saving rate is up to 28.3%. The SCR policy reduces the requirement for VLR capacity in evidence. Furthermore, The costs for maintaining mobility database increase significantly as its size gets larger. The SCR policy can save considerable costs through reducing the VLR size in wireless ATM.. References [1] S. Khatun, B.M. Ali, V. Prakash, and M. Ismail, “Performance analysis and optimization of a mobility support ATM switch,” Proc. IEEE GLOBECOM’01., vol. 6, pp. 3449-3453, 2001. [2] M. Cheng, S. Rajagopalan, L.-F. Chang, G.P. Pollini, and M. Barton, “PCS Mobility Support over Fixed ATM Networks,” IEEE Commun. Mag., pp.82-92, Nov. 1997. [3] 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. 13471384, Aug. 1999. [4] A. Acharya, J. Li, B. Rajagopalan, and D. Raychaudhuri, “Mobility management in wireless ATM networks,” IEEE Commun. Mag., pp.100-109, Nov. 1997. [5] B.A. Akyol, and D.C. Cox, D.C., “Handling mobility in a wireless ATM network ,” Proc. INFOCOM ’96., vol. 3, 1996 pp. 1405-1413 [6] Y.-B. Lin, “Overflow control for cellular mobility database,” IEEE Trans. Veh. Technol., vol. 49, no. 2, pp. 520-530, Mar. 2000. [7] Y.-B. Lin, “Modeling techniques for large-scale PCS networks,” IEEE Trans. on Comput., vol. 50, no. 4, pp. 356-370, Apr. 2001. [8] S.M. Ross, “Stochastic Processes Volume I-Theory,” John Wiley & Sons, Inc., 1983. [9] S.M. Ross, “Introduction to Probability Models,” Academic Press, Inc., 1993. [10] J. Banks, J. Carson II, and B. Nelson. “Discrete-Event System Simulation,” Prentice Hall, 1996. 20.

(32)