Explicit and Implicit Pipeliningin Wireless MAC

Nitin Vaidya

University of Illinois at Urbana-Champaign

nhv@uiuc.edu

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

Thanks!

nhv@uiuc.edu