Rate Adaptation Algorithm and Cross layer
design optimization for TCP Wireless
network
A Project Report
submitted by
Ajin Tom (13EC202)
Kevin Dsouza (13EC256)
Pragun Khera (13EC234)
under the guidance of
Prof. Ashvini Chaturvedi
in partial fulfilment of the requirements
for the award of the degree of
BACHELOR OF TECHNOLOGY
DEPARTMENT OF ELECTRONICS AND COMMUNICATION
ENGINEERING
NATIONAL INSTITUTE OF TECHNOLOGY KARNATAKA
SURATHKAL, MANGALORE - 575025
November 10, 2016
ABSTRACT
Today, all the available IEEE 802.11 WLAN standards (802.11a/b/g) provide multi-rate
capabilities. To achieve a high performance under varying conditions, these devices need
to adapt their transmission rate dynamically. While this rate adaptation algorithm is
a critical component of their performance and algorithms such as Auto Rate Fallback
(ARF), Receiver Based Auto Rate (RBAR) and Adaptive Auto Rate Fallback (AARF)
have been published, there are certain limitations to each of these mechanisms. These
algorithms are each designed and optimised for specific usage scenarios, with each of them
showing reduction in performances when used in other scenarios. Additionally, most of
these rate adaptation algorithms fail to perform in a ”dense” wifi scenario, when many
clients are connected to a single AP. The Aim of this project is to improve upon these
existing RAAs and combine these with an effective cross layer approach involving the
TCP stack at the end device such in order to achieve enhanced performance over the
wireless channel, particularly in ”dense” scenarios.
i
TABLE OF CONTENTS
ABSTRACT i
1 Introduction 1
1.1 Problem definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Previous work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Description 4
2.1 Simulation of the Rate Adaptation Algorithms’ Performance . . . . . . 4
2.1.1 ConstantRateWifiManager . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 AarfWifiManager . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3 AarfcdWifiManager . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.4 CaraWifiManager . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.5 AparfWifiManager . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.6 IdealWifiManager . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.7 OnoeWifiManager . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.8 MinstrelHtWifiManager . . . . . . . . . . . . . . . . . . . . . . 12
2.1.9 AmrrWifiManager . . . . . . . . . . . . . . . . . . . . . . . . . 13
3 Conclusions 14
3.1 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
ii
LIST OF FIGURES
2.1 The topology for the simulation for a particular number of nodes . . . . 4
2.2 The Performance metrics for the ConstantRateWifiManager v/s the num-
ber of nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 The Performance metrics for the AarfWifiManager v/s the number of nodes 6
2.4 The Performance metrics for the AarfcdWifiManager v/s the number of
nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 The Performance metrics for the CaraWifiManager v/s the number of
nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6 The Performance metrics for the AparfWifiManager v/s the number of
nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.7 The Performance metrics for the IdealWifiManager v/s the number of
nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.8 The Performance metrics for the OnoeWifiManager v/s the number of
nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.9 The Performance metrics for the MinstrelHtWifiManager v/s the number
of nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.10 The Performance metrics for the AmrrWifiManager v/s the number of
nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1 The Comparison of performance the ConstantRateWifiManager with the
best RAAs with respect per node throughput and delay . . . . . . . . . 15
3.2 The Comparison of performance the ConstantRateWifiManager with the
best RAAs with respect to overall throughput and collisions . . . . . . 16
iv
CHAPTER 1
Introduction
1.1 Problem definition
There are many reasons for the highly volatile nature of the wireless medium used by the
IEEE 802.11 standard: attenuation, fading and interference from other radiation sources,
interference from other 802.11 devices in an ad hoc network, etc. We can classify these
transmission quality changes as either transient short-term modifications to the wireless
channel or durable long-term modifications to the transmission environment.
When packet loss over a wireless 802.11 link occurs, the TCP mechanism is uncondi-
tionally coupled with congestion control mechanism. Such TCP behaviour works fairly
well in wired networks where packet losses are mostly caused by link congestion. But in
a wireless medium, TCP connections encounter other problems like high BER, channel
asymmetries, mobility and limited bandwidth. Thus there is a need for a solution which
can account for the discrepancies in the channel and alter the characteristics of TCP. A
detailed description of the TCP variants used in wireless networks is presented in [1].
If the sluggish behaviour of TCP and the reduction of the congestion window is
eliminated, then TCP could be made faster over wireless media, which would be beneficial
to mobile users and low latency applications.
This problem dominates in a scenario where the number of users in a network are more.
According to [3] the TCP performance coupled with the RAA grows worse in a dense
network scenario where the number of people contending for the channel is more. Due to
this effect of contention, the overall application throughput turns out to be suboptimal.
1.2 Previous work
People have tried to solve the problem of wireless TCP performance in the past at the
MAC layer by developing Rate Adaptive Algorithms(RAAs). Some of the RAAs that
have been developed in the recent years are:
1. Auto-rate fallback (ARF)
2. Adaptive auto-rate fallback (AARF)
3. SNR based rate adaptation
Cross layer design approach has also been tried at the end devices. A survey of the
possible cross layer optimization techniques that could be implemented is delineated in
[4]. One of the cross layer approach is the TCP aware scheme. In the TCP aware scheme,
a split connection approach is used. A scheme called Freeze TCP is used which sends
out Zero Window Acknowledgement (ZWA). This relies on the network layer making
predictions about future disconnections and uses fast retransmit upon reconnection.
1.3 Motivation
The RAAs mentioned in the above segment are a good start to solve the TCP performance
problem [2]. But these algorithms are not fully efficient and can be improved further by
analyzing all input parameters. Typically, if someone walks by, opens a door, or moves
objects around, this will have an effect on the transmission medium for a transient time.
Its throughput capacity might drop sharply but not for long. If one decides to move
to another workplace, thus approaching the AP (Access Point), the attenuation will
decrease and this will have a longer lasting effect on the energy of the radio signal that
will probably decrease the BER (Bit Error Rate). Thus, the RAA should be able to
distinguish between these two cases. The cross layer approach has to be implemented in
a way as to not violate the end to end TCP semantic and be resilient to mobility and
other dynamic channel parameters.
2
Algorithms that adapt the transmission parameters to the channel conditions can be
designed to optimize a number of parameters depending on the network topology and
the type of device:
1. Power Consumption
2. Throughput
The main motivation behind this project is to improve the performance of TCP,
mainly the throughput as we are focusing on wireless networks with no stringent power
restrictions, over the wireless medium by enhancing the already existing Rate Adaptation
Algorithms at the MAC layer. Also, to come up with an efficient cross layer optimization
design at the end devices that can augment the TCP performance, mainly the interaction
between the MAC and the TCP layer.
1.4 Overview
Major Components
1. Review the already existing RAAs and simulate them in NS3
2. Come up with changes to these algorithms and see the improvements if any
3. Check whether improved set of input parameters can improve the RAAs
4. Try to break the problem into end-to-end and hop-to-hop and analyze
5. Come up with a cross layer design methodology
3
CHAPTER 2
Description
2.1 Simulation of the Rate Adaptation Algorithms’
Performance
• Traffic: TCP Cubic
• Rate Adaptation Algorithms: 9 in total
• Simulation time: 3 seconds
• Number of clients: Ranging from 1 to 50
• Topology: Single AP and number of clients ranging from 1 to 50 with serversrunning on every node. RandomDiscPositionAllocator is used to position the nodesaround the AP in the form of a disc in a random fashion as shown from a NetAnimvisualisation in figure 2.1. This topology is derived from [3] to simulate channelcontention and upload traffic.
• Scenario: The nodes keep sending traffic to the AP and thus contend for thechannel frequently. The channel losses are kept at a minimum and therefore theresults could be attributed to the collisions due to DCF contention.
• The changes in these parameters are compared with increasing number of nodesand the effect of a dense scenario is observed.
1. Average application throughput per node
2. Average delay per node
3. Total Goodput (Application-Level Throughput)
4. Total number of collisions
Figure 2.1: The topology for the simulation for a particular number of nodes
2.1.1 ConstantRateWifiManager
This algorithm uses constant rates for data and RTS transmissions. This will help us
set a baseline and compare the performance of TCP with and without rate adaptation
mechanisms.
Figure 2.2: The Performance metrics for the ConstantRateWifiManager v/s the numberof nodes
5
2.1.2 AarfWifiManager
Lacage, et al. proposed Adaptive Auto Rate Fallback (AARF) [2] to improve perfor-
mance in stable environments. Unlike ARF keeping the rate increase threshold constant
(N), ARRF adaptively adjusts this threshold. More specifically, a sender increases its
data rate rold to a new rate rnew after N consecutive successful transmissions. If the first
transmission at this new rate rnew fails, the sender falls back on the prior rate rold and
doubles the threshold to 2N for the next rate increase. Otherwise, i.e., the first trans-
mission at the new rate succeeds, the threshold is reset. With such adaptive threshold
updates, AARF increases the time interval between rate increases over a stable channel
and produces fewer rate fluctuations than ARF.
Figure 2.3: The Performance metrics for the AarfWifiManager v/s the number of nodes
6
2.1.3 AarfcdWifiManager
AARF-CD is derived from AARF, but it uses the RTS/CTS mechanism only when it is
necessary [8]. The challenge of rate adaptation schemes is to adapt the physical trans-
mission rate based on channel-related losses, i.e. collisions should not influence the choice
of the rate. In the cited paper, the authors proposed a new rate adaptation algorithm
that behaves like Auto Rate Fallback (ARF), but makes use of the RTS/CTS handshake,
when necessary, to decide whether the physical transmission rate should be changed.
Figure 2.4: The Performance metrics for the AarfcdWifiManager v/s the number of nodes
7
2.1.4 CaraWifiManager
Strategy Collision-Aware Rate Adaptation (CARA) [6] by Kim, et al. is designed to
handle collisions without using RTS/CTS frames under good conditions. CARA uses
of RTS/CTS in response to a frame loss. When a frame is lost, an RTS precedes the
retransmission of the lost data frame. CARA’s rationale is that RTS (always sent at the
basic rate) is resilient to channel fading. Therefore, if RTS is also lost, the data frame loss
is likely due to collision. Except for the use of RTS/CTS, CARA adjusts the data rate
similarly to ARF. Essentially, what CARA does is to use RTS/CTS to reduce collisions
from hidden terminals. To minimize the overhead from the use of RTS/CTS, CARA
suggests that a transmitting station switches its adapter to sense the channel immediately
after a transmission is over. If the channel is sensed busy and the transmission gets lost,
this loss is obviously inferred from collision without the need of an RTS.
Figure 2.5: The Performance metrics for the CaraWifiManager v/s the number of nodes
8
2.1.5 AparfWifiManager
This method relies solely on link quality information available at the transmitter by
employing the reception or non-reception of the acknowledgment frames as a measure
of the channel quality with respect to the power level and data rate [9]. The method
is fully compatible with the 802.11 wireless LAN standard. In contrast to many other
proposals, it neither relies on the RTS/CTS protocol nor requires a feedback channel to
transmit link-quality estimates from the receiver to the transmitter. Different strategies
for optimizing the data rate and power level are given. These depend on the scenarios
considered, the number of active stations, and the service requirements. The two main
strategies are either to drive the system towards the highest possible data rate and adjust
the rate and power levels accordingly (high-performance mode) or to focus on power
saving, possibly trading this for other performance criteria such as throughput or delay
performance (low-power mode).
Figure 2.6: The Performance metrics for the AparfWifiManager v/s the number of nodes
9
2.1.6 IdealWifiManager
This algorithm is similar to the RBAR [10] in spirit in the sense that every station
keeps track of the snr of every packet received and sends back this snr to the original
transmitter by an out-of-band mechanism. Each transmitter keeps track of the last snr
sent back by a receiver and uses it to pick a transmission mode based on a set of snr
thresholds built from a target ber and transmission mode-specific snr/ber curves.
Figure 2.7: The Performance metrics for the IdealWifiManager v/s the number of nodes
10
2.1.7 OnoeWifiManager
As the earliest implemented open source rate adaptation on a Linux driver, Onoe [5]
was developed by MadWifi organization for wireless adapters with Atheros chips. It is a
credit based algorithm and tries to find the best data rate with a loss ratio less than 50%.
Onoe adjusts the rate at the end of each 1000 ms cycle based on collected transmission
statistics. Therefore, Onoe is insensitive to bursty losses and irresponsive to fast changes
in wireless channel changes.
Figure 2.8: The Performance metrics for the OnoeWifiManager v/s the number of nodes
11
2.1.8 MinstrelHtWifiManager
The Minstrel rate adaptation algorithm uses a mechanism called a multi-rate retry chain,
which enables it react to short term variations in channel quality [7]. The retry chain
consists of four rate-count pairs, named r0/c0, r1/c1, r2/c2, and r3/c3. A packet is first
transmitted at rate r0 for c0 attempts. If these attempts are not successful, Minstrel
transmits the frame at rate r1 for c1 attempts. The process continues until either the
packet is successfully transmitted or ultimately discarded after (c0 + c1 + c2 + c3)
unsuccessful transmission attempts.
Figure 2.9: The Performance metrics for the MinstrelHtWifiManager v/s the number ofnodes
12
2.1.9 AmrrWifiManager
The requirement of an optimal RAA for a high latency application led to the introduction
of a Binary Exponential Backoff in the original MADWIFI algorithm [2]. This was
implemented by adapting the length of the period used to change the values of the
rate/count pairs. To simplify the logic of the code, the authors also decided to use
heuristics simpler than those in the MADWIFI algorithm to choose the rate/count pairs
at the period boundaries.
Figure 2.10: The Performance metrics for the AmrrWifiManager v/s the number of nodes
13
CHAPTER 3
Conclusions
The ConstantRateWifiManager is compared with the two best performing RAAs in dense
scenario i.e IdealWifiManager and MinstrelHtWifiManager with respect to certain assess-
ment indicators.
3.1 Analysis
Some of the observations that can be made from the figures 3.1 and 3.2 are:
1. Even though the RAAs do perform better than the constant rate manager, theoverall performance of the RAAs in a dense scenario is suboptimal.
2. Figure 3.1 shows how the throughput and the delay per node changes with increas-ing number of nodes. The RAAs have greater throughput and lesser delay whencompared to the ConstantRateWifiManager, but the performance gets degradedwhen the number of nodes goes beyond 10.
3. Figure 3.2 shows how the overall throughput at the sink and the number of channelcontention collisions changes with increasing number of nodes. The RAAs performmuch better i.e the throughput is higher than the ConstantRateWifiManager butdeteriorates in a dense scenario.
4. The number of collisions is observed to be higher in the RAAs as the mentionedRAAs tend to contend for the channel more often than the ConstantRateWifiMan-ager which results in higher number of collisions.
5. The throughput per node is what the user ultimately experiences and we think canbe a good measure of performance of the algorithms. When the number of nodesgoes beyond 10, both the algorithms, with and without the RAA behave poorlywith respect to the average throughput per node. This highlights the need for aRAA that performs well in a dense scenario with consistent upload traffic.
Figure 3.1: The Comparison of performance the ConstantRateWifiManager with the bestRAAs with respect per node throughput and delay
15
Figure 3.2: The Comparison of performance the ConstantRateWifiManager with the bestRAAs with respect to overall throughput and collisions
16
3.2 Future Work
Since the earliest rate adaptation work ARF for IEEE 802.11 networks, rate adaptation
has been extensively studied in the last decade. However, as shown by Reis et ale [11]
with measurement from realistic scenarios, the transmission of new data only accounts
for up to 40% of the time: most of the remaining time is consumed by retransmissions.
Therefore, rate adaptation requires more efforts to improve network utilization.
1. Error and mobility model: Integrate the already existing error and mobility modelsin ns-3 to our scenario and check the difference in behaviour of the RAAs fromperformance in a error less and stationery scenario.
2. Change to a download scenario and try to compare the results of the simulations.
3. New rate adaptation scheme: So far, there is yet no rate adaptation scheme that iseffective in both channel fading and collisions dominated environments, responsiveto quick transient channel dynamics, and yielding long term performance. New rateadaptation schemes are needed.
4. Cross layer behaviour: Check behaviour of TCP Cubic along with the RAAs; alsocheck the need for a cross layer approach.
17
REFERENCES
[1] Alexander Afanasyev, Neil Tilley, Peter Reiher, and Leonard Kleinrock , Host-to-
Host Congestion Control for TCP , IEEE communication surveys & tutorials, VOL.
12, NO. 3, third quarter 2010.
[2] Mathieu Lacage, Mohammad Hossein Manshaei, and Thierry Turletti , IEEE 802.11
Rate Adaptation: A Practical Approach, MSWiM04, October 4-6, 2004, Venezia,
Italy.
[3] Mukulika Maity, Bhaskaran Raman, Mythili Vutukuru TCP Download Performance
in Dense WiFi Scenarios, 2015 IEEE Transactions on Mobile Computing.
[4] Vijay T. Raisinghani, Sridhar Iyer, Cross layer design optimizations in wireless pro-
tocol stacks, Journal Computer Communications Volume 27 Issue 8, May, 2004,
Pages 720-724.
[5] Madwifi., ”http://sourceforge.net/projects/madwifi.”
[6] Kim, S. Kim, S. Choi and D. Qiao, ”CARA: Collision-Aware Rate Adaptation for
IEEE 802.11 WLANs,” in IEEE INFOCOM’06, Barcelona, Spain, April 2006.
[7] Dong Xia, Jonathan Hart, Qiang Fu, Evaluation of the Minstrel Rate Adaptation
Algorithm in IEEE 802.11g WLANs, IEEE ICC 2013 - Communication QoS, Relia-
bility and Modeling Symposium.
[8] Federico Maguolo, Mathieu Lacage, Thierry Turletti, Efficient Collision Detection
for Auto Rate Fallback Algorithm.
[9] Pierre Chevillat, Jens Jelitto, Hong Linh Truong, Dynamic Data Rate and Transmit
Power Adjustment in IEEE 802.11 Wireless LANs, International Journal of Wireless
Information Networks July 2005, Volume 12, Issue 3, pp 123145.
[10] Gavin Holland, Nitin Vaidya, Paramvir Bahl, A Rate-Adaptive MAC Protocol for
Multi-Hop Wireless Networks, ACM SIGMOBILE 7/01 Rome, Italy.
18