| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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):
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:
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?
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:
|