The Tenet Architecture for Tiered Sensor Networks Ben Greenstein, Jeongyeup Paek Omprakash Gnawali, Ki-Young Jang, August Joki, Marcos Vieira, Deborah Estrin, Ramesh Govindan, Eddie Kohler

2 The Problem ■ Sensor data fusion within the network … can result in energy-efficient implementations ■ But implementing collaborative fusion on the motes for each application separately … can result in fragile systems that are hard to program, debug, re-configure, and manage. ■ We learnt this the hard way, through many trial deployments

3 An Aggressive Position ■ Why not design systems without sensor data fusion on the motes? ■ A more aggressive position: Why not design an architecture that prohibits collaborative data fusion on the motes? ■ Questions: How do we design this architecture? Will such an architecture perform well? No more on-mote collaborative fusion

4 Tiered Sensor Networks Motes Low-power, short-range radios Contain sensing and actuation Masters 32-bit CPUs (e.g. PC, Stargate) Higher-bandwidth radios Larger batteries or powered Enable flexible deployment of dense instrumentation Provide greater network capacity, larger spatial reach Many real-world sensor network deployments are tiered ■ Real world deployments at, Great Duck Island (UCB, [Szewczyk,`04]), James Reserve (UCLA, [Guy,`06]), Exscal project (OSU, [Arora,`05]), … Future large-scale sensor network deployments will be tiered

5 Tenet Principle Multi-node data fusion functionality and multi-node application logic should be implemented only in the master tier. The cost and complexity of implementing this functionality in a fully distributed fashion on motes outweighs the performance benefits of doing so. Aggressively use tiering to simplify system !

6 and may return responses Tenet Architecture Motes process data, No multi-node fusion at the mote tier Masters control motes Applications run on masters, and masters task motes

7 What do we gain ? ■ Simplifies the application development Application writers do not need to write or debug embedded code for the motes – Applications run on less-constrained masters ■ Enables significant code re-use across applications Simple, generic, and re-usable mote tier – Multiple applications can run concurrently with simplified mote functionality Robust and scalable network subsystem – Networking functionality is generic enough to support various types of applications which improves network re-usability

8 ■ More bits communicated than necessary? ■ Communication over longer hops? Challenges Fusion ■Not an issue Typically the diameter of the mote tier will be small Can compensate by more aggressive processing at the motes ■In most deployments, there is a significant temporal correlation Mote-local processing can achieve significant compression ■… but little spatial correlation Little additional gains from mote tier fusion ■Mote-local processing provides most of the aggregation benefits. The cost will be small…

9 System Overview Tasking SubsystemNetworking Subsystem Tasking Language Task Parser Tasklets and Runtime Reliable Transport Routing Task Dissemination Tenet System How to disseminate tasks and deliver responses? How to express tasks?

10 Tasking Subsystem Networking Subsystem Tasking Language Task Parser Tasklets and Runtime Reliable Transport Routing Task Dissemination Tenet System ■ Goals Flexibility: Allow many applications to be implemented Efficiency: Respect mote constraints Generality: Avoid embedding application-specific functionality Simplicity: Non-expert users should be able to develop applications

11 Tasking Language ■ Linear data-flow language allowing flexible composition of tasklets A tasklet specifies an elementary sensing, actuation, or data processing action Tasklets can have several parameters, hence flexible Tasklets can be composed to form a task –Sample( 500ms, REPEAT, ADC0, LIGHT )  Send() ■ No loops, branches: eases construction and analysis Not Turing-complete: aggressively simple, but supports wide range of proposed applications Data-flow style language natural for sensor data processing

12 Classes of Tasklets ■ System Reboot Get Send ■ Task Manipulation Issue (Wait, Alarm) DeleteTaskIf DeleteActiveTaskIf ■ Sensor/Actuator Sample Actuate ■ Data Manipulation Arithmetic Comparison Logical Bitwise Statistics DeleteAttributeIf ■ Miscellaneous Storage Count / Constant

13 Task Compositions… ■ CntToLedsAndRfm ■ SenseToRfm ■ With time-stamp and seq. number ■ Get memory status for node 10 ■ If sample value is above 50, send sample data, node-id and time-stamp WaitCountLightsSendSampleSendCountStampTimeSendSampleMemStatsSendAddressNEQ(10)DeleteIfSampleLT(50)DeleteATaskIfAddressStampTimeSend

14 How many Tenet tasks can a mote run at the same time? + Memory is the constraint, and task complexity matters! Memory Usage (~5KB heap) Sample(1)Send 110Bytes Sample(1) Stamp Time CAGSDASend 180Bytes Sample(40)Send 190Bytes tasks Classify Amplitude Gather Statistics Delete Attribute Sample(1)Send Stamp Time 26 Classify Amplitude Sample(1)Send Stamp Time tasks, or 31 Sample(1)Send tasks 38 Wait Stamp Time Memory Stats Next Hop Send task 1 Network Monitoring tasks n Sensing Application (…on Tmote Sky motes)

15 Overview of Networking Subsystem Tasking System Networking Subsystem Tasking Language Task Parser Tasklets and Runtime Tenet System ■ Goals Scalability and robustness Generality: Should support diverse application needs Reliable Transport Routing Task Dissemination

16 Task Dissemination ■ Reliably flood task from any master to all motes Uses the master tier for dissemination Per-active-master cache with LRU replacement and aging

17 Reliable Transport ■ Delivering task responses from motes to masters Works transparently across the two tiers ■ Three different types of transport mechanism for different application requirements Best-effort delivery (least overhead) End-to-end reliable packet transport End-to-end reliable stream transport

18 Putting it all together…

19 Application Case Study: PEG ■ Goal Compare performance with an implementation that performs in-mote multi-node fusion ■ Pursuit-Evasion Game Pursuers (robots) collectively determine the location of evaders, and try to corral them.

20 Mote-PEG vs. Tenet-PEG Pursuer Evader Detected Re-task the motesTask the motes Evader Pursuer Evader Detected Evader Leader Election Leader Mote-PEGTenet-PEG

21 Error in Position EstimateReporting Message Overhead PEG Results-1 Comparable positional estimate error Comparable reporting message overhead

22 PEG Results-2 Latency is nearly identical A Tenet implementation of an application can perform as well as an implementation with in-mote collaborative fusion

23 N W Real-world Tenet deployment on Vincent Thomas Bridge 570 ft 120 ft 30 ft Mote Master Ran successfully for 24 hours 100% reliable data delivery Deployment time: 2.5 hours Total sensor data received: 860 MB

24 Interesting Observations Fundamental mode agrees with previously published measurement Faulty sensor! Consistent modes across sensors

25 Related Work ■ Architecture SNA [Culler,`05], [Polastre,`05], Internet [Saltzer, `84], … ■ Virtual Machine Mate [Levis,`02], … ■ Tasking Library VanGo [Greenstein,`06], SNACK [Greenstein,`04] ■ Task Dissemination Deluge [Hui,`04], Trickle [Levis,`04], … ■ Reliable Transport RMST [Stann,`03], Wisden [Xu,`04], … ■ Routing ESS [Guy,`06], Centroute [Stathopoulos,`05], …

26 Conclusion Applications Simplifies application development Networking SubsystemRobust and scalable network Tasking SubsystemRe-usable generic mote tier Simple, generic and re-usable system

27 Software Available Soon… ■ Master tier Cygwin Linux Fedora Core 3 Stargate ■ Mote tier TelosB MicaZ Thank you!