Hi Junpeng, all,
I think this deserves a broader conversation – do we need dot11 variables for PEDCA or any other modes at all?
The main question we need to answer is: WHY?
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.
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?
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.
So, IMHO, I see no value in adding new dot11 in any form or aligning it with EDCA.
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.
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
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