Presentation - Kushagram/wireless-testbed GitHub Wiki

Background

In this experiment we are trying to look into the asymmetric distribution of the traffic that exists between the uplink and downlink and how this ratio of uplink and downlink traffic evolves as the total traffic exceeds the total available bandwidth of the channel. The inherent principle that gives rise to the above problem is the Half Duplex system which forms the basis of wireless transmission and the concept of queue at each station.

Queue : Since a common channel is being shared by all the stations and the Access Point, multiple stations are in a contention to send the frames to the Access Point.These packets when they arrive at the channel,get lined up in a queue( which uses FIFO principle) and are sent at the fraction of the bandwidth that has been alloted to them.However the thing that has to be kept in mind is that the rate of packet arrival should not exceed the data rate at which the data is being transmitted. Same thing applies for the Access Point end as well.
Congestion : A channel is said to be congested when the rate of packet arrival surpasses the allotted rate of data transmission. The queue which has a fixed buffer(we can intuitively say that actually the traffic has gone beyond the total bandwidth available) would no longer be able to fit in more data packets. Hence some data packets start getting dropped as well as the data packets already in the queue have to wait for a longer time,thus increasing the latency and dropping the data transmission rate.Thus once congestion comes into the picture this continuous increase in the packet arrival rate at the channel has inverse relation with data transmission rate.

How is the above theory relevant to our experiment?

In our experiment there are 3 clients and 1 Access Point.Initially the downlink to uplink ratio is 1:3 but as the packets/sec are continuously increased at both the client end and Access Point end, at one point the rate of arrival of packets at the Access Point end surpasses the rate at which it transmits the data.This leads to congestion on the Access Point side hence leading to an overall decrease in the rate of packet transmission(i.e the bandwidth alloted to the downlink end). Since the overall throughput of the channel remains constant,thus if bandwidth allotted to Access Point goes down the marked out portion is added to the uplink's allotted bandwidth. Hence even though there is a continuous increase in the rate at which the packets arrive at the uplink stations even then they don't run out of buffer because of their continuously increasing allotted bandwidth.This change in ratio becomes steady once the uplink to downlink ratio reaches close to 3:1, which is the same as we get from theoretical analysis.

Exploring where the unfairness lies in the above issue

Right now in the steady state the bandwidth alloted to each station is c/4(where c is the total bandwidth of the channel), due to the CSMA/CA protocol working behind the curtains.At the Access Point side this c/4 further gets distributed near about equally amongst the three flows. Hence approximately c/12 to each flow at the Access Point.This is where the unfairness lies, even though the Access Point is handling three flows still it gets allotted same share of the bandwidth allotted as the stations with one flow got.

What should be the scenario to eliminate this unfairness?

Ideally the bandwidth of the channel should be allotted in proportion to the number of flows rather than in proportion to the number of stations in contention for gaining the access.Hence in above case it should have been c/6 to each flow(since total number of flows is 6). Thus bandwidth allotted to each of the uplink station in the steady state would be c/6 and bandwidth allotted to the downlink station(Access Point) would be (3*c/6) i.e c/2. Now the station with more number of flows is getting more bandwidth which is what we ideally want.Or we can implement the protocol in such a way that the AP has greater chance of access to the channel.This can probably be achieved by instead of sending ACK frames all alone they can be sent along with any pending sequences in the queue.Hence in this way the next sequence gets transmitted during the SIFS interval itself without having to face any contention as no station tries to send unless it finds the channel empty for a period equal to DIFS.

Run my Experiment

In this experiment, I used the sb4 testbed on ORBIT. To reserve time on this testbed, log in to http://geni.orbit-lab.org, click on "Control Panel", click on "Scheduler", click on the grid squares corresponding to the "outdoor" testbed and the date/time you want, and submit your reservation request. You may then complete the experiment at the reserved time.

Set up the testbed

At your reserved time, SSH into outdoor.orbit-lab.org.

Load the wifi-experiment.ndz image onto the 8 nodes that you will use in your experiment-in my case:

omf load -i wifi-experiment.ndz -t node1-1.outdoor.orbit-lab.org,node1-2.outdoor.orbit-lab.org,node1-3.outdoor.orbit-lab.org,node1-4.outdoor.orbit-lab.org

(Note that the command above is all one line, and there are no spaces between the commas and the node names.)

After this process is finished, turn your nodes on:

omf tell -a on -t node1-1.outdoor.orbit-lab.org,node1-2.outdoor.orbit-lab.org,node1-3.outdoor.orbit-lab.org,node1-4.outdoor.orbit-lab.org

In this experiment we have reserved 2 terminals for each of the client nodes hence in all 6 terminals are there plus 3 terminals for the Access Point. Then open eight terminals, SSH into the outdoor testbed console with your GENI wireless username and keys, and SSH from there into each of the four nodes (using the username "root").

Next ssh into each of the nodes on two terminals each. For example to ssh into node 1-3 run the following commands in each of the two terminals that you want to assign as node1-3:

ssh root@node1-1

Similarly repeat for node1-2,node1-3,node1-4 as well.

Note: We would be making node1-1 the Access Point and node1-2,node1-3 and node1-4 the clients.

Configure the wireless access points

SSH into one node from outdoor console and set it as a AP .We take that node as node1-1.On this node bring up the wifi interface with the following command:

ifconfig wlan0 up

Then, run the following command to set up a WiFi AP with ESSID "wireless1" and password "secretpassword":

create_ap -c 1 -n -g 10.10.10.1 wlan0 wireless1 secretpassword

where -g flag helps you to explicitly assigh the desired IP address to the AP.

In the output you should see :

ap0: AP-ENABLED

Now let us connect each of the clients to this Access Point.

On one of the clients' terminal run the following commands(because running the following commands on multiple terminals of the same client would lead to multiple processes running in the background eventually leading to the failure of the wireless interface):

First set up a Wifi configuration file :

wpa_passphrase wireless1 secretpassword > wpa.conf

The wpa_passphrase utility turns your human-readable password ("secretpassword") into a preshared key (psk) format, and the results are redirected to a file. (You can see this file with cat wpa.conf.)

Then bring up the wireless interface using(** don't forget this step**:

ifconfig wlan0 up

Finally connect to the network with:

wpa_supplicant -iwlan0 -cwpa.conf -B

Thereafter in order to assign the IP address to this node run :

ifconfig wlan0 10.10.10.X

where X is the number to the right of the hyphen in node1-X. e.g.: for node1-4,X would be 4

In order to check that all the client node have indeed got connected to the Access Point run the following command from the client node whose connectivity you want to verify:

ping -c 1 10.10.10.1

Sending UDP Traffic over the network

On the node that will generate the downlink traffic, create four separate "send.txt" files to begin with, and name them according to the packet rate: send-150.txt, send-300.txt, send-450.txt, send-600.txt,send-750.txt,send-3000.txt,send-15000.txt

When you run the experiment, use bash variables to fill in the name of the node, the experiment parameters, and the trial number in the log file names. For example, at the beginning of an experiment run, you would run (on all the nodes):

UPRATE=50

DOWNRATE=150

NODE='node name'

TRIAL=1

Similarly when you change the uprate and downrate then run all the above four commands on all the nodes again.

We use D-ITG to generate traffic in the network.

Install D-ITG on each of the nodes using:

sudo apt-get install d-itg

For each flow of traffic you should run ITGSend on the sender node and ITGRecv on the receiver node.Hence for 3 uplink flows run ITGSend on each of the three 3 clients' terminal and and run ITGRecv on AP's terminal.For downlink we specify multiple flows in a script and run a single send session on the Access Point and 3 ITGRecv on each of the clients.

Then,on the UL-generating nodes i.e node1-2,node1-3,node1-4, you would run e.g.

ITGSend -a 10.10.10.1 -rp 7555 -T UDP -C "$UPRATE" -c 1000 -t 60000 -x "$UPRATE-$DOWNRATE-$TRIAL-$NODE-rx.log" -l "$UPRATE-$DOWNRATE-$TRIAL-$NODE-tx.log"

At the same time run ITGRecv on the receiving AP terminal.

Similarly if we want to send 3 flows of UDP packets with size 1000 bytes at the rate of $DOWNRATE from the Access Point on another AP terminal,to create the script file run the following commands:

$ cat  >  send-"$DOWNRATE".txt <<END

> -a 10.10.10.2 -rp 8999 -T UDP -C $DOWNRATE  -c 1000 -t 60000

> -a 10.10.10.3 -rp 8999 -T UDP -C $DOWNRATE -c 1000 -t 60000

> -a 10.10.10.4 -rp 8999 -T UDP -C $DOWNRATE -c 1000 -t 60000

END

Next start the sender to send the above script file:

ITGSend send-"$DOWNRATE".txt -x "$UPRATE-$DOWNRATE-$TRIAL-$NODE-rx.log" -l "$UPRATE-$DOWNRATE-$TRIAL-$NODE-tx.log"

Then, your log files will be nicely named with all the details in them, e.g.

50-150-1-node1-4-tx.log 50-150-1-node1-4-rx.log

In order to receive the above files run

ITGRecv -l "$UPRATE-$DOWNRATE-$TRIAL-$NODE-rx.log"

on each of the client' receiving terminals.

After, all the ITGSend have finished sending the packets close all the receivers by using Ctrl-C.

Next in order to analyze the bitrates of the packets sent, run the following command:

ITGDec "$UPRATE-$DOWNRATE-$TRIAL-$NODE-rx.log"

on each of the clients' receiving terminals whereas run

ITGDec "$UPRATE-$DOWNRATE-$TRIAL-$NODE-rx.log"

on the AP's receiving terminal.

In between trials of experiments with the same parameters, you would just change the "TRIAL" variable, e.g. run

TRIAL=2

on all the nodes, and then run the same ITGSend commands (with the variable embedded in them!). When you start a new set of parameters (four times), you would run the whole block of four lines to set all four variables.

Note down the kbits/sec value for each flow while at the same time ensuring that the percentage of packets dropped is negligible.

Sending TCP traffic over the network

Wherever the phrase UDP appears in the commands described in the previous section just replace them with the TCP phrase.Rest all the commands would be the same.

Results

We can notice that as the total demand increases the existing CSMA/CA protocol which forms the basis of operation is designed such that it favours the uplink traffic volume which is clearly evident from the bar graph obtained from the data set.The graph has been obtained using a software known as plotly. Note that for higher total demand values, the share of uplink traffic is more than that of downlink traffic.

All the above observations are probably due to the issue of congestion and unfairness that is inherited from the CSMA/CA protocol since the access to the channels is random i.e. all the stations have equal probability of getting access to the channel.

The graphical representation of data rate distribution in case of UDP packets is:

https://user-images.githubusercontent.com/24861389/28075280-a6200a9e-6678-11e7-8dc7-6275376a0bd1.png

The graphical representation of data rate distribution in case of TCP packets is:

https://user-images.githubusercontent.com/24861389/28075156-3d68abaa-6678-11e7-8128-4f003b848c96.png