Presentation is loading. Please wait.

Presentation is loading. Please wait.

MARCH : A Medium Access Control Protocol For Multihop Wireless Ad Hoc Networks 2007. 5. 23 성 백 동

Similar presentations


Presentation on theme: "MARCH : A Medium Access Control Protocol For Multihop Wireless Ad Hoc Networks 2007. 5. 23 성 백 동"— Presentation transcript:

1 MARCH : A Medium Access Control Protocol For Multihop Wireless Ad Hoc Networks 2007. 5. 23 성 백 동 iceboy98@hufs.ac.kr

2 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

3 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

4 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

5 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

6 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

7 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

8 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

9 The MARCH Protocol The Overhearing Mechanism The overheard CTS 1 packet can be used to convey the information of a data packet arrival at MH B to MH C 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

10 The MARCH Protocol 10 The RTS-CTS handshake in MACA The proposed handshake mechanism in MARCH protocol

11 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(RT ID ) Assume  each MH keeps sensing the channel and will not transmit until the channel is free 11

12 The MARCH Protocol Two routes - can be established through an appropriate routing protocol Route 1 consists of MH A, MH B, MH C, MH D Route 2 includes MH Y, MH C, and MH Z MH Z will overhear the CTS 2 packet To avoid MH Z 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

13 Two overlapping routes in an ad hoc mobile network The MARCH Protocol 13 X A BC Z D Y RTS 1 CTS 1 CTS 2 Overhear CTS2 To avoid MH Z misinterpreting, the RT ID method Include Timer T W Route 1 Route 2

14 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

15 Network topology Performance Evaluation 15 1 Route 1 Route 2 23 8 9 4 5 7 6 10m

16 Performance Evaluation End-to-End Throughput Under high traffic load, MARCH achieves about 66% improvement when compared to MACA  The reduced handshake mechanism MH 2 must content with MH 1 and MH 3 for the channel  It is difficult for MH 2 to forward data packet to MH 3  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

17 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 17 Route Control Overhead

18 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 MH 2 and MH 7  Packet queueing due to collisions does not happen in MARCH until the traffic load is above 100 pkt/sec 18 End-to-End Delay

19 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


Download ppt "MARCH : A Medium Access Control Protocol For Multihop Wireless Ad Hoc Networks 2007. 5. 23 성 백 동"

Similar presentations


Ads by Google