| Hi Boyce,
good comment! This is one more case for TID restrictions that needs clarification. I do not know the answer.
How this case would operate in general? - STAs that have R-TWT SP ongoing and compete with EDCA can only send the high TID traffic, while other STAs can send traffic from all TIDs? - The STAs that have R-TWT SP ongoing would be capable to send from all ACs after Early termination or at the end of R-TWT SP? I assume that R-TWT will likely be AP triggered, because AP can obtain the TXOP in the beginning of the R-TWT SP more likely that non-AP STAs that are restricted to be silent at the beginning of the R-TWT SP.
Cheers, Jarkko
Hi Jarkko, When you say “It would be good to allow also lower TID traffic transmission in R-TWT, if there are enough capacity. This ensures that allocated resources are not wasted.”, are you assuming that a set of resources is allocated to 1 STA? what if one resource is allocated to multiple STAs and they use the resource in a EDCA manner, latency-sensitive traffic from one STA has to compete with non-latency-sensitive traffic from another STA. Regards Boyce Hi Chunyu, I have two questions/comments: 1. The UL TID and DL TID mapping. (Following the previous emails on the topic) - It would be good to allow also lower TID traffic transmission in R-TWT, if there are enough capacity. This ensures that allocated resources are not wasted. - The submission does not state clearly how to use UL TID and DL TID restrictions. - Typically non-AP STAs desire to use multi-TID transmissions and get all their traffic transmitted with minimum number of waking ups. 2. R-TWT and BC TWT (signaling) compatibility. - I am not sure whether BC TWT capable STAs are capable to understand BC-TWT element with parameters values that are not defined for BC TWT. I think this adds new requirements to BC TWT capable STAs. - If AP supports only R-TWT, then I am not sure does it make sense to signal R-TWT flows in format that is understood by legacy BC-TWT capable STAs? - Why BC TWT capable STA should get information on R-TWT SPs? Is there intention that AP would allocate resources for BC TWT capable STAs in R-TWT SP? I would rather separate BC-TWT SPs and R-TWT SPs. Jarkko
Some problems come into my mind if TID level is used. 1, [fairness and abuse issue] If a STA maps latency-sensitive and non-latency-sensitive traffic to the same TID, the STA is allowed to use rTWTs to transmit non-latency-sensitive traffics as well, due to the fifo block issue you mentioned (although I believe this is not a problem at all, most of designs of TID queues are software-based.). This is not fair to latency-sensitive traffics in other STAs, especially when the data volume of the non-latency-sensitive traffic is huge. For example, a “smart” STA can map buffered video to the same TID with latency-sensitive traffic. So the STA’s buffered video traffic would have higher priority than other STA’s buffered video traffic. The QoS of its own latency-sensitive traffic is not affected as long as the STA is able to handle the so-called “fifo-blocking” problem which is very simple. And latency-sensitive traffics from other STAs have to compete with the non-latency-sensitive traffic. 2, [resource allocation issue] The EHT AP has to allocate a lot of resources for the STA, if the data volume of latency-sensitive traffic is small and the data volume of non-latency-sensitive traffic mapping to the same TID is large. So I don’t think we should use TID level just because of head-of-fifo blocking problem(which is not a big deal for most of devices nowadays). Thanks for sharing your comments. Please see the attached document with some responses. There have been some questions/comments on the traffic requirement etc. and questions on TIDs' role here. We agree that STA may want to share the traffic characteristics and requirements with AP or even wants to change default packet classification (mapping) to TID. Those can be done using existing or extended tool(s) (TSPEC e.g.). I believe Duncan etc. have a contribution on TSPEC variant/lite, and Dibakar etc. have a contribution on SCS change. In this set up procedure, we focus on the general rTWT set up procedure, and that it operates at TID level inline with that the blockack agreement is established at TID level. Please note that there is a subclause 35.7.2.2 traffic classification/requirements are discussed. Since restricted TWT is intended to service latency sensitive traffic, we need a mechanism to provide the identification for such traffic streams. TID is the right level rTWT operates at to avoid problem such as head-of-fifo blocking. So in both DL and UL, the traffic transmitted during rTWT SPs is constrained to the TID(s) that AP/STA agreed on during the rTWT setup. the R-TWT proposal has DL TID and UL TID bitmaps. I am wondering how these are used? - In DL why would AP limit the TIDs it is allowed to transmits to the STA? - In UL can STA transmit from other TIDs than signaled here? Thanks for the updated contribution. I add my comments after Boyce’s doc. Thank for the updated contribution. I have some further comments, please find them in the attached. Thank you for the perfect contribution! I added my comments in the attached file. BR, Xiangxin Unisoc Technologies Co., Ltd. +86 21 20360600 3324 Thank you so much for this contribution. You have drafted an excellent spec text. In addition to Stephane’s and Rojan’s comments, please find the attached document for my comments on your draft. Have a wonderful weekend! Thanks all for your feedback. Please see the updated rev1: 11-21/462r1 on server: Stephane, Rojan, please see attached document for responses to your comments inline. Thank you for initiating the review on this document. In addition to Rojan’s comments, please in the attached document my comments on this subject. Thanks for preparing the CR. Please see attached for my comments. Will you review and provide your feedback to this draft text that resolves some TBD/CID?
<11-21-0462-01-00be-pdt-mac-restricted-twt-tbds-crs-part1-Boyce-Frank.docx>
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
|