| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Younghoon, Thanks for further clarifications. As you also mentioned, even if the AP performs CCA before resuming the TXOP, the longer it waits, the higher the chances of the medium becoming busy. If we allow the AP to hold on to the medium for arbitrary duration of time, there may
be fairness issues for non-AP STAs. As such, there should be an upper bound on the time that the AP is allowed to perform the “PIFS like” TXOP recovery, else the chances of collisions in the medium will increase. I think, EIFS may be a good upper bound. If
the CCA is idle within EIAFs, AP may perform the TXOP recovery; anything longer and the AP shall perform regular channel access. What do you think? Regards, Rojan From: Young Hoon Kwon <younghoon.kwon@xxxxxxx> Hi Ming and all, This is to have follow up discussions on yesterday’s presentation regarding 20/0427 Synchronous multi-link operation. First of all, thank you very much for your valuable comments during the call. To the best I remember, the concern that Ming has is that the duration of immediate response frame can be long such that continuing a TXOP when the AP MLD does not receive the immediate response frame correctly may not be appropriate.
If the duration of the immediate response frame becomes longer, it is true that the chance of the wireless medium (that BA was not sent) becomes busy will increase. And, also I agree with you that it is not appropriate to continue the AP
MLD’s TXOP if the channel becomes busy. However, this is why I propose to have CCA before resuming the TXOP in the SP. Therefore, the AP MLD will continue the TXOP on the link that BA is not successfully received only if the channel remains idle before resuming the TXOP. I think this procedure is actually in line with current PIFS recovery rule (The only difference is that the CCA measurement duration is extended from PIFS to whole BA + SIFS duration). Please let me know if I misunderstood your comment. Thanks, Young Hoon To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 |