- This topic has 0 replies, 1 voice, and was last updated 9 years, 7 months ago by
.
-
Posts
-
I’ve been struggling with a concept for a while, and I think I finally have it. Thanks to Andrew vonNagy for helping me think through this.
802.11-2012, Section 10.1.3.2:
Beacons are scheduled at the TBTT, which considered ‘absolute’ time (not relative time). Beacons can be delayed, but an AP’s TBTT is not adjusted for beacon delay that’s caused by Clause 9 medium access rules (standard EDCA arbitration).
When clients receive the beacon, it has a timestamp that is used by clients to set their own Time Sync Function (TSF). This means that clients have relative (not absolute) time based on whether or not the beacon was delayed, but luckily (and this was my discovery) the clients’ TSF doesn’t drift over time because the TBTT doesn’t drift over time. In other words, client TSF is relative, but only a little, and if it is ever off-base, the very next beacon (or the next or next, depending on beacon delay) would fix it (or come close to fixing it). Client TSF would never vary more than the maximum delay of a beacon.
If “sleeping” clients wake up at a TBTT so that they can hear the beacon (so as to see if they have queued data frames), and the beacon is delayed, then they simply stay awake however long it takes for the beacon to come. No harm, no foul.
Something I haven’t looked into extensively is if a beacon doesn’t show up at all, e.g. due to a collision. Does the client device get a clue at some point that the beacon isn’t going to show? I don’t know yet. Stay tuned.
- You must be logged in to reply to this topic.