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

Re: [STDS-802-11-TGBE] Please review 11-23/847r2 (deferred CIDs)

Hi Chunyu,

 

For CID 16285, I would prefer running a SP to either have a Note or reject the CID.

As Abhi wrote during last teleconf meeting (on another subject), “ a note is a recommendation - it gives flexibility to implementations”.

I think the suggested Note falls in that direction.

 

Regards,

Pascal

 

From: Chunyu Hu <chunyuhu07@xxxxxxxxx>
Sent: mercredi 28 juin 2023 05:57
To: Qi Wang <qi_wang2@xxxxxxxxx>; sunhee.baek <sunhee.baek@xxxxxxx>; VIGER Pascal <Pascal.Viger@xxxxxxxxxxxx>
Cc: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx; Chunyu Hu <chunyuhu07@xxxxxxxxx>
Subject: Re: [STDS-802-11-TGBE] Please review 11-23/847r2 (deferred CIDs)

 

BEWARE: This email originated outside of our organization. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe.
Please report all suspicious emails to the ISS department as an attachment.

 

++ 

 

Qi and all:

 

For CID 16146, it seems to me that the best way is to remain the status quo and reject the comment, given various attempt made to propose a way or the way to figure out what quiet intervals are overlapping and hence can be ignored. 

 

For CID 16285, I am okay to reject unless there is objection. We could run a SP if there is strong opinion to give it a try.

 

Thx.

Chunyu

 

 

On Tue, Jun 27, 2023 at 11:23 AM Qi Wang <qi_wang2@xxxxxxxxx> wrote:

Hi Chunyu and all, 

 

CID-16146

In the last round of the 11be comment resolutions, we discussed the same issue raised by CID-16146.  

 

One solution that was discussed is to specify in 11be that: an EHT AP shall not scheduled an quiet interval that is not an overlapping quiet interval to have a duration of 1 TU.   The rational is 1 TU is too short to be useful for channel measurement.  

 

It would be great if anyone who has concerns for this approach can elaborate your concerns. 

 

 

CID-16285

In 11REVme_D2.0, 9.4.2.22 Quiet element, there is the following text: 

“The Quiet Count filed is set to the number of TBTTs until the beacon interval during which the next quiet interval starts. The value of 0 is reserved.”

 

So, “The value of 0 is reserved” is a legacy behavior, and an AP needs to take this into account when sending the quiet element.  I don’t the following proposed note is needed for 11be. 

 

(#16285)NOTE 2—An R-TWT scheduling AP might transmit Quiet elements in Beacon and Probe Response frames at least one TBTT in advance of the targeted start time of R-TWT SP(s), due to that the value of 0 in the Quiet Count field is reserved as specified in 9.4.2.22 (Quiet element).

 

Regards,

Qi



On Jun 21, 2023, at 8:15 AM, Chunyu Hu <chunyuhu07@xxxxxxxxx> wrote:

 

Hi, all:

 

Thank you for your quick feedbacks.

I've revised the resolution for CID 16285 and will go over CID 16146 in the mtg to see if we can converge.

 

The revised doc is uploaded: 

 

Thx.

Chunyu

 

On Wed, Jun 21, 2023 at 4:27 AM Mark Rison <m.rison@xxxxxxxxxxx> wrote:

> If there are something that I am not considered or people has strong opinion to keep the current proposed text here, I suggest to change “ doesn’t have dot11RestrictedTWTOptionImplemented set to true” to  “has dot11RestrictedTWTOptionImplemented set to false”.

 

There is a potential difference in the situation where the MIB attribute

in question does not exist.  See Subclause 1.4:

 

(#2005)A reference to a value of a MIB attribute of the form “if <MIB attribute> is <x>” is to be interpreted

as though written “if <MIB attribute> is present and is <x>”. A reference to a value of a MIB attribute of the

form “if <MIB attribute> is not <x>” is to be interpreted as though written “if <MIB attribute> is not

present, or is present and is not <x>”.

 

Thanks,

 

Mark

 

--

Mark RISON, Standards Architect, WLAN   English/Esperanto/Français

Samsung Cambridge Solution Centre       Tel: +44 1223  434600

Innovation Park, Cambridge CB4 0DS      Fax: +44 1223  434601

ROYAUME UNI                             WWW: http://www.samsung.com/uk

 

From: 全映桥 (Yingqiao Quan) <yingqiao.quan@xxxxxxxxxx>
Sent: Wednesday, 21 June 2023 10:34
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] Please review 11-23/847r2 (deferred CIDs)

 

Hi Chunyu,

 

Thanks for your document.

 

There are some minor concern for the proposed text of CID# 16146.

1.  What is the definition of “the Broadcast TWT advertising Management frames” ? Does it refer to Beacon, Probe/(re)Association Request/Response frames? It might be clarified.

2.  IMO, how does the non-AP EHT STAs that don’t support R-TWT recognize the overlapping quiet is implementation dependent and is out of the scope of this standard, so we may just simply point it out.

3.  If there are something that I am not considered or people has strong opinion to keep the current proposed text here, I suggest to change “ doesn’t have dot11RestrictedTWTOptionImplemented set to true” to  “has dot11RestrictedTWTOptionImplemented set to false”.

 

16146

SunHee Baek

35.8.5.2

621.10

In R-TWT, overlapping quiet interval sets 1 TU to guarantee R-TWT SP, but the current spec doesn't support any method for non-AP EHT STAs that don't support R-TWT to ignore overlapping quiet interval.

Please specify how non-AP EHT STAs that don't support R-TWT may behave as if overlapping quiet intervals do not exist.

Revised. An EHT non-AP STA can still choose to parse the TWT element to extract R-TWT info and choose to ignore overlapping intervals as an example. Add a NOTE.

 

TGbe editor: please revise as specified in this doc {11-23/847r2} tagged by #16146.

 

(#16146)NOTE3—An EHT non-AP STA that is not a member of an R-TWT SP or that doesn’t have dot11RestrictedTWTOptionImplemented set to true might parse the TWT element in the Broadcast TWT advertising Management frames and decide whether an quiet interval is an overlapping one and decide whether to ignore it.

 

 

BR，

 

Yingqiao Quan

Communication Standards Devision

 

<image001.png>

 

 

发件人: Chunyu Hu <chunyuhu07@xxxxxxxxx>
发送时间: 2023年6月21日 13:30
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: [STDS-802-11-TGBE] Please review 11-23/847r2 (deferred CIDs)

 

注意: 这封邮件来自于外部。除非你确定邮件内容安全，否则不要点击任何链接和附件。
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

 

Hi, all:

 

We deferred a few CIDs in presenting 11-23/847r1. Would the folks requesting the deferral or comments please review and/or share any further thoughts you may have on the CIDs below?

16700, 16701: @Yonggang Fang 

15935, 16652: @Gaurang Naik 

16678: @Qi Wang 

16420, 16424: @Jeongki Kim 

15834, 17090: revised per discussion in mtg. @Mark Rison @Rubayet Shafin would you please review?

 

Let me know if I miss any. Thx!

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

 

 

<noname.png>

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