Fast and Scalable Access to Advance Resource Reservation Data in Future Cellular Networks Aixin Sun∗ , Mahbub Hassan, Mohammed Baseem Hassan, Peter Pham† and Boualem Benatallah School of Computer Science and Engineering University of New South Wales Sydney, NSW 2052, Australia Email: {mahbub, mbaseem, boualem}@cse.unsw.edu.au
Abstract— Increasing demand on the scarce radio spectrum indicates that availability of required radio resources (e.g. wireless bandwidth) at a given time and location will be less certain in the future. Resource uncertainty inhibits many future applications that require large amount of resources to be guaranteed at specific times and locations. In order to address the problem of resource uncertainty, these applications may need to reserve network resources in advance. However, in order to support percall advance reservation, the network must store, process, and access large volume of reservation data efficiently. In particular, the admission control functions must have fast and scalable access to these reservation data for making effective decisions regarding the acceptance and rejection of both immediate and future calls. In this paper, we propose a distributed reservation database architecture that features proactive processing and delivery of reservation data to admission control functions located in each radio base-station. To demonstrate the effectiveness of our architecture, we present results from a prototype experiment that compared the proposed proactive approach with the traditional query-based data delivery approach. With proactive approach, the response time of admission control was 20 times or more faster than traditional query-based approach in our experiments.
I. I NTRODUCTION With increasing data rate, next generation cellular networks will be capable of supporting novel infrastructure communications that has totally different requirements than that of traditional personal voice calls. For example, embedded mobile routers [1] in future vehicles could be connected to an Internet Service Provider’s (ISP’s) gateway through cellular networks as soon as the ignition key of the vehicle is turned on. The mobile router remains connected to the ISP’s gateway, and continues to provide high-speed information and entertainment for on-board passengers until the vehicle reaches its destination. In this example scenario, the mobile call was not made by a person holding a personal device, but rather by an embedded device (the mobile router), which needs guaranteed availability of enough radio resources (e.g. some minimum communication bandwidth) at specific locations (base-stations) and times so the passengers can enjoy uninterrupted service throughout the trip. However, the scarcity of radio spectrum fuelled by growing demand for mobile computing and communications indicates *Aixin Sun is currently with School of Computer Engineering, Nanyang Technological University, Singapore. Email:
[email protected] † Peter Pham is currently with Cohda Wireless Pty Ltd, Suite 5, 83 Fullarton Road, Kent Town, SA 5067, Australia. Email:
[email protected]
that the availability of large amount of radio resource at a given location and time will be less certain in future. Resource uncertainly can seriously inhibit the development of such novel applications over cellular networks. Given that the call start time, duration, and mobility for such applications1 can be derived well in advance, operators of future cellular networks may allow per-call advance reservation of its network resources. In order to support per-call advance reservation, the network must store, process, and access large volume of reservation data efficiently. In particular, the admission control functions must have fast and scalable access to the reservation data for making effective decisions regarding the acceptance and rejection of both immediate and future calls. In this paper, we propose a distributed reservation database architecture that features proactive processing and delivery of reservation data to admission control functions located in each radio base-station. To demonstrate the effectiveness of our architecture, we present results from a prototype experiment that compared the proposed proactive approach with the traditional query-based data delivery approach. The response time of admission control with our architecture was 20 times or more faster than that of the query-based approach. The rest of the paper is organised as follows. Using a simple framework for advance reservation in cellular networks, Section II explains the data structure needed to store reservation information of future calls, and how various admission control functions interact with the reservation database. Section III motivates and presents the proposed distributed database architecture. Proactive data access is presented in Section IV followed by experimental results in Section V. Finally, we conclude the paper in Section VI. II. A DVANCE R ESERVATION F RAMEWORK Figure 1 shows an example framework2 to illustrate how advance reservation would work for cellular networks. An user agent (e.g. a communications software) makes a reservation request Rj with following information: departure time 1 Other examples of infrastructure communications where the call start time, end time, and the route can be predicted well in advance would include Internet connectivity in public transports, routine video surveillance from unmanned vehicles, and so on. 2 This is only an example of a generic framework. A cellular operator may have a practical implementation that has different elements, but the results presented in this paper will maintain its relevance.
Case 1
Reservation Agent
Reservation request
Gateway
Reservation Admission Control
Reservation Agent
RC
User Agent RC 1
Network Data Mining Centre
MSCs
RC 2
MSC1
MSC2
Case 3
MSCs
Resource Allocation Register Case 2 BS 1
BS 2
BS 3
BS 4
BS 5
BS 6
RC 1
RC 2
RC 3
RC 4
RC 5
RC 6
Call Admission Control Non-Reserved Call Request
Fig. 1.
Reservation Framework
BS: Base-station
Fig. 2.
and location, arrival location, travel route(s), and amount of resource (e.g., bandwidth) to reserve at different locations. User may also simply provide the type of application (e.g., video conferencing, mobile TV) if unsure about the amount of resource to reserve. Based on the given information and historical log data, network data mining centre works out residence times3 for each cell along the route. Reservation agent (RA) then translates Rj into a set of cell reservation requests {Rji }. Each cell reservation request Rji = huj , ci , tsi , tei , ri i specifies that ri resource needs to be reserved for user uj from time tsi to time tei at cell ci . Clearly, the number of cell reservation requests equals the number of base-stations involved in user’s trip. Reservation admission control or RAC is responsible for accepting or rejecting cell reservation requests from RA. If all cell reservation requests in Rj are accepted by RAC, Rj is accepted; all its cell reservation records are then stored in a resource allocation register or RAR, and a unique reservation ID is returned to the user. Once resource reservation is confirmed, the user can enjoy the trip with uninterrupted service by showing the reservation ID at each cell crossings along the route. Similar to any other reservation system, a user may cancel or alter a previously confirmed reservation. Cancellation of reservation is a relatively simple operation where the reservation record(s) in RAR are deleted for the corresponding reservation ID. Alteration of reservation can be considered as a cancellation request followed by a new resource reservation request. In this paper, we therefore focus on resource reservation requests only. RAC is not the only function that needs access to RAR. Call admission control (CAC), that typically resides in each cellular base-station, now will handle both non-reserved and reserved requests and need access to RAR as well for every single admission control decision. To accept or reject a reserved request, CAC needs to verify the validity of the given reservation ID, and hence needs to access RAR. CAC also needs to access RAR for the traditional non-reserved calls, e.g. personal voice calls, because it needs to make sure that enough resources will be available in the base-station for approaching reserved calls. The situation is similar to a restaurant where the owner turns away customers who did not make prior reservations to leave 3 Note
that specific learning techniques are out of the scope of this paper.
RC: Reservation Controller (RAC+RAR)
An overview of cellular network infrastructure
some tables unoccupied for soon-to-be-arriving customers who made prior booking. If CAC fails to block non-reserved calls, it may be necessary to interrupt some on-going non-reserved calls (asking dining customers to leave!) to make room for a call that reserved resources in advance. Such look-ahead CAC has been studied by several researchers in the context of advance reservation [2], [3], [4]. In this paper we are not concerned with how the look-ahead time is determined for a good network performance, but rather emphasise that look-ahead is an absolutely essential feature of any CAC that operates within an advance reservation framework. It is this requirement that makes it necessary for CAC to have efficient access to RAR even when dealing with non-reserved calls. III. D ISTRIBUTED R ESERVATION M ANAGEMENT Since both RAC and CAC need access to RAR for every single user request, locating RAR within the cellular network infrastructure needs some planning to avoid excessive signalling overhead in the backbone. The task of reservation management is further complicated by the fact that many cellular operators would prefer minimum modification to existing infrastructure to achieve ease of deployment and maintenance. A cellular network consists of a large number of radio basestations. Based on their locations and/or workload, these basestations are grouped into clusters. All base-stations within a cluster are connected to a mobile switching centre (MSC) using land lines. An MSC stores information about the mobile devices resident within its corresponding cluster and is responsible for directing calls to them. Each MSC is connected to other MSCs and all MSCs are connected to the network gateway. Figure 2 illustrates a simple cellular network with 6 base-stations and 2 MSCs. The reservation agent of the network is connected to the gateway. Since RAC is tightly coupled with RAR, they need to be physically close to each other to minimise signalling overhead. Hence, in our architecture, RAC and RAR are always placed together, and we name the two components together a Reservation Controller (RC). Once we have the RAC and RAR together, the main design issue for our distributed reservation management is then how to distribute RCs in the cellular
TABLE I C OMPARISON OF DIFFERENT APPROACHES FOR RESERVATION DATA
te
ts ts
MANAGEMENT
Approach Network modification RAR Workload CAC signalling cost RAC signalling cost CAC response time
Centralised minimum heavy high – High
Fully-Distributed maximum light – high very low
ts te
te ts
te
ts
te
Reservation data records
rmax
Our Approach in-between in-between in-between in-between low
infrastructure so reservation agent and CACs in the basestations can access RCs efficiently. There are basically two approaches to place RCs in a cellular network — centralised and distributed. With centralised approach, one RC is introduced to the entire network connecting to the gateway, as shown in Figure 2 (Case 1). Reservation data for all base-stations in the network is stored in the only RAR. The main advantage of this approach is that only minimal modification to the existing cellular network infrastructure is required and the maintenance cost is relatively low. Also, since RC is centrally placed with direct connection with reservation agent, there is no signalling cost for processing cell reservation requests. The main problem, however, is the communication between the central RC and the distributed CACs located in radio base-stations. For each admission control, a given CAC function will have to query the central RC. This will overload the RC, create heavy CAC signalling overhead, and more importantly increase the response time for CAC decisions. Clearly, a distributed approach would be more appropriate if we are to improve the CAC-RC communication. The level of distribution has important implications. In the extreme case (see Case 2 in Figure 2), reservation data can be distributed all the way to the base-stations, so CAC and RAR are physically co-located. Although this approach provides the fastest access to reservation data for the CACs, it may become prohibitive from deployment and maintenance point of view. Additionally, to make a reservation, each cell reservation request Rji now needs to be processed by the RAC associated with the corresponding base-station. This would significantly increase RAC signalling overhead in the network. Our distributed reservation management approach (see Case 3 in Figure 2) distributes the RCs to the MSCs. With this approach, each RAR stores reservation data for the MSC’s member base-stations. Compared with centralised approach, the workload of each RC is much lighter because of the less number of base-stations to support. As the number of MSCs in a network is much fewer than base-stations, our approach requires much less modification to the existing cellular network compared with Case 2. Table I summarises the differences our approach brings forward in comparison with the centralised (Case 1) and fully distributed (Case 2) approaches. IV. P ROACTIVE DATA ACCESS Because CACs are not physically co-located with RARs in our MSC-based distributed reservation management, the
Reserved resource
tc
te
Fig. 3.
time
Reservation histogram
data access method employed by the CACs plays a significant role on the response time of a CAC. A data access method stipulates how a CAC function accesses the reservation data stored in RAR and any associated processing on the data that is needed to make an accept or reject decision. As the response time of CAC is critical in cellular network, the typical querybased data access is not suitable because of data processing time at RAR and limited number of concurrent connections supported by RAR. This calls for an efficient and effective reservation data access mechanism for CACs. Before we proceed with our proposed proactive data access method, we first explain the process involved for an CAC to make an admission decision. A. Reservation Data Access Process The reservation records stored in RAR are used for (i) reservation verification when CAC receives a reserved request, (ii) resource availability checking when CAC receives a nonreserved request, or when RAC receives a cell reservation request. RAR stores records in the form of hdj , uj , ci , tsi , tei , ri i where dj refers to reservation ID4 and huj , ci , tsi , tei , ri i is one cell reservation Rji in an accepted user reservation request Rj . Reservation verification is rather simple by querying RAR whether the reservation record(s) exists given the reservation ID. Resource availability checking is however not so straightforward. There are three parameters essential for resource availability checking: resource requirement, start time ts and end time te . For a cell reservation request, ts and te are specified in the request; for a non-reserved call request, ts is the time when the call is received, i.e., current time tc , and te is the end of look ahead time (denoted by Ta ) for the call, i.e., tc + Ta . Resource is said available if and only if there is enough resource to meet the requirement for any time point between ts and te . A typical process for resource availability checking is to construct a reservation histogram [5] as shown in Figure 3. The time interval between ts and te is first partitioned into a number of time slots with a predefined time granularity (i.e., length of time slot, e.g., 5 seconds), denoted by Tδ . The accumulated resource reserved in each time slot in a base-station is then derived from the reservation records 4 Note
that, the same reservation ID dj is used for all Rji ’s in one Rj .
CAC for BS 1
Reservation histogram for BS 1
CAC for BS 2
Reservation histogram for BS 2
CAC for BS n
Circular array
id
res
Amount of reserved resource
id
res
Reservation data map
id
res
Reservation histogram for BS n
Reservation request bji
Reservation Admission Control
Reservation Histogram Updater
Fig. 5.
Processed reservation data in circular array
Ta
Resource Allocation Register d
u
c
ts
te
r
d1
u1
c1
ts1
te1
r1
d2
u2
c2
ts2
te2
r2
Td ...
t0 tc
tu
t1
... tu
tc
Fig. 4.
Proactive data access architecture
...
t2
tu
tc
overlapping with the time slot. Once constructed, resource availability checking requires one traverse of the reservation histogram. With traditional query-based approach, whenever resource availability needs to be checked, CAC issues a query to RAR with ts and te to retrieve the reservation records. CAC then constructs a reservation histogram with time complexity of O(mn) where m is number of time slots from ts to te , and n is the number of reservation records in each time slot. Since querying records from RAR and constructing reservation histogram both takes time, traditional query-based approach clearly leads to slow response time for CAC. Moreover, as CAC and RAR are not co-located, the reservation records delivery from RAR to CAC certainly results in significant signalling overhead and may cause propagation delay. Additionally, the high request arrival rate could result in heavy workload for RAR. Thus, traditional query-based approach is inappropriate for CAC to access reservation data in RAR. B. Proactive Data Access Architecture To guarantee fast response time of CAC, the architecture must ensure that CAC can access reservation data “locally” without the burden of processing large number of reservation records. In other words, reservation records need to be proactively processed and delivered to CAC before it makes a decision for any incoming non-reserved call. Thus, we propose to employ proactive approach where a program associated with RAR periodically processes the reservation records and pushes processed reservation data (i.e., reservation histogram) to CAC. In this way, CAC accesses processed data locally thus fast response time can be guaranteed. Proactive approach is applicable in this context because the start time and end time for any resource availability checking issued by CAC are pre-determinable, i.e., tc and tc + Ta respectively. Proactive approach is also applicable for reservation verification as for any given valid reservation ID, the corresponding reservation record Rji always satisfies tsi ≤ tc ≤ tei . The list of valid reservation IDs can then be pre-retrieved from RAR. The proactive data access architecture (see Figure 4) consists of three major components, namely, reservation admission
t3
update
... tu
tc
Fig. 6.
Processed reservation data update
control, resource allocation register, and reservation histogram updater (RHU) where RHU is the program associated with RAR for reservation data processing. Recall that a RC supports all member base-stations of one MSC, RHU periodically processes reservation records (retrieved from RAR) for these base-stations and pushes processed reservation data to their CACs. Thus, the proposed architecture provides proactive reservation data processing and data delivery. With proactive approach, the pro-actively delivered reservation data needs to be stored in CAC and updated along the time. In this architecture, we use a circular array to store the reservation histogram [5]. Each element in the circular array stores two components (see Figure 5), (i) amount of reserved resource at the time slot and (ii) a map structure containing pairs of reservation ID and amount of resource reserved, (dj , ri ). The former is used for resource availability checking and the latter is used for reservation ID verification. Given a non-reserved call request, time complexity for resource availability checking in CAC is O(1) as the number of time slots to check is fixed, which is Ta /Tδ ; given a reserved call request, time complexity for reservation ID verification is O(log2 n) with binary search where n is the number of reservations in a time slot. The amount of memory required in CAC depends on the number of elements in the circular array, which in turn, determines RHU’s update frequency. Note that, the minimum number of elements in the circular array is Ta /Tδ as CAC needs to check resource availability from tc to tc + Ta . As tc points to the next element every Tδ time interval, if the number of elements is exactly Ta /Tδ , RHU has to push the updated reservation data to the element previously pointed by tc to ensure the reservation data from tc to tc + Ta is up-to-date. As Tδ is relatively a short time interval, the update frequency is relatively high making RHU always busy in updating CACs of all member base-stations. To be able to adjust the update
V. E XPERIMENTS A. Implementation and Experimental Setting The proactive data access architecture is implemented in C++ using MySQL as RAR database at the Network Research Lab at School of Computer Science and Engineering (CSE), at the University of New South Wales (UNSW). Two RCs were implemented as server programs each connected to a MySQL database through CSE Intranet. We assumed that each RC processes reservation data for 50 base-stations. A client program was implemented to randomly generate requests following predefined parameter settings. The results reported in this paper were obtained on a 2.53GHz Pentium IV PC with 512MB RAM running Linux. B. CAC Response Time We studied the CAC response time with query-based and proactive approaches respectively. 10,000 reservation records were randomly generated for one base-station in a time window of 4 hours. With these reservation records stored in RAR, non-reserved requests were generated for the same base-station with arrival rate of 10 requests per second following Poisson distribution. With query-based approach, response time of CAC could be affected by the look ahead time Ta and time
Average CAC response time (ms)
20
Query-based approach Proactive approach
18 16 14 12 10 8 6 4 2 0 0
100
200
300
400
500
Look ahead time (sec)
Fig. 7. Average response time of CAC with query-based and proactive approaches Average number of records accessed
frequency, in our architecture design, we introduce a parameter Td as the update time interval where Td ≥ Tδ . The number of elements in the circular array is set to (Ta + Td )/Tδ and the array needs to be updated every Td time interval. Figure 6 illustrates the updating process when Td = 3 × Tδ . Starting with t0 when the reservation histogram is fully up-to-date and the last updated time is marked with tu . When time reaches t1 , tc points to next element and the element previous pointed by tc becomes outdated (grayed in Figure 6). When time reaches t3 , 3 elements in the histogram become outdated and update occurs. While a longer Td reduces the update frequency, the amount of processed reservation data to be pushed to CAC in each update becomes larger. That is, if Td is long, the update frequency is low and the amount of data to be delivered in each update is large, and the memory space occupied in CAC needs to be large as well. In short, such a design makes Td a control knob for adjusting the delivery frequency/delivery volume. The introduction of update time interval Td , however, gives constraint on making reservations from users. To make/cancel/alter reservation, the request has to be issued from users Ta + Td time before the resource is to be used, i.e., ts > tc + Ta + Td . The reason is that reservation histogram in CAC holds the processed reservation data from tc to tc + Ta + Td after each update. If ts ≤ tc + Ta + Td , the reservation histogram may have to be updated because of any newly accepted/cancelled reservation which results in additional signalling overhead. Note that, in the architecture, RAC accesses reservation data in RAR using query-based approach as start time and end time of any reservation request are defined by users and cannot be predicted by the system (as tc and tc + Ta for CAC).
800
Query-based approach Proactive approach
700 600 500 400 300 200 100 0 0
100
200 300 400 Look ahead time (sec)
500
Fig. 8. Average number of reservation records accessed with query-based and proactive approaches
granularity Tδ . We therefore study the impact of each of two parameters while keeping the other fixed. The average response time of CAC of processing 10,000 non-reserved requests with varying look ahead time using query-based and proactive approaches respectively is reported in Figure 7. We also recorded the number of reservation records accessed by CAC in make each decision when handling non-reserved requests as shown in Figure 8. Note that, with proactive approach, CAC does not need to access reservation records and therefore the values reported in Figure 8 are zeros for comparison purposes only. Four observations can be made from the results: (i) proactive approach was much more efficient than query-based approach. The average response time using proactive data processing was more than 20 times faster than that of traditional query-based approach, (ii) response time of CAC using pro-actively processed reservation data was not affected by the length of look ahead time, or the effect was negligible, (iii) with query-based approach, length of look ahead time had a linear effect on the number of reservation records to access, which in turn, had linear impact on CAC’s response time, and (iv) the experimental results confirmed that CAC’s time complexity is O(mn) with query-based approach as discussed in Section IV-A. The experiments on the impact of Tδ on CAC’s response time showed that the response time was less affected by the setting of Tδ , shown in Figure 9. For proactive approach, CAC’s response time was almost not affected by varying Tδ .
Query-based approach Proactive approach
Average RAC response time (ms)
Average CAC response time (ms)
30
20
15
10
5
25 20 15 10 5
0 1
Fig. 9.
5 10 30 Time granularity Tδ (sec)
0
60
Impact of time granularity Tδ to CAC response time
0
Fig. 10.
value 150 sec 5 sec 5 (Poisson) 120 sec (Poisson) 4 (Poisson)
Average RAC response time (ms)
Parameter Histogram update interval (Td ) Time granularity (Tδ ) Reservation request rate (req/sec) Length of request at each base-station Number of base-stations involved in each request
4000 8000 12000 16000 Number of reservation requests
20000
Impact of request arrival rate to RAC’s response time
TABLE II E XPERIMENT PARAMETER SETTINGS
ArrivalRate=2 ArrivalRate=3 ArrivalRate=4 ArrivalRate=5 ArrivalRate=6
24 22 20 18 16 14 12 30
On the other hand, a larger Tδ gave slightly faster response time with query-based approach because of its O(mn) time complexity (as longer Tδ leads to smaller m). C. RAC Response Time We also studied the relationships between RAC’s response time and parameters including request arrival rate and mean length of cell reservation requests. The response time reported are the average of processing randomly generated 20,000 user reservation requests. Reservation requests were randomly generated following the parameter settings given in Table II. Some parameters were generated following Poisson distribution and the mean values are given in Table II with a mark “(Poisson)”. Starting with an empty RAR, the accumulated average response time with varying reservation request arrival rate is shown in Figure 10. It can be observed that if the arrival rate was higher, RAC’s response time was longer (because more records needed to be retrieved from RAR5 ). As a result, reservation request arrival rate had a linear impact on the RAC’s response time. Similarly, with fixed request arrival rate, length of cell reservation request had a linear impact on the number of reservation records accessed by RAC. Experiments with varying request length confirmed that request length had a linear impact on RAC’s response time, as shown in Figure 11. VI. C ONCLUSION In order to provide guaranteed and uninterrupted services for resource demanding applications, future cellular network may allow per-call advanced reservation of resource. The network then has to store, process and access large volume of reservation data. In this paper, we propose a distributed 5 In our experiments, the outdated reservation records (i.e., t < t ) were e c deleted from RAR when performing histogram update.
Fig. 11.
60 90 120 Mean length of reservation request (sec)
150
Impact of request length to response time
reservation database architecture that features proactive processing and delivery of reservation data to admission control functions located in each radio base-station. To demonstrate the effectiveness of our architecture, we present results from a prototype experiment that compares the proposed proactive approach with the traditional query-based data delivery approach. As a part of future work, we would like to study data mining techniques for cell residence time estimation. VII. ACKNOWLEDGEMENT The work is funded by Australian Research Council Discovery Grant DP0452942. In addition, the authors would like to thank Marie Nguyen for her contribution in experiment implementation. R EFERENCES [1] C. Systems, “CISCO 3200 Series Mobile Routers,” 2003-2004, available at http://www.cisco.com/. [2] A. Greenberg, R. Srikant, and W. Whitt, “Resource Sharing for BookAhead and Instantaneous-Request Calls,” IEEE/ACM Transactions on Networking, vol. 7, pp. 10–22, February 1999. [3] Y.-D. Lin, C.-H. Chang, and Y.-C. Hsu, “Bandwidth brokers of instantaneous and book-ahead requests for differentiated services networks,” in IEEE Global Telecommunications Conference, no. 1, Nov 2001, pp. 2285–2289. [4] C. Oliveira, J. B. Kim, and T. Suda, “An adaptive bandwidth reservation scheme for high-speed multimedia wireless networks,” IEEE Journal on Selected Areas in Communications, vol. 16, pp. 858–874, Aug. 1998. [5] L.-O. Burchard, “Analysis of data structures for admission control of advance reservation requests,” IEEE Trans. Know. & Data Eng., vol. 17, no. 3, pp. 413–424, March 2005.
