Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Got it. Anyway, that can be further discussed under the spectral mask. Best regards, Wook Bong Lee From: Ron Porat [mailto:ron.porat@xxxxxxxxxxxx]
Hi Wook bong For the second one, can non-AP assume no need to further meet the puncturing mask when there is no puncturing information in Beacon? Yes, that’s my understanding.
I suppose we can leave it to the (smart) AP to manage emissions in that case but I’m not sure what if anything we need to say in the spec. we can discuss it more. Thanks, Ron From: Wook Bong Lee <wookbong.lee@xxxxxxxxxxx>
Hi Ron, Thanks. Sure for #1. I will update the draft. For the second one, can non-AP assume no need to further meet the puncturing mask when there is no puncturing information in Beacon? In other words, AP will ensure it, e.g. by assigning MCS 7 or higher? Can we capture that kind of requirement for AP? Best regards, Wook Bong Lee From: Ron Porat [mailto:ron.porat@xxxxxxxxxxxx]
Hi Wook bong, In regards to #1 let’s hear on the call what people prefer and go with that. In regards to #2 the AP may do any puncturing it wants based on the spec but what we are defining is what the non-AP STA will be required to meet when transmitting
a TB PPDU. Thanks, Ron From: Wook Bong Lee <wookbong.lee@xxxxxxxxxxx>
Hi Ron, Thanks for the suggestion. Regarding number 1, I think epsilon – 2 seems too tight. Original proposal was epsilon + 1, allowing leakage from both side. As others commented, we can live
with epsilon, i.e. EVM. In this case, the non-contiguous one becomes same as larger block requirement, e.g. 2x996+484 requirement is same as 3x996. Regarding number 2, I am fine with static one. In this case, we don’t allow AP to perform dynamic puncturing for TB PPDU? Best regards, Wook Bong Lee From: Ron Porat [mailto:ron.porat@xxxxxxxxxxxx]
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 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: Wook Bong Lee
Hi Alfred, Sigurd and Tianyu, Can you please add following in the PHY queue? 11-21/639, Proposed Resolution of Remaining TBDs in 36.3.19.4.4 and 36.3.20.3, Wook Bong Lee (Samsung) I will upload today or next Monday morning. Best regards, Wook Bong Lee From: Alfred Asterjadhi [mailto:asterjadhi@xxxxxxxxx]
Hello all,
The deadline for sending these e-mails is April 13th 2021 @10:00am ET.
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 |