Supporting Multi-Dimensional Range Query for Sensor Networks

Transcription

1 Supporting Multi-Dimensional Range Query for Sensor Networks Yu-Chi Chung I-Fang Su Chiang Lee Department of Computer Science and Information Engineering National Cheng-Kung University, Tainan, Taiwan, R.O.C. {justim, emily, Abstract This paper presents the design of Pool, an efficient and scalable data storage scheme for supporting multidimensional queries. The foundation of the work that makes the Pool approach superior in executing multi-dimensional queries is that it provides a novel and elegant higher dimension to two-dimensional data mapping mechanism. Our performance study proves the efficiency of the design. Keywords: Sensor networks, Data-centric, Multidimensional, Range query, Query processing. 1. Introduction Many different kinds of sensor applications have emerged in recent years [6]. In these applications, a large volume of data or events (they are considered the same thing and will be used interchangeably in this paper) are continuously collected and stored in (at) appropriate (proper) sensors for future use. Recent studies have found that the Data- Centric Storage (DCS) scheme is the most efficient one for storing and processing data in a sensor network when the sensor network is large. In DCS [13], each event is placed in a sensor network according to its event type, which refers to certain pre-defined constellations of attribute values such as temperature and pressure [13]. For example, the geographic hash table (GHT) approach [13] is designed to map event types to sensor nodes that store the same type of events. While processing a query, the system refers the hash table to locate the sensors that own the type of events required by the query and send the query to those sensors. A major limitation of the earlier DCS systems is that they either supported (support) only an exact match point query, such as GHT [13], or a simple range query concerning a maximum of two attributes, such as the time-indexing This work is supported by National Science Council of Taiwan (R.O.C.) under Grants NSC E MY3 and NSC E I-Fang Su is also a lecturer at the Department of Information Management Fortune Institute of Technology, No.1-10, Nwongchang Rd., Lyouciyou Village, Daliao, Kaohsiung County 831, Taiwan, R.O.C. scheme [9], the DIFS [8], and the DIST [12]. Recent technology in sensor hardware has demonstrated the capability of detecting multiple types of environment parameters (such as temperature, humidity, light, and barometric pressure) by each sensor [5]. It is mandatory that more functions should be added to sensors in future to fulfill the need of monitoring more complex environments. This means that a future event (or a sensor reading) is likely to be composed of several different attribute values, which will hereafter be referred to as a multi-dimensional event. The DCS systems mentioned above are inadequate for managing and processing these multi-dimensional events. We need new techniques for coping with multi-dimensional events to answer multidimensional queries. This is because processing a query over multi-dimensional events is much more complex than processing a query on single-dimensional events. The following issues need to be addressed to cope with the complexity of multi-dimensional events: (1) How to map highdimensional events to a two-dimensional space of sensors while still preserving the proximity of events. A poor mapping that fails to allow relevant events stay close in nearby sensors may ly increase the data collection and processing cost. (2) It is likely and perhaps often the case that a user is interested in just some of the attributes, but not all of them. In these circumstances, the query that a user issues is a partial-match (point or range) query. It is time-consuming to process these types of queries when compared to processing an exact-match query, as more events could satisfy the partial-match conditions, therefore requiring more sensors to process the query. Another tough problem is to find methods to reduce the processing cost of partial-match queries. (3) With the increasing number of sensors available, the cost of processing a query may not decrease correspondingly because more sensors need to wake up and transmit data. How to deal with this scalability problem is another obstacle of a DCS system. (4) The hotspot problem is often one of the major causes for serious performance downgrade in a DCS system. A well-designed highperformance DCS system should be able to provide good solutions to all these issues. Among these solutions, DIM (standing for Distributed Index for Multi-dimensional data)

2 is the only system able to fully support multi-dimensional range queries. However, DIM does not fully take the above factors into consideration in its design. These problems result in a substantial impact on the performance of DIM. In the following sections, we first use an example to explain how the above factors affect the performance of DIM. Then, we introduce the core features of the proposed study. DIM is inspired by a classical database index, the k-d tree [1], and embeds such an index in a sensor network. In DIM, each sensor is an index node. Thus, the number of index nodes in the sensor network depends on the size of the network. Figure 1(a) shows how an eight-sensor network is partitioned. Figure 1(b) displays the code of a zone and the corresponding value range of the network. Each zone is assigned a unique zone code, which is shown under each sensor in the figure. The mapping between the value range and the zone code is accomplished by a localitypreserving geographic hash [11]. The details of the hash function are omitted here as they are unrelated to the context of our work. When answering a range query, DIM finds all zones whose value ranges overlap with the range in the query and sends the query to index nodes of those zones. This design philosophy is beneficial for locating the sensors that are involved in a query. For example, to answer Q =< [0.6, 0.8], [0.6, 0.65], [0.45, 0.6]>, sensors of zone 110, zone 1111, and zone 1110 in Figure 1(a) are all involved. However, as the network size increases, the zones have to be further split into smaller zones. As a results, more zones of sensors are inevitably involved in the processing of the query. This directly entails an increase of the query processing cost. In other designs such as GHT [13], the sensors involved in a query may not increase with the size of the sensor network. (However, GHT is only suitable for processing one-dimensional events, as we have already mentioned.) A new storage system that is able to process multi-dimensional queries and reduce the number of involved sensors is therefore in high demand. In addition, sometimes a user is interested in some of the attributes, but not all of them. For instance, the resultant events of the partial-match range query Q =<, [0.6, 0.7], [0.4, 0.6]>, where denotes a don t care condition, is collected from the sensors in zones 010, 011, 110, 1111, and 1110 (Figure 1(a)). The result spans half the sensor network, resulting in a high query processing cost. The reason for the high cost is that the events are widely-scattered across sensors so that collecting them requires more effort in certain conditions. Additionally, the simulation result of DIM shows that DIM does not adapt gracefully to skewed data [11]. Thus, the hotspot problem affects the performance of the DIM system. A new, effective, and robust query processing mechanism is needed to facilitate more efficient processing of multi-dimensional queries in current DCS systems. In this paper, we propose a framework that copes well with (a) Sensor network with eight sensors [11]. Zone Code Value Ranges {[0,0.5], [0.5,1], [0,0.5]} {[0,0.5], [0.5,1], [0.5,1]} {[0,0.5], [0,0.5], [0,1]} {[0.5,1], [0.5,1], [0,0.5]} {[0.75,1], [0.5,1], [0.5,1]} {[0.5,0.75], [0.5,1], [0.5,1]} {[0.5,1], [0,0.5], [0,0.5]} 101 {[0.5,1], [0,0.5], [0.5,1]} (b) The corresponding value ranges of Figure 1(a). Figure 1. Examples of DIM. both exact match and partial match range queries on multidimensional events. The proposed framework also resolves all the observed problems concurrently. We term it the Pool scheme, because the index nodes in our system are grouped together and work as a data pool. The following list explains Pool s core features that differentiate our scheme from past research. 1. An inter-sensor data indexing scheme is designed to facilitate range query processing. The indexing scheme is elegant in the sense that (a) it preserves the distance of events during the mapping so that two nearby events in a high-dimensional space are still mapped to neighboring sensors (index nodes) in the sensor network, and (b) it provides an effective pruning mechanism to reduce the search space. The former (Point a) implies that the index nodes that are visited for processing a range query can be limited to a restricted geographic area. It therefore ly reduces the data transmission cost among the index nodes. It also prevents the query from flooding the whole sensor network. The latter (Point b) ensures that the number of visited index nodes is restricted. 2. The number of index nodes in our system does not increase with the network size. Instead, it increases with the workload of the whole system. This strategy prevents the rapid growth of amount communication messages among index nodes when the network size increases. 3. Pool has a workload sharing mechanism to alleviate the hotspot problem caused by a skewed event distribution. An index node that experiences an unusual workload (e.g., a burst of data insertion) can share the workload with its neighbor. The rest of the paper is organized as follows. Section 2 provides preliminaries upon which the design theory and application can be built. The details of the proposed method are given in Section 3. In Section 4, additional research issues are discussed in order to enhance the completeness of this work. Section 5 presents the simulation model and the simulation results. Finally, we summarize the paper and describe our future work in Section 6.

3 2. Preliminaries We use < V 1,V 2,,V k > to represent an event of k attribute values (e.g., temperature, humidity, etc.), where V i is the value of the i-th attribute. We assume all attribute values are scalar and have been normalized [11] so that they fall within the range [0, 1]. We define Q as an h-dimensional range query <[L 1,U 1 ], [L 2,U 2 ],,[L h,u h ]> on h attributes, where h k and L i and U i are the user-specified lower bound and upper bound of i-th attribute respectively. A k- dimensional event E =<V 1,V 2,,V k > is an answer of a h-dimensional Q if ((L 1 V 1 U 1 ) (L 2 V 2 U 2 ) (L h V h U h )) = true. Note that as dimension and attribute in this paper often refer to the same thing, we will use them interchangeably. The queries dealt with are categorized as follows. (1) A multi-dimensional exact match point query is a query whose h = k and L i = U i for all 1 i k. All events whose attribute values exactly match the corresponding user-specified values will be returned. (2) A multi-dimensional partial match point query is a query whose h < k and L i = U i for 1 i h. (3) A multi-dimensional exact match range query refers to a query whose h = k and L i U i for 1 i k. Sensors will return all events whose attribute values fall into the user-specified ranges of the corresponding attributes. (4) A multi-dimensional partial match range query is a query whose h<kand L i <U i for 1 i h. Note that for processing a partial match query (i.e., Type 2 or Type 4 query), the query can be rewritten by setting the range of each unspecified attribute to [0, 1]. That is to say, all possible values of this attribute satisfy the query. For example, Q is a partial match range query and from the j-thtothek-th are unspecified. Then, Q can be written as Q =< [L 1,U 1 ], [L 2,U 2 ],,[L j 1,U j 1 ], k j+1 {}}{ [0, 1], [0, 1],,[0, 1]> before it is processed. Note that as we have mentioned in Section 1, partial match queries (i.e., Type 2 and Type 4 queries) are more commonly seen in real sensornet applications. However, the state-of-the-art solutions for processing these two types of queries in a sensor network are very expensive in terms of both storage access as well as communication costs. The Pool technique was developed to address the disadvantages of current DCS systems. The Pool approach proposed in this paper is able to support all four types of queries efficiently. Our approach is specially effective for processing Type 4 queries, which is the most costly and most complex type of query to process in a sensor network. In Pool, it is assumed that each node maintains a neighbor table via periodic exchange of beacon messages. We also assume that every sensor node recognizes its own geographic location. This can be achieved through the use of GPS or other appropriate localization techniques [3]. The underlying routing protocol in Pool is the existing greedy perimeter stateless routing (GPSR) algorithm [10] which is quite popular and has been adopted in various systems [11, 12, 13]. To support the elegant features of a DCS system mentioned in Section 1, we visualize the deployment field of a sensor network as a number of equal sized grid cells. The size of each cell is α α meter 2 (α is a system parameter). With reference to their functions, the sensors of the network can be classified into two types. Each cell has both types of sensor nodes. Index Node: An index node is responsible for storing events and processing queries. The Pool design assumes that the sensor deployment is so dense [2, 14] that each cell contains at least one sensor node. Therefore, only the node closest to the center of a cell operates as an index node. Hence, each cell has only one index node. Non-index Node: All sensors that are not an index node are non-index nodes. We use C (x,y) to represent a cell in the sensor network, where (x, y) is the cell s logical position in the grid, and x and y are the column and the row respectively where the cell appears in the grid. Both x and y start from 0. Hence, C (0,0) is the cell at the 0-th column and the 0-th row. Therefore, C (0,0) is termed the origin of the grid (referring to Figure 2). The physical location of the origin C (0,0) is denoted as (x orig,y orig ). With this arrangement, each sensor can therefore determine which grid-cell it belongs to by using its own geographic location, the cell size α, and the coordinate (x orig,y orig ). Given a sensor with a physical location (a, b), its native cell is C (x,y),wherex = a xorig α and y = b yorig α. The detected events in this study are stored in a certain group of cells which forms a Pool. Figure 2 shows three Pools (i.e., P 1, P 2 and P 3 ) in the sensor network. The number of Pools in a sensor network dependents on the number of attributes of an event. If the dimensionality of an event is k, thenk Pools (i.e., P 1, P 2,, P k ) will exist in the sensor network. We use l to represent the side length (in terms of the number of cells) of a Pool. Hence, a Pool is composed of l l cells. We refer to the cell at the lower left corner of a Pool as the pivot cell (denoted as PC i ). When the location of PC i is determined and the side length of a Pool is given, then a Pool s layout can be established. For example, suppose the dimensionality of an event is three (i.e., k =3), and l =5. We assume that PC 1, PC 2,andPC 3 are at C (1,2), C (2,10),andC (7,3), respectively. The layouts of P 1, P 2,andP 3 in the sensor network are as shown in Figure 2. In this study, the pivot cell location of a Pool is chosen randomly [7, 13]. Given a Pool P i and its pivot cell PC i, the geographic relationship between all cells of P i and the pivot cell can be

4 C (0,0) (xorig, y orig) l= P Pivot Cell C(2,10) P 3 4 P Pivot Cell 1 C(7,3) Pivot Cell 0 C(1,2) Sensor Network Figure 2. The Pool layout. Non-index node Index node described by a Horizontal Offset (HO) and a Vertical Offset (VO) as follows. Definition 2.1. Horizontal Offset (HO) and Vertical Offset (VO). Given the pivot cell C (x,y) and a cell C (z,w) of P i,thehorizontal Offset (HO) and the Vertical Offset (VO)ofC (z,w) with respect to C (x,y) are defined as HO = z x and VO= w y. Note that HO and VO are always positive and 0 HO l 1, 0 VO l Design of a Data-Centric Storage System Supporting Multi-dimensional Queries The design goal of our system is to provide an energy efficient, hotspot-free and scalable approach for supporting multi-dimensional queries in sensor networks. Our design to achieve this goal includes three parts: data insertion, query processing and workload sharing. The data insertion mechanism stores detected events at appropriate nodes. The query processing mechanism analyzes a user query and forwards it to the nodes that own the interested events and retrieve the matching events. The workload sharing mechanism enables a sensor node to distribute its workload to other sensors when it finds itself overloaded. However, due to the size limitation of the paper, we will not present the details of the workload sharing mechanism but briefly mention the main idea in Section 4.2 and explain the details in our technical report [4]. For the same reason, the proofs of the theorems are also omitted [4] Data Insertion Mechanism The data insertion mechanism is responsible for storing a detected k-dimensional event E in an appropriate index node. We select two dimensions out of the k-dimensions of an event E =<V 1,V 2,,V k > and use the attribute values of these two dimensions to determine where the event E should be stored. First, we use the attribute that has the est value of an event to determine the Pool where the event should be stored. That is, if max(v j ) for 1 j k occurs at V i,theevente is stored at P i. In general the est value of an event can appear at any attribute and as the probability is close to uniform in most applications, detected events can thus be uniformly dispersed among Pools. Within each Pool, the cell where an event should be stored is determined by both the events est and second est attribute values. The distribution of events in the cells of a Pool is uniform, if the second est attribute values are also uniformly distributed. As a result, high-dimensional events can be uniformly mapped to a two-dimensional storage space. The following discussion comprises two parts. First, we define how the cells of a Pool are partitioned based on value ranges. Second, we explain how an event is inserted to a cell based on the value ranges of a cell Definition of Ranges of a Cell Each cell can be identified by two value ranges, the horizontal range and the vertical range. We use an example to explain how the horizontal range and the vertical range of a cell are assigned. Assume that a sensor network has three Pools (i.e., P 1,P 2 and P 3 )asshownin Figure 3. An enlarged P 1 and its cells are shown on the right of the figure. Let the side length of P 1 be five and PC 1 be C (1,2). The range displayed under each column of cells is the horizontal range of the cells belonging to this column. Thus, the horizontal range of the cells of the first column is [0, 0.2), that of the second column is [0.2, 0.4), and so on. The vertical range of a cell is assigned according to the following rule. Given a certain column of P 1, we evenly partition the range of 0 to the upper bound of the horizontal range of this column into five subranges. Each sub-range is assigned accordingly to be the vertical range of a cell of this column. We take the second column of P 1 as an example. For instance, the upper bound of the horizontal range of this column is 0.4. We split the range [0, 0.4) into five partitions and thus we have [0, 0.08), [0.08, 0.16), [0.16, 0.24), [0.24, 0.32) and [0.32, 0.4), respectively as the vertical ranges of the cells of this column. From this example, we can easily derive a general formula for the assignment of the horizontal and the vertical ranges of each cell. We denote Range H (C (x,y) ) and Range V (C (x,y) ) as the horizontal range and the vertical range respectively of C (x,y). C (x,y) P i and l is the side length of P i. Then, Range H (C (x,y) ) and Range V (C (x,y) ) can be determined by Equation 1. Range H (C (x,y) ) = [ HO, HO+1 ). l l Range V (C (x,y) ) = [VO HO+1 l 2,VO+1 HO+1 (1) l 2 ) Insertion of Events to Cells When a k-dimensional event E =<V 1,V 2,,V k > is detected, the event needs to be inserted into a cell. This actually involves two subtasks: (1) determining a Pool, and (2) determining a cell within this Pool to which the event should be sent. In the following, we first define some notations that are used in our discussion. Then, we present how these two tasks are accomplished.

5 C (1,2) Vertical Ranges C (3,4) P P1 P C (1,2) Sensor Network [0.16, 0.2) [0.32, 0.4) [0.04, 0.08) [0, 0.2) [0.2, 0.4) P 1 [0.48, 0.6) [0.64, 0.8) [0.4, 0.6) [0.6, 0.8) [0.8,1) [0.12, 0.16) [0.24, 0.32) [0.36, 0.48) [0.48, 0.64) [0.6, 0.8) [0.08, 0.12) [0.16, 0.24) [0.24, 0.36) [0.32, 0.48) [0.4, 0.6) [0.08, 0.16) [0.12, 0.24) [0.16, 0.32) [0.2, 0.4) [0, 0.04) [0, 0.08) [0, 0.12) [0, 0.16) [0, 0.2) Horizontal Ranges Figure 3. The horizontal range and the vertical range of each cell of P 1. Again, let E =<V 1,V 2,,V k > be a k-dimensional event. We define d i to be the dimension where the i- th est value occurs, and 1 i k. Thus, d 1 is the dimension where the maximum value among its attributes occurs, and d 2 is the dimension where the second est attribute value occurs, and so on. For example, if E =<0.3, 0.2, 0.1>, thend 1 =1because 0.3 is the maximum value of all dimensions. The notation V d 1 refers to V 1 (because d 1 =1), which is 0.3. For ease of understanding, we assume that all attribute values are distinct. That is, V g V h where g h, 1 h k and 1 g k. We will postpone until Section 4.1 the discussion about the more general case where the values of different dimensions could be identical. Deciding a Pool If d 1 of E is i (that is, the maximum value of E is V i ), then E should be stored at P i. The advantage of this arrangement is that the search of interested events can be concentrated on simply one Pool and the others can be ignored which ly reduce the search space. Deciding a Cell We use the est and the second est attribute values of each event to determine the location of the cell at which the event is going to be stored. For example, let E =<0.4, 0.3, 0.1>. Since the est value of E occurs at the first dimension (i.e., d 1 =1), E should be stored in P 1. The est value 0.4 falls within the range [0.4, 0.6) which is the horizontal range of the third column of cells in Figure 3. The second est attribute value is 0.3 and it falls within the vertical range [0.24, 0.36) of the cell at the third column and the third row (i.e., C (3,4) )ofp 1. Thus, E is stored in C (3,4). Formally, a formula is derived in the following theorem which determines the cell where an event should be stored. Theorem 3.1. Let E =< V 1,V 2,,V k > be a k- dimensional event. Suppose PC d 1 is the pivot cell of P d 1, which is the Pool to store E. LetC (x,y) be the cell [0.8, 1) at which E should be stored. Then, HO and VO can be determined by the following equation. HO = V d 1 l. VO = V d 2 l 2 (HO+1). (2) Notice that the location of the cell is determined easily by applying Equation 2, which is simply an arithmetic computation. There is no search process for the cell to store E, as required by most distributed index-based approaches. Finally, the detailed steps of the data insertion mechanism are given in Algorithm 1. Algorithm 1: Pseudo code of the data insertion mechanism. GIVEN: A multi-dimensional event E, and the side length l of Pools. FIND : A geographic location (a, b) in the sensor network, and the index node that is the closest to (a, b). 1 d 1 = the dimension that the est attribute value of E appears; 2 d 2 = the dimension that the second est attribute value of E appears; l HO = V d 1 l ; VO= V d (HO+1) ; 4 C (x,y) Get the pivot cell of P d 1 through a distributed hash table (DHT) ; 5 (a, b) Get the center of cell C (x+ho,y+vo) ; 6 Routing E to (a, b) using GPSR ; 3.2. Query Processing Mechanism The query processing mechanism consists of two parts: query resolving and queryforwarding. The query resolving function of the design is to determine a set of index nodes that are able to provide answers for the query. The query forwarding element forwards the query to this set of index nodes Query Resolving Mechanism for Exact Match Range Queries As the est value (i.e., V d 1 ) and the second est value (i.e., V d 2 )ofe are used to determine a cell in which E is stored, they can be utilized to locate the cells that contain the user-requested events. In the following, we say that a cell C (x,y) is relevant to a query Q if the index node of C (x,y) may own qualifying events of Q. Wefirstuse an example to explain the underlying concept of the query resolving mechanism. Example 3.1. Let Q =<[L 1,U 1 ], [L 2,U 2 ],,[L k,u k ]> = < [0.2, 0.3], [0.25, 0.35], [0.21, 0.24] > be a threedimensional range query. P 1 shown in Figure 3 is a Pool in the sensor network. Let E =<V 1,V 2,V 3 > be a three-dimensional event stored at an index node of a cell in P 1. If E is an answer of Q, then we are sure that E s est value is V 1 (i.e., V d 1 max = V 1 ) because this event is stored in P 1.AsV 1 is the est value of E, its V 2 and V 3 must be smaller than V 1. Therefore, V 2 of all events in P 1 must not be within the range [0.3, 0.35], because the event s V 2 value becomes the est among V 1, V 2,and

6 V 3, and hence the event should be stored in P 2 instead of in P 1. As we are now considering the cells of P 1,weare sure that V 1 of all events in P 1 must be er than 0.25 (otherwise, its V 1 cannot be the est among all), and V 2 of all events in P 1 must be less than 0.3 (for the same reason). More precisely, the cells of P 1 that may have events that satisfy Q would be those having a value range of [MAX(L 1,L 2,L 3 ),U 1 ]=[MAX(0.25, 0.2, 0.21), 0.3] =[0.25, 0.3] in the horizontal dimension, and a range of [MAX(L 2,L 3 ),MIN(U 1,MAX(U 2,U 3 ))] =[MAX(0.25, 0.21),MIN(0.3,MAX(0.35, 0.24))]=[0.25, 0.3] in the vertical dimension. The reason for a lower bound MAX(L 2,L 3 ) and an upper bound MIN(U 1,MAX(U 2,U 3 )) in the vertical dimension will be stated and proved in a later theorem. In this particular example, only C (2,5) satisfies the above condition because the cell s range [0.2, 0.4) intersects the derived query range [MAX(L 1,L 2,L 3 ),U 2 ]=[0.25, 0.3] in its horizontal dimension and its range [0.24, 0.32) also intersects the derived range [MAX(L 1,L 3 ), MIN(U 2,MAX(U 1,U 3 ))] = [0.25, 0.3] in the vertical dimension. That is, only C (2,5) may have events satisfying the given range query. All the other cells of P 1 do not have qualifying events, and hence they can be ignored in processing this query. In this way, the value ranges of a cell that may have qualifying events are determined in just one step (using the above formula). This process is therefore highly effective (requiring just one step) and efficient (sifting a high percentage of non-qualifying cells). According to the above discussion, we derive a general formula for finding the cells that satisfy a range query. Theorem 3.2. Q =<[L 1,U 1 ], [L 2,U 2 ],,[L k,u k ]> is a k-dimensional range query. C (x,y) is a cell of P i. Then C (x,y) may contain qualifying events (and should be retrieved in query processing) if Range H (C (x,y) ) RH i (Q) φ, and Range V (C (x,y) ) RV i (Q) φ, whereri H (Q) and RV i (Q) are the est and the second est value ranges respectively of qualifying events of Q that are stored in P i. R i H (Q) = [MAX(L 1,L 2,,L k ),U i ], R i V (Q) = [MAX({L 1,L 2, L k } {L i }), MIN(U i,max({u 1,U 2,,U k } {U i }))]. Let us use the earlier example in this subsection to illustrate the complete result after applying the theorem in query processing. Assume there are three Pools in the sensor network, and their layouts are shown in Figure 2. Q =< [0.2, 0.3], [0.25, 0.35], [0.21, 0.24]> is a three-dimensional range query. For P 1, the previous example has shown that only C (2,5) may have qualifying events. Based on Theorem 3.2, we have RH 2 (Q) = [0.25, 0.3] and R2 V (Q) = [0.21, 0.3] for the cells in P 2. We find that only the ranges of C (3,12) and C (3,13) of P 2 intersect RH 2 (Q) and R2 V (Q). That means only those events of C (3,12) and C (3,13) in P 2 can possibly satisfy the query. As for P 3,wehave RH 3 (Q) =[0.25, 0.24] and R3 V (Q) =[0.25, 0.24]. As a result, none of the cells of P 3 can possibly have qualifying events. The final result is shown in Figure 4 and the cells that are relevant to Q are shadowed. Amazingly, a P 1 C (1,2) (a) C (2,5) is relevant to the query. P 2 C (2,10) (b) C (3,12) and C (3,13) are relevant to the query. P 3 C (7,3) (c) No cell in P 3 is relevant to the query. Figure 4. The cells of P 1, P 2 and P 3 that are relevant to Q. large number of cells of the Pools can be screened in query processing and those cells relevant to Q can be determined easily using the rules in Theorem Query Resolving Mechanism for Partial Match Range Queries We mentioned in Section 2 that processing a partial match range query is much more costly than processing an exact match range query, and unfortunately the former occurs more frequently than the latter type of queries. Therefore, one of the major goals of this work is to effectively deal with partial match range queries. Interestingly, the query resolving mechanism presented in Section can be easily applied to processing partial match range queries without any modification, and yet it is much more efficient than any existing strategies found in existing literature. We use the following example to illustrate how the mechanism is used in processing partial match range queries. Example 3.2. Assume that Q =<,, [0.8, 0.84] > is a three-dimensional partial match range query. From the discussion in Section 2 we know that Q should be rewritten as < [0, 1], [0, 1], [0.8, 0.84] > before it is processed. By applying Theorem 3.2, we obtain RH 1 (Q) = [0.8, 1] and RV 1 (Q) = [0.8, 1] for P 1 cells, RH 2 (Q) = [0.8, 1] and RV 2 (Q) =[0.8, 1] for P 2 cells, and RH 3 (Q) =[0.8, 0.84] and RV 3 (Q) =[0, 0.84] for P 3 cells. Comparing the ranges of every cell with these RH i (Q) and Ri V (Q) for 1 i 3, we find that only the dark cells in Figure 5 are relevant to Q. This example clearly shows the effectiveness of the proposed method in processing partial match range queries. The details of the algorithm is given in Algorithm Query Forwarding Mechanism AsetR of relevant cells is obtained at the end of the Algorithm 2. We next discuss how a query is forwarded to these cells and how the retrieved qualifying events are sent back to the sink, where the query is issued. The basic scheme is that the sink first forwards the query to a designated node, referred to as a splitter. Subsequently, the

7 P 1 C (1,2) (a) C (5,6) is relevant to the query. P 2 C (2,10) (b) C (6,14) is relevant to the query. P 3 C (7,3) (c) C (11,3) C (11,7) are relevant to the query. Figure 5. Cells of P 1, P 2 and P 3 that are relevant to query <,, [0.8, 0.84]>. splitter sends a copy of the query to each index node. The splitter is chosen in such a way that the index node that is closest to the sink for each Pool the index node is designated as the splitter of the Pool. Since the Pools of the system are predefined, the sink knows which index node of each Pool is closest to the sink (i.e., the sink knows where the splitters are). The splitter determines the relevant cells within this Pool by using the equations in Theorem 3.1, and then sends a copy of the query to each relevant cell inside this Pool. The retrieved qualifying events are sent back to the sink through the same path. In this way, the entire query forwarding paths form a tree, which enables the system to consume sensor energy more efficiently than by unicasting the query to index nodes individually. The aggregate operations, which are frequently seen in sensor network applications, can also be performed in each splitter so that the number of events to be sent through the path can be ly reduced. The detailed algorithm the query forwarding mechanism can be found in our technical report [4]. Algorithm 2: Pseudo code of the query resolving algorithm. GIVEN:Ak-dimensional query Q =<[L 1,U 1 ], [L 2,U 2 ],, [L k,u k ]>, the Pool P i and the side length l of P i. FIND : A set of relevant cells (denoted as R)ofP i such that every cell in this set is relevant to Q. 1 if MAX(L 1,L 2,,L k ) U i then 2 R i H (Q) =[MAX(L 1,L 2,,L k ),U i ] ; 3 R i V (Q) =[MAX({L 1,L 2, L k } {L i }),MIN(U i,max({u 1,U 2,,U k } {U i }))] ; 4 for ho 0 to l 1 do 5 for vo 0 to l 1 do 6 Range H (C (x+ho,y+vo) )=[ ho l, ho+1 ) ; l 7 Range V (C (x+ho,y+vo) )=[vo ho+1 l 2, (vo +1) ho+1 l 2 ) ; 8 if (Range H (C (x+ho,y+vo) ) R i H (Q) φ) (Range V (C (x+ho,y+vo)) R i V (Q) φ) then 9 Put C (x+ho,y+vo) into the relevnat cell set R ; 4. Solving Additional Issues In the last section, we assumed that the attribute values of each event are distinct. Here, we discuss how the system reacts when multiple identical est values occur. Incidentally, we will briefly address how to deal with the hotspot issue in this section Multiple Greatest Values When more than one est value occurs in an event, an intuition is to store a copy of this event in each of the Pools that correspond to the dimensions of the event having the est value. For example, E =<0.4, 0.4, 0.2> is a threedimensional event, and the est value (i.e., 0.4) appears in the first and the second dimensions. From the discussion of Section 3.1, it is intuitive to think that E should be stored in both P 1 and P 2. However, this approach has the following major flaws. First, routing the event to multiple Pools clearly increases the communication cost. Second, it may lead to errors for aggregate queries (e.g., SUM, COUNT and AVG). The Pool scheme does not store multiple copies of an event. Instead, it only stores one copy of the event in the cell that is closest to the place where the event is detected. In the above example, for instance, we assume that E is generated in a sensor in C (8,12).UsingTheorem3.1,we find that E can be stored in C (12,13) or C (3,5).AsC (12,13) is closer to C (8,12), the sensor therefore forwards the event to C (12,13). While processing a query, the query is forwarded to all relevant cells (Section 3.2). Thus, although <0.4, 0.4, 0.2> is only stored in one cell, it can be retrieved by the query processing mechanism. Note that forwarding the query to other Pools that do not contain E =<0.4, 0.4, 0.2> is not a waste. This is because there may be other qualifying events in those Pools that should be retrieved. In the above example, for instance, a qualifying event <0.41, 0.4, 0.2> which is stored in C (3,5) should be accessed. Therefore, our mechanism does not incur any additional query forwarding cost, which makes the solution ideal Workload Sharing Mechanism The workload sharing mechanism is used to mitigate the hotspot problem caused by uneven distribution of data, for instance, a significantly high percentage of events appearing in the same value range. The basic idea of the workload sharing mechanism is that an index node can transfer its workload to another sensor when an index node finds that its remaining resource is below a certain threshold. This index node then switches to a low-power state to conserve energy. Due to the size limitation of the paper, we omit the details of this part and leave them in [4]. 5. Simulation Results As we have mentioned in Introduction, DIM [11] is the only DCS system that has the capability of processing multi-dimensional range queries. Thus, in this section, we conduct simulations to compare Pool with DIM. We compare their processing costs for both exact match queries and partial match queries. For both Pool and DIM, the query processing cost includes the cost of forwarding the query to the query-relevant index nodes plus the cost of retrieving the qualifying events from these query-relevant index

8 nodes. In the following, we first present our experiment settings. Then, a brief version of the performance results is described. Readers may refer to our technical report [4] for a complete study of the performance under various conditions Performance Model In all our experiments, we uniformly place sensor nodes in the entire field. The number of sensor nodes varies from 300 to Each node has a radio range of 40m and has on average 20 nodes within its nominal radio range [11]. The cell size is set to be 5m and the side length of each Pool is set to be 10 cells (i.e., α =5and l =10). Each sensor on average generates three events and each event is three-dimensional [11]. Similar to DIM, the attribute value on each dimension is uniformly distributed within [0, 1]. Exact Match Query Settings Each query is also threedimensional. To ensure a fair comparison, we employ the four query size distributions that were used in DIM [11] to emulate the range sizes specified in a query. Due to the size limitation, we only present the results of two of them in this paper. They are the uniform and the exponential distributions [11]. Partial Match Query Settings A partial match query occurs when one or more attribute value ranges are unspecified. An unspecified value range would be the entire value range [0, 1]. For convenience, we refer to a m-partial match query as a query with m unspecified value ranges. For example, Q =< [0.2, 0.4], [0, 1], [0, 1] > is 2-partial (i.e., m = 2). For a three-dimensional partial match query, m can be 1 or 2. We refer to them as 1-partial and 2- partial match query, respectively. To generate an m-partial query, we randomly choose m dimensions and set their range to [0, 1]. The range of dimensions that are not chosen is selected randomly from [0, 0.25]. In addition, for a 1-partial match query we further distinguish which attribute has the unspecified value range. If the unspecified value range is at the n-th attribute (1 n 3), we term it a 1@n-Partial match query. Hence, there can be 1@1-partial, 1@2-partial, and 1@3-partial match queries. The probability for having each type of the 1@n-partial match queries is the same. The reason for making the distinction of the 1@npartial match query is that DIM s performance is strongly dependent on the attribute in the query that has an unspecified value range. We need to examine how DIM and Pool react to the change of this attribute. In order to simplify the simulation, we do not further distinguish them from 2- partial match queries Query Processing Cost Our study includes two main tasks, data insertion and query processing. In this paper, we only present the comparison result of query processing. We omit the data insertion part in the presentation because the data insertion cost of both methods are conceptually the same. Both methods use the same data routing protocol, GPSR, for forwarding events to sensors. Hence, the difference is minor [4] Comparisons on Exact Match Queries In comparing the performance of exact match queries, we vary the range size distributions to measure the number of message exchanges among sensors. The result is shown in Figure 6. Interesting facts are observed from this figure. First, all the subfigures reveal that the range size of a query strongly affects the performance of the two approaches. For instance, both approaches cost much less in exponential size distribution (Figure 6(b)) than in uniform size distribution (Figure 6(a)). This is mainly because most queries in uniform size distribution have a quite large range size. A query therefore has to visit a large number of index nodes in order to acquire all the answers. Secondly, the performance result reveals that Pool is more scalable than DIM. Unlike DIM, the performance of Pool is much less sensitive to the size of the network, no matter the range size distribution. This is because DIM treats all sensors as index nodes. The number of index nodes that should be visited becomes relatively large in the large networks. However, the number of index nodes in the Pool approach does not necessarily increase with the network size. Instead, it increases with the workload of the whole system. This strategy avoids the rapid growth of message exchange among index nodes when the network size increases. Hence, scalability becomes achievable when the Pool approach is used Comparisons on Partial Match Queries As we mentioned before, partial match queries are more frequently used in most applications and they are more expensive to process than exact match queries. In this set of comparisons, the network size is fixed at 900 sensor nodes. The event distribution is uniform. Number of dimensions with unspecified ranges First, we examine how the number of dimensions with unspecified ranges in a partial match query affects the performance of both approaches. Our result in Figure 7(a) shows that the more the dimensions in a query with an unspecified range, the higher the query processing cost would be incurred. This is true for both approaches. For 1-partial match queries, the DIM s approach requires about 180% higher cot than the Pool s approach, whereas for 2-partial match queries, DIM becomes 250% higher. It clearly indicates that the DIM s approach performs poorly while processing partial match queries, especially for vague queries (where more dimensions of the query are with an unspecified range). 1-partial match queries We further examine the effect of the dimension in a 1-partial match query with an unspecified range on the performance of query processing. Our result in Figure 7(b) clearly shows that DIM s performance is highly dependent on the dimension where the unspecified value range occurs. Interestingly, it performs quite poorly for 1@1-partial match queries (i.e., the unspecified range occurs only at the first dimen-

9 Number of Messages 390 DIM 360 Pool Network Size (a) Query processing cost for uniform range size distribution. Number of Messages DIM Pool Network Size (b) Query processing cost for exponential range size distribution. Figure 6. Cost for processing exact match queries under varing range size distributions. Number of Messages DIM Pool 0 1-Partial 2-Partial Number of Partial Match Dimensions (a) Number of partial match dimensions. Number of Messages @1-Partial 1@2-Partial 1@3-Partial Partial Match Dimension DIM Pool (b) Partial match dimension order. Figure 7. Query processing cost for partial match queries. sion), and better for 1@3-partial match queries. The main reason is that DIM s design is based on a k-d tree. In a k-d tree, the data space is recursively partitioned into two halves based on the attributes one at a time. That is, events are distinguished as those stored on the left half and those on the right half of the sensor network based on the values of the first attribute (dimension). In each half, events can be further partitioned to those stored in the upper quarter of the sensor network or the lower quarter, based on the values of the second dimension, so on. Therefore, the performance of DIM is affected most if the first dimension in a partial match query gives an unspecified value range, because the entire sensor network is not screened at all. All the sensors will be re-examined in the next processing step, which is to use the second attribute s value range to screen sensors. The result is that the percentage of sensors that can be screened during the process is quite low. If the unspecified range of a partial match query occurs at the last dimension, however, the harmful impact can be reduced. That is why DIM s cost decreases in Figure 7(b). Pools performance, on the other hand, shows an extremely good pruning ratio, no matter which dimension of partial match query is with an unspecified range. The result shows that Pool has overcome the flaw of DIM and offers a better performance of around 50% to 100% than DIM s approach. 6. Conclusions and Future Work In this paper, we proposed the design and implementation of a framework named Pool for processing multidimensional range queries in sensor networks. The strict design goals presented in the Introduction have been successfully achieved through the data insertion and query processing mechanisms. Our performance study showed that Pool exhibits a superior performance and demonstrated that Pool is a highly successful design for multi-dimensional data storage and retrieval in sensor networks. Currently, we are extending the capability of Pool for providing more advanced functionalities including the continuous monitoring of the nearest neighbor queries, etc. References [1] J. L. Bentley. Multidimensional binary search trees used for associative searching. Communication of the ACM, 18(9): , [2] S. Bhattacharya, H. Kim, S. Prabh, and T. Abdelzaher. Energy-conserving data placement and asynchronous multicast in wireless sensor networks. In MobiSys 2003, pages , San Francisco, California, ACM Press. [3] N. Bulusu, J. Heidemann, and D. Estrin. Gps-less low cost outdoor localization for very small devices. IEEE Personal Communications Magazine, 7(5):28 34, Oct [4] Y.-C. Chung, I.-F. Su, and C. Lee. Supporting multidimensional range queries over sensor networks. Technical report, Department of Computer Science and Information Engineering, National Cheng Kung University, justim/tech range queries.ps, [5] Crossbow. Mep-sys datasheet. Website. xbow.com/products/product_pdf_files/ Wireless_pdf/MEP-SYS_Datasheet.pdf. [6] P. Desnoyers, D. Ganesan, and P. Shenoy. Tsar: a two tier sensor storage architecture using interval skip graphs. In Proceedings of SenSys 05, pages 39 50, [7] A. Ghose, J. Grossklags, and J. Chuang. Resilient datacentric storage in wireless ad-hoc sensor networks. In Proceedings of MDM 2003, pages 45 62, [8] B. Greenstein, D. Estrin, R. Govindan, S. Ratnasamy, and S. Shenker. Difs: a distributed index for features in sensor networks. In Proceedings of the First IEEE International Workshop on Sensor Network Protocols and Applications, pages , May [9] G. He, R. Zheng, I. Gupta, and L. Sha. A framework for time indexing in sensor networks. ACM Transactions on Sensor Networks, 1(1): , [10] B. Karp and H. T. Kung. Gpsr: Greedy perimeter stateless routing for wireless networks. In Proceedings of Mobicom 2000, Boston, Massachusetts, August [11] X. Li, Y. J. Kim, R. Govindan, and W. Hong. Multidimensional range queries in sensor networks. In Proceedings of the 1st international conference on Embedded networked sensor systems, pages 63 75, Los Angels, CA, November [12] A. Meka and A. Singh. Dist: a distributed spatio-temporal index structure for sensor networks. In Proceedings of CIKM 05, pages , Bremen, Germany, ACM Press. [13] S. Ratnasamy, B. Karp, S. Shenker, D. Estrin, R. Govindan, L. Yin, and F. Yu. Data-centric storage in sensornets with ght, a geographic hash table. Mobile Networks and Applications, 8(4): , August [14] Y. Xu, W.-C. Lee, J. Xu, and G. Mitchell. Processing window queries in wireless sensor networks. In Proceedings of ICDE 06, pages , Atlanta, GA, April 2006.