Many-to-Many Aggregation for Sensor Networks

Adam Silberstein and Jun Yang

Duke University

23/4/19 1

Introduction

• What is a sensor network?– A collection of nodes– Node components

• Sensors (e.g. temperature)• Radio (wireless) communication• Battery power

23/4/19 2

Crossbow Mica2 WiSARD

Sensor Network Tasks

23/4/19 3

ag

hc

e

i

m

jl

d

fk

b

k

l

m

fk(vb,vc,vd)

fl(va,vb,ve)

fm(vb,vc)

Many-to-One TransmissionMany-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

23/4/19 4

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

23/4/19 5

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

23/4/19 6

i j l

k

m

vi

a

b

c

i jwava+wbvb+wcvc

Multicast vs. Aggregation

• Intuitions– Favor multicast near source

• Many destinations per value

– Favor aggregation near destination• Destination has many values

23/4/19 7

a

b

ci j

wk,ava+wk,bvb+wk,cvc+wk,dvd

d

l

m

k

wl,ava+wl,bvb+wl,cvc

wm,ava

raw: va

agg: wk,bvb+wk,cvc+wk,dvd

agg: wl,bvb+wl,cvc

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

23/4/19 8

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

23/4/19 9

Single-Edge Problem

23/4/19 10

a b c d

k 1 1 1 1

l 1 1 1

m 1

SourcesDest.

S i→j

D i→j

a

b

ci j

d

l

m

k wk,ava+wk,bvb+wk,cvc+wk,dvd

wl,ava+wl,bvb+wl,cvc

wm,ava

~ i!j denotes producer-consumer relationship between i and j

Reduction

23/4/19 11

a b c d

k 1 1 1 1

l 1 1 1

m 1

SourcesDest.

S i→j

D i→j

c

a

b

dm

l

k

Sources Destinations

weighted bipartitevertex 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

1c

1 1 1 l

Global Solution

• Can we solve edges independently?

23/4/19 12

i

c

a

b

y

x

w

j k

d

c

a

b

y

x

w

d z

{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

upstream downstream

Global Solution II

• Theorem: Optimal solutions for the individual MVC problems at each edge combine for consistent global plan

• Implications1. 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!

23/4/19 13

Plan Implementation

• For each s~d, 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,n’i

• Space consumed by tables no more than by pure multicast or aggregation plan

23/4/19 14

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

23/4/19 15

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

23/4/19 16

a b c d eoptimize optimize optimize optimize

a b c d e

optimizeoptimize

??

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

23/4/19 17

Varying # of Destinations

23/4/19 18

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

Varying # Sources

23/4/19 19

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

Suppression Override Policies

23/4/19 20

• 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

23/4/19 21

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/4/19 22

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

23/4/19 23

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

23/4/19 24