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 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

 

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).

 

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

a)      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

b)      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).

c)      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.

 

 

Thanks everyone!

Kerstin

 

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

You don't often get email from yaohuang.wee@xxxxxxxxxxxxxxxx. Learn why this is important

 

 

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.

 

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).

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).

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.

 

Best regards,
Gaius

 

From: Giovanni Chisci <00002b657bbbbed7-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Saturday, 16 November 2024 1: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:

 

https://mentor.ieee.org/802.11/dcn/24/11-24-1966-00-00bn-pdt-mac-crtwt.docx

 

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:

 

gchisci@xxxxxxxxxxxxxxxx

 

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