I have some comments on your document 25/0627r4 as below.
From: Giovanni Chisci <00002b657bbbbed7-dmarc-request@xxxxxxxxxxxxxxxxx>
Date: Monday, April 28, 2025 at 11:26 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBN] MAC Queue Request for P-EDCA PDT
Hi Dmitry and all,
Thanks for your great work on this feature and the PDT.
Please find attached my comments for DCN 25/0627.
Best,
Giovanni
From: Akhmetov, Dmitry <Dmitry.Akhmetov@xxxxxxxxx>
Sent: Thursday, April 24, 2025 10:29 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] MAC Queue Request for P-EDCA PDT
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments,
and do not enable macros.
Hi Yonggang,
That you for your complete explanation. But it think it is already not allowed (i.e. STA will not send DS-CTS if EIFS is active) by baseline behavior:
10.3.2.3.7 EIFS.
… The STA shall not begin a transmission until the expiration of the later of the NAV and EIFS or EIFS–DIFS+AIFS[AC]….
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
|
|
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:
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
|
|
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
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