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

Thanks for your response, please see comments below

On Apr 1, 2026, at 3:27 PM, Akhmetov, Dmitry <Dmitry.Akhmetov@xxxxxxxxx> wrote:

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

[MA] Not sure how do you consider this an option, We shall not change VHT STA behavior. Am I missing something?

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?

[MA] Long time slots are typically used for 2.4GHz for 11b devices and occasionally for 11g devices. This will also impact the slot time, DIFs, and AIFSN values for the ACs.

In my opinion, the simplest solution is to disable P-EDCA on 2.4GHz. 2.4GHz is generally not suitable for low latency due to its congestion. Even if we restricted P-EDCA to only UHR STAs, if any STA associated with the AP on 2.4GHz does not support short time slots, the AP must announce long time slots in its beacon. We cannot avoid UHR APs announcing long slot times on 2.4GHz for backward compatibility when legacy 11b devices are associated with it. There are example of UHR features that are not allowed on 2.4GHz as well.

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.

[MA] the issue in my option is that the AP cant guarantee the behavior of the legacy devices if it sent an RTS, some will not respond if their implementation was not allowing the less than 16 us new condition you are adding. So it will be a waste of resources to stop every STA from contending and send an RTS and get no response. Allowing only UHR on the DL side should not have this problem since the AP will not be allowed to send an RTS to a legacy device in the protected period. Not sure how this will be the same thing!

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

[MA] Applying a new feature for new APs and STAs will enhance both UL and DL performance for new devices. However, the issue arises because the AP can utilize P-EDCA for all DL traffic to legacy and UHR devices, while only UHR devices are currently using P-EDCA. Consequently, the AP, which is contending for more traffic, will increasingly use P-EDCA. As a result, UL, the purpose of which was to introduce this feature, will be competing with the AP’s P-EDCA traffic frequently.

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.

[MA]From a different perspective, this doesn’t mean ignoring NAV. It’s a NAV for a special RA where you’re allowed to respond if your NAV allowing that before receiving the DS-CTS

I agree that responding to any RTS example is valid, but this is the same case if we reduced the NAV duration. They’ll still respond to any RTS received during that period, right?

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.

[MA] this in some implementation might require hardware changes, I think it is too late to consider that. Would love to hear others opinions too

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

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