An Interactive, Source-Centric, Open Testbed for Developing and Profiling Wireless Sensor Systems

Abstract

The difficulty of developing wireless sensor systems is widely recognized. Problems associated with testing, debugging, and profiling are key contributing factors. While network simulators have proven useful, they are unable to capture the subtleties of underlying hardware, nor the dynamics of wireless signal propagation and interference; and physical experimentation remains a necessity. To this end, developers increasingly rely on shared deployments exposed for physical experimentation. Sensor network testbeds are under development across the world.

We present a complementary testbed architecture that derives its novelty from three characteristics. First, the system is interactive; users can profile source and network level components across a network in real time, as well as inject transient state faults and external network traffic. Second, the system is source-centric; it enables automated source code analysis, instrumentation, and compilation. Finally, the design is open; developers can extend the set of exposed inter faces as appropriate to particular projects without modifying the underlying middleware. We present the testbed design and implementation, a graphical user interface, a shell-based macro programming interface, example scenarios that illustrate their use, and discuss the testbed's application in the research and teaching activities at client institutions.

Keywords:

• Sensor Networks
• Testbeds
• Testing
• Experimentation
• Instrumentation
• Debugging
• Profiling

Acknowledgements

The work presented in this article was funded in part by the National Science Foundation (CNS-0520222) and the South Carolina Space Grant Consortium. The authors gratefully acknowledge these agencies for their support. The authors also wish to thank Sally K. Wahba for her work in characterizing the relationship between packet reception rate, transmission distance, and transmission power (Section 3.4, Table 1). Finally, the authors wish to thank the anonymous reviewers for their detailed comments and suggestions, which were of great value in improving this article.

Notes

¹We use the term “profiling” to refer to the process of collecting system events and state information during program execution (e.g., state changes, radio events, voltage data). The collected data may be analyzed in real time, or stored for ex post facto analysis.

²Our current API implementation uses the Java Remote Method Protocol (JRMP) for interprocess communication, requiring that client interfaces be implemented in Java. With minor modifications, the Internet Inter-Orb Protocol (IIOP) could be used [53] to enable CORBA compatibility, eliminating this restriction.

³Note, however, that some experimental controls can not be preserved in software. External network interference, for instance, may vary from one experimental run to another.

⁴The SerialForwarder libraries are packaged as part of the TinyOS distribution [59].

⁵The NESTbed distribution includes two alternative radio stack implementations; these are the only operating system alternatives available for selection through the graphical interface. The system is, however, extensible to an arbitrary number and type of alternative services.

⁶The Instrumentation and Compilation API assumes interface compatibility between selected components and user provided alternatives. Syntactic errors introduced during the instrumentation process due to interface violations in user provided components will be reported at compile time. Semantic errors can of course not be checked.

⁷The Message Interface Generator included as part of the TinyOS distribution is used to create this class [58].

⁸We have omitted standard error checking and recovery logic for the sake of presentation

⁹This discounts the possibility of forwarding raw packet data through a gateway for remote inspection.

¹⁰It may be useful to note that MoteLab, Kansei, the Deployment Support Network, and other testbeds include integrated health monitoring services. The basic approach is to periodically poll each device to determine whether it is in a programmable state. Unresponsive nodes are avoided by manual and automatic allocation strategies. Since the NESTbed system is intended for interactive use, users are notified of device problems at the point of installation (as indicated by programming failures). Unresponsive nodes can be power-cycled through the NESTbed interface. Hence, while useful in batch-based systems, the benefit of periodic health monitoring is unclear in the context of the NESTbed design.

¹¹We intend to investigate the use of DSN in future NESTbed enhancements.