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] 回���: [STDS-802-11-TGBN] PDT CR MAC NPCA CC50 revision to document 11-25-936r6


Junbin,

I still believe that the language is fine.
If you want to change anything, you can probably simply remove item 2) c) i)

In your table, as long as you have "YES" in column 1, then nothing else matters - the only thing that the STA should do is use the TXOP information from the 1st PPDU.
The 2nd and 3rd PPDUs are still checked for BW, but no NPCA duration information is obtained from either of those frames.

Therefore, 2) c) i) does not matter in that case.
If the condition of 2) c) i) is true, that is, only PHY header information is allowed to be used, then you cannot use the DUR information from the 1st PPDU, and then only thing that you can do is use the PHY length information from the 3rd PPDU, which is the same as condition 1), so effectively, 2) c) i) is not needed (because it is redundant to condition 1))

If you have NO in column 1), then you cannot satisfy condition 2, and you must be using condition 1.


But I still feel like leaving 2) c) i) in place for now, because I am not certain if the language for condition 1) collides with condition 2)

In fact, condition 1) allows use of TXOP_DUR information from the phy header of the third PPDU, so there does need to be something that makes condition 1) and condition 2) exclusive.

I will add some text to fix this.
I.e. we do not want condition 1) to be met if the ICF was received.
I.e. condition 1) uses the PHY header information of a PPDU to determine NPCA duration, but condition 1) could be applied to the 3rd PPDU of condition 2) unless we explicitly state that condition 1) cannot be met if we meet the basic condition of condition 2) which is that an ICF was detected as part of the sequence leading to the PPDU


As for the names of the two NPCA switch "modes", we are gathering the dozens of suggestions and will have a contest to choose one later - maybe in September...

Still holding onto the new revision pending the review of some additional comments on r6.....


On Wed, Jun 18, 2025 at 3:04 AM 陈俊斌 <00003c9288e54ba2-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:

Hi, Matt,

 

Thanks for your reply. For the section 2), I’d like to discuss more on this part.

7) section 2) c) i) -- suggestion to remove the PHY header based qualifier

I think that the qualifier needs to remain

it is complicated by the assignments of the MAC variables, but I'll keep rereading it and probably have a nightmare about it tonight

 

For section 2) c), currently the logical structure of the texts in r6 is:

c)  at least one of the following is true:

i)                   If AP has enabled PHY header-based NPCA only,                =>   check NPCA_PPDU_REM_DUR of 3rd PPDU

ii)                 If AP has enabled MAC header-based NPCA in addition,     =>   check NPCA_CFRAME_TXOP_REM_DUR of 1st PPDU,

The mentioned PHY header-based qualifier makes i) and ii) mutually exclusive situations, the STA can only fit in one of i) and ii).

That is to say, if the AP set the “MAC Header-based NPCA bit” to 1, the STA will not check NPCA_PPDU_REM_DUR of 3rd PPDU.

However, as your previous reply to Gaurang, a STA may still check the variable NPCA_PPDU_REM_DUR of 3rd PPDU, if the 1st PPDU is lost.

 

As for the potential cases that PPDUs might lost, here are some of my considerations for your reference.

 

Cases

1st PPDU successfully received?

2nd PPDU successfully received?

3rd PPDU successfully received?

Behavior

1

Yes

Yes

Yes

l   Always check NPCA_PPDU_REM_DUR of 3rd PPDU.

l   Further check NPCA_CFRAME_TXOP_REM_DUR of 1st PPDU, if AP has enabled MAC header-based NPCA.

2

Yes

Yes

No

l   Check NPCA_CFRAME_TXOP_REM_DUR of 1st PPDU (and 2nd PPDU?), if AP has enabled MAC header-based NPCA.

l   Shall not switch to NPCA primary channel if AP has disabled MAC header-based NPCA, since 3rd PPDU is lost.

3

Yes

No

Yes

l   Same as case 1 in this table.

l   Does the reception of 2nd PPDU matter here? I am not sure for now.

4

No

Yes

Yes

l   Always check NPCA_PPDU_REM_DUR of 3rd PPDU

l   Can not check NPCA_CFRAME_TXOP_REM_DUR of 1st PPDU since it is lost.

l   Again, does 2nd PPDU matter here? Maybe check NPCA_CFRAME_TXOP_REM_DUR from 2nd PPDU?

5

Other situations

l   The STA receives only one PPDU. It just reduces to the rules in condition 1), thus in condition 2) we don’t need to consider these situations again.

 

Based on the table presented above, I would recommend reorganizing the logical structure of the text as follows:

  1. the STA receives one PPDU and the PPDU is not an ICF-only PPDU,

b)        at least one of the following is true:

i)          Check NPCA_PPDU_REM_DUR of the PPDU.

ii)        If the AP has enabled MAC header-based NPCA in addition,  =>  Further check NPCA_CFRAME_TXOP_REM_DUR of the PPDU.

Note – I am using the limitation “the PPDU is not an ICF-only PPDU” to exclude the situation that the PPDU is a (MU)RTS and no following CTS received.

 

  1. the STA receives a sequence of PPDUs (1st ICF, 2nd ICR and 3rd PPDU), which consist at least two of the mentioned PPDUs :

c)         at least one of the following is true:

i)          If the 3rd PPDU is received    =>   check NPCA_PPDU_REM_DUR of 3rd PPDU.

ii)        If the AP has enabled MAC header-based NPCA in addition,  =>  Further check NPCA_CFRAME_TXOP_REM_DUR of 1st PPDU (and/or 2nd PPDU).

Note – I am using the limitation “at least two of the mentioned PPDUs” to make sure that the TXOP is not failed.

 

BTW, it just came up to me that we may use the name “single PPDU triggered” for condition 1) and “multiple PPDU triggered” for condition 2), if you are ok to reorganize the text as my suggestion. Of course I am also open to other better names.

 

Hope my considerations help, thank you!

 

 

Best Regards!

 

Junbin Chen

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

 

发件人: Matthew Fischer <matthew.fischer@xxxxxxxxx>
发送时间: 2025年6月18日, 星期三 上午 06:04
收件人: 陈俊斌 <chenjunbin@xxxxxxxxxxxxxx>
抄送: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBN] 回复: [STDS-802-11-TGBN] PDT CR MAC NPCA CC50 revision to document 11-25-936r6

 

 

Junbin,

 

Thanks for reviewing:

 

1) for UHR Link reconfig frame - agree

2) adding other NPCA parameters to the list of those that must be included in the frames, I think that the earlier paragraphs in this section already include mention of those other parameters, plus another comment suggested adding one or two that were missing - so instead of a new bullet, the previous paragraph is modified to include them - ignoring the optional/mandatory question for now

3) names PHY header based and MAC header based -

there have been many suggestions and none yet suitable, so we'll just stick with this one for a while and people can continue to come up with ideas for the next several months

 

4) does specifying EHT/HE/UHR mean that it must be a data frame

no - it could be mgmt, it could also be a non-HT that is a data frame - no need to be that specific anyway

 

5) simplify the PHY header based conditions - agree

6) same as 5) - agree

7) section 2) c) i) -- suggestion to remove the PHY header based qualifier

I think that the qualifier needs to remain

it is complicated by the assignments of the MAC variables, but I'll keep rereading it and probably have a nightmare about it tonight

 

8) change above to a reference - agree

9) meaning of peers - still under discussion, looking for a consensus

 

 

A revision will appear later.

 

 

On Tue, Jun 17, 2025 at 5:21 AM 陈俊斌 <00003c9288e54ba2-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:

Hi, Matthew,

 

Thanks for your contribution, and here are some of my comments, see the attached doc.

 

 

Best Regards!

 

Junbin Chen

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

 

发件人: yuxin.lu <eeluyx@xxxxxxxxx>
发送时间: 2025年6月17日, 星期二 下午 04:02
收件人: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBN] PDT CR MAC NPCA CC50 revision to document 11-25-936r6

 

Hi Matthew,

 

Thanks for keep updating this PDT. Appreciate the nice work 

 

A general comment: With the development of the various MAPC schemes, we may need to consider the type of frames related to MAPC when describing the switching conditions. For example, for Co-SR, the STA shouldn't switch on receiving Co-SR Invite frame、Co-SR Response frame if the following Co-SR Trigger frame is intended for this STA; similarly for Co-BF

 

I would propose two directions to address it 

1. Classify AP2AP frames as intra-BSS frames (additional rules/indication may need to be defined), set/update intra-BSS NAV, and do not perform NPCA switching (a conservative direction) 

2. Classify AP2AP frames as inter-BSS frames, detail the switching condition on different types of MAPC frames, such as Co-SR and Co-BF (a sophisticated direction)

3. Others 

 

I am not sure whether it would be solved in this CC round, also fine if we solve it in the next round, if no simple solution can be agreed, but at least a placeholder should be provided in this PDT since the current resolution seems incomplete, missing this picture. Thanks  

 

On Tue, 17 Jun 2025 at 07:19, Matthew Fischer <matthew.fischer@xxxxxxxxx> wrote:

 

Revision 6 is now on the server:

 

Within the document, there is a revision notes section that summarizes the changes for each revision.

 


 

--

Matthew Fischer

Broadcom

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


 

--

Best Regards,

Yuxin

 

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