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

Re: [STDS-802-11-TGBN] 11-25-936r4 PDT NPCA update -- was: Reminder: Technical Submissions Queues

Dear Matthew,

I have a comment on the current NPCA condition related to NPCA PCH occupancy.
In the current PDT CR MAC NPCA CC50(25/0936r5), NPCA operation is only allowed when none of the first, second, or third PPDUs occupy the NPCA primary channel (PCH) in the MAC Header-based condition 2).

(page 46)
d) (#1057) (#1217) (#1218) (#2146)the largest bandwidth of the three PPDU(s) is determined by the STA to be less than or equal to one half of the BSS operating bandwith as determined based on the channel allocations in the corresponding band and the PPDU bandwidth that is signaled in the received PPDU(s) or obtained from the RXVECTOR parameter CH_BANDWIDTH_IN_NON_HT of the received PPDU(s), and the channels occupied by the PPDU(s) do not overlap with the NPCA primary channel (#3045) (#3046) (#3016)

However, since the third PPDU is already observed by the STAs when making the NPCA decision, I wonder if it might be more reasonable to allow NPCA as long as the third PPDU does not occupy the NPCA PCH—even if the first one does.

If there is any specific reason why all three PPDUs must be considered, could you kindly share the rationale behind it?  

Looking forward to your thoughts.

Best regards,
Gwangho

2025년 6월 13일 (금) 오전 5:22, Matthew Fischer <matthew.fischer@xxxxxxxxx>님이 작성:

Haorui,

Please see inline:

On Wed, Jun 11, 2025 at 8:32 PM Haorui Yang (Rae) <yanghaorui0217@xxxxxxx> wrote:
Hi Matthew,

Thanks for your response.

My futher response is:
1. I am confused by the explaination of number of devices under AP who guesses the appropriate value. This may be an implementation solution but I cannot find such idea in the spec.
    For the QSRC, I checked 10.23. The QSRC is used under some conditions e.g. the previous PPDU transmission fails. 
    However, in the PDT the QRSC is always used in the CW setting, even its default value is 0.
    I do not get the reason why not follow the exisitng CW setting.
There are many parameters of 802.11 MAC operation that have always been flexible, with a range of values allowed and with nothing in the standard to indicate how a device that has control of those parameters should decide what those values should be set to. This case is not different from the existing standard. Yes, it is an implementation decision as to what values to use; In some cases, the standard might provide some suggestions, but certainly, there are many cases where no such suggestions exist.
 
    
2. In the PDT, the MUEDCA is mentioned in 37.10.1 where says that the transition bwt EDCA and MUEDCA parameters occurs at the same time on both PCH and NPCA PCH.
    So if the MUEDCA timer is not zero and the MUEDCA is triggered due to the transmission on NPCA, when the STA swtiches back, the MUEDCA parameters on PCH are still used. 
    If the QSRC[AC], CW[AC]and the backoff counter for the AC having a successful transmission on NPCA is replaced then this is against the text in 37.10.1?
I do not know what you mean when you say that MUEDCA is triggered by a TX on NPCA - I think that you mean that the MUEDCA timer is reloaded after a TX on NPCA, which happens if the AP triggers the STA.
At switch back, MUEDCA parameters used on the primary channel - yes, ok, because a successful TX for restarting the MUEDCA timer can happen anywhere because the timer is there to make certain that the STA is receiving a minimum amount of TXOPs. That sounds fine to me.

But I am lost again on the next part when you say that the QSRC is replaced due to a successful transmission and that this is against the text?
How is there a contradiction?

 
BRs,

Haorui Yang (Rae)

China Mobile
---- Replied Message ----
From Matthew Fischer<matthew.fischer@xxxxxxxxx>
Date 6/12/2025 00:27
To <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject Re: [STDS-802-11-TGBN] 11-25-936r4 PDT NPCA update -- was: Reminder: Technical Submissions Queues

Haorui,

First, I would like to say that between you and I, the discussion reflects only the thoughts of two of the members of 802.11, so we probably cannot create a reasonable resolution without having a lot more opinion expressed by the other members. So what follows are just my thoughts and without knowing what the larger group would prefer to do, I will not offer any proposed modifications to the current document:

On Tue, Jun 10, 2025 at 8:08 PM Haorui Yang (Rae) <yanghaorui0217@xxxxxxx> wrote:
Hi, Matthew,
Thanks for drafting the PDT.
Please find the following comment from my side:
1. I am wondering why the initial QSRC should be announced by the AP to make the STA to align the counter with the AP. There is no such behaviour in the EDCA so could you explain more?

The init_QSRC is not being provided to make the non-AP devices "align" with the AP:

1) The move to the NPCA channel is a move to a "new contention domain" - this means that there is no current history regarding the accumulation of attempts and successes for access to this NPCA channel.
2) when arriving at the NPCA channel to perform contention, if the AP begins with an assumption that the only devices that will be contending for the NPCA channel are any of its associated BSS members that have also switched to the NPCA channel, then the AP can make a guess as to how many such devices are present and given this assumption, the AP can establish a "best" set of values for the EDCA parameters that will be used on the NPCA channel

I.e. one must recognize that the EDCA parameters (CWmin, CWmax, AIFSN, TXOPLimit, QSRC) can be set by the AP and that the "correct" or "best" values for these parameters depends on the number of devices that are contending
Clearly, the value of CW depends on the value of QSRC, and the value of QSRC depends on the history of contention - by incrementing QSRC, the contention history is being used to adjust the contention parameters to match the current conditions (see 10.23.2.2 EDCA backoff procedure)

If nothing is done to the EDCA parameters when switching from the primary channel to the NPCA ch, then the current history of the primary channel will be transferred to the NPCA channel, but the main condition on the NPCA channel, that is, the number of contending devices, is likely to be different from the condition on the primary channel, plus, there is no history on the NPCA channel. Because the two channels are different, a default, starting value should be established for the NPCA primary channel.

This is where the guessing on the part of the AP comes in - basically, by providing an init_QSRC for NPCA, the AP can provide a false history that is based on what the AP is guessing is the amount of contention to be expected on the NPCA channel. The default is 0, but the AP can provide a higher value.

 
2. When resuming the parameters of the EDCAF after STA switching back, the AC, whose PPDU has been transmitted with NPCA and the MUEDCA is triggered, should be excluded from the resuming to keep using the MUEDCA to maintain the faireness. This is missing in the current text.  

If the devices never left the primary channel, then to maintain fairness, nothing needs to be done.

If you view the excursion to the NPCA as "extra, bonus, operating time" which is NOT part of the normal contention and access delay on the primary channel (and this should be how it is viewed), then one can argue that whatever happens on the NPCA channel is irrelevant to the primary channel.

As an analogy, if you are paid $2000 for doing work during a normal 40 hour work week, but then in the next week, you worked an additional 10 hours of overtime for an additional $500 pay, then would you expect that you get paid a total of $2500 for that week, or would you say that you have to subtract the $500 in overtime from the regular work week and then, despite your extra working hours, only get a total of $2000?

The NPCA channel access is BONUS time. Nothing that happens there has anything to do with fairness on the main channel.

 
BRs,

Haorui Yang(Rae)

China Mobile
---- Replied Message ----
From Matthew Fischer<matthew.fischer@xxxxxxxxx>
Date 6/10/2025 08:16
To <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject Re: [STDS-802-11-TGBN] 11-25-936r4 PDT NPCA update -- was: Reminder: Technical Submissions Queues

936r4 is now on the server:



Chaoming,

Thanks for the review.
Here is a summary of responses to your comments, for details of changes, please see the newest revision of the document.

1. PPDU-based v TXOP-based condition naming

You correctly point out that some form of TXOP information is possibly being used to determine the NPCA duration in the PPDU-based condition.
Therefore, I have changed PPDU-based to PHY Header based and TXOP based to MAC Header based.

2. might vs may within condition 2

might is the correct term, so no change is needed here
may is the correct term only when an optional action is being described - might is the correct term when describing a possible event, which is the case here

3. request for modification of a long sentence describing the time window for receipt of the third PPDU

I have divided the sentence into a first part and two subbullets

4.  request to allow use of PHY header TXOP fields instead of (or in addition to?) MAC DUR field

This would be a significant change, and I am not certain if there is widespread support for it, so I would recommend a separate straw poll / document for this requested change

5. request to move the OBSS PPDU condition to earlier in the sequence

There is no need to move this requirement - the initial statement of condition 2 is that ALL of the following items must be true, so the order does not matter
However, it is noted that the condition says that at least one of the "received PPDUs", but it is not clear that if one receives only the PHY header of the third PPDU, is that a "received PPDU" so I have added the additional condition "or partially received PPDUs" to allow for identification of the OBSS nature of the TXOP through reception of the OBSS information in the PHY header of the third PPDU

6. use of triple negative

It looks like a double negative to me, as such, I do not think that the language is difficult to parse

And your proposed phrasing is inaccurate:

"its use of triggered UL transmission only is enabled"

There is no process that enables UL triggered UL transmission only.
There is only a process that enables or disables UL transmissions that are not triggered

So I have made no change to this text

7.  prohibiting UHR ELR PPDU transmission during NPCA

You propose removing this restriction

I'm a bit on the fence on this one - there was a significant amount of informal support for the restriction
I do not know how much opposition there is to including it
So I have made no change for now

8. prohibition of the use of DSO with NPCA

You propose removing this restriction

The arguments that I have heard against using DSO with NPCA are much louder and stronger than ELR
I am confident that there is not much support for removal of this restriction
So I have made no change for now

9. you propose allowing groupcast frame transmisions on the NPCA channel with a new condition:

if All the member STAs corresponding to the group addressed frames are operating on the NPCA primary channel

Your argument to support this change is based on the last part of the note of motion 366.
I think that we have different interpretations of that note.
Here is the last part that you are using to justify your proposed change:

the group addressed frame will be buffered and delivered immediately following the next DTIM Beacon, unless explicitly specified otherwise

I believe that the phrase "unless explicitly specified otherwise" is referring to the future time at which the frames will be delivered, and not to the text in the normative part of the motion text which says that the frames shall not be delivered during the NPCA window.

So no change at this time to the PDT for this comment.




On Sun, Jun 8, 2025 at 8:15 PM 罗朝明(Chaoming Luo) <luochaoming@xxxxxxxx> wrote:

Hi Matt,

 

A few comments on 25/936r3 as attached.

 

BR,

Chaoming

发件人: Matthew Fischer <matthew.fischer@xxxxxxxxx>
发送时间: 2025年6月8日 9:04
收件人: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBN] Reminder: Technical Submissions Queues

 

 

Alfred,

 

Please update the revision for 11-25-0936 to r3:

 

 

Thank you.

 

Matthew Fischer (Broadcom)

 

On Sat, Jun 7, 2025 at 5:18 PM Matthew Fischer <matthew.fischer@xxxxxxxxx> wrote:

 

Alfred,

 

Please update the revision for 11-25-0936 to r2:

 

 

Thank you.

 

 

 

On Sat, Jun 7, 2025 at 9:33 AM Kiseon Ryu <kiseon.ryu@xxxxxxxxxxxxxx> wrote:

Hi Alfred,

 

Please keep the following contributions in the TGbn MAC queue and update the link to the documents.

 

2025

873

0

TGbn

P-EDCA Discussion

Kiseon Ryu (WILUS)

07-Jun-2025 

Download

2025

874

0

TGbn

UHR BSS Parameter Update

Kiseon Ryu (WILUS)

07-Jun-2025 

Download

 

Thanks,

Kiseon

 

 

 

From: Alfred Asterjadhi <asterjadhi@xxxxxxxxx>
Date: Wednesday, June 4, 2025 at 9:16 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: [STDS-802-11-TGBN] Reminder: Technical Submissions Queues

Hello all,

 

Please consider this as a gentle reminder regarding the announcement made during the Joint telco of last week:

 

·         Authors of technical submissions are invited to review the technical submissions queues and are requested to:

§  Send a request for removal of the submission from the queue, if the concepts in the submission are planned to (or are) being handled via a CR/PDT.

§  Upload the contribution and send an e-mail to the TGbn chair to update the link to the contribution by the end of this week (Sunday, June 7th, 2025). Submissions that have not been uploaded by then and have not been requested to update the link to the document, will be removed from the technical submission queue. 

 

Regards,


Alfred

--

Alfred Asterjadhi, PhD

IEEE802.11 TGbe/TGbn Chair,

Qualcomm Technologies Inc.

Cell #:    +1 858 263 9445

Office #: +1 858 658 5302

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


 

--

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

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

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

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