Project Proposal for Dan

SUPERB Summer 2001

Background:

The PicoRadio project is a research effort exploring dense networks of very small low-power System-On-Chip (SOC) devices. The application space for PicoRadio includes numerous types of sensor networks and anything else that requires large numbers of inexpensive devices producing relatively low-bandwidth data in a decentralized way.

The PicoRadio Test Bed is a general-purpose platform for evaluation of PicoRadio algorithms. The Test Bed system is comprised of a number of processing units (PicoNodes) communicating with erach other over radio channels. The primary difference between Test Bed nodes and SOC PicoNodes is that a PRTB node is constructed from COTS (Commercial Off-The-Shelf) hardware and uses standard programming methodologies e.g. compiled 'C' code and commercial FPGA technologies. The Test Bed provides an intermediate step between concept and the ultimate goal where algorithms such as network protocols, Media Access Control (MAC), and applications can be evaluated. In other words, it's a place to run PicoRadio code in a real system before the actual PicoRadio nodes are available.

Currently, we have something like 18 working PicoNodes (number varies with type of use). For demonstrations and as a test case for the system we've developed a sensor application where multiple nodes equipped with sensors communicate with a central basestation. The basestation collects, processes, and logs the samples sent by the sensor nodes. This network has been deployed twice - once at BWRC for about a week (last week) and at the recent BWRC retreat in Tahoe for about half a day. The system performed OK under the circumstances, but as with any brand-new system there's a lot we don't understand about the dynamics of the system as a whole. Even though portions have been tested in isolation and with a small subset of other components, interactions between components in the complete system produce unexpected results, generally showing up as errors in data reporting.

At first glance, the sensor network is application-specific. However, it's based on the basic underlying functionality of the generic Test Bed. For instance, many low-level support mechanisms such as interrupt control will be used in most if not all future Test Bed applications, so it's critical that these basic mechanisms be free of implementation errors so that the Test Bed system doesn't "contaminate" the algorithms under evaluation.

Project Outline:

An important near-term task is to analyze the sensor application from end to end to identify and correct sources of error. This project will be to perform the analysis and, if time permits, to design and implement fixes to any problems. There are likely to be a variety of error sources, such as bad data encoding (a bug or bad choice of method), corruption on the wireless link, or data lost in processing. We hope to eliminate errors everywhere except on the link, which is inherently error-prone.

The project will follow roughly these steps:

1) Learn about the Test Bed to the point where you can create a simple application (write and compile 'C' code and generate a simple FPGA design in the TestBed workspace) and run the application on a single node.

2) Study the sensor application until you understand it inside-out.

3) Learn about the kernel resoures used by the application.

4) Deploy and operate the sensor network in the BWRC facility.

5) Analyze, or "profile" the network from end-to-end. For this you will need to understand how the sensors themselves work, how a sample is taken, and what happens to the sample between the time it is generated and the time the basestation has logged it to a file.

By the time the project is done, you will have detailed knowledge of:

1) The sensor application, of course.

2) The system resources used by the app, including software kernel and FPGA circuit blocks.

3) How the sensor network operates, including the basic communication "protocol" (in our case a Media Access Control, or MAC) and how the basestation and sensor nodes communicate with each other: when to send, when to listen, which radio frequency to use, when samples are taken and why.

4) End-to-end "data semantics".

The ultimate goal will be to compile a report (separate from your SUPERB report) on actual or likely error sources and recommend solutions. A secondary (but less important) will be to fix the errors yourself.