A performance evaluation on the use of IEEE 802.11 for long range communication

2005:040 CIV

M A S T E R ' S T H E S I S

A Performance Evaluation on the Use of IEEE 802.11 for Long Range

Communication

Mathias Eriksson

Luleå University of Technology MSc Programmes in Engineering

Department of Computer Science and Electrical Engineering

Master's Thesis

A Performance Evaluation on the use of IEEE 802.11 for Long Range

Communication

Mathias Eriksson

Luleå University of Technology February 3, 2005

Supervisor: Ingemar Nyström, FMV:RFN, Vidsel Examiner: Pierre Fransson, Luleå University of Technology Department of Computer Science and Electrical Engineering

Division of Computer Science and Networking

Abstract

Wireless equipment based on the IEEE 802.11 standard have enjoyed wide- spread success during recent years. Traditionally, such equipment have mainly been used indoors to allow users to wirelessly connect to the Internet or a LAN.

By using directional antennas the range of 802.11 equipment can be extended to reach several kilometers outdoors, expanding the areas of usage and applica- tions for the 802.11 standard.

This thesis evaluates of the shelf equipment based on 802.11 in a variety of situations, including both stationary and mobility tests. Performance tests of distances of up to 2000 meters have been possible to perform by connecting di- rectional antennas to standard access points. Furthermore, a number of dierent transport layer protocols have been tested in order to cover a broad spectrum of the various types of applications that can come into consideration. Knowledge of distance limitations for this type of equipment and the performance impact of dierent transport layer protocols is of interest to the missile test range, RFN, in order to see if it is possible to use standard o the shelf equipment for some tasks during test activities.

The results of the stationary tests show that the access points used in this the-

sis perform very well up to the maximum distance tested (2000 meters). Of

the four TCP variants tested TCP Vegas is the overall winner, combining high

throughput with noticeably fewer frames retransmitted by the access points. For

UDP, few packet losses and low jitter were seen in general. As for the mobility

tests, speeds of up to 100kph, although leading to more retransmitted frames by

the access points, showed promising results for both TCP and UDP with high

throughput and only marginally higher delays than for the stationary tests.

Acknowledgments

The work on this thesis took place between August 2004 and January 2005 at the missile test range, RFN, in Vidsel, Sweden. I would not have been able to carry out the work on this thesis or to accomplish ve and a half years' of studying without the following people, who I am deeply grateful to.

My examiner, Pierre Fransson, at the University of Technology in Luleå, Swe- den, for all the help and many tips with the thesis proposal and report.

My supervisor, Ingemar Nyström, for his help during my time at RFN.

Leif Stubbfält, for giving me the opportunity to do my thesis at RFN.

My classmates during my time as a student at the University of Technology in Luleå, for all the fun and hard work we have experienced together. You know who you are.

And last but not least my mother, Ingegerd Eriksson, for always supporting me no matter what I do. I owe you the world.

Vidsel, 2005-01-25

Mathias Eriksson

In memory of my father, Nils G. Eriksson

Contents

Contents ix

List of Figures xi

List of Tables xii

1 Introduction 1

1.1 Motivation and Goal of the Thesis . . . . 1

1.2 Demarcations . . . . 1

1.3 Report Outline . . . . 2

2 802.11 Background 3 2.1 802.11 Wireless LAN . . . . 3

2.2 802.11 MAC . . . . 4

2.2.1 Basic Access . . . . 5

2.2.2 RTS/CTS Access . . . . 7

2.3 802.11 Physical Layer . . . . 7

2.4 802.11 Security . . . . 7

2.5 Super G Technology . . . . 8

2.6 802.11 MAC Layer Theoretical Throughput . . . . 9

3 Transport Layer Protocols 12 3.1 User Datagram Protocol . . . 12

3.2 Transmission Control Protocol . . . 12

3.2.1 Improvements to TCP Reno(NewReno, SACK, D-SACK) 14 3.2.2 TCP Variants . . . 15

3.2.3 Linux TCP . . . 16

3.3 Real-Time Transport Protocol . . . 17

3.4 TCP performance issues in 802.11 Wireless LANs . . . 17

3.4.1 Mechanisms for enhancing performance . . . 18

4 Experimental Setup And Results 19 4.1 Equipment and Network Topology . . . 19

4.2 Software Tools . . . 20

4.3 Test Methodology . . . 21

CONTENTS

4.4 Test Site . . . 22

4.5 Test Cases . . . 22

4.6 Signal Strength . . . 24

4.7 Results and Discussion . . . 25

5 Conclusions and Future Work 48

Bibliography 49

A Abbreviations 51

B IEEE 802.11 Taskgroups 53

C Equipment and Software 54

List of Figures

2.1 802.11 OSI Model . . . . 3

2.2 General 802.11 Frame Format . . . . 4

2.3 Hidden Station Problem . . . . 5

2.4 BA Timing Scheme . . . . 6

2.5 RTS/CTS Timing Scheme . . . . 6

2.6 PHY Sub layers . . . . 7

2.7 Data Frame Format or MAC Protocol Data Unit . . . . 9

2.8 ACK Frame Format . . . . 9

2.9 PPDU frame format . . . 10

4.1 Network Topology . . . 20

4.2 Trac Types . . . 23

4.3 Signal Strength Reported by AP, legends showing the height above the ground for the stationary antenna . . . 25

4.4 Unidirectional TCP Throughput (Trac Type a) . . . 27

4.5 Bi-Directional TCP Throughput (Trac Type b) . . . 31

4.6 TCP throughput with UDP reverse trac, (Trac Type c) . . . 35

4.7 TCP throughput reported by Iperf with forward RTP trac and reverse UDP trac. APs in point-to-point mode using standard settings. (Trac Type f) . . . 41

4.8 Unidirectional TCP throughput (from Iperf, Trac Type a)

with UDP reverse trac (Trac Type c). APs in point-to-point

mode using standard settings . . . 46

List of Tables

4.1 Stationary Test Cases . . . 23 4.2 Mobility Test Cases . . . 24 4.3 TCP statistics output from TCPTrace, APs in point-to-point mode

using standard settings . . . 28 4.4 AP Statistics, point-to-point mode using standard settings. Mob

is short for mobile, stn is short for stationary . . . 29 4.5 Bidirectional TCP statistics from TCPTrace, APs in point-to-

point mode using standard settings. Mob is short for mobile, stn is short for stationary . . . 32 4.6 AP Statistics for bidirectional TCP, APs in point-to-point mode

using standard settings. Mob is short for mobile, stn is short for stationary . . . 33 4.7 TCP statistics from TCPTrace with UDP reverse trac, APs in

point-to-point mode using standard settings . . . 36 4.8 AP Statistics, One TCP stream and one Reverse UDP stream,

APs in point-to-point mode using standard settings. Mob is short for mobile, stn is short for stationary . . . 37 4.9 Reverse UDP statistics from Iperf, APs in point-to-point mode

using standard settings . . . 38 4.10 Unidirectional UDP statistics reported by Iperf, APs in point-

to-point mode using standard settings . . . 39 4.11 AP statistics for unidirectional UDP, APs in point-to-point mode

using standard settings. Mob is short for mobile, stn is short for stationary . . . 39 4.12 Bidirectional UDP statistics reported by Iperf, APs in point-to-

point mode using standard settings. Mob is short for mobile, stn is short for stationary . . . 40 4.13 AP statistics for bidirectional UDP, APs in point-to-point mode

using standard settings. Mob is short for mobile, stn is short for stationary . . . 40 4.14 TCP statistics output by TCPTrace, RTP forward trac and

UDP reverse trac. APs in point-to-point mode using standard

settings . . . 42

LIST OF TABLES

4.15 UDP statistics output by Iperf with reverse TCP/RTP trac, APs in point-to-point mode using standard settings . . . 43 4.16 AP statistics, TCP, RTP forward trac and UDP reverse trac.

APs in point-to-point mode using standard settings. Mob is short for mobile, stn is short for stationary . . . 44 4.17 Unidirectional TCP statistics (from TCPTrace) mobility test, APs

in point-to-point mode using standard settings . . . 45 4.18 Unidirectional UDP (from Iperf) mobility test, APs in point-to-

point mode using standard settings . . . 46 4.19 AP Statistics for mobility test, APs in point-to-point mode us-

ing standard settings. Mob is short for mobile, stn is short for

stationary . . . 47

Chapter 1

Introduction

1.1 Motivation and Goal of the Thesis

The missile test range (RFN) in Vidsel, Sweden, is a part of the Swedish Defense Material Administration (FMV). Its main task is to help verify and validate weapon systems and airplanes for the Swedish Air Force. In recent years, several other customers from countries including France, Great Britain, Germany, Italy and USA have performed tests at RFN. During tests, special equipment for wireless transmission is used to send command signals between dierent systems and steerable platforms, and also to gather test data from numerous sensors.

Although this equipment function very well, it is expensive and often custom built. At some occasions there is a need to place monitoring equipment, control equipment and sensors on objects or sites where the risk of destruction is high.

Furthermore, the work with cutting costs in recent years have been extensive which makes it interesting to look at alternative solutions. This is where o the shelf equipment based on the 802.11 standard could t in. Such equipment is inexpensive, oers reasonably high bandwidths and is easy to deploy. Normally, 802.11 is only used at short distances between sender and receiver, but the range can be extended with directional antennas. To know what applications that could be considered for 802.11 equipment, a thorough understanding of transmission protocols, delays, packet loss and throughput with respect to the distance between sender and receiver is needed. Therefore, it is the goal of this thesis to establish this understanding.

1.2 Demarcations

Initially, some extra buering capability was meant to be implemented to ensure

that data would not be lost in case of a breakdown of the wireless link. A

shortage of time meant that this had to be excluded from the thesis. Security

issues are only brought up on a theoretical level. This is because either the

data transmitted does not have to be encrypted, or encryption of the data

CHAPTER 1. INTRODUCTION

is done using hardware encryption and is the responsibility of the customers.

Furthermore, all tests were performed using the default settings for the various transmission protocols and operating system (Linux) used.

1.3 Report Outline

The rest of the report is organized as follows. Chapter 2 introduces the IEEE

802.11 standard and some information specic to the equipment used in this

thesis. Also, a calculation of the theoretical throughput for both TCP and

UDP is done. Chapter 3 presents the transport protocols evaluated in this

thesis and brief information about problems related to wireless transmissions

using the TCP protocol. Chapter 4 gives information about the equipment

used and test setup together with results and discussion. Finally, chapter 5

presents conclusions and future work. The chapters are meant to be read in

the order presented, but some sections of chapter 2 and 3 can be skipped if the

information given is already familiar.

Chapter 2

802.11 Background

This chapter introduces the IEEE 802.11 standard [1] and some of its extensions.

The main points of focus are type of services oered and how they are provided by the standard, explaining certain features/design decisions and the reasoning behind them.

2.1 802.11 Wireless LAN

Wireless LANs (WLAN) have become increasingly popular in recent years due to factors like low cost and exibility. 802.11 was rst standardized by IEEE in 1997 and revised in 1999. The standard species a media access controll (MAC) layer and a physical (PHY) layer, see Figure 2.1, for wireless connectivity in an ad-hoc or infrastructure network. It uses the same interface as Ethernet and

Figure 2.1: 802.11 OSI Model

therefore, the protocols running on top of such an interface can not distinguish 802.11 from Ethernet. The major dierences from Ethernet is of course the wireless media used for transmission and the possibility of having mobile users.

A WLAN may either consist only of so called stations (STAs) running in ad-hoc mode, or it may consist of STAs and access points (AP) in infrastructure mode.

It is among other things the job of an AP to provide access to a wired LAN and distribution services like association within the WLAN. Since the introduction of the standard, a number of task groups have been formed to add functionality and increase performance of 802.11

. In this thesis, the focus is on the high bit

1

see Appendix B for a summary of some of the 802.11 extensions

CHAPTER 2. 802.11 BACKGROUND

rate extension, 802.11g [2], which allows for data rates of up to 54Mbps. The data rate is dened in terms of available bit rate, i.e. no overhead in the form of encapsulation of data, collisions in the wireless media or processing delays in WLAN equipment are taken into account. The higher bit rates are achieved by using more advanced frequency modulation schemes. Since it operates in the unlicensed 2.4GHz band, it is susceptible to interference from bluetooth, microwave ovens and certain cordless phones. The operating range depends on the equipment used and environmental factors. Outdoors, with line of sight, the range may be anywhere between 50 and 300m assuming usage of the included standard omni-directional antenna.

2.2 802.11 MAC

The MAC layer of 802.11 is responsible for providing equal access to the shared, unreliable wireless media and reliable data transfer over the same. Although it is shared, no two transmissions can occur at the same time, since both transmis- sions would probably fail because of interference. Access to the shared media is regulated by an interframe space (IFS) time period that has to pass between the transmission of each frame. The IFS take on dierent values depending on the type of frame being sent, see section 2.2.1. The operation of transmitting one frame is atomic, that is, the operation has to nish before the next frame can be sent. A frame received from upper layers is called a service data unit (SDU), which is referred to as a MAC-SDU (MSDU) on the MAC layer. It is encapsulated by a header and checksum before being passed down to PHY as a MAC protocol data unit (MPDU). The 802.11 general frame format can be seen in Figure 2.2.

Figure 2.2: General 802.11 Frame Format

There are three dierent frame types. Management frames, used for exchanging management information between STAs, control frames that controls the access to the media and data frames that are used for data transmission. The MAC layer is also responsible for encryption of the frames and if needed, fragmenta- tion of the frames.

Two operating modes are oered, the distributed coordination function (DCF)

which is mandatory, and the point coordination function (PCF) which is op-

tional. DCF in turn oers two access methods, basic access (BA) which is

mandatory and ready to send/clear to send (RTS/CTS) which is optional. DCF

is sometimes referred to as contention mode, since each sender has to contend

for the access to the media. DCF is based on the carrier sense multiple access

2.2. 802.11 MAC

with collision avoidance (CSMA/CA) protocol. This protocol is designed to avoid collisions on the media by having a sender check if the media is busy prior to sending a frame. The actions taken by each member of a WLAN and the CSMA/CA mechanism is described in sections 2.2.1 and 2.2.2. The reason why a sender does not try to detect collisions is that it would require the capability of both sending and receiving at the same time, which would require much more advanced (i.e., expensive) technology. Also, a collision could still occur at the receiving end because of the hidden STA problem. As can be seen in Figure 2.3, this problem involves at least three STAs where two of them can not hear each other because of the distance or obstructions between them. However, they are both able to communicate with the third STA and may therefore interfere each others' transmissions.

Figure 2.3: Hidden Station Problem

2.2.1 Basic Access

Using BA, a STA about to send its rst frame and having sensed the channel idle for a period of more than or equal to distributed coordination function interframe space (DIFS), may start to send the frame immediately. The value of DIFS depends on the standard used. As an example, DIFS is 28µs when using only 802.11g compliant equipment. Each frame contains a duration eld, stating how much time will be used for transmitting the frame on the channel. This value allows competing STAs to determine or update their network allocation vector (NAV), so that they can keep track of how long they should defer their access. The value in NAV takes precedence, so access will be deferred whether or not the competing STA senses the channel to be idle during this time. When this time has passed, the STA will again wait for a time equal to DIFS and then enter the exponential back o algorithm, EBA. The rst part of EBA consists of adding an additional random backo (BO) time in order to decrease the probability of competing STAs sending at the same time. The random back o

time is calculated according to equation 2.1

BO = Backof f V alue ∗ SlotT ime (2.1) where SlotTime (ST) is 9µs for 802.11g compliant equipment only. The backo

value (BV) is selected from the uniformly distributed interval (0,CW-1) where

CHAPTER 2. 802.11 BACKGROUND

CW is the contention window. Equation 2.2 describes how CW is calculated

CW = 2

∗ CW

(2.2)

where n is the number of dierent CW sizes. CW is zero until the rst trans- mission attempt when it gets the minimum value 16. This value is doubled each time a transmission fails until its maximum value of 1024. The CW is reset after each successful transmission or after reaching one of the retry limits described below. The second part of the EBA consists of counting down the random back o time while the channel is sensed to be idle. When the random BO time reaches zero, the STA is allowed to immediately send its frame.

Upon receiving a frame correctly, the receiving STA waits for a period equal to short IFS (SIFS) before sending an explicit acknowledgment (ACK) back to the sender. SIFS for 802.11g is 10µs. If the ACK is not correctly received by the sender, the frame will be retransmitted up to 7 times. After 7 unsuccessful tries, the frame will be dropped. The retry count is maintained in a variable called station short retry count (SSRC). For BA, SSRC represents the number of retransmissions of data frames, where as it represents the number of resent RTS frames for RTC/CTS. SSRC gets reset upon correctly receiving an ACK with the BA method, or upon receiving a CTS with the RTS/CTS method. To keep track of retransmitted data frames for RTS/CTS, a variable station long retry count (SLRC) is maintained having a maximum value of 4.

Figure 2.4: BA Timing Scheme

Figure 2.5: RTS/CTS Timing Scheme

2.3. 802.11 PHYSICAL LAYER

2.2.2 RTS/CTS Access

The dierence between BA and RTS/CTS is how the connection between two STAs is set up. Assuming that the channel is idle for a time equal to DIFS, using RTS/CTS, the sending STA sends a RTS frame to the receiving STA, asking to reserve the area of the receiving STA for a limited time specied in the RTS frame. The receiving STA responds with a CTS frame after rst waiting for a period equal to SIFS. Upon reception of this frame, the area is considered to be reserved and the sending STA may send its frame after yet another SIFS period.

Should the sending STA not receive a CTS, the RTS is re-sent up to 7 times according to the SSRC. The advantage with RTS/CTS is that it takes care of the hidden STA problem, in that every STA in the range of the receiving STA will receive the RTS/CTS exchange, update their NAV and defer their access.

The dierence between BA and RTS/CTS is illustrated in Figure 2.4 and 2.5

2.3 802.11 Physical Layer

The PHY layer of 802.11 consists of two sub layers, the physical layer conver- gence protocol (PLCP) and the physical medium dependent (PMD) as can be seen in Figure 2.6. The PHY acts as an interface between the MAC layer and the

Figure 2.6: PHY Sub layers

wireless media. As such, it is responsible for the actual transmitting of frames and for sensing whether the channel is idle or not and reporting this back to the MAC layer. The 802.11 standard supports three dierent PHYs, of which the direct sequence spread spectrum (DSSS) is the most common used. DSSS works in conjunction with dierent modulation schemes

to represent data bits as symbols before transforming and spreading the energy of the transmitted signal in a wider frequency range. This makes it easier for the receiver to pick up the signal and recover the frame sent.

2.4 802.11 Security

As with any wireless transmission, the data sent can be intercepted by anyone within signal range using compliant equipment. Also, a non-authorized user may gain access to network resources, especially since the AP in many WLANs uses the dynamic host control protocol (DHCP). To prevent these problems, wired equivalent privacy (WEP) was introduced with the 802.11 standard. It

2

which scheme is used depends on the data rate speed

CHAPTER 2. 802.11 BACKGROUND

was supposed to oer a level of security comparable with wired LANs, where you somehow need to gain physical access to be able to intercept trac or use network resources. WEP uses a 40 or 104-bit secret key known by each STA in a WLAN prior to transmission. It then adds a 24-bit initialization value (IV) to the secret key to form the encryption key which it uses with the RC4-algorithm [3] to encrypt the data. However, WEP has proved to be easy to decrypt by a non authorized user. The reason is that the secret key is static and needs to be changed manually on every STA in a WLAN. Furthermore, the IV, although changed with every frame sent, repeats itself after a not so large number of frame transmissions and it is also sent in clear text. This will ultimately lead to the usage of the same encryption key after only a few seconds at 54Mbps, thus making it a trivial task to decode the data sent using standard equipment and programs available on the Internet. Also, WEP provides weak support for authentication. If the WLAN uses DHCP, the association with an AP is automatic. By default, an AP sends out a so called service set identier (SSID) which is necessary for a STA to associate itself with the AP. Since the secret key may be broken, WEP provides no protection at all against non authorized users.

Using only static IP addresses, an access list based on MAC addresses for STAs in the WLAN and disabling the SSID broadcast will make it somewhat harder to gain access to the WLAN. However, this information can be retrieved from eavesdropping on transmissions in the WLAN, and then used to take over the identity of a STA in the WLAN. The upcoming extension, 802.11i, is supposed to solve all known problems with WEP by introducing an authentication server, a dynamic key change and the advanced encryption standard (AES) algorithm [4].

2.5 Super G Technology

The APs used in this thesis incorporates a technology called Super G [5]. This is basically an implementation of a subset from the upcoming 802.11e standard.

This standard supports frame bursting which allows the sending AP to send several frames back to back instead of deferring its access after each frame sent.

This means that more frames will be sent in the same amount of time. The subset also includes fast frames. This technique bundles more data in each frame sent, and allows two 1500-byte Ethernet frames to be sent at one time.

Apart from the subset, Atheros has also included hardware data compression

based on the same algorithm as Winzip [6]. Data already compressed with

this algorithm will therefore not see increased throughput. To further increase

the performance, there exists an option to use two channels at the same time

(dynamic turbo) which doubles the theoretical bandwidth.

2.6. 802.11 MAC LAYER THEORETICAL THROUGHPUT

2.6 802.11 MAC Layer Theoretical Throughput

This section presents the theoretical throughput of the 802.11 MAC layer. As stated in chapter 2.1, the speed of 802.11 is dened in terms of available bit rate, not taking encapsulation of data, collisions in the wireless media or processing delays in the wireless equipment into account. To calculate the theoretical throughput, it is necessary to make some simplifying assumptions. The only type of MAC frames considered are data and ACK frames, none of which are subject to corruption by interference or packet collisions. Fragmentation is not an issue, which normally would be the case since maximum sized Ethernet frames are 1500 bytes long, where as 802.11 data frames may contain 2312 bytes of upper layer data. Figure 2.7 shows the MAC protocol data unit where it can be seen that an additional 34 bytes are added to the Ethernet frame. The MAC layer ACK has a simpler format which can be seen in Figure 2.8. Both of these frames are called physical layer convergence protocol-service data unit (PSDU) on the PHY layer (Figure 2.9). Furthermore, propagation delay is

Figure 2.7: Data Frame Format or MAC Protocol Data Unit

Figure 2.8: ACK Frame Format

not included, and there is always a continuous and sucient number of frames to send in order not to drain nor overow sending or receiving buers. Other important factors are timing parameters, preamble and data rates, which varies between dierent extensions of the standard. The measurements performed in this thesis are limited to 802.11g compliant equipment only at its maximum data rate speed, 54Mbps

, a circumstance that admits the usage of shorter preamble and slot time. Also, one must consider the upper layer protocol, the total time to transmit one frame, its ACK and timing delays. For both UDP and TCP, the time to transmit one frame without timing delays can be described as shown in equation 2.3

T X

= T

+ T

+ T

∗ d (16 + 6 + M P DU ∗ 8) N

e + T

(2.3) where

3

some tests are actually done using a subset of 802.11e

CHAPTER 2. 802.11 BACKGROUND

Figure 2.9: PPDU frame format

ˆ T

, or preamble duration for the physical layer convergence protocol (PLCP) is 16µs

ˆ T

, or duration of the signal symbol is 4µs

ˆ T

, or symbol interval is 4µs

ˆ MAC protocol data unit (MPDU) in bytes is 1534

ˆ N

or number of data bits per symbol is 216, and

ˆ T

or signal extension is 4µs

Substituting these numbers into equation (2.3) yields

T X

= 16 + 4 + 4 ∗ d (16 + 6 + 1534 ∗ 8)

216 e + 6 = 254µs (2.4) The MAC ACK in response to the frame is given by

T X

= T

+ T

+ T

∗ d (16 + 6 + M

∗ 8)

N

e + T

(2.5) where M

, the size of the MAC acknowledgment frame, is 14 bytes. Substi- tuting into (2.5) gives

T X

= 16 + 4 + 4 ∗ d (16 + 6 + 14 ∗ 8)

216 e + 6 = 30µs (2.6) The transmission delay for each frame caused by timing is

T X

= T

+ T

+ T

(2.7) where

ˆ T

is 28µs

ˆ T

is 10µs and

2.6. 802.11 MAC LAYER THEORETICAL THROUGHPUT

ˆ T

is the average back o time, 67.5µs which gives

T X

= 28 + 10 + 67.5 = 105.5µs (2.8) (2.4), (2.6) and (2.8) gives the total transmission time

T X

= 389.5µs (2.9)

or 2567 transactions each second. For UDP, the maximum amount of useful data in every frame is 1472 bytes, and therefore the theoretical throughput becomes U DP

= 1472 ∗ 8 ∗ 2567 = 30.2M bps (2.10) For TCP, one has to consider the TCP ACK since it results in a MAC layer transmission. The size of a TCP ACK is 40 bytes so (2.3) becomes

T X

= 16 + 4 + 4 ∗ d (16 + 6 + 74 ∗ 8)

216 e + 6 = 38µs (2.11) Also, (2.6) and (2.8) gets doubled so that

T X

= 563µs (2.12)

or 1777 transactions each second. The maximal amount of useful data is 1460 bytes which gives a theoretical throughput of

T CP

= 1460 ∗ 8 ∗ 1777 = 20.7M bps (2.13) As can be seen, the numbers for both UDP and TCP are quite low, 56 and 38%

respectively, compared to the advertised data rate. As a reference, the maximum

speed achieved indoors with the APs used in this thesis is 29.3 and 23.5Mbps

respectively. The reason that throughput is higher than calculated for TCP is

probably because the average BO is lower than estimated. Also, most of the time

one ACK is sent for every two maxium sized Ethernet frames received (delayed

ACKs), which would further increase the calculated value of the theorectical

throughput. In the case of UDP, the achieved throughput is reached with zero

or close to zero packet loss which is probably why the throughput is somewhat

lower than calculated.

Chapter 3

Transport Layer Protocols

This chapter provides background on the transport layer protocols used in this thesis, including the two most commonly used on the Internet, UDP and TCP.

The TCP variant used in the Internet today is called Reno, but its exact behavior varies depending on the operating system and/or TCP-stack used, since various suggested improvements to TCP may be implemented and used by default. A brief background on the Linux implementation of TCP is provided, since it is the operating system of choice in this thesis. Also, issues regarding the usage of TCP in a 802.11 WLAN are explained.

3.1 User Datagram Protocol

The user datagram protocol (UDP) [7] is the standard transmission layer pro- tocol for providing a connectionless service. It is said to be connectionless since the sending transport layer does not establish a connection with the receiv- ing layer, before it starts to send data provided by an application. The data is encapsulated by a segment that contains a header with information about source port, destination port, length of the segment in bytes and a checksum.

The specication of source and destination port is needed to be able to direct segments to the correct process in the end systems. The overhead associated with the header is 8 bytes. UDP does not provide any protection against packet losses or congestion since no connection state is maintained in the end systems, and it is therefore said to be unreliable. The state- and connectionless service makes UDP rather fast and because of that, it is the preferred protocol for many real-time applications.

3.2 Transmission Control Protocol

The transmission control protocol (TCP) [8] is the standard transmission layer protocol for providing a point-to-point full-duplex connection-oriented service.

In contrast to UDP, a sender has to establish a connection with the receiver

3.2. TRANSMISSION CONTROL PROTOCOL

by initializing a three-way handshake. This is done to inform each other about allocated buers (sender and receiver) and initial values of sequence numbers, one for the sender and one for the receiver. The sequence number is increased with each new segment sent and is used to keep track of the segments in the transmission. The sequence number is byte based, i.e. it does not reect the number of segments sent but instead species the number of the rst byte in every segment. The receiver in turn, ACKs the data received by specifying the next byte expected from the sender. This way, the sender will know if packets are lost and have to be transmitted again, thus providing a reliable transfer of data. To regulate the rate at which segments get sent, TCP implements two control mechanisms, the ow control and the congestion control.

TCP Flow Control

It is the job of the ow control to make sure that the sender does now overow the receiver's buer, which will happen if the received data is not processed quickly enough. To prevent this, there is a limited amount of unacknowledged segments allowed at any given time during the lifetime of a connection. This amount is controlled by a receiver window (R

) variable, maintained at the sender. The size of R

is determined at the receiver, by subtracting buer space used from the buer allocated. The sender gets notied about R

with every ACK it receives. Since the sender knows the number of unacknowledged segments, it can compare this with R

to make sure that it does not overow the receiver buer.

TCP Congestion Control

The congestion control mechanism of TCP consists of four dierent algorithms, slow start, congestion avoidance, fast retransmit and fast recovery. They act together to try to avoid overowing intermediate router buers in the network between the sender and receiver. Congestion control uses an additional vari- able, congestion window (C

), to regulate the senders' transmission rate. The amount of unacknowledged data must be less than or equal to the minimum of C

and R

.

C

is initialized to the size of one maximum segment size (MSS) and is in- creased with one MSS for each unique ACK received. MSS is dened as the maximum segment size not including any header. The size of the header for a TCP segment is 40 bytes. If it is a new connection, C

will continue to double every RTT until the rst packet loss is detected. Packet loss is dened by either receiving three duplicate ACKs, or by a timeout of the retransmission timer associated with the oldest outstanding ACK.

In the case of duplicate ACKs, a variable slow start threshold (SS

) is set

to one half of the size of C

plus three segments, accounting for segments

having left the network due to duplicate ACKs. Following this, C

is set to

the size of (SS

). SS

is used for determining when the sender should

enter congestion avoidance, i.e. increasing C

by one MSS (linearly) every

CHAPTER 3. TRANSPORT LAYER PROTOCOLS

RTT. Recovery from duplicate ACKs is initialized by a fast retransmit of the missing packet, without waiting for a timer timeout.

After a fast retransmit, the sender uses fast recovery to control the sending of new packets until a non-duplicate ACK is received. During fast recovery, C

is increased by one MSS for every additional duplicate ACK received and a new segment is transmitted if allowed according to the value of C

and R

. When an ACK for new data arrives, the value of C

is set to the value it had upon receiving the rst three duplicate ACKs, and fast recovery is exited.

In the case of a retransmission timeout (RTO), SS

is set to one half of the current C

, but C

is now set to one MSS. The reason for this is that a timeout is considered to be caused by a sudden change in the network load (ACK is lost), where as a duplicate ACK indicates that packets are still arriving at the receiver. Instead of entering congestion avoidance, the sender will enter slow start. The RTO is according to [9] calculated from the following three equations.

S

= 0.875 ∗ S

+ 0.125 ∗ RT T

(3.1) where S

is the smoothed RTT and RT T

is the most recent RTT sample,

RT T

= 0.75 ∗ RT T

+ 0.25 ∗ |S

− RT T

| (3.2) where RT T

is the variation of the RTT, and

RT O = S

+ max(1s, 4 ∗ RT T

) (3.3) If RTO is less than one second, then it should be rounded up to one second.

3.2.1 Improvements to TCP Reno(NewReno, SACK, D- SACK)

A number of improvements to increase the performance of TCP have been pro- posed since the introduction of Reno in 1990. Some of the propositions are explained below.

Selective Acknowledgment

Even though TCP uses cumulative acknowledgments, the sender has no idea

whether one or many packets have been lost since only the oldest unacknowl-

edged packet is known to be lost. This can lead to unnecessary retransmissions

of successfully received packets, or having to wait one RTT for each outstand-

ing ACK. The selective acknowledgment (SACK) [10] solves this by letting the

receiver include information in the ACKs about which segments that have been

received correctly. This way, unnecessary retransmissions can be avoided.

3.2. TRANSMISSION CONTROL PROTOCOL

Duplicate Selective Acknowledgment

Although SACK informs the sender about successfully received packets, it has no way of knowing if the receiver has received duplicate packets. This can for instance happen if a packet has been delayed in the network, thus leading to a unnecessary retransmission. With the use of duplicate SACK (D-SACK) [11], the sender will know in what order the packets arrived at the receiver.

More specically, the sender will know which packet that caused the D-SACK.

This information will assist the sender in making more informed decisions to avoid false retransmissions due to reordering, retransmits due to timeouts, early retransmission timeout and detecting if a packet has been replicated in the network.

NewReno

An alternative to SACK and D-SACK is NewReno [12], which stores the highest sequence number (RECOVER) upon entering fast retransmit. After receiving the ACK in response to the retransmitted packet, RECOVER is compared to the sequence number in the ACK. If they match the sender enters the congestion avoidance phase. Otherwise, the sender retransmits the next segment reported to be missing. The procedure is repeated until RECOVER matches the sequence number in the ACK received. This behavior ensures that the sender can recover one segment each RTT.

3.2.2 TCP Variants

The TCP congestion control has been subject to intense research over the years.

The research on TCP congestion control has spawned several variants that im- proves performance on, for instance, high speed networks and over lossy links.

Three of these variants are compared to TCP Reno in this thesis.

TCP Vegas

There are two major dierences between TCP Vegas [13] and Reno. The rst is

that Vegas tries to predict when congestion is going to occur and adjust its send-

ing rate accordingly, instead of waiting for a packet loss like Reno. Vegas does so

by assuming that the number of bytes currently in transit is proportional to the

expected throughput. By calculating the expected throughput and comparing

it with the current actual throughput, a decision to adjust C

accordingly

is made. The second dierence is that Vegas employs a new retransmission

mechanism in which the RTT is calculated with every ACK received, instead

of about once every RTT. If a duplicate ACK is received and its timestamp is

greater than the value of RTO, the segment will be retransmitted without wait-

ing for three duplicate ACKs. Vegas also employs a slight modication to the

slow start behavior, and that is to let the congestion window grow exponentially

every other RTT instead of every RTT.

CHAPTER 3. TRANSPORT LAYER PROTOCOLS

TCP Westwood+

Instead of halving C

as TCP Reno does upon detecting congestion, TCP Westwood+ [14] uses an adaptive approach. This approach tries to select appro- priate values of C

and SS

based on the bandwidth used upon detecting congestion. To estimate the bandwidth, Westwood+ counts the amount of data (D

) ACKed during the last RTT (T

) and use these values to form the discrete bandwidth samples (B

) in equation 3.4.

B

= D

T

(3.4)

B

is then ltered to obtain a bandwidth average and low frequency components which corresponds to congestion. It has been shown [15] that Westwood+ par- ticularly improves performance on wireless links, since it is able to distinguish packet losses caused by congestion from packet losses caused by interference on the wireless media. Details about losses on wireless media can be found in section 3.4 below.

Binomial Increase Congestion Control TCP

The Binomial Increase Congestion Control (BIC) TCP [16] imposes congestion control by combining an additive increase with a binary search increase when probing for bandwidth. When a packet loss is detected, a maximum window size equal to the current size of C

is set and C

is reduced multiplicatively by a constant factor. The new size of C

becomes the minimum window size.

Using Binary search, the size of C

is immediately increased to the midpoint of the interval between the maximum and minimum window size. If the interval is too large, the size of C

will increase by a predetermined constant value.

C

will then rst be incremented exponentially, followed by a linear increase as the size of C

approach the maximum window size. BIC-TCP is mainly targeted at high speed networks, but since it is included in the Linux kernel and poses an interesting solution to congestion control, it is evaluated in this thesis.

3.2.3 Linux TCP

The Linux TCP implementation supports many of the suggested improvements

to TCP including the ones mentioned in section 3.2.1. Linux also takes a some-

what dierent approach for congestion control [17]. First of all, C

is com-

pared to the number of packets outstanding in the network, as opposed to the

dierence of the next segment to be sent and the last segment ACKed. Also,

the number of segments are tracked for full sized packets instead of using byte-

to-byte basis. Linux only allows one packet to be transmitted per segment,

which leads to a more conservative behavior. When it comes to the RTO timer,

Linux uses a minimum value of 200 ms as opposed to 1 second stated by [9] and

500 ms used in some TCP implementations. Furthermore, the same approach

as TCP Vegas is used for measuring the RTT, i.e., one sample is calculated

3.3. REAL-TIME TRANSPORT PROTOCOL

for each ACK received. Taking many samples means that the variance of the RTT samples will be smaller. This could cause problems with the RTO during slow start, since then there are few ACKs being received and the RTO estimate will not increase (i.e. is underestimated) fast enough. This can in turn lead to spurious retransmission timeouts. The RTO can also be overestimated. If the RTT drops suddenly and signicantly, the value of RT T

will temporarily in- crease leading to higher values of the RTO. To overcome these problems, Linux uses a variable measured mean deviance (MDEV) to adjust the value of RT T

(equation 3.2), i.e. RT T

is set equal to MDEV.

To avoid underestimating the RTO, MDEV continuously records the current maximum RTT variance during each RTT, thus assuring that RT T

will have the maximum value estimated for each RTT. In the second case, MDEV is given a low weight if the RTT drops suddenly and signicantly below the S

to neutralize the risk of overestimating the RTO.

3.3 Real-Time Transport Protocol

The Real-time Transport Protocol (RTP) [18] is a protocol that runs on top of either UDP or TCP

. The xed size of the RTP header is usually 12 bytes and includes information like type of payload, a timestamp and a sequence number. The header also has a variable portion, 0-60 bytes, consisting of a list of contributing sources for the payload. RTP is highly suitable for real- time transmissions of data such as audio, video and simulation/sensor data.

However, it makes no guarantee about timely delivery of the data which makes it the responsibility of the receiving application to deal with losses and/or jitter.

3.4 TCP performance issues in 802.11 Wireless LANs

TCP assumes that packet loss is caused by congestion. This assumption is based on the low loss properties of wired links. In a wireless network, packet losses may occur due to high bit error rates or collisions on the wireless media. Since TCP trac is bi-directional, packets might collide with ACKs owing in the opposite direction, which indeed is not caused by congestion. Despite this fact, TCP will react the same way as it does on a wired network, i.e. reacting to congestion as described in section 3.2. Typical problems on a wireless media include signal fading or black out, due to interference from obstacles or other STAs/cells. Mobile hosts are especially vulnerable to this phenomenon. Another problem is modied frames because of interference from equipment using the same frequency band. These frames will be dropped by the receiving station if they can not be recovered. Although some recovery is performed at the MAC layer, the performance of TCP will suer, and it may also trigger TCP

1

RTP is usually run on top of UDP

CHAPTER 3. TRANSPORT LAYER PROTOCOLS

retransmissions. Link latency is another factor aecting TCP performance. It is not uncommon that the link latency contributes to the majority of the RTT, leading to higher RTO values potentially degrading performance. A high RTT variance is not uncommon in a wireless network, which ultimately aects the RTT estimation of TCP.

3.4.1 Mechanisms for enhancing performance

There are three categories for enhancing TCP performance over wireless links.

End-to-end, split connection or local recovery. End-to-End relies on the trans- port layer for dealing with packet losses. One solution could be the use of SACK, to get a better idea if the packet loss was caused by a link error or by congestion.

Split connection splits the connection at the STA, using TCP from the sender to

the STA, and then using either TCP or some other connection-oriented protocol

from the sending STA to the receiving STA. In this case, the protocol used at

the STA could know the characteristics of the wireless link, thus being better

able to deal with losses related to the link. In local recovery, losses are dealt

with locally since they in fact occur locally. The explicit mechanism in the MAC

layer of 802.11 already implements local recovery, but improvements including

local caching of TCP packets at the sending STA to further hide link losses to

the transport layer have been proposed [19].

Chapter 4

Experimental Setup And Results

This chapter describes the equipment and software used during testing. The test methodology is rst explained followed by the test cases and the results.

The results for all tests (except when using client/AP mode) on the APs were in general good, coming close to the theoretically calculated throughputs. The main exception was the client/AP mode that behaved erratic at all distances tested, a behavior that was not expected.

As for the dierent TCP and UDP tests that were conducted, the following results were observed. For unidirectional TCP throughput using point-to-point mode and standard settings, TCP Vegas achieved about 90% of the bandwidth achieved by the other three variants. This together with the fact that West- wood+ did not achieve higher throughput than the other three variants was somewhat surprising. For all other tests, Vegas performed on par with the other three variants when it came to throughput, whereas it consistently caused noticeably fewer retransmissions for the 802.11 MAC layer. Using the Super G setting increased TCP throughput of up to 35%. However, when testing bidi- rectional TCP, the bandwidth sharing was somewhat unfair. UDP put a lot less stress on the APs than TCP did, but seemed to be more sensitive to increases in distance between the antennas. The mobility tests showed that both connec- tivity and throughput was good at speeds of up to 100kph, even though a few frames were dropped by the APs.

4.1 Equipment and Network Topology

The tests in this thesis have been performed on a network consisting of two

PCs, two APs and two directional antennas. Although the network topology

is simple, it models a type of network that could be considered for deployment

within the RFN test range. As can be seen in Figure 4.1 the end nodes (PCs) are

referred to as mobile (a laptop) and stationary (a desktop) host respectively.

CHAPTER 4. EXPERIMENTAL SETUP AND RESULTS

This naming convention will be used throughout the rest of this thesis. The

Figure 4.1: Network Topology

PCs, are standard Intel Pentium based PCs running the 2004.2 Gentoo Linux [20] distribution with kernel 2.6.7-r11. The APs are D-Link DWL-2100AP [21]

featuring ve dierent modes of operation, of which the point-to-point mode is focused upon during testing. As a comparison, some tests have also been performed running the APs in the client/AP mode. The directional antennas, an ANT24-1400 and an ANT24-1800 from D-Link, have a gain of 14 and 18dBi respectively. The antennas have a horizontal and vertical beam width of 30 and 15 degrees respectively. The reason that two dierent antennas are used is because the network may have a mobile host on which a larger antenna can not be tted. For a more detailed specication of the equipment used, refer to Appendix C.

4.2 Software Tools

To generate network trac during testing, Iperf 1.7.0 [22] has been used.

This is a well known bandwidth measurement tool that supports both UDP and TCP. Iperf works by running a server on the target computer, to which one can connect with a client from another computer. For TCP, Iperf reports the average throughput for the duration of a bandwidth measurement test. For UDP, packet loss and jitter are also reported. The interarrival jitter, J, is calculated according to equation 4.1 from [18] as

J

= J

+ |D(i − 1, i)| − J

16 (4.1)

where D is the dierence in packet spacing at the receiver compared to the sender for a pair of packets. Iperf was also slightly modied to print the included UDP packet numbers and time of arrival, i.e. the system time, at the receiver to a

le. This was done since it turned out that although the APs were associated, a lot of packets could be lost especially in the beginning of a transmission. This event would have been dicult to identify from regular trace les since they hardly contain any information at all about UDP connections.

To gather trace les, Tethereal 0.10.6 [23] was used, which is a command

line based version of Ethereal. And nally, to analyze the trace les, TCPTrace

4.3. TEST METHODOLOGY

6.6.7 [24] was used, which displays information on a per connection basis and also is able generate graph les.

4.3 Test Methodology

The development of the test methodology used herein mainly took place indoors for practical reasons.

One important observation during initial testing of suitable software was that the APs some times seemed to be in sort of an idle state. Although they were associated, it could take up to eight seconds before a connection could be established between the Iperf server and client. This could also be observed by using the Ping command. This behavior never occurred when running back to back unidirectional TCP or UDP tests, but could happen anytime after 30 seconds or so of not generating network trac. To exclude the possibility that this lack of connectivity was due to erroneous behavior or other limitations in the equipment and software used apart from the APs, similar tests were performed on a wired network. The wired tests showed that the connection would always be established immediately and a measured performance of about 93Mbit/s on a 100Mbit network was achieved. As an additional precaution, unidirectional TCP and UDP tests were also performed under Windows XP, showing the same behavior for the APs and performance as on the wired network. The 802.11 standard features a power saving mode, where a client can either be active or asleep, but this is not the case for APs. Furthermore, the DWL-2100AP interface does not feature a setting for power saving, nor is it described in any error reports or documentation describing the APs. Therefore, the spurious loss of connection was concluded to be normal behavior. To try to remedy the problem with the APs, the start of every transmission was preceded by 10 Internet Control Message Protocol (ICMP) echo request packets, which turned out to be successful in most cases.

The six dierent tests (i.e. examining trac types) described below (section 4.5) are combined into seven groups of tests. Each test was repeated 5 times to improve statistical correctness. To simplify the test procedure and to achieve repeatability, simple scripts were written and then executed by Cron. The output of each command (Ping, Ifconfig, Tethereal, Iperf) was written to a le for post processing purposes. To synchronize the system time on the PCs, NTP was used. This was necessary to ensure that the scripts were executed at approximately the same time on both PCs. Since no external clock was available, a time server was run on one PC synchronizing its system time with the local hardware clock. The accuracy is not as good as with an external clock, but still within a few milliseconds which is more than sucient.

To get some information about the PHY performance, screen shots were taken from the APs' web interfaces since their was no other way to save the AP statistics. The screen shots were taken once after ve repetitions of each test.

Finally, since several variants of TCP were tested, the APs were rebooted after

each change of TCP variant. This served to reset the AP statistics and to have

CHAPTER 4. EXPERIMENTAL SETUP AND RESULTS

the same conditions prior to each new set of tests.

4.4 Test Site

The outdoor testing took place on a narrow road parallel to a 2.2 kilometer long runway. This road is fairly level, but is slightly declined towards the end of the strip with dierence in height of about 1 meter. The placement of the ANT24- 1800 was the same throughout the testing, at the end of the road, whereas the ANT24-1400 was moved to vary the distance between the two. Both antennas were directed horizontally in parallel with the road but the height above ground diered, 3.5 and 2.2 meters respectively. The mobile antenna was mounted on a antenna pole positioned on the roof-rack of a car.

4.5 Test Cases

When designing the test cases, test site and possible areas of application had to be considered. Ideas of possible applications existed but ultimately depended on the results from the tests regarding throughput, delay, jitter and packet losses.

To give a broad view of the functionality and the performance of the APs and the transport layer protocols, six dierent trac types (TT) were tested. The dierent trac types are illustrated in Figure 4.2 as follows. Trac type a (TTa) represents a unidirectional TCP stream from the mobile host towards the stationary host. Trac type b (TTb) represents bidirectional TCP, one stream from the mobile host and one from the stationary host. Trac type c (TTc) represents a unidirectional UDP stream from the mobile host, with a reverse TCP stream from the stationary host. Trac type d (TTd) represents a unidirectional UDP stream from the mobile host towards the stationary host.

Trac type e (TTe) represents bidirectional UDP, one stream from the mobile host and one from the stationary host. Finally, trac type f (TTf) represents one unidirectional TCP stream and one unidirectional RTP stream from the mobile host, with a reverse UDP stream from the stationary host.

To further broaden the view of the performance of the APs, two dierent modes of operation on the APs were tested, point-to-point and client/AP. In point-to- point mode the APs are intended to work as a bridge between two networks, connecting them by a wireless point-to-point link. The client/AP mode is the one traditionally used

in 802.11 WLANs with a wireless client (STA) connecting to the AP. Point-to-point mode was included because the network topology could be seen as a point-to-point link, whereas the traditional client/AP mode was included as a comparison. Apart from changing the mode of operation for some tests, the Super G and limited data rate settings were tested with the point-to-point mode. Super G was used to see how much it could boost the performance compared with standard 802.11g. Limited data rate means that the maximum advertised data rate of the APs was set to be less than the

1

Together with the ad-hoc mode

4.5. TEST CASES

Figure 4.2: Trac Types

standard 54Mbps. This was done to investigate if the proprietary algorithm for dynamic rate adaptation and automatic fallback could lead to bandwidth thrashing as pointed out in [25] for instance. Bandwidth thrashing is basically caused by a wireless sender that has to resend a frame because it is corrupted, and does the resending with a data rate that is too high. That is, the resent frame is also likely to be corrupted, thus wasting valuable bandwidth by causing seemingly unnecessary retransmissions.

The actual test cases can be divided into two main categories, stationary and mobile. The stationary test cases using standard point-to-point settings and trac types TTa-TTe were performed with the distance between the antennas varying between 500 and 2000 meters in 500 meter steps. All other stationary test cases were performed with distance between the antennas being 1000 and/or 2000 meters. All stationary tests were performed for a duration of 60 seconds.

The AP operation modes and settings used, together with trac types and distance are summarized in Table 4.1 The maximum distance, 2000 meters, was

Mode, Settings, Trac Type 500 1000 1500 2000

point-to-point, standard settings, TTa-TTe X X X X

point-to-point, standard settings, TTf X X

point-to-point, limited data rate, TTa-TTe X X

point-to-point, Super G, TTa-TTe X X

client/AP, standard settings, TTa-TTe X X

Table 4.1: Stationary Test Cases

CHAPTER 4. EXPERIMENTAL SETUP AND RESULTS

chosen since the line of sight was limited to just over 2000 meters. The 1000 meter distance was chosen since it would give some information about how the performance would change if the distance doubled. The other two distances were chosen to gather more reference data and to get more information about performance degradation (signal strength) versus distance.

The mobility tests were performed at 50 and 100 kph moving both towards and from the xed antenna over the full 2000 meter distance. The APs were in point-to-point mode using standard settings and trac types TTa,TTc and TTd from Figure 4.2 as summarized in Table 4.2. The maximum speed was

Mode, Settings, Trac Type 50 100

point-to-point, standard settings, TTa,c,d X X Table 4.2: Mobility Test Cases

limited by both the test site and the car used. As in the case with doubling the distance, doubling the speed from 50 to 100kph would give an indication of the performance change versus the speed. Also, both speeds are signicantly higher than they normally are for to mobile users in a 802.11 WLAN. The mobility tests were performed for the duration of 80 and 150 seconds respectively, depending on the speed.

4.6 Signal Strength

Signal strength during transmission as reported by the APs was measured be- fore the actual testing began. It was not clear what the signal strength values reported by the APs represented or if they were correct. However, by using a step attenuator with the option to decrease the signal strength in one or ten dB steps, it was concluded that the signal strength seemed to be using a dB scale.

This way, relative values of the signal strength could be obtained, even though

they might not show the real signal strength. In general, signal strength decays

with the square of the distance meaning that if the distance is doubled, the

signal strength becomes 1/4 (or 6dB less) of its previous value. An important

factor is not only to have line of sight between the antennas, but also to have

some ground clearance for the antennas. The mobile antenna was kept constant

at 2.2 meters above ground, and the stationary antenna was altered between

1, 1.7 and 3.5 meters above ground. As can be seen in Figure 4.3, the signal

strength decreases to about 1/4 when doubling the distance. Signal strength

at 1000 meter are 36, 33 and 26dB for 3.5, 1.7 and 1 meter respectively. Cor-

responding values for 2000 meter are 27, 25 and 0. The values for 1500 and

2000 meters are about the same, which perhaps can be explained by the fact

that an obstacle 4 meters in height next to the road at 1300 meter, aects the

signal conditions negatively at 1500 meter. It might look like the dierence

between 1.7 and 3.5 meters above ground is small, but the throughput for 1.7

meters suered severely at both 1500 and 2000 meters, for instance achieving

an average TCP throughput of only 0.5Mbps for 2000 meter.

4.7. RESULTS AND DISCUSSION

Figure 4.3: Signal Strength Reported by AP, legends showing the height above the ground for the stationary antenna

4.7 Results and Discussion

During tests, some 250GB of data was collected. The results presented do not say how APs from other vendors than D-Link or even other models from D- Link would perform. It is not unlikely that the results would dier to some extent. However, for the the APs used in this thesis, the results are valid and it would also not be dicult to repeat the tests using other hardware. The Figures throughout the rest of this section shows the achieved TCP throughput reported by Iperf using dierent AP modes/settings, protocols and trac patterns as described in section 4.5. There are three types of tables used, representing TCP statistics output by TCPTrace, AP statistics output by the APs and UDP statis- tics reported by Iperf. For all these tables, point-to-point mode using standard settings is used. Statistics regarding other settings and client/AP mode are only commented using the corresponding point-to-point tables as starting point. The tests are presented below with respect to the dierent trac types specied in section 4.5

Trac Type a - Unidirectional TCP

This test examines the characteristics of a unidirectional TCP stream from

the mobile sender towards the stationary sender. The purpose is to nd out

the maximum achievable throughput and also get some reference values to be

able to compare how additional TCP streams eect delay and packet loss. As

can be seen in Figure 4.4, all TCP variants achieve about the same maximum

throughput except for Vegas that has a somewhat lower throughput. Figure 4.4a

shows that Vegas comes in at about 15Mbps or 72% of the maximum theoretical

throughput at 1000 meters (about 17.5Mbps or 85% for the others) and about

14.3 (69%) at 2000 meters (15.5, 75% for the others). One possible explanation

could be the fact that Vegas keeps less packets in intermediate network buers,

which in this case is the buers of the APs, thus underutilizing the available

CHAPTER 4. EXPERIMENTAL SETUP AND RESULTS

bandwidth. Figure 4.4a also shows that the biggest performance drop is between 1000 and 1500 meters. Figure 4.4b shows that the proprietary algorithm for dynamic rate adapation and automatic fallback seems to be rather ecient.

The measurments are performed at 1000 meters and they are 2-3 Mbps (for the 36Mbps case) lower compared to the numbers for 1000 meters in Figure 4.4a.

Figure 4.4c shows that Super G boosts the TCP throughput at 1000 meters with about 35% compared with standard settings (Figure 4.4a), with less boost at 2000m. Vegas achieves a throughput about 5Mbps lower than the others (20 and 25 Mbps respectively). It can be noted that 25Mbps is about 121%

of the theoretical throughput of standard 802.11g, but that other calculations would have to be done for maximum theoretical throughput of Super G. For the AP/client mode in Figure 4.4d, throughput is increased with about 2-3Mbps compared with point-to-point using standard settings in Figure 4.4a. As for Super G, the increase is less pronounced at 2000 meters.

Apart from having lower throughput, Vegas has a much lower RTT than the other three TCP variants. The RTTs for Reno, Westwood+ and BIC are about 29 and 33ms at 1000 and 2000 meters respectively, whereas Vegas has a RTT of about 3.2ms for both 1000 and 2000 meters (Table 4.4). The RTTs for the other AP settings and client/AP mode pretty much correspond to the change in achieved throughput. For instance, halving the throughput from 36Mbps to 18Mbps in Figure 4.4b, leads to a doubled RTT. An important charateristic of the TCP variants is their friendliness towards the APs. The amount of retransmitted frames by the APs when Vegas was used, varied between 2 and 6% of the total frames sent by the mobile host and between 6 and 10% for the stationary host depending on the distance. For the other three variants, the numbers were 5 to 9% and 12 to 15% respectively (Table 4.4). For Super G, the retransmitted frames were about half the number compared with standard setting at 1000 meters, but only showing a slight improvement at 2000 meters.

The improvement for the limited data rate setting was only marginal at both distances, whereas the client/AP mode forced the APs to resend almost twice as many frames as the standard setting at 1000 meters and up to 50% more frames at 2000 meters. Apart from observing that Vegas stands out from the rest, an important observation was the behavior of the APs when using the client/AP mode. TCPTrace reported hardware duplicates of transmitted segments, i.e.

segments having the same TCP header and ID elds at the IP level. The number of duplicates varied from a couple (using Vegas) to several hundred segments (Westwood+). The segements were reported at the sender side when receiving ACKs. Since the APs reported no duplicate frames received, it indicates that the frames were duplicated in the receiving AP. Also, Iperf indicated a somewhat erratic behaviour of the TCP sender. The throughput (reported with an interval of one second) varied between 0 and maximum values achieved, a behaviour that was not seen using the the point-to-point mode of the APs. One conclusion could be that the AP/client mode is not suited for longer distances. The number of retransmitted frames was higher for the stationary host, which could be explained by the fact that a sender gets more bandwidth than the receiver.

To verify this, the stationary host was used as the TCP sender which lead to

4.7. RESULTS AND DISCUSSION

(a) Point-to-point, Standard Settings (b) Point-to-point, Limited Data Rate

@1000m

(c) Point-to-point, Super G (d) client/AP, Standard Settings

Figure 4.4: Unidirectional TCP Throughput (Trac Type a)

more retransmitted frames by the mobile host. For the signal strengths obtained in Figure 4.3, it can be concluded that the performance degradation does not seem to be proportional to the decay of the signal strength. The signal strength is only 1/4 for 2000 meter compared with 1000 meter, but the throughput only drops with about 2Mbps or about 11%.

Apart from the client/AP mode, the unidirectional TCP tests showed good

results. The point-to-point mode was more consistent when using standard

settings than using Super G, based on the fact that the relative performance

degradation was less when the distance increased. Also, there seems to be no

real reason to limit the data rate since the achieved TCP throughput was lower

in that case.

CHAPTER 4. EXPERIMENTAL SETUP AND RESULTS

500 1000 1500 2000 Reno RTT (ms) 28 28.9 32.5 32.6 Stdev (ms) 7.2 7.8 8.9 8.9

Retr (KB) 0 0 0 0

BIC

500 1000 1500 2000 RTT (ms) 28.5 29.9 32.2 32.2 Stdev (ms) 7 7.1 9.2 8.8

Retr (KB) 0 0 0 0

Vegas

500 1000 1500 2000 RTT (ms) 3 3.2 3.2 3.3 Stdev (ms) 1.1 1.4 1.5 1.6

Retr (KB) 0 0 0 0

Westwood+

500 1000 1500 2000 RTT (ms) 28.3 29.5 31.6 33.5 Stdev (ms) 7 7.1 9 8.7

Retr (KB) 0 0 0 0

Table 4.3: TCP statistics output from TCPTrace, APs in point-to-point mode

using standard settings