SMART MEDIUM ACCESS CONTROL (SMAC) PROTOCOL FOR MOBILE AD HOC NETWORKS USING DIRECTIONAL ANTENNAS

SMART MEDIUM ACCESS CONTROL (SMAC) PROTOCOL FOR

MOBILE AD HOC NETWORKS USING DIRECTIONAL ANTENNAS

P. Sai Kiran

Associate Professor, School of Computer Science and Informatics,

SreeNidhi Institute of Science and Technology, Ghatkesar, Hyderabad., Andhra Pradesh, India.

psaikiran@hotmail.com

A

BSTRACT

This paper proposes a Smart Medium Access Control (SMAC) Protocol for Mobile Ad Hoc Networks (MANET) using Directional Antennas. SMAC protocol exploits the Directional Transmission and sensing capability of the Directional Antennas there by increasing the Performance of MANET. SMAC protocol proposes a Dual Channel Approach for Data and Control Information to overcome deafness and Hidden terminal problems. SMAC protocol proposes a new Node Mobility update Model used for addressing Node Mobility. SMAC protocol also uses alternate method to backoff timer, processing the data packets in the queue ready for transmission in other directions when the data packet in the front of the queue to be transmitted finds channel busy in its direction. SMAC has the advantage over other MAC protocols proposed for Directional Antennas as it addresses all the issues like Mobility of Node, Deafness, Hidden Terminal etc.

1. INTRODUCTION

According to the definition of IEEE 802.11: A network composed solely of stations within mutual communication range of each other via the wireless medium (WM).

Traditional MAC Protocols such as IEEE 802.11 DCF (Distributed Coordination Function) and IEEE 802.11 Enhanced DCF designed for Omni-directional antennas and cannot achieve high throughput in ad hoc networks as they waste a large portion of the network capacity. On the other hand, smart antenna technology can improve spatial reuse of the wireless channel, which allows nodes to communicate simultaneously without interference.

The capabilities of directional antennas were not exploited when using conventional MAC protocols, such as IEEE 802.11.

In fact, the network performance may even deteriorate due to issues specific to directional antennas. There are many protocols proposed that exploits the directional antenna capabilities while addressing the specific issues of the MAC protocols using directional antennas. We want to propose a MAC protocol using directional antennas that will not only concentrate on spatial reuse but also on throughput and performance of the protocol.

This Paper is organized as Follows: Section II deals with brief description of Previous MAC Protocols for MANET using directional antennas, section III deals with Design Considerations for a proposed SMAC Protocol, Section IV Gives the working of the proposed SMAC protocol, Section V Analyses the SMAC Protocol while Section VI Concludes the Paper.

2. P

REVIOUS

MAC P

ROTOCOLS FOR

D

IRECTIONAL

A

NTENNAS

Most of the protocols proposed for directional antennas are extensions to the (DCF) of IEEE 802.11, which comprises physical and virtual carrier sensing implemented by an RTS/CTS handshake preceding the data transmission.

Directional MAC (DMAC): One of the first modifications of DCF that aims at directional antennas was proposed in the D- MAC protocol [20]. It is a rather straightforward extension of the 802.11 protocol. Here, RTS, DATA, and ACK packets are sent directionally. Alternatively, RTS packets are sent omnidirectionally if none of the directional antennas of the transmitter is blocked. This protocol did not address the deafness problem, Hidden terminal problems and node Mobility problems.

In Nasipuri et al.[15], proposal, the source and destination nodes use omnidirectional RTS/CTS to build up the handshake.

The sender and receiver estimate the location of each other by noting the antenna that received the maximum power of the RTS/CTS packets. Then they use the antennas facing each other to transmit data directionally. This protocol can be applied to mobile environments but did not address deafness problem and hidden terminal problems.

In Directional Virtual Carrier Sensing (DVCS) scheme [16], each network node is assumed to have an electrically steerable antenna system, which can change the beamforms of the antenna dynamically. Each node will cache the estimated AoAs of its neighbors when it hears any signal, regardless of whether the signal is targeted at the node. When it has data to send, if location information of the destination node is available, it will beaform at that direction, otherwise it will send RTS omni directionally. The protocol also uses Directional Network Allocation Vector (DNAV) to maintain a unique timer. DNAV is a directional version of NAV (Network Allocation Vector) in IEEE 802.11, which reserves the channel for others only in a range of directions. This protocol did not address Deafness problem and Hidden terminal problems.

The Dual Busy Tone Multiple Access with Directional Antennas (DBTMA/DA) [14] is a variation of DBTMA by using directional antennas. The switched beam directional antenna model is adopted in this paper. In addition to the directional transmission of RTC/CTS and data packets, a tiny busy tone is used to avoid collisions in a much finer grain with increased spatial reuse and channel capacity. Two busy tones: transmission busy tone and reception busy tone are assigned two separate single frequencies in the control channel. A node hearing a transmission/reception busy tone will defer receiving/transmitting, which alleviates both the hidden and exposed terminal problems. This protocol did not address the deafness and node mobility.

The Tone-based directional MAC (ToneDMAC) [9] protocol seeks to indicate deafness to blocked transmitters and thus increase fairness. Using omnidirectional tones after the DATA/ACK exchange, both transmitter and receiver indicate that they were recently engaged in communication. Thus, a neighboring node can realize deafness if it overhears a tone from its intended receiver. In this case, the node reduces its contention window to the minimum value and has thus a fair chance to win the next channel contention. This protocol did not consider the node mobility.

3. D

ESIGN

C

ONSIDERATIONS

F

OR

T

HE

SMAC P

ROTOCOL

3.1 Antenna Model

The Best Design consideration for a MAC protocol using Directional Antennas is Smart Antenna. This Protocol although considers the smart antenna as the choice for designing the protocol, also supports nodes with other directional antenna models like switched beam antennas.

3.2 Directionality

If the Antenna Model is smart antenna, the transmission would be very accurate in the direction of transmission. In this protocol, the 360⁰ coverage is divided into number of segments based on the directionality in the clock wise direction.

If the Antenna type is switched beam antenna, then the number of segments would be equal to the number of directional antennas in the switched beam and the numbering of the segments would be given in the clock wise direction.

If we consider an example of switched beam antenna with 6 directional antennas, the segments numbering would be as indicated in the Figure 1.

Figure 2 considers the usage of Smart Antennas where the number of segments would be based on the level of spatial reuse required and to reduce the interference.

3.3 Sensing the Medium

The Design Consideration for sensing the medium in this protocol is directional carrier sensing. If the data is to be transmitted to a segment, then this protocol requires not only the segment in the directional of the target to be free or idle but also the immediate neighboring segments should also be free from transmission.

For example, if we consider the Figure 1 and if the direction of intended transmission is segment 2 then the node would initiate transmission only when the segments 1, 2 and 3 are found to be free of transmission. This Design option considers the node

mobility (source or destination), that was neglected by many of the previous protocols for MANET using directional Antennas.

3.4 Information at each node

Every node maintains information indicating the direction of neighboring nodes as well as the status of the segments whether the segments can be used for transmission and free from any transmission in that direction.

This information will be maintained in two tables at each node.

TABLE 1:NEIGHBOR NODE INFORMATION

Node Segment Number Status Source Destination

3.4.1 Neighboring Node Information Table

This table would indicate the direction of the nodes in the form of segment numbers and this information will be used to communicate with the nodes using the segment numbers indicated. The Source Segment number indicates the segment being used by the source to reach the destination node. The destination segment number indicates the segment through which the destination node receives this packet. The status would indicate the state of the node whether the node is busy in transmission or not. This status information is very much needed and used in this protocol so as to avoid the Deafness problem.

This would indicate that the node is busy in transmission, so it is not responding to the RTS request of a node.

An Entry of the node in this table would indicate that the node is within the coverage Area of the current node.

3.4.2 Segment Table

This table will have the information about the segment and the status of the segment (Busy/Idle).

The structure of the table is as shown in Table 2.

TABLE 2:SEGMENT TABLE

Segment Number Status Waiting

The Segment number will indicate the segment and the status will be either Busy or Idle. Waiting field is just a single bit indicating 0 or 1. Bit 1 indicate that one or more packets are waiting in the backoff queue for the segment to be free.

Need for Two Tables: We are maintaining two different tables one to indicate the node status and another to indicate the Segment status. Segment table is needed as we need to check for

FIGURE 1:SEGMENT NUMBERING FOR SWITCHED BEAM ANTENNA

1 2

3 4 5 6

FIGURE 2:SEGMENT NUMBERING FOR SMART ANTENNA

2 1

3 8

7 5 6

4

the availability of the segments free from transmission. On the other hand waiting bit in the table would reduce the time needed to search if any packets are waiting for the segment to be free or not.

In Figure 1, as mentioned if we are using segment 2 for

transmission we will also block any transmission from segment 3 and a and thus will indicate that segment 1,2 and 3 to be busy in the segment table.

3.5 Channel

The Channel will be divided in to two sub channels Control channel and Data channel. The Control channel will be used to send the control information through node updates for maintaining the tables.

The Data channel will be used to transmit RTS-CTS-Data etc. The Node can simultaneously transmit in both channels without any interference.

3.6 Mobility Updates

All the nodes in this network will transmit a update message to all its neighboring one hop nodes in directional mode.

The update packets will be transmitted to one segment at a time. The update packet format is as shown in figure 3.

The Fields in the packet are

Source node ID: The Node ID transmitting the packet.

Segment Number: The Segment Number used by the sender node to transmit the update packet.

Status: This field is used by the node to inform the one-hop neighbor about the status of transmission in different segments of the node. If the sender node is transmitting the data using the segment 1 in a 6 segment node. As we want to reserve the segments 2 and 6 i.e immediate segments, the status would indicate that the segments 1,2, and 6 are busy and would indicate by 1 in those bit positions.

3.6.1 Sensing the Medium

A node will sense the medium periodically in a particular segment direction and would transmit the update packet in that direction. If the Medium is found to be busy, then it would switch on to the next segment after waiting in omni-directional mode for a certain period of time. The node shifts to omni directional mode to listen to other update messages if any transmitted by other nodes through any other segments.

A node maintains single bit information for each segment, whether it had transmitted update packet in a particular segment direction or not. If it had already transmitted the update packet in a segment direction then it would make the bit position of the segment number to be 1. If it had failed to sense the medium to be idle then it would keep the bit value to zero.

3.6.2 Transmission

When the node finds the medium to be idle in a particular direction, then it would transmit the request-to-transmit (RTS) packet in that direction. Here the node would not address any node in that direction as it will not be sure about the identity of the nodes in that direction. Any node receiving this RTS packet would respond with a Clear to Send (CTS) packet with its ID.

The RTS packet will have the sender ID. The receiving node will

update neighbor node table about the sender node location. The CTS packet transmitted by the receiving node will have its ID for the sender node to update its table about the node location. The sender node after receiving the CTS would transmit the update packet about the status of the node in that Direction.

The receiving node after receiving the update packet would piggyback the Acknowledgement with the Update Message to the sender. Thus, the two nodes would update their tables when one node successfully accesses the channel.

3.6.3 Delivery of Update Messages

A node for each segment would maintain single Bit to indicate the transmission of update packet. The Node will update the Bit to 1 after transmitting update packet. The transmission can be by the node initiating the transmission of update packet in that segment direction or by responding to the update packet transmitted by piggybacking. Before sensing another segment in increasing order, the node would check the status of update message delivery for any previous segments and would give another chance. A new round starting from segment 1 initiated only after successfully transmitting update messages in all the directions.

3.6.4 Timeouts and Retransmission

When a node senses the medium in a particular direction or segment and finds to be free, it transmits RTS packet. A node after transmitting a RTS packet will not receive a CTS packet if there is no node in that direction or the node in that direction does not respond because of deafness problem. The sender node would timeout before receiving any CTS packet from the other node. The node would retransmit the RTS message for three consecutive times before giving up. After three attempts it would make the update bit set to 1.

Because of the design option that a node not only initiates the transmission of updates packet but also piggybacks the received update packet form another nodes. The probability of update packet missing transmission in a particular direction is very less.

3.7 Queue Model

SMAC protocol uses different queues apart from a Ready queue that will maintain the packets ready to transmit. SMAC maintains a queue called nodenotfound to store the packets for which the destination node not found. SMAC also maintains N number of backoff queues where N is the number of segments for a node.

For example, Node with Figure1 Antenna would maintain 6 backoff queues apart from nodenotfound queue and ready queue.

4. WORKING OF PROPOSED PROTOCOL

The proposed SMAC uses Directional transmission scheme.

SMAC protocol uses alternative method [1] to back off, when the direction in which the packet to be transmitted is found busy.

4.1 Carrier Sensing and Backoff

The SMAC protocol uses alternate method that processes the data packets in the queue ready for transmission in other directions when the data packet in the front of the queue to be transmitted finds channel busy in its direction.

Initially a node read the packets that are ready for transmission from the ready queue. It would read the Destination Node ID from the packet header and see for the existence of the node in the neighbor node table. SMAC will process the packet further if it finds node in the table. SMAC will place the packet in nodenotfound queue if it does not find the node in the table.

The packets placed in nodenotfound queue will get a chance two more times for transmission before informing the routing Source

Node ID

Segment Number

No of

Segments

Status M bits to

represent N segments

N bits to represent status of N

segments

FIGURE 3:UPDATE PACKET FORMAT

protocol about the unavailability of the node. For this, single bit is added to the header part of the packet and initialized to 0.

If SMAC finds the destination node information, it will get the destination node segment. SMAC will find the status of the segment and the neighboring segments for transmission. If the status of the segments is found idle then the SMAC will proceed with packet transmission after RTS, CTS exchange. If the segments are found busy then the packet will be placed in to the Backoff queue for that segment. The waiting Bit will be updated to 1 by the SMAC after placing the packet in the Backoff queue.

SMAC will then proceed to the next packet ready in the queue. It will check whether the next packet in the queue belongs to the same destination of previous packet. If the previous packet was transmitted successfully then this packet will also be transmitted and if the packet was placed in to Backoff queue then this packet will be placed in to the Backoff queue without further processing.

4.2 Data Transmission

Once the carrier is sensed to be idle in the intended direction, the sender node will transmit a RTS(Request to Send) message indicating the transmission. The Destination node would update its segment table about the transmission and respond with a CTS message. The Sender before transmitting an RTS message would update its segment table with the segment for transmission. Once the sender receives the CTS message, it would start data transmission. Sender and destination nodes will update the segment tables after completing the transmission.

4.3 Processing Backoff Queues

SMAC protocol would process Backoff queues when the next packet in the ready queue is having different destination node to that of previous packet. SMAC would check the segment table to see if any segment waiting bit set to 1 and status is idle.

This would mean that the segment, which was busy, previously is now idle and there are packets in the Backoff queue for that segment.

SMAC protocols would identify those segments and would process the packets in that segment backoff queue and transmit all the packets of the segment. Before transmitting the packets, the SMAC would check the neighboring node table to see whether the node is still in that segment or moved to a new segment. If SMAC does not find the node information in the neighboring node table then the packets for that node will be shifted to nodenotfound queue. If the node is moved to a new segment because of node mobility then the segment to which the node moved will be verified to see if the status is idle or not. If the status of the segment is idle then the packets will be transmitted in that segment direction. The packets will be placed to the New segment backoff queue if the status of the segment is busy. Once all the packets in the segment backoff queue are processed, waiting bit of the segment will be set to 0.

4.4 Processing nodenotfound Queue

SMAC protocol will also process the nodenotfound queue after processing the Backoff queues. A packet in the nodenotfound queue will be tried for transmission twice before initiating the node not found message to the routing protocol. All the packets in the nodenotfound queue will be processed before leaving the queue. If the packet destined to a node is found in the neighbor node table then the packet will either be transmitted or placed in the backoff queue for that segment depending on the status of the destination node. If the node information is still not available then the node bit is modified to 1 if it is zero. If the node bit is already 1 indicating that the packet is being tried for transmission for second time, the packet will be discarded from

the nodenotfound queue and informs the network layer that node is not available.

5. ANALYZING THE PROTOCOL

This section gives information about how the proposed protocol addresses various issues of the MAC protocol using directional antennas for MANET.

5.1 Throughput

The SMAC uses an alternate method to the backoff timer used by all the previous protocols. This method makes use of directional transmission thus increasing throughput. This protocol does not wait for a segment to be free by initiating backoff timer but shifts to another packet ready for transmission in another segment direction. This will improve the throughput of a system and also increases the overall performance in terms of spatial reuse and throughput.

5.2 Overhead

The overhead involved in this protocol is in transmitting the control information to all the neighboring nodes. This protocol uses two channels, data channel and control channel. Since the control information is transmitted through control channel and does not interrupt the transmission in data channel. The overhead involved does not affect the performance of the protocol. This protocol is also scalable as the number of nodes in the network does not affect the overhead involved as the control information is transmitted between neighboring nodes only.

5.3 Mobility

This is one of the few protocols proposed for MAC using directional antennas addressing the node mobility. Mobility issues for a MAC protocol using directional antennas are node mobility during transmission and node mobility in idle state.

This protocol uses control information to keep track of the node mobility when the node is not transmitting. During the transmission to overcome the node mobility and the possible interference because of the node mobility and directional transmission, this protocol not only reserves the segment in actual destination node direction but also reserves the immediate neighbor segments. The nodes do adjust their transmission using the angle of arrival or any other algorithm for beam forming in the intended direction.

5.4 Spatial Reuse

This protocol increases the spatial reuse as the nodes can transmit in other directions when a node is transmitting in a particular direction. SMAC protocol reserves three segments even though required transmission needs only one segment to cope with node mobility and reducing interference. This approach even though looks like reducing the spatial reuse without which the spatial reuse can be high. This approach is much needed to address the node mobility and interference problem. With the new method that is an alternative to the back off timer method, this scheme may restrict a node to transmit data in one direction but it can initiate transmission in other free directions.

5.5 Deafness and Hidden Terminal Problems

A node is “Deaf” to the signals from some other node while it beamformed in another direction resulting in multiple packet drops due to increase in the back off time to a limit. The node availability information and the alternate method proposed in this protocol for backoff timer eliminates the Deafness problem. This

protocol also overcomes Hidden Terminal problems with the information about the state of the neighboring nodes.

6. CONCLUSION

This paper proposed a new MAC protocol using Directional Antenna. We tried to exploit the Directional transmission capabilities of the directional antennas to improve throughput, spatial reuse and overall performance of communication. This paper introduced Node Mobility model using control information transmitted through control channel. The node mobility model is designed to be used not only for this SMAC but also for routing protocols and transport layer services like TCP and Quality of Service connection establishment and IP Address Configuration etc,. This paper included a method alternate to the backoff timer to increase the throughput. This protocol overcomes the various problems like Hidden Terminal problem, Deafness, Information Staleness and Node Mobility problem that are specific to the MAC protocols for MANET using directional antennas.

This Protocol can be further extended to include service differentiation for providing Quality of Service problem.

REFERENCES

[1] P. Sai Kiran, “Increasing throughput using directional antennas in Wireless Ad Hoc Networks”, IEEE ICSCN’06.

[2] P. Sai Kiran, “A survey on mobility support by MAC protocols using directional antennas for wireless ad hoc networks”, in Proc, IEEE ISAHUC2006.

[3] P. Sai Kiran, “Statefull Addressing Protocol (SAP) for Mobile Ad Hoc Networks”, in proc, IASTED CIIT’07, [4] C. Siva Ram Murthy & B. Manoj; “Ad Hoc Wireless

Networks , Architectures and Protocols”, Prentice Hall, 2004

[5] Hongning Dai, Kam-Wing Ng and Min-You Wu, An

“Overview of MAC Protocols with Directional Antennas in Wireless ad hoc Networks”, ICWMC 2006, Bucharest, Romania, July 29-31, 2006

[6] Masanori Takata, Masaki Bandai and Takashi Watanabe,

“Performance Analysis of a Directional MAC for Location Information Staleness in Ad Hoc Networks”, ICMU 2005 pp.82-87 April 2005.

[7] Ram Ramanathan, Jason Redi, Cesar Santivanez, David Wiggins , and Stephen Polit, “ Ad Hoc Networking with Directional Antennas: A Complete System Solution” IEEE Communications, March 2005.

[8] Jungmin So, Nitin Vaidya , “Multi-Channel MAC for Ad Hoc Networks: Handling Multi-Channel Hidden Terminals Using A Single Transceiver”, in proc, MobiHoc’04, May 24–26, 2004.

[9] Romit Roy Choudhury and Nitin H. Vaidya, “Deafness: A MAC Problem in Ad Hoc Networks when using Directional Antennas”, in proc ICNP’04.

[10] Tetsuro Ueda, Shinsuke Tanaka, Siuli Roy, Dola Saha and Somprakash Bandyopadhyay, “Location-Aware Power- Efficient Directional MAC Protocol in Ad Hoc Networks Using Directional Antenna”, IEICE 2004.

[11] Michael Neufeld and Drik Grunwald, “Deafness and Virtual Carrier Sensing with Directional Antennas in 802.11 Networks”, Technical Report CU-CS-971-04, University of Colorado.

[12] Ajay Chandra V. Gummalla and John O.Limb , “Wireless Medium Access Control Protocols”, IEEE Communications Surveys and Tutorials, Second Quarter 2000

[13] Romit Roy Chowdary, Xue Yang, Ram Ramanathan and Nitin. H Vidya, “Using Directional Antennas for Medium

Access Control in Ad Hoc Networks”, MOBICOM ’02 Sep 23-28 2002

[14] Z. Huang, C.-C. Shen, C. Srisathapornphat and C. Jaikaeo,

“A busy-tone based directional MAC protocol for ad hoc networks,” in Proc. IEEE Milcom, 2002.

[15] A. Nasipuri, S. Ye and R. E. Hiromoto, “A MAC protocol for mobile ad hoc networks using directional antennas,” in Proc. IEEE WCNC, 2000.

[16] M. Takai, J. Martin, A. Ren and R. Bagrodia, “Directional virtual carrier sensing for directional antennas in mobile ad hoc networks,” in Proc. ACM MobiHoc, 2002.

[17] L. Bao and J.J. Garcia-Luna-Aceves, “Transmission scheduling in ad hoc networks with directional antennas,” in Proc. ACM MobiCom, 2002.

[18] S. Bandyopadhyay, K. Gyoda, K. Hasuike, S. Horisawa, Y.

Kado, S. Tawara, “An Adaptive MAC Protocol for Ad Hoc Networks with Directional Antenna” IEICE TRANS.

COMMUN., VOL. E84-B, No.11 Nov 2001.

[19] Robert Vilzmann and Christian Bettstetter, “ A Survey on MAC Protocols for Ad Hoc Networks with Directional Antennas”

[20] Y.-B. Ko, V. Shankarkumar and N. H. Vaidya, “Medium access control protocols using directional antennas in ad hoc networks,” in Proc. IEEE Infocom, 2000.

[21] IEEE802.11 working group, Wireless LAN Medium Access Control(MAC) and Physical Layer (PHY) specifications, 1999