Hi, Jarkko: Thanks for your questions. I answered Rojan’s question in a separate email. On #1, the “limiting” here is not from limiting network configuration or AP point of view per se; but more from requester of such restricted TWT session. The background on this was explained in contribution 1045r3 slides 20-23. Basically, we see various scenarios from an STA: - Want to have all traffic to be prioritized. This can be the case where a device is designed to be dedicated for applications carrying latency sensitive traffic. E.g. wearable ar/vr devices.
- The STA is a more general computing devices, and can have mixed type of applications running at the same time. E.g. running an interactive gaming, doing file transfer, receiving emails etc. In this, we can identify traffic streams by their TIDs to prioritize and leave the regular traffic ‘un-restricted’.
The first one can be a special configuration #2. On your second question, the details are still open for the group to explore/discuss. But I think it would make sense to limit the total amount of total amount of time to the whole time period (so, some regular traffic can still flow: new STAs may join/leave, beacon, bcast traffic …). It would also make sense to limit the total amount of time for a STA so it doesn’t consume all the maximum of time unless the network is designed to serve only latency sensitive traffic over one link. Both can be network configuration IMO. These are just forwarding thoughts as shared in slide 10. In SP #4/5, we want to first obtain agreement to have such a mechanism. And then we can go to next level of details. Thanks. Chunyu From: Jarkko Kneckt <jkneckt@xxxxxxxxx>
Sent: Thursday, September 03, 2020 9:06 AM
To: chunyuhu07@xxxxxxxxx
Cc: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx; Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBE] 11-20/1046: discussion on "restricted TWT" Hi Chunyu, I agree that Rojan’s question on allowed operations during the restricted TWT is important and should be clarified. I would like to add two questions to restricted TWT: 1. Is it beneficial to allow transmissions on limited set of TIDs during the restricted TWT? - Non-AP STAs have been able to transmit traffic from any TID in UL HE TB PPDUs. Transmission from any TID ensures that STA can use the allocated transmission time and transmit the most urgent data. If STA is limited to transmit only on a specific TID, then it may waste allocated transmission resources. - AP has not been having restrictions on the data that it transmits in MU DL PPDU. Are you proposing to limit the TIDs from which the AP may transmit during the restricted TWT? Will this limit the available traffic that AP may transmit, i.e. does AP have enough data to transmit relevant size PPDUs so that use of large BW, high number of spatial streams, etc. in PPDU is efficient? The BSS throughput is lower, if AP needs to lower its transmission rate due to lack of available data. 2. Is there any limitation of the maximum total time that AP may have restricted TWT period ongoing? Can AP allocate non-stop restricted TWTs for the whole operating time? Jarkko
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. 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!
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 |