TAG: a Tiny AGgregation Service for Ad-Hoc Sensor Networksusers.eecs.northwestern.edu/~peters/references/TAGMadden02.pdf · Samuel Madden, Michael J. Franklin, and Joseph M. Hellerstein

Appearing in 5th Annual Symposium on Operating Systems Design and Implementation (OSDI). December, 2002. 1

TAG: a Tiny AGgregation Service for Ad-Hoc Sensor Networks�

Samuel Madden, Michael J. Franklin, and Joseph M. Hellerstein Wei Hong�madden,franklin,jmh � @cs.berkeley.edu [email protected]

UC Berkeley Intel Research, Berkeley

Abstract

We present the Tiny AGgregation (TAG) service for ag-gregation in low-power, distributed, wireless environ-ments. TAG allows users to express simple, declarativequeries and have them distributed and executed efficientlyin networks of low-power, wireless sensors. We discussvarious generic properties of aggregates, and show howthose properties affect the performance of our in networkapproach. We include a performance study demonstrat-ing the advantages of our approach over traditional cen-tralized, out-of-network methods, and discuss a variety ofoptimizations for improving the performance and fault-tolerance of the basic solution.

1 Introduction

Recent advances in computing technology have led to theproduction of a new class of computing device: the wire-less, battery powered, smart sensor [25]. These new sen-sors are active, full fledged computers, capable not only ofmeasuring real world phenomena but also filtering, shar-ing, and combining those measurements. One exampleof such small sensor devices are the motes under devel-opment at UC Berkeley. Current generation motes areroughly 2cm x 4cm x 1cm and are equipped with a radio,a processor, memory, a small battery pack, and a suite ofsensors. The mote operating system, TinyOS, provides aset of primitives designed to facilitate the deployment ofmotes in ad-hoc networks. In such networks, devices canidentify each other and route data without prior knowl-edge of or assumptions about the network topology, al-lowing the network topology to change as devices move,run out of power, or experience shifting waves of interfer-ence.

Due to the relative ease of deployment of mote-based sen-sor networks, practitioners in a variety of fields have be-gun considering them for a range of monitoring and datacollection tasks. For example: civil engineers are usingmotes to monitor building integrity during earthquakes

�This work has been partially supported by the NSF under grants

IIS-0086057 and SI0122599, and by research funds from IBM, Intel,Microsoft, and the UC Micro program.

[31]; biologists are planning mote deployments for habitatmonitoring[21, 5]; administrators of large computer clus-ters are interested in using motes to monitor the tempera-ture and power usage in their data centers.

All of these sensor applications depend on the ability toextract data from the network. Often, this data consists ofsummaries (or aggregations) rather than raw sensor read-ings. Other researchers have noted the importance of dataaggregation in sensor networks [13, 10, 12]. This previouswork has tended to view aggregation as an application-specific mechanism that would be programmed into thedevices on an as-needed basis, typically in error-prone,low-level languages like C. In contrast, our position is thatbecause aggregation is so central to emerging sensor net-work applications, it must be provided as a core serviceby the system software. Instead of a set of extensible CAPIs, we believe this service should consist of a generic,easily invoked high-level programming abstraction. Thisapproach enables users of sensor networks, who often arenot networking experts or even computer scientists, to fo-cus on their applications free from the idiosyncrasies ofthe underlying embedded OS and hardware.

1.1 The TAG Approach

We have developed Tiny AGgregation (TAG), a genericaggregation service for ad hoc networks of TinyOS motes.There are two essential attributes of this service. First, itprovides a simple, declarative interface for data collectionand aggregation, inspired by selection and aggregation fa-cilities in database query languages. Second, it intelli-gently distributes and executes aggregation queries in thesensor network in a time and power-efficient manner, andis sensitive to the resource constraints and lossy commu-nication properties of wireless sensor networks. TAG pro-cesses aggregates in the network by computing over thedata as it flows through the sensors, discarding irrelevantdata and combining relevant readings into more compactrecords when possible.

TAG operates as follows: users pose aggregation queriesfrom a powered, storage-rich basestation. Operators thatimplement the query are distributed into the network bypiggybacking on the existing ad hoc networking protocol.


Sensors route data back towards the user through a routingtree rooted at the basestation. As data flows up this tree,it is aggregated according to an aggregation function andvalue-based partitioning specified in the query. As an ex-ample, consider a query that counts the number of nodesin a network of indeterminate size. First, the request tocount is injected into the network. Then, each leaf node inthe tree reports a count of 1 to their parent; interior nodessum the count of their children, add 1 to it, and report thatvalue to their parent. Counts propagate up the tree in thismanner, and flow out at the root.

1.2 Overview of the Paper

The contributions of this paper are four-fold: first, we pro-pose a simple, SQL-like declarative language for express-ing aggregation queries over streaming sensor data andidentify key properties of aggregation functions that affectthe extent to which they can be efficiently processed insidethe network. Second, we demonstrate how such in net-work execution can yield an order of magnitude reductionin communication compared to centralized approaches.Third, we show that by adopting a well-defined, declar-ative query language as a level of abstraction betweenthe user and specific networking and routing protocols,a number of optimizations can be transparently applied tofurther reduce the data demands on the system. Finally,we show that our focus on a high-level language leads touseful end-to-end techniques for reducing the effects ofnetwork loss on aggregate results.

The remainder of the paper is structured as follows. Inthe next section, we briefly review the TinyOS hardwareand software environment. Then, we discuss the syntaxand semantics of queries in TAG and classify the types ofaggregates supported by the system, focusing on the char-acteristics of aggregates that impact their performance andfault tolerance. We then present the core TAG algorithmand show how our solution satisfies the query require-ments while providing performance and tolerance to net-work faults. We discuss several optimizations for improv-ing the performance of the basic approach. Additionally,we include experimental results demonstrating the effec-tiveness and robustness of our algorithms in a simulationenvironment, as well as a brief study of a real-world de-ployment on TinyOS motes. Finally, we discuss relatedwork and conclude.

2 Motes and Ad-Hoc NetworksIn this section, we provide a brief overview of the motehardware architecture, the TinyOS system, and an ad hocrouting algorithm for mote-based sensor networks.

2.1 Motes

Current generation TinyOS motes are equipped with a4Mhz Atmel microprocessor with 4 kB of RAM and 128kB of code space, a 917 MHz RFM radio running at 50kb/s, and 512kB of EEPROM. An expansion slot accom-modates a variety of sensor boards by exposing a numberof analog input lines as well as popular chip-to-chip serialbusses. Current sensor options include: light, tempera-ture, magnetic field, acceleration, sound, and power.

The single-channel radio is half duplex, meaning motescannot send and receive at the same time. Currently, thedefault TinyOS implementation uses a CSMA-like mediaaccess protocol with a random backoff scheme. Messagedelivery is unreliable by default, though applications canbuild up an acknowledgment layer. Often, a message ac-knowledgment can be obtained for free (see Section 2.2).

Power is supplied via an AA battery pack or a coin-cellattached through the expansion slot. The effective life-time of the device is determined by this power supply. Inturn, the power consumption of each sensor node tendsto be dominated by the cost of transmitting and receivingmessages. In terms of power consumption, transmitting asingle bit of data is equivalent to 800 instructions. Thisenergy tradeoff between communication and computationimplies that many applications will benefit by processingthe data inside the network rather than simply transmittingthe sensor readings. An AA battery pack will allow a moteto send 5.52 million messages (if it does no other compu-tation and only powers its radio up to transmit) which isequivalent to one message per second every day for abouttwo months – not long if the goal is to deploy long lived,zero-maintenance ad-hoc sensor networks. Hence, power-conserving algorithms are particularly important. 1 As wewill discuss in Section 4.1 , our design is amenable to verylow power modes in which the radio is kept powered downfor long periods of time.

To understand how data is routed in our ad-hoc aggrega-tion network, two properties of radio communication needto be emphasized. First, radio is a broadcast medium sothat any mote within hearing distance hears a message,irrespective of whether or not that mote is the intended re-cipient. Second, we only make use of symmetric links(where if mote � can hear mote

�,

�can also hear � .)

As is common in ad-hoc protocols, asymmetric links aredetected and blacklisted using a technique similar to thatproposed in AODV [24].

Messages in the current generation of TinyOS are a fixed

1Note that as sensor devices become more integrated, it is expectedthat the ratio of communication to computation costs will get more im-portant over time as silicon efficiency increases while the physical costsof pushing radio waves over the air remain constant.


size – by default, 30 bytes. Each device has a uniquesensor ID that distinguishes it from others. All messagesspecify their recipient (or specify broadcast, meaning allavailable recipients), allowing motes to ignore messagesnot intended for them, although non-broadcast messagesare received by all motes within range – unintended recip-ients simply drop messages not addressed to them.

2.2 Ad-Hoc Routing AlgorithmGiven this overview of the mote environment, we now dis-cuss how sensor devices route data. One common tech-nique, which we sketch here, is to build a routing tree.We omit some details of this approach due to space con-straints – a number routing protocols suitable for thispurpose have been proposed; the reader is referred to[32, 13, 12, 14, 1] for more information. In general, TAGis agnostic to the choice of routing algorithm, requiringit to provide just two capabilities. First, it must be ableto deliver query requests to all nodes in a network.2 Sec-ond, it must be able to provide one or more routes fromevery node to the root of the network where aggregationdata is being collected. These routes must guarantee thatat most one copy of every message arrive (no duplicatesare generated).

In the tree-based routing scheme, one mote is appointed tobe the root, usually because it is the point where the userinterfaces to the network. The root broadcasts a messageasking motes to organize into a routing tree; in that mes-sage it specifies its own id and its level, or distance fromthe root (in this case, zero.) Any mote without an assignedlevel that hears this message assigns its own level to be thelevel in the message plus one. It also chooses the senderof the message as its parent, through which it will routemessages to the root.

Each of these motes then rebroadcasts the routing mes-sage, inserting their own ids and levels. The routing mes-sage floods down the tree in this fashion, with each noderebroadcasting the message until all nodes have been as-signed a level and a parent. These routing messages areperiodically broadcast from the root, so that the processof topology discovery goes on continuously. This constanttopology maintenance makes it relatively easy to adapt tonetwork changes caused by mobility of certain nodes, orto the addition or deletion of motes. We describe a specifictopology maintenance protocol used for our experimentson loss in Section 7.1 below. To maintain stability in thenetwork, parents are retained unless a child does not hearfrom them for some long period of time, at which point it

2Note that, as an optimization, it may be useful for the routing layerto limit the extent to which queries are propagated based on properties ofthe query – for example, a short-lived query over constrained geographicarea need not be sent to motes far away from that area. We reserve suchoptimizations for future work.

selects a new parent using this same process. We look inmore detail at the robustness of this approach with respectto loss and its effect on aggregate values in Section 7.

When a mote wishes to send a message to the root, itbroadcasts a message addressed to its parent, which inturn forwards the message on to its parent, and so on,eventually reaching the root. In Section 4, we show how,as data is routed towards the root, it can be combined withdata from other motes to efficiently combine routing andaggregation. Now, however, we turn to the syntax and se-mantics of aggregate queries in TAG.

3 Query Model and Environment

Given our goal of allowing users to pose declarativequeries over sensor networks, we needed a language forexpressing such queries. Rather than inventing our own,we chose to adopt a SQL-style query syntax. We sup-port SQL-style queries (without joins) over a single ta-ble called sensors, whose schema is known at the basestation. As is the case in Cougar [23], this table can bethought of as an append-only relational table with one at-tribute per input of the motes (e.g., temperature, light.)In TAG, we focus on the problem of aggregate sensorreadings, though facilities for collecting individual sensorreadings also exist.

Before describing the semantics of queries in general, webegin with an example query. Consider a user who wishesto monitor the occupancy of the conference rooms on aparticular floor of a building, which she chooses to do byusing microphone sensors attached to motes, and lookingfor rooms where the average volume is over some thresh-old (assuming that rooms can have multiple sensors). Herquery could be expressed as:

SELECT AVG(volume),room FROM sensorsWHERE floor = 6GROUP BY roomHAVING AVG(volume) > thresholdEPOCH DURATION 30s

This query partitions motes on the 6th floor accordingto the room in which they are located (which may be ahard-coded constant in each device, or may be determinedvia some localization component available to the devices.)The query then reports all rooms where the average vol-ume is over a specified threshold. Updates are deliveredevery 30 seconds, although the user may deregister herquery at any time.

In general, queries in TAG have the form:SELECT �� ( �� ), attrs FROM sensorsWHERE � selPreds GROUP BY � attrs HAVING � havingPreds EPOCH DURATION �

With the exception of the EPOCH DURATION clause, thesemantics of this statement are similar to SQL aggregate


queries. The SELECT clause specifies an arbitrary arith-metic expression over one or more aggregation attributes.We expect that the common case here is that �� willsimply be the name of a single attribute. Attrs (option-ally) selects the attributes by which the sensor readings arepartitioned ; these can be any subset of attrs that appearin the GROUP BY clause. The syntax of the �� clauseis discussed below; note that multiple aggreggates maybe computed in a single query. The WHERE clause filtersout individual sensor readings before they are aggregated.Such predicates can typically be executed locally at themote before readings are communicated, as in [23, 18].The GROUP BY clause specifies an attribute based par-titioning of sensor readings. Logically, each reading be-longs to exactly one group, and the evaluation of the queryis a table of group identifiers and aggregate values. TheHAVING clause filters that table by suppressing groupsthat do not satisfy the havingPreds predicates.

The primary semantic difference between TAG queriesand SQL queries is that the output of a TAG query is astream of values, rather than a single aggregate value (orbatched result). In monitoring applications, such contin-uous results are often more useful than a single, isolatedaggregate, as they allow users to understand how the net-work is behaving over time and observe transient effects(such as message losses) that make individual results,taken in isolation, hard to interpret. In these stream se-mantics, each record consists of one group id,aggregatevalue � pair per group. Each group is time-stamped andthe readings used to compute an aggregate record all be-long to the same time interval, or epoch. The durationof each epoch is the argument of the EPOCH DURATIONclause, which specifies the amount of time (in seconds)devices wait before acquiring and transmitting each suc-cessive sample. This value may be as large as the userdesires; it must be at least as long as the time it takesfor a mote to process and transmit a single radio messageand do some local processing – about 30 ms (includingaverage MAC backoff in a low-contention environment)for current generation motes (yielding a maximum sam-ple rate of about 33 samples per second.) In section 4.1,we discuss situations that require longer lower bounds onepoch duration.

3.1 Structure of Aggregates

The problem of computing aggregate queries in large clus-ters of nodes has been addressed in the context of shared-nothing parallel query processing environments [26]. Likesensor networks, those environments require the coordina-tion of a large number of nodes to process aggregations.Thus, while the severe bandwidth limitations, lossy com-munications, and variable topology of sensor networks

mean that the specific implementation techniques used inthe two environments must differ, it is still useful to lever-age the techniques for aggregate decomposition used indatabase systems [2, 35].

The approach used in such systems (and followed inTAG) is to implement �� via three functions: a mergingfunction � , an initializer , and an evaluator, � .In general, � has the following structure:

�� !where "�#� and "$%� are multi-valued partial staterecords, computed over one or more sensor values, repre-senting the intermediate state over those values that willbe required to compute an aggregate. %&�� is the partial-state record resulting from the application of function �to '�(� and '$)� . For example, if � is the merg-ing function for AVERAGE, each partial state record willconsist of a pair of values: SUM and COUNT, and � is spec-ified as follows, given two state records +*-,/.102,�� and3*546.70849� :

��;:=<>�@?�<A��B�C:DE�@?5D8��!��8�C:=<GF�:�DH�I?�<GF�?5DJ�The initializer is needed to specify how to instantiate astate record for a single sensor value; for an AVERAGEover a sensor value of � , the initializer 7K��ML returns thetuple N��.HOP� . Finally, the evaluator � takes a partialstate record and computes the actual value of the aggre-gate. For AVERAGE, the evaluator �QKRS*A.70T� L simplyreturns *VU60 .

These three functions can easily be derived for the basicSQL aggregates; in general, any operation that can be ex-pressed as commutative applications of a binary functionis expressible.

3.2 Taxonomy of Aggregates

Given our basic syntax and structure of aggregates, anobvious question remains: what aggregate functions canbe expressed in TAG? The original SQL specificationoffers just five options: COUNT, MIN, MAX, SUM, andAVERAGE. Although these basic functions are suitable fora wide range of database applications, we did not wish toconstrain TAG to only these choices. For this reason, wepresent a general classification of aggregate functions andshow how the dimensions of that classification affect theperformance of TAG throughout the paper. We will as-sume that when aggregation functions are registered withTAG, they are classified along the dimensions describedbelow.3

3We omit a detailed discussion of how new aggregate functionsare registered with motes. For now, aggregates are pre-compiled intomotes. Virtual-machine languages recently proposed for TinyOS-style[16] motes could also be used for this purpose.


MAX, MIN COUNT, SUM AVERAGE MEDIAN COUNT DISTINCT 4 HISTOGRAM 5 Section

Duplicate Sensitive No Yes Yes Yes No Yes Section 7.5Exemplary (E), Summary (S) E S S E S S Section 6.2Monotonic Yes Yes No No Yes No Section 4.2Partial State Distributive Distributive Algebraic Holistic Unique Content-Sensitive Section 5.1

Table 1: Classes of aggregates

We classify aggregates according to four properties thatare particularly important to sensor networks. Table 1shows how specific aggregation functions can be classi-fied according to these properties, and indicates the sec-tions of the paper where the various dimensions of theclassification are emphasized.

The first dimension is duplicate sensitivity. Duplicate in-sensitive aggregates are unaffected by duplicate readingsfrom a single device while duplicate sensitive aggregateswill change when a duplicate reading is reported. Dupli-cate sensitivity implies restrictions on network propertiesand on certain optimizations, as described in Section 7.5.

Second, exemplary aggregates return one or more repre-sentative values from the set of all values; summary ag-gregates compute some property over all values. Thisdistinction is important because exemplary aggregates be-have unpredictably in the face of loss, and, for the samereason, are not amenable to sampling. Conversely, forsummary aggregates, the aggregate applied to a subset canbe treated as a robust approximation of the true aggregatevalue, assuming that either the subset is chosen randomly,or that the correlations in the subset can be accounted forin the approximation logic.

Third, monotonic aggregates have the property that whentwo partial state records, � , and � 4 , are combined via� , the resulting state record �

�will have the prop-

erty that either� � , .�� 4 .1�K�� L�� K��QK�� , L>.1�K�� 4 LBL or� �/,�. �E4�.��QK�� L�� K �QK��/, L .��QK��4EL�L . This is impor-

tant when determining whether some predicates (such asHAVING) can be applied in network, before the final valueof the aggregate is known. Early predicate evaluationsaves messages by reducing the distance that partial staterecords must flow up the aggregation tree.

The fourth dimension relates to the amount of state re-quired for each partial state record. For example, a partialAVERAGE record consists of a pair of values, while a par-tial COUNT record constitutes only a single value. ThoughTAG correctly computes any aggregate that conforms tothe specification of � in Section 3 above, its performanceis inversely related to the amount of intermediate state re-quired per aggregate. The first three categories of this di-mension (e.g. distributive, algebraic, holistic) were ini-tially presented in work on data-cubes [9].� In Distributive aggregates, the partial state is simplythe aggregate for the partition of data over which theyare computed. Hence the size of the partial state records

is the same as the size of the final aggregate.� In Algebraic aggregates, the partial state records arenot themselves aggregates for the partitions, but are ofconstant size.� In Holistic aggregates, the partial state records are pro-portional in size to the set of data in the partition. Inessence, for holistic aggregates no useful partial aggre-gation can be done, and all the data must be broughttogether to be aggregated by the evaluator.� Unique aggregates are similar to holistic aggregates,except that the amount of state that must be propagatedis proportional to the number of distinct values in thepartition.� In Content-Sensitive aggregates, the partial staterecords are proportional in size to some (perhaps sta-tistical) property of the data values in the partition.Many approximate aggregates proposed recently inthe database literature are content-sensitive. Exam-ples of such aggregates include fixed-width histograms,wavelets, and so on; see [3] for an overview of suchfunctions.

In summary, we have classified aggregates according totheir state requirements, tolerance of loss, duplicate sen-sitivity, and monotonicity. We will refer back to this clas-sification throughout the text, as these properties will de-termine the applicability of communication optimizationswe present later. Understanding how aggregates fit intothese categories is a cross-cutting issue that is critical (anduseful) in many aspects of sensor data collection.

Note that our formulation of aggregate functions, com-bined with this taxonomy, is flexible enough to encompassa wide range of sophisticated operations. For example, wehave implemented (in the simulator described in Section5 below), an isobar finding aggregate. This is a duplicate-insensitive, summary, monotonic, content-sensitive aggre-gate that builds a topological map representing discretebands of one attribute (light, for example) plotted againsttwo other attributes (x and y position in some local coor-dinate space, for example.)

4The HISTOGRAM aggregate sorts sensor readings into fixed-widthbuckets and returns the size of each bucket; it is content-sensitive be-cause the number of buckets varies depending on how widely spacedsensor readings are.

5COUNT DISTINCT returns the number of distinct values reportedacross all motes.


3.3 Attribute Catalog

Queries in TAG contain named attributes. Some mecha-nism is needed to allow users to determine the set of at-tributes they may query, and to allow motes to advertisethe attributes they can provide. In TAG, we include oneach mote a small catalog of attributes. This catalog canbe searched for attributes of a specific name, or iteratedthrough. To limit the burden of reporting catalog informa-tion from motes, we assume the central query processorcaches or stores the attributes of all motes it may access.

When a TAG sensor receives a query, it converts namedfields into local catalog identifiers. Nodes lacking at-tributes specified in the query simply tag missing at-tributes as NULL in their result records (alternatively, thequery could specify that the lacking node should opt outof the query.) This technique increases the scalability oflarge sensor network deployments as it does not requireall nodes to have global knowledge of all attributes.

As in relational databases, partial state records result-ing from the evaluation of a query have the same layoutacross all nodes. Thus, tuples in TAG need not be self-describing; attribute names are not carried with results,leading to a significant reduction in the amount of data thatmust be propagated with each tuple. At the same time, itis not necessary for all nodes to have identical catalogs,which allows heterogeneous sensing capabilities and in-cremental deployment of motes.

Attributes in TAG may be direct representations of sen-sor values, such as light or temperature, or may be in-trospective, such as remaining energy or network neigh-borhood information. More generally, they can representtime-varying statistics over local sensor values, such as anexponentially decaying average of the last � light read-ings, or more complicated attributes such as a room num-ber, GPS coordinate, or relative distance to some neighborfrom a localization component. Individual software com-ponents in TinyOS choose which attributes they will makeavailable, and provide an accessor function for acquiringthe next attribute reading.

4 In Network Aggregates

Given the simple routing protocol from Section 2.2 andour query model, we now discuss the implementation ofthe core TAG algorithm for in network aggregation.

A naive implementation of sensor network aggregationwould be to use a centralized, server-based approachwhere all sensor readings are sent to the base station,which then computes the aggregates. In TAG, however,we compute aggregates in network whenever possible,because, if properly implemented, this approach can be

lower in number of message transmissions, latency, andpower consumption than the server-based approach. Wewill measure the advantage of in network aggregation inSection 5 below; first, we present the basic algorithm indetail. We first consider the operation of the basic ap-proach in the absence of grouping; we show how to extendit with grouping in Section 4.2.

4.1 Tiny Aggregation

TAG consists of two phases: a distribution phase, in whichaggregate queries are pushed down into the network, anda collection phase, where the aggregate values are contin-ually routed up from children to parents. Recall that ourquery semantics partition time into epochs of duration ,and that we must produce a single aggregate value (whennot grouping) that combines the readings of all devices inthe network during that epoch.

Given our goal of using as few messages as possible, thecollection phase must ensure that parents in the routingtree wait until they have heard from their children be-fore propagating an aggregate value for the current epoch.We will accomplish this by having parents subdivide theepoch such that children are required to deliver their par-tial state records during a parent-specified time interval.This interval is selected such that there is enough time forthe parent to combine partial state records and propagateits own record to its parent.

When a mote � receives a request to aggregate, � , eitherfrom another mote or from the user, it awakens, synchro-nizes its clock according to timing information in the mes-sage, and prepares to participate in aggregation. In the treebased routing scheme, � chooses the sender of the mes-sage as its parent. In addition to the information in thequery, � includes the interval when the sender is expect-ing to hear partial state records from � . � then forwardsthe query request � down the network, setting this deliveryinterval for children to be slightly before the time its par-ent expects to see � ’s partial state record. In the tree-basedapproach, this forwarding consists of a broadcast of � , toinclude any nodes that did not hear the previous round,and include them as children (if it has any.) These nodescontinue to forward the request in this manner, until thequery has been propagated throughout the network.

During the epoch after query propagation, each mote lis-tens for messages from its children during the interval itspecified when forwarding the query. It then computes apartial state record consisting of the combination of anychild values it heard with its own local sensor readings.Finally, during the transmission interval requested by itsparent, the mote transmits this partial state record up thenetwork. Figure 1 illustrates the process. Notice that par-ents listen for longer than the transmission interval they


Level 1

Level 2

Level 3

Level 4

Level 5

Time

TreeDepth

Sensing and Processing,Radio IdleDelivery Interval(Transmitting)

Listening/Receiving

Radio and Processor Idle

End ofEpoch

Start ofEpoch

Root

Figure 1: Partial state records flowing up the tree duringan epoch.

specified, to overcome limitations in the quality of clocksynchronization algorithms between parents and children.In this way, aggregates flow back up the tree interval-by-interval. Eventually, a complete aggregate arrives at theroot. During each subsequent epoch, a new aggregate isproduced. Notice that, for a significant portion of eachepoch, motes are idle and can enter a low power state.

This scheme begs the question of how parents choose theduration of the interval in which they will receive values.It needs to be long enough such that all of a node’s chil-dren can report, but not so long that the epoch ends be-fore nodes deep in the tree can schedule their communi-cation. Furthermore, longer intervals require radios to bepowered up for more time, which consumes precious en-ergy. In general, the proper choice of duration for theseintervals is somewhat environment specific, as it dependson the density of radio cells and “bushiness” of the net-work topology. For the purposes of the simulations andexperiments in this paper, we assume the network has amaximum depth

�, and set the duration of each interval

to be (EPOCH DURATION)/�, with nodes at level trans-

mitting during the �� interval. We rely on the TinyOSMAC layer [32] to avoid collisions between nodes trans-mitting during the same interval. Note that this providesa lower-bound on the EPOCH DURATION and constrainsthe maximum sample rate of the network, since the epochmust be long enough for partial state records from the bot-tom of the tree to propagate to the root.

To increase the sample rate, one could consider pipeliningthe communications schedule shown in Figure 1. Withpipelining, the output of the network would be delayed byone or more epochs, as some nodes would wait until thenext epoch to report the aggregates they collected duringthe current epoch. In exchange for such delays, the effec-tive sample rate of the system is increased (for the samereason that pipelining a long processor stage increases theclock rate of a CPU.) We do not consider such schemes

in detail here; we discussed a fully-pipelined approach toaggregation in a workshop submission [20].

In Section 5.1 we show how TAG can provide an orderof magnitude decrease in communications costs over acentralized approach. However, before discussing perfor-mance, we extend the approach to support grouping.

4.2 Grouping

Grouping in TAG is functionally equivalent to theGROUP BY clause in SQL: each sensor reading is placedinto exactly one group, and groups are partitioned accord-ing to an expression over one or more attributes. The basicgrouping technique is to push the expression down withthe query, ask nodes to choose the group they belong to,and then, as answers flow back, update aggregate valuesin the appropriate groups.

Partial state records are aggregated just as in the approachdescribed above, except that those records are now taggedwith a group id. When a node is a leaf, it applies thegrouping expression to compute a group id. It then tagsits partial state record with the group and forwards it onto its parent. When a node receives an aggregate from achild, it checks the group id. If the child is in the samegroup as the node, it combines the two values using thecombining function � . If it is in a different group, it storesthe value of the child’s group along with its own value forforwarding in the next epoch. If another child messagearrives with a value in either group, the node updates theappropriate aggregate. During the next epoch, the nodesends the value of all the groups about which it collectedinformation during the previous epoch, combining infor-mation about multiple groups into a single message aslong as message size permits. Figure 2 shows an exampleof computing a query grouped by temperature that selectsaverage light readings.

Recall that queries may contain a HAVING clause, whichconstrains the set of groups in the final query result. Thispredicate can sometimes be passed into the network along

Group AVG

Group AVG

Group AVG

Temp: 20Light: 10

Temp: 20Light: 50

Temp: 10Light: 15

Temp: 30Light: 25

Temp: 10Light: 15

Temp: 10Light: 5

1

2

3

4

5

6

1

2

3

4

5

6

AggregateAVG(light)

Groups1 : 0 < temp 102 : 10 < temp 203 : 20 < temp 30 1 10

13

1025

Group AVG123

105025

123

103025

(6,5,2)(3,1)(4)

(6,5)(4)

(6,5)

SELECT AVG(light),temp/10FROM sensorsGROUP BY temp/10

Figure 2: A sensor network (left) with an in network,grouped aggregate applied to it (right). Parenthesizednumbers represent nodes that contribute to the average


with the grouping expression. The predicate is only sentif it can potentially be used to reduce the number of mes-sages that must be sent: for example, if the predicate isof the form MAX(attr) x, then information aboutgroups with MAX(attr) � x need not be transmittedup the tree, and so the predicate is sent down into the net-work. When a node detects that a group does not satisfy aHAVING clause, it can notify other nodes in the networkof this information to suppress transmission and storageof values from that group. Note that HAVING clausescan be pushed down only for monotonic aggregates; non-monotonic aggregates are not amenable to this technique.However, not all HAVING predicates on monotonic aggre-gates can be pushed down; for example, MAX(attr) �x cannot be applied in the network because a node cannotknow that, just because its local value of � � �I� is less than� , the MAX over the entire group is less than � .

Grouping introduces an additional problem: the numberof groups can exceed available storage on any one (non-leaf) device. Our proposed solution is to evict one or moregroups from local storage. Once an eviction victim is se-lected, it is forwarded to the node’s parent, which maychoose to hold on to the group or continue to forwardit up the tree. Notice that a single node may evict sev-eral groups in a single epoch (or the same group multipletimes, if a bad victim is selected). This is because, oncegroup storage is full, if only one group is evicted at a time,a new eviction decision must be made every time a valuerepresenting an unknown or previously evicted group ar-rives. Because groups can be evicted, the base station atthe top of the network may be called upon to combine par-tial groups to form an accurate aggregate value. Evictingpartially computed groups is known as partial preaggre-gation, as described in [15].

Thus, we have shown how to partition sensor readingsinto a number of groups and properly compute aggregatesover those groups, even when the amount of group infor-mation exceeds available storage in any one device. Wewill briefly mention experiments with grouping and groupeviction policies in Section 5.2. First, we summarize someof the additional benefits of TAG.

4.3 Additional Advantages of TAG

The principal advantage of TAG is its ability to dramat-ically decrease the communication required to computean aggregate versus a centralized aggregation approach.However, TAG has a number of additional benefits.

One of these is its ability to tolerate disconnections andloss. In sensor environments, it is very likely that someaggregation requests or partial state records will be gar-bled, or that devices will move or run out of power. These

losses will invariably result in some nodes becoming lost,either without a parent or not incorporated into the aggre-gation network during the initial flooding phase. If weinclude information about queries in partial state records,lost nodes can reconnect by listening to other node’s staterecords – not necessarily intended for them – as they flowup the tree. We revisit the issue of loss in Section 7.

A second advantage of the TAG approach is that, in mostcases, each mote is required to transmit only a single mes-sage per epoch, regardless of its depth in the routing tree.In the centralized (non TAG) case, as data converges to-wards the root, nodes at the top of the tree are required totransmit significantly more data than nodes at the leaves;their batteries are drained faster and the lifetime of thenetwork is limited. Furthermore, because the top of therouting tree must forward messages for every node in thenetwork, the maximum sample rate of the system is in-versely proportional to the total number of nodes. To seethis, consider a radio channel with a capacity of � mes-sages per second. If � motes are participating in a cen-tralized aggregate, to obtain a sample rate of

�samples

per second, ��

messages must flow through the rootduring each epoch. ��

�must be no larger than � , so

the sample rate�

can be at most ��U � messages per moteper epoch, regardless of the network density. When usingTAG, the maximum transmission rate is limited insteadby the occupancy of the largest radio-cell; in general, weexpect that each cell will contain far fewer than � motes.

Yet another advantage of TAG is that, by explicitly divid-ing time into epochs, a convenient mechanism for idlingthe processor is obtained. The long idle times in Figure 1show how this is possible; during these intervals, the radioand processor can be put into deep sleep modes that usevery little power. Of course, some bootstrapping phaseis needed where motes can learn about queries currentlyin the system, acquire a parent, and synchronize clocks;a simple strategy involves requiring that every node wakeup infrequently but periodically to advertise this informa-tion and that devices that have not received advertisementsfrom their neighbors listen for several times this periodbetween sleep intervals. Research on energy aware MACprotocols [34] presents a similar scheme in detail. Thatwork also discusses issues such as time synchronizationresolution and the maximum sleep duration to avoid theadverse effects of clock skew on individual devices.

Taken as a whole, these TAG features provide users with astream of aggregate values that changes as sensor readingsand the underlying network change. These readings areprovided in an energy and bandwidth efficient manner.


5 Simulation-Based Evaluation

In this section, we present a simulation environment forTAG and evaluate its behavior using this simulator. Wealso have an initial, real-world deployment; we discuss itsperformance at the end of the paper, in Section 8.

To study the algorithms presented in this paper, we simu-lated TAG in Java. The simulator models mote behavior ata coarse level: time is divided into units of epochs, mes-sages are encapsulated into Java objects that are passeddirectly into nodes without any model of the time to sendor decode. Nodes are allowed to compute or transmit ar-bitrarily within a single epoch, and each node executesserially. Messages sent by all nodes during one epoch aredelivered in random order during the next epoch to modela parallel execution. Note that this simulator cannot ac-count for certain low-level properties of the network: forexample, because there is no fine-grained model of time,it is not possible to model radio contention at a byte level.

Our simulation includes an interchangeable communica-tion model that defines connectivity based on geographicdistance. Figure 3 shows screenshots of a visualizationcomponent of our simulation; each square represents asingle device, and shading (in these images) represents thenumber of radio hops the device is from the root (center);darker is closer. We measure the size of networks in termsof diameter, or width of the sensor grid (in nodes). Thus,a diameter 50 network contains 2500 devices.

We have run experiments with three communicationsmodels; 1) a simple model, where nodes have perfect(lossless) communication with their immediate neighbors,which are regularly placed (Figure 3(a)), 2) a randomplacement model (Figure 3(b)), and 3) a realistic modelthat attempts to capture the actual behavior of the radioand link layer on TinyOS motes (Figure 3(c).) In this lastmodel, notice that the number of hops from a particularnode to the root is no longer directly proportional to thegeographic distance between the node and the root, al-though the two values are still related. This model usesresults from real world experiments [7] to approximate theactual loss characteristics of the TinyOS radio. Loss ratesare high in in the realistic model: a pair of adjacent nodesloses more than 20% of the traffic between them. Devicesseparated by larger distances lose still more traffic.

The simulator also models the costs of topology mainte-nance: if a node does not transmit a reading for severalepochs (which will be the case in some of our optimiza-tions below), that node must periodically send a heartbeatto advertise that it is still alive, so that its parents and chil-dren know to keep routing data through it. The intervalbetween heartbeats can be chosen arbitrarily; choosing alonger interval means fewer messages must be sent, but

(a) Simple (b) Random (c) Realistic

Figure 3: The TAG Simulator, with Three Different Com-munications Models, Diameter = 20.

requires nodes to wait longer before deciding that a par-ent or child has disconnected, making the network lessadaptable to rapid change.

This simulation allows us to measure the the number ofbytes, messages, and partial state records sent over theradio by each mote. Since we do not simulate the moteCPU, it does not give us an accurate measurement of thenumber of instructions executed in each mote. It does,however, allow us to obtain an approximate measure ofthe state required for various algorithms, based on the sizeof the data structures allocated by each mote.

Unless otherwise specified, our experiments are over thesimple radio topology in which there is no loss. We alsoassume sensor values do not change over the course of asingle simulation run.

5.1 Performance of TAG

In the first set of experiments, we compare the perfor-mance of the TAG in network approach to centralized ap-proaches on queries for the different classes of aggregatesdiscussed in Section 3.2. Centralized aggregates have thesame communications cost irrespective of the aggregatefunction, since all data must be routed to the root. For thisexperiment, we compared this cost to the number of bytesrequired for distributive aggregates (MAX and COUNT),an algebraic aggregate (AVERAGE), a holistic aggregate(MEDIAN), a content-sensitive aggregate (HISTOGRAM),and a unique aggregate (COUNT DISTINCT); the resultsare shown in Figure 4.

Values in this experiment represent the steady-state costto extract an additional aggregate from the network oncethe query has been propagated; the cost to flood a requestdown the tree in not considered.

In our 2500 node (��

) network, MAX and COUNThave the same cost when processed in the network, about5000 bytes per epoch (total over all nodes), since they bothsend just a single integer per partial state record; similarlyAVERAGE requires just two integers, and thus always hasdouble the cost of the distributive aggregates. MEDIANcosts the same as a centralized aggregate, about 90000bytes per epoch, which is significantly more expensive


CO

UN

T

MIN

HIS

TO

GR

AM

AV

ER

AG

E

CO

UN

T D

IST

INC

T

ME

DIA

N

Cen

tral

ized

(no

t TA

G)

Aggregation Function

0

20000

40000

60000

80000

Byt

es T

rans

mitt

ed /

Epo

ch, A

ll Se

nsor

sTAG (In Network)Any Centralized Aggregate

In-network vs. Centralized AggregationNetwork Diameter = 50, No Loss

Figure 4: In network Vs. Centralized Aggregates

than other aggregates, especially for larger networks, asparents have to forward all of their children’s values to theroot. COUNT DISTINCT is only slightly less expensive(73000 bytes), as there are few duplicate sensor values;a less uniform sensor-value distribution would reduce thecost of this aggregate. For the HISTOGRAM aggregate,we set the size of the fixed-width buckets to be 10; sensorvalues ranged over the interval [0..1000]. At about 9000messages per epoch, HISTOGRAM provides an efficientmeans for extracting a density summary of readings fromthe network.

Note that the benefit of TAG will be more or less pro-nounced depending on the topology. In a flat, single-hopenvironment, where all motes are directly connected to theroot, TAG is no better than the centralized approach. Fora topology where � motes are arranged in a line, central-ized aggregates will require �

4 U�� partial state records tobe transmitted, whereas TAG will require only � records.

Thus, we have shown that, for our simulation topology, innetwork aggregation can reduce communication costs byan order of magnitude over centralized approaches, andthat, even in the worst case (such as with MEDIAN), itprovides performance equal to the centralized approach.

5.2 Grouping Experiments

We also ran several experiments to measure the perfor-mance of grouping in TAG, focusing on the behavior ofvarious eviction techniques. We tried a number of simpleeviction policies, but found that the choice of policy madelittle difference for any of the sensor-value distributionswe tested – in the most extreme case, the difference be-tween the best and worst case eviction policy accountedfor less than 10% of the total messages. Due to the rel-ative insignificance of these results and space limitations,

we omit a detailed discussion of the merits of various evic-tion policies.

6 Optimizations

In this section, we present several techniques to improvethe performance and accuracy of the basic approach de-scribed above. Some of these techniques are function de-pendent; that is, they can only be used for certain classesof aggregates. Also note that, in general, these techniquescan be applied in a user-transparent fashion, since they arenot explicitly a part of the query syntax and do not affectthe semantics of the results.

6.1 Taking Advantage of A Shared Channel

In our discussion of aggregation algorithms up to thispoint, we have largely ignored the fact that motes com-municate over a shared radio channel. The fact that everymessage is effectively broadcast to all other nodes withinrange enables a number of optimizations that can signifi-cantly reduce the number of messages transmitted and in-crease the accuracy of aggregates in the face of transmis-sion failures.

In Section 4.3, we saw an example of how a shared chan-nel can be used to increase message efficiency when anode misses an initial request to begin aggregation: it caninitiate aggregation even after missing the start request bysnooping on the network traffic of nearby nodes. When ithears another device reporting an aggregate, it can assumeit too should be aggregating. By allowing nodes to exam-ine messages not directly addressed to them, motes areautomatically integrated into the aggregation. Note thatsnooping does not require nodes to listen all the time; bylistening at predefined intervals (which can be short oncea mote has time-synchronized with its neighbors), dutycycles can be kept quite low.

Snooping can also be used to reduce the number of mes-sages sent for some classes of aggregates. Consider com-puting a MAX over a group of motes: if a node hears a peerreporting a maximum value greater than its local maxi-mum, it can elect to not send its own value and be sure itwill not affecting the value of the final aggregate.

6.2 Hypothesis Testing

The snooping example above showed that we only needto hear from a particular node if that node’s value will af-fect the end value of the aggregate. For some aggregates,this fact can be exploited to significantly reduce the num-ber of nodes that need to report. This technique can begeneralized to an approach we call hypothesis testing. Forcertain classes of aggregates, if a node is presented with aguess as to the proper value of an aggregate, it can decide


locally whether contributing its reading and the readingsof its children will affect the value of the aggregate.

For MAX, MIN and other monotonic, exemplary aggre-gates, this technique is directly applicable. There are anumber of ways it can be applied – the snooping approach,where nodes suppress their local aggregates if they hearother aggregates that invalidate their own, is one. Alter-natively, the root of the network (or any subtree of thenetwork) seeking an exemplary sensor value, such as aMIN, might compute the minimum sensor value � overthe highest levels of the subtree, and then abort the aggre-gate and issue a new request asking for values less than� over the whole tree. In this approach, leaf nodes neednot send a message if their value is greater than the min-imum observed over the top

�levels; intermediate nodes,

however, must still forward partial state records, so even iftheir value is suppressed, they may still have to transmit.

Assuming for a moment that sensor values are inde-pendent and uniformly distributed, then a particular leafnode must transmit with probability O/U ��

(where�

is thebranching factor, so O U ��

is the number of nodes in thetop�

levels), which is quite low for even small values of�

. For bushy routing trees, this technique offers a signif-icant reduction in message transmissions – a completelybalanced routing tree would cut the number of messagesrequired to O U � . Of course, the performance benefit maynot be as substantial for other, non-uniform, sensor valuedistributions; for instance, a distribution in which all sen-sor readings are clustered around the minimum will notallow many messages to be saved by hypothesis testing.Similarly, less balanced topologies (e.g. a line of nodes)will not benefit from this approach.

For summary aggregates, such as AVERAGE orVARIANCE, hypothesis testing via a guess from theroot can be applied, although the message savings arenot as dramatic as with monotonic aggregates. Note thatthe snooping approach cannot be used: it only appliesto monotonic, exemplary aggregates where values canbe suppressed locally without any information from acentral coordinator. To obtain any benefit with summaryaggregates and hypothesis testing, the user must define afixed-size error bound that he or she is willing to tolerateover the value of the aggregate; this error is sent into thenetwork along with the hypothesis value.

Consider the case of an AVERAGE: any device whose sen-sor value is within the error bound of the hypothesis valueneed not answer – its parent will then assume its valueis the same as the approximate answer and count it ac-cordingly (to apply this technique with AVERAGE, par-ents must know how many children they have.) It can beshown that the total computed average will not be off from

0

500

1000

1500

2000

2500

10 15 20 25 30 35 40 45 50

Mes

sage

s / E

poch

/ S

enso

r

Network Diameter

Steady State Messages/Epoch Max Query With Hypothesis Testing

No HypothesisHypothesis : 50Hypothesis : 90

Hypothesis via Snooping

Figure 5: Benefit of Hypothesis Testing for MAX

the actual average by more than the error bound, and leafnodes with values close to the average will not be requiredto report. Obviously, the value of this scheme depends onthe distribution of sensor values. In a uniform distribu-tion, the fraction of leaves that need not report approxi-mates the size of the error bound divided by the size ofthe sensor value distribution interval. If values are nor-mally distributed, a much larger fraction of leaves do notreport.

We conducted a simple experiment to measure the ben-efit of hypothesis testing and snooping for a MAX aggre-gate. The results are shown in Figure 5. In this exper-iment, sensor values were uniformly distributed over therange [0..100], and a hypothesis was made at the root. No-tice that the performance savings are nearly two-fold fora hypothesis of 90. We compared the hypothesis testingapproach with the snooping approach (which will be ef-fective even in a non-uniform distribution); surprisingly,snooping beat the other approaches by offering a nearlythree-fold performance increase over the no-hypothesiscase. This is because in the densely packed simple nodedistribution, most devices have three or more neighborsto snoop on, suggesting that only about one in four de-vices will have to transmit. With topology maintenanceand forwarding of child values by parents, the savings bysnooping is reduced to a factor of three.

7 Improving Tolerance to Loss

Up to this point in our experiments we used a reliableenvironment where no messages were dropped and nonodes disconnected or went offline. In this section, weaddress the problem of loss and its effect on the algo-rithms presented thus far. Unfortunately, unlike in tradi-tional database systems, communication loss is a a fact oflife in the sensor domain; the techniques described in thesection seek to mitigate that loss.


7.1 Topology Maintenance and Recovery

TAG is designed to sit on top of a shifting network topol-ogy that adapts to the appearance and disappearance ofnodes. Although a study of mechanisms for adaptingtopology is not central to this paper, for completeness wedescribe a basic topology maintenance and recovery al-gorithm which we use in both our simulation and imple-mentation. This approach is similar to techniques used inpractice in existing TinyOS sensor networks, and is de-rived from the general techniques proposed in the ad-hocnetworking literature[28, 22].

Networking faults are monitored and adapted to at twolevels: First, each node maintains a small, fixed sized listof neighbors, and monitors the quality of the link to eachof those neighbors by tracking the proportion of packetsreceived from each neighbor. This is done via a locallyunique sequence number associated with each message byits sender. When a node � observes that the link quality toits parent � is significantly worse than that of some othernode � � , it chooses � � as its new parent if � � is as closeor closer to the root as � and � � does not believe � is itsparent (the latter two conditions prevent routing cycles.)

Second, when a node observes that it has not heard fromits parent for some fixed period of time (relative to theepoch duration of the query it is currently running), it as-sumes its parent has failed or moved away. It resets itslocal level (to � ) and picks a new parent from the neigh-bor table according to the quality metric used for link-quality. Note that this can cause a parent to select a nodein the routing subtree underneath it as its parent, so childnodes must reselect their parent (as though a failure hadoccurred) when they observe that their own parent’s levelhas gone up.

Note that switching parents does not introduce the pos-sibility of multiple records arriving from a single node,as each node transmits only once per epoch (even if itswitches parents during that epoch.) Parent switching cancause temporary disconnections (and thus additional lostrecords) in the topology, however, due to children select-ing a new parent when their parent’s level goes up.

7.2 Effects of A Single Loss

We first study the effect that a single device going offlinehas on the value of the aggregate; this is an important mea-surement because it gives some intuition about the magni-tude of error that a single loss can generate. Note that, be-cause we are doing hierarchical aggregation, a single motegoing offline causes the entire subtree rooted at the node tobe (at least temporarily) disconnected. In this first exper-iment we used the simple topology, with sensor readingschosen from the uniform distribution over [1..1000]. Af-

0

5

10

15

20

25

30

35

40

45

10 15 20 25 30 35 40 45 50

Per

cent

Err

or

Network Diameter

Maximum Error vs. Aggregation Function

AVERAGECOUNT

MINIMUMMEDIAN

(a) Maximum Error

-0.5

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

10 15 20 25 30 35 40 45 50

Network Diameter

Average Error vs. Aggregation Function

AVERAGECOUNT

MINIMUMMEDIAN

(b) Average ErrorFigure 6: Effect of a Single Loss on Various AggregateFunctions. Computed over a total of 100 runs at eachpoint. Error bars indicate standard error of the mean, 95%confidence intervals.

ter running the simulation for several epochs, we selected,uniformly and at a random, a node to disable. In this en-vironment, children of the disabled node were temporar-ily disconnected but eventually their values were reinte-grated into the aggregate once they rediscovered their par-ents. Note that the amount of time taken for lost nodes toreintegrate is directly proportional to the depth of the lostnode, so we did not measure it experimentally. Instead,we measured the maximum temporary deviation from thetrue value of the aggregate that the loss caused in the per-ceived aggregate value at the root during any epoch. Thismaximum was computed by performing 100 runs at eachdata point and selecting the largest error reported in anyrun. We also report the average of the maximum erroracross all 100 runs.

Figure 6 shows the results of this experiment. Note thatthe maximum loss (Figure 6(a)) is highly variable and thatsome aggregates are considerably more sensitive to lossthan others. COUNT, for instance, has a very large error inthe worst case: if a node that connects the root to a largeportion of the network is lost, the temporary error will bevery high. The variability in maximum error is because awell connected subtree is not always selected as the vic-tim. Indeed, assuming some uniformity of placement (e.g.the devices are not arranged in a line), as the networksize increases, the chances of selecting such a node godown, since a larger proportion of the nodes are towardsthe leaves of the tree. In the average case(Figure 6(b)), theerror associated with a COUNT is not as high: most lossesdo not result in a large number of disconnections. Notethat MIN is insensitive to loss in this uniform distribution,since several nodes are at or near the true minimum. Theerror for MEDIAN and AVERAGE is less than COUNT andmore than MIN: both are sensitive to the variations in thenumber of nodes, but not as dramatically as COUNT.

7.3 Effect of Realistic Communication

In the second experiment, we examine how well TAG per-forms in the realistic simulation environment (discussed


in Section 5 above). In such an environment, withoutsome technique to counteract loss, a large number of par-tial state records will invariably be dropped and not reachthe root of the tree. We ran an experiment to measurethe effect of this loss in the realistic environment. Thesimulation ran until the first aggregate arrived at the root,and then the average number of motes involved in the ag-gregate over the next several epochs was measured. The“No Cache” line of Figure 7 shows the performance ofthis approach; at diameter 10, about 40% of the partialstate records are reflected in the aggregate at the root; bydiameter 50, this percentage has fallen to less than 10%.Performance falls off as the number of hops between theaverage node and the root increases, since the probabilityof loss is compounded by each additional hop. Thus, thebasic TAG approach presented so far, running on currentprototype hardware (with its very high loss rates), is nothighly tolerant to loss, especially for large networks. Notethat any centralized approach would suffer from the sameloss problems.

7.4 Child Cache

To improve the quality of aggregates, we propose asimple caching scheme: parents remember the partialstate records their children reported for some number ofrounds, and use those previous values when new valuesare unavailable due to lost child messages. As long asthe duration of this memory is shorter than the intervalat which children select new parents, this technique willincrease the number of nodes included in the aggregatewithout over-counting any nodes. Of course, cachingtends to temporally smear the aggregate values that arecomputed, reducing the temporal resolution of individ-ual readings and possibly making caching undesirable forsome workloads. Note that caching is a simple form of in-terpolation where the interpolated value is the same as theprevious value. More sophisticated interpolation schemes,such as curve fitting or statistical observations based onpast behavior, could be also be used.

We conducted some experiments to show the improve-ment caching offers over the basic approach; we allocatea fixed size buffer at each node and measure the averagenumber of devices involved in the aggregation as in Sec-tion 7.3 above. The results are shown in the top threelines of Figure 7 – notice that even five epochs of cachedstate offer a significant increase in the number of nodescounted in any aggregate, and that 15 rounds increases thenumber of nodes involved in the diameter 50 network to70% (versus less than 10% without a cache). Aside fromthe temporal smearing described above, there are two ad-ditional drawbacks to caching; First, it uses memory thatcould be used for group storage. Second, it sets a mini-mum bound on the time that devices must wait before de-

0

10

20

30

40

50

60

70

80

90

100

10 15 20 25 30 35 40 45 50

Per

cent

age

of N

etw

ork

Invo

lved

Network Diameter

Percentage of Network Involved, Child Caching

No Cache5 Epochs Cache

9 Epochs Cache15 Epochs Cache

Figure 7: Percentage of Network Participating in Aggre-gate For Varying Amounts of Child Cache

termining their parent has gone offline; given the benefit itprovides in terms of accuracy, however, we believe it to beuseful despite these disadvantages. The substantial benefitof this technique suggests that allocating RAM to applica-tion level caching may be more beneficial than allocatingit to lower-level schemes for reliable message delivery, assuch schemes cannot take advantage of the semantics ofthe data being transmitted.

7.5 Using Available Redundancy

Because there may be situations where the RAM or la-tency costs of the child cache are not desirable, it is worth-while to look at alternative approaches for improving losstolerance. In this section, we show how the network topol-ogy can be leveraged to increase the quality of aggregates.Consider a mote with two possible choices of parent: in-stead of sending its aggregate value to just one parent, itcan send it to both parents. A node can easily discoverthat it has multiple parents by building a list of nodes ithas heard that are one step closer to the root. Of course,for duplicate-sensitive aggregates (see Section 3.2), send-ing results to multiple parents has the undesirable effectof causing the node to be counted multiple times. The so-lution to this is to send part of the aggregate to one parentand the rest to the other. Consider a COUNT; a mote with�� O children and two parents can send a COUNT of � U��to both parents instead of a count of � to a single parent.Generally, if the aggregate can be linearly decomposed inthis fashion, it is possible to broadcast just a single mes-sage that is received and processed by both parents, so thisscheme incurs no message overheads, as long as both par-ents are at the same level and request data delivery duringthe same sub-interval of the epoch.

A simple statistical analysis reveals the advantage of do-ing this: assume that a message is transmitted with proba-bility � , and that losses are independent, so that if a mes-sage � from node � is lost in transition to parent

� , , it isno more likely to be lost in transit to

� 4 . 6 First, consider

6Although independent failures are not always a valid assumption,


the case where � sends � to a single parent; the expectedvalue of the transmitted count is � � � (0 with probabil-ity KBO � �ML and � with probability � ), and the variance is� 4 � � � KRO � �ML , since these are standard Bernoulli trialswith a probability of success � multiplied by a constant � .For the case where � sends � U�� to both parents, linearityof expectation tells us the expected value is the sum of theexpected value through each parent, or � � � �� U�� .Similarly, we can sum the variances through each parent:

var =�� ! D �� !

=� D � �� !

Thus, the variance of the multiple parent COUNT is muchless than with just a single parent, although its expectedvalue is the same. This is because it is much less likely(assuming independence) for the message to both parentsto be lost, and a single loss will less dramatically affectthe computed value.

We ran an experiment to measure the benefit of this ap-proach in the realistic topology for COUNTwith a networkdiameter of 50. We measured the number of devices in-volved in the aggregation over a 50 epoch period. Whensending to multiple parents, the mean COUNT was 974( ��

), while when sending to only one parent, themean COUNT was 94 ( �

�� O ). Surprisingly, sending tomultiple parents substantially increases the mean aggre-gate value; most likely this is due to the fact that lossesare not truly independent as we assumed above.

This technique applies equally well to any distributiveor algebraic aggregate. For holistic aggregates, likeMEDIAN, this technique cannot be applied, since partialstate records cannot be easily decomposed.

8 Prototype Implementation

Based on the encouraging simulation results presentedabove, we have built an implementation of TAG forTinyOS Mica motes [19]. The implementation does notcurrently include many of the optimizations discussed inthis paper, but contains the core TAG aggregation algo-rithm and catalog support for querying arbitrary attributeswith simple predicates. In this section, we briefly sum-marize results from experiments with this prototype, todemonstrate that the simulation numbers given above areconsistent with actual behavior and to show that substan-tial message reductions over a centralized approach arepossible in a real implementation.

These experiments involved sixteen motes arranged in adepth four tree, computing a COUNT aggregate over 1504-second epochs (a 10 minute run.) No child cachingor snooping techniques were used. Figure 8 shows the

they will occur when local interference is the cause of loss. For example,a hidden node may garble communication to � < but not � D , or one parentmay be in the process of using the radio when the message arrives.

0

5

10

15

20

0 20 40 60 80 100 120 140

CO

UN

T

Epoch

Count Per Epoch, 16 Nodes (Epoch Duration = 4 Seconds)

TAGCentralized

Figure 8: Comparison of Centralized and TAG based Ag-gregation Approaches in Lossy, Prototype EnvironmentComputing a COUNT over a 16 node network.

COUNT observed at the root for a centralized approach,where all messages are forwarded to the root, versus thein network TAG approach. Notice that the quality ofthe aggregate is substantially better for TAG; this is dueto reduced radio contention. To measure the extent ofcontention and compare the message costs of the twoschemes, we instrumented motes to report the number ofmessages sent and received. The centralized approach re-quired 4685 messages, whereas TAG required just 2330,representing a 50% communications reduction. This isless than the order-of-magnitude shown in Figure 4 forCOUNT because our prototype network topology had ahigher average fanout than the simulated environment, somessages in the centralized case had to be retransmittedfewer times to reach the root. Per hop loss rates wereabout 5% in the in network approach. In the centralizedapproach, increased network contention drove these lossrates to 15%. The poor performance of the centralizedcase is due to the multiplicative accumulation of loss, suchthat only 45% of the messages from nodes at the bottomof the routing tree arrived at to the root.

This completes our discussion of algorithms for TAG. Wenow turn to the extensive related work in the networkingand database communities.

9 Related Work

The database community has proposed a number of dis-tributed and push-down based approaches for aggregatesin database systems [26, 33], but these universally assumea well-connected, low-loss topology that is unavailable insensor networks. None of these systems present tech-niques for loss tolerance or power sensitivity. Further-more, their notion of aggregates is not tied to a taxonomy,and so techniques for transparently applying various ag-gregation and routing optimizations are lacking. The par-tial preaggregation techniques [15] used to enable groupeviction were proposed as a technique to deal with verylarge numbers of groups to improve the efficiency of hashjoins and other bucket-based database operators.


The first three components of the partial-state dimensionof the taxonomy presented in Section 3.2 (e.g. algebraic,distributive, and holistic) were originally developed as apart of the research on data-cubes [9]; the duplicate sensi-tivity, exemplary vs. summary, and monotonicity dimen-sions, as well as the unique and content-sensitive statecomponents of partial-state are our own addition. [29]discusses online aggregation [11] in the context of nested-queries; it proposes optimizations to reduce tuple-flow be-tween outer and inner queries that bear similarities to ourtechnique of pushing HAVING clauses into the network.

With respect to query language, our epoch based approachis related to languages and models from the TemporalDatabase literature; see [27] for a survey of relevant work.The Cougar project at Cornell [23] discusses queries oversensor networks, as does our own work on Fjords [18], al-though the former only considers moving selections (notaggregates) into the network and neither presents specificalgorithms for use in sensor networks.

Literature on active networks [30] identified the idea thatthe network could simultaneously route and transformdata, rather than simply serving as an end-to-end data con-duit. The recent SIGCOMM paper on ESP [4] providesa constrained framework for in network aggregation-likeoperations in a traditional network. Within the sensornetwork community, work on networks that perform dataanalysis is largely due to the USC/ISI and UCLA com-munities. Their work on directed diffusion [13] dis-cusses techniques for moving specific pieces of informa-tion from one place in a network to another, and pro-poses aggregation-like operations that nodes may performas data flows through them. Their work on low-level-naming[10] proposes a scheme for imposing names ontorelated groups of devices in a network, in much the waythat our scheme partitions sensor networks into groups.Work on greedy aggregation [12] discusses networkingprotocols for routing data to improve the extent to whichdata can be combined as it flows up a sensor network –it provides low level techniques for building routing treesthat could be useful in computing TAG style aggregates.

These papers recognize that aggregation dramatically re-duces the amount of data routed through the networkbut present application-specific solutions that, unlike thedeclarative query approach approach of TAG, do not offera particularly simple interface, flexible naming system, orany generic aggregation operators. Because aggregation isviewed as an application-specific operation in diffusion, itmust always be coded in a low-level language. Althoughsome TAG aggregates may also be application-specific,we ask that users provide certain functional guarantees,such as composability with other aggregates, and a clas-sification of semantics (quantity of partial state, mono-

tonicity, etc.) which enable transparent application ofvarious optimizations and create the possibility of a li-brary of common aggregates that TAG users can freelyapply within their queries. Furthermore, directed diffu-sion puts aggregation APIs in the routing layer, so that ex-pressing aggregates requires thinking about how data willbe collected, rather than just what data will be collected.This is similar to old-fashioned query processing code thatthought about navigating among records in the database –by contrast, our goal is to separate the expression of ag-gregation logic from the details of routing. This allowsusers to focus on application issues and enables the sys-tem to dynamically adjust routing decisions using general(taxonomic) information about each aggregation function.

Networking protocols for routing data in wireless net-works are very popular within the literature [14, 1, 8],however, none of them address higher level issues of dataprocessing, merely techniques for data routing. Our tree-based routing approach is clearly inferior to these ap-proaches for peer to peer routing, but works well forthe aggregation scenarios we are focusing on. Work on(N)ACKs (and suppression thereof) in scalable, reliablemulticast trees [6, 17] bears some similarity to the prob-lem of propagating an aggregate up a routing tree inTAG. These systems, however, consider only fixed, lim-ited types of aggregates (e.g. ACKs or NAKs for regionsor recovery groups.) Finally, we presented an early ver-sion of this work in a workshop publication [20].

10 ConclusionsIn summary, we have shown how declarative aggregatequeries can be distributed and efficiently executed oversensor networks. Our in network approach can provide anorder of magnitude reduction in bandwidth consumptionover approaches where data is aggregated and processedcentrally. The declarative query interface allows end-usersto take advantage of this benefit for a wide range of aggre-gate operations without having to modify low-level codeor confront the difficulties of topology construction, datarouting, loss tolerance, or distributed computing. Further-more, this interface is tightly integrated with the network,enabling transparent optimizations that further decreasemessage costs and improve tolerance to failure and loss.

We plan to extend this work as the data collection needsof the wireless sensor community evolve. We are movingtowards an event-driven model where queries can be ini-tiated and results collected in response to external eventsin the interior of the network, with the results of thoseinternal sub-queries being aggregated across nodes andshipped to points on the network edge.

As sensor networks become more widely deployed, es-pecially in remote, difficult to administer locations,


bandwidth- and power-sensitive methods to extract datafrom those networks will become increasingly important.In such scenarios, the users are often scientists who lackfluency in embedded software development but are inter-ested in using sensor networks to further their own re-search. For such users, high-level programming interfacesare a necessity; these interfaces must balance simplicity,expressiveness, and efficiency in order to meet data col-lection and battery lifetime requirements. Given this bal-ance, we see TAG as a very promising service for datacollection: the simplicity of declarative queries, combinedwith the ability of TAG to efficiently optimize and executethem makes it a good choice for a wide range of sensornetwork data processing situations.

AcknowledgmentsThanks to our shepherd, Deborah Estrin, and to ouranonymous reviewers for their thoughtful reviews and ad-vice. Robert Szewczyk, David Culler, Alec Woo, andRamesh Govindan contributed to the design of the net-working protocols discussed in this paper. Per Ake Lar-son suggested the use of partial preaggregation for groupeviction. Kyle Stanek implemented isobar aggregates inour simulator.

References[1] W. Adjue-Winoto, E. Schwartz, H. Balakrishnan, and

J. Lilley. The design and implementation of an intentionalnaming system. In ACM SOSP, December 1999.

[2] F. Bancilhon, T. Briggs, S. Khoshafian, and P. Valduriez.FAD, a powerful and simple database language. In VLDB,1987.

[3] D. Barbara, W. DuMouchel, C. Faloutsos, P. J. Haas, J. M.Hellerstein, Y. E. Ioannidis, H. Jagadish, T. Johnson, R. T.Ng, V. Poosala, K. A. Ross, and K. C. Sevcik. The NewJersey data reduction report. Data Engineering Bulletin,20(4):3–45, 1997.

[4] K. Calvert, J. Griffioen, and S. Wen. Lightweight net-work support for scalable end-to-end services. In ACMSIGCOMM, 2002.

[5] A. Cerpa, J. Elson, D.Estrin, L. Girod, M. Hamilton, ,and J. Zhao. Habitat monitoring: Application driver forwireless communications technology. In ACM SIGCOMMWorkshop on Data Communications in Latin America andthe Caribbean, 2001.

[6] S. Floyd, V. Jacobson, C. Liu, S. McCanne, and L. Zhang.A reliable multicase framework for light-weight sessionsand application level framing. IEEE Transactions on Net-working, 5(6):784–803, 1997.

[7] D. Ganesan. Network dynamics in rene motes. PowerPointPresentation, January 2002.

[8] T. Goff, N. Abu-Ghazaleh, D. Phatak, and R. Kahvecioglu.Preemptive routing in ad hoc networks. In ACM MobiCom,July 2001.

[9] J. Gray, A. Bosworth, A. Layman, and H. Pirahesh.Data cube: A relational aggregation operator generaliz-ing group-by, cross-tab, and sub-total. In ICDE, February1996.

[10] J. Heidemann, F. Silva, C. Intanagonwiwat, R. Govindan,D. Estrin, and D. Ganesan. Building efficient wireless sen-sor networks with low-level naming. In SOSP, October2001.

[11] J. Hellerstein, P. Hass, and H. Wang. Online aggregation.

In Proceedings of the ACM SIGMOD, pages 171–182, Tuc-son, AZ, May 1997.

[12] C. Intanagonwiwat, D. Estrin, R. Govindan, and J. Hei-demann. Impact of network density on data aggregationin wireless sensor networks. Submitted for Publication,ICDCS-22, November 2001.

[13] C. Intanagonwiwat, R. Govindan, and D. Estrin. Directeddiffusion: A scalable and robust communication paradigmfor sensor networks. In MobiCOM, Boston, MA, August2000.

[14] J. Kulik, W. Rabiner, and H. Balakrishnan. Adaptive proto-cols for information dissemination in wireless sensor net-works. In MobiCOM, 1999.

[15] P.-A. Larson. Data reduction by partial preaggregation. InICDE, 2002.

[16] P. Levis and D. Culler. Mate: A tiny virtual machine forsensor networks. Submitted for Publication.

[17] J. Lin and S. Paul. RMTP: A Reliable Multicast TransportProtocol. In INFOCOM, pages 1414–1424, 1996.

[18] S. Madden and M. J. Franklin. Fjording the stream: Anarchitechture for queries over streaming sensor data. InICDE, 2002.

[19] S. Madden, W. Hong, J. Hellerstein, and M. Franklin.TinyDB web page. http://telegraph.cs.berkeley.edu/tinydb.

[20] S. Madden, R. Szewczyk, M. Franklin, and D. Culler. Sup-porting aggregate queries over ad-hoc wireless sensor net-works. In Workshop on Mobile Computing and SystemsApplications, 2002.

[21] A. Mainwaring, J. Polastre, R. Szewczyk, and D. Culler.Wireless sensor networks for habitat monitoring. In ACMWorkshop on Sensor Networks and Applications, 2002.

[22] V. D. Park and M. S. Corson. A highly adaptive distributedrouting algorithm for mobile wireless networks. In INFO-COM, 1997.

[23] P.Bonnet, J.Gehrke, and P.Seshadri. Towards sensordatabase systems. In Conference on Mobile Data Man-agement, January 2001.

[24] C. E. Perkins and E. M. Royer. Ad-hoc on-demand dis-tance vector routing. In Workshop on Mobile Computingand Systems Applications, 1999.

[25] G. Pottie and W. Kaiser. Wireless integrated network sen-sors. Communications of the ACM, 43(5):51 – 58, May2000.

[26] A. Shatdal and J. Naughton. Adaptive parallel aggregationalgorithms. In ACM SIGMOD, 1995.

[27] R. T. Snodgrass, editor. The TSQL2 Temporal Query Lan-guage. Kluwer Academic Publisher, 1995.

[28] L. Subramanian and R. H.Katz. An architecture for build-ing self-configurable systems. In MobiHOC, Boston, Au-gust 2000.

[29] K.-L. Tan, C. H. Goh, and B. C. Ooi. Online feedback fornested aggregate queries with multi-threading. In VLDB,1999.

[30] D. L. Tennenhouse, J. M. Smith, W. D. Sincoskie, D. J.Wetherall, and G. J. Minden. A survery of active networkresearch. IEEE Communications, 1997.

[31] UC Berkeley. Smart buildings admit their faults.Web Page, November 2001. Lab Notes: Researchfrom the College of Engineering, UC Berkeley.http://coe.berkeley.edu/labnotes/1101.smartbuildings.html.

[32] A. Woo and D. Culler. A transmission control scheme formedia access in sensor networks. In ACM Mobicom, July2001.

[33] W. P. Yan and P. A. Larson. Eager aggregation and lazyaggregation. In VLDB, 1995.

[34] W. Ye, J. Heidemann, and D. Estrin. An energy-efficientMAC protocol for wireless sensor networks. In IEEE Info-com, 2002.

[35] A. Yu and J. Chen. The POSTGRES95 User Manual. UCBerkeley, 1995.

Documents

TAG: a Tiny AGgregation Service for Ad-Hoc Sensor Networksusers.eecs.northwestern.edu/~peters/references/TAGMadden02.pdf · Samuel Madden, Michael J. Franklin, and Joseph M. Hellerstein