Hi, Osama: Thanks for your comment/question. The restricted TWT SP can be assigned to a group of STAs same as existing TWT, during which AP can use DL/UL MU transmissions. The contention exists even it’s assigned to a single STA but with both DL/UL traffic. STAs as members of the SP can use any existing mechanism to reduce or even eliminate contention among them. This is related to your comment – any additional mechanism(s) we need to define in accessing the medium during SP to further improve the performance. It’s covered in this contribution but we can continue to discuss once the group agree on first steps and the direction. Thanks. Chunyu From: Osama Aboul-Magd <oamagd@xxxxxxxxx>
Sent: Friday, September 11, 2020 4:10 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 11-20/1046: discussion on "restricted TWT" Hi Chunyu, Perhaps agreeing with Graham Smith your new proposal sounds very close (if not exactly similar) to HCCA without the HCF polling. The elements you introduced like using the traffic characteristics and the end of TXOP before the start of the restricted TWT SP have already been introduced in 802.11e using TSPEC IE. Perhaps we as a group should look on what is already available in the spec before jumping and proposing similar algorithms. I have a question just to make sure since it is not clear to me from the ppt. Is the restricted TWT SP assigned for a single STA or a group of STAs? if for a group of STAs, do you use contention during the SP? Lastly I agree with Rojan's concern and I believe this concern is the reason why polling was used in HCCA to ensure access to the medium when the time of SP arrives. Hi Chunyu, thank you for your responses. I agree that communicating the most urgent data is important. I agree that it may not make sense to have hard limit on the data that can be transmitted. We also have submission 1006r2 also discusses on mechanisms to signal low latency traffic and signaling the most urgent data to be transmitted. I agree that it makes sense to leave transmission resources also for the regular traffic.
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. 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? 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
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 |