HandShake Protocol 1 Both RTS and CTS contains

Hand-Shake Protocol 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

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

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

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)

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

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

The Backoff Algorithm B P 1 -B P 2 BEB 48. 5 0 copy BEB 23. 32 23. 82

Control Oscillation for BO Multiplicative Increase and Linear Decrease(MILD): • Collision: BO = min(1. 5× BO, BOmax) • Success: BO = max(BO-1, BOmin) P 1 -B P 2 -B P 3 -B P 4 -B P 5 -B P 6 -B BEB copy MILD copy 2. 96 3. 01 2. 84 2. 94 3. 00 3. 05 6. 10 6. 18 6. 05 6. 12 6. 14 6. 09

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

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

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

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