1. CAST i CAST iCAST / TRUST Collaboration Presenter ： David Chu 2007 June 5 A Declarative Sensor Network Architecture

2. context Leach's Storm Petrel Sensor Networks 10’s – 100’s – 1000’s – 10,000’s

3. motivation programming sensor networks is difficult! building entire sensor systems is even harder!!

4. inspiration data management network design s e n s o r n e t w o r k s

5. inspiration : data management declarative is widely used in data management –relational databases –spreadsheets –abstract “what” from “how” (Sensor-Network-As-Database)

6. inspiration : network design declarative is new idea in networking –compact –flexible –analyzable, optimizable –Internet Routing, Overlays built declaratively (the P2 project)

7. inspiration data management network design s e n s o r n e t w o r k s ( DSN )

8. what we did adapted declarative language built compiler & runtime for sensornets wrote declarative examples

9. working programs geographic routing tracking localization link estimator multi-hop collection tree routing

10. P. Levis, N. Patel, D. Culler, S. Shenker. "Trickle: A Self- Regulating Algorithm for Code Propagation and Maintenance in Wireless Sensor Networks." NSDI 2004. … from original Trickle paper… DSN specification 10x6 topology 30x2 topology

11. lines of code

12. [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 application deployment (underway)

13. how much declarative? experiences thus far and current work

14. 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

15. architectural flexibility dsn can… –describe entire system stack application + network + mac layers –naturally expose abstractions –freely mix and match with outside libraries

16. resource management memory processor energy

17. implications of declarative concise, intuitive programming 1 specification, N possible execution plans ?

18. distributed protocol state Client State Server State Shared State

19. a typical protocol Client control block Server control block ? ? ? ? ? ? ? Shared variables

20. state proxy... All nodes involved in a distributed protocol (client, server and nodes along path) storage cost client server comm cost similar to database partitioning and normalization problems!

21. routing layer state proxying Sensornet Internet nexthop forwarding table D C A B source route to D distance vector routing A: D via B B: D via C C: D via D

22. conclusion sensor networks → data + communication programs work just as well with lines of code + architectural flexibility + resource management toward automated system optimizations

23. thanks collaborators Joe Hellerstein, Scott Shenker, Ion Stoica Arsalan Tavakoli, Lucian Popa Tsung-Te Lai Phil Levis, Jung Woo Lee, Aby John Daniel Malmon

24. 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