Using TCP Effectively in

Mobile Ad-hoc Wireless

Networks with Rate

Adaptation

Sam De Silva

This report is submitted as partial fulfilmentof the requirements for the Honours Programme of theSchool of Computer Science and Software Engineering,

The University of Western Australia,2007

Abstract

TCP is the most reliable and efficient transport protocol available in wired net-works. However, in wireless medium it is almost impossible to maintain a goodTCP connection due to unpredictable changes in the channel quality, which resultin changes in the bandwidth. Due to these reasons, packet loss occurs more oftenin wireless networks. Various rate adaptation algorithms have been proposed tohandle this change of bandwidth and maintain a better TCP connection. IEEE802.11 Wireless Local Area Network (WLAN) standard supports multiple ratetransmission in its physical (PHY) layer even though the standard does not dic-tate a particular algorithm to adapt the data rate. This thesis, discusses variousrate adaptation algorithms and carry out detail investigations on OpportunisticAuto Rate (OAR) algorithm over several routing protocols including Ad-hoc OnDemand Distance Vector (AODV) protocol to measure and compare the TCPthroughput.

Keywords: OAR, TCP, NS2,Throughput, Rate Adaptation Algorithm, AODV,DSR, Congestion ControlCR Categories: A.2, I.7.2

ii

Acknowledgements

I take this opportunity to thank few people who have helped me to achieve mystudy for this thesis. Many thanks to my project supervisor, Prof. AmitavaDatta who directed me to this study, and for his assistance, guidance and advicegiven to me until the completion of this thesis. Thanks to my fellow studentswho have helped me in many occasions. Finally, to my wife, Sai Sutha, my sonVaruna and daughter Dilanga for their constant support and love.

iii

Contents

Abstract ii

Acknowledgements iii

1 Introduction 1

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Organisation of this Thesis . . . . . . . . . . . . . . . . . . . . . . 2

2 Transmission Control Protocol (TCP) Overview 4

2.1 Properties of Reliability . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Providing Reliability . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 Sliding Window and Flow Control . . . . . . . . . . . . . . . . . . 7

2.4 Segment Format and Connection Management . . . . . . . . . . . 8

2.5 Congestion Control . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.6 Timeout and Retransmission . . . . . . . . . . . . . . . . . . . . . 13

3 IEEE 802.11 Standard Overview 14

3.1 Medium Access Control (MAC) . . . . . . . . . . . . . . . . . . . 14

3.1.1 Distributed Coordination Function (DCF) . . . . . . . . . 15

3.1.2 Hidden-Station . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1.3 Exposed-Station . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1.4 Virtual Carrier Sensing . . . . . . . . . . . . . . . . . . . . 17

3.1.5 Fragmentation and Defragmentation . . . . . . . . . . . . 19

3.1.6 Multi-rate Support . . . . . . . . . . . . . . . . . . . . . . 19

3.2 Physical Layer (PHY) . . . . . . . . . . . . . . . . . . . . . . . . 20

4 Overview of Routing Protocols 22

4.1 Destination Sequence Distance Vector (DSDV) . . . . . . . . . . . 22

iv

4.2 Ad-hoc On-Demand Distance Vector (AODV) . . . . . . . . . . . 23

4.3 Dynamic Source Routing (DSR) . . . . . . . . . . . . . . . . . . . 23

5 Rate Adaptation Algorithms 25

5.1 Automatic Rate Fallback (AFR) . . . . . . . . . . . . . . . . . . . 25

5.2 Adaptive ARF (AARF) . . . . . . . . . . . . . . . . . . . . . . . 26

5.3 Receiver-Based Auto Rate (RBAR) . . . . . . . . . . . . . . . . . 26

5.3.1 Channel Quality Estimation and Rate Selection . . . . . . 26

5.3.2 Rate Transmission and Adapting to IEEE 802.11 . . . . . 27

5.4 Opportunistic Auto Rate (OAR) . . . . . . . . . . . . . . . . . . 28

6 Implementation 29

6.1 Opportunistic Auto Rate Implementation Details . . . . . . . . . 29

6.2 Problems in DSDV Implementation . . . . . . . . . . . . . . . . . 31

7 Simulation Experiments and Results 33

7.1 Simulation Environment . . . . . . . . . . . . . . . . . . . . . . . 33

7.2 Performance Metric . . . . . . . . . . . . . . . . . . . . . . . . . . 33

7.3 Experiments and Results . . . . . . . . . . . . . . . . . . . . . . . 34

8 Future Studies and Conclusion 47

8.1 Fault and Limitation in Original OAR Implementation . . . . . . 47

8.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

A Original project Proposal 51

B TCL script for scenario with 50 nodes using AODV protocol 57

C Perl script to extract the network TCP throughput 61

v

List of Tables

6.1 Results for DSDV with 50 Nodes . . . . . . . . . . . . . . . . . . 32

7.1 Results for AODV with 4 Nodes . . . . . . . . . . . . . . . . . . . 38

7.2 Results for AODV with 50 Nodes . . . . . . . . . . . . . . . . . . 42

7.3 Results for DSR with 50 Nodes . . . . . . . . . . . . . . . . . . . 42

7.4 Results comparison for AODV and DSR with 50 Nodes . . . . . . 43

vi

List of Figures

2.1 Packet transmission with positive acknowledgement [4]. . . . . . 6

2.2 Retransmission when timeout [4]. . . . . . . . . . . . . . . . . . . 7

2.3 Placing a fixed window on the sequence of packets [4]. . . . . . . 8

2.4 Slides the window [4]. . . . . . . . . . . . . . . . . . . . . . . . . 8

2.5 TCP segment format [23]. . . . . . . . . . . . . . . . . . . . . . . 9

2.6 Sequence of messages in three-way handshake for establishing con-nection [4] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.7 Sequence of messages in three-way handshake for closing connec-tion [4]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.8 TCP’s congestion control using slow start and congestion avoid-ance [23]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1 DCF’s Back-off timer and channel access. . . . . . . . . . . . . . . 15

3.2 Hidden-Station problem. . . . . . . . . . . . . . . . . . . . . . . . 16

3.3 Exposed-Station problem. . . . . . . . . . . . . . . . . . . . . . . 17

3.4 Four-Way handshake [23]. . . . . . . . . . . . . . . . . . . . . . . 17

3.5 Duration of transmission and update of NAV [23]. . . . . . . . . 18

3.6 Fragmentation of large frames [23]. . . . . . . . . . . . . . . . . . 19

7.1 4 mobile nodes scenario in a space of 1000m x 1000m. . . . . . . . 34

7.2 Throughput for different queue sizes using AODV with OAR in 4nodes scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

7.3 Total network throughput without OAR implementation usingAODV routing protocol in 4 nodes scenario. . . . . . . . . . . . . 36

7.4 Total network throughput with OAR implementation using AODVrouting protocol in 4 nodes scenario. . . . . . . . . . . . . . . . . 37

7.5 TCP window size using AODV without OAR at node 1 in 4 nodesscenario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

vii

7.6 TCP window size using AODV with OAR at node 1 in 4 nodesscenario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

7.7 50 mobile nodes scenario in a space of 1000m x 1000m. . . . . . . 41

7.8 Throughput for different queue sizes using AODV with OAR in 50nodes scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

7.9 Total network throughput without OAR implementation usingAODV routing protocol in 50 nodes scenario. . . . . . . . . . . . . 43

7.10 Total network throughput with OAR implementation using AODVrouting protocol in 50 nodes scenario. . . . . . . . . . . . . . . . . 44

7.11 Total network throughput with OAR implementation using DSRrouting protocol in 50 nodes scenario. . . . . . . . . . . . . . . . . 45

7.12 Total network throughput without OAR implementation usingDSR routing protocol in 50 nodes scenario. . . . . . . . . . . . . . 46

8.1 Limitations in OAR - creating congestion [22]. . . . . . . . . . . 47

8.2 Limitations in OAR - Under utilising back-to-back packet sending. 49

viii

CHAPTER 1

Introduction

1.1 Motivation

TCP has been the most popular transport control protocol used in the networkingenvironments including the Internet. TCP has evolved over a period of time andoffers various versions. TCP is used to provide end-to-end reliable packet transferin connection-oriented wired networks. TCP also provides congestion controlmechanisms to handle traffic in highly congested networks. When a packet lossis detected, TCP’s congestion control mechanism always assumes that it is dueto traffic congestion in the network. Therefore it starts its recovery mechanisms.This is true for a wired network environment. However, this may not be alwaystrue in wireless networks.

The channel properties of a wireless network are quite different from wirednetworks. Wireless channels are noisy. Wireless networks change rapidly due tothe mobility of its nodes or the interferences. Packet loss occurs more often inthe wireless network than wired networks due to these reasons. Therefore, wecannot always assume that packet loss occurs due to congestion only [20].

TCP cannot distinguish whether packet loss occurs due to congestion in thenetwork layer or due to noise in the channel in the physical layer. So, packetloss always indicates TCP to think that there is congestion in the network and itstarts congestion control. However, packet loss in the physical layer due to noisein a wireless network cannot be corrected using congestion control mechanisms.This affects performance of TCP greatly.

In addition to the above reason, TCP also assumes that the nodes and thelinks between them in the network are stable. Also, it assumes that the linkcapacities never change. Using these assumptions, TCP can correctly measurethe round trip time. Unlike in wired networks, none of these assumptions is truein wireless ad-hoc mobile networks.

In 1997, the IEEE adopted first wireless local area network standard named

1

IEEE 802.11. This provided data rate up to 2Mbps. Since then, several taskgroups have extended IEEE 802.11 standard. The task group 802.11b produceda standard for Wireless Local Area Network (WLAN) operations in 2.4 GHzband with data rate up to 11Mbps. The 802.11a task group created a standardfor WLAN operation in the 5GHz band with data rate up to 54 Mbps [12]. Inthis thesis we focus on IEEE 802.11b multi-rate standard and its use for ourstudy. The above standards do not outline an algorithm for the sending rateat Link Layer. It is the freedom and the responsibility of the organisations toimplement rate adaptation mechanisms in their network drivers. As mentionedin various publications, a rate adaptation at MAC layer can significantly improvethe throughput. Therefore, to get the maximum TCP performance in wirelessmobile networks, we research the MAC layer protocol and routing and forwardingprotocols to minimise the packet losses by means of using Opportunistic AutoRate (OAR) algorithm.

The previous studies completed in [20] and [23] have discussed the implemen-tation of OAR in wireless networks to improve the TCP throughput. However,the authors have used wireless static networks for their experimental investiga-tions. Compared to the static wireless networks, the wireless mobile networksproduce different results in TCP throughput. Due to the moving nodes, thetopology of the wireless mobile network can change rapidly. This is one of themost important factors that directly affects the TCP performance in wirelessmobile networks. Therefore, the study performed in this thesis has been focusedon implementing OAR in MAC layer and experiment in wireless mobile networkenvironment to make observations.

1.2 Organisation of this Thesis

The subsequent chapters of this thesis have been organised as follows. In chapter2, it describes the most important characteristics and the functionality of theTransport Control Protocol (TCP). In chapter 3, we discuss and provide anoverview of IEEE 802.11 standard. In this chapter we also discuss the MediumAccess Control (MAC) layer and Physical layer. The MAC layer and the Physicallayer play an important role in our experiments and provide the foundation forthis study. Chapter 4 presents an overview of several routing protocols thatare used for the experiments. Chapter 5 provides a detail study on several rateadaptation algorithms and their advantages and disadvantages. OpportunisticAuto Rate (OAR) will be discussed in depth to provide better understandingand will be used for the implementation. Chapter 6 contains the practical partof this study. The Implementation of Opportunistic Auto Rate Algorithm in

2

MAC layer will be discussed in this chapter. Chapter 7 contains the details ofthe experiments and the analysis of the results. Several routing protocols are usedand compared with respect to their TCP throughput to measure the efficiency ofOAR in this chapter. Finally, future work and conclusion are provided in chapter8.

3

CHAPTER 2

Transmission Control Protocol (TCP)Overview

The physical layer of the network protocol stack can provide unreliable packetdelivery. The packets can be lost or destroyed when the transmission errorsinterfere with data, when the network is overloaded or when hardware fails. Whenthe network routes the packets, it can deliver the packets to the destination outof sequence, duplicate packets or introduce substantial delay in delivery.

At the highest level of the network protocol stack, application programs needto send large volumes of data from one computer to another. Using unreliableconnectionless delivery system in transmitting large volumes of data is tedious.As a result it will require the programmers to build error handling and recoverymodules into their applications. This is not very effective in real world because,it is difficult to understand and design application programs that provide highreliability in communication with limited expertise of the programmers.

As a consequence, the need of incorporating the handling of reliable datadelivery into the network protocol was identified and therefore, the applicationprograms can be free from the details of the networking. As a result of this, TCPwas designed.

The following describes the properties of the services that TCP provides [4]:

2.1 Properties of Reliability

The reliable delivery provided by TCP can be characterised by the following 5features.

1. Stream Orientation

When two application programs are transferring large amount of data toeach other, the data are transmitted as a stream of bits and it makes sure

4

that the receiver receives the data in the same sequence as the source sendsit.

2. Virtual Circuit Connection

When two applications wish to communicate with each other, both senderand receiver interact with their respective operating systems and informtheir desire to communicate. Conceptually, one application places a ”call”that must be accepted by the other application before transfer. Then theprotocol modules inform both applications that the connection has beenestablished so that the two applications can begin the transfer. This isknown as virtual circuit [4].

3. Buffered Transfer

Applications send data via the virtual circuit by passing data octets toprotocol software. Each application uses a convenient size of data, whichcan be as small as single octet, to transfer. The protocol software is freeto divide the data into packets independent of the pieces sent by the ap-plication. To achieve an efficient transfer, it collects enough data from thestream to fill a datagram before it transmits.

4. Unstructured Stream

It is important to be aware that the TCP stream service does not honorstructured data streams. For an example, there is no way for a payrollapplication to have the stream service mark boundaries between employeerecords, or to identify the contents of the stream as being payroll data. Theapplication programs using the stream service must identify stream contentand agree on stream format before initiating the connection [4].

5. Full Duplex Connection

The connection provided by TCP stream service allows concurrent trans-mission in both directions. In this full duplex connection, there are twoindividual streams flowing in opposite directions from each other. The ad-vantage of full duplex is that the underlying protocol software can sendcontrol information for one stream back to the source with the data. Thisprocess is known as piggybacking and it reduces large amount of networktraffic.

5

2.2 Providing Reliability

According to the features of reliability we discussed, the stream service of TCPguarantees delivery of data without duplication or data loss from the source tothe destination. However, having unreliable underlying communication system,it is important to understand how the protocol software achieves a reliable packetdelivery. This is achieved by using a technique called positive acknowledgementand retransmission. This technique requires the recipient to communicate withthe source and send back an acknowledgement (ACK) message to confirm thereceipt. Figure 2.1 depicts the message flow.

Figure 2.1: Packet transmission with positive acknowledgement [4].

The sender keeps a record of the packet it sent and wait till it receive anacknowledgement before it sends the next packet. The sender also starts a timeras it sends the packet. If the timer expires after a predetermined threshold thenthe sender assumes that the receiver did not receive the packet and therefore itstarts retransmission of the same packet. Figure 2.2 illustrates this scenario.

Each packet sent by the sender attaches a sequence number to it. When thereceiver successfully receives the packet, it sends back the sequence number ofthe packet it received on the acknowledgement packet back to the sender. Thisway, TCP avoids duplicate packet delivery.

6

Figure 2.2: Retransmission when timeout [4].

2.3 Sliding Window and Flow Control

The concept of Sliding Window, makes stream transmission efficient. Recall thesequence of events that are depicted in Figure 2.2. To achieve reliability, thesender transmits a packet and waits for an acknowledgement before retransmis-sion. As we can see, the data is flowing only in one direction from one machine toanother at any time even though the network is capable of communicating in bothdirections simultaneously. This positive acknowledgement mechanism wastes asubstantial amount of network bandwidth because it must delay sending a newpacket until it receives an acknowledgement for the previous packet [4].

The sliding window technique uses the network bandwidth better because, itallows the sender to transmit multiple packets before it waits for an acknowledge-ment of the previously sent packets. As shown in Figure 2.3, the sliding windowprotocol places a small, fixed-size window on the sequence of packets that areto be transmitted and it transmits all the packets that are inside the window.The sender is allowed to transmit all the packets in the sliding window before it

7

receives an acknowledgement.

Figure 2.3: Placing a fixed window on the sequence of packets [4].

As Figure 2.4 shows, once the sender receives an acknowledgement for thefirst packet it sent, it slides the window forward and transmits the next packet.Therefore, by increasing the window size the network idle time can be minimised.

Figure 2.4: Slides the window [4].

TCP uses a similar sliding window technique in its flow control mechanism.However, TCP allows the window size to be varied over time instead of a fixedwindow size. Each acknowledgement specifies how many octets have been re-ceived and how many more octets can be received by the receiver, based on itscurrent buffer size. In response to the number of octets that the receiver preparedto receive, the sender increases or decreases the window size.

2.4 Segment Format and Connection Management

The unit of transfer between the TCP software on two machines is called a seg-ment. Segments are exchanged to establish connections, transfer data, send ac-knowledgement, advertise window sizes, and close connections. Figure 2.5 showsthe format of the TCP segment [23].

Each segment is divided into header and data. The header carries the identi-fication and control information.

8

Figure 2.5: TCP segment format [23].

When establishing a connection, TCP uses three-way handshake. This isshown in Figure 2.6.

The first segment of the handshake is to send the SYN bit. The secondmessage has both SYN and ACK bits set to indicate that it acknowledges the firstSYN segment. The final message has only ACK bit set to inform the destinationthat both sides agree that the connection has been established.

The programs that use TCP to communicate can terminate the connectiongracefully by using the close operation. When the sending TCP receives anacknowledgement for its last packet transmitted, it sends a segment with FINbit set to indicate that there is no more data to be sent. The receiving TCPacknowledges the FIN and informs its end of the application that there is nomore data to be received. The Figure 2.7 shows this messaging format.

9

Figure 2.6: Sequence of messages in three-way handshake for establishing con-nection [4] .

2.5 Congestion Control

Congestion is a condition of service delay caused by an overload of datagrams atone or more switching points (routers). End points do not usually know wherethe congestion has occurred or why. For the connected applications, the conges-tion means increased delay. Unfortunately, most transport protocols use timeoutand retransmission. So, they respond to increased delay by re-transmitting data-grams. However, retransmission aggravates the congestion instead of alleviating.The increased traffic will produce further delay leading to more and more trafficuntil the network becomes useless.

The congestion control mechanism in TCP [17] reduces the sending rate byadjusting the sender’s window size to handle this situation. TCP always assumesthat the packet loss is due to congestion in the network. The window used forcongestion control is called congestion window.

In order to determine the size of the congestion window, a combination oftwo algorithms is used: slow start and congestion avoidance. Initially, the slowstart increases the window size until it reaches a threshold. Then, the congestionavoidance is used to determine the window size.

10

Figure 2.7: Sequence of messages in three-way handshake for closing connection[4].

1. Slow Start

Initially, the congestion window size is set to one and the sender sendsthe initial segment and wait for acknowledgement. When the acknowledge-ment arrives, it increases the congestion window size to 2 and sends twosegments. When two acknowledgements arrive, TCP can send 4 segments.This exponential increment of the window size continues until it reachesthe slow start threshold.

The slow start threshold (SST) has an important impact on congestioncontrol mechanism. Whenever, congestion occurs in the network, SST isadjusted to indicate current network condition. Initially SST is set to alarge value. When a packet loss occurs, SST is set to half of the currentcongestion window [21], [13].

2. Congestion Avoidance

To avoid increasing the window size too quickly and causing additional

11

congestion, TCP adds additional restriction called congestion avoidance[21], [13]. Once the congestion window passes the slow start threshold,TCP enters into the congestion avoidance phase and slows down the rateof increment. During this phase, it increases the congestion window size by1 only if all the segments in the window have received acknowledgements.

Figure 2.8 shows the slow start, congestion avoidance and threshold man-agement in TCP [23].

Figure 2.8: TCP’s congestion control using slow start and congestion avoidance[23].

12

2.6 Timeout and Retransmission

One of the most important and complex ideas in TCP is how it handles timeoutand retransmission. TCP expects the destination to send an acknowledgementwhen the sender sends a new segment. When the segment is sent, TCP starts atimer and waits for an acknowledgement. If the timer expires before the data inthe segment is acknowledged, then TCP assumes that the data segment was lostand therefore it starts to retransmit.

TCP computes the timeout value using the segment sent time and the acknowledgement-received time. This is known as round trip sample. Whenever, it computes a newround trip sample, TCP adjusts its notion of the average round trip time (RTT)for the connection using the following equation:

RTT = (α ∗OLD RTT ) + ((1− α) ∗New Round Trip Sample) (2.1)

The value of α is a constant between 0 and 1.

When a packet is sent, TCP computes the timeout value as a function of thecurrent round trip estimate. The following equation shows this computation:

Timeout = β ∗RTT (2.2)

The value of β is a constant greater than 1. This constant must be chosen sothat the Timeout is greater than the round trip time.

13

CHAPTER 3

IEEE 802.11 Standard Overview

In 1997, the IEEE adopted the first wireless local area network (WLAN) standardnamed IEEE 802.11. This is also known as Wi-Fi (Wireless Fidelity). TheIEEE 802.11 standard defines two operational modes for WLANs: infrastructure-based and infrastructure-less or ad-hoc [12]. Infrastructure-based is the modecommonly used to construct the Wi-Fi hotspots using Access Points (AP). In thead-hoc mode, any station that is within the transmission range of any other, canstart communicating.

The first standard published, supported data rate up to 2Mbps [11]. Sincethen, several task groups have been created to extend the IEEE 802.11 standard.The task groups, 802.11a and 802.11b, extended the original standard to providewhat is now known as Wi-Fi. 802.11b produced a standard for WLAN with datarate up to 11Mbps and published in 1999. 802.11a group created a standard tosupport for WLAN with data rate up to 54 Mbps.

The main scope of IEEE 802.11 standard is to develop a Medium AccessControl (MAC) and Physical Layer (PHY) specification for WLAN [19]. Itdescribes the functions that are required by the wireless devices to function withinwireless environment. In addition to this, the standard provides the support forthe frame fragmentation and multiple sending rates [5].

3.1 Medium Access Control (MAC)

The MAC layer protocol offers two types of services: a contention-based serviceprovided by the Distributed Coordination Function (DCF), and a contention-free service provided by the Point Coordination Function (PCF). The PFC isimplemented on top of DFC and is based on a polling scheme. It uses a centralPoint Coordinator that cyclically polls stations so that it gives the opportunity totransmit. However, this polling based implementation in PFC cannot be adoptedin ad-hoc mobile networks. PFC can only be used in wireless mobile networks

14

where the stations are connected with fixed Access Point (AP). Therefore, PFCwill not be discussed any further in this thesis.

3.1.1 Distributed Coordination Function (DCF)

DCF is the basic medium access method in 802.11 MAC protocol. The DCF isbased on a Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA)scheme. According to this scheme, when a mobile node receives a packet to betransmitted, it first senses the channel to confirm that no other nodes in thenetwork are transmitting. If the channel is idle then it starts the transmission.Otherwise, it chooses a random back-off value, which determines the time itshould wait before it transmits the packet. During this time period, the nodecounts down the backoff-timer. When it reaches zero, the node transmits thepacket. Since the nodes are selecting a random back-off value, the chances ofselecting the same back-off value by two different nodes at the same time arevery small. Under the normal circumstances, the probability of collision is low.Figure 3.1 [4] shows the back-off timer selection and channel access by the nodes.

Figure 3.1: DCF’s Back-off timer and channel access.

Usually, the nodes in WLAN have only one antenna for both sending andreceiving. So, the nodes will not be able to listen while sending packets. Due tothis reason, the CSMA/CA scheme does not have collision detection capability.Since there is no collision detection mechanism, the stations that are transmit-ting during the collision will always complete their transmission reducing thethroughput as well as the utilisation of the network bandwidth.

15

The wireless ad-hoc networks that rely on CSMA/CA protocol face two majorproblems: Hidden-Station and Exposed-Station.

3.1.2 Hidden-Station

The hidden-station problem occurs when two (or more) stations, say A and C,cannot detect each other’s transmission (due to being outside of each other’stransmission range) but their transmission ranges are not disjoint [12], [23]. Asshown in Figure 3.2, when the station A and station C start transmitting towardsthe same receiver B, the collision occurs.

Figure 3.2: Hidden-Station problem.

3.1.3 Exposed-Station

The exposed-station problem results from a situation where a sending station hasto delay a permissible transmission due to irrelevant transmission between twoother stations, which are within the transmission range of the sender. Figure 3.3depicts the exposed-station scenario. The stations A and C are within the trans-mission range of B and therefore, A and C can overhear the transmissions fromB. But, station A is outside the transmission range of C and it can’t hear C’stransmissions. Let us assume B is transmitting to A, and C wants to transmit aframe to D. According to the CSMA scheme C senses the medium and finds itbusy because of B’s transmission and delays the transmission to D, even thoughthis transmission does not cause a collision. Therefore, exposed-station problemcan reduce the throughput of the network.

16

Figure 3.3: Exposed-Station problem.

3.1.4 Virtual Carrier Sensing

The hidden-station problem occurs when using physical carrier sensing only. Toalleviate the hidden-station problem IEEE 802.11 provides a mechanism calledvirtual carrier sensing. The virtual carrier sensing, uses Request To Send(RTS)and Clear To Send(CTS) control frames. Before the data transmission, the sourcestation sends the RTS control frame to the destination station announcing thedesire to send the data. Upon receiving the RTS, the destination station, repliesusing CTS frame indicating that it is ready to receive. After successful datatransmission to the destination, the destination station responds with Acknowl-edgement (ACK), which finalises the communication. This is called Four-Wayhandshake (Figure 3.4).

Figure 3.4: Four-Way handshake [23].

17

The time period between the control frames and data frames is known asShort Interframe Space (SIFS). The time after finalising the communication isknown as DCF Interframe Space (DIFS).

The duration of the transmission initiated by RTS consist of one CTS frame, one DATA frame, one ACK frame and 3 SIFS intervals. Both RTS and CTSframes carry this overall transmission duration. This information can be heardby any neighboring stations, which are within the transmission range of source,and the destination stations. Each station stores this information in NetworkAllocation Vector (NAV) for later use. Therefore, the stations are aware of thetransmissions of the hidden stations and the duration of the transmissions, theycan avoid the collisions caused by the hidden-station problem. The transmissionduration and the NAV update are depicted in Figure 3.5.

Figure 3.5: Duration of transmission and update of NAV [23].

However, the Four-Way handshake can only reduce the hidden-station prob-lem because, RTS and CTS packets are still sent using CSMA and therefore theyare exposed to hidden-station problem. Since these packets are very small andtherefore, the collision probability is fairly low.

It is also important to remember, that the control packet transmission intro-duces an additional overhead, which affects the overall throughput of the network.In later chapters, we will be looking at reducing this overhead with the use ofback-to-back packet delivery in OAR.

18

3.1.5 Fragmentation and Defragmentation

The Fragmentation and Defragmentation in MAC layer provides the robustnessin communicating large frames in wireless networks. Unlike in wired networksthe frame sizes must be kept to the minimum in wireless networks. This isbecause, the packet drop increases with the increasing packet size. The fragmen-tation function in MAC layer divides the large frames into a number of smallerframes before the sender starts transmitting. The Defragmentation function inMAC layer reassembles the divided frames to construct the original frame at thereceiver’s end. Figure 3.6 shows the fragmentation of frames.

Figure 3.6: Fragmentation of large frames [23].

The sender waits to receive an ACK for each fragment it sent to the destina-tion before it sends the next fragment. In case, if the sender never receives anACK for the previously sent fragment (even after performing the retransmission)then it drops all the fragmented frames.

The MAC header carries the information about fragmented frames so thatthey can be used when constructing the original frame at the destination. Themore fragments bit in the Frame control Field indicates to the receiver whether allthe fragments have been sent so that it can start constructing the original frame.The sequence number and fragment number provided in Sequence Control Fieldon the MAC header help to identify which fragment belongs to which frame andthe order of the fragments within the frames respectively.

3.1.6 Multi-rate Support

IEEE 802.11 standard provides multiple sending rate capabilities. However, thestandard does not rule out a particular algorithm to adapt multiple rates. It is upto the individual product manufactures to implement rate adaptation techniques.In this thesis, we are looking at using OAR as the rate adaptation technique

19

to acquire the advantage of multi-rate feature in the standard to increase thethroughput of the network. This approach will be discussed in later chapters indetail. The standard proposes following rules to maintain the interoperability ofall devices that provide multi-rate capabilities .

• All control frames must be transmitted at one of the rates in the BSSBasic Rate Set to ensure that they will be understood by all stations in thenetwork.

• All multicast and broadcast frames must be transmitted at one of the ratesin BSS Basic Rate Set.

• All data frames must be sent at the data rate chosen by the rate adaptationalgorithm

• No station in the network is allowed to send messages with a rate graterthan the highest rate in the Operational Rate Set.

• Control Response frames (CTS or ACK) must be sent at the same rate asthe previously received control frame if that rate is part of the mandatoryrates. Otherwise, they have to be sent at the highest possible rate in theBSS Basic Rate Set.

3.2 Physical Layer (PHY)

In wireless networks, the data signals are traveled through the air from sourceto the destination. These data signals are transferred as radio signals at a givenfrequency. Every station which is tuned to that frequency and they are withinthe carrier sense then they can detect the signal [23]. Every station that is withinthe transmission range, can receive the signals that are transmitted. The abilityto receive radio waves are depends on various factors like frequency, signal power,distance to intervening objects, distance to the sender and noise of the channel.All of these factors are contributing to change of Signal-to-Noise-Ratio (SNR).

To improve the reliability and the throughput of the radio wave transmission,the spread spectrum is used. There are two types of spread spectrums are usedin the physical medium. They are; Frequency Hoping Spread Spectrum (FHSS)and Direct Sequence Spread Spectrum (DSSS). The idea behind the FHSS is totransmit on a given frequency for a short time only. Then it start hoping toother frequencies over the whole frequency band. For FHSS, the frequency bandis between 2.4Ghz and 2.483Ghz and it provides 75 separate 1Mhz sub channels.

20

The advantage in FHSS is it is not strongly affected by the signal interference.For DSSS, the frequency band is divided into 14 overlapping 22Mhz channels.DSSS uses rather wide channels. DSSS can provide high throughput but it isalso strongly affected by the noise.

The original IEEE 802.11 physical layer defines data rate of 1Mbps and 2Mbpsradio waves in the 2.4Ghz frequency band via the above two spread spectrumtechnologies.

21

CHAPTER 4

Overview of Routing Protocols

As a part of this study I have experimented using Dynamic Source Routing(DSR), Ad-hoc On-Demand Distance Vector (AODV) and Destination SequenceDistance Vector (DSDV) routing protocols to compare the performance of OAR.The following sections give a brief overview of these routing protocols:

4.1 Destination Sequence Distance Vector (DSDV)

DSDV is a proactive, unicast routing protocol [3], [6]. This means, each node inthe network maintains a complete information about network topology locally tosend the data based on point-to-point routing. This requires periodic exchangeof control messages to maintain the routing tables. The information collectedthrough proactive exchange of partial routing tables is stored at each node.

The advantage of this protocol is that a node can immediately find the bestroute to a destination since it knows the complete topology of the network. Thisreduces the latency. However, with an increasing number of nodes and mobilityin a network, the exchange of control messages will be increased and it mayconsume almost the entire bandwidth.

The local routing table contains the complete graph of the network, the edgesbetween the nodes and the cost of the each edge (hop count). Each node main-tains its local routing table by running the Distributed Bellman-Ford algorithm.When a node receives some new information about other nodes, it sends thisinformation to its neighbors by advertising the local routing table so that theneighbors can update their routing tables accordingly.

A mobile network changes the topology frequently due to mobility of thenodes. Therefore, the local routing tables may not be updated promptly. Aproactive protocol like DSDV may give rise to loops due to invalid informationin the routing table. In this case, the packets may loop around a circle of nodesfor a long time.

22

To avoid updating the local routing table with old information, broadcastingnode adds a sequence number to the control packet. The receiving nodes checkthis sequence number and update their routing tables if this sequence number isnewer than the one they have received last. Broadcasting of control informationis known as flooding scheme.

4.2 Ad-hoc On-Demand Distance Vector (AODV)

AODV is a reactive, multicast routing protocol. The reactive protocols discoverthe route between two nodes only when it is required, to reduce the overhead ofcontrol traffic. Multicasting requires a node to maintain unicast routes to eachnode in the multicast group [6], [10], [16].

The packet size in AODV is uniform, unlike DSR and DSDV. AODV main-tains only one route between a source and a destination where as DSR maintainsmultiple routes. AODV maintains a lifetime associated with the entries in therouting table. If a route entry is not used within the specified lifetime, then itwill be deleted. In this case, the route discovery will be performed when it isrequired. This is the technique AODV used to keep the routing tables up to date.

During the route discovery, the source node uses an expanding ring searchstrategy to find a route.

AODV does not retransmit data packets that are lost and hence does notguarantee packet delivery. The percentage of the throughput will be higher inthe networks with relatively small number of nodes and mobility. However, whenthe packet loss increases with a large number of nodes and their mobility, thethroughput rate of AODV will be reduced.

4.3 Dynamic Source Routing (DSR)

DSR is a reactive protocol like AODV and it discovers the route to destina-tions on-demand. Each node gathers information about the network topology byoverhearing other nodes’ transmissions. This is known as promiscuous mode ofoperation supported by IEEE 802.11 standard. DSR keeps the control messagesto be lowest compared to table driven protocols like DSDV [6].

The DSR protocol has important mechanisms through which the protocoloperates. These are route discovery and route maintenance. Both of these mech-anisms are operated on-demand.

23

A node may receive multiple routes to a destination in response to a routediscovery and therefore, DSR maintains multiple routes between nodes so that itcan select the best route from the cache.

The packet size of DSR is non-uniform. This may require fragmentation offrames based on the bandwidth before the transmissions.

DSR has relatively high latency in finding routes.

24

CHAPTER 5

Rate Adaptation Algorithms

This chapter provides an overview of rate adaptation algorithms and their usein ad-hoc mobile networks. The IEEE 802.11 standard provides multiple datarates at the physical layer (PHY). There are two ways to adapt the data rates:statistics-based and Signal-to-noise ratio (SNR) based. Both techniques haveit’s own advantages and disadvantages. Several rate adaptation algorithms arediscussed in this chapter are based on the referenced publications [2], [14], [23],[6]. The Opportunistic Auto Rate algorithm will be discussed in more detail asit is subject to our experiments.

5.1 Automatic Rate Fallback (AFR)

AFR was the first commercially published rate adaptation algorithm. The origi-nal proposal [15], was designed for original IEEE 802.11 standard that provided1 to 2 Mbps data rate. However, AFR can be extended to cater for higher datarates.

The channel quality of the network is gathered based on the statistics of thesuccessful and missing acknowledgements (ACK) at the sender. ARF adapts therate by either increasing or decreasing the current data rate according to thechannel state. The data rate is increased when the sender receives a certainnumber of ACKs for consecutive number of packets and it is decreased whencertain number of ACKs are missing.

AFR adapts slowly to improving channel quality. It decreases the data ratequickly when it detects decreasing channel quality [9]. Due to this reason, theoverall throughput achieved in AFR is not optimal.

25

5.2 Adaptive ARF (AARF)

The Adaptive ARF is an enhancement to the original AFR algorithm [18] totackle the problem in slow adaptation in improving channel quality. ARF regu-larly tries to update the sending rate. However, this happens even when thereis no change in the channel quality resulting unnecessary overhead. One wayto reduce this unwanted overhead is to change the successive ACK limit to ahigher number. This solution will be effective in the networks where the channelquality is fairly stable for most of the time. However, if the channel quality isvarying all the time then this solution will not be effective and make the datarate adaptation even slower.

AARF introduces a new idea to reduce the overhead by dynamically adaptingthe threshold γ of received successive ACKs. To achieve this, AARF multipliesthe number of successive ACK by two when the increase of a sending rate fails.AARF reduces the update trials and therefore less packet drops and retransmis-sions.

5.3 Receiver-Based Auto Rate (RBAR)

As an alternative to the rate adaptation based on statistics at the sender, RBARuses the channel quality available at the receiver’s end [9]. This is because, onlythe receiver can estimate the channel quality accurately. The estimated channelquality is used to select a data rate from a predefined lookup table. The datarate is then sent back to the sender so that the sender can transmit the next datapacket using this rate.

5.3.1 Channel Quality Estimation and Rate Selection

Whenever, the receiver receives a packet, it measures the Signal to Noise Ratio(SNR). The SNR represents the channel quality changes based on the path lossdue to topology changes, interference or energy. However, in reality it is verydifficult to measure the SNR accurately and most of the IEEE 802.11 devicesdo not support this functionality. As a solution to this problem Holland et al.use the received signal strength of the last packet as an indicator of the channelquality [9].

Based on the measured SNR the receiver selects the optimal rate from a lookup table. The lookup table contains the optimal data rates for various SNR

26

thresholds. The rate selection is performed according to the following algorithm[23]:

Let R1, .....RN represent the available data rates where R1 denotes the low-est and RN denotes the highest rate available in the network. Furthermore, letτ1, ....., τN be the SNR thresholds at which the received signal can still be in-corporated using a given data rate. Select a data rate r(t) at the time t fromthe available data rates, R1, .....RN according to the SNR(t) using the followingformula:

R1 = SNR(t) < τ1

Ri = τi < SNR(t) < τi+1, i = 1, ..., N − 1RN = else

5.3.2 Rate Transmission and Adapting to IEEE 802.11

When the rate is selected at the receiver, it has to be transmitted back to thesender so that the sender can use it for subsequent transmissions. Holand et al.[9] propose a way to transmit this rate without introducing additional overhead.The idea is to use the RTS/CTS exchange to transmit the data rate back to thesender. Instead of carrying the reservation time, the RTS and CTS packets carrythe data rate and the size of the packet. Using this information, any overhearingnode in the neighborhood can still compute the reservation time and update itsNetwork Allocation Vector (NAV). The links in heterogeneous ad-hoc networkscan be in different bandwidths and therefore, the RTS and CTS packets must betransmitted at the base rate to ensure that any node can receive the RTS/CTSpackets.

When the new data rate is transferred to the sender using the CTS frame, theNAV of the nodes within the range of the sender are no longer correct as theywere updated according to the previous data rate in the RTS. Therefore, a newmechanism is required to inform the new data rate to the nodes in the range ofthe sender so that they can update the NAV accordingly. This can be achievedby introducing a special subheader. This is part of the MAC header and knownas Reservation Sub Header (RSH). RSH contains all fields required to update theNAV of the overhearing nodes.

Therefore, in order to integrate RBAR into IEEE 802.11 standard, the follow-ing modifications are proposed to be made to the original IEEE 802.11 standard[23].

• Modify the RTS/CTS frames to carry the data rate and the packet sizeinstead of the reservation time.

27

• Introduce a new subheader as a part of the MAC header to carry RSH.

• Modify the PLCP header to carry separate rates for the data and the RSHinstead of the signal.

5.4 Opportunistic Auto Rate (OAR)

Opportunistic Auto Rate (OAR) is an optimisation for any existing IEEE 802.11rate adaptation algorithm [2]. OAR works by exploiting wireless channels when-ever the channel quality is good. When the channel quality is good, a high datarate is used. Since OAR is an optimisation for rate adaptation algorithms, firstit needs a rate adaptation algorithm like RBAR, ARF, etc. to be implementedin MAC layer to select a data rate based on the channel quality. Secondly, OARneeds to hold the channel for an extended period when the channel quality isgood in order to exploit it.

Exploitation of a higher quality channel can be accomplished by providingtemporal fairness rather than packet fairness provided by existing IEEE 802.11standard. The packet fairness implies that every node in the network can transmitone single packet whenever it gains access to the channel. The temporal fairnessimplies that every node is granted the same medium access time to transmitpackets. Based on temporal fairness, OAR ensures that every node is granted atime for packet transmission equal to the time it takes to transmit one packetat the base rate. Therefore, the number of packets that can be transmitted by anode is calculated using the following equation:

number of packets per channel access = transmission ratebase rate

The OAR implementation discussed in the following chapter was using theRBAR algorithm as the data rate selection and OAR as an optimisation algorithmto exploit the high quality channels.

28

CHAPTER 6

Implementation

6.1 Opportunistic Auto Rate Implementation Details

For the purpose of simulating OAR performance, NS2 Simulator version 3.0 hasbeen used. I have identified that the MAC layer is the best place to implement theOAR functionality and therefore, MAC layer modules in NS2 have been modifiedto implement OAR. It provides us the freedom to test any routing protocol tomeasure and compare the throughput of TCP by implementing in the MAC layer.

OAR is actually an optimisation of existing rate adaptation algorithms likeReceiver-Based Auto Rate (RBAR). In RBAR, it selects the appropriate sendingrate by the receiver based on the packet-received strength. On top of this, OARallows back-to-back packet sending when the channel quality is good.

First of all, we wanted to implement a way to vary the channel quality. As[1] implemented in their NS2 extension, I used the power with which the packetis received to simulate the quality of the channel. The received power (RP) of thepacket is a property (RxPr) of the packet-stamp object. An arbitrary thresholdvalue is introduced to evaluate the strength of the received power according tothe following equation.

channel quality value = received power - threshold

The channel quality value (CCV) is used to indicate how good the quality ofthe channel is. Based on this channel quality value, we choose an appropriatedata rate for the data packets to be sent.

When the RTS control packet is received by the destination node, the packetcontains the receiving power. The MAC layer implementation in NS2 is changedso that when the destination receives a RTS control frame, it calculates the CCVusing this received power and picks the data rate (new bandwidth) according tothe following C++ implementation.

29

if (CCV > 0 && CCV < 2)

new_bandwidth = basicRate_;

else if (CCV >= 2 && CCV < 4)

new_bandwidth = 2000000;

else if (CCV >= 4 && CCV < 16 )

new_bandwidth = 5500000;

else if (CCV >= 16)

new_bandwidth = 11000000;

If the CCV is less than 2 then it indicates that the channel quality is in itslowest and therefore, the data packets are to be sent at the base rate. The baserate that I have selected in this implementation is 1Mbps. All the control packets(RTS and CTS) are sent at this base rate. When the CCV is between 2 and 4then I pick the data rate of 2Mbps. When the CCV is between 4 and 16 thenthe data rate is selected as 5.5Mbps. When CCV is more than 16 then the datawill be sent at a rate of 11Mbps.

When the RTS is received at the destination, it sends the CTS frame to con-firm the receipt of RTS and to begin the data transmission. When the destinationsends the CTS, it piggyback the new bandwidth calculated as above in the CTScontrol packet. For this purpose, I have added a new property called rate in thepacket object in NS2.

When the sender receives the CTS for the RTS it sent previously, it looks intothe rate value in the CTS packet to decide the rate that it should send the dataframes. In OAR, we have the capability of sending back-to-back packets to gainthe maximum utilisation of the channel quality. Therefore, before sending thedata packets, the sender calculates how many packets can be sent based on therate. The MAC layer implementation in NS2 has been changed in the followingmanner to cater for calculating the number of back-to-back packets.

if (bandwidth_ == 11000000)

set_num_pkt(11);

else if (bandwidth_ == 5500000)

set_num_pkt(5);

else if (bandwidth_ == 2000000)

set_num_pkt(2);

else

set_num_pkt(1);

30

According to the above code, we select 11 back-to-back packets to be sentby the sender when the channel is in its best quality, which is the bandwidthof 11Mbps. If the bandwidth is 5.5Mbps then, the sender sends 5 back-to-backpackets. When the bandwidth is 2Mbps then it sends 2 packets and 1 packetswhen the bandwidth is in its base rate, which is 1Mbps.

The number of packets was calculated based on the following equation:

number of back − to− back packets = transmission ratebase rate

When the sender starts sending the data frames, the number of back-to-back packets counted down, after every successful receipt until it reaches zero.During the back-to-back packet transmissions the sender and destination doesnot exchange the control frames. The advantage of sending back-to-back packetsis to reduce the number of control packets to be transmitted in the network andtherefore, increase the throughput. This reduces the latency of sending the datapackets from source to the destination.

The MAC layer implementation in NS2 has been changed so that the acknowl-edgements (ACK) are sent at the same rate as the data packet was received. Thisis because, the receiver can safely assume that the channel quality is still sameas when it received the data packet [14].

During these data transmissions, the duration of the transmission is calculatedbased on the rates we selected above so that the neighboring nodes can updatetheir Network Allocation Vector (NAV).

Various TCL scripting and scenario files were used to simulate the experi-ments using NS2 [7]. A sample TCL script that were used for 50 nodes withAODV routing can be found in Appendix B. The trace files that were generatedupon successful completion of NS2 simulations were used to extract the TCPthroughput for the overall network. Appendix C shows the Perl script that wasused to extract this information.

6.2 Problems in DSDV Implementation

During my experiments, I came across a problem in DSDV implementationin NS2. With the combination of my scenario and CSMA, DSDV creates aloop while sending packets. This is because, the DSDV is not incrementingthe forward count for the received packets. This issue has been discussed inhttp://mailman.isi.edu/pipermail/ns-users/2002-November/027520.html. How-ever, the solution suggested in this news group posting seems to be incorrect.

31

Table 6.1 shows the throughput results I got for DSDV with the above fix for50 nodes scenario.

Implementation Number of Number of Number ofNodes Packets Packets

Sent ReceivedWithout OAR 50 227086 222728

With OAR 50 753588 748240

Table 6.1: Results for DSDV with 50 Nodes

As we discussed in previous chapters, DSR is an improved routing protocol,which provide an higher throughput in the mobile wireless networks compared toDSDV protocol. However, when comparing the results I got for DSDV with theabove fix shows much higher throughput for DSDV than DSR. This is because,the suggested fix increments the forward counter of DSDV unconditionally. Fix-ing this issue in NS2 simulator is out of the scope of this study, and therefore, Ihave removed DSDV throughput comparisons from our experiments. Therefore,the experiments shown in the following chapter concentrates on AODV and DSRrouting protocols only.

32

CHAPTER 7

Simulation Experiments and Results

This chapter contains the practical experimental details carried out in this thesistogether with results and observations made. The experiments were carried outin NS2 [8] network simulator environment. The main focus in this thesis isto research on the TCP throughput when using OAR in MAC layer. We haveperformed the comparisons of the throughput using AODV and DSR routingprotocols to see the best performance in wireless ad-hoc mobile networks.

7.1 Simulation Environment

The NS2 simulator environment can be set according to the IEEE 802.11 stan-dard. Using the TCL scripts, I have set up various simulation experimentalscenarios.

The nodes that are used in the experiments are mobile nodes. They move inthe experimental space at random speed in random directions. The experimentswere carried out with and without OAR implementation to compare the results.Then, the experiments were repeated for Dynamic Source Routing (DSR), Des-tination Sequenced Distance Vector (DSDV) and Ad hoc On Demand DistanceVector (AODV) routing protocols to measure and compare the results.

The interface queue size of the receiving nodes is also taken into considerationwhen performing the experiments to compare the throughput to find the optimumqueue size.

7.2 Performance Metric

The TCP throughput has been used as the main metric to research the perfor-mance of the TCP in the experiments I have performed here. The TCP through-put for the overall network was computed according to the following:

33

throughputTCP = TCP data received at the receiver (number of packets)Duration of TCP connection

The throughput of the experiments in this thesis was measured every seconduntil the experiment was completed. Therefore the Duration of TCP Connectionin above equation is 1.

7.3 Experiments and Results

Firstly, 4 mobile nodes were used in the 1000m x 1000m space for a period of 900seconds. The data traffic is generated using TCP between 2 nodes. This experi-ment uses the Ad hoc On Demand Distance Vector (AODV) routing protocol totransfer the packets. Figure 7.1 shows the view of the nodes using the nam, thenetwork animator.

Figure 7.1: 4 mobile nodes scenario in a space of 1000m x 1000m.

34

Firstly, an experiment was carried out with different queue sizes ranging from5 to 50. The idea of this experiment was to find the best queue size, whichprovides the best TCP throughput. The experiment was performed repeatedly foreach queue size and we measured the overall throughput of the network for eachqueue size. Figure 7.2 shows the total TCP throughput measured for differentqueue sizes.

Figure 7.2: Throughput for different queue sizes using AODV with OAR in 4nodes scenario

The result shows that the throughput was increased as the queue size wasincreased until the throughput becomes a constant. The optimal queue sizefound by this experiment was 15.

This simulation scenario was used without and with OAR implementation bysetting the queue size to 15 to measure the throughput of the whole networkduring 900 seconds. The test results were extracted by measuring the totalnumber of TCP packets received at the end of each second until the simulationwas completed. Then, we plotted the resulting TCP throughput against the time.Figure 7.3 and 7.4 depict the results of these experiments.

When we compare the above results, it shows that the test we performed with

35

Figure 7.3: Total network throughput without OAR implementation using AODVrouting protocol in 4 nodes scenario.

OAR implementation has increased the throughput significantly. For an example,compare the throughput between 700 and 800 seconds. The result we got for thetest without using OAR shows the maximum number of TCP packets receivedat this time range as about 120 packets. However, the results we got for the testrun with OAR shows the maximum number of TCP packet received at this timerange as over 500 packets. In this case, the throughput has been increased by416 percent when test was performed with OAR. This is a big improvement inthe overall network performance.

At times, the throughput is shown as zero (e.g. at 550th second) due to thenodes moving outside the transmission range of each other and therefore, nothroughput was recorded.

Table 7.1 sumarises the above rest results got for 4 nodes scenario.

According to the results in table 7.1, the test that used OAR shows a slightimprovement in reducing the packet loss compared to the test that did not usethe OAR. With OAR, the network utilisation has been increased by sending large

36

Figure 7.4: Total network throughput with OAR implementation using AODVrouting protocol in 4 nodes scenario.

number of packets compared to the implementation without OAR and therefore,network idle time has been reduced. These reasons have been contributed to amuch higher throughput in the network with OAR.

Figures 7.5 and 7.6 show the TCP window sizes during the experimentswithout and with OAR for a particular node. The TCP window is used by TCPprotocol to manage the congestion and retransmission using its congestion controlmechanism. This is known as congestion window size.

In this case, I have used node 1 to measure the window size since the gener-ated traffic in NS2 shows that node 1 involves in large amount of transmissionactivities. The above results, show that TCP window size is relatively largerwhen OAR was implemented. This indicates that TCP is maintaining a highthroughput before the packet losses occurred. When we haven’t implementedOAR, TCP maintains a lower window size. This means, the packet losses haveoccurred much earlier and therefore the throughput has been reduced. WithOAR, the window size has been maintained at a higher value at most of the timeand it did not reduce much during the simulation period. This is because, OAR

37

Implementation Number of Number of Number of Number of Lost%Nodes Packets Packets Packets

Sent Received LostWithout OAR 4 42079 41449 630 1.5%

With OAR 4 141659 139578 2081 1.47%

Table 7.1: Results for AODV with 4 Nodes

is handling the packet delivery providing higher throughput and giving no reasonfor TCP to perform its congestion control mechanism. However, when we did notuse OAR, the congestion window size changed very often during the simulationtime. This means, when the packet loss occurs, it relies on TCP’s congestioncontrol mechanism to recover and therefore, the throughput of the network wasreduced.

In the second experimental scenario, I have used 50 mobile nodes in 1000mx 1000m space. The data traffic is generated using TCP among 30 nodes. Theexperiment was run for 1200 seconds. I used a larger number of nodes in thisexperiment to reduce the network idle time due to the nodes being out side eachother’s transmission range. Figure 7.7 shows the nam view of the mobile nodesat the start of the simulation.

Using this scenario, an experiment was performed to determine the optimumqueue size with OAR implementation. The overall throughput in the networkwas measured for each queue size ranging from 5 to 100. Figure 7.8 shows theresult by plotting the queue size against the total number of packets received foreach queue size.

According to the test results, it shows that the best queue size was 30 andthis queue size was used for the rest of the experiments.

The simulation tests were performed using this scenario to measure the overallthroughput in the network without and with OAR implementation. Figures 7.9and 7.10 show the TCP throughput results.

Similar to the first scenario, which we have experimented with 4 nodes, thetest results with OAR shows a vast improvement in throughput in the network.Compared to the previous scenario, the network idle time has been reducedmerely due to the use of larger number of nodes in the network.

Table 7.2 shows the summary of the overall throughput measured in thisscenario.

When large number of mobile nodes involve in a wireless ad-hoc network,

38

Figure 7.5: TCP window size using AODV without OAR at node 1 in 4 nodesscenario.

the packet loss become much higher compared to the networks, which have fewernumber of nodes. This confirms by the results we got in table 7.2 when we did notuse OAR. In this case, the packet loss percentage was 4.8. However, with OARimplementation, we have managed to reduce the packet loss in larger networks.In this case, the packet loss percentage was reduced to 1.38 compared to thescenario where we did not use OAR.

Based on the test results in table 7.2, we can confirm our hypothesis OARimplementation with AODV routing protocol improves the network throughputtremendously. This is due to managing the packet delivery based on the channelquality at lower network layer like MAC layer so that the TCP performance canbe increased.

Since the implementation of OAR was done in the MAC layer, it is inde-pendent from the packet routing protocols in the network layer. Therefore, we

39

Figure 7.6: TCP window size using AODV with OAR at node 1 in 4 nodesscenario.

can use this generic MAC layer implementation of OAR with any routing proto-col. The main routing protocols considered here are AODV and DSR. Differentrouting protocols have their own performance advantages on TCP. So, furtherexperiments were carried out to compare the OAR performance against AODVand DSR routing protocols.

I have used the 50 nodes scenario to perform the experiments for DSR with-out and with OAR implementation. The Figures 7.11 and 7.12 represent thethroughput results we got for both of these cases.

Similar to the results we got for AODV, in DSR, we achieve a larger through-put with OAR implementation compared to when we did not use OAR. Table 7.3shows the summary of these test results.

According to the above results, the percentage of packet loss is minimum in

40

Figure 7.7: 50 mobile nodes scenario in a space of 1000m x 1000m.

DSR in both cases when we use OAR and when we did not use OAR compared toAODV. DSR maintains multiple routes to the destinations in its cache. Therefore,it can provide the best path to the destination avoiding packet losses.

Table 7.4 shows the comparison of the results we got for AODV and DSR.

According to the comparison in table 7.4, the overall TCP throughput washighest when using OAR with AODV routing protocol. DSR gave lower through-put in both with and without OAR implementation. Compared to AODV, a lessernumber of packets have been sent in the network with DSR. This may be due tothe high latency in DSR. These results resemble the performance benefits withineach routing protocol. Usually, DSR performs well in low mobility scenarios. Inhigh mobility scenarios like what we have used for the experiments, DSR providedlower throughput. However, AODV is highly scalable in high mobility scenariosand it provided the best throughput. With the implementation of OAR, AODVhas performed much better in this scenario.

41

Figure 7.8: Throughput for different queue sizes using AODV with OAR in 50nodes scenario

Implementation Number of Number of Number of Number of Lost%Nodes Packets Packets Packets

Sent Received LostWithout OAR 50 226716 216096 10620 4.68%

With OAR 50 831636 820119 11517 1.38%

Table 7.2: Results for AODV with 50 Nodes

Implementation Number of Number of Number of Number of Lost%Nodes Packets Packets Packets

Sent Received LostWithout OAR 50 155232 153851 1381 0.89%

With OAR 50 360236 359053 1183 0.33%

Table 7.3: Results for DSR with 50 Nodes

42

Figure 7.9: Total network throughput without OAR implementation using AODVrouting protocol in 50 nodes scenario.

Implementation Number of Number of Number of Number of Lost%Nodes Packets Packets Packets

Sent Received LostDSR Without OAR 50 155232 153851 1381 0.89%

AODV Without OAR 50 226716 216096 10620 4.68%DSR With OAR 50 360236 359053 1183 0.33%

AODV With OAR 50 831636 820119 11517 1.38%

Table 7.4: Results comparison for AODV and DSR with 50 Nodes

43

Figure 7.10: Total network throughput with OAR implementation using AODVrouting protocol in 50 nodes scenario.

44

Figure 7.11: Total network throughput with OAR implementation using DSRrouting protocol in 50 nodes scenario.

45

Figure 7.12: Total network throughput without OAR implementation using DSRrouting protocol in 50 nodes scenario.

46

CHAPTER 8

Future Studies and Conclusion

8.1 Fault and Limitation in Original OAR Implementation

As we have seen in earlier chapters and in the experimental results, it provesthat the OAR implementation in MAC layer based on temporal fairness in thenetwork, improves the TCP throughput. However, [22], [24] brings up a furtherdiscussion on the limitations in original OAR implementation [2].

Figure 8.1: Limitations in OAR - creating congestion [22].

The scenario discussed in [22] is shown in Figure 8.1. The base rate consideredin this example is 2Mbps. According to this scenario, the distances between nodesS1 through S15 and node A are sufficiently small such that a data rate of 11Mbps is available. Nodes A and D are sufficiently far apart so that the data rateof 2Mbps is available. There is one TCP flow from each node S1 through S15

47

through to node D. In order to research the TCP throughput as a function of thequeue size at node A, the interface queue size at nodes S1 through S15 and nodeD is set to 50 packets and the queue size at node A is variable. Note that nodeA represents a congested node as the bandwidth of all incoming links is 11Mbpswhereas the bandwidth of the outgoing link to node D is only 2Mbps.

OAR compounds this problem further due to its temporal fairness. Each ofnodes S1 through S15 will transmit 5 packets back-to-back to node A causingits queue to fill more rapidly.

In the above example, node A communicates with nodes S1 through S15and node D. This means, the interface queue can contain packets to differentdestinations.

According to Figure 8.1, the interface queue at node A shows the next packetin the queue is addressed to node S1, node A allows a data rate of 11 Mbpsand therefore 5 back-to-back packets. However, the next packet in the queue isaddressed to node D. This is the error in original OAR implementation. Ratherthan sending one packet to S1, it sends the following 4 packets to node D back-to-back when normally it would be limited to a single packet at 2Mbps. It did notcheck to see whether the following packets in the interface queue were addressedto different nodes. When this happens, no RTS/CTS handshake is performedfor the following packets designated to node D causing further problems in thenetwork.

This problem has been fixed in the OAR implementation carried out in thisthesis to check the destination when sending back-to-back packets. The fix pro-vided in my implementation was to record the node from which the sender re-ceived the last CTS message and for all the following back-to-back packets tocheck whether the destinations of these packets are same as the node that sentthe last CTS frame.

When considering this scenario, the temporal fairness provided by OAR isnot beneficial for heterogeneous multi-rate multi-hop scenarios. Heterogeneitymeans that the links in a multi-hop path supply different rates. In this case,if the packets did not queued up in the order of the destination at the sender,then the sender will not be able to send all back-to-back packets to the sendersin higher quality channels and will fall back to sending RTS and CTS controlpackets again for each packet. For an example, consider the scenario shown inFigure 8.2. The node A meant to send 5 back-to-back-packets to node S1. But,the next packet in the interface queue, is designated for node D. Therefore, itstarts a RTS/CTS handshake for this packet. At this point, the back-to-backpacket counter is set to 1. The next packet is designated for node S1. Sincethe back-to-back packet counter is reset and the destination node is different,

48

Figure 8.2: Limitations in OAR - Under utilising back-to-back packet sending.

it has to start another RTS/CTS handshake to send the following four packetsback-to-back. This is not a full utilisation of back-to-back packet sending featurein OAR.

On the other hand, the nodes that have higher quality channels to receivethan to transmit can become congested because, of packets arriving faster thantheir abilities to forward them. Heterogeneous multi-hop networks could containmany of these nodes. These nodes have an increased risk of congestion usingOAR since it allows faster channels to transfer more back-to-back packets thanthe slower channels.

These observations are highlighted in this thesis to address researching re-quirements to enhance the OAR performance in heterogeneous multi-hop net-works.

8.2 Conclusion

TCP provides its congestion control mechanism to overcome the congestion inthe network. This solution works ideally for infrastructure based fixed nodenetwork because, the packet loss is mainly due to the congestion in the network.However, in mobile ad-hoc networks many factors are involved which contributeto packet loss in addition to congestion in the physical layer and therefore, usingTCP congestion controlling mechanism cannot overcome the packet loss in ad-hoc

49

mobile networks.

Therefore, we have focused on using a rate adaptation algorithm in handlingthis situation. The standard IEEE 802.11 standard does not rule out any rateadaptation algorithm. But, the standard supports the multi-rate capability inthe network allowing third parties to implement rate adaptation techniques intheir network devices. Therefore, we have considered using OAR, implementedin MAC layer and performed various experiments to handle packet loss in mobilead-hoc environment and gain benefit of TCP. The study was carried out usingthe NS2 network simulator.

The experiments simulated real life scenarios and we checked the TCP through-put of the network and compared it with and without OAR implementation. Theexperiments performed using OAR showed a tremendous improvement in TCPthroughput and less packet loss. This confirms that OAR can be used as an rateadaptation technique in ad-hoc wireless mobile networks successfully.

However, as mentioned in the previous chapters, further studies must be car-ried out to eliminate the limitations in using OAR in heterogeneous multi-ratenetworks.

50

APPENDIX A

Original project Proposal

TCP in Multirate Ad-hoc Mobile Wireless Networks

1. Background

TCP has been the most popular transport control protocol used

in the networking environments including the Internet. TCP has

been evolved over a period of time and offers various versions.

TCP is used to provide end-to-end reliable packet transfer in

connection-oriented networks. TCP also provides congestion control

mechanisms to handle traffic in highly congested networks. When a

packet loss is detected, TCP’s congestion control mechanism always

assumes that it is due to traffic congestion in the network.

Therefore it starts its recovery techniques. This is true for a

wired network environment. However, this may not be always true

in wireless networks.

The channel properties of a wireless network are quite different

from wired networks. Wireless channels are noisy. Wireless networks

changes rapidly due to the mobility of its nodes or the

interferences. Packet loss occurs more often in the wireless

network than wired networks due to these reasons. Therefore, we

cannot always assume that packet loss occurs due to congestion only.

TCP cannot distinguish whether packet loss occurs due to congestion

in the network layer or due to noise in the channel in the link

layer. So, packet loss always indicates TCP to think that there

is congestion in the network and it starts congestion control.

However, packet loss in the link layer due to noise in a wireless

network cannot be corrected using congestion control mechanisms.

This affects performance of TCP.

51

In addition to the above reason, TCP also assumes that the nodes

and the links between them in the network are stable. Also, it

assumes that the link capacities never change. Using these

assumptions, TCP can correctly measure the round trip time. Unlike

in wired networks, none of these assumptions is true in wireless

ad-hoc mobile networks. Therefore, to get the benefit of TCP

performance in wireless networks, we have to research the MAC

layer/physical layer protocols and routing and forwarding protocols

to handle packet loss.

2. Overview of Transmission Control Protocol (TCP)

TCP introduces Reliable Delivery Service over unreliable networks.

TCP makes sure that packets are delivered from one node to the other

without loosing the data and in the same order as it was sent. To

achieve this reliable delivery, TCP provides the following features:

Stream Orientation

When two application programs transfer large volume of data we think

of the data as a stream of bits. This stream is divided into 8-bit

octets. The stream delivery service on the destination machine passes

to the receiver exactly the same sequence of octets that the sender

passes to it on the source machine.

Virtual Circuit Connection

This is analogous to placing a telephone call. Before transfer can

start, both the sending and receiving application programs interact

with their operating systems informing them their desire for the stream

transfer. Protocol software modules in two operating systems

communicate by sending messages to each other over the network

verifying that the transfer is authorized and that both sides are ready

for the transfer. Once all are ready, the protocol software informs the

application programs that the connection has been established and the

transfer can begin. If the communication fails due to any reason, the

protocol software informs the two applications about the failure. We use

the term "Virtual Circuit" because, even though the two application

programs think that the connection between them is a dedicated hardware

circuit, the reliability is an illusion provided by the stream delivery.

Buffered Transfer

Application software programs send a data stream across the virtual

circuit by repeatedly passing data octets to the protocol software.

52

When transferring the data each application chooses whatever size it

finds convenient. At the receiving end, the protocol software delivers

the octets from the data stream that it received in the same order as it

received from the sender making them available to the receiver as soon as

they arrive.

The protocol software is free to break the stream into packets independent

from the pieces the application programs transfer. To make the transfer

more efficient, and to minimize the network traffic, it collects enough

data from the stream to fill a reasonably large datagram before

transmitting it. This is called buffered transfer.

Unstructured Stream

The stream service provided by TCP does not guarantee the structure of the

stream. For an example, there is no way a Payroll application have the

stream service to mark boundary between the employee records or identify

them as payroll data. The application programs using the stream service

must understand the content of the stream.

Full Duplex Connection

The connection provided by the TCP stream service allows concurrent data

transfer in both directions. A full duplex connection consists of two

streams flowing in opposite directions without having an interaction

between them.

Flow Control

TCP controls the data flow between the sender and the receiver using a

sliding window mechanism. This improves the throughput of the network and

reduces network traffic.

Congestion Control

The TCP congestion controls mechanism manages the network capacity. In

the event of high congestion it reduces the transfer rate to prevent

network failure.

3. Issues in Wireless Transmission and Solutions

Following shows the issues associated with wireless networks:

MAC layer Issues

By nature, a wireless medium is a broadcast medium. That means, when one

node is transmitting, all the other nodes, which are in the range of

53

transmission, can overhear it. If two or more nodes transmit

simultaneously, the transmissions can collide with each other resulting

in the receivers not receiving the packets. To eliminate this, MAC layer

implementation introduced the carrier sensing mechanism. However, the

carrier sensing can lead to the "Hidden terminal problem" and "Exposed

terminal problem".

To avoid these problems, IEEE 802.11 MAC protocol provided Distributed

MAC (Distributed coordination function) and Centralised MAC (Point

coordination function).

Physical Layer Issues

The nodes in the wireless network send the data signals through the air

as radio waves traveling in a given frequency. Every node that is within

the range and tuned to that frequency, can receive the signals. The

usable range of the radio waves depends on various parameters such as

signal strength, radio frequency, distance, and interference of intervening

objects or signals and the noise in the channel. In order to improve the

reliability and the throughput of radio wave transmissions, a technology

called Spread Spectrum is used. The use of spread spectrum also minimises

the interference with other signals that share the same medium.

The IEEE 802.11 physical layer defines data rate of 1MB/s and 2MB/s using

radio waves in the 2.4Ghz frequency band via two spread spectrum

technologies. The are Frequency Hopping Spread Spectrum and Direct

Sequence Spread Spectrum.

Data Rate Issues

The IEEE 802.11 standard provides multiple data rates at the physical

layer. However, the standard does not provide a rate adaptation

algorithm allowing a selection of data rate according to the channel

quality. It has been left to the responsibility of the manufactures that

implement the IEEE 802.11 standard in their product. There are two

different approaches in adopting the rate at MAC layer. They are;

Statistic Based and Signal-To-Noise Ratio. Both approaches have

different properties that result in different performance.

Following are the different rate adaptation algorithms:

* Automatic Rate Fallback (ARF)

This was the first commercial rate adaptation algorithm. The channel

quality is estimated by gathering statistics of successful and missing

acknowledgements at the sender. The data rate is increased when the

sender receives ACKs for a certain number of consecutive packets and

54

it is decreased when a certain number of ACKs is missing.

* Adaptive Automatic Rate Fallback (AARF)

This addresses a problem in ARF, which regularly tries to update the

sending rate even when the channel condition does not change. This

regular update trials result in unnecessary overhead.

* Receiver-Based Auto Rate (RBAR)

Rather than based on the statistics RBAR uses the channel quality

information available at the receiver in order to select a data rate.

We will be using RBAR in our experiments to compare the results.

* Opportunistic Auto Rate (OAR)

OAR is the most efficient algorithm. It exploits the channels whenever

the channel quality is good. The exploitation of high quality channels

can be

accomplished by providing temporal fairness rather than packet fairness.

Packet fairness implies that every node can transmit one single packet

whenever it gains access to the channel. The temporal fairness implies

that every node

is granted the same medium access time to transmit packets. The OAR is

the major rate adaptation algorithm that will be used in the

experiments of this research.

4. Routing and Forwarding Protocols

The highly dynamic nature of mobile ad-hoc networks (MANET) results

in frequent and unpredictable changes in network topology, which adds

complexity and difficulty to route among the mobile nodes. There are

several proposed routing protocols for MANETs . Out of these several

routing protocols, the Ad-hoc On Demand Distance Vector (AODV) routing

protocol will be considered in detail in this research.

AODV is a reactive routing protocol. AODV minimizes the number of

route broadcasts by creating routes on-demand as opposed to maintaining

a complete list of routes. This protocol works well in small to medium

size networks with moderate mobility.

5. Research Content and Motivation

As mentioned above, the use of TCP in ad-hoc mobile network has been a

challenge. Extensive research has been done to analyse TCP throughput

in ad-hoc static wireless networks.

55

The main focus of this research is to experiment the TCP throughput and

latency in ad-hoc mobile wireless network where the network topologies

are changed over time due to the mobility of the nodes. This adds the

complexity of node movement in addition to the noise and data rates

handling compared to static wireless

networks.

The following activities will be performed during this research using

the NS2 network simulator:

* Detail study of AODV implementation.

* Implementation of OAR rate adaptation algorithm within the network

layer combining AODV.

* Provide scenarios to simulate the network channel failures at random

interval for random amount of time artificially and handle the packet

transmission using OAR algorithm.

* Measure the throughput and the latency of packet transmission with

and without OAR support for each of the above channel failure scenarios

and present the test data in comparison.

Following assumptions are made for the purpose of this study:

The MAC layer implementation of the NS2 simulator performs as per in

the literature with CSMA/TDM protocols.

56

APPENDIX B

TCL script for scenario with 50 nodesusing AODV protocol

# wrls-aodv-50.tcl

# 50-nodes example for ad-hoc simulation with AODV

#**Sam

if {$argc < 1} {

puts stderr "usage: ns $argv0"

puts stderr " 0 ---> 802.11 1 ---> OAR"

exit 1;

}

# Mode

set mode [lindex $argv 0]

puts "mode: $mode"

#Sam**

# Define options

set val(chan) Channel/WirelessChannel ;# channel type

set val(prop) Propagation/TwoRayGround ;# radio-propagation model

set val(netif) Phy/WirelessPhy ;# network interface type

set val(mac) Mac/802_11 ;# MAC type

set val(ifq) Queue/DropTail/PriQueue ;# interface queue type

set val(ll) LL ;# link layer type

set val(ant) Antenna/OmniAntenna ;# antenna model

set val(ifqlen) 30 ;# max packet in ifq

set val(nn) 50 ;# number of mobilenodes

set val(rp) AODV ;# routing protocol

set val(x) 1000 ;# X dimension of topography

57

set val(y) 1000 ;# Y dimension of topography

set val(cp) "tcp-50" ;# Node creation file

set val(sc) "scen-50" ;# Node movement file

set val(stop) 1200 ;# time of simulation end

#**Sam

Mac/802_11 set basicRate_ 1e6

Mac/802_11 set mode_ $mode

Phy/WirelessPhy set CSThresh_ 3.652e-10

#Sam**

set ns_ [new Simulator]

set tracefd [open simple.tr w]

set windowVsTime2 [open win.tr w]

set namtrace [open simwrls.nam w]

$ns_ trace-all $tracefd

$ns_ namtrace-all-wireless $namtrace $val(x) $val(y)

# set up topography object

set topo [new Topography]

$topo load_flatgrid $val(x) $val(y)

#

# Create God

#

set god_ [create-god $val(nn)]

#

# Create nn mobilenodes [$val(nn)] and attach them to the channel.

#

# configure the nodes

$ns_ node-config -adhocRouting $val(rp) \

-llType $val(ll) \

-macType $val(mac) \

-ifqType $val(ifq) \

-ifqLen $val(ifqlen) \

-antType $val(ant) \

58

-propType $val(prop) \

-phyType $val(netif) \

-channelType $val(chan) \

-topoInstance $topo \

-agentTrace ON \

-routerTrace ON \

-macTrace OFF \

-movementTrace ON

for {set i 0} {$i < $val(nn) } { incr i } {

set node_($i) [$ns_ node]

}

#

# Define node movement model

#

puts "Loading connection pattern..."

source $val(cp)

#

# Define traffic model

#

puts "Loading scenario file..."

source $val(sc)

# Printing the window size

proc plotWindow {tcpSource file} {

global ns_

set time 0.01

set now [$ns_ now]

set cwnd [$tcpSource set cwnd_]

puts $file "$now $cwnd"

$ns_ at [expr $now+$time] "plotWindow $tcpSource $file" }

# Define node initial position in nam

for {set i 0} {$i < $val(nn)} { incr i } {

# 50 defines the node size for nam

$ns_ initial_node_pos $node_($i) 50

}

59

# Telling nodes when the simulation ends

for {set i 0} {$i < $val(nn) } { incr i } {

$ns_ at $val(stop) "$node_($i) reset";

}

# ending nam and the simulation

$ns_ at $val(stop) "$ns_ nam-end-wireless $val(stop)"

$ns_ at $val(stop) "stop"

$ns_ at $val(stop).0002 "puts \"NS EXITING...\" ; $ns_ halt"

proc stop {} {

global ns_ tracefd namtrace

$ns_ flush-trace

close $tracefd

close $namtrace

}

$ns_ run

60

APPENDIX C

Perl script to extract the network TCPthroughput

# type: perl throughput.pl <trace file> <granularity>

$infile=$ARGV[0];

$granularity=$ARGV[1];

#We compute how many TCP packets were received at end of each second

#until the simulation was completed. These number of packets were then

#recorded against the time.

$received=0;

$sent=0;

$clock=0;

$totalR=0;

$totalS=0;

$agt=’AGT’;

open (DATA, "<$infile")

|| die "Cant open $infile $!";

while (<DATA>)

{

@x = split(’ ’);

if ($x[1]-$clock <= $granularity)

{

if ( ($x[0] eq ’r’) && ($x[3] eq $agt) && ($x[6] eq ’tcp’) )

61

{

$received = $received + 1;

}

if ( ($x[0] eq ’s’) && ($x[3] eq $agt) && ($x[6] eq ’tcp’) )

{

$sent = $sent + 1;

}

}

else

{

#Display the throughput for previous second

$totalR = $totalR + $received;

$totalS = $totalS + $sent;

print STDOUT "$clock $received\n";

$clock=$x[1];

$received = 0;

$sent = 0;

if ( ($x[0] eq ’r’) && ($x[3] eq $agt) && ($x[6] eq ’tcp’) )

{

$received = 1;

}

if ( ($x[0] eq ’s’) && ($x[3] eq $agt) && ($x[6] eq ’tcp’) )

{

$sent = 1;

}

}

}

$totalR = $totalR + $received;

$totalS = $totalS + $sent;

print STDOUT "$x[1] $throughput\n";

print STDOUT "Total Received: $totalR\n";

print STDOUT "Total Sent: $totalS\n";

$totalR=0;

$totalS=0;

$clock=0;

62

$received=0;

$sent=0;

close DATA;

exit(0);

63

Bibliography

[1] http://networks.rice.edu/ext/oar/index.htm.

[2] B. Sadeghi, V Kanodia, A. S. Opportunistic auto-rate media accessprotocol for ad hoc networks.

[3] Charles E. Perkins, P. B. Highly dynadestination-sequenced distance-vector routing for mobile computers, 1994.

[4] Comer, D. E. Internetworking with TCP/IP Principles, Protocols, andArchitectures, second ed. Adison-Wesley, 2000.

[5] Craig Sweet, V. D., and Sidhu, D. Ieee 802.11 performance in anad-hoc environment, Feb 2004.

[6] Datta, A. Wireless mobile networks lecture notes.

[7] Eitan Altman, T. J. Ns2 lecture notes, Dec 1998.

[8] Fall, K., and Varadhan, K. The NS2 Manual, The VINT Project. IEEEComputer Society, 2000.

[9] Gavin Holland, N. V., and Bahl, P. A rate-adaptive mac protocol formulti-hop wireless networks. pp. 236–251.

[10] Ian D. Chakeres, E. M. B.-R. Ad-hoc ondemand vector protocol.

[11] IEEE Computer Society. IEEE Std 802.11: Wireless Lan Medium Ac-cess Control (MAC) and Physical Layer (PHY) Specifications, June 1997.

[12] Imrich Chlamtac, Marco Conti, J. J. N. L. Mobile ad-hoc network-ing: imperatives and challenges, 2003.

[13] Jacobson, V., and Karels, M. J. Congestion avoidance and control.pp. 314–329.

[14] Javier Del Prado Pavon, S. C. Link adaptation strategy for ieee 802.11wlan via received signal strength measurement. IEEE International Confer-ence on Communications 2 (May 2003), 1108–1113.

64

[15] Kamerman, A., and Monteban, L. Wavelan ii: A high performancewireless lan for the unlicenced band. Bell labs Technical Journal (1997),118–133.

[16] Kim J.M., J. J. Performance evaluation of aodv-based power-aware routingprotocol in mobile ad hoc networks.

[17] Lawrance S. Brackmo, S. W. O., and Peterson, L. L. Tcp vegas:New techniques for congestion detection and avoidance. Sigcomm, pp. 24–35.

[18] Mathieu Lacage, M. H. M., and Turletti, T. In mswim 04: Pro-ceedings of the 7th acm international symposium on modeling, analysisandsimulation of wireless and mobile systems, new york, ny, usa.

[19] Rui Jiang, V. G., and Ravishankar, C. V. Interactions between tcpand the ieee 802.11 mac protocol. DARPA Information Survivability Con-ference and Exposition 1 (2003), 273–282.

[20] Sorav Bansal, Rajeev Shorey, A. A. K. Performance of tcp and udpprotocols in multi-hop multirate wireless networks, 2004.

[21] Stevens, W. Tcp slow start, congestion avoidance fast retransmit, andfast recovery algorithms, Jan 1997.

[22] Timo Zauner, Luke Haslett, W. H. S. J. C. J. S. A congestion-awaremedium access control protocol for multi-rate ad-hoc networks.

[23] Zauner, T. Tcp in multirate wireless networks, April 2006.

[24] Zhengghua Fu, Haiyun Luo, P. Z. L. Z. M. G. The impact of mul-tihop wireless channel on tcp performance. IEEE Transactions on MobileComputing 4 (April 2005), 2.

65