Computer Networks (CITS3230) - Project 2008

• The project - Description, Updates, and iPod HOWTO.

A delay tolerant network (DTN) is one in which nodes experience frequent, lengthy delays in communicating with other nodes because there is no guaranteed connectivity between communicating end points. DTNs are often described as potential mechanisms for communication between low-earth orbiting (LEO) satellites, for communication between mobile devices in environments lacking fixed infrastructure, and for emergency workers communicating after natural disasters. An often cited fun example of DTNs is the Wizzy Digital Courier service, which exchanges email between remote villages and schools in South Africa using motorcycles and a milk truck.

For an overview of DTNs, read the first 3 sections of the conference paper "Routing in a Delay Tolerant Network", in Proc. ACM-SIGCOMM'04, August 2004, (PDF, 13 pages).

DTNs best support environments in which wireless network coverage is sparse. The mobile devices, themselves, carry and exchange messages for each other. The devices (actually, the people carrying the devices) form a social network with other devices that they meet while walking around, and periodically try to keep in contact with them by generating and sending self-contained messages. Messages eventually arriving at the intended destination are unlikely to arrive in order and do not need to be acknowledged.

There are many metrics that we could use to evaluate the effectiveness of our DTN. For example, information in messages can lose its value over time, and if our DTN cannot deliver messages in a timely fashion, then it will not be considered effective (and hence will not be used). The speed at which messages can be delivered will depend on a number of factors, including the number of nodes in the communication region (and thus the node density), and the speed at which nodes move (and thus come into contact with other nodes).

Similarly, later messages from a source node can be considered more important than earlier ones, and mobile devices have limited storage available for carrying the messages of other nodes. In combination, these two factors suggest that nodes may have to occassionally drop messages due to a lack of storage.

To evaluate the effectiveness of our DTN we thus need to evaluate it under a range of operating conditions.

The project is designed to assess your understanding of important aspects of MAC, Data Link and Network Layer networking protocols, and your ability to analyse and report on your observations. This project has a number of goals:

1. To design, implement, test, and document a simple delay tolerant network protocol using the cnet simulator under Linux.
2. To analyse and report on the observed effectiveness of the protocol's execution within the simulator.
3. To modify the delay tolerant network protocol developed in part 1 (if necessary) to execute on the mobile Apple iPod Touch platform.
4. To again test, analyse and report on the observed effectiveness of the protocol's execution on the mobile platform.
5. To reflect on the effectiveness of first developing a protocol in a simulator and then deploying and testing the same protocol on a real networked device.

Your protocol and its analysis must address the following requirements:

1. When executing within the simulation, develop and implement a carrier-sense multiple-access with collision-avoidance (CSMA/CA) MAC protocol by which your mobile nodes transmit wireless data frames.
2. Develop and implement a simple strategy for the exchange of messages across the DTN, initially assuming unlimited resources. Test your DTN for a variety of node densities and node mobility conditions.
3. Develop and implement a message delivery strategy in which later messages from a source node supersede earlier messages, in an environment in which nodes only remember a limited number or volume of messages for other nodes.
4. Undertake a wide variety of tests on your DTN to evaluate its effectiveness under varying conditions of your choosing. 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 groups of four. Your choice of project partners is up to you.

Unless a declaration requesting a different breakdown of marks, signed by all group members, is provided to Chris McDonald by the project's deadline, all members of a group 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 group.

The deadline for submitting your group'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 group. Only one group 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 DTN protocol.

that you wish to be examined.

By the deadline you should also hand in a printed copy of your group'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,
• descriptions of your experiments, and
• graphs demonstrating the effectiveness of your DTN 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, chosen algorithms, nor data structures.

The best preparation for the project is to have completed all laboratory sheets.

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

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

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 and the Apple iPod Touches 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 2008.