Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Ron, Thanks for your comments and suggestions. Please see my answers inline. BR, Oded From: Ron Porat [mailto:000009a0da80e877-dmarc-request@xxxxxxxxxxxxxxxxx]
Hi Oded, A few more comments:
Thanks, Ron From:
김상현 [mailto:shk0787@xxxxxxxxx]
Dear Oded, Thank you so much. Best Regard, Sanghyun Kim Sanghyun Kim, Ph.D
-----Original Message----- Hi Sanghyun Kim, I understand your intention and personally I don’t have a problem with your suggestion to change the wording. Note however that this text is given in the “general” sub-clause as
an introduction/explanation. If you want to turn it to a requirement then maybe you should run a SP on that first. Anyway, I changed the text as you suggested. BR, Oded From:
김상현 [mailto:shk0787@xxxxxxxxx]
Dear Oded, Thank you for the response. I am not sure of the scenario an EHT STA punctures available channels yet. But, I think we need to consider text that can cover as many cases as possible, because we don't know all the scenarios yet. Simple scenarios I can imagine are below. -An EHT STA may try to keep some channels IDLE(available) for P2P transmission or coordinated APs. Thank you for considering my comments. Best Regard, Sanghyun Kim, Ph.D WILUS Inc. -----Original Message----- Hi Sanghyun Kim, Thanks for your comments. I have updated the text in accordance with your 1st and 3rd comments. Regarding your 2nd suggestion to replace “available” with “occupied by the PPDU”, if I understand you correctly, your intention is to use a wider definition. However
I don’t understand in which practical scenario will a transmitter choose not to use an available secondary channel within an at least 80MHz BW transmission.
Could you elaborate on that? BR, Oded From:
김상현 [mailto:shk0787@xxxxxxxxx]
Dear Oded, Thanks for preparing the text. Please find attached comments. Best Regards Sanghyun Kim Sanghyun Kim, Ph.D
-----Original Message----- Hi Youhan Thanks for your comment and corrections. I updated the text according to most of them, please see attached. Regarding your high level comment about the name “preamble puncture”: I partially agree with your observation. I think however that the term “preamble puncture” was chosen in 802.11ax because the puncturing indication relates only to P80 where pre-HE processing
in the receiver is required for BW of 80MHz & 160MHz. It then enables proper processing of the HE-SIG-B field on the non-punctured subchannels.
There is no argument that any 20MHz subchannel in S80 may also be unavailable, so the HE preamble is punctured in these subchannels as well but it is not necessarily processed/decoded. Therefore,
this is not related to “preamble puncture”. In EHT the situation is similar, although not identical: In OFDMA, the preamble puncture indication field in U-SIG in an EHT MU PPDU indicates the preamble puncturing pattern of only the 80MHz where the U-SIG is being sent. So the receiver will have
the puncturing indication for only the 80MHz segment where it processes the pre-EHT, which is similar to HE. In non-OFDMA with puncturing, the U-SIG in each 80 MHz may carry puncturing channel info for all 80 MHz segments, so we should distinguish between two cases: 1.
If the 80MHz segment where the STA processes the pre-EHT is punctured, then it is again similar to HE. 2.
In the case where the punctured subchannel is outside the aforementioned 80MHz segment, I agree that the more accurate term to be used is e.g. “puncture” or “channel puncture” rather than
“preamble puncture”. So in my opinion the term “preamble puncture” is still applicable. In any case, I think it is too early to determine whether the term “preamble puncture” should be revised and in any case I think it is better to have the group decide on that. Best Regard, Oded From: Youhan Kim [mailto:youhank@xxxxxxxxxxxxxxxx]
Hi, Oded, Thanks for the nice work. Please find my suggested edits in the attached document. One high level comment is on the name “preamble puncturing”. In 11ax, we called it ‘preamble’ puncturing because 11ax puncturing was defined only for DL OFDMA. And for HE modulated fields in DL OFDMA, ‘puncturing’ is naturally done by not allocating certain
RUs. Hence, what had to be ‘defined’ was to puncture the preamble (more specifically, the pre-HE modulated fields). In 11be, however, we are extending the puncturing to non-OFDMA cases, in which case the name ‘preamble’ puncturing does not seem appropriate as even the EHT modulate fields need to be punctured
as well. Regards, Youhan From: Oded Redlich (TRC) <oded.redlich@xxxxxxxxxx>
CAUTION: This email originated from outside of
the organization. Hi Yujin, Thanks for the comment. Will be updated in the next revision. BR, Oded From: Yujin Noh [mailto:yujin.noh@xxxxxxxxxxxx]
Hi Oded, Thank you for the draft. Please find minor editorial updates to be consistent with other subclauses. Regards, Yujin From: Oded Redlich (TRC) <oded.redlich@xxxxxxxxxx>
Hello Preamble Puncture TTTs and all, I have uploaded the initial draft for the preamble-puncture sub-clause to the server. The document reference number is 1319. Your comments are welcomed. BR, Oded From: Oded Redlich (TRC) [mailto:oded.redlich@xxxxxxxxxx]
Dear TTTs of preamble puncture, This is a kind reminder to volunteer to write the text of the below suggested sub-clauses. BR, Oded From: Oded Redlich (TRC)
Dear preamble puncture TTTs, Preamble puncture text is suggested to be inserted in a new sub-section 34.3.10.10 “Preamble Puncture”. Also new text in section 9.4.2.xxx (“EHT Capabilities Element”) will probably be added to define the sub-field “EHT PHY Capabilities Information field”. We need to define the preamble puncture
Rx capabilities within this sub-field (similar to how it is defined in 9.4.2.247 in 11axD6.0) Thus I suggest the following list of sub clauses to be added: Under 34.3.10.10 – Preamble Puncture
Under 9.4.2.xxx.yyy – EHT PHY Capabilities Information field
Please feel free to volunteer to write a specific section In addition, please let me know if you have any comments or if I have missed something BR, Oded Redlich 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 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 |