This document proposes a new MAC protocol for reliable multicast over multi-hop wireless ad hoc networks. The protocol introduces RTS/CTS to multicast MAC to solve problems like hidden terminals. It works by having members send concurrent CTS messages on orthogonal frequencies to acknowledge reception of RTS and data. Performance analysis shows it achieves higher throughput and goodput than prior protocols like ABM, MMP, LBP, by reducing dropped packets through reliable transmissions while keeping overhead low.

1. MAC Protocol for Reliable
Multicast over Multi-Hop
Wireless Ad Hoc Networks
OsamaAskoura
EECS6590paperreview
1

2. Roadmap
• Introduction
• Prior Works
• The Algorithm
• Performance Analysis
• Discussion
• Conclusion
2

3. What are ad-hoc networks?
3
Fig1: Ad-hoc Network Example. Sources: Google Images

4. Why are ad-hoc networks important ?
4
Fig2: Ad-hoc Network Applications. Sources: Google Images

5. What is multicast?
5
Fig3: Multicast Example. Sources: Google Images
Bob
Mike
Yan
Tell Bob, Mike and
Yan, Food is north

6. MAC Protocol for Reliable
Multicast over Multi-Hop
Wireless Ad Hoc Networks
6

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

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

9. Prior Works
• MMP (Multicast MAC Protocol)
• LBP (Leader based protocol)
• ELBP (Enhanced Leader Based)
• BMMM (Batched Mode Multicast MAC)
9

10. Prior Works
• ABM/MMP (Multicast MAC Protocol)[Gossain2004]
– 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

11. 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!

12. Prior Works
• ELBP (Enhanced Leader Based) [Bao2005]
– 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

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

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

15. Example
15

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

17. Algorithm Flow Chart
• Solves
– Hidden Terminal Problem
– Packet Loss due to channel error
– High overhead in MAC; thus high throughput
17

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

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

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

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

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

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

24. Performance Analysis (throughput)
24

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

26. Performance Analysis (goodput)
• Define Goodput (G) as system
utilization when packets are received
by all receivers.
26

27. Performance Analysis (goodput)
27

28. Performance Analysis (goodput)
28

29. Discussion
• How can the new claimed leader
assign a sub-carrier to itself that does
not conflict with other nodes?
29

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

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