Unit home

help3002

Lecture recordings
via LMS

Schedule

Project

Final exam

Unit outline

Resources

Textbooks

Extra reading

Look after yourself!

Labsheet 4 - for the week commencing 25th March 2024

1. [30 minutes - and as discussed in Tutorial-3]
   In Lecture-4 we saw how a number of uncoordinated nodes can share a transmission medium, such as a wireless medium, by using the medium in a cooperative manner and using randomness to resolve contention.

   Develop a function in pseudo-code (similar to either Java, Python, or C, or anything), to simulate multiple network stations communicating using a Slotted ALOHA protocol. Your function should be provided with parameters, such as the number of nodes, the probability that a node has a new frame for transmission, and the probability that a node is wishing to re-transmit a frame that was previously involved in a collision.

   Determine what the important metric of observed channel utilization means for the a Slotted ALOHA protocol. Ensure that the observed channel utilization may easily be measured (perhaps the return value of the function).

2. [30 minutes]
   [example starting file: slottedaloha.c]
   Now, convert your pseudo-code into some executable code, written in Java, Python, or C (your choice, you don't have to use the provided example code). Your solution should complete your function SlottedAloha() so that it will calculate the network's channel utilization for various parameters.

   Don't be overwhelmed by this problem. You are not being asked to develop a protocol using the cnet framework. A working solution requires only about 30 lines of code to be added to the function SlottedAloha().

3. [30 minutes]
   Now, in a manner similar to previous exercises using cnet, develop a shellscript to execute your simulation many times, varying the number of nodes, and the transmission probabilities. Using Google Charts (or any other preferred software) to plot the channel utilization for the various parameters.
   
   
   
4. [20 minutes]
   [files required: GEOROUTING, georouting.c, and mobility.c ]
   GEOROUTING is a topology file which defines the attributes of a simple wireless Ethernet (IEEE802.11) simulation. You'll observe that the simulation executes over a fixed area, and that we can define as many, or as few, nodes as required.
   • georouting.c implements a very simple mobile/wireless routing protocol. Each node periodically generates and transmits messages for delivery to other nodes. As copies of each message arrive at the mobile nodes, the destination either accepts messages addressed to it, or other nodes forward the message if they are closer to the final destination (The protocol is unrealistic in that every node 'magically' knows the location of all other nodes, even if they are out of range).
     Note that georouting.c does not use cnet's built-in Application Layer to generate and receive messages (it could do so with a small change, though the AL would report many errors until you implemented Q4 of this labsheet). Instead, georouting.c just generates short random messages in its transmit() function, and some statistics are printed when cnet is terminated.

   • mobility.c implements the movement "strategy" of each node. The random waypoint model simply involves choosing a random destination, walking towards that destination at a constant speed, pausing at the destination for a specified time, and then choosing a new destination. Mobility happens "in the background", and is independent of wireless transmissions (of course, we can both walk and talk, can't we?) There is no real need to understand how this node mobility code works, although it follows cnet's familiar event-driven model.

   Note that the file GEOROUTING defines a simulation over a 1000m square map, which is too big to display. Change the values of mapheight and mapwidth to, say, 200m each.

   Then execute the provided code with the command:

   cnet -gN GEOROUTING

5. [15 minutes]
   [files required: plot-pausetime-to-html.sh, and plot-walkspeed-to-html.sh, ]
   You may like to consider the shellscripts which each produce plots either as HTML for display in your browser. Each shellscript invokes multiple georouting simulations, varying either the nodes' walking speed or the amount of time that they pause before choosing a new walking destination.

   Are you able to provide an explanation for the variation in the plots, or is there just too much randomness in the system for us to see any patterns?
   
   

6. 🌶 [1 hour]
   The basic georouting protocol does not account for lost or duplicate frames. Without an acknowledgment scheme in the protocol, we cannot account for lost frames - they are not retransmitted and, if not received, they are simply "lost"
   Similarly, because multiple nodes can receive and retransmit each frame (each trying to "do the right thing" in the cooperative network), it is possible that multiple copies of the same frame will eventually arrive at the intended destination.
   Implement (transfer from your earlier lab work) a simple stop-and-wait scheme to correct this.

7. 🌶 🌶 [1-2 hours]
   In the basic georouting protocol, above, nodes do not attempt to detect, avoid, or resolve frame collisions in the wireless medium. In fact, they are oblivious to all problems because each node transmits its wireless frames by calling CNET_write_physical_reliable() which (silently) does not introduce any collisions.
   Replace the use of CNET_write_physical_reliable() with the standard CNET_write_physical(). Frame collisions should (may) now be observed and are reported on the Statistics subwindow.
   Implement the traditional IEEE802.11 Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) mechanism, involving new Request To Send (RTS), Clear To Send (CTS), and Acknowledgment (ACK) control frames.
   Collisions may (rarely) still occur, so you should also employ the use of the CNET_carrier_sense() function, an EV_FRAMECOLLISION event handler, and a binary exponential backoff algorithm.