Thank you again for your inputs during the last joint call.
I’ve revised the CR (21/0455r6) based
on comments during the call and those from offline discussions. The two minor updates on the spec text are all within the last two paragraphs on page 8 as highlighted by the comments:
-
Incorporated Yunbo’s and Yongho’s comments that a P2P link between two STAs shall not transmit a PPDU on any punctured subchannel indicated in beacons if the P2P link is within the operating bandwidth of the BSS.
-
Adopted the editorial updates suggested by Xiaofei on text related to MU sequence
In the meantime, I’ve updated subclause numbers based on D1.0 following the latest guidelines. Please let me know if you have additional comments/suggestions.
Thanks,
Yanjun
From: Jonghun Han <jong_hun.han@xxxxxxxxxxx>
Sent: Wednesday, May 12, 2021 11:50 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] (2) [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] (2) [STDS-802-11-TGBE]
(2) [STDS-802-11-TGBE] [Suspected Marketing Mail] Re: [STDS-802-11-TGBE] On preamble puncturing RE: [STDS-802-11-TGBE] PDT - Unused tone EVM (+ note to MAC)
CAUTION:
This email originated from outside of the organization.
Hello Laurent,
Thanks for the clarification.
Regards.
Jonghun.
---------
Original Message ---------
Sender : Cariou, Laurent <laurent.cariou@xxxxxxxxx>
Date : 2021-05-12 17:15 (GMT+9)
Title : Re: [STDS-802-11-TGBE]
答复: [STDS-802-11-TGBE] (2) [STDS-802-11-TGBE] (2) [STDS-802-11-TGBE] [Suspected
Marketing Mail] Re: [STDS-802-11-TGBE] On preamble puncturing RE: [STDS-802-11-TGBE] PDT - Unused tone EVM (+ note to MAC)
Hi,
My understanding is that all what is not static puncturing is dynamic puncturing.
Now within dynamic puncturing, there are different categories and my understanding is that the group has agreed that they are R2, except the mode inherited
from 11ax that Yanjun described:
-
Dynamic puncturing of EHT MU PPDU with a triggered response (if any response)
Your example below Jonghun would be R2.
Thanks,
Laurent
|
Hello Ross,
Thanks for the clarification a lot.
I'd like to ask another simple question.
When an EHT STA sends EHT MU PPDU for SU transmission, how does the receiver of the PPDU know the puncturing info?
Even though it is included in preamble of EHT MU PPDU, but there is no RU allocation in the PPDU and no ACTIVE_SUBCHANNELS in RXVECTOR. So, the receiver MAC cannot obtain the
puncturing info.
Any procedure there to fill this gap? It seems that I lost many discussion related to preamble puncturing.
Regards,
Jonghun
---------
Original Message ---------
Sender : Yujian (Ross Yu) <ross.yujian@xxxxxxxxxx>
Date : 2021-05-12 15:36 (GMT+9)
Title : [STDS-802-11-TGBE]
答复: [STDS-802-11-TGBE] (2) [STDS-802-11-TGBE] (2) [STDS-802-11-TGBE] [Suspected Marketing Mail] Re: [STDS-802-11-TGBE] On
preamble puncturing RE: [STDS-802-11-TGBE] PDT - Unused tone EVM (+ note to MAC)
Hi Jong Hun,
My understanding of dynamic vs static preamble puncturing is regarding non-HT duplicate PPDU. For EHT MU PPDU, puncturing info is self-contained
and should not be limited or mixed together.
|
regards 于健 Ross Jian Yu Huawei Technologies |
|
Hello Yanjun,
Thanks for the quick responses.
Now, I have a better understanding on your CR.
I have one more comment.
As you said, if "dynamic puncturing" is considered as R2 feature and your CR focused on "static puncturing", then I think the statement describing "dynamic
puncturing" such as "An EHT STA may puncture additional subchannels
on top of the punctured subchannels indicated in the Disabled Subchannel Bitmap field in the EHT Operation element in an EHT MU PPDU or a non-HT duplicate PPDU. " should
be removed in R1 spec.
Since we don't have an appropriate procedure that covers "dynamic puncturing" and we will not allow it in R1, we don't need this statement in
R1.
Please correct me if I am wrong.
Thanks.
BR,
Jonghun
---------
Original Message ---------
Sender : Yanjun Sun <yanjuns@xxxxxxxxxxxxxxxx>
Date : 2021-05-12 13:59 (GMT+9)
Title : Re: [STDS-802-11-TGBE] (2) [STDS-802-11-TGBE] [Suspected Marketing
Mail] Re: [STDS-802-11-TGBE] On preamble puncturing RE: [STDS-802-11-TGBE] PDT - Unused tone EVM (+ note to MAC)
Hi Jonghun,
Thank you for the careful review and constructive inputs. Please see
clarifications and comments inline.
|
Thank you, Yanjun |
|
CAUTION:
This email originated from outside of the organization.
Hello Yanjun,
Sorry for late reply and thanks for your work, 455r5.
I have one question and two suggestions.
1. [Question] 35.12.x Preamble Puncturing Operation
I saw the statement, "as the RXVECTOR parameter INACTIVE_SUBCHANNELS is not present as defined in Table 36-1 (TXVECTOR and RXVECTOR Parameters), a
responding EHT STA cannot learn the additionally punctured subchannels". Could you explain the reason why we remove INACTIVE_SUBCHANNELS in RXVECTOR?
[YS] Bo’s contribution 21/0635r3 removed INACTIVE_SUBCHANNELS from RXVECTOR and got approved in the PHY meetings. So I tried to make this CR consistent with the group’s decision there.
As far as I know, we allow EHT STA to puncture additional subchannels on top of "static puncturing". Let's call it as "dynamic puncturing" here.
If EHT STA transmits EHT MU PPDU with dynamic puncturing, then the responding STA needs to know the dynamic puncturing pattern.
For example, if RTS (non-HT dup) is transmitted with dynamic puncturing, then the RTS-received
STA requires "dynamic puncturing information" to respond with CTS.
Without INACTIVE_SUBCHANNELS, how does the CTS-responding STA obtain this information?
[YS] Please see the next comment on dynamic puncturing.
2. [Suggestion] 10.3.2.9
CTS procedure + dynamic puncturing
This is an extension of the above question.
The desciption in 10.3.2.9 cannot cover the dynamic bandwidth case.
If EHT STA transmits RTS with dynamic puncturing, then CTS-responding STA cannot obtain the dynamically punctured channel information.
So, we need to define and include the procedure/signaling related
to the dynamic puncturing if we want to allow dynamic puncturing in R1.
Or, we can disable dynamic puncturing in R1.
[YS] There was comments (e.g. CID 2148) to have static puncturing in R1 and dynamic puncturing in R2. In addition, there is no motion/SP to support dynamic puncturing yet. Based on
these facts, this CR is focusing on static puncturing only. For CTS transmission, the puncturing pattern will be obtained from management frames such as Beacon frames. In case any motion/SP gets approved to support dynamic puncturing, we could then expand
the spec text as your suggested.
3. [Suggestion] 10.3.2.9 CTS procedure + INACTIVE_SUBCHANNELS
In 10.3.2.9, it seems that we made two changes associated with preamble puncturing.
- the list of subchannels to be CCA-checked
- CH_BANDWIDTH_IN_NON_HT setting of CTS frame
I think we should make one more change about reflecting INACTIVE_SUBCHANNELS.
If the CTS-responding STA just follows the current 10.3.2.9, CTS frame may be sent without considering the puncturing pattern, because the subclause
only describes whether the RTS-received STA respond or not and the setting of CH_BANDWIDTH_IN_NON_HT.
It would be better if we add a statement,. something like "The STA shall puncture the subchannel indicated by TXVECTOR parameter INACTIVE_SUBCHANNELS".
[YS] I understand your concern. If we focus static puncturing (the focus of this CR), I believe the following text on page 8 achieves the same goal as your suggested text: “If a 20MHz
subchannel is indicated as a punctured subchannel in the Disabled Subchannel Bitmap field in the EHT Operation element, the corresponding bit in the TXVECTOR parameter INACTIVE_SUBCHANNELS shall be set to 1 and the punctured 20MHz subchannel shall not be used
by any PPDU to or from the AP”. Please let me know if you have additional suggestions.
4. Typo
There is a typo in 35.12.x Preamble puncturing Operation.
TXVEROR --> TXVECTOR
[YS] Thank you and fixed as suggested.
Best regards,
Jonghun
---------
Original Message ---------
Sender : Yanjun Sun <yanjuns@xxxxxxxxxxxxxxxx>
Date : 2021-05-04 08:29 (GMT+9)
Title : Re: [STDS-802-11-TGBE] [Suspected Marketing Mail] Re: [STDS-802-11-TGBE]
On preamble puncturing RE: [STDS-802-11-TGBE] PDT - Unused tone EVM (+ note to MAC)
Hi folks,
As I haven’t received any new comments/suggestions on technical changes, I’ve uploaded the latest draft to
21/0455r5.
Compared to the earlier version in this email thread, this version includes
3 editorial changes (tagged by R5 as usual):
·
page 5: addressed the editorial comment of CID 2541 that is transferred from Edward to me
·
page 8: changed "if" to "as" in the following sentence "if the RXVECTOR parameter INACTIVE_SUBCHANNELS is not present as defined in Table 36-1" based on Laurent's suggestion
·
page 9: completely removed the text on "35.5.2 EHT sounding protocol" instead of having the text with strikethrough over it. The deletion of text was based on Wook Bong's suggestion.
|
Please let me know if you have further suggestions/comments. Thank you, Yanjun |
|
CAUTION:
This email originated from outside of the organization.
Thank you Yanjun.
It looks good to me now.
Best regards,
Wook Bong Lee
|
Hi Wook Bong, Xiaogang, and all,
Thank you for the review and constructive inputs.
I agree with you that the changes to “35.5.2 EHT sounding protocol” on page 9 are redundant after a careful review and I’ve deleted them as suggested.
I initially wanted to clarify two things in the text:
1.
NDPA cannot request feedback on a punctured subchannel indicated in beacons
2.
NDPA and NDP cannot be sent on a punctured subchannel indicated in beacons
After careful review, I believe these two points have also been covered by existing text introduced in Rev 4 of this CR and the existing text in
subclause 35.5.2 (EHT sounding protocol), so I’ve deleted the “NOTE” paragraph on page 9 to avoid redundancy as well.
|
All the two changes to the spec text are on page 9 and I’ve attached the revised version for your reference. Please let me know if you have additional
comments/suggestions. Thank you, Yanjun |
|
CAUTION:
This email originated from outside of the organization.
Hi Yanjun,
Thanks for update.
I have one follow up comment.
An EHT NDP Announcement frame shall not request feedback on a 242-tone RU that is signaled as punctured in the U-SIG of the NDP that follows the EHT NDP Announcement frame
or in the Disabled Subchannel Bitmap field in the EHT Operation element. The TXVECTOR parameter INACTIVE_SUBCHANNELS for the EHT NDP Announcement frame and the following NDP shall indicate the same puncturing
pattern as in the Partial BW Info subfield in the EHT NDP Announcement frame.
Yellow highlighted text is what you want to add for Disabled Subchannel Bitmap.
However, following clarification seems enough. Maybe you want to make this normative.
NOTE- the TXVECTOR parameter INACTIVE_SUBCHANNELS of an EHT NDP Announcement frame is also set based on the value indicated in the most recent Disabled Subchannel Bitmap field in the EHT Operation element if the
field is present, unlike an HE NDP Announcement frame which sets its INACTIVE_SUBCHANNELS based on a STA Info field with the AID11 of 2047.
We already have
An SU beamformer may solicit partial bandwidth or full bandwidth SU feedback from an SU beamformee in an EHT non-TB sounding sequence. In partial bandwidth non-TB sounding sequence
case, the Puncturing Channel Information fields in U-SIG shall indicate the same puncturing pattern as in the Partial BW Info subfield in the EHT NDP Announcement frame.
The yellow highlighted text seems redundant and not correct.
The puncturing pattern of U-SIG can be different from the Partial BW Info when MU sounding is enabled.
Maybe you can modify as follows
without changing 35.5.2 EHT sounding protocol subsection.
NOTE-
the TXVECTOR parameter INACTIVE_SUBCHANNELS of an EHT NDP Announcement frame
and NDP frame is also set based on the value indicated in the most recent Disabled Subchannel Bitmap field in the EHT Operation element if the field is present.
Note, unlike an HE NDP Announcement frame
which sets its INACTIVE_SUBCHANNELS based on a STA Info field with the AID11 of 2047.
Maybe you can add
An EHT NDP Announcement frame shall not request feedback on a 242-tone RU that is signaled as punctured in the U-SIG of the NDP that follows the EHT NDP Announcement frame
or in the TXVECTOR parameter INACTIVE_SUBCHANNELS of an EHT NDP Announcement frame.
Best regards,
Wook Bong Lee
|
Clear to me, thanks Yanjun.
|
Thanks Best Regards Jay Yang |
|
Hi Jay,
Thank you for reviewing the document. The intention of the cited bullet is to inherit the structure from 11ax on how a punctured PPDU begins a TXOP.
In 11ax, for example, we have
“i) Transmit an 80 MHz HE MU PPDU where in the preamble the only punctured subchannel is the secondary 20 MHz channel, if all of the 20 MHz subchannels
(other than the primary 20 MHz channel) that are not punctured were idle during an interval of PIFS immediately preceding the start of the TXOP.”
In 11be, we also need to define punctured transmission for frames in non-HT duplicate PPDU such as RTS. For example, an EHT AP may indicate a secondary
40MHz is punctured for the whole BSS and RTS needs to avoid the punctured 40MHz. So the cited bullet defines the rule for RTS to begin a TXOP.
Hope this helps to provide more context and please let me know if you have other questions or comments.
|
Thank you, Yanjun |
|
CAUTION:
This email originated from outside of the organization.
Hi Yanjun,
Could you explain more on the following bullet? I’m not clear the context of it.
n) Transmit a punctured non-HT duplicate PPDU if all of the 20 MHz subchannels that are not punctured were idle during an interval of PIFS immediately preceding the start of the TXOP.
|
Thanks Best Regards Jay Yang |
|
Hi Wook Bong and Xiaogang and all,
Thank you for the prompt inputs.
I’ve adopted the suggested changes and provided clarifications in the attached. The changes to spec text are tagged with “R5” in the comments.
Please let me know if you have additional comments/suggestions. As we may get other comments tomorrow during the call, I’ll upload the attached during/after
the call.
|
Thank you, Yanjun |
|
CAUTION:
This email originated from outside of the organization.
Hi Yanjun,
I think we need a more discussion for this in joint meeting.
BTW, we don’t have
INACTIVE_SUBCHANNELS in an EHT NDP Announcement frame.
Best regards,
Wook Bong Lee
|
Hi Yanjun,
I added several comments as attached. Thanks.
|
BRs, Xiaogang. |
|
Hi Yanjun,
Thanks for your effort.
I have one question.
If the EHT AP has included the Disabled Subchannel Bitmap field in the EHT Operation element, an EHT STA may use EHT MU PPDU preamble puncturing modes as defined in 36.3.12.11 (Preamble punctured EHT PPDU) or
EHT TB PPDU for non-contiguous bandwidth transmission with additional 20MHz subchannel(s) punctured on top the punctured subchannels indicated in the Disabled Subchannel Bitmap field in the EHT Operation
element.
Can you clarify EHT TB PPDU part?
What is non-contiguous bandwidth transmission? I think you may refer noncontiguous MRU transmission. (Please refer 11-21/639r4)
What is additional 20MHz subchannel punctured?
It is not super clear to me.
Please clarify.
Best regards,
Wook Bong Lee
|
Hi folks,
Based on offline comments, I’ve uploaded
21/0455r4
to clarify that MU transmission is allowed to puncture additional subchannels as in legacy HE, and to align the Table 36-1 entries with those from 21/0635r3 that passed SP in PHY today. The new spec text changes are tagged by “R4” in the comments.
Please let me know if you have additional comments/suggestions.
|
Thank you, Yanjun |
|
CAUTION:
This email originated from outside of the organization.
Hi Ron, Sigurd and all, I’ve tried to include your comments on page 8 in
21/0455r3,
tagged with R3 in the comments. Please let me know if the proposed change look reasonable to you.
|
Hi Alfred, as there is some aspect related to PHY in this CR, is it possible to move 21/0455r3 from the MAC queue to the join queue? Thank you, Yanjun |
|
Hi Sigurd, Hi MAC folks,
Agreed, 16 bits is fine for full flexibility but as we know in the PHY the rel. 1 STA is limited to SU transmissions with just one
hole as defined specifically in the spec so some restrictions are needed indeed here.
Thanks,
Ron
|
Hi Ron,
About:
I assume only one punctured subband will be signaled in the beacon and will be limited to the non-ofdma puncturing patterns we defined
in the spec (other cases STA doesn’t implement).
I see 455r2 uses a 16-bit bitmap to indicate the (static) puncturing pattern. I don’t believe anyone really expects to use the full flexibility of
this 16 bit indication, but we should probably be more explicit about the restrictions you mention when it comes to static puncturing.
Regards,
Sigurd
|
|
This email was sent from outside of MaxLinear. |
|
Hi Wook bong, That rule is an unnecessary constraint/requirement. My thinking based on the discussion is that we need a two-fold solution which
seems natural based on 11ax design and puncturing mask we adopted in 11be: 1.
Use option 3 for unused tone error EVM at a fixed level of max(epsilon-2,-38) in the hole of a non-contiguous MRU.
2.
In addition to #1 – non-AP STA needs to meet the punctured mask we already defined in 36.3.19.1.2 for any RU/MRU (this one has nothing to do with non-contiguous MRU)
based on static puncturing, meaning applied only for the subband signaled in the beacon (that’s the only subband the STA knows is punctured) I assume only one punctured subband will be signaled in the beacon and will be limited to the non-ofdma puncturing patterns we defined
in the spec (other cases STA doesn’t implement). Thanks, Ron
Hi Jianhan, That is only if we don’t allow non-AP STA to transmit higher than MCS 7 power level. If that is what members wants, then we need to make a rule like
E.g. when allocates non-contiguous MRU, AP STA shall assume an non-AP STA uses transmit power less than the maximum power of EHT-MCS
7. Best regards, Wook Bong Lee From: Jianhan Liu [mailto:Jianhan.Liu@xxxxxxxxxxxx]
-29 to -38 dB is always more tighter than -20 to -25dBr (puncture mask), right?
Then puncture mask becomes less useful then if puncture cases cannot be always identified.
Thanks, Jianhan From: Wook Bong Lee [mailto:wookbong.lee@xxxxxxxxxxx]
Hi Jianhan and Ron, Punctured mask: -20 to -25dBr Max(EVM – 2,-38): -15 to -38 dB depending on modulation level If we only allow power level less than or equal to the maximum power of EHT-MCS 7, then
Max(EVM – 2,-38): -29 to -38 dB. Best regards, Wook Bong Lee From: Jianhan Liu [mailto:Jianhan.Liu@xxxxxxxxxxxx]
Hi All, For epsilon-2 in option 3, in which cases that the unused tone mask is tighter than punctured mask? Thanks, Jianhan From: Ron Porat [mailto:000009a0da80e877-dmarc-request@xxxxxxxxxxxxxxxxx]
Hi Wook bong, Xiaogang, For the regular unused tone mask we could go with epsilon-2 in option 3 to make it tighter and that should be sufficient to expand
the 11ax style requirement to non-contiguous MRU. If on top of that we want to add some new requirement based on section 36.3.19.1.2 we need to be a bit more careful and discuss it
separately. Since the STA is not in control (unlike SU) and doesn’t know if and where there is a disallowed subchannel we may want to limit it to only a subchannel conveyed in the beacon (static puncturing) and further decouple the requirement from the M-RU
size (e.g. case 3 therein). Thanks, Ron From: Chen, Xiaogang C <xiaogang.c.chen@xxxxxxxxx>
Thanks Wook Bong to initiate this. One thing to consider is regulatory may not differentiate puncture and unallocated. They only differentiate adjacent and non-adjacent subchannel. Given that, regarding the unused EVM of the frequency portion of the “hole”, fully rely on
e or
e-2 may violate the regulatory requirement (for low MCS) if the interpretation of the unused “hole” is just “non-adjacent”.
So IMO puncture mask is safer for the “hole”. BRs, Xiaogang.
Hi all, Thanks for discussion today. Please give your opinion on 11-21/639r1,
Proposed Resolution of Remaining TBDs in 36.3.19.4.4 and 36.3.20.3,
Wook Bong Lee (Samsung) Please focus on change #3. PHY group accepted change #1, 2 and 4 today. Best regards, Wook Bong Lee From:"Calibri&q
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
|
|
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