| Hi, Patrice:
Thanks for your comments. Please see response inline.
Thanks. Chunyu
Hi Chunyu, Thanks for sharing the next revision of the doc1802. I have some comments on this revision: - Why are you defining r-TWT TID ? Is there a different mapping with classical TIDs ? If no, I think that it creates some misunderstandings.
It’s for notation convenience. As stated in the doc (pasted below), it refers to the TID(s) that are specified in the r-TWT setup procedure and is referred so to make the rest text in this clause less cumbersome. ---
The TID(s) that are specified in the Restricted
TWT DL or UL TID Bitmap with the corresponding DL or UL TID Bitmap Valid
subfield set to 1 in a TWT Response frame that indicates Accept TWT are
referred to as r-TWT DL TID(s) or r-TWT UL TID(s), and collectively as r-TWT
TID(s), in the following subclause. -- - About CID5664, I think that you don’t answer to the comment that asks additional mechanisms for controlling the data flows sent by the STAs during the rTWT SP. It means some penalties if STAs don’t respect the deal with the AP.
The comment raised the request to “ensuring that a station uses efficiently its low latency resources.”, and along the goal, the “traffic prioritization” rules are described in the newly added subclause. So the r-TWT STA should first deliver the latency sensitive traffic. It’s not clear what “a priori” low latency traffic is as there is no such reference in spec, but I think the proposed text addressed the concern to large extent (may not be 100% strictly speaking.)
- On p.5 l.28, a NOTE enables the scheduling AP to solicit any STAs that is not registered to the corresponding rTWT. To ensure fairness among all STAs, it is preferable to tear down the rTWT SP if no data from registered STAs remain to be transmitted.
I agree to the suggested preference and we can continue that discussion in resolving CIDs on SP terminations. But I hope you would agree, as we discussed in doc 11-21/1147 and many feedbacks received offline and via CIDs (e.g. 5775, 7471), it’s impossible to forbid any traffic (not originated from r-TWT STAs, or other TIDs), nor desired in some cases (where extra resources in frequency/spatial domain can be allocated for non r-TWT STAs. e.g.). The NOTE is to point it out but not adding any new restriction or enabling new behaviors.
Regards Patrice Hi, all: I have taken into feedback and offline discussion into account and uploaded the latest revision as r1 at: Please continue to share any thoughts/feedback you may have.
Hi, all: I have uploaded a CR document below 4121, 4719, 4767, 4775, 4779, 4780, 5348, 5728, 5775, 5887, 7471 Please review and share your comments in the thread or to me. Thank you and happy holidays! 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
|