Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 答���: [STDS-802-11-TGBE] SPs discussion regarding RU allocation (609r4)

Hi Wookbong,

 

Further discussions should stand on the shoulders of giants (a baseline table). If you have any concerns on any of the entries, please let me know.

 

regards

于健 Ross Yu

Huawei Technologies

 

发件人: Wook Bong Lee [mailto:wookbong.lee@xxxxxxxxxxx]
发送时间: 2020年5月30日 0:57
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] SPs discussion regarding RU allocation (609r4)

 

Hi Ross,

 

Again, if you think “people are free to add or remove some of the entries by further discussion” then I would recommend not to have the table yet!

 

Agreeing on something and revert it later will take a lot more time than doing it when it is stable.

 

Best regards,

Wook Bong Lee

 

From: Yujian (Ross Yu) [mailto:ross.yujian@xxxxxxxxxx]
Sent: Wednesday, May 27, 2020 8:03 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] SPs discussion regarding RU allocation (609r4)

 

Hi Ron,

 

I am fine with that. The table now is a baseline. People are free to add or remove some of the entries by further discussion. Thanks.

 

regards

于健 Ross Yu

Huawei Technologies

 

发件人: Ron Porat [mailto:ron.porat@xxxxxxxxxxxx]
发送时间: 2020年5月28日 10:44
收件人: Yujian (Ross Yu) <ross.yujian@xxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: RE: [STDS-802-11-TGBE] SPs discussion regarding RU allocation (609r4)

 

Hi Ross,

 

Thanks very much for the changes.   I reviewed the table again and have one suggestion to remove the three combinations below that have no middle RU26 since we can now use their counterparts in the orange side so no point sending an inefficient RU combination with a hole when we have the exact same combination but with the hole  filled.

 

 

52

52

--

106

1

 

106

--

52

52

1

106

--

106

1

 

 

Let me know your thoughts,

 

Regards,

Ron

 

 

 

From: Yujian (Ross Yu) [mailto:ross.yujian@xxxxxxxxxx]
Sent: Tuesday, May 26, 2020 7:08 PM
To: Ron Porat; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: 答复: [STDS-802-11-TGBE] SPs discussion regarding RU allocation (609r4)

 

Hi Ron,

 

I have added two entries back, 484-tone RU/996-tone RU contributes to zero user fields. Now it is exactly what you said. 11ax entries except removal of MU-MIMO support for 106-tone RU, and 23 entries for small MRU combinations.

 

Please double check. It is also in slide 18 of:

https://mentor.ieee.org/802.11/dcn/20/11-20-0609-05-00be-further-discussion-on-ru-allocation-subfield-in-eht-sig.pptx

 

 

 

regards

于健 Ross Yu

Huawei Technologies

 

发件人: Ron Porat [mailto:000009a0da80e877-dmarc-request@xxxxxxxxxxxxxxxxx]
发送时间: 2020年5月27日 5:47
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] SPs discussion regarding RU allocation (609r4)

 

Hi Ross,

 

In your table below, is the only difference relative to 11ax the orange part + the omission of MU-MIMO over 106RU?

 

Thanks,

Ron

 

 

 

From: Wook Bong Lee [mailto:wookbong.lee@xxxxxxxxxxx]
Sent: Tuesday, May 26, 2020 1:59 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] SPs discussion regarding RU allocation (609r4)

 

Hi Ross,

 

Thanks.

We are preparing a contribution on this topic.

It will be ready before next PHY meeting.

We can further discuss during next meeting.

 

Best regards,

Wook Bong Lee

 

From: Yujian (Ross Yu) [mailto:ross.yujian@xxxxxxxxxx]
Sent: Monday, May 25, 2020 8:29 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 答复: SPs discussion regarding RU allocation (609r4)

 

Hi all,

 

Since we have no PHY sessions this week, I’d like to continue the discussion regarding RU allocation subfields using email reflector. I have uploaded 609r4 with updated SPs:

https://mentor.ieee.org/802.11/dcn/20/11-20-0609-04-00be-further-discussion-on-ru-allocation-subfield-in-eht-sig.pptx

 

For SP2, I have made the changes according to some previous passed SPs regarding MU-MIMO support, remove TBD regarding number of entries. The large MRU part still needs some further discussion, so I don’t touch that part now. There are also some comments regarding compressed modes, I add a subbullet to say it is TBD. If you have concerns regarding specific entries, please let me know.

 

Table XX - RU Allocation subfield

order

#1

#2

#3

#4

#5

#6

#7

#8

#9

Number
of entries

 

TBD

26

26

26

26

26

26

26

26

26

1

 

TBD

26

26

26

26

26

26

26

52

1

 

TBD

26

26

26

26

26

52

26

26

1

 

TBD

26

26

26

26

26

52

52

1

 

TBD

26

26

52

26

26

26

26

26

1

 

TBD

26

26

52

26

26

26

52

1

 

TBD

26

26

52

26

52

26

26

1

 

TBD

26

26

52

26

52

52

1

 

TBD

52

26

26

26

26

26

26

26

1

 

TBD

52

26

26

26

26

26

52

1

 

TBD

52

26

26

26

52

26

26

1

 

TBD

52

26

26

26

52

52

1

 

TBD

52

52

26

26

26

26

26

1

 

TBD

52

52

26

26

26

52

1

 

TBD

52

52

26

52

26

26

1

 

TBD

52

52

26

52

52

1

 

TBD

52

52

--

106

1

 

TBD

106

--

52

52

1

 

TBD

26

26

26

26

26

106

1

 

TBD

26

26

52

26

106

1

 

TBD

52

26

26

26

106

1

 

TBD

52

52

26

106

1

 

TBD

106

26

26

26

26

26

1

 

TBD

106

26

26

26

52

1

 

TBD

106

26

52

26

26

1

 

TBD

106

26

52

52

1

 

TBD

106

--

106

1

 

TBD

52

52

--

52

52

1

 

TBD

242-tone RU empty (with zero users)

1

 

TBD

106

26

106

1

 

TBD

242

8

 

TBD

484

8

 

TBD

996

8

 

TBD

2*996

8

 

TBD

52

52

26

26

26

52

1

 

TBD

52

52

26

52

26

26

1

 

TBD

52

52

26

52

52

1

 

TBD

52

52

--

106

1

 

TBD

106

--

52

52

1

 

TBD

26

26

26

26

26

106

1

 

TBD

26

26

52

26

106

1

 

TBD

52

26

26

26

106

1

 

TBD

52

52

26

106

1

 

TBD

106

26

26

26

26

26

1

 

TBD

106

26

26

26

52

1

 

TBD

106

26

52

26

26

1

 

TBD

106

26

52

52

1

 

TBD

106

--

106

1

 

TBD

52

52

--

52

52

1

 

TBD

242-tone RU empty (with zero users)

1

 

TBD

106

26

106

1

 

TBD

242

8

 

TBD

484

8

 

TBD

996

8

 

TBD

2*996

8

 

TBD

26

26

26

26

26

52

26

26

1

TBD

26

26

52

26

26

26

26

26

1

TBD

26

26

52

26

26

26

52

1

TBD

26

26

52

26

52

26

26

1

TBD

26

26

52

26

52

26

26

1

TBD

26

26

52

26

52

26

26

1

TBD

26

26

52

26

52

52

1

TBD

52

26

26

26

52

26

26

1

TBD

52

52

26

52

26

26

1

TBD

26

26

26

26

26

106

1

TBD

26

26

52

26

106

1

TBD

26

26

52

26

106

1

TBD

26

26

52

26

106

1

TBD

52

26

26

26

106

1

TBD

52

52

26

106

1

TBD

106

26

26

26

26

26

1

TBD

106

26

26

26

52

1

TBD

106

26

52

26

26

1

TBD

106

26

52

26

26

1

TBD

106

26

52

26

26

1

TBD

106

26

52

52

1

TBD

106

26

106

1

TBD

106

26

106

1

 

For SP3 and 4, it is for large single RU, try to follow 11ax, again compressed modes TBD

•     SP3: Do you agree that for RU242, RU484 or RU996, in the RU allocation table, 9 entries per RU size will be used to indicate: contributes 0~8 User fields to the User Specific field in the same EHT-SIG content channel as this RU Allocation subfield?

–    Compressed modes are TBD.

–    Yes/No/Abstain

 

•     SP4: Do you agree that for RU 2*996,  in the RU allocation table, 9 entries per RU size will be used to indicate: contributes 0~8 User fields to the User Specific field in the same EHT-SIG content channel as this RU Allocation subfield?

–    Compressed modes are TBD.

–    Yes/No/Abstain

 

SP2-4 are more straightforward thoughts. Let’s focus on SP2-4 first.

 

Please share your comments if you have any concerns or suggestions. Thanks.

 

regards

于健 Ross Yu

Huawei Technologies

 

发件人: Wook Bong Lee [mailto:wookbong.lee@xxxxxxxxxxx]
发送时间: 2020年5月14日 3:12
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] SPs discussion regarding RU allocation

 

Thanks, Sameer.

I am also fine with the SP without the number of users.

 

Hope we can move forward with it.

 

Best regards,

Wook Bong Lee

 

 

From: Sameer Vermani [mailto:svverman@xxxxxxxxxxxxxxxx]
Sent: Wednesday, May 13, 2020 12:00 PM
To: Wook Bong Lee <wookbong.lee@xxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: SPs discussion regarding RU allocation

 

Hi Wookbong,

 

Thanks for your comments.

 

It’s Ross’s SP in the end, so I will leave it to him as to whether he wants to add the “number of users” part or not.  I just mentioned what I would be comfortable with at this point of time as far as the SP goes. Maybe it will make sense for the RU allocation sub-field to also tell the “number of users”, but that’s a detail I would like to discuss later as we need more time to think about it.

 

Regards,

Sameer

 

From: Wook Bong Lee <wookbong.lee@xxxxxxxxxxx>
Sent: Wednesday, May 13, 2020 11:51 AM
To: Sameer Vermani <svverman@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: SPs discussion regarding RU allocation

 

CAUTION: This email originated from outside of the organization.

Hi Sameer,

 

Thanks for discussion.

Don’t get me wrong. I was asking whether that was his intention.

Anyway, I would like to know your detailed design so that we can see how it works.

 

I don’t know what is the benefit of splitting a number of users allocated to each RU from the RU Allocation subfield.

If your proposal is to make it simplify signaling, then I would like to repeat what I mentioned to Ron for self-contained design.

We already have a parsing algorithm for 11ax, at least that part it does not complicate the implementation, actually changing from that complicates the implementation.

As far as I know, Ross’s new design is to reduce the number of bits for the RU Allocation subfield.

Still, his design preserves the 11ax part.

 

Best regards,

Wook Bong Lee

 

From: Sameer Vermani [mailto:svverman@xxxxxxxxxxxxxxxx]
Sent: Wednesday, May 13, 2020 9:48 AM
To: Wook Bong Lee <wookbong.lee@xxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: SPs discussion regarding RU allocation

 

Hi Ross,

 

Thanks for the updated SP text.

 

Regarding SP1, I like your new proposed text. I actually would not like to add what Wook Bong is proposing below as there might be a possibility for some or all of the MU-MIMO modes to be signaled through a compressed mode. Hence, I think the “number of users allocated to each RU” maybe signaled in a different way for the MU-MIMO modes (including packets where MU-MIMO is being done on part of the PPDU BW).

 

Regarding SP2, I agree with Wook Bong that it maybe premature to discuss the table right now. I would prefer to defer that discussion and focus on higher level concepts for now.

 

Thanks,

Sameer

 

From: Wook Bong Lee <wookbong.lee@xxxxxxxxxxx>
Sent: Wednesday, May 13, 2020 9:10 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] SPs discussion regarding RU allocation

 

CAUTION: This email originated from outside of the organization.

Hi Ross,

 

Thanks for this.

 

I would like to focus on first SP.

You may want to add ‘except TB PPDU’ after ‘an EHT PPDU sent to multiple users’.

One more ting, in 11ax, the RU allocation table is indicating number of users allocated to each RU as in the text you captured.

You don’t want to capture that part?

also indicates information needed to compute the number of users allocated to each RU

 

Second SP, the table you provide is list of potential RU allocation which is trivial based on agreements so far.

So, maybe better to discuss more detail concept than the table.

Table itself can be developed based on high level concept agreement later.

We may have different row order than your table in below. It can be confusing.

 

One note, below rows can be TBD rows as well.

TBD

26

26

52

26

106

1

TBD

106

26

52

26

26

1

 

Best regards,

Wook Bong Lee

 

 

From: Yujian (Ross Yu) [mailto:ross.yujian@xxxxxxxxxx]
Sent: Wednesday, May 13, 2020 12:19 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] SPs discussion regarding RU allocation

 

Hi all,

 

Last meeting, the agreement is to prepare a better language regarding RU allocation SPs. Hence I have prepared a revised version with the updated SPs.

 

https://mentor.ieee.org/802.11/dcn/20/11-20-0609-02-00be-further-discussion-on-ru-allocation-subfield-in-eht-sig.pptx

 

The first two SPs are also pasted here.  All your comments are welcome.

 

SP1: Do you agree to add the following to the 11be SFD:

l  An RU Allocation subfield that is present in the Common field of the EHT-SIG field of an EHT PPDU sent to multiple users, indicates RU assignment, including the size of the RU(s) and their placement in the frequency domain, to be used in the EHT modulated fields of the PPDU in the frequency domain.

o   Compressed modes are TBD.

 

Discussion:

Note in 11ax specs, we have the following description:

Each RU Allocation subfield in an HE-SIG-B content channel corresponding to a 20 MHz frequency segment indicates the RU assignment, including the size of the RU(s) and their placement in the frequency domain, to be used in the HE modulated fields of the HE MU PPDU in the frequency domain, also indicates information needed to compute the number of users allocated to each RU, where the subcarrier indices of the RU(s) meet the conditions in Table 27-25 (RUs associated with each RU Allocation subfield for each HESIGB content channel and PPDU bandwidth).

 

For SP1, I just try to follow 11ax without mentioning too much details.

 

Note We also have the following passed motion as a baseline:

l  An RU Allocation subfield is present in the Common field of the EHT-SIG field of an EHT PPDU sent to multiple users.

o   Compressed modes are TBD.

o   Contents of the RU Allocation subfield are TBD.

[Motion 57, [9] and [25]]

 

 

SP2: Do you agree that the mapping from the TBD-bit RU Allocation subfield to the RU assignment, contains the following entries:

l  The RUs highlighted in orange means combination.

Table XX RU Allocation subfield

order

#1

#2

#3

#4

#5

#6

#7

#8

#9

Number
of entries

 

TBD

26

26

26

26

26

26

26

26

26

1

 

TBD

26

26

26

26

26

26

26

52

1

 

TBD

26

26

26

26

26

52

26

26

1

 

TBD

26

26

26

26

26

52

52

1

 

TBD

26

26

52

26

26

26

26

26

1

 

TBD

26

26

52

26

26

26

52

1

 

TBD

26

26

52

26

52

26

26

1

 

TBD

26

26

52

26

52

52

1

 

TBD

52

26

26

26

26

26

26

26

1

 

TBD

52

26

26

26

26

26

52

1

 

TBD

52

26

26

26

52

26

26

1

 

TBD

52

26

26

26

52

52

1

 

TBD

52

52

26

26

26

26

26

1

 

TBD

52

52

26

26

26

52

1

TBD

52

52

26

52

26

26

1

TBD

52

52

26

52

52

1

TBD

52

52

-

106

TBD

TBD

106

-

52

52

TBD

TBD

26

26

26

26

26

106

TBD

TBD

26

26

52

26

106

TBD

TBD

52

26

26

26

106

TBD

TBD

52

52

26

106

TBD

TBD

106

26

26

26

26

26

TBD

TBD

106

26

26

26

52

TBD

TBD

106

26

52

26

26

TBD

TBD

106

26

52

52

TBD

TBD

106

--

106

TBD

TBD

52

52

--

52

52

1

TBD

106

26

106

TBD

TBD

242

TBD

TBD

484

TBD

TBD

996

TBD

TBD

2*996

TBD

TBD

26

26

26

26

26

52

26

26

1

 

TBD

26

26

52

26

26

26

26

26

1

 

TBD

26

26

52

26

26

26

52

1

 

TBD

26

26

52

26

52

26

26

1

 

TBD

26

26

52

26

52

26

26

1

 

TBD

26

26

52

26

52

26

26

1

 

TBD

26

26

52

26

52

52

1

 

TBD

52

26

26

26

52

26

26

1

 

TBD

52

52

26

52

26

26

1

 

TBD

26

26

26

26

26

106

TBD

 

TBD

26

26

52

26

106

1

 

TBD

26

26

52

26

106

TBD

 

TBD

26

26

52

26

106

TBD

 

TBD

52

26

26

26

106

TBD

 

TBD

52

52

26

106

TBD

 

TBD

106

26

26

26

26

26

TBD

 

TBD

106

26

26

26

52

TBD

 

TBD

106

26

52

26

26

TBD

 

TBD

106

26

52

26

26

1

 

TBD

106

26

52

26

26

TBD

 

TBD

106

26

52

52

TBD

 

TBD

106

26

106

TBD

 

TBD

106

26

106

TBD

 

 

 

Discussion:

Now there is argument regarding MU-MIMO support for 106-tone RU, number of entries for MU-MIMO support (8 or 16), large MRU indication method. The entries in the table now try to avoid those controversial parts.

 

regards

于健 Ross Yu

Huawei Technologies

 

 

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