ManytoMany Aggregation for Sensor Networks

1
Many-to-Many Aggregation for Sensor Networks

• Adam Silberstein and Jun Yang
• Duke University

2
Introduction

• What is a sensor network?
• A collection of nodes
• Node components
• Sensors (e.g. temperature)
• Radio (wireless) communication
• Battery power

Crossbow Mica2
WiSARD
3
Sensor Network Tasks
a
b
g
m
h
c
i
e
d
j
l
f
k
4
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

5
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
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
wavawbvbwcvc
c
7
Multicast vs. Aggregation

• Intuitions
• Favor multicast near source
• Many destinations per value
• Favor aggregation near destination
• Destination has many values

raw va agg wk,bvbwk,cvcwk,dvd agg
wl,bvbwl,cvc
8
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

9
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

10
Single-Edge Problem
S i?j
Sources
Dest.
i!j denotes producer- consumer relationship
between i and j
D i?j
11
Reduction
S i?j
Sources
Dest.
D i?j
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

12
Global Solution

• Can we solve edges independently?

d
upstream
downstream
i
j
k
b,c wont 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

13
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!

14
Plan Implementation

• For each sd, store wd,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,wd,si
• Partial aggregation table hd,c,md,gi
• Outgoing message table hg,c,ni
• Space consumed by tables no more than by pure
  multicast or aggregation plan

15
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

16
Dynamic Features

• Milestone
• Rigid solution burdens routing layer
• Dont solve every routing hop
• Instead, set milestone nodes
• Optimize over virtual edges, not physical edges

17
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

18
Varying of Destinations

• Fix number of sources per destination, vary
  number of destinations
• Fewer destinations favors aggregation
• Optimal makes best decision at all settings

19
Varying Sources

• Fix number of destinations, vary number of
  sources per
• Fewer sources favors multicast
• Optimal is again best at all settings

20
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

21
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

22
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

23
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

24
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,ni
• Send message g with c components to node n
• Space consumed by tables no more than by pure
  multicast or aggregation plan