Stanford University
Computer Science 444N: Spring 2001

Projects

Project links | Process | Home

Project links

Here are links to the project proposals submitted by all the groups:

• Roma extensions
• Ad Hoc participation guarantee
• SPINACH Extensions
• Experiment with Queuing Disciplines in Mobile Ad hoc Networks
• Personal Authentication Manager
• Distributed application platform for adhoc networks
• Issues in locating an entity over sensor networks
• Halibut, an In-Building Location System

Process

1. Write pre-proposals and form teams

Proposal due 24 April.

By the end of this stage, each student should be part of a team (3-5 students), and each team should have created a project proposal and made it available on the web.

How you go about this depends on your situation. If you already have a clear idea of your project, you can start writing the proposal, post it, and recruit other students from CS 444N to join your team. If you have a less clear idea, you may want to meet with other students and brainstorm a project idea.

The proposal is a one-page description of the project, including the following:

1. Name, email, homepage for each team member, include one primary contact for the team
2. Overview of the project explaining what it is and what problem it solves.
3. What existing components or services can be leveraged, and what has to be built
4. Main novel technical challenges in realizing the project
5. 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.
6. A couple of research questions you believe could be investigated through your project.

The project proposal should be formatted as an HTML or text document and made available on the web. The proposal, along with subsequent deliverables, will form your project web site.

When your proposal is posted on the web, send email to the TA to have a link added to the list on this page.

2. Finalize proposals

Final proposal due 1 May.

By the deadline, each team should:

1. meet at least once
2. ensure that their proposal contains a list of team members, a clear description of what they hope to demo, and what equipment and other resources are needed to complete the project

3. Go to it!

You have about one month to get from proposal to demoable prototype, with a writeup. You're free to schedule this time as you please, but we highly recommend getting started soon!

Contact us if you need help.

4a. Demo/poster session

Scheduled for 5 June.

For demo day, you should prepare (1) a working prototype, (2) a 5-10 minute presentation and (3) a poster with 6-10 slides.

The poster should capture the gist of your presentation, so someone who doesn't hear the presentation can still get a good idea of your project.

4b. Final reports

Deadline to be announced.

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 USITS.

The report should be approximately 6 to 10 pages and cover these points:

Motivation

What problem are you trying to solve? Why and how would someone use your system? Give a specific scenario. State your assumptions, like "Our wireless virtual-reality bifocals will be widely useful because we expect that within five years, 80% of senior citizens will be avid Quake players."

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?

Analysis and research results

Given the time constraints, we don't expect a detailed analysis, but at least speculate on the scalability, security, usability and fault tolerance of your system, and attempt to answer those research questions you identified for your project.

Lessons learned

References

4c. Complete project web site

Due date to be determined.

Your project web site should contain links to:

• your proposal
• your final report
• your code (bundled as a tar.gz or zip)
• an overview of the code, with instructions on how to run it (this can be part of the final report, or a separate README)

This site should remain available after the quarter is over, so that we can refer students to your site the next time the course is offered. If this is a problem due to lack of disk space or whatever, let us know so we can archive your site on our server.

4d. Return equipment

Do this by the end of the quarter. We know where you live!

$Id: projects.html,v 1.31 2002/04/03 00:50:55 mgbaker Exp $