An Intelligent Way to ReduceChannel Under-utilization inMobile Ad hoc Networks
Naoki Nakamura,1 Debasish Chakraborty,2 David Wei,3
and Norio Shiratori2
1 Tohoku University School of Medicine, Tohoku University, Sendai, Japan2 Research Institute of Electrical Communication, Tohoku University, Sendai, Japan3 CIS Department, Fordham University, Bronx, NY
3.1 Introduction 433.2 Related Works 453.3 Background 453.4 Enhancements for Efficient Channel Utilization 513.5 Performance Evaluation and Discussions 563.6 Summary 60References 60
3.1 INTRODUCTION
In wireless network, performance is dependent on medium access control protocol.Carrier sense multiple access (CSMA) is commonly used for its simplicity. But CSMAis unable to handle the hidden terminal problem, especially in ad hoc networks, wheremultihop communication among nodes is common. To overcome this problem, aframe exchange protocol is used, called request to send/clear to send (RTS/CTS)handshaking. It was first proposed in Ref. [1].
44 An Intelligent Way to Reduce Channel Under-utilization in Mobile Ad hoc Networks
There have been a lot of researches on developing the wireless medium accesscontrol (MAC) that efficiently shares limited resources between all stations [1, 2]. Atpresent, IEEE 802.11 MAC is clearly the most accepted and widely used wirelesstechnology. The IEEE 802.11 works based on carrier sense multiple access withcollision avoidance (CSMA/CA) and adopts a random access scheme where packetsare sent randomly to reduce the number of collisions as much as possible. In addition,IEEE 802.11 introduces a mechanism called RTS/CTS handshaking and virtual carriersensing to further reduce the chance of collisions that can occur due to hidden terminalproblems.
However, it is observed [3] that hidden and exposed terminal problems are exac-erbated in mobile ad hoc network (MANET) while using IEEE 802.11. The ultimateresult is heavy degradation in throughput and instability of networks. In Ref.[4], itis shown that this problem is more severe in large and dense ad hoc networks. So,improvement of performance degradation for IEEE 802.11 over the MANET is animportant issue.
“False blocking” problem unnecessarily prohibits nodes from transmitting at agiven instant [5]. In worst case, all the neighboring nodes are blocked and can nottransmit frames and they are put into the deadlock state. This happens when RTSframe reserves the channel but the channel remains unused. Ray et al. [5] proposed“RTS validation,” where a channel is released when each node assumes that CTS ismissing, after it receives RTS frame, based on the physical carrier sensing.
In Ref. [6], with the same motivation, we proposed a scheme called “extraframe transmission” to manipulate frame transmission during RTS/CTS handshak-ing. When no CTS is received for some specific duration after node sends an RTSframe, it will immediately send another small frame to other destination. Boththese schemes [5, 6] reuse the channel unnecessarily reserved. The main differ-ence between RTS validation scheme and extra frame transmission scheme is, whichnode to detect the interruption of RTS/CTS handshaking. In Ref. [6], it is doneby sender, whereas in Ref. [5] neighboring nodes are responsible for interruptiondetection.
In this chapter, we propose another type of extra frame, called “reverse extraframe.” We also note that there is scope for improvement when channel releaseschemes are not applicable. To reuse the channel as much as possible, we modifyNAV operations to increase the chance of channel reuse. In addition, focusing onthe fact that these schemes can work independently, we combine modified schemestogether. Moreover, our proposed mechanisms are free from compatibility problemswith standard IEEE 802.11. Results from simulations verify the effectiveness of ourschemes. It is observed that our combination of schemes leads to higher gain inthroughput compared to IEEE 802.11.
The rest of this chapter is organized as follows. In Section 3.2, we discuss therelated works. Basic operations of the IEEE 802.11 are explained and its operation inMANET during RTS/CTS failure is described in Section 3.3. Our proposed schemeof our enhancement of IEEE 802.11 is explained in Section 3.4. The effectiveness ofour scheme and evaluation of our proposal are discussed in Section 3.5. Finally, weconclude our work in Section 3.6.
3.3 Background 45
3.2 RELATED WORKS
The CSMA protocol as proposed in Ref. [7] and its susceptibility to the hidden terminalproblem was noted in Ref. [8], where the authors proposed a solution called busy-tonemultiple access (BTMA) protocol. To reduce the effect of hidden terminal problem,multiple access with collision avoidance (MACA) protocol was proposed in Ref. [1].MACA uses RTS/CTS mechanism to avoid the hidden terminal problem, but does notinclude any positive acknowledgement to ensure the integrity of the DATA transmis-sion. A positive acknowledgement scheme as added in the MACAW protocol [2]. TheMACAW protocol also requires nodes to send a packet called DATA-send (DS) toindicate that a DATA packet transmission is about to begin; however, this mechanismis not part of the IEEE 802.11 standard, so it may not be compatible with the standardprotocol. Ray et al. [5] noted that in a general multihop network, the RTS/CTS mech-anism cannot completely eliminate DATA packet collisions due to the masked nodeproblem. They also observed that it holds true even under idealized conditions such asnegligible control packet size, negligible propagation delay, and identical interferenceand packet-sensing ranges. Nevertheless, the RTS/CTS mechanism greatly reducesthe hidden terminal problem and is desirable to be deployed in general. Although inRef. [9] blocking in wireless network has been discussed, but the severity of falseblocking was first described in Ref. [5] work. Shigeyasu et al. [10] proposed a newMAC protocol in order to overcome the false blocking problem in wireless LANs.
RTS validation has been proposed to mitigate the false blocking problem wherethe nodes that have received RTS inhibit themselves from transmitting in the chain [5].Upon overhearing an RTS frame, nodes listen to the medium whether the correspond-ing DATA frame transmission has taken place or not. They do this based on physicalcarrier sensing. If transmission has not taken place, the medium should have remainedidle for an expected duration. At this point, nodes start to overhear the DATA frametransmission since they have received an RTS frame. When the medium remains idlefor the specified duration since the node received an RTS frame, it will conclude thatan interruption of RTS/CTS handshaking has occurred. Then the node will releasethe NAV registered by that RTS frame and stop deferring. Subsequently, each nodereleases the channel independently. Harada et al. [11] introduced a new frame, calledcancel RTS (CRTS), which left the reserved channel free in order to decrease degra-dation of channel utilization caused by failure to obtain a channel during RTS/CTShandshaking. In this scheme, when a sender node does not receive CTS correctly forits RTS, it sends a CRTS frame. Then, neighboring nodes, upon overhearing CRTS,cancel the NAV set by the RTS. However, the introduction of a new frame can causecompatibility problems with standard IEEE 802.11.
3.3 BACKGROUND
The IEEE 802.11 MAC layer covers three functional areas: reliable data deliveryaccess, control, and security. We will discuss mainly about first two functions, as theyare more closely related to our proposal in this chapter.
46 An Intelligent Way to Reduce Channel Under-utilization in Mobile Ad hoc Networks
3.3.1 Reliable Data Delivery
Like any wireless network, a wireless LAN using IEEE 802.11 physical and MAClayer is not reliable. Noise, interference, and other propagation have adverse effectand cause significant number of frame loses. The reliability mechanism can be han-dled at the higher level as TCP. But the times used at higher levels are usually in theorder of seconds. It is, therefore, more efficient to deal with errors at the MAC layerlevel. To solve this problem, IEEE 802.11 includes a frame-exchange protocol, calledRTS/CTS handshaking. When a station receives a data frame from another station, itreturns an acknowledgment (ACK) frame to the source station. This exchange shouldnot be interrupted by a transmission from any other station. If the source station doesnot receive an ACK within a certain period of time, it will retransmit the frame. Toenhance further reliability to this scheme, a four-way-handshaking scheme has beenintroduced. In this scheme, the source issues a RTS frame to the destination. The des-tination then responds with a CTS. After receiving the CTS, the source transmits thedata frame and the destination responds with a ACK. Both RTS and CTS alert all theneighboring nodes that are within transmission range to refrain from transmitting toavoid collision. The RTS/CTS is an optional function of the MAC that can be disabled.
3.3.2 Access Control
The 802.11 working group considered two types of proposals for a MAC algorithm:distributed access controls, which, like ethernet, distribute the decision to transmitover all the nodes using a carrier-sense mechanism; and centralized access proto-cols, which involve regulation of transmission by a centralized decision maker. Adistributed access protocol makes sense for an ad hoc network of peer workstationsand may also be attractive in other wireless LAN configurations that consist primar-ily of bursty traffic. The IEEE 802.11 describes two medium access functions calledpoint coordination function (PCF) and distributed coordination function (DCF). Thelower sublayer of the MAC layer is the distributed coordination function (DCF). DCFuses contention algorithm to provide access to all traffic. The DCF sublayer is basedon carrier sense multiple access (CSMA) technique. In this chapter, we focus onIEEE 802.11 DCF that provides a distributed access mechanism scheme over ad hocnetworks.
IEEE 802.11 DCF is based on CSMA/CA. It provides basic access mechanismusing two-way handshaking and four-way handshaking. We present only the basicfunctional overview of the IEEE 802.11 standard here. More details can be found inRef. [13].
If the medium is sensed to be free for a DCF interframe space (DIFS) interval,the transmission may proceed. On the other hand, if the medium is busy, the stationmust defer its transmission until the end of the current transmission. Then, it willwait for an additional DIFS interval and generate a random back-off timer beforetransmission. The counter is decreased as long as the medium is sensed as idle andfrozen when the medium is busy and resumed when the medium is sensed as idle
3.3 Background 47
again for a time longer than a DIFS interval. Only when the backoff counter reacheszero, the station can transmit its packets.
A station desiring to transmit senses the medium whether another station is trans-mitting before initiating a transmission. If the medium is sensed to be free for a DCFinterframe space interval, the transmission may proceed. On the other hand, if themedium is busy, the station must defer it transmission until the end of the currenttransmission. Then, it will wait for an additional DIFS interval and generate a randombackoff timer before transmission. The counter is decreased as long as the medium issensed as idle and frozen when the medium is busy and resumed when the mediumis sensed as idle again for a time longer than a DIFS interval. Only when the backoffcounter reaches zero, the station can transmit its packets.
To ensure that backoff maintains stability, a technique known as binary expo-nential backoff is used. A station will attempt to transmit repeatedly in the face ofrepeated collisions, but after each collision, the mean value of the random delay isdoubled. The binary exponential backoff provides a means of handling a heavy load.Repeated failed attempts to transmit result in longer and longer backoff times, whichhelps to smooth out the load. Without such a backoff, two or more stations attemptto transmit at the same time, causing a collision. These stations then immediatelyattempt to retransmit, causing a new collision.
The backoff counter is uniformly chosen between (0, ω − 1). The value ω, knownas contention window (CW), represents the contention level in the channel. At thefirst transmission attempt, ω is set to CWmin. After each transmission failure, ω isdoubled up to a maximum value of CWmax. Figure 3.1 illustrates the basic accessmechanism.
Since stations cannot listen to the channel while transmitting, collision detectionis not possible in wireless medium. An ACK is transmitted by the receiving station toconfirm the successful reception. Receiving station waits for a short interframe space(SIFS) interval after receiving data frame correctly. After that, it sends back an ACKto the sending station. In case of missing an ACK, sender assumes a transmission lossand schedules retransmission after doubling the CW.
3.3.3 Hidden and Exposed Terminal Problems
Hidden nodes in a wireless network refer to nodes that are out of range of other nodesor a collection of nodes. The hidden node problem occurs when a node is visible
DIFS
Defer access
Slot time
contention window
Select slot and decrement backoffas long as medium is idle
Next frameBusy medium Backoff window
Figure 3.1 The basic access mechanism.
48 An Intelligent Way to Reduce Channel Under-utilization in Mobile Ad hoc Networks
A
Tx range of B
C
Tx range of A
B
Wants to transmit to B
Currentlytransmiting
Figure 3.2 Hidden terminal problem.
from a wireless hub, but not from other nodes communicating with the said hub. Thisleads to difficulties in media access control. In the classic hidden terminal situation,as station “B” can hear both “A” and “C” station, but “A” and “C” cannot hear eachother. Therefore, “A” and “C” unable to avoid colliding with each other as shown inFigure 3.2. In wireless networks, the exposed terminal problem occurs when a nodeis prevented from sending packets to other nodes due to a neighboring transmit ion. Inthe exposed terminal case, a well-sited station “A” can hear far away station “C.” Eventhough “A” is too far from “C” to interfere with its traffic to other nearby stations, “A”will defer to it unnecessarily, thus wasting an opportunity to reuse the channel locallyas illustrated in Figure 3.3. Sometimes there can be so much traffic in the remote areathat the well-sited station seldom transmits.
A
Tx range of C
C D
Tx range of B
B
Wants to transmit to D
Currentlytransmiting
Figure 3.3 Exposed terminal problem.
3.3 Background 49
Sender
Receiver
Other
RTS
CTS
DATA
ACK
NAV (RTS)
NAV (CTS)
Defer access
DIFS SIFS SIFS
NAV (DATA)
SIFS
Figure 3.4 The RTS/CTS access mechanism.
3.3.4 RTS/CTS Handshaking Mechanism and VirtualCarrier Sensing
The RTS/CTS access method is provided as an option in IEEE 802.11 to reduce thecollisions caused by hidden terminal problem. A station that needs to transmit largedata frame (longer than predefined RTS threshold value) follows the backoff procedureas the basic mechanism described before. After that, instead of sending data frame, itsends a special short control frame called RTS. This frame includes information aboutthe source, destination, and duration required by the following transaction (CTS,DATA, and ACK transmission). Upon receiving the RTS, the destination respondswith another control frame called CTS, which also contains the same information.The transmitting station is allowed to transmit data only if the CTS frame is receivedcorrectly.
All other nodes overhearing either RTS and/or CTS frame adjust their networkallocation vector (NAV) to the duration specified in RTS/CTS frames. The NAV con-tains period of time in which the channel will be unavailable and is used as virtualcarrier sensing. Figure 3.4 depicts the RTS/CTS mechanism. Stations defer transmis-sions if either physical or virtual sensing finds the channel being busy. Nevertheless,if receiver’s NAV is set while data frame is received, DCF allows the receiver to sendthe ACK frame.
The effectiveness of RTS/CTS mechanism is shown in Ref. [12] as it can earlydetect the collisions by the lack of CTS. Here, it considered that an absence of CTSimplies a collision has occurred and thus can effect an early detection. However, theprotocol cannot free or reallocate the channel that was already reserved by the previousRTS frame. Stations receiving only the RTS frame but not CTS cannot assume thattransmission does not take place. Therefore, they defer for an interval declared in lastRTS. This results in wasting of channel capacity around the sender node.
3.3.5 RTS/CTS-Induced False Blocking
In this section, we analyze the situations when CTS is not received at the sender andhow to improve the channel utilization in each occasion.
50 An Intelligent Way to Reduce Channel Under-utilization in Mobile Ad hoc Networks
A
Tx range of N
SR
M
NRTS
Tx range of S
B
Tx range of M
Tx range of R
Figure 3.5 Illustration of situation 2.
Situation 1: Backoff timers at two or more stations reach zero at the same timeand send the RTS frame simultaneously, so the sender does not receive theCTS frame. This happens more frequently as network traffic increases.
Situation 2: As is illustrated in Figure 3.5, station S starts the RTS/CTS sequencewhile another transmission which interferes with the reception is been carryingon, say, between N and M. Even if the RTS correctly reaches the receiver, thevirtual carrier sensing at station R will forbid the CTS response.
Situation 3: This situation occurs when the intended receiver, R, moves to a newposition, which is out of communication range of S as shown in Figure 3.6.Hence, it cannot receive RTS from S.
Figure 3.6 Illustration of situation 3.
3.4 Enhancements for Efficient Channel Utilization 51
The above situations are regularly found in MANET where stations route packetsthrough each other in multihop fashion, as stations are free to move arbitrarily. Inwireless network, only node is allowed to transmit at a particular time and manynodes around the receiver may be blocked. The neighbors of the blocked node areunaware of this blocking. So, a node may initiate a communication with a node thatis presently blocked and consequently the destination does not respond to the RTSpacket. However, the sender interprets it as channel contention and enters backoff.The neighboring nodes are prevented from decrementing backoff counter and sendingpackets because of the NAV set by RTS.
This false blocking is a consequence when all the nodes that receive RTS in-hibit themselves from transmitting. This problem can get severe when it is occurredin circular way, which can create pseudodeadlock [5]. This leads to lower channelutilization and route failure. Therefore, releasing unused channel is important forchannel stability. RTS validation reduced the above problem, but there is still wastedchannel capacity.
By our proposed schemes, we try to reuse the wasted channel capacity as muchas possible.
3.4 ENHANCEMENTS FOR EFFICIENT CHANNELUTILIZATION
In this section, we present three different approaches and their modification for optimaluse of otherwise wasted channel capacity in MANET. In our proposed schemes, wetried to unlock the unnecessarily blocked channel by using NAV update and also triedsome aggressive methods to recover as much as possible and minimize the channellose due to false blocking.
We have described each of our proposed schemes (i) modification of NAVoperation, (ii) extra frame transmission (EFT), (iii) combination of schemes, and(iv) reverse extra frame transmission (R-EFT) in different subsequent subsections.
3.4.1 Modification of NAV Operation
In case of RTS validation mechanism [5], when the node has already been deferred,it can not set NAV back to the previous value that has already been set by other RTSframes. Besides that, RTS validation may not be always available. Higher the amountof network traffic, more frequent the unavailability of RTS validation. As a result, RTSvalidation can not fully utilize the unused channel. Thus, the efficiency of channelreuse will be reduced. Improvement is possible if RTS validation works irrespectiveof NAV set.
With the above considerations, we modify the NAV operation with three newvariables as follows:
(i) We divided the original NAV in two parts: one is set of NAVk indexed withthe corresponding node’s ID and the other is NAVother.
52 An Intelligent Way to Reduce Channel Under-utilization in Mobile Ad hoc Networks
(ii) NAV used for the operation is calculated by the maximum value in the setsof NAVk and NAVother.
(iii) NAVk is adjusted when overhearing RTS/DATA frame from node nodek, andNAVother is adjusted by cases, other than RTS/DATA frame, like receivingCTS frame or suffering from collision.
(iv) Allowing NAVk to override by newer value in the duration field. It means,when node overhears RTS/ DATA frame of node k then NAVk will be updatedby the duration the frame has.
(v) If needed, RTS validation will reset NAVk.
NAV updating scheme can handle NAV for multiple nodes with record of cor-responding senders’ ID, related to failure of RTS/CTS handshaking, and gives theflexibility and convenience to cancel the NAV even if NAV has already set. This mod-ification is helpful for RTS validation to cancel the NAV and improve the channelcapacity.
In addition, there is benefit of NAV updating in extra frame transmission schemes,discussed in the following subsection.
3.4.2 Extra Frame Transmission
Extra frame transmission works as shown in Figure 3.7. After sender has transmittedRTS for receiver 1 and has waited until it conceives that CTS will not come back, itpicks a frame from the sending queue and immediately transmits it to the alternatereceiver, if an appropriate one exists. We explain the term “appropriate frame” inthe following paragraphs. The extra frame will be removed from the queue if thetransmission is completed (confirmed by ACK from receiver) [13] or the transmittedextra frame is broadcasted. Regardless of the success of extra frame transmission, thesender goes back to normal operation by scheduling the retransmission of the originalframe with doubled CW.
Figure 3.7 Extra frame transmission.
3.4 Enhancements for Efficient Channel Utilization 53
Since the standard protocol does not specify the timeout value for CTS response,sender normally stays idle till the end of the allocated duration. However, the RTS/CTSsequence uses strict timing. So, we introduce a new parameter, handshake timeout S,which accounts for the maximum time that may be required to receive a CTS. Havingwaited for this handshake timeout S, the sender is assured that the CTS response fromreceiver will not come at all.
The transmitted extra frame should maintain the following properties:
1. Extra frame should be destined to a station different from the currently at-tempted one. Since no reply is received from the current destination, anyfurther attempt to the same station will be futile.
2. The selected extra frame should be a broadcast frame (which is irrelevant toRTS threshold), or unicast frame smaller than RTS threshold. So, this framecan be immediately transmitted without following RTS/CTS frame exchangeprotocol.
3. The chosen extra frame should be first in the queue destined for a particularreceiver. For example, if there are two frames for the same destination at thesender, and the first frame is larger than RTS threshold but the second frameis not, then none of the frames will be sent. Even though second frame maysatisfy the first two conditions. This constraint is considered to avoid anyout-of-order transmission.
It has been observed that with the increase in traffic load and node density, thechance of false blocking increases. In that case, there is a fair chance of a successfultransmission of this extra frame because channel around sender has been alreadyreserved by previous RTS frame. In this process, we can deliver a frame that cannotbe sent in normal operation.
With NAV updating schemes, introduced earlier, the benefits of this scheme canbe double folded. The nodes who received the RTS and blocked their channel will beallowed to cancel the original NAV duration.
Actually, nodes will readjust the previously set NAV with the duration of extraframe. NAV of extra frame should have shorter value in duration field than currentNAV for the RTS sender; node can indirectly cancel its NAV. So, if the selected extraframe is a broadcast frame, whose NAV duration is zero, the overhearing nodes canreset the NAV value for RTS and completely cancel the NAV. Even if RTS thresholdis set to zero, extra frame can release the channel effectively.
3.4.3 Combination of RTS Validation and Extra FrameTransmission
Extra frame transmission and RTS validation [5] work-independently on sender nodeand neighboring nodes, respectively. For further performance improvement, we pro-pose an approach to combine RTS validation and extra frame.
Since an appropriate extra frame cannot be always available in the waiting queueof sender node, the channel reuse is not available as frequently as RTS validation.
54 An Intelligent Way to Reduce Channel Under-utilization in Mobile Ad hoc Networks
although it may available, it has the ability to deliver data as an extra frame. To utilizethis ability, we entrust mainly extra frame transmission with delivering the extra frametransmission and entrust RTS validation with releasing channel. To work together inparallel, we set two parameters, handshake timeout N and handshake timeout S, asfollows:
Handshake Timeout S : RTS Tx time + propagation delay
where Tx represents the transmission time.With these parameters, when a node detects the interruption of RTS/CTS hand-
shaking, and if an extra frame is available, the extra frame will deliver a small dataas well as release the channel by virtue of NAV updating. Even if there are no ex-tra frames, RTS validation just releases the NAV. Therefore, complementing bothmechanisms together leads to improvement in channel efficiency.
3.4.4 Reverse Extra Frame Transmission
To allow the neighboring nodes, who overhear the RTS, we propose an aggressiveway of channel reuse by introducing a new type of extra frame called “reverse extraframe.” The timing to transmit it is same as that of releasing channel of RTS validation.So, it can be said to be a subset of RTS validation. The algorithm for combining theschemes, including reverse extra frame, is shown in Figure 3.8.
The idea stem from the fact that, generally speaking, once RTS frame has beensent, it is relatively free from collision for the duration specified in the RTS frame. Ifone of the neighboring nodes can send a frame to the sender, its frame is expected toreach successfully. To exploit this relatively safe period of time to reuse the channel,we allow the neighboring nodes to send an extra frame to the node that originates theRTS. Reverse extra frame transmission works as shown in Figure 3.9.
It is not possible to completely prevent the reverse extra frames from collisionbecause there can be several eligible candidates for sending an extra frame. To reducethe probability of collision, the following constraints are introduced:
� Reverse extra frame should be the first frame in the queue and be destined tothe node RTS frame had sent.
� The length of the duration in reverse extra frame should be smaller than thatof the duration specified in RTS.
� The node should have a short backoff timer that would have expired if nodedoes not receive RTS frame.
If an appropriate reverse extra frame is found, it will be sent immediately andwill be removed from the queue if the transmission is completed (confirmed by ACK
Overhear frame for
others from nodek
NAVk
Duration(RTS/DATA)
Yes
Is channel
idle for
Handshake_Timeout_N?
Start Sensing
the channel
Request to set NAV
Yes
NO
NAVother
specified value
Request to cancel NAV
Delete NAVk
NAV
NAVk
NAVother
max(
),
?
calculate the NAV
request to
set NAV
Request to
cancel NAVk
Yes
k
Remaining Backoff
Handshake_Timeout_N?
Is Reverse Extra
Frame available?
Yes
No
Sent RTS
Send Reverse
Extra Frame
Backoff
Backoff - Handshake_Timeout_N
Backoff
uniform(0, Backoff)
No
Normal Operation of IEEE 802.11
Handshake_Timeout_S
CTS return within
Yes
RTS/DATA frame?
frame?
Yes
No
No
Send
Extra Frame
Is RTS
Is
Is set by
EFT Scheme
Modified
RTS
Validation
Scheme
R-EFT Scheme
NAV updating Scheme
No
<
Fig
ure
3.8
Flow
char
tof
com
bina
tion
ofsc
hem
es.
55
56 An Intelligent Way to Reduce Channel Under-utilization in Mobile Ad hoc Networks
Figure 3.9 Reverse extra frame transmission.
from sender). Then, the node goes back to the normal operation, regardless of thesuccessful transmission of reverse extra frame.
We have earlier seen that even when RTS/CTS handshaking is interrupted, theneighboring nodes will be inhibited from transmitting. RTS validation can releasethe channel, but the nodes cannot recover from the loss incurred by the interruption.Because when the nodes sensed the channel as busy, their backoff timers were haltedand stopped decrementing during RTS/CTS handshaking.
When reverse extra frame is available, nodes can make up the above loss of time.Because without performing RTS/CTS handshaking, node transmits the data framethat is supposed to send in the near future. But due to the restriction imposed to preventcollision, reverse extra frame may not be always available. When there is no reverseextra frame to compensate the loss of time, we allow the nodes to decrement theirrespective backoff timer.
We allow those nodes to decrement the time equal to the “handshake timeout”from their respective remaining backoff timer. But for those nodes whose remainingtime of the backoff timer is less than or equal to the “handshake timeout,” to differtheir access to avoid collision, it will choose a uniform random backoff time from(0, current backoff time).
So, when reverse extra frame is not available, the nodes will decrease backofftimer for the deferred time as if it had not been interrupted. We can thus reduce thewaiting time for the node before transmitting and increase the throughput.
3.4.5 Compatibility with IEEE 802.11
CRTS [11] is releasing the NAV by introducing an extra frame. However, our schemeskeep the format unchanged. Thus, our proposed schemes are compatible with theexisting IEEE 802.11 standard. Even if there are stations that do not support ourenhancement, they will also work as well.
3.5 PERFORMANCE EVALUATION AND DISCUSSIONS
In this section we have discussed on performance evaluation and scenario used fornetwork simulation. We later explained and analyzed the results.
3.5 Performance Evaluation and Discussions 57
3.5.1 Simulation Scenario
The most widely recognized network simulator, ns-2 [16], is used to evaluate theeffectiveness of our mechanism. We compared the performance of standard IEEE802.11 [13], RTS validation [5], and our proposed enhancements.
The network model of a multihop wireless topology and routing protocol ad hocon demand distance vector (AODV) [15]. The link layer is a shared media radio withnominal channel bit rate of 1 Mbps. The antenna is omnidirectional with radio rangeof 250 m.
Traffic source and destination pairs are randomly spread over the network. Typeof traffic is constant bit rate (CBR) with packet size randomly chosen between 512and 2048 bytes, to prove that our evaluation process is not affected by the frame size.We have created 30 sets of CBR traffic. The sum of all the senders’ transmission rateis represented as offered load. For example, if the offered load is 600 kbps, then thetransmission rate of CBR traffic is 20 kbps.
The random waypoint model is used. In this model, a mobile station begins bystaying at one location for a certain period of time (we call this pause time). Oncethis time expires, this station chooses a random location in the simulation field witha random speed between [min speed, max speed], which is randomly selected withuniform probability. Each node moves according to random waypoint model withparameters max speed = 10 (m/s), min speed = 0 (m/s), and pause time = 50(s).
In each experiment, we run the simulation on the 1500 × 500 m2 field for 700 s.We start measuring from 100 s and up to 700 s. Each plot in these graphs is theaverage of at least 50 simulations. As a default parameter of each simulation, wedefine the number of stations as 50. And each node moves according to randomwaypoint with parameters max speed=10 (m/s), min speed = 0 (m/s), and pausetime = 50 (s).
3.5.2 Results and Analysis
In this section, we compare the performance between our proposed schemes withRTS validation. We ran our simulation in two different scenarios. In one, the offeredload varies between 200 and 800 kbps and in another, the number of nodes variesfrom 10 to 90.
We evaluate the effects of our schemes in terms of MAC layer throughput (Thmac)with above two scenarios. Thmac is computed as a summation of data frame sizesuccessfully sent by each node per unit time. Suppose, ui is the data frame size in bitsuccessfully transmitted by node i. If the total transmission time is t, then Thmac inbits per second (bps) is defined as:
Thmac =∑i=N
i=1 ui
t(3.1)
58 An Intelligent Way to Reduce Channel Under-utilization in Mobile Ad hoc Networks
450
500
550
600
650
700
750
800
850
900
200 300 400 500 600 700 800
Thr
ough
put (
kbps
)
Offered load (kbps)
RTS Validation and REFT and NAV updating and EFTRTS Validation and REFT and NAV updating
RTS Validation with NAV updatingRTS Validation
EFT with NAV updatingEFT
Figure 3.10 MAC layer throughput (Thmac) comparison as a function offered load.
Firstly we confirm the comparison of throughput (Thmac) as a function of offeredload in Mac layer for six different combinations of schemes in Figure 3.10. Figure 3.10shows that NAV update scheme improves the Thmac of extra frame and RTS validation.RTS validation with NAV updating is more effective than extra frame with NAVupdating due to the increase in the occurrence in the channel release. RTS validationincluding its variants (RTS validation with NAV updating and reverse extra frame)yield high performance on proposed combination schemes.
On the other hand, when the number of nodes is varying, Figure 3.11 shows,Thmac of RTS validation including its variants is rapidly decreasing with the increase
350
400
450
500
550
600
650
700
750
800
850
900
10 20 30 40 50 60 70 80 90
Thr
ough
put (
kbps
)
Node density (# of nodes in the field)
RTS Validation and REFT and NAV updating and EFTRTS Validation and REFT and NAV updating
RTS Validation with NAV updatingRTS Validation
EFT with NAV updatingEFT
Figure 3.11 MAC layer throughput (Thmac) as a function of node density.
3.5 Performance Evaluation and Discussions 59
in the number of nodes. In worst case, the performance of RTS validation is less thanthat of extra frame with NAV updating. This is because RTS validation and its variantsare based on physical carrier sensing; they are very much sensitive to the number oftransmission in the networks.
Even in above severe condition, extra frame can keep improvement level higherdue to its two-fold advantage of sending extra frame and releasing the channel. Thecombination of EFT and R-EFT shows a much steadier nature even with increase inthe number of nodes. The improvement is more visible when the number of nodes is60 or more. Therefore, combination of RTS validation and its variants and extra frameworks in a complementary style. This leads to high performance in both scenarios.
In our proposed combination of schemes, we reused the channel as aggressivelyas possible. So, in order to verify whether there is any degradation in reliability bythis enhancement, we measured the delivery rate of each unicast frame.
Packet delivery ratio (PD) is computed as:
PD =∑i=N
i=1 Ri∑i=N
i=1 Si
(3.2)
Si is the total data size of unicast data frame node i sent and Ri the total data sizeof ACK frame node i received.
Figure 3.12 and Figure 3.13 show CBR packet delivery rate as a function ofoffered traffic load and node density for RTS validation and IEEE 802.11.
In both scenarios, when RTS/CTS is not interrupted frequently, all schemes havesimilar packet delivery ratios. As the interruption of RTS/CTS handshaking becomesmore frequent, our combined scheme yields a higher packet delivery ratio than theothers in both scenarios. In high nodes density scenario, especially when interrup-
0.180
0.185
0.190
0.195
0.200
0.205
0.210
0.215
0.220
0.225
0.230
200 300 400 500 600 700 800
Fra
me
deliv
ery
rate
(#
of A
CK
fram
e / #
of s
ent f
ram
e)
Offered load (kbps)
RTS Validation and REFT and NAV updating and EFTRTS Validation
IEEE 802.11
Figure 3.12 Frame delivery rate as function of offered load.
60 An Intelligent Way to Reduce Channel Under-utilization in Mobile Ad hoc Networks
0.170
0.180
0.190
0.200
0.210
0.220
0.230
0.240
10 20 30 40 50 60 70 80 90
Fra
me
deliv
ery
rate
(#
of A
CK
fram
e / #
of s
ent f
ram
e)
Node density (# of nodes in the field)
RTS Validation and REFT and NAV updating and EFTRTS_Validation
IEEE 802.11
Figure 3.13 Frame delivery rate as a function of node density.
tion of RTS/CTS handshaking occurs more frequently, our scheme’s packet deliveryratio is higher than those of other schemes. This is because reusing the wasted channelaggressively enables nodes to deliver more packets in a stable manner, consequentlyincreasing the packet delivery ratio. These results show that regardless of whetherchannels are released/reused aggressively, our combination of schemes does notadversely effect packet delivery ration.
3.6 SUMMARY
In this chapter we have shown that our proposed schemes can overcome the in-herent channel inefficiency of RTS/CTS handshaking in mobile ad hoc networks,especially when node density is high and interruption is frequent. At the same time,our enhancements do not suffer from any compatibility problems and generate noadditional overhead, which is vital for smooth deployment. Results obtained fromextensive simulations show that our combined method considerably improves thethroughput compared to standard IEEE 802.11 and the RTS validation scheme. Thus,we can confirm that such smart approach can improve channel utilization in wirelesscommunication.
REFERENCES
1. P. Karn, MACA: – A new channel access method for packet radio. In Proceedings the 9th ARRLComputers Networking Conference, Ontario, Canada, September 1990.
2. V. Bharghavan, A. Demers, S. Shenker, and L. Zhang, MACAW: A media protocol for wireless LANs.In Proceedings of the ACM SIGCOMM’94, London, UK, September 1994.
References 61
3. S. Xu and T. Saadawi. Does the IEEE 802.11 MAC protocol work well in multihop wireless ad hocnetworks? In Proceeding of IEEE Commun. Mag., 39(6):130–137, 2001.
4. Y. Wang and J. J. Garcia-Luna-Aceves. Collision avoidance in multihop ad hoc networks. In Proceed-ings of the IEEE/ACM MASCOT’02, Texas, USA, October 2002.
5. S. Ray, J. Carruthers, and D. Starobinski. Evaluation of the masked node problem in ad-hoc wirelessLANs. IEEE Trans. Mobile Comput., 4(5): pp. 430–442, 2005.
6. A. Chayabejara, S.M.S. Zabir, N. Shiratori, An enhancement of the IEEE 802.11 MAC for multihopad hoc networks, In Proceedings of IEEE Vehicular Technology, 2003 Fall, Florida, USA. October6–9, 2003.
7. L. Kleinrock and F. A. Tobagi, Pakcet switching in radion channels: Part 1. Carrier sense multipleaccess modes and their throughput-delay characteristics. IEEE Trans. Commun., COM-23(12):1400–1416, 1975.
8. L. Kleinrock and F. A. Tobagi, Pakcet switching in radion channels: Part 2. The hidden node problemin carier sense multiple access modes and the busy tone solution. IEEE Trans. Commun., COM23(12):1417–1433, 1975.
9. V. Bharghavan, Performance evaluation of algorithms for wireless medium access. In IEEE Perfor-mance and Dependability Symposium ’98, IEEE, Raleign, NC 1998.
10. T. Shigeyasu, T. Hirakawa, H. Matsumo, and N. Morinaga. Two simple modifications for improv-ing IEEE 802.11 DCF throughput performance. In IEEE Wireless Communication and NetworkingConference (WCNC), 2004.
11. T. Harada, C. Ohta, M. Morii. Improvement of TCP throughput for IEEE 802.11 DCF in wirelessmulti-hop networks. IEICE Trans. Commun., J85-B(12):2198–2208, 2002.
12. G. Bianchi, Performance analysis of the IEEE 802.11 distributed coordination function. IEEEJ. Select. Areas Commun., 18(3):535–547, 2000.
13. IEEE Standard for Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Speci-cation. IEEE Std. 802.11, August 1999. [Online]. Available: http://standards.ieee.org/getieee802/802.11.html
14. H. Wu, Y. Peng, K. Long, S. Cheng, and J. Ma, Performance of reliable transport protocol OverIEEE 802.11 wireless LAN: Analysis and enhancement. In Proceedings of the IEEE INFOCOM’02,June 2002.
15. C. E. Perkins, E. M. Royer, and S. Das, Ad hoc on-demand distance vector (AODV) Routing, RFC3561, July 2003. [Online]. Available: ftp://ftp.rfc-editor.org/in-notes/rfc3561.txt
16. The Network Simulator Version 2 (ns–2), [Online]. Available: http://www.isi.edu/nsnam/ns/
