Hello, Yanjun,
I agree to mark it as TBD (to support 320 MHz) in sub-clause 33.x.x.2 (INACTIVE_SUBCHANNELS) as in your proposal. My point is we don't need to change the definition of INACTIVE_SUBCHANNELS for this case in Table 34-1 or Table 27-1 for now, since there's no discussion for new mechanism yet.
Best Regards,
Bo
Hi Bo,
Thank you for the additional inputs.
For 320MHz, there are multiple possible ways to indicate punctured subchannel. I’m in general aligned with your suggestion of using a 16 bit map instead of the existing 8 bit map, but I’m concerned to include that at the moment as there
is no related motion passed yet. So I’m leaning toward leaving it as TBD, same as what you indicated for EHT format in 1043r4. Please let me know if you have any alternative suggestion.
Thank you,
Yanjun
From: sun.bo1@xxxxxxxxxx <sun.bo1@xxxxxxxxxx>
Sent: Thursday, September 24, 2020 4:29 PM
To: Yanjun Sun <yanjuns@xxxxxxxxxxxxxxxx>
Cc: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx; yongho.seok@xxxxxxxxx; Xiaofei.Wang@xxxxxxxxxxxxxxxx
Subject: Re:PDT-MAC-TXOP-Preamble-Puncturing
CAUTION: This email originated from outside of
the organization.
Hello, Yanjun,
As I explained in another email to Yongho, we can keep INACTIVE_SUBCHANNELS as it is in Table 27-1 and we can directly refer to it in Table 34-1. It's not necessary to change the definition
of INACTIVE_SUBCHANNELS in Table 34-1 or in Table 27-1.
But I'd suggest to update the text in your proposed sub-clause 33.x.x.2 (INACTIVE_SUBCHANNELS) to make it similar to sub-clause 26.11.7 (INACTIVE_SUBCHANNELS and RU_ALLOCATION). And as Yongho
pointed out, you may want to specify the INACTIVE_SUBCHANNELS is a 16-bit bitmap to support 320 MHz bandwidth. And in future, e.g. D0.1 comment process, we may add a table in section 34 corresponding to Table 27-4 as in section 27 to explain the CH_BANDWIDTH
and INACTIVE_SUBCHANNELS.
Best Regards,
Bo
Original Mail
Sender: YanjunSun <yanjuns@xxxxxxxxxxxxxxxx>
To: sun bo10013985;
CC: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
<STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx>;yongho.seok@xxxxxxxxx <yongho.seok@xxxxxxxxx>;Xiaofei.Wang@xxxxxxxxxxxxxxxx <Xiaofei.Wang@xxxxxxxxxxxxxxxx>;
Date: 2020/09/25 04:20
Subject: RE: Re:PDT-MAC-TXOP-Preamble-Puncturing
Good point, Bo.
We could add the following to the PDT. Another option is to handle it within your PHY PDT for a cohesive design. Please let me know which way works better for you.
34.x.2 TXVECTOR and RXVECTOR
Table 34-1 TXVEROR and RXVECTOR Parameters
Parameter | Condition | Value | TXVECTOR | RXVECTOR |
INACTIVE_SUBCHANNELS | FORMAT is NON_HT and NON_HT_MODULATION is equal to NON_HT_DUP_ OFDM | TBD | | |
Thank you,
Yanjun
From:sun.bo1@xxxxxxxxxx <sun.bo1@xxxxxxxxxx>
Sent: Wednesday, September 23, 2020 6:34 PM
To: Yanjun Sun <yanjuns@xxxxxxxxxxxxxxxx>
Cc: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx; yongho.seok@xxxxxxxxx;Xiaofei.Wang@xxxxxxxxxxxxxxxx
Subject: Re:PDT-MAC-TXOP-Preamble-Puncturing
CAUTION: This email originated from outside of
the organization.
Hello, Yanjun,
Thanks for initiaing the discussion.
For your reference, the current 11ax TXVECTOR parameter INACTIVE_SUBCHANNELS is present and indicates the 20 MHz subchannels that are punctured when "FORMAT
is NON_HT and NON_HT_MODULATION is NON_HT_DUP_OFDM".
In 11be, Table 34-1 will contain parameter INACTIVE_SUBCHANNELS as well to extend support for FORMAT=EHT_MU. But for NON_HT case, the use of this parameter may refer to the definition as
in 11ax Table 27-1. My question is whether current definition for INACTIVE_SUBCHANNELS in Table 27-1 supports the description in your proposal?
Best Regards,
Bo
Original Mail
Sender: YanjunSun <yanjuns@xxxxxxxxxxxxxxxx>
CC: Yongho Seok <yongho.seok@xxxxxxxxx>;Xiaofei.Wang@xxxxxxxxxxxxxxxx
<Xiaofei.Wang@xxxxxxxxxxxxxxxx>;sun bo10013985;
Date: 2020/09/24 09:02
Subject: RE: PDT-MAC-TXOP-Preamble-Puncturing
Hi All,
Thank you for your inputs today. Please see the revised draft at:https://mentor.ieee.org/802.11/dcn/20/11-20-1408-01-00be-pdt-mac-txop-preamble-puncturing.docx
Yongho, Bo, the draft has been revised to refer to theINACTIVE_SUBCHANNELSdefined in 1403. Thanks again for your inputs.
Please let me know if you have any questions/comments.
Thank you,
Yanjun
From: Yanjun Sun <yanjuns@xxxxxxxxxxxxxxxx>
Sent: Tuesday, September 15, 2020 10:29 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] PDT-MAC-TXOP-Preamble-Puncturing
CAUTION: This email originated from outside of
the organization.
Hi all,
If you have any comments on the following clause for TXOP with preamble puncturing, please let me know.
https://mentor.ieee.org/802.11/dcn/20/11-20-1408-00-00be-pdt-mac-txop-preamble-puncturing.docx
Thanks for the folks who has provided early feedbacks.
Thank you,
Yanjun
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