| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Tomo,
Thanks for the email.
Please see inline.
Best,
Giovanni
From: tomoko.adachi.b99@mail.toshiba <tomoko.adachi.b99@mail.toshiba>
Sent: Thursday, June 25, 2026 19:48 To: Giovanni Chisci <gchisci@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx> Subject: RE: Request agenda time for presenting 25/1939 Co-RTWT Part 4 WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
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.
[GC] Thanks, I think that we do not need to specify alternative setting rules for that field. If that 'Dyration Unit' field is functional to interpret a 'Duration', but there is no indicated 'Duration' I think the setting of that field is irrelevant. I am not
convinced that we need to specify that the 'Duration Unit' field has to be specified to be reserved under HG RTW. But curious to hear other members' opinions on this. This can discussion can progress also in parallel and I believe it should not halt the resolution
of the CIDs.
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.)
[GC] Doesn't look like other granularities are precluded in the future. In fact, there are still 4 available bits that in future amendments can be used as 'Granularity extension part 2'.
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? [GC] The sentence is there to clarify that non-UHR STA interpret always as 'Nominal Minimum TWT Wake Duration field'. For UHR STA, need to see also 37.x (High granularity (HG) RTWT) subclause. I updated the text to clarify this aspect.
l How do you read “HG”? Better to change “a HG …” to “an HG …”?
[GC] modified 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 …”
[GC] done
l I wonder why HG RTWT is not specified under 37.14.2.4, 37.14.2, or 37.14, but just under 37. [GC] It is not a MAPC scheme per se, but an enhancement of RTWT. If there is a desire of the group to move it we can entertain at a later stage, but I would avoid it at this time for stability. 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 https://mentor.ieee.org/802.11/dcn/25/11-25-1939-05-00bn-lb291-cr-for-cortwt-part4.docx
@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. https://mentor.ieee.org/802.11/dcn/25/11-25-1939-04-00bn-lb291-cr-for-cortwt-part4.docx
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 |