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

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:

 

 

 

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:

 

 

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>

Date: 2024年12月19日 07:10

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

 

r12 is now on the server:

 

 

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