Programming Vast Networks of Tiny Devices

Programming Vast Networks of Tiny Devices

David Culler University of California, Berkeley

Intel Research Berkeley

http://webs.cs.berkeley.edu

11/14/2002 NEC Intro

Programmable network fabric • Architectural approach

– new code image pushed through the network as packets– assembled and verified in local flash– second watch-dog processor reprograms main controller

• Viral code approach (Phil Levis)– each node runs a tiny virtual machine interpreter– captures the high-level behavior of application domain as

individual instructions– packets are “capsule” sequence of high-level instructions– capsules can forward capsules

• Rich challenges– security– energy trade-offs– DOS

pushc 1 # Light is sensor 1sense # Push light readingpushm # Push message bufferclear # Clear message bufferadd # Append val to buffersend # Send message using AHRforw # Forward capsulehalt #


Mate’ Tiny Virtual Machine

• Comm. centric stack machine

– 7286 bytes code, 603 bytes RAM

– dynamicly typed• Four context types:

– send, receive, clock, subroutine (4)

– each 24 instructions• Fit in a single TinyOS AM

packet– Installation is atomic– Self-propagating

• Version information

0 1 2 3

SubroutinesClock

SendR

eceive

Events

gets/sets

Code

OperandStackReturnStack

PC MateContext

Network Programming Rate

0%20%

40%60%

80%100%

0 20 40 60 80 100 120 140 160 180 200 220 240

Time (seconds)

Perc

ent

Prog

ram

med


Case Study: GDI• Great Duck Island application• Simple sense and send loop• Runs every 8 seconds – low duty cycle• 19 Maté instructions, 8K binary code• Energy tradeoff: if you run GDI application for

less than 6 days, Maté saves energy


Higher-level Programming?• Ideally, would specify the desired global

behavior• Compilers would translate this into local

operations

• High-Performance Fortran (HPF) analog– program is sequence of parallel operations on large matrices– each of the matrices are spread over many processors on a

parallel machine– compiler translates from global view to local view

» local operations + message passing– highly structured and regular

• We need a much richer suite of operations on unstructured aggregates on irregular, changing networks


Sensor Databases – a start• Relational databases: rich queries

described by declarative queries over tables of data

– select, join, count, sum, ...– user dictates what should be computed– query optimizer determines how – assumes data presented in complete, tabular form

• First step: database operations over streams of data

– incremental query processing

• Big step: process the query in the sensor net

– query processing == content-based routing?– energy savings, bandwidth, reliability

App

Sensor Network

TinyDB

Query, Trigger

Data

SELECT AVG(light) GROUP BY roomNo


Motivation: Sensor Nets and In-Network Query Processing

• Many Sensor Network Applications are Data Oriented

• Queries Natural and Efficient Data Processing Mechanism– Easy (unlike embedded C code)– Enable optimizations through abstraction

• Aggregates Common Case– E.g. Which rooms are in use?

• In-network processing a must– Sensor networks power and bandwidth constrained– Communication dominates power cost– Not subject to Moore’s law!


SQL Primer

• SQL is an established declarative language; not wedded to it– Some extensions clearly necessary, e.g. for sample rates

• We adopt a basic subset:

• ‘sensors’ relation (table) has– One column for each reading-type, or attribute– One row for each externalized value

» May represent an aggregation of several individual readings

SELECT {aggn(attrn), attrs} FROM sensorsWHERE {selPreds}GROUP BY {attrs}HAVING {havingPreds}EPOCH DURATION s

SELECT AVG(light) FROM sensors WHERE sound < 100GROUP BY roomNoHAVING AVG(light) < 50


TinyDB Demo (Sam Madden)

Joe Hellerstein, Sam Madden, Wei Hong, Michael Franklin


Messages/ Epoch vs. Network Diameter

0

500

1000

1500

2000

2500

3000

10 20 30 40 50Network Diameter

Mes

sage

s /

Epoc

h

No GuessGuess = 50Guess = 90Snooping

Bytes / Epoch vs. Network Diameter

0

10000

20000

30000

40000

50000

60000

70000

80000

90000

100000

10 20 30 40 50Network Diameter

Avg.

Byt

es /

Epo

ch

COUNTMAXAVERAGEMEDIANEXTERNALDISTINCT

Tiny Aggregation (TAG) Approach

• Push declarative queries into network

– Impose a hierarchical routing tree onto the network

• Divide time into epochs• Every epoch, sensors evaluate query

over local sensor data and data from children

– Aggregate local and child data– Each node transmits just once per epoch– Pipelined approach increases throughput

• Depending on aggregate function, various optimizations can be applied

hypothesis testing

http://banner.arttoday.com/PD-0025311/text.click


Aggregation Functions• Standard SQL supports “the basic 5”:

– MIN, MAX, SUM, AVERAGE, and COUNT• We support any function conforming to:

Aggn={fmerge, finit, fevaluate}Fmerge{<a1>,<a2>} <a12>finit{a0} <a0>Fevaluate{<a1>} aggregate value(Merge associative, commutative!)Example: AverageAVGmerge {<S1, C1>, <S2, C2>} < S1 + S2 , C1 + C2>AVGinit{v} <v,1>AVGevaluate{<S1, C1>} S1/C1

Partial Aggregate


Query Propagation

• TAG propagation agnostic– Any algorithm that can:

» Deliver the query to all sensors» Provide all sensors with one or

more duplicate free routes to some root

• simple flooding approach– Query introduced at a root; rebroadcast

by all sensors until it reaches leaves– Sensors pick parent and level when they

hear query– Reselect parent after k silent epochs

Query

P:0, L:1

2

1

5

3

4

6

P:1, L:2

P:1, L:2

P:3, L:3

P:2, L:3

P:4, L:4


Illustration: Pipelined Aggregation

1

2 3

4

5

SELECT COUNT(*) FROM sensors

Depth = d



1 2 3 4 5

1 1 1 1 1 1

1

2 3

4

51

1

11

1Sensor #

Epoc

h #

Epoch 1SELECT COUNT(*) FROM sensors



1 2 3 4 5

1 1 1 1 1 1

2 3 1 2 2 1

1

2 3

4

51

2

21

3Sensor #

Epoc

h #




1 2 3 4 5

1 1 1 1 1 1

2 3 1 2 2 1

3 4 1 3 2 1

1

2 3

4

51

2

31

4Sensor #

Epoc

h #




1 2 3 4 5

1 1 1 1 1 1

2 3 1 2 2 1

3 4 1 3 2 1

4 5 1 3 2 1

1

2 3

4

51

2

31

5Sensor #

Epoc

h #




1 2 3 4 5

1 1 1 1 1 1

2 3 1 2 2 1

3 4 1 3 2 1

4 5 1 3 2 1

5 5 1 3 2 1

1

2 3

4

51

2

31

5Sensor #

Epoc

h #



Discussion• Result is a stream of values

– Ideal for monitoring scenarios• One communication / node / epoch

– Symmetric power consumption, even at root• New value on every epoch

– After d-1 epochs, complete aggregation• Given a single loss, network will recover after at most d-1

epochs• With time synchronization, nodes can sleep between

epochs, except during small communication window• Note: Values from different epochs combined

– Can be fixed via small cache of past values at each node– Cache size at most one reading per child x depth of tree

1

2 34

5


Testbench & Matlab Integration

• Positioned mica array for controlled studies

– in situ programming– Localization (RF, TOF)– Distributed Algorithms– Distributed Control– Auto Calibration

• Out-of-band “squid” instrumentation NW

• Integrated with MatLab– packets -> matlab events– data processing– filtering & control


Acoustic Time-of-Flight Ranging

• Sounder/Tone Detect Pair• Emit Sounder pulse and RF message• Receiver uses message to arm Tone

Detector• Key Challenges

–Noisy Environment –Calibration

• On-mote Noise Filter• Calibration fundamental to “many

cheap” regime» variations in tone frequency and amplitude,

detector sensitivity• Collect many pairs

– 4-parameter model for each pair–T(A->B, x) = OA + OB + (LA + LB )x–OA , LA in message, OB, LB local

no calibration: 76% error

joint calibration: 10.1% errorjoint calibration: 10.1% error

Programming Vast Networks of Tiny Devices

Documents

Transcript of Programming Vast Networks of Tiny Devices