240 likes | 347 Views
Many-to-Many Aggregation for Sensor Networks. Adam Silberstein and Jun Yang Duke University. Introduction. What is a sensor network? A collection of nodes Node components Sensors (e.g. temperature) Radio (wireless) communication Battery power. Crossbow Mica2. WiSARD.
E N D
Many-to-Many Aggregation for Sensor Networks Adam Silberstein and Jun Yang Duke University
Introduction • What is a sensor network? • A collection of nodes • Node components • Sensors (e.g. temperature) • Radio (wireless) communication • Battery power Crossbow Mica2 WiSARD
Sensor Network Tasks b a g m c h m fm(vb,vc) i e d j l l fl(va,vb,ve) f k k fk(vb,vc,vd) Many-to-Many Transmission Many-to-One 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
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
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 k i j l vi m a b i j wava+wbvb+wcvc c
Multicast vs. Aggregation • Intuitions • Favor multicast near source • Many destinations per value • Favor aggregation near destination • Destination has many values a k wk,ava+wk,bvb+wk,cvc+wk,dvd b i j l wl,ava+wl,bvb+wl,cvc c m wm,ava raw: va agg: wk,bvb+wk,cvc+wk,dvd agg: wl,bvb+wl,cvc d
Problem Definition • Input: • Set of sources S, destinations D • s ~ d denotes s is required by d • Algebraic aggregate per destination • fd(vs1,…,vsn) = ed(md({wd,s1(vs1),…,wd,sn(vsn)})) • Vsn: source reading • wd,sn: pre-aggregate function • md: merging function • ed: evaluator function • Output: • Transmission plan for each network edge
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
Single-Edge Problem wk,ava+wk,bvb+wk,cvc+wk,dvd wl,ava+wl,bvb+wl,cvc wm,ava a S i→j k Sources b Dest. ~ i!j denotes producer- consumer relationship between i and j i j l c D i→j m d
Reduction S i→j • 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 Sources Dest. 1 D i→j weighted bipartite vertex cover l 1 1 1 1 c Sources Destinations a k b l c m d
Global Solution • Can we solve edges independently? d upstream downstream i j k {b,c} won’t arrive at j to transmit to k! a w a w b x b x • Edge solutions must be consistent across network • – Raw value required for consumption at downstream edge must • be produced by upstream edge c y c y d z
Global Solution II • Theorem: Optimal solutions for the individual MVC problems at each edge combine for consistent global plan • Implications • Solve global problem by solving edges in isolation • Bipartite vertex cover solvable in polynomial time • When problem changes due to failures, route adjustments, workload adjustments, etc... • Only affected edges must be re-optimized!
Plan Implementation • For each s~d, store wd,sonce 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,wd,si • Partial aggregation table: hd,c,md,gi • Outgoing message table: hg,c,n’i • Space consumed by tables no more than by pure multicast or aggregation plan
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
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 a b c d e a b c d e optimize optimize optimize optimize optimize ? ? optimize
Experimental Setup • Simulation of Mica2 Motes • Accounting of bytes sent + received • 68 nodes located as in 2003 Great Duck Island deployment (~20000 m2) • Four Algorithms • Flood • Each source transmits to ALL nodes • Multicast • Aggregation • Optimal
Varying # of Destinations • Fix number of sources per destination, vary number of destinations • Fewer destinations favors aggregation • Optimal makes best decision at all settings
Varying # Sources • Fix number of destinations, vary number of sources per • Fewer sources favors multicast • Optimal is again best at all settings
Suppression Override Policies • 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
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
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
Tables • 4 lightweight tables per node htuple_typei • Raw table:hs,gi • Raw value s in outgoing message g • Pre-aggregation table: hs,d,wd,si • Raw s aggregated using wd,s for destination d • Partial aggregation table: hd,c,md,gi • Apply md 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