| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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>
Hi Chaoming, Thanks for the comments. Please find my replies below. Best Regards, Liwen From:
罗朝明(Chaoming Luo) <luochaoming@xxxxxxxx>
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>
Hi Laurent, I fixed the updated text for the first comment. Best Regards, Liwen From: Liwen Chu
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>
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>
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>
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.
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
--------------------------------------------------------------------- This e-mail and any attachments may contain confidential material for 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 |