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:
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.
[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
Many thanks for kicking this effort off! My comments attached.
------------------------------------------------------------------
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
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,
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