| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Chunyu, Thanks for starting the thread. I think the crux of the matter is how to ensure that the “Restricted TWT” is indeed “Restricted”? Mandating early termination of preceding TXOP only addresses part of the problem, but how are traffic from 3rd party STAs (e.g.
non-latency sensitive traffic) prohibited from accessing the channel during the “restricted TWT” SP? Is it entirely based on the NAV protection (e.g. RTS/CTS) of the TWP SP, or do you envision other methods? Also, there is no guarantee that the RTS frame can
gain the channel access at the start of the TWT SP. I couldn’t find much details in your slides, appreciate if you could shed some light. Regards, Rojan From: Chunyu Hu <chunyuhu07@xxxxxxxxx> Hi, all: Starting a thread for Q/A/discussion on the proposed “restricted TWT” described in contribution
11-20/1046. I saw there were a lot of discussions in the chat window. Thanks for some answers provided and shared interest on this topic. Let me share my 2cents on the legacy STA handling. First, in order to provide low latency traffic more predictable performance, it’s the key to protect the start of a protected time period for the network to “commit” to a pre-setup schedule, as Gaurav nicely put. While the legacy STA handling needs multi-layer solutions/strategy and also patience/confidence/incentive for wider deployment, 802.11be is the right place to first define an enabling mechanism to start from. It’s hard to get around it
if we want WiFi to support this category of applications. Please share your further comments and questions. 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 |