Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Bo, Please see my
inline comments. Thanks, Zinan From: gongbo (E) <gongbo8@xxxxxxxxxx>
Hi, Zinan. Thanks for your valuable comments. The current version can still differentiate SU/MU since the measured PPDU is the most recent received one matching the PPDU Type/beamforming/coding type. And the AP knows the SU/MU of the most recent PPDU it sent to the STA. [ZL] I could not find any texts that specify the measured PPDU is the most recently received one. Subclause 26.13 (Link adaptation using the HLA Control subfield)
in REVme D1.4 does not specify the measured PPDU is the most recently received one. In addition, even it was specified, the channel may not be available for the unsolicited MFB to be transmitted right after the measured PPDU or the transmitter of the unsolicited
MFB can only send the unsolicited MFB when it has the data/frame to send. The indicated NSS/MCS in the unsolicited MFB may not be valid information to the receiver of the MFB when it is received. Do you want to add some time constraint on that? For example,
the unsolicited MFB needs to be sent within the same TXOP of the measured PPDU. Anyway, it looks like we need more time to discuss this issue. I am neutral with the current version. But probably I will bring up this issue during the next
round of comment resolution. Please let me know if the above explanation is good for you, and if you are ok with this CR document. Your further comments are welcome. Thanks. Best regards, Bo Gong (Huawei) 发件人:
Zinan Lin [mailto:Zinan.Lin@xxxxxxxxxxxxxxxx]
Bo, Thanks for your answer. Please see my inline
comments.
Zinan From: gongbo (E) <gongbo8@xxxxxxxxxx>
Hi, Zinan, Thanks for your comments. The response to your comments are labeled in red.
No, we don’t need to consider the solicited MFB case for the figure
[ZL] The reason I asked above question is your previous answer includes the MFB case. That is why I got confused.
2)
I still do not understand how to differentiate the feedbacks between SU MIMO and MU MIMO transmissions using the ELA subfield design in this proposal, especially in unsolicited MFB case. Could you
please elaborate it? For unsolicited feedback, the current text follows 11ax, and doesn't cover/differentiate SU MIMO and MU MIMO transmission. [ZL] In REVme802.11 D1.4 (Fig. 9-29), the HLA
does include different PPDU types in the MSI/Partial PPDU Parameters subfield if the Unsolicited MFB subfield is 1. HE MU PPDU and HE SU PPDU can simply differentiate the measured PPDU was sent to
a single STA or multiple STAs. It gives the receiver of the MFB some good guideline on whether the estimated MCS/NSS is based on SU or MU transmission (although the MU transmission may include MU-MIMO or OFDMA). Best Regards, Bo Gong (Huawei) 发件人:
Zinan Lin [mailto:Zinan.Lin@xxxxxxxxxxxxxxxx]
Hi Bo, Thanks for addressing my comments and presenting 11-22/1317r2. Here are my comments and questions to last your answer. Thanks! Zinan From: gongbo (E) <gongbo8@xxxxxxxxxx>
Hi, Zinan, Your comments are replied in the attached document and it is updated as r2 now. Further discussion is welcome. Best regards, Bo Gong (Huawei) 发件人:
Zinan Lin [mailto:Zinan.Lin@xxxxxxxxxxxxxxxx]
Hi Bo, I have a few comments on 11-22/1317r1 as attached. Please take a look and let me know if you have any question. Best, Zinan From: gongbo (E) <gongbo8@xxxxxxxxxx>
Hi, Zinan, thanks for your reply. As illustrated in the SP#4 in 11-22/1238r2, “Do you agree that 802.11be shall not define operation with more than 8 spatial streams and that the format of all subfields related to spatial streams
shall remain unchanged (i.e. no changing the number of bits)?”, more than 8 spatial streams will not be defined in 11be. Meanwhile, the motivation of the requirement that the format of all related subfields shall remain unchanged is to avoid repeated development
of the developed products due to a large amount of protocol modifications at this stage. However, for EHT link adaptation which hasn’t been defined, it doesn't involve that. Thus, it is better to set Nss field to 3 bits directly. It seems we haven’t run the motion for this SP. Best Regards, Bo Gong (Huawei) 发件人:
Zinan Lin [mailto:Zinan.Lin@xxxxxxxxxxxxxxxx]
Hi Bo, Thank you so much for drafting the CR document 1317r0.
One general comment: Nss is set to 3 bits in the newly defined ELA Control subfield in this document. I understand SP#4 “Do you agree that 802.11be shall not define operation
with more than 8 spatial streams and that the format of all subfields related to spatial streams shall remain unchanged (i.e. no changing the number of bits)?” in 11-22/1238r2 has the results Y/N/A: 22/4/5. Could you please remind me what the motion number
for this SP is? Thanks, Zinan From: gongbo (E) <000017a2c2fb48c4-dmarc-request@xxxxxxxxxxxxxxxxx>
Hi, all. The document 1317r0, which includes CID 10116 about EHT link adaptation, has been presented in the last joint meeting. Any comments and discussion are welcome. Best regards, Bo Gong (Huawei) To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 |