| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Yonggang, Thank you for continuing the discussion on the reflector. Concerning the improvement of the latency of your proposal, I disagree with you. Your proposal improves the latency access of the Multi link devices and not especially the low latency
data flow. Any devices (legacy or/and 11be) can have low latency flows. So your proposal is really unfair for legacy devices and single link 11be devices.
I think that low latency improvement has to be initiated at flow management level, instead of device level.
Best regards Patrice From: Yonggang Fang <yfang@xxxxxxxxx>
Hi Pooya , Thank you for the feedback. For the fairness to OBSS stations, I tries to provide my view to the question in the conference call. The intention of this proposal is to give more opportunity of channel access to the latency
sensitive service when multiple channels are idle, therefore it could access to the media earlier. For the case of a single-link STA associated to one of the links of the same AP MLD , in similar link conditions, that is true the 3-link MLD counts down 3 times as fast. In non-similar conditions, the 3-link MLD may win in the non-busy
link like contending in single link case because other links will not contribute countdown if they are busy. Therefore a latency sensitive service will take the advantage of ML to access to the media faster only when multiple channels are idle at same time. Best Regards Yonggang Fang ZTE (TX) Phone 858-883-7984
Original Mail Sender: PooyaMonajemi <00000ef0b9e0aff7-dmarc-request@xxxxxxxxxxxxxxxxx> Date: 2020/05/13 17:01 Subject: Re: [STDS-802-11-TGBE] discussion on 11-20-0469-01-00be-multi-link channel sensing and channel access Hello Yonggang , Thanks for initiating the discussion. In case of secondary channel PIFS , one could argue that with a good channel planning we can avoid placing a nearby BSS on the secondary channel of this AP. Here the main problem is not with OBSS but with a single-link STA associated to one of the links of the same AP MLD . If I understand your proposal correctly,
all backoff counters count down when any link is idle. Then in similar link conditions, the 3-link MLD counts down 3 times as fast. In non-similar conditions, the 3-link MLD pretty much always wins in a busy link because it counts down in the non-busy link. I'd like to point out that there is already an inherent gain in latency when a STA contends (fairly) on multiple channels. Simply using the first link that
opens up will show gain. Regards Pooya M. Cisco Systems On Wednesday, May 13, 2020, 02:18:24 PM PDT, Yonggang Fang <yfang@xxxxxxxxx> wrote: Hi, Yunbo , Dmitry and all, Thank you all for comments on the contribution of 11-20/0469r1 in 11be MAC conference call. As the discussion time was limited in the coherence call, I would like to have offline
discussion for the joint ML EDCA backoff counter for high priority and low latency service. Fairness – Existing multi-channel access: 802.11 specifies the channel access on the secondary channel in PIFS after the primary channel EDCA backoff counter reaches to “0”. If the
station senses the secondary channel idle in PIFS , the station will perform the multi-channel access on both primary and secondary channels. Therefore other stations (OBSS ) operating on the secondary channel may feel unfair as well. – Joint ML EDCA backoff channel access: each of ML senses on its channel independently but shares the joint backoff counter. When the backoff counter reaches to “0”, the
MLD can perform channel access on the channels being sensed as idle at the joint ML backoff counter = 0. In the extreme case that a channel is only idle at the time that the joint backoff counter is 0, the joint ML EDCA backoff procedure is same as the
existing multi-channel access in term of fairness. In other case, the joint ML EDCA backoff would be more fair than the existing "CCA+PIFS " multiple channel access to OBSS stations. Channel Access Delay – Comparing to the existing channel access in the multiple channels, the minimum channel access delay depends on the primary channel access. Even the secondary channel is idle,
the station cannot perform the channel access on the secondary channel if the primary channel is busy. – Comparing to the independent ML channel access, the minimum channel access delay depends on the first available channel with the backoff counter = 0 among multiple links.
Even when multiple channels are idle, the ML channel access delay would not be reduced significantly. It is possible to reduce the CW size of ML for the low latency service to speedup channel access, but it may not take advantage of ML to further reduce the
channel access time. The joint ML EDCA hackoff is not conflict with the CW size reduction, it can further reduce the channel access time on top of CW size reduction for the time sensitive services. – Joint ML EDCA backoff channel access delay depends on the number of idle channels at same time in addition to other common factors like CW size, channel load, etc. When only
one channel is in idle, the joint ML channel access delay is the same as the independent ML channel access. But when X channels are sensed idle in the same time, the ML channel access delay will be reduced by about X times. If there is other question or comment, I am glad to discuss them as well. Best Regards Yonggang Fang ZTE (TX) Phone 858-883-7984 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 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 |