Research Article XCP-Winf and RCP-Winf: Improving...

Research ArticleXCP-Winf and RCP-Winf Improving Explicit WirelessCongestion Control

Luiacutes Barreto

Escola Superior de Ciencias Empresariais Instituto Politecnico de Viana do Castelo Valenca 4930-678 Viana do Castelo Portugal

Correspondence should be addressed to Luıs Barreto lbarretoesceipvcpt

Received 16 May 2014 Revised 18 December 2014 Accepted 18 December 2014

Academic Editor Tzonelih Hwang

Copyright copy 2015 Luıs Barreto This is an open access article distributed under the Creative Commons Attribution License whichpermits unrestricted use distribution and reproduction in any medium provided the original work is properly cited

Congestion control in wireless networks is strongly dependent on the dynamics and instability of wireless links Therefore it isvery difficult to accurately evaluate the characteristics of the wireless links It is known that TCP experiences serious performancedegradation problems inwireless networksMoreover congestion controlmechanisms that rely onnetwork interaction andnetworkparameters such as XCP and RCP do not evaluate accurately the capacity and available link bandwidth in wireless networks Inthis paper we propose new explicit flow control protocols for wireless mesh networks based on XCP and RCP We name theseprotocols XCP-Winf and RCP-Winf They rely on the MAC layer information gathered by a new method to accurately estimate theavailable bandwidth and the path capacity over a wireless network path The estimation is performed in real time and without theneed to intrusively inject packets in the network These new congestion control mechanisms are evaluated in different scenarios inwireless mesh and ad hoc networks and compared against several new approaches for wireless congestion control It is shown thatboth XCP-Winf and RCP-Winf outperform the evaluated approaches showing its stable behavior and better channel utilization

1 Introduction

Reliable transport protocols such as TCP were developedto perform well in traditional wired networks where packetlosses occur mostly because of congestion [1] Howevernetworks with wireless and other lossy links also sufferfrom significant losses due to bit errors and handoffs TCPresponds to the losses by invoking congestion control andavoidance algorithms This results in degraded end-to-endperformance in wireless systems and networks [2]

Recent efforts to design better congestion control have ledto the origin of several explicit-feedback congestion controlmethods These methods solicit active multibyte feedbackfrom the routers to the end-hosts delivering a precise andtimely congestion signal that is used to accurately adjustflow sending rates Therefore they aim to achieve faster con-vergence smaller packet loss rate high link utilization andbetter fairness between flows Examples of these congestioncontrol mechanisms that rely on network interaction arethe explicit control protocol (XCP) [3] and the rate controlprotocol (RCP) [4] Their main purpose is to generalizeexplicit congestion notification where nodes inform eachother about the degree of congestion XCP decouples channel

utilization from fairness control and requires the efficientestimation of the aggregate traffic behavior that is bothavailable bandwidth and link capacity RCP is a congestioncontrol algorithm whose main key is to finish the flows asfast as possible RCP dynamically updates the rate assigned tothe flows approximating a processor sharing in the presenceof feedback Although the support of explicit congestioncontrol and network interaction is expected to lead to a moreefficient congestion control in shared medium systems suchas wireless mesh and ad hoc networks we have shown in [5]that this is not the case since they are incapable of predictingeffectively capacity inwireless networks and also that they arenot efficient and fair This is due to the fact that the availablecapacity at a wireless link depends on the link rates at theneighboring edges Ignoring this dependence will overesti-mate the available capacity and lead to poor performance andto instability We believe that estimating the exact capacityof a link as a function of the link rates at the neighboringedges would provide accurate XCP- and RCP-like scheme tobe implemented for wireless multihop networks

To support efficiency and stability of wireless networks itis crucial to develop a congestion control scheme which pro-vides efficient and accurate sharing of the underlying network

Hindawi Publishing CorporationJournal of Computer Networks and CommunicationsVolume 2015 Article ID 925207 18 pageshttpdxdoiorg1011552015925207

2 Journal of Computer Networks and Communications

capacity among multiple competing applications Factorssuch as handoffs channel allocation and channel quality aredirectly related to link capacity Being able to accuratelymon-itor link capacity and available bandwidth and then use thatinformation to perform accurate congestion control is a mainchallenge inwireless communications In [6]we proposed thert-Winf algorithm which is a new wireless inference mecha-nism based on IdleGap [7] that is able to estimate availablebandwidth and path capacity rt-Winf uses the informationincluded in RTSCTS packets to measure the transmissiontime and obtain the link capacity and available bandwidth

In this paper we describe XCP-Winf and RCP-Winf twonew congestion control mechanisms based respectively onXCP and RCP that are extended with the support of anaccurate capacity and available bandwidth computation algo-rithm The link capacity and available bandwidth obtainedthrough rt-Winf are transmitted through cross layer tech-niques to XCP and RCP that use that information in theirnative congestion control techniques We show how newXCP-Winf andRCP-Winf functions can be built with this newinformation The proposed congestion control approachesare evaluated in different simulated scenarios mesh and adhoc and are evaluated against state-of-the-art congestioncontrol mechanismsThe obtained results show that the inte-gration of rt-Winf allows clear improvement of XCP and RCPnetwork performance against standard congestion controlprotocols and also against specific congestion protocols forwireless environments

In [8] we presented a base version of both XCP-Winf andRCP-Winf with preliminary results In this paper we presenta complete proposal (1) we present the rt-Winf approachwith an evaluation through simulation and emulation inCMU wireless emulator [9] (2) we describe and refine theconceptual approach of both XCP-Winf and RCP-Winf witha new mathematical model (3) we perform a completeevaluation of the congestion control approaches comparedagainst state-of-the-art approaches such as XCP-b [10] andTCP-AP (TCPwith adaptive pacing) [11] (4)we complete theevaluation with the assessment of both XCP-Winf and RCP-Winf in terms of TCP-friendliness

The remaining of this paper is organized as followsNext section Section 2 briefly presents the background andrelated workThen Section 3 describes the rt-Winf algorithmand rt-Winf obtained results In Section 4 how rt-Winf isintegrated within both XCP and RCP is presented Section 5describes and discusses the results obtained through sim-ulation using mesh and ad hoc scenarios with differentcharacteristics Finally Section 6 presents the conclusionsand future work

2 Related Work

21 Capacity and Available Bandwidth Estimation AdHocProbe [12] WBest [13] TSProbe [14] and IdleGap [7] aresome examples of link estimation mechanisms for wirelessnetworksWhileWBest calculates both capacity and availablebandwidth AdHoc Probe provides only the path capacity ofthe wireless channel However WBest is known to be very

intrusive when estimating the available bandwidth TSProbe[14] is a new capacity estimation tool based on AdHocProbe but it is focused on time-slotted connections such asbluetooth or WIMAX TSProbe uses the interaction betweenseveral link layer properties to deploy an adaptive probingscheme that utilizes payloads that vary in sizeWhile accuratein time-slotted connections it lacks efficiency in dynamicwireless environments

IdleGap takes into consideration the CSMA collisionavoidance (CSMA-CA) schemeofwireless networks to obtainits available bandwidth The idle nodes which are waiting totransmit use the network allocation vector (NAV) [15] whichshows how long other nodes allocate the link in the IEEE80211 MAC protocol The idle time in the wireless networkcan then be estimated from the NAV information

All the presented mechanisms were defined with themain purpose of only estimating available bandwidth andlink capacity in specific network conditions Some mecha-nisms can only estimate available bandwidth and others onlyestimate link capacity In a wireless network environmentit is important to have a tool that can retrieve an accurateestimation of the busy time and the total elapsed timebetween communications It is also important to have amechanism that uses not only source information but alsoreceiver information as this is the only way to have a precisenetwork status It is therefore important to introduce theconcept of network cooperation in network estimation toolsAnother important issue is the effective calculation of theactual data rate that is used by each communication process

22 Congestion Control The transmission control protocol(TCP) [16] is the most used congestion control protocol incomputer networks However TCP assumes that the proba-bility of a lost packet is higher than the one of a corruptedpacket [17] which is not true in wireless networks Severalcongestion control mechanisms were proposed to enhanceTCPrsquos behavior in a wireless environment Mechanisms likeTCP-F [18] TCP-ELFN [19] TCP-BuS [20] and ATCP [21]represent some examples of protocols for wireless networksin generalThey concentrate on improving TCPrsquos throughputby freezing TCPrsquos congestion control algorithm during link-failure induced losses especially when route changes occurThese TCP developments differ in themanner inwhich lossesare identified and notified to the sender and in their detailsof freezing TCPrsquos congestion control algorithm Even thoughthese schemes do not recognize the need of congestiondetection and signaling over a neighborhood their conges-tion metric implicitly takes some degree of neighborhoodcongestion into account

WCP [22] and WCPCap [22] are congestion controlmechanisms developed for wireless mesh networks WCP isAIMDbased and for every flow the sourcemaintains a rate119877which represents the long term sending rate for the flowThemain issue of WCP is that it does not correctly evaluate theavailable rate making an assumption that all links have equalrate WCPCap estimates the available capacity within eachneighborhood and distributes this capacity to contendingflows using a distributed rate controller Available capacity in

Journal of Computer Networks and Communications 3

WCPCap is obtained through an analytical model presentedin [23] which lacks sender and receiver node cooperationMoreover it does not take into consideration all the factorsthat influence the network dynamics thus leading to inaccu-rate and overestimated values New mechanisms like imTCP(in-line measurement TCP) [24] and TCP-AP (TCP withadaptive pacing) [11] have been proposed ImTCP introducesa new bandwidth measurement algorithm that can performin-line measurements The available bandwidth estimationresults from the arrival intervals of ACKs packets Howeverthese intervals in dynamic wireless environments can sufferhigh variation thus introducing lack of accuracy Anotherimportant drawback of imTCP is that it can only estimateavailable bandwidth TCP-APwas developed taking only intoconsideration multihop wireless environments A TCP-APsender adapts its transmission rate using an estimate of the4-hop propagation delay and the coefficient of variation ofrecently measured round-trip times being very conservativeand not using efficiently the medium

For ad hoc networks other congestion control techniqueswere developed such as TPA (transport protocol for ad hocnetworks) [25] COPAS [26] and LRED [27] TPA congestioncontrol mechanism is inspired by TCP but it is optimizedto minimize the number of required packet retransmissionstransmitting blocks using a window-based scheme As TPAuses blocks on its operation it can suffer high performancedegradation as it does not consider information on linkcapacity and available bandwidth measurements COPASproposes a route selection scheme that attempts to finddisjoint paths for different flows by assigning weights tolinks proportional to the average number of backoffs onthe link COPAS therefore needs to use a large amountof network information thus being very aggressive to thenetwork and requiring a large amount of processing LREDuses an exponential weighted moving average of the num-ber of retransmissions at the MAC layer as a measure ofcongestion while marking packets LRED calculates droppedpackets based only on its ownperception whichmakes LREDbehavior inefficient and unstable

Recent research has recognized the importance of explic-itly detect and signal congestion over a networkOne exampleis the explicit wireless congestion control protocol (EWCCP)[28] which identifies the set of flows that share the chan-nel capacity with flows passing through a congested nodeEWCCP is as TCP an AIMD algorithm based protocolwhich lacks the maximization of the network utilization toachieve the highest minimum rate possible When in moredynamic environments this is a main issue

An alternative to AIMD based approaches is schemes inwhich intermediate routers send explicit and precise feedbackto the sources Examples of such congestion control schemesare the explicit control protocol (XCP) [3] and the rate controlprotocol (RCP) [4]

XCP was designed to extract congestion informationdirectly from intermediate nodes (routers andor switches)XCP uses a feedback mechanism to inform the senderabout the best network conditions that is the maximumthroughput This feedback is accomplished by the use ofa congestion header in each packet sent Along the path

intermediate nodes update the congestion header When thepacket reaches the receiver it copies the network informationobtained from the last intermediate router into outboundpackets of the same flow (normally acknowledgment pack-ets) WXCP [29] and XCP-b [10] are variants of XCP thatmeasure indirect parameters such as queue sizes and numberof link layer retransmissions using very complex heuristicsThe direct estimation of the link capacity will allow a moreaccurate XCP-like scheme to be implemented for wirelessmultihop networks

The rate control protocol (RCP) aims to deliver fast flow-completion or download times RCP uses the same feedbackprinciple of XCP and tries to emulate processor sharingHowever it uses a different approach routers along the pathdo not determine incremental changes to the end-systemrsquosthroughput but determine the available capacity and the rateat which the end-system should operate More recently andtaking into consideration RCP main properties for wirelesssensor networks (WSN) the wireless rate control protocol(WRCP) [30] mechanism has been proposed WRCP usesexplicit feedback based on capacity information to achievea max-min fair rate allocation over a collection tree InWRCP a receiver capacity model is applied This modelassociates capacities with nodes instead of links The receivermodel is also used to develop and implement the explicitand distributed rate-based congestion control protocol forwireless sensor networks

3 rt-Winf

In this section we analyse the main principles and results ofrt-Winf since it will be the basis of the new approaches forXCP-Winf and RCP-Winf IdleGap [7] was the underlyingbasis for the development of rt-Winf Themain purpose of rt-Winf was to mitigate IdleGap main issues being compatiblewith all systems and evaluating both the link capacity andthe available bandwidth without overloading the network rt-Winf considers the link capacity as the maximum sustainabledata rate at a link The available bandwidth is the unusedportion of the link capacity rt-Winf does not affect theOSI model and obtains all of the necessary information tocalculate the path capacity and available bandwidth Oneof the main issues of IdleGap is that it uses the DataRatevalue of the IEEE80211 header [31] while rt-Winf effectivelycalculates the capacity The operational principles of rt-Winfallow it to rely on the Request To Send (RTS)Clear To Send(CTS) handshake or on small probe packets

31 RTSCTS Packets A RTSCTS enabled rt-Winf mecha-nism relies on the RTSCTS handshake to correctly retrievethe NAV values and uses the same node states as defined byIdleGap that is the Sender Onlooker and Receiver statesIn the Sender state the node is transmitting data in theReceiver state the node is receiving data and in the Onlookerstate the node is not participating in the transmission TheRTSCTS handshake allows rt-Winf to immediately startevaluating both link capacity and available bandwidth afterthe handshake completion time


Table 1 rt-Winf algorithm

State Available bandwidth Capacity

Onlooker

Captured RTS packet

119862Onlooker =119878

119879ACK minus 119879CTS minus 2119879SIFS

Yes

AB = 119862Onlooker times (1 minussumNAVRTS

119879Total)

No

AB = 119862Onlooker times (1 minussumNAVCTS

119879Total)

Sender AB = 119862Sender times (1 minussumNAVCTS

119879Total) 119862Sender =

119878


Receiver AB = 119862Receiver times (1 minussumNAVRTS

119879Total) 119862Receiver =

119878

119879DATA minus 119879RTS minus 3119879SIFS

The RTSCTS packets have accurate duration valueswhich can be used to trigger rt-Winf calculations Tounderstand how RTSCTS packets can be used by eachnode state a set of handshake captures was performed Theobtained captures showed information on how each nodestate manages the received packets CTS DATA and ACKpackets are captured in the case of the Sender state In theReceiver state a node is able to capture the RTS and theDATApackets while a node in the Onlooker state is able to capturethe complete set of packets RTS CTS DATA and ACKThis different knowledge implied the conception of differentalgorithms for each state Then we propose that each nodestate uses a different method to determine the Idle Rate ascan be seen in Table 1

To obtain the link capacity and the available bandwidthestimations a node in the Sender state relies on the NAVinformation of the CTS packets Thus a Sender obtains thelink capacity (119862Sender) using

119862Sender =119878

119879ACK minus 119879CTS minus 2119879SIFS (1)

where 119878 is the DATA packet size 119879ACK is the actual clocktime when the ACK packet is received 119879CTS is the clock timeof the CTS packet reception and 119879SIFS is the duration of theoccurred short interframe spacing (SIFS)The time when thechannel is busy can then be represented by

119879Busy = 119879ACK minus 119879CTS minus 2119879SIFS (2)

When the Sender obtains the capacity it can determinethe available bandwidth (AB) by

AB = 119862Sender times (1 minussumNAVCTS119879Total

) (3)

where NAVCTS is the NAV information on a CTS packet and119879Total represents the total elapsed transmission time obtainedby the difference between the last captured ACK time and theinitial transmission time

In the Receiver state a node uses the NAV information onthe RTS packets to obtain the capacity (119862Receiver) or Idle Rateby

119862Receiver =119878

119879DATA minus 119879RTS minus 3119879SIFS (4)

where 119879RTS is the time when the RTS packet was received and119879DATA is the clock information of the reception of the firstDATA packet The Receiver available bandwidth estimationis then calculated through

AB = 119862Receiver times (1 minussumNAVRTS119879Total

) (5)

where NAVRTS represents the NAV value on the RTS packetand 119879Total is defined as the difference between the last sentACK packet time and the initial RTS reception time

The Onlooker state uses the NAV value according tothe existence or not of the RTS packet to obtain both theavailable bandwidth and capacity If a node in the Onlookerstate captures a CTS packet of a communication without cap-turing the RTS packet this implies that the communication issuffering from the hidden nodes problemThus the algorithmwill only use the NAV from the CTS packet to retrieve thecorrect values An Onlooker node obtains the link capacity(119862) by

119862Onlooker =119878


If the node only captures a CTS packet the AB is obtainedby

AB = 119862Onlooker times (1 minussumNAVCTS119879Total

) (7)

where119879Total is equal toNAVCTS+119879CTS+2SIFS If theOnlookerreceives a RTS packet then

AB = 119862Onlooker times (1 minussumNAVRTS119879Total

) (8)

And 119879Total is defined as NAVRTS + 119879RTSTable 2 shows for a better understanding of the available

bandwidth and capacity evaluation the variable symbols andtheir description used in rt-Winf calculations

A general rt-Winf system with its main functioningprinciples and states transitions can be observed in Figure 1The estimation process in the Receiver starts when a RTSpacket is received If the node transitions from the Onlooker


UpdatesCOnlooker

No DATA to transmit

DATA to transmit sends RTS

No RTS

Receives CTS

Stores TCTSSends DATA

Receives ACKfrom the receiver withreceiver capacity (CReceiver)

DeterminescapacityCOnlooker

Receives RTS

Receiver

Updates

Stores TRTS

Sends CTS

Receives DATA

Stores TACKCalculates receiver

capacity (CReceiverIf COnlookerdetermines

(

Stores TACKCalculates sender capacity (CSender)If COnlookerDetermines CSender minus COnlookerIf gt 0 CSender = COnlookerIf lt 0 CSender = CSenderDetermines CSender minus CReceiverIf gt 0 C = CReceiverIf lt 0 C = CSender

Calculatesavailable bandwidth (AB)

2

3

4

5

1

2

3

4

5

1

0 COnlooker

If gt 0 CReceiver = COnlookerIf lt 0 CReceiver = CReceiver

CReceiver minus COnlooker

Sends ACK with CReceiver

Sender Onlooker

Figure 1 rt-Winf Sender Receiver and Onlooker state diagrams

Table 2 rt-Winf variables

Variable Description119862 Capacity119862Sender Sender state capacity119862Receiver Receiver state capacity119862Onlooker Onlooker state capacityAB Available bandwidth119878 Packet size119879Transfer Transfer time119879Total Total elapsed time119879ACK Time of ACK packet119879DATA Time of DATA packet119879BO Backoff timeMSDU MAC service data unitNAVCTS NAV value in CTS packetNAVRTS NAV value in RTS packet119879CTS CTS packet time119879RTS RTS packet time119879MSDU Delay per MSDU11987980211b Maximum 80211b theoretical throughput

state to the Receiver state it stores theOnlooker state capacity(119862Onlooker) estimated value First the node stores the timeat which it received the RTS packet (119879RTS) Then it sends

a CTS packet to the Sender initiating the communicationprocess When the Receiver receives the actual data it storesits reception time (119879DATA) and then using the correspondingcapacity estimation equation it obtains its link capacity Ifthe Receiver has stored 119862Onlooker meaning that there wasa transition from the Onlooker state to the Receiver statethe node compares its capacity estimation value (119862Receiver)with 119862Onlooker If it returns a positive value it updates thereceiver capacity value to 119862Onlooker otherwise it uses itscapacity estimated value of119862ReceiverThis process is describedin (9) The node will always use the smallest value of the twocapacities for better channel utilization

119862Receiver minus 119862Onlooker

if (gt 0) 997904rArr 119862Receiver = 119862Onlooker

else if (lt 0) 997904rArr 119862Receiver = 119862Receiver

(9)

Then the 119862Receiver value is sent to the Sender on an ACKpacket

In the Sender state and when a CTS packet is capturedthe node starts to evaluate the available bandwidth and linkcapacity First the node stores the time at which the CTSpacket is received (119879CTS) and then starts to send the actualdata When it receives an ACK packet acknowledging datareception it stores the time at which the ACK packet wasreceived (119879ACK) and obtains from the received ACK packetheader the 119862Receiver Then it uses the corresponding equationof Table 1 to estimate its link capacity (119862Sender)


If the node goes to the Sender state from the Onlooker itfirst compares the 119862Sender with stored capacity 119862Onlooker Thenode has to use the minimum value of the capacities So forobtaining that minimum value between 119862Sender and 119862Onlookerthe node subtracts the 119862Onlooker value from the 119862Sender valueIf this value is positive it means that the minimum value isequal to 119862Onlooker thus the node updates the 119862Sender valueto be equal to the 119862Onlooker value Otherwise it maintains asthe minimum capacity value its 119862Sender capacity value Thisoperation is described in

119862Sender minus 119862Onlooker

if (gt 0) 997904rArr 119862Sender = 119862Onlooker

else if (lt 0) 997904rArr 119862Sender = 119862Sender

(10)

Then it compares 119862Sender with the one received on thereceived ACK packet (119862Receiver) For better channel use it hasto use the minimum capacity value this avoids queue fill-ups and bottlenecks If the node was not previously on theOnlooker state it immediately compares its 119862Sender capacityestimated value with the 119862receiver value received on the ACKpacket If it returns a positive value the sender updates itscapacity to 119862Receiver otherwise it uses the stored value of119862Sender

119862Sender minus 119862Receiver

if (gt 0) 997904rArr 119862Sender = 119862Receiver


(11)

Finally and with the stored capacity value it determinesthe corresponding available bandwidth This cooperationprocess between the Sender and the Receiver is a greatimprovement when compared to IdleGap The onlookingcapacity is obtained as described in Table 1

32 Probe Packets If RTSCTS packets are not present rt-Winf can use probe packets in order to retrieve the transfertime values Probe packets can be sent between nodes Probepackets are just sent in the beginning of the communicationand for each new communication new probe packets aresent To achieve good results we use packets with 1500 bytesand frequency of 4 samples before the actual transmissionstarts (as stated in [12]) It must be noticed however thatprobe packets with reduced sizes can be used The probepackets must be UDP generated packets with altered framecontrol IEEE 80211 header type data and subtype reservedWe use packets with frame control type set to 10 (data)and subtype to 1001 (reserved) This way the Sender and theReceiver can successfully differentiate these packets from theordinary data packets The IEEE 80211 standard defines thatfor each successfully received packet it must be sent a MACACK packet [31] The whole process is very similar to the onewith the RTSCTS handshake

The process for determining the initial capacity lasts theduration of the period that corresponds to sending a packetand receiving its correspondent MAC ACK packet

The generated packets are used to retrieve the capacity(119862) and available bandwidth (AB) values according to thefollowing

119862 =119878

119879Transfer (12)

where 119878 is the packet size and 119879Transfer the transfer time isequal to 119879ACK minus 119879DATA and

AB = 1 minus (sum119901

119894119879Transfer

119879Total) times 119862 (13)

where 119901 is the number of packets transmitted and 119879Total is thetotal elapsed time since the beginning of the process

The generated packets are only sent before a node startsa transmission and in the absence of traffic This allows thesystem to initially determine the available bandwidth andcapacity Then the existing traffic and the MAC layer ACKwill be used to trigger the calculations As NAV values are notcorrectly defined in DATA packets rt-Winf uses clock timeinformation to determine the busy time Each node state hasto manage independently its clock information ThereforeNAV values are not considered in this specific implementa-tion with probe packets To be fully operational both Senderand Receiver must be running the rt-Winf mechanism

In a normalVoIP call usingG711 codec [32] the overheadintroduced by this mechanism is sim166 For a flow withmore than 1Mbps the overhead is less than sim015

33 rt-Winf Results We have implemented rt-Winf in theCMU wireless emulator [9] and in the ns-2 simulator [33]The three states defined by rt-Winf mechanism and the coop-eration between them and between the nodes was developedin 119862 language In base rt-Winf the system is configured withenabledRTSCTSACKhandshake packets In rt-Winf probeprobe packets are implemented The maximum achievabledata rate is set to 11Mbps Nodes are placed in such a distancethat the path loss effect is considered negligible Path capacityand available bandwidth are evaluated in different scenarios

For path capacity evaluation rt-Winf results are com-pared againstAdHoc Probe results andmaximum throughput(that represents the maximal theoretical throughput) in asimple 2 ad hoc nodes testbed AnUDPflowwith constant bitrate (CBR) of 64Kbps is transferred between the two nodesAccording to [34] the maximal theoretical throughput isobtained through

TH80211b =MSDU119879MSDU

(14)

where MSDU is the MAC service data unitThe maximum throughput represents in ideal condi-

tions the maximum achievable capacity Figure 2 shows thepath capacity results With a CBR flow in the network theexpected capacity shall be lower than themaximum through-put The simulations validate this assumption showing thatrt-Winf results are close to the maximum throughput valuesIt is then possible to observe that rt-Winf uses efficiently theinformation present in the channel in order to obtain the


0

2

4

6

8

10

0 50 100 150 200 250 300 350 400

Capa

city

(Mbp

s)

Time (s)

Maximum throughput

AdHoc Probert-Winf

Figure 2 AdHoc Probe and rt-Winf path capacity estimation

resulting capacity This is because rt-Winf measures moreaccurately the channel occupation time as it takes intoconsideration all traffic flows Compared to the AdHoc Probemechanism and with a similar probing time rt-Winf gathersmore information to perform the desired calculations thusbeing able to be statistically more precise and less sensitive toflow variationsAdHoc Probe only takes into consideration itsprobing packets which can suffer dispersion and collisionsintroducing a negative impact on the capacity evaluation

Path capacity and available bandwidth evaluations arealso conducted on a wireless mesh scenario (Figure 3)The two mobile nodes Mobile Node 1 and Mobile Node 2communicate with each other through two mesh nodes thatare responsible for the routing and link management Themobile nodes are in such a distance that the traffic is alwaysrouted by the mesh nodes

Path capacity results are shown in Figure 4 and availablebandwidth results are shown in Figure 5 Figure 5 containsthe results of rt-Winf IPerf UDP [35] and IdleGap Maximumthroughput values are also presented being considered as anupper bound of the result as described before IPerf UDPresults are considered the lower bound

As observed in Figure 4 rt-Winf is less sensitive tovariationswhen compared toAdHoc ProbeThis is because rt-Winf is taking into consideration all packets in the networkand ismeasuring the channel occupation time of each packetwhile AdHoc Probe is only considering the packets that itgenerates thus being more sensitive to flow variations

The results presented in Figure 5 allow observing howIdleGap is not effectively measuring the available bandwidthIdleGap values have a small variation but are near to theDataRate value In rt-Winf it is possible to observe how theresults vary through time Those results are within an upperbound the maximum theoretical throughput and a lowerbound IPerf UDP

To observe the impact of rt-Winf with probe packets ina wireless mesh scenario and to allow a valuable comparisonbetween the emulator and simulator results simulations in

the ns-2 simulator [33] were also conducted As rt-Winfis based on IdleGap the simulations also allow a baselinecomparison of those mechanisms In the simulations a FTPtransfer from a source to a sink is used with different simul-taneous flows The maximum throughput is calculated usingns-2 default values and using (14) Figure 6 summarizes theobtained results Each value is an average of 20 runs lasting300 seconds of simulated time and nodes are stationary Asobserved IdleGap results are almost equal to the maximaltheoretical throughput as it is using the IEEE80211 headerDataRate value in the calculations These results validatethe ones obtained with the CMU emulator since the resultsfor 1 flow in Figure 6 are similar to the ones of Figure 4In the simulations with rt-Winf probes probe packets withdifferent sizes are used The results show that rt-Winf withprobe packets is also efficiently measuring the capacity andits values are very similar to the rt-Winf mechanism workingwith RTSCTS control packets

4 XCP-Winf and RCP-Winf

To improve the performance of congestion control tech-niques in dynamic wireless networks we define a newcongestion control approach based on XCP and RCP Thesolution proposed adopts the explicit congestion controlscheme enhanced with the interaction of a link and availablebandwidth estimation mechanism As both base XCP andRCP do not rely on an effective link capacity estimation tool[36] they begin to use the link capacity at the interface tocompute the rate feedback this introduces capacity overesti-mationwhichwill generate inflated feedback and the senderswill send more traffic than the link can transfer In the newapproach rt-Winf estimates the available bandwidth that willbe used by the congestion controlmechanisms to update theirtransmit rateThe estimationmechanism is integrated both atSender Receiver and Onlooker nodes

rt-Winf estimation values are obtained in the MAC layerand therefore this information has to be accessed by XCP-Winf and RCP-Winf The rt-Winf information is sent to thenetwork layer through a simple but effective cross layercommunication process For this communication system ashared database architecture is used with a set of methods togetinsert information in a database accessible by all protocollayers One example of such architecture is the MobileMancross layered network stack [37]

A generic XCP-WinfRCP-Winf mechanism relies on themain functioning principles of XCP and RCP and is repre-sented in Figure 7 rt-Winf inserts the available bandwidthand the link capacity information in the shared database andthen XCP-Winf and RCP-Winf access that information anduse it to update their functions In the following subsectionswe present the algorithms performed on both XCP-Winf andRCP-Winf mechanisms

For a better understanding of the implemented functionsdescribed in the following sections Table 3 shows the variablesymbols and its description

41 XCP-Winf Functions This section describes the proposedXCP-Winf functionsThemain changes are performed on the


Mobile node 1Mobile node 2

Mesh node 1 Mesh node 2

Figure 3 Wireless mesh scenario

0

2

4

6

8

10

0 50 100 150 200 250 300 350 400

Capa

city

(Mbp

s)

Time (s)

AdHoc Probert-WinfMaximum throughput

Figure 4 Path capacity in the wireless mesh scenario

0

2

4

6

8

10

12

0 50 100 150 200 250 300 350 400

Avai

labl

e ban

dwid

th

Time (s)

Maximum throughputrt-WinfIdleGap

DataRateIPerf UDP

Figure 5 Available bandwidth in the wireless mesh scenario

XCP Sender and XCP router functionsThe XCP Sender usesthe Sender state of the rt-Winf algorithm and the XCP routeruses theOnlooker stateTheXCP-Winf Receiver is responsiblefor copying the throughput value required by the sender (inthe packet) represented by 119862desired to the reverse feedback

10000

9000

8000

7000

6000

5000

4000

3000

2000

1000

0

1 2 4 6 8

Number of flows

Capa

city

(kbp

s)

IdleGaprt-Winf probe (1000 bytes)rt-Winf RTSCTS

rt-Winf probe (300bytes)Maximum throughput

Figure 6 Ns-2 capacity results

field of outgoing packets A XCP-Winf Receiver operates in asimilarway as aXCPReceiverWhen acknowledging a packetthe XCP-Winf Receiver copies the congestion header fromthe data packet to the corresponding acknowledgment packetand acknowledges the data packet in the same way as a TCPreceiver

When operating as a XCP-Winf Sender several calcula-tions need to be performed for each packet In a XCP-Winfsystem the necessary change in the throughput (THchange) isobtained by

THchange =119862desired minus 119862winf

119862winf times (119879RTT119872) (15)

where 119879RTT is the current round-trip time (RTT) and 119872 isthe maximum segment size used on the network 119862winf is thelink capacity obtained from rt-Winf and 119862desired is a desiredchange in the capacity value that might be supplied by anapplication or it might be the speed of the local interfaceIf no additional capacity is needed or desired 119862desired willbe equal to zero and the packet will be immediately sent Ifthe value of THchange exceeds the available bandwidth valueABwinf obtained by rt-Winf it is reduced to the current valueof ABwinf


RetrieveXCPRCP

Transportlayer

rt-Winfmodule

Networklayer

MAClayer

Insert

Cross layershared

database

Figure 7 XCP-WinfRCP-Winf system

The XCP-Winf routernode system operations in theOnlooker state are divided into four moments when a packetarrives when a packet departs when the control intervaltimeout packet arrives and when it is required to assess thepersistent queue Once more rt-Winf available bandwidthand capacity are used in the calculations On a packetarrival the total input traffic (120601) seen at the XCP queue isincremented by the size of the packet receivedThe sumof theinverse throughput is used for capacity allocationThe inversethroughput constitutes a lower bound for the throughput forany balanced fair network and can be defined as the sumof the inverse residual capacities on the link The inversethroughput (THInverse) uses the capacity value obtained by rt-Winf and the packet size (119878) allowing having more precisevalues when compared to standard XCP

119894=119899

sum119894=1

THinverse =119878119894

119862winf119894 (16)

where 119899 is the number of packets receivedAnother importantparameter is the sum of 119879RTT by throughput this parameteris used to obtain the control interval on its calculation it usesrt-Winf capacity values

119894=119899

sum119894=1

Γ+ =119879RTT119894 times 119878119894

119862winf119894 (17)

This algorithm also checks if the round-trip time (119879RTT)of each flow is exceeding the maximum allowable controlinterval (119879ci) with a default value of 05 seconds If the round-trip time exceeds the threshold the maximum allowablecontrol interval to avoid delays when new flows are startedis updated to

119894=119899

sum119894=1

Γ+ =119879ci times 119878119894119862winf119894

(18)

When operating on the Onlooker state and when thecontrol timer expires rt-Winf values are used to determine

Table 3 XCP-Winf and RCP-Winf variables

Variable DescriptionTHchange Calculated throughput changeTHinverse Inverse throughput120601 Total input traffic119867RCP RCP header size119867IP IP header size119879pacing Pacing intervalΓ RTT by throughput119878 Packet size119872 Maximum segment size119902 Queue size119902 Instant queue119879RTT Sender estimate of the round-trip time (RTT)119879RTT Average 119879RTT119879ci Maximum allowable control interval119879119890 Queue estimation timer

119879119898Time between the transmission of twoconsecutive packets

119879RTT Sender estimate of the round-trip time (RTT)119879DIFS IEEE 80211 DCF interframe space time119879SIFS IEEE 80211 short interframe space time119879backoff IEEE 80211 backoff time119862winf rt-Winf obtained capacity119862desired Packet desired capacity change119862120593 Amount of capacity shuffled119862change Allocated feedback change119862119908 Weighted link capacity119862extra Extra bandwidth consumed due to backoffABwinf rt-Winf obtained available bandwidth119865 Aggregated feedback119877 RCP rate119901119891 Positive feedback factor119899119891 Negative feedback factor119891119901 Positive feedback119891119899 Negative feedbackCWSender Sender congestion window

the aggregated feedback (119865) The aggregated feedback valuedepends on the link available bandwidth The aggregatefeedback represents the desired variation onnumber of bytesthat the traffic is able to allow in a time interval normallythe average RTT A XCP-Winf router obtains the aggregatefeedback [3] based on rt-Winf information

119865 = 120572 times (119862winf minus ABwinf) minus 120573 times119902

119879RTT (19)

where 120572 and 120573 are constant parameters 119902 represents thequeue value 119879RTT represents the average RTT and 119902119879RTTrepresents the persistent queue ABWinf is the available band-width value of the rt-Winf mechanism


Then as stated in [3] the amount of capacity that willbe shuffled (119862120593) in the next control interval is obtainedThis allows new flows to acquire capacity in a full loadedsystem This parameter is obtained by max(0 01 times ABwinf minus|119865winf|) This will allow obtaining the increasemdashpositivefeedback scale factor (119901119891)mdashor decreasemdashnegative feedbackscale factor (119899119891)mdashon the traffic

119901119891 =119862120593 +max (119865 0)

sumΨ

119899119891 =119862120593 +max (minus119865 0)

120601

(20)

When a packet departs the node has to calculate a per-packet capacity change that will be compared to the 119879changevalue in the packet header As stated in [3] ldquousing theAIMD rule positive feedback is applied equally per flowwhile negative feedback is made proportional to each lowrsquoscapacityrdquo The allocated feedback (119862change) for the packet isthe positive per-packet feedback (119891119901)minus the negative per-packet feedback (119891119899) The positive feedback is obtained using119901119891 and the flows interpacket time then

119891119901 = 119901119891 times119878

119862winf (21)

The negative feedback is obtained using the packet sizeand the 119899119891

119891119899 = 119899119891 times 119878 (22)

Thus the capacity change requested is

119862change = 119891119901 minus 119891119899 (23)

This value may be positive or negative The node verifieswhether the packet is requesting more capacity (via thepacketrsquos 119862desired field) than the node has allocated If sothis means that the senderrsquos desired throughput needs tobe reduced and verified against rt-Winf available bandwidth(ABwinf) If the node has allocated more capacity than theavailable bandwidth the desired throughput is updated to thert-Winf available bandwidth If the allocated capacity is lessthan the available bandwidth the 119862desired field in the packetheader is updated with the feedback allocation

XCP-Winf as XCP needs to calculate a queue that doesnot drain in a propagation delay which is the persistentqueue This queue is intended to be the minimum standingqueue over the estimation interval Each time a packetdeparts the queue length ( 119902) is checked and the minimumqueue size is calculated When the queue estimation timer 119879119890expires the persistent queue length is equal to the minimumqueue value over the last 119879119890 interval For obtaining theduration of the 119879119890 interval the capacity value of rt-Winf isused

119879119890 = max(119902 (119879RTT minus119902

119862winf2)) (24)

ComparingXCP-Winf with XCP it is possible to concludethat both use the same principles but differ in the way linkcapacity and available bandwidth are obtained and used

42 RCP-Winf Functions RCP-Winf updates RCP oper-ations using rt-Winf link capacity values A RCP-WinfReceiver operates in the same way as a standard RCPReceiver The RCP-Winf Receiver just updates the RCPcongestion header with the bottleneck rate that is the rate ofthe most congested link in the ACK packet and then sendsit to the sender

RCP-Winf relies only on link capacity evaluation andthere is no need for determining the aggregate feedback(119865) thus there is also no need for explicitly using theavailable bandwidth A RCP-Winf implementation also keepsunchanged the standard operations performed by RCProuters when a packet arrives and departs

When operating as a sender RCP-Winf needs to performoperations that allow it to modulate the congestion windowThe RCP-Winf Sender will evaluate the desired changein throughput 119862desired through the value obtained in theACK packet congestion header field and the link capacityobtained by the rt-Winf gathered through the cross layercommunication process

119862winf minus 119862desired le 0 (25)

According to this evaluation RCP-Winfwill update or notthe desired change in throughput If the evaluation returnsa negative value the 119862desired value will be updated to the119862winf valueThen itmodulates the sender congestionwindow(CWSender)

CWSender =119862desired times 119879RTT119872+119867RCP + 119867IP

(26)

where 119867RCP is the RCP header size (12 bytes) and 119867IP is theIP header size Then it calculates the pacing interval (119879pacing)that will be used to send packets from the queue

119879pacing =119872

119862desired (27)

When the rate timer of a RCP-Winf router expires thenode first gets the rt-Winf capacity values Then it assumesthat the aggregate incoming traffic rate is defined by thert-Winf capacity value (119862winf) Next it obtains the averageround-trip time of the traffic that has arrived in the rateestimation interval (119879119890) After that the node updates the RTTestimate (119879RTT) and then it updates the rate value that will beoffered to the flows (119877) using the rt-Winf capacity

119877 = 119877

times ( 1+ [((119879119890

119879RTT)

times(120572 times (119862119908 times 119862winf minus 119862winf) minus 120573 times119902

119879RTT))

times (119862119908 times 119862winf)minus1])

(28)


The node tests the rate value and updates itThe rate valuecannot be under a minimum rate value (119877min) or above aweighted (119862119908) link capacity value

if (119877 lt 119877min) 997904rArr 119877 = 119877min

else if (119877 gt 119862119908 times 119862winf) 997904rArr 119877 = 119862119908 times 119862winf(29)

Then the node decides the length of the next rateestimation interval Before finishing the node resets thevariables and restarts the timer 119862119908 controls the target link-utilization and can be any value in the range 095 lt 119862119908 lt 1It is important to choose a value less than 1 as it allows somecomfort to drain excess traffic before building up a queueIn extreme congestion scenarios the minimum rate valueallowed (119877min) is considered to be

119877min =(001 timesMTU)

119879RTT (30)

where MTU is the maximum transmission unit The result ofthe operation will be the value of the minimum rate

A RCP-Winf router also has to perform per-packetoperations namely when a packet arrives and when a packetdeparts Whenever a packet arrives carrying a valid round-trip time its value is added to the stored sum of RTTs andthe number of packets carrying a valid RTT is incrementedThis allows for amore precise calculation of the average RTTsThis is also the normal operation of a RCP standard systemRCP-Winf router uses the obtained values of rt-Winf as theirunderlying value When a packet requests an unspecifiedvalue or a value that exceeds the link capacity the system isupdated with the rt-Winf obtained capacity value that is

119862desired = 119862winf (31)

5 Simulation Results

This section introduces the simulation setup to evaluate theperformance of the proposed congestion controlmechanismsand the simulation results The results are obtained usingthe ns-2 [33] simulator To evaluate the performance threemetrics are used throughput delay and number of receivedpackets The proposed control mechanisms XCP-Winf andRCP-Winf are evaluated against the base protocols TCPXCP and RCP and against the XCP-b and TCP-AP protocolswhich are especially developed for wireless networks

Different wireless mesh and ad hoc scenarios were usedThe parameters of the simulations are presented in Table 4The configured default transmission range is 250 meters thedefault interference range is 500meters and the channel datarate is 11Mbps For the data transmissions an FTP applicationwith packets of 1500 bytes or a constant bit rate (CBR)application is used The mobility is emulated through the ns-2 setdest tool to provide a random node movement patternWe configure setdest with a minimum speed of 10ms amaximum speed of 30ms and a topology boundary of 1000times 1000 meters All results were obtained from ns-2 tracefiles with the help of trace2stats scripts [38] adapted to our

Mesh 0 Mesh 3

Mesh 4

Mesh 1 Mesh 2

Mobile 0

Mobile 3

Mobile 1

Mobile 2

Mobile 4

Figure 8 Topology of 5 mesh nodes 5 mobile nodes

Table 4 Simulation environment

Simulation parametersTopology area 1000m times 1000mSimulation time 300 secSimulation repetition 30 timesAd hoc scenario number of mobile nodes 8 16 32 64 128 256Mesh scenario number of mobile nodes 3 4 5 6 7Mesh scenario number of mesh fixed nodes 5 9 12 16Mesh nodes position RandomPath loss model Two-rayMobility model Random way pointMaximum movement speed 30msMac layer IEEE 80211Propagation model Two-ray groundRouting protocol DSDV

own needs The routing protocol used was the destination-sequence distance-vector (DSDV) [39]The presented resultsshow the mean values obtained through different simulationruns with different seeds and the 95 confidence interval

51 Mesh and Ad Hoc Scenarios Results Next we presentanalyze and compare the results of the congestion controlapproaches in the mesh topology scenario The mesh topolo-gies defined comprise a grid of 5 9 12 and 16 fixed meshnodes In all mesh topologies a combination of 3 4 56 and 7 mobile nodes is used Figure 8 represents a meshtopology of 5 mesh nodes and 5 mobile nodes The mobilenodes are simultaneously sources and sinksThe results showthroughput delay and the number of received packets

Figures 9(a) 9(b) and 9(c) show the previously referredperformance metrics for five different scenarios In eachscenario a fixed number of 16 mesh nodes and a variable


0100

200300400500600700800900

3 35 4 45 5 55 6 65 7

Thro

ughp

ut (k

bps)

Number of mobile nodes

TCP avg throughputXCP avg throughputRCP avg throughputXCP-Winf avg throughput

RCP-Winf avg throughputXCP-b avg throughputTCP-AP avg throughput

(a) Throughput

10

100

1000

10000

100000

3 35 4 45 5 55 6 65 7

Del

ay (m

s)


TCP avg delayXCP avg delayRCP avg delayXCP-Winf avg delay

RCP-Winf avg delayXCP-b avg delayTCP-AP avg delay

(b) Delay

0

2000

4000

6000

8000

10000

12000

14000

3 35 4 45 5 55 6 65 7

Num

ber o

f pac

kets


TCP avg recv packetsXCP avg recv packetsRCP avg recv packetsXCP-Winf avg recv packets

RCP-Winf avg recv packetsXCP-b avg recv packetsTCP-AP avg recv packets

(c) Received packets

Figure 9 Mesh scenario 16 mesh nodes variable number of mobile nodes

number from 3 to 7 of mobile nodes were used Each mobilenode as previously stated is simultaneously sending andreceiving data

The obtained results show that the integration of rt-Winfin XCP and RCP improves significantly their behavior whichmakes XCP and RCP behave more efficiently and with betterchannel utilization which also leads to less channel losses(more received packets) The use of rt-Winf in the meshnodes (Onlooker state) makes the feedback mechanismmoreaccurate as all nodes in the network can determine availablebandwidth and capacity and send that information to theother nodes that are participating in the communicationBoth XCP-b and TCP-AP have better results than TCP andstandard XCP and RCP However they are outperformedby both XCP-Winf and RCP-Winf TCP-AP is the mostconservative one and obtains worse results on the number ofreceived packets XCP-b relies on the maximum buffer size

of nodes and therefore with the current scenario conditionsXCP-b is less efficient and less accurate than both XCP-Winfand RCP-Winf

To evaluate XCP-Winf and RCP-Winf when using CBRapplications an UDP application (simulating a VoIP applica-tion) is configured for the 16 mesh nodes scenario and vari-able number of mobile nodes Figure 10 shows the obtainedresults Without rt-Winf enabled XCP obtains better resultsthan RCP for a lower number of mobile nodes This isdue to the fact that RCP was developed having in mindInternet bursts traffic With less mobile nodes exchanginginformation the number of collisions is lower and lessretransmissions and burst traffic are present in the networkIt is also possible to conclude that both XCP and RCP arenot evaluating correctly the link capacity and do not have thenecessary mechanisms to overcome this situation With rt-Winf the throughput results are considerably betterHowever


0

100

200

300

400

500

3 35 4 45 5 55 6 65 7

Thro

ughp

ut (k

bps)


XCP avg throughputRCP avg throughputXCP-Winf avg throughput


Figure 10 CBR throughput in mesh scenario 16 mesh nodesvariable number of mobile nodes

it can be seen that XCP and RCP have lower performance incontrolling congestion when the traffic is UDP

Once more RCP-Winf reflects its base development forbursty traffic The CBR application is sending data at aconstant rate with more mobile nodes sending data morecollisions will occur and more bursts of traffic will bepresent in the networkThis situation will allow RCP to reactmore precisely and with more mobile nodes to have betterthroughput resultsThe results also show that XCP-b is bettersuited when the number of mobile nodes is small The resultsshow that TCP-AP though specially developed for wirelessenvironments has very poor results This is because a TCP-AP sender adapts its transmission rate using an estimate ofthe 4-hop propagation delay and the coefficient of variationof recently measured round-trip timesThis means that TCP-AP is very conservative not using efficiently the medium

The congestion control approaches are also evaluatedin ad hoc scenarios using CBR UDP 64Kbps flows Thescenarios are composed of 8 16 32 64 128 and 256 nodesand for each scenario there are 4 8 16 32 64 and 128 simul-taneous flows The flows are randomly generated throughthe ns-2 gencbrtcl tool The mobility was also dynamicallygenerated through different seed values The obtained resultsare presented in Figures 11(a) 11(b) and 11(c)

From the obtained results it is possible to conclude thatstandard XCP and RCP have the same behavior when thetraffic is UDP however the integration of rt-Winf makesthem react differently as they both use the information fromthe MAC sublayer in a different way It is also possible tosee that with rt-Winf integrated both XCP and RCP canreceive more packets which reflects a lower rate of lostpackets This is due to the fact that XCP-Winf and RCP-Winf with accurate link capacity and available bandwidthare using more efficiently the medium and improving eachnode queue management As more packets are transmittedmore throughput is obtained and the medium is better usedit is possible to infer that both XCP-Winf and RCP-Winf are

more stable and fair In the same conditions it is possibleto send more information with a higher rate It must benoticed that the results also reflect the mobility randomnesswhere more nodes are in each otherrsquos influence area Anotherfactor that is influencing the results is the routing informationand the exchanged routing messages as flows increase thecollisions and delay also increase which is also reflected inthroughput values Once more XCP-b obtains good resultswhen the network is not heavily utilized where XCP-bincreases its available bandwidth and consequently its rateHowever with more nodes and flows in the network XCP-bbehavior is less efficient due to the higher number of lossesreducing the flow rate With respect to TCP-AP its behavioris also degraded as the number of flows increases while thethroughput results are improved they are obtained with lessreceived packets

52 Building Scenario Results For a more real evaluationwe defined a new mesh network scenario to simulate apublic building with public services and a public garden(Figure 12) According to Table 4 the different parameters arethe following the numbers ofmobile nodes are 10 20 and 30the fixed mesh nodes are 6 and two different flows are usedIn this scenario mobile nodes start to transmit in a randomway and their transmission lasts 240 secondsThemeshnodesposition is randomly defined in the inside area A randomlychosen mesh node is shut down for 100 seconds during thesimulation period Two types of flows are used to represent alight traffic flow (4 CBR 64Kbps flows sent each 400ms) anda heavy traffic flow (4 CBR 128Kbps flows sent each 100ms)

The obtained results of the light traffic flows are shown inFigures 13(a) 13(b) and 13(c) the results of the heavy trafficflows are presented in Figures 14(a) 14(b) and 14(c) As can beobserved from the results the integration of rt-Winf in bothXCP and RCP improves their standard behavior Since thenodes that are not participating in the communication enterthe Onlooker state and evaluate the network performance itis possible to have a state by state and rate by rate overallperformance evaluation As rt-Winf uses three different statesand network cooperation it is possible to have a moreeffective and efficient hop by hop performance evaluationThis results in a more efficient evaluation and use of thechannel capacity As XCP-Winf and RCP-Winf also havemore capability to adapt to the changing conditions of thenetwork this is expressed in better transmitting rates andbetter channel usage XCP-b has again poor performance forhigh load scenarios XCP-b is not taking into considerationpacket loss considering packet loss as a buffer overflowthus having a more inefficient behavior and introducingunnecessary capacity slowdowns on the network TCP-APpresents good overall results However it obtains thoseresults with a considerable reduction in received packetswhich indicates that TCP-AP is more conservative and is notefficiently using the medium

53 Utility Results As TCP is the most used and deployedcongestion control protocol on the Internet it is important (asdescribed in [40]) to analyze how XCP-Winf and RCP-Winf

14 Journal of Computer Networks and CommunicationsTh

roug

hput

(kbp

s)

Number of simultaneous flows

0

50

100

150

200

250

300

0 20 40 60 80 100 140120



(a) Throughput


0

20

40

60

80

100

120

140

0 20 40 60 80 100 120 140

Del

ay (m

s)

XCP avg delayRCP avg delayXCP-Winf avg delay

RCP-Winf avg delayXCP-b avg recv packetsTCP-AP avg recv packets

(b) Delay

Number of simultaneous flows0 20 40 60 80 100 120 140

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

Num

ber o

f pac

kets

XCP avg recv packetsRCP avg recv packetsXCP-Winf avg recv packets



Figure 11 Ad hoc scenario variable number of flows

200m

150m

400m

400m

50m

Figure 12 Building layout simulation

flows interact and competewithTCP For this purpose we usethe average data rate over time for each flow thus allowing

observing how bandwidth is being managed between TCPand the winf proposals This is called utility of a networkingprotocol

Two scenarios were defined one using XCP-Winf andTCP and the other using RCP-Winf and TCP The twoscenarios consist of a 1000m times 1000m area divided intothree distinct parts an area of 250m times 250m where thereare two mobile node sources one with TCP and the otherwith XCP-Winf or RCP-Winf amiddle area of 500m times 500mwith twomobile nodes with the rt-Winf mechanism activated(the average data rate is measured on these two nodes asthey will have TCP and winf -like flows competing) finallyanother area of 250m times 250m for the mobile nodes sinksEach source generates two FTP flows with packets of 1500bytes The simulation lasts for 120 seconds

Figures 15(a) and 15(b) show the obtained results It ispossible to observe that on both situations TCP flow growsfaster and gains more bandwidth on the beginning this is


500

600

700

800

900

1000

1100

1200

1300

10 15 20 25 30

Thro

ughp

ut (k

bps)




(a) Light flow throughput

50

100

150

200

250

300

350

10 15 20 25 30

Del

ay (m

s)




(b) Light flow delay

8000

10000

12000

14000

16000

18000

20000

22000

24000

10 15 20 25 30

Num

ber o

f pac

kets


XCP avg recv packetsRCP recv packetsXCP-Winf recv packets

RCP-Winf recv packetsXCP-b avg recv packetsTCP-AP avg recv packets

(c) Light flow received packets

Figure 13 Public building light flow variable number of mobile nodes

because TCPrsquos congestion mechanisms are not evaluatingcorrectly the network status (TCP is trying to fill the nodesqueues expecting that packet loss due to queue overflow willindicate congestion) However RCP-Winf and XCP-Winf areevaluating and measuring consistently how the network isbehaving and adjusting the bandwidth requirements to thatinformation As RCP-Winf is based on RCP with its burstytraffic development it has a more unstable behavior duringthe initial instant of the simulation as more traffic is presenton the network RCP-Winf becomes more stable

The results also show that thewinf mechanisms are TCP-friendly on the long term and are adjusting to the unfairnessnature of TCP XCP-Winf reacts earlier to these constraintsand starts to compete for the same bandwidth as TCP earlierthan RCP-Winf However it must be noticed that the resultsshow that both RCP-Winf and XCP-Winf take some time toallow a fair share of bandwidth between their native flows and

TCP It is advisable that this fair share is obtained as quickly aspossible thus allowing a more efficient share and coexistenceof network resources

6 Conclusions

In this paper we presented a study that demonstrates thatusing MAC layer information in congestion control througha cross layer communication process can be an importantfactor of network performance improvementThisMAC layerinformation resorts to CTSRTSACK messages handshakeor on small probes to know each nodersquos channel allocationand it allows accurate determining of the links capacityand available bandwidth This information is then used bycongestion control mechanisms based on explicit congestionnotifications XCP and RCP to accurately determine thenetwork status and act accordingly


600

700

800

900

1000

1100

1200

1300

1400

10 15 20 25 30

Thro

ughp

ut (k

bps)




(a) Heavy flow throughput


0

50

100

150

200

250

300

10 15 20 25 30

Del

ay (m

s)



(b) Heavy flow delay

10000

12000

14000

16000

18000

20000

22000

24000

26000

28000

10 15 20 25 30

Num

ber o

f pac

kets




(c) Heavy flow received packets

Figure 14 Public building heavy flow variable number of mobile nodes

The evaluation results of XCP-Winf and RCP-Winfobtained through ns-2 simulations show that the rt-Winfalgorithm improves significantly XCP and RCP behaviormaking themmore efficient and stable To obtain the availablenetwork capacity both XCP and RCP need all nodes in thenetwork to cooperate which increases network overheadspecially when dealing with special wireless environmentssuch as wireless mesh networks and ad hoc networks Usingrt-Winf which works in the MAC layer it is possible toperform link capacity and available bandwidth calculationswithout interfering in the network dynamics allowing signif-icant improvement of XCP and RCP performance It was alsopossible to conclude that XCP-Winf and RCP-Winf behavemore efficiently and use the network available informationmore effectively than XCP-b and TCP-AP two protocolsspecifically designed for wireless environments It is thenpossible to conclude that both XCP-Winf and RCP-Winfoutperform XCP-b and TCP-AP in terms of medium usage

thus allowing amore stable behavior and a faster convergenceto the active network conditions

As future work we plan to extend the evaluation withthe analysis of the effect of collision probability and theimprovement of the results when introducing this effect onthe congestion control approaches and also to work on theimprovement of XCP-Winf and RCP-Winf utility resultsallowing having a much more efficient coexistence with TCPflows with the rt-Winf versions of XCP and RCP An effortwill also be made in optimizing other protocols behaviorsuch as TCP-AP with the integration of rt-Winf real timeand in-line information As this work presents mainly resultsobtained through simulation evaluation future work mightalso involve exploring the implementation of the proposedsolutions against other routing protocols and also implementthem directly in the Linux Kernel allowing creating a smalltestbed for testing and evaluating the solutions in realenvironments and in different conditions


0

500

1000

1500

2000

2500

3000

3500

4000

4500

0 20 40 60 80 100 120

Avg

rate

(kbp

s)

Time (s)

XCP-Winf TCP

(a) XCP-Winf utility results

0

1000

2000

3000

4000

5000

0 20 40 60 80 100 120

Avg

rate

(kbp

s)

Time (s)

RCP-Winf TCP

(b) RCP-Winf utility results

Figure 15 Utility results

Conflict of Interests

The author declares that there is no conflict of interestsregarding the publication of this paper

References

[1] S Vangala and M A Labrador ldquoPerformance of TCP overwireless networks with the Snoop protocolrdquo in Proceedings ofthe 27th Annual IEEE Conference on Local Computer Networks(LCN rsquo02) pp 600ndash601 November 2002

[2] H Balakrishnan VN Padmanabhan S Seshan andRH KatzldquoA comparison ofmechanisms for improving TCP performanceoverwireless linksrdquo IEEEACMTransactions onNetworking vol5 no 6 pp 756ndash769 1997

[3] D Katabi M Handley and C Rohrs ldquoCongestion controlfor high bandwidth-delay product networksrdquo in Proceedings ofthe Conference on Applications Technologies Architectures andProtocols for Computer Communications (SIGCOMM rsquo02) pp89ndash102 ACM August 2002

[4] N Dukkipati and N McKeown ldquoWhy flow-completion timeis the right metric for congestion controlrdquo ACM SIGCOMMComputer Communication Review vol 36 no 1 pp 59ndash622006

[5] L Barreto and S Sargento ldquoTCPXCP andRCP inwirelessmeshnetworks an evaluation studyrdquo in Proceedings of the 15th IEEESymposium on Computers and Communications (ISCC rsquo10) pp351ndash357 Riccione Italy June 2010

[6] B Res L Barreto and S Sargento ldquort-Winf real time wirelessinference mechanismrdquo in Proceedings of the IEEE GlobecomWorkshop on Mobile Computing and Emerging Communica-tion Networks (MCECN rsquo10) pp 1130ndash1135 Miami Fla USADecember 2010

[7] H K Lee V Hall K H Yum K Kim III and E J Kim ldquoBand-width estimation in wireless lans for multimedia streamingservicesrdquo Advances in Multimedia vol 2007 Article ID 704297 pages 2007

[8] L Barreto and S Sargento ldquoXCP-winf and RCP-winf conges-tion control techniques for wirelessmesh networksrdquo in Proceed-ings of the IEEE International Conference on Communications(ICC rsquo11) Kyoto Japan June 2011

[9] CMUWireless Emulator httpwwwcscmuedusimemulator[10] F Abrantes and M Ricardo ldquoA simulation study of XCP-b

performance in wireless multi-hop networksrdquo in Proceedings ofthe 3rd ACM Workshop on QoS and Security for Wireless andMobile Networks (Q2SWinet rsquo07) pp 23ndash30 ACM 2007

[11] S M ElRakabawy A Klemm and C Lindemann ldquoTCP withadaptive pacing for multihop wireless networksrdquo in Proceedingsof the 6th ACM International Symposium on Mobile Ad HocNetworking and Computing (MOBIHOC rsquo05) pp 288ndash299ACM May 2005

[12] L-J Chen T Sun G YangM Y Sanadidi andMGerlaAdHocProbe Path Capacity Probing in Wireless Ad Hoc Networks vol15 Kluwer Academic 2009

[13] M Li M Claypool and R Kinicki ldquoWBest a bandwidth esti-mation tool for IEEE 80211 wireless networksrdquo in Proceedingsof the 33rd IEEE Conference on Local Computer Networks (LCNrsquo08) pp 374ndash381 October 2008

[14] L-J Chen C-W Sung H-H Hung T Sun and C-F ChouldquoTSProbe a link capacity estimation tool for time-slottedwireless networksrdquo inProceedings of the 4th IEEE and IFIP Inter-national Conference on Wireless and Optical CommunicationsNetworks (WOCN rsquo07) pp 1ndash5 July 2007

[15] M S Gast 80211 Wireless NetworksmdashThe Definitive GuideOrsquoreilly 4th edition 2002

[16] J Postel ldquoTransmission Control Protocolrdquo RFC 793 1981[17] B A Fourouzan TCPIP Protocol Suite McGraw-Hill Higher

Education 2nd edition 2002[18] K Chandran S Raghunathan S Venkatesan and R Prakash

ldquoA feedback-based scheme for improving TCP performance inad hoc wireless networksrdquo IEEE Personal Communications vol8 no 1 pp 34ndash39 2001

[19] G Holland and N Vaidya ldquoAnalysis of TCP performance overmobile ad hoc networksrdquo in Proceedings of the 5th Annual


ACMIEEE International Conference on Mobile Computing andNetworking (MobiCom rsquo99) ACM New York NY USA 1999

[20] D Kim C-K Toh and Y Choi ldquoTCP-BuS improving TCPperformance in wireless ad hoc networksrdquo in Proceedings of theIEEE International Conference on Communications (ICC rsquo00)vol 3 pp 1707ndash1713 2000

[21] J Liu and S Singh ldquoATCP TCP for mobile ad hoc networksrdquoIEEE Journal on Selected Areas in Communications vol 19 no7 pp 1300ndash1315 2001

[22] S Rangwala A Jindal K-Y Jang K Psounis and R GovindanldquoUnderstanding congestion control in multi-hop wireless meshnetworksrdquo in Proceedings of the 14th Annual InternationalConference on Mobile Computing and Networking (MobiComrsquo08) pp 291ndash302 ACM September 2008

[23] A Jindal and K Psounis ldquoAchievable rate region and optimalityof multi-hop wireless 80211-scheduled networksrdquo in Proceed-ings of the Information Theory and Applications Workshop pp263ndash269 February 2008

[24] C L T Man G Hasegawa and M Murata ldquoImTCP TCP withan inline measurement mechanism for available bandwidthrdquoComputer Communications vol 29 no 10 pp 1614ndash1626 2006

[25] G Anastasi E Ancillotti M Conti and A Passarella ldquoTPAa transport protocol for ad hoc networksrdquo in Proceedings ofthe 10th IEEE Symposium on Computers and Communications(ISCC rsquo05) pp 51ndash56 June 2005

[26] C D A Cordeiro S R Das and D P Agrawal ldquoCOPASdynamic cont ention-balancing to enhance the performance ofTCP over multi-hop wireless networksrdquo in Proceedings of the11th International Conference onComputer Communications andNetworks pp 382ndash387 Miami Fla USA October 2002

[27] Z Fu H Luo P Zerfos S Lu L Zhang and M Gerla ldquoTheimpact of multihop wireless channel on TCP performancerdquoIEEE Transactions on Mobile Computing vol 4 no 2 pp 209ndash221 2005

[28] K Tan F Jiang Q Zhang and X Shen ldquoCongestion controlin multihop wireless networksrdquo IEEE Transactions on VehicularTechnology vol 56 no 2 pp 863ndash873 2007

[29] Y Su andT Gross ldquoWXCP explicit congestion control for wire-less multi-hop networksrdquo in Quality of ServicemdashIWQoS 2005Proceedings of the 13th International Workshop IWQoS 2005Passau Germany June 21ndash23 2005 vol 3552 of Lecture Notes inComputer Science pp 313ndash326 Springer BerlinGermany 2005

[30] A Sridharan and B Krishnamachari ldquoExplicit and precise ratecontrol for wireless sensor networksrdquo in Proceedings of the7th ACM Conference on Embedded Networked Sensor Systems(SenSys rsquo09) pp 29ndash42 ACM November 2009

[31] IEEE Computer Society ldquoIEEE Std 80211mdashIEEE Standardfor information technologymdashtelecommunications and infor-mation exchange between systemsmdashlocal and metropolitanarea networksmdashspecific requirements Part 11 wireless LANmedium access control (MAC) and physical layer (PHY) spec-ificationsrdquo IEEE Standard 80211-2007 2007

[32] Recommendation ITU-T G7110 2005 httpwwwituintrecT-REC-G711

[33] ldquoThe network simulatormdashns-2rdquo 2001 httpwwwisiedunsnamns

[34] Z Ilic A Bazant I Colak and D Jaksic ldquoOptimal MAC packetsize in wireless LANrdquo in Proceedings of the 28th InternationalConvention MIPRO 2005 Web Services XML and Applicationof XML Technology pp 290ndash293 Croatian Association forInformation and Communication Technology Electronics andMicroelectronics Rijeka Croatia 2005

[35] IPerf httpsiperffr[36] M Proebster M Scharf and S Hauger ldquoPerformance com-

parison of router assisted congestion control protocols XCPvs RCPrdquo in Proceedings of the 2nd International Conference onSimulation Tools and Techniques (Simutools rsquo09) pp 881ndash888ICST (Institute for Computer Sciences Social-Informatics andT elecommunications Engineering) Rome Italy March 2009

[37] M Conti G Maselli G Turi and S Giordano ldquoCross-layeringin mobile ad hoc network designrdquo Computer vol 37 no 2 pp48ndash51 2004

[38] M Fiore trace2stats httppersocitiinsa-lyonfrmfiorere-searchhtml

[39] C E Perkins and P Bhagwat ldquoHighly dynamic destination-sequenced distance-vector routing (DSDV) formobile comput-ersrdquo ACM SIGCOMM Computer Communication Review vol24 no 4 pp 234ndash244 1994

[40] J Feng and L Xu ldquoTCP-friendly CBR-like rate controlrdquo inProceedings of the IEEE International Conference on NetworkProtocols (ICNP rsquo08) pp 177ndash186 October 2008

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014


Active and Passive Electronic Components

Control Scienceand Engineering

Journal of



RotatingMachinery


Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design



Shock and Vibration


Civil EngineeringAdvances in

Acoustics and VibrationAdvances in



Electrical and Computer Engineering

Journal of

Advances inOptoElectronics


Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of


Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014


Chemical EngineeringInternational Journal of Antennas and

Propagation




Navigation and Observation



DistributedSensor Networks



capacity among multiple competing applications Factorssuch as handoffs channel allocation and channel quality aredirectly related to link capacity Being able to accuratelymon-itor link capacity and available bandwidth and then use thatinformation to perform accurate congestion control is a mainchallenge inwireless communications In [6]we proposed thert-Winf algorithm which is a new wireless inference mecha-nism based on IdleGap [7] that is able to estimate availablebandwidth and path capacity rt-Winf uses the informationincluded in RTSCTS packets to measure the transmissiontime and obtain the link capacity and available bandwidth

In this paper we describe XCP-Winf and RCP-Winf twonew congestion control mechanisms based respectively onXCP and RCP that are extended with the support of anaccurate capacity and available bandwidth computation algo-rithm The link capacity and available bandwidth obtainedthrough rt-Winf are transmitted through cross layer tech-niques to XCP and RCP that use that information in theirnative congestion control techniques We show how newXCP-Winf andRCP-Winf functions can be built with this newinformation The proposed congestion control approachesare evaluated in different simulated scenarios mesh and adhoc and are evaluated against state-of-the-art congestioncontrol mechanismsThe obtained results show that the inte-gration of rt-Winf allows clear improvement of XCP and RCPnetwork performance against standard congestion controlprotocols and also against specific congestion protocols forwireless environments

In [8] we presented a base version of both XCP-Winf andRCP-Winf with preliminary results In this paper we presenta complete proposal (1) we present the rt-Winf approachwith an evaluation through simulation and emulation inCMU wireless emulator [9] (2) we describe and refine theconceptual approach of both XCP-Winf and RCP-Winf witha new mathematical model (3) we perform a completeevaluation of the congestion control approaches comparedagainst state-of-the-art approaches such as XCP-b [10] andTCP-AP (TCPwith adaptive pacing) [11] (4)we complete theevaluation with the assessment of both XCP-Winf and RCP-Winf in terms of TCP-friendliness

The remaining of this paper is organized as followsNext section Section 2 briefly presents the background andrelated workThen Section 3 describes the rt-Winf algorithmand rt-Winf obtained results In Section 4 how rt-Winf isintegrated within both XCP and RCP is presented Section 5describes and discusses the results obtained through sim-ulation using mesh and ad hoc scenarios with differentcharacteristics Finally Section 6 presents the conclusionsand future work

2 Related Work

21 Capacity and Available Bandwidth Estimation AdHocProbe [12] WBest [13] TSProbe [14] and IdleGap [7] aresome examples of link estimation mechanisms for wirelessnetworksWhileWBest calculates both capacity and availablebandwidth AdHoc Probe provides only the path capacity ofthe wireless channel However WBest is known to be very

intrusive when estimating the available bandwidth TSProbe[14] is a new capacity estimation tool based on AdHocProbe but it is focused on time-slotted connections such asbluetooth or WIMAX TSProbe uses the interaction betweenseveral link layer properties to deploy an adaptive probingscheme that utilizes payloads that vary in sizeWhile accuratein time-slotted connections it lacks efficiency in dynamicwireless environments

IdleGap takes into consideration the CSMA collisionavoidance (CSMA-CA) schemeofwireless networks to obtainits available bandwidth The idle nodes which are waiting totransmit use the network allocation vector (NAV) [15] whichshows how long other nodes allocate the link in the IEEE80211 MAC protocol The idle time in the wireless networkcan then be estimated from the NAV information

All the presented mechanisms were defined with themain purpose of only estimating available bandwidth andlink capacity in specific network conditions Some mecha-nisms can only estimate available bandwidth and others onlyestimate link capacity In a wireless network environmentit is important to have a tool that can retrieve an accurateestimation of the busy time and the total elapsed timebetween communications It is also important to have amechanism that uses not only source information but alsoreceiver information as this is the only way to have a precisenetwork status It is therefore important to introduce theconcept of network cooperation in network estimation toolsAnother important issue is the effective calculation of theactual data rate that is used by each communication process

22 Congestion Control The transmission control protocol(TCP) [16] is the most used congestion control protocol incomputer networks However TCP assumes that the proba-bility of a lost packet is higher than the one of a corruptedpacket [17] which is not true in wireless networks Severalcongestion control mechanisms were proposed to enhanceTCPrsquos behavior in a wireless environment Mechanisms likeTCP-F [18] TCP-ELFN [19] TCP-BuS [20] and ATCP [21]represent some examples of protocols for wireless networksin generalThey concentrate on improving TCPrsquos throughputby freezing TCPrsquos congestion control algorithm during link-failure induced losses especially when route changes occurThese TCP developments differ in themanner inwhich lossesare identified and notified to the sender and in their detailsof freezing TCPrsquos congestion control algorithm Even thoughthese schemes do not recognize the need of congestiondetection and signaling over a neighborhood their conges-tion metric implicitly takes some degree of neighborhoodcongestion into account

WCP [22] and WCPCap [22] are congestion controlmechanisms developed for wireless mesh networks WCP isAIMDbased and for every flow the sourcemaintains a rate119877which represents the long term sending rate for the flowThemain issue of WCP is that it does not correctly evaluate theavailable rate making an assumption that all links have equalrate WCPCap estimates the available capacity within eachneighborhood and distributes this capacity to contendingflows using a distributed rate controller Available capacity in









3 rt-Winf






Onlooker

Captured RTS packet

119862Onlooker =119878


Yes


119879Total)

No


119879Total)



119878




119878




119862Sender =119878






) (3)



119862Receiver =119878




) (5)



119862Onlooker =119878




) (7)



) (8)





UpdatesCOnlooker

No DATA to transmit


No RTS

Receives CTS




Receives RTS

Receiver

Updates

Stores TRTS

Sends CTS

Receives DATA



(



2

3

4

5

1

2

3

4

5

1

0 COnlooker




Sender Onlooker









(9)








(10)





(11)





119862 =119878

119879Transfer (12)




119879Total) times 119862 (13)







(14)




0

2

4

6

8

10

0 50 100 150 200 250 300 350 400

Capa

city

(Mbp

s)

Time (s)

Maximum throughput

AdHoc Probert-Winf



















0

2

4

6

8

10

0 50 100 150 200 250 300 350 400

Capa

city

(Mbp

s)

Time (s)



0

2

4

6

8

10

12

0 50 100 150 200 250 300 350 400

Avai

labl

e ban

dwid

th

Time (s)


DataRateIPerf UDP



10000

9000

8000

7000

6000

5000

4000

3000

2000

1000

0

1 2 4 6 8

Number of flows

Capa

city

(kbp

s)







119862winf times (119879RTT119872) (15)



RetrieveXCPRCP

Transportlayer

rt-Winfmodule

Networklayer

MAClayer

Insert

Cross layershared

database



119894=119899

sum119894=1

THinverse =119878119894

119862winf119894 (16)


119894=119899

sum119894=1

Γ+ =119879RTT119894 times 119878119894

119862winf119894 (17)


119894=119899

sum119894=1

Γ+ =119879ci times 119878119894119862winf119894

(18)








119879RTT (19)




119901119891 =119862120593 +max (119865 0)

sumΨ

119899119891 =119862120593 +max (minus119865 0)

120601

(20)


119891119901 = 119901119891 times119878

119862winf (21)


119891119899 = 119899119891 times 119878 (22)


119862change = 119891119901 minus 119891119899 (23)



119879119890 = max(119902 (119879RTT minus119902

119862winf2)) (24)








(26)


119879pacing =119872

119862desired (27)


119877 = 119877

times ( 1+ [((119879119890

119879RTT)


119879RTT))


(28)



if (119877 lt 119877min) 997904rArr 119877 = 119877min




119879RTT (30)



119862desired = 119862winf (31)




Mesh 0 Mesh 3

Mesh 4

Mesh 1 Mesh 2

Mobile 0

Mobile 3

Mobile 1

Mobile 2

Mobile 4








0100

200300400500600700800900

3 35 4 45 5 55 6 65 7

Thro

ughp

ut (k

bps)




(a) Throughput

10

100

1000

10000

100000

3 35 4 45 5 55 6 65 7

Del

ay (m

s)




(b) Delay

0

2000

4000

6000

8000

10000

12000

14000

3 35 4 45 5 55 6 65 7

Num

ber o

f pac

kets











0

100

200

300

400

500

3 35 4 45 5 55 6 65 7

Thro

ughp

ut (k

bps)














roug

hput

(kbp

s)


0

50

100

150

200

250

300

0 20 40 60 80 100 140120



(a) Throughput


0

20

40

60

80

100

120

140

0 20 40 60 80 100 120 140

Del

ay (m

s)



(b) Delay


0

2000

4000

6000

8000

10000

12000

14000

16000

18000

Num

ber o

f pac

kets





200m

150m

400m

400m

50m







500

600

700

800

900

1000

1100

1200

1300

10 15 20 25 30

Thro

ughp

ut (k

bps)





50

100

150

200

250

300

350

10 15 20 25 30

Del

ay (m

s)





8000

10000

12000

14000

16000

18000

20000

22000

24000

10 15 20 25 30

Num

ber o

f pac

kets









6 Conclusions



600

700

800

900

1000

1100

1200

1300

1400

10 15 20 25 30

Thro

ughp

ut (k

bps)






0

50

100

150

200

250

300

10 15 20 25 30

Del

ay (m

s)




10000

12000

14000

16000

18000

20000

22000

24000

26000

28000

10 15 20 25 30

Num

ber o

f pac

kets










0

500

1000

1500

2000

2500

3000

3500

4000

4500

0 20 40 60 80 100 120

Avg

rate

(kbp

s)

Time (s)

XCP-Winf TCP


0

1000

2000

3000

4000

5000

0 20 40 60 80 100 120

Avg

rate

(kbp

s)

Time (s)

RCP-Winf TCP





References













































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation

















3 rt-Winf






Onlooker

Captured RTS packet

119862Onlooker =119878


Yes


119879Total)

No


119879Total)



119878




119878




119862Sender =119878






) (3)



119862Receiver =119878




) (5)



119862Onlooker =119878




) (7)



) (8)





UpdatesCOnlooker

No DATA to transmit


No RTS

Receives CTS




Receives RTS

Receiver

Updates

Stores TRTS

Sends CTS

Receives DATA



(



2

3

4

5

1

2

3

4

5

1

0 COnlooker




Sender Onlooker









(9)








(10)





(11)





119862 =119878

119879Transfer (12)




119879Total) times 119862 (13)







(14)




0

2

4

6

8

10

0 50 100 150 200 250 300 350 400

Capa

city

(Mbp

s)

Time (s)

Maximum throughput

AdHoc Probert-Winf



















0

2

4

6

8

10

0 50 100 150 200 250 300 350 400

Capa

city

(Mbp

s)

Time (s)



0

2

4

6

8

10

12

0 50 100 150 200 250 300 350 400

Avai

labl

e ban

dwid

th

Time (s)


DataRateIPerf UDP



10000

9000

8000

7000

6000

5000

4000

3000

2000

1000

0

1 2 4 6 8

Number of flows

Capa

city

(kbp

s)







119862winf times (119879RTT119872) (15)



RetrieveXCPRCP

Transportlayer

rt-Winfmodule

Networklayer

MAClayer

Insert

Cross layershared

database



119894=119899

sum119894=1

THinverse =119878119894

119862winf119894 (16)


119894=119899

sum119894=1

Γ+ =119879RTT119894 times 119878119894

119862winf119894 (17)


119894=119899

sum119894=1

Γ+ =119879ci times 119878119894119862winf119894

(18)








119879RTT (19)




119901119891 =119862120593 +max (119865 0)

sumΨ

119899119891 =119862120593 +max (minus119865 0)

120601

(20)


119891119901 = 119901119891 times119878

119862winf (21)


119891119899 = 119899119891 times 119878 (22)


119862change = 119891119901 minus 119891119899 (23)



119879119890 = max(119902 (119879RTT minus119902

119862winf2)) (24)








(26)


119879pacing =119872

119862desired (27)


119877 = 119877

times ( 1+ [((119879119890

119879RTT)


119879RTT))


(28)



if (119877 lt 119877min) 997904rArr 119877 = 119877min




119879RTT (30)



119862desired = 119862winf (31)




Mesh 0 Mesh 3

Mesh 4

Mesh 1 Mesh 2

Mobile 0

Mobile 3

Mobile 1

Mobile 2

Mobile 4








0100

200300400500600700800900

3 35 4 45 5 55 6 65 7

Thro

ughp

ut (k

bps)




(a) Throughput

10

100

1000

10000

100000

3 35 4 45 5 55 6 65 7

Del

ay (m

s)




(b) Delay

0

2000

4000

6000

8000

10000

12000

14000

3 35 4 45 5 55 6 65 7

Num

ber o

f pac

kets











0

100

200

300

400

500

3 35 4 45 5 55 6 65 7

Thro

ughp

ut (k

bps)














roug

hput

(kbp

s)


0

50

100

150

200

250

300

0 20 40 60 80 100 140120



(a) Throughput


0

20

40

60

80

100

120

140

0 20 40 60 80 100 120 140

Del

ay (m

s)



(b) Delay


0

2000

4000

6000

8000

10000

12000

14000

16000

18000

Num

ber o

f pac

kets





200m

150m

400m

400m

50m







500

600

700

800

900

1000

1100

1200

1300

10 15 20 25 30

Thro

ughp

ut (k

bps)





50

100

150

200

250

300

350

10 15 20 25 30

Del

ay (m

s)





8000

10000

12000

14000

16000

18000

20000

22000

24000

10 15 20 25 30

Num

ber o

f pac

kets









6 Conclusions



600

700

800

900

1000

1100

1200

1300

1400

10 15 20 25 30

Thro

ughp

ut (k

bps)






0

50

100

150

200

250

300

10 15 20 25 30

Del

ay (m

s)




10000

12000

14000

16000

18000

20000

22000

24000

26000

28000

10 15 20 25 30

Num

ber o

f pac

kets










0

500

1000

1500

2000

2500

3000

3500

4000

4500

0 20 40 60 80 100 120

Avg

rate

(kbp

s)

Time (s)

XCP-Winf TCP


0

1000

2000

3000

4000

5000

0 20 40 60 80 100 120

Avg

rate

(kbp

s)

Time (s)

RCP-Winf TCP





References













































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation












Onlooker

Captured RTS packet

119862Onlooker =119878


Yes


119879Total)

No


119879Total)



119878




119878




119862Sender =119878






) (3)



119862Receiver =119878




) (5)



119862Onlooker =119878




) (7)



) (8)





UpdatesCOnlooker

No DATA to transmit


No RTS

Receives CTS




Receives RTS

Receiver

Updates

Stores TRTS

Sends CTS

Receives DATA



(



2

3

4

5

1

2

3

4

5

1

0 COnlooker




Sender Onlooker









(9)








(10)





(11)





119862 =119878

119879Transfer (12)




119879Total) times 119862 (13)







(14)




0

2

4

6

8

10

0 50 100 150 200 250 300 350 400

Capa

city

(Mbp

s)

Time (s)

Maximum throughput

AdHoc Probert-Winf



















0

2

4

6

8

10

0 50 100 150 200 250 300 350 400

Capa

city

(Mbp

s)

Time (s)



0

2

4

6

8

10

12

0 50 100 150 200 250 300 350 400

Avai

labl

e ban

dwid

th

Time (s)


DataRateIPerf UDP



10000

9000

8000

7000

6000

5000

4000

3000

2000

1000

0

1 2 4 6 8

Number of flows

Capa

city

(kbp

s)







119862winf times (119879RTT119872) (15)



RetrieveXCPRCP

Transportlayer

rt-Winfmodule

Networklayer

MAClayer

Insert

Cross layershared

database



119894=119899

sum119894=1

THinverse =119878119894

119862winf119894 (16)


119894=119899

sum119894=1

Γ+ =119879RTT119894 times 119878119894

119862winf119894 (17)


119894=119899

sum119894=1

Γ+ =119879ci times 119878119894119862winf119894

(18)








119879RTT (19)




119901119891 =119862120593 +max (119865 0)

sumΨ

119899119891 =119862120593 +max (minus119865 0)

120601

(20)


119891119901 = 119901119891 times119878

119862winf (21)


119891119899 = 119899119891 times 119878 (22)


119862change = 119891119901 minus 119891119899 (23)



119879119890 = max(119902 (119879RTT minus119902

119862winf2)) (24)








(26)


119879pacing =119872

119862desired (27)


119877 = 119877

times ( 1+ [((119879119890

119879RTT)


119879RTT))


(28)



if (119877 lt 119877min) 997904rArr 119877 = 119877min




119879RTT (30)



119862desired = 119862winf (31)




Mesh 0 Mesh 3

Mesh 4

Mesh 1 Mesh 2

Mobile 0

Mobile 3

Mobile 1

Mobile 2

Mobile 4








0100

200300400500600700800900

3 35 4 45 5 55 6 65 7

Thro

ughp

ut (k

bps)




(a) Throughput

10

100

1000

10000

100000

3 35 4 45 5 55 6 65 7

Del

ay (m

s)




(b) Delay

0

2000

4000

6000

8000

10000

12000

14000

3 35 4 45 5 55 6 65 7

Num

ber o

f pac

kets











0

100

200

300

400

500

3 35 4 45 5 55 6 65 7

Thro

ughp

ut (k

bps)














roug

hput

(kbp

s)


0

50

100

150

200

250

300

0 20 40 60 80 100 140120



(a) Throughput


0

20

40

60

80

100

120

140

0 20 40 60 80 100 120 140

Del

ay (m

s)



(b) Delay


0

2000

4000

6000

8000

10000

12000

14000

16000

18000

Num

ber o

f pac

kets





200m

150m

400m

400m

50m







500

600

700

800

900

1000

1100

1200

1300

10 15 20 25 30

Thro

ughp

ut (k

bps)





50

100

150

200

250

300

350

10 15 20 25 30

Del

ay (m

s)





8000

10000

12000

14000

16000

18000

20000

22000

24000

10 15 20 25 30

Num

ber o

f pac

kets









6 Conclusions



600

700

800

900

1000

1100

1200

1300

1400

10 15 20 25 30

Thro

ughp

ut (k

bps)






0

50

100

150

200

250

300

10 15 20 25 30

Del

ay (m

s)




10000

12000

14000

16000

18000

20000

22000

24000

26000

28000

10 15 20 25 30

Num

ber o

f pac

kets










0

500

1000

1500

2000

2500

3000

3500

4000

4500

0 20 40 60 80 100 120

Avg

rate

(kbp

s)

Time (s)

XCP-Winf TCP


0

1000

2000

3000

4000

5000

0 20 40 60 80 100 120

Avg

rate

(kbp

s)

Time (s)

RCP-Winf TCP





References













































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation










UpdatesCOnlooker

No DATA to transmit


No RTS

Receives CTS




Receives RTS

Receiver

Updates

Stores TRTS

Sends CTS

Receives DATA



(



2

3

4

5

1

2

3

4

5

1

0 COnlooker




Sender Onlooker









(9)








(10)





(11)





119862 =119878

119879Transfer (12)




119879Total) times 119862 (13)







(14)




0

2

4

6

8

10

0 50 100 150 200 250 300 350 400

Capa

city

(Mbp

s)

Time (s)

Maximum throughput

AdHoc Probert-Winf



















0

2

4

6

8

10

0 50 100 150 200 250 300 350 400

Capa

city

(Mbp

s)

Time (s)



0

2

4

6

8

10

12

0 50 100 150 200 250 300 350 400

Avai

labl

e ban

dwid

th

Time (s)


DataRateIPerf UDP



10000

9000

8000

7000

6000

5000

4000

3000

2000

1000

0

1 2 4 6 8

Number of flows

Capa

city

(kbp

s)







119862winf times (119879RTT119872) (15)



RetrieveXCPRCP

Transportlayer

rt-Winfmodule

Networklayer

MAClayer

Insert

Cross layershared

database



119894=119899

sum119894=1

THinverse =119878119894

119862winf119894 (16)


119894=119899

sum119894=1

Γ+ =119879RTT119894 times 119878119894

119862winf119894 (17)


119894=119899

sum119894=1

Γ+ =119879ci times 119878119894119862winf119894

(18)








119879RTT (19)




119901119891 =119862120593 +max (119865 0)

sumΨ

119899119891 =119862120593 +max (minus119865 0)

120601

(20)


119891119901 = 119901119891 times119878

119862winf (21)


119891119899 = 119899119891 times 119878 (22)


119862change = 119891119901 minus 119891119899 (23)



119879119890 = max(119902 (119879RTT minus119902

119862winf2)) (24)








(26)


119879pacing =119872

119862desired (27)


119877 = 119877

times ( 1+ [((119879119890

119879RTT)


119879RTT))


(28)



if (119877 lt 119877min) 997904rArr 119877 = 119877min




119879RTT (30)



119862desired = 119862winf (31)




Mesh 0 Mesh 3

Mesh 4

Mesh 1 Mesh 2

Mobile 0

Mobile 3

Mobile 1

Mobile 2

Mobile 4








0100

200300400500600700800900

3 35 4 45 5 55 6 65 7

Thro

ughp

ut (k

bps)




(a) Throughput

10

100

1000

10000

100000

3 35 4 45 5 55 6 65 7

Del

ay (m

s)




(b) Delay

0

2000

4000

6000

8000

10000

12000

14000

3 35 4 45 5 55 6 65 7

Num

ber o

f pac

kets











0

100

200

300

400

500

3 35 4 45 5 55 6 65 7

Thro

ughp

ut (k

bps)














roug

hput

(kbp

s)


0

50

100

150

200

250

300

0 20 40 60 80 100 140120



(a) Throughput


0

20

40

60

80

100

120

140

0 20 40 60 80 100 120 140

Del

ay (m

s)



(b) Delay


0

2000

4000

6000

8000

10000

12000

14000

16000

18000

Num

ber o

f pac

kets





200m

150m

400m

400m

50m







500

600

700

800

900

1000

1100

1200

1300

10 15 20 25 30

Thro

ughp

ut (k

bps)





50

100

150

200

250

300

350

10 15 20 25 30

Del

ay (m

s)





8000

10000

12000

14000

16000

18000

20000

22000

24000

10 15 20 25 30

Num

ber o

f pac

kets









6 Conclusions



600

700

800

900

1000

1100

1200

1300

1400

10 15 20 25 30

Thro

ughp

ut (k

bps)






0

50

100

150

200

250

300

10 15 20 25 30

Del

ay (m

s)




10000

12000

14000

16000

18000

20000

22000

24000

26000

28000

10 15 20 25 30

Num

ber o

f pac

kets










0

500

1000

1500

2000

2500

3000

3500

4000

4500

0 20 40 60 80 100 120

Avg

rate

(kbp

s)

Time (s)

XCP-Winf TCP


0

1000

2000

3000

4000

5000

0 20 40 60 80 100 120

Avg

rate

(kbp

s)

Time (s)

RCP-Winf TCP





References













































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation














(10)





(11)





119862 =119878

119879Transfer (12)




119879Total) times 119862 (13)







(14)




0

2

4

6

8

10

0 50 100 150 200 250 300 350 400

Capa

city

(Mbp

s)

Time (s)

Maximum throughput

AdHoc Probert-Winf



















0

2

4

6

8

10

0 50 100 150 200 250 300 350 400

Capa

city

(Mbp

s)

Time (s)



0

2

4

6

8

10

12

0 50 100 150 200 250 300 350 400

Avai

labl

e ban

dwid

th

Time (s)


DataRateIPerf UDP



10000

9000

8000

7000

6000

5000

4000

3000

2000

1000

0

1 2 4 6 8

Number of flows

Capa

city

(kbp

s)







119862winf times (119879RTT119872) (15)



RetrieveXCPRCP

Transportlayer

rt-Winfmodule

Networklayer

MAClayer

Insert

Cross layershared

database



119894=119899

sum119894=1

THinverse =119878119894

119862winf119894 (16)


119894=119899

sum119894=1

Γ+ =119879RTT119894 times 119878119894

119862winf119894 (17)


119894=119899

sum119894=1

Γ+ =119879ci times 119878119894119862winf119894

(18)








119879RTT (19)




119901119891 =119862120593 +max (119865 0)

sumΨ

119899119891 =119862120593 +max (minus119865 0)

120601

(20)


119891119901 = 119901119891 times119878

119862winf (21)


119891119899 = 119899119891 times 119878 (22)


119862change = 119891119901 minus 119891119899 (23)



119879119890 = max(119902 (119879RTT minus119902

119862winf2)) (24)








(26)


119879pacing =119872

119862desired (27)


119877 = 119877

times ( 1+ [((119879119890

119879RTT)


119879RTT))


(28)



if (119877 lt 119877min) 997904rArr 119877 = 119877min




119879RTT (30)



119862desired = 119862winf (31)




Mesh 0 Mesh 3

Mesh 4

Mesh 1 Mesh 2

Mobile 0

Mobile 3

Mobile 1

Mobile 2

Mobile 4








0100

200300400500600700800900

3 35 4 45 5 55 6 65 7

Thro

ughp

ut (k

bps)




(a) Throughput

10

100

1000

10000

100000

3 35 4 45 5 55 6 65 7

Del

ay (m

s)




(b) Delay

0

2000

4000

6000

8000

10000

12000

14000

3 35 4 45 5 55 6 65 7

Num

ber o

f pac

kets











0

100

200

300

400

500

3 35 4 45 5 55 6 65 7

Thro

ughp

ut (k

bps)














roug

hput

(kbp

s)


0

50

100

150

200

250

300

0 20 40 60 80 100 140120



(a) Throughput


0

20

40

60

80

100

120

140

0 20 40 60 80 100 120 140

Del

ay (m

s)



(b) Delay


0

2000

4000

6000

8000

10000

12000

14000

16000

18000

Num

ber o

f pac

kets





200m

150m

400m

400m

50m







500

600

700

800

900

1000

1100

1200

1300

10 15 20 25 30

Thro

ughp

ut (k

bps)





50

100

150

200

250

300

350

10 15 20 25 30

Del

ay (m

s)





8000

10000

12000

14000

16000

18000

20000

22000

24000

10 15 20 25 30

Num

ber o

f pac

kets









6 Conclusions



600

700

800

900

1000

1100

1200

1300

1400

10 15 20 25 30

Thro

ughp

ut (k

bps)






0

50

100

150

200

250

300

10 15 20 25 30

Del

ay (m

s)




10000

12000

14000

16000

18000

20000

22000

24000

26000

28000

10 15 20 25 30

Num

ber o

f pac

kets










0

500

1000

1500

2000

2500

3000

3500

4000

4500

0 20 40 60 80 100 120

Avg

rate

(kbp

s)

Time (s)

XCP-Winf TCP


0

1000

2000

3000

4000

5000

0 20 40 60 80 100 120

Avg

rate

(kbp

s)

Time (s)

RCP-Winf TCP





References













































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation










0

2

4

6

8

10

0 50 100 150 200 250 300 350 400

Capa

city

(Mbp

s)

Time (s)

Maximum throughput

AdHoc Probert-Winf



















0

2

4

6

8

10

0 50 100 150 200 250 300 350 400

Capa

city

(Mbp

s)

Time (s)



0

2

4

6

8

10

12

0 50 100 150 200 250 300 350 400

Avai

labl

e ban

dwid

th

Time (s)


DataRateIPerf UDP



10000

9000

8000

7000

6000

5000

4000

3000

2000

1000

0

1 2 4 6 8

Number of flows

Capa

city

(kbp

s)







119862winf times (119879RTT119872) (15)



RetrieveXCPRCP

Transportlayer

rt-Winfmodule

Networklayer

MAClayer

Insert

Cross layershared

database



119894=119899

sum119894=1

THinverse =119878119894

119862winf119894 (16)


119894=119899

sum119894=1

Γ+ =119879RTT119894 times 119878119894

119862winf119894 (17)


119894=119899

sum119894=1

Γ+ =119879ci times 119878119894119862winf119894

(18)








119879RTT (19)




119901119891 =119862120593 +max (119865 0)

sumΨ

119899119891 =119862120593 +max (minus119865 0)

120601

(20)


119891119901 = 119901119891 times119878

119862winf (21)


119891119899 = 119899119891 times 119878 (22)


119862change = 119891119901 minus 119891119899 (23)



119879119890 = max(119902 (119879RTT minus119902

119862winf2)) (24)








(26)


119879pacing =119872

119862desired (27)


119877 = 119877

times ( 1+ [((119879119890

119879RTT)


119879RTT))


(28)



if (119877 lt 119877min) 997904rArr 119877 = 119877min




119879RTT (30)



119862desired = 119862winf (31)




Mesh 0 Mesh 3

Mesh 4

Mesh 1 Mesh 2

Mobile 0

Mobile 3

Mobile 1

Mobile 2

Mobile 4








0100

200300400500600700800900

3 35 4 45 5 55 6 65 7

Thro

ughp

ut (k

bps)




(a) Throughput

10

100

1000

10000

100000

3 35 4 45 5 55 6 65 7

Del

ay (m

s)




(b) Delay

0

2000

4000

6000

8000

10000

12000

14000

3 35 4 45 5 55 6 65 7

Num

ber o

f pac

kets











0

100

200

300

400

500

3 35 4 45 5 55 6 65 7

Thro

ughp

ut (k

bps)














roug

hput

(kbp

s)


0

50

100

150

200

250

300

0 20 40 60 80 100 140120



(a) Throughput


0

20

40

60

80

100

120

140

0 20 40 60 80 100 120 140

Del

ay (m

s)



(b) Delay


0

2000

4000

6000

8000

10000

12000

14000

16000

18000

Num

ber o

f pac

kets





200m

150m

400m

400m

50m







500

600

700

800

900

1000

1100

1200

1300

10 15 20 25 30

Thro

ughp

ut (k

bps)





50

100

150

200

250

300

350

10 15 20 25 30

Del

ay (m

s)





8000

10000

12000

14000

16000

18000

20000

22000

24000

10 15 20 25 30

Num

ber o

f pac

kets









6 Conclusions



600

700

800

900

1000

1100

1200

1300

1400

10 15 20 25 30

Thro

ughp

ut (k

bps)






0

50

100

150

200

250

300

10 15 20 25 30

Del

ay (m

s)




10000

12000

14000

16000

18000

20000

22000

24000

26000

28000

10 15 20 25 30

Num

ber o

f pac

kets










0

500

1000

1500

2000

2500

3000

3500

4000

4500

0 20 40 60 80 100 120

Avg

rate

(kbp

s)

Time (s)

XCP-Winf TCP


0

1000

2000

3000

4000

5000

0 20 40 60 80 100 120

Avg

rate

(kbp

s)

Time (s)

RCP-Winf TCP





References













































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation













0

2

4

6

8

10

0 50 100 150 200 250 300 350 400

Capa

city

(Mbp

s)

Time (s)



0

2

4

6

8

10

12

0 50 100 150 200 250 300 350 400

Avai

labl

e ban

dwid

th

Time (s)


DataRateIPerf UDP



10000

9000

8000

7000

6000

5000

4000

3000

2000

1000

0

1 2 4 6 8

Number of flows

Capa

city

(kbp

s)







119862winf times (119879RTT119872) (15)



RetrieveXCPRCP

Transportlayer

rt-Winfmodule

Networklayer

MAClayer

Insert

Cross layershared

database



119894=119899

sum119894=1

THinverse =119878119894

119862winf119894 (16)


119894=119899

sum119894=1

Γ+ =119879RTT119894 times 119878119894

119862winf119894 (17)


119894=119899

sum119894=1

Γ+ =119879ci times 119878119894119862winf119894

(18)








119879RTT (19)




119901119891 =119862120593 +max (119865 0)

sumΨ

119899119891 =119862120593 +max (minus119865 0)

120601

(20)


119891119901 = 119901119891 times119878

119862winf (21)


119891119899 = 119899119891 times 119878 (22)


119862change = 119891119901 minus 119891119899 (23)



119879119890 = max(119902 (119879RTT minus119902

119862winf2)) (24)








(26)


119879pacing =119872

119862desired (27)


119877 = 119877

times ( 1+ [((119879119890

119879RTT)


119879RTT))


(28)



if (119877 lt 119877min) 997904rArr 119877 = 119877min




119879RTT (30)



119862desired = 119862winf (31)




Mesh 0 Mesh 3

Mesh 4

Mesh 1 Mesh 2

Mobile 0

Mobile 3

Mobile 1

Mobile 2

Mobile 4








0100

200300400500600700800900

3 35 4 45 5 55 6 65 7

Thro

ughp

ut (k

bps)




(a) Throughput

10

100

1000

10000

100000

3 35 4 45 5 55 6 65 7

Del

ay (m

s)




(b) Delay

0

2000

4000

6000

8000

10000

12000

14000

3 35 4 45 5 55 6 65 7

Num

ber o

f pac

kets











0

100

200

300

400

500

3 35 4 45 5 55 6 65 7

Thro

ughp

ut (k

bps)














roug

hput

(kbp

s)


0

50

100

150

200

250

300

0 20 40 60 80 100 140120



(a) Throughput


0

20

40

60

80

100

120

140

0 20 40 60 80 100 120 140

Del

ay (m

s)



(b) Delay


0

2000

4000

6000

8000

10000

12000

14000

16000

18000

Num

ber o

f pac

kets





200m

150m

400m

400m

50m







500

600

700

800

900

1000

1100

1200

1300

10 15 20 25 30

Thro

ughp

ut (k

bps)





50

100

150

200

250

300

350

10 15 20 25 30

Del

ay (m

s)





8000

10000

12000

14000

16000

18000

20000

22000

24000

10 15 20 25 30

Num

ber o

f pac

kets









6 Conclusions



600

700

800

900

1000

1100

1200

1300

1400

10 15 20 25 30

Thro

ughp

ut (k

bps)






0

50

100

150

200

250

300

10 15 20 25 30

Del

ay (m

s)




10000

12000

14000

16000

18000

20000

22000

24000

26000

28000

10 15 20 25 30

Num

ber o

f pac

kets










0

500

1000

1500

2000

2500

3000

3500

4000

4500

0 20 40 60 80 100 120

Avg

rate

(kbp

s)

Time (s)

XCP-Winf TCP


0

1000

2000

3000

4000

5000

0 20 40 60 80 100 120

Avg

rate

(kbp

s)

Time (s)

RCP-Winf TCP





References













































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation










RetrieveXCPRCP

Transportlayer

rt-Winfmodule

Networklayer

MAClayer

Insert

Cross layershared

database



119894=119899

sum119894=1

THinverse =119878119894

119862winf119894 (16)


119894=119899

sum119894=1

Γ+ =119879RTT119894 times 119878119894

119862winf119894 (17)


119894=119899

sum119894=1

Γ+ =119879ci times 119878119894119862winf119894

(18)








119879RTT (19)




119901119891 =119862120593 +max (119865 0)

sumΨ

119899119891 =119862120593 +max (minus119865 0)

120601

(20)


119891119901 = 119901119891 times119878

119862winf (21)


119891119899 = 119899119891 times 119878 (22)


119862change = 119891119901 minus 119891119899 (23)



119879119890 = max(119902 (119879RTT minus119902

119862winf2)) (24)








(26)


119879pacing =119872

119862desired (27)


119877 = 119877

times ( 1+ [((119879119890

119879RTT)


119879RTT))


(28)



if (119877 lt 119877min) 997904rArr 119877 = 119877min




119879RTT (30)



119862desired = 119862winf (31)




Mesh 0 Mesh 3

Mesh 4

Mesh 1 Mesh 2

Mobile 0

Mobile 3

Mobile 1

Mobile 2

Mobile 4








0100

200300400500600700800900

3 35 4 45 5 55 6 65 7

Thro

ughp

ut (k

bps)




(a) Throughput

10

100

1000

10000

100000

3 35 4 45 5 55 6 65 7

Del

ay (m

s)




(b) Delay

0

2000

4000

6000

8000

10000

12000

14000

3 35 4 45 5 55 6 65 7

Num

ber o

f pac

kets











0

100

200

300

400

500

3 35 4 45 5 55 6 65 7

Thro

ughp

ut (k

bps)














roug

hput

(kbp

s)


0

50

100

150

200

250

300

0 20 40 60 80 100 140120



(a) Throughput


0

20

40

60

80

100

120

140

0 20 40 60 80 100 120 140

Del

ay (m

s)



(b) Delay


0

2000

4000

6000

8000

10000

12000

14000

16000

18000

Num

ber o

f pac

kets





200m

150m

400m

400m

50m







500

600

700

800

900

1000

1100

1200

1300

10 15 20 25 30

Thro

ughp

ut (k

bps)





50

100

150

200

250

300

350

10 15 20 25 30

Del

ay (m

s)





8000

10000

12000

14000

16000

18000

20000

22000

24000

10 15 20 25 30

Num

ber o

f pac

kets









6 Conclusions



600

700

800

900

1000

1100

1200

1300

1400

10 15 20 25 30

Thro

ughp

ut (k

bps)






0

50

100

150

200

250

300

10 15 20 25 30

Del

ay (m

s)




10000

12000

14000

16000

18000

20000

22000

24000

26000

28000

10 15 20 25 30

Num

ber o

f pac

kets










0

500

1000

1500

2000

2500

3000

3500

4000

4500

0 20 40 60 80 100 120

Avg

rate

(kbp

s)

Time (s)

XCP-Winf TCP


0

1000

2000

3000

4000

5000

0 20 40 60 80 100 120

Avg

rate

(kbp

s)

Time (s)

RCP-Winf TCP





References













































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation











119901119891 =119862120593 +max (119865 0)

sumΨ

119899119891 =119862120593 +max (minus119865 0)

120601

(20)


119891119901 = 119901119891 times119878

119862winf (21)


119891119899 = 119899119891 times 119878 (22)


119862change = 119891119901 minus 119891119899 (23)



119879119890 = max(119902 (119879RTT minus119902

119862winf2)) (24)








(26)


119879pacing =119872

119862desired (27)


119877 = 119877

times ( 1+ [((119879119890

119879RTT)


119879RTT))


(28)



if (119877 lt 119877min) 997904rArr 119877 = 119877min




119879RTT (30)



119862desired = 119862winf (31)




Mesh 0 Mesh 3

Mesh 4

Mesh 1 Mesh 2

Mobile 0

Mobile 3

Mobile 1

Mobile 2

Mobile 4








0100

200300400500600700800900

3 35 4 45 5 55 6 65 7

Thro

ughp

ut (k

bps)




(a) Throughput

10

100

1000

10000

100000

3 35 4 45 5 55 6 65 7

Del

ay (m

s)




(b) Delay

0

2000

4000

6000

8000

10000

12000

14000

3 35 4 45 5 55 6 65 7

Num

ber o

f pac

kets











0

100

200

300

400

500

3 35 4 45 5 55 6 65 7

Thro

ughp

ut (k

bps)














roug

hput

(kbp

s)


0

50

100

150

200

250

300

0 20 40 60 80 100 140120



(a) Throughput


0

20

40

60

80

100

120

140

0 20 40 60 80 100 120 140

Del

ay (m

s)



(b) Delay


0

2000

4000

6000

8000

10000

12000

14000

16000

18000

Num

ber o

f pac

kets





200m

150m

400m

400m

50m







500

600

700

800

900

1000

1100

1200

1300

10 15 20 25 30

Thro

ughp

ut (k

bps)





50

100

150

200

250

300

350

10 15 20 25 30

Del

ay (m

s)





8000

10000

12000

14000

16000

18000

20000

22000

24000

10 15 20 25 30

Num

ber o

f pac

kets









6 Conclusions



600

700

800

900

1000

1100

1200

1300

1400

10 15 20 25 30

Thro

ughp

ut (k

bps)






0

50

100

150

200

250

300

10 15 20 25 30

Del

ay (m

s)




10000

12000

14000

16000

18000

20000

22000

24000

26000

28000

10 15 20 25 30

Num

ber o

f pac

kets










0

500

1000

1500

2000

2500

3000

3500

4000

4500

0 20 40 60 80 100 120

Avg

rate

(kbp

s)

Time (s)

XCP-Winf TCP


0

1000

2000

3000

4000

5000

0 20 40 60 80 100 120

Avg

rate

(kbp

s)

Time (s)

RCP-Winf TCP





References













































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation











if (119877 lt 119877min) 997904rArr 119877 = 119877min




119879RTT (30)



119862desired = 119862winf (31)




Mesh 0 Mesh 3

Mesh 4

Mesh 1 Mesh 2

Mobile 0

Mobile 3

Mobile 1

Mobile 2

Mobile 4








0100

200300400500600700800900

3 35 4 45 5 55 6 65 7

Thro

ughp

ut (k

bps)




(a) Throughput

10

100

1000

10000

100000

3 35 4 45 5 55 6 65 7

Del

ay (m

s)




(b) Delay

0

2000

4000

6000

8000

10000

12000

14000

3 35 4 45 5 55 6 65 7

Num

ber o

f pac

kets











0

100

200

300

400

500

3 35 4 45 5 55 6 65 7

Thro

ughp

ut (k

bps)














roug

hput

(kbp

s)


0

50

100

150

200

250

300

0 20 40 60 80 100 140120



(a) Throughput


0

20

40

60

80

100

120

140

0 20 40 60 80 100 120 140

Del

ay (m

s)



(b) Delay


0

2000

4000

6000

8000

10000

12000

14000

16000

18000

Num

ber o

f pac

kets





200m

150m

400m

400m

50m







500

600

700

800

900

1000

1100

1200

1300

10 15 20 25 30

Thro

ughp

ut (k

bps)





50

100

150

200

250

300

350

10 15 20 25 30

Del

ay (m

s)





8000

10000

12000

14000

16000

18000

20000

22000

24000

10 15 20 25 30

Num

ber o

f pac

kets









6 Conclusions



600

700

800

900

1000

1100

1200

1300

1400

10 15 20 25 30

Thro

ughp

ut (k

bps)






0

50

100

150

200

250

300

10 15 20 25 30

Del

ay (m

s)




10000

12000

14000

16000

18000

20000

22000

24000

26000

28000

10 15 20 25 30

Num

ber o

f pac

kets










0

500

1000

1500

2000

2500

3000

3500

4000

4500

0 20 40 60 80 100 120

Avg

rate

(kbp

s)

Time (s)

XCP-Winf TCP


0

1000

2000

3000

4000

5000

0 20 40 60 80 100 120

Avg

rate

(kbp

s)

Time (s)

RCP-Winf TCP





References













































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation










0100

200300400500600700800900

3 35 4 45 5 55 6 65 7

Thro

ughp

ut (k

bps)




(a) Throughput

10

100

1000

10000

100000

3 35 4 45 5 55 6 65 7

Del

ay (m

s)




(b) Delay

0

2000

4000

6000

8000

10000

12000

14000

3 35 4 45 5 55 6 65 7

Num

ber o

f pac

kets











0

100

200

300

400

500

3 35 4 45 5 55 6 65 7

Thro

ughp

ut (k

bps)














roug

hput

(kbp

s)


0

50

100

150

200

250

300

0 20 40 60 80 100 140120



(a) Throughput


0

20

40

60

80

100

120

140

0 20 40 60 80 100 120 140

Del

ay (m

s)



(b) Delay


0

2000

4000

6000

8000

10000

12000

14000

16000

18000

Num

ber o

f pac

kets





200m

150m

400m

400m

50m







500

600

700

800

900

1000

1100

1200

1300

10 15 20 25 30

Thro

ughp

ut (k

bps)





50

100

150

200

250

300

350

10 15 20 25 30

Del

ay (m

s)





8000

10000

12000

14000

16000

18000

20000

22000

24000

10 15 20 25 30

Num

ber o

f pac

kets









6 Conclusions



600

700

800

900

1000

1100

1200

1300

1400

10 15 20 25 30

Thro

ughp

ut (k

bps)






0

50

100

150

200

250

300

10 15 20 25 30

Del

ay (m

s)




10000

12000

14000

16000

18000

20000

22000

24000

26000

28000

10 15 20 25 30

Num

ber o

f pac

kets










0

500

1000

1500

2000

2500

3000

3500

4000

4500

0 20 40 60 80 100 120

Avg

rate

(kbp

s)

Time (s)

XCP-Winf TCP


0

1000

2000

3000

4000

5000

0 20 40 60 80 100 120

Avg

rate

(kbp

s)

Time (s)

RCP-Winf TCP





References













































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation










0

100

200

300

400

500

3 35 4 45 5 55 6 65 7

Thro

ughp

ut (k

bps)














roug

hput

(kbp

s)


0

50

100

150

200

250

300

0 20 40 60 80 100 140120



(a) Throughput


0

20

40

60

80

100

120

140

0 20 40 60 80 100 120 140

Del

ay (m

s)



(b) Delay


0

2000

4000

6000

8000

10000

12000

14000

16000

18000

Num

ber o

f pac

kets





200m

150m

400m

400m

50m







500

600

700

800

900

1000

1100

1200

1300

10 15 20 25 30

Thro

ughp

ut (k

bps)





50

100

150

200

250

300

350

10 15 20 25 30

Del

ay (m

s)





8000

10000

12000

14000

16000

18000

20000

22000

24000

10 15 20 25 30

Num

ber o

f pac

kets









6 Conclusions



600

700

800

900

1000

1100

1200

1300

1400

10 15 20 25 30

Thro

ughp

ut (k

bps)






0

50

100

150

200

250

300

10 15 20 25 30

Del

ay (m

s)




10000

12000

14000

16000

18000

20000

22000

24000

26000

28000

10 15 20 25 30

Num

ber o

f pac

kets










0

500

1000

1500

2000

2500

3000

3500

4000

4500

0 20 40 60 80 100 120

Avg

rate

(kbp

s)

Time (s)

XCP-Winf TCP


0

1000

2000

3000

4000

5000

0 20 40 60 80 100 120

Avg

rate

(kbp

s)

Time (s)

RCP-Winf TCP





References













































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation










roug

hput

(kbp

s)


0

50

100

150

200

250

300

0 20 40 60 80 100 140120



(a) Throughput


0

20

40

60

80

100

120

140

0 20 40 60 80 100 120 140

Del

ay (m

s)



(b) Delay


0

2000

4000

6000

8000

10000

12000

14000

16000

18000

Num

ber o

f pac

kets





200m

150m

400m

400m

50m







500

600

700

800

900

1000

1100

1200

1300

10 15 20 25 30

Thro

ughp

ut (k

bps)





50

100

150

200

250

300

350

10 15 20 25 30

Del

ay (m

s)





8000

10000

12000

14000

16000

18000

20000

22000

24000

10 15 20 25 30

Num

ber o

f pac

kets









6 Conclusions



600

700

800

900

1000

1100

1200

1300

1400

10 15 20 25 30

Thro

ughp

ut (k

bps)






0

50

100

150

200

250

300

10 15 20 25 30

Del

ay (m

s)




10000

12000

14000

16000

18000

20000

22000

24000

26000

28000

10 15 20 25 30

Num

ber o

f pac

kets










0

500

1000

1500

2000

2500

3000

3500

4000

4500

0 20 40 60 80 100 120

Avg

rate

(kbp

s)

Time (s)

XCP-Winf TCP


0

1000

2000

3000

4000

5000

0 20 40 60 80 100 120

Avg

rate

(kbp

s)

Time (s)

RCP-Winf TCP





References













































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation










500

600

700

800

900

1000

1100

1200

1300

10 15 20 25 30

Thro

ughp

ut (k

bps)





50

100

150

200

250

300

350

10 15 20 25 30

Del

ay (m

s)





8000

10000

12000

14000

16000

18000

20000

22000

24000

10 15 20 25 30

Num

ber o

f pac

kets









6 Conclusions



600

700

800

900

1000

1100

1200

1300

1400

10 15 20 25 30

Thro

ughp

ut (k

bps)






0

50

100

150

200

250

300

10 15 20 25 30

Del

ay (m

s)




10000

12000

14000

16000

18000

20000

22000

24000

26000

28000

10 15 20 25 30

Num

ber o

f pac

kets










0

500

1000

1500

2000

2500

3000

3500

4000

4500

0 20 40 60 80 100 120

Avg

rate

(kbp

s)

Time (s)

XCP-Winf TCP


0

1000

2000

3000

4000

5000

0 20 40 60 80 100 120

Avg

rate

(kbp

s)

Time (s)

RCP-Winf TCP





References













































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation










600

700

800

900

1000

1100

1200

1300

1400

10 15 20 25 30

Thro

ughp

ut (k

bps)






0

50

100

150

200

250

300

10 15 20 25 30

Del

ay (m

s)




10000

12000

14000

16000

18000

20000

22000

24000

26000

28000

10 15 20 25 30

Num

ber o

f pac

kets










0

500

1000

1500

2000

2500

3000

3500

4000

4500

0 20 40 60 80 100 120

Avg

rate

(kbp

s)

Time (s)

XCP-Winf TCP


0

1000

2000

3000

4000

5000

0 20 40 60 80 100 120

Avg

rate

(kbp

s)

Time (s)

RCP-Winf TCP





References













































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation










0

500

1000

1500

2000

2500

3000

3500

4000

4500

0 20 40 60 80 100 120

Avg

rate

(kbp

s)

Time (s)

XCP-Winf TCP


0

1000

2000

3000

4000

5000

0 20 40 60 80 100 120

Avg

rate

(kbp

s)

Time (s)

RCP-Winf TCP





References













































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation


































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation









Research Article XCP-Winf and RCP-Winf: Improving...

Documents

Transcript of Research Article XCP-Winf and RCP-Winf: Improving...