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


Patrice,

The NPCA mechanism allows two options:

a) on the NPCA channel, normal EDCA access is allowed for all devices operating on the NPCA channel
b) on the NPCA channel, normal EDCA access is allowed for the AP only, and non-AP devices are only allowed to be triggered by the AP

My understanding is that you are questioning the need for b).

First, as long as a) is present, you have the mode that you are interested in (assuming you want NPCA at all), so your questioning of mode b) is possibly because you do not want mode b), but because mode b) is optional, you do not have to operate using mode b). Now, of course, mode b) can be dedicated by the AP, so if you have a non-AP perspective, then you might argue that if the AP that you are associated with selects mode b), then it is NOT optional for you.
This is an understandable position.

So, why is there a mode b)? And why would you be forced by the AP to use it?

mode b) exists because many participants have expressed a concern that each individual OBSS event is not equally detectable by all members of my BSS.
therefore, it is quite possible that some subset of my BSS devices switch from the primary channel to the NPCA channel while others do not switch
because of this mismatch, the effectiveness of NPCA might be questioned - i.e. a non-AP STA moves to NPCA and attempts to contact the AP, but the AP is still on the primary channel or vice versa
A primary rationale is that if the AP does not make the switch, then there is no value to the NPCA switch because all exchanges should include the AP
Additionally, even if the AP made the switch, for the DL direction, the AP does not know which STAs made the switch.

So, mode b) is offered as a means of attempting to provide a higher probability of success for NPCA operation
In particular, it allows what is discerned to be the most efficient access:
- the AP starts with a poll to determine which STAs did make the switch and then performs whatever triggered UL it deems best based on that poll result

Others have cited additional rationales:
- since the NPCA operation is bonus time, it is best to let the AP decide how to use it because it has the broadest perspective on BSS traffic and demands
- because the total time for NPCA operation is limited by the OBSS TXOP on the primary, it is inefficient to waste that time performing contention on the NPCA channel
- the AP might have the best idea of which of its associated STAs might have made the jump (e.g. based on stored information about relative locations of its STAs and OBSS STAs)

Note also that if triggered only mode is used and after a timeout occurs, no trigger is heard, then any non-AP that made the switch can move back to the primary and sleep for the rest of the OBSS TXOP
[ note that the switch back conditions have not yet been agreed to and therefore, you will not find this in the current PDT ]



On Wed, Jun 11, 2025 at 2:44 AM NEZOU Patrice <Patrice.Nezou@xxxxxxxxxxxx> wrote:

Hi Matthew,

 

Thanks for this new revision.

 

I have some remarks related to the resolution of 1809 about the MU EDCA Timer usage. You notified that the AIFSN[AC] is set to 0 for all ACs on the NPCA primary channel. It means that EDCA is disabled in that case. Only triggered transmissions can be initiated.

 

What is the interest to define “a mode of operation in which untriggered UL transmissions on the NPCA primary channel by NPCA non-AP STAs is not permitted” (11bn draft 0.3 p.150 l.17) ?

 

Can you clarify that point ?

 

Regards

 

Patrice

 

From: Matthew Fischer <matthew.fischer@xxxxxxxxx>
Sent: mardi 10 juin 2025 02:16
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] 11-25-936r4 PDT NPCA update -- was: Reminder: Technical Submissions Queues

 

BEWARE: This email originated outside of our organization. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe.
Please report all suspicious emails to the ISS department as an attachment.

 

 

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



--
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