Network Engineering Stack Exchange is a question and answer site for network engineers. It only takes a minute to sign up.
Sign up to join this community
I have been reading multiple sources regarding STAs PS mode and they all end up saying that the STA is responsible to wake up at preconfigured (during association) Listen Intervals to check the AP's Beacon for TIM-->AID and grab the buffered data.
But how come that when a message from a chatting app is sent to the target STA, it wakes up immediately without waiting for its Listen Interval to happen? Who wakes the STA up then?
Every access point sends beacon packets at regular interval called as beacon interval. The station which wants to save power provides “Listen Interval” field during association with the AP. The listen interval is given in beacon interval units, so essentially it tells the AP how many beacons it wants to wait before turning the receiver on from the sleep state. After waking up, STA waits for a beacon and check if AP has buffered any frames for it (This can be known from the TIM element corresponding to AID in the beacon frame). If AP has buffered any frames then the STA requests AP for transmission of those frames.
But how come that when a message from a chatting app is sent to the target STA, it wakes up immediately without waiting for its Listen Interval to happen?
Beacon interval is in range of few tens of milliseconds (eg. 50ms, 100ms) and listen interval is usually few beacon periods. So in most of the cases a device can wake up periodically within 300-400 ms and retrieve all the frames buffered by the AP. So we feel that it's quite immediate. If we configure listen interval to few seconds, then the delay in data will be boldly noticeable.
Who wakes the STA up then?
In Power save mode STA is configured to wake up within listen interval and check if AP has buffered any frames for it. It wakes up by itself. Its internal clock acts like alarm clock which wakes it up after a predefined time.
