Berkeley dsn declarative sensor networks problem David Chu, Lucian Popa, Arsalan Tavakoli, Joe Hellerstein approach related dsn architecture status  B. T. Loo, et al.’s P2 and Declarative Networking Project  TinyDB, SNACK, Mate, …  Apps: Tracking, Trickle, Tree Collection, Dissemination  Primary predicates: Timers, LEDs, Link Tables, Internal Temperature  Evaluating against hand-tuned nesC and declarative TinyDB  Adding more compiler optimizations to better use resources  Thanks to: Phil Levis, Scott Shenker, Ion Stoica the central process of the sensor network is to manage the generation, transformation and movement of data; – use snlog, a deductive declarative query language, as the systems language for sensor networks. what is snlog? Benefits  Concise & powerful description of the entire system stack  Many additional benefits… (see “what is snlog” below) Questions  Can we provide an energy- and resource-efficient runtime?  Is it hard to program declaratively? 32 nd VLDB September 2006 Seoul, Korea Example snlog App Combination of:  rules (CL1)  facts (CL2-CL4)  queries (Query) Why snlog?  Data manipulation is central to sensor networks  Concise declarations for rapid development  Type safety, yet very flexible. Spectrum of sensor network programming systems TinyDB + Easy to use + Safe - Lacks expressiveness nes C + Flexible - Dangerous - Global behavior unclear - Not amenable to global optimizations ? Can we simultaneously capture the benefits of both high & low level languages for building sensor network systems? CL1: Oid, Obj) :− Oid), Oid), Oid, Obj). Query: Oid, Obj). base application rules CL2: oid). CL3: oid). CL4: oid). collection facts CL2: oid). CL3: oid). CL4: oid). dissemination facts + ( ) or similar store() facts not shown VC: :- V2 > V1, ALTERNATIVE: VC1: :- VC2: :- V1<V2. VC3: :- V1>V2. VC4: :- VC5: :- VC6: :- Query: TR1: :- dest(D), TR2: :- dest(D), C=C1+C2. TR3: ) :- TR4: :- TR5: dest(base). Query: nextHop(S,D,Z,C). runtime & libraries optimized system stack path(…) :- link(…), dest(…), … … store(…) :- prod(…), cons(…), … … binary image in-flight tuple snlog compiler/optimizer snlog program From declaration to runtime… the network Join Proj tupleready sendready Join Agg Proj Sel table (compiler generated) builtin (user’s library) database operators (compiler’s library) push interfaces pull interfaces thread of control event signal *#*# refer to note tupleready sendready Key systems challenges  Memory vs. processor optimizations  Runtime code/data size efficiency  Execution plan representation routing tree protocol version coherency protocol More Examples SelAg Proj …… … …… … … runtime daemon mac daemon tupleready store() facts and 3 refreshEvent() rules not shown  Asynchronous component communication model  Heterogeneous network interoperability  Systems layering and abstractions support  Broadcast support, semantics and optimizations  Declarative control of timinig, power management, etc.  Distributed algorithms (networking, localization, tracking etc.) naturally deductive  Independence from hardware platform changes  Organized data storage (e.g. flash) is natural  Straightforward support for events  Easily add new sensors as predicates  Amenable to cross-layer and cross-node optimizations