| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Minho and Mark, My understanding of using the two modes is the following. There are only two power management mode: 1)
Active mode (AM): PM bit = 0. Under AM, the STA is
always in awake state. 2)
Power Save mode (PSM) : PM bit = 1. Under PSM, the STA switches between the awake state and the doze state. The first question that we need to answer is, if a STA uses WUR mode,
which power management mode does it need to use? (Please note that a STA
must use
one and only one “power management mode”) I think the answer is the STA
needs to use PSM, otherwise the STA is always in awake state. Hence, a natural conclusion
is: if the STA wants to use WUR mode, it has to use PSM and WUR mode simultaneously. Please correct me if you find any error in the above deduction. Best Regards, Jason Yuchen Guo 发件人: *** 802.11
TGba - WUR- Wake-up Radio Operation *** [mailto:STDS-802-11-TGBA@xxxxxxxx] 代表
Mark Hamilton Hi, Minho, all, I didn’t get to hear the discussion in TGba on this topic, so my first response is that what I have in my slides may be inaccurate/out-of-date, and hence why these assumptions
need to be confirmed with TGba, before ARC takes any next steps. That said, my understanding of the latest thinking in TGba is that the main radio stack (that’s the “PCR”, right?) is in an existing power save mode, when it is relying on
the WUR to handle any needed wakeups. And, further, that it is envisioned to use one of the longer-term existing power save modes – not, for example, “legacy” power save as the 11-17/992r1 presentation seems to imply in the first few slides (with TIM indications,
PS-Polls, etc.) I had heard that TWT or WNM sleep mode are highly likely possibilities. But, all this is conjecture on my part, based on hallway “rumor” that I’ve heard. My only understanding of the term “WUR mode” comes from reading 11-17/972r2. So, please excuse my approach, but I will not use that term, in the following. My understanding, which I tried to capture in slide 9, is that a device that has WUR capability would be generally in one of two states (ignoring brief intervals while it is
transitioning from one to the other):
-
The “main” Wi-Fi stack is operational, and the WUR radio is “off”. In this state, the main stack may or may not be in some (short-term) power save mode; for example,
it could be using U-APSD, or even a PS-Poll mode, etc. The point is that the main stack is acting like a traditional 802.11 device with respect to the AP, and to local higher layers/applications. During this time, the power consumption is consistent with
a traditional 802.11 device. The WUR radio is effectively powered down, optionally (I would think it would be, for purposes of saving power, but perhaps some implementations would find it acceptable to just leave it on, but doing effectively nothing).
-
OR
-
The main Wi-Fi stack is in a deep sleep mode (WNM sleep mode or TWT, for example), for an extended period of time, and the WUR radio is active (RX-only, though) and
configured and negotiated to be ready to receive wake up frames. Since the Wi-Fi stack retains state and can immediately come back to activity when a WUR wakeup happens, the Wi-Fi stack is not “off”. However, per 11-17/972r2, it seems there is discussion
of taking the main stack into an even longer sleep by also suspending the normal behavior of the deep sleep mode that it is in. I gather from 11-17/972r2 that my second state is “WUR mode”. If that is in error, someone please correct me. So, to try to address your question, I think I would say that when in WUR mode, the main stack is in a long-term sleep mode (again, such as TWT or WNM sleep mode) and the WUR
radio is following its appropriate behavior to receive wakeup frames. But, your question seems to be specifically focused on whether the main stack is following any periodic wakeup – for Beacons, or perhaps other signaling – while it is in this deep sleep
mode. Maybe I’m missing something, but I think the straw poll in 11-17/972r2, on slide 6, showed that the TGba membership felt it was preferable for the sleeping device to suspend
any such periodic wakeups when in “WUR mode”. However, if the motion failed to say that such a device does not need to wake up to periodically receive a Beacon, that seem in contradiction to the straw poll in 11-17/972r2. So, I’m confused. I personally don’t see any architectural preference for the answer to whether the main stack wakes up periodically, or at what frequency – it comes down to complexity of having
both AP and non-AP STA understand that such periodic wakeups are suspended, and take additional steps to account for that (such as time synchronization upon wakeup, additional buffering needed in the AP, higher likelihood of error conditions/state change complexities
that need to be handled, etc) versus the benefits of the additional power savings. The addition of WNM sleep mode, for example, is already one facility we have for a non-AP STA to not receive every Beacon (or even DTIM), with the resulting implications.
I seems that WUR mode, with a suspended main stack sleep mode, is just another such facility being added with parameters appropriate for a different usage scenario. To your two options below, I’m trying to see what the difference is between the two options, really. If we say that a (non-AP) STA is not allowed to be in both WUR mode and
power saving mode at the same time, I can only assume (based on what WUR mode means, from above), that the allowed state is to have the WUR radio receiving wakeup frames, and the main stack is “off” (?). Surely, the main stack being fully operational doesn’t
make sense (that’s my first state above, not the second state, where “WUR mode” makes any sense. And, the main stack in power saving mode is disallowed. So, what else is there but “off”? Is that the question – if the device is in “WUR mode” must the main
stack be completely off – which I would take to mean not preserving state, and therefore would go through all the usual power-on sequence to reconnect to the AP upon wakeup?
(Note that if this is the question, then slide 9 of the ARC material explicitly states my assumption that I thought TGba _did_ allow the main stack to remain associated
while using the WUR for wakeup. So, your comments about “aligned with slide 9” confuse me.) Mark From: Minho Cheong [mailto:minho.cheong@xxxxxxxxxxxx]
Hi Mark,
I have a quick question on 2nd & 3rd paragraph in slide 9.
FYI, In Berlin, a related motion failed at TGba session, I remember:
-
Motion text contained in 17/0992r1 was “the STA does not need to wake up its PCR periodically to receive the beacon when the STA uses both the power
save mode and the WUR mode simultaneously”. I’m still confused on the relation between the above motion and slide 9 of this material. In order words, could you confirm if option#2 in the below would be the right path between the following two possible options, from the WLAN architectural point
of view?
-
(option#1) allow STA to belong to power saving mode and WUR mode at the same time. Only need to define STA’s specific functions.
o
It seems aligned with the above motion which was failed in Berlin
-
(option#2) doesn’t allow STA to belong to power saving mode and WUR mode at the same time.
o
It seems aligned with slide 9 of ARC material Thanks a lot.
Minho From: *** 802.11 TGba - WUR- Wake-up Radio Operation *** [mailto:STDS-802-11-TGBA@xxxxxxxx]
On Behalf Of Mark Hamilton All, I have uploaded an “r1” update to the document, capturing the notes as made during today’s discussion. I marked what we discussed today in green colored text, although I understand
these are still our “best guess” and may not be final or 100% agreements. Again, just trying to be helpful in moving the discussion along, hopefully in parallel with work going on in TGba, and hopefully helping to provide insight into/for that work. Update is here:
https://mentor.ieee.org/802.11/dcn/17/11-17-1246-01-0arc-11ba-arch-discussion-part-2.pptx
Mark From: Mark Hamilton [mailto:mark.hamilton2152@xxxxxxxxx]
All, I have uploaded a document intended to guide the discussion on Tuesday’s (Aug 15) ARC call, considering 11ba architecture concepts, here:
https://mentor.ieee.org/802.11/dcn/17/11-17-1246-00-0arc-11ba-arch-discussion-part-2.pptx
Any comments before the call are also welcome, of course! Thanks. Mark On Mon, Jul 17, 2017 at 4:36 PM, Mark Hamilton <mark.hamilton2152@xxxxxxxxx> wrote:
|