1 / 15

CC/RR Performance Evaluation

This study aims to clarify the usefulness and applications of CC/RR in specific situations where it is the most effective mechanism. Simulation results demonstrate that CC/RR is particularly useful for servicing bursty traffic, initiation of signaling, and delay-sensitive traffic. Alternatives such as round-robin polling and EDCF have their limitations and cannot fully replace CC/RR. The recommendation is to keep CC/RR due to its better performance in certain cases.

clares
Download Presentation

CC/RR Performance Evaluation

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. CC/RR Performance Evaluation Yonghe Liu, Jin-meng Ho, Matthew B. Shoemake, Jie Liang Texas Instruments Y. Liu , et al

  2. Objective • To clarify and illuminate the usefulness of and applications for CC/RR • CC/RR is not a panacea, but there are specific and important situations in which CC/RR is the most effective mechanism • CC/RR is complementary to HCF in its ability to enhance controlled contention functionality • To show simulation results that show specific and valid situations where CC/RR is the most effect mechanism to use Y. Liu , et al

  3. Applications of CC/RR • CC/RR is useful for servicing bursty traffic: • Initiation of signaling • E.g, voice call setup • It is unacceptable to have long delays in setting up voice calls or even worse dropped signaling packets due to heavy network load • On/Off delay sensitive traffic • E.g., telnet, chat, web browsing • These types traffic are very bursty yet require low latency • CC/RR provides an efficient mechanism to determine which stations have traffic to send on a heavily loaded network without large overhead • Better control • Through CC sending frequency and CCI length Y. Liu , et al

  4. Possible Alternatives to CC/RR • In the cases where CC/RR is most effective, alternative mechanisms have problems • Round robin polling • In the case of a heavily loaded network with bursty traffic not all devices have data to transmit • Likewise there may be many stations, e.g. VoIP clients, that have no data to transmit, but require a guaranteed low latency response when they do have traffic • In either case, round robin polling becomes inefficient due to the fact that many clients on the network do not have traffic • Likewise, when the number of clients with traffic is small percentage, round robin polling yields large response times than does CC/RR • EDCF • In servicing delay sensitive traffic, EDCF has little control • Making EDCF traffic more aggressive to minimize delay results in the risk of dropped packets Y. Liu , et al

  5. EDCF Replacing CC/RR? • EDCF • Request frames sent using EDCF • Piggyback requests with data • Possible • High latency for requests • Simply cannot tolerate this! • Large jitter • Dropped requests Y. Liu , et al

  6. Simulation Setup • Two downlink streaming flows • Contention Free • 2.4Mbps each • 1500 Bytes packets • Exp. inter-arrival time • 14 STAs using EDCF • CWmin = 31, AIFS=DIFS • Exp. ON/Off model • 1.2 Mbps each • 1 STA sending TXOP requests • Simulations compare latency of TXOP requests using: • EDCF with various CWmin/CWmax • CC/RR Y. Liu , et al

  7. Simulation Result: EDCF • Request sending every 2s • Using EDCF • CWmin = 15, CWmax=1023, AIFS=DIFS Large latency and jitter Request dropped after retry limits (7) Delay (seconds) Y. Liu , et al

  8. Simulation Result: EDCF • Request sending every 2s • Using EDCF • CWmin = 7, CWmax=1023, AIFS=DIFS Slightly lower latency but jitter still high Still have dropped requests after retry limits (7) Delay (seconds) Y. Liu , et al

  9. Simulation Result: EDCF • Request sending every 2s • Using EDCF • CWmin = 3, CWmax=1023, AIFS=DIFS Latency no better and jitter still high Still have dropped requests after retry limits (7) Delay (seconds) Y. Liu , et al

  10. Simulation Result: EDCF • Request sending every 2s • Using EDCF • CWmin = 15, CWmax=63, AIFS=DIFS Latency marginally better and jitter still high Still have dropped requests after retry limits (7) Delay (seconds) Y. Liu , et al

  11. Simulation Result: EDCF • Request sending every 2s • Using EDCF • CWmin = 7, CWmax=63, AIFS=DIFS Latency marginally better and jitter still high Still have dropped requests after retry limits (7) Delay (seconds) Y. Liu , et al

  12. Simulation Result: EDCF • Request sending every 2s • Using EDCF • CWmin = 3, CWmax=63, AIFS=DIFS Latency marginally better and jitter still high Still have dropped requests after retry limits (7) Delay (seconds) Y. Liu , et al

  13. Simulation Result: CC/RR • Request sending • Using CC/RR, CC Priority<Streaming • Every 20ms starting at 0 High delay due to large CF burst, EDCF suffers as well Delay (seconds) Y. Liu , et al

  14. Simulation Result: CC/RR • Request sending • Using CC/RR, CC Priority>Streaming • Every 20ms starting at 0 0~20ms Offset possible depending on periodic CC’s start time Delay (seconds) Y. Liu , et al

  15. Conclusion • CC/RR an effective method for collecting requests for delay sensitive • Signaling • Bursty traffic • EDCF not capable of replacing CC/RR • Large latency and jitter • Dropped packets • AP has no control over delay of RR request • HCF with Round Robin Polling • Inefficient in case where CC/RR is effective Recommendation Keep CC/RR, because there are important cases where it provides better performance than any other mechanism Y. Liu , et al

More Related