Re: [STDS-802-11-TGBN] MAC Queue Request for P-EDCA PDT

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

Hi Dmitry,

Thanks for the response. Let’s using an example FES of P-EDCA to explain my comments.

Assuming STA2, STA3 and STA4 are the P-EDCA eligible STAs. In the initial P-EDCA contention,

STA4 is P-EDCA eligible STA that participated in a P-EDCA contention but did not initiate a TXOP
STA2 and STA3 are P-EDCA eligible STAs that participated in a P-EDCA contention, but did not receive the CTS frame in response to the RTS frame used to initiate the TXOP obtained during the P-EDCA contention

In the first retry of DS/P-EDCA,

if STA4 does not send a DS followed by RTS (i.e., following EIFS rule), the collision probability of DS and followed by RTS will be reduced from the initial transmission of DS (i.e., the collision is only between STA2 and STA3 instead of STA2, STA3 and STA4). STA4 shall follow the EIFS protection rule, which will help the P-EDCA collision converged.
if STA4 sends a DS followed by RTS (as the described in PDT), the collision probability of DS and followed by RTS will be same as the initial DS transmission.

This is why I suggest separating the retry cases and adding the rule “The P-EDCA eligible STA that participated in a P-EDCA contention but did not initiate a TXOP shall not start another P-EDCA contention within the EIFS period after the RTS”. Otherwise, there is no performance gain in the retry of P-EDCA.

If P-EDCA is enabled, DS is part of a test frame exchange sequence. The entire FES of P-EDCA, including DS shall meet the idle period assessment requirement.

Thanks

Yonggang

From: Akhmetov, Dmitry <Dmitry.Akhmetov@xxxxxxxxx>
Sent: Wednesday, April 23, 2025 1:10 PM
To: Yonggang Fang <Yonggang.Fang@xxxxxxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: RE: MAC Queue Request for P-EDCA PDT

External email : Please do not click links or open attachments until you have verified the sender or the content.

Hi Yonggang,

Thank you for the comment, please see below:

From: Yonggang Fang <Yonggang.Fang@xxxxxxxxxxxx>
Sent: Wednesday, April 23, 2025 10:15 AM
To: Akhmetov, Dmitry <Dmitry.Akhmetov@xxxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: RE: MAC Queue Request for P-EDCA PDT

Hi Dmitry,

Thanks for the update. As discussed before, I have some comments on the following paragraph:

“A P-EDCA eligible STA that participated in a P-EDCA contention but did not initiate a TXOP (see 10.23.2.4) during the P-EDCA contention or did not receive the CTS frame in response to the RTS frame used to initiate the TXOP obtained during the P-EDCA contention may transmit the DS-CTS frame without invoking the backoff procedure as in 10.23.2.2 to start another P-EDCA contention, for up to TBD retries”

The P-EDCA eligible STA that participated in a P-EDCA contention but did not initiate a TXOP shall not start another P-EDCA contention within the EIFS period of RTS.

[Akhmetov, Dmitry] “to start P-EDCA” is not a requirement, it is not “shall start P-EDCA”, but only “may start P-EDCA”

This is because the re-transmission from the STA that did not initiate TXOP will interfere the retransmission of STA that transmitted RTS but not received CTS in the EIFS protection period. We need to treat those two cases separately.

[Akhmetov, Dmitry] There is no such thing like “retransmission from a STA that did not initiate TXOP. The part : “STA that …. did not initiate a TXOP” mean that STA was in a process of counting down BK slots in P-EDCA contention, but detected medium BUSY condition on the respective slot boundary, so it stopped count down process. If STA detected some other transmission it will defer till the end of that transmission and only after that it will try (after detecting the medium IDLE for at least AIFSN2 to transmit DS. When STA may send DS depends on what caused medium BUSY event. If it was caused by the start of transmission of other frame(s) (for example – 2 RTSes from other 2 P-EDCA eligible STA, as in you example, it may a) detect RTS and set NAV or b) may get CRC32 error during reception and set EIFS or c) may fail to decode preamble and schedule nothing (in this case STA will wait for the medium IDLE event , defer for AIFSN2 and TX DS).

In short: You cannot claim that (I assume this is what you meant) another attempt of DS transmission will interfere with TX of another STA

The P-EDCA eligible STA that participated in a P-EDCA contention but did not initiate a TXOP should not transmit DS-CTS within the EIFS protection period of RTS. Otherwise, it will make worse to the idle period assessment test.

[Akhmetov, Dmitry]

There is no such thing like “EIFS protection period of RTS” . I said it many times – P-EDCA eligible STA obey all existing rules before transmission DS-CTS except backoff. This is fundamental assumption – a simple, compliant with regulations (- important!) , least invasive “change/addition to current EDCA mechanism that provide a STA a chance to TX a signal to protect medium for contention.

If NAV set – STA wait for its expiration; if CCA_busy – STA wait for medium IDLE; If timeout timer is running – STA does not TX DS-CTS, etc. – exactly as you do today before invoking backoff.

So, in that regards, I do not see how IDLE period assessment will be affected here.

Thanks

Yonggang

From: Akhmetov, Dmitry < >
Sent: Friday, April 18, 2025 6:37 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBN] MAC Queue Request for P-EDCA PDT

External email : Please do not click links or open attachments until you have verified the sender or the content.

Hi Alfred,

Could you please add

CR50 for P-EDCA to the MAC agenda

https://mentor.ieee.org/802.11/dcn/25/11-25-0627-04-00bn-cc50-cr-for-p-edca.docx

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