Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Explicit and Implicit Pipelining in Wireless MAC Nitin Vaidya University of Illinois at Urbana-Champaign Joint work with Xue Yang, UIUC."— Presentation transcript:

1 Explicit and Implicit Pipelining in Wireless MAC Nitin Vaidya University of Illinois at Urbana-Champaign nhv@uiuc.edu Joint work with Xue Yang, UIUC

2 Goal Improving performance of MAC protocols

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

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

5 Observation Backoff and RTS/CTS handshake are unproductive: Do not contribute to goodput Random backoff Data Transmission/ACK RTS/CTS Unproductive

6 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

7 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

8 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

9 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

10 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!

11 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

12 How to get around the issue of bandwidth division ?

13 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

14 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

15 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

16 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

17 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

18 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

19 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

20 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

21 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

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

23 Can we avoid using busy tone channel?

24 Observation Busy tone may not always be sensed –Narrow-band channel for busy tone

25 Observation Taking this into account did not make the performance much worse –Sensing probability 0 as well ! Suggests the “implicit” pipelining scheme

26 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

27 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

28 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)

29 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

30 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

31 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

32 Implicit Pipeline Two stages as in Hiperlan/1, but no need to use busy tone

33 Average number of stations in stage 2

34 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

35 Contention Window 1

36 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

37 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

38 Wireles LANs with RTS/CTS Handshake packet size: 256 bytes 802.11 DCF Implicit Pipelining 53% improvement Normalized throughput

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

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

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

42 Fairness Comparable to 802.11 Fairness Index Implicit Pipelining 802.11 DCF

43 Fairness Comparable to 802.11 Max/Min Throughput Ratio Implicit Pipelining 802.11 DCF

44 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

45 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

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

47 Thanks! nhv@uiuc.edu


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

Similar presentations


Ads by Google