Presentation is loading. Please wait.

Presentation is loading. Please wait.

Wireless MACs (reprise): Overlay MAC Brad Karp UCL Computer Science CS 4C38 / Z25 24 th January, 2006.

Similar presentations

Presentation on theme: "Wireless MACs (reprise): Overlay MAC Brad Karp UCL Computer Science CS 4C38 / Z25 24 th January, 2006."— Presentation transcript:

1 Wireless MACs (reprise): Overlay MAC Brad Karp UCL Computer Science CS 4C38 / Z25 24 th January, 2006

2 2 Context: 802.11 MAC and Forwarding MACAW (1994) –Communication range = interference range –No carrier sense –RTS/CTS for hidden terminal problem 802.11b standard (mid 90s) –Designed chiefly with base stations in mind –Carrier sense and RTS/CTS –Interference range > communication range Roofnet (2005) –Multi-hop forwarding using 802.11b –RTS/CTS disabled (no help to performance) –Collisions between forwarders in a chain –Highly asymmetric packet loss rates on many links Overlay MAC (2005) –Study pathologies when 802.11a applied to multi-hop forwarding –Propose time-slotted “overlay” for 802.11a to alleviate problems Many competing schemes for MACs, even slotted ones! This paper: measure underlying problem; build real implementation; evaluate it.

3 3 Motivation: 802.11’s Shortcomings Asymmetric interaction between nodes –at senders –at receivers Rigid allocation of bandwidth among flows –no application choice of bandwidth allocation –poor fairness among flows for some traffic workloads

4 4 802.11a Testbed Indoor, chain topology No other 802.11 traffic in band UDP broadcast packets TCP

5 5 Motivation: Asymmetric Carrier Sense at Senders All 15 node pairs: greedy broadcast UDP Far apart nodes: –ca. 5.1 Mbps –senders send simultaneously; don’t sense one another’s carriers Close nodes: –ca. 2.5 Mbps each –senders share fairly; sense one another’s carriers Three cases: –one sender >= 4.5 Mbps, other <= 800 Kbps –no RTS/CTS; no ACKs; no transport protocol –only explanation: one sender can’t sense other’s carrier –doesn’t depend on receiver

6 6 Motivation: Asymmetric / Symmetric Interaction at Receivers Sender pairs who can broadcast at full rate, each sends greedy UDP unicast Example 1: –1  2 3  4 –85% packet drops from 1 to 2 –sending rate drops > 60% from 1 to 2 Example 2: –1  2  3 –35% packet drops for both 1 and 2 –channel utilization: drops by 55%

7 7 Motivation: Rigid Bandwidth Allocation How do you divide capacity when senders use auto bit-rate selection? –802.11 answer: equal number of transmit opportunities for senders… –…but each packet may be at different bit-rate Heterogeneous sending rates: –1  AP  2 –1 sends at 54 Mbps –2 sends at {6, 12, 18, 36, 54} Mbps Fair, but total utilization drops as node 2 slows! Unpredictable: –Node 1 alone: 24 Mbps –Node 2 joins at 6 Mbps: Node 1 gets 3.6 Mbps

8 8 Motivation: Forwarding and Fairness 802.11 doesn’t consider forwarding in b/w allocation Interference range twice transmission range –N2 can’t receive during xmits of {N4, N5, N6} –N3 can’t receive during xmits of N1 802.11’s bandwidth allocation –N1 and N3: 1/3 each of N2’s bw –N4, N5, N6: 1/9 each (equal share of 1/3) Fairer would be –N3: 3/7 –N1, N4, N5, N6: 1/7 N1 N2 N3 N4 N5 N6

9 9 Motivation: (More) Unfairness Two flows: 1  2 and 3  4 One at a time: each 4.6 Mbps Simultaneously: one > 4 Mbps, one < 100 Kbps Rate limiting both to 2.3 Mbps: one 2.3 Mbps, one 580 Kbps

10 10 Assumptions Unicast and broadcast transmission supported Promiscuous mode listening RTS/CTS configurable “off” Limit transmit queue to 1-2 packets –Why?

11 11 OML: Design Overview Divide time into slots –All nodes agree on slot boundaries –Need loosely synchronized clocks Mutually interfering nodes contend for same set of slots –Which nodes mutually interfere? Each slot in set owned by one sender Senders may have weights; bandwidth divided proportionally to weights

12 12 OML: Clock Synchronization Real hardware clocks don’t tick at promised rate –oscillators in PCs are typically off by 1 – 100 μs per s –1 – 2 μs change per degree C! –skew: difference in frequency between two clocks Many proposed algorithms for sync’ing distributed clocks in many settings OML solution: –single leader node broadcasts timestamps –estimate propagation delay to receivers –receivers estimate their own skew; apply correction –goal: error must be much smaller than slot length

13 13 OML: Slot Length Constraints –longer than clock error –longer than packet transmission time –otherwise, as short as possible Value in evaluation –5 max-sized (1500-byte) packets –10 ms @ 6 Mbps

14 14 OML Algorithm 1: Diameter One, Unit Weights Pseudo-random hash function –Output uniformly random in (0, 1] –H i = H(n i, t), for c nodes, 1 ≤ i ≤ c n i = node ID of node i (integer, unique per node) t = time slot ID (increasing integer) –Assume all nodes who contend know one another’s n i –Each node can locally compute H i for all its neighbors Biggest H i wins; winner is r, where:

15 15 Suppose node i wants weight w i Redefine H i () in terms of w i : Nodes must know w i of all nodes they contend with (within interference zone) Winner r of slot is still node with greatest H i in that slot Proven in tech report: OML Algorithm 2: Diameter One, Arbitrary Weights

16 16 OML Algorithm 3: Diameter > 1 Only nodes that can interfere with one another must compete for slots What set of nodes interfere with one node? –Radio ranges highly variable –No very satisfying, scalable answer! Solution in paper: assume a fixed, k-hop interference zone –nodes broadcast for k hops intent to contend –greater k  assume more nodes mutually interfere –greater k  utilization may decrease

17 17 OML Algorithm: Diameter > 1 (cont’d) Overlapping interference regions reduce utilization Suppose H 1 < H 2 < H 3 H 1 and H 2 will both think they’ve “lost,” but H 1 and H 3 don’t interfere! 123

18 18 OML Algorithm: Slot Groups Each slot owner relinquishes slot with probability (1-p) in each group Nodes know locally when slot relinquished; use another pseudo-random hash function in (0, 1] After slot relinquished, others in zone compete for it Reduces chance of race in previous slide

19 19 Evaluation: Simulation QualNet simulator 802.11a, 6 Mbps fixed rate Two-ray ground reflection model (350 m range) RTS/CTS disabled 50 nodes / km 2, randomly placed Slot time: 10 ms (5 1500-byte pkts) Group size: N = 20 slots k = 2 AODV routing 1 simulated minute

20 20 Metric: Fairness Index M flows weights w 1, …, w M Throughputs x 1, …, x M Fairness index, F: F = 1 when all flows’ throughputs proportional to weights F = 1/M when one flow starves all others

21 21 Simulation: Packet Transmissions Workload: 10 UDP flows, different sources, one sink OML successfully avoids simultaneous contending transmissions OML is too conservative; delivers fewer packets successfully than 802.11

22 22 Simulation: Average Throughput 5- and 10-flow workloads Throughput comparable for OML vs. 802.11

23 23 Simulation: Fairness Nodes set weights to number of unique source IPs in output queue; unit weight per flow Per-source-IP queues; round-robin among queues N.B. fairness of 1 impossible; not all flows contend with all others OML more fair than 802.11

24 24 Simulation: Throughput and Path Length Narrower span of throughputs for OML than for 802.11 Improved fairness across varying path lengths, but less total capacity

25 25 Testbed: Heterogeneous Data Rates Two senders: one fixed at 54 Mbps, one varying from 6 to 54 Mbps Same weights at both senders; equal channel access time at each sender Proportional sharing Increased total throughput vs. 802.11

26 26 Testbed: Chain Topology 5-hop chain testbed Two one-hop flows on random links One flow at a time Simultaneous, no OML Simultaneous, OML, k={1, 2} Improved fairness at cost of reduced throughput

27 27 Testbed: Chain Topology, Throughput-Fairness Trade Off “Oracle”: global knowledge of interference; “perfect” scheduling OML approaches optimal fairness with k=2, at some throughput cost 802.11 appears to favor throughput over fairness

Download ppt "Wireless MACs (reprise): Overlay MAC Brad Karp UCL Computer Science CS 4C38 / Z25 24 th January, 2006."

Similar presentations

Ads by Google