Hi Shawn,
++reflector
Thank you for your comments, please see below:
From: Shawn Kim <shawn.kim@xxxxxxxxxxxxxx>
Sent: Wednesday, April 15, 2026 12:38 AM
To: Akhmetov, Dmitry <Dmitry.Akhmetov@xxxxxxxxx>
Subject: Re: [STDS-802-11-TGBN] P-EDCA 97us problem
Dear Dmitry,
Thank you for the productive discussion regarding the issues arising from the DS-CTS frame's Duration/ID field being set to 97 us.
Based on 11-26/0210, my understanding is that you are proposing the following two changes:
- Modify the Duration/ID value of the DS-CTS frame: (From 97 us to 77 us (71 us for 2.4 GHz))
- Adjust the timing for NAV idle assessment when responding with a CTS: (From the end of the RTS to the start of the CTS)
Regarding 1. (Duration/ID Value): If the Duration/ID of the DS-CTS is set to 77 us, there is a high probability of collision between an RTS transmitted at the last slot boundary of P-EDCA contention and an AP transmission initiated at "NAV expiration + PIFS (AIFS[1])".
- Last slot boundary: 97 us after the end of the DS-CTS (34 us + 7 x 9 us).
- AP transmission timing: 102 us (77 us + 25 us PIFS).
As you know, the last 4 us of PIFS (aRxTxTurnaroundTime) is not used for CCA. Therefore, an RTS transmitted by a P-EDCA STA starting at 97 us might not be detected by the AP before it initiates its own transmission at 102 us.
To avoid this issue with the last slot boundary (used by STAs with BO=7), I believe a value larger than 77 us is required.
Specifically, 85 us appears to be the most appropriate value for the DS-CTS Duration/ID:
- An RTS transmitted at the earliest point (BO=0) ends 86 us after the DS-CTS. If the NAV is set to 85 us, the CTS responder will not face NAV-related issues.
- In this case, the earliest the AP can initiate a transmission is 110 us (85 us + 25 us). This allows the AP to reliably detect an RTS transmitted at the 97 us boundary. (Note: While another slot boundary exists at 106 us, it is only 4 us apart from 110 us and thus unusable, meaning the CW for P-EDCA remains effectively limited to 7).
[Akhmetov, Dmitry] The table below show that if value is 77us, a STA may use any MCS to transmit RTS frame. As I mentioned in my document 77 gives an AP _better_ chances to detect RTS transmission that can be commenced at 97us giving it 5us (and you are right about RxTxTurnaropund time, so actually ~1us ), smaller values will not give even that. If you go with larger value, like 78, 79 … 85, you will face that if STA chose to TX RTS @ MCS3, remaining NAV will be greater than SIFS, it will 85-77=8 -> 15+8=23us left. So even with proposed modification to NAV idle assessment STA will not be able to respond. You mentioned that issue in your (2) as well
AIFS(2)=34us
AIFS +BC + RTS duration
NAV time left @ the end of RTS reception when duration is 77us
RTS duration
Slot 0
Slot 1
Slot 2
Slot 3
Slot 4
Slot 0
Slot 1
Slot 2
Slot 3
Slot 4
52
86
95
104
113
122
-9
-18
-27
-36
-45
36
70
79
88
97
106
7
-2
-11
-20
-29
28
62
71
80
89
98
15
6
-3
-12
-21
[Shawn] Firstly, I believe we need to verify if 1 us is a technically valid duration for reliable CCA. The baseline CCA requirement requires a >90% probability of detecting a busy medium within aCCATime. Since 1 us is significantly shorter than the aCCATime in most implementations, it may be physically impossible to meet the required CCA detection probability. If this 1 us window is insufficient, we should either 1. Set the DS-CTS Duration/ID to a value larger than 77 us or 2. Restrict the use of the last slot boundary (e.g., limiting CW_min/max to 6). As you pointed out, if the Duration/ID value is larger than 77 us, the issue remains that a CTS cannot be responded to for a 24 Mbps RTS frame(BO=0), even with the modified NAV assessment rules.
In this regard, it appears that an MCS selection rule remains necessary regardless of the change in NAV idle assessment rules. If such constraints are unavoidable, I believe maintaining the baseline rule and simply restricting the RTS rate to 6 Mbps might be a more practical and less risky approach.
Furthermore, I have concerns about the side effects of modification of the NAV idle assessment rules.
As you know, a STA's NAV can momentarily become zero (e.g., for a SIFS duration) even during an ongoing OBSS TXOP. For instance, if the Duration field of an ICF is set to "SIFS + ICR_Time" the NAV set based on the ICF is 0 between the end of the ICR and the start of the next OBSS PPDU.
If we change the rule to evaluate NAV idle at the timing of the CTS transmission, a STA with such a temporary "NAV 0" could incorrectly respond with a CTS to an RTS frame, even during an OBSS TXOP. This issue could occur even for RTS frames transmitted outside the P-EDCA contention period, potentially leading to unintended collisions and breaking the virtual carrier sensing protection.
I am concerned that introducing a fundamental change to the baseline NAV evaluation logic may add unnecessary complexity and risk, especially when a more straightforward solution can address the issue. In summary, my preference is to set the DS-CTS Duration/ID to a value larger than 77 us (but still shorter than 86 us) to make available the last slot boundary and to fix the RTS data rate at 6 Mbps for simplicity. However, if there are strong concerns regarding the 6 Mbps restriction, we could consider the retransmission of the RTS frame to allow for 12/24 Mbps. Frankly, I also have doubts about the necessity of transmitting a 12/24 Mbps RTS when it is certain that a CTS response cannot be performed due to the remaining NAV.
Regarding 2. (CTS response rule): If we set the DS-CTS Duration/ID field to 85 us and limit RTS transmissions to 6 Mbps, the issue of being unable to respond with a CTS due to NAV is resolved. This means we do not need to modify the NAV idle assessment timing in 10.3.2.9.
[Akhmetov, Dmitry] That is certainly one of possible options – we only reduce protected duration by 1 slot (for example) and mandate the STA to use RTS at MCS0.
This is a subvariant of my option (3) listed in the initial email. In such a case the spec will only say that STA need to ensure that RTS duration is long enough so it reception ends after NAV expiration. Some STAs will always use RTS @ MCS0, more flexible implementation may use rate depending on selected slot number. I think something Yonggang proposed something similar
If allowing RTS at 12/24 Mbps is necessary, a more comfortable solution—despite a slight overhead—might be to require retransmission of the RTS(after PIFS from the previous RTS) if the previous RTS was completed while the NAV was still non-zero. Since the retransmitted RTS would end after the DS-CTS NAV expires, the responder could respond with the CTS. Based on my calculation, retransmission would only be required when transmitting a 12 Mbps RTS with BO ≤ 1, or a 24 Mbps RTS with BO ≤ 2.
[Akhmetov, Dmitry] That , with current P-EDCA (and EDCA) architecture, is not possible. If you send initial frame of the TXOP and fail to get response – you need to do another backoff (per EDCA rules). You may also send DS-CTS again after timeout expiration and start another P-EDCA contention. Moreover – you don’t know why RTS failed. May be because NAV is set on the receiver or may be there was RTS collision – this is why we don’t do PIFS recovery on initial frames of the TXOP.
The reason for using a PIFS between the first and second RTS frames is to ensure the receiver can successfully respond to the second RTS. (If the interval between the two RTS frames were shorter than PIFS, the receiver cannot respond with the CTS frame due to busy medium (PIFS prior to the second RTS)).
I look forward to hearing your thoughts on this.
Best regards,
Shawn
2026년 4월 10일 (금) 오전 5:53, Akhmetov, Dmitry <Dmitry.Akhmetov@xxxxxxxxx>님이 작성:
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
- 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?
[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
- 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.
[Akhmetov, Dmitry] Alternatively – AP can disable P-EDCA is long slot is selected.
- 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!
[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.
- 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.
[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
- 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.
- 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
[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.
- 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:
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
--
Sanghyun Kim, Ph.D
WILUS Inc.
5th Fl., 216 Hwangsaeul-ro Bundang-gu,
Seongnam-si Gyeonggi-do 13595, Korea
T +82 31 712 0523
www.wilusgroup.com
WILUS Inc.
5th Fl., 216 Hwangsaeul-ro Bundang-gu,
Seongnam-si Gyeonggi-do 13595, Korea
T +82 31 712 0523
www.wilusgroup.com