Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[STDS-802-11-TGBA] 答复: [STDS-802-11-TGBA] [STDS-802-11-ARC] ARC Teleconference and connection info - August 15, 9am ET



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
发送时间: 2017826 2:41
收件人: STDS-802-11-TGBA@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBA] [STDS-802-11-ARC] ARC Teleconference and connection info - August 15, 9am ET

 

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]
Sent: Thursday, August 24, 2017 12:53 PM
To: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Cc: STDS-802-11-TGBA@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBA] [STDS-802-11-ARC] ARC Teleconference and connection info - August 15, 9am ET

 

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.


Best Regards,

 

Minho

 

 

From: *** 802.11 TGba - WUR- Wake-up Radio Operation *** [mailto:STDS-802-11-TGBA@xxxxxxxx] On Behalf Of Mark Hamilton
Sent: Tuesday, August 15, 2017 7:18 AM
To: STDS-802-11-TGBA@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBA] [STDS-802-11-ARC] ARC Teleconference and connection info - August 15, 9am ET

 

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]
Sent: Friday, August 11, 2017 5:26 PM
To: STDS-802-11-ARC@xxxxxxxxxxxxxxxxx; '*** 802.11 TGba - WUR- Wake-up Radio Operation ***' <STDS-802-11-TGBA@xxxxxxxx>
Subject: RE: [STDS-802-11-ARC] ARC Teleconference and connection info - August 15, 9am ET

 

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:

--- This message came from the IEEE 802.11 ARC Reflector ---

All,  (TGba reflector on CC:, as FYI, and an invitation to anyone who is personally interested)

 

This is a reminder that, as agreed in Berlin, the ARC SC will hold a teleconference to continue our discussion of 802.11ba architecture implications, at 9:00 am Eastern Time Tuesday, August 15th for 1 hour.

 

We’ll use the JoinMe conference bridge (connection information is below).

 

The agenda is to continue our discussions on 802.11ba (WUR) architecture topics.  Please see slides 17-20 of the Berlin ARC agenda (11-17/0886r4) for our current/latest status.  The goal is to distill a list of assumptions (or questions where don’t think we can propose assumptions) that we can use to guide the joint discussion with TGba in Kona.


See (hear) you there!  Mark

 

--

 

Note that teleconferences are subject to IEEE policies and procedures, see:

        IEEE Patent Policy

        Patent FAQ

        Letter of Assurance Form

        Affiliation FAQ

        Anti-Trust FAQ

        Ethics

        802 LMSC P&P

        802 LMSC OM

        802 WG P&P

        IEEE802.11 WG OM



Connection information:


Join the meeting: https://join.me/IEEE802.11

On a computer, use any browser with Flash. Nothing to download.
On a phone or tablet, launch the join.me app and enter meeting code: IEEE802.11


Join the audio conference:
Dial a phone number and enter access code, or connect via internet.

By phone:
United States - Hartford, CT   +1.860.970.0010
United States - Los Angeles, CA   +1.213.226.1066
United States - Thousand Oaks, CA   +1.805.309.5900
Australia - Sydney   +61.2.9191.6319
Canada - Toronto   +1.647.977.2648
Finland - Helsinki   +358.9.4259.9698
Germany - Frankfurt   +49.69.3329.6380
Hong Kong - national   +852.5808.1760
Japan - Tokyo   +81.3.4579.5983
Korea, Republic of - South Korea   +82..26.022.2310
Netherlands - Amsterdam   +31.20.808.3218
United Kingdom - London   +44.33.0088.2634
Access Code   808-571-868#

Other international numbers available

By computer via internet:
Join the meeting, click the phone icon and select 'Call via internet'. A small download might be required.