| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Yajun,
In my first comment, I meant to say that your intention is to say “except when the STA is in doze state when it switches back to the BSS primary channel” rather than “except that the STA is in doze state when it switches back to the BSS primary channel”. The “except that” can have a very different interpretation.
Regarding my second comment, the CID itself and other discussions in the document talk about not resuming backoff on the BSS PC if it has transmitted PM=1 on the NPCA PC. For example, “if an NPCA STA changed its PS mode (e.g., sending a frame with Power Management subfiled set to 1 and received the acknowledge), it won’t resume backoff after switching back to the BSS Primary channel.” This is not the definition of doze state that you are referring to now. Since you spoke of transmission of PM=1, I assumed that you are referring to the doze state from the perspective of the AP. Only the AP has no means of differentiating whether the non-AP is in doze or awake state and hence, will assume that the non-AP is in doze state after it has transmitted PM=1. If you are referring to the non-AP’s perspective which can be either awake or doze, the CID text as well as the above motivation is not accurate.
Now, let’s say that we agree to discuss only the non-AP perspective of doze state (as an alternative to awake state) after it has transmitted PM=1.
How often the non-AP changes from doze to awake state and for how long is not really in the scope of standards. One can claim that the non-AP is capable of detecting the initial preamble (and not the entire PPDU) when in doze state and hence perform both ED and PD. One can claim that the non-AP transitions to awake state upon receiving a preamble, processing it and transitions back to doze state. So, it is incorrect to state that the non-AP in its doze state cannot perform CCA. It is only from the perspective of the AP that it cannot.
Nowhere else in the specification too, the backoff procedure has been linked to the doze state. For example, in section 10.23.2.2 (EDCA backoff procedure), it is specified that the backoff procedure “shall” be invoked in various conditions including when a queue becomes empty or after the transmission of the final PPDU in the TXOP by a TXOP holder. The final PPDU transmitted might as well have been one with PM=1 and the non-AP might have transitioned to its doze state immediately after that. You may then want to qualify all these conditions using “except when in doze state”, etc.
So, the non-AP’s internal handling of doze/awake is outside the purview of the standards. The mandatory behavior required of the non-AP is that transmission can only occur after due backoff has been performed.
Regards,
Sindhu
Hi, Sindhu,Please see my reply in BLUEHi, Gaurang,The third reply to Sindhu might also be able to clarify your doubts.Furthermore, do you agree with the following scenario: If a non-AP STA sets the PS Management subfield to 1 on the NPCA PC, then when it switches back to the BSS PC, will this non-AP STA remain in the doze state without performing any exchanges with the AP if it has no further pending traffic?Looking forward to further discussion.Thanks,Yajun-------------------------------------------------------------------------------------------------------------------------------------------------------------------------Hi Yajun,I have some comments on the following change you are proposing in 25/1924r3:37.18.5 Switching back from the NPCA channelWhen the STA switches back to the BSS primary channel, it shall:1) replace the current values of the variables QSRC[AC], CW[AC] and the backoff counter for each EDCAF with the values that it stored when it switched to the NPCA primary channel.2) resume the backoff procedure, except that:— the STA is in doze state when it switches back to the BSS primary channel. (#4462)Comments:• The above change literally means that the STA must be in doze state when switching back to the BSS PC from the NPCA PC. This I think is not your intention
- YC: No, it doesn’t means the STA must be in doze state. CID #4462 raised that when the STA operates on NPCA PC and sets PS Management subfield to 1 to go to doze state, the STA won’t resume the backoff procedure after it switches back to the BSS PC.
• Your intention seems to be to omit backoff procedure for those STAs which are already in doze state. This too does not seem intuitive. Active or doze state of a non-AP STA is from the perspective of the AP when the AP intends to transmit to the non-AP. The non-AP can stay in doze state and continue to perform backoff and even transmit to the AP.
- YC: I may not agree with you that the non-AP STA in doze state can perform backoff or even transmit to AP.
Could you please elaborate on how the non-AP STA perform backoff procedure or even transmit when it is in doze state?Personally, the situation you mentioned where a non-AP STA can continue to perform backoff and even transmit to the AP, might occur when the non-AP STA is in AWAKE state rather than doze state.According to baseline(REVmf 1.0) ,
- (P2116L21) Physical and virtual CS functions are used to determine the state of the medium.
- (P2160L59) After this DIFS or EIFS medium idle time, the STA shall then generate a random backoff count…
The detection of the medium mainly involves physical Carrier Sensing and virtual carrier sensing/NAV, the former requires the non-AP STA to detect the channel by activating the radio frequency transceiver, while the latter requires receiving and decoding the frames within the channel.But, the definition of (P2731L64)Doze “STA is not able to transmit or receive non-WUR PPDUs and consumes very low power” means that the STA in doze state cannot detect the medium.Obviously, the non-AP SAT in doze state cannot perform backoff procedure.• Why is the backoff procedure being linked to the doze state?
- YC: Let me clarify it once again though I have clarified in the previous email.
I did not deliberately link/couple this to NPCA. That was not my intention. However, when considering the new feature NPCA, this issue arose.In the baseline, if the STA successfully exchanges frames with its associated AP to change its power mode and then enters doze state, it means the STA has accessed the channel and the backoff counter is zero.The introduction of NPCA PC creates a new scenario. We need to determine if the backoff procedure on the BSS PC should be resumed when the NPCA STA return to the BSS PC. This is an unprecedented issue in legacy Wi-Fi standard/baseline.The current wording in bn Draft 1.0, stating that 'the NPCA STA SHALL resume the backoff procedure,' may be overly prescriptive and technically inaccurate. This statement is problematic as it suggests that the backoff procedure MUST be resumed regardless of the specific state of the NPCA STA.The issue we are discussing is that the NPCA STA doesn’t resumes the backoff procedure if the NPCA STA is in doze state when it switches back to the BSS PC. If we don't exclude this situation, then what should the NPCA STA do when it in doze state? Must it wake up and resume the backoff procedure? This seems to be contrary to the original intention of saving energy, doesn't it?Again, I agree with that the non-AP STA in PS mode can perform backoff or even transmit, e.g. awake state. That is the reason why I add the exception that the non-AP STA is in doze state rather than in PS mode, i.e., ‘except that: the STA is in doze state when it switches back to the BSS primary channel. (#4462)’Regards,Sindhu-----邮件原件-----
发件人: Sindhu Verma <sindhu.verma@xxxxxxxxxxxx>
发送时间: 2026年2月3日 3:20
收件人: 程亚军 <chengyajun@xxxxxxxxxx>
抄送: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
主题: [External Mail]Re: [STDS-802-11-TGBN] CR doc-25/1924: Backoff Procedure after Switching Back to BSS PCH[外部邮件] 此邮件来源于小米公司外部,请谨慎处理。若对邮件安全性存疑,请将邮件转发给misec@xxxxxxxxxx进行反馈
To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature