| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Chaoming,
Thanks for the comments. Please find my replies below.
Best Regards,
Liwen
From: 罗朝明(Chaoming Luo) <luochaoming@xxxxxxxx>
Sent: Monday, July 7, 2025 1:02 AM
To: Liwen Chu <liwen.chu@xxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: RE: [EXT] [STDS-802-11-TGBN] Tracking TBDs in TGbn D0.3
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
发件人: Liwen Chu <liwen.chu@xxxxxxx>
发送时间: 2025年7月4日 7:04
收件人: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBN] [EXT] [STDS-802-11-TGBN] Tracking TBDs in TGbn D0.3
Hi Laurent,
I fixed the updated text for the first comment.
Best Regards,
Liwen
From: Liwen Chu
Sent: Thursday, July 3, 2025 12:38 PM
To: Cariou, Laurent <laurent.cariou@xxxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: RE: [EXT] [STDS-802-11-TGBN] Tracking TBDs in TGbn D0.3
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
From: Cariou, Laurent <laurent.cariou@xxxxxxxxx>
Sent: Monday, June 30, 2025 1:06 PM
To: Liwen Chu <liwen.chu@xxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: RE: [EXT] [STDS-802-11-TGBN] Tracking TBDs in TGbn D0.3
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
From: Liwen Chu <liwen.chu@xxxxxxx>
Sent: Monday, June 30, 2025 6:26 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] [EXT] [STDS-802-11-TGBN] Tracking TBDs in TGbn D0.3
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
From: Alfred Asterjadhi <asterjadhi@xxxxxxxxx>
Sent: Thursday, June 12, 2025 2:09 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: [EXT] [STDS-802-11-TGBN] Tracking TBDs in TGbn D0.3
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.
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 EurosThis 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