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

Re: [STDS-802-11-TGBN] PDT MAC NPCA document 11-25-936 updated to r7


Yongho,



On Wed, Jul 23, 2025 at 8:10 PM Yongho Seok <yongho.seok@xxxxxxxxx> wrote:
Hi Matt, 

a)      The bandwidth of the PPDU is determined by the STA to be 20, 40, 80 or 160 MHzthe 20/40/80/160 MHz channel occupied by the PPDU is identified by the STA, (#3045) (#3046)based on the Bandwidth field in the PHY preamble of the PPDU and the channel allocations in the corresponding band indicated in the RXVECTOR parameter RU_ALLOCATION of the PHY-RXSTART.indication associated with the PPDU, if present (#421), and the channel occupied by the PPDU does not overlap with the NPCA primary channel (#1236)

Since the 320 MHz channel uses overlapping channelization, when a UHR BSS operates on 320 MHz-2 (e.g., channel center frequency numbered 63) and an NPCA STA receives an OBSS PPDU with the Bandwidth field set to 4 (320 MHz-1), the NPCA STA can use NPCA because the received OBSS PPDU does not overlap with the NPCA primary channel. Is there any reason this case is excluded? Otherwise, 320 MHz should be listed. 
The same comment applies to 2-f.

I agree that this disjoint 320 MHz case could work, except:
Is there anything in the received OBSS 320 MHz PPDU that allows a STA to determine which 160 MHz subchannels are occupied by the 320 MHz OBSS PPDU?
I.e. while the case that you describe seems reasonable, will the NPCA STA be able to correctly identify the specific subchannel occupancy of the 320 MHz OBSS PPDU?
If you can direct me to the PHY HEADER information that will definitively provide the specifics of the occupied channels of the 320 PPDU to the NPCA STA, then I can add that as a rule to use.
Otherwise, it will not work.
 

5)      The STA shall begin all frame exchanges on the NPCA primary channel with an NPCA  (#3056) ICF using non-HT PPDU or non-HT duplicate PPDU format using a rate of 6 Mb/s, 12 Mb/s, or 24 Mb/s.

a)      Details on the NPCA ICF are TBDFor TXOPs initiated by an AP, the initial Control frame (ICF) shall be a BSRP Trigger frame or an MU-RTS Trigger frame except when at least one of the target non-AP STA(s) is operating in the DUO mode, in which case, the ICF) may be a BSRP Trigger frame or a BSRP NTB Trigger frame but not an MU-RTS. In addition: (#1063) (#1225) (#1515) (#2371)

i)       The ICF shall conform to the rules in 37.11.2 (Dynamic Unavailability Operation (DUO) mode) if at least one of the target non-AP STA(s) is operating in DUO mode. (#1063) (#2371)

ii)     The ICF shall conform to the rules in 37.13 (Enhanced multi-link single-radio (EMLSR) operation for a UHR non-AP MLD) if at least one of the target non-AP STA(s) is affiliated with a non-AP MLD that is operating in EMLSR mode. (#1063) (#2371)

iii)    The ICF shall conform to the rules in 37.9.1 (Dynamic power save (DPS) operation) if at least one of the target non-AP STA(s) is operating in DPS mode. (#1063) (#2371)

Clarification question: 
Even though the DPS non-AP STA establishes the parameterized LC mode, does it mean that the NPCA AP shall use the default LC mode on the NPCA primary channel? The phrase “conform to the rules” does not necessarily imply that the rule is overriding. In the first main bullet, you state that the ICF shall be sent using the default LC mode.

The first bullet is a generic requirement for sending ICF/ICR during NPCA in order to increase the probability that other devices that may be present on the NPCA channel will hear the NPCA TXOP.
By also mandating non-HT 6, 12, 24, the odds of other devices receiving MAC information to protect the NPCA TXOP is further increased.
The fact that such a requirement also helps the operation of several reduced capability modes is an additional benefit but not necessarily the initial motivation for the requirement.
Nothing in the first bullet contradicts the rules in 37.15.1 DPS - you might argue that if a DPS STA is in HC mode, then there is no need for ICF/ICR and the rule here requiring the ICF/ICR is therefore somehow an override of the DPS rules - but that is not true - the DPS rules do NOT disallow the use of 6 mbps ICF/ICR during HC mode. Using such might be less efficient, but it is not forbidden.

I.e. Mandating the use of ICF/ICR during NPCA is not the same as mandating the use of LC mode during NPCA!

 

a)      For TXOPs initiated by a non-AP STA, if the intended recipient STA is a mobile AP operating in the DPS mode, the ICF shall conform to the rules found in 37.9.1 (Dynamic power save (DPS) operation). (#1063) (#2371)

I think we need further analysis on whether the mobile AP can use the NPCA. Currently, the spec does not state anything explicitly, but the current wording could be interpreted to mean that the mobile AP is allowed to use the NPCA. I would suggest removing this sentence until we have completed a more thorough analysis. 

Due to ongoing discussion on this item, I will not change it for now.


 

Thanks, 
Yongho 

2025년 7월 23일 (수) 오전 4:39, Matthew Fischer <matthew.fischer@xxxxxxxxx>님이 작성:

Morteza,

Draft not ready yet, pending review of additional reviews...

1) added a line for the 80 MHz BSS case regarding NPCA channel placement, per your comment

2) and vs or regarding BW of OBSS PPDU - discussing this paragraph with other reviewers - not settled on a change yet

3) initial Control response
I was not certain if the response is always a control frame, but I guess it is

4) request to merge conditions a) and b) of condition 2)
the conditions are distinct - note that condition a) requires a sequence to be identified and condition b) describes the parts of the sequence that must be identified
While it might be possible to merge them, there is no value in merging them - it would just be an exercise in attempting to create accurate text

5) UL length field of the BSRP frame - 
added NTB case

6) BW of OBSS determination
The language here is being reviewed by multiple people
I have a tentative change that I think solves your problem
It identifies the BW of interest as only extracted from the first frame, and in that case, even though RTS is explicitly called out in the sub bullet, this does not mean that BSRP, for example is ignored
I.e. anything that is not explicitly named in the sub bullets is already covered by the generic statement of the main bullet, so BSRP is already covered

7) indentation
if you switch to simple markup I believe that the indentation is correct
if it is not, then it is probably because of a formatting problem that I am unable to correct and will leave to the TGbn editor

8) existing values of the variables
I think that the phrase is straightforward
if you look at the existing baseline EDCA, it mentions these variables, and clearly, they are dynamic.
IF it helps, I can change "existing" to "current"

9) received INIT_QSRC value - 
added transmitted, as per comment

10) ICF for NPCA by non-AP STA
merged your comments with those from others

11) switch back time
yes - trying to get agreement among various people
Will add at least a minimal statement that a STA switches back when NPCA_TIMER expires
A lot of people have a lot of opinions about the exact nature and conditions for the switch back, but that base statement should at least exist





On Thu, Jul 17, 2025 at 5:48 PM Morteza Mehrnoush <morteza.80211@xxxxxxxxx> wrote:
Hi Matt,

Thank you for preparing the new revisions. Attached please find some comments on r8.

Thanks,
Morteza

On Wed, Jul 2, 2025 at 6:19 PM 顾祥新 (Xiangxin Gu) <000046f9987a2d10-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:

Hi Matt,

 

Thanks for the clear answer. I’d like to respect the group’s selection.

 

BTW, the method captured in the PDT is not align with the motion:

•         The NPCA operation shall use the same EDCA parameters ((MU) EDCA Parameter Set, EPCS EDCA Parameters), on both the BSS primary channel and the NPCA primary channel.

[Motion #145, [1] and [203, 195]]

 

BR,

 

Xiangxin Gu

Institute of Communication Technology

unisoc-signature

 

From: Matthew Fischer <matthew.fischer@xxxxxxxxx>
Sent: Tuesday, July 1, 2025 7:55 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] PDT MAC NPCA document 11-25-936 updated to r7

 

 

Xiangxin,

 

You have correctly raised this question on the reflector so that the question is actually addressed to the entire TGbn and not just to me.

 

The current mechanism is the result of previous discussions which to the best of my recollection, included a proposal such as yours.

 

 

 

On Sun, Jun 22, 2025 at 10:50 PM 顾祥新 (Xiangxin Gu) <Xiangxin.Gu@xxxxxxxxxx> wrote:

Hi Matt,

 

Thanks for the excellent job on NPCA PDT.

 

During the last Thu. teleconference, many members asked questions on the mode of the non-AP STA not using untriggered UL transmission on NPCA channel by setting NPCA AIFSN to 0.

To my understanding, it is hard for the AP to make the non-AP STA not EDCA NPCA channel by this way.

Firstly, the AP has to keep triggering UL transmission to the non-AP STA to keep the corresponding MUEDCATimer not expired.

Secondly, the situation becomes more sophisticated in case that EDCA BSS channel is allowed for the non-AP STA.

 

Why not just use a single bit in the signaling to indicate the mode, which is easier for the AP implementation and also clearer for reading ?

 

BR,

 

Xiangxin Gu

Institute of Communication Technology

unisoc-signature

 

From: Matthew Fischer <matthew.fischer@xxxxxxxxx>
Sent: Thursday, June 19, 2025 11:05 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBN] PDT MAC NPCA document 11-25-936 updated to r7

 


In response to various comments received, a new revision is available.

 

 

 

 

--

Matthew Fischer

Broadcom

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

This email (including its attachments) is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. Unauthorized use, dissemination, distribution or copying of this email or the information herein or taking any action in reliance on the contents of this email or the information herein, by anyone other than the intended recipient, or an employee or agent responsible for delivering the message to the intended recipient, is strictly prohibited. If you are not the intended recipient, please do not read, copy, use or disclose any part of this e-mail to others. Please notify the sender immediately and permanently delete this e-mail and any attachments if you received it in error. Internet communications cannot be guaranteed to be timely, secure, error-free or virus-free. The sender does not accept liability for any errors or omissions.
本邮件及其附件具有保密性质，受法律保护不得泄露，仅发送给本邮件所指特定收件人。严禁非经授权使用、宣传、发布或复制本邮件或其内容。若非该特定收件人，请勿阅读、复制、 使用或披露本邮件的任何内容。若误收本邮件，请从系统中永久性删除本邮件及所有附件，并以回复邮件的方式即刻告知发件人。无法保证互联网通信及时、安全、无误或防毒。发件人对任何错漏均不承担责任。


 

--

Matthew Fischer

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

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



--
Matthew Fischer

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



--
Matthew Fischer

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