The Mechanics

You will do this project in groups. The group should have strictly two or three members. Groups with more than three members will not be permitted. All groups will be judged against the same criteria irrespective of size.
 

• The project groups must be formed and submitted by February 15. A list of project ideas will also be released by this date. If you have ideas for the project, please discuss them with the professor before Feb 15.
• On or before February 27, you will submit (electronically) a document which provides preliminary system specs and design, assumptions you have made, and a plan of execution (including a proposed timeline). This should be emailed to cmsc628@cs.umbc.edu with the subject  "Project Proposal".
• The feedback on the project proposals will be given back by March 6.
• The modified project proposals (if need be) will be due on March 11.
• On April 3, you will submit a brief  report of your progress to date, changes in the design if any, as well as an updated timeline. Again, this will be via email , with the subject "Mid Term Progress Report".
• The project report detailing your work (the system design, experimental studies etc.) as well as submission of your code, will due on May 13, 2002 in a similar manner - emailed with subject as "Final Report". Code should be attached as a tarred, gzipped file. Please note that pdf, ps and text (formatted to 72 columns) are the only acceptable formats for all electronic submissions.
• You will also arrange to demonstrate your project to the instructor between May 16 and May 21. A sign-up sheet will be put up a week in advance. The report and code submission must precede the demonstration by 24 hours.

You are allowed to discuss the project across groups. Clearly, you are not allowed to share solutions. You may read papers and textbooks in this area as well. However, you should cite the sources you have consulted. You are free to chose any imperative language should you so desire, as long as the project runs on CS/UCS machines.
 

The Project ( 100 points)
Some of these projects have been suggested by other faculty members. The name of the faculty member that suggested the project is given with the project. You may wish to contact the concerned faculty member for more clarifications about the project.

• Service-based routing for ad hoc networks
• Freeze TCP implementation and analysis - (Dr. Phatak)
• Location Learning on 802.11 LAN - (Dr. Oates)
• Dynamic Transport Selection - selected
• Mobile Security - selected
• Adhoc FS - selected
• Bandwidth assignment on Combined wireless and optical networks - (Guo Aihua)
• Multi-media QoS studies over combined wireless and optical networks
• Ubiquitous Data Mining
• Semantic Caching in Pervasive environments

Tips on writing the proposal - adapted from a document by John Wilkes, Hewlett-Packard Laboratories.

When done well, a good project proposal results in a clear set of goals that guide the project and helped determine when corrective or supportive action is needed to help get things back on track. What follows are outlines for the five major portions that a project proposal should contain.

• Problem statement: What is the problem that this project is going to address? Does it matter: why is the problem important? Who will benefit when the problem is solved?
• Hypotheses: What is the basic approach, method, idea or tool that is being suggested to solve the problem? What are plausible alternatives? How likely are they? What is good and bad about them by comparison with what is proposed? What have others done already? What did they learn? (This is the literature search segment.)
• Experiments: What will be done to test out the hypotheses? How will this confirm (or deny) the hypotheses? Why will the conclusions be believable? Who will work on this? For how long?
• Results: What will be the outcome of the work (an implemented system, simulation results,...)? What are the intermediate milestones? How will we know when they are complete? What are the measures for success? (E.g. faster , smaller , more available .) How will we know to declare the project a success?

Some general suggestions

As should be evident to most of you, it is imperative for a project of this complexity and involving teams that you design your system before you code! In your design, you will need to make assumptions as you flesh in the details of the system. Please make sure that you state them in your design document. Make a timeline for your work, and try and stick to it. Where you divide tasks, make sure you clearly define points of articulation and interfaces between modules. As you form groups, please make sure that you can find a common time to meet. This is especially true for those who are part time students and hold jobs which will restrict your schedule. Please comment your code well -- it will help both you and us. You in figuring out code your partners have written, us in grading it. Also, use some form of revision control on your source tree. CS/UCS machines have systems such as RCS available for your use. This will help if lightening strikes, UPC fails and machines/disks crash, making your recent changes disappear! Please do create makefiles as well.