| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
| Hi Sangho, Thanks for your review and comments. Please see my responses inline. Please note that your comments for P5 and P6 are about text that has already been motioned in based on earlier revision of this document. I have responded, and if you have further comments we can resolve them in D2.0. Kumail. [MKH]: Baseline spec in 11ax defines bTWT operation between TWT scheduling AP and TWT scheduled STA, so r-TWT scheduling AP is the correct usage. Please refer to 26.8.3.
[MKH]: This text only specifies that if any TIDs are indicated in the UL/DL TID bitmaps, then those indicated TIDs should have to be mapped to the corresponding link, which follows from the TID to link mapping rules. It is possible for AP/STA to not specify any TIDs in these bitmaps, and set the corresponding TID Bitmap valid subfields in TWT Traffic Info Control to 0. In that case all TIDs mapped to link will be considered as latency sensitive for that r-TWT schedule. Please refer to corresponding field definitions in 9.4.2.199 in 11beD1.4. I think we should not exclude the unsolicited response method to setup rTWT as it is allowed in bTWT and may be useful in certain scenarios. For example, a STA may be re-associating/switching link where it already had some r-TWTs setup previously with the AP where it indicated TIDs. So AP will have this knowledge, and to reduce signaling, AP can send an unsolicited TWT response. It may have use cases in enterprise WLANs as well.
[MKH]: See above comments. To clarify, it is not necessary for STA to always indicate TIDs. But if it does, they should have to be mapped to the corresponding link on which the TWT agreement is being set up.
[MKH]: Baseline specifies this subfield as reserved when transmitted by a TWT scheduled STA, and only AP can set them. This is used to constrain certain type of frames by AP (please see Table 9-339 in baseline). We defined value 4 (and 5 in this proposal) as r-TWT schedule so STA needs to identify such schedules. So we propose to not change baseline for bTWT schedules (reserved/0), whereas allow r-TWT scheduled STA to indicate value 4/5. Please also see Q/A on Liwen’s comments in the same thread. [MKH]: Please note the definition of Broadcast TWT Recommendation value 5 in Table 9-339. It specifies that such schedule supports UL/DL as well as p2p for r-TWT traffic prioritization. So UL/DL traffic is allowed in Recomm value 5. This sentence was added on request of a member to clarify how to signal for a schedule for p2p only. So if no UL/DL TIDs are indicated, it refers that only p2p traffic will be prioritized in this special case. TXOP sharing happens with sending of MU-RTS TXS Trigger frame, so this provision applies to trigger-enabled TWT only. For non-trigger enabled TWT, it is not required for AP to send any trigger frame, including the MU RTS TXS Trigger frame.
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 |