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

Re: [STDS-802-11-TGBE] Feadback Request for proposal 20/1897r3

Dear ALL,

I found that the images disappeared from the mail. 
Please find Figure 1 and Figure 2 on slides 15 and 27 of updated doc: 20/1897r4 

https://mentor.ieee.org/802.11/dcn/20/11-20-1897-04-00be-obss-edca-parameter-sets-for-rta.pptх

Best regards,
Evgeny Khorov


On Mon, Apr 26, 2021 at 4:08 PM Evgeny Khorov <khorov@xxxxxxx> wrote:
Dear ALL,
 
Last month I presented a proposal on OBSS EDCA Parameter Sets for improving RTA https://mentor.ieee.org/802.11/dcn/20/11-20-1897-03-00be-obss-edca-parameter-sets-for-rta.pptx 
 
I collected several questions and comments, the answers to which are below. If you have any other questions or comments, please feel free to contact me.
 
Comment/Question 1. The red and the orange plots overlap on Slide 15 (see Fig. 1). Why does it happen? It looks strange, given that the corresponding TXOP values are different: 0.5 ms and 2.5 ms. Even if the plot describes the average value, one would expect a visible difference.
Figure 1: Overlapping BSS Scenario.
 
Answer. The plots overlap for the case when BSS2 consists of legacy STAs. In this case, the TXOP limit applies only to transmissions in BSS1: the legacy STAs from BSS2 have AIFSN = 3, non-RTA STAs (non-legacy) from BSS1 have AIFSN = 10, and RTA STAs have AIFSN = 2. Thus, the legacy STAs from BSS2 have a significant influence on the RTA STAs delay, while the influence of non-RTA STAs from BSS1 is negligible. It should be noted here that non-RTA STAs generate saturated data flows and occupy all the available channel resources.
 
Comment/Question 2. For the single BSS case, tweaking of the EDCA parameters for RTA traffic should not adversely affect the regular (non-RTA) traffic too much. One concern with your scheme may be that as long as there is RTA traffic, the other traffic may not be able to gain channel access at all. Simulation to verify this would be helpful.
 
Answer. Although in the considered case, the RTA traffic has an absolute priority over the non-RTA traffic, the non-RTA traffic is not “turned off” completely, which is confirmed by Fig. 2. Fig. 2 shows the efficiency of channel resource usage (i.e., the portion of channel time consumed by useful data transmission) by non-RTA STAs vs. the number of RTA STAs. As one can see, the efficiency does not drop to zero, so non-RTA STAs still have an opportunity to transmit their data. This efficiency decreases with the number of RTA STAs because the RTA STAs consume more and more channel resources, but the same behavior is observed for the “Default EDCA” case as well, and the drop in the efficiency for tuned EDCA parameters is ~25%. But at the same time, we significantly decrease the delay percentile (from 15 ms to ~3 ms), which in some scenarios can be considered as a good tradeoff. We propose enabling the AP to decide whether it wants to be RTA-friendly and to set the EDCA parameters as requested by the neighboring APs. The Aps’ decision about RTA-friendly operation can be based on its statistics of RTA and non-RTA traffic: if after becoming RTA-friendly, the goodput of non-RTA traffic falls below some required value, e.g., when a neighboring BSS generates too much RTA traffic, the AP can stop being RTA-friendly.
Figure 2: Single BSS Scenario.
 
Comment/Question 3. If we decrease the TXOP limit, we decrease the throughput. If we change CWmin, we risk either to increase the channel access time due to longer contention or to increase the risk of collision. To limit these effects for overlapping BSSs, we need coordination of these parameters. Such an approach might work in the case of more or less equal traffic in overlapping BSSs. But imagine a situation when one BSS needs to quickly transmit small and rare packets, while the other BSS needs to support several AR/VR links: the first BSS requires a small TXOP limit, while the second BSS requires a large TXOP limit: setting the same parameters for both BSSs will not work.
 
Answer. First, the decrease in efficiency of – 25% is not so much.
Second, we propose to make the support of the RTA-friendly environment an optional feature indicated by the RTA-friendliness flag.  If an AP decides to be RTA-friendly, it should set its EDCA parameters as agreed with the other APs, and also, it should make sure that the traffic in its own BSS does not suffer significantly. If the performance of its BSS degrades beyond the tolerated level because of RTA-friendliness, e.g., when one BSS serves too many RTA STAs which occupy all the available channel resources and leave insufficient resources to STAs from another BSS, the AP can refuse to be RTA-friendly. But still, it is up to the AP/vendor to decide how much degradation of the performance is tolerable.
 
Meanwhile, a similar issue is relevant for Restricted TWT, so the amount of channel time reserved with the restricted TWT shall also be limited.
 
Comment/Question 4. If several APs belong to the same management domain, their EDCA parameters can be controlled by the owner. What motivates the neighboring APs to adjust their EDCA parameters if they do not belong to the same management domain?
Answer. Wi-Fi networks are often deployed in scenarios when several management domains coexist in the same geographical area or when a management domain is surrounded by unmanaged BSSs. As an example, let us consider a block of apartments, where in every apartment there is a Wi-Fi network, and these networks belong to different owners and are possibly managed by different providers. Even if the corresponding Access Points are produced by the same company, they still are not controlled in a centralized manner. In such a case, we need a standard approach to coordinate the network parameters in order to improve the Quality of Service in the overlapping networks: cooperation can be beneficial for all the participants.
 
For example, in two apartments, the owners play VR games from time to time. So, they both want that their service becomes better because of the RTA-friendliness of their neighbors.
 
RTA-friendliness shall not adversely affect the regular traffic. If an AP decides to be RTA-friendly, it shall set its EDCA parameters as agreed with the other APs, and also, it should make sure that the traffic in its own BSS does not suffer significantly. If the performance of its BSS degrades beyond the tolerated level because of RTA-friendliness, e.g., when one BSS serves too much RTA traffic which occupies all the available channel resources and leaves insufficient resources to STAs from another BSS, the AP can refuse to be RTA-friendly. But still, it is up to the AP/vendor to decide how much degradation of the performance is tolerable.
 
 
Comment/Question 5. The proposed approach requires modification of access points and increases their complexity.
Answer. The standard is going to introduce much more complex features for access points, e.g., the TWT support and different scheduled access approaches. Having EDCA parameter Set already supported, adding a possibility to coordinate the existing EDCA parameters likely requires only minor changes.
 
Comment/Question 6. The presented results show a case of irregular sporadic RTA traffic, but what will happen in case of heavy AR/VR? It seems that such a preemptive policy will block non-RTA traffic, which is not desirable.
Answer. OBSS EDCA Parameter Set is proposed first to serve rare sporadic traffic, for which it is hardly possible to use Restricted TWT efficiently. In contrast, for heavy traffic or regular flows, such as AR/VR, the usage of scheduling approaches such as (restricted) TWT seems to be the most suitable solution. For both approaches: OBSS EDCA Parameter Set and Restricted TWT, we have a potential problem that an RTA flow can block non-RTA transmissions. We believe that this solution can be solved as in answer to Comment 3.
 
Comment/Question 6. Also, we do not seem to have big problems with serving rare RTA traffic such as voice or video communications.
Answer. Indeed,  voice or video communications make only a part of RTA scenarios, but they do not have such strict requirements on PLR and delay as listed in the RTA TIG recommendations. We believe that cloud gaming, sensing, or industrial automation scenarios could correspond to a situation where the traffic is irregular, but the delay requirements are much stricter, and the proposed approach will be fruitful.
 
Comment/Question 7. For the Multi-BSS case, 11be has already adopted shared TXOP coordination among APs (for R2); if you adapt your scheme for it, more people may be receptive.
Answer. We believe that our solution does not contradict the TXOP sharing among APs and can be used together with this feature. To obtain a TXOP, an AP needs to access the channel, and our solution makes sure that the channel access time is not too long. At the same time, our solution also improves the performance of uplink transmissions for the case when an arbitrary STA needs to transmit its RTA frames. Meanwhile, we agree that OBSS EDCA Parameter Set can be implemented as a part of the Multi-BSS coordination framework.

Best regards,
Evgeny Khorov

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