Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Mark and all, Thanks for bringing the updated proposal. I have the following high level comments:
1.
The first comment is related with previous SP3 (9/5/15). From implementation point of view, there is no reasoning to restrict for case
7, there must exist one punctured subchannel in P80. What’s the technical problem if the P80 is not punctured? The Tx only needs to ensure the Rx can find one CC1 and one CC2 in HE-SIG-B. In other words, if p80 is empty, the Tx needs to puncture one subchannel
and lose 1/(5~8) Tput efficiency, just to meet the making-no-sense requirement?
2.
The second comment is related with SP4 (19/5/8). The puncture pattern in 11be is not finalized. I see people also show interests in 1xx1
pattern in P80 in 11be. Contributions in 20-129r0 shows a very good example on the Tput loss when a less flexible preamble puncture is supported. I hear Youhan also says he is ok to not make any changes regarding the stage of 11ax spec. I share similar opinion
on that. So I prefer to not make changes regarding the puncture pattern at this stage. Maybe adjust the spectrum mask or regulatory rule is a good choice.
3.
Last but not least, I also have concern that currently few PHY people join the call, it is a risky we make big technical changes regarding
preamble puncture. I will join Thur call, we may further discuss it during the call. regards 于健 Ross Yu Huawei Technologies 发件人: *** 802.11 TGax - HEW - High Efficiency WLAN *** [mailto:STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx]
代表
Mark RISON Based on the SPs last week, here is my updated proposal on spec wording for preamble puncturing: Table 9-321b—Subfields of the HE PHY Capabilities Information field,
Punctured Preamble Rx field definition B0 indicates support for the reception of an 80 MHz preamble where the only punctured subchannel is the secondary 20 MHz
B1 indicates support for the reception of an 80 MHz preamble where the only punctured subchannel is
one of the two 20 MHz subchannels in the secondary 40 MHz channel B2 indicates support for the reception of a 160 MHz or 80+80 MHz preamble where
the only punctured subchannels are the secondary 20 MHz channel [Do we want a "NOTE—No more than two adjacent 20 MHz channels are available to be punctured across an 80+80 MHz preamble."?] B3 indicates support for the reception of a 160 MHz or 80+80 MHz preamble where the
only punctured subchannels are one or both of the 20 MHz subchannels in the secondary 10.23.2.5 EDCA channel access in a VHT, HE or TVHT BSS [Note for group discussion: condition highlighted in yellow should probably be changed to something like “if all of the 20 MHz subchannels that are not punctured
were idle”, because the current wording is not specific enough (e.g. for k) and l) it’s not just any one of the four 20 MHz subchannels in S80 that needs to be idle).] i) Transmit an
80 MHz HE MU PPDU j) Transmit an
80 MHz HE MU PPDU k) Transmit a l) Transmit a Table 27-1—TXVECTOR and RXVECTOR parameters, CH_BANDWIDTH value
if FORMAT is HE_MU HE-CBW-PUNC80-PRI for preamble puncturing in 80 MHz, where in the preamble
the only HE-CBW-PUNC80-SEC for preamble puncturing in 80 MHz, where in the preamble
the only punctured subchannel is one of the two 20 MHz subchannels in
the secondary 40 MHz channel HE-CBW-PUNC160-PRI20 for preamble puncturing in 160 MHz, where in
HE-CBW-PUNC80+80-PRI20 for preamble puncturing in 80+80 MHz, where in
HE-CBW-PUNC160-SEC40 for preamble puncturing in 160 MHz HE-CBW-PUNC80+80-SEC40 for preamble puncturing in 80+80 MHz, where in
Table 27-3— Interpretation of FORMAT, NON_HT Modulation and CH_BANDWIDTH parameters,
CH_BANDWIDTH rows as shown HE-CBW-PUNC80-PRI: The STA transmits an
80 MHz HE PPDU HE-CBW-PUNC80-SEC: The STA transmits an
80 MHz HE PPDU HE-CBW-PUNC160-PRI20: The STA transmits a HE-CBW-PUNC80+80-PRI20: The STA transmits an 80+80 MHz HE PPDU
HE-CBW-PUNC160-SEC40: The STA transmits a HE-CBW-PUNC80+80-SEC40: The STA transmits an 80+80 MHz HE PPDU
Table 27-4— Interpretation of CH_BANDWIDTH and INACTIVE_SUBCHANNELS parameters when FORMAT is equal to NON_HT and NON_HT_MODULATION is equal to NON_HT_DUP_OFDM,
CH_BANDWIDTH rows as shown, for punctured PPDUs [Note for group discussion: are we OK with the vague “any”?] CBW80: The bit corresponding to the primary 20 MHz channel set to 0 and
CBW160: The bit corresponding to the primary 20 MHz channel set to 0 and
CBW80+80: The bit corresponding to the primary 20 MHz channel set to 0 and
Table 27-20—HE-SIG-A field of an HE MU PPDU, Bandwidth field Set to 4 for preamble puncturing in 80 MHz, where in the preamble
the only punctured subchannel is the secondary 20 MHz channel Set to 5 for preamble puncturing in 80 MHz, where in the preamble
the only punctured subchannel is one of the two 20 MHz subchannels in
the secondary 40 MHz channel Set to 6 for preamble puncturing in 160 MHz or 80+80 MHz, where in
Set to 7 for preamble puncturing in 160 MHz or 80+80 MHz, where in
C.3 MIB Detail [Note for group discussion: I think the changes below are enough and it’s necessary to be quite so specific as above here, but I can be so if the group so
desires.] dot11HEPuncturedPreambleRxImplemented OBJECT-TYPE SYNTAX OCTET STRING(SIZE( MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute is a bitmap that indicates the preamble p where bit
an 80 MHz preamble where the secondary 20 MHz
bit
one of the two 20 MHz subchannels in the secondary 40 MHz channel is punctured, bit
a 160 MHz or 80+80 MHz preamble where
bit
a 160 MHz or 80+80 MHz preamble where one or both of the 20 MHz subchannels in the secondary 40 MHz channel are punctured.
::= { dot11PhyHEEntry
2 } Change “MHz is” to “MHz channel is” at 274.59. For cross-checking purposes, I think the following gives all the permitted puncturings for 80+80/160; please tell me if you spot and mistakes or omissions: 6 where P20 is lowest (reversed pattern where P20 is highest): -x--xx-- -x----xx -x--x--- -x---x-- -x----x- -x-----x -x------ 6 where P20 is second lowest (reversed pattern where P20 is second highest): x---xx-- x-----xx x---x--- x----x-- x-----x- x------x x------- 6 where P20 is third lowest (reversed pattern where P20 is third highest): ---xxx-- [80+80 only] ---x--xx ---xx--- ---x-x-- ---x--x- ---x---x ---x---- 6 where P20 is fourth lowest (reversed pattern where P20 is fourth highest): --x-xx-- --x---xx --x-x--- --x--x-- --x---x- --x----x --x----- 7 where P40 is lowest (reversed pattern where P40 is highest): --x-xx-- --x---xx --x-x--- --x--x-- --x---x- --x----x --x----- --xxxx-- [80+80 only] --xx--xx --xxx--- [80+80 only] --xx-x-- --xx--x- --xx---x --xx---- ---xxx-- [80+80 only] ---x--xx ---xx--- ---x-x-- ---x--x- ---x---x ---x---- 7 where S40 is lowest (reversed pattern where S40 is highest): x---xx-- x-----xx x---x--- x----x-- x-----x- x------x x------- xx--xx-- xx----xx xx--x--- xx---x-- xx----x- xx-----x xx------ -x--xx-- -x----xx -x--x--- -x---x-- -x----x- -x-----x -x------ Thanks, Mark -- Mark RISON, Standards Architect, WLAN English/Esperanto/Français On Fri, 17 Apr 2020 at 00:25, Osama Aboul-Magd <oamagd@xxxxxxxxx> wrote:
To unsubscribe from the STDS-802-11-TGAX list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1
To unsubscribe from the STDS-802-11-TGAX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1 |