-ECE 697W. Special Topics in Wireless Communications

Final Project Report Format Specification

This semester, the projects are quite diverse, ranging from paper designs to substantial implementations. So it is not so easy to provide a single specification for the project write up. Here is a specification used in other courses. Consider it a broad outline that you will need to adapt for your specific project. In general, projects which are more of the "conceptual design" flavor will require a longer length than those that are "implementation driven".

 In general, the model you should follow is like a research conference paper. The elements of such a paper are the following. While it is not necessary to slavishly follow this outline, it is a good starting point, and any reasonable report with cover this set of topics. I expect the reports to be between 20 and 25 pages (maximum) in length, including figures, charts, and tables of results. However, please do not pad your reports simply to achieve a particular length. If you require less space to communicate your ideas (or more pages for appendices and graphs), that is fine.

  1. Abstract (0.5 pages)
  2. Introduction (2 pages)
  3. Related Work (2 pages)
  4. Methodology or Technical Approach (2 pages)
  5. Design Rationale (3 pages)
  6. Technical Results and Analysis (as long as necessary; 10-15 pages is not uncommon)
  7. Future Work (0.5 page)
  8. Summary and Lessons Learned (0.5 pages)
These are explained in more detail in the remaining sections.

Title

It is important to choose a report title that communicates what your project is about. For example, a title like "On Wireless Network Performance" is not nearly as descriptive as "The Performance of Fast Hopping Spread Spectrum Packet Radio Networks: An Analysis of Metricom's Ricochet System."

Abstract

The abstract should provide a broad overview of the report, ending with a short statement of the major results of your investigation. Identify the audience likely to be interested in your results (communications theoretists, protocol designers, security experts, etc.), and use the abstract to draw in that audience by briefly describing your key idea and experimental approach. The abstract should be strong enough to encourage the reader to read the rest of the report. Abstracts are very limited in length, rarely more than one half page.

Introduction

The Introduction usually expands on the abstract, and is often 2 pages long. It starts out broad and then gets very specific about your project. It's job is to set the stage for the report. Why is cache performance important? What are the relevant technology trends that influenced your project? End the Introduction with a paragraph or two description of what you did and your key results and/or observations. The very last paragraph should a roadmap to the rest of the report.

Related Work

It is unlikely that you invented something completely new to be reported on in your report. I believe that it was Einstein who said "If I have seen farther, it is because I have stood on the shoulders of giants." Scientific papers (and dissertations!) are full of citations to related and previous work. You must put your own work in the context of what has been done before. Review the previous literature, identify its strengths and weaknesses, and make allusions to what is new or unique about your own work. 2 pages should be enough, but if you have done a very extensive literature search, this is an excellent opportunity to document what you have learned outside of the textbook (and suggestions for high quality supplemental readings are always welcome!).

 Sometimes it is easier to place the related works section at the end of the report, after you have presented your own ideas and results first. Either approach is fine, and it is just a matter of taste as to where this important section fits best.

Methodology/Technical Approach

It is important to communicate to your readers about your experimental method. Did you use an analytical model, a simulator, or a performance monitor? What benchmarks did you use, and why? Did you collect traces? Do you analyze the protocol for an existing wireless network? How did you collect your traces? What networks did you evaluate. Why did you choose them?

It is the responsibility of the section to document the PROCESS you followed during your project and the tools you used (including new ones you developed) in completing your project. 2 pages should be sufficient to document your project methodology.

Design Rationale

This is the first section that gets into the real meat of the report (but it only makes sense if you actually designed something!). It is difficult to give sweeping advice for a section like this, because the details will vary from one project to the next. Some projects may have a large design component, like a new network protocol or a new authentication mechanism. For example, if you developed a new scheme for power management in portable devices, this is the place to document that design and to explain why you designed it as you did. There is some element of design in almost every project. The job of this section is to document that design and to report on the alternatives you may have considered but then rejected. 3-5 pages should be long enough in most cases, but this section is one likely to vary in length the most from one project to another.

Technical Results and Analysis

This is the centerpiece of the report, and the one that will influence the project grade the most (by the way, it is also the one that gets the paper accepted or rejected at the conference!). Again, it is difficult to give general advice, but we will be looking for a qualitative or (even better) quantitative analysis of your ideas in this section. Prove to us that your acknowledge scheme yields lower latencies and higher throughputs for wireless traffic. Show us how your power management scheme yields improved performance. Demonstrate the value of your pricing model and how it can be used to allocate bandwidth in a wireless environment. And so on.

 Now it may be the case that your brilliant ideas have not panned out as big performance wins. This is ok. What IS important is that you understand the strengths and weakness of your proposed mechanism and that you include a detailed evaluation of that mechanism that illuminates its value (or lack thereof). If this section is quantitative, I would expect to find in it the plots and performance graphs, etc. If your project is a conceptual architecture, this is where to describe it and qualitatively justify it. It is important that you take (only) as many pages as necessary to explain your approach as is required.

 If you have a huge number of plots, it may make sense to place the detailed plots in an appendix, and just include summary data in the body of the report. The same is true if you have extensive equations or derivations for your analytical performance models.
 
 

Future Work

This is can be a short section. The main idea here is to document things you wish you had time to do but could not accomplish in the time frame of the project. Also suggestions for future projects that build on your accomplishments would be very much appreciated!

Summary and Lessons Learned

This is another short section. Now that you have presented your methodology, rationale, and results in some detail in the preceeding sections, you can summarize these in few paragraphs. A recipe for a good paper or presentation is the following: "Tell them what you are going to tell them, then you tell them, then you tell them what you told them." The summary section is responsible for the latter. Reiterate your results, now in the context of the full report.

 Undoubtedly, you will have learned much from the project in non-technical areas. For example, how to work as a team, how to schedule time, how to deal with the shortage of machines or other resources. This is an opportunity to document the lessons you have learned and to make suggestions to the instructors of how to improve the experience for future generations of  students. We value your feedback!

References and Bibliography

The final section is a complete bibliography of the references you used in formulating the project and in shaping your final results. An annotated bibliography is nice feature to include if you have time. I am interested in identifying valuable supplemental readings that could be included in future offerings of this course, and I am VERY interested in your impressions of the papers you have read.
this is revised from a document written by Randy H. Katz, ed., randy@cs.Berkeley.edu, Last Edited: 14 April 96