1 / 24

i CAST

iCAST / TRUST Collaboration. A Declarative Sensor Network Architecture. Presenter ： David Chu 2007 June 5. i CAST. Leach's Storm Petrel. context. Sensor Networks 10’s – 100’s – 1000’s – 10,000’s. motivation. programming sensor networks is difficult!.

idalee
Télécharger la présentation

i CAST

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. iCAST / TRUSTCollaboration A Declarative Sensor Network Architecture Presenter：David Chu2007 June 5 iCAST

  2. Leach's Storm Petrel context 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 s e n s o rn e t w o r k s network design data management

  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 s e n s o rn e t w o r k s ( DSN ) network design data management

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

  11. lines of code

  12. Day Fire Harvard Burn Site application deployment (underway) [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.

  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 Shared State Server 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) . . . client server comm cost similar to database partitioning and normalization problems! storage cost

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

  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

More Related