DIVISION OF ENGINEERING AND APPLIED SCIENCES
HARVARD UNIVERSITY

CS 263: Wireless Sensor Networks Prof. Matt Welsh Spring 2009

Research Projects

Projects are to be undertaken either individually or in pairs, unless you have made special arrangements with me.

Project Presentation Schedule

April 28, 2009

• Matt Tierney and Daniel Shteremberg, Wireless Sensor Network Visualization with TuningFork
• Jason Waterman, Running on Empty: Maximizing Utility from Energy Harvesting Sensor Networks
• Oliver Wilder-Smith, A Visual Programing IDE for Pixie
• Kevin Brownell and Michael Lyons, An Analysis of Hardware Acceleration for Wireless Sensor Networks

April 30, 2008

• CK Lin, Dynamic Transmission Power Control for Wireless Sensor Networks
• Atanu Roy Chowdhhury, Design of an Autonomous Wireless Body Sensor Network
• Robin Smogor and Peter Macko, Profiling Application Energy Use in PixieOS
• Subhash Arja and Neil Jhaveri, SnoozingFlush

Each talk will be 15 minutes in length followed by 5 minutes for questions.

Deadlines

• March 3, 2009 - before class Research proposals due, email to cs263-staff@eecs. See below for format.
• April 9, 2009 - before class Email a project update to to cs263-staff@eecs. This should be a one page (or so) email detailing what you have accomplished so far on your project, and specifically comparing your progress to the milestones you described in your original project proposal.
• April 28 and 30, 2009 In-class presentations. These will be 15-minute talks given in class describing your project and progress to date. You should plan to have your project mostly complete by that time, apart from final experiments and writing up the report.
• May 11, 2009, 5pm Final project reports due.

Proposal Format

Research Project Proposals due by beginning of lecture on Tuesday March 3, 2009. Please email your proposal in PDF format to cs263-staff@eecs.

The proposal should be a 2-3 page document including sections on:

• A summary of the project;
• Background and related work (specifically, describe what is novel about your project);
• A brief description of your proposed approach, and any other thoughts on how you will proceed;
• A specific timeline of milestones that you intend to accomplish for your project. This should include the initial starting point, goal for what you intend to accomplish by the project update (due April 9), the in-class presentation (April 28 and 30), and the final goal for the end of the project (final project report due May 11, 2009).

Project Presentations

CS263 final project presentations will take place during class on April 28 and 30. All students are expected to attend both days.

Each project group will prepare a 15 minute presentation outlining your project and presenting initial results. Following each presentation we will have 5 minutes for questions and to switch to the next group. The presentation format is intended to resemble a "work in progress" session at a research conference, in which individuals are given an opportunity to present a brief overview of a new and exciting project. We do not expect that you will have completed your project by this date, although you should have done most of the work so you have something tangible to present. You should include a summary of the status of your project as well as what your expected outcome will be.

Presentation format: Please prepare a short presentation in PowerPoint or PDF format. We suggest no more than 10 slides total in your talk. Only one project member needs to give the presentation, but you are welcome to "tag team" if you like. Please time yourselves and be sure that your talk will exceed no more than 15 minutes ... we will "gong" any talk that goes over time (and you will lose points for exceeding the time limit!).

The goal of your presentation is not to explain everything that you have done, but rather to get the main points across in a short time. Above all, you should make your talks fun and interesting. Of course, this does not mean the talk should not have any technical depth. All talks will be graded on clarify, style, technical content, and whether it stays on time.

Please email your presentation slides to cs263-staff@eecs by 11:59pm the day before your presentation. We will load all slides onto one laptop so that switching between presentations will go smoothly.

Final Report

Your final paper for the course is due at 5:00pm EST on May 11, 2009. No late papers will be accepted. Please e-mail the paper as an attachment (not a URL) to cs263-staff@eecs.

The final paper for the course is intended to be a conference-style paper, much like the papers you have been reading all semester. It should include the same general structure (abstract/intro/related work/system architecture/implementation/evaluation/future work/conclusions) as these other papers. Of course, depending on your project, the exact structure may vary.

The paper should be written for a scientific audience of experts in the field of wireless communications and sensor networks. In other words, it should present your research in the same manner as you would expect to see in a conference such as Sensys, Mobicom, SIGCOMM, etc. The idea behind this is to give you practice writing conference papers, and hopefully we will be able to actually submit your paper to one of these conferences in the coming months (the Sensys deadline is in April, for example). If you are interested in this, I am happy to work with you to refine your paper for submission.

As with all conference papers, you must follow a set of formatting guidelines. I am not going to pull out a ruler to check your margins, etc. but if you seriously abuse these general guidelines then you run the risk of making the reviewers (i.e., me) unhappy.

• Papers must be between 10 and 12 pages long, including all text, figures, references, etc.

• Papers must be submitted in PDF format. No other formats will be accepted (no Word, HTML, or PostScript). It is your responsiblilty to ensure that your paper prints correctly. If you use color in your figures, ensure they can be discerned in black and white.

  I strongly recommend the use of pdflatex to generate your paper. A template for writing papers using this tool can be downloaded here: template.tar.gz This template has the appropriate formatting, layout, etc. for final papers for the course. (It also happens to be the same format used by many conference papers.)

  If you use regular TeX or LaTeX, you can use dvips and pstopdf to generate a PDF file, but I find that the results are often unsatisfying. At least use the times package (\usepackage{times}), which causes Adobe's standard fonts to be used, yielding much better results.

  If you wish to use another tool, the following PDF file is an example of the formatting that I expect for papers in this course: regions-hotnets03.pdf

• Your document should be double column, use 10-point font, single-spaced. (Footnotes, captions, bibliographic entries, etc. can use a smaller font, but it must be legible.) The left and right margins should be 1/2 inch; and top and bottom margins should be 1 inch. You should use two-column formatting with 1/3 of an inch between columns. Generally, your paper should be visually appealing and easy to read.

• Email the course staff if you have any questions!

Project Ideas

These are only suggestions to help you get a sense of the scope and topics for research projects that would work for CS263. As mentioned previously, projects must have some connection to the overall topic of the course, but can draw on ideas from other fields (e.g., theory, AI, languages, etc.) In fact, we encourage projects that have a "non-systems" component.

• Develop an adaptive congestion control protocol.

  In many sensor network applications (for example, medical monitoring) the amount of data that sensors wish to relay to the base greatly overwhelms the capacity of the radio channel. Existing approaches to congestion control (for an example, see here), are fairly simplistic in that they send feedback to transmitting nodes to inform them of the total rate at which they are allowed to transmit data. Unfortunately this is not a good match for many applications, which may not be able to transmit at an arbitrary rate, or that may wish to tune the quality of the data they transmit rather than just the number of packets per second.

  You should consider developing a more adaptive and robust approach to congestion control that allows the application to receive feedback on network characteristics and tune the quality or rate of data transmitted. Be sure your work goes beyond the existing papers in this area in some way. Check out the work on Interference Aware Rate Control (IFRC) as a starting point.

• Develop a multi-application/multi-query resource management strategy.

  Most work on sensor networks assumes a single application, user, or query is using the network at one time. However, if sensor networks are successful, we imagine many applications and queries running in one network at a time. This opens up many interesting questions for resource sharing, protection, and optimization. How do you ensure that multiple applications do not interfere with each other? How do you protect apps from each other? Virtual machines, like Mate, could potentially support multiple apps per network, but need to be extended to fairly allocate resources across apps, for example, to prevent one app from consuming too much energy or radio bandwidth.

  A similar idea exists in a framework such as TinyDB, which could conceivably permit multiple concurrent queries from different users. In traditional databases, work on "multiquery optimization" attempts to combine multiple queries and schedule them to optimize resource usage. This is a very interesting problem in a sensor network context; for example, if many queries are all sampling the same sensors, it would be very inefficient to run them all separately. Likewise, if two queries are performing "similar" operations, it should be possible to combine them in some way. There are many interesting problems to look at in this space.

• Add support for resource profiling to Pixie.

  Pixie provides the low-level mechanisms for managing sensor node resources, but it is assumed that programmers will perform offline profiling to determine how much resource each application stage needs to operate. A great project would be to implement some form of automatic resource profiling, either online or offline. An offline strategy could use either a simulator or a code-analysis tool to determine the resource envelope required by a given stage or set of stages, and then modify the application code to configure ticket request amounts. An online strategy would measure resource usage and feed this information back to the application to tune ticket requests. A hybrid approach is probably best.

• Design a radio transmission power control algorithm.

  Transmission power control is a knob that's there but not exploited by most existing sensor networks. It has been the case partly because turning radio signal strength makes the networking much more complicated and therefore harder to implement. Radio channel itself is unreliable already. Tuning transmission power just adds more uncertainty to whether packets can travel between any pair of nodes in the network. When the community is still working to converge on a stable radio stack that implements MAC and routing layers that work properly, exploring another knob of changing transmission power is just not practical. However, it is well-known that power consumption of the radio still dominates the total power consumption of a mote. Power control of the radio is still very attractive because it could yield performance gains in two directions: improving energy efficiency and reducing interference. Now that TinyOS community has made good progress on a reasonably stable radio stack, it is a good time to start experimenting the opportunity given by power control.

• Real-time sensor network monitoring.

  Sensor networks are expected to be left unattended and operate for long time periods. However, software bugs and other factors may cause various types of failures in the network, e.g. node crashing, network partitioning, power failure, protocol state corruption, or sensor malfunctioning. Because proper operation of the network is critical for collecting usable sensor data, it is desired that these failure be detected and reported quickly. One approach [see Sympathy paper] to achieve this is to instrument your sensor network application with the monitoring tool but it is prone to the failure of the application, i.e. if the application crashes the node, your monitoring component dies too. Another way to do this is to deploy monitoring sensor nodes along with the sensor network itself. The monitoring nodes can overhear the radio packets sent by the deployed sensor nodes and detect failures by analyzing the packets. There has been some work in this area for offline diagnosis of the network [see LiveNet and SNIF papers], but it will be more useful if the diagnosis is done in an on-line fashion and to detect failures when they occur. If you are interested in visualization, you might want to check out TuningFork and find a way to use it to practically visualize real-time sensor network behaviour.