1 / 12

Basic Behavior of a overhearing station: • Receive RTS: Defer until CTS should have been sent

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

geona
Download Presentation

Basic Behavior of a overhearing station: • Receive RTS: Defer until CTS should have been sent

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  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 B P1 P2

  8. Control Oscillation for BO 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

More Related