: Enabling Wireless Sensor Network Research

1
Enabling Wireless Sensor
Network Research
Geoffrey Werner-Allen and Matt Welsh Harvard
University werner_at_eecs.harvard.edu
http//motelab.eecs.harvard.edu
2
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
• All messages send to mote's serial port logged to
  database
• Integrated power profiling
• Power consumption of one mote logged

3
The eMote
4
MoteLab Design Goals

• Accelerate wireless sensor network software
  design cycle
• Automate data collection
• Simplify data retreival
• Provide ubiquitous interface
• Allow global access
• Transparently arbitrate resources among competing
  users

5
User Interface Home Page
Shows information about scheduling, running, and
completed jobs, and allows data download
6
User Interface Job Creation
We provide a number of different ways of
assigning executable to nodes
7
User Interface Data Retrieval
After the job completes, we download collected
data from the homepage
8
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

9
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

10
Interactive Use

• Each mote's serial port available via TCP/IP
• Allows interactive use while a job is running
• Does not interfere with database logging

11
Power Profiling
Sample data collected from node instrumented with
Keithley 2701 Digital Multimeter
Continuous Mode 250 Hz Burst Mode 3000 Hz
12
Connectivity Graphs
Lab connectivity information collected regularly
by a standard MoteLab job
13
MoteLab _at_ Harvard Uses

• Education
• Two courses have created MoteLab-based class
  assignments
• Numerous course projects have used MoteLab
• Research
• MoteLab has aided in almost every sensor
  network-related research project, including
  CodeBlue, TOSSIM, and Volcanic Monitoring

14
Future Work

• In progress
• Scripting Interface (Kyle Jameison, Bret Hull,
  MIT)
• Planned
• Continue Modularization
• Integrate with other hardware platforms (e.g.,
  Telos)
• Decouple access and job scheduling

15
MoteLab is OPEN for ACCOUNTS email werner_at_eecs.h
arvard.edu for SOURCE visit
motelab.eecs.harvard.edu
16
User Interface Job Creation
Job creation begins with naming and a description
17
User Interface Job Creation
Jobs consist of executable files to reprogram the
nodes and class files that allow us to parse sent
messages
18
User Interface Job Creation
Power profiling is one of several job options
that we support
19
User Interface Scheduling
Here we've selected a 15 minute interval to run
our job
20
User Interface Scheduling
We've successfully scheduled our job, and the
schedule page reflects that it is waiting to be
run
21
MoteLab Architecture
22
MoteLab _at_ 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