6590 Research Paper Review: MAC Protocol for Multi-Hop Multicast in Adhoc Networks

MAC Protocol for Rel iable Multicast over Multi-Hop

Wireless Ad Hoc Networks

Osama Askoura

EECS6590 paper review

1

Roadmap

• Introduction

• Prior Works

• The Algorithm

• Performance Analysis

• Discussion

• Conclusion

2

What are ad-hoc networks?

3 Fig1: Ad-hoc Network Example. Sources: Google Images

Why are ad-hoc networks important ?

4

Fig2: Ad-hoc Network Applications. Sources: Google Images

What is multicast?

5

Fig3: Multicast Example. Sources: Google Images

Bob

Mike

Yan

Tell Bob, Mike and Yan, Food is north

MAC Protocol for Rel iable Multicast over Multi-Hop

Wireless Ad Hoc Networks

6

No RTS/CTS in IEEE802.11 multicast

• MAC layer is based on one-hop broadcast from source to multiple receivers.

• IEEE802.11 does not sustain RTS/CTS or ACK in multicast.

• This yields unreliable communication.

– No guarantee of delivery

– Hidden Terminal Problem

7

Introduction • Increasing MAC reliability adds MAC

overhead

• This paper proposes a MAC protocol that uses RTS/CTS using OFDMA concepts.

• Introduces RTS/CTS to Multicast MAC Protocol

• CTS’s are sent on orthogonal frequencies all at once.

8

Prior Works

• MMP (Multicast MAC Protocol)

• LBP (Leader based protocol)

• ELBP (Enhanced Leader Based)

• BMMM (Batched Mode Multicast MAC)

9

Prior Works

• ABM/MMP (Multicast MAC Protocol)[Gossain 2004]

– Uses ACK (ACK-Based-Multicast) Receive

members reply in specific order to avoid

collision at sender

– Ensures some reliability

– Still suffers hidden terminal problem

10

Prior Works • LBP (Leader-based Protocol) [Kuri 2001]

– Only one “leader” member sends ACK or CTS

– Performs well in low mobility networks

– Suffers in high mobility networks (MAC overhead choosing leader every time leader leaves)

– Other problems if leader couldn’t decode he’s the leader to send CTS

– Problem if others couldn’t decode received messages or who’s leader

– Problem if only leader received message. Others didn’t; It still assumes all did

– Still suffers hidden terminal problem (only leader CTS’s)

11

Got it!

Prior Works

• ELBP (Enhanced Leader Based) [Bao 2005]

– Uses RTS-CTS-SEQ-DATA-NACK

– SEQ indicates data frame is multicast

– Problem if member don’t receive both SEQ and

Data

– Still suffers hidden terminal problem

12

Prior Works

• BMMM (Batched Mode Multicast MAC) [Sun 2002, Sun 2003]

– Uses RTS/CTS and ACK for all member

nodes

– Uses two channels for data transmission

and ACK

– Suffers high overhead

13

PRO Algorithm Overview • Solves

– Hidden Terminal Problem

– Packet Loss due to channel error

– High overhead in MAC; thus high throughput

• Uses – RTS/CTS & ACK

– CTS is sent concurrently over orthogonal channels

– Back-off is doubled up to Wmax if ACK not received.

14

Example

15

Algorithm Details • Each member has unique pre-assigned subcarrier

location/bit in an OFDM symbol

• Sets this bit to BPSK +1, if successfully decoded

RTS/DATA

• Sets this bit to BPSK -1, if received but failed to

decode RTS/DATA. Sender resends RTS/DATA

• If member cannot decode MAC header of RTS. No

CTS is sent

16

Algorithm Flow Chart

• Solves

– Hidden Terminal Problem

– Packet Loss due to channel error

– High overhead in MAC; thus high throughput

17

Algorithm Design issues • Who assigns the sub-carriers to members?

– A multicast leader (ML)

– Members broadcasts (MJREQ) to join, leader receives it and assign empty subcarrier. (max of 52)

– Sends (MJACK) to confirm join and includes sub-carrier location

• How can a leader leave multicast group? – Leader chooses a member at random

– Unicasts (MLREQ) to it. Member should reply (MLACK)

– If no reply within time threshold. Leader select another member until a new ML is selected

18

Algorithm Design issues • What if there’s no leader? Leader fails

suddenly? – Matters only when new member join; no leader means no (MJACK) is

sent within time threshold to MJREQ

– New member claims leadership of the group

19

Performance Analysis • Numerical Analysis was performed

• Considered a system consisting of 50 nodes. Each node always has a packet available for transmission - saturation condition. Transmission queue of each node is always assumed to be nonempty

• Metrics: – transmission/failure/drop probabilities.

– Throughput and Goodput.

20

Performance Analysis (parameters)

21

B is number of “back-off stages” How many times we

double Wmin to reach Wmax. 1024/16 = 6

SIFS/DIFS/ACK/RTS/CTS times are transmission

durations

Pe is probability of error due to channel conditions

r is number of receivers

Number of nodes = 50

Performance Analysis (transmission/failure probability)

• Transmission probability: ps

sender receives ACK

• Fail probability: p

sender does not receive ACK

• Collision probability: pc

22

ABM: MMP

Performance Analysis (drop probability)

• Dropped packet pd: if one node misses current packet and next packet is transmitted

(LBP non-leader nodes for example). Current packet is a dropped packet

• ABM and PRO dropped packets occur at retry limit exhaustion

• LBP dropped packets occur at retry limit and when one member does not receive packet

23

Performance Analysis (throughput)

24

Performance Analysis (throughput)

• Throughput considers system utilization for successful transmissions

• This is misleading for LBP since a transmission is considered successful even if data packets were dropped for non-leader members

25

Performance Analysis (goodput)

• Define Goodput (G) as system

utilization when packets are received

by all receivers.

26

Performance Analysis (goodput)

27

Performance Analysis (goodput)

28

Discussion

• How can the new claimed leader

assign a sub-carrier to itself that does

not conflict with other nodes?

29

Conclusion

• Reliable MAC protocol proposed that

utilizes RTS/CTS over OFDM

concepts, using orthogonal channels

• This solves hidden terminal problem

and packet drops while keeping

“goodput” higher than older protocols

30

References • [1] Sung Won Kim, Byung-Seo Kim, Inkyu Lee, “MAC Protocol for Reliable Multicast over Multi-Hop

Wireless Ad Hoc Network” IEEE, 2012

• [2] H. Gossain, N. Nandiraju, K. Anand, and D. P. Agrawal, “Supporting MAC layer multicast in IEEE 802.11 based MANETs: Issues and solutions,” in Proc. IEEE LCN, Nov. 2004, pp. 172–179.

• [3] J. Kuri and S. K. Kasera, “Reliable multicast in multi-access wireless LANs,” ACM Wireless Netw., vol. 7, no. 4, pp. 359–369, Aug. 2001.

• [4] C.-W. Bao and W. Liao, “Performance analysis of reliable MAC-layer multicast for IEEE 802.11 wireless LANs,” in Proc. IEEE ICC, May 2005, pp. 1378–1382.

• [5] M.-T. Sun, L. Huang, A. Arora, and T.-H. Lai, “Reliable MAC layer multicast in IEEE 802.11 wireless networks,” Wireless Commun. Mobile Comput., vol. 3, no. 4, pp. 439–453, June 2003.

• [6] ——, “Reliable MAC layer multicast in IEEE 802.11 wireless networks,” in Proc. IEEE ICPP, Aug. 2002, pp. 527–536.

31