Date post: | 23-Feb-2017 |
Category: |
Technology |
Upload: | osama-m-askoura |
View: | 168 times |
Download: | 0 times |
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