Thank you for your hard work.
I kind of agree with your resolution regarding non-TB PPDU transmission from a DPS STA.
In addition, if additional padding and the I-FCS field are included in the Basic Trigger frame, ICF/ICR exchange may not be required in advance for the DPS STA to respond with a TB PPDU in HC mode.
I think we need to clarify this in the CR document.
From: 罗朝明(Chaoming Luo) <000015d97e832564-dmarc-request@xxxxxxxxxxxxxxxxx>
Date: Monday, July 21, 2025 at 4:38 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBN] [EXT] [STDS-802-11-TGBN] Tracking TBDs in TGbn D0.3
Hi Liwen,
The “ICF Required” field does not resolve the issue.
Per the text “A DPS assisting AP that intends to perform the frame exchanges with its peer DPS STA with its ICF Required
field equal to 1 in a TXOP by using the DPS peer STA’s operating bandwidth, NSS, MCS shall transmit an ICF frame in a PPDU per the peer DPS STA’s LC mode capabilities to solicit the peer DPS STA’s transition from the LC mode to the HC mode.”
It implies: if ICF Required = 1, the AP could NEVER initiate exchanges with the DPS STA
in LC mode.
Is this what we really want? I think in all the cases a DPS STA can do frame exchanges
in LC mode, we do not need to preclude it. So ICF Requires = 1 does not provide any value.
Per the text “A DPS assisting AP may perform the frame exchanges with its peer DPS STA in a TXOP with or without an
ICF frame if the peer DPS STA has the ICF Required field set to 0.”
It implies: if ICF Required = 0, the AP can solicit the DPS STA to HC mode via ICF, or
if the AP intends to initiate exchanges with the DPS STA in LC mode if the AP does not send ICF.
Since this case is the case all DPS STAs can work, we don’t need such an “ICF Required”
field.
Instead, I think the issue of “how can the AP solicit one DPS STA to HC mode via ICF while trigger another DPS STA
keeping in LC mode” is something we really needs to solve.
BR,
Chaoming
发件人: Liwen Chu <liwen.chu@xxxxxxx>
发送时间: 2025年7月7日 21:36
收件人: 罗朝明(Chaoming Luo) <luochaoming@xxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
主题: RE: [EXT] [STDS-802-11-TGBN] Tracking TBDs in TGbn D0.3
Hi Chaoming,
Thanks for the comments. Please find my replies below.
Best Regards,
Liwen
|
|
Caution: This is an external email. Please take care when clicking links or opening attachments. When in doubt, report
the message using the 'Report this email' button
|
Hi Liwen,
For CID 1767, sounds like you’re proposing to use the ICF-required field to resolve the issue. I think that does not work well.
E.g., when the AP intends to do DL OFDMA with multiple DPS STAs (STA1 with ICF-required quals to 0, others 1), should the AP trigger
STA1 in the ICF? If no, then the AP needs to send another frame to trigger STA1, which brings overhead. If yes, should STA1 switch to HC mode upon receiving this ICF?
A simpler way may be: The AP indicates to the DPS STA in the ICF whether the STA is requested to switch to HC mode or stay in LC mode.
We do not need the ICF-required field.
[Liwen] Per TXOP responder indication whether the TXOP responder will switch to HC mode in ICF requires the indication in the
User Info field. There is reserved bit for such indication currently. Repurposing the current field makes the protocol complicated. For your example, the AP can either solicit STA1 independently or solicit STA1 with the other STAs. The main part of DPS’s power
save is from the low capability listening.
For CID 1776, it’s better to leave to next round since we do not have sufficient discussion on it yet. I’m willing to bring a contribution
for it later.
[Liwen] It seems I got the feedback that the comment should be rejected. We can further it during the F2F meeting.
BR,
Chaoming
Hi Laurent,
I fixed the updated text for the first comment.
Best Regards,
Liwen
Hi Laurent,
Thanks for the comments.
For the comment of “Better wording needed” for ICF Required field, I made the following change. Is the changed text ok to you?
The ICF Required field indicates whether the peer DPS assisting STA needs to transmit an ICF frame to the DPS STA before performing the frame exchanges with the DPS STA in a TXOP. The ICF Required field equal to 1 indicates that
the transmission of the ICF frame to the DPS STA prior to any frame exchange is needed. Otherwise the ICF transmission before the frame exchanges with the DPS STA is not needed.
For the comment of “better name to avoid confusion” about DPS mobile AP, do you have any suggestion? Or is DPS MAP good enough?
For the comment of “Need to cover properly the case of DUO”, the following is what I am thinking
Given that the feature combinations include DUO + DPS, NPCA + NPS, DSO + DPS, DUO + DPS + DSO… It is not appropriate to add the ICF rules under the conditions that more than one of DSO, DPS, NPCA, DUO… in this subclause. I can
work with you and the other people about such rules in a separate sublause if no other person work on it.
I am working with several members on R4 to deal with mobile AP’s ICF Required and under which conditions (mobile AP being the member of multiple BSSID
AP set, or the member of co-hosted AP set, neither of them; mobile AP with padding requirement or not etc.) a mobile AP can enable its DPS mode. The changes related to your comments will be incorporated in R4.
Best Regards,
Liwen
|
|
Caution: This is an external email. Please take care when clicking links or opening attachments. When in doubt, report the message using
the 'Report this email' button
|
Hi Liwen,
See attached some comments and rewording suggestions on doc 669r3
Thanks for the good work
Best
Laurent
Hi Alfred,
Please add the following contribution to the MAC agenda
https://mentor.ieee.org/802.11/dcn/25/11-25-1090-00-00bn-cr-cc50-mac-cids-in-clause-9-4-1-85.docx
I will upload my other contributions by the end of this week.
Best Regards,
Liwen
|
|
Caution: This is an external email. Please take care when clicking links or opening attachments. When in doubt, report the message using
the 'Report this email' button
|
Hello all,
I ported the table that Ross prepared to our teleconference agenda and am tracking with requests and progress in the CR stage. POCs, please help populate the missing rows.
Tracking of TBDs in TGbn D0.3.
|
Clause
|
Topic
|
PoC
|
TBDs
|
Notes
|
|
Clause 6
|
|
Yan Li
|
6
|
|
|
Clause 9
|
9.2.4.6.4 HE variant
|
Liwen Chu
|
2
|
|
|
9.3.1.22 Trigger frame format
|
Alice Chen
|
18
|
|
|
9.4.1.85 DPS Operation Parameters
|
Liwen Chu
|
5
|
|
|
9.4.2.aa1 UHR Operation Element
|
Ming Gan
|
6
|
|
|
9.4.2.aa2 UHR Capabilities element
|
Ming Gan
|
2
|
|
|
9.6.7.69 MAPC Request frame format
|
Arik Klein
|
2
|
Resolved in
11-25/0599r13
|
|
9.6.7.70 MAPC Response frame format
|
Arik Klein
|
2
|
Resolved in
11-25/0599r13
|
|
9.6.10 Protected Dual of Public Action frame details
|
Jay Yang
|
2
|
|
|
Clause 37
|
37.5 Prioritized EDCA
|
Dmitry Akhmetov
|
1
|
|
|
37.6 UHR Acknowledgement Procedure
|
Ming Gan
|
1
|
Ack procedure for ELR
|
|
37.14 SMD BSS transition
|
Duncan Ho
|
14
|
|
|
37.15 Power management
|
Liwen Chu
|
17
|
|
|
37.16 Non-primary channel access (NPCA)
|
Matthew Fischer
|
16
|
|
|
37.17 Unavailability reporting and parameter updates
|
Laurent Cariou
|
37
|
37.17.2: Resolved in
25/437 (Laurent)
37.17.3, 37.17.4: Resolved in
25/508 (Laurent)
37.17.5: Resolved in
25/744 (Sherief)
|
|
37.20 Padding for an ICF
|
Liwen Chu
|
1
|
|
|
37.22 Low Latency Indication
|
Mohamed Abouelseoud
|
3
|
|
|
Clause 38
|
38.3.5 Interference mitigation
|
Shimi Shilo
|
13
|
|
|
38.3.16.8 Pilot subcarriers
|
Chenchen Liu
|
5
|
|
|
38.3.22 Coordinated spatial reuse
|
Jason Yuchen Guo
|
1
|
|
|
Annex C
|
|
Yan Li
|
1
|
|
|
|
Total
|
|
155
|
|
Regards,
AA
--
Alfred Asterjadhi, PhD
IEEE802.11 TGbe/TGbn Chair,
Qualcomm Technologies Inc.
asterjadhi@xxxxxxxxx
aasterja@xxxxxxxxxxxxxxxx
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
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: 90-92 route de la Reine, 92100 Boulogne, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 5 208 026.16 Euros
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
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