Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-TGBE] 11-21/0683 | CID 2215

Noted. Thanks for calling this out for attention.

Xiangxin, I went through the r2 document and haven't seen any instance of using the "EHT non-AP STA". But if I missed anything, please point it out.

Thanks.
Chunyu

On Mon, May 3, 2021 at 5:01 AM Edward Au <edward.ks.au@xxxxxxxxx> wrote:
Hi Xiangxin, Chunyu,

For the sake of consistency with respect to the majority of the similar terms in P802.11REVme D0.0, please kindly use non-AP EHT STA.

Thanks,
Edward 

On Mon, May 3, 2021 at 4:21 AM 顾祥新 (Xiangxin Gu) <Xiangxin.Gu@xxxxxxxxxx> wrote:

Hi Chunyu,

 

Thanks for the contribution.

I noticed there are two terminologies: non-AP EHT STA and EHT non-AP STA in D0.4.

Should we select one?

 

Xiangxin

 

From: Chunyu Hu <chunyuhu07@xxxxxxxxx>
Sent: Monday, May 3, 2021 2:17 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 11-21/0683 | CID 2215

 

Thanks Stephane, and other commenters.

 

Please find the revised version uploaded to the server:

 

Thanks.

Chunyu

 

On Thu, Apr 29, 2021 at 5:01 AM BARON Stephane <Stephane.BARON@xxxxxxxxxxxx> wrote:

Hi Chunyu,

 

Thank you for your explanations.

Concerning the comment resolution, I agree that limiting an overlapping quiet interval to 1TU (= 1ms) seems to reduce the negative impact on the fairness.

But it is very difficult to evaluate this impact without considering the duration of the rTWT itself.

Typically, if the duration of the rTWT is around 1ms, I do not see a significant fairness progress if we limit the overlapping quiet element to the same duration.

 

For the NAV protection, even if the AP can do it, I think additional mechanism should be put in place to allow station with latency sensitive traffic to efficiently use the rTWT protected by NAV. But I agree that this not in the scope of the TBDs , so I will prepare a text to cover this subject, linked to the part of our 11-20/1843r1 document that is not covered by your 11-21/683 document.

 

Regards.

 

Stéphane.

 

From: Chunyu Hu <chunyuhu07@xxxxxxxxx>
Sent: jeudi 29 avril 2021 07:51
To: BARON Stephane <Stephane.BARON@xxxxxxxxxxxx>
Cc: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 11-21/0683 | CID 2215

 

Hi, Stephane:

 

The development of this text is inline with a few things taken into consideration:

1) the motion introduced the TBD rules to quiet intervals usage on a few concerns. One is that it creates unfairness to legacy STAs. Maybe Qi can chime to comment more on this.

2) the rule for rTWT supporting ETH STA is that it will stop its txop to go across the boundary of rTWT SP, and as such, it doesn't need to obey such overlapping quiet intervals to stay quiet during the quiet interval. This is in the motion as well.

3) the rule for rTWT non-supporting EHT STA is that they can ignore such overlapping quiet intervals. Of course, as you pointed out, the EHT STA would have to parse both rTWT SP info and quiet intervals to know the nature/intention of quiet interval. This is also agreed per motion.

 

The effort in this proposed CR is to limit the part that the quiet interval's effect on legacy STA vs on EHT STA, which reflects the input we collected from those active motion contributors and commenters, is to limit the quiet interval duration to its minimum, that is, 1 TU.

 

I agree the NAV protection should be exercised by rTWT STAs similar to the TWT protection field as defined in the individual TWT case. This, even without definition, can be done by rTWT scheduling AP/scheduled STA and they have incentive to do so. This'll be in the part of the general channel access rule if wish to be spelled explicitly, however, but not this TBD scope. The CR does capture the commenter's input and agreement and we think it's proper to think this draft text also served as its resolution.

 

Thanks.

Chunyu

 

 

 

On Mon, Apr 26, 2021 at 9:42 AM BARON Stephane <Stephane.BARON@xxxxxxxxxxxx> wrote:

Hi Payam,

 

Thank you for preparing the resolution of the CID2215.

As far as I understand, the proposed resolution is to remove the exception authorizing the EHT STA to ignore the quiet elements that are dedicated to the protection of the rTWT.

But the last sentence of the document you propose (683r0) mentions the contrary :  “Non-AP EHT STAs may behave as if such overlapping quiet intervals do not exist.”

So I don’t see how the proposed text solves the fairness issue raised by the CID between legacy and EHT stations.

 

More generally, I think the spirit of your resolution goes against the idea that the support of the low latency feature is optional for the EHT STA.

At least the EHT STA will have to decode and store the information of all the quiet elements that will be put in place to protect recurrent rTWT periods.

Despite legacy stations, EHT station cannot ignore that a lot of quiet elements can be present and shall then be able to support it.

 

I think that to solve the problem of fairness raised by the CID2215, we should rather think to an optional mechanism put in place or not by the AP (depending on the type of stations associated to it) to reserve the medium in a way that will be fair for both legacy and EHT STAs.

I think the best solution would be to rely on NAV protection that can easily be put in place by  an AP reserving the medium prior the start of the rTWT period.

 

Let me know you opinion.

 

Best regards.

 

Stéphane.

 

 

From: Payam Torab <torab@xxxxxxxx>
Sent: jeudi 22 avril 2021 17:08
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 11-21/0683 | CID 2215

 

Hi Alfred,

Could you please add 11-21/0683 to the comment resolution agenda. This submission attempts to resolve a TBD. Targeted CID per title.

 

 

Hello all,

This is a contribution to expand TBD rules for scheduling quiet intervals to protect restricted TWT SPs, and also announcing them. Your comments much appreciated.

 

Regards,
Payam

 

https://mentor.ieee.org/802.11/dcn/21/11-21-0683-00-00be-restricted-twt-quiet-interval-tbd-cr.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

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