Many-to-Many Aggregation for Sensor Networks Adam Silberstein and Jun Yang Duke University 6/25/20151

Introduction What is a sensor network? –A collection of nodes –Node components Sensors (e.g. temperature) Radio (wireless) communication Battery power 6/25/20152 Crossbow Mica2WiSARD

Sensor Network Tasks 6/25/20153 a g hc e i m j l d f k b k l m f k (v b,v c,v d ) f l (v a,v b,v e ) f m (v b,v c ) Many-to-One Transmission Many-to-Many Transmission

In-Network Control Multiple sources, multiple destinations –Each destination node computes aggregate using readings from source nodes Sources transmit directly to destinations –Aggregate used as control signal to dictate behavior at destination i.e. adjust sampling rate 6/25/20154

Motivation Why spend transmission to control sensor sampling? –Radio typically dominant energy consumer –High-cost sensors: sap flux, swivel cameras Use low-cost sensors to tune sampling rates –Sap flux is negligible when soil moisture is low –Activate camera if motion sensors are triggered Why not out-of-network control? –Long round trips to root and back –Overtax nodes near root with forwarding 6/25/20155

Computing Aggregates In-Network Multicast –Sources required by multiple destinations –Build tree rooted at each source –Transmit value in “raw” form In-network Aggregation –Destination requires multiple sources –Build partial aggregates en-route TAG [Madden et al. 02] –Aggregate destination- specific 6/25/20156 ijl k m vivi a b c ij wava+wbvb+wcvcwava+wbvb+wcvc

Multicast vs. Aggregation Intuitions –Favor multicast near source Many destinations per value –Favor aggregation near destination Destination has many values 6/25/20157 a b c ij w k,a v a +w k,b v b +w k,c v c +w k,d v d d l m k w l,a v a +w l,b v b +w l,c v c w m,a v a raw: v a agg: w k,b v b +w k,c v c +w k,d v d agg: w l,b v b +w l,c v c

Problem Definition Input: –Set of sources S, destinations D s ~ d denotes s is required by d –Algebraic aggregate per destination f d (v s 1,…,v s n ) = e d (m d ({w d,s 1 (v s 1 ),…,w d,s n (v s n )})) –V s n : source reading –w d,s n : pre-aggregate function –m d : merging function –e d : evaluator function Output: –Transmission plan for each network edge 6/25/20158

Edge Workloads How do we determine the workload for each edge? Multicast trees from each source dictate how data are routed –Minimality Trees have no extra edges –Sharing If two trees have paths between same pair of nodes, paths are identical 6/25/20159

Single-Edge Problem 6/25/ abcd k1111 l111 m1 Sources Dest. S i→j D i→j a b c ij d l m k w k,a v a +w k,b v b +w k,c v c +w k,d v d w l,a v a +w l,b v b +w l,c v c w m,a v a ~ i!j denotes producer- consumer relationship between i and j

Reduction 6/25/ abcd k1111 l111 m1 Sources Dest. S i→j D i→j c a b d m l k SourcesDestinations weighted bipartite vertex cover Problem: Find minimal set of vertices such that all edges have one selected vertex Implications  Select source = multicast: value transmitted raw over edge, satisfying “column”  Select destination = aggregate: values aggregated and transmitted over edge, satisfying “row”  Each selection contributes marginal cost of 1 to message 1 1 c 11 1 l

Global Solution Can we solve edges independently? 6/25/ i c a b y x w j k d c a b y x w dz {b,c} won’t arrive at j to transmit to k! Edge solutions must be consistent across network – Raw value required for consumption at downstream edge must be produced by upstream edge upstreamdownstream

Global Solution II Theorem: Optimal solutions for the individual MVC problems at each edge combine for consistent global plan Implications 1.Solve global problem by solving edges in isolation Bipartite vertex cover solvable in polynomial time 2.When problem changes due to failures, route adjustments, workload adjustments, etc... Only affected edges must be re-optimized! 6/25/201513

Proof Sketch Goal: Prove if a source is selected in mvc at downstream edge, it will have been selected in mvc at upstream edge Upstream-to-downstream transition cases –(U,V,E): (sources, destinations, incident edges) –(X,Y,F): (new sources, destinations, edges) 1.Destinations removed (diverging multicast) Lemma A: If source vertex u 2 mvc(U,V,E), then u 2 mvc(U,V [ Y, E [ F) 2.Sources added (converging multicasts) Lemma B: If source vertex u 2 mvc(U [ X, V, E [ F), then u 2 mvc(U,V,E) Prove A,B simultaneously through induction Prove s 2 downstream ! s 2 upstream 6/25/201514

Plan Implementation For each s~d, store w d,s once in network –At edge where raw to aggregate transition occurs 4 lightweight tables per node htuple_typei –Raw table: hs,gi –Pre-aggregation table: hs,d,w d,s i –Partial aggregation table: hd,c,m d,gi –Outgoing message table: hg,c,n’i Space consumed by tables no more than by pure multicast or aggregation plan 6/25/201515

Dynamic Features Suppression –Sources only transmit when readings change –Intuition: High suppression favors raw values –A node may override local solution Raws to be aggregated can be sent raw instead –Locally optimal decision, but must stay raw until destinations, risking sub-optimal behavior downstream 6/25/201516

Dynamic Features Milestone –Rigid solution burdens routing layer –Don’t “solve” every routing hop –Instead, set milestone nodes Optimize over virtual edges, not physical edges 6/25/ abcde optimize abcde ??

Experimental Setup Simulation of Mica2 Motes –Accounting of bytes sent + received 68 nodes located as in 2003 Great Duck Island deployment (~20000 m 2 ) Four Algorithms –Flood Each source transmits to ALL nodes –Multicast –Aggregation –Optimal 6/25/201518

Varying # of Destinations 6/25/ Fix number of sources per destination, vary number of destinations Fewer destinations favors aggregation Optimal makes best decision at all settings

Varying # Sources 6/25/ Fix number of destinations, vary number of sources per Fewer sources favors multicast Optimal is again best at all settings

Suppression Override Policies 6/25/ Policies dictate how much better locally optimal solution must be Conservative (local must be dramatically better) gives benefit of of override at high suppression with little penalty at low

Conclusion More sophisticated applications should push decision-making into network Many-to-many aggregation generalizes in- network control Solving optimal transmission over each edge reduces to bipartite VC –Per-edge optimal solutions gives globally optimal and consistent solution Override and milestone features make many-to- many tunable to deployment 6/25/201522

Motivation Radio transmission costs dominant over instructions, simple sensing –Minimize number, size of messages Expensive sensors : sap flux, swivel cameras –Spend on messaging to save on sensing –Limit sampling using cheaper sensors Sap flow negligible at night, at low soil moisture Operate camera only when sound detected 6/25/201523

Approaches Out-of-network control –All readings sent to root; root re-tasks nodes –Problems Risk transmitting over many hops Overtax nodes nearest the root In-network control –Define aggregate functions computed in-network Each destination requires multiple source inputs –Advantage: Distribute decision-making within network –In data collection applications, allows batching No need for real-time updates 6/25/201524

Tables 4 lightweight tables per node htuple_typei –Raw table: hs,gi Raw value s in outgoing message g –Pre-aggregation table: hs,d,w d,s i Raw s aggregated using w d,s for destination d –Partial aggregation table: hd,c,m d,gi Apply m d to merge c records for dest. d in message g –Outgoing message table: hg,c,n’i Send message g with c components to node n’ Space consumed by tables no more than by pure multicast or aggregation plan 6/25/201525