Hi, Zhijie: Thanks for the follow-up. Response inline. I can also schedule offline meeting with you and/or anyone else on further discussion. Thanks. Chunyu From: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>
Sent: Thursday, August 27, 2020 8:06 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [Suspected Marketing Mail] [STDS-802-11-TGBE] 11-20/1045: "prioritized EDCA channel access" discussion Hi Chunyu, See my further comment. Thanks Best Regards Jay Yang From: Chunyu Hu <chunyuhu07@xxxxxxxxx>
Sent: 2020年8月27日 23:41
To: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>
Cc: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [Suspected Marketing Mail] [STDS-802-11-TGBE] 11-20/1045: "prioritized EDCA channel access" discussion Hi, Zhijie: Thanks for the questions. See inline. Hi Chunyu, Let’s continue our discussion here. Q1: slide12: the current txop should end at the boundary. If retransmission happened during the TXOP, it means retransmission also need to be stopped even if it is not up to the max retransmission times?
A: correct. retransmission follows the same rule. à<Jay> Seem the time slot is an addition constraint for HW retransmission. I don’t know how chipset company consider this. We always increasing the retransmission times through HW+SW retransmission to guarantee no pkt lost in low latency case(VI or VO case) in practice. I’m afraid your proposal will cause more pkts lost due to the slot boundary limitation in low SNR case. [Chunyu:] My view is that re-transmission or overall stability of a link operation is an orthogonal problem to handle. To deliver a solution for latency sensitive application, pEDCA alone is only one puzzle in it, but a critical one. The slot boundary handling exist even nowadays if you think about it, but a matter of soft versus hard. E.g. P2P/NAN/TWT operations all require some sort of being aware of a time schedule, and yielding to the upcoming critical event. It’s not clear to me if/how this incur more pkt loss (for regular or P-traffic?). Can you elaborate? Q2: I remember Yonghong ask the question about the OBSS, I have a similar question on it. How do you consider the compatibility with legacy devices, including legacy AP and legacy STA? For instance, for the legacy AP, it can’t decode the new signaling sent from P-EDCA AP, and how the legacy STA connected to P-EDCA AP get the transition opportunity compared to P-EDCA STA?
A: For the OBSS, it would have the requirement that the neighboring BSSs understand the same protocol however STAs within OBSS doesn't need to track every slot boundary. Additional OBSS coordination can be designed (see the slot information format design --> information bitmap that contains OBSS) such that BSS informs each other the protected time periods in its own TSF time domain. It's some work we can extend to. à<Jay> I mean the pre-11be STA don’t support this protocol in current WIFI SPEC. I don’t know how to let them understand this. [Chunyu:] agree. STAs that don’t understand the protocol and doesn’t know how to parse new format to learn prioritized access time windows can break the ‘prioritized access’. We would need some sort of greenfield link operation, hence our proposal of “latency sensitive link” in contribution 11-20/408. At some point, we need to find a way to move forward and evolve technology to support applications that can benefit our life and work … 😊 Q3: slide19, simulation results: What’s the SNR do you set? What’s the simulation results if set different SNR on each STA? Do you enable MPDU and MPSU aggregation for VO traffic? Because we don’t do any aggregation for VO traffic in practice because of low latency reason.
A: in this set of simulation, rate is fixed and every STAs can hear each other. No hidden terminal situation is simulated. We are mostly focusing on the protocol effectiveness here. MSDU agg is ON: 2 MSDUs per A-MSDU. A-MPDU is on and BA window of 64 is used -- for all three schemes (VO uses txop limit 0). We set txop limit to 0 for VO for a fair comparison and mean to demonstrate that using an aggressive CW/AIFSN doesn't solely solve the problem. à<Jay> I hope you could consider my suggestion to add more variant parameters on the simulation. So that we could know your proposal can cover all the scenarios or it just works in some special case. [Chunyu:] sure. We certainly will simulate more scenarios and share more results in later contributions. Due to time limit, we first target at demo’ing the effectiveness of the protocol. Q4: If a STA has some higher priority traffic, How AP to allocate the time slot if AP find the RSSI of STA is very bad? If AP allocates too much time slot for it, it will harmful for the total TP. How do you consider in such scenario?
A: the requester and granter need to take into account their link operating state: that includes their tx/rx capability, rssi, traffic, to request reasonable amount of time in slots. In practice, one can go through some probing stage to start the initial assignment. It may need to do so with some margin to tolerate traffic/channel dynamics. It may need to adjust assignment as traffic/channel vary over time but hopefully at slow pace. à<Jay> Seems it requires that the AP will be more intelligent to understand the associated STA status before allocate the time slots according to your description. In other scenarios, I believe some STA associated with same AP will require more time slots than expected to show their better performance than others, And AP will decide their performance through the number of slots. [Chunyu:] yes but the action (evaluating the link operating status) is not limited to AP. The non-AP STA can do so as well, and it can combine its knowledge of applications/use cases to request slots. The latter, we believe, is an advantage in this design. The scheme empowers a more distributed decision. Thanks Best Regards Jay Yang Hi, all: Starting a thread for Q/A for the doc 11-20/1045r3 to cover remaining Q/As. I captured Jay, Mohamed, Liangxiao, and Sharan. Other please also feel free to ask questions here or send me separate emails. Thanks. Chunyu
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 |