: A Wireless Sensor Network Testbed

1. : A Wireless Sensor Network Testbed Geoffrey Werner-Allen, Patrick Swieskowski and Matt Welsh Harvard University werner@eecs.harvard.edu http://motelab.eecs.harvard.edu

2. Before MoteLab ... How to Experiment on a Wireless Sensor Network (circa 2003) 1) Reprogram Nodes 2) Instrument for Data Collection 3) Deploy into Environment 4) Run Experiment 5) Collect Motes 6) Analyze Data 7) Goto (1)

3. Before MoteLab ... How to Experiment on a Wireless Sensor Network (circa 2003) Tedious, time consuming Unclear how to do this Tedious, time consuming Ugh Not again! 1) Reprogram Nodes 2) Instrument for Data Collection 3) Deploy into Environment 4) Run Experiment 5) Collect Motes 6) Analyze Data 7) Goto (1)

4. MoteLab Design Goals Accelerate Wireless Sensor Network Software Design Cycle • Automate data collection • Simplify data retrieval • Provide ubiquitous interface • Allow global access • Transparently arbitrate resources among competing users

5. What is MoteLab? • Web-enabled testbed for Ethernet-connected motes • 30 MicaZ nodes distributed throughout our CS building at Harvard • Simple Web interface for scheduling and programming • Automated logging to database • Messages sent to mote's serial port logged to database • Integrated power profiling • Power consumption of one mote logged

6. How to Use MoteLab 1) Instrument Code : every message sent by your program to the serial port during the experiment will be logged by MoteLab. 2) Create Experiment : select which nodes to use and assign which binaries will run on each one of them. 3) Schedule Experiment : just a few mouse clicks. 4) Download Data from MoteLab 5) Analyze Your Data 6) Goto (3)

7. (Demo)

8. The “eMote” : MIB600

9. ... After MoteLab How to Experiment on a Wireless Sensor Network (circa 2005) Automated Simple Done Automated Not necessary (Still your problem) Easy! 1) Reprogram Nodes 2) Instrument for Data Collection 3) Deploy into Environment 4) Run Experiment 5) Collect Motes 6) Analyze Data 7) Goto (1)

10. Access Control • Rolling user quotas • decremented on job schedule • incremented on job completion • Transparent job schedule • users can observe greedy behavior • allows correct scheduling of temporally-sensitive jobs • Lab administrators have full control over scheduling

11. MoteLab Contention

12. MoteLab Contention 4/8/2005 Sensys Deadline

13. Interactive Use • Each mote's serial port available via TCP/IP • Serial Forwarder available for each mote allows TinyOS Java tools to connect to the mote directly • Allows interactive use while a job is running • Does not interfere with database logging

14. Power Profiling Sample data collected from node instrumented with Keithley 2701 Digital Multimeter Continuous Mode : 250 Hz Burst Mode : 3000 Hz

15. Connectivity Graphs Lab connectivity information collected regularly by a standard MoteLab job

16. MoteLab @ Harvard : Stats • 30 nodes over 3 floors of a large office building • Statistics, over 16 months: • 85 users, 58 Harvard, 27 external • 820 unique jobs created • 2516 experiments run • Average job length: 20 minutes • Longest job : 5.5 hours

17. MoteLab @ Harvard : Uses • Education • CS263 : Wireless Sensor NetworksSimple source-to-sink routing • CS161 : Operating Systems'Capture the Flag' game • Numerous class research projects have used MoteLab • Research • MoteLab has assisted almost every Harvard sensor network-related research project, including CodeBlue, ADMR, PowerTOSSIM, MoteTrack and Volcanic Monitoring

18. Similar Systems EmStar/EmTOS (UCLA) : Heterogeneous network (Mica2, Stargate). Nodes used as network interfaces. Kansei Testbed (Ohio State) : Also heterogeneous (Mica2, Telos, XSM, Stargate). Data logging and job automation similar to MoteLab. Mirage (Intel Research Berkeley) : Bid-based scheduling to manage contention. Less automation, more control.

19. Future Work • Continue Modularization • Develop tools in common with other testbed developments • Integrate with Telos (required backchannel boards soon available) • Decouple access and job scheduling • Increase size of Harvard Lab

20. MoteLab is OPEN for ACCOUNTS email: werner@eecs.harvard.edu for SOURCE visit: motelab.eecs.harvard.edu

21. User Interface : Job Creation Job creation begins with naming and a description

22. User Interface : Job Creation Jobs consist of executable files to reprogram the nodes and class files that allow us to parse sent messages

23. User Interface : Job Creation Power profiling is one of several job options that we support

24. User Interface : Scheduling Here we've selected a 15 minute interval to run our job

25. User Interface : Scheduling We've successfully scheduled our job, and the schedule page reflects that it is waiting to be run

26. MoteLab Architecture

27. User Interface : Data Retrieval After the job completes, we download collected data from the homepage

28. User Interface : Home Page Shows information about scheduling, running, and completed jobs, and allows data download

29. User Interface : Job Creation We provide a number of different ways of assigning executable to nodes

30. Lab Partitioning • Breaks testbed into multiple independent chunks • Suggested by Eric Fraser at UCB • Users can select a subset of motes to execute their job • At Harvard : “MD East”, “MD West”, or “MD All” subsets of the lab • Easy to define new spatial partitions as necessary