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

Re: [STDS-802-11-TGBN] [!]Re: [!]Re: [STDS-802-11-TGBN] NPCA straw polls

Hello Hirohiko INOHIZA,

Thanks for preparing the SP.

I am wondering why the UHR STA should set the support field differently for 2.4GHz and 5GHz. 
Because the STA can know whether NPCA can be performed based on the BSS bandwidth based on the passed motion:

• An AP shall not allow the use of NPCA within its BSS if the BSS operating bandwidth is less than or equal to 40 MHz.

[Motion #365, [264] and [246]] 


BRs,

Haorui Yang(Rae)

China Mobile
---- Replied Message ----
FromINOHIZA Hirohiko<hirohiko.inohiza@xxxxxxxxxxxx>
Date3/28/2025 02:02
To<STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
SubjectRe: [STDS-802-11-TGBN] [!]Re: [!]Re: [STDS-802-11-TGBN] NPCA straw polls
Hi Alfred,

Regarding the SPs of 24/1699r1 which my colleague requested to defer during March meeting, I had discussion with some members and changed the text.
Could you schedule time for the following straw poll?

Do you agree to include the following into the 11bn SFD?
    * An UHR STA shall not support NPCA operation when the operating band of an AP is 2.4GHz band.
    * The NPCA Supported field of the UHR MAC Capabilities Information field of the UHR Capabilities element is set to 0 for the 2.4GHz band.

Best regards,
Hirohiko INOHIZA

-----Original Message-----
From: Yuki Tsujimaru <000040e1314150c9-dmarc-request@xxxxxxxxxxxxxxxxx> 
Sent: Tuesday, March 11, 2025 7:19 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] [!]Re: [!]Re: [STDS-802-11-TGBN] NPCA straw polls


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.



Hi Alfred,

We would like to defer these SPs since the main author is absent this week, and some members requested offline discussion so we want harmonize.

We want them to be scheduled in a teleconference after this week.

-- 25/0221r4
Tuesday MAC PM2
SP8: Yuki Yoshikawa, NPCA: 24/1699r1 – Result:
Do you agree to include the following into the 11bn SFD?
An NPCA STA may indicate a mode of NPCA indicating whether NPCA operation is enabled or disabled.
Detailed signaling is TBD.

SP9: Yuki Yoshikawa, NPCA: 24/1699r1 – Result:
Do you agree to include the following into the 11bn SFD?
An UHR STA shall not support NPCA operation when the operating band of an AP is 2.4GHz band.
The NPCA Supported field of the UHR MAC Capabilities Information field of the UHR Capabilities element is reserved for the 2.4GHz band.

SP10: Yuki Yoshikawa, NPCA: 24/1699r1 – Result:
Do you agree to include the following into the 11bn SFD?
An NPCA AP shall not transmit Beacon frame, probe response frame and the group addressed frames when operating in the NPCA primary channel.

Wednesday MAC AM1
SP1: Yuki Yoshikawa, NPCA: 24/1699r1 – Result:
 Do you agree to include the following into the 11bn SFD?
An NPCA AP shall only respond to a frame in the NPCA primary channel received from a NPCA STA that is associated to the NPCA AP.
SP2: Yuki Yoshikawa, NPCA: 24/1699r1 – Result:
 Do you agree to include the following into the 11bn SFD?
An NPCA STA shall only respond to a frame in the NPCA primary channel received from another NPCA STA which is the destination of NPCA ICF or the source of NPCA ICF.
--

Thank you.
Yuki Tsujimaru


-----Original Message-----
From: Yuki Yoshikawa <00003a6e12a10726-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Tuesday, March 4, 2025 9:27 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: [!]Re: [STDS-802-11-TGBN] [!]Re: [!]Re: [STDS-802-11-TGBN] NPCA straw polls

Hi Li,

Thank you for your suggestion.
I change the SP2 as your proposal.

I get Yuxin's and your comments.
I will withdraw SP3.

Now I change SPs as follows:
    SP1:
    Do you agree to include the following into the 11bn SFD?
    * An NPCA STA may indicate a mode of NPCA indicating whether NPCA operation is enabled or disabled.
    * Detailed signaling is TBD.

    SP2:
    Do you agree to include the following into the 11bn SFD?
    * An UHR STA shall not support NPCA operation when the operating band of an AP is 2.4GHz band.
    * The NPCA Supported field of the UHR MAC Capabilities Information field of the UHR Capabilities element is reserved for the 2.4GHz band.

    SP4:
    Do you agree to include the following into the 11bn SFD?
    * An NPCA AP shall not transmit Beacon frame, probe response frame and the group addressed frames when operating in the NPCA primary channel.

    SP5:
    Do you agree to include the following into the 11bn SFD?
    * An NPCA AP shall only respond to a frame in the NPCA primary channel received from a NPCA STA that is associated to the NPCA AP.

    SP6:
    Do you agree to include the following into the 11bn SFD?
    * An NPCA STA shall only respond to a frame in the NPCA primary channel received from another NPCA STA which is the destination of NPCA ICF or the source of NPCA ICF.

[24/1699r1]

Thank you,
Yuki Yoshikawa

-----Original Message-----
From: 陈俊斌 <00003c9288e54ba2-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Monday, March 3, 2025 8:55 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: [!][STDS-802-11-TGBN] 答复: [!]Re: [!]Re: [STDS-802-11-TGBN] NPCA straw polls

Hi, Yuki,



Based on you previous explaination, I suggest to change SP2 as follows:

SP2:

Do you agree to include the following into the 11bn SFD?

An UHR STA shall not support NPCA when the operating band of an AP is 2.4GHz band.

*  The NPCA Supported field of the UHR MAC Capabilities Information field of the UHR Capabilities element is reserved for the 2.4GHz band.

Currently in the 11be D7.0 we have similar solution to the “Support For 320MHz In 6 GHz” field of the EHT PHY Capabilities Information field, which is reserved for 2.4GHz band.

Therefore, I think this SP text is more clear than the previous one.



As for SP3, kind of agree with Yuxin’s comment, I guess that it would a good solution for an AP to indicate a unified NPCA supported BW for the BSS, and then the disablement of the NPCA mode of non-AP STA can be easily determined by AP based on the the operating BW info related to the non-AP STA. And by doing so, the dynamic indication from each non-AP STAs, as proposed in your SP3 text, is no longer a necessary choice, the current OMI mechanism can implicitly handle this.



Best Regards!



Junbin Chen

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



发件人: Yuki Yoshikawa <00003a6e12a10726-dmarc-request@xxxxxxxxxxxxxxxxx>
发送时间: 2025年3月3日, 星期一 下午 05:33
收件人: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBN] [!]Re: [!]Re: [STDS-802-11-TGBN] NPCA straw polls



Hi Li,



does the constraint also work for non-AP STA in 2.4GHz ?

Maybe..(ex. in Association request)
If the AP has its capabilities turned off, the non-AP STA should not work in 2.4GHz.

So, non-AP STA is not mentioned in the SP.



Thank you,

Yuki Yoshikawa



From: li.yan16@xxxxxxxxxx <mailto:li.yan16@xxxxxxxxxx>  <li.yan16@xxxxxxxxxx <mailto:li.yan16@xxxxxxxxxx> >
Sent: Monday, March 3, 2025 3:11 PM
To: yoshikawa.yuki <yoshikawa.yuki@mail.canon <mailto:yoshikawa.yuki@mail.canon> >
Cc: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <mailto:STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx> ; eguchi.takami <eguchi.takami@mail.canon <mailto:eguchi.takami@mail.canon> >; yukawa.mitsuyoshi <yukawa.mitsuyoshi@mail.canon <mailto:yukawa.mitsuyoshi@mail.canon> >; hirohiko.inohiza@xxxxxxxxx <mailto:hirohiko.inohiza@xxxxxxxxx> ; yoshikawa.yuki <yoshikawa.yuki@mail.canon <mailto:yoshikawa.yuki@mail.canon> >
Subject: [!]Re: [!]Re: [STDS-802-11-TGBN] NPCA straw polls



Hi Yuki,

    Thanks for your clarification. It does make sense if indication is the NPCA Supported field of the UHR MAC Capabilities Information field of the UHR Capabilities element, which has defined in 11bn D0.1.

    A further comment: does the constraint also work for non-AP STA in 2.4GHz ?











Best Regards！

Yan Li

Original

From: yoshikawa.yuki@mail.canon <mailto:yoshikawa.yuki@mail.canon>  <yoshikawa.yuki@mail.canon <mailto:yoshikawa.yuki@mail.canon> >

To: 李炎10200040;

Cc: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <mailto:STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>  <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <mailto:STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx> >;eguchi.takami@mail.canon <eguchi.takami@mail.canon <mailto:eguchi.takami@mail.canon> >;yukawa.mitsuyoshi@mail.canon <yukawa.mitsuyoshi@mail.canon <mailto:yukawa.mitsuyoshi@mail.canon> >;hirohiko.inohiza@xxxxxxxxx <hirohiko.inohiza@xxxxxxxxx <mailto:hirohiko.inohiza@xxxxxxxxx> >;yoshikawa.yuki@mail.canon <yoshikawa.yuki@mail.canon <mailto:yoshikawa.yuki@mail.canon> >;

Date: 2025年03月03日 13:41

Subject: RE: [!]Re: [STDS-802-11-TGBN] NPCA straw polls

Hi Li,



Thank you for your reply.



I don’t intend to add any additional signals in SP2 now.

I am only referring to the NPCA Supported field in the UHR MAC Capabilities Information field of the UHR capabilities element.



How about changing as follows.

"An AP shall indicate in the UHR capabilities element that the NPCA operation is not supported when the operating band of an AP is 2.4GHz band"



From: li.yan16@xxxxxxxxxx <mailto:li.yan16@xxxxxxxxxx>  <li.yan16@xxxxxxxxxx <mailto:li.yan16@xxxxxxxxxx> >
Sent: Monday, March 3, 2025 11:27 AM
To: yoshikawa.yuki <yoshikawa.yuki@mail.canon <mailto:yoshikawa.yuki@mail.canon> >
Cc: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <mailto:STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx> ; eguchi.takami <eguchi.takami@mail.canon <mailto:eguchi.takami@mail.canon> >; yukawa.mitsuyoshi <yukawa.mitsuyoshi@mail.canon <mailto:yukawa.mitsuyoshi@mail.canon> >; hirohiko.inohiza@xxxxxxxxx <mailto:hirohiko.inohiza@xxxxxxxxx> ; yoshikawa.yuki <yoshikawa.yuki@mail.canon <mailto:yoshikawa.yuki@mail.canon> >
Subject: [!]Re: [STDS-802-11-TGBN] NPCA straw polls



Hi Yuki,

    It depends on the decision of 11bn group. Basically, i don't think it's necessary to carry additional indication, especially the indication can only support one value(i.e., NPCA operation will not be supported on 2.4GHz in any case). If you have a certain indication, the indication may indicate the support of a certain operation or not. But for the case above, it looks confusing to have such an indication which always indicates not support.

    However, if you have a strong opinion on it, how about adding a bullet to say  it's TBD whether any additional signaling is needed🙂









Best Regards！

Yan Li

Original

From: yoshikawa.yuki@mail.canon <mailto:yoshikawa.yuki@mail.canon>  <yoshikawa.yuki@mail.canon <mailto:yoshikawa.yuki@mail.canon> >

To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <mailto:STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>  <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <mailto:STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx> >;李炎10200040;

Cc: eguchi.takami@mail.canon <mailto:eguchi.takami@mail.canon>  <eguchi.takami@mail.canon <mailto:eguchi.takami@mail.canon> >;yukawa.mitsuyoshi@mail.canon <yukawa.mitsuyoshi@mail.canon <mailto:yukawa.mitsuyoshi@mail.canon> >;hirohiko.inohiza@xxxxxxxxx <hirohiko.inohiza@xxxxxxxxx <mailto:hirohiko.inohiza@xxxxxxxxx> >;yoshikawa.yuki@mail.canon <yoshikawa.yuki@mail.canon <mailto:yoshikawa.yuki@mail.canon> >;yoshikawa.yuki@mail.canon <yoshikawa.yuki@mail.canon <mailto:yoshikawa.yuki@mail.canon> >;

Date: 2025年03月03日 09:48

Subject: RE: [STDS-802-11-TGBN] NPCA straw polls

Hi Li,

2. for SP2,  i'm not sure if we can just define some rule text to 
 avoid the usage of NPCA in 2.4 GHz instead of adding any new signaling
I reconsidered that indication is necessary because UHR Capabilities IE is included even in the 2.4GHz band. Therefore, I think it is better to revert to the original text for SP2.
"An AP shall indicate in the capability that the NPCA operation is not supported when the operating band of an AP is 2.4GHz band "

Thank you,
Yuki.

-----Original Message-----
From: yoshikawa.yuki <yoshikawa.yuki@mail.canon <mailto:yoshikawa.yuki@mail.canon> >
Sent: Friday, February 28, 2025 1:53 PM
To: 陈俊斌 <chenjunbin@xxxxxxxxxxxxxx <mailto:chenjunbin@xxxxxxxxxxxxxx> >; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <mailto:STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Cc: eguchi.takami <eguchi.takami@mail.canon <mailto:eguchi.takami@mail.canon> >; yukawa.mitsuyoshi <yukawa.mitsuyoshi@mail.canon <mailto:yukawa.mitsuyoshi@mail.canon> >; hirohiko.inohiza@xxxxxxxxx <mailto:hirohiko.inohiza@xxxxxxxxx> ; yoshikawa.yuki <yoshikawa.yuki@mail.canon <mailto:yoshikawa.yuki@mail.canon> >
Subject: RE: [STDS-802-11-TGBN] NPCA straw polls

Hi, Yuxin, Jay, Li and Junbin,

Thank you for all the good comments.
The proposed SPs is based on 24/1699r1.

I will respond to them in order.

Would you clarify whether this NPCA STA includes both AP and non-AP?
I think both side.
SP3 are based on the assumption that SP1 has passed. Therefore, if the enable/disable indication by frame exchange is included, I think it should be described as a rule when indicating the change in bandwidth or in 2.4GHz.

Could you change "TBD frames" to "Beacon frame and the group addressed frames" in the SP text?
If there is no problem with this change, as you pointed out, SP4 will be changed to Beacon, group addressed frame. In addition, probe response frame would be also included in the SP4. So, SP4 will be changed as follows:
"An NPCA AP shall not transmit Beacon frame, probe response frame and the group addressed frames when operating in the NPCA primary channel."

If your intention here is just to specify the enable/disable frame exchange, i wonder what the 'dynamically' means?
As you mentioned, "dynamically" was assumed to be by frame exchange. How about the following as an SP without "dynamically"?
SP1 will be changed as follows:
"An NPCA STA may indicate a mode of NPCA indicating whether NPCA operation is enabled or disabled. Detailed signaling is TBD."

An AP shall indicate in the capability that the NPCA operation is not 
 supported when the operating band of an AP is 2.4GHz band
SP2 will be changed as follows:
"An AP shall not support when the operating band of an AP is 2.4GHz band."

An NPCA STA shall only respond to a frame in the NPCA primary channel 
 received from another NPCA STA which is the destination of NPCA ICF or 
 the source of NPCA ICF (it's a special ICF used for initial frame 
 exchanges on NPCA primary channel, which has mentioned in D0.1, 
 instead of any ICF)
SP6 will be changed as follows:
"An NPCA STA shall only respond to a frame in the NPCA primary channel received from another NPCA STA which is the destination of NPCA ICF or the source of NPCA ICF."

Do you have a vision that the NPCA Supported BW can be variant for different NPCA STAs implementation?
I hadn't considered having different bandwidth capabilities for each STA. However, considering scenarios like power saving, I think it would be better to allow NPCA to be enabled/disabled for each STA.

Now I change SPs as follows:
    SP1:
    Do you agree to include the following into the 11bn SFD?
    * An NPCA STA may indicate a mode of NPCA indicating whether NPCA operation is enabled or disabled.
    * Detailed signaling is TBD.

    SP2:
    Do you agree to include the following into the 11bn SFD?
    * An AP shall not support when the operating band of an AP is 2.4GHz band.

    SP3:
    Do you agree to include the following into the 11bn SFD?
    * An NPCA STA shall indicate in the NPCA mode that NPCA operation is disabled when the operating channel width of the NPCA STA is changed from channel width more than TBD MHz to equal or less than TBD MHz

    SP4:
    Do you agree to include the following into the 11bn SFD?
    * An NPCA AP shall not transmit Beacon frame, probe response frame and the group addressed frames when operating in the NPCA primary channel.

    SP5:
    Do you agree to include the following into the 11bn SFD?
    * An NPCA AP shall only respond to a frame in the NPCA primary channel received from a NPCA STA that is associated to the NPCA AP.

    SP6:
    Do you agree to include the following into the 11bn SFD?
    * An NPCA STA shall only respond to a frame in the NPCA primary channel received from another NPCA STA which is the destination of NPCA ICF or the source of NPCA ICF.

-----Original Message-----
From: 陈俊斌 <00003c9288e54ba2-dmarc-request@xxxxxxxxxxxxxxxxx <mailto:00003c9288e54ba2-dmarc-request@xxxxxxxxxxxxxxxxx> >
Sent: Friday, February 28, 2025 12:14 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <mailto:STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: [!][STDS-802-11-TGBN] 答复: [STDS-802-11-TGBN] NPCA straw polls

Hi, Yuki and Yuxin,



Thanks for your SPs and comments. Here’s my question on SP3.



SP3:

Do you agree to include the following into the 11bn SFD?

* An NPCA STA shall indicate in the NPCA mode that NPCA operation is disabled when the operating channel width of the NPCA STA is changed from channel width more than TBD MHz to equal or less than TBD MHz



Do you have a vision that the NPCA Supported BW can be variant for different NPCA STAs implementation?

For example, a non-AP operating with 160MHz announces that its NPCA supported BW is 80MHz, while another 2nd non-AP operating with 320MHz announces that its NPCA supported BW is 160MHz, and at the same time a 3rd non-AP operating with 320MHz announces that its NPCA supported BW is 80MHz, like the table list below?



Operating BW

NPCA Supported BW

Non-AP 1

160MHz/80MHz

80MHz

Non-AP 2

320MHz/160MHz

160MHz

Non-AP 2

80MHz

Not supported for NPCA

Non-AP 3

320MHz/160MHz/80MHz

80MHz

If so, I am wondering if it makes the transmission scheduler of AP more complicated? And a further signaling overhead is required for non-AP to indicate their NPCA supported BW.

Basically I guess it is good to define a unified NPCA Supported BW for all UHR NPCA STAs for implementation simplicity. Or, do you have any other considerations?





Best Regards!



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

Junbin Chen



发件人: Jay Yang <yang.zhijie@xxxxxxxxxx <mailto:yang.zhijie@xxxxxxxxxx> >
发送时间: 2025年2月27日, 星期四 下午 07:49
收件人: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <mailto:STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
主题: Re: [STDS-802-11-TGBN] NPCA straw polls



Hi Yuki,



Thanks for your SPs.



Regarding your SP4,  I'm not sure which the TBD frames meaning, it's too broad. Based on Liwen's contribution, I think the group address frame and Beacon frame shall be not transmitted in NPCA primary channel, but I'm not sure about other frames. Could you change "TBD frames" to "Beacon frame and the group addressed frames" in the SP text?

SP4:
Do you agree to include the following into the 11bn SFD?
* An NPCA AP shall not transmit TBD frames when operating in the NPCA primary channel







Thanks



Best Regards



Jay Yang (杨志杰)





Original

From: https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fyuxin.lu&c=E,1,Gp39bmItdx2Bc7XLqI6rqTjp12yURa4W-4cyawEGA0k4Wdb3rtIFjIz9alyAsIGvWg-cK5C8XHvw1SNf58tKi6M2NowJ_oKKbMbwmx23_i8,&typo=1 <eeluyx@xxxxxxxxx <mailto:eeluyx@xxxxxxxxx <mailto:eeluyx@xxxxxxxxx%20%3cmailto:eeluyx@xxxxxxxxx> > >

To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <mailto:STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>  <mailto:STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>  <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <mailto:STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <mailto:STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx%20%3cmailto:STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx> > >;

Date: 2025年02月27日 18:05

Subject: Re: [STDS-802-11-TGBN] NPCA straw polls

Hi Yuki,



Thanks for preparing those SPs, for SP3, below are some comments for your consideration



Would you clarify whether this NPCA STA includes both AP and non-AP?

. if it includes AP, we have an agreement (Motion #134) that says that [An AP shall not allow the use of NPCA within its BSS if the BSS operating bandwidth is less than or equal to TBD MHz, where TBD = 40 MHz or 80 MHz]

. if it includes non-AP, non-AP can simply indicate its NPCA Supported BW with other operation parameters to clarify its NPCA operating capability to AP, instead of performing disabling NPCA which introduces additional signaling overhead; for example, if non-AP indicates NPCA Supported BW=80 MHz, then its operating channel width is changed from 80MHz to 40MHz (should notify this change to AP via OMI/OMN), non-AP automatically disables NPCA since it can no longer support 80MHz, or it can update its NPCA operating capability to AP with a new NPCA Supported BW value



Best Regards

Yuxin

TCL



On Thu, 27 Feb 2025 at 15:15, Yuki Yoshikawa <00003a6e12a10726-dmarc-request@xxxxxxxxxxxxxxxxx <mailto:00003a6e12a10726-dmarc-request@xxxxxxxxxxxxxxxxx <mailto:00003a6e12a10726-dmarc-request@xxxxxxxxxxxxxxxxx%20%3cmailto:00003a6e12a10726-dmarc-request@xxxxxxxxxxxxxxxxx> > > wrote:

    Hi Alfred,

    Could you please schedule time to consider the following straw polls?
    Comments, questions and suggestions are welcome!

    SP1:
    Do you agree to include the following into the 11bn SFD?
    * An NPCA STA may dynamically indicate a mode of NPCA indicating whether NPCA operation is enabled or disabled Detailed signaling is TBD

    SP2:
    Do you agree to include the following into the 11bn SFD?
    * An AP shall indicate in the capability that the NPCA operation is not supported when the operating band of an AP is 2.4GHz band

    SP3:
    Do you agree to include the following into the 11bn SFD?
    * An NPCA STA shall indicate in the NPCA mode that NPCA operation is disabled when the operating channel width of the NPCA STA is changed from channel width more than TBD MHz to equal or less than TBD MHz

    SP4:
    Do you agree to include the following into the 11bn SFD?
    * An NPCA AP shall not transmit TBD frames when operating in the NPCA primary channel

    SP5:
    Do you agree to include the following into the 11bn SFD?
    * An NPCA AP shall only respond to a frame in the NPCA primary channel received from a NPCA STA that is associated to the NPCA AP.

    SP6:
    Do you agree to include the following into the 11bn SFD?
    * An NPCA STA shall only respond to a frame in the NPCA primary channel received from another NPCA STA which is the destination of ICF or the source of ICF.


    Thanks,
    Yuki

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

________________________________

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


________________________________________________________________________
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

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