Thanks Yongho. Inline. Updates in a subsequent revision.On Thu, Jul 24, 2025 at 5:54 PM Yongho Seok <yongho.seok@xxxxxxxxx> wrote:Hi Alfred,
A UHR non-AP STA, which has enabled any of the operation modes that requires an ICF from the associated UHR AP (i.e., eMLSR,
DPS,DSO, NPCA, or DUO), is not expected to set the UL MU Disable subfield to 1 in transmitted OM Control subfields because any UL MU Disable field set to 1 sent by the non-AP STA is ignored by the AP if the non-AP STA has enabled any of these modes since the AP is required to send ICFs to the non-AP STA in order to operate in any of these modes.
I agree that eMLSR and DUO modes require an ICF from the associated UHR AP. However, for DPS mode with ICF Required set to 0, there is no ICF requirement from the associated UHR AP. For frame exchange in HC mode, ICF is required, but the AP can still send frames in LC mode without using ICF. In this case, if the STA sends the UL MU Disable, it can be interpreted as the AP being limited to LC mode exchange only.
Another point is that DPS can use RTS as the ICF (i.e., when the DPS Padding Delay is set to 0). In such cases, regardless of the UL MU Disable setting, RTS/CTS can still serve as ICF/ICR. I suggest removing DPS for now.[AA] I can say DPS with nonzero padding. Does that work?Please also add the the following. In 437r18, the UL MU Data Disable RX is mandated on the AP side as a supplement to the UL MU Disable constraint in DUO. However, since the same rules are extended to other features, the UL MU Data Disable RX condition should also be extended.A UHR AP shall set the OM Control UL MU Data Disable RX Support field in the UHR Capabilities element to 1 if the UHR AP has dot11DUOOptionImplemented equal to true, dot11EHTEMLSROptionActivated equal to true, dot11UHRDPSAssistingImplemented equal to true, dot11NPCAOptionImplemented equal to true, dot11DSOOptionActivated equal to true.[AA] There are some interdependencies between multiple components on this part. Hopefully we converge soon.It seems the following is a typo. Please remove 'non-AP' unless you alrady fixed.A UHR non-AP STA that sends a PPDU that solicits an acknowledgment or block acknowledgment from a peer UHR STA and that has negotiated Control frame protection with that peer UHRnon-APSTA, shall ensure that the value of[AA] Good catch. Actually i had missed this one. Fixed.Thanks,Yongho2025년 7월 14일 (월) 오전 10:29, Alfred Asterjadhi <asterjadhi@xxxxxxxxx>님이 작성:Thanks Zhenpeng.
Attached some responses. And amendments will appear in the next revision (planning a subsequent upload sometime today).
Regards,
AAOn Mon, Jul 14, 2025 at 3:05 AM Shizhenpeng <shizhenpeng1@xxxxxxxxxx> wrote:Hi Alfred,
Thank you for working on the document. Attached, please find my comments.
Regards,
Zhenpeng Shi
From: Alfred Asterjadhi <asterjadhi@xxxxxxxxx>
Sent: Saturday, July 12, 2025 2:16 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] PDT on ICF/ICR and CRF for multiple modes
Thanks for the review and please find attached some responses. Amendments in next revision.
Regards,
AA
On Thu, Jul 10, 2025 at 7:55 PM insun.jang <insun.jang@xxxxxxx> wrote:
Hi Alfred
Thanks a lot for working the document.
Attached please find my feedback
Thanks
Best Regards
Insun
From: Alfred Asterjadhi <asterjadhi@xxxxxxxxx>
Sent: Friday, July 11, 2025 4:08 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] PDT on ICF/ICR and CRF for multiple modes
Thanks Kaiying for the detailed review. Please find some responses in the attached file. Rev2 will account for the changes (will keep using green highlights).
Regards,
AA
On Thu, Jul 10, 2025 at 11:42 AM Kaiying Lu <Kaiying.Lu@xxxxxxxxxxxx> wrote:
Hi Alfred,
Thanks for your great work.
Attached please find my comments.
Thanks,
Kaiying
From: Alfred Asterjadhi <asterjadhi@xxxxxxxxx>
Sent: Thursday, July 10, 2025 10:50 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] PDT on ICF/ICR and CRF for multiple modes
External email : Please do not click links or open attachments until you have verified the sender or the content.
Thanks for reviewing Matt.
Ack. Will review the latest of 936rX and account for the changes in the next REV of this document.
Regards,
Alfred
On Thu, Jul 10, 2025 at 10:41 AM Matthew Fischer <matthew.fischer@xxxxxxxxxxxx> wrote:
In the NPCA section for AP, you have a statement that the rules are specified in NPCA, then you have a bullet that says that the AP is not allowed to use RTS or MU-RTS for TXOPs during NPCA, but this contradicts the table agreed to for AP in the consensus document, and it contradicts the existing language in 936rx, both of which allow an MU-RTS to be used in at least some cases.
Matthew Fischer
Nice Guy
Broadcom Inc.
+1 408 543 3370 office
On Thu, Jul 10, 2025 at 10:33 AM Alfred Asterjadhi <asterjadhi@xxxxxxxxx> wrote:
Thanks for the careful review, Gaius. Please find attached some responses. I will upload a REV1 shortly that incorporates all changes so far.
PS: I like the idea below.
Regards,
Alfred
On Wed, Jul 9, 2025 at 6:58 PM Gaius Yao Huang Wee <yaohuang.wee@xxxxxxxxxxxxxxxx> wrote:
Hi Alfred,
Thanks for your work. I have bunch of mostly editorial comments for your consideration. Please see attached.
Regarding “initial response”, I suppose we can still call it “initial Control response” and define it as, e.g., “a frame transmitted in response to an initial Control frame (ICF).”
Best regards,
GaiusFrom: Alfred Asterjadhi <asterjadhi@xxxxxxxxx>
Sent: Wednesday, 9 July 2025 3:10 am
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] PDT on ICF/ICR and CRF for multiple modes
Thanks Mark. Please find inline.
Regards,
Alfred
On Tue, Jul 8, 2025 at 12:06 PM Mark Rison <m.rison@xxxxxxxxxxx> wrote:
Hello Alfred,
I think it should be "initial Control frame" not "Initial Control frame"
(except at the start of a sentence/heading/cell/etc.) or "initial control frame".
[AA] Ack. will apply throughout.
Is "initial response frame" defined somewhere?
[AA] I am not certain. Will double check.
"MU RTS" should be "MU-RTS" throughout.
[AA] Ack.
What are those strange "[2 octets]" etc.?
[AA] Sizes of the fields for the calculation/expectation purposes for UHR.
Thanks,
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
1 Cambridge Square, Cambridge CB4 0AE Fax: +44 1223 434601
ROYAUME UNI WWW: http://www.samsung.com/uk
From: Alfred Asterjadhi <asterjadhi@xxxxxxxxx>
Sent: Tuesday, 8 July 2025 19:46
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] PDT on ICF/ICR and CRF for multiple modes
Hi Michail,
Thanks for reviewing. Responses attached (updated version of the draft with incorporated changes will come up in the next few days).
Regards,
Alfred
On Tue, Jul 8, 2025 at 11:21 AM Michail Koundourakis <m.koundou@xxxxxxxxxxxxxxxxxxx> wrote:
Hi Alfred (and all),
Please see comments in the attached.
Kind regards,
Michail
From: Alfred Asterjadhi <asterjadhi@xxxxxxxxx>
Sent: 04 July 2025 01:38
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBN] PDT on ICF/ICR and CRF for multiple modes
Hi all,
Please find a PDT that aims at bringing clarity on the ICF/ICR and CRF details when multiple modes are enabled:
- https://mentor.ieee.org/802.11/dcn/25/11-25-1071-00-00bn-pdt-cr-for-icf-icr-details-with-multiple-modes.docx
Since this touches the ICF/ICR of multiple modes I would like to ask for a careful review, especially from the POCs of the respective topics:
- Liwen on DPS and eMLSR
- Laurent on DUO
- Matt on NPCA
- Morteza on DSO
- Po-Kai on CFP (REVmf)
- Mohamed on LLI
- Ming on the CRF (I included some spec text in this doc but I believe it should go in 11-25/0910 so please double check)
PS: ICF/ICRs for MAP related topics are not covered in the above doc.
Thanks in advance for the review and happy 4th of July.
Regards,
Alfred
--
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
--
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
--
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
--
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
This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.
--
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
--
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
--
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
--Alfred Asterjadhi, PhDIEEE802.11 TGbe/TGbn Chair,Qualcomm Technologies Inc.Cell #: +1 858 263 9445Office #: +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
--Alfred Asterjadhi, PhDIEEE802.11 TGbe/TGbn Chair,Qualcomm Technologies Inc.Cell #: +1 858 263 9445Office #: +1 858 658 5302
