1. Centroute, Tenet and EmStar: Development and Integration Karen Chandler Centre for Embedded Network Systems University of California, Los Angeles

2. Outline Centroute Tenet EmStar Integration progress and future work

3. Centroute Centralised, on-demand, tree-based routing Source routing to create a tree from nodes to sinks Moves processor / memory intensive operations from motes to sink Stable, scalable, fast converging routing algorithm

4. Disadvantages of Centralisation Decision making on central node means single point of failure But: Sensor networks have the same single point of failure regardless of routing algorithm All state information needs to be transmitted to sink for decision making, instead of decisions being made locally Tree formation on-demand helps minimise this

5. Tree Formation in Centroute Sink Node 1Node 2 Node 3Node 4 Initial Round of Join Requests: Only Nodes 1 and 2 in range of sink Sink Node 1Node 2 Node 3Node 4 Join Responses sent: Nodes 1 and 2 now part of the tree

6. Tree Formation in Centroute Sink Node 1Node 2 Node 3Node 4 Next Round of Join Requests: Nodes 1 and 2 forward requests for Nodes 3 and 4 Sink Node 1Node 2 Node 3Node 4 Sink chooses a path for the nodes, and responses are sent along this path

7. Link Quality Estimation Link quality estimates only provided in Join Request Beacons Multiple beacons sent in quick succession, aggregate beacons forwarded to parent Link information only kept while in the Join phase Does not attempt to improve an established path Motes detach themselves from the tree after multiple packet failures

8. Centroute Performance Better connectivity than multihop, even at high mote density Less RAM space needed on motes, and doesn't scale with network size Less control packet over-head than other routing protocols like Multihop Only suffers reduced performance under very sparse topologies

9. Tenet Architecture Design 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.

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

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

12. Tenet 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

13. The Tenet Stack

14. Why merge these projects? Compatible design philosophy Both projects focus on moving complexity from mote level to master level Test of integration capabilities Both projects are intended to be modular, proof of concept of this functionality Centroute offers performance improvements + extra tools

15. EmStar and Centroute Centroute was developed using EmStar, and relied on EmStar libraries for key functionaility: Interprocess communication Timers User input / output Emulation mode Process management

16. Issues with EmStar and Usability Very large package must be downloaded Requires a kernel module, which can be problematic under some Linux versions, and we are tied to Linux only Many dependencies between libraries and a large code base means a long compile time for users who only require a small subset of the code base Tied to an old version of Tiny-OS

17. Goals with EmStar 2.0 Keep it simple! EmStar 1.0 is feature rich, but very few users are aware of its full functionality Most users only require a minimal subset of EmStar features Re-use past work where possible Minimise platform-dependent code Simplify the task of porting to other platforms Simplify maintenance Minimises the size of the code-base

18. Changes to EmStar 2.0 Interprocess Communication: Previously used the FUSD kernel module and device files to exchange data between processes Now uses socket interface to exchange data Pros: Standard interface, easy to use, portable to other platforms Cons: Can't 'listen in' on communications between modules

19. Changes to EmStar 2.0 User Input / Output Previously user could echo commands to device files, and cat that file for output Current version doesn't accept run time commands from the user, output data provided to a log file Future versions will use the socket interface to allow users to provide run time commands and query for updates Pros: Easy for the user to view execution status at run time or after completion Cons: Can't currently tune operation at run time (to be fixed in a future version)

20. Changes to EmStar 2.0 Emulation Mode EmStar provided library files to allow mote code to run on a Linux platform, and to have full debugging and visibility into that code The new version of EmStar has this same functionality Leverages the new library functions to provide the same features

21. Changes to EmStar 2.0 Process Management Vinayak developed a simple scripting language to launch processes with a set of user provided parameters Doesn't provide the full functionality of EmStar 1.0 No simple process viewing utiliity No sophisticated process management (like time based mode changes etc.)‏

22. Current Status New EmStar library files have been tested internally and are functional Working on combining with Tenet now In the future, more feature additions, make more user friendly

23. Questions?