Project 2008 updates - last updated 3rd June

• The project - Description, Updates (last updated 3rd June), and iPod HOWTO .

• Starting materials for the project are available from the Linux directory /cslinux/examples/CITS3230/project
  • The first example provides a topology file RANGE, and C code, in range.c, to demonstrate how nodes with a single wireless interface can transmit and receive data. Execute this example with: cnet RANGE

    The C code simply positions nodes and then increases the transmission power of node0 to obtain a greater transmission distance. At the default transmission power of 14.7dBm, a wireless signal will (theoretically) propagate 170m. You do not normally need to set a link's transmission power before every transmission.

  • The second example is more detailed, and may (should) be used as a "skeleton" to start your project. It requires a number of files: PROJECT, csse2nd.map, project.c, mapping.h, mapping.c, walking.h, and walking.c

    In combination, these files simulate a number of mobile devices walking around the top floor of the CSSE building. The topology file requests compilation of the 3 C files.

    Under execution, each node's reboot_node handler calls the readmap() function, which reads the layout of the CSSE 2nd floor from the text file csse2nd.map.    Other functions in readmap.c that are aware of the layout, choose random positions that are not inside the objects, and find walking paths that don't walk through walls. Functions in walking.c undertake random walks around the 2nd floor, and functions in project.c transmit random messages whenever a mobile node has stopped walking.

    For your project, there should be no need to modify either the mapping or walking code, but you are welcome to do so if you wish to improve them (or find a bug!).

• A new version of cnet (v3.1.1) is available from here for those running it on their own machines.
• An explanation of cnet's support for mobile and wireless networking may be found here: www.csse.uwa.edu.au/cnet3/wlans.html.
• If you are running cnet on your own computer, you will need to download and install (at least) cnet v3.1.1.
  Updates to cnet will be provided and announced to address any problems found.

Clarifications - newest items first

1. 3rd June - when compiling your protocols for the iPods (with cnet -P ) remember that the iPods do not support all of the functions/features of the full simulation. These include EV_APPLICATIONREADY, EV_KEYBOARDREADY, MAX_MESSAGE_SIZE, CNET_get_mapscale, CNET_get_position, CNET_set_position, and TCLTK.

   Use conditional compilation to isolate code requiring these constants or functions.

2. 2nd June - your protocols are required to implement the RTS/CTS/DATA/ACK control frame exchange when running within the simulator, but are not required to support this when executing on the iPods (because the iPod WiFi hardware performs this for you). Use conditional compilation in your protocols to handle this:

       #if    defined(CNET4IPOD)
           ... less to do ...
       #else
           ... RTS/CTS/DATA/ACK ...
       #endif
   

3. 2nd June - when using the iPods, keep in mind that your devices are just broadcasting into the wireless medium and, thus, anyone may receive a copy of your transmissions. Hence, you may receive copies of the transmissions of others, and so you'll need to distinguish your transmissions from the chatter. A suggested mechanism is to place a unique integer, such as your phone number, at the head of your outgoing frames, and then to ignore any arriving frames not carrying this integer.
4. 16th May - The starting materials are provided as a guide - you do not have to use any of them if you wish. In particular, the C files walking.c and talking.c work together to implement a model where each node only transmits data when it is stationary. You do not have to support this model, and are free to implement nodes that transmit whenever they wish.
5. 1st May - The original project description carries the wording "Messages eventually arriving at the intended destination do not need to be acknowledged." This means that, if a message is generated in node N1 for node N2, then when (if?) that message arrives at node N2, possibly after many hops and after many minutes or hours, then node N2 does not need to inform node N1 of its arrival.
6. 1st May - Calls to CNET_write_physical() may result in frame collisions in the wireless medium if two or more nodes transmit at nearly the same time. Calls to CNET_write_physical_reliable() will not generate any collisions. You must be calling CNET_write_physical() in your final project submission.
7. 1st May - Your project should not employ cnet's standard Application Layer, and its functions CNET_read_application() and CNET_write_application(). We cannot use cnet's standard Application Layer for this project because it will forever complain when any message is delivered out of order, missed, or duplicated. Simply generate, transmit, and receive your own random messages. However, your replacement code should ensure that messages are only (finally) accepted by the intended destination while acccumulating statistics such as the number of messages delivered, and their average delivery time.

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.