Project Requirements
All teams must be composed of two members. You can do one of the following:
• A simulation project, using either QualNet or NS-2. If you choose to do a simulation project, you need to implement something new, not something that already exists.
• An implementation project, using either HP iPAQs or your own laptops. If you choose to do an implementation project, you can either implement something new, or you can test existing implementations/software.
Design Specification - due April 13th
You should first decide what problem you are going to solve, and then you should create a design specification that includes the following items:
• Name and email address of each team member.
• Overview of the project explaining what it is and what problem it solves.
• What existing components or services can be leveraged, and what has to be built.
• Main novel technical challenges in realizing the project, and how you will overcome those challenges.
• Motivation for the project: Why is it needed? Do existing systems or services do something similar, and if so, how is yours different/better? Your "survey of the competition" should include both relevant research projects (industry or academic) and relevant commercial services.
• Top-level design, including a week-by-week task breakdown of the implementation phase.
• Preliminary thoughts on testing methodology for your project.
A list of project ideas can be found here. Your design specification should be no longer than 3 pages.
Implementation - due May 10th
Implement the project!
Mini-demos: approximately May 11th and 12th
Note: there is no “turn-in” component for this part.
Testing and Characterization Specification - due May 18th
You should create a testing specification detailing how you will test your code, and motivation for why these are conclusive tests. These tests should be automated and repeatable, and should include tests to ensure your program is operating correctly. You will also need to characterize and evaluate your project. Characterization and evaluation includes documenting the project metrics - i.e. how well does your algorithm perform, what are the specific performance characteristics such as throughput, delay, etc. The specification you turn in should be no longer than 3 pages, and should include the following items:
• Name and email address of each team member.
• List of performance characteristics of your project that are important to evaluate.
• List of tests you will perform.
• Motivation for why these are conclusive and important tests.
Testing/Debugging Phase - due June 1st
Implement the tests and collect the metrics you detailed in your Testing and Characterization Specification.
In-Class Project Demos - June 4th
You will need to demonstrate your project to the class. You should have a working prototype, and a 10 minute presentation of your project.
Demos for the TA and professor: June 11th
Final reports - due June 13th
Your report should be a technical description of your system, and should follow the guidelines below. For good examples of mobile systems papers, see recent proceedings from MobiCom and MobiSys.
The report should be no more than 8 pages and should cover these points:
Motivation: What problem are you trying to solve? Why is your project going to change the world? Why and how would someone use your system? Give a specific scenario. State your assumptions.
Related work: Briefly describe other attempts to solve the problem, or similar problems. How does your system improve on these attempts?
Design and implementation: Discuss in detail your approach for solving the problem: external design (how your system interacts with other components), user interface, internal design (the various pieces that comprise your system). Expand on the scenario from the motivation section. Explain any interesting design tradeoffs. Are there any reusable parts that could be packaged as a library for other programmers? You should also indicate any significant ways that your finished product differs from what was included in the design specification, and why those changes had to be made.
Testing and Characterization: Discuss how you tested your approach and why these are conclusive tests. Include a characterization of the performance of your project, including any helpful graphs. In addition to including your results, you should also explain your results. Why did you obtain those results? Why does your system result in the performance metrics you obtained? You should be especially sure to explain any abnormalities or unexpected results in your data.
Discussion: lessons learned
References