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

[STDS-802-11] 答复: [STDS-802-11] 答复: [STDS-802-11] Candidate SFD text contributions for inclusion to TGbe SFD: LIST OF MOTIONS FOR SEPTEMBER 03



--- 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]
发送时间: 202093 10:00
收件人: Yujian (Ross Yu) <ross.yujian@xxxxxxxxxx>; STDS-802-11@xxxxxxxxxxxxxxxxx
主题: RE: [STDS-802-11] 答复: [STDS-802-11] Candidate SFD text contributions for inclusion to TGbe SFD: LIST OF MOTIONS FOR SEPTEMBER 03

 

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]
Sent: Wednesday, September 02, 2020 1:11 AM
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11]
答复: [STDS-802-11] Candidate SFD text contributions for inclusion to TGbe SFD: LIST OF MOTIONS FOR SEPTEMBER 03

 

--- 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]
发送时间: 2020824 22:23
收件人: STDS-802-11@xxxxxxxxxxxxxxxxx
主题: [STDS-802-11] Candidate SFD text contributions for inclusion to TGbe SFD: LIST OF MOTIONS FOR SEPTEMBER 03

 

--- 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. 


Please refer to the document linked below for a list of all the motions (starting from slide 24)  that will be run during the Sept 03 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