DESIGN OF RELIABLE MAC PROTOCOL FOR DIRECTIONAL BROADCASTING

Woosuk Cha, Moonkun Lee, Gihwan ChoDivision of Electronic & Information Engineering, University of Chonbuk664-14 Duckjin-Dong, Duckjin-Gu, Chonju, Chonbuk 561-756 South Korea

ABSTRACT

The wireless transmission medium inherently broadcasts asignal to all neighbor nodes in the transmission range.Existing asynchronous MAC protocols do not provide aconcrete solution for reliable broadcasting in the linklayer. This mainly occurs because an omni-directionalbroadcasting deteriorates the network performance due tothe explosive collisions and contentions. This paper pro-poses a directional broadcasting protocol based on direc-tional antennas, named RMDB (a Reliable MAC protocolfor Directional Broadcasting). This protocol utilizesMACA (Multiple Access and Collision Avoidance) schemethrough 4-way handshake, and DAC (Directional Anten-nas Control) information to resolve most collision prob-lems associated with an omni-directional antenna. To ana-lyze its performance, RMDB protocol is compared withIEEE 802.11 DCFprotocol and the protocol 2 ofreference[3], in terms of the success rate ofbroadcasting and colli-sion rate.

Keywords: broadcasting, directional antennas, MAC

I. INTRODUCTION

Broadcasting is a technique used to transfer data from onenode to all neighbor nodes. It is widely utilized for a rout-ing method in wireless networks. In an Ad hoc network, itis used to transfer a control message to establish a basicpath from a source node to a destination node [1].

Mobile nodes in an Ad hoc and sensor network usuallyshare a single common channel. Synchronization amongthe nodes is very difficult, even global network topologyinformation is usually unavailable to facilitate the schedul-ing of broadcasting. Thus, flooding is used for broadcast-ing in a network layer. However, [2] has revealed that agreat redundancy, contention and collision could be identi-fied if the flooding is done blindly. This situation is re-ferred to as a broadcast storm problem.

Wireless transmission medium has a propagation featurethat all neighbor nodes in transmission range can receive asignal simultaneously. However reliable broadcasting inthe existing MAC protocols has not yet been considered,

The Research was supported in part by University IT ResearchCenter Project, Korea

because system efficiency seriously deteriorates due to thefrequent collisions and contentions for wireless media ac-cess. One possible method to overcome this problem con-sists of utilizing directional antennas. The protocol withdirectional antennas takes both a spatial reuse and an ex-tension of transmission range because directional antennasfocus on an antenna beam only toward where a destinationnode is located.

This paper proposes a directional broadcasting protocol inthe link layer based on directional antennas, named RMDB(a Reliable MAC protocol for Directional Broadcasting).This method makes use of 4-directional (cardinal) broad-castings to resolve the frequent contention and collisionproblems with the omni-directional antenna. This is ac-complished with DAC (Directional antennas Control) tableand MACA (Multiple Access and Collision Avoidance)scheme using the 4-way handshake through RTDB (Re-quest To Directional Broadcasting), CTDB (Clear To Di-rectional Broadcasting), DDATA (Directional DATA),DACK (Directional ACK) exchanges. The protocol miti-gates the collision problem which occurs due to the simul-taneous transmission of a control frame, using MaxSlot. Inaddition, the hidden terminal and deafness problems canbe naturally resolved with this methodology.

This paper is organized as follows. Section 2 describes theexisting works with directional antennas in wireless net-works. Section 3 describes a model for directional anten-nas and RMDB protocol in detail. Section 4 discusses howthe hidden terminal and deafness problems can be resolved.Section 5 analyzes the results of simulation. Finally, sec-tion 6 summarizes the work and discusses the future re-search possibilities.

II. RELATED WORK

Many researches have been proposed for broadcastingwith directional antennas in the link layer and the networklayer. However, most of the proposed MAC protocols haveconsidered only the unicasting. To the best of our knowl-edge, there exists little work on exploiting directional an-tennas for broadcasting. Currently, the research with direc-tional antennas can be classified into two approaches; oneis to reduce contention and collision in the link layer [3-6],the other is to improve the performance of a routing proto-col in the network layer [7-8].

1 of 7

The protocol 2 in [3] suggested a broadcasting schemebased on retransmission of a broadcast packet through DS(Direction Search), DI (Direction Information), NACK(Negative ACK) signal exchanges. The sending node ac-quires the directional information of neighbor nodes usingDS and DI signal exchanges. It broadcasts data to neighbornodes which respond with a DI signal. If a neighbor nodedoes not receive the broadcast data, it replies with NACK.Thus, the sending node can recognize the fact that the databroadcasting has failed. It continues to retransmit a broad-cast packet until either no NACK is detected or the numberof retries reaches the maximal retry threshold. Because itdoes not support a collision avoidance means, it generatesunnecessary redundant traffic due to the frequent rebroad-casting.

Reference [4] proposed a new MAC protocol, whichmakes use of an RTS (Request To Send) /CTS (Clear ToSend) exchange similar to that in IEEE 802.11 protocol toenable the sender and receiver to identify each other's di-rections. Then, the sender transmits a data packet using thesame directional antenna as the receiving CTS. [5] repre-sented a new carrier sensing mechanism called DVCS (Di-rectional Virtual Carrier Sensing) with directional antennas.The DVCS supports not only an effective adaptability ofcontention based MAC protocols, but also interoperabilityof directional antennas and an omni-directional antenna.[6] proposed DMAC (Directional MAC) protocol andMMAC (Multi-Hop RTS MAC) protocol with directionalantennas. Even though it is similar to that in IEEE 802.11protocol, it allows a node to communicate directly withother nodes located far away. [4-6] concentrated on an ef-fective unicast transmission only using the advantage ofdirectional antennas, but have not considered a broadcasttransmission.

Reference [7] proposed directional antennas based proto-col in order to improve the efficiency of on-demand rout-ing protocol in Ad hoc networks. Based on the directionaltransmission, it reduces the number of routing packetstransmitted during the route discovery by limiting thequery flood to a restricted region. [8] presented a channelreservation method with utilizing directional antennas andevaluated its performance on the reactive routing protocols.[7-8] shown that the routing efficiency on Ad hoc networkcould be improved with directional antennas, but theirworks were only based on the unicasting facilities.

IEEE 802.11 MAC protocol [9] supports CSMA/CA (Car-rier Sense Multiple Access/Collision Avoidance) basedunicast transmission, using interchange of RTS and CTSframes. It is presently most commonly used for Ad Hocnetworks. However IEEE 802.11 protocol does not pro-vide a concrete solution for broadcasting.

III. RMDB PROTOCOL

RMDB protocol aims to resolve "broadcast storm prob-lem" and supports a reliable directional broadcasting usingdirectional antennas, DAC table, and MaxSlot.

4/4 space#4 antenna

I

3/4 space#3 antenna

1/4 space#1 antenna

72/4space#2 antenna

(a) antenna modeling

B

A

(b) directional broadcast

Figure 1. Antenna Model

A. Antenna Model

To begin with, it is assumed that each node has directionalantennas and a transceiver, and shares a common wirelesschannel. As shown in Figure 1 (a), directional antennasconsist of four antennas, and each antenna is numbered toindicate the direction. Each antenna has 90 degrees beamwidth and conical radiation pattern, and does not overlapwith the other ones, consequently four antenna cover forfull angle of 360 degrees. In the Figure 1 (b), an exampleof directional broadcast is presented, that is, node A com-municates with node B through #1 and #3 antennas respec-tively.

Octets 34 1 1 0-2312 4

the existing MAC header Direction MaxSlot Frame Body CRC

Figure 2. The format of a control frame

B. Control Frame Format

Figure 2 shows a control frame format which is used inRMDB protocol. RMDB protocol adds Direction andMaxSlot fields to the existing frame format ofIEEE 802.11protocol. The Direction field indicates the number of anantenna, which is used to send a frame. The MaxSlot fieldindicates the maximum value of slots, which is used byreceivers later in order to compute the value of aCTDBDe-layTime and aDACKDelayTime.

A sender in the existing MACA scheme sends RTS andDATA to a receiver, the receiver replies with CTS andACK respectively. In the case of broadcasting based onMACA scheme, if the sender broadcasts one DATA to-ward the full angle of 360 degrees, a set of receivers mayreply with their ACK frames at the same time. As a result,a collision may occur at the sender side. RMDB protocolmakes use of the MaxSlot field of a control frame to miti-gate the collision problem due to the simultaneous trans-

2 of 7

mission of the control frames. The sender can only esti-mate the value of the MaxSlot field. This is computed asfollows.

* MaxSlot = C1

* C: the number of neighbor nodes included in thetransmission range of an antenna which RMDB pro-tocol transmits any frame through.

* n: The initial value of n is 2, and then increases byone whenever a sender detects a collision by the si-multaneous transmission of a control frame. Whenthe sender completes data broadcasting, it is initiatedby 2. There is a tradeoff on choice of n. That is, if thevalue of n increases, the competitive rate of a channelmay be reduced, conversely, its transmission delaymay be increased.

C. DAC Table

NAV (Network Allocation Vector) is a status variablemaintained by the IEEE 802.11 for virtual carrier sensing[9]. The DAC table in RMDB protocol is similar to theNAV, but some additional features are added in order tosupport for the directional broadcasting.

Table I. DAC table structure

D #1 #2 #3 #4SA active active active active

Count 3 2 2 3aReceivedCTDB No No No No

SN Omni-directional reception modeaTotalCTDBTimeout 0aTotalDACKTimeout 0

Table I describes the initial DAC table structure of node Afor the example of the Figure 4. Each entry indicates anantenna as a factor of the direction that each directionalantenna points to. Each parameter is defined as follows:

* D (Direction): the direction that each directional antennapoints to. #1, #2, #3, and #4 entries indicate 0 - 90, 90 -180, 180 - 270, 270 - 360 degrees angles respectively.

* SA (State of an Antenna): the state information of eachdirectional antenna. There are two states: active andpassive. The active state implies that a node can trans-mit and receive a signal through the antenna. Con-versely the passive state implies that it can not transmitand receive a signal through the antenna.

* Count: the number of neighbor nodes located within thetransmission range of each directional antenna. It ismaintained by using the number of CTDBs received forthe previous channel reservation process.

* aReceivedCTDB: this field is used to resolve the hiddenterminal and deafness problems. If a node receivesCTDB from the neighbor nodes, it sets the entry of aRe-ceivedCTDB field to be Yes.

* SN (State of Node): the operation modes of a node.There are two modes: omni-directional reception modeand directional transceiver mode. Omni-directional re-ception mode implies that a node can only receive asignal through all of the antennas in an idle state. Con-versely directional transceiver mode is able to transmitand receive a signal through a particular directional an-tenna.

* aTotalCTDBTimeout: the maximum time interval,which a sender should wait for CTDBs from theneighbor nodes after it broadcasts a RTDB in order toavoid collision due to the simultaneous transmission ofCTDBs.

* aTotalDACKTimeout: similar to aTotalCTDBTimeoutfield, except that a sender expects to receive DACKs in-stead of CTDBs.

The aTotalCTDBTimeout and aTotalDACKTimeout fieldsare computed as follows:

aTotalCTDBTimeout = MaxSlot x aSlotTimeaTotalDACKTimeout= MaxSlot x aSlotTime

where aSlotTime is the propagation delay time, which isrequired to broadcast a control frame.

D. The Basic Operation ofRMDB Protocol

In order to enable a reliable directional broadcasting,RMDB protocol requires two processes: the channel reser-vation process and the data broadcasting process. Theprocesses are accomplished by RTDB/CTDB andDDATA/ DACK exchanging respectively.

the RTDB broadcasting ofA aTotalCTDBTimeout aTotalDACKTimeout\ , hH H~---------H ItheDDA of A >HA n n n n ~~i. DDAM biodddiil UA 1|A

Bthe RTDB receiving Sr

D

the CTDB broadcasting jn:......

[IHl _

..

n<.....the DACK broadcastimg

11 HI

V andanother nodes '' the silent state

time

Figure 3. Time diagram ofRMDB protocol

Figure 3 shows the time diagram of the basic operation ofRMDB protocol for the example of figure 4 and 5. Node Ais the sender and broadcasts RTDB through #1 antenna.The receivers, nodes B, C and D, receive RTDB from Asimultaneously. Within the aTotalCTDBTimeout period, B,C and D should only reply to A with CTDB through #1

3 of 7

u

and #3 antennas. If the nodes, not included in the 1/4 di-rectional transmission range ofA, receive the CTDB, theyset the antenna receiving the CTDB to be silent until Acompletes a data broadcasting. After the aTo-taICTDBTimeout period has elapsed, A broadcastsDDATA, and B, C and D receive the DDATA simultane-ously. Within the aTotalDACKTimeout period, B, C and Dshould reply to A with DACK.

(a) the 1/4 directional (b) the 1/4 and 3/4 directionaltransmitting ofRTDB transmitting ofCTDB

Figure 4. The 2-way handshake ofRTDB and CTDB

* Channel Reservation Process

To solve the hidden terminal problem, RMDB protocolrequires a channel reservation process. Figure 4 providesan example of the 2-way handshake process of RTDB andCTDB exchange as follows in order:

1) A creates RTDB containing the Direction and MaxSlotfield, which have 1 (#1 antenna) and 9 (C=32) respec-tively.

2) A checks the aReceivedCTDB field in the DAC tableto determine whether or not it can broadcast RTDB. Ifthe value of the #1 entry of aReceivedCTDB field isNo, A broadcasts RTDB to all of neighbor nodeswithin the transmission range of its 1/4 space through#1 antenna. Otherwise A delays the data broadcastinguntil the #1 entry of the aReceivedCTDB field is set tobeNo.

3) After A broadcasts RTDB, A updates the DAC table.4) The nodes B, C and D receive RTDB from A simulta-

neously.5) Each node checks the MaxSlot field of the RTDB

frame and individually computes a random backofftime (aCTDBDelayTime) in order to avoid the colli-sion caused by the simultaneous transmission ofCTDBs at A. The aCTDBDelayTime is computed asfollows:

aCTDBDelayTime = aRandom Value x aSlotTimewhere aRandom Value is pseudorandom integer drawnfrom a uniform distribution over the interval [0, Max-Slot].

6) It is assumed that the value of aCTDBDelayTimecomputed by B, is less than those of C and D. Afterthe aCTDBDelayTime period has elapsed, B broad-casts CTDB through #1 antenna. N and 0 receiveCTDB with #3 antenna from B and update the #3 entryof aReceivedCTDB field in the DAC table to be Yes.

7) Further, B broadcasts CTDB through #3 antenna. Hand G receive CTDB with #1 antenna from B and up-date the #1 entry of aReceivedCTDB field in the DACtable to be Yes.

8) Subsequently, both C and D repeat the same stage asthe CTDB broadcasting ofB.

±

(a) the 1/4 directional (b) the 1/4 and 3/4 directionaltransmitting ofDDATA transmitting ofDACK

Figure 5. The 2-way handshake ofDDACK and DACK

* Data Broadcasting Process

With the channel reservation process, the number ofCTDBs can be obtained. This represents the number ofneighbor nodes located within the 1/4 space of A. There-fore, if this number and the number of DACK in the databroadcasting process are equal, A can confirm that aDDATA broadcasting and the operation is performed suc-cessfully. Figure 5 illustrates an example of the 2-wayhandshake process of DDATA and DACK exchanging asin the following order:

1) After the aTotalCTDBTimeout period has elapsed, Abroadcasts DDATA through #1 antenna and updatesthe aTotalDACKTimeout field in the DAC table to beMaxSlot x aSlotTime.

2) B, C and D receive DDATA fromA simultaneously.3) Each node computes a random backoff time (aDACK-

DelayTime) individually as the nodes participated inthe channel reservation process.

4) It is assumed that the value of aDACKDelayTimecomputed by B, is less than those of C and D. Afterthe aDACKDelayTime period has elapsed, B broad-casts CTDB through #3 antenna. H and G receiveCTDB with #1 antenna from B and update the #1 entryof aReceivedCTDB field in the DAC table to be No.

4 of 7

_Q

5) Further, B broadcasts DACK through #1 antenna. Nand 0 receive DACK with #3 antenna from B and up-date the #3 entry of aReceivedCTDB field in the DACtable to be No.

6) After the aTotalDACKTimeout period has elapsed, Acompares the number of CTDBs with the number ofDACKs. If it is equal, A can confirm that the DDATAbroadcasting is successfully completed. Otherwise, Aattempts the data broadcasting process again.

For simplicity, the directional broadcasting with the #1directional antenna is described above. IfA executes a di-rectional data broadcasting through #2, #3 and #4 antennasin turn after completing a data broadcasting using #1 an-tenna, the results would be the same as those of an omni-directional antenna.

IV. HIDDEN TERMINAL AND DEAFNESSPROBLEMS

A. Hidden Terminal Problem

As shown in Figure 4 and 5, if one of H, G, E, S and Jbroadcasts a signal through #1 antenna while A is broad-casting data to B, C and D with #1 antenna, a collisionmay occur. RMDB protocol resolves the hidden terminalproblem by using the directional RTDB/CTDB exchangingand DAC table. The process is conducted as follows inorder:

1) B, C and D receive RTDB from A and reply to A withCTDB through #1 and #3 antennas individually.

2) H, G, J and S may receive CTDBs from B, C and Dwith #1 antenna respectively. N and 0 may receiveCTDBs from B, C and D with #3 antenna respectively.

3) H, G, J and S update the #1 entry of aReceivedCTDBfield in their own DAC table to be Yes. N and 0 updatethe #3 entry of aReceivedCTDB field in their own DACtable to be Yes.

4) To avoid a collision, H, G, J and S should not permit adata transmission through #1 antenna. H, G, J and Sshould delay their data transmission until the value ofthe #1 entry of aReceivedCTDB field is set to be No. Inaddition, ifN and 0 broadcast data through #3 antennawhile A with #1 antenna is communicating with B, Cand D with #3 antenna, it may cause the deafness prob-lem. This is the reason why B, C and D have activatedthe only #3 antenna and inactivated others.

5) When H, G, J and S receive DACK, indicating that Ahas completed a data broadcasting, they update the #1entry of aReceivedCTDB field in the DAC table to beNo.

the current transmissionarea ofA \

- - +: DTDB : RTDB

I...

(a) (b)Figure 6. Examples of the deafness problem

B. Deafness Problem

Figure 6 (a) shows an example of the deafness problembetween a sender and neighbor nodes. Currently A has ac-tivated the only #1 antenna while the others are inactivated.Because node X is out of the transmission range of B, Cand D, it can't receive CTDB from B, C and D. Conse-quently, X does not recognize that A is transmitting. WhenX receives a broadcast data from the upper layer, it maybroadcast RTDB through #1 antenna. If X broadcasts itthrough #1 antenna, A will not receive RTDB from Xthrough #3 antenna because A has inactivated #3 antenna.That is, the deafness problem may occur. In order to re-solve this problem, RMDB protocol defines a new DTDB(Delay To Directional Broadcasting) frame.

1) In Figure 6 (a), X is not aware that A is communicatingwith B, C and D through #1 antenna, so it may broad-cast RTDB through #1 antenna.

2) A can not receive RTDB from X, but H, the neighbornode of A, can receive RTDB with #3 antenna from X.H checks the aReceivedCTDB field in DAC table. If thevalue of the aReceivedCTDB field is No, it normallybroadcasts CTDB through #3 antenna in accordancewith the channel reservation process. However, cur-rently the value of the #1 entry of aReceivedCTDB fieldin DAC table is Yes, because H has already received theCTDB frame from B. This means that H should not es-tablish the communication link with other nodes until Acompletes a data broadcasting. Therefore, H broadcastsDTDB instead of CTDB through #3 antenna as an ac-knowledgement for the RTDB ofX.

3) When X receives DTDB from H, it recognizes thatsome neighbor node is in the process of communicating,so it delays its data broadcasting.

Figure 6 (b) shows an example of another deafness prob-lem. Currently B, C and D communicate with A through#3 antenna. They have inactivated #1, #2, #4 antennas.Because N and 0 have already received CTDB individu-

5 of 7

ally B or C, or both, the value of the #3 entry of aRe-ceivedCTDB field is Yes.

It is assumed that X receives a broadcast data from the up-per layer and broadcasts RTDB through #3 antenna. Cur-rently it is possible that A communicates with B, C, D, andthen X communicates with N and 0 simultaneously with-out collision. Therefore, it appears that X may broadcastRTDB through #3 antenna. However, ifB or C will broad-cast RTDB through #1 antenna after the communicationbetween A and B, C, D is completed, the deafness problemwill occur. That is, N and 0 would not receive RTDB fromB or C. In order to avoid this problem, ifN and 0 receivethe RTDB from X, they send DTDB instead ofCTDB to X.Then, X delays its data broadcasting.

V. PERFORMANCE ANALYSIS

The proposed RMDB protocol has been analyzed for itsperformance with IEEE 802.11 protocol [9] and protocol 2in [3]. To simplify our description, the protocol 2 in [3] isnamed as DNACK (Directional NACK).

A. Simulation Model

The simulation has been conducted by CSIM18 simulator[10] with the parameters practically used in IEEE 802.11protocol. The network for simulation is modeled as fol-lows:

* Nnodes are uniformly deployed in the field of the 300mx 300m of the network.

* Wireless transmission medium operates at the data rateof 1 Mbps in the wireless transmission range of 50m.

* The average number of neighbor nodes (AN) for eachnode is determined according to the number of N, andtable II shows their values.

Table II. The number of neighbor nodes

N 10 20 30 40 50 60 70 80 90 100

AN 1.0 1.7 3.1 3.9 4.9 5.9 7.5 8.5 9.2 10.2

N 110 120 130 140 150 160 170 180 190 200

AN 11.4 12.7 13.9 15.1 16.5 17.9 19.0 20.2 21.5 22.6

Even if the nodes are uniformly deployed, our simulationhas confirmed that the average increasing rate of neighbornodes is proportional to the increasing rate ofN.

B. Simulation Results

The performance ofRMDB protocol has analyzed the suc-cess rate of data broadcasting and the collision rate interms of the number of N. 20 simulations have been indi-vidually conducted for the cases of the different number ofnodes ranging from 10 to 200 in increment of 10. During

the simulation senders were chosen at random and gener-ated a broadcast data in an exponential probability distri-bution. The simulation result has been analyzed with re-spect to the following two performance criteria:

* Success rate of broadcasting: NSBINGB x 100where NSB stands the number of the succeeded broad-casting. NGB is the number of the generated a broadcastdata. The broadcast success in the link layer means thatall of the neighbor nodes have successfully received abroadcast data from a sender.

* Collision rate: NCINB x 100where NC and NB imply the number of collisions andthe total number of the data broadcasted, respectively.

b0

-0

It

5oA

oA,DC5)

100%90%80%70%60%50%40%30%20%10%0%

1 3 5 7 9 1 1 13 15 17 19the number of nodes deployed (*10)

Figure 7. The success rate of broadcasting

Figure 7 shows the success rate of broadcasting with re-spect to N. It was confirmed that the success rate of broad-casting has gradually reduced in proportion to the increas-ing rate of N. In particular, IEEE 802.11 protocolbroadcasts a broadcast data blindly without a channelreservation after physical carrier sensing, and there is noprocess to reward for broadcasting failure. Thus, the num-ber of neighbor nodes, which can not receive the broadcastdata, increases rapidly as N increases. It is shown that thesuccess rate of broadcasting is less than lI% when the aver-age number of neighbor nodes becomes more than 4. Be-cause DNACK protocol broadcasts a broadcast data withdirectional antennas, it could considerably reduce the pos-sibility for a collision. Additionally, it rebroadcasts abroadcast data using NACK when a neighbor fails to re-ceive it. Therefore, the success rate of broadcasting inDNACK protocol was higher than that in IEEE 802.11protocol. RMDB protocol reduces a channel contention byusing MaxSlot, and reserves a shared channel by usingRTDB/CTDB exchange. Thus, its success rate of broad-casting was higher than those of IEEE 802.11 andDNACK protocols.

The success rate of broadcasting has significant ramifica-tions. IEEE 802.11 broadcast protocol does not has both

6 of 7

channel reservation and data rebroadcasting. Thus, thesuccess rate of broadcasting is low. However, the utiliza-tion of system resources, i.e. power or bandwidth etc, ishigh since extra traffic is not generated to guarantee thedata broadcasting. DNACK protocol generates unneces-sary redundant traffic because it rebroadcasts a broadcastdata using NACK. Consequently, each node consumes alot of system resources due to the redundant traffic.RMDB protocol broadcasts a broadcast data through achannel reserved in advance, therefore unnecessary trafficis not generated. However, some degree of additional traf-fic is generated due to the exchange RMDB and CTDB forthe reservation of channel.

2100%

= 1800%0

*" 1500%o 1200%

900%

600%300%

0%

0 802.11 39 17

. DNACK/A RMDB

1 3 5 7 9 1 1 13 15 17 19the number of nodes deployed(* 10)

Figure 8. Collision rate

Figure 8 shows the total collision rate. As N increases by10, the average increase rate of collisions for IEEE 802.11,DNACK and RMDB protocol showed 92.6%, 19.6%, and1.31% respectively. RDMD protocol avoids a collision byimplementing a channel reservation process. Consequently,it could reduce the collision rate considerably. Both IEEE802.11 and DNACK protocol broadcast a broadcast datablindly without channel reservation. Therefore, the colli-sion rate increases rapidly as N increases. In addition, it isshown that the collision rate of DNACK protocol is lowerthan that of IEEE 802.11 protocol. It is due to thatDNACK protocol makes use of directional antennas.

VI. CONCLUSION

This paper proposed RMDB protocol in order to solve"broadcast storm problem" in broadcasting with an omni-directional antenna in wireless network. RMDB protocolsupports a directional broadcasting based on directionalantennas. It has resolved the hidden terminal and deafnessproblems using a DAC table and the 4-way handshake. Inaddition, it has mitigated the collision problem caused by asimultaneous transmission of control frames by usingMaxSlot.

As a result of performance analysis through simulation, itwas confirmed that the collision rate of the RMDB proto-col is lower than those of IEEE 802.11 and DNACK pro-

tocols, and that the success rate of broadcasting ofRMDBprotocol is higher than those of IEEE 802.11 and DNACKprotocols. With these results, it is expected that RMDBprotocol can be used effectively in wireless networks, i.e.,sensor networks, where a number of sensor nodes aretightly interconnected, since RMDB protocol maintainsconstantly low collision and contention, independently ofnetwork density.

REFERENCES

1. B. Williams and T. Camp, "Comparison of BroadcastingTechniques for Mobile Ad Hoc Networks," ACM Mo-bile Ad Hoc Networking and Computing 2002, Jun.2003, pp. 194-205.

2. Y. Tseng, S. NI, Y. Chen and J. Sheu, "The BroadcastStorm Problem in a Mobile Ad Hoc Networks," Wire-less Networks Vol. 8, pp. 153-167. Mar. 2002.

3. Y. Utsunomiya, M. Takahashi, M. Bandai and I. Sasase,"A Medium Access Control Protocol with Retransmis-sion using NACK and Directional Antennas for Broad-casting in Wireless Ad h-Hoc Networks," EuropeanWireless 2004, Feb. 2004.

4. A. Nasipuri, S. Ye, J. You and R. E. Hiromoto, "AMAC Protocol for Mobile Ad Hoc Networks Using Di-rectional Antennas," IEEE Wireless Communicationsand Networking 2000, Sep. 2000, pp. 1214-1219.

5. M. Takai, J. Martin, R. Bagrodia and A. Ren, "Direc-tional Virtual Carrier Sensing for Directional antennasin Mobile Ad Hoc Networks," ACM Mobile Ad HocNetworking and Computing 2002, June.2002. pp. 183-193.

6. R. R. Choudhury, X. Yang, R. R and N. H. Vaidya, "Us-ing Directional Antennas for Medium Access Control inAd Hoc Networks," ACM Mobile Ad Hoc Networkingand Computing 2002, Jun. 2002. pp. 59-70

7. A. Nasipuri, J. Mandava, H. Manchala and R. E. Hiro-moto, "On Demand Routing Using Directional Anten-nas in Mobile Ad Hoc Netowrks," IEEE ComputerCommunication and Networks 2000, Oct. 2000.

8. R. R. Choudhury and N. Vaidya, "On Ad Hoc RoutingUsing Directional Antennas," Illinois Computer SystemsSymposium(iCSS), May. 2002.

9. IEEE 802.11 Working Group, "Part 11: Wireless LANMedium Access Control (MAC) and Physical Layer(PHY) Specifications," ANSIIIEEE Std. 802.11, Sep.1999.

10. Mesquite Software Inc., CSIM1 8 Simulation Engine

7 of 7