Programming Vast Networks of Tiny Devices David Culler University of California, Berkeley Intel...

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

SubroutinesClo

ck

Sen

d

Receive

Events

gets/sets

Co

de

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)

Per

cen

t P

rog

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 50

Network Diameter

Messag

es /

Ep

och

No GuessGuess = 50Guess = 90Snooping

Bytes / Epoch vs. Network Diameter

0

10000

20000

30000

40000

50000

60000

70000

80000

90000

100000

10 20 30 40 50

Network Diameter

Avg

. B

yte

s /

Ep

och

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 testinghypothesis 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: Average

AVGmerge {<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

5

1

1

11

1

Sensor #

Ep

och

#

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

5

1

2

21

3

Sensor #

Ep

och

#




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

5

1

2

31

4

Sensor #

Ep

och

#




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

5

1

2

31

5

Sensor #

Ep

och

#




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

5

1

2

31

5

Sensor #

Ep

och

#



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 3

4

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% errorno calibration: 76% error

joint calibration: 10.1% errorjoint calibration: 10.1% errorjoint calibration: 10.1% errorjoint calibration: 10.1% error

Date post:	18-Dec-2015
Category:	Documents
View:	215 times
Download:	0 times

Programming Vast Networks of Tiny Devices David Culler University of California, Berkeley Intel...

Documents