MACAW: A Media Access Protocol for Wireless LAN’s

1. MACAW: A Media Access Protocol for Wireless LAN’s Nasser Behmadi Mobile Computing and Wireless Networks nbehmadi@aut.ac.ir Fall 1392

2. Outline • CSMA • DATA • MACA • RTS-CTS-DATA • MACAW • RTS-CTS-DATA-ACK nbehmadi@aut.ac.ir Fall 1392

3. Intro • Wide variety of wireless devices • Media in wireless networks is scarce • Should be shared, then accessed • Two approaches: • Token-based  • Multiple-access  nbehmadi@aut.ac.ir Fall 1392

4. 4 key observations • Contention is at the Rx, not the Tx • Congestion is location dependent • MAC should propagate congestion info • MAC should propagate sync info about contention periods nbehmadi@aut.ac.ir Fall 1392

5. CSMA • Avoid collisions by testing the signal strength in the vicinity of Tx • Collisions occur at the Rx, not the Tx ! • CS does not provide the appropriate info for CA nbehmadi@aut.ac.ir Fall 1392

6. Hidden/Exposed Terminal nbehmadi@aut.ac.ir Fall 1392

7. MACA • RTS-CTS • Each station that: • Hear RTS, defer until CTS come back • Hear CTS, defer until DATA finish • Hear RTS but no CTS, can commence transmission after CTS has been sent nbehmadi@aut.ac.ir Fall 1392

8. Backoff Algorithm • MACA uses BEB • What if 2 pads were in the same cell? nbehmadi@aut.ac.ir Fall 1392

9. What has happened? • A single pad transmits at channel capacity and the other pad is completely backed off! • The less-backed-off pad will retransmit first and “win” the collision and thereby reset its backoff counter to BOmin • CAUSE: • No “sharing” of congestion info nbehmadi@aut.ac.ir Fall 1392

10. BEB-Copy • Add a field which contains the current value of the backoff counter • STRATEGY: • Copy the backoff value of packet into your own backoff counter • After each successful transmission all pads have the same backoff counter • Trick: Info has been shared  nbehmadi@aut.ac.ir Fall 1392

11. Further improvement of BEB • BEB backoff calculation adjusts extremely rapidly • large variations in the backoff counter • MILD: multiplicative increase, linear decrease • F_inc(x) := MIN[1.5x, BOmax] • F_dec(x) := MAX [x-1, BOmin] nbehmadi@aut.ac.ir Fall 1392

12. Let’s compare the results ! nbehmadi@aut.ac.ir Fall 1392

13. Multiple Stream Model • Initial design: • A single FIFO packet queue at each station • A single BO • What if? • Allocate BW equally? nbehmadi@aut.ac.ir Fall 1392

14. Is this “fair”? nbehmadi@aut.ac.ir Fall 1392

15. Per station fairness vs. per stream fairness • Keep in each station separate queues for each stream • Run the backoffalgorithm independently for each queue • streams originating from a multi-stream station have a slight advantage over streams in a single stream station nbehmadi@aut.ac.ir Fall 1392

16. Message Exchange • Transport layer vs. Link layer • recovery at the link-layer can be much faster • RTS-CTS-DATA-ACK •  backoff: no ACK or CTS arrives •  backoff: ACK arrives •  backoff: successful RTS-CTS, but no ACK arrives nbehmadi@aut.ac.ir Fall 1392

17. Effect of noise • Decrease in throughput: slow TCP recovery • Where is overhead of ACK inclusion? nbehmadi@aut.ac.ir Fall 1392

18. Data Sending Packet (DS) • Recall disposed terminal problem • When B is transmitting, C is unable to hear any replies and thus initiating a transfer is useless • because C has only heard the RTS and not the CTS, C does not know if B is indeed transmitting data nbehmadi@aut.ac.ir Fall 1392

19. DS • Exposed terminal problem is not obviated yet! • Was RTS-CTS exchange successful !? • Before sending a DATA packet, a station sends a short 30 byte Data-Sending packet (DS) • It means that RTS-CTS exchange was successful and data transmission is imminent • Without DS: the “losing” pad cannot identify when the next contention period nbehmadi@aut.ac.ir Fall 1392

20. DS nbehmadi@aut.ac.ir Fall 1392

21. RRTS • B2-P2: wins the initial contention • large DATA pkt vs. short CONTROL pkts • The key problem: lack of sync info nbehmadi@aut.ac.ir Fall 1392

22. RRTS nbehmadi@aut.ac.ir Fall 1392

23. RRTS (Two problems) • B1 has no way of knowing when contention periods start or finish • DS cannot solve this problem ! Why? • Neither of the base stations can hear any part of the other streams message exchange • B1’s backoff counter keeps increasing • because it never receives a response from P1 nbehmadi@aut.ac.ir Fall 1392

24. RRTS (solution) • P1 do the contending on behalf of B1 • Whenever a station receives an RTS to which it cannot respond due to deferral, it then contends during the next contention period and sends a RRTS pkt to the sender of the RTS • Recipient of an RRTS immediately responds with an RTS nbehmadi@aut.ac.ir Fall 1392

25. Is RRTS enough? • RRTS does not solve all contention problems! nbehmadi@aut.ac.ir Fall 1392

26. Is RRTS enough? • When B1 initiates a data transfer by sending an RTS, P1 cannot hear it due to P2’s transmission • Again the key is the lack of sync info ! • The RRTS packet is irrelevant here since P1 cannot hear the incoming RTS nbehmadi@aut.ac.ir Fall 1392

27. Multicast • The RTS-CTS exchange is no longer viable since the multiple receivers cannot coordinate and are likely to collide with each other’s CTS • Overhearing stations • Defer for the length of the following DATA transmission • This design has the same fawsas CSMA nbehmadi@aut.ac.ir Fall 1392