Download presentation
Presentation is loading. Please wait.
Published byMargaret Lamb Modified over 9 years ago
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
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
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
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” Pipelining Total channel bit rate: 11 Mbps “Total” Pipelining, payload size: 1KB 802. 11 payload size: 1KB “Total” Pipelining, payload size: 512 B 802.11, payload size: 512 B Control Channel Bit Rate (Mbps) Aggregate Throughput (Kbps)
15
Partial Pipelining 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
16
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 Stage 1: Busy tone channel 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? 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
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 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
22
Benefits of Partial Pipeline (cont.) By migrating most of the backoff (i.e., random backoff phase 1) to the busy tone sub-channel, the bandwidth independent overhead 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
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 to the reduced bandwidth-dependent overhead. Stage 1Stage 2
24
Performance Results of Partial Pipelining Partial Pipelining Payload size: 512 B 802.11, Payload size: 512 B Contending Stations (N) Normalized Throughput Improved Channel Utilization 37.5% improvement
25
Performance Results of Partial Pipelining Contending Stations (N) Average Packet Access Delay (s) Improved Packet Access Delay 802.11 Payload size: 512 B Partial Pipelining Payload size: 512 B 42% improvement
26
Performance Results of Partial Pipelining Contending Stations (N) Joule / Kbps Improved Access Energy Efficiency Partial Pipelining Payload size: 512 B 802.11, Payload size: 512 B 37% improvement
27
Can we avoid using busy tone channel?
28
Busy Tone May not Always Be Sensed Partial Pipelining with busy tone detection probability: 100%, 80% and 50%, respectively Partial Pipelining with 0% busy tone detection probability 802.11 Normalized Throughput 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 Backoff phase 1 Data/ACK Stage1Stage 2 RTS/CTS Backoff phase 2 Stage 1: Random backoff phase 1 Stage 2: Random backoff phase 2, RTS/CTS handshake and Data/ACK transmission
32
Still pipeline two stages, but with single channel Random backoff phase 1 Data/ACK RTS/CTS Backoff phase 2 Data/ACK RTS/CTS Backoff phase 2 Implicit stage 1 Channel usage
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 Encountered Payload size: 512 B, RTS/CTS access method Contending Stations (N) Number of RTS Retransmissions 802.11 Implicit pipelining Partial Pipelining
39
Performance Results of Implicit Pipelining improvement Implicit pipelining Payload size: 512B 802.11 Payload size: 512 B 30% Improved Channel Utilization Contending stations (N) Normalized Throughput (Kbps)
40
Performance Results of Implicit Pipelining improvement 24% Improved Packet Access Delay Contending stations (N) Average Packet Access Delay (s) 802.11 Payload size: 512 B Implicit pipelining Payload size: 512B
41
Performance Results of Implicit Pipelining improvement 31% Improved Access Energy Efficiency Contending stations (N) Joule / Kbps 802.11 Payload size: 512 B Implicit pipelining Payload size: 512B
42
Performance of Implicit Pipelining in multi-hop Ad hoc networks Simulated in 30 1000m*1000m random networks with 80 contending stations Throughput ratio of “implicit” pipelining over 802.11 Aggregate Throughput Ratio 10% - 49% Improvement Topology Index
43
Performance of Implicit Pipelining in multi-hop Ad hoc networks Simulated in 30 1000m*1000m random networks with 80 contending stations Packet Access Delay Average Packet Access Delay (s) 802.11 Implicit pipelining Topology Index 11% - 69% Improvement
44
Performance of Implicit Pipelining in multi-hop Ad hoc networks Simulated in 30 1000m*1000m random networks with 80 contending stations Access Energy Efficiency Joule / Kbps Implicit pipelining 802.11 Topology Index 9% - 46% Improvement
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
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.