| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Giovanni,
I have not been in the discussion, but please allow me to provide some comments on your 25/1939r5:
l
When Nominal Minimum TWT Wake Duration/UHR Target Wake Time Extension field is used as UHR Target Wake Time Extension field, Wake Duration Unit field is no longer used,
but I don’t see how it will be set in this case (expecting that Wake Duration Unit field will be set to 0, not meaning the unit is 256 us but meaning reserved). Just in case to avoid a future compatibility issue, I think it should be specified.
l
The proposed way of defining the fields seems to eliminate the possibility of any other granularity other than 64 us or 1TU in the future. Is this OK? (Just want to
confirm this is the group’s direction.)
l
In p.13, where the first paragraph is changed, it says “For a non-UHR STA, the Nominal Minimum TWT Wake Duration/UHR Target Wake Time Extension field of the Broadcast
TWT Parameter Set field is the Nominal Minimum TWT Wake Duration field.” But a UHR STA not supporting the UHR HG RTWT will interpret this field as the Nominal Minimum TWT Wake Duration field as well. Correct? No need to add such description?
l
How do you read “HG”? Better to change “a HG …” to “an HG …”?
l
Last sentence just before 37.14.2.4.3 in p.18, “… the TSF timer of the HG RTWT AP that transmit the …”
à “… the TSF timer of the HG RTWT AP that transmits the …”
l
I wonder why HG RTWT is not specified under 37.14.2.4, 37.14.2, or 37.14, but just under 37.
Best regards, tomo From: Giovanni Chisci <00002b657bbbbed7-dmarc-request@xxxxxxxxxxxxxxxxx>
[Co-RTWT TTT - Part 4 r5 uploaded - please review] Dear all, uploaded r5 with revision number alignment @Guoyuchen (Jason Yuchen Guo),
@Cariou, Laurent,
@Liwen Chu,
@Abhishek Patil, since you had made comments during the call on the client capability for HG RTWT, please engage in discussion
so that we can run the SP on Monday. My recommendation is to keep the client capability since more than one member had strong concerns in mandating that a UHR STA that supports EHT RTWT also shall support
the UHR HG RTWT. On the technical aspects, while it is important to represent the coordinated AP's RTWT SP start time in the most accurate way, and have (in the sunny day case) all
clients understanding the start point with the highest possible granularity, if in some cases a set of STAs do not support it, it means that the help to the CoRTWT schedule is to a lesser extent comparatively to the best case, but there is no performance degradation.
There is still flexibility for deployments to use (or not) clients that support the HG RTWT, according to the application requirements. Best, Giovanni From: Giovanni Chisci <00002b657bbbbed7-dmarc-request@xxxxxxxxxxxxxxxxx> WARNING: This
email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. [Co-RTWT TTT - Part 4 r4 uploaded - please review] Dear all, I uploaded a new revision to fix a deletion error. Best, Giovanni From: Giovanni Chisci <gchisci@xxxxxxxxxxxxxxxx> [Co-RTWT TTT - Part 4 uploaded - please review] Dear
@Alfred Asterjadhi Could you please add this document to the agenda? Was presented in May Ad-Hoc, I have incorporated the feedback I received and
I am hereby queueing for SP.
https://mentor.ieee.org/802.11/dcn/25/11-25-1939-03-00bn-lb291-cr-for-cortwt-part4.docx Full list (16 CIDs): 4133
4134 5092 8114 8115 8116 9375 10041 10042 11379 11380 11682 11960 11962 12041 12042 To the Co-RTWT TTT, please review and let me know if you have any feedback. Best, Giovanni From: Giovanni Chisci <00002b657bbbbed7-dmarc-request@xxxxxxxxxxxxxxxxx> WARNING: This
email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Dear
@Alfred Asterjadhi, For my part I have the following documents:
Additionally, would kindly request
@Yujian (Ross Yu) to update the 25/1772 to reflect current assignments for following CIDs:
Thank you in advance, Giovanni From: Abhishek Patil <0000297b717f2a04-dmarc-request@xxxxxxxxxxxxxxxxx>
WARNING: This email originated from
outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Hi Alfred,
The contributions will be ready in early July. I will let you know if I have any of them ready sooner.
Regards, From: Alfred Asterjadhi <asterjadhi@xxxxxxxxx>
WARNING: This email originated from
outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Hello all, Please consider this as a gentle reminder for the deadline below: " Please make sure that you send a CR submission request
no later than June 5th, 2026, anywhere on earth (AOE)
" Regards, Alfred On Fri, May 29, 2026 at 8:36 AM Alfred Asterjadhi <asterjadhi@xxxxxxxxx>
wrote:
-- Alfred Asterjadhi, PhD IEEE802.11 TGbe/TGbn Chair, Qualcomm Technologies Inc. Cell #: +1 858 263 9445 Office #: +1 858 658 5302 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 |