Thanks Jinsoo.
I will upload updated version, but will wait few more days as there maybe another comment.
Wook Bong
From: Jinsoo Choi [mailto:js.choi@xxxxxxx]
Sent: Thursday, March 26, 2020 4:21 PM
To: Wook Bong Lee <wookbong.lee@xxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] [PHY] mullti-RU allocation, 11-20/373
Hi Wookbong,
I think your modified text looks better. Thanks for the update.
Best regards,
Jinsoo
From: Wook Bong Lee [mailto:wookbong.lee@xxxxxxxxxxx]
Sent: Friday, March 27, 2020 12:14 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [PHY] mullti-RU allocation, 11-20/373
Hi Jinsoo,
I copied your question on multi-RU in this e-mail.
One more question on another SP for RU allocation in MU; (sorry for bringing up different contribution 373 here)
SP: Do you agree to use RU allocation subfield defined in 11ax to indicate RU to be assigned to each STA for MU PDDU when only one RU per a STA is assigned and
the number of multiplexed users in each RU is up to 8?
In 11ax, you know there is a case that the multiplexed users in a RU is not supported up to 8, when only two 106-RUs are assigned (with middle 26-RU hole) that
the users in each RU are limited as 4. Would you intend to change this case up to 8 which requires the modification of current RU signaling table and not aligned with your current text I guess?
Thanks for catching this.
It was not our intention. How about this?
·
Do you agree to use RU allocation subfield defined in 11ax to indicate RU to be assigned to each STA for MU PDDU when only one RU per a STA is assigned and the number of multiplexed users in each
RU is supported in 11ax?
Best regards,
Wook Bong Lee
From: Yujian (Ross Yu) [mailto:ross.yujian@xxxxxxxxxx]
Sent: Friday, March 20, 2020 6:06 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [PHY] mullti-RU allocation, 11-20/373
Hi all,
Overhead is important to consider as we already have more bits for U-SIG and its overflow info. Regarding complexity, I don't think it is an big issue and 11ax already has it.
--------------------------------------------------
regards
于健 Ross Yu
Sent from Great Huawei Mate 20X
发件人：Wook Bong Lee <wookbong.lee@xxxxxxxxxxx>
收件人：STDS-802-11-TGBE <STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx>
时 间：2020-03-21 08:13:20
主 题：Re: [STDS-802-11-TGBE] [PHY] mullti-RU allocation, 11-20/373
Yes! That was my point before.
I guess Ron wants to revert that motion.
Best regards,
Wook Bong Lee
From: Junghoon Suh [mailto:Junghoon.Suh@xxxxxxxxxx]
Sent: Friday, March 20, 2020 3:38 PM
To: Wook Bong Lee <wookbong.lee@xxxxxxxxxxx>;
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] [PHY] mullti-RU allocation, 11-20/373
At least, the RU Allocation sub-field is not needed even in case of the U-SIG over-flow, which is against the motion we have.
Regards
Junghoon
From: Wook Bong Lee [mailto:wookbong.lee@xxxxxxxxxxx]
Sent: March 20, 2020 6:33 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [PHY] mullti-RU allocation, 11-20/373
I guess “no common field in trigger based RU signaling method” is when U-SIG is not over flowed?
Wook Bong
From: Jianhan Liu [mailto:Jianhan.Liu@xxxxxxxxxxxx]
Sent: Friday, March 20, 2020 3:10 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [PHY] mullti-RU allocation, 11-20/373
For trigger based RU signaling, I did not see the need for common filed.
From: Junghoon Suh [mailto:Junghoon.Suh@xxxxxxxxxx]
Sent: Friday, March 20, 2020 3:01 PM
To: Jianhan Liu; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] [PHY] mullti-RU allocation, 11-20/373
Hi, Jianhan
So, the common field is not needed for the self-contained RU allocation. I think it is what I reckon.
We do not need any RU allocation table in the common field, if each user is self-contained with STA-ID, MCS and RU allocation.
Regards
Junghoon
From: Jianhan Liu [mailto:Jianhan.Liu@xxxxxxxxxxxx]
Sent: March 20, 2020 5:55 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [PHY] mullti-RU allocation, 11-20/373
Our analysis is that the efficiency can be more down by 40% only compared the SIG filed:
For
averall efficiency (compare the whole PPDU), a trigger based RU signaling can cause 15% throughput loss.
From: Chen, Xiaogang C [mailto:xiaogang.c.chen@xxxxxxxxx]
Sent: Friday, March 20, 2020 2:41 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [PHY] mullti-RU allocation, 11-20/373
Hi,
I think the beauty of trigger frame-like signaling is simplicity. Common filed will always be present in EHT-SIG regardless of which signaling scheme is chosen.
TF-like or reuse 11ax is just tradeoff between simplicity and overhead.
Some simple overhead analysis attached.
For TF-like, I assume 42bits/user to convey the whole resource allocation information and each user is independently coded (6bits tail + 4 bits CRC). 42 bits/user is a rough
estimation.
TF-like scheme has a bit more overhead to buy the simplicity for most case. For sure, overhead is large if many clients, e.g. 64 in the table, are scheduled. But for 64 clients/PPDU,
every client should not expect high throughput given the limited BW for each one.
|
Reuse 11ax (BPSK) |
TF-like (BPSK) |
|
|
320MHz, 16 STA, 242-RU/STA |
75/CC * 2CC + 52/user block*8 = 566 bits -> 11 Sym |
42*16 = 672 bits -> 13 Sym |
|
160MHz, 8 STA, 242-RU/STA |
43/CC * 2CC + 52 *4 = 294 bits -> 6 Sym |
42*8 = 336 bits -> 7 Sym |
|
320/160MHz, 6 STA, MUMIMO Full BW |
52/user block * 3 = 312 bits -> 3 Sym |
42*6 = 252 bits -> 5 Sym |
|
320MHz PPDU, 160MHz MUMIMO 6 STA + 160MHz OFDMA 8STA |
75/CC * 2CC + 52/user block*7 = 514 bits -> 10 Sym |
42*14 = 588 bits -> 12 Sym |
|
320MHz PPDU 64 STA |
75/CC * 2CC + 52 * 32 -> 35 sym |
42*64 -> 52 Sym |
BRs,
Xiaogang.
From: Junghoon Suh <Junghoon.Suh@xxxxxxxxxx>
Sent: Friday, March 20, 2020 2:17 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [PHY] mullti-RU allocation, 11-20/373
Hi, Ron
Do we need a common field in EHT-SIG or not in case of the trigger frame like RU signaling?
Regards
Junghoon
From: Ron Porat [mailto:000009a0da80e877-dmarc-request@xxxxxxxxxxxxxxxxx]
Sent: March 20, 2020 5:12 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [PHY] mullti-RU allocation, 11-20/373
Hi Tianyu,
We are looking into it, likely slightly higher for per-user only, depends on so many parameters, # of users, SIGB MCS, BW, …
Thanks,
Ron
From:
tianyu@xxxxxxxxx [mailto:tianyu@xxxxxxxxx]
Sent: Friday, March 20, 2020 1:49 PM
To: Ron Porat
Cc: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [PHY] mullti-RU allocation, 11-20/373
Hi Ron,
Using simple unified RU signaling is an attractive idea. But do you have any analysis on the overhead comparison?
Thanks.
Tianyu
On Mar 20, 2020, at 1:45 PM, Ron Porat <000009a0da80e877-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
Hi Wookbong,
I would suggest that we take a step back and think about it a bit more together with the MAC guys. In 11ax the PHY guys looked at various schemes for SIG-B
and ended up with 2 modes, one that has RU tables and one that doesn’t (aka ‘compressed mode’) and the MAC guys went in a different direction and designed a trigger frmae that is actually similar to the compressed mode. At least both SIG-B and the trigger
frmae can use high MCS for efficiency so that’s good.
Do we want to continue like that in 11be? And then the STA decodes a new advanced trigger frame with per user fields enhanced to include all new M-RU? but still
decoded new advanced RU tables with M-RU. Frankly it looks strange.
Thanks,
Ron
From: Wook
Bong Lee [mailto:wookbong.lee@xxxxxxxxxxx]
Sent: Friday, March 20, 2020 10:46 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [PHY] mullti-RU allocation, 11-20/373
Hi Jianhan,
I can certainly run the SP you suggested. No problem with that. As you mentioned it can be much clearer.
What about additional SPs in below? Are you fine with those SPs as well? Of cause, I can stop if first one fails. (Hope this is not happening, though.)
Best regards,
Wook Bong Lee
From: Jianhan
Liu [mailto:Jianhan.Liu@xxxxxxxxxxxx]
Sent: Friday, March 20, 2020 10:42 AM
To: Wook Bong Lee <wookbong.lee@xxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] [PHY] mullti-RU allocation, 11-20/373
Hi Wook bong,
I agree that motion 57 partially include what I suggested. The SP that I proposed maybe can make it more clear what the architecture of EHT-SIG is.
But it is up to the group to decide.
Thanks,
Jianhan
From: Wook
Bong Lee [mailto:wookbong.lee@xxxxxxxxxxx]
Sent: Friday, March 20, 2020 10:28 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [PHY] mullti-RU allocation, 11-20/373
Hi Jianhan,
Thanks for your response and suggestion.
I can certainly run following SP.
• Do
you agree to the RU allocation signaling in EHT-SIG is based on RU allocation signaling as defined in HE-SIGB of 11ax?
I though this is already agreed as we have following texts in SFD.
An RU Allocation subfield is present in the Common field of the EHT-SIG field of an EHT PPDU sent to multiple users.
· Compressed modes are TBD.
· Contents of the RU Allocation subfield are TBD.
[Motion 57, [9] and [25]]
Anyway, if this is not same, I can add your suggested SP in 11-20/373.
In addition to that, I think we can move bit more. J
• Do
you agree to use RU allocation subfield defined in 11ax to indicate RU to be assigned to each STA for MU PDDU when only one RU per a STA is assigned and the number of multiplexed users in each RU is up to 8?
From above SP, non-AP STA can reuse exactly same parsing method as in 11ax.
Maybe I was not clear enough in above SP.
To be super clear, I would like to give an example.
Currently RU Allocation subfield 0 means below.
<image001.png>
We want to maintain at least B7 – B0 shall be same as in Table 27-26—RU Allocation subfield except reserved values.
We can certainly add more bits to extend that, which is the second SP.
• Do
you support to indicate the information of multi-RU allocation for MU PDDU by adding additional RU Allocation subfield to RU Allocation subfield when more than one RUs are assigned to a STA?
– Note:
the number of bits for additional RU Allocation subfield is TBD
In this way, we can just add few more logics to existing one to cover all 11be cases.
Maybe I misunderstood. Please let me know I missed something.
Best regards,
Wook Bong Lee
From: Jianhan
Liu [mailto:jianhanliu@xxxxxxxxx]
Sent: Friday, March 20, 2020 10:06 AM
To: Wook Bong Lee <wookbong.lee@xxxxxxxxxxx>
Cc: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [PHY] mullti-RU allocation, 11-20/373
Hi Wook Bong,
Thanks for initiating this thread.
As to your straw poll, I am not sure if we should reuse RU allocation defined in 11ax because the RU allocation may be extended in different ways, for example, as in some of the presentations, 2 bits are added extend the RU allocation table
even for the scenarios same as 11ax.
However, I think the consensus of RU allocation proposals presented in the 11be conference calls is that the RU allocation signaling method is a HE-SIGB based method. I would like to have a more general straw poll than a detailed one because
we may come up with a more efficient way compared to 11ax. So how about the following general straw poll?
Do you agree to the RU allocation signaling in EHT-SIG is based on RU allocation signaling as defined in HE-SIGB of 11ax?
I think this general straw poll at least can give the group a direction and that is a progress.
Thanks,
Jianhan
On Thu, Mar 19, 2020 at 9:08 PM Wook Bong Lee <wookbong.lee@xxxxxxxxxxx> wrote:
Hi Dongguk,
Thanks for good question.
Since we already agreed 16 spatial stream support in 11be, I would like to see total 16 spatial stream signaling support in release 1 as well.
I don’t want to have two different signaling for release 1 and release 2.
If you see contribution 11-20/373, we added 16 user case for >= 106 tone RU cases.
We are open to limit max 8 for small size RUs.
If you see below SP,
SP#1
• Do you agree to use RU allocation subfield defined in 11ax to indicate RU to be assigned to each STA for MU PDDU when only one RU per a STA is assigned and the number of multiplexed users in each RU is up to 8?
It says when the number of multiplexed users in each RU is up to 8, and when only single RU is assigned (this condition is same as 11ax), then the RU allocation subfield definition is same.
In this way, a non-AP STA can reuse most part of parsing logic.
In my opinion, above SP covers all of your options.
Best regards,
Wook Bong Lee
From: Dongguk Lim [mailto:dongguk.lim@xxxxxxx]
Sent: Thursday, March 19, 2020 8:52 PM
To: Wook Bong Lee <wookbong.lee@xxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Cc: hg.cho@xxxxxxx; js.choi@xxxxxxx
Subject: RE: [STDS-802-11-TGBE] [PHY] mullti-RU allocation, 11-20/373
Hi Wookbong,
Thanks for trying to make a harmonized SPs regarding MRU allocation in OFDNA transmission.
I have a comment about the number of Users multiplexed in one RU.
I remembered that we had discussions on the number of users which are supported in MU-MIMO transmission shortly in the past F2F meeting. But, we haven’t been able to discuss this enough.
Anyway, we consider the supporting up to 16 spatial stream in 11be. So, do you want to restrict the number of spatial stream in MU-MIMO transmission?
And if do you expanding later for example, in R2 version, do you consider expanding the RU allocation subfield again then?
Best regards,
Dongguk
From: Wook Bong Lee [mailto:wookbong.lee@xxxxxxxxxxx]
Sent: Friday, March 20, 2020 8:20 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] [PHY] mullti-RU allocation, 11-20/373
Hi PHY fans,
This is an email to discuss straw poll for multi-RU allocation signaling in 11-20/285.
During 3/18 conference call, there was a request to discuss straw poll using e-mail reflector.
If you are not interested in this topic, sorry for this e-mail.
o 373r0 RU Allocation Subfield Design for Multi-RU Support (Myeongjin Kim)
First, Eunsung asked to defer the straw poll since he has some more multi-RU combination to propose, and it may impact the signaling design.
Eunsung’s contribution was discussed 3/18 call, and there was no agreement to add more multi-RU combination.
Second, Ron wanted to see whether we can use Trigger based, i.e. User Info field to indicate RU allocation information.
But as Ross mentioned during 3/18 call, we already agreed including RU Allocation subfield in the common field of EHT-SIG.
An RU Allocation subfield is present in the Common field of the EHT-SIG field of an EHT PPDU sent to multiple users.
· Compressed modes are TBD.
· Contents of the RU Allocation subfield are TBD.
[Motion 57, [9] and [25]]
So, I would like to run deferred SPs in 11-20/373.
If you have any question or any suggested modification, please let us know.
These are current SPs in 11-20/373.
SP#1
• Do you agree to use RU allocation subfield defined in 11ax to indicate RU to be assigned to each STA for MU PDDU when only one RU per a STA is assigned and the number of multiplexed users in each RU is up to 8?
SP#2
• Do you support to indicate the information of multi-RU allocation for MU PDDU by adding additional RU Allocation subfield to RU Allocation subfield when more than one RUs are assigned to a STA?
– Note: the number of bits for additional RU Allocation subfield is TBD
Best regards,
Wook Bong Lee
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
*********** MEDIATEK Confidentiality Notice ***********
The information contained in this e-mail message (including any
attachments) may be confidential, proprietary, privileged, or
otherwise exempt from disclosure under applicable laws. It is
intended to be conveyed only to the designated recipient(s). Any
use, dissemination, distribution, printing, retaining or copying
of this e-mail (including its attachments) by unintended recipient(s)
is strictly prohibited and may be unlawful. If you are not an
intended recipient of this e-mail, or believe that you have received
this e-mail in error, please notify the sender immediately
(by replying to this e-mail), delete any and all copies of this
e-mail (including any attachments) from your system, and do not
disclose the content of this e-mail to any other person. Thank you!
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
*********** MEDIATEK Confidentiality Notice ***********
The information contained in this e-mail message (including any
attachments) may be confidential, proprietary, privileged, or
otherwise exempt from disclosure under applicable laws. It is
intended to be conveyed only to the designated recipient(s). Any
use, dissemination, distribution, printing, retaining or copying
of this e-mail (including its attachments) by unintended recipient(s)
is strictly prohibited and may be unlawful. If you are not an
intended recipient of this e-mail, or believe that you have received
this e-mail in error, please notify the sender immediately
(by replying to this e-mail), delete any and all copies of this
e-mail (including any attachments) from your system, and do not
disclose the content of this e-mail to any other person. Thank you!
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
*********** MEDIATEK Confidentiality Notice ***********
The information contained in this e-mail message (including any
attachments) may be confidential, proprietary, privileged, or
otherwise exempt from disclosure under applicable laws. It is
intended to be conveyed only to the designated recipient(s). Any
use, dissemination, distribution, printing, retaining or copying
of this e-mail (including its attachments) by unintended recipient(s)
is strictly prohibited and may be unlawful. If you are not an
intended recipient of this e-mail, or believe that you have received
this e-mail in error, please notify the sender immediately
(by replying to this e-mail), delete any and all copies of this
e-mail (including any attachments) from your system, and do not
disclose the content of this e-mail to any other person. Thank you!
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