| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Wook bong,
You may support 8LTF but not want to get even 4LTF if you receive Nss=2, so these are two different things.
Thanks, Ron
From: Wook Bong Lee <wookbong.lee@xxxxxxxxxxx>
Hi Youhan, Xiaogang and Steve,
Do we need to mention whether a device is supporting extra LTF or not? Can we just have how many LTFs it can process for SU? If it is matching with its Nss value, then the device is not supporting extra LTF.
Best regards, Wook Bong Lee
From: Steve Shellhammer [mailto:sshellha@xxxxxxxxxxxxxxxx]
Youhan and Xiaogang,
Xiaogang, thanks for bringing up this point.
If B0 is zero, then Extra LTFs are not supported. So setting B3-B4 to 0, which is used to indicate a max of 4 LTFs, is not correct.
I agree with Youhan, that making those bit Reserved is correct.
If we do that, the B3-B4 does not have any impact on the number of supported LTFs, which I believe fixes the issue brought up by Xiaogang.
Xiaogang, do you agree that making them reserved solves this issue?
Regards, Steve
From: Youhan Kim <youhank@xxxxxxxxxxxxxxxx>
CAUTION: This email originated from outside of the organization. How about “If B0 is set to 0 then B3 and B4 are both reserved”?
Thanks. Youhan
From: Chen, Xiaogang C <xiaogang.c.chen@xxxxxxxxx>
CAUTION: This email originated from outside of the organization. Sorry Steve, one more question regarding the B3B4 setting. If non-AP STA doesn’t support extra LTF, the text below means it can only support up to 4 LTF in sounding / MUMIMO and OFDMA? e.g. If AP has 8 antennas this STA can even not be fully sounded because it only receive up to 4 LTF (B0 = 0)? If that’s the correct understanding, I think we need to decouple B0 and B3,B4.
If B0 is set to 0 then B3 and B4 are both set to 0.
BRs, Xiaogang.
From: Chen, Xiaogang C <xiaogang.c.chen@xxxxxxxxx>
Hi Steve, Regarding the text below, if a non-AP STA is capable of receive 2 SS and don’t support extra LTF reception (B0 = 0), then B1B2 set to 0 means it can still receive 4 LTF in single user transmission. So AP can still transmit 4 LTF where 2 out of the 4 LTF are extra. I guess it’s not a correct interpretation right?
If B0 is set to 0 then B1 and B2 are both set to 0.
BRs, Xiaogang.
From: Steve Shellhammer <sshellha@xxxxxxxxxxxxxxxx>
Ross,
You bring up a good point. I have revised the document (now 755r1), and dropped the text on “non-OFDMA” in the description of bits B3-B4.
Thanks for reminding me of that motion.
Regards, Steve
From: Yujian (Ross Yu) <ross.yujian@xxxxxxxxxx>
CAUTION: This email originated from outside of the organization. Hi Steve,
Then how about the OFDMA case?
We have the following motion: The allowed values of maximum NLTF receive capability for multiple-user transmission are 4, 8, and 16.
[Motion 141, #SP261, [3] and [52]]
regards 于健 Ross Jian Yu Huawei Technologies
发件人: Steve Shellhammer [mailto:sshellha@xxxxxxxxxxxxxxxx]
Hi Ross,
It is my understanding that this Extra LTF PHY Capability is for the non-OFDMA mode. As you can see B0 indicates support for this feature, where it is clear that it is for the non-OFDMA case. That is why we are providing clarifying text.
The main point of the edits is to clarify this is a receiver capability, which was unclear in the original text.
I hope this addresses your comment.
Regards, Steve
From: Yujian (Ross Yu) <ross.yujian@xxxxxxxxxx>
CAUTION: This email originated from outside of the organization. Hi Steve,
B3-B4 previously covers OFDMA case, which is the case in 11ax. For OFDMA case, it indicates 8 or same as Beamformee NSTS capability.
regards 于健 Ross Jian Yu Huawei Technologies
发件人: Steve Shellhammer [mailto:sshellha@xxxxxxxxxxxxxxxx]
Alfred, Sigurd, and Tianyu,
Please add the following PDT to the PHY Agenda,
· Doc 11-21/755r0, PDT Clarification Extra LTF PHY Capability
Thanks, Steve
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 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 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 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 |
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature