Re: [STDS-802-11-TGBN] P-EDCA 97us problem

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

HI Mohamed,

Thank you for your comments. I formatted your reply for better reading, please see below

On changes in clause 10.3.2.9 CTS and DMG CTS procedure

The change _might_ be needed if the group decide to go with “shorten the protected duration” approach. Also see (3) for more thoughts on that

On variation between 5/6 and 2.4 Ghz:

Yes, I somehow overlooked this, probably aSigExtension should cover 10us and 16us difference. But your comment raised another interesting question : we have short and long slot time. Protected duration was calculated from the assumption that aSlotTime is 9us (short slot), but theoretically it can be 20us as well … which mean 97us would only cover 3 slots of contention… Any thoughts on that?

On shortening duration 62us value:

Yes, I thought about that as well. Yes, it has a large flaw of not providing enough of protection and increase the chances of AP and in some cases even non-AP to grab the medium if P-EDCA STA chose large backoff value for the contention. This was the reason of proposing less aggressive protection reduction but with the need to allow STA to reply with the CTS if remaining NAV is less than 16us. I still think this desirable approach. Yes, old devices may not adopt to this new behavior, but that should be only an issue on AP side as it need to track whether AP transmit to legacy device or to EHT device. But exactly same issue present with your proposal – if you disallow DL direction after P-EDCA contention for legacy devices and make exception for EHT devices to reply with CTS frame when NAV is set.
Mohamed: Additionally, some legacy STAs, depending on their implementation, might decide to go to sleep when receiving a frame from a STA outside their BSS (DS-CTS). This will prevent the response to the DS-CTS. Legacy devices were never designed to respond to frames received from STAs other than their BSSID during NAV set by STAs.

i. Don’t think this is an issue. NAV from DS-CTS is just 97us (or even shorter), yes, we cannot rule out that some device may decide to sleep for just 97us… but in such a case entire P-EDCA is in grave danger if everybody go to sleep if they see DS-CTS

Mohamed: So if we wanted to go with this solution we need to reduce the contention slots to 5 which limit the performance of P-EDCA significantly.

i. This is one of potential solutions as well, cannot say that I like it

Mohamed: The major issue is the AP sending DS-CTS and targeting Legacy STAs and UHR STAs. This is already problematic to make it work in addition it create unbalanced UL/DL flows, where UL for legacy can’t use P-EDCA while DL for Legacy can use P-EDCA. That is a bug by itself.

i. I don’t think this is a good example. It is not a bug, it is a generic behavior every time when we introduce new feature. Same can be applied to QoS and non-QoS STAs, same can be applied to STA that support and do not support TWT SP, same can be applied to STAs that support and do not support TB PDUs

Mohamed: Limiting P-EDAC to UHR devices and updating NAV behavior rules for UHR devices would resolve this problem and maintain the fairness for UL and DL for legacy devices. This should be the cleanest solution with no corner cases

i. Fairness is not a part of the equation here. While the solution looks clean it introduces major issue: letting UHR STA to ignore NAV may create a very bad precedence to use the same thing next time… and we do not want that. If strongly believe that there shall not be exemptions to NAV behavior. Additionally, both STA and AP that have NAV set from DS-CTS may respond to _any_ RTS that is received when NAV is set because neither AP nor STA has information about the source of DS-CTS.

On changing RTS rate.

while it seem very complicated, I don’t think it is the case. Yes, some additional logic will be required, as it is always with any new feature, but it should be similar to rate selection/adaptation that any STA is already doing when transmitting/preparing to transmit to some receiver.

I would appreciate other members contribution to this thread

Dmitry

From: Mohamed Abouelseoud <mohamed.a.abouelseoud@xxxxxxxxx>
Sent: Wednesday, March 11, 2026 11:35 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] P-EDCA 97us problem

Thank you, Dmitry, for working on resolving this issue.

Regarding the Duration of the contention period

As I mentioned in my comment during the presentation, updating VHT behavior is not an option. The baseline states that when the STA receives the RTS, it checks for NAV. If the NAV is not 0, it should not send a CTS.

To avoid any issues, we should limit the NAV to the shortest duration. For AIFSN[2]+RTS_duration= 34+28=62. This is problematic because it will cover only 5 slots where the AP can win the channel with AIFSN=1 in 62+25=87us from the DS-CTS reception.

Additionally, some legacy STAs, depending on their implementation, might decide to go to sleep when receiving a frame from a STA outside their BSS (DS-CTS). This will prevent the response to the DS-CTS. Legacy devices were never designed to respond to frames received from STAs other than their BSSID during NAV set by STAs.

So if we wanted to go with this solution we need to reduce the contention slots to 5 which limit the performance of P-EDCA significantly.

The major issue is the AP sending DS-CTS and targeting Legacy STAs and UHR STAs. This is already problematic to make it work in addition it create unbalanced UL/DL flows, where UL for legacy can’t use P-EDCA while DL for Legacy can use P-EDCA. That is a bug by itself.

Limiting P-EDAC to UHR devices and updating NAV behavior rules for UHR devices would resolve this problem and maintain the fairness for UL and DL for legacy devices. This should be the cleanest solution with no corner cases.

Regarding the variation in behavior between 5/6gHZ and 2.4Ghz

This is not an issue. The signal extension duration (6us) introduced in 11g OFDM-based PHYs to accommodate processing delays while maintaining compatibility with legacy 802.11b devices makes the periods for both 2.4GHz and 5/6GHz kind of equivalent. This ensures consistent 16us physical turnaround time across all bands. During transmission and reception, PPDU adds a signal duration of 6us before signaling the end of transmission or reception, or even the CCA ideal. Therefore, there is no need to define two different behaviors for 2.4 and 5/6GHz.

Regarding changing the RTS rate based on the Backoff value

This is very problematic to consider at this point of time since it’s the most complicated option for implementation.

Thanks

Mohamed

On Mar 11, 2026, at 10:24 AM, Akhmetov, Dmitry <Dmitry.Akhmetov@xxxxxxxxx> wrote:

Greetings everyone,

This is to start discussion thread on P-EDCA 97us. I encourage everyone interested in P-EDCA topic to use this thread to provide comments and share opinion on a problem.

Quick summary:

Four options presented, option 4 is proposed as a solution. The document 0210 describe pros/cons of options 1-3.

Limit P-EDCA operations to UHR STAs. UHR STAs may ignore NAV set from DS-CTS and respond to an RTS received when NAV is set from DS-CTS frame
Shorten protected duration to 72us
Make RTS rate dependent on selected slot number, i.e. if STA chose backoff slot =0, RTS rate shall be MCS0 and so on, If BK=1-> rate can be MCS0 or MCS1
Shorten duration to 77us for 5/6Ghz and 71us for 2.4Ghz and make adjustment to SIFS transmission time

Contribution 0210r2:

https://mentor.ieee.org/802.11/dcn/26/11-26-0210-02-00bn-lb291-cr-p-edca-part4.docx

Again, comments/suggestions are highly appreciated

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