Re: [STDS-802-11-TGBN] 答复: [STDS-802-11-TGBN] PDT-MAC-NPCA

[Matthew Fischer <matthew.fischer@xxxxxxxxx>]

Gaurang,

It doesn't look very technical to me, as it says TBD.

The older versions said TBD and the newer ones say TBD.

On Mon, Jan 13, 2025 at 9:33 PM Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx> wrote:

Hi Matt,

This is a technical change, and I would prefer not to make such modifications without proper discussions, especially since the text has been stable for a long time. Given that there is no explicit motion, I suggest reverting it back to TBD.

I appreciate your excellent work on the PDT. For these last-minute changes, however, I would request that you highlight the modifications to make them easier to identify. For instance, I couldn't locate the change made in r22.

Thanks,

Gaurang

---

From: Matthew Fischer <matthew.fischer@xxxxxxxxx>
Sent: Monday, January 13, 2025 9:19 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBN] 答复: [STDS-802-11-TGBN] PDT-MAC-NPCA

 

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

1762r22 is on the server:

https://mentor.ieee.org/802.11/dcn/24/11-24-1762-22-00bn-pdt-mac-npca.docx

r22 includes a statement that the non-AP STA can only enable NPCA mode if the associated AP supports it

Gaurang,

Morteza and I had an offline discussion while I was mediating with a few other parties.

Morteza private agreed to the change that you see in r21.

On Mon, Jan 13, 2025 at 9:14 PM Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx> wrote:

Hi Matt, 

I do not follow the rationale for the latest change. I wasn't involved in any discussions leading to this change. I would prefer to revert to the text from the earlier revisions. The most recent email I found on this topic is from Morteza, who suggested keeping it TBD. This seems reasonable to me, as the group hasn't discussed this matter and there is no SP/motion on it.

Thanks,

Gaurang

---

From: Matthew Fischer <matthew.fischer@xxxxxxxxx>
Sent: Monday, January 13, 2025 8:40 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBN] 答复: [STDS-802-11-TGBN] PDT-MAC-NPCA

 

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

1762r21 is now available:

https://mentor.ieee.org/802.11/dcn/24/11-24-1762-21-00bn-pdt-mac-npca.docx

This revision includes a modification to case a) for beginning NPCA operation based on the reception of an OBSS PPDU that is not part of a control frame sequence

The modification is to restore the TXOP_DURATION as a possible indicator of the duration of the OBSS activity, but with a condition that the AP directs whether this value will be used or not

This is based on offline discussions and is a modest modification and a middle ground between earlier revisions of the document and the more recent revisions.

On Mon, Jan 13, 2025 at 6:07 PM Matthew Fischer <matthew.fischer@xxxxxxxxx> wrote:

Morteza,

Thank you for clarifying.

1.

NPCA non-AP STA enablement

As you now clearly explicitly state that you are not looking for dynamic enable/disable for the non-AP STA, then I think that no changes are needed.

You are saying that there should be a qualifier for the non-AP STA behavioral statements to clarify that the STA has enabled NPCA.

But if the STA supports NPCA operation, then it communicated this in the NPCA Information field within an ASSOC REQ frame.

Since you are not asking for dynamic NPCA, then that STA NPCA status is static for the duration of the association.

As to the behavioral sentences, section 37.10 starts with a definition of NPCA non-AP STA which has indicated that it supports NPCA.

The remainder of the subclause that describes NPCA STA behavior, then, through the use of that term, automatically only applies to a STA that has indicated its support for NPCA.

So I believe that no additional conditions need to be added to any statements within the subclause.

2.

Request to add the NPCA operation duration value of PPDU length + TXOP_DURATION

While this feels like a significant change, I also do not see anything in any motion that prevents this interpretation, see M133 and M144

We can probably raise this issue during the presentation

Gwangho,

I understand now that it appears that you are mentioning the OBSS channel allocation.

There might need to be some fine tuning of the determination of the description of the events that allow NPCA operation, in that during the examination of those events, the determination of the channel occupancy needs to have more detail.

My feeling is that the current text indicates that basically, the OBSS activity lies within the primary 80 or primary 160 MHz of the main BSS BW, and whether it occupies the entirety of that primary 80 or 160 is immaterial.

I.e. if only the primary 20 MHz portion of the primary 80 or 160 is occupied by the OBSS, then the switch for NPCA is still and always only to the upper 80 or upper 160 MHz portion of the main BSS BW.

But the text might not exactly convey that

On Mon, Jan 13, 2025 at 5:41 PM 이광호 <gwangho.lee@xxxxxxxxxx> wrote:

Thanks for the response!

 

What I mentioned for “the channel allocations” is highlighted below:

 

An NPCA STA may switch to the NPCA primary channel for NPCA operation if the value of the most recently received or transmitted NPCA Operation Information Present field corresponding to the BSS of which it is a member is equal to 1 and either condition a) or b) is met: M11

a)      the STA received a PPDU and/or received a PHY-RXSTART.indication primitive for an HE/EHT/UHR PPDU on the BSS primary channel and all of the following conditions are true: M144

a.      …

b.      …

c.      the 20/40/80/160 MHz channel occupied by the PPDU is identified by the STA, based on the Bandwidth field in the PHY preamble of the PPDU and the channel allocations in the corresponding band, and the channel occupied by the PPDU does not overlap with the NPCA primary channel M127

d.      TBD conditions

b)      the STA received a PPDU containing a Control frame and a PPDU containing an initial response frame of a Control frame exchange on the BSS primary channel and all of the following conditions apply: M144 M164

a.      …

b.      …

c.      the 20/40/80/160 MHz channel occupied by the received PPDU(s), identified by the STA 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), does not overlap with the NPCA primary channel M127

                                                  i.     …

                                                 ii.     …

d.      TBD conditions

 

What I meant by “the channel allocations” is the channel configuration of OBSS. However, it is clear now from your response that the channel allocations are the current BSS's channel allocation including NPCA primary channel allocation. If this is the case, I think current NPCA operation has limitations to check whether the received PPDUs from OBSS overlap with NPCS primary channel. Since NPCA STAs are not aware of the channel allocations of the OBSS, the bandwidth information of the received PPDU(s) is not enough to make a decision whether the NPCA primary channel is occupied by the received PPDU(s). Because NPCA STAs cannot be assumed to know the channel allocations (channel configuration) of the OBSS, NPCA STAs cannot make a decision whether the NPCA primary is occupied by the received PPDUs without physically scanning the channels. I think physical scanning together with BW information checks need to be described in the text.

 

 

Best regard,

Gwangho

2025년 1월 14일 (화) 오전 9:24, Morteza Mehrnoush <morteza.80211@xxxxxxxxx>님이 작성:

Hi Matt,

Thanks for the response. 

Re #1: I don't want to add dynamic switching to the STA side. For a feature like EMLSR, a non-AP MLD needs to enable EMLSR mode (non-AP STA sends a EML OMN frame as a request and receives an EML OMN frame as a response from AP) and then it operates in EMLSR mode. However, there is no NPCA enablement defined for the non-AP STA.

I am not suggesting to define the NPCA enablement/disablement procedure at this time. All I am saying is that in addition to "NPCA Operation Information Present field set to 1" as a condition to switch to NPCA primary channel, we need to have additional condition for non-AP STA like this "if non-AP STA enabled the NPCA mode" to switch to NPCA primary channel. How exactly the NPCA enablement happens by non-AP STA is TBD and can be addressed later.

Re#2: My intention is to have the two possibilities "LSIG or LSIG+TXOP DURATION" open for now. Below is my suggested text.

a.      the duration of the PPDU, (determined by the MAC in a manner TBD, but necessarily involving some of the parameters of the RXVECTOR associated with the received PPDU) , or duration of the PPDU plus the RXVECTOR parameter TXOP_DURATION, is greater than the value indicated in the most recently received or transmitted NPCA Minimum Duration Threshold field corresponding to the BSS of which it is a member M133

                                               i.     whether duration of the PPDU or duration of the PPDU plus the RXVECTOR parameter TXOP_DURATION of the PPDU is considered for this comparison is TBD

Sorry, I am attending remotely this time, so can't meet in person. 

Thanks,

Morteza

On Sun, Jan 12, 2025 at 11:13 PM Matthew Fischer <matthew.fischer@xxxxxxxxx> wrote:

Morteza,

1.

I believe that you are requesting a significant change which I feel cannot be made without full discussion and a vote.

I.e. add dynamic capability of NPCA for STA

Additionally, I am not exactly certain of everything that you are saying. I think it might be this:

a. you would like to add dynamic capability to the STA side

b. you argue that because the AP appears to have dynamic capability in the text, that such an extension beyond the motion text should be justification for your proposal to add dynamic NPCA for the STA

Apologies if I am misreading this.

I do not think that the statement that you cite was actually meant to give the AP dynamic capability, but rather, to require the STA to ensure that NPCA is enabled in the BSS before it performs an NPCA switch.

But I can see that it looks like dynamic capability.

If that statement is removed, then there is no condition for the STA to perform NPCA.

If you want to prevent AP dynamic NPCA operation, then you could propose adding a prohibition.

I believe that is in line with previous feature restrictions of this sort.

If you want to propose STA dynamic capability, then I believe that needs a presentation and a vote.

Note that there is already a separate discussion regarding changing the AP enable/disable activity.

So any change in this regard really needs broader discussion and a vote.

I invite you to make a very specific proposal before the larger group.

2.

using LSIG or LSIG+TXOP DURATION are both possibilities

I believe that the current text allows this. I do not understand what change you would like.

Please provide an exact reference with a proposed change.

Maybe you are thinking that "OBSS activity" is not defined by motion 133, yet the text seems to have defined it.

This is because motion 144 has defined it.

Again, apologies if I am misunderstanding the comments.

If this is the case, then either please provide an exact proposed text change or just find me to chat.

On Sun, Jan 12, 2025 at 10:29 PM Matthew Fischer <matthew.fischer@xxxxxxxxx> wrote:

Vishnu,

Regarding NPCA Minimum Duration Threshold

First, the simple response to part of your email:

I feel that there is no need for a TBD. There is already plenty of language that says that there will be a comparison made. There are already statements that some unspecified parameters might be used.

Response to the technical part:

I do agree that the description of the comparison operation between the above parameter and some quantity obtained from the OBSS activity is not accurately specified in the current revision.

I appreciate the suggested update to the text, but I believe that your suggestion is also inaccurate.

I'd rather work out the correct, exact formulation before making a change than to change one inaccurate description for another inaccurate description.

Feel free to provide further exchange to attempt to reach this point. I will continue that attempt within this email.

In particular, your solution is missing the switch delay time which feeds into the NPCA HE switch time and the NPCA NHT switch time.

Because the NPCA operation does not begin until those points in time, the threshold value must be compared to the difference between these points in time and the remaining duration value.

I believe that the correct description must reference these parameters, and not the PHY Header Duration.

Note also, that, assuming that PHY header information must always be used in order to determine that it is ok to switch to NPCA, the switch time will necessarily always be greater than PHY header time

For example:

and the duration of the PPDU is greater than or equal to the threshold plus the NPCA HE switch time

Note that in the current document NPCA HE switch time is not accurately specified yet, either, and in fact, that item has a TBD in the text.

Possible definition of NPCA HE switch time:

equal to the amount of time, measured from the start of the received PPDU, that has elapsed, when the receiving STA is ready to switch to the NPCA channel

For the case when a DUR field value is extracted from an ICF or ICR, because the DUR value expresses a value of time with a zero reference at the end of the ICF or ICR, the threshold comparison should be related to the end of the relevant frame, again, with an adjustment for the switch delay.

For example:

and the DUR value in the ICF or ICR is greater than or equal to the threshold plus the NPCA NHT switch time

and NPCA NHT switch time:

equal to the amount of time, measured from the start of the received control frame, that has elapsed, when the receiving STA is ready to switch to the NPCA channel

And we're not done here, because that switch time is different for every implementation and perhaps for different frames with different formats and encodings.

So the AP has to choose the longest time of all of the possibilities of all associated STAs and then advertise that.

I will add a NOTES section at the bottom of the document to keep track of these ideas.

On Sun, Jan 12, 2025 at 8:02 PM Morteza Mehrnoush <morteza.80211@xxxxxxxxx> wrote:

Hi Matt,

I have two comments on r19.

1) In this part of text, the NPCA is described to be performed by non-AP STA while it's not mentioned if the non-AP STA needs to enable the mode. Similar to other features, non-AP STA should be able to enable/disable the mode. My suggestion is that for non-AP STA it needs to mention if the non-AP STA enables the mode, then it can follow the NPCA operation followed by below text. 

BTW, M11 is a very general SP on NPCA feature, so it doesn't describe the behavior mentioned in this part of text.  

An NPCA STA may switch to the NPCA primary channel for NPCA operation if the value of the most recently received or transmittedNPCA Operation Information Present field from its associated APcorresponding to the BSS of which it is a member is equal to 1 if and either condition a) or b) is met: M11

2) In this part of text, both using the "PPDU duration (based on L-SIG)" or "PPDU duration (based on L-SIG) plus TXOP_DURATION" for comparison with "NPCA Minimum Duration Threshold" is a possibility and should be TBD. 

In M133, the highlighted text doesn't describe the behavior, and it needs to be decided later. "M133: • If the duration of the OBSS activity that makes the primary channel busy is smaller than the duration threshold, the NPCA STAs (AP and non-AP) do not switch to the NPCA primary channel".

a.      the duration of the received PPDU, (determined by the MAC in a manner TBD, but necessarily involving some of the parameters of the RXVECTOR associated with the received PPDU) determined by the Length and Rate fields of the L-SIG field of the PPDU, plus the TXOP duration, indicated in the TXOP field of the HE-SIG-A/U-SIG field, is greater than the NPCAvalue indicated in the most recently received or transmitted NPCA Minimum Duration Threshold field corresponding to the BSS of which it is a memberadvertised by its associated AP M133

                                               i.     whether the RXVECTOR parameter TXOP_DURATION of the PPDU is considered for this comparison is TBD

Thanks,

Morteza

On Sun, Jan 12, 2025 at 6:40 PM Vishnu Ratnam <vishnu.r@xxxxxxxxxxx> wrote:

Hi Matt,

 

One thing I wanted to highlight regarding the NPCA draft is that the motion (copied below) is a little vague on how the NPCA Minimum Duration Threshold should be applied.

 

Motion text: An AP that enables NPCA announces the minimum duration threshold of the BSS primary channel busyness because of OBSS activity for switching to NPCA primary channel

• If the duration of the OBSS activity that makes the primary channel busy is smaller than the duration threshold, the NPCA STAs (AP and non-AP) do not switch to the NPCA primary channel.

 

The current PDT text states that:

• For HE+ PPDUs, condition for the switch is set to “PPDU duration >= NPCA Minimum Duration Threshold”.
• For ICF frames, the condition for switch is set to “the TXOP duration >= NPCA Minimum Duration Threshold field”

 

I believe that the correct conditions should be that:

• For HE+ PPDUs, the condition for the switch is “PPDU duration – PHY header duration >= NPCA Minimum Duration Threshold”
• For ICF frames, the condition for switch is “the TXOP duration >= NPCA Minimum Duration Threshold field” if the ICF is not RTS. For the case of RTS, to ensure a NAV reset is not performed, we may need to wait longer, so the condition may be slightly more complex.

 

Or more generally: “the residual PPDU duration (for HE+ PPDUs) or TXOP duration (for ICF frames) as measured from the NPCA switch time is >= the NPCA Minimum Duration Threshold”.  The NPCA switch time is the time of triggering the NPCA switch, as determined from the type of observed inter-BSS activity (HE switch time or NHT switch time or RTS switch time).

 

Could you kindly share your view on the above? I would prefer if we can add a [TBD] annotation on the sentences where the application of NPCA Minimum Duration Threshold is described. Alternatively, I hope we can work on clarifying the exact conditions later through amendments.

 

Regards,

Vishnu

 

 

From: Matthew Fischer <matthew.fischer@xxxxxxxxx>
Sent: Sunday, January 12, 2025 8:29 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] 答复: [STDS-802-11-TGBN] PDT-MAC-NPCA

 

Caution: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

 

 

1762r19 now available:

 

https://mentor.ieee.org/802.11/dcn/24/11-24-1762-19-00bn-pdt-mac-npca.docx

 

Note that the previously discussed revision was 1762r17.

 

r18 - contains change that removes text that says that the "AP may enable NPCA operation by setting a bit"

After additional discussion with members, citing, for example, the case of a PS NPCA STA, the duration of the delay of communication of a change in mode can be extensive in time value.

The group should expect a submission or contribution that can be used to introduce text describing a delayed/slow transition to/from NPCA in the future.

 

r19 - adds an author

 

 

 

On Sun, Jan 12, 2025 at 12:58 AM Matthew Fischer <matthew.fischer@xxxxxxxxx> wrote:

 

1762r17 now available on the server:

 

https://mentor.ieee.org/802.11/dcn/24/11-24-1762-17-00bn-pdt-mac-npca.docx

 

Gaurang,

 

I do agree that the motions do not explicitly state that the AP enables or disables NPCA, but if this is not the case, then who does enable/disable NPCA?

Certainly not some random non-AP STA. So I think that it is reasonable to have included a simple on/off switch by the AP in the current text.

 

Supposing that the group agrees that some less "sudden" enablement of NPCA is needed, I do not see how adoption of a change to accommodate for example, a mechanism along the lines of channel switch announcement that spans several beacons for use by NPCA would be prevented by the existing text, which can be easily modified when some alternative "soft mode switch" text is available and agreed upon to replace it.

 

Additionally, if such a change were agreed upon, it would affect more than just the cited paragraph, as additional changes would be needed in the frame formats.

 

As to the need for such a change, I would like to hear the arguments and see the group agreeing to it.

I do not understand why a "sudden change" in the mode would cause any problems.

The current situation is likely to be that there are many STAs associated with an AP and maybe only a few can perform NPCA.

So if there are STAs that have a slow enablement, then it just means that the STAs that can perform NPCA rises slowly.

A "failure" would be that an AP might attempt to TX to a slow STA that is not yet ready to switch.

There would be a lost transmission. We have TX failures frequently. When NPCA is disabled, all of that available secondary BW is lost already.

So in this case, you've just lost it for a bit longer until everyone switches to NPCA operation. Not a problem.

I still do not understand why a STA would need a long time (100 ms??) to switch on NPCA anyway..

If the delay is less than 5 ms, then I see virtually no problem.

 

Junbin,

 

generally followed your suggestions

 

 

Liangxiao,

 

Please note:

Any comment that was in your document that is not referenced in the list below was generally accepted:

 

1.

NPCA information field AP vs non-AP STA

we have an open item on determining exactly what parameters are sent in UL vs DL direction and in what frames, only when there is a group consensus on how this is to be resolved should we bother to make modifications here

 

2. 

channel number vs the number of the channel

"channel number" is a term that already exists in the baseline, so it is better to keep using this term

the sentence is a bit complex, but quite parsable

 

3. 

OBSS activity vs NAV

 

the language used so far in the document is very careful to avoid explicitly using the term NAV because:

a. for PPDU cases, the NAV in the MAC header can only be extracted sometimes (based on MCS and signal level) and even then, can only be definitively verified at the end of the MPDU where the FCS occurs, meaning that it is either low quality or too late to be used

b. for PPDU cases, one might, depending on the PPDU format, be able to extract NAV information from a PHY header, but this information has a high quantization error and also has an upper bound that might render the information inaccurate and is sometimes absent and some people have objected to the possibility of using NAV even if you are able to get accurate information because the initial NAV might represent only an upper bound estimate of the upcoming TXOP which might be either shortened or lengthened during the TXOP, and if NPCA is being performed during that initial value of NAV, then any subsequent changes to the NAV by the original OBSS TXOP holder will be invisible, potentially causing issues

 

c. the more exact meaning of the field is clarified with the much more complex behavioral description within 37.10

 

4.

received from or transmitted to 

the statement needs to be applicable to both AP and non-AP STA, since both will enter NPCA operation

because it is the AP that sets the parameter with a transmission, the reception case applies only to the non-AP STA and the transmission case applies only to the AP

hence the current wording

 

 

Matthew Fischer, Broadcom

 

 

On Sat, Jan 11, 2025 at 11:55 PM Liangxiao Xin <xlx20190808@xxxxxxxxx> wrote:

Hi Matt,

 

Thanks for preparing the document. Please see my comments in the attached file. 

 

Regards,

Liangxiao

 

On Sun, Jan 12, 2025 at 3:24 PM Gaurang Naik <0000305a2f8ce933-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:

Hi Matt,

 I have a comment on the following text in r16. 

I understand the text to mean that an AP can set the bit to 1 in one Beacon and then to 0 in the next, abruptly disabling the mode. I've had offline discussions with members about the need for a smoother transition method for enabling/disabling and potentially to update other NPCA-related parameters.

None of the current motions address how an AP enables/disables NPCA mode. Therefore, I propose deleting the first two sentences of the paragraph above (highlighted). If necessary, we can add a note such as: "NOTE - The method by which an AP enables/disables NPCA mode or updates NPCA-related parameters is TBD."

 Thanks,

Gaurang

---

From: Matthew Fischer <matthew.fischer@xxxxxxxxx>
Sent: Wednesday, January 8, 2025 8:05 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBN] 答复: [STDS-802-11-TGBN] PDT-MAC-NPCA

 

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

 

1762r16 now available:

 

https://mentor.ieee.org/802.11/dcn/24/11-24-1762-16-00bn-pdt-mac-npca.docx

 

 

Mickael,

 

1.

The double "to" in the NPCA Primary Channel field description is not a typo - it is correct syntax, albeit possibly confusing.

The situation arises because of the adjacent positioning of two verbs:

switch to

to perform

There are a couple of alternatives, but I am not certain that they are better:

 

0. choice 0, existing language:

The NPCA Primary Channel field indicates the channel number of a channel within the BSS bandwidth that corresponds to the channel that the NPCA AP and its associated NPCA non-AP STAs switch to to perform NPCA operation

1. choice 1

The NPCA Primary Channel field indicates the channel number of a channel within the BSS bandwidth that corresponds to the channel to which the NPCA AP and its associated NPCA non-AP STAs switch to perform NPCA operation

 

2. choice 2

The NPCA Primary Channel field indicates the channel number of a channel within the BSS bandwidth that corresponds to the channel that the NPCA AP and its associated NPCA non-AP STAs switch to in order to perform NPCA operation

 

3. choice 3, combining 1 and 2

The NPCA Primary Channel field indicates the channel number of a channel within the BSS bandwidth that corresponds to the channel to which the NPCA AP and its associated NPCA non-AP STAs switch in order to perform NPCA operation

 

I have not changed the existing language at this point.

 

 

2.

Regarding the NPCA Supported field

As you note, there has been discussion as follows:

The existing document uses the presence of NPCA parameters transmitted by the AP to indicate that the AP supports and has enabled NPCA within the BSS

Because of this, the use of an individual NPCA Supported bit by the AP seems redundant but to some people, it seems odd that the AP does not set the bit.

In order to reduce confusion, you suggest adding language for the AP that indicates that the bit is reserved.

I am actually ok with either solution - i.e. marking the bit as reserved for the AP or allowing the AP to set it.

I feel that we should see a few more opinions before I change anything.

After the initial discussion on the reflector, the existing situation has stood until your comment.

 

3.

removed the leftover reference to the previously deleted item c) TBD

 

 

4.

Not from you, but modified some other editorial change - regarding the untriggered UL operation - trying to use language that is more formal

 

 

 

On Wed, Jan 8, 2025 at 1:16 AM LORGEOUX Mickael <Mickael.Lorgeoux@xxxxxxxxxxxx> wrote:

Hi Matthew and all,

 

Happy new year to everyone !

 

Thanks Matthew for your work on this PDT NPCA document.

 

My review on the revision r15 is here attached :

-Two comments on page 12 and 14 highlight some typos.

-One comment on page 13 is related to NPCA support indication.

 

Best regards

Mikael

 

From: Matthew Fischer <matthew.fischer@xxxxxxxxx>
Sent: mardi 7 janvier 2025 22:46
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] 答复: [STDS-802-11-TGBN] PDT-MAC-NPCA

 

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.

 

 

r15 now on the server:

 

https://mentor.ieee.org/802.11/dcn/24/11-24-1762-15-00bn-pdt-mac-npca.docx

 

 

Laurent,

 

1. modified text as requested, as there is no mention of frames in the motion, even though I know of no magic technique outside of a transmitted frame that can be used to communicate a mode change for the BSS from an AP to any of its associated non-AP STAs. However, see my statement on the use of "TBD" in my item 2 comments. 

 

2. 

M144 does indicate that these two items are used to switch to NPCA but the motion also includes the phrase "NOTE: other conditions TBD", echoing M11!

 

Now, one could read the M144 "other conditions TBD" as corresponding to "other conditions" found in M11, which seems like a very natural reading, or one could regard the M144 reference as indicating that there will be other conditions that provide more details for the first two items of M144.

 

The motion is poorly worded, in that it does not state which case is correct and I can see that either interpretation could be correct.

 

In any case, I am happy to remove item c) since anything that is not currently present in any draft text is always implicitly TBD and having a TBD in the draft is not really much different from having nothing in the text.

In either case, a motion is needed to add new text to a draft and putting such text into a draft does not first require an existing TBD that would be replaced.

 

If anyone really has any item c) TBD condition that they want to replace item c) TBD, then they can certainly propose it during the meeting and the success or failure of that proposal is unaffected by the presence or absence of item c) TBD.

 

Now, this does leave a few other TBDs in the document - I did not touch them because I really do not care either way.

 

 

On Tue, Jan 7, 2025 at 11:57 AM Cariou, Laurent <laurent.cariou@xxxxxxxxx> wrote:

Hi Matt,

1. Then please follow the text that was agreed.

And replace the sentence by the following: An NPCA AP may enable or disable a mode of operation in NPCA where the NPCA non-AP does not use untriggered UL transmissions on the NPCA primary channel.

 

2. We indeed have that initial motion. However, we also passed motion 144 that determines the event that trigger the switch to the NPCA PC and those are the 2 items a) and b) in your doc. That means that other events are no longer there. I would remove bullet c) unless someone insists on keeping that.

 

Thanks

Laurent

 

From: Matthew Fischer <matthew.fischer@xxxxxxxxx>
Sent: Tuesday, January 7, 2025 7:53 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] 答复: [STDS-802-11-TGBN] PDT-MAC-NPCA

 

 

No update to doc 1762r14

I.e. 1762r14 remains the current version.

 

Responses to comments from Laurent,

 

1.

 

Laurent suggests deleting the following line of text, with the rationale that this text is not yet agreed to:

 

An NPCA AP may enable or disable the use of untriggered UL transmissions on the NPCA primary channel, by transmitting TBD frames

 

Yet, this text is nearly an identical match to the text of the passed motion 129.

 

Here is M129:

 

•       TGbn defines a mode of operation in NPCA where the NPCA non-AP does not use untriggered UL transmissions on the NPCA primary channel

•       This mode can be enabled/disabled by the AP

•       Whether the mode is for all associated non-APs or per non-AP is TBD

•       TBD whether MU EDCA parameters mechanism is used for this or not

[Motion #129, [1]]

 

2.

 

Laurent suggests deleting condition c) in the "conditions to initiate NPCA operation"

 

For review:

condition a) is primary channel BUSY due to reception of a OBSS PPDU that is not a control frame sequence

condition b) is primary channel BUSY due to reception of an OBSS PPDU that is a control frame sequence

condition c) is "primary channel BUSY due to TBD additional conditions"

 

again, this condition c) is based on a passed motion, M11:

 

•       TGbn defines a mode of operation that enables a STA to access the secondary channel while the primary channel is known to be busy due to OBSS traffic or other TBD conditions.

•       The mode of operation shall not assume that the STA is capable to detect or decode a frame and obtain NAV information of the secondary channel concurrently with the primary channel.

•       A BSS shall only have a single NPCA primary channel (name TBD) on which the STA contends while the primary channel of the BSS is known to be busy due to OBSS traffic or other TBD conditions.

[Motion #11, [1]]

 

 

The passed motion yields the text of item c) ni 1762r14:

 

c) The primary channel is known to be busy and TBD conditions

 

This text is nearly a match for the passed motion text.

 

 

 

On Tue, Jan 7, 2025 at 5:43 AM Cariou, Laurent <laurent.cariou@xxxxxxxxx> wrote:

Hi Matt,

Some comments/modifications attached.

Thanks
Laurent

 

From: Matthew Fischer <matthew.fischer@xxxxxxxxx>
Sent: Friday, January 3, 2025 11:16 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] 答复: [STDS-802-11-TGBN] PDT-MAC-NPCA

 

 

Junbin,

 

In reviewing the motions that have passed, you can see that no frames have been specified, so the existing text is already a bit speculative, but it matches how things have been done for almost every amendment of 802.11, i.e. inclusion of CAP and OP IEs and placing those IEs within Assoc, etc frames.

 

The Probe Req and Probe Resp frames are similar in history.

 

Because of the speculative nature of the existing text (i.e. the inclusion of the information in the CAP and OP elements and then those within the frames), all of that text is effectively speculative, and hence, keeping a TBD in the text is a reminder that the exact finalized set of fields, elements and frames is yet to be agreed upon. So I would rather not remove the TBD.

 

As for the suggested modified text that you include, I believe that the existing language is almost identical to what you suggest.

I do not see any real differences except that you are adding the name of the element in which the fields are found, but this is unnecessary, as these fields only exist within those elements.

Interestingly, your AP text mentions the fields and the elements and the non-AP text only includes the fields.

 

Maybe there is a better approach, but now that we are so close to the JAN meeting, I'll wait to see what motions are passed that might clarify this and other issues within the PDT.

Thanks.

 

 

On Thu, Jan 2, 2025 at 7:35 PM 陈俊斌 <00003c9288e54ba2-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:

Hi, Matthew:

 

Thanks for your contribution, and I have a few clarification questions on the PDT here:

 

In 37.10 of the PDT, there is:

An NPCA AP that has enabled NPCA operation shall include the NPCA Operation Information field in its UHR Operation element and indicate its NPCA switching delay and NPCA switch back delay respectively in the NPCA Switching Delay field and NPCA Switch Back Delay fields of the TBD frames. M124

 

I am a little bit confused about the “TBD frames“ here.

 

In 9.4.2.aaa and 9.4.2.aab of the PDT, the NPCA Switching Delay field and the NPCA Switching Back Delay field are included in the UHR Cap IE and UHR OP IE, which are included in the frames as listed in 9.3.3.x of this PDT;

 

Is here the aforementioned “TBD frame” suggests that, for an NPCA AP, the NPCA Switching Delay field and the NPCA Switching Back Delay field might be included in some field other than the UHR Cap IE and UHR OP IE? Or, the UHR Cap IE and /or UHR OP IE might be carried in some frames that is not listed in 9.3.3.x of this PDT?

 

As recorded in the open issue 1 and 7, I agree that the NPCA op info might appear in some frame which a non-AP STA transmits;

But since we are talking about the NPCA AP in the cited paragraph here, I am thinking that maybe we can make the aforementioned “TBD frames” more clear here, and leave the open issue about the indication of the NPCA parameters of non-AP STA in another paragraph?

 

For example, how about the following texts:

An NPCA AP that has enabled NPCA operation shall indicate its NPCA Switching Delay and NPCA Switch Back Delay respectively in the NPCA Switching Delay field and NPCA Switch Back Delay field, by including the NPCA Operation Information field in the UHR Operation element. M124

 

A non-AP NPCA STA that has enabled NPCA operation shall indicate its NPCA Switching Delay and NPCA Switch Back Delay respectively in the NPCA Switching Delay field and NPCA Switch Back Delay field via TBD frames. M124

 

 

Best Regards!

 

---------------------

Junbin Chen 陈俊斌

 

 

发件人: Matthew Fischer <matthew.fischer@xxxxxxxxx>
发送时间: 2025年1月3日, 星期五 上午 03:21
收件人: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBN] PDT-MAC-NPCA

 

 

1762r14 is available on the server:

 

https://mentor.ieee.org/802.11/dcn/24/11-24-1762-14-00bn-pdt-mac-npca.docx

 

 

Gaurang,

 

1.

Re the first paragraph of 37.x (which has been changed to 37.10 NPCA

 

Whether the last sentence should begin with an NPCA STA or a non-AP NPCA STA:

 

The current consensus is that the AP and non-AP have different methods for indicating their support for NPCA.

 

2.

your comment on whether or not NPCA information would be carried in beacons being an unsettled issue is not relevant to the cited paragraph

the cited paragraph only indicates that a bit should be set - it does not indicate which frame the bit is carried in

 

3.

other comments generally accepted

 

 

 

 

 

On Thu, Dec 19, 2024 at 9:59 PM Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx> wrote:

Hi Matt,

 

Thanks for your work on this. I have a few comments in the attached.

 

Thanks,

Gaurang

 

---

From: Matthew Fischer <matthew.fischer@xxxxxxxxx>
Sent: Thursday, December 19, 2024 9:49 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBN] PDT-MAC-NPCA

 

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

 

New and Improved! r13:

 

https://mentor.ieee.org/802.11/dcn/24/11-24-1762-13-00bn-pdt-mac-npca.docx

 

Re MIB (Li Quan):

 

I agree that having a default value does not make sense.

An item for TGmf is that in at least 23.x and 27.x there are PHY MIB tables with many XxxxOptionImplemented variables with default values.

 

Re (Haorui):

 

In 37.x, within 1762r13, removed redundant phrase "and the channel occupied by the received PPDU(s)"

 

 

 

On Thu, Dec 19, 2024 at 7:00 AM Mark Rison <m.rison@xxxxxxxxxxx> wrote:

It makes no sense for a capability variable to have a default.

A STA is either capable or not capable.

 

Also, it should be "STA" not "station", I think.

 

[Also, I always forget about the current preference re

dot11FooImplemented v dot11FooEnabled.]

 

Thanks,

 

Mark

 

--

Mark RISON, Standards Architect, WLAN   English/Esperanto/Français

Samsung Cambridge Solution Centre       Tel: +44 1223  434600

1 Cambridge Square, Cambridge CB4 0AE   Fax: +44 1223  434601

ROYAUME UNI                             WWW: http://www.samsung.com/uk

 

From: Li Quan <quan.li@xxxxxxxxxx>
Sent: Thursday, 19 December 2024 14:30
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] PDT-MAC-NPCA

 

Hello Matthew and all,

Thank you for updating the PDT.

Recently, I have been revising the MIB and would like to ask your opinion. 

Below is the MIB I drafted for NPCA. Would you prefer to use this version or do you have any suggestions for modifications?

 

dot11NPCAOptionImplemented OBJECT-TYPE

SYNTAX TruthValue

MAX-ACCESS read-only

STATUS current

DESCRIPTION

"This is a capability variable.

Its value is determined by device capabilities.

This attribute, when true, indicates that the station implementation is

capable of supporting NPCA operation."

DEFVAL { false }

::= { TBD }

 

BR，

Li Quan

 

 

Original

From: MatthewFischer <matthew.fischer@xxxxxxxxx>

To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>;

Date: 2024年12月19日 07:10

Subject: Re: [STDS-802-11-TGBN] PDT-MAC-NPCA

 

r12 is now on the server:

 

https://mentor.ieee.org/802.11/dcn/24/11-24-1762-12-00bn-pdt-mac-npca.docx

 

John Wullert,

 

Generally agree with both of your comments, r12 includes changes that generally follow the spirit of those comments. 

 

Haorui,

 

1. - agree, changed to multiple BSS in r12

2. the commas in the cited item in r11 are in the correct locations

 

note that as long as conjunctions are used, no comma should appear as those conjunctions are adding/modifying the single, albeit long, qualifying phrase

i.e. the entire phrase beginning with "identified" and ending with "received PPDU(s)" is a single qualifying phrase referring to the subject "channel" that appears at the very beginning

the predicate for channel is "does not overlap", making everything in between is a single qualifying phrase, which must be set aside by commas

 

so the structure of the sentence is:

 

the channel, identified by some means, does not overlap something

 

"identified by some means" is then expanded into that big long multiply-qualifying phrase

the commas serve to separate the qualifier from the subject and the predicate

this is because the natural English order is:

 

adjectival phrase subject predicate object

 

In the cited sentence, when the order of adjectival phrase and subject is reversed, commas are used to separate the adjectival phrase

 

subject, adjectival phrase, predicate object

 

3. agree, removed "/or"

 

NOTE - this email has been truncated by removing quoted text from previous emails.

If you want to view the previous emails, please refer to earlier emails in the thread.

 

 

On Tue, Dec 17, 2024 at 11:01 PM Haorui Yang(Rae) <yanghaorui0217@xxxxxxx> wrote:

Hi Math,

 

Thanks for your efforts on updating the draft over and over.

 

I have the below comments further:

1. MBSS in baseline = mesh BSS so in this PDT the MBSS should be changed to multiple BSS set, or other better wording;

 

2. for b)-c, the highlighted comma seems in a wrong place. Maybe it should be after "CH_BANDWIDTH_IN_NON_HT of the received PPDU(s)";

"c.the 20/40/80/160 MHz channel occupied by the received PPDU(s), identified by the STA 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 channel occupied by the received PPDU(s), does not overlap with the NPCA primary channel"

 

3. based on Motion #164, only receiving the CTS without RTS cannot trigger NPCA switch, but in current bullet b) "and/or" means 3 possible cases including the case where only the response frame is received, which seems against the Motion.

b)the STA received a PPDU containing a Control frame and/or a PPDU containing a initial response frame of a Control frame exchange on the BSS primary channel and all of the following conditions apply:

 

BRs,

 

Haorui Yang(Rae)

 

China Mobile

--

--

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

---

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

---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: 90-92 route de la Reine, 92100 Boulogne, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 5 208 026.16 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

 

 

--

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

---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: 90-92 route de la Reine, 92100 Boulogne, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 5 208 026.16 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

 

 

--

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

 

--

Liangxiao Xin 

OPPO

 

---

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

---

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

---

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