1. Both RTS and CTS contains: The address of the sender The address of the receiver The sizeof the intended data short message size contention concentrated in RTS-CTS Basic Behavior of a overhearing station: Receive RTS: Defer until CTS should have been sent Receive CTS: Defer until Data should have been sent Hand-Shake Protocol

2. MACA in Operation The Hidden Terminal Problem is avoided ABC CTS RTS C waits to send since it hears B ’ s CTS ABC RTS CTS C send since it does not hears A ’ s CTS The Expose Terminal Problem is avoided

3. MACA Rules Machine states: IDLE, CONTEND, WFCTS, WFDATA, QUITE. Control rules: carry capture and data transmission –IDLE, have data  CONTEND, random timer,  WFCTS if capture carry –IDLE, income RTS  send CTS, WFData, set timer –WFCTS, income CTS  tran Data, IDLE, clear timer –WFData, income Data  IDLE, clear timer –CONTEND, income RTS  tran CTS, WFData, clear timer Backoff rules: reduce collision in re-attempt Deferral rules:govern collision avoidance –When hear RTS, goes to QUITE, and sets a timer value sufficient to hear a CTS from the intended node. –When hear CTS, goes to QUITE, and sets a timer value sufficient to hear Data from the intended node. Timeout rules: –CONTEND, timer expires  send RTS, WFCTS –Other states, timer expires  IDLE

4. Binary Exponential Backoff A station know a collision if it does not receive the expected CTS It will try to re-transmit the RTS. Before re-transmit RTS, it need to wait an random time from [0 BO] to avoid second collision. How to decide the upper bound BO according to the congestion condition. Backoff rules in MACA: BO = B_min initially. When a CTS is received, BO=B_min If a CTS is not received after RTS, BO= min(2*BO, B_max)

5. MACAW: Paper # 12 Many Improvement to MACA Blueprint of the 802.11 Goals: Improve network utilization Provide fair access to network Concentrates on two aspects of the MAC protocol: The backoff algorithm The basic RTS-CTS-DATA message exchange

6. Unfairness in BEB Problem: The “least backed off” node will likely unfairly always win Solution: Share BO value with other nodes: Sender includes current BO value in each packet When you hear a packet, your BO = BO from packet

7. The Backoff Algorithm BEBcopy BEB P1-B P2-B 48.5 0 23.32 23.82 B P2 P1

8. Control Oscillation for BO BEB copyMILD copy P1-B P2-B P3-B P4-B P5-B P6-B 2.96 3.01 2.84 2.94 3.00 3.05 6.10 6.18 6.05 6.12 6.14 6.09 Multiplicative Increase and Linear Decrease(MILD): Collision: BO = min(1.5× BO, BOmax) Success: BO = max(BO-1, BOmin)

9. Backoffs for Multiple Streams Problem: Congestion at one stream affects all streams (of the same node): Single outgoing packet queue and single BO at each node But congestion at one receiver may not be present at others Need a per-stream-fairness in sharing the bandwidth Solution: Treat each stream separately: Use a separate packet queue for each destination Run the backoff algorithm separately for each queue A node sends next from the queue whose BO expires first If a tie, just pick among the winning queues randomly

10. Adding an ACK Problem: Collisions/dropped packets are still possible: Due to random noise. Can recover at transport layer, but introduces a large delay Solution: Receiver sends an ACK packet after receipt of DATA: Link-layer recovery, much faster If ACK not received, sender schedules DATA for retransmit On retransmit, sender starts again with RTS If receiver already had DATA (first ACK was lost), receiver returns ACK in response to RTS Causes slight throughput decrease when few errors But significant throughput in more common case of more errors

11. Use of New Request-for-RTS Packet Problem: What happens to the sender if the destination can’t CTS a received RTS This occurs when destination is deferring (in QUITE state)? The sender keeps retransmitting RTS and increasing its own BO timeout. Not fair to this sender Solution: Have B do contention on behalf of A: If B receives RTS for which it must defer CTS reply Then B later sends RRTS to A when it can send A responds by starting normal RTS-CTS Others hearing RRTS defer long enough for RTS-CTS

12. Multicast Transmissions Problem: Basic RTS-CTS only works for unicast transmissions: For multicast, RTS would get CTS from each intended receiver Likely to cause (many) collisions back at sender Sort-of solution: Don’t use CTS for multicast data: Receivers recognize multicast destination in RTS Don’t return CTS Sender follows RTS immediately by DATA After RTS, all receivers defer for long enough for DATA Helps, but doesn’t fully solve problem: Like normal CSMA, only those in range of sender will defer Others in range of receiver will not defer Complete solution to problem not yet known