| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Dmitry, I’ve some comments on the resolution of CID 879. One of the resolutions for this comment in your document is the following: [#879] A P-EDCA eligible STA that has
EPCS priority access enabled shall follow channel access procedures as
described in 35.16.3.2 EDCA operation using EPCS EDCA parameters and may start P-EDCA contention if conditions to start P-EDCA contention are satisfied. I believe this will make STAs affiliated with EPCS non-AP MLD start P-EDCA using the same criteria as STAs affiliated with non-EPCS non-AP MLDs.
In 11be, we have the following behavior for EDCA and MU-EDCA parameter set management –
An AP affiliated with an EPCS AP MLD manages the EDCA parameter set and the MU EDCA parameter set for EPCS non-AP MLD with the EPCS priority access in the enabled
state and non-EPCS non-AP MLDs as follows: — If EPCS priority access is in the enabled state for at least one
EPCS non-AP MLD associated with the EPCS AP MLD, then • if the EDCA parameters previously sent out by an AP affiliated
with an EPCS AP MLD in Management frames it transmits (see 10.2.3.2 (HCF contention based channel access (EDCA))) do not result in higher priority for STAs that are affiliated with EPCS non-AP MLDs in the enabled state, that AP shall announce EDCA parameters
in Management frames that result in higher priority for those STAs with EPCS priority access in the enabled state. A combination of this clause with your resolution can start to cause some issues. For example, as P-EDCA eligible STAs send DS-CTSs, the STAs affiliated with EPCS non-AP MLDs
will not be able to retain their higher priority for channel access. This can trigger the AP MLD to adjust the EDCA parameters that can start to cause a chain reaction. I think a careful analysis of your resolution combined with baseline EPCS is necessary. Also, we need to ensure that the priority access mechanism built for EPCS in baseline
is not disrupted by introduction of P-EDCA. Thanks. Peshal From: Akhmetov, Dmitry <Dmitry.Akhmetov@xxxxxxxxx>
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 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 |