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

3.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

iii

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

[11] Maya Rodrig, C. Reis, R. Mahajan, D. Wetherall, and 1. Zahorjan, ”Measurement-

Based Characterization of 802.11 in a Hotspot Setting,” in ACM SIGCOMM Work-

shops, 2005.

19