Labsheet 4 - for the week commencing 22nd March 2020
Our Laboratory Zoom URLs
|Monday Laboratories, 11am-3pm
|Friday Laboratories, 12pm-4pm
The purpose of this week's labsheet is to introduce you to some basic
Local Area Networking (LAN) concepts,
to explore wireless-Ethernet (IEEE802.11).
- [30 minutes]
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 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,
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).
- [30 minutes]
Now, convert your pseudo-code into some executable code,
written in C, Java, or Python
(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
- [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.
- [20 minutes]
GEOROUTING is a topology file
which defines the attributes of a simple wireless Ethernet (IEEE802.11)
You'll observe that the simulation executes over a fixed area,
and that we can define as many, or as few, nodes as required.
Just execute the provided code with the command:
cnet -gN GEOROUTING
georouting.c implements a very simple mobile/wireless
Each node periodically generates and transmits messages for delivery to
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).
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
georouting.c just generates short random messages in its
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
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.
In the basic georouting protocol, above,
nodes do not attempt to detect, avoid, or resolve frame collisions in the
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,
Request To Send (RTS),
Clear To Send (CTS),
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.
- [15 minutes, JUST FOR INTEREST]
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 such variation in the plots?
The basic georouting protocol does not account for lost or
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"
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.