cast i cast icast / trust collaboration presenter ： david chu 2007 june 5 a declarative sensor...

iCAST

iCAST / TRUSTCollaboration

Presenter：David Chu2007 June 5

A Declarative Sensor Network Architecture

context

Leach's Storm Petrel

Sensor Networks 10’s – 100’s – 1000’s – 10,000’s

motivation

programming sensor networks is difficult!

building entire sensor systems is even harder!!

inspiration

data management network design

s e n s o r n e t w o r k s

inspiration : data management• declarative is widely used in data

management– relational databases– spreadsheets– abstract “what” from “how”

• (Sensor-Network-As-Database)

inspiration : network design• declarative is new idea in networking

– compact– flexible– analyzable, optimizable– Internet Routing, Overlays built declaratively

• (the P2 project)

inspiration

data management network design

s e n s o r n e t w o r k s

( DSN )

what we did

• adapted declarative language

• built compiler & runtime for sensornets

• wrote declarative examples

working programsgeographic routing

tracking

localization

link estimator

multi-hop collection

tree routing

… from original Trickle paper … DSN specification

10x6 topology

30x2 topology

lines of code

[Above] The locations of the 2005-2006 and 2006-2007 debris flow deployment sites.[Top Right] Smoke from the Day Fire. [Middle Right] Recently burned hillside in Burbank, CA was the site of two debris flows in 2005-2006 Winter season. [Bottom Right] Base of the channel after debris flow with remaining sediment. [Bottom Left] Burn-resilient vegetation is quickly recovering just a few months after the fires and debris flows.

Harvard Burn Site

Day Fire

applicationdeployment(underway)

how much declarative?

experiences thus far and current work

a declarative architecture• why rethink the architecture?

– disparate application requirements

– breaking of traditional abstraction boundaries

• what are the implications?

– architectural flexibility is essential

– put resource management in user’s hands

architectural flexibility

• dsn can…

– describe entire system stack• application + network + mac layers

– naturally expose abstractions

– freely mix and match with outside libraries

resource management

• memory

• processor

• energy

implications of declarative

• concise, intuitive programming

• 1 specification,N possible execution plans

ü

?

distributed protocol state

Client State Server StateShared State

a typical protocol

Client control block

Server control block

?

?

?

?

?

?

?

Shared variables

state proxy

. . .

All nodes involved in a distributed protocol(client, server and nodes along path)

storage cost

client server

commcost

similar to database partitioningand normalization problems!

routing layer state proxying

Sensornet

Internetnexthop forwarding table

D

C A

B

source route to Ddistance vector routing

A: D via B

B: D via C

C: D via D C: D via D

conclusion

• sensor networks→ data + communication

• programs work just as well with lines of code

• + architectural flexibility+ resource management

• toward automated system optimizations

thanks

collaborators

Joe Hellerstein, Scott Shenker, Ion Stoica

Arsalan Tavakoli, Lucian Popa

Tsung-Te Lai

Phil Levis, Jung Woo Lee, Aby John

Daniel Malmon

trade-offs• the declarative approach

– doesn’t outperform hand-tuned

– no real-time guarantees

• implementation limitations

– only P (not NP) programs

– handling opaque data objects