Hi, Zinan. Thanks for your valuable comments. Please see
my inline response.
[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 Line 24 to Line 29, Page 4271 in REVme D1.4, (the sub-clause 26.13 Link adaptation using the HLA Control subfield), the following text specifies that the measured PPDU is the most recent received
one matching the PPDU Type/beamforming/coding type.
“Unsolicited HE-MCS, NSS, DCM, BW, and RU estimates reported in an HLA Control subfield sent by a
STA
are computed based on the most recent PPDU received by the STA
that matches the description
indicated by the PPDU format, Tx Beamforming, and Coding Type subfields in the same HLA Control
subfield.”
[ZL]
In addition, even it was specified, the channel may not be available for the unsolicited MFB to be transmitted right after the measured PPDU
Ø
If the new arrival frames, which means the frames received later than the measured PPDU, don’t match the PPDU Type/beamforming/coding type of the measured PPDU, the transmission of the
unsolicited MFB can be delayed.
Ø
If the new arrival frames, which means the frames received later than the measured PPDU, match the PPDU Type/beamforming/coding type of the measured PPDU, the unsolicited MFB should
be re-estimated according to the newest frame.
[ZL]
or the transmitter of the unsolicited MFB can only send the unsolicited MFB when it has the data/frame to send.
The transmitter of the unsolicited MFB can also send a QoS Null frame to carry the +HTC subfield.
[ZL]
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.
If the time between the measured PPDU and the unsolicited MFB is too long, the STA may give up the transmission of the unsolicited MFB, or the AP may no longer refer to the received
unsolicited MFB. The specific processing can be left to the implementation.
[ZL]
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.
Thanks for your understanding and look forward to your support.
发件人: Zinan Lin [mailto:Zinan.Lin@xxxxxxxxxxxxxxxx]
发送时间: 2022年10月18日
9:14
收件人: gongbo (E) <gongbo8@xxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
抄送: Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>
主题: RE: [STDS-802-11-TGBE] Comments Collection for CID 10116 of 1317r0 about EHT link adaptation
Hi Bo,
Please see my
inline comments.
Thanks,
Zinan
From: gongbo (E) <gongbo8@xxxxxxxxxx>
Sent: Monday, October 17, 2022 7:51 AM
To: Zinan Lin <Zinan.Lin@xxxxxxxxxxxxxxxx>;
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Cc: Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>
Subject: 答复: [STDS-802-11-TGBE] Comments Collection for CID 10116 of 1317r0 about EHT link adaptation
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]
发送时间: 2022年10月15日
3:23
收件人: gongbo (E) <gongbo8@xxxxxxxxxx>;
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
抄送: Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>
主题: RE: [STDS-802-11-TGBE] Comments Collection for CID 10116 of 1317r0 about EHT link adaptation
Bo,
Thanks for your answer. Please see my inline
comments.
Thanks,
Zinan
From: gongbo (E) <gongbo8@xxxxxxxxxx>
Sent: Friday, October 14, 2022 5:27 AM
To: Zinan Lin <Zinan.Lin@xxxxxxxxxxxxxxxx>;
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Cc: Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>
Subject: 答复: [STDS-802-11-TGBE] Comments Collection for CID 10116 of 1317r0 about EHT link adaptation
Hi, Zinan,
Thanks for your comments.
The response to your comments are labeled in red.
1)
This figure is only applicable in the unsolicited MFB case, i.e., Unsolicited MFB subfield is set to 1.Do you think solicited MFB case should be considered
as well?
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]
发送时间: 2022年10月13日
6:35
收件人: gongbo (E) <gongbo8@xxxxxxxxxx>;
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
抄送: Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>
主题: RE: [STDS-802-11-TGBE] Comments Collection for CID 10116 of 1317r0 about EHT link adaptation
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>
Sent: Saturday, October 8, 2022 6:02 AM
To: Zinan Lin <Zinan.Lin@xxxxxxxxxxxxxxxx>;
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Cc: Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>
Subject: 答复: [STDS-802-11-TGBE] Comments Collection for CID 10116 of 1317r0 about EHT link adaptation
|
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]发送时间:
2022年10月8日
0:58收件人: gongbo (E) <gongbo8@xxxxxxxxxx>;
STDS-802-11- |
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]
发送时间: 2022年10月8日
0:58
收件人: gongbo (E) <gongbo8@xxxxxxxxxx>;
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: RE: [STDS-802-11-TGBE] Comments Collection for CID 10116 of 1317r0 about EHT link adaptation
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>
Sent: Friday, September 23, 2022 2:48 AM
To: Zinan Lin <Zinan.Lin@xxxxxxxxxxxxxxxx>;
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: 答复: [STDS-802-11-TGBE] Comments Collection for CID 10116 of 1317r0 about EHT link adaptation
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]
发送时间: 2022年9月23日
12:33
收件人: gongbo (E) <gongbo8@xxxxxxxxxx>;
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: RE: [STDS-802-11-TGBE] Comments Collection for CID 10116 of 1317r0 about EHT link adaptation
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>
Sent: Monday, September 19, 2022 10:27 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] Comments Collection for CID 10116 of 1317r0 about EHT link adaptation
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