Romit TMC Directional

8/13/2019 Romit TMC Directional

1/15

On Designing MAC Protocols for WirelessNetworks Using Directional Antennas

Romit Roy Choudhury, Student Member , IEEE , Xue Yang, Member , IEEE ,Ram Ramanathan, Senior Member , IEEE , and Nitin H. Vaidya, Senior Member , IEEE

Abstract We investigate the possibility of using directional antennas for medium access control in wireless ad hoc networks.Previous research in ad hoc networks typically assumes the use of omnidirectional antennas at all nodes. With omnidirectionalantennas, while two nodes are communicating using a given channel, MAC protocols such as IEEE 802.11 require all other nodes inthe vicinity to remain silent. With directional antennas, two pairs of nodes located in each others vicinity may potentially communicatesimultaneously, increasing spatial reuse of the wireless channel. Range extension due to higher gain of directional antennas can alsobe useful in discovering fewer hop routes. However, new problems arise when using directional beams that simple modifications to802.11 may not be able to mitigate. This paper identifies these problems and evaluates the tradeoffs associated with them. We alsodesign a directional MAC protocol (MMAC) that uses multihop RTSs to establish links between distant nodes and then transmits CTS,DATA, and ACK over a single hop. While MMAC does not address all the problems identified with directional communication, it is anattempt to exploit the primary benefits of beamforming in the presence of some of these problems. Results show that MMAC canperform better than IEEE 802.11, although we find that the performance is dependent on the topology and flow patterns in the system.

Index Terms Directional antennas, medium access control, wireless ad hoc networks, deafness.

1 INTRODUCTION

THE problem of utilizing directional antennas to improvethe performance of ad hoc networks is nontrivial.Directional antennas can provide higher gain and reduceinterference by directing beamforms toward a desireddirection. However, they also pose challenges in the designof medium access control (MAC) protocols. A directionaltransmission, due to its greater transmission range, may

potentially interfere with communications taking place faraway. Previous research on MACprotocols using directionalantennas has assumed an equal transmission range whenusingdirectional and omnidirectional beamforms. However,this prevents exploiting thepotential of directional antennas,especially the possibility of replacing many small hopcommunication links with one long, single hop link.

By using directional antennas, a node may also be able toselectively receive signals only from a certain desireddirection. This enables the receiver node to avoid inter-ference that comes from unwanted directions, therebyincreasing the signal to interference and noise ratio (SINR).However, due to selective reception of signals, a node Amight not be aware of some other node, B , attempting toinitiate communication with it. Node B , receiving noresponse from node A, would continue to retransmit,

wasting channel capacity in unproductive control packettransmission. Thus, the question of whether directionalantennas improve the performance of an ad hoc network isnot straightforward, but requires close examination of issues involved in channel access. The contribution of thispaper lies in identifying the fundamental problems withdirectional medium access control, evaluating their impact

on network performance, and in proposing a protocol-design that attempts to maximize the benefits of directional beamforming.

This paper is organized as follows: In Section 2, wediscuss related work on medium access control usingdirectional antennas, including a brief summary of IEEE 802.11. We describe our antenna model in Section 3.The problem under consideration is discussed in Section 4.In Section 5, we describe a basic Directional MAC (DMAC)protocol that is similar to 802.11, but adapted for directionalantennas. Section 6 identifies several problems with BasicDMAC and proposes a simple variation called DMAC-I. InSection 7, we propose a multihop RTS protocol. We

compare the performance of our proposed protocols withIEEE 802.11 in Section 8. We discuss some of the issues withDMAC/MMAC in Section 9 and summarize the paper inSection 10.

2 R ELATED WORKThe use of directional or beamforming antennas has beenextensively studied in the context of broadband and cellularnetworks [2], [1], [34]. Recently, attention has been focusedon the possibility of using directional antennas for mediumaccess control in multihop networks [4], [9], [13], [19], [25],[14], [24], [31], [32], [35]. In principle, many of the proposed

protocols are similar to IEEE 802.11, carefully adapted for

IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 5, NO. 5, MAY 2006 477

. R.R. Choudhury, X. Yang, and N.H. Vaidya are with the Department of Computer Science, Coordinated Science Laboratory, University of Illinoisat Urbana-Champaign, 1308 West Main Street, Urbana, IL 61801.E-mail: {croy, xueyang, nhv}@uiuc.edu.

. R. Ramanathan is with Division Scientist, Internetworking ResearchDepartment, BBN Technologies, 10 Moulton St., Cambridge, MA 02138.E-mail: [email protected].

Manuscript received 29 Jan. 2004; revised 18 Sept. 2004; accepted 8 Dec.2004; published online 15 Mar. 2006.For information on obtaining reprints of this article, please send e-mail to:

[email protected], and reference IEEECS Log Number TMC-0017-0104.1536-1233/06/$20.00 2006 IEEE Published by the IEEE CS, CASS, ComSoc, IES, & SPS


2/15

use over directional antennas. We present a brief overviewof IEEE 802.11, followed by a discussion of the existingprotocols for directional medium access control.

2.1 IEEE 802.11 Distributed Coordinated Function(DCF)

In the IEEE 802.11 MAC protocol [16], an exchange of

request to send(RTS)/clear to send(CTS) precedes DATAcommunication. Both RTS and CTS packets contain theproposed duration of transmission. Nodes located in thevicinity of communicating nodes, which overhear either of these control packets, must themselves defer transmissionfor the proposed duration. This is called Virtual CarrierSensing and is implemented through a mechanism calledthe Network Allocation Vector (NAV). A node updates thevalue of the NAV with the duration field specified in theRTS or CTS. Thus, the area covered by the transmissionrange of the sender and receiver is reserved for data transferto overcome the hidden terminal problem [17].

IEEE 802.11 is a CSMA/CA protocol that performs physical carrier sense before initiating transmission. Once thechannel is sensed as idle for a DIFS (DCF interframespacing) duration, 802.11 invokes a backoff mechanism forcontention resolution. A node S chooses a random backoff interval from a range [0, CW], where CW is called theContention Window. CW is initialized to the value of CW min .Node S then decrements the backoff counter once every idleslot time. When the backoff counter reaches 0, node Stransmits the RTS packet. If the transmission from S collideswith some other transmission (collision is detected by theabsence of a CTS), S doubles its CW, counts down a newlychosen backoff interval, and attempts retransmission. TheContention Window is doubled on each collision until itreaches a maximum threshold, called CW max . While in the backoff stage, if a node senses the channel as busy, it freezesits backoff counter. When the channel is once again idle fora duration called DIFS, the node continues counting downfrom its previous (frozen) value.

2.2 MAC Using Directional AntennasThe design of IEEE 802.11 implicitly assumes an omnidir-ectional antenna at the physical layer. Although 802.11 mayoperate correctly when using directional antennas, perfor-mance may get affected [15], [30]. Recently, several MACprotocols have been proposed that suitably adapt 802.11 for beamforming antennas [5], [22], [29], [30]. Ko et al. [19]have proposed to transmit an RTS directionally, only if theRTS does not collide with other ongoing communications.Kobayashi and Nakagawa [20] propose a similar mechan-ism in which NAVs are assigned on a per sector basis. TheDNAV mechanism [11] described later in this paper isderived from the above observation. Nasipuri et al. [23]propose to reduce the interference in the wireless channel by communicating directionally. However, their proposalsrequire the transmission of an omnidirectional CTS toinform the receivers neighborhood about the imminentdialog. This offsets spatial reusea key advantage of usingdirectional antennas. In [13], Elbatt et al. propose aninteresting ideathey use RTS/CTS to inform the neighborhood about the beam indices to be used for theimminent communication. Based on this information,

neighbors of the communicating nodes decide which

beams may be used for initiating their own RTS packets.Bandyopadhyay et al. [3] present another MAC protocolthat informs neighborhood nodes about ongoing commu-nications through additional control messages. In addition,the protocol assumes knowledge of network traffic.

Takai et al. [33] proposes Directional Virtual CarrierSensing (DVCS) and DNAV mechanisms similar to the

notion of DNAV in our Basic DMAC protocol [12],described in Section 5. We identify several problemsaffecting this protocol. We also propose a new MACprotocol for directional antennas.

In [25], Ramanathan presents an interesting discussion onseveral issues arising fromdirectional communication. In thispaper, we identify several other problems, namely, hiddenterminals, deafness, etc., that have not been identified in thepast. We discuss how these problems may affect theperformance of the MAC protocol and explain why theymay be hard to alleviate with simple modifications to 802.11.Workreportedinthispaperhasbeenpublishedinpartin[12].Later, several authors have aimed to address these problemsand designed new directional MAC protocols. Korakis et al.[21] attempt to address the problems arising from directionalantennas, including deafness. To inform neighbors of acommunicating node pair, the authors propose to transmitdirectional RTS/CTS packets on every beam. Transmittingmultiple RTS/CTS packets for each transmitted data packetmay alleviate the impact of deafness, but at the cost of highcontrol overhead. In [10], we addressed the problem of deafness separately, by using subband tones to notify theneighbors of a communicating node of its activity. While thisscheme shows encouraging performance, the receiver hard-ware necessary to implement it may be relatively complex.

There is some ongoing work in implementing testbedsthat utilize directional/beamforming antennas for network-ing. Ramanathan et al. have demonstrated how directionalantennas can offer up to factors of 10 improvement inthroughput [26]. In [8], Choudhury et al. have designed aprototype and have studied individual aspects of beam-forming (deafness, spatial reuse, etc.) from the MAC androuting perspectives. In [6], Bhagwat et al. present thechallenges faced in implementing a rural network using802.11 and directional antennas. They discuss how rangeextension capabilities of directional antennas may beutilized heavily in specific outdoor environments. Severalother efforts, also underway in mesh networking commu-

nities [7], [18], indicate the rising interest in utilizingdirectional antennas more effectively for wireless networks.

3 P RELIMINARIES3.1 Antenna ModelWe have incorporated a steerable antenna model 1 at theradio layer of the Qualnet simulator [13]. The antennasystem offers two modes of operation: Omni and Directional(imagine two passive antennas, attached to a singletransceiver). A node resides in the Omni mode when it

478 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 5, NO. 5, MAY 2006

1. Although we model a steerable antenna, our discussions on mediumaccess control in this paper can be generalized to other types of antennas

like switched beam antennas.


3/15

does not know the direction from which a signal mightarrive. Once a signal is detected, the antenna begins toreceive the signal with an omnidirectional gain, Go. Whilethe signal is being received, the antenna performs anazimuthal steer and selects the beam on which theimpinging signal power is maximum. This beam is thencached at the receiver and may be used in the near future

for communicating back to the transmitter. Of course, whiletransmitting for the first time, the MAC layer needs tospecify the direction in which the antenna must steer its beam. In general, other beamforming parameters liketransmission power could also be specified. A tuple compris-ing all these beamforming parameters is called a transceiver profile. Since we do not consider power control and weassume a fixed beamwidth for this paper, our transceiverprofiles include only the direction of transmission.

Observe that, when using directional beams for commu-nicating (transmitting or receiving), the main lobe gain inthe direction of the beam is Gd . Typically, Gd Go. TheFriss Equation represents how transmit and receive gains(GT and GR ) are related to the transmit and receive powers

(P T and P R ) [27]:

P R P T GT GR

Kr :

The term K is a constant that accounts for atmosphericabsorption, ohmic losses, etc., r (greater than some r 0 ) is thedistance between the transmitter and the receiver, and isthe path-loss index ( 2 4 ). Note that GT and GR aretransmit and receive gains along the straight line joining thetransmitter and receiver. Observe from the equation that themaximum distance, r, over which two nodes can commu-nicate, increases with increase in transmit and the receivegains. Of course, the increase is not linear and depends onthe path-loss index, as evident from reorganizing the aboveequation as

r P T GT GR

KP R 1 =

:

When compared to omnidirectional antennas, directionalantennas will offer range extension capabilities. Putdifferently, two nodes in omni mode may be out of communication range because the product of their omni-directional transmit and receive gains, Go Go, is notlarge enough. However, if one of the nodes beamforms inthe direction of the other, the new product, Gd Go, may be sufficiently large to enable direct communication. More-over, nodes that beamform toward each other with gainproduct Gd Gd may be able to communicate directlywith each other over a distance greater than what is possiblewhen only one (or none) of them is beamformed (becauseGd Gd Gd Go Go Gd Go Go). As shown later,the benefits of range extension when using directionalantennas can be significant, compensating for the losses thatarise due to channel access overheads.

Relating to 802.11, a transmitter can transmit the RTSdirectionally, assuming that it is aware of the direction of its intended receiver. Since the receiver does not know apriori who the transmitter might be, it cannot receive theRTS directionally. The receiver receives the RTS omnidir-ectionally and performs the azimuthal scan in parallel to

obtain the best beam for this transmitter. Thereafter, the

CTS, Data, and ACK packets can be transmitted andreceived directionally. However, since we assume that theRTS must be received omnidirectionally, the maximumdistance between two communicating neighbors is dictated by the gain product Gd Go.

4 P ROBLEM FORMULATIONThe IEEE 802.11 protocol limits spatial reuse of the wirelesschannel by silencing all nodes in the neighborhood of thesender and receiver. Using directional antennas, however, itis possible to carry out multiple simultaneous transmissionsin the same neighborhood. In Fig. 1, simultaneous commu-nication between node pairs A; B and C; D is possible,provided the beamwidth of the directional transmissions isnot very large. However, simultaneous communicationfrom E to F and from A to B is not possible.

Due to higher gain, directional antennas have a greatercommunication range than omnidirectional antennas. Thisenables two distant nodes to communicate over a singlehop. From the perspective of routing, routes using direc-tional antennas may contain fewer hops than what may bepossible using omnidirectional antennas. In this paper, wedo not consider transmit power control, not because it isirrelevant, but because the problem of directional mediumaccess control is by itself rich, even without power control.Future work would address power control as well.

A MAC protocol for directional antennas should attemptto exploit both the benefits of directionality, namely, spatialreuse and higher communication range. The Basic DMACprotocol described in the next section attempts to improvespatial reuse of the channel. In addition, the basic DMACprotocol offers useful insight into the key problems thatarise from directionalityproblems that we believe would be broadly applicable to directional MAC protocols in

general. The MMAC protocol presented in Section 7attempts to exploit the higher communication range of directional antennas by attempting to form the longestpossible links. This is achieved by propagating an RTS overmultiple hops and then transmitting CTS, DATA, and ACKdirectionally over a single hop. We describe the protocols inthe subsequent sections.

5 B ASIC DMAC P ROTOCOLWe use the term Basic Directional MAC or Basic DMAC [12]to refer to the MAC protocol for directional antennasdescribed in this section. In designing MAC protocols, we

assume that an upper layer is aware of the neighbors of a

CHOUDHURY ET AL.: ON DESIGNING MAC PROTOCOLS FOR WIRELESS NETWORKS USING DIRECTIONAL ANTENNAS 479

Fig. 1. An example topology scenario.


4/15

node and is capable of supplying the transceiver profilesrequired to communicate to each of these neighbors. TheDMAC protocol receives these transceiver profiles from theupper layers along with the packet to be transmitted. TheBasic DMAC protocol [12] presented here generalizes theideas in [19] and is similar to the DVCS mechanismproposed by Takai et al. [33] and a protocol proposed in

[2]. Later in this paper, we point out the shortcomings of theBasic DMAC protocol and also compare its performancewith the MultiHop RTS MAC protocol proposed inSection 7. In principle, Basic DMAC is similar to IEEE802.11, adapted for use over directional antennas.

5.1 Channel ReservationChannel reservation in Basic DMAC is performed using aRTS/CTS handshake, both being transmitted directionally.An idle node listens to the channel omnidirectionally (i.e., itis in the Omni mode). When it receives a signal arriving froma particular direction, it locks onto that signal and receivesit. Please note that while a node is in the Omni mode and isreceiving the signal, it is susceptible to interference from alldirections. Only when the node has beamformed in aspecific direction can it avoid the interference from otherdirections. In describing the Basic DMAC protocol, we referto a sender node as node S and the receiver node as node R.

5.1.1 RTS Transmission The MAC layer at node S receives a packet from its upperlayers along with the transceiver profile T p to be used fortransmission. Having received this, DMAC requests thephysical layer to beamform according to the transceiverprofile T p. Let us denote this beamform by B R since this beam points in the direction of node R. To detect whether itis safe to transmit using beam B R , node S now performsphysical carrier sensing using B R . If the channel is sensedidle, DMAC checks its Directional NAV Table (or DNAV,explained in the next section) to find out whether it mustdefer transmitting in the direction of node R. The DNAVtable, as explained in the following section, maintains avirtual carrier sense status for every Direction of Arrival (DoA)in which it has overheard a RTS or CTS packet. Once node S finds that it is safe to transmit using B R , it enters the backoff phase (similar to 802.11). While in the backoff phase, BasicDMAC requires node S to remain in the directional mode.When the backoff counter counts down to zero, DMAC atnode S sends down the RTS control packet to the physicallayer, meant to be transmitted to node R using beam B R .

5.1.2 RTS Reception and CTS Transmission A node when idle remains in the Omni mode, listening tothe channel omnidirectionally. The antenna system iscapable of determining the direction of arrival (DoA) of this incoming signal. Let us assume that node R is in theOmni mode and is able to receive the RTS from node S withDoA denoted by D SR .

Nodes other than R, say X i , that also receive the RTSupdate their respective DNAV tables with the capturedDoAs (note that the DoA captured by node X i would beDSX i ). This prevents node X i from transmitting any signalin the reverse direction of D SX i (i.e., D X i S ). Node X i defers

all transmissions directed toward a certain range of

directions around D X i S . We discuss the details later in ourdiscussions on DNAV. These nodes also update the DNAVtable with the transfer duration specified in the RTS packet.

Having received the RTS from S , node R determines thedirection DRS to send the CTS in response. If the DNAVtable at R permits transmissions in the direction D RS , thenthe DMAC at node R requests the physical layer to beamform in this direction. Let this beam be denoted byB S since it is directed toward node S . The physical layer atnode R senses the physical channel using B S for SIFS timeslots. If the channel remains free during this interval, theCTS is transmitted using beam B S . If the carrier is sensed busy during the SIFS period, CTS transmission is canceled(similar to 802.11).

5.1.3 CTS Reception and DATA/ACK Exchange The sender node S , meanwhile, waits for the CTS using the beam B R that it had used to send the RTS. If the CTS doesnot come back within a CTS-timeout duration (calculated asin 802.11), then S schedules a retransmission of the RTS. If S receives the CTS, it initiates the transmission of DATAusing beam B R . Node R, on receiving the DATA success-fully, transmits an ACK using beam B S . Nodes other than S and R that receive the CTS, DATA, or ACK update theirDNAV table with the respective DoAs and the durationspecified in the packet, as elaborated below.

5.2 Directional NAV (DNAV) TableThe Network Allocation Vector (NAV) is a status variablemaintained by the IEEE 802.11 MAC for virtual carriersensing. The value of the NAV is updated from theduration field of overheard packets. The value of NAVindicates the duration for which the node must defer

transmission to avoid interfering with some other transmis-sion in the vicinity.Using directional antennas requires that the NAV be

directional as well [19], [25], [11], [33]. To put it differently,if a node receives an RTS or a CTS from a certain direction,then it needs to defer only those transmissions that aredirected in (and around) that direction. A transmissionintended toward some other direction may be initiated. TheDirectional NAV Table (DNAV) is a table that keeps track of the directions (and the corresponding durations) towardwhich a node must not initiate a transmission. We illustratethis with a simple example with reference to Fig. 1. Assumethat communication between nodes A and B is in progress,

with A transmitting to B . During this interval, if node E hasa packet to send to F , it must check its DNAV table to checkif it is safe to transmit in the direction of F . However, notethat node E would have already received a CTS from nodeB and updated its DNAV table. Thus, on checking theDNAV table, E finds that it is unsafe to transmit in thedirection of F . However, if E had a packet to send to D , theDNAV check would indicate that it is safe to transmit. Inthat case, E can proceed to transmit toward D. At this point,we would like to mention that even if F was a littledisplaced and the line joining EF did not coincide exactlywith the line joining EB , E might still need to defertransmission to F in order to avoid interfering at B .

Specifically, in Basic DMAC, node E defers transmission



5/15

toward F if the angle between EF and EB is less than somethreshold, . We illustrate with the help of Fig. 2. Weassume that all nodes transmit with a beamwidth of 2 degrees. Now, if node E has overheard an RTS or CTSfrom node B , it updates the DNAV table with the directionDEB . Now, if E wants to send a packet to node H , then itmust beamform in the direction of DEH to transmit the RTS.Node E checks whether the angle between DEB and DEH isgreater than a threshold , where is as following:

2 ;

where is the angular separation of the edges of thetwo beamforms. If is negative then the two beamformsmay overlap. The accurate choice of depends on theradiation pattern of the antenna in use. If the gain of themainlobe reduces sharply with increasing angular separa-tion from the mainlobe direction, then the value of can besmall. This is because lesser interference will be emanatingin directions away from the mainlobe direction, allowingfor lesser spatial separation between adjacent communica-tions. For our simulations, we have assumed to be zero inview of the sharp beam pattern used.

6 P ROBLEMS WITH BASIC DMACIn this section, we discuss some channel access problemswith Basic DMAC that may arise with other directionalMAC protocols as well.

6.1 Hidden Terminal ProblemsThe well-known hidden terminal problem in multihopwireless networks can be resolved by the exchange of RTS/CTS control packets as in MACA [17] and 802.11. However,the RTS/CTS exchange assumes that these packets aretransmitted omnidirectionally. Directional transmission of RTS/CTS introduces two new kinds of hidden terminals,discussed below.

6.1.1 Hidden Terminal Due to Asymmetry in Gain Consider Fig. 1. Assume that all nodes in this figure arecurrently idle. Nodes in their idle state ( Omni mode) have again of Go. Now, assume that node B transmits a

Directional RTS (DRTS) to node F , and F responds with a

Directional CTS (DCTS). Assume that node A (still in omnimode) is far enough from node F not to hear this DCTS.DATA transmission begins from node B to F , both nodespointing their transmission and reception beams with again Gd . Node A cannot sense this transmission. While thiscommunication is in progress, assume that node A has apacket to send to node E . Node A senses the channel with adirectional beam (of gain Gd ) pointed toward E andconcludes that the channel is idle. Subsequently, it sendsa DRTS to node E . However, since node F is receivingDATA with a gain Gd with a beam pointed toward node B(and node A), it is possible that the DRTS from A interferesat node F . In other words, sender and receiver nodes withtransmit and receive gain of Gd and Go, respectively, may be out of each others range, but may be within range if they both transmit and receive with gain Gd (note that Gd isgreater than Go).

While such hidden terminal problems are possible, closerexamination revealed that they may not be frequent.Considering the example in Fig. 1, node A may not always

interfere with packet reception at node F (from B ) becausenode A will almost certainly be further away from F than B .If node F locks on to signals from node B , then interferingat F can be rareto interfere, A must be far enough from B to not sense B 0s transmission through B 0s backlobes, and yetneeds to be close enough to F to cause a collision.

6.1.2 Hidden Terminal Due to Unheard RTS/CTS Assume that in Fig. 1, E is transmitting a packet to D. Whilethis transmission is in progress, node B sends a RTS tonode F . F responds with a CTS. Although E may be withinthe transmission range of F , it does not receive the CTS,since it is beamformed in the direction of D. On receivingthe CTS from F , B starts transmitting data to F . Whilecommunication between B and F is in progress, assumethat E finishes transmitting to D and now wants to transmitto F (or any other node in the direction of F ). E 0s DNAVtable indicates that it is free to transmit toward F and onperforming physical carrier sense, E finds that the channelis idle. E transmits the RTS and a collision occurs at F (sinceF 0s receiving beam is pointing in the direction of E ). Thiskind of hidden terminal problems can be frequent withdirectional communications, but may not arise in the case of omnidirectional transmissions. With omnidirectional trans-missions, node B may be aware of the ongoing transmissionfrom E . This would prevent B from transmitting the RTSwhile E is engaged in communication. This clearly suggestsa potential tradeoff between spatial reuse and collisionswhen using directional antennas.

6.2 UnderutilizationWhen using Basic DMAC, the communication range is bounded by the product of Gd Go. This is because an idlereceiver receives a directional RTS in the omni mode.However, as discussed earlier, it is possible for nodes tocommunicate over a longer range if both the transmitterand the receiver could agree to beamform at each other atthe same time. In such a case, the communication rangewould be greaterbounded by Gd Gd (Gd Go). BasicDMAC fails to exploit this potential of range extension,possible when all nodes are in the network are equipped

with directional antennas.


Fig. 2. An example where node E wishes to send a packet to H while ithas a DNAV entry for direction DEB . The figure shows a condition wherenode E can safely transmit to node H , since it would not interfere withnode B 0s communication.


6/15

6.3 DeafnessAnother drawback of directional beamforming is deafness.We explain deafness using the scenario in Fig. 3. Assume

that node C and B have packets to send to node A (node A being the common receiver for both the flows). At any giveninstance, if A is receiving B 0s packet, C would be unawareof it (when using Basic DMAC) and may transmit an RTSmeant for A. Since A would be beamformed in the directionof B , A does not receive the RTS and, consequently, doesnot respond with a CTS. Node C , on receiving no responsefrom A, doubles its contention window, chooses a new backoff interval from the new window, and begins countingdown. When the countdown reaches zero, C retransmits theRTS. Retransmissions can go on multiple times until A hasfinished the dialog with B and has switched back to theomni mode. Unproductive retransmissions from C is anoutcome of deafness.

Now, consider the case where B has multiple packets tosend to A. Once B has finished transmitting the first packet,it immediately prepares to transmit the next packet bychoosing a backoff interval from the minimum contentionwindow 0 ; CW min . It is likely that node C is still engaged inthe backoff phase when B finishes counting down its small backoff value for the second packet. B acquires channelaccess. This can continue for a long time, causing C to dropmultiple packets before it gets fortunate enough to stealchannel access from B . After this point, B encountersrepeated deafness and continues to drop packets whenever

it exceeds the retransmission threshold. Multiple packet

drops at the source node, without actual congestion or linkfailure, can adversely affect performance. Higher layerprotocols that use packet drops as indicators of the networkcondition may be misled. End-to-end throughput andlatency can degrade. Deafness also leads to short-termunfairness between flows that share a common receiver.

Now, consider another case in which node C intends tosend packets to A and A intends to originate packets meantfor B . In other words, node A is both a receiver and a trafficoriginator. Also, assume that both the originators of theflows (C and A) are always backlogged. Observe that onceA has finished transmitting a packet, it beamformsimmediately in the direction of B , carrier senses, and begins counting down the backoff interval in the directionalmode (as required by Basic DMAC). Clearly, while back-logged, A would almost always remain in the directionalmode, forcing C to drop all packets during the interval.Since C continues to remain beamformed toward A whileattempting transmission, another node, say, D, trying tocommunicate to C , may also experience prolonged deaf-ness. A chain is possible in which none of the nodescommunicate successfullya deadlock. This is a seriousproblem, caused when the intended receiver of a node isitself a traffic originator.

6.4 Variation to Basic DMACThe possibility of deadlock can be pronounced in the caseof ad hoc networks because nodes that forward traffic on behalf of other nodes may also originate data trafficthemselves. A simple modification to Basic DMAC canreasonably address this problem. Observe that the problemof deadlock arises primarily because the deaf node(node A in our example in Fig. 6) always remains

beamformed toward its intended receiver. Put differently,node A performs carrier sensing, backoff, transmission, andretransmission, all in the directional mode. This deprivesnode C of the chance to communicate to A . We propose avariation to Basic DMAC in which nodes switch back to theomnidirectional mode while counting down their backoff values. Once the backoff timer expires, a node beamformstoward its intended receiver and initiates transmission.While backing off in the omnidirectional mode, a nodesenses the carrier busy only if a signal arrives from thedirection in which the node intends to transmit. However, if an RTS or CTS arrives from other directions, a node will becapable of receiving them. This mitigates the deadlock

problem. However, the possibility of a hidden terminal problem due to asymmetry in gain increases if nodes remain inthe omnidirectional mode while backing off, but, asdiscussed earlier, the possibilities can be small. The tradeoff is evaluated in Section 8, where we refer to this variation of Basic DMAC as DMAC-I.

7 MULTIHOP RTS MAC P ROTOCOLIn this section, we enhance Basic DMAC by proposingMultiHop RTS MAC (MMAC). While Basic DMAC wasmotivated by the possibility of higher spatial reuse,MMAC attempts to exploit the extended communication

range of directional antennas while achieving spatial reuse


Fig. 3. An example scenario depicting the possibility of deafness.


7/15

comparable to the Basic DMAC protocol. Although deafnessand hidden terminals problems still exist in MMAC (wehave addressed the problem of deafness separately in [10]), better use of directional capabilities in MMAC cancompensate for their negative impact, leading to improve-ment in performance as observed in later sections. Toillustrate the benefit of utilizing extended communicationrange, let us refer to Fig. 4. Assume that all the nodes areidle (i.e., in the Omni mode). Also assume that if Atransmits directionally, only B , G, and D would be able toreceive the signal while they are in their Omni mode.However, a communication may directly take place between A and F if both A and F are pointing their beams toward each other. With the protocol below, suchdirect communication between nodes A and F is possible.

7.1 Protocol Description: Multihop RTSFor describing the multihop RTS protocol, we definetwo kinds of neighbors: DO-neighbors and DD-neighbors.

. Direction-Omni (DO) Neighbor: A node B is a DO-neighbor of a node A if node B can receive adirectional transmission from A even if B is in theOmni mode.

. Direction-Direction (DD) Neighbor: A node B is a DD-neighbor of a node A if node B can receive adirectional transmission from A when node B is beamformed in the direction of node A. A DD-neighbor of a node may also be reached using aroute through other nodes such that adjacent nodeson the route are DO-neighbors. We call such a routea DO-neighbor route. It may be noted that DD-neighbors are capable of single hop communication,since they can form a direct link between them. Also,note that all DO-neighbors are also DD-neighbors, butnot necessarily vice versa.

In the above notation, DO is an abbreviation for Direc-tional-Omni and DD is an abbreviation for Directional-Directional. Followingsimilar terminology, communication between DO-neighbors may be called DO-communication,and, between DD-neighbors, DD-communication. In thescenario depicted in Fig. 4, assume that node F is a DD-neighbor of node A and node B is a DO-neighbor of node A.Similarly, node C is a DO-neighbor of node B andnode F is aDO-neighbor of node C . A DO-neighbor route from A to F is

A-B

-C

-F .

It is important to note that, although two DD-neighborscan communicate with each other directly (provided they beamform in each others direction), some mechanism isneeded to first make them beamform in each othersdirection. This observation motivates the proposed Multi-Hop RTS MAC protocol. The MultiHop RTS MAC protocol(MMAC) builds on the Basic DMAC protocol. TheMAC layer is supplied with a DO-neighbor route to theintended DD-neighbor ( F in our example in Fig. 4). Weassume that a module running above the MAC layer iscapable of deciding the suitable DO-neighbor route to a DD-neighbor and can specify the corresponding transceiverprofiles to be used. The multihop RTS protocol has beendesigned as part of a larger ad hoc networking system thatutilizes directional antennas [28], [26]. Architecture of thissystem includes several modules, such as neighbor dis-covery, link characterization, proactive routing, and aposition information module. Interested readers are re-ferred to [28].

Once the MAC layer has received the packet with theroute, the idea is to send an RTS along the DO-neighborroute to the DD-neighbor (destination) and request thedestination node (node F , in the example in Fig. 4) to pointits receiving beam toward the RTS sender (node A) at aspecific point of time in the near future. Node F receives theRTS, transmits the CTS in the direction of the RTS sender(node A), and waits for the arrival of the DATA packet. Thedetails of this MMAC protocol are discussed below. Forillustration purposes, we will refer to Fig. 4, where weassume that node A wishes to transmit a packet to node T .This is achieved by having node A transmit the data packetdirectly to node F , using MMAC. Node F , in turn, delivers

the packet to node T using MMAC as well, as shown inFig. 4.

7.2 Channel ReservationThe notion of reserving the channel before communicationis retained in this protocol. In fact, the necessity for channelreservation becomes acute in MMAC. Setting up thedirectional link between A and F involves multiple RTSs(to be forwarded) as well as requires node A to inactivelywait for CTS during that time interval. This may be viewedas a substantial investment of network resources that isworthwhile only if the subsequent CTS/DATA/ACK(transmitted using DD-communication) is successful. This

motivates conservative channel reservation so that once the


Fig. 4. A scenario showing how the multihop RTS is forwarded from node A to node F .


8/15

directional link has been established, the DATA transmis-sion may be carried out uninterrupted. The mechanism isdescribed below.

7.3 RTS Transmission

1. The MAC layer of node A receives a packet (from an

upper layer) containing the DO-neighbor route tothe next DD-neighbor, F . The route is specified asA-B -C -F . Let T B and T F be the transceiver profile of the DO-neighbor and the DD-neighbor. The trans-ceiver profiles for nodes B and F are necessary fordirectional RTS transmissions as detailed in thesubsequent steps. These profiles are assumed to bemaintained by a neighbor discovery module in ourproposed system.

2. Upon receiving the packet, MMAC checks for thestatus of the physical layer. It proceeds to Step 3 onlywhen the physical layer is not engaged in transmit-ting or receiving packets.

3. MMAC at node A now requests the physical layer to beamform according to the transceiver profile T F .Let us denote this beam by B F , since the beam pointsin the direction of node F .

4. The MMAC protocol at node A now performs thesame set of operations as described in the RTStransmission procedure of DMAC. These operationsinclude physical carrier sensing, DNAV check, andcounting down the backoff timer. Once these stepsare completed, MMAC at node A sends an RTS tothe physical layer to be transmitted using beam B F (in the direction of the DD-neighbor F ). Theduration field of this RTS includes the entireduration for multihop RTS transmissions and sub-sequent CTS, DATA, and ACK transmissions. ThisRTS packet has its destination node as node F . Itmay be noted that this RTS, transmitted using beamB F , may not reach node F since F in idle state islistening in Omni mode. However, the intention of sending this RTS in the direction of node F is not todeliver the RTS to F , but to reserve the channel inthe region between node A and F . To put itdifferently, since a communication between nodesA and F is imminent, nodes like G and D should beinformed to avoid interference. When G and Dreceive this RTS, they set their DNAVs in thedirection of A and also in the opposite direction.

For illustration, let us consider node D. If DADdenotes the DoA of the RTS at node D , then D setsthe DNAV for direction DAD for the durationspecified in the RTS packet. In addition, D setsDNAV for the direction DAD 180 mod 360 . Thelatter is necessary so that D does not initiate acommunication in the direction of node F , before F has received the multihop RTS. Therefore, theduration for which transmission is deferred alongthe direction DAD 180 mod 360 is equal to thetime required for the multihop RTS to reach F fromA. This time is calculated by node D as the Timerequired for 1 RTS transmission Number of hops in the

multihop route (note that the Number of hops in the

multihop route is also included in the RTS packet andthe Time required for 1 RTS transmission is constant asexplained in the next step of this protocol).

Destination node F may receive the RTS from Ain some instances. For example, this may occur if F happens to be beamformed in the direction of Awhen A initiates RTS transmission. If F receives this

RTS, it may reply immediately with a CTS or mayoptionally switch to the omni mode to be able toreceive the imminent multihop RTS (discussed inStep 5). We use the former option in our simulations.When using this option, node A remains beam-formed in the direction of F after transmitting theRTS. If node A receives a CTS from F , it initiatesdata transmission. If the CTS does not arrive withina suitable timeout interval (similar to Basic DMAC),node A proceeds to Step 5.

5. MMAC now constructs a special type of RTS packetthat is delivered to the destination over multiplehops (we call it the forwarding-RTS). This RTS packetcontains the DO-neighbor route from node A to F (A-B -C -F in our example) and the duration fieldindicating the duration of subsequent DATA/ACKtransmissions. When all the steps (namely, virtualand physical carrier sensing, backing off, and wait-ing for DIFS interval) have been successfullyperformed, MMAC at node A transmits the forward-ing-RTS packet to the DO-neighbor specified in theroute ( B in our example). None of the nodes (eitheron the DO-neighbor route or otherwise) modify theirDNAV tables on receiving or overhearing the forwarding-RTS packet.

Nodes which receive the forwarding-RTS packetforward it to their DO-neighbor specified in the DO-neighbor route. The forwarding-RTS packet getshighest priority for transmission (forwarding of RTS by the intermediate node does not involve backing off). This implies that the Time required for1 RTS transmission is assumed constant. This assump-tion may sometimes turn out to be incorrect. Inparticular, if a node in the DO-neighbor route is busyor has a DNAV set for the direction of forwarding, itwill simply drop the RTS. The forwarding-RTSpackets are not acknowledged on receipt.

6. In the meantime, while the forwarding-RTS packet is being forwarded to node F , node A beamforms inthe direction of F and waits in anticipation of the

CTS. If the forwarding-RTS gets dropped beforereaching the destination, or if a node like G, lyingoutside the DO-range of A, initiates a transmission inthe direction of A, then A will not receive the CTS. If the CTS does not come back within a CTS-timeoutduration, then A cancels its attempt of DD commu-nication and initiates traditional DO-communicationto B (as in DMAC). The CTS-timeout duration iscalculated as the time required for the forwarding-RTS packet to reach F (over the specified route) plusthe turn-around time for F to send the CTS. Sinceintermediate nodes do not back off while forwardingRTS packets, the CTS timeout duration can be

estimated accurately.



9/15

7.3.1 RTS Reception and CTS Transmission On receiving the forwarding-RTS, node F replies with aCTS by pointing its transmitting beam in the direction of A.The transmission of the CTS must be preceded by virtualand physical carrier sensing and waiting for a SIFS intervalof time (as described previously for the Basic DMACprotocol).

7.3.2 CTS Reception and DATA/ACK Exchange Node A remains beamformed in the direction of F andwould thus receive the CTS directionally. Once the CTS isreceived, the directional-directional link (DD-link) has beensuccessfully formed and node A proceeds to send theDATA packet using beam B F . If F receives the DATApacket successfully, it acknowledges node A with an ACK.The ACK is sent using the same beam used for sending theCTS. Nodes that overhear the CTS or DATA packet updatetheir DNAV tables with the duration specified in thepackets. The duration field of the CTS includes the timerequired for completing the subsequent exchange of dataand ack packets. This time is obtained from the durationfield specified in the RTS packets.

8 P ERFORMANCE EVALUATIONIn this section, we evaluate the performance of BasicDMAC, DMAC-I, as well as the MultiHop RTS (MMAC)protocol. We compare the protocols to the IEEE 802.11standard. We discuss results reflecting the pros and cons of directional communication. For our simulations, we haveused the Qualnet Simulator, version 2.6.1 [16]. The direc-

tional gain for the antenna is 10 dB and the beamwidth used

is 45 degrees. The approximate transmission range whenusing IEEE 802.11 is 250 meters. The approximate transmis-sion range of a DD-link is 900 meters. We use the two-raypropagation model. We do not consider node mobility inour simulation scenarios.

8.1 Simulation ResultsDirectional communication introduces three new problems:new kinds of hidden terminals, higher directional inter-ference, and deafness (as discussed in Section 6). In thispaper, we intend to evaluate the net impact of directionalantennas. The problems related to using directionalantennas are dependent on topology; nodes placed in astraight line may suffer due to the higher directionalinterference. Performance also depends on the flow orroute configuration in the system; if routes of two flowsshare a common link, then deafness would be a consequence.To understand these dependencies better, we have identi-

fied several simulation scenarios that capture these issuesindividually. The chosen scenarios are deliberately keptsimple.

First, we show the dependence of performance ontopology. Fig. 5 depicts six nodes in two differentconfigurations. Nodes A, B , and C in Fig. 5 are always backlogged with CBR traffic and packets of size 512 bytes.The transmitting beamforms of nodes A, B , and C areshown. The destinations are nodes D, E , and F , respec-tively. We compare the performance of Basic DMAC(DMAC-I and MMAC behave identically to Basic DMACin these scenarios) with 802.11, for both configurations. Inthe rest of the paper, we would refer to Basic DMAC as

DMAC and enhanced DMAC as DMAC-I.


Fig. 5. (a) A scenario allowing high spatial reuse for DMAC. (b) High directional interference degrades performance of DMAC.


10/15

In Table 1, for the scenario from Fig. 5a, the totalthroughput of DMAC is more than twice of 802.11. This is because directional communication increases the spatialreuse of the channel. For the scenario in Fig. 5b, DMAC doesnot offer much benefit. Since the interfering range of directional antennas is larger, using DMAC, only one of the three transmissions can occur at anygiven time, except ininfrequent cases where communications get scheduled intime in fortunate schedules. Forexample, if node C transmitsan RTS to F while nodes A and B are waiting to initiatecommunication, then even if A initiates an RTS later, it mightnot interfereat F . This is because F is already captured in C 0scommunication and A is too far (in this case) to unlock F from C 0s signals. Now, if F can complete the CTS to C beforeA initiates data communication to D , then the two dialogsmay overlap in time. Observe that A would initiatedirectional transmission to D irrespective of whether C iscommunicating with F . Thus, independent of C -F , thepacket from node A to D is transmitted successfully. Thisprevents the contention window of node A from growingexponentially. As a result of lesser backing off, node Aachieves comparatively higher throughput, while introdu-cing unfairness. For 802.11, all the three flows share thechannel almost equally. However, due to infeasibility of time-overlapping communications, it achieves slightly lesserthroughput relative to DMAC.

Random topologies would be characterized by lesserdegree of node alignment, allowing higher scope for spatialreuse. Later in this section, we evaluate the performance on

random topologies.

Routes taken by the flows also affect the performance of directional antenna protocols. Flows that share a commonreceiver cause deafness problems. To illustrate this, weperformed simulations for an example scenario shown inFig. 6. Both nodes A and B wish to send packets to node C .Table 2 compares Basic DMAC, DMAC-I, and 802.11 interms of total throughput (as a function of the rate of CBRtraffic). Results show that DMAC and DMAC-I performworse than 802.11. This degradation occurs due to deafness,as discussed earlier. Observe that between Basic DMAC andDMAC-I, the performance is comparable. This is because, inthe common receiver case, the advantages of omnidirec-tional carrier sensing in DMAC-I is not reflected. It should bepointed out that 802.11 also suffers the problem of deafness,although less acutely. Consider Fig. 6, but using 802.11 withomnidirectional antennas. Assume now that A is forwardingnode X 0s packet to C and B is forwarding node Y 0s packet toC . Both packets are finally destined to reach D . Using 802.11,when C is transmitting to D, nodes A and B are aware of thecommunication and defer transmission.

However, nodes X and Y may initiate RTSs to A and B ,respectively, to which they receive no response. X and Y would continue to send RTSs and backoff repeatedly. Thus,the problem of deafness occurs two hops away from thecommunicating link in 802.11, while, in DMAC (and

MMAC), it occurs in the one-hop region. Deafness alsooccurs in a scenario where a node is both the receiver of aparticular flow, as well as the originator of another flow.Fig. 7 shows such a scenario. The arrows in the figure depictsingle hop flows, indicating that nodes B and C are bothreceivers and originators.

Table 3 compares Basic DMAC, DMAC-I, and 802.11 interms of total throughput for the scenario in Fig. 7. Clearly,DMAC-I outperforms both 802.11 and Basic DMAC.Between 802.11 and Basic DMAC, we observe that 802.11performs better. The results can be explained based on thekey observation that the scenario in Fig. 7 can lead todeadlocks due to deafness. Consider the case of Basic

DMAC. Since node B would not be able to communicate to


TABLE 1Comparing Per Flow Throughput of DMAC and 802.11

Fig. 6. An example to illustrate deafness.

TABLE 2Evaluating the Impact of Deafness

Fig. 7. A scenario in which a node is a receiver and originator.


11/15

node C , while C has backlogged traffic for D, node B continues to drop packets. Since node B always remains beamformed toward C (trying to establish successfulcommunication), node A attempts repeated retransmissionsto B , and drops packets after continued failures. As a result,the performance of the system degrades. Also, this leads toacute unfairness since the flow from C to D can alwayscommunicate, depriving both the other flows. While 802.11does not suffer from such a deadlock scenario, 2 it requiresnode B to remain silent while node C is communicating. Inaddition, node A does not initiate an RTS to B since it sensesthe signal from C to D. As a consequence, the problem of backing off unnecessarily does not appear with 802.11,although only one communication can occur at any giventime. Also observe that the fairness of 802.11 is higher thanDMAC. Once C finishes its communication to D, theprobability that A or B accesses the channel is high. This is because when C had won channel contention, A and B hadfrozen their backoff counters. Once C completes transmis-sion, A and B count down their remaining backoff duration,which is likely to be smaller than the new backoff valuechosen by C . The performance improves further when

DMAC-I is used. Observe that, using DMAC-I, when C communicates to D , A may communicate to B if A managesto transmit the RTS while B is in the omnidirectional mode.This increases spatial reuse. Moreover, the problem of deadlock does not arise since B often can communicate to C with reasonable frequencyi.e., if C receives an RTS from B while C is in the omnidirectional backoff phase, C replies toB with a CTS and the dialog between B and C can proceed.

Having observed the individual effects of introducingdirectional communication, we now proceed to evaluatetheir combined effect on network performance and comparethem with the IEEE 802.11 standard. It is relevant to pointout at this time that for the purpose of comparison, we useidentical routes for 802.11, DMAC, DMAC-I, and MMAC inall cases. However, this does not bring out the bestperformance of DMAC, DMAC-I, or MMAC since nodeswhich can be reached in a single hop using directionalantennas are forced to reach through multiple hops sinceomnidirectional communication requires so. As discussedlater, we have also performed some preliminary experi-ments comparing our proposed MAC protocols using routesthat are feasible only with directional antennas.

Fig. 8a shows a grid topology of 25 nodes. We system-atically introduce flows into this grid and vary the trafficpatterns. We begin with four multihop flows as shown in

Fig. 8b. The distance between rows and columns in the grid,called grid-distance henceforth, is 150 meters. This ensuresthat adjacent, as well as diagonal, nodes can communicatewith each other. Note that nodes 7, 9, 17, and 19 areconsidered diagonal to node 13. In our simulations, themultihop RTS is forwarded over not more than three hopsand using the same route as shown in the figures. The trafficon each flow is CBR (Constant Bit Rate) and is varied from75 Kbps to 2,000 Kbps with packet size of 512 bytes. Fig. 9shows the comparative results of 802.11, DMAC, andMMAC in terms of aggregate throughput over all flows.In Fig. 9, DMAC performs worse than 802.11. The poorperformance of DMAC may be attributed to the highalignment of hops in the chosen routes and to higherinterference in directions of ongoing communication. Theperformance of DMAC-I is comparable to DMAC even withomnidirectional backoff. This can be expected because thescenario shows that all originators of traffic are at the edgeof the network and do not require to forward traffic on behalf of the others. Consequently, the problem of dead-

lock, as observed earlier, does not occurthe benefits of DMAC-I are therefore not visible. MMAC performs betterthan both DMAC, DMAC-I, and 802.11. This is becauseDATA is transferred over fewer hops using MMAC asopposed to four hops using DMAC/802.11. Therefore, thetotal consumption of the wireless bandwidth is much less,allowing a greater number of packets to be transmittedwithin the same span of time.

In the next experiment, we alter the routes. The newroutes are less aligned, as shown in Fig. 8c. Fig. 9 shows therelative performance of 802.11, DMAC, DMAC-I, andMMAC. Evident from the graph, directional antennaprotocols perform much better than 802.11 because the

potential for spatial reuse is greater for this scenario. To putit differently, two node pairs on the route of a given flowcan now communicate simultaneously using directionalantennas, e.g., node pairs (6, 12) and (13, 14). This ispossible because the direction in which the individual nodepairs communicate are not same, unlike the scenario inFig. 8b. The throughput curves saturate beyond a particulardata sending rate because the channel capacity gets fullyutilized. The aggregate throughput is higher for directionalprotocols because more links can simultaneously commu-nicate. However, DMAC and DMAC-I are marginally betterthan 802.11 because deafness (due to common receiver)offsets the gains derived from spatial reuse. It is interestingto note that deafness does not affect the performance of

MMAC as much because nodes that forward RTSs inMMAC are engaged in communication for a very smallamount of time (and are not silenced during the CTS/DATA/ACK exchange). In comparison, intermediate nodesin DMAC, DMAC-I, and 802.11 remain occupied for theentire span of CTS, DATA, and ACK transmission.

The next comparison of 802.11, DMAC, DMAC-I, andMMAC is performed for the scenario shown in Fig. 8d. Thechosen routes are characterized by a smaller degree of alignment, allowing higher spatial reuse. Fig. 10 shows theresults for this experiment. The aggregate throughputachieved by MMAC is much higher than DMAC andDMAC-I, which are, in turn, higher than 802.11. This

supports our intuition that unaligned routes enhance


2. With 802.11, node B is aware of the transmission between nodes C and

D and, therefore, refrains from initiating a dialog with C .

TABLE 3Evaluating the Impact of Deadlock Due to Deafness


12/15

spatial reuse of the wireless channel and directionalcommunication would consequently benefit.

We now compare the performance of the three protocolssimulated over 25 random topologies and route patterns.The flows are between the same source-destination pairs (asin Fig. 8d), except that the nodes are now randomlydistributed in the region. An example topology has beenshown in Fig. 11. Observe that, with randomly located

nodes, the degree of link alignment is less, indicating thepossibility of higher spatial reuse. The simulation resultshave been averaged over all the scenarios and shown inFig. 11. On average, random topologies show a significantimprovement in performance using MMAC as evident inFig. 11. While the performance of DMAC is poor (andcomparable to 802.11), DMAC-I outperforms both DMACand 802.11. The improvement of DMAC-I over DMAC can be attributed to the possibility of deadlocks occurringwhenever the traffic originator needs to forward traffic on behalf of others. Since such cases occur when nodes arerandomly placed, the benefits of omnidirectional backing

off becomes conspicuous. However, the benefits of highercommunication range in MMAC exceeds the benefits of DMAC-I.

We investigated the performance of our protocols withvarying node density. With twice the number of nodes, wedoubled the number of flows to measure protocolscalability. Fig. 12 illustrates the variation of aggregatethroughput with higher node density. Clearly, with anincrease in network traffic, MMAC routes fail more oftenmultihop RTS packets are unable to reach the destina-tion and MMAC falls back on individual DO routes.Consequently, MMAC degenerates to DMAC-I and theperformances become comparable. However, due to the

possibility of higher spatial reuse, MMAC, DMAC, and


Fig. 8. (a) The 5 5 grid topology used for simulations. (b) Flows with aligned routes. (c) Less alignment in routes. (d) Randomly chosen routes. Wecompare the performance of DMAC, MMAC, and 802.11 for all the above scenarios. The grid distances, although shown to be identical, are variedover multiple simulations.

Fig. 9. Aggregate throughput (Kbps) of the network with routes in Figs. 8b and 8c.

Fig.10. Aggregate throughput (Kbps) of thenetworkwith routes in Fig.8d.


13/15

DMAC-I all continue to outperform 802.11, even at highernode densities.

Having illustrated the comparative performances of IEEE 802.11 and our directional protocols, we now focuson the comparison between DMAC, DMAC-I, and MMAC.As mentioned earlier, to compare the throughput of DMAC,DMAC-I, MMAC, and 802.11, we used identical routes inour previous simulations. However, this is unfair forprotocols that use directional antennas because routessuitable for 802.11 may be suboptimal for DMAC, DMAC-I, and MMAC. To compare the relative performance of DMAC, DMAC-I, and MMAC, we design the routes tocontain the longest possible links that can be formed byeach of the protocols. To achieve this, we scaled up thedistance between nodes in the random topologies by afactor of two. On these random topologies, we use the sameset of flows and routes used previously. We observed fromthe simulation results that increasing distance betweennodes improves throughput of DMAC, DMAC-I, andMMAC, provided the network does not get disconnected.This improvement is an outcome of lesser contention andinterference experienced by the communicating nodes inthe network.

Fig. 13 shows the average end-to-end delay for DMAC,DMAC-I, and MMAC flows, averaged over 25 scaled

topologies mentioned above. The end-to-end delay is thetime interval calculated from the instance a packet is handeddown by the application layer at the source node to theinstance the packet is received by the application layer at thedestination node. In Fig. 13, we observe that the delayincreases initially with increase in sending rate. On furtherincreasing the sending rate, the end-to-end delay curvessaturate. This behavior may be explained as follows: Whenthe network load is low, the contention and queuing delay ateach intermediate hop is small. As the network loadincreases, queue sizes grow, in turn, increasing the averageend-to-end delay of delivered packets. The curves saturatewhen the queues get full (the delay is calculated only overpackets that are not dropped due to queue overflow).DMAC-I performs better than DMAC because omnidirec-tional backoff in DMAC alleviates the possibility of prolonged deafness, and eliminates the possibility of dead-locks. However, MMAC outperforms DMAC-I and DMACsince it utilizes the longest possible links between node pairs.While data packets have to travel on each DO-link whenusing DMAC and DMAC-I, MMAC requires only RTSs totravel on the DO-links and data to be transmitted on thepotentially longer DD-links. This enables MMAC to usefewer hops in several instances. However, the higher failure


Fig. 12. Variation of throughput with increase in node density.Fig. 13. Average end-to-end delay of DMAC/MMAC over multiplesimulations using random topologies and flows.

Fig. 11. Average aggregate throughput over multiple simulations using random topologies and routes.


14/15

probability in transmitting the multihop RTS packet whenusing MMAC, increases the latency of packet delivery due tofrequent timeouts and retransmissions. This partially offsetsthe advantage of utilizing DD-links when using MMAC.Therefore, the performance of MMAC (in terms of end-to-end delay) is only slightly better in comparison to DMAC.

9 DISCUSSION9.1 Neighbor DiscoveryTo be able to transmit to a neighbor, the MAC layer needs todetermine the direction of beam-steering. We have assumedthat higher layers are capable of providing this direction-of-neighbor information. One way to achieve this could be aproactive mechanism whereby nodes periodically transmitomnidirectional hello messages at higher power levels.The power level can be adjusted such that, even withomnidirectional transmission and omnidirectional recep-tion, the communication range matches the DO or DD range.Nodes that overhear the periodic hello messages can

record the best beam for receiving these signals. To initiatedirectional transmissions to a neighbor later, a node can usethis (periodically refreshed) recorded beam. Another alter-native is where nodes periodically transmit directionalhello messages in multiple directions on the azimuthplane. Neighbors of the transmitter may receive thesehello messages omnidirectionally while determining the best beam to transmit back to this transmitter at a later time.Yet another alternative is where nodes synchronously beamform in specific directions at prespecified times andoscillate randomly between beamforming in that directionand the opposite. While nodes require to be clock-synchronized, such a scheme has shown to perform well

in [26].9.2 MobilityWe do not consider mobility in this paper. We believe thatseveral applications of ad hoc networks relate to statictopologies (e.g., mesh networks, wireless backbones). Ourevaluations are more applicable to such scenarios. How-ever, as discussed earlier, we assumed a neighbor-discoverymodule to provide the MAC layer with beamforminginformation. Therefore, the sensitivity of DMAC/MMACto topology changes depends largely on the ability of theneighbor discovery protocols. In conjunction with a direc-tional-antenna aware neighbor discovery module, our ideasmay hold even in the face of mobility.

9.3 MultipathIn a multipath environment, signals may arrive at thereceiver from multiple directions, thereby causing a node toset DNAVs around all these directions. This can potentiallyreduce the performance gains from spatial reuse. Oursimulations do not model multipath environments. We planto incorporate this in our future work.

10 C ONCLUSIONThis paper considers the problem of designing mediumaccess control protocols for ad hoc networks using direc-

tional antennas. The results show that the performance

improvement, in terms of aggregate throughput and end-to-end delay, is possible when using directional antennas. Wealso notice that the performance of the system clearlydepends on the topology and flow pattern in the network,more aligned topologies degrading the performance of directional antenna protocols. The multihop RTS protocolcan outperform 802.11, DMAC, and DMAC-I, suggestingthat it is beneficial to employ directional communication inshared wireless medium in multihop ad hoc networks.

ACKNOWLEDGMENTSThis work is supported in part by the Defense AdvancedResearch Projects Agency (DARPA), US National ScienceFoundation (NSF), and Motorola Center for Communica-tion Fellowship. It was published in part at the InternationalConference on Mobile Computing and Networking (MobiCom),2002.

REFERENCES[1] A. Acampora and S. Krishnamurthy, A New Adaptive MAC

Layer Protocol for Broadband Packet Wireless Networks in HarshFading and Interference Environments, Proc. IEEE/ACM Trans.Networking, June 2000.

[2] C.A. Balanis, Smart Antennas for Future Reconfigurable WirelessCommunication Networks, technical report, Arizona State Univ.,Apr. 2000.

[3] S. Bandyopadhyay, K. Hausike, S. Horisawa, and S. Tawara, AnAdaptive MAC and Directional Routing Protocol for Ad HocWireless Networks Using ESPAR Antenna, Proc. ACM MobiHoc,pp. 243-246, Oct. 2001.

[4] L. Bao and J. Garcia-Luna-Aceves, Transmission Scheduling inAd Hoc Networks with Directional Antennas, Proc. MobiCom,2002.

[5] S. Bellofiore, J. Foutz, R. Govindarajula, I. Bahceci, C.A. Balanis,

A.S. Spanias, J. Capone, and T.M. Duman, Smart AntennaSystem Analysis, Integration, and Performance for Mobile Ad-Hoc Networks (Manets), IEEE Trans. Antennas and Propagation,2002.

[6] P. Bhagwat, B. Raman, and D. Sanghi, Turning 802.11 Inside-Out, Proc. Workshop Hot Topics in Networks (HotNets II), Nov. 2003.

[7] S. Biswas and R. Morris, Opportunistic Routing in Multi-HopWireless Networks, Proc. Workshop Hot Topics in Networking(HotNets II), Nov. 2003.

[8] R.R. Choudhury, T. Ueda, and J. Bordim, Ad Hoc NetworkingUsing Beamforming Antennas: A Testbed Experience, technicalreport, Univ. of Illinois at Urbana-Champaign, Sept. 2004.

[9] R.R. Choudhury and N.H. Vaidya, Impact of DirectionalAntennas on Ad Hoc Routing, Proc. Personal and Wireless Comm.(PWC), Sept. 2003.

[10] R.R. Choudhury and N.H. Vaidya, Deafness: A MAC Problem inAd Hoc Networks when Using Directional Antennas, Proc. IEEE

Intl Conf. Network Protocols (ICNP), Oct. 2004.[11] R.R. Choudhury, X. Yang, and N.H. Vaidya, Using DirectionalAntennas in Ad Hoc Networks, technical report, Texas A&MUniv., July 2001.

[12] R.R. Choudhury, X. Yang, N.H. Vaidya, and R. Ramanathan,Using Directional Antennas for Medium Access Control inAd Hoc Networks, Proc. ACM MobiCom, Sept. 2002.

[13] T. Elbatt, T. Anderson, and B. Ryu, Performance Evaluation of Multiple Access Protocols for Ad Hoc Networks Using DirectionalAntennas, Proc. IEEE Wireless Comm. and Networking Conf., 2003.

[14] Z. Huang, C. Shen, C. Srisathapornphat, and C. Jaikaeo, A Busy-Tone Based Directional MAC Protocol for Ad Hoc Networks,Proc. Milcom, 2002.

[15] Z. Huang and C.-C. Shen, A Comparison Study of Omnidirec-tional and Directional MAC Protocols for Ad Hoc Networks,Proc. IEEE Globecom, 2002.

[16] IEEE 802.11, Wireless LAN Medium Access Control (MAC) and

Physical Layer (PHY) Specifications, 1999.



15/15

[17] P. Karn, MACAA New Channel Access Method for PacketRadio, Proc. Ninth Computer Networking Conf., 1990.

[18] R. Karrer, A. Sabharwal, and E. Knightly, Enabling Large-ScaleWireless Broadband: The Case for Taps, Proc. Workshop HotTopics in Networks (HotNets II), 2003.

[19] Y. Ko, V. Shankarkumar, and N.H. Vaidya, Medium AccessControl Protocols Using Directional Antennas in Ad Hoc Net-works, Proc. IEEE Infocom, vol. 1, Mar. 2000.

[20] K. Kobayashi and M. Nakagawa, Spatially Divided Channel

Scheme Using Sectored Antennas for CSMA/CADirectionalCSMA/CA, Proc. Intl Symp. Personal Indoor and Mobile RadioComm. Conf., 2000.

[21] T. Korakis, G. Jakllari, and L. Tassiulas, A MAC Protocol for FullExploitation of Directional Antennas in Ad Hoc Wireless Net-works, Proc. MobiHoc, 2003.

[22] D. Lal, R. Toshniwal, R. Radhakrishna, D. Agrawal, and J. Caffery,A Novel MAC Layer Protocol for Space Division Multiple Accessin Wireless Ad Hoc Networks, Proc. lC3N, 2002.

[23] A. Nasipuri, S. Ye, J. You, and R. Hiromoto, A MAC Protocol forMobile Ad Hoc Networks Using Directional Antennas, Proc.IEEE Wireless Comm. and Networking Conf., vol. 3, pp. 1214-1219,Sept. 2000.

[24] C. Peraki and S. Servetto, On the Maximum Stable ThroughputProblems in Random Networks with Directional Antennas, Proc. MobiHoc, 2003.

[25] R. Ramanathan, On the Performance of Ad Hoc Networks with

Beamforming Antennas, Proc. ACM MobiHoc, pp. 95-105, Oct.2001.[26] R. Ramanathan, J. Redi, C. Santivanez, D. Wiggins, and S. Polit,

Ad Hoc Networking with Directional Antennas: A CompleteSystem Solution, J. Selected Areas in Comm., Jan. 2005.

[27] T. Rappaport, Wireless Communications Principles and Practice.Prentice Hall, 2002.

[28] J. Redi and R. Ramanathan, Utilizing Directional Antennas forAd Hoc Networks, Proc. IEEE Milcom (Classified Volume), 2001.

[29] M. Sanchez, T. Giles, and J. Zander, CSMA/CA with BeamForming Antennas in Multi-Hop Packet Radio, Proc. SwedishWorkshop on Wireless Ad Hoc Networks, pp. 63-69, Mar. 2001.

[30] H. Singh and S. Singh, DOA-ALOHA: Slotted ALOHA forAd Hoc Networking Using Smart Antennas, Proc. VehicularTechnology Conf. (VTC), Fall 2003.

[31] A. Spyropoulos and C. Raghavendra, Energy Efficient Commu-nications in Ad Hoc Networks Using Directional Antennas, Proc.

Infocom, 2002.[32] K. Sudaresan and R. Sivakumar, On the Medium Access ControlProblem in Ad-Hoc Networks with Smart Antennas, Proc. MobiHoc, June 2003.

[33] M. Takai, J. Martin, R. Bagrodia, and A. Ren, Directional VirtualCarrier Sensing for Directional Antennas in Mobile Ad HocNetworks, Proc. ACM MobiHoc, pp. 39-46, June 2002.

[34] J. Ward and R. Crompton, Improving the Performance of SlottedALOHA Packet Radio Networks with Adaptive Arrays, IEEETrans. Comm., vol. 40, no. 11, pp. 1716-1724, 1992.

[35] S. Yi, Y. Pei, and S. Kalyanaraman, On the Capacity Improve-ment of Ad Hoc Wireless Networks Using Directional Antennas,Proc. MobiHoc, 2003.

Romit Roy Choudhury received the BTechdegree in computer science from the HaldiaInstitute of Technology, India, in 2000 and theMS degree in electrical and computer engineer-ing from the University of Illinois at Urbana-Champaign in 2003. He is currently a PhDcandidate in computer science at the Universityof Illinois. His research interest is in the area ofwireless networking with an emphasis on med-

ium access control, location management, androuting. He was awarded the Best Paper Award at the Eighth PersonalWireless Communications (PWC) Conference, 2003. He is currently therecipient of the Motorola Center for Communications Fellowship, 2003 to2005. He is a student member of the IEEE.

Xue Yang received the BE degree and the MSdegree from the University of Electronic Scienceand Technology of China. She is currently a PhDcandidate at the University of Illinois at Urbana-Champaign (UIUC). She was awarded theVodafone-US Foundation Graduate Fellowshipfrom 2003 to 2005. Her current research is in theareas of wireless networking and mobile com-puting with a focus on medium access control,quality of service, and topology control. For more

information, please visit http://www.crhc.uiuc.edu/~xueyang/. She is a

member of the IEEE.

Ram Ramanathan received the BTech degree from the Indian Instituteof Technology, Madras, India, and the PhD degree from the University ofDelaware. He is a division scientist in the Internetworking ResearchDepartment at BBN Technologies. His current research interests are inthe areas of wireless networking, mobile ad hoc networking, internet-work routing and multicasting, self-organizing networks, and graphtheory. He has been with BBN for about 10 years. He is a seniormember of the IEEE.

Nitin H. Vaidya received the PhD degree fromtheUniversityof Massachusetts atAmherst.He ispresently an associate professor of electrical andcomputer engineering at the University of Illinoisat Urbana-Champaign (UIUC). He has heldvisiting positions at Microsoft Research, SunMicrosystems, and the Indian Institute of Tech-nology-Bombay. His current research is in wire-less networking and mobile computing. Hecoauthored papers that received awards at the

ACM MobiCom and Personal Wireless Communications (PWC) confer-ences. Dr. Vaidyas research has been funded by various agencies,including the US National Science Foundation, DARPA, Motorola,Microsoft Research, and Sun Microsystems. He was a recipient of aCAREERawardfromthe USNationalScience Foundation.Hehasservedon the committees of several conferences, including as program cochairforthe2003ACMMobiComand general chairforthe 2001 ACM MobiHoc.Hehas served asan editorfor several journalsand will serveas theeditor-in-chief for the IEEE Transactions on Mobile Computing from January2005. He is a senior member of the IEEE and a member of the ACM. Formore information, please visit http://www.crhc.uiuc.edu/~nhv/.

. For more information on this or any other computing topic,please visit our Digital Library at www.computer.org/publications/dlib.


Romit TMC Directional

Documents

Transcript of Romit TMC Directional