1 / 46

Explicit and Implicit Pipelining in Wireless MAC

Explicit and Implicit Pipelining in 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

operreault
Download Presentation

Explicit and Implicit Pipelining in Wireless MAC

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Explicit and Implicit Pipeliningin 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 RTS/CTS Data Transmission/ACK

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

  6. Random backoff RTS/CTS Data Transmission/ACK Stage1 Stage2 Pipelining • Two stage pipeline: • Random backoff and RTS/CTS handshake • Data transmission and ACK • “Total” pipelining: Resolve contention completely in stage 1

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

  8. Related Work • Todd and Mark, “Capacity allocation in multiple access networks,” IEEE Trans. on Communications, vol. COM-33, 1985. • Todd and Mark considered a similar “total pipelining” model, where the channel contention is completely resolved on a separate scheduling sub-channel. • Results: • If MAC access control overhead consists of bandwidth-dependent component only, not possible to improve throughput by pipelining • If MAC access control overhead consists of bandwidth-independent component only, substantial improvement can be expected.

  9. “Total” pipelining of IEEE 802.11 in wireless networks • IEEE 802.11 contention resolution overhead consists of both bandwidth-independent and bandwidth-dependent components. • Random Backoff Duration is bandwidth-independent • Collision detection and RTS/CTS transmissions are bandwidth-dependent overhead

  10. Random backoff RTS/CTS Random backoff RTS/CTS Random backoff RTS/CTS Pipelining works well only if two stages are balanced! Control Channel Data Transmission/ACK Data Transmission/ACK Data Channel

  11. Difficult to keep the two stages balanced • Length of stage 1 depends on: • The random backoff duration • The number of collisions occurred • Control channel bandwidth • Length of stage 2 depends on: • The data packet size • Data channel bandwidth

  12. How much bandwidth does control channel require? • If small, then • RTS/CTS takes very long time. • Collision detection is slow. • Data Channel may be unnecessarily kept idle due to the lengthened contention resolution duration. • If large, then • The portion of channel bandwidth used for productive data packet transmission is reduced Total bandwidth is fixed!

  13. Difficulties 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

  14. Simulation Results for “Total” PipeliningTotal channel bit rate: 11 Mbps “Total” Pipelining, payload size: 1KB 802. 11 payload size: 1KB Aggregate Throughput (Kbps) “Total” Pipelining, payload size: 512 B 802.11, payload size: 512 B Control Channel Bit Rate (Mbps)

  15. PartialPipeliningModified 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 Backoff phase 2 RTS/CTS Data/ACK Stage1 Stage2

  16. 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 Stage 1: Busy tone channel Random backoff phase 1 Random backoff phase 1 Random backoff phase 1 Backoff phase 2 RTS/CTS Data/ACK Backoff phase 2 RTS/CTS Data/ACK Stage 2: Data channel

  17. Stage 1 of “Partial Pipelining” • Each station maintains a counter for random backoff phase 1. • The stations, which count to zero first, send a busy tone to claim wining in stage 1, becoming pipelined stations. • Multiple pipelined stations are possible • Other stations are frozen in backoff phase 1 on sensing a busy tone, and are unfrozen when the transmission of the pipelined packet begins.

  18. Stage 2 of “Partial Pipelining” • Only pipelined stations are allowed to contend for the data sub-channel in stage 2. • Stage 2 proceeds quite similar to IEEE 802.11 DCF. • Random backoff phase 2 • RTS/CTS handshake • Data/ACK • Retransmissions upon collisions • Pipelined stations that lose data sub-channel access return back to stage 1.

  19. 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 phase 2 RTS/CTS Data/ACK Backoff phase 2 RTS/CTS Data/ACK

  20. Gain of “Partial” Pipelining Over “Total” Pipelining • Since there is no need to completely resolve contention in pipelined stage 1, the length of stage 1 is elastic so the two stages can be kept balanced • No packets transmitted on busy tone channel • bandwidth can be small • the difficulty of deciding optimum bandwidth division in “total pipelining” is eased

  21. 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 phase 2 RTS/CTS Data/ACK Backoff phase 2 RTS/CTS Data/ACK

  22. Benefits of Partial Pipeline (cont.) • By migrating most of the backoff (i.e., random backoffphase 1) to the busy tone sub-channel, the bandwidthindependent overhead is reduced. • Cost of backoff = Channel bandwidth * backoff duration • Using IEEE 802.11 DSSS, the backoff duration could be several milliseconds Data Channel Bandwidth Area = cost of backoff Busy Tone Channel Bandwidth Backoff Duration

  23. Benefits of Partial Pipeline (cont.) • Only pipelined stations can contend for the data sub-channel in stage 2 • With large probability, the number of pipelined stations, which contend for the data sub-channel at the same time, is small • reduces collision probability on the data sub-channel • Leading tothe reduced bandwidth-dependent overhead. Stage 1 Stage 2

  24. Performance Results of Partial Pipelining Partial Pipelining Payload size: 512 B Improved Channel Utilization 37.5% improvement 802.11, Payload size: 512 B Normalized Throughput Contending Stations (N)

  25. Performance Results of Partial Pipelining Improved Packet Access Delay 42% improvement 802.11 Payload size: 512 B Average Packet Access Delay (s) Partial Pipelining Payload size: 512 B Contending Stations (N)

  26. Performance Results of Partial Pipelining Improved Access Energy Efficiency 37% improvement 802.11, Payload size: 512 B Joule / Kbps Partial Pipelining Payload size: 512 B Contending Stations (N)

  27. Can we avoid usingbusy tone channel?

  28. Busy Tone May not Always Be Sensed Partial Pipelining with busy tone detection probability: 100%, 80% and 50% , respectively 802.11 Normalized Throughput Partial Pipelining with 0% busy tone detection probability Contending stations (N)

  29. Observation • With 0% busy tone detection probability: • throughput of partial pipelining degrades due to the increased contention in stage 2 • throughput remains better than 802.11 because of the reduced bandwidth-dependent and bandwidth-independent overhead • This suggests the “implicit” pipelining scheme

  30. Without busy tone in stage 1 • When a station counts its backoff counter to 0, other stations do not know. • Effectively, all stations may count down till the end of stage 1 (as marked by end of ongoing data transmission) • More pipelined stations will appear compared to when using busy tone. • If we can still control the number of pipelined stations within a reasonable range, the benefits of “partial” pipelining may be retained.

  31. Implicit Pipeline • Stage 1: Random backoff phase 1 • Stage 2: Random backoff phase 2, RTS/CTS handshake and Data/ACK transmission Backoff phase 1 Backoff phase 2 RTS/CTS Data/ACK Stage1 Stage2

  32. Still pipeline two stages, but with single channel Random backoff phase 1 Random backoff phase 1 Random backoff phase 1 Implicit stage 1 Backoff phase 2 RTS/CTS Data/ACK Backoff phase 2 RTS/CTS Data/ACK Channelusage

  33. Stage 1 of “Implicit” Pipelining • Each station reduces stage 1 backoff counter by a “reasonable” amount at the end of ongoing data transmission. • “implicit pipelining” • Stations with backoff counter less than zero win stage 1, becoming pipelined stations.

  34. Stage 1 of “Implicit Pipelining” (cont.) • The objective of the backoff algorithm for stage 1 is to keep the number of pipelined stations non-zero but small when ongoing data transmission finishes. • Contention window for stage 1 is increased aggressively (on failure to win data channel access in stage 2) • The more appeared pipelined stations, the more stations that have large contention window sizes – self adjusting. • Backoff counter is decreased faster for stations that have been waiting longer in stage 1

  35. Average number of pipelined stations for “implicit” pipelining Contending stations (N)

  36. Implicit Pipelining • Inherites benefits of “partial pipelining” • Backoff phase 1 proceeds in parallel with other channel activities, leading to the reduced bandwidth-independent channel idle overhead. • Reduces data channel contention by reducing the number of contending stations, leading to the reduced bandwidth-dependent collision overhead.

  37. Implicit Pipelining • Advantages compared with “partial pipelining” • No busy tone channel is needed • Disadvantage compared with “partial pipelining” • More pipelined stations appear from stage 1, leading to the degraded performance in very large networks

  38. Number of Collisions EncounteredPayload size: 512 B, RTS/CTS access method 802.11 Number of RTS Retransmissions Implicit pipelining Partial Pipelining Contending Stations (N)

  39. Performance Results of Implicit Pipelining Implicit pipelining Payload size: 512B Improved Channel Utilization 30% improvement 802.11 Payload size: 512 B Normalized Throughput (Kbps) Contending stations (N)

  40. Performance Results of Implicit Pipelining Improved Packet Access Delay 24% 802.11 Payload size: 512 B improvement Average Packet Access Delay (s) Implicit pipelining Payload size: 512B Contending stations (N)

  41. Performance Results of Implicit Pipelining Improved Access Energy Efficiency 31% 802.11 Payload size: 512 B improvement Joule / Kbps Implicit pipelining Payload size: 512B Contending stations (N)

  42. Performance of Implicit Pipelining in multi-hop Ad hoc networks Throughput ratio of “implicit” pipelining over 802.11 10% - 49% Improvement Aggregate Throughput Ratio Topology Index Simulated in 30 1000m*1000m random networks with 80 contending stations

  43. Performance of Implicit Pipelining in multi-hop Ad hoc networks Packet Access Delay 802.11 11% - 69% Improvement Average Packet Access Delay (s) Implicit pipelining Topology Index Simulated in 30 1000m*1000m random networks with 80 contending stations

  44. Performance of Implicit Pipelining in multi-hop Ad hoc networks Access Energy Efficiency 802.11 9% - 46% Improvement Joule / Kbps Implicit pipelining Topology Index Simulated in 30 1000m*1000m random networks with 80 contending stations

  45. Conclusions • Pipelining can improve MAC performance • “Partial” pipelining is more suitable for wireless networks than “total” pipelining. • Various approaches (e.g., partial pipelining, implicit pipelining) can be conceived for pipelining. • On-going work: Improving pipelining in multi-hop networks

  46. Thanks! Slides last modified February 29, 2004

More Related