Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Chunyu, Thanks for the presentation. I also had some questions: -
You describe the traffic as being bursty/periodic. What type of traffic are you envisioning fits this model? I can see where the downstream video
portion of AR/VR would fit this model. What about the upstream aspects of AR/VR? They would have similar latency requirements and be bursty, but I would not expect them to be so periodic? -
Related question – Does the traffic really need to be periodic? The AP is effectively allocating periodic resources to ensure that the a slot is available
to meet the latency constraints. It seems to me that non-periodic traffic would just tend to waste more of these slots. (not great to waste, but the approach would still help meet the latency objectives.) -
Are you expecting that access to this capability would be restricted in any way? Would any non-AP STA be allowed to invoke this, or would there be
infrastructure to restrict this (e.g., make it a paid-for extra service in public Wi-Fi networks)? Thanks, John From: Chunyu Hu <chunyuhu07@xxxxxxxxx>
Hi, Zhijie: Thanks for the questions. See inline. Chunyu On Wed, Aug 26, 2020 at 7:20 PM Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx> wrote:
A: correct. retransmission follows the same rule.
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.
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.
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.
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 |