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

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

Hi Mohamed, all,

 

Please see below in blue

 

From: Mohamed Abouelseoud <mohamed.a.abouelseoud@xxxxxxxxx>
Sent: Tuesday, April 7, 2026 5:09 PM
To: Akhmetov, Dmitry <Dmitry.Akhmetov@xxxxxxxxx>
Cc: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] P-EDCA 97us problem

 

Hi Dmitry,

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

  1. On changes in clause 10.3.2.9 CTS and DMG CTS procedure
    1. 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?

[Akhmetov, Dmitry] I’m not seeing why we cannot change VHT STA behavior. EHT STA is a VHT STA. I agree that we cannot change _legacy_ behavior, but that is different story

  1. On variation between 5/6 and 2.4 Ghz:
    1. 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. 

[Akhmetov, Dmitry] Alternatively – AP can disable P-EDCA is long slot is selected.

  1. On shortening duration 62us value:
    1. 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!

[Akhmetov, Dmitry] As I said before, I understand the challenge, I just pointed out that in both cases a _reasonable_ implementation on AP side would need to track whether to transmit to legacy client or to EHT client. Anyway, I understand that changes in 10.3.2.9. are not preferable direction for you.

    1. 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

    1. 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

    1. 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. 

[Akhmetov, Dmitry] Well, since very beginning I was arguing that P-EDCA is solely a UL feature, but group decided that AP should use it as well, so now we have to live with it. Regarding your fear of AP to use P-EDCA frequently – well, it does not depend on whether AP deliver traffic to  legacy or to non-legacy clients. P-EDCA is a feature that enhance channel access for AC_VO. We do not put restriction on what type of traffic can be transmitted once you obtained a TXOP during P-EDCA contention. STA compete for the medium access to TX “a” traffic, not “the” traffic.

Also, do not forget that besides traditional BSS we may have soft-APs with 1-2 clients attached and it very well can be a case when “modern” phone with soft-AP that has “older” laptop connected to it.

So I do not think it is right idea to limit operation for EHT clients only

    1. 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?

[Akhmetov, Dmitry] Not exactly. Two pieces here: 1) Yes, that are case cases when you receive RTS from the _same_ device (i.e. TXOP owner) addressed to you. Here, NAV is set from some special but  _generic_ address, so if you say “if NAV set by address XXX – you can reply with CTS” it mean you reply to _any_ RTS. 2) if you receive RTS _after_ NAV has expired, nothing stop you from replying with CTS, that is correct. But that is classical hidden node issue. In the first place – if you are receiving an RTS from somebody, it mean that somebody obtained TXOP -> that somebody did not set NAV from DS-CTS. Exactly as that somebody send  you RTS because it did not get initial RTS or CTS frames from hidden STAs. And it is irrelevant whether we keep 97us or 72us or 62us.

  1. On changing RTS rate.
    1. 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 

[Akhmetov, Dmitry] Certainly there might be limitation, but I am not very convinced that this is hardcoded in HW. If dynamic rate selection is problematic, we can consider compromise variant based on Yonggang’s suggestion: make a requirement that STA that transmit initial RTS make sure its duration in long enough to end after NAV. Some implementations will use fixed MCS0 for this, some may be flexible and select rate accordingly.



 

I would appreciate other members contribution to this thread

[Akhmetov, Dmitry] I can repeat that second time. So far we only have you, me and Yonggang

 

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.

 

  1. 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
  2. Shorten protected duration to 72us
  3. 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
  4. Shorten duration to 77us for 5/6Ghz and 71us for 2.4Ghz and make adjustment to SIFS transmission time

 

Contribution 0210r2:

 

 

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