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

Re: [STDS-802-11-TGBN] doc 0754 - CIDs on P-EDCA clause, part 6



Hi Juseong,

 

Correct me if I’m wrong:

I guess what you are trying to say is that after the end of P-EDCA TXOP (that is successfully initialized), QSRC is not immediately reset.

QSRC is reset when STA invoke _new_ backoff which assumes that QSRC is reset only after that , i.e. ->invoke backoff -> reset QSRC (per reasons (b) and (e) ).

In such a case STA may send DS-CTS (i.e. it is satisfy conditions to starts P-EDCA contention), win contention, send RTS, receive CTS .. after some time this TXOP is over.

STA, even it successfully delivered data, at this point of time has QSRC _NOT_ reset. Which makes it technically possible for the second P-EDCA attempt.

 

Correct? If yes, this bring the following question:

 

When STA invoke backoff procedure?

Say, STA had regular EDCA TXOP, send RTS-CTS-DATA-ACK, now TXOP is over. Per condition (b), STA just completed TXOP and because of that it now shall invoke backoff. Right?

In a case of P-EDCA, STA did the same – it won contention, obtained a TXOP, send some frames (at least initial frame exchange in the TXOP is successful) and now it’s TXOP is finally over.  In my thinking that should trigger condition (b)-> you shall invoke new backoff -> you reset QSRC -> that clears your condition to do another P-EDCA contention.

 

Am I missing anything in this picture? If not, QSRC is reset naturally when old TXOP is over and new backoff is invoked the end of a previous TXOP. STA start its EDCA channel access and it also (subject to conditions) _may_ send DS-CTS. (not shall, but _may_, if conditions are satisfied)

 

Dmitry

 

 

 

From: "문주성 (Juseong Moon)" <theonebird81@xxxxxxxxx>
Sent: Tuesday, April 28, 2026 12:26 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] doc 0754 - CIDs on P-EDCA clause, part 6

 

Hi Dmitry,

 

Thank you very much for your effort.

Regarding your document, I would like to discuss CID 7109, which is currently indicated as “rejected” in the document.

7109

Juseong Moon

37.6

203

4

A potential ambiguity exists in the P-EDCA procedure when transmission failures occur after initial success. A P-EDCA STA may successfully transmit one or more MPDUs after initiating contention with a DS-CTS, but then experience subsequent transmission failures. These failures can cause the QSRC to increase. However, the PSRC value might still remain below the threshold required to transmit a DS-CTS. This creates an undefined scenario where the STA could repeatedly re-transmit a DS-CTS to re-initiate P-EDCA contention, even though it has already successfully transmitted at least one MPDU.

To prevent this unintended looping behavior and clarify the procedure, a specific rule for handling failures after partial success should be defined. It should be specified that if a P-EDCA STA experiences a transmission failure after having already successfully transmitted at least one MPDU, its PSRC shall be set to a value greater than or equal to the PSRC Threshold. This would effectively prevent the STA from transmitting another DS-CTS and ensure that it reverts to the standard EDCA backoff mechanism as intended.

as in comment

Rejected

 

The QSRC increase should not happen in this case because STA performed successful initial frame exchange and obtained a TXOP. If some failures happens after that, a STA may perform recovery(retry) of a failed MPDUs within obtainted TXOP.

P-EDCA itself does not guarantee delivery of a frame being transmitted over wireless medium, it only provide additional transmission opportunity (or higher chances to obtained one)

 

In the current resolution, it is stated that if the transmission of the initial frame succeeds, QSRC is reset to 0, and therefore the issue raised in the comment would not occur.

 However, the baseline text is defined differently. There are clearly cases in which QSRC is not immediately reset to 0 upon the successful transmission of the first frame within a TXOP.

 

 

The current 802.11bn D1.4 text is as follows:

 

37.2.2 Prioritized EDCA (P-EDCA)

A P-EDCA STA that successfully (as defined in 10.23.2.2 EDCA Backoff procedure) delivered one or more pending MPDUs in a TXOP obtained in a P-EDCA contention shall not start P-EDCA contention until all conditions to start a P-EDCA contention are satisfied again. Additionally, the P-EDCA STA shall update AIFSN, CWmin, and CWmax of EDCAF[AC_VO] with the values in dot11EDCATable for non-AP STA and with the values in dot11QAPEDCATable for the AP and shall resume the operation of EDCAF[AC_VI], EDCAF[AC_BE], EDCAF[AC_BK]. Additionally, the P-EDCA STA shall initialize CW[AC_VO] to the value of CWmin[AC_VO] and continue operation of EDCAF[AC_VO].

 

NOTE 3—After successful delivery of one or more pending MPDUs the STA resets QSRC[AC_VO], therefore conditions to start P-EDCA contention are no longer satisfied.

 

 

The relevant text from 802.11mf D2.0 is:

 

10.23.2.2 EDCA backoff procedure

The backoff procedure shall be invoked by an EDCAF if any of the following events occurs:

(…)

 

In addition, the backoff procedure may be invoked by an EDCAF if:

j) For the EDCAF that is the TXOP holder, the transmission by the TXOP holder of an MPDU in a non-initial PPDU of a TXOP fails, as defined in this subclause and an MPDU in the non-initial PPDU does not solicit a TB PPDU.

 

NOTE 1—If the transmission by the TXOP holder of an MPDU in a non-initial PPDU of a TXOP failed, the STA can perform either a PIFS recovery, as described in 10.23.2.8 (Multiple frame exchange sequences in an EDCA TXOP), perform a backoff as described in item j) above, or wait for the TXNAV timer to expire and invoke the backoff procedure per item b) above. How it chooses among these options is implementation dependent.

 

If the backoff procedure is invoked for reason c), d), f), j), or k) above, CW[AC] and QSRC[AC] shall be updated as follows:

— If QSRC[AC] is less than dot11ShortRetryLimit,

— QSRC[AC] shall be incremented by 1.

— CW[AC] shall be set to the lesser of CWmax[AC] and 2QSRC[AC] × (CWmin[AC] + 1) - 1.

— Else

— QSRC[AC] shall be set to 0.

— CW[AC] shall be set to CWmin[AC].

 

 

Although backoff item j) is optional (“may”), it is still clearly available for implementation. After either performing PIFS recovery or not performing it, the STA still has the following choices:

1.           Backoff before TXNAV expiration: item j)

2.           Mandatory backoff after TXNAV expiration: item b)

 

Item b) resets QSRC to 0, so there is no issue in that case. However, under item j), QSRC is incremented. In that case, a STA that has already successfully transmitted at least one initial PPDU within a TXOP gained from its P-EDCA contention will again satisfy the conditions for P-EDCA contention.

 

In other words, if a STA successfully transmits at least one PPDU and then chooses to invoke backoff with item j) for a subsequent non-initial PPDU transmission:

             Frames still remain in the VO Tx queue, and

             QSRC will not be reset to 0.

Therefore, the conditions for DS transmission remain satisfied.

 

This concern is the reason our comment was submitted. At minimum, for fairness, a P-EDCA STA should not be allowed to use P-EDCA again after successfully transmitting at least one frame, when performing backoff for non-initial PPDU retransmission. At the very least, it would be desirable to prevent P-EDCA STAs from using backoff item j), which increments QSRC, in such cases.

 

If you have further opinions, please let me know.

 

Best regards,

Juseong Moon

 

 



2026. 4. 28. 오전 5:42, Akhmetov, Dmitry <Dmitry.Akhmetov@xxxxxxxxx> 작성:

 

Greetings P-EDCA followes,

 

I just uploaded doc 0754 that provide resolution to 24 CIDs in P-EDCA clause

 

 

Please review and let me know if you have any questions/comments/suggestions.

 

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