Re: [STDS-802-11-TGBN] 1964r1, P-EDCA part 2

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

Hi Atsushi,

This is a good question and a good example, which force me to ask same question with respect to MU EDCA.

AP has nothing on dot11 side that allow to control MU EDCA params one way or another. Spec says nothing about where AP get these values or who give these values to the AP.

Yet, the Mu EDCA parameters would be very important if network administrator want to coordinate them across own management domain.

Dmitry

From: SHIRAKAWA Atsushi <shirakawa.atsushi@mail.sharp>
Sent: Friday, November 6, 2026 7:57 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx; Akhmetov, Dmitry <dmitry.akhmetov@xxxxxxxxx>
Subject: Re: [STDS-802-11-TGBN] 1964r1, P-EDCA part 2

Hi Dmitry

>> You, on contrary, saying :

>>we need to match P-EDCA to EDCA because

>> we need a way to change parameters -> but this is already possible w/o dot11

Let me ask about point above.

My understanding is that the need for dot11 variables depends on whether the corresponding parameters are intended to be managed internally by the implementation (i.e., vendor-specific behavior) or externally through a standardized management interface. I thought we need dot11 variables for the latter case.

If a network administrator needs to tune P-EDCA parameters, such as CWds, to optimize the operation of P-EDCA, a common management interface (e.g., dot11 variables/MIB objects) could be useful for configuring those parameters in a standardized manner. Otherwise, the configuration would need to rely on a vendor-specific mechanism.

BR.

Atsushi.

差出人: Akhmetov, Dmitry <dmitry.akhmetov@xxxxxxxxx>
送信日時: 2026年11月5日 18:28
宛先: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
件名: Re: [STDS-802-11-TGBN] 1964r1, P-EDCA part 2

Hi Junpeng,

My points for removing dot11PEDCAConsecuitiveAttempts and dot11PEDCARetryThreshold are:

It removes existing duplication between dot11 and corresponding PSRC/QSRC thresholds and as well fixes some other inconsistencies with initialization of variables
Existing named variables in 37.2.2. already serve as a container to store operational parameters for both AP and STA
We already have a number of examples for various modes which operate just fine w/o dott1:

EMSLR has no dot11 variables for transition delays
None of 802.11bn modes has dot11 variables
MU EDCA – the one you are quoting has no dot11 on Ap side

Removal simplifies and streamline text

(2) serve as evidence that updates and initializations already works a/o dot11

You, on contrary, saying :

we need to match P-EDCA to EDCA because

we need a way to change parameters -> but this is already possible w/o dot11
we need a container to store values -> but we have already named variables for the container

that P-EDCA should serve as “first step” -> all other modes need to be brought on the same level. I have some doubts about that direction

number of changes is relatively small -> it mean that you need to add three additional tables , 2 for AP and 1 for non-AP, if you really want to match to EDCA

I simply see no reason to completely redesign, spend _more_ time, effort, and group time to review changes to achieve something that is already implemented.

Dmitry

From: Junpeng Lou <junpenglou001@xxxxxxxxx>
Sent: Thursday, November 5, 2026 8:50 AM
To: Akhmetov, Dmitry <dmitry.akhmetov@xxxxxxxxx>
Cc: Yonggang.Fang@xxxxxxxxxxxx; li.yan16@xxxxxxxxxx; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] 1964r1, P-EDCA part 2

Hi Dmitry and all,

Thank you for your work on this. Please find my feedback marked in green.

Any comments are welcome.

Thank you.

Akhmetov, Dmitry <dmitry.akhmetov@xxxxxxxxx> 于2026年11月4日周三 16:11写道：

Hi Junpeng, all,

Part 1 MIBs：

I think this deserves a broader conversation – do we need dot11 variables for PEDCA or any other modes at all?

[Junpeng] I believe we could first focus on P-EDCA, because P-EDCA has a natural advantage in that we can use EDCA as a reference model. I'm not sure whether the other modes have a comparable reference in the existing specification.

In addition, there may be a related question that should be addressed first regarding the description of the AP: is wording such as “the AP uses the parameters from the element that it most recently transmitted” appropriate?

In general, when an AP transmits an element, the purpose is to notify the receiving STAs of the parameters that they are expected to use.

I'm not sure whether other amendments (outside .11bn) phrase it this way, but at least the EDCA wording doesn't seem to put it that way.

The main question we need to answer is: WHY?

[Junpeng] Therefore, I believe the fundamental question should be: why does EDCA define MIB attributes for both APs and non-AP STAs? So I think the fundamental question is: why does EDCA have MIBs on both the AP and non-AP sides?— and, relatedly, is there any real difference in the parameter-delivery flow between P-EDCA and EDCA? Answer those, and the P-EDCA case mostly falls out of it.

What purpose in adding new dot11 or aligning P-EDCA with EDCA is going to serve?

For simplicity, let’s take “CWds” parameter as an example: Today is has no dot11 equivalent and never had (and that is fine), dot11 for this variable never existed neither for AP not for non-AP side.

It is simply defined in the text; Ap and non-AP use named CWds variable to hold the value (same!) to send DS-CTS.

AP, when it wants to send updated value, it just put this NEW value in the P-EDCA Operation Parameters of UHR Operation element. And according to 37.2.2 both non-AP (when receive) and AP (when transmit) update CWds value from this field.

And if AP does not advertise, non-AP (and AP as well!) use values from Table 37-1.

[Junpeng] CWds does not appear to have a direct counterpart in EDCA, so it may not be the best example here. I suggest that we first consider parameters such as CWmin, CWmax, and AIFSN. Or, regardless of whether new MIBs should be added, the question for D2.0 is: why do we need to delete the existing `dot11PEDCARetryThreshold` and `dot11PEDCAConsecutiveAttempts`?

Where is in this sequence the dot11 equivalent need to be present? And why? An argument “to make it similar to EDCA” would also assume the follow up question – we already counter example in a form of MU EDCA:

the dot11 MU EDCA table exist ONLY on non-AP side, and it ONLY needed to store the value it receives from the AP
AP advertise MU EDCA and does not use it for self
The spec does not define where these new values are coming from – from AP related dot11 tables, from some management entity of from MAC algorithm inside. And we already have product on market that successfully advertise MU EDCA w/o having dot11 on AP side.

So, if MU EDCA is already not aligned with EDCA, why we would want to align P-EDCA to EDCA?

And if we align P-EDCA, would you be proposing aligning Mu EDCA as well?

[Junpeng] The purpose of retaining MIB attributes for P-EDCA would not simply be to align P-EDCA with EDCA. The more fundamental question is why P-EDCA cannot follow the same model as EDCA.

What's more, the MU EDCA example actually cuts the other way: it shows MIBs are needed on the non-AP side, since that's where the value received from the AP has to be stored.

And going one step further, the same example also explains why MU EDCA has no AP-side MIBs — the AP never uses those advertised parameters itself. For P-EDCA and EDCA, that's not the case: the AP uses them for its own contention. Which is precisely why EDCA defines MIBs on both sides today, and why P-EDCA should as well.

P-EDCA defines a container in a form of a named variables in the 37.2.2 and described their purpose. Values of those variables do not change dynamically; we do not need to track their status and keep previous values. We have table 37-1 with default values.

[Junpeng] I would like to add one point based on our previous understanding: the “container in the form of named variables” described here actually corresponds to the variables carried in the fields of the over-the-air frame.

In addition, as I understand it, whether the values of these variables change dynamically is determined by the higher layer on the AP side, after which the updated values are notified to the non-AP STAs. I am not sure whether, by saying that the values “do not change dynamically,” you only mean that the values remain unchanged during a single contention procedure. If so, this seems to be independent of whether corresponding MIB attributes should exist.

So, IMHO, I see no value in adding new dot11 in any form or aligning it with EDCA.

[Junpeng] Please see my comments above.

And please correct me if I’m wrong… but beside MU EDCA that only partially rely on dot11 (non-AP side only), EMLSR has no dot11 for its transition/delay parameters and none of .11bn modes has dot11 variables for its operational parameters.

[Junpeng] Please correct me if my understanding is incorrect. Nevertheless, after we resolve the P-EDCA issue, if similar questions arise for other modes, the P-EDCA mechanism could potentially serve as a reference model. However, this should be considered only after the P-EDCA description has been made technically correct and sufficiently rigorous.

I’d prefer to delete existing dot11PEDCAConsecutiveAttempts and dot11PEDCARetryThreshold to simplify the spec as both are duplicates of existing PSRC and QSRC Threshold variables. This will streamline the description and will reduce amount of spec/comments/effort we need to spend to develop .11bn

[Junpeng] The current D2.0 draft does indeed appear to contain a duplication issue. However, I believe the fundamental problem is that the AP side and the non-AP side have not been clearly distinguished.

If the description follows the EDCA model and distinguishes between the AP side and the non-AP side, the parameters would not be duplicate storage:

on the AP side, the over-the-air parameters would be derived from the AP’s MIB attributes, which may be configured by a higher-layer entity such as the AP SME;
on the non-AP side, the P-EDCA parameters would be received over the air and used to update the corresponding local MIB attributes.

In other words, the AP-side MIB attributes would be used to set the parameters transmitted over the air, and the non-AP STA would use the received values to set its own corresponding MIB attributes. The existing EDCA procedures follow this general model: the AP announces parameters based on its MIB entries, and the non-AP STA updates its local parameter tables after receiving the announcement.
Therefore, simply deleting the two dot11 variables would not resolve the issue. Instead, the AP/non-AP distinction should be made explicit.
Furthermore, if the existing EDCA description is used as a reference, I do not expect this change to require a significant amount of additional work. If possible, I would be happy to handle the related CIDs.

Part 2 — Identical Parameters for AP and non-AP Sides

[Junpeng] Regarding CID 17798, although we have already had some discussion and reached a certain level of agreement, I now have some additional questions.

In the current D2.0 draft, the AP and non-AP STA use exactly the same P-EDCA parameters. This can indeed increase the probability that a non-AP STA successfully gains access to the channel. However, applying the same parameter increase to the AP side may provide only limited benefit.

If the AP were allowed to use parameters different from those used by the non-AP STAs, the AP could operate more flexibly and the parameter configuration could become more meaningful.

For the AP, P-EDCA applies only to AC_VO. Therefore, the AP’s use of P-EDCA parameters does not necessarily create the same type of contention or collision concerns that would arise if the AP and non-AP STAs were forced to use identical access parameters.

Instead, the AP-side and non-AP-side parameters could both be configured by the AP’s higher layer, while still being independently optimized. This would allow more precise control over channel access for the AP and the non-AP STAs, rather than forcing both sides to use exactly the same access parameters.

My primary concern is whether allowing the AP and non-AP STAs to use distinct P-EDCA parameters would introduce any critical issues.

Dmitry

From: Junpeng Lou <junpenglou001@xxxxxxxxx>
Sent: Wednesday, November 4, 2026 1:55 PM
To: Akhmetov, Dmitry <dmitry.akhmetov@xxxxxxxxx>; Yonggang.Fang@xxxxxxxxxxxx; li.yan16@xxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] 1964r1, P-EDCA part 2

Hi Dmitry and all,

Based on our discussion this morning, if I understand correctly, Yonggang does not object to keeping the MIBs.

The overall mode workflow is that the P-EDCA parameters of non-AP STAs are configured by the AP, and the AP uses the same set of parameters for its own access.

Given the above, I would like to request to defer the following CIDs in 11-26-1964r1: 16288, 17796 and 17797.

I’m willing to spend time to refine it and provide protocol wording similar to the EDCA specification( as following FYR).

Thanks,

Junpeng Lou

FYR: 10.2.3.2 (EDCA)

...

Akhmetov, Dmitry <dmitry.akhmetov@xxxxxxxxx> 于2026年11月3日周二 07:30写道：

Hi everyone,

I’ve just uploaded r1 of 1964 doc , part 2 of P-EDCA clause CIDs

https://mentor.ieee.org/802.11/dcn/26/11-26-1964-01-00bn-lb296-cr-for-37-2-2-p-edca-part-2.docx

Please let me know if you have questions or comments,

Dmitry

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