| 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 ---
Folks, Sharing my separate, targeted responses to certain esteemed colleagues below; Robert: I disagree. A proper vote on LB296 hinges directly upon precise interpretation of the UHR PAR language I referenced upon initiating this dialogue. As there is clearly NO current consensus on the same, I maintain this email thread at this time IS INDEED the proper forum for seeking some collective agreement on what “Throughput” is, so we can each cast a timely vote on whether D2.0 actually delivers the required amount of it. Vinko, Tom: C’mon guys, we in this venue are all products of a higher education steeped in the Socratic Method. We were all taught that you don’t prove a thesis by merely repeating the premise over and over, or claim that somebody else already proved it. So that you can then peremptorily dismiss dissents as “inaccurate information”. From the comments below I count 4 such fixin’s: ELR, LDPC2, DRU (aka DSO) and MAP (aka NPCA). Laurent: I took your advice and emailed you for “more details and explanations”. Never heard back, so I guess I’m just going to have to wing it here.
This is somewhat of a headscratcher for me. While I admit that ELR will extend UHR (MCS0) connectivity at least marginally beyond EHT’s, that doesn’t mean ELR INCREASES UHR throughput, just that it DOESN’T DECREASE it over that new “ELR Zone”.
Employing LDPC2 (instead of LDPC) adds about 1db more coding gain to UHR’s link budget over EHT’s. In practice, this manifests as about 12% greater “range at a given MCS” for UHR, quite similar to what happens with ELR! So, again, NO “at least 25% UHR Tpt increase…” due to LDPC2.
I don’t see how UHR simply re-arranging its same exact number of data-bearing OFDM subcarriers as EHT could possibly manifest as increased Throughput. Once more, NO “at least 25% UHR Tpt increase…” due to DRUs.
I left this for last since the exact same (flawed!) MAP analysis below was used to shoot down my LB291 ”NO” vote during Comment Resolution earlier this year. The case made then was that since a (dual AP-single Client) UHR MAP link could certainly transport well over 40% more Mbps than a (supposedly corresponding single AP-single client) EHT (necessarily non-MAP) link, therefore UHR can INDEED deliver at least 25% greater throughput than EHT. NOPE, SORRY-BOGUS COMPARISON!!! Once last time, NO “at least 25% UHR Tpt increase…” due to MAPs. All in all, NO “at least 25% UHR Tpt increase…” due to ANY D2.0 constituents. Bottom Line, dot 11 colleagues, I see myself complete vindicated in proclaiming that P802.11bn D2.0 IS NOT compliant with the P802.11bn PAR, and therefore, once again: P802.11bn D2.0 is fatally flawed and SHOULD NOT be forwarded to SA ballot for ratification and incorporation into IEEE Std 802.11 IOW, Vote “DISAPPROVE” on LB296, for reasons of PAR non-compliance! Best Regards, Carlos Carlos A. Rios CEO, Terabit Wireless LLC (408) 202-6294 From: *** IEEE STDS-802-11 List *** STDS-802-11@xxxxxxxxxxxxxxxxx On Behalf Of laurent cariou --- This message came from the IEEE 802.11 Working Group Reflector --- Hi, Agree with Vinko and Tom, and just adding small clarification, having authored the UHR PAR (before we close this thread, as it seems my previous email didn't go through). The PAR text that Tom shared was crafted on purpose to NOT mean "peak throughput" increase, but "throughput at range" increase. That's why we added the qualifier "in at least one signal to interference and noise (SINR) level (rate-vs-range)." Carlos, you can compare it with the PAR language from previous generations where we intended for peak throughput increase like EHT. We knew at the time that there would likely not be peak throughput increase features defined in UHR and wrote the UHR PAR to be achievable with the features that we would, and eventually did, define (some having been cited by Vinko and Tom). 11bn draft 2.0 is therefore fully compliant with the UHR PAR. Happy to give more details and explanations offline to you Carlos or others if need be. thanks, Laurent Le mardi 11 août 2026 à 20:36:22 UTC+2, Vinko Erceg <00000c44f70266db-dmarc-request@xxxxxxxxxxxxxxxxx> a écrit : --- This message came from the IEEE 802.11 Working Group Reflector --- Thanks Robert, I agree that we can stop emailing here, but inaccurate information went to a quite large audience and it is good that few people replied and corrected. 11bn Draft 2.0 is fully compliant with the UHR PAR, in my mind there is nothing to debate here. Best, Vinko.. From: *** IEEE STDS-802-11 List *** <STDS-802-11@xxxxxxxxxxxxxxxxx> on behalf of Stacey, Robert <robert.stacey@xxxxxxxxx> --- This message came from the IEEE 802.11 Working Group Reflector --- Hello Carlos, The right way to debate this is through the balloting and comment resolution process. Submit your comment(s) on LB296. The comment will be debated in TGbn. You can build support for your position there. Since this is PAR related, I'm also willing to let you present and build support in the September WG mid-week plenary. I don't think an email exchange will accomplish much. Regards, -Robert From: *** IEEE STDS-802-11 List *** <STDS-802-11@xxxxxxxxxxxxxxxxx> on behalf of Thomas Pare <0000296b6387558a-dmarc-request@xxxxxxxxxxxxxxxxx> --- This message came from the IEEE 802.11 Working Group Reflector --- Hello Vinko, I agree and believe the actual UHR PAR is not being correctly stated or interpreted. It reads [23/11-23-0480r3]: “…at least one mode of operation capable of increasing throughput by 25%, as measured at the MAC data service Access Point, in at least one Signal to Interference and Noise Ratio (SINR) level (Rate-vs-Range), compared to the Extremely High Throughput MAC/PHY operation” There are dozens of contributions that demonstrate UHR features (DSO, NPCA, ELR, DRU, MAP) enable 11bn devices to boost the Rate-vs-Range performance well above the 25% target. Best regards, Tom Pare From: *** IEEE STDS-802-11 List *** <STDS-802-11@xxxxxxxxxxxxxxxxx> On Behalf Of Vinko Erceg
--- This message came from the IEEE 802.11 Working Group Reflector --- Well, incorrect understanding. We all here know that "throughput" also includes a gamut of metrics such as system throughput, throughput in the presence of interference (NPCA, MAPC schemes), throughput in the presence of lower bandwidth non-APs (DSO), throughput while optimizing device power consumption (DPS), throughput at a farther coverage edge (ELR), throughput while meeting latency requirements (all the above features). Throughput cannot be interpreted as just a peak value that exists between 2 devices in the absence of any other contenders/conditions. Therefore, ".... a couple hundred of the world’s premier Wireless Technologists ...." have done a wonderful job on that and I thank all of them on their hard work and great amendment that will proliferate in billions of devices. Thank you All and Best Regards, Vinko Erceg From: *** IEEE STDS-802-11 List *** <STDS-802-11@xxxxxxxxxxxxxxxxx> on behalf of Carlos Rios <carlos@xxxxxxxxxxxxxxxxxxx> --- This message came from the IEEE 802.11 Working Group Reflector --- Dear IEEE802.11 Colleagues: I’m likely unknown to most of you (although a few may recall my pitching a 92 Gbps TGbn PHY a little while back), but I’ve actually been a diligent dot11-er since 1998. An Old School PHY guy, I materially contributed to standards b, a, g and n, only to then step back and watch all the young’uns go on to shine with ac, ax and, most famously, be. But now, however, tremendously dismayed with TGbn I feel compelled reach out to the entire 802.11 Voting Membership in this fashion. In short: - P802.11bn D2.0 is fatally flawed and SHOULD NOT be forwarded to SA ballot for ratification and incorporation into IEEE Std 802.11 IOW, Vote “DISAPPROVE” on LB296, for reasons of PAR non-compliance! In not so short:
Well, I don’t know about you, and maybe I’m just being an Old School by-the-book fuddy-duddy, but I find such shenanigans PATENTLY ABSURD, pretty embarrassing and more than just a little bit insulting. WHO DOES THIS? Definitely NOT the world’s premier Wireless Technologists. IMHO, the WG should respond by gently telling our misguided TGbn brethren “Uh, NO. Please go back and finish the task we gave you” As an editorial aside, I am shocked, SHOCKED that TGbn led a couple hundred of the world’s premier Wireless Technologists on a 3-year trek down this particular rabbit hole.
We dropped the ball, too. Oops. Colleagues, WE CAN DO BETTER THAN THIS! Please overwhelmingly “DISAPPROVE” LB296, let’s quickly put this unfortunate episode behind us and immediately get back to devising and standardizing the best radios this world has ever seen. UHR-EHT Throughput Analysis The P802.11 PAR reads, in part (boldface and parentheses mine): “… Ultra High Reliability (MAC/PHY operation) … is defined as …operation capable of increasing throughput by 25% … compared to the Extremely High Throughput MAC/PHY operation…” WiFi Point-to-Point Link Throughput can be succinctly expressed as: IEEE802.11 Tpt = Peak WiFi Stream Data Rate (“PDR”) x MIMO Order (“Nss”) x MLO order “nMLO”, where PDR = Maximum MCS/ Bandwidth/ Guard Interval construct per the corresponding IEEE802.11 Modulation-Coding Scheme Table(s) nMLO = Number of distinct AP-Client connections comprising the link - A fair UHR-EHT Link Tpt comparison would first predicate identical MIMO and MLO orders - Such reduces the alleged throughput discrepancy to a 25% greater UHR PDR over that of EHT - However, UHR and EHT Peak Data Rates are IDENTICAL (i.e., 2882 Mbps given MCS13, 320 MHz BW and 800ns GI)! Ergo, this particular UHR construct IS NOT CAPABLE of 25% greater throughput than EHT So, P802.11bn D2.0 DOES NOT COMPLY with its enabling P802.11bn PAR QED Thanks for your attention, and best regards, Carlos Carlos A. Rios CEO, Terabit Wireless LLC (408) 202-6294 Carlos A. Rios CEO, Terabit Wireless LLC (408) 202-6294 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 ************* 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 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 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 |