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

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

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.

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