HI Junpeng,
Thank you for you comments,
Please see below
From: Junpeng Lou <junpenglou001@xxxxxxxxx>
Sent: Sunday, November 1, 2026 7:27 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] CIDs for P-EDCA, part 2
Subject: Follow-up on CID 17798, CID 16880 and MIB/SME for P-EDCA
Hi Dmitry,
Thanks a lot for your work on this.
This email includes three independent discussion points related to P-EDCA:
1. CID 17798
The resolution states that using the same set of P-EDCA parameters for both AP and non-AP STAs is an intentional design choice rather than an oversight. I would like to seek further clarification on the rationale behind this design decision.
As we know, legacy EDCA already supports separate parameter configurations for APs and non-AP STAs. From my understanding, only minimal changes to the current specification would be sufficient to enable independent P-EDCA parameter sets for APs and non-AP STAs.
This improvement could bring differentiated channel access priority for downlink UHR traffic and BSS management signaling at AP side, without introducing excessive specification development overhead. It seems to be a beneficial enhancement to enrich the protocol
capability.
Could you please share the key considerations that lead to this intentional same-parameter design for P-EDCA?
[Akhmetov, Dmitry] In short, the motivation is short: P-EDCA was designed as a way to help a STA (but primarily to non-AP for UL access) which struggle with channel access because if multiple
collisions (-> QSRC go up). AP already have all means to have more prioritized access over STA. So both have a) same parameters to send DS-CTS b) same P-EDCA params. This was discussed extensively during 0.1 preparation and from “P-EDCA is for UL” we end up
with “P-EDCA for everyone”.
2. CID 16880
Regarding the normative text on Page 293 and Page 294(D2.0):
> Page 293: If the AP has enabled P-EDCA and the most recent Mode Tuple field corresponding to P-EDCA in UHR Parameters Update element from the AP does not carry the Mode Specific Parameters field for P-EDCA in P-EDCA enable or P-EDCA update operations,
then the default P-EDCA parameters specified in Table 37-1 (Default values for P-EDCA parameters)
shall apply.
> Page 294: Table 37-1 (Default values for P-EDCA parameters) defines default values for P-EDCA parameters
used by a P-EDCA STA when the AP has enabled P-EDCA and does not advertise P-EDCA parameters.
I understand the intended meaning of these two sentences, yet I believe the wording and layout could be refined.
- There appears to be redundancy between the rule on page 293 and the description for Table 37-1 on page 294, since both describe the scenario where default P-EDCA parameters take effect.
[Akhmetov, Dmitry] Yes, both talks about default values, but first talk about the im a context of enablement and advertisement and the other describe actual default parameters. I think
these two allow for a better connection and understanding of the text.
- The page 293 sentence only talks about the AP, and the clause “shall apply” does not explicitly cover non-AP STAs, which is what we intend to include. Perhaps wording like "... shall apply
for the P-EDCA STA" would be clearer.
[Akhmetov, Dmitry] Why it is not clear that rules can only applied to a P-EDCA STA? Ap is a STA. non-AP is a STA as well, so when AP enable P-EDCA, it enables it for self and P-EDCA STAs
in own BSS
- These two statements are about the same default-parameter rule but are separated by several other paragraphs. It would improve readability if they could be placed in adjacent paragraphs.
[Akhmetov, Dmitry] Two paragraphs describing two different things. One talk about advertisement and enablement and another - about default values, I do not think they need to be placed
together
3. MIB and SME
As discussed in earlier email threads, I still hold the view that the MIB is necessary. It shall be explicitly specified that parameters on the AP side originate
from SME. Compared with MU EDCA, the EDCA machine serves as a better reference for this design.
[Akhmetov, Dmitry] We had a very productive discussion over email about MIB variables, thank you. I believe that we should not try to make P-EDCA to be a copy of EDCA. The example with
Mu EDCA is just an illustration that feature can be successfully implemented w/o mib. P-EDCa need a container to store its AIFSN, CW, CWds, PRRC and QSRC threshold – and we already defined them in 37.2.2.. Mib on both sides 9 AP and non-AP) will only act as
unnecessary duplication
We can continue our offline discussion, hope to see you in Bangkok
Thanks!
Best regards,
Junpeng Lou
Akhmetov, Dmitry <dmitry.akhmetov@xxxxxxxxx>
于2026年11月1日周日 12:58写道：
Greetings everyone,
This is a gentle reminder to review doc 1964 for P-EDCA clause 37.2.2; it will likely be scheduled for presentation during f2f/adhoc
week.
Dmitry
Greetings everyone,
I have uploaded document 11-26/1964r0 which provides resolution to 51 remaining CID in P-EDCA clause,
https://mentor.ieee.org/802.11/dcn/26/11-26-1964-00-00bn-lb296-cr-for-37-2-2-p-edca-part-2.docx
Please review and let me know if you have any questions, comments or suggestions.
Thank you,
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
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