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

Re: [STDS-802-11-TGBN] PDT MAC CR-TWT

Hi Giovanni,

 

Thanks for the effort on PDT.

I think that “APs in the same neighborhood that belong to different BSSs” is different to “OBSS APs”.

“APs in the same neighborhood that belong to different BSSs” does not mean overlapped operating channel and overlapped coverage.

 

BR,

 

Xiangxin Gu

Communication Standards Devision

 

 

From: Kerstin Johnsson (Nokia) <000039130cefe96b-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Thursday, December 5, 2024 9:01 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] PDT MAC CR-TWT

 

Hi Giovanni et. Al,

 

Please find my edits/comments into the updated, clean draft.

 

Some highlights:

-        The wording is quite difficult to follow (even for a native speaker). I realize this is “par for the course” w/ specifications, but there is still room for improvements.  I’ve tried to make the wording more concise to make reading the text easier.

-        In Co-R-TWT, an AP “extends protection to” another AP’s SPs.  It does not “extend the protection for” those SPs. 

The former wording (which I’ve inserted into the draft in all relevant locations) implies that protection is being “newly offered/provided”, where it did not exist before.  The latter (which was originally used) implies that protection already exists and is simply “being prolonged”.

-        You’ll see that I re-ordered the discussion of “responding AP” and “coordinated AP”.  Again, I don’t see why you’d discuss “coordinated AP” before discussing “responding AP” – that’s putting the cart before the horse.  An AP must first respond before it can be coordinated.  So, it makes sense to discuss it in that order. 

 

BR,

Kerstin

 

 

From: Giovanni Chisci <00002b657bbbbed7-dmarc-request@xxxxxxxxxxxxxxxxx>
Date: Tuesday, December 3, 2024 at 02:37
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBN] PDT MAC CR-TWT

 

CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.

 

Proposed Draft Text for CR-TWT

 

Dear Brian, John, and all,

 

Thanks for the continued effort for improving the CR-TWT PDT!

 

This email:

  • closes the first round of comments on r1_Draft_v00 (find attached a response to Brian, I provide also a response to John’s suggestions inline)
  • kicks off the second round of comments on r1_Draft_v01 (please provide comments and edits in track change on the attached r1_Draft_v01_Clean)
    • Please provide comments on r1_Draft_v01 by Wednesday 12/04 at 5pm Pacific time – in about 48h from now (I target to upload a hopefully stable r1 on Mentor by Friday 12/06 COB)

 

A few highlighted issues from the comments that I would like to collect opinions on are the following:

  • Name of the feature: Currently I am using CR-TWT, there have been proposals to have an additional hyphen as in C-R-TWT, and to use “Co” as in CoR-TWT or Co-R-TWT. Granted that it is not urgent (we can replace all the occurrences easily), I would like to hear member’s opinions on this.
  • Organization of the subclauses: currently CR-TWT is a 37.x clause, and the assumption that there will be another clause for M-AP coordination framework (e.g., 37.y). A comment discussed on whether CR-TWT clause should be a subclause (e.g., 37.y.x) of M-AP coordination framework clause (e.g., 37.y). Also this is not extremely urgent, but we can keep this in mind as we see how the M-AP coordination framework clause evolves (in its own TTT discussion).

 

Thank you in advance,

Giovanni Chisci (QC)

 

From: Brian Hart (brianh) <00000c7561051aea-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Sunday, December 1, 2024 9:55 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] PDT MAC CR-TWT

 

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hi Giovanni

 

Many thanks for your detailed work! Some quick responses on the old document threads and also on the new document.

 

Best wishes

Brian

 

 

From: Wullert, John R II (PERATON LABS) jwullert@xxxxxxxxxxxxxxx
Sent: Monday, November 25, 2024 1:20 PM
To: Giovanni Chisci gchisci@xxxxxxxxxxxxxxxx; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBN] PDT MAC CR-TWT

 

Giovanni,

  Thanks for the continued coordination!

 

One comment:

  • In the last paragraph of Clause 37.x.2 in the latest draft, you refer to a CR-TWT responding AP following the rules to “establish or teardown agreement(s)”.  Given the definitions, it makes sense that a CR-TWT responding AP would follow the rules to establish agreements, but shouldn’t it be the CR-TWT coordinated AP that is responsible for tearing down agreements?  (While they refer to the same device, the definitions represent different states of that device.  In addition, restricting teardown to the CR-TWT responding AP seems to suggest that only the CR-TWT requesting AP can initiate the teardown process, which I don’t think has been decided.)

[GC] Thanks for the good point. For the time being I decided to remove everything related to teardown (since it has not been discussed yet). That being said I think that AP2 (the one that is extending the protection for an R-TWT of AP1) changes state from CR-TWT responding AP to CR-TWT coordinated AP on a per schedule (per agreement) basis, so I am in agreement with you that once we define “tearing down” agreements, AP2 would be an action as a “CR-TWT coordinated AP”.

John

 

Cisco Confidential

From: Giovanni Chisci <00002b657bbbbed7-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Friday, November 22, 2024 4:21 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] PDT MAC CR-TWT

 

Proposed Draft Text for CR-TWT

 

Dear Gaius, Brian, Kumail, Kerstin, and all,

 

Thanks a lot for providing the initial set of comments. They were very useful to provide the new draft for r1.

 

This email:

  • Includes Word documents including the PoC responses based on the received comments on r0 on separate documents (from Brian and Kumail)
  • Unify the thread since I noted a branching out between text suggestions directly on email thread (Gaius and Kerstin) and suggestion on Word documents (Brian and Kumail).
  • Replies inline to the suggestions made directly on this thread.
  • Provides two new documents (r1_Draft_v00_Clean and r1_Draft_v00_Redline) for the new round of comments collection kicked off by this email.

 

Please keep providing comments on r1_Draft_v00_Clean.

I’ll keep updating the r1 Draft by increasing the version count at each round (e.g., next round will be kicked off with new r1_Draft_v01), until the draft is stable for upload. The next round will be kicked off as soon as there are a sufficient number of comments on r1_Draft_v00_Clean.

 

Best,

Giovanni

 

 

From: Kerstin Johnsson (Nokia) 000039130cefe96b-dmarc-request@xxxxxxxxxxxxxxxxx
Sent: Friday, November 22, 2024 3:09 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] PDT MAC CR-TWT

 

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hi Giovanni et. al,

 

I had similar (and in some cases the same) edits as Gaius.  I will copy paste his changes here with my additional changes inserted:

 

37.x.1 General

CR-TWT operation described in this subclause enables APs in the same neighbourhood that belong to different BSSs to:

a) coordinate their R-TWT schedule(s),

b) ensure that one AP extentds the protection for the R-TWT schedule(s) of the other AP.

b) request protection for their R-TWT schedule(s) from other APs

c) respond to requests to protect R-TWT schedule(s) of other APs

[GC] Thanks for the suggestion, I would try to avoid splitting request/response in this part. Please check if the version in r1_Draft_v00 is satisfactory.

A CR-TWT requesting AP is an AP that requests protection for one or more of its R-TWT schedule(s). A CR-TWT responding AP is an AP that responds to a CR-TWT request from another AP, potentially resulting in negotiation of a CR-TWT agreement per the rules defined in 37.x.2 (CR-TWT negotiation). A CR-TWT coordinated AP is an AP that has agreed to provides protection for the requested R-TWT schedule(s) of a CR-TWT requesting AP either by establishing an per a CR-TWT agreement reached through negotiations or other means. A CR-TWT responding AP is an AP that responds to a CR-TWT requesting AP that initiates a CR-TWT negotiation to establish an agreement by following the rules defined in 37.x.2 (CR-TWT negotiations).

[GC] I provided clarifications on this part in r1_Draft_v00, please check if it is satisfactory. I would avoid using the terminology “has agreed” for the CR-TWT coordinated AP, since CR-TWT responding APs are those that make the agreements via negotiations (and then extend the protection), but some others just extend the protection.

[GC] On the swapping places for the definitions of CR-TWT coordinated AP and CR-TWT responding AP, I would still try to keep this order, since the text seems to be clearer if the superset is defined first, and the subset after. Please check the r1_Draft_v00 is satisfactory. Let’s hear also other opinions.

IfWhen a CR-TWT coordinated AP extends the protection of to an R-TWT schedule of a CR-TWT requesting AP, then:

it shall ensure that its TXOPs ends before the start time(s) of the CR-TWT requesting AP’s SP(s) as identified by corresponding to that R-TWT schedule, and

if it has at least one associated non-AP STA that is capable of R-TWT, it shall advertise the R-TWT schedule in the its Beacon frames it transmits that R-TWT schedule so that those STAs also extend protection to the R-TWT per the rules defined in 35.8.4.1 (TXOP and backoff procedure rules for R-TWT SPs).

if it has at least one associated non-AP STA that is capable of R-TWT, it shall advertise the R-TWT in the its Beacon frames it transmits that R-TWT schedule so that its associated non-AP STAs capable of R-TWT also extend protection to supporting R-TWT follow the R-TWT per the rules defined in 35.8.4.1 (TXOP and backoff procedure rules for R-TWT SPs) for that R-TWT schedule.

[GC] Some of the suggestions are implemented. Please check if the version in r1_Draft_v00 is satisfactory.

 

 

Thanks everyone!

Kerstin

 

 

 

 

From: Muhammad Kumail Haider kumail.ieee@xxxxxxxxx
Sent: Thursday, November 21, 2024 11:07 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] PDT MAC CR-TWT

 

Hi Giovanni, thanks for initiating this effort and a great first draft.

 

Please find attached some suggestions and comments.

 

Best,

Kumail.

 

 

 

From: Muhammad Kumail Haider <kumail.ieee@xxxxxxxxx>
Sent: Thursday, November 21, 2024 11:07 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] PDT MAC CR-TWT

 

Hi Giovanni, thanks for initiating this effort and a great first draft.

 

Please find attached some suggestions and comments.

 

Best,

Kumail.

 

To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1

 

 

On Nov 19, 2024, at 11:12 AM, Brian Hart (brianh) <00000c7561051aea-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:

 

Hi Giovanni

 

Many thanks for kicking this effort off! My comments attached.

 

Best wishes

Brian

 

 ------------------------------------------------------------------

 

From: Gaius Yao Huang Wee yaohuang.wee@xxxxxxxxxxxxxxxx
Sent: Monday, November 18, 2024 5:31 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] PDT MAC CR-TWT

 

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hi Giovanni,

 

Thanks for preparing the initial PDT for CR-TWT. I have some editorial suggestions on your current text.

 

37.x.1 General

CR-TWT operation described in this subclause enables APs in the same neighbourhood that belong to different BSSs to:

a) coordinate their R-TWT schedule(s),

b) ensure that one AP extentds the protection for the R-TWT schedule(s) of the other AP(s).

[GC] Agreed, updated

A CR-TWT requesting AP is an AP that requests protection for one or more of its R-TWT schedule(s). A CR-TWT responding AP is an AP that responds to a CR-TWT requesting AP that initiates a CR-TWT negotiation to establish an agreement by following the rules defined in 37.x.2 (CR-TWT negotiations). A CR-TWT coordinated AP is an AP that provides protection for the requested R-TWT schedule(s) of a CR-TWT requesting AP either by establishing an agreement through negotiations or by other means. A CR-TWT responding AP is an AP that responds to a CR-TWT requesting AP that initiates a CR-TWT negotiation to establish an agreement by following the rules defined in 37.x.2 (CR-TWT negotiations).

[GC] On the swapping places for the definitions of CR-TWT coordinated AP and CR-TWT responding AP, I would still try to keep this order, since the text seems to be clearer if the superset is defined first, and the subset after. Please check the r1_Draft_v00 is satisfactory. Let’s hear also other opinions.

 

IfWhen a CR-TWT coordinated AP extends the protection of an R-TWT schedule of a CR-TWT requesting AP, then:

a) it shall ensure that its TXOP ends before the start time of the CR-TWT requesting AP’s SP(s) corresponding to that R-TWT schedule, and

b) if it has at least one associated STA that is capable of R-TWT, it shall advertise in the Beacon frames it transmits that R-TWT schedule so that its associated STAs supporting R-TWT follow the R-TWT rules defined in 35.8.4.1 (TXOP and backoff procedure rules for R-TWT SPs) for that R-TWT schedule.

[GC] Agreed, updated. This text is now in dedicated sections.

 

Best regards,
Gaius

 

 

Cisco Confidential

From: Giovanni Chisci <00002b657bbbbed7-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Friday, November 15, 2024 9:11 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBN] PDT MAC CR-TWT

 

Dear CR-TWT TTT members,

 

I hope to find you well.

 

Proposed Draft Text for CR-TWT

 

As POC,I have created an initial PDT document which is 11-24-1966:

 

 

The CR-TWT feature currently (at the end of 2024 November IEEE 802 Plenary Session) has two passing motions.

The initial PDT-MAC-CRTWT document r0 includes proposed text based on this two motions.

As additional motions are passed, we will add to the text in the document.

 

I have taken the author list from the TTT list found in the document

 

11-24-1698-13-00bn-tgbn-d0-1-spec-text-volunteers-and-status

 

If you have volunteered for the CR-TWT TTT, please check the author list of 24/1996r0.

If your name is spelled incorrectly, or is missing an affiliation, or has an incorrect affiliation, or if your name is missing entirely, or if you are in the list and do not wish to be included in the author list, then please send an individual email to:

 

 

to indicate which particular problem exists so that I can update the document.

 

Feel free to send any comments on the existing PDT (i.e. the draft text, not the author list) in 24/1996r0 as a response to this email, so that all TTT members may see your comment and so that we can discuss the comment and then debate any changes to the document. This will be the general process going forward for text that is included in the document. I hope that there is little discussion on the initial text, since it is so high level and there are only a few sentences. If there is a firestorm over these first few sentences, then I will be anxiously awaiting the next passing motion...

 

At some point, the group should pass a few more motions relating to CR-TWT, and when this happens, then we will try to find volunteers to create draft text sections corresponding to those new motions. Depending on the size/complexity of that text, it should appear for discussion within this email thread either as:

 

a) text that is directly included as native text within an email sent to this thread (usually for small text additions/changes)

 

b) text included within a new WORD document that does not need to be an official 802.11 submission or uploaded to the server, since the text on its own will not be subject to a motion, but will only be subject to motion as part of a complete CR-TWT PDT document (i.e. 24/1996rx) - such a document would be sent as an attachment to this email thread for discussion

 

c)  text included within a copy of the 24/1996rx WORD document, showing additions and changes to the existing 24/1996rx doc that again, should not be uploaded to the server, but attached to the email thread.

 

We will try, with any new proposed draft text, to discuss new proposed text within this thread and come to a super-majority regarding such new text (e.g. 75% of the TTT membership, whatever that is). I do not want to use the word consensus, because that implies near unanimous agreement and I feel that such a goal is impractical. But suggesting something like 75% is also problematic, as there is no real defined TTT membership - it is fluid. So there will be a judgement call as to when we should close the debate on any new text; Such a decision will occur when the number of objections quiets down to some small number of members (e.g. <25%, which is currently estimated to be about 15 people - but that too will be a judgement call because someone could invite a dozen of their friends to send an objection to the thread even though they are not listed as TTT members and there probably is nothing that can be done about that). In cases where such quieting does not occur, then we will have to throw the text into TGbn for a straw poll and update our document 1762rx based on that outcome.

 

I hope it will be generally obvious when we can accept text vs when we need to perform an SP in the TG, and I hope that we do not need to frequently submit SPs in the TG or we will never complete a D0.1....

 

P.S.: Many thanks to Matthew Fischer for the initial email that kicked off the discussion for the PDT of the NPCA feature, which has been taken as example to define the process in this thread.

 

Thank you and best regards,

Giovanni Chisci (QC)

 

To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1

To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1

To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1

 

To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1

To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1

To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1

To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1

To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1

To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1