Explicit and Implicit Pipelining in Wireless MAC Nitin Vaidya University of Illinois at Urbana-Champaign Joint work with Xue Yang, UIUC

Goal Improving performance of MAC protocols

IEEE 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/ACK RTS/CTS

Inefficiency of IEEE Backoff interval should be chosen appropriately for efficiency Backoff interval with far from optimum

Observation Backoff and RTS/CTS handshake are unproductive: Do not contribute to goodput Random backoff Data Transmission/ACK RTS/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/ACK RTS/CTS Stage1Stage2

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/CTS Random backoff RTS/CTS Random backoff Data Transmission/ACK

Pipelining works well only if two stages are balanced! Data Transmission/ACK Random backoff RTS/CTS Random backoff RTS/CTS Random 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 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 Stage1Stage2 RTS/CTS Backoff 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 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/ACK RTS/CTS Backoff phase 2 Data/ACK RTS/CTS Backoff 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 1Stage 2

Sounds like HIPERLAN/1? Elimination Stage Data Transmission Yield Stage HIPERLAN / 1 (no pipelining) Random backoff phase 1 Data/ACK RTS/CTS Backoff phase 2 Data/ACK RTS/CTS Backoff phase 2 Partial Pipelining

Benefits of Partial Pipeline Random backoff phase 1 Data/ACK RTS/CTS Backoff phase 2 Data/ACK RTS/CTS Backoff phase 2 Partial Pipelining Because of pipelining, stages 1 and 2 proceed in 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 DSSS, the backoff duration could be several milliseconds

Results of Partial Pipelining Improved throughput and stability over DCF DCF Partial Pipelining

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 Backoff phase 1 Data/ACK Stage1Stage2 RTS/CTS Backoff 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 Data/ACK RTS/CTS Backoff phase 2 Data/ACK RTS/CTS Backoff phase 2 Similar to busy tone probability = 0

Random backoff phase 1 Data/ACK RTS/CTS Backoff phase 2 Data/ACK RTS/CTS Backoff 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 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 DCF Implicit Pipelining 53% improvement Normalized throughput

Wireless LANs with RTS/CTS Handshake packet size: 512 bytes 46% improvement Normalized throughput Implicit Pipelining DCF

Wireless LANs with RTS/CTS Handshake packet size: 2048 bytes Implicit Pipelining 26% improvement DCF Normalized throughput

Wireless LANs NO RTS/CTS Handshake packet size: 512 bytes Implicit Pipelining DCF 87% improvement Normalized throughput

Fairness Comparable to Fairness Index Implicit Pipelining DCF

Fairness Comparable to Max/Min Throughput Ratio Implicit Pipelining DCF

Simulation results for multi-hop Ad hoc networks Simulated in m*1000m random networks with 80 active stations Throughput Ratio of “implicit pipelining” over

Simulation results for multi-hop Ad hoc networks Simulated in m*1000m random networks with 80 active stations Number of collisions Implicit Pipelining DCF

Conclusions Pipelining can improve performance Various approaches can be conceived for pipelining Improves stability –Implicit pipelining compatible with

Thanks!