Dust-up: Client Listen Interval -vs- AP DTIM Count
Last Post: February 11, 2015:
-
Is it? Thanks a lot! Cheers!
-
Does anyone have any new information on this topic ?
-
Hi,
what was the final conclusion on this?
-
I did not have anything new on this, so I decided to look through the Interoperability test suites used by the UNH-IOL Wireless test lab. Many of their tests cut through the maze of the 802.11 standard and define clear cut tests to prove its requirements.
Starting on page 50 In the description of their 802.11 Base AP MAC Layer Test Suite, Test #1.3.2 - Aging Function, defines the requirements. To make a long story short, I'll only quote parts of the test:
"The exact point at which frames should be discarded is not defined in the standard, but the period must not be shorter than the Listen Interval...".
This is tested, in various increments, with Listen Intervals from one (beacon period) to the maximum of 65,535.
From the expected results section:
"The [AP] should eventually discard traffic that has been buffered...longer than the Listen Interval of [the client]." and "[The AP] should not discard traffic that has been buffered for [the client] for less than the Listen Interval".
This test description ends with:
"If the AP deauthenticates or disassociates the [client] it has traffic for prior to reaching the [clients] listen Interval the test results will become invalid."
I did not find any tests involving the Listen Interval in any of their other tests, nor did I find any restrictions based upon the AP's DTIM interval.
-
I edited my last reply on this topic, and hoped that it would then show up as a new entry. It didn't, so I've put in this note just to increment the date.
-
But still it's unclear.
Lets take one example:
Suppose LI is 7 and DTIM of AP is 10. That means Station will wake up for any UC frames for every 7th beacon period.
Now, STA wakes up at 7th beacon period and found that there is no frames for it. But AP have some BC and MC frames. So will this STA will wake up at 10th beacon interval ? if yes then how? If no then those BC MC frames are missed by this STA.
Any use case where we can see BC and MC frames ?
-
This appears to be one of those questions left open (undefined) in the 802.11 standard.
It depends on whether the device supports WMM, and Listen Interval algorithms used in the specific AP and the Client devices in question.
A search I just ran found that Symbol, RIM, Broadcom, and Cisco all have patents that mention this issue. I did not get a chance to investigate the WMM requirements further, but that is where I suggest you look for a (hopefully) clearer answer.
Obviously, simple minded DoS attacks against the AP would be possible if the AP did not remain the ultimate arbiter of the process. Also, for effective power savings, the AP and Client must cooperate very closely. One interesting technique uses dynamic LI changes through, otherwise superfluous, Re-Association Requests.
I think the overriding phrase here is "The AP... may use the Listen Interval...".
-
If U-APSD is used then , legacy PS is not used. (is this statement correct ? ).
But if U-APSD is not used by client device then STA's LI algo might take the DTIM count and wake up accordingly... (nt clear)..
not clear about AP's algo for LI check ??? How AP will adjust ?
-
Hi, i read all the threads of " Client Listen Interval -vs- AP DTIM Count ". Regarding your doubt LI = 7 and DTIM = 10, STA will wake up to receive 7th beacon(TIM) and check if UC data is buffered at AP if data is buffered STA will ask for data and once data transmission is over it'll go back to sleep mode and wake up again to receive DTIM. DTIM count is also present in all the TIMs so last TIM received by STA will decide when to wake up for DTIM. Since DTIM is the only way to get the info. of buffered BC/MC data STA has wait till it receives DTIM.
-
Bt on what basis you are saying this.
Do you have any packet capture to prove it . Or you have any reference of standard .
Plz let me know.