Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Wookbong, I think your modified text looks better. Thanks for the update. Best regards, Jinsoo From: Wook Bong Lee [mailto:wookbong.lee@xxxxxxxxxxx] 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] 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. -------------------------------------------------- 发件人: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] 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] 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] For trigger based RU signaling, I did not see the need for common filed. From: Junghoon Suh [mailto:Junghoon.Suh@xxxxxxxxxx] 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] 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] 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.
BRs, Xiaogang. From: Junghoon Suh <Junghoon.Suh@xxxxxxxxxx> 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] 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] 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] 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] 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] 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] 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, On Thu, Mar 19, 2020 at 9:08 PM Wook Bong Lee <wookbong.lee@xxxxxxxxxxx> wrote:
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 |