MARCH : A Medium Access Control Protocol For Multihop Wireless Ad Hoc Networks

1. <Sensor Network Seminar 2007 > <출처 - IEEE 2000 > MARCH : A Medium Access Control ProtocolFor 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

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

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

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

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

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

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

9. 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

10. The MARCH Protocol 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(RTID) • Assume • each MH keeps sensing the channel and will not transmit until the channel is free

12. 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

13. The MARCH Protocol Overhear CTS2 To avoid MHZ misinterpreting, the RTID method Z X D Include Timer TW CTS2 CTS1 B C CTS1 CTS2 RTS1 A Y Route 1 Route 2 Two overlapping routes in an ad hoc mobile network

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

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

16. Performance Evaluation End-to-End Throughput Performance • 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

17. Performance Evaluation Route Control Overhead • 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

18. Performance Evaluation End-to-End Delay • 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

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