Last Post: March 3, 2021:
11ax has introduced a new power save mechanism called TWT(Target Wake Time), where each station can negotiate their sleep time and wake for the TWT SP(Service periods) and does not have to wake up for beacons to read the TIM, this is a good feature which allows the clients to sleep depending on each clients needs.
My doubts is about multicast/broadcast frames, shouldn't the client wake up for each DTIM ? or else it would miss the multicast/broadcast frames, How does TWT handle this while the legacy clients will still be waking up for each DTIM and receive the frames.
I could not find the answer anywhere, would appreciate if someone can explain on this.
Extreme settings for DTIM, either large or small, can gravely affect Client performance. For example a setting of 1, 2, or 3, can limit battery life tremendously.
Parameters like TWT, in my estimation, only cloud the situation. The best source of information on this issue will probably be the technical team behind the particular client device you are using. I would bet that settings that work best for one client type, may only exacerbate the performance for another - due to the different "philosophies" behind the designs.
If you have any information regarding your own findings, since your fist post, I'm sure others would find it interesting.
Addendum: TWT also places more demands upon the AP's, or controllers in the network. Not the least of which will be a greater memory requirement. I predict that when the magic maximum number of clients, per AP, is reached, that some admins and users will be upset when they can not associate or the mechanism flat out fails.
This behavior could be tested ahead of time, but I have not heard of any tests being proposed. I'm sure that someday the WFA will need to add these tests to its /ax test suite.