Back in the early stages of sensor network research, I was working at Information Science Institute (ISI)
getting ready for a DARPA
demo. The demonstration consisted of showing the first
implementation of a data dissemination scheme using a small multihop
network deployed in the
parking lot at the entrance of the building. The demo was a
failure, and at the time I decided to perform the autopsy. There
were many problems, but one of the most important ones was the lack an
out-of-band channel and supporting infrastructure to better debug,
control and analyze the distributed system interactions in
real-time. Since that episode, it was clear to me that one of the
fundamental requirements for sucessfully deploying sensor network
systems was the development of better testbeds and software
environments that would facilitate the system development and the
understanding of sometimes complex
interactions in the system.
As part of my research involvement at CENS, I have been quite active
and
interested in developing infrastructure to support sensor network
experimentation using real platforms and systems.
Testbed Management Tools
The large number of different hardware
platforms available in the
lab---more than hundred different type of nodes, including Stargates,
iPAQs, PC104s---make the system administration and software management
a daunting task. This is particularly critical in a system
research lab, where multiple users need to experiment with
possibly unstable versions of the software, but high degree of
availability of scarce resources is still needed. I developed a
set of testbed
management tools that allow individual testbed users to change,
update, and test any system software on these platforms---including the
kernel---in a simple and efficient manner. The tools allow each
user or group of users to perform cvs
style operations on a testbed node filesystem image.
Multiple users can be assigned different nodes and have different
images in each of their nodes, without having to worry about manually
transfer them to each node, or checking if the right set of binaries is
in place. In addition, updating binaries is very efficient and
can be done en masse for all
the nodes. The system has been successfully running for a couple
of years now.
EmStar
I have also been involved with EmStar, a programming model
and a software environment for developing and deploying sensor network
applications on Linux-class hardware platforms. The system is
still under development at CENS. EmStar allows users to run the same code and configuration on real nodes (either using low-power
radios such as motes, or 802.11), as a pure simulation, or in a hybrid mode that combines
processing done in simulation and communication, sensing, and actuation
on real (physical) channels. The same source code can be used in
any of these modes without changes. The EmStar system consists of
different modules with specific---albeit configurable---functionality,
connected via libraries that implement message-passing IPC primitives,
a control plane that manages all modules---start-up, keepalive,
restarts, logging---, a group of low level modules that provides basic
services---neighbor discovery, routing, time synchronization---, and
visualization modules that permit interactive evaluation of the
system. The goal is to leverage on the reusability of
customizable modules to provide a simpler solution for a system
designer than application-specific solutions. I have contributed
specifically to the Link
interface---the basic API used by all modules in the framework to
connect to each other---, the helper libraries, the link measurement
and neighbor
discovery modules, the link reliability modules, routing algorithm
modules, the simulation interface for both motes and udp, the
radio propagation channel library, the visualization modules, as well
as full implementations of ASCENT and SCALE.
The large number of different hardware
platforms available in the
lab---more than hundred different type of nodes, including Stargates,
iPAQs, PC104s---make the system administration and software management
a daunting task. This is particularly critical in a system
research lab, where multiple users need to experiment with
possibly unstable versions of the software, but high degree of
availability of scarce resources is still needed. I developed a
set of testbed
management tools that allow individual testbed users to change,
update, and test any system software on these platforms---including the
kernel---in a simple and efficient manner. The tools allow each
user or group of users to perform cvs
style operations on a testbed node filesystem image.
Multiple users can be assigned different nodes and have different
images in each of their nodes, without having to worry about manually
transfer them to each node, or checking if the right set of binaries is
in place. In addition, updating binaries is very efficient and
can be done en masse for all
the nodes. The system has been successfully running for a couple
of years now.