DIVISION OF ENGINEERING AND APPLIED SCIENCES
HARVARD UNIVERSITY
CS 263. Modern Distributed
Systems:
|
Research 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.
Projects are to be undertaken in groups of two students, unless you have made special arrangements with me.
Proposal Format Research Project Proposals due by beginning of lecture on Thursday, October 27. Please email your proposal in PDF format to cs263-reviews@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 November 22), and final goal for the end of the project (final project report due Friday, January 6, 2006).
Project Ideas
- Develop a new programming or query model for sensor networks.
The TinyDB system has been very successful at making it easy to "program" a sensor network by providing a high level query interface. However, TinyDB is limited in a number of dimensions and is not appropriate for general purpose application design. Consider extending the TinyDB model to incorporate new query operators, aggregation techniques, or possibly extending TinyDB to permit users to push application-specific operators into the query engine. For example, the Mate virtual machine could be used as the protected execution environment for these operators.
Take a look at the recent papers by Sam Madden on various extensions to TinyDB, and the work on Synopsis Diffusion by Suman Nath et al., as an example of a cool new aggregation technique.
- 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.
- 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 conceiveably 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.
- 802.15.4 benchmarking with motelab
Define several traffic patterns to challenge the network. Measure the link quality, packet loss rate, highest data rate, etc. Analyze the result with respect to location of the motes, number of concurrent transmissions, time in the day and so on.
Compare the results with existing models of radio propagation in indoor environments. Consider the use of multiple frequencies and transmit power levels (the CC2420 radios allow you to control frequency and transmit power in software).
For this project, be sure to read the paper on SCALE by A. Cerpa et al. (UCLA).
- Implementation and measurement of ad hoc routing protocols on sensor network nodes.
Several of the "classic" ad hoc routing protocols (AODV, DSR, etc.) have been implemented on TinyOS, although I am not aware of any serious evaluations of their performance. Use MoteLab to implement and study one or more of these protocols in a realistic indoor environment. Use your mote kits to measure performance with mobile nodes roaming the building. Compare your result with published simulation and other studies using other devices (e.g., 802.11 cards).
- Extend the TOSSIM environment for realistic radio models, Telos, and 802.15.4.
The TOSSIM simulator is widely used to study sensor network applications, though it isn't very realistic. Extending TOSSIM to integrate a better model of radio propagation, perhaps based on real measurements using the MoteLab testbed, would be incredibly valuable.
One aspect of this project would be to take a set of measurements of radio connectivity in MoteLab and produce a radio model for TOSSIM based on this data. Then, run an application (such as TinyDB, or the routing protocol you developed as part of Assignment #1) and compare the performance in simulation to real data on MoteLab. If the two do not match up well, try to understand why -- what other aspects of TOSSIM need improvement to get it to be more realistic?
Newer versions of TOSSIM include extensions to model power consumption of individual motes. This model is based on the older Mica2 nodes and needs to be updated for the MicaZ and Telos motes. The sensor models supported by TOSSIM are also very simplistic and need to be updated.
The end result of the project should strive to demonstrate a set of real applications running on both MoteLab and TOSSIM that behave identically (or as closely as possible). Identifying problems with the existing simulator is also instructive to the research community.
See the papers on TOSSIM by Levis et al. in SenSys'03, and PowerTOSSIM by Shnayder et al. in SenSys'04.