Sensor-aware Adaptive Pull-Push Query Processing for Sensor Networks

Transcription

1 Sensor-aware Adaptve Pull-Push Query Processng for Sensor Networks Raja Bose Unversty of Florda Ganesvlle, FL 326 U.S.A. Abdelsalam Helal Unversty of Florda Ganesvlle, FL 326 U.S.A. ABSTRACT Tll now query processng strateges for wreless sensor networks (WSNs) have typcally assumed that the cost of transmttng a sensor readng over the network s much hgher than the cost of samplng a sensor. However, as we shall show n ths paper, ths assumpton s no longer always vald, due to avalablty of new generaton sensor platform hardware whch utlze ndustry standard mesh-networkng protocols such as ZgBee on top of relatvely hgh-speed yet low-power wreless rados. In fact, the energy consumed for acqurng a sample from a sensor can be sgnfcantly hgher than the energy consumed for transmttng ts readng over the network. Hence, new queryng strateges need to be formulated whch optmze the order of samplng sensors across the network n such a manner that sensors wth expensve acquston costs are not sampled unless explctly requred. In ths paper, we propose dstrbuted pull-push queryng mechansms whch optmze the query plan by adaptng to varable costs of acqurng readngs from dfferent sensors across the network. The goal of these mechansms s to mnmze the energy consumpton of nodes executng a query whle ensurng that the latency of query response does not exceed user-specfed bounds. We also analyze the performance of varous plan optons on dfferent hardware confguratons, based on ther energy consumpton and latency, through experments usng real-world data.. INTRODUCTION The man focus of research on query processng n sensor networks has been the mnmzaton of energy consumpton of the sensor network. Tll now, most contemporary research on acquston-based query processng on sensor networks has assumed that the energy cost of transmttng a sensor s readng s always sgnfcantly hgher than the energy cost of samplng that sensor. However, ths assumpton seems to no longer be unversally vald, due to rapd advances n rado hardware technology and avalablty of relatvely hgh speed yet low power networkng protocols such as ZgBee/ From our Permsson to copy wthout fee all or part of ths materal s granted provded that the copes are not made or dstrbuted for drect commercal advantage, the VLDB copyrght notce and the ttle of the publcaton and ts date appear, and notce s gven that copyng s by permsson of the Very Large Database Endowment. To copy otherwse, or to republsh, to post on servers or to redstrbute to lsts, requres a fee and/or specal permssons from the publsher, ACM. VLDB 08, August 24-30, 2008, Auckland, New Zealand. Copyrght 2008 VLDB Endowment, ACM /00/00. experence, we found that the energy consumpton of a node can be qute hgh even when t samples a sensor wthout transmttng the readng over the network and the contrbuton of network cost to the total energy consumpton of a node can be sgnfcantly less than the sensor samplng cost. To the best of our knowledge, there s no publshed work tll date, whch has explctly looked at ths ssue and has suggested query processng strateges to deal wth t. The contrbutons of ths paper are as follows: We examne reasons why sensng cost has become the overly domnatng factor n node energy consumpton as a result of recent technologcal developments n networkng hardware. To valdate ths, we compare and analyze energy consumptons of two dfferent generatons of sensor platforms namely, the Crossbow MICA2 Mote and the Atmel Zlnk RCB. We consder the tradtonal push strategy for sensor samplng and propose selectve pull and hybrd pull-push mechansms for samplng sensors and query executon, whch avods samplng a sensor over the network unless explctly requred to. We also look at the tradeoffs for adoptng each strategy. We show how the query optmzer can generate query plans havng low energy cost and bounded latency by optmzng the order of samplng sensors across the network and selectvely applyng push and pull strateges for acqurng readngs. We valdate our approach through experments on real-lfe data and analyze the performance of varous query plan optons. The rest of ths paper s structured as follows. Secton 2 descrbes the motvaton behnd ths paper and examnes the reasons why the tradtonal assumpton of network cost outweghng the sensor samplng cost no longer always holds true. It also provdes a dscusson of how ths affects exstng query processng and executon technques. Secton 3 gves a bref descrpton of the sensor network hardware and software used n ths paper. In Secton 4, frst we go over the tradtonal push strategy for samplng sensors and n-network executon of queres. Then we propose selectve pull and hybrd pull-push strateges for mprovng energy consumpton of sensor nodes by selectve samplng of sensors and optmzng the order of ther samplng across the network. We also look at the tradeoffs of each strategy. Then, we descrbe the steps a query optmzer goes through n order to generate an optmal query plan and how the actual performance of a plan can be montored durng executon. In Secton 5, we dscuss fault tolerance ssues and how to cope wth them. Secton 6 provdes expermental analyss of query plan performance based on energy consumpton and query response

2 latency. Secton 7 covers relevant related work n ths area. Secton 8 concludes ths paper and outlnes future work. 2. MOTIVATION In ths secton, we dscuss why the cost of samplng a sensor can become so sgnfcant that ts contrbuton to the total energy consumpton of a node becomes extremely hgh as compared to network cost. Fgure shows the comparatve % contrbutons of networkng and sensng tasks to total energy consumpton for the Crossbow MICA2 mote and the Atmel Zlnk RCB sensor platform. The MICA2 was released n 2002 and has been amongst the frst and most wdely used sensor platforms n sensor network research. The Atmel Zlnk RCB on the other hand, was released relatvely recently n 2007 and s amongst a new generaton of non-mote sensor platforms beng developed by companes such as Atmel and Texas Instruments. The MICA2 hardware s bult around an Atmel Atmega28 mcrocontroller and Chpcon CC000 rado. It typcally runs the propretary ad-hoc routng protocol used by TnyOS and has a transmsson baud rate of 38.4Kbps. The Atmel Zlnk RCB s based around the Atmega28 mcrocontroller and AT86RF rado. It runs a full featured ndustry standard ZgBee stack from Meshnetcs Inc. and has a comparatvely hgh transmsson baud rate of 250Kbps. The energy consumpton values for the MICA2 were derved from experments performed by Madden et. al [7]. The energy consumpton values for the Zlnk RCB were calculated based on the sensor confguraton used by Madden et. al and hardware specfcatons provded by Atmel. Fgure. Network Cost vs. Sensor Samplng Cost From Fgure we can see that the contrbuton of sensng to the total energy consumpton for the Zlnk RCB s sgnfcantly hgher (by about 20%) as compared to the older MICA2 mote. Ths can be explaned as follows. The newer rados used by ZgBee have lower current consumpton and sgnfcantly hgher baud rates (250Kbps) as compared to older low-power rados such as the CC000 (38.4Kbps). Hence, rados take much less tme to transmt a packet and therefore consume much less energy. On the other hand, the technology used for acqurng readngs from a sensor has more or less remaned the same. Apart from a few power hungry sensors such as magnetometers or organc byproduct sensors, most sensors have very low power requrements of the order of fractons of a mllampere. In fact, the cost of samplng a sensor s largely due to the cost of operatng the mcrocontroller and ts Analog-to- Dgtal converter (ADC), whch s of the order of a few mllamperes. In order to sample an analog sensor (most sensors used today fall n ths category), a mcrocontroller has to operate ts ADC to access and convert the sensor s output voltage nto dscrete numbers. Ths s a relatvely power hungry operaton and also typcally requres some tme to complete snce the speed of samplng s bounded by delays such as tme requred to ntalze the ADC, watng for nput lne voltages to stablze and takng multple samples to ensure correctness of readng. These delays are nevtable due to physcal lmtatons of the mcrocontroller and sensor and the fact that the sensors themselves are extremely smple electrcal devces such as resstors or dodes. Therefore, the energy requred to take a sensor readng has remaned more or less the same whereas the energy requred for transmttng a readng over the network has decreased drastcally. Wth more advances n rado technology we expect ths gap to wden further n the future. Hence, the tables are now beng turned and one s faced wth stuatons where the cost of sensng can actually outwegh network cost by a sgnfcant margn. 2. Re-examnng Sensor Samplng Strateges In lght of the above dscusson, we feel there s a need to take a fresh look at sensor samplng strateges. We note that even though, n case of the MICA2 the sensng cost has a hgher contrbuton to the total energy cost as compared to network cost, t may not be sgnfcant enough to outwegh the total network cost of communcatng over a mult-hop network. On the other hand, for newer hardware such as the Atmel RCB, the dfference s sgnfcant enough to warrant a fresh look at query processng strateges for n-network executon of queres. Currently almost all query executon plans use the Push approach. Push requres nodes to autonomously sample ther sensors and push ther readngs nto the network. Optmzatons have been suggested where nodes can avod samplng ther sensors f the result of the query can be deduced from already exstng nformaton. These optmzatons ether nvolve the use of partal aggregate nformaton or utlze models to determne whch sensors to sample. The former approach used n TAG [8] only avods samplng of sensors drectly connected to a node and does not control sensor samplng of other nodes below t n the aggregaton tree. The latter approach used by Deshpande et. al n BBQ [2], makes the decson of whch sensors to sample based on data requrements of the model, rather than energy consumpton. Deshpande et. al do consder the acquston cost of samplng a sensor however, they are prmarly nterested n utlzng ths data to fnd another sensor whch s less expensve to sample based on correlatons between varous phenomena (example, temperature and battery voltage). Therefore, ther approach does not look at the queston of whether to entrely avod samplng a sensor based on energy consderatons; rather t depends on a model to determne whch sensors to sample and attempts to fnd replacement sensors f possble, havng lower energy cost of samplng. The Pull approach requres nodes to wat for an explct command before samplng ts sensors. The pull approach has been utlzed very frugally n sensor network query processng tll now, manly due to the assumpton that network cost s more than the cost of sensng. However, n vew of the dscusson n secton 2, the pull approach once agan becomes a vable opton durng query

3 processng. But both the push and pull approaches have ther advantages and drawbacks. The push approach allows nodes to execute ther task autonomously and has low latency of query response. However, the push approach also almost always requres a node to sample ts sensors (barrng certan ntermedate nodes as mentoned before). Ths approach worked well n the past when the cost of samplng a sensor was a mnor contrbutor to the total energy cost. But ths may not work that well now snce acqurng readngs from a sensor makes up the largest fracton of a node s energy consumpton by a wde margn. Hence, even f a sensor s readng s not transmtted over the network, smply samplng t causes the node s energy consumpton to be qute sgnfcant. The pull approach on the other hand only requres nodes to sample ther sensors when explctly asked to. However, usng pull navely by pullng readngs from sensors n parallel wll not prove useful n terms of energy consumpton due to obvous reasons. On the other hands, f sensor readngs are pulled n an optmal order based on ther acquston costs, ths can lead to lower energy costs snce sensors wll be sampled only when requred. Madden et. al have proposed such a technque n TnyDB [7], however ther mechansm s only meant for sensors connected to the same node and provdes a locally optmal orderng of samplng of sensors connected to the same node rather than a network-wde orderng of all sensors nvolved n the query. The dsadvantage of the pull approach s that t suffers from hgher network cost as t requres the exchange of two messages as opposed to one message n pull. Moreover, ts data delvery latency s also hgher than push. Hence, we feel that a thrd plan opton namely, a hybrd Pull-Push approach s requred when data s pushed from some sensors and pulled from others. In ths hybrd approach pull mechansms are utlzed to cut down on unnecessary samplng of sensors thereby reducng energy consumpton and push mechansms are utlzed to reduce network traffc and latency of query response. Secton 4 provdes a detaled dscusson of all three approaches and descrbe how a query optmzer generates and chooses the query executon plan whch best meets the goal of mnmzng node energy consumpton whle ensurng that the latency of query response does not go beyond user-specfed bounds. 3. SYSTEM SETUP In ths secton, we provde a bref descrpton of the sensor network hardware, software and network setup that wll be used for the rest of ths paper. We are desgnng our system usng the Atlas Platform [5] whch s a servce orented sensor network (SOSN). A servce orented sensor network (SOSN) mports the concept of Servce Orented Archtecture (SOA) nto the sensor network doman. It represents each of ts sensors as a servce object n a servce framework that allows ther dynamc dscovery and composton nto applcatons. The servce layer of a SOSN resdes on a central host computer whch communcates wth the sensor nodes va a network gateway as shown n Fgure 2(a). The servce layer s bult on top of a SOA-based framework such as OSG [4]. Sensor servces abstract away low level operatonal detals of ther assocated hardware sensor and provde hgh level methods for accessng them. They also have a set of assocated propertes whch provde nformaton about the sensor hardware such as output range, error bounds, power consumpton values and unts of measurement. The Atlas Platform hardware conssts of Atmel Zlnk RCB nodes runnng custom frmware. The Zlnk RCB nodes communcate over a ZgBee network. ZgBee provdes an ndustry standard mesh networkng protocol runnng on top of the IEEE stack. ZgBee s supported by almost all new generaton sensor platforms that are beng released today and s fast becomng the network of choce for sensor networks deployed n ntellgent envronments such as homes, warehouses or hosptals. As compared to propretary ad-hoc networkng protocols wdely used by the wreless sensor networkng (WSN) communty where all nodes functon as routers, ZgBee networks have three classes of devces n them, namely, Coordnator, Router and End-Devce. Each ZgBee network has one coordnator whch n our case also serves as a gateway to the Atlas servce layer. The routers are responsble for formng the ntermedate network connectons and the vast majorty of devces are end-devces whch do not partcpate n the network routng process. Most f not all the sensors n the network are typcally connected to end-devces. Only end-devces are allowed to sleep n a ZgBee network and are therefore manly battery powered whereas the coordnator and routers have to stay on all the tme and are typcally mans powered devces. Fgure 2(b) shows the topologes possble n ZgBee networks namely, star, mesh and cluster-tree. For ths paper, we assume that the network topology s a cluster-tree, that s, t s a hybrd of star and mesh topologes. Fgure 2. (a) SOSN; (b) ZgBee Network Topologes 4. SENSOR QUERYING STRATEGIES We frst begn by dentfyng the type of queres we are targetng for optmzaton and defne some terms whch wll be used n subsequent sectons. Then we provde a descrpton of how a query s dssemnated amongst the nodes for n-network executon based on network topology. Then we cover three queryng strateges namely, Push, Pull and hybrd Pull-Push. For each of the approaches we also defne cost functons whch wll be used by the query optmzer to dentfy the best query plan. Then, we descrbe how the query optmzer generates and chooses the best query plan for mnmzng energy consumpton whle ensurng that the response latency remans wthn user-specfed bounds. Fnally, we descrbe how the cost performance of a plan can be montored durng ts executon to ensure ts effectveness. 4. Defntons In ths paper, we focus on contnuous selecton queres nvolvng multple predcates appled on multple sensors, snce these types of queres are drectly affected by sensor acquston costs and the order of samplng sensors. We denote these predcate queres n CNF as:

4 Q = ( Cj ). Each lteral C j nvolves a predcate appled on a j sensor and s of the form P(s), where P s a predcate and P(s) denotes that predcate P s beng appled on sensor s. Sel P (s) denotes the selectvty of sensor s wth respect to predcate P. We assume Sel P (s) є[0, ] and therefore gves the probablty that P(s) evaluates to False. Hence, hgher the value of Sel P (s), more selectve s the sensor s wth respect to predcate P. Sel P (s) can be calculated by the query processor based on sensor hstory such as [] or can be obtaned drectly from statstcs stored onboard sensor nodes, but we do not go nto detals of such operatons n ths paper. If the predcate beng referred to n the text s unambguous, we may use Sel(s) nstead of Sel P (s). We denote the cost of samplng a sensor s as E(s) where E(s) denotes energy consumed by the mcrocontroller for samplng sensor s and s measured n mlljoules (mj). Note that the mcrocontroller may consume dfferent amounts of energy based on the type of sensor beng sampled. Assume that the node evaluatng C j only transmts the result when C j evaluates to True. Then, we defne the network cost of transmttng the result of a lteral C j as NwkCost(C j ), where NwkCost(C j ) s the total energy consumed (mj) by nodes n the network for transmttng the result to ts destnaton. Ths cost s the sum total of energy spent by each node along the route (ncludng the source and destnaton nodes) for recevng and transmttng the result. NwkCost can be calculated f the network structure and lnk qualty nformaton s avalable. In a ZgBee network, ths nformaton s readly avalable from the Coordnator (one of whose roles s to mantan an overall vew of the network) and the query processor does not need to expend extra effort towards gatherng ths nformaton from all the nodes n the network. Fgure 3. Query Dssemnaton and Evaluaton 4.2 Query Dssemnaton Users ssue queres to the query processor resdng n the servce layer (Fgure 2(a)). The query processor generates a sutable query plan after utlzng ts optmzer and njects t nto the network va the coordnator/gateway. The query s dssemnated nto the network for executon usng a overlay tree structure smlar to what s used n TnyDB [7]. Fgure 3 shows an example of a query that has been dssemnated amongst partcpatng nodes for nnetwork executon. We wll use ths example n the followng subsectons to llustrate all the three strateges namely, Push, Selectve Pull and Pull-Push. In ths partcular example, the query beng dssemnated s: Q = ( C C2 C3) ( C2 C4) ( C5 C32 C42) ( C6). Evaluaton of each C j s assgned to the node connected to the sensor assocated wth the lteral. For example, C and C 2 are pushed to node N. Hence, a node may have to perform evaluaton of lterals belongng to multple clauses. The cost of evaluatng the set of lterals assgned to a node depends on the selectvty of each sensor nvolved and ts cost of samplng. Snce a node s requred to evaluate multple dsjunctons of lterals (often belongng to dfferent clauses), the order of sensor samplng s done as follows. For each group of lterals assgned to a node belongng to the same clause, the node samples the sensors serally n the ascendng order of ther selectvty. Ths ensures that the sensors whch are most lkely to satsfy ther predcates and hence, cause the dsjuncton to evaluate to True are sampled frst. The samplng halts as soon as one of the lterals evaluates to True. If we arrange the sensors n ascendng order of ther selectvty and enumerate them and ther assocated predcates, then the expected energy cost of evaluatng a group of lterals assgned to a node belongng to the same clause s: C( P ( s ) )= E ( s ) = Sel Pk ( sk ), where Sel P0 (s 0 ) s k= set equal to. A node evaluates groups of lterals n ascendng order of ther expected energy cost. Note that for the sake of smplcty, ths formula assumes that each group of lterals s evaluated ndependently. In realty however, f a sensor belongs to more than one group of lterals, t s only sampled once and ts readng shared to reduce energy consumpton. 4.3 Push Strategy The Push approach s the most wdely adopted strategy for samplng sensors and evaluatng queres. We cover ths approach for the sake of reference and for dervng cost functons, snce we wll be usng certan aspects of Push-based queryng n our proposed query plans. Durng each epoch of executon, nodes sample ther respectve sensors and create partal evaluaton records whch they transmt to ther parents, smlar to what s descrbed n [8]. Snce each node can be assgned lterals belongng to multple clauses, multple partal evaluaton records can orgnate from a sngle node. Ths entre process of evaluaton uses the slotted approach of tme schedulng as descrbed n [7], where each node dvdes ts epoch nto multple slots and requres ts chldren to respond wthn a certan sub-nterval. Clauses are evaluated n full at the ntermedate node servng as the root of the sub-tree contanng all the nodes nvolved n the clause. For example, n Fgure 3 the fnal evaluaton of clause C C ) takes place at node d. The conjuncton ( 5 32 C42 of clauses also gets evaluated n a smlar manner to gve the fnal result of the query. The roots of all the evaluaton sub-trees get selected durng the query dssemnaton phase, based on routng of clauses and lterals down the cluster-tree network. If a node detects that a clause gets splt up amongst ts chldren, then t knows that t s the root of the evaluaton tree for that clause. Smlarly f a node detects that two or more clauses get routed to dfferent chld nodes then t determnes t s a root of the evaluaton tree for conjuncton of those clauses. The ntermedate routng nodes are capable of suppressng the transfer of partal evaluaton records f they are able to deduce the fnal result based on nformaton contaned n them. For example, a clause

5 evaluaton root node wll not transmt the result f t fnds out that ts clause evaluated to False, thereby causng the entre query to evaluate to False Energy Cost The energy cost of evaluatng a clause usng Push strategy can be calculated by modfyng the expresson gven n secton 4.2 to factor n the cost of evaluatng lterals and assocated network cost for all nodes nvolved n the clause (denoted by the set Node). The N N expected evaluaton cost of a clause ( P ( s )) usng N Node push approach (denoted by EvalCost Push ) s gven by: N N N ( Sel + P N ( s )) NwkCostC ( N) C( P (s )) where, N Node N s the Id of a node belongng to the set N Node, Sel s P N ( 0 ) =,, ( N ( N CN = P s )) and partal clause N N evaluaton cost C( P ( s ) ) s defned n secton 4.3. The sum nsde the box brackets gves the total energy consumed by a node for evaluatng the lterals and transmttng the result over the network f any of the lterals evaluates to True. The fnal summaton s over all members of the Node set. The NwkCost term s calculated based on the number of hops requred to transmt the partal evaluaton record to the next ntermedate node whch wll merge t. For example, referrng to Fgure 3, NwkCost(C ) 2 (the number of hops between nodes N and b ) whereas NwkCost(C 2 ) 3 (the number of hops between nodes N and a ). Fnally, the total energy cost of evaluatng a query Q = ( Cj ) usng push strategy s gven by: j TotalCost Push = FnalAggregatonCost + EvalCost Push( Cj ), where FnalAggregatonCost s the addtonal network cost requred to aggregate partal results obtaned from evaluaton of each clause to obtan the fnal result of the conjuncton. In case the evaluaton tree structure s such that the fnal result can be obtaned as a sde-effect of clause evaluaton (for example, a leftdeep evaluaton tree) then FnalAggregatonCost s equal to Selectve Pull Strategy The order of evaluaton n the Push strategy s governed by the structure of the evaluaton tree whch n turn depends on the topology of the network. The naïve Pull strategy would nvolve pullng all the sensor readngs n parallel and essentally followng the same evaluaton order as above, but such a plan would be of no use snce t wll always have hgher energy cost (due to extra network traffc) and double the latency of the Push strategy. Instead of the naïve approach, we suggest a selectve pull strategy where the samplng of sensors across the network s ordered accordng to the expected cost of evaluatng of clauses nvolvng them and clauses are evaluated n seral order. Consder the example depcted n Fgure 3. For the sake of dscusson, suppose the optmal order of evaluaton obtaned by the query optmzer (based on ascendng cost of evaluaton) s: ( C C2 C3) ( C5 C32 C42) ( C6) ( C2 C4) The selectve pull executon strategy s as follows: The frst step s the query dssemnaton phase as descrbed n secton 4.2, where the entre query s pushed on the network. It has been suggested that for the pull approach, nodes do not need to store query nformaton [0]. However, we feel that for contnuous queres t s more energy effcent and fault tolerant for nodes to store the query nstructons even though they do not execute them wthout the arrval of an explct command from above. The next step nvolves evaluaton of the frst clause n the executon schedule. In the example above, node a whch s the root of the st clause s evaluaton tree, transmts a pull command to nodes b and c. These nodes n turn relay the command to nodes N, N2 and N3. The root does not ssue 3 pull commands rather the number of pull commands ssued (2) s equal to the number of ts chldren t needs to transmt the command to. After each of the nodes receve ther respectve pull commands, they sample ther sensors n the order descrbed n secton 4.2. One mportant thng to note here s that a pull command does not reference a partcular sensor. In fact, when a node receves a pull command t samples sensors assocated wth all the lterals assgned to t. Recall that a node can have multple sensors spread across multple clauses. Hence, adoptng ths strategy s that ths avods the same node from havng to sample ts sensors multple tmes. Ths naturally saves energy consumpton due to networkng but t also saves a sgnfcant amount of energy consumed by sensor samplng. Ths s due to the fact t s far more energy-effcent to ntalze the ADC once and sample all the sensors rather than keep startng and stoppng t for each ndvdual sample. Hence, when a node sends a response to a pull command t transmts multple partal evaluaton records up to the root. Once a node fnshes evaluaton, t transmts the partal records to the root of the evaluaton tree. The partal records get merged on ther way up to the root n the same manner as descrbed n secton 4.3. Once the root receves all the responses and t s able to determne whether the clause evaluated to True or False. If t evaluated to False, the executon of the query for that epoch s termnated snce t results n the entre conjuncton expresson evaluaton to False. If the clause evaluates to True, the root of ths clause s evaluaton tree (node a n the example) transmts the partal evaluaton records of the other clauses to the root of the next clause s evaluaton tree (node d n the example). Ths root n turn examnes the partal evaluaton records and sends pull commands to only those nodes whch have sensors whose readngs are not n any of the partal record. The process of executon contnues n ths manner tll one of the clauses evaluates to False or all clauses evaluate to True, n whch case a response s sent to the query processor va the network coordnator/gateway. We can observe that the effectveness of the selectve pull strategy depends on the order n whch clauses are evaluated across the network. Orderng of sensor samples wth the am of mnmzng acquston costs has been studed before by Madden et. al n [7]

6 but as mentoned n secton 2., ther mechansm only provdes a locally optmal orderng of samplng of sensors connected to the same node rather than a network-wde orderng of all sensors nvolved n the query Energy Cost The cost effectveness of the selectve pull strategy depends not only on the cost of evaluatng a clause but also on the cost of transferrng control from the root of one clause evaluaton tree to the next. The formula for calculatng the cost of evaluatng a clause usng pull s smlar to EvalCost Push descrbed n secton 4.3 except t contans an addtonal term correspondng to the network cost of the pull command. The expected evaluaton cost N N of a clause ( ( P ( s )) ) usng pull approach (denoted N Node by EvalCost Pull ) s gven by: [ NwkCost ) ] N Node ( C N + EvalCost ; where, N s the Id of Push N N a node belongng to the set Node and CN = ( P ( s )). The cost of transferrng control from the root of one evaluaton tree to the next s bascally the network transmsson cost for transferrng the partal records to the other root. Both these peces of nformaton can be easly obtaned by the query processor. Gven an ordered par of two clauses, the servce layer can provde nformaton as to the possble number of partal evaluaton records that need to be transferred based on whch sensors are connected to whch nodes. Furthermore, based on network nformaton obtaned from the ZgBee coordnator/gateway the query processor can also fnd out the cost of transmttng those records from one root node to the other. The total expected energy cost of evaluatng a query Q = ( Cj ) usng pull strategy (where clauses are numbered n j ascendng order of executon), s gven by: TotalCost Pull = p TrfCost ( ) + EvalCost Pull ( Cj ), where TrfCost ( ) > denotes the network energy cost of transferrng control from root of evaluaton tree of clause numbered - to the root of the evaluaton tree of clause numbered. p denotes the probablty that clause wll be executed, that s, t s the probablty that executon control wll transton from clause - to. Ths probablty s dependent on the probablty that the prevous clause - evaluates to True. p = and p = p ' k, (for 2), where p k= P( Ckj = True). Ths j k= mples that p k = - P( Ckj = False) = - P( C kj = False j ). j Hence, p k = - Sel ( s), where A kj s the set of sensors s A kj nvolved n evaluaton of clause Ckj. Note that there s an j assumpton of ndependence of sensor selectvty n the formula for p k. If possble one can refne ths probablty by usng correlaton nformaton about varous phenomena such as the approach used by Deshpande et. al n [2] Determnng the Optmal Order of Executon As dscussed prevously, determnng the optmal order of executon s essental for the selectve pull approach to succeed. The goal here s to determne the optmal order of evaluatng clauses so that the total energy consumpton s mnmzed. Gven a query Q = B. We can vew the executon space as a complete drected-graph G = (V, E) where clause B n the query Q s represented by vertex V. The weght of the edge E(, j) gong from a vertex V to V j s set equal to p' ( TrfCost > j + EvalCostPull(Bj)) where p, EvalCost Pull (B j ) and TrfCost j are defned above. The edge weght gves the expected cost of transtonng from V and V j based on transton probablty p. Also, a dummy node D s added to G such that E(D, ) = EvalCost Pull (B ) and E(, D) = 0, for = to V. Thus, the problem of optmzng the order of clause evaluaton wth the goal of mnmzng total energy consumpton can now be solved as a Travelng Salesman Problem wth startng pont as node D. There have been numerous solutons proposed for the Travelng Salesman Problem such as dynamc programmng for fndng perfect solutons and heurstc technques such as smulated annealng and local search for near-optmal solutons. We decded to use the smulated annealng technque for our system and for the experments descrbed n secton 6, due to the fact that t s relatvely fast and provdes solutons whch are reasonably close to the optmal answer. 4.5 Hybrd Pull-Push Strategy Both the push and selectve pull strateges have ther advantages and dsadvantages. The push strategy provdes greater autonomy to the nodes and works wthout external supervson. It also wll typcally have lower latency of query response as compared to selectve pull. The selectve pull strategy on the other hand, takes nto consderaton the fact that sensng costs now sgnfcantly domnate the total energy consumpton and tres to optmze the order of sensor samplng across the network n order to mnmze energy consumpton. However, ths comes at a cost of greater relance on the network and hgher latency as compared to the push approach, snce each node s subject to external supervson from another node. We feel that one of the best ways to utlze the strong ponts of both push and pull strateges s to adopt a hybrd pull-push approach. The man goal of the hybrd pull-push approach s to mnmze the total energy requred to execute a query n the network whle ensurng that the latency of query response s wthn bounds specfed by the user. In order to acheve ths, the plan utlzes the push approach on a number of sensors based on cost and latency consderatons and utlzes the selectve pull approach on the rest of the sensors. After query dssemnaton, the group of sensors correspondng to a set of clauses havng the lowest evaluaton cost s asked to execute the push strategy. Snce the query s a conjuncton of clauses hence, only f all of the ntally selected clauses evaluate to True, are the other clauses evaluated usng the selectve pull approach. The constructon of a hybrd pull-push plan s descrbed n more detal n secton 4.6, when we dscuss how the query optmzer chooses the best plan of executon.

7 4.5. Energy Cost The energy cost of a hybrd pull-push plan depends on whch of the clauses were evaluated usng push approach and whch were evaluated usng selectve pull. The total energy cost s smply the sum of the energy cost of each clause calculated by applyng the approprate cost formula for the push or pull approach. Suppose n the query n queston n Q = Q = B where the clauses are numbered n the order of executon. Suppose the hybrd plan calls for m clauses to be evaluated usng push and the rest evaluated usng pull, thereby mplyng n ths case that the frst m clauses wll be evaluated usng push. Then the total energy cost of the hybrd pull-push plan s gven by: TotalCost Hybrd = m EvalCost Push B ) n ( + p[ TrfCost( ) + EvalCostPull ( B )] m+ 4.6 Choosng the Best Query Plan The query optmzer generates all three types of query plans dscussed n the precedng sub-sectons and chooses the one whch best mnmzes the energy consumpton whle meetng the user requrements on latency of query response. To ad the query optmzer n makng a decson a user s requred to provde nformaton regardng ts tolerance for latency. Instead of requrng the user to provde a hard number, the query optmzer asks for tolerances n terms of percentage (denoted by L max ). The percentage value represents the magntude by how much the latency can exceed that of the Push approach. If L Push and L Plan respectvely denote the latences for push approach and the plan L that was chosen then, Plan LPush x00 Lmax must hold true. LPush Consder the query Q = B.Then, the latency for the push approach s gven as: L Push = Latency PushFnalAggregaton + LatencyPush( B ) where Latency Push (B ) denotes the latency n recevng a response for clause B f t evaluates to True, and Latency Push FnalAggregaton denotes the latency n generatng the fnal results from results of the clause evaluatons. For the sake of smplcty, these ndvdual latency values can be smply calculated as the total number of hops between the nodes evaluatng B and the root of B s evaluaton tree. The latency for the selectve pull approach s gven as: L Pull = p [ LatencyPull B ) + TrfLatency( ) ] ( where Latency Pull (B ) s calculated as twce the total number of hops between the nodes evaluatng B and the root of B s evaluaton tree. p s as defned n secton TrfLatency ( ) > s the latency n transferrng control from the root of clause (-) s evaluaton tree to clause s evaluaton tree. The latency of a hybrd plan s calculated as the sum of latences due to ts push and pull operatons. If we consder the hybrd pullpush plan from the example gven n secton 4.5, then ts query response latency s gven as: m L Hybrd = LatencyPushFnalAggregaton+ LatencyPush( B ) + p [ LatencyPull ( B ) + TrfLatency( ) ] m+ Gven latency tolerance L max, the query optmzer undertakes the followng steps to determne the optmum query plan: ) Frst t generates a query plan usng the push strategy and calculates the energy cost (TotalCost Push ) and latency (L Push ). 2) Next t generates a query plan usng the selectve pull approach by solvng the optmzaton problem usng smulated annealng and calculates the energy cost (TotalCost Pull ) and latency (L Pull ). 3) Fnally, t generates a hybrd pull-push query plan as follows: Suppose the selectve pull query plan generated for query Q = B n step 2, resulted n a query plan wth the followng order of evaluaton of clauses: B, B 2, B 3,...B n. The query optmzer progressvely replaces the pull acton assocated wth each clause wth push, startng from the frst clause. Each tme t does ths, t recalculates the latency of the plan (L Hybrd ) and checks f ts percentage relatve dfference wth L Push s less than L max or not. Ths process s contnued tll the relatve dfference n latency becomes less than L max. If the fnal hybrd plan conssts of m push based evaluatons followed by (n-m) selectve pull-based evaluatons then the followng holds true: There exsts no k < m such that, k LatencyPushFnalAggregaton+ LatencyPush( B ) + p k+ [ LatencyPull ( B ) + TrfLatency( ) ] Lmax. Fnally, the query optmzer compares the energy costs of all the plans whch meet the user s latency bounds and chooses the one wth the lowest cost. Typcally one would expect that the hybrd pull-push plan wll be always chosen. However, ths may not be true n every case snce the cost-effectveness of the plan depends a lot on energy consumpton characterstcs of the sensors and the sensor platform hardware. Hence, the approach outlned above allows the optmzer to fall back on tradtonal approaches such as Push, f the new strateges do no prove to be more cost-effectve. 4.7 Montorng Plan Performance Snce the query plan s generated based on a snapshot of hstory ts effectveness n mnmzng energy consumpton can decrease over tme due to changng condtons n the deployment envronment. In order to montor the effectveness of the query plan beng executed, each node can keep track of selectvty of ts sensors and calculate the expected cost of evaluaton of lterals assgned to t (usng the formula from secton 4.2). Ths nformaton can be perodcally transmtted up the evaluaton tree as a partal record gettng merged along the way, n the same manner as the query evaluaton records. Ths wll lead to the root of each clause s evaluaton tree to have updated cost estmates for

8 that clause (usng formulas from sectons 4.3. and 4.4.). For selectve pull and pull-push approaches, the total cost also depends on the probablty of transferrng control from one root to another. Hence, each evaluaton tree root also factors nto the cost calculaton, the expected network cost based on the actual transton probablty of transferrng control to the next root n the executon sequence. Fnally, the query processor n the servce layer compares the actual updated cost wth the estmated cost and f requred, regenerates plans and chooses the best one usng more up-to-date selectvty data. The new plan can ether be dssemnated n ts entrety nto the network or the query processor only dssemnates those portons of the new plan whch dffer from the exstng plan. Selectvely addng or removng query executon assgnments from specfc nodes n ths manner, wthout havng to reset the entre query executon process, leads to greater energy effcency and hgher system avalablty. 5. FAULT TOLERANCE Whle fault tolerance s not the man focus of ths paper, we dscuss some mechansms for dealng wth node and network malfunctons, snce falure s an ntegral part of any sensor network. The query executon strateges descrbed n ths paper utlze n-network evaluaton trees and hence, are vulnerable to falure of any of the nodes partcpatng n the evaluaton process or nodes whch are not partcpatng n query evaluaton but are nonetheless playng a vtal role by lnkng up dfferent segments of an evaluaton tree. The followng are possble types of falure that can affect the query executon plans descrbed n ths paper: Node whose sensors are nvolved n evaluaton of a clause fals: In such s case, the ancestor of ths node responsble for mergng ts evaluaton record wll not receve any messages from t. If the node s usng the push approach, there are a number of technques that have been suggested to cope wth falure such as the use of chld caches [8] and Bayesan technques to determne whether the lack of response ndcates suppresson or node falure []. In case the node was usng the pull approach then ts falure wll get detected by the next epoch of executon when a pull command s ssued. Ths s due to the fact that ZgBee ams at provdng relable message delvery through acknowledgement mechansms present n the lnk layer and above. Hence, a sender s able to determne f ts message got delvered or not. The effect of falure of sensors partcpatng n a query depends on the type of query that was ssued. For queres targetng specfc sensors, the falure of one or more of those sensors may result n the query executon beng halted, whereas queres targetng the entre network may not be affected drastcally by such falures. Non-partcpatng ntermedate node fals: In case an ntermedate router node whch s not partcpatng n query evaluaton fals, then ts chld nodes smply re-assocate themselves wth a new parent n the network. Ths s a feature of ZgBee s self-healng characterstcs whch allows the network to cope wth loss of a lmted number of routers wthout affectng network connectvty. Root of evaluaton tree fals: Ths s the most serous type of falure that can affect query plan executon snce the falure of the root wll not only cause the evaluaton of ts clause to fal but mght also lead to the entre query executon gettng stalled dependng upon the locaton of that node n the network. We propose that for each node whch s the root of an evaluaton tree or sub-tree, should nform a small set of ts mmedate neghbors (whch are wthn -hop) about ts status and have them cache all the nformaton necessary to act as a root node. These neghbors are responsble for montorng whether the root s onlne or not. Snce they are only -hop away, the network overhead and network energy cost s not that sgnfcant. When one of the nodes dscovers that the root n ts neghborhood s dead t can take over the role of the root snce t already has all the necessary nformaton. To avod multple nodes from detectng falure at the same tme and becomng roots of the same tree, we can have each node montor the root s health n a round robn fashon for a certan number of contguous epochs. One of the most mportant practcal ssues whch wll occur n the above scenaros s the fact that whenever a node rejons the network t s assgned a dfferent network address by ts new parent. Smlarly, when the root of an evaluaton tree fals and a new root takes over, naturally the network address of the new root won t match the address of the orgnal root. Ths can create sgnfcant problems snce other nodes n the tree wll be unaware of such changes and wll be unable to transmt readngs or commands. Fortunately, ZgBee provdes a soluton to deal wth such ssues n the form of logcal addresses. A logcal address s an applcaton-specfc address (ndependent of the network address) whch can be user-defned and used for communcaton between applcatons. Durng query dssemnaton phase, we can assgn each node n the tree a unque logcal address whch t retans for the duraton of the query lfetme. Hence, even f a node rejons the network by assocatng wth a new parent ts logcal address stll remans the same and gets automatcally mapped to ts new network address. Smlarly, when a node takes over as the root of an evaluaton tree t can changes ts logcal address to that of the deceased root. Ths ensures that t s able to receve evaluaton records from the other nodes n the tree wthout havng to nform them of the change. 6. EXPERIMENTAL ANALYSIS In ths secton, we compare and analyze each of the query plan optons dscussed n ths paper, based on two performance metrcs: energy consumpton and latency of query response. We perform our analyss for two dfferent sensor platforms: the Crossbow MICA2 mote and the Atmel Zlnk RCB. Frst we provde a bref dscusson of experment methodology and then we dscuss and analyze the expermental results. 6. Method of Expermentaton Our experments conssted of smulatng the constructon and nnetwork executon of all the three types of query plans dscussed n ths paper (Push, Selectve Pull and Pull-Push). The data used for performng all the smulatons was sourced from the Lab dataset [3], collected by Intel Berkeley Research Lab. Out of the 54 data logs, 48 were chosen as the remanng ones had ncomplete sets of readngs. Each sensor log contaned approxmately 40,000 readngs and was sorted to ensure that all the readngs are n ascendng order of ther tme stamps. Frst the

9 smulator randomly constructed a set of 5 selecton queres nvolvng multple predcates. Each query conssted of 6 clauses wth each clause contanng anywhere between 3-5 lterals. Each lteral conssted of a range flter predcate assocated wth a specfc sensor and some sensors were nvolved n the evaluaton of multple clauses. Next, for each teraton, the smulator randomly generated an ad-hoc network of sensors nodes (each responsble for the operaton of one or more sensors partcpatng n the query) and generated query plans usng the process descrbed n secton 4.6. Then, t smulated the executon of each plan usng hardware specfcatons of both the MICA2 mote and the Atmel Zlnk RCB. Energy consumpton and latency values correspondng to both hardware platforms were logged and ther fnal values averaged across all teratons. 6.2 Results and Analyss The results are depcted n two sets of graphs. Fgures 4 & 5 provde the energy consumpton plots for push, selectve pull and hybrd pull-push plans and Fgures 6 & 7 show the comparatve latences of query response for each type of plan. play a very mportant role n the determnaton of whch queryng strategy to use and one type of query plan does not ft all hardware confguratons. In [4], Hedemann et. al proposed that data dssemnaton algorthms need to be mapped to applcaton requrements. However, we feel that n addton to that, they also need to be mapped to the target hardware s specfcatons. Hence, the query optmzer needs to be capable of not only detectng key parameters of the target hardware for whch t s generatng a query plan but also be flexble enough to be able to generate multple plans for the same query, but targeted at dfferent hardware platforms. Ths s especally mportant n the case of servce orented sensor platforms lke Atlas whch are desgned to smultaneously run on multple types of sensor platforms usng multple heterogeneous networkng protocols. On a sde note we would also lke to pont out that the energy consumpton of selectve pull plans seem to be hgher than the energy consumpton of hybrd pull-push plans whch use push to evaluate only the frst clause n the executon schedule. Ths can be explaned by the fact that the frst clause s always evaluated wth a probablty of regardless of whch plan s beng used, hence, nstead of pullng readngs for that clause t s more energy effcent to have t executed n a push manner. Fgure 4. Comparng Energy Consumpton of Query Plans for Zlnk RCBs Fgure 4 shows the energy consumpton (n mj) of Zlnk RCB hardware per epoch of executon plotted aganst the number of clauses (0-6) that were evaluated usng push by the query plan. Ths mples that when the number of push clauses s equal to zero, t corresponds to the selectve pull query plan whereas when t s equal to sx, t corresponds to the push query plan. The rest of the values correspond to dfferent versons of the hybrd pull-push plan based on how many clauses are beng executed n push manner (wth the remanng evaluated usng selectve pull). Clearly we can see that the energy consumpton decreases as more push clauses are substtuted wth pull. However, the ncrease n effcency s observed to be stronger n case of the Zlnk RCB (average gan of over 60%) as opposed to the MICA2 mote (average gan of %). Ths s due to the fact that the cost dfferental between network and sensng cost s much larger n case of the Zlnk RCB as compared to the MICA2 mote. Hence, n case of the MICA2 the reducton n energy consumpton due to pullng of sensor samples s somewhat offset by the ncrease network cost due to the pull operatons. Ths s largely due to the slower rado used by the MICA2. The Zlnk RCB on the other hand employs a much faster rado and s able to reduce the mpact of extra network usage. Ths shows that hardware does Fgure 5. Comparng Energy Consumpton of Query Plans for MICA2 motes Fgure 6. Comparatve Latences of Query Plans for Zlnk RCBs

10 Fgures 6 & 7 show the relatve dfference n query response latences of each plan based on the combnaton of push and selectve pull approaches beng appled. The relatve dfference s calculated as a percentage wth respect to latency of the push approach. Selectve pull clearly has the hghest relatve latency amongst all plans snce all the sensors are sampled usng pull commands. Relatve latency decreases as the number of clauses beng evaluated usng push ncreases. Hence, as dscussed before, ths can be utlzed to fnd the rght combnaton of push and pull n order to meet user latency requrements whle keepng the energy cost at a mnmum. One nterestng thng to note from the plots n Fgures 6 & 7 s that some hybrd plans actually have seem to have slghtly lower latency than the push approach. The reason for ths occurrng s that unlke the push approach where all clauses are evaluated n parallel (barrng optmzatons done on ntermedate nodes of the evaluaton tree), the hybrd pull-push approach frst executes a small sub-set of clauses usng push and does not ntate executon of other clauses unless requred. Ths not only enables t to save energy due to reduced number of sensor samplngs but also allows t to a return a result faster snce the number of nodes nvolved n the push evaluaton tree s much lower as compared to the complete push-based executon plan. Fgure 7. Comparatve Latences of Query Plans for MICA2 motes 7. RELATED WORK There s a large body of avalable research proposng technques for queryng sensor data. These approaches can be broadly dvded nto stream-based and acquston-based approaches. The stream-based approaches vew data orgnatng from sensors as a seres of data streams. They assume a pror exstence of sensor data and do not factor n sensor acquston costs. The acqustonbased technques on the other hand closely look at ways to sample sensors and transmttng ther nformaton so that the total energy consumpton s mnmzed. We feel ths paper s more closely related to the acquston-based technques rather than streamng methods hence, the related work covered n ths secton reflects that. The related work relevant to ths paper s dvded nto two broad categores: acquston-based technques for mnmzng the cost of samplng sensors and push-pull mechansms for query executon n sensor networks. In TnyDB, Madden et. al [7] proposed algorthms for mnmzng energy consumpton by optmzng the order of samplng sensors and the predcates beng appled on them usng a seres-parallel graph. However, ther approach was only proposed for orderng sensors connected to the same node rather than all sensors partcpatng n a query. Ths s probably due to the fact that when TnyDB was desgned, network costs were much more sgnfcant than sensor samplng costs. A model-based approach (BBQ) was proposed by Deshpande et. al [2] utlzng a tme-varyng multvarate Gaussan model for processng sensor queres. As dscussed n secton 2., BBQ pulls readngs whenever the model needs to be updated and also utlzes correlaton amongst varous phenomena to select sensors whch are less expensve to sample. Both the abovementoned strateges only look at the tradeoffs based on the cost of samplng one sensor versus another and do not consder the tradeoff between network costs and sensor samplng costs. Hartl et. al [3] descrbe an nference-based technque where only a sub-set of nodes are actvated and the readngs from ther sensors are used to approxmate readngs from other sensors usng Bayesan nference. Ther mechansm was proposed specfcally for obtanng the global average of readng values and s subject to predcton errors due to ncomplete data modelng or sgnfcant fluctuaton of readngs. However, the combnaton of our approach and model-based technques such as those lsted above can potentally provde a more optmal soluton n the future. The push-pull approach for query executon has been appled by a number of query processng strateges for sensor networks. However, as we shall see, these mechansms manly seek to mnmze the network cost, based on the assumpton that t always sgnfcantly outweghs the sensor samplng cost. Trgon et. al [2] propose a hybrd push-pull mechansm where sensors have ther readngs pushed to ntermedate nodes (called vew nodes), from where they are pulled by the query processor based on query requrements. However, ther approach only seeks to reduce the network cost and latency of answerng queres and t does not factor n the cost of samplng sensors (as evdenced by the fact that t uses the push approach to sample sensors). In [9], Shenker et. al propose a structured hybrd push-pull mechansm where data s pushed from sensors onto ntermedate nodes and stored usng geographc hash tables. The snk nodes apply the same hash functon to determne where specfc data s stored and use the pull approach to retreve data. In contrast, Lu et. al [6] use an unstructured push-pull approach (called Comb-Needle) where queres are dssemnated along the horzontal lnes of a sensor grd (vsualzed as a comb wth horzontal teeth) and data s ndependently pushed along the vertcal lnes of a sensor grd (vsualzed as vertcal needles). However, all these hybrd pushpull mechansms mentoned above requre nodes to proactvely push sensor readngs to ntermedate nodes n the network and hence, are fundamentally dfferent from the push-pull approach proposed n ths paper. In fact, n the context of actual sensor samplng, all of them can be classfed as mechansms whch use the push strategy. 8. CONCLUSIONS AND FUTURE WORK In ths paper, we looked at how and why sensor samplng costs (as opposed to network cost) can become the major contrbutor to the total energy consumpton of sensor nodes, especally amongst the new generaton of sensor platforms equpped wth hgh speed wreless rados havng low power consumpton. To address ths ssue, we proposed query optmzatons nvolvng the utlzaton of push and modfed pull approaches wth the goal of mnmzng