Explicit and Implicit Pipelining
in Wireless MAC
Nitin Vaidya
University of Illinois at Urbana-Champaign
[email protected]
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
RTS/CTS
Data Transmission/ACK
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
Unproductive
Random
backoff
RTS/CTS
Data Transmission/ACK
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
Stage1
RTS/CTS
Data Transmission/ACK
Stage2
How to pipeline?
• Use two channels
 Control Channel: Random backoff and RTS/CTS
handshake
 Data Channel: Data transmission and ACK
Random
backoff
RTS/CTS
Random
backoff
RTS/CTS
Data Transmission/ACK
Random
backoff
RTS/CTS
Data Transmission/ACK
Pipelining works well only
if two stages are balanced!
Random
backoff
RTS/CTS
Random
backoff
RTS/CTS
Random
backoff
RTS/CTS
Control Channel
Data Transmission/ACK
Data Channel
Data Transmission/ACK
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
Stage 1: Random backoff phase 1
Stage 2: Random backoff phase 2, RTS/CTS handshake
and Data/ACK transmission
Backoff phase 1
Stage1
Backoff
phase 2
RTS/CTS
Stage2
Data/ACK
How to pipeline?
• 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
Random backoff phase 1
Random backoff phase 1
Random backoff phase 1
Backoff
RTS/CTS Data/ACK
phase 2
Backoff
RTS/CTS Data/ACK
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?
HIPERLAN / 1 (no pipelining)
Elimination
Stage
Yield Stage
Data Transmission
Partial Pipelining
Random backoff phase 1
Random backoff phase 1
Random backoff phase 1
Backoff
RTS/CTS Data/ACK
phase 2
Backoff
RTS/CTS Data/ACK
phase 2
Benefits of Partial Pipeline
Because of pipelining, stages 1 and 2 proceed
in parallel. Stage 1 costs little except for a
narrow band busy tone channel
Partial Pipelining
Random backoff phase 1
Random backoff phase 1
Random backoff phase 1
Backoff
RTS/CTS Data/ACK
phase 2
Backoff
RTS/CTS Data/ACK
phase 2
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
Area = cost
of backoff
Data Channel
Bandwidth
Busy Tone
Channel Bandwidth
Using IEEE 802.11
DSSS, the backoff
duration could be
several milliseconds
Backoff Duration
Results of Partial Pipelining
• Improved throughput and stability over
802.11 DCF
Partial
Pipelining
802.11 DCF
Can we avoid using
busy 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
Stage 1: Random backoff phase 1
Stage 2: Random backoff phase 2, RTS/CTS handshake
and Data/ACK transmission
Backoff phase 1
Stage1
Backoff
phase 2
RTS/CTS
Stage2
Data/ACK
Still two stages,
but with single channel
• Similar to busy tone probability = 0
Random backoff phase 1
Random backoff phase 1
Random backoff phase 1
Backoff
RTS/CTS Data/ACK
phase 2
Backoff
RTS/CTS Data/ACK
phase 2
• 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)
Random backoff phase 1
Random backoff phase 1
Random backoff phase 1
Backoff
RTS/CTS Data/ACK
phase 2
Backoff
RTS/CTS Data/ACK
phase 2
Implicit stage 1
Channel usage
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 stations
in 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
Normalized throughput
Implicit
Pipelining
53%
802.11 DCF
improvement
Wireless LANs
with RTS/CTS Handshake
packet size: 512 bytes
Normalized throughput
Implicit
Pipelining
46%
improvement
802.11 DCF
Wireless LANs
with RTS/CTS Handshake
packet size: 2048 bytes
Normalized throughput
Implicit
Pipelining
26%
improvement
802.11 DCF
Wireless LANs
NO RTS/CTS Handshake
packet size: 512 bytes
Normalized throughput
Implicit
Pipelining
87%
improvement
802.11 DCF
Fairness Comparable to 802.11
Fairness Index
Implicit
Pipelining
802.11 DCF
Fairness Comparable to 802.11
Max/Min Throughput Ratio
Implicit
Pipelining
802.11 DCF
Simulation results for
multi-hop Ad hoc networks
Throughput Ratio of “implicit pipelining” over 802.11
Simulated in 30 1000m*1000m random networks with 80 active stations
Simulation results for
multi-hop Ad hoc networks
Number of collisions
802.11 DCF
Implicit
Pipelining
Simulated in 30 1000m*1000m random networks with 80 active stations
Conclusions
• Pipelining can improve performance
• Various approaches can be conceived
for pipelining
• Improves stability
– Implicit pipelining compatible with 802.11
Thanks!
[email protected]