Faster In-Network Evaluation of Spatial Aggregation in Sensor Networks

Dina Goldin University of Connecticut, Storrs, CT, USA

Abstract

Spatial aggregation is an important class of queries for geoaware spatial sensor database applications. Given a set of spatial regions, it involves the aggregation of dy- namic sensor readings over each of these regions simul- taneously. Nested spatial aggregation involves one more level of aggregation, combining these aggregates into a single aggregate value. We show that spatial aggregate values can often be computed in-network, rather than waiting until the partial aggregate records reach the root as is now the case. This decreases the amount of commu- nication involved in query evaluation, thereby reducing the network's power consumption.

We describe an algorithm that allows us to determine when an aggregate record for any spatial region is ready to be evaluated in-network, based on decorating the routing tree with region leader lists. We also identify several im- portant scenarios, such as nested spatial aggregation and filtering predicates, when the savings from our approach are expected to be particularly great.

1 Introduction

It is expected that most applications of sensor net- works [2], such as security, civil and environmental engi- neering, or meteorology, will involve queries that combine streaming sensor data with spatial data [8, 101. F'urther- more, it is expected [I] that in many sensor network appli- cations the sensors will be geo-aware, i.e. they will know their location in some local or global coordinate system.

In this paper, we focus on spatial querying for geo- aware sensor databases. As is standard for the sensor database setting, we assume a central processor which provides an entry point for querying the sensor network; it serves as a host for a spatial database. Queries may involve both the data collected at sensors as well as data from this database. As is also standard, we assume that a routing tree is maintained over the sensors, whose root communicates directly with the central processor.

To avoid information overload, as well as to decrease the amount of costly communication during query evalu- ation, it is natural to aggregate sensor data. The issue of

aggregation has emerged as an important one for sensor network querying [5, 111.

We identify spatial aggregation as a new and particu- larly important class of continuous queries for geoaware spatial sensor networks. Given a set of spatial re- gions, spatial aggregation involves simultaneous aggrega- tion of dynamic sensor readings over each of these regions. Nested spatial aggregation involves one more level of ag- gregation, combining these aggregates into a single value.

A major challenge for sensor network databases is to perform continuous queries in the context of power con- straints on the sensors. For aggregation queries, most systems use in-network evaluation strategies to reduce the traffic and decrease power usage.

In this paper, we propose a new strategy for improving the efficiency of in-network evaluation of spatial aggre- gation queries. Specifically, we present a technique en- abling us to determine, during the bottom-up evaluation of aggregation records, when an aggregate record for any spatial region has finished merging and is ready to be evaluated. This allows us to push more processing into the network for many query scenarios, and achieve signif- icant savings as a result. Experimental results show that we can reduce in-network communication by up to 16%, without any drop in accuracy.

Outline. In Sec. 2, we define spatial aggregation and nested spatial aggregation; in Sec. 3, we show how to per- form these queries in-network using existing techniques. In Sec. 4, we present our technique, based on region leader lists. In Sec. 5, we discuss three of the scenarios where it can benefit in-network query processing (nested aggrega- tion, filtering predicates, and data pruning), by allowing us to push more computation into the sensor networks. The computation and maintenance of region leader lists, and the experimental evaluation of our technique, can be found in out technical report [3].

2 Spatial Aggregation Queries

In spatial querying over geoaware sensor networks, we often want to compute separate aggregate values for each of a set of regions, rather than over the entire network; we refer to this operation as spatial aggregation:

Proceedings of the 22nd International Conference on Data Engineering (ICDE’06) 8-7695-2570-9/06 $20.00 © 2006 IEEE

- Find average temperature for each region. - Find maximum humidity for each region.

These regions may represent cities, precincts, sections of an airport, etc. We assume that they are stored in a spa- tial database relation [a, 101 which includes a description of the geometry for each region and uses a region ID as the key. Note that multiple spatial relations over the same geographic domain may coexist in the database, such as police and fire districts. Our scenario allows continuous queries over them them to be processed simultaneously.

Definition 2.1 Given some aggregate function f and the relations

regions (RegionID, RegionGeometry) sensors(SensorID, SensorLocn, Value)

where Value is the dynamic attribute representing the sen- sor reading of some value of interest (e.g. temperature or humidity), spatial aggregation off over regions computes the relation agg(RegionID, Aggregatevalue), where:

RegionID is the key of both regions and agg, and the set of RegionID7s is the same for both relations:

TRegionID = nRegionID regi0ns

a tuple (R, v) belongs to agg if and only if, given the set SR of tuples in sensors which represents sensors lying inside the region R, v is the aggregate of Value's in SR, with f as the aggregate function.

We assume that every sensor is located within some region, and that for each region, at least one sensor is located within it. However, we do not assume that the regions are non-intersecting; a sensor may be located in more than one region simultaneously.

Example 2.1 Let regions consist of two regions: (Rl, RGeoml), (R2, RGeom2)

and sensors consist of four sensors:

(sl, ptl, 801, ($27 pt2, YO), (s3, pt3, 55), ($4, pt4, 70)

where p t l and pt2 lie inside region R1, and pt2, pt3, and pt4 lie inside region R2. Let AVG be the aggregate func- tion f ; then the output relation is: (Rl, 75), (R2, 65).

We now consider the case when a query consists of two levels of aggregation, with spatial aggregation at the lower level; we call such a query nested spatial aggregation:

- Which region has most sensors? - Which region has highest average temperature? - Which region has lowest max. ozone value?

In each example, spatial aggregation is performed first, to find the aggregate values (COUNT, AVG, and MAX respectively). The second aggregation determines an ag- gregate over the results. For example, the first query is evaluated as follows: (1) apply COUNT to the sensor readings in network, grouped by region; (2) apply MAX to the result.

3 In-network spatial aggregation

The standard framework for computing aggregation in sensor networks performs the computation in-network at the sensor nodes, as the data is transmitted up the rout- ing tree. In-network aggregation strategies reduce the number of records that need to be communicated up to the central processor. Due to the power-intensive nature of communication of sensor networks, this results in a significant reduction of power usage.

In-network aggregation is characterized by the follow- ing three functions [7]:

initializer i: sensor + state record merger f : { state records ) + state record evaluator e: state record + aggregate value

For details of the in-network aggregation technique, sees [7]. To evaluate spatial aggregation, one would apply this technique to all the regions simultaneously:

1. State records for spatial aggregation need an addi- tional attribute, region ID; we refer to a state record with this attribute as region aggregate record (RAR).

2. At each sensor node X, the initializer creates a sepa- rate RAR for each region to which the sensor belongs, assigning the ID of that region to the,record.

3. At each internal node Y, the meryer only merges RARs that share the same region ID; in effect, we execute many mergers in parallel, one for each region ID appearing among the input records for Y.

4. As a result of all merges, a complete aggregate record for each region arrives a t the root of the routing tree.

5. The evaluator computes a separate aggregate value - - -

for each complete RAR; the output is a list of tuples with region IDS and aggregate values, as expected.

For nested spatial aggregation, only the first of its two levels of aggregation can be performed in-network; the second level must currently be done a t the root. This is because we must wait until a RAR has been evaluated a t the end of the first level of aggregation, i.e. at the root, before it can be used as input for the second level of aggregation. The technique that we introduce in the next section allows us to perform the evaluation sooner, rather than waiting till the complete RAR reaches the root.

4 Region Leader Lists

Note that each RAR obtained during spatial aggregation only contains information for a small subset of the sen- sors, i.e. those sensors that are located in the correspond- ing region. If some subtree T of the routing tree contains no sensors within some region R, T's root will not receive any RARs for R. As a result, state records for in-network spatial aggregation are often ready to be evaluated long

Proceedings of the 22nd International Conference on Data Engineering (ICDE’06) 8-7695-2570-9/06 $20.00 © 2006 IEEE

before they reach the root of the routing tree. For exam- ple, if only one of the root's children has any descendants that lie in some region R, then the RAR for R is ready to be evaluated at that child, if not before.

We refer to RARs that are ready to be evaluated as complete. Note that whether a record is complete does not depend either on the aggregate function or on the sensor readings. It only depends on the topology of the sensor network, i.e. which nodes lie within which region.

Our technique for deciding when RARs are complete relies on associating each of the regions with a unique node in the routing tree, called its region leader. Like- wise, each of the nodes is associated with a leader list, a (possibly empty) list of regions for which it is the leader. We also assume that each RAR has a complete flag, to be marked complete when appropriate.

A node X may serve as the leader for a region R only if all sensors that lie within R axe descendants of X in the routing tree; i.e., X must be a common ancestor of all sensors that lie in R. It is easy to show that as a result

5 Three Scenarios

In this section, we discuss three scenarios where the tech- nique described above allows us to improve query process- ing, by pushing more computing into the network: nested aggregation, filtering predicates and data pruning.

(Re)evaluating nested aggregation

Region leader lists allow us to improve the evaluation of nested spatial aggregation, by modifying it in the follow- ing way:

1. As soon as an RAR from the first level of aggregation is marked complete, it is evaluated.

2. Immediately, this evaluated record is input to the initializer for the second level of aggregation, and a "2nd level" state record is created.

3. Whenever two or more 'L2nd level" records arrive at a sensor node, they are merged into a single "2nd level" aggregate record.

of this requirement, if X is region h d e r of R, then the As a Of this modification, the number of records to aggregation record for R is complete once it is processed be transmitted to the base station is By con- at X: trast, when region leader information is not available, all

RARs have to be transmitted to the root for evaluation. Proposition 4.1 Let q be a n R A R whose region ID is R, and let X be the region leader of R. Then, q is complete Filtering predicates at X, i.e, will no t be modified (by merging) by any of the ancestors of X . Often, predicates are applied to sensor readings and their

aggregates as part of query evaluation. In SQL queries, these predicates are specified in the where and having

Region leader lists allow us to know when an RAR is ,,lause of ,.he query [q, for example: complete without waiting for it to reach the root. An RAR is marked complete once it has been merged a t the SELECT avg(volume)

sensor node that is its region leader, before being trans- G R O U P BY region

mitted further up the tree. H A V I N G avg(vo1ume) > threshold

Once an RAR has been marked complete, it can be These predicates act as filters on records; records that evaluated right away (see step 3 of the in-network ag- do not satisfy the having constraint do not have to be gregation strategy in Sec. 3), increasing the amount of to the central processor- processing that can be done in-network. When the eval- When a filtering predicate applies to an aggregate

uation function decreases the size of the record, for ex- value, as in the example above, all r f ~ ~ r d s from the group

ample in the case of the AVG aggregation function, this have to be merged together before the predicate can be immediately results in communication savings. evaluated. (This requirement can be relaxed for special

predicates over monotonic aggregates such as described Additional efficiency can be realized by recognizing . that a complete RAR, evaluated or not, never needs to be

m [i'].) Up to now, this could only be ensured if the RAR

merged again on its way to the central processor. Thus, of a group has reached the root node.

if a node receives an RAR which is marked complete, this Now, we can apply the predicate as soon as an RAR has

record can be moved directly from the input buffer to the been evaluated, which may be long before it has reached the root. This reduces the amount of communication output buffer, with no need to pass it to the merge opera-

tion or store it in the CPU. This results in further energy needed for query execution. If the predicate is highly se-

savings. lective, the communication savings to the sensor network can be very significant.

The energy savings described above are relatively mi- nor. We have identified several other scenarios where re- Data Pruning gion leader information allows us to improve query pro- cessing more significantly, by pushing more computing In some sensor network databases, the data readings at into the network; they are discussed next. the sensors do not fluctuate much from epoch to epoch

Proceedings of the 22nd International Conference on Data Engineering (ICDE’06) 8-7695-2570-9/06 $20.00 © 2006 IEEE

(such as temperature). Aggregate values may fluctuate even less than the individual readings at sensors, as in the case of AVG. When a data record's values is the same, or close, to one for the previous time slot (epoch), we may want to avoid transmitting such records; we call this technique data pruning.

Some strategies for data pruning are delta gathering [4], TiNA [9], and duplicate suppression [6]. For example, in delta gathering, the new value are reported only if they represent LLcrossing a threshold" :

Delta-gathering. Let J be the set of threshold values, and x be the last transmitted sensor reading. If y is the current reading, it will be transmitted only if the interval (x; y] contains some value in J.

The idea for TiNA is similar. When the aggregate values are not evaluated until they

reach the root of the network, as is currently the case, none of the data pruning strategies can be applied. How- ever, in the case of spatial aggregation, region leader infor- mation allows us to evaluate RARs earlier, obtaining final aggregate values in-network. Data pruning strategies can then be applied to these values, reducing communication.

6 Discussion

Spatial aggregation is an important class of queries for geoawaxe spatial sensor database applications. Given a set of spatial regions, it involves the aggregation of dy- namic sensor readings over each of these regions simul- taneously. Nested spatial aggregation involves one more level of aggregation, combining these aggregates into a single aggregate value.

In this paper we have considered the problem of contin- uously evaluating spatial aggregation. We presented a a new technique that allows spatid aggregate values to be computed in-network, rather than waiting until the par- tial aggregate records reach the root as is now the case. This decreases the amount of communication involved in query evaluation, thereby reducing the network's power consumption. We also identified three scenarios, nested aggregation, filtering predicates, and data pruning, when the savings from our approach are expected to be partic- ularly great.

Our technique uses region leader lists to determine, during the bottom-up evaluation of aggregation records, when an aggregate record for any spatial region has fin- ished merging and is ready to be evaluated in-network. We do not assume that the regions are non-intersecting; a sensor may be located in more than one region simul- taneously. Also, when multiple spatial relations coexist over the same geographic domain, such as police and fire districts, our scenario allows continuous queries over them them to be processed simultaneously.

The computation and maintenance of region leader lists, and the experimental evaluation of our technique, can be found in out technical report [3]. There, two approaches are presented for computing the lists, exact (based on finding the least common ancestors) and ap- proximate (based on georouting [dl). Experimental results show that our approach can reduce in-network communi- cation during the computation of spatial aggregation by up to 16%, without any drop in accuracy.

References

[I] I. F. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cyirci. Wireless Sensor Networks: A Survey. Computer Networks, 38(4):393-422, 2002.

[2] P. Bonnet, J. E. Gehrke, and P. Seshadri. Towards sensor database systems. Proc. 2nd Int? Conf. on Mobile Data Mgmt. Hong Kong, Jan. 2001.

[3] D. Goldin. Fast in-network evaluation of spatial ag- gregation in sensor networks. UConn BECAT/CSE Technical Report, Nov 2005.

[4] D. Goldin, M. Song, A. Kutlu, H. Gao, and H. Dave. Georouting and deltacgathering: Efficient data prop- agation techniques for geosensor networks. GeoSen- sor Networks Workshop (GSN703), Portland, Maine, Oct 2003.

[5] J. Hellerstein, W. Hong, S. Madden, and K. Stanek. Beyond average: Towards sophisticated sensing with queries. 2nd Int? Workshop on Inf. Proc. in Sensor Networks (IPSN703), Mar 2003.

[6] C. Intanagonwiwat, R. Govindan, D. Estrin, J. Hei- demann, and F. Silva. Directed diffusion for wireless sensor networking. ACM/IEEE Trans. on Network- ing, 11(1):2-16, Feb 2002.

[7] S. Madden, M. Fkanklin, J. Hellerstein, and W. Hong. Tag: a tiny aggregation service for ad- hoc sensor networks. OSDI, Dec 2002.

[8] P. Rigaux, M. Scholl, and A. Voisard. Spatial Databases. Morgan Kaufrnann, 2001.

[9] M. Sharaf, J. Beaver, A. Labrinidis, and P. Chrysan- this. Tina: A scheme for temporal coherency-aware in-network aggregation. Proc. 3rd Int 'l A CM Work- shop on Data Engr. for Wireless and Mobile Access (MobiDE), San Diego, CA, Sep 2003.

[lo] M. Worboys. GIs: a Computing Perspective. Taylor & Francis, 1995.

[ l l ] Y. Yao and J. Gehrke. Query processing in sen- sor networks. Proc. 1st Biennial Conf. on Innova- tive Data Systems Research (CIDR 2003). Asilomar, California, Jan. 2003.

Proceedings of the 22nd International Conference on Data Engineering (ICDE’06) 8-7695-2570-9/06 $20.00 © 2006 IEEE