Hi Dmitry and all,
Thank you for your work on this. Please find my feedback marked in green.
Any comments are welcome.
Thank you.
Hi Junpeng, all,
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.
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.
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: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.
- 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.
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.
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.
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
