Re: [STDS-802-11-TGBE] Discussion on 11-21/1224 CC 36 CR for Restricted TWT Setup

[Muhammad Kumail Haider <kumail.ieee@xxxxxxxxx>]

Hi Jarkko,

Thanks for your comments. Please see my responses inline.

On Sep 30, 2021, at 9:10 AM, Jarkko Kneckt <jkneckt@xxxxxxxxx> wrote:

Hi Kumail,

thank you for your submission and taking the questions/comments.

All operations of TWT Recommendation value 5 flow are possible with a value 4 flow. I am wondering why we need the value 5 option? 

[MKH]: Proposed text in 1224r6 (SC 35.7.4.1) specifies: "If Trigger frame(s) are addressed to an r-TWT scheduled STA by an r-TWT scheduling AP in a restricted TWT service period with Broadcast TWT Recommendation field equal to 5, then at least one Trigger frame shall be an MU RTS TXS Trigger frame with TXOP Sharing Mode subfield equal to 2(#4778).”

This provision is specifically for accommodating STA’s p2p traffic and does not apply to r-TWT SP with Recommendation Value 4.

Another advantage is that such a distinction allows AP to advertise specific schedules in which it is willing to accommodate p2p traffic. For schedules with Recommendation Value 4, the AP will accommodate r-TWT requests for UL/DL traffic only.

- P2P transmissions have own clock that synchronize these transmissions. It is very hard to synchronize the AP clock and the P2P clock. 

Using rTWT for p2p does not require clock level synchronization or time synchronization. The peer-to-peer link would have to manage its schedule (which can be done at large granularity level) to benefit from the AP assisted approach. If the schedule doesn’t fit, STA can choose not to setup r-TWT for its p2p.

- The UL and DL TID limitations allow AP to dictate what traffic is transmitted in the rTWT SP. This is causes poor SP utilization, complicates STA scheduling and degrades overall QoS. 

UL/DL TID bitmaps identify which traffic is deemed latency sensitive, which is desired to be delivered with higher priority and is the key reason an r-TWT is setup. I fail to see how prioritizing this traffic in r-TWT would degrade overall QoS? Regarding your concern about poor SP utilization,  current r-TWT spec does not limit/restrict transmissions within an r-SP to latency sensitive TIDs only. How traffic is prioritized within an r-SP is ongoing discussion in the group (21/1115); however, that is beyond the scope of this doc (setup).

Moreover, the UL and DL TID bitmaps are not strictly dictated by the AP. These are indicated during r-TWT setup for latency sensitive traffic identification and a STA can also indicate these TIDs in the r-TWT Request.

Regards,

Kumail.

Cheers,

Jarkko 

<Screen Shot 2021-09-30 at 08.23.30.png>

On Sep 30, 2021, at 08:18, Muhammad Kumail Haider <kumail.ieee@xxxxxxxxx> wrote:

Hello all, 

Following up on the discussion in today’s call. There were several people still in the queue; I noted Rubayet, Jarkko, Guogang, Liwen, Liangxiao, Stephane and Qi. Please let me know your comments/questions and appreciate the feedback!

Kumail.

On Sep 29, 2021, at 5:30 PM, Muhammad Kumail Haider <kumail.ieee@xxxxxxxxx> wrote:

Hello all,

I received several comments since Rev.4 was posted and had offline discussions as well. Based on feedback, the doc is updated to Rev.6 11-21/1224 CC 36 CR for Restricted TWT Setup. Please review and let me know if there are any further comments/questions. 

Best regards,

Kumail

On Sep 20, 2021, at 12:44 PM, Muhammad Kumail Haider <kumail.ieee@xxxxxxxxx> wrote:

Hello all,

I have updated 11-21/1224 CC 36 CR for Restricted TWT Setup to Rev.4 based on feedback from the group and offline discussions. Please let me know if there are any further comments/questions. 

Best regards,

Kumail

---

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