Computer Networks (CITS3230) - Project 2009

• The project - Description and Updates.

Consider a large region, such as the UWA campus, supported by a number of wireless access-points (APs). The access-points periodically transmit "beacon" frames to announce their presence and availability. These beacon frames, like all wireless signals, lose their strength over distance and thus cannot be "heard" everywhere. The region is not fully covered by the signal "footprint" from all access-points and, thus, there are many "black holes" within the region that cannot "hear" any of the access-points.

Mobile computers, such as laptops and handheld devices, associate with one of these access-points and pass traffic through it to communicate with the wider Internet. Such wireless traffic is said to make one hop between the mobile device and access-point, before the access-point further forwards the traffic "into" the Internet.

Fortunately, there are many mobile devices within the region willing to transmit and receive traffic on behalf of other mobile devices that are unable to associate with an access-point. Such traffic will take one extra hop to enter the wider Internet. Similarly, devices whose own traffic is already making two hops before reaching an access-point, are willing to relay the traffic of other, even more remote, devices.

Some traffic thus makes one hop to the Internet, some two hops, some three hops, .... Obviously, fewer hops provide a faster and more reliable service, and the mobile devices are always interested in their traffic taking a shorter path, if possible.

Being portable, the mobile devices will eventually move, resulting in some devices being able to "hear" an access-point, some devices becoming "closer" to an access-point, some devices becoming "further away" from an access-point, and others becoming disconnected entirely.

For simplicity, we'll assume that all mobile devices wish to undertake all of their communication with a single host on the Internet - one that simply receives all messages and immediately replies to them. Such a host could be providing a Twitter-like service, or sequenced frames from an unmissable video. As this single host is "on the Internet", it is equally accessible via all access-points.

There are many metrics that we could use to evaluate the effectiveness of such a wireless network. The speed at which messages can be delivered will depend on a number of properties of the network, including the average number of hops between a mobile device and the access-point by which it's currently reaching the Internet, the number of devices in the communication region (and thus the device density), and the speed at which mobile devices move (and thus come into, and lose, contact with other devices). To evaluate the effectiveness of our protocol we, thus, need to evaluate it under a range of operating conditions.

The goal of this project is to design, implement, test, analyse, and document a simple wireless network protocol that meets the needs of the mobile devices in the above region.

The project is designed to assess your understanding of important aspects of MAC, Data Link and Network Layer networking protocols, and the clarity with which you analyse and report on your observations.

Your protocol and its analysis must address the following requirements:

1. Implement and test a carrier-sense multiple-access with collision-avoidance (CSMA/CA) MAC protocol by which your mobile devices transmit wireless data frames. Your MAC-layer protocol should be a close approximation to that of the IEEE 802.11 WiFi standard.
2. Design and implement a simple strategy for the exchange of messages between each mobile device and the common destination.
3. Design and implement some simple metrics by which you will be able to evaluate your protocol.
4. Undertake a wide variety of tests on your protocol to evaluate its effectiveness under a variety of device densities and device mobility conditions. Present your analysis in your written report, including a number of plots which demonstrate and support your analysis.

The project contributes 40% of your mark in CITS3230 this year.

You must undertake the project in teams of up to three. Your choice of project partners is up to you.

Unless a declaration requesting a different breakdown of marks, signed by all team members, is provided to Chris McDonald by the project's deadline, all members of a team will receive the same mark.

Anyone wishing to find a project partner should contact Chris McDonald as quickly as possible, so that individuals may join a team.

The deadline for submitting your team's project materials is:

You should use the web-based project submission program, cssubmit, to submit:

• A file named README clearly stating the names and student numbers of students in your team. Only one team member needs submit a copy of the materials for marking.
• commented C source files for execution within cnet.
• commented cnet topology files and shellscripts that clearly demonstrate how much of the project you have completed. These will be considered, and used, during the marking process to evaluate how well you have tested your protocol.

By the deadline you should also hand in a printed copy of your team's project documentation, together with a signed project declaration sheet, to the School's front office. Do not place your documentation in a folder - just place one staple in the top-left corner.

Your documentation, at most 12 A4 pages in length, should include:

• any special instructions necessary to execute your protocol or to re-run your experiments,
• descriptions of your experiments, and
• graphs demonstrating the effectiveness of your protocol.
  Each graph presented should be accompanied by a brief description of what the graph is showing, and why it demonstrates a successful ''result''. You should also attempt to describe any unexpected results.

Your documentation should not include printed source code listings, a description of your code, nor data structures.

Your network protocols must be written in ISO-C99 as the cnet simulator compiles them using the GNU C compiler, with the switches gcc -std=c99 -Wall -pedantic. Ideally, your protocol should be developed in multiple C source code files, with each file having a distinct responsibility (e.g. one for a CSMA/CA layer, a data link, and message management).

The best preparation for the project is to have completed all laboratory sheets. While they don't focus on wireless networking, they introduce many concepts and cnet features important for this project.

Starting materials are available from the Linux directory /cslinux/examples/CITS3230/project. These provide some sample cnet-based code to demonstrate how to use its wireless network functions, and some sample cnet topology files for the project.

If you have limited experience with C, please request as much help as necessary during CITS3230 laboratory sessions or via help3230, or from the CITS1210 teaching materials.

The cnet simulator is available in our School on all laboratory computers running Linux. Its full documentation and source code is also available from www.csse.uwa.edu.au/cnet3 and you are welcome to undertake the project on your home Linux or Mac-OSX computers. Please note, however, that all materials submitted for marking must be working on our School's Linux machines by the due date.

Please post requests for clarification about any aspect of the project to help3230 so that all students may remain equally informed.  

Good luck,

Chris McDonald
30th April 2009.