| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Dibakar, Thanks for your presentation yesterday! I provided a suggestion that AP MLD can indicate the busy status on other links in BA to non-STR MLD (does not have to be full NAV status information, a single bit might be sufficient). The specific
condition for busy status could be AP receiving frame from its own BSS or more stricter rule. You mentioned that if non-STR MLD may not receive the BA, then what procedure should be followed. Upon further thinking, we can define harder rule. If the non-STR MLD does not receive the BA or if it receives BA successfully with AP indicating busy on other link, then non-STR MLD shall perform the NAV Sync delay countdown or ED threshold
(TBD). If non-STR MLD receives BA with NOT BUSY status on other link, then it does not need to perform the NAV Sync delay or ED threshold and resume regular operation. Could you please explain the response on ED threshold? I was unable to hear response properly due to poor voice quality. Thanks, Sharan From: Das, Dibakar [mailto:dibakar.das@xxxxxxxxx]
Hi, I was asked a question offline on 490r0. For the benefit of the group I am forwarding the entire discussion to the reflector.
Regards, Dibakar From: Das, Dibakar
Hi Guoyuchen, Thanks for reviewing the presentation. Please see my response inline below.
Regards, Dibakar From: Guoyuchen (Jason Yuchen Guo) <guoyuchen@xxxxxxxxxx>
Hi Dibakar, Thanks for your presentation on DCN 490r0, I have some questions.
1.
In slide 3, in the figure, Link 3 should be Link2 (is it a typo?), otherwise, even if STA1 is not transmitting on link1, STA2 still cannot receive the RTS (TA:STA3) on Link3; On Link2,
RTS (TA: STA1) should be RTS (TA: STA2), typo, right? [ It is on same channel as link 2. I was using the early definition of a link being defined for a (AP,STA) touple. Since the link 2 and “link
3” have different STAs but same AP, I thought they would be two different links. I should have clarified they are on the same channel.
Yes, on link 2 the RTS should have TA as STA-2, it’s a typo.]
2.
In slide 5, in your results of the legacy STA throughput, mode 3 is slightly worse less mode 2, I’m wondering why. My thinking is,
in mode 3, the EHT STA has NAV knowledge, then it will contend less, then legacy STA should have better performance, but it doesn't, why? [So, there are two competing effects on legacy throughput due to transmission by the EHT STA:
A.
When the EHT STA transmits one or more RTS while there is an ongoing legacy STA transmission it clearly collides and results in lower throughput for the legacy
STA. This effect creates lower legacy throughput when the EHT STA has complete NAV info. See figure 1 attached.
B.
When the EHT STA has complete NAV info it can also have a slightly higher chance of winning the contention because of the coupling in RTS-CTS. In our simulation
we assume that when the EHT STA is transmitting an RTS on link 1 and waiting to receive the CTS, it stops backoff in link 2 so as not to impact the reception of the PPDU on link 2 (and vice versa). Now, if the AP in link 1 happens to be busy, the EHT STA would
have unnecessarily stopped backoff in link 2 which gives opportunity for the legacy STA in link 2 to grab the medium. This effect results in higher legacy throughput when the EHT STA does not have complete info as the legacy STA have more opportunities to
win the medium. See figure 2 attached. In the end what we observe is the two effects sort of washing each other out but its possible for one of them to be slightly more dominant. I believe that’s why
one effect is higher.]
3.
In slide 7, for your opt1, transmitting one RTS still brings some risk: there may be OBSS transmission on going, and the AP
does not know. [
That’s correct. When the AP is a hidden node to that OBSS transmission, it can happen. Our thinking was that this OBSS case is beyond our control and we wont be able to solve it. We are mainly looking at solving the problem within the BSS. To account for the
OBSS case I believe the most likely solution, in absence of complicated signaling, would be to mandate a NAVsyncdelay value in the spec without the RTS relaxation rule. However, this will probably be too conservative in some scenarios and kill the latency
performance. ] Best, Jason Yuchen Guo 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 |