| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
| --- This message came from the IEEE 802.11 Working Group Reflector ---
Hi Ron, Thanks for the comment. I don’t see additional complexity of my proposed alternative solution. The receiver needs to read all the RU allocation subfields anyway within the
2CCs. The Multi-RU signaling is not related with number of holes. By largely reducing the number of entries, there can be one dedicated zero user MRU entry
for each MRU size. We don’t need to use a combination of single RU zero user case. The latter case may make the two hole cases more complicated. For the overhead, 8 RU allocation subfields mean 1 byte, it is not small regarding signal field. And the number of entries in a bit table also matters. regards 于健 Ross Yu Huawei Technologies 发件人: Ron Porat [mailto:ron.porat@xxxxxxxxxxxx]
Hi Ross, Indeed this is a repeat of the previous discussion. We have reviewed your designs but feel that they require more complex receivers which unfortunately
adds to the fact that decoding the preamble through USIG/ESIG is already the most complex part of the design in our minds (so not the right place to add complexity). Really as you said in your method(s) the Rx needs to decode ALL the RU fields in both CC and add more complex logic to infer the M-RU exact location
(where the hole is). If we add more M-RU (2 holes) in rel. 2 I’m not even sure what the impact on that logic will be. In our proposal the hole, or exact location of M-RU is explicitly signaledà
hence 9 bits but simpler receiver. However the enumaration proposed is logical and makes for a simple decoder that can be based on reading on RU table in one CC.
Furthermore, in our view adding more complexity is OK if we add new features, but what are we getting from squeezing 9 bits into 8 bits? We have
looked at the overhead for 320MHz with ESIG at MCS0 (worst case), there are very few cases of # of users per CC where those extra 8 bits per CC cause the ESIG field to increase by one 4uS symbol (borderline cases). And what counts is ESIG total duration.
iWe think it’s not worth it for the added complexity. So my suggestion is that we go with a simple approach that rarely costs us anything and move on to finalize the RU table. Thanks much, Ron From: Yujian (Ross Yu) [mailto:ross.yujian@xxxxxxxxxx]
--- This message came from the IEEE 802.11 Working Group Reflector ---
Hi Alfred and all, I’d like to discuss SP#175 separately. SP#175 is the more detailed version of the previous failed motion. SP#175 also consumes 208 entries and expand RU allocation table from 8 bit in
11ax to 9 bit in 11be unnecessarily. Whilst alternative solutions: Opt B proposed in slide 7 of 970r1 only needs 40 entries, which fits the existing 8 bit table. Opt C proposed in slide 8 even only needs 9 entries.
By reading N RU allocation subfields, the Rx is able to identify the size and position of the MRU instead of introducing entries for each MRU position.
There is no need to introduce a very huge table with around 300 entries. regards 于健 Ross Yu Huawei Technologies 发件人: Alfred Asterjadhi [mailto:asterjadhi@xxxxxxxxx]
--- This message came from the IEEE 802.11 Working Group Reflector ---
Hello all, Our TGbe Editor has prepared the Rev 59 of the compendium of SPs and potential changes to the SFD, which can be found below: This is a call for members to review the new SFD text contributions (which are highlighted in yellow and identified by tags listed as [DCN (Presentation, Author, Affiliation), ...]
SP#X, ...) in the compendium of SPs document. Please do send an e-mail in response to this Call For Review if you would like to identify any of these "new SFD text contributions" as contributions that need further discussion. The deadline for sending these e-mails
is SEPTEMBER 02 2020 @10:00am ET. A list of these requested contributions will be queued for discussion and run as a separate motion (Motions >=127) during the Joint conference call scheduled
on September 03rd 2020. New SFD text contributions that have not received a request for further discussions will be part of the cumulative motion (Motion 124) that will be run at the
same Joint conference call.
For more information please refer to the subclause "Guideline-Building Consensus and Populating the TGbe SFD" in https://mentor.ieee.org/802.11/dcn/20/11-20-0984-01-00be-tgbe-teleconference-guidelines.docx. If you have any comments and/or questions please let me know. Best Regards, Alfred -- Alfred Asterjadhi, PhD IEEE802.11 TGbe Chair, Qualcomm Technologies Inc. Cell #: +1 858 263 9445 Office #: +1 858 658 5302 To unsubscribe from the STDS-802-11 list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1
To unsubscribe from the STDS-802-11 list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1
To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1 |