This is a relatively simple enhancement of the skeleton files (mainly sim.sh and main.c). It will be far more clear then Example #2 - which becomes fairly involved in places. I recommend using this as a guide to generate ideas and supply syntactical examples.

There are 3 zip files:

• Data Link Layer Example (24 kb)
• Media Access Example (31 kb)       (this tutorial)
• Skeleton (17 kb)

Download the 2nd file, gunzip it, and untar it.

NOTE: The contents of this tape archive should reside in their own directory. If it is untarred in the same directory as either the skeleton or the other example, there will be a file collision and some files will be overwritten and lost.

The filelist should be as follows:

• event.h
• event.c
• main.h
• main.c
• makefile
• sim.sh
• sim.gnuplot.sh
• <sample.OP>/data.plot1.ps.00 Sample output from previous simulations
• <sample.OP>/data.plot1.ps.02
• <sample.OP>/data.plot1.ps.05
• <sample.OP>/data.plot2.ps.00
• <sample.OP>/data.plot2.ps.02
• <sample.OP>/data.plot2.ps.05
• <sample.OP>/data.plot3.ps.00
• <sample.OP>/data.plot3.ps.02
• <sample.OP>/data.plot3.ps.05
• <sample.OP>/data.plot4.ps.00
• <sample.OP>/data.plot4.ps.02
• <sample.OP>/data.plot4.ps.05

Type the command:

You will see the following:

	sim: Command line parameters are as follows
	sim:
	sim: Description.....command line flag: value
	sim: ---------------------------------------------
	sim: Number of nodes............(-n): 10
	sim: Channel length.............(-l): 100 (meters)
	sim: Propagation delay..........(-T): 3.3e-7 (sec)
	sim: Channel capacity...........(-c): 2.048e6 (bps)
	sim: Number of bits/packet......(-x): 2048 (bits)
	sim: Number of bits/ACK.........(-a): 8 (bits)
	sim: Max number of buffers/node.(-b): 30
	sim: Max contention window size.(-u): 1024
	sim: Min window contention size.(-v): 4
	sim: Prob[successful packet]....(-p): 0.0
	sim: SIFS.......................(-s): 8.25e-07 (sec)
	sim: DIFS.......................(-d): 1.32e-06 (sec)
	sim: T3.........................(-t): 9.9e-07 (sec)
	sim: System arrival rate........(-S): 1 (frames per sec)
	sim:
	sim: Please enter a Probablity that there will be an
	sim: unsuccessful packet transmission (ex 0.0, 0.2, 0.5):

These are the command line paramters which will be passed into the simulation.

Follow the directions in the script and run the simulation.

The script runs the "dcf" program 20 times as the default. It collects statistics for 3 plots:

• Channel Arrival Rate vs. Utilization
• Channel Arrival Rate vs. Average Packet Delay
• Channel Arrival Rate vs. Average Queue Length

It will collect these statistics for any Probability that there will be an unsuccessful packet transmission. (See above)

Then it will Ghostview the plots at the end of the simulation.

NOTE: There is sample output in the directory sample.OP

This is a simplified version of the Media Access Control Protocol for the IEEE 802.11 proposed standard on wireless LANs.

An explanation of this protocol is beyond the scope of this module. The simulation focuses on specific areas of the protocol such as:

• DIFS
• SIFS
• Random backoff of a node
• Collisions

It does not attempt to implement the protocol exactly. This would require about 3000 more lines of code (and a lot more time than i have).

The genEvent? functions I added (to the skeleton) are:

• gen_re_arrival();     Re-arrival of a packet to the channel
• gen_x_successful();     Successful transmission
• gen_x_unsuccessful();     Unsuccessful transmission

The utilities I added (to the skeleton) are:

• Prob();     Draw a random probability between 0 and 1
• queueItUp();     Add a packet to a node's queue
• willCollide();     Check to see if a new packet will collide

And the processEvent? functions I added (to the skeleton) are:

• processArrival();     Process an arrival to a node
• processReArrival();     Process a rearrival to a node
• processXsuccessful();     Process a successful transmission
• processXunsuccessful();     Process an unsuccesful transmission (collision)

Again, an explanation of the way these functions work is beyond the scope of this module. They are all quite short, so if you're interested in the data flow, it is obtainable directly from the code.

I modified main.c to add the above functions.

Specifically, I added the following to the skeleton:

• Several new variables
• Many of these to "initParams", "initAll", "showParams", and "showReport"
• My "genEvent?" functions and "processEvent?" functions
• Some utility functions to make the program more modular

The major difference between this program and the skeleton is the lack of a "printStatus" function. I implement this function inside of main.c, which is probably not a good idea (sloppy).

Also, since this program is collecting 4 statistics, in the "showReport" function, I open 4 data files, "a", "b", "c", and "d". Each of these has it's own 2 number pair representing a statistic from the simulation.

After 1 run, the files look something like this:

Since the program is being run but the script "sim.sh", these files are being concatenated to 4 data files, (data.utilization, data.packetdelay, data.queuelength, and data.re_arrivals) for plotting.

So, after 5 program runs, those data files look like this:

These programs will be plotted using 4 GNUplot driver files:

• data.plot1
• data.plot2
• data.plot3
• data.plot4

These driver files are generated when sim.sh calls sim.gnuplot.sh. If you want to generate these files on your own to see what they look like, type:

where:

• data1 = data file for plot1 (data.utilization)
• data2 = data file for plot2 (data.packetdelay)
• data3 = data file for plot3 (data.queuelength)
• data4 = data file for plot4 (data.re_arrivals)
• 10 = number of nodes in simulation
• 0.5 = probability of unsuccessful packet transmission

The sim.sh script required the most extensive modificaiton. Again, if you are unfamiliar with the UNIX operating system, no amount of explanation will make this script clear.

This script esentailly works the same way as the skeleton version - except it keeps track of the above 4 statistics altogether. This just means there are more files to keep track of, and therefore everything is esentially done 4 times, instead of once (as in the skeleton sim.sh).

It is liberally commented - so it is entirely possible to understand what it is doing by running it and looking @ the source.

Return to the tutorial and examples...