| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Yonggang, Thank you for the comment, please see below: From: Yonggang Fang <Yonggang.Fang@xxxxxxxxxxxx>
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”
[Akhmetov, Dmitry] “to start P-EDCA” is not a requirement, it is not “shall start P-EDCA”, but only “may start P-EDCA”
[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
[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 < >
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 |