doc.:IEEE /321r0 Submission May 2002 Y. Liu, et al Slide 1 CC/RR Performance Evaluation Yonghe Liu, Jin-meng Ho, Matthew B. Shoemake, Jie Liang Texas Instruments

doc.:IEEE /321r0 Submission May 2002 Y. Liu, et al Slide 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

doc.:IEEE /321r0 Submission May 2002 Y. Liu, et al Slide 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

doc.:IEEE /321r0 Submission May 2002 Y. Liu, et al Slide 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

doc.:IEEE /321r0 Submission May 2002 Y. Liu, et al Slide 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

doc.:IEEE /321r0 Submission May 2002 Y. Liu, et al Slide 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

doc.:IEEE /321r0 Submission May 2002 Y. Liu, et al Slide 7 Simulation Result: EDCF Request sending every 2s –Using EDCF –CWmin = 15, CWmax=1023, AIFS=DIFS Request dropped after retry limits (7) Large latency and jitter Delay (seconds)

doc.:IEEE /321r0 Submission May 2002 Y. Liu, et al Slide 8 Simulation Result: EDCF Request sending every 2s –Using EDCF –CWmin = 7, CWmax=1023, AIFS=DIFS Still have dropped requests after retry limits (7) Slightly lower latency but jitter still high Delay (seconds)

doc.:IEEE /321r0 Submission May 2002 Y. Liu, et al Slide 9 Simulation Result: EDCF Request sending every 2s –Using EDCF –CWmin = 3, CWmax=1023, AIFS=DIFS Still have dropped requests after retry limits (7) Latency no better and jitter still high Delay (seconds)

doc.:IEEE /321r0 Submission May 2002 Y. Liu, et al Slide 10 Simulation Result: EDCF Request sending every 2s –Using EDCF –CWmin = 15, CWmax=63, AIFS=DIFS Still have dropped requests after retry limits (7) Delay (seconds) Latency marginally better and jitter still high

doc.:IEEE /321r0 Submission May 2002 Y. Liu, et al Slide 11 Simulation Result: EDCF Request sending every 2s –Using EDCF –CWmin = 7, CWmax=63, AIFS=DIFS Delay (seconds) Still have dropped requests after retry limits (7) Latency marginally better and jitter still high

doc.:IEEE /321r0 Submission May 2002 Y. Liu, et al Slide 12 Simulation Result: EDCF Request sending every 2s –Using EDCF –CWmin = 3, CWmax=63, AIFS=DIFS Delay (seconds) Still have dropped requests after retry limits (7) Latency marginally better and jitter still high

doc.:IEEE /321r0 Submission May 2002 Y. Liu, et al Slide 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)

doc.:IEEE /321r0 Submission May 2002 Y. Liu, et al Slide 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)

doc.:IEEE /321r0 Submission May 2002 Y. Liu, et al Slide 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