MARCH : A Medium Access Control Protocol

For Multihop Wireless Ad Hoc Networks

2007. 5. 23성 백 동

iceboy98@hufs.ac.kr

< 출처 - IEEE 2000 > <Sensor Network Seminar 2007 >

Agenda

Abstract Introduction Related work

Sender-Initiated MAC Protocols Receiver-Initiated MAC Protocols

The MARCH Procotol The Overhearing Mechanism MARCH Illustration

Perframance Evaluation End-to-End Throughput End-to-End Delay

Conclusion

2

Abstract

MARCH utilizes the broadcast characteristics of an omnidirectional

antenna to reduce the number of control message RTS-CTS handshake is used only by the first hop of a route

collision is reduced and channel throughput is increased

3

Introduction

A multihop wireless ad hoc network consists of mobile hosts(MHs) equipped with radio devices to cooperatively form a communication network MHs

may not be within transmission range of each other Can build a connection through other MHs

Need to MAC protocol Use a common radio channel to communicate with one another CSMA

Simple hidden terminal problem

Degrades performance

4

Introduction

Other protocols Developed various MAC protocol with an additional control handshake

before data transmission sender-initiated protocols receiver-initiated protocols

less control overhead is required Outperform sender-initiated protocol but vulnerable

MARCH(Multiple Access with ReduCed Handshake) combines the advantages of both sender- and receiver-initiated

protocols reduces the number of handshakes Outperform sernder-initiated protocol

5

Related work

Sender-Initiated MAC Protocols MACA(Multiple Access Collision Avoidance)

Use a request-response dialogue to solve the HTM problem Request-to-send(RTS) and Clear-to-send(CTS)

MACAW Improvement of MACA Use more handshakes to handle problems associated with control

packet collision FAMA(Floor Acquisition Multiple Access)

Improve MACA Adds carrier sensing capability in order to reduce the possibility of

collision Performance is quite limited when the traffic load is high

high probability of control packet collision A lot of reTX and lowering the channel throughput

6

Related work

Receiver-Initiated MAC Protocols reduce the number of control packets MACA-BI(MACA By Invitation)

Based on the prediction predict the packet arrival time at its neighboring MHs

send ready-to-receive (RTR) packets RIMA(Receiver Initiated Multiple Access)

Improved MACA-BI Employs a new packet arrival prediction method

Assumes that all MHs have the same packet arrival rate. When an MH receives a data packet, it assumes that its neighboring MH

also receives a data packet. It then sends an RTR packet to invite the neighboring MH to transmit.

Reduce control overhead if the data packet arrival at a sender can be correctly predicted by its

receiver

7

The MARCH Protocol

reduced the amount of control overhead. Operates without resorting to any traffic prediction

Exploits the broadcast characteristic of omnidirectional antennas to reduce the number of required handshakes

Approach An MH has knowledge of data packet arrival at its neighboring

MHs from the over heard CTS packet. It can then initiate an invitation for the data to be relayed

8

The MARCH Protocol

The Overhearing Mechanism The overheard CTS1 packet can be used to convey the information

of a data packet arrival at MHB to MHC Figure shows the new handshake process through the route RTS-CTS handshake reduced to a single CTS(CTS-only)

handshake after the first hop Reduction in the control overhead is a function of the route length Ad hoc route of L hops

The number of handshakes needed to send a data packet from the source to destination

2L in MACA , L in MACA-BI, and (L+1) in MARCH If L is large, MARCH will have very similar number of handshakes as in

MACA_BI

9

The MARCH Protocol

10

The RTS-CTS handshake in MACAThe proposed handshake mechanism in MARCH protocol

The MARCH Protocol

MARCH Illustration Include information in an CTS/RTS packet

The MAC address of the sender and the receiver The route identification number(RTID)

Assume each MH keeps sensing the channel and will not transmit until the

channel is free

11

The MARCH Protocol

Two routes - can be established through an appropriate routing protocol Route 1 consists of MHA , MHB , MHC, MHD

Route 2 includes MHY , MHC, and MHZ

MHZ will overhear the CTS2 packet To avoid MHZ misinterpreting it and initiating an unnecessary CTS-

only handshake

The MAC Layer has access to tables that maintain information on the routes the node participates Consult to understand if it should respond to a control msg to

certain route

MARCH does not participate in routing, nor makes any decisions about the data packets exchanged in the network layer

12

Two overlapping routes in an ad hoc mobile network

The MARCH Protocol

13

X

A

B C

Z

D

Y

RTS1

CTS1

CTS1

CTS2

CTS2

Overhear CTS2To avoid MHZ misinterpreting, the RTID method

Include Timer TW

Route 1

Route 2

Performance Evaluation

Test environment Simulations using the OPNET tool Compared the performance( throughput , overhead and delay)

of MARCH with MACA Neighboring MHs are separated by 10 m Each MH is within the tx range of its upstream and downstream

MH2 The channel is considered to be error free and its capacity is

1Mbps Data size = 2048 bits Control packet size = 128 bits Generate data packets according to a Poissaon process with an

arrival rate varying from 10 pkt/sec to 350 pkt/sec The TX-RX/RX-TX turn-around time of a radio transceiver is 25

usec and the length of a time slot is 1 usec

14

Network topology

Performance Evaluation

15

1

Route 1

Route 2

2 3

8

9

45

7

6

10m

Performance Evaluation

End-to-End Throughput Under high traffic load, MARCH achieves about 66% improvement

when compared to MACA The reduced handshake mechanism

MH2 must content with MH1 and MH3 for the channel It is difficult for MH2 to forward data packet to MH3

RTS packets transmitted by MH2 may collide at MH3, with other packets coming from MH7 , MH4, or MH8

In MARCH Transmissions between MH2 and MH3

The CTS packets from MH3 may only collide with RTS packets from MH1

16

End-to-End Throughput Performance

Performance Evaluation

The control overhead associated with each protocol in MACA

when the traffic load is greater than 50 pkt/sec, control packet collisions result in a lot of reTX

an increase in control overhead in MARCH

has a lower probability of control packet collision Its control overhead is much less than MACA at all traffic loads

17Route Control Overhead

Performance Evaluation

End-to-end Delay Under light traffic load, the delay in MARCH is higher than MACA

The reduced handshake mechanism introduces an extra delay close to the packet inter-arrival time at each intermediate MH

As the traffic load increases beyond 50 pkt/sec the delay in MACA grows significantly when compared to MARCH

since control packet collisions cause a lot of queuing delay at MH2 and MH7

Packet queueing due to collisions does not happen in MARCH until the traffic load is above 100 pkt/sec

18End-to-End Delay

Conclusion

MARCH improves throughput, delay, and control overhead performance by

reducing the number of handshakes Exploits the fact that control messages are overheard by

neighbors More deterministic and does not resort to network prediction

The concepts can be applied to other multi-channel MAC protocols to further improve their communication performance

19