Hi Mark, Matt and all,
Thanks for further detailed discussion. For the first item, maybe i have a different opinion.
> The existing SAP PHY-CONFIG.request passes the OPERATING_CHANNEL parameter in the PHYCONFIG_VECTOR and the PHY uses that to set its own dot11CurrentPrimaryChannel variable.
Yes, so I think we can just use that for NPCA. When the MAC decides
it's time to switch to the NPCAPC, it sends PHY-CONFIG.request with
OPERATING_CHANNEL set to the NPCAPC (and the other parameters to
indicate where the secondaries are). When it's time to go back to
the real PC, it sends another PHY-CONFIG.request with OPERATING_CHANNEL
set to the real PC.
Yan: we should store both of these two parameters(BSS P20 and NPCA P20) concurrently in NPCA operation and such NPCA switch behavior is different from any channel switch operation(i.e., SST or off-channel operation), which may change its center-frequency(I guess?). Basically i think this is the reason why not bring up another channel parameter for SST or off-channel operation.
Besides above, the current definition of OPERATING_CHANNEL refers to the BSS P20. However, it is weird to set the BSS P20 to NPCA P20, because they have totally different definitions. As we know, the relevant primitives are just instances and references for implementation, which means different vendors may have different design within their device and you can have only one interface to set current operating channel for implementation. However, when we provide such instances in the standard, we should pay attention to the definition of different parameters and try our best to avoid any ambiguity.
After all, i agree with your option 2 to add a new parameter indicating NPCAPC and use 0/null to signal whether operating on NPCA channel instead of adding another 'use NPCA primary channel' parameter.
Best Regards！
Yan Li
> The existing SAP PHY-CONFIG.request passes the OPERATING_CHANNEL parameter in the PHYCONFIG_VECTOR and the PHY uses that to set its own dot11CurrentPrimaryChannel variable.
Yes, so I think we can just use that for NPCA. When the MAC decides
it's time to switch to the NPCAPC, it sends PHY-CONFIG.request with
OPERATING_CHANNEL set to the NPCAPC (and the other parameters to
indicate where the secondaries are). When it's time to go back to
the real PC, it sends another PHY-CONFIG.request with OPERATING_CHANNEL
set to the real PC.
> But there is no actual instance where the standard indicates that the MAC should/shall actually invoke the PHY-CONFIG.request.
> As such, there is no line of text that says that the MAC shall populate the OPERATING_CHANNEL parameter with some specific information, for example, that it received from a beacon.
> In addition, I see several instances of PHY-CONFIG.confirm in some of the PHY clauses, and there is no PHY-CONFIG.confirm defined in the PHY SAP subclause.
> And of course, there is no text to say what a MAC does when it receives a PHY-CONFIG.confirm.
> If someone really wants to, they can propose a lot of fixes for the use of the PHY-CONFIG.request.
> E.g. existing missing specification: during scanning, and auth/assoc, during channel switch operations while associated, etc.
> E.g. new use: NPCA
> I am NOT volunteering.
I suspect that you're right, and all this needs to be brought to TGmf.
FWIW I don't think PHY-CONFIG.confirm exists at all. On the other
hand, there is a statement that
[PHY-CONFIG.request] is generated by the MAC sublayer for the local PHY entity when it desires to change the configuration of the PHY.
so all that might be missing might be a hand-wavy NOTE to say that
that includes scanning, starting/joining, off-channel operation,
etc.
However, since it's already implicit that PHY-CONFIG.request is used
to set the PC, it doesn't make the spec any worse to use it to set
the NPCAPC.
> I did not look too closely, but I also wonder if there is a problem in the way that the current PHYCONFIG_VECTOR is defined, with a minimal set of parameters back in the PHY SAP subclause and then additional parameters indicated for various PHY types in each of their respective subclauses.
I've raised this in more than one generation of TGm, and there was never
enough interest for anyone to try to fix it.
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: Matthew Fischer <matthew.fischer@xxxxxxxxx>
Sent: Thursday, 12 December 2024 20:38
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] PDT-MAC-NPCA
Mark,
Some follow up:
The existing SAP PHY-CONFIG.request passes the OPERATING_CHANNEL parameter in the PHYCONFIG_VECTOR and the PHY uses that to set its own dot11CurrentPrimaryChannel variable.
But there is no actual instance where the standard indicates that the MAC should/shall actually invoke the PHY-CONFIG.request.
As such, there is no line of text that says that the MAC shall populate the OPERATING_CHANNEL parameter with some specific information, for example, that it received from a beacon.
In addition, I see several instances of PHY-CONFIG.confirm in some of the PHY clauses, and there is no PHY-CONFIG.confirm defined in the PHY SAP subclause.
And of course, there is no text to say what a MAC does when it receives a PHY-CONFIG.confirm.
If someone really wants to, they can propose a lot of fixes for the use of the PHY-CONFIG.request.
E.g. existing missing specification: during scanning, and auth/assoc, during channel switch operations while associated, etc.
E.g. new use: NPCA
I am NOT volunteering.
I did not look too closely, but I also wonder if there is a problem in the way that the current PHYCONFIG_VECTOR is defined, with a minimal set of parameters back in the PHY SAP subclause and then additional parameters indicated for various PHY types in each of their respective subclauses.
More background:
8.3.5.16 PHY-CONFIG.request
8.3.5.16.1 Function
This primitive is a request by the MAC sublayer to the local PHY entity to configure the PHY.
8.3.5.16.2 Semantics of the service primitive
The primitive provides the following parameter:
PHY-CONFIG.request(
PHYCONFIG_VECTOR
)
8.3.5.16.3 When generated
This primitive is generated by the MAC sublayer for the local PHY entity when it desires to change the
configuration of the PHY.
VHT example (partial text):
21.2.3 PHYCONFIG_VECTOR parameters
The PHYCONFIG_VECTOR carried in a PHY-CONFIG.request primitive for a VHT PHY contains an
OPERATING_CHANNEL parameter, which identifies the operating or primary channel. The PHY shall set
dot11CurrentPrimaryChannel to the value of this parameter.
The PHYCONFIG_VECTOR carried in a PHY-CONFIG.request primitive for a VHT PHY contains a
CHANNEL_WIDTH parameter, which identifies the operating channel width and takes one of the
values 20 MHz, 40 MHz, 80 MHz, 160 MHz, and 80+80 MHz. The PHY shall set
dot11CurrentChannelWidth to the value of this parameter.
On Thu, Dec 12, 2024 at 11:30 AM Matthew Fischer <matthew.fischer@xxxxxxxxx> wrote:
Mark,
The NPCA primary channel information comes to a non-AP STA through some management frame sent by the AP.
This information is pseudo static.
The MAC must tell the PHY to switch back and forth between the BSS P Chan and the NPCA P Chan.
I think that there are at least two general mechanisms that could be used to do this:
1)
Once the non-AP STA has the NPCA P Ch information, it can store it in a MAC variable, along with a MAC variable for BSS P Ch
Whenever NPCA Operation is invoked, the MAC then uses a PHY SAP that says "switch to chan X" and supplies the MAC variable NPCA P Ch as "X"
Whenever NPCA Operation is terminated, the MAC then uses a PHY SAP that says "switch to chan X" and supplies the MAC variable BSS P Ch as "X"
2)
Once the non-AP STA has the NPCA P Ch information, it can transfer it to the PHY using a PHY SAP that provides an NPCA P Ch in the "PHY configuration" (and the BSS P Ch)
Whenever NPCA Operation is invoked, the MAC then uses a PHY SAP that says "switch to NPCA configuration" and the PHY already has the NPCA P Ch information locally
Whenever NPCA Operation is terminated, the MAC then uses a PHY SAP that says "switch off NPCA" and the PHY already has the BSS P Ch information locally
I do not know if either of these looks like what we have already been doing for other MAC "commands" which control the PHY
We should find something that looks like what we have done in the past to be consistent.
For example, do we already have a MAC variable for BSS P Ch?
On Thu, Dec 12, 2024 at 2:02 AM Stephen McCann <mccann.stephen@xxxxxxxxx> wrote:
Yan,
returning to Matthew's comment, I also agree that the term NPCA_PRIMARY_CHANNEL is awkward. Fully expanded it is "Non Primary Channel Access Primary Channel". Let's try and think of another term please. Thanks.
Kind regards
Stephen
On Thu, 12 Dec 2024 at 09:06, Mark Rison <m.rison@xxxxxxxxxxx> wrote:
Some thoughts:
- Why do we need both an OPERATING_CHANNEL and an NPCA_PRIMARY_CHANNEL?
The PHY is never operating on both simultaneously, so can't the MAC just
send an updated OPERATING_CHANNEL to the PHY whenever it switches to/from
NPCA?
- If we do keep an NPCA_PRIMARY_CHANNEL can't we just use a magic value
(e.g. 0 or null) to signal "not used" rather than invent a USE_NPCA?
- We've already had off-channel operation in the context of e.g. SST and
of TDLS. How was the off-channel identified to the PHY in this case?
I can't immediately identify the signalling used, but can't we just
use the same signalling?
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 Yan <li.yan16@xxxxxxxxxx>
Sent: Thursday, 12 December 2024 07:32
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] PDT-MAC-NPCA
Hi Matt,
Thanks for your specific clarification. My feedback is as below:
NPCA_PRIMARY_CHANNEL looks ok to me, but in the NPCA TTT we have been disucssing whether the name should be different, so until we resolve that, I would say that the issue is not settled.
Yan : i will keep it in mind and try my best to keep consistent with the NPCA text when the group decides to use a new name, but for now i would like to use NPCA_PRIMARY_CHANNEL for the PHYCONFIG_VECTOR
For USE_OF_NPCA_PRIMARY_CHANNEL, I do not like this name, because the syntax is a bit strange.I believe that what you really want is USE_NPCA_PRIMARY_CHANNEL (i.e. remove the "OF" portion).
Yan : i will remove the 'of ' term and track the discussion on the name of NPCA_PRIMARY_CHANNEL
Regarding the other question of whether BEACON frame should be included in the PDT MAC NPCA document, there is some question as to whether this should be the case.
There has been discussion which suggests that instead of adding yet a few more elements to the Beacon, that we should start adding a single bit to the Beacon for each new amendment.
Yan : thanks again for specific clarification. I remove text regarding beacon frame in the MLME-SCAN.confirm primitive and upload a new revision 24/2026r1 PDT-Joint-MLME-SAP
Best Regards！
Yan Li
Original
From: MatthewFischer <matthew.fischer@xxxxxxxxx>
Date: 2024年12月12日 04:56
Subject: Re: [STDS-802-11-TGBN] PDT-MAC-NPCA
Yan,
NPCA_PRIMARY_CHANNEL looks ok to me, but in the NPCA TTT we have been disucssing whether the name should be different, so until we resolve that, I would say that the issue is not settled.
The issue is that the P in NPCA expands to PRIMARY, so that to say NPCA PRIMARY sounds redundant.
I do not know when the question will be resolved.
For USE_OF_NPCA_PRIMARY_CHANNEL, I do not like this name, because the syntax is a bit strange.
I believe that what you really want is USE_NPCA_PRIMARY_CHANNEL (i.e. remove the "OF" portion).
Again, this name should be updated once we decide on what to call the feature and its operating channel.
But for now, you should remove OF.
Regarding the other question of whether BEACON frame should be included in the PDT MAC NPCA document, there is some question as to whether this should be the case.
There has been discussion which suggests that instead of adding yet a few more elements to the Beacon, that we should start adding a single bit to the Beacon for each new amendment.
The new bit would indicate UHR capable.
The relevant elements for the new amendment's operation and capabilities would then be available upon request.
This reduces beacon bloat.
This is why the Beacon is not currently included in the PDT MAC NPCA document.
Again, this is an open issue, but for now, it seems preferable to keep the Beacon out of the document.
On Tue, Dec 10, 2024 at 11:42 PM Li Yan <li.yan16@xxxxxxxxxx> wrote:
Hi all,
As a new term, 'NPCA primary channel', has been proposed in NPCA opeation ,which is totally different parameter from OPERATING_CHANNEL(BSS primary channel) in the PHYCONFIG_VECTOR, then i suggest to add two new parameters for UHR PHYCONFIG_VECTOR in order to instruct PHY whether operating on NPCA primary channel as below
I'm trying to discuss it with the PoC of UHR PHY service interface(Bo Sun). However, i would also like to receive any comments or suggestions from our NPCA TTT group or other members interested in this topic.
38.2.4 PHYCONFIG_VECTOR
(current parameter)The PHYCONFIG_VECTOR carried in a PHY-CONFIG.request primitive for an UHR PHY contains an OPERATING_CHANNEL parameter, which identifies the operating or primary channel. The PHY shall set dot11CurrentPrimaryChannel to the value of this parameter.
(new proposed one)The PHYCONFIG_VECTOR carried in a PHY-CONFIG.request primitive for an UHR PHY contains a NPCA_PRIMARY_CHANNEL parameter, which identifies the NPCA primary channel. The PHY shall set dot11NPCAPrimaryChannel to the value of this parameter.
(new proposed one)The PHYCONFIG_VECTOR carried in a PHY-CONFIG.request primitive for an UHR PHY contains a USE_OF_NPCA_PRIMARY_CHANNEL parameter, which indicates whether operating on the NPCA primary channel or not. The PHY shall set dot11USEofNPCAPrimaryChannel to the value of this parameter.
Best Regards！
Yan Li
Original
From: 李炎
Date: 2024年12月11日 09:15
Subject: Re: [STDS-802-11-TGBN] PDT-MAC-NPCA
Hi Matt,
I have one more comment that maybe you miss the beacon frame since you propose to add UHR capabilities element UHR operation element for the relevant frames ((re)association,probe frame).
Moreover, both of PDT-NPCA from you and PDT-Power-save from Liwen mention the UHR capabilities element UHR operation element, could you please talk with each other for convergence?
However, i have uploaded PDT-Joint-MLME-SAP doc.(24/2026r0) ,which is based on corresponding UHR capabilities element UHR operation element in your doc. I will realy appreciate it if you and other members could check it.
Best Regards！
Yan Li
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
From: MatthewFischer <matthew.fischer@xxxxxxxxx>
Date: 2024年12月11日 06:20
Subject: Re: [STDS-802-11-TGBN] PDT-MAC-NPCA
Chaoming,
1762r10 has changes along the lines that you have requested:
On Mon, Dec 9, 2024 at 10:44 PM 罗朝明(Chaoming Luo) <luochaoming@xxxxxxxx> wrote:
Hi Matt,
Thanks very much for the clarification! Two more here:
For the “TXTIME” stuff, I agree with you that it’s complicated to make the change and the calculation. My suggestion is making it simple for now and leave that for later discussion, possibly involve PHY guys. So, the text could be something like:
the duration (TBD for how to determine the value) of the received PPDU is greater than the NPCA value indicated in the most recently received or transmitted NPCA Minimum Duration Threshold field corresponding to its BSS.
Another issue is about untriggered UL transmissions mode.
The SFD says “Whether the mode is for all associated non-APs or per non-AP is TBD”. But r9 writes “If the STA is a non-AP STA and the associated AP has disabled the use of untriggered UL transmissions on the NPCA primary channel, then the non-AP STA shall not initiate a TXOP on the NPCA primary channel.” Sounds like r9 making it a mode for all associated non-APs. I’d suggest the following change:
A non-AP STA that supports NPCA operation shall announce its NPCA Switching Delay and NPCA Switch Back Delay in TBD frames.
Add the following:
An NPCA AP may enable or disable the use of untriggered UL transmissions on the NPCA primary channel, by transmitting TBD frames.
i. Whether the mode is for all associated non-APs or per non-AP is TBD.
ii. TBD whether MU EDCA parameters mechanism and or some other mechanism is used to disable untriggered UL transmissions on the NPCA primary channel.
c. If the STA is a non-AP STA and the associated AP has disabled the use of untriggered UL transmissions on the NPCA primary channel, then the non-AP STA shall not initiate a TXOP on the NPCA primary channel.
Remove the following:
i. TBD whether MU EDCA parameters mechanism and or some other mechanism is used to disable untriggered UL transmissions on the NPCA primary channel.
BR,
Chaoming
发件人: Matthew Fischer <matthew.fischer@xxxxxxxxx>
发送时间: 2024年12月10日 4:08
收件人: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBN] PDT-MAC-NPCA
1762r9 now available:
asdf
Thank you for the comments, see some responses inline:
On Sun, Dec 8, 2024 at 10:52 PM 罗朝明(Chaoming Luo) <luochaoming@xxxxxxxx> wrote:
Hi Matt,
Thanks for the update. Still there are points in r7 not comply with SFD:
In SFD “due to OBSS traffic or other TBD conditions”, meaning “other TDB conditions” are NOT necessarily be sub-category of “OBSS traffic. However, r7 writes TDB conditions only in sub-items of OBSS PPDU or exchange.
Updated to include a new separate item c) for TBD conditions
In SFD, no agreement on which exact subchannel will be selected for NPCA p-channel. However, r7 limits NPCA p-channel to be in S160 or S80 or S40. Which may not be a reasonable limitation. E.g., when BSS A of 320 MHz overlaps with BSS B of 80 MHz, why A can not choose the S80 of the P160 as its NPCA p-channel?
Paragraph deleted
PLME-TXTIME.confirm primitive is generated in the transmitter side but not receiver side, so the duration of the received PPDU can’t be determined by the receiver by using TXTIME. PSDU_LENGTH in RXVECTOR may help on this.
PSDU_LENGTH is octets, not time, so it will not give the answer that the MAC needs.
The MAC needs many more parameters than just PSDU_LENGTH to calculate a PPDU duration.
And once it has all of the parameters it needs, the equation to determine the PPDU duration is very complex.
In the case of TX PPDU, there are quite a few separate TXTIME equations that are in the baseline, and by using PLME-TXTIME.request, the complexity of choosing the correct parameters and the correct TXTIME equation are all invisible to the MAC.
So exactly the same complicated determination of a PPDU duration would exist for the MAC if it wants to calculate a duration for an RX PPDU, hence, the simplest solution would seem to be for the MAC to just use the same PLME-TXTIME.request, but instead of passing TXVECTOR, pass an RXVECTOR.
But, there are issues with this:
If the MAC uses an RXVECTOR in the TXTIME.request, the PHY should then return the TXTIME for the RX PPDU.
Theoretically.
Of course, it is much more complicated than this.
Even though TXVECTOR and RXVECTOR are defined with the SAME TABLEs, they are actually different because many of the parameters in the table are unique to RX vs TX and vice versa.
So it is possible that some of the parameters needed are missing in some RXVECTORS (e.g. the L_LENGTH is not included in the RXVECTOR for an HE PPDU!)
And a PHY would then know that there is something wrong if it gets a PLME-TXTIME.request(RXVECTOR)
So the simplest fix for this might be to add a PPDU_DURATION parameter to RXVECTOR for ALL FORMAT values.
Then we would still have to add language to the PHY to tell it how to use TXTIME equations with the RX PPDU parameters to create this value.
I.e. the PHY would pass this value in the RXVECTOR.
There are still possibly some additional complications, as the PHY could compute a PPDU duration when it has received the L_SIG but before it has received a HE header, for example and then another one after it receives another PHY header. So the PHY might need to pass more than one RXVECTOR (it already does, because it passes one RXVECTOR at PHY header successful decode (RXSTART) and another one at the end of the PPDU reception in the RXEND)
I am not certain that I want to start making such changes until we have an agreement as to exactly what the best solution is.
And I hope that the current language is good enough for now.
I believe that this sort of detail is best left to a later date.
BR,
Chaoming
发件人: Matthew Fischer <matthew.fischer@xxxxxxxxx>
发送时间: 2024年12月7日 6:48
收件人: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBN] PDT-MAC-NPCA
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
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
--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
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
--
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