explicit and implicit pipelining in wireless mac nitin vaidya university of illinois at...
TRANSCRIPT
Explicit and Implicit Pipeliningin Wireless MAC
Nitin Vaidya
University of Illinois at Urbana-Champaign
Joint work with Xue Yang, UIUC
Goal
• Improving performance of MAC protocols
IEEE 802.11 MAC
• Channel contention resolved using backoff– Nodes choose random backoff interval from [0, CW]– Count down for this interval before transmission
• RTS/CTS handshake before transmission of data packet
Random backoff
Data Transmission/ACKRTS/CTS
Inefficiency of IEEE 802.11
• Backoff interval should be chosen appropriately for efficiency
• Backoff interval with 802.11 far from optimum
Observation
• Backoff and RTS/CTS handshake are unproductive:
Do not contribute to goodput
Random backoff
Data Transmission/ACKRTS/CTS
Unproductive
Pipelining• Two stage pipeline:
1. Random backoff and RTS/CTS handshake
2. Data transmission and ACK
• “Total” pipelining: Resolve contention completely in
stage 1
Random backoff
Data Transmission/ACKRTS/CTS
Stage1 Stage2
How to pipeline?
• Use two channels Control Channel: Random backoff and RTS/CTS
handshake Data Channel: Data transmission and ACK
Data Transmission/ACK
Random backoff
RTS/CTSRandom backoff
RTS/CTS RTS/CTSRandom backoff
Data Transmission/ACK
Pipelining works well only if two stages are balanced!
Data Transmission/ACK
Random backoff
RTS/CTSRandom backoff
RTS/CTS RTS/CTSRandom backoff
Data Transmission/ACK
Control Channel
Data Channel
Difficult to keep the two stages balanced
• Length of stage 1 depends on: Control channel bandwidth The random backoff duration The number of collisions occurred
• Length of stage 2 depends on: Data channel bandwidth The data packet size
How much bandwidth does control channel require?
• If small, then – RTS/CTS takes very long time.– Collision detection is slow
• If large, then – The portion of channel bandwidth used for
productive data packet transmission is reduced
Total bandwidth is fixed!
Difficulty with Total Pipelining
• The optimum division of channel bandwidth varies with contention level and data packet size
• Performance with inappropriate bandwidth division could be even worse than 802.11 DCF
How to get around the issue of bandwidth division ?
Partial Pipelining
• Only partially resolve channel contention in stage 1
• Since no need to completely resolve contention, the length of stage 1 can be elastic to match the length of stage 2
Modified Two Stage Pipeline
Backoff phase 1 Data/ACK
Stage1 Stage2
RTS/CTSBackoff phase 2
Stage 1: Random backoff phase 1
Stage 2: Random backoff phase 2, RTS/CTS handshake and Data/ACK transmission
How to pipeline?
Random backoff phase 1 Random backoff phase 1 Random backoff phase 1
• Still use two channels Narrow Band Busy Tone Channel:
Random backoff phase 1 Data Channel: Random backoff phase 2, RTS/CTS
handshake and Data/ACK
Data/ACKRTS/CTSBackoff phase 2
Data/ACKRTS/CTSBackoff phase 2
Random Backoff Phase 1
• Each Station maintains a counter for random backoff phase 1
• The stations, which count to zero first, send a busy tone to claim win in stage 1– Multiple winners are possible
• Other stations know they lost on sensing a busy tone
Gain over total pipelining?
• No packets transmitted on busy tone channel bandwidth can be small the difficulty of deciding optimum bandwidth
division in “total pipelining” is avoided
• Length of stage 1 is elastic so the two stages can be kept balanced
Benefits of Partial Pipeline
• Only winners of stage 1 can contend channel in stage 2– reduces the data channel contention– reduces collision probability on the data channel
Stage 1 Stage 2
Sounds like HIPERLAN/1?
Elimination Stage
Data TransmissionYield Stage
HIPERLAN / 1 (no pipelining)
Random backoff phase 1 Random backoff phase 1 Random backoff phase 1
Data/ACKRTS/CTSBackoff phase 2
Data/ACKRTS/CTSBackoff phase 2
Partial Pipelining
Benefits of Partial Pipeline
Random backoff phase 1 Random backoff phase 1 Random backoff phase 1
Data/ACKRTS/CTSBackoff phase 2
Data/ACKRTS/CTSBackoff phase 2
Partial Pipelining
Because of pipelining, stages 1 and 2 proceedin parallel. Stage 1 costs little except for a narrow band busy tone channel
Benefits of Partial Pipeline
By migrating most of the backoff to busy tone channel,
bandwidth cost of random backoff is reduced Cost of backoff = Channel bandwidth * backoff duration
Data Channel Bandwidth
Busy Tone Channel Bandwidth Backoff Duration
Area = cost of backoff
Using IEEE 802.11 DSSS, the backoff duration could be several milliseconds
Results of Partial Pipelining
• Improved throughput and stability over 802.11 DCF
802.11 DCF
Partial Pipelining
Can we avoid usingbusy tone channel?
Observation
• Busy tone may not always be sensed– Narrow-band channel for busy tone
Observation
• Taking this into account did not make the performance much worse– Sensing probability 0 as well !
• Suggests the “implicit” pipelining scheme
Implicit Pipeline
Backoff phase 1 Data/ACK
Stage1 Stage2
RTS/CTSBackoff phase 2
Stage 1: Random backoff phase 1
Stage 2: Random backoff phase 2, RTS/CTS handshake and Data/ACK transmission
Still two stages, but with single channel
Random backoff phase 1 Random backoff phase 1 Random backoff phase 1
Data/ACKRTS/CTSBackoff phase 2
Data/ACKRTS/CTSBackoff phase 2
• Similar to busy tone probability = 0
Random backoff phase 1 Random backoff phase 1 Random backoff phase 1
Data/ACKRTS/CTSBackoff phase 2
Data/ACKRTS/CTSBackoff phase 2
Channel usage
Implicit stage 1
• Stations do not know when a station counts to 0
• Effectively, all stations may count down till the end of phase 1 (as marked by end of pipelined data transmission)
Backoff Phase 1
• During the random backoff phase 1, the stations counting down the backoff counter to zero win stage 1. Only the winners of stage 1 contend channel in stage 2
• Difference from partial pipelining: – With busy tone, only stations counting down to 0 first win
stage 1. Multiple winners are possible only if they count down to 0 together
– Without busy tone sensing, no way for a station to claim channel explicitly
• more stations can win stage 1
Backoff Phase 1
• Nodes can count down number of slots = duration of on-going data transmission
• Generalize– Ignore data packet size– Each node reduces backoff interval by an
“arbitrary” (reasonably chosen) amount at the end of current busy channel period
Implicit Pipeline(Dual-Stage)
• Choose backoff such that number of winners from stage 1 (entering stage 2) is non-zero but small at the end of each busy period– Backoff increased aggressively (on failure
to win phase 2, not just on collision)– Backoff decreased faster for nodes that
have been waiting longer
Implicit Pipeline
• Two stages as in Hiperlan/1, but no need to use busy tone
Average number of stationsin stage 2
Implicit Pipelining
• Inherites benefits of partial pipelining– Reduces channel contention by reducing
the number of contending stations.– Backoff phase 1 proceeds in parallel with
other channel activities
Contention Window 1
Implicit Pipelining
• Advantages compared with “partial pipelining”– No busy tone channel is needed– Can be applied to multi-hop ad hoc networks
• Disadvantage compared with partial pipelining– More stations may win stage 1, which leads to
degraded stability in large networks
Simulation results for Implicit Pipelining
• Obtained via modified ns-2 simulator– Constant Bit Rate (CBR) traffic– Channel bit rate 11 Mbps– Active stations are always backlogged– Various packet sizes
• Simulated both in wireless LANs and multi-hop ad hoc networks
Wireles LANs with RTS/CTS Handshake
packet size: 256 bytes
802.11 DCF
Implicit Pipelining
53%improvement
Normalized throughput
Wireless LANs with RTS/CTS Handshake
packet size: 512 bytes
46%improvement
Normalized throughput Implicit Pipelining
802.11 DCF
Wireless LANs with RTS/CTS Handshake
packet size: 2048 bytes Implicit Pipelining
26%improvement
802.11 DCF
Normalized throughput
Wireless LANs NO RTS/CTS Handshake
packet size: 512 bytes
Implicit Pipelining
802.11 DCF
87%improvement
Normalized throughput
Fairness Comparable to 802.11
Fairness Index
Implicit Pipelining
802.11 DCF
Fairness Comparable to 802.11Max/Min Throughput Ratio
Implicit Pipelining
802.11 DCF
Simulation results for multi-hop Ad hoc networks
Simulated in 30 1000m*1000m random networks with 80 active stations
Throughput Ratio of “implicit pipelining” over 802.11
Simulation results for multi-hop Ad hoc networks
Simulated in 30 1000m*1000m random networks with 80 active stations
Number of collisions
Implicit Pipelining
802.11 DCF
Conclusions
• Pipelining can improve performance
• Various approaches can be conceived for pipelining
• Improves stability– Implicit pipelining compatible with 802.11
