Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] discussion on 11-20-0469-01-00be-multi-link channel sensing and channel access

Hi Yunbo,


Thank you for the comments.  See my response in-line.


Best Regards

Yonggang Fang

ZTE (TX)

Phone 858-883-7984

Original Mail
Sender: Liyunbo <liyunbo@xxxxxxxxxx>
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx>;
Date: 2020/05/13 18:31
Subject: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] discussion on 11-20-0469-01-00be-multi-link channel sensing and channel access

Hi Yonggang,

 

Thanks for initiating the discussion. I have similar view as Pooya. The main fairness concern is for single link STA, not OBSS STA.  I have several additional comments:

 

When the CWmin can further reduce, simply reduce CWmin will get similar gain as Joint backoff. If you argue that we can using Joint backoff in addition to reduce the CWmin, we need to consider that, how to set CWmin is depends on the traffic load on this link (include OBSS transmission), when the load is light, a small CWmin can be used, the STA can easily get a TXOP, it may not so necessary to use joint backoff, because access delay may not be the bottleneck of delay. When the load is heavy, a very small CWmin is not a good choice (may increase the collision probability), under this condition, Joint backoff may also increase the collision probability. So it is not easy to convince people without simulation results.

[YG]  This is a good point. The load heavy may be caused by many stations that are contending the media at same time.  Therefore reducing CWmin may not be helpful.   When the CW becomes large, there exist many idle slots during the backoff procedure. The joint backoff procedure would redcue the waiting time in multi-link access and speed up the procedure. 

 

Joint backoff may has a big change for the backoff rules, and makes it complex. For example, when only the first link get TXOP after BO counter reaches 0, the second link will need to update CW and BO counter to continue the backoff. Later if the transmission is finished or failed in the first link, and the CW and BO counter need to update, but CW and BO counter already there (two link share one CW and BO counter in Joint backoff), how to deal with it is a new issue that never happens in single link backoff.

[YG]   The joint backoff could be considered as a single backoff procedure for multiple links.  When a backoff counter reaches to 0,  the MLD starts the transmisison on link 1, and resets the backoff counter.  There might a couple of options for CW update

1)  the link2 may not perform EDCA like single link case. CW will be updated once transmission on link1 completes.

2)  the link2 may perform EDCA using the current CW parameters when MLD is transmitting on link1.  After the transmission on link1 completes, the MLD updates CW and uses the new CW for the next contention period. 

 

Regards,

Yunbo

 

 

发件人: Pooya Monajemi [mailto:00000ef0b9e0aff7-dmarc-request@xxxxxxxxxxxxxxxxx]
发送时间: 2020年5月14日 8:02
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: 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