| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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 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 From: Yang, Zhijie (NSB - CN/Shanghai) [mailto:zhijie.yang@xxxxxxxxxxxxxxx]
Clear to me, thanks Yanjun. Thanks Best Regards Jay Yang From: Yanjun Sun <yanjuns@xxxxxxxxxxxxxxxx>
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 From: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>
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 From: Yanjun Sun <yanjuns@xxxxxxxxxxxxxxxx>
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 From: Wook Bong Lee <wookbong.lee@xxxxxxxxxxx>
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 From: Chen, Xiaogang C [mailto:xiaogang.c.chen@xxxxxxxxx]
Hi Yanjun, I added several comments as attached. Thanks. BRs, Xiaogang. From: Wook Bong Lee <wookbong.lee@xxxxxxxxxxx>
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 From: Yanjun Sun [mailto:yanjuns@xxxxxxxxxxxxxxxx]
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 From: Yanjun Sun <yanjuns@xxxxxxxxxxxxxxxx>
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 From: Ron Porat <000009a0da80e877-dmarc-request@xxxxxxxxxxxxxxxxx>
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 From: Sigurd Schelstraete <sschelstraete@xxxxxxxxxxxxx>
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 From: Ron Porat <000009a0da80e877-dmarc-request@xxxxxxxxxxxxxxxxx>
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:
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 From: Wook Bong Lee <wookbong.lee@xxxxxxxxxxx>
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. From: Wook Bong Lee <wookbong.lee@xxxxxxxxxxx>
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 |