| Hi Matthew,
I need to correct the text.
Juseong: The value of the UL Length field does not directly represent the time duration of the ICR frame. It is derived from TXTIME, which indicates the actual transmission time duration from the transmitter of the ICR ICF. According to IEEE 802.11-2024, subclause 26.5.2.2.4, Allowed settings of the Trigger frame fields and TRS Control subfield, “The AP shall set the UL Length subfield of a Trigger frame to the value given by Equation (27-11) with m = 2.” Therefore, when using the UL Length field value for timeout calculation, it must first be converted using Equation (27-11) of IEEE 802.11-2024 or an equivalent method.
Thank you.
Juseong Moon. 2025. 7. 29. 오전 10:26, 문주성 (Juseong Moon) <theonebird81@xxxxxxxxx> 작성:
Hi Matthew,
Thank you for sharing your PDT document. I have a few concerns and would like to share my comments below in-line.
Best regards, Juseong Moon.
37.10.2 Switching to the NPCA channel (#1505) (…)
2) All of the following conditions are true:
a) A sequence of three PPDUs, separated by aSIFSTime, is identified on the BSS primary channel, comprising an initial Control frame, an initial response frame and a third PPDU following the initial response frame
b) The STA received at least the first PPDU containing the initial Control frame and the PHY-RXSTART.indication and/or the PHY-RXEARLYSIG.indication of the third PPDU (#1513) (#2649) (#2678) (#2679) (#3047) (#3048) (#3416)
c) An indication that a valid TXOP was obtained on the BSS primary channel, as verified by the receipt of a PHY-RXEARLYSIG.indication or PHYRXSTART.indication primitive corresponding to the third PPDU that occurs during a time window that: i) has a duration that is equal to NPCA_START_TIMEOUT which is aSIFSTime + (2 x aSlotTime) + aRxPHYStartDelay ii) begins at aSIFSTime + ICR_Timeout after the MAC receives a PHY-RXEND.indication primitive corresponding to the first PPDU, where ICR_Timeout is equal to: (1) The length (in usec) of the expected CTS if the initial Control frame is an RTS or an MU-RTS Trigger frame (2) The value of the UL Length field of the Common Info field if the initial Control frame is a BSRP Trigger frame or a BSRP NTB Trigger frame (#2146) (#2433) (#2649)
Juseong: The value of the UL Length field does not directly represent the time duration of the ICR frame. It is derived from TXTIME, which indicates the actual transmission time duration from the transmitter of the ICR. According to IEEE 802.11-2024, subclause 26.5.2.2.4, Allowed settings of the Trigger frame fields and TRS Control subfield, “The AP shall set the UL Length subfield of a Trigger frame to the value given by Equation (27-11) with m = 2.” Therefore, when using the UL Length field value for timeout calculation, it must first be converted using Equation (27-11) of IEEE 802.11-2024 or an equivalent method.
I suggest a modified text as follows: The TXTIME, derived from the value of the UL Length field of the Common Info field if the initial Control frame is a BSRP Trigger frame or a BSRP NTB Trigger frame. NOTE: The TXTIME can be derived from Equation (27-11), with m = 2.
d) At least one of the three PPDUs in the sequence of PPDUs is classified by the STA as an inter-BSS PPDU following the procedure defined in 37.4 (Intra-BSS and inter-BSS PPDU classification for UHR STA) (#1056) (#2146) (#3593) (#3049)
e) At least one of the following conditions is true: i) The NPCA AP corresponding to the BSS of which the STA is a member has enabled PHYLEN NPCA only and the value of the MAC variable NPCA_PPDU_REM_DUR derived from the received third PPDU of the sequence of PPDUs is greater than the value indicated in the most recently received or transmitted NPCA Minimum Duration Threshold field corresponding to its BSS (#1056) (#2146) (#3593) (#3050) ii) If the NPCA AP corresponding to the BSS of which the STA is a member has enabled MOPLEN NPCA in addition to PHYLEN NPCA and the value of the MAC variable NPCA_CFRAME_TXOP_REM_DUR derived from the received first PPDU (containing the initial Control frame of the control frame exchange) of the sequence of PPDUs is greater than the value indicated in the most recently received or transmitted NPCA Minimum Duration Threshold field corresponding to its associated BSS (#1056) (#2146) (#3593)
f) (#1057) (#1217) (#1218) (#2146)The bandwidth of the third PPDU is determined by the STA to be 20, 40, 80, 160 or 320 MHz based on the Bandwidth field in the PHY preamble of the PPDU not overlap with the NPCA primary channel and the channel occupied by the PPDU does not overlap with the NPCA primary channel..(#3045) (#3046) (#3016)
g) If the STA maintains an intra-BSS NAV, it is zero; If the STA does not maintain an intra-BSS NAV, the basic NAV is zero. (#833) (#2148)
Juseong: If the NPCA STA has received at least a valid ICF and a subsequent frame (the ICR or the third frame following the ICR) during the NAVTimeout, it shall set the basic NAV. This is the baseline NAV rule, and the basic NAV will not reset until the NPCA STA receives a CF-End frame. Therefore, under the current PDT 25/0936r12, the NPCA STA cannot switch to the NPCA primary channel. The previous PDT revisions prior to r12 also have a similar issue. At present, I understand that a separate NAV for the NPCA primary channel is not defined. As a matter of common sense, the NAV is considered to be shared between the BSS primary channel and the NPCA primary channel. In this situation, once the NPCA STA switches to the NPCA primary channel based on condition 2) (ICF–ICR–third PPDU), it definitely sets the NAV and therefore cannot transmit on the NPCA primary channel at all. To resolve this issue, I have prepared a CR document, 25/1326r0. Please refer to CID #1823.
2025. 7. 28. 오후 3:41, Matthew Fischer <matthew.fischer@xxxxxxxxx> 작성:
Matt, Please find inline some clarifications.
From: Matthew Fischer <00000959766b2ff5-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Monday, July 28, 2025 12:29 PM
Salvatore,
Hi Matt,
Please find inline some further comments from my side.
what is the technical reason to substract the largest between
switch back delays of the STA and its intended recipients. This would also lead to effectively
have STAs returning
to primary channel at different times if bullet 1 of section 37.10.3 is kept, which may cause medium sync issues.
Several people have suggested that differing switch back times will cause medium sync problems on the BSS primary channel.
This should not be the case:
Regardless of when any STA switches back, there should never be a channel sync problem because every STA that switched did so based on received OBSS information
which is nominally the same information. In such a case, each STA can switch back at different times so long as all STAs switch back BEFORE the end of the OBSS occupancy.
So long as this is true, all returnees will only be able to sit and wait for the end of the OBSS busy time.
If you return earlier, it does not matter, because you are just going to sit and wait. [ST] I agree, but the assumption here is that STA will receive same OBSS information, which is not always the case. Also on top of medium
sync issue, my understanding is that by letting a STA switch earlier there would be a less efficient use of the resources as STAs that switch earlier would be able to neither transmit or receive anything on the primary, while they could have stayed longer
on the NPCA primary channel and perhaps continue communication.
Assuming that two STAs receive different OBSS information to invoke NPCA, then the switch back delay is not the thing that is causing them to return to the main channel out of sync.
It is the OBSS information that they received which causes this mis-sync.
But I could argue that this is not a mis-sync anyway, because, for a STA that has different OBSS information, that information is still valid and still prevents the STA from using the main channel.
[ST] Understood – One question: the STAs that switching back to the primary channel while there is still an OBSS will maintain the NAV information, and this won’t be reset even if they switch
earlier?
The intent is that when a STA switches to NPCA, it does this for a duration equal to the OBSS PPDU or the OBSS TXOP. In that case, either: a) the NAV on the BSS pch remains in place and continues to count down while the STA is on the NPCA pch, the BSS pch NAV will be at or near zero when the STA switches back b) the NAV on the BSS pch does not matter because the STA remains on the NPCA pch for exactly the duration of the OBSS activity back on the BSS pch The text is not actually clear as to which is the method, but these are logically equivalent implementation choices. The text should eventually clarify this as it is just implicit right now. If a STA switches back early, then in order to conform to this expectation, the STA would need to continue to obey the NAV on the BSS pch that had been set previously by the OBSS activity Again, this exactness does not currently exist in the text, but for fairness and channel state sync reasons, I do not think that anyone would object to such a description.
One might propose that if the AP switches, then all STAs should switch, since for STAs that remain on the main channel, communication with the AP will not be possible. The opposite is not true.
That is, if a STA switches but the AP does not, then there is little that can be done or that should be done.
This is more of a switch or not switch, not a difference in detected OBSS durations.
Such a proposal is problematic because the AP has detected an OBSS BUSY and is not supposed to transmit, so how can it communicate the switch information to the STAs? [ST] Agree that if AP switches back, then all STAs should also do so. However, my comment was for the case when the AP does not switch back because its switch back is shorter. In this case, the
AP could still serve those STAs with similar switch back delay, while the STAs with higher switch back can start return to the primary channel.
The statement was actually referring to the switch from BSS pch to NPCA pch, but is similarly applicable to the reverse case.
Regarding different switch back times: As noted below, the subtraction in the next revision will be only for that STA's switch back delay time.
As to your rationale to support this change, sure, there could be some additional time for all of the late switchers to exchange data - I do not believe that it is very significant. If the NPCA duration is 2 msec and the max difference in the sb delays is 128 usec, then the additional time is 5%. If the NPCA duration is longer, then the savings is less. In any case, with the change, you have what you are interested in.
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
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
|