Given that OFDMA is generally not enabled, router makers have not been providing guidance on how to test it. Device makers are also holding cards close to their chests, although Broadcom provided some tips for showing OFDMA's benefits at their best. Qualcomm has yet to make time to discuss OFDMA testing with me.
Intel has been somewhat helpful, providing a handful of AX200 adapters and responding to some questions. I've been able to get more information from developers on the linux-wireless mailing list, however. Johannes Berg from Intel Germany has been particularly helpful, sharing key information on how to make the AX200 capture OFDMA HE-MU data packets.
I also need to acknowledge two equipment makers for their help. Arris (now part of CommScope) arranged to have Broadcom install a special firmware load that basically turned their mAX Pro mesh router into a Broadcom reference AP. This gave me full control of the various AP parameters involved in OFDMA. Without their help, I would not have had an AP to use that supports UL and DL OFDMA on both bands.
NETGEAR has also been very helpful, engaging in multiple OFDMA test method discussions and answering any questions I've asked.
The resulting OFDMA testbed shown below is essentially the same used for Wi-Fi 6 RvR testing. A single, cable-connected Intel AX200 STA has been replaced by an octoScope Box18 with four Samsung S10e smartphones inside. Four octoScope high-gain dual-band antennas grab the RF and a four-channel 90 dB range programmable attenuator (quadAtten) is used to attenuate signal level.
The quadAtten feeds into a four-channel two-way RF splitter/combiner, whose second port connects to octoScope Pal-24 and Pal-5 partner devices that have their own attenuator. This provides the option of adding 2.4 GHz b/g/n and 5 GHz a/n/ac STAs into the test mix.
OFDMA test setup
Here's the Arris mAX Pro in the octoScope Box38. The four antennas used for OFDMA testing are photo left.
Arris mAX Pro in test chamber
Here's a view of the four Samsung S10e's in the smaller Box18. The phones are spaced evenly and, yes, right up against the antennas. Experimentation found that the slight tilt helped maximize signal level. This setup provided a maximum RSSI level around -50 dBM for each STA.
Four Samsung S10e in second chamber
My test measures total UDP throughput for the four phones with OFDMA enabled and disabled. The test is run by a Python script using the octoScope platform to run the test and report the results. Android adb shell commands are used to control Samsung S10 association and start/stop iperf3 running in the Magic Iperf app on each phone.
The script runs a rate vs. range (RvR) test multiple times using UDP traffic with different packet size for each run. Specifically, the RvR tests runs UDP traffic for 30 seconds per step, using 6 dB steps, 0-36 dB attenuation range. The RvR test is repeated with 128, 166, 512 and 1500 Byte packet size. The whole sequence is then repeated a second time to check for repeatability. Then the same sequence is run uplink. All devices are reassociated between each RvR run.
This test shows total throughput gain with some combinations of packet size and signal level. It also shows significant total throughput loss in other combinations of signal level and packet size. I'm showing only uplink results due to a current limitation in the octoScope system that prevents proper UDP results reporting running downlink traffic to iperf3 endpoints (vs. octoScope's built-in traffic endpoint).
The plot shows total throughput gain between OFDMA disabled and enabled in the Arris AP plotted on the Y axis. The X axis shows results grouped by packet size and applied attenuation. So, for example, the highest gain of 33% was obtained with 1500 byte (standard) packet size and 18 dB of applied attenuation.
It's obvious there is no logical progression in these results. The primary consistency is that throughput gain went negative when 24 dB of attenuation was applied. (The phones reported RSSI in the mid -70 dBm range with this attenuation.) I'm not showing the results with 30 and 36 dB of attenuation since those values caused at least one of the STAs to disconnect or report essentially unusable throughput.
OFDMA Gain - Uplink - Run 1
The second test run shows high variation in the results. There's a rough correlation in the conditions producing gain, but gain values are mostly different.
OFDMA Gain - Uplink - Run 2
Keep in mind that this data was produced by an AP that is essentially a Broadcom reference design. While you can buy the Arris mAX Pro, you can't buy it with the firmware used in this test.
The hype machine pushing Wi-Fi 6 has been as shameless as the one behind 5G mobile technology. Both are pushing products that don't really deliver on their breathless promises of higher bandwidth, at least not without a lot of fine-print caveats...if you can find them.
But there's a difference between hype and flat-out misrepresentation. When router makers shipped routers without a key 802.11ac feature—MU-MIMO—working, they provided clear disclaimers, like "MU-MIMO ready". Hell, they even clearly stated in product specs that the products were based on the draft 11ac IEEE spec.
With AX, clear disclosure of product limitations and key missing features appear to be a thing of the past. As I said at the top of this piece, we're into year 2 of manufacturers shipping Wi-Fi 6 consumer routers that still don't support working OFDMA, a key feature of the (still) draft 802.11ax standard. And manufacturers still don't clearly disclose that fact.
OFDMA is featured prominently in product marketing material, but the fact that the product does not yet support it is not. If you can find a disclaimer, it's typically buried deep in a spec sheet footnote, vaguely stated and not even tied directly to the spec it's disclaiming. Nor do marketing material or spec sheets clearly state which Wi-Fi 6 features are supported.
This whole situation stinks and marks a new low in Wi-Fi marketing. So, router makers, it's long past time to come clean and include information on which AX features your products actually support.
Yes, I know this could run into a crazy long list and could change over time. So why not start with the key features prominently touted in marketing material, namely, OFDMA DL and UL, DL MU-MIMO and 160 MHz channels? These are the features most likely to affect real-world consumers, so their support (or lack thereof) should be clearly stated. Update your online spec sheets when support is added and flag users to changes in firmware release notes, or via alerts in those apps you're always pushing users to install.
That said, I'm still working on Wi-Fi 6 and other test methods, with an eye to next seeing if Wi-Fi 6 really reduces latency as it claims to do. But it sure would be nice if I had some real products to test that actually fully support the (still draft) 802.11ax standard.