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

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

Hi Matt,

 

Thanks for the update.

I think the following text has something not correct and not have consensus on any motion yet.

 

b.       the duration of the PPDU, determined as the smaller of the value of TXTIME from the PLME-TXTIME.confirm primitive returned in response to a PLME-TXTIME.request primitive that used the RXVECTOR associated with the PPDU in place of the TXVECTOR parameter for the primitive and the value of the TXOP_DURATION parameter of the RXVECTOR of the PPDU, is greater than the value indicated in the most recently received or transmitted NPCA Minimum Duration Threshold field corresponding to its BSS

 

“the value of the TXOP_DURATION parameter of the RXVECTOR of the PPDU” might be smaller than “the value of the OBSS PPDU length”, but the NPCA operation may still possible if the value of OBSS PPDU length is greater than the NPCA Minimum Duration Threshold.

I would suggest to change the text to align with the motion

  • 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.

[Motion #133, [1]]

b. the duration of the OBSS activity based on the received PPDU is greater than the minimum duration threshold advertised by its associated NPCA AP in the NPCA Minimum Duration Threshold field of the NPCA Operation Information field of the (TBD) UHR Operation element of the associated NPCA AP.

Thanks,

Kaiying

 

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

 

External email : Please do not click links or open attachments until you have verified the sender or the content.

 

1762r8 now available:

 

Thank you, Jeongki,

 

I have made changes corresponding to your items 2. and 3., but not 1.

 

The change suggested in item 1 does not clarify anything. The other examples that you implicitly cite to justify your proposed change number 1 are contained within a paragraph that covers both non-AP and AP cases, so the text in those cases needs to include both the AP and non-AP cases. In this new case for your item 1, the language can easily be written separately for the non-AP vs AP case and because separate, explicit language is clearer, it is preferred.

 

 

 

 

On Mon, Dec 9, 2024 at 6:58 AM Jeongki Kim <jeongki.kim.ieee@xxxxxxxxx> wrote:

Hi Matt,

 

Thank you for the update. Some comments.

 

1. For "A non-AP NPCA STA shall not switch to the NPCA primary channel for NPCA operation if the value of the most recently received NPCA Operation Information Present field from its associated AP is equal to 0. An NPCA AP shall not switch to the NPCA primary channel for NPCA operation if the value of its most recently transmitted NPCA Operation Information Present field is equal to 0.", you can also change to "An NPCA STA shall not 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 its BSS is equal to 0." to align with the ext (/other) paragraphs.

2. Similarly, "it shall be ready to transmit and receive frames addressed to it" can be changed to "it shall be ready to transmit and receive frames ". "addressed to it" is applicable to the receive procedure.

3. "OBSS HE/EHT/UHR PPDU" can be changed to "Inter-BSS HE/EHT/UHR PPDU" because OBSS PPDU can be shown only in an example figure of baseline spec (none in texts).

 

Thanks,

Jeongki

 

2024년 12월 6일 (금) 오후 5:48, Matthew Fischer <matthew.fischer@xxxxxxxxx>님이 작성:

 

1762r7 PDT MAC NPCA is on the server:

 

 

This version includes many editorial changes all of which were prompted by comments received from Mark Rison.

 

 

 

On Fri, Dec 6, 2024 at 2:50 AM Mark Rison <m.rison@xxxxxxxxxxx> wrote:

Thanks for this, Matt.  I attach some comments.

 

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: Matthew Fischer <matthew.fischer@xxxxxxxxx>
Sent: Thursday, 5 December 2024 20:27
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] [EXTERNAL] [STDS-802-11-TGBN] PDT-MAC-NPCA

 

 

Thank you for all of the comments received during the call and through the reflector.

 

I have attempted to address each of the comments in the latest revision that is now available on the server:

 

 

In addition to the revision notes, you will find the following in the new DISCUSSION section:

 

The use of the term “received PPDU” in the descriptive behavioural subclauses (e.g. 37.x NPCA) is problematic because the OBSS PPDU that is used to trigger a switch to an NPCA operation on a subchannel of the BSS is not always actually “received”. For the Control frame cases, the PPDU(s) are received, but for the PPDU without a preceding Control frame, only the PHY header of the OBSS PPDU is received before the switch occurs. So for that case, we cannot use “received”. The MAC does receive information from the PHY after a valid PHY header reception, in the PHY-RXSTART.indication() primitive and this does contain an RXVECTOR.

 

Text has been modified appropriately.

 

 

On Thu, Dec 5, 2024 at 7:44 AM Brian Hart (brianh) <brianh@xxxxxxxxx> wrote:

Hi Matt

 

As per thread in chat, with a little augmentation:

 

… (is the field really called just "TXOP"?)

… I think they changed it to be TXOP … Take it back, it is still called TXOP_DURATION

… this seems like the TXVECTOR or RXVECTOR parameter. The subfield is still called "TXOP"

… Since this is MAC text, the text should refer to the parameter used in the MAC-PHY interface (“TXOP_DURATION parameter in the TXVECTOR”), not something below that interface (“TXOP field”)

 

Cheers

Brian

 

From: Matthew Fischer <matthew.fischer@xxxxxxxxx>
Sent: Tuesday, December 3, 2024 10:21 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] [EXTERNAL] [STDS-802-11-TGBN] PDT-MAC-NPCA

 

 

There will be no r5 at this time.

 

On Tue, Dec 3, 2024 at 10:19 AM Matthew Fischer <matthew.fischer@xxxxxxxxx> wrote:

 

John,

 

If you retain the term NPCA, and then use the term Alternate Primary Channel, then you lose a nominal coupling to the NPCA mechanism.

 

If we change the name of NPCA to TACA = Temporary Alternate Channel Access, and then call the new primary as the Alternate Primary Channel, then there is a nice nominal pairing between the name of the feature/mechanism/operational mode and one of the items that is a subject of that mode.

 

e.g. If we use TACA, then when a STA switches to TACA operation, the STA is performing Temporary Alternate Channel Access on an Alternate Channel where there is an Alternate Primary Channel.

 

You could even drop the T and just have ACA

Alternate Channel Access

Alternate Channel

Alternate Primary Channel

 

Some might argue for changing "Channel" to "Subchannel", as the Alternate Channel is supposed to be a portion (i.e. subchannel) of the normal BSS Operating Channel

 

Bur dropping Temporary loses the ephemeral nature of the channel, hence my inclusion of "temporary", so, I think it is better to drop the Alternate label, as Temporary sort of covers the alternate nature of it anyway:

 

Temporary Subchannel Access = TSA

Temporary Subchannel

Temporary Primary Channel

 

Or, you could use Interim:

 

Interim Subchannel Access

Interim Subchannel

Interim Primary Channel

 

more choices:

 

Transient

Ephemeral

Fugacious

Capricious

 

 

 

 

On Mon, Dec 2, 2024 at 10:11 AM Wullert, John R II (PERATON LABS) <jwullert@xxxxxxxxxxxxxxx> wrote:

Matt,

  One note – when I proposed the phrase “Alternate Primary Channel Access”, I was not proposing that we use “APCA primary channel”, but that we use “Alternate Primary Channel” to refer to the channel used for access control.

John

 

From: Matthew Fischer <matthew.fischer@xxxxxxxxx>
Sent: Wednesday, November 27, 2024 3:13 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] [EXTERNAL] [STDS-802-11-TGBN] PDT-MAC-NPCA

 

 

After receiving some editorial comments regarding 1762r2, I have made many of the suggested editorial changes and then added some of my own.

The result is a new r3 version that is now available on the server:

 

 

 

 

 

On Tue, Nov 26, 2024 at 3:09 PM Matthew Fischer <00000959766b2ff5-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:


Thanks to those who submitted comments on 1762r1.

Due to the large volume of motions that were passed regarding the NPCA feature, there is a new revision of 1762 that has been uploaded.

This revision is constructed from several comments/proposed text sections that I received from various TTT members and then consolidated into the r2 version of 1762.

The changes are vast.

This latest revision can be found on the server:

 

 

Note that because of the amount of changes made to the earlier revision of the document, those comments that were sent to this email thread were not directly addressed.

 

As to the comment from John Wullert regarding terminology, I agree that the term NPCA primary channel seems a bit clumsy upon expansion of the acronym.

John's suggestion is an interesting alternative, but I would not unilaterally adopt it without first soliciting additional opinion on the matter.

[of course, at this point, no one else has responded... so maybe there is no other opinion!]

[and I'll note that if you do not expand the acronym, the term isn't so clumsy]

[and I'll note that even with John's proposal, upon expansion, you still get a "double primary" problem - e.g. APCA Primary Channel = Alternate Primary Channel Access Primary Channel]

 

How about TACA - Temporary Alternate Channel Access

 

No change has yet been made to that term.

 

 

 

Matthew Fischer

Nice Guy

Broadcom Inc.

+1 408 543 3370 office

 

 

On Mon, Nov 25, 2024 at 8:45 AM Wullert, John R II (PERATON LABS) <jwullert@xxxxxxxxxxxxxxx> wrote:

Matt,

   Thanks for this.  The one comment I have is related to terminology – It seems to me that “non-primary channel access primary channel”, the expansion of “NPCA primary channel”, has the potential to lead to confusion.  It might be better to call this feature “Alternate Primary Channel Access”?  In that case, what is currently labeled “NPCA primary channel” would become the “alternate primary channel”, which seems much more descriptive and clearer to me.  (Given that the motions use NPCA, it may be that this is the wrong place to have the discussion…)

John

 

 

 

 


 

--

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


 

--

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

Image removed by sender.

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