Like every other website on the planet, SmallNetBuilder uses cookies. Our cookies track login status, but we only allow admins to log in anyway, so those don't apply to you. Any other cookies you pick up during your visit come from advertisers, which we don't control.
If you continue to use the site, you agree to tolerate our use of cookies. Thank you!

Wireless Features

{mospagebreak toctitle=Introduction, Holdup, More on RUs}

 

Introduction

OFDMA spectrum plot

OFDMA spectrum plot
Credit: Gjermund Raaen

I feel like I've been on hold for the past year.

As 2018 drew to a close, the collapse of advertising support caused me to shift gears into paid consulting. While this has been better for me financially, the primary focus on consulting work has meant virtually no product reviews have been posted on SmallNetBuilder in 2019.

I've really, really been trying to change that. But I continue to run into obstacles while trying to develop new Wi-Fi test methods to move beyond the focus on speed tests to measure the quality, robustness and efficiency of Wi-Fi products.

After finishing the automation of the TR-398 Wi-Fi Performance Test suite on the octoScope platform, I've been mainly trying to demonstrate that OFDMA, a key Wi-Fi 6 feature, can produce higher total throughput. TL;DR: I have seen higher total throughput with OFDMA enabled, but gains are highly variable.

OFDMA is beginning to look at lot like MU-MIMO.

As I noted in Wi-Fi 6 Performance Roundup: Five Routers Tested, one of the chief obstacles in the quest to test OFDMA has been the fact that most of the consumer Wi-Fi 6 products on the market to date have not had OFDMA enabled. Time and time again, I was told that new firmware enabling OFDMA would be released in a month or so, only to have that month come and go without new firmware. It's kinda hard to develop test methods when you don't have something to test.

As of end of 2019, there are four Wi-Fi 6 routers with OFDMA enabled that you can buy in the U.S., shown in Table 1. This is out of almost two dozen Wi-Fi 6 routers or mesh systems announced.

Product Wi-Fi 6 Certified Platform OFDMA Verified Notes
2.4 GHz
DL
2.4 GHz
UL
5 GHz
DL
5 GHz
UL
ASUS RT-AX88U Yes Broadcom No No Yes Yes Yes See below
NETGEAR RAX120 No Qualcomm Yes No Yes No Yes Chipset not capable of UL OFDMA
Amplifi Alien No Qualcomm Yes Yes Yes Yes No Likely uses new Qualcomm chip version
Linksys MX5300 (Velop AX) Yes Qualcomm Yes Yes Yes Yes No Likely uses new Qualcomm chip version
Buffalo AirStation WXR-5950AX12 Yes Qualcomm? Yes Yes Yes Yes No Japan only. Likely uses new Qualcomm chip version
Buffalo AirStation WXR-5950AX12R Yes Qualcomm? Yes Yes Yes Yes No Japan only. Likely uses new Qualcomm chip version
Table 1: OFDMA support summary

The Verified column in Table 1 means I've seen the product actually transmit HE-MU data frames, which are required for OFDMA operation. For the others, you'll have to take the manufacturer's word for it, which I would not recommend. Because Wi-Fi 6 Certification, which requires supporting Downlink (DL) and Uplink (UL) OFDMA on both bands, isn't a guarantee you'll actually get OFDMA in the router you buy.

Case in point, the ASUS RT-AX88U. ASUS started by releasing a beta firmware back around August, which enabled DL OFDMA in 5 GHz only. Then, in November, ASUS announced the router was now Wi-Fi 6 Certified. When updated firmware was posted a week or so later, however, there was no OFDMA enable for the 2.4 GHz radio. ASUS explained this was due to compatibility problems with "legacy" devices.

So Wi-Fi 6 Certification doesn't guarantee that OFDMA will be fully enabled, either. And key features like 160 MHz channel width, DL (AX) MU-MIMO, Target Wake Time (TWT) and many OFDMA-related features are optional Wi-Fi 6 Certifications, as indicated by the search filters shown below in the Wi-Fi CERTIFIED product finder.

Wi-Fi 6 Cerficiation option

Wi-Fi 6 Cerficiation options

What's The Holdup?

So here we are moving into year two of the Great Transition to Wi-Fi 6 with high-priced, top-of-line routers still shipping without support (or guarantee of support) for key Wi-Fi 6 features. The story has been different on the client side, however, where there has been no lack of OFDMA-enabled devices looking for APs and routers to work with.

The Samsung Galaxy S10 line started to ship shortly after Wi-Fi 6 routers hit store shelves. And Intel had its AX200 M.2 format card ready for laptops. Hell, even Apple released the AX-enabled iPhone 11 in a relatively timely manner, although about a year behind Samsung.

All these devices support OFDMA and DL AX MU-MIMO as near as I can tell, looking at packet captures. So the obstacle is clearly on the router / AP side. Why?

The answer is that the folks writing the code for the AP airtime scheduler have a hellaciously difficult job. In the old days, all the scheduler had to do was send out packets using simple methods like round-robin. Then came packet aggregation in 11n and even more in 11ac, which meant packets didn't always get sent out right away, but were queued and combined into larger frames. AC MU-MIMO complicated things even further, requiring decisions on when and how to hold packets and transmit them simultaneously using MU-MIMO beamforming.

Now with AX, the scheduler has all the previous methods at hand, plus OFDMA. OFDMA is another simultaneous-transmission method like MU-MIMO. But instead of using beamforming techniques, which stagger signals in the time domain (phase angle), OFDMA operates in the frequency domain, divving up a single 20, 40, 80 or 160 MHz channel into sub-channels, called RUs (Resource Units). Each of these RUs can be assigned to a AX device (STA), usually when it associates.

To complicate the scheduler's task even further, OFDMA also works in the uplink direction. So the scheduler must also decide if it wants to receive data simultaneously from multiple STAs. UL OFDMA requires precise synchronization between AP and STA, which, of course, isn't easy. Whether it works reliably enough in the real world to provide the higher bandwidth efficiency and lower latency benefits that OFDMA promises has yet to be determined.

Of course, all these decisions must be made for each transmit opportunity (TXOP). As I said, this is complex stuff.

A Little More About RUs

Since RUs are at the heart of OFDMA, they merit a closer look. RUs come in six different channel widths, with each width supporting a maximum data / link rate per stream. The table below, taken from the IEEE 802.11ax draft spec, shows the maximum number of RUs for each channel width.

20 MHz Bandwidth RU locations

20 MHz Bandwidth RU locations (from IEEE draft 802.11ax)

The next diagram shows how a 20 MHz wide channel can be split into different RU widths. The wider the RU, the greater its data / link rate and the fewer available. In other words, if an AP wants to cram more STAs into an OFDMA frame, each one gets a smaller data rate.

Note that all RUs don't have to be the same. Assuming 20 MHz channel width, a frame could have four STAs using 26-tone RUs and one STA using a 106-tone RU. This assignment can be dynamic, so the next frame could have all five STAs using 26-tone RUs. The AP keeps track of which STA gets what RU by assigning each STA an AID (Association ID) when it associates.

20 MHz Bandwidth RU locations

20 MHz Bandwidth RU locations (from IEEE draft 802.11ax)

Note that an RU's width doesn't change with Wi-Fi channel width. All that happens with wider channels is that more RUs are supported, as shown in the next diagram. Wider channels also bring two more RU widths; the 484-tone RU is only available with 40 and 80 MHz channel widths and the highest value 996-tone RU requires an 80 MHz wide channel.

RUs in varying channel widths

RUs in varying channel widths (from IEEE draft 802.11ax)

What can increase an RU's throughput is the number of spatial streams. Since most STAs are two-stream, let's look at the MCS table (which shows data / link rates for our ol' pal the 26-tone RU, with two streams. For one stream, divide the data rate values in half.

26-tone RU, 2 stream MCS table (from IEEE draft 802.11ax)

26-tone RU, 2 stream MCS table (from IEEE draft 802.11ax)

This table brings home the reality of the tradeoffs inherent in OFDMA. To support the highest number of STAs in a single frame, the highest data rate each could get is just shy of 30 Mbps. But since this is an MCS table, that number really is link rate, with actual delivered data rate being lower. Keep this in mind the next time you see claims that 11ax can support hundreds of simultaneous clients.

So what data rate does the single 996-tone RU supported in a two-stream 80 MHz channel provide? Table 27-97 (not shown) yields 1201 Mbps. This is also the maximum data rate supported in an AX non-OFDMA 80 MHz channel.

For one final example, let's go back to the maximum RU per channel width table to see what we could get using four two-stream OFDMA STAs in an 80 MHz channel. Table 27-6 above says we could use 242-tone RUs and the Table 27-81 below says each of our four STAs would get at best 287 Mbps data rate. Not bad, but not the 1201 Mbps a single two-stream 80 MHz bandwidth STA would get. It's also worth noting that 4 x 287 = 1148. So the benefit of getting four STAs into one transmit frame incurs a 4% data rate loss overhead.

242-tone RU, 2 stream MCS table (from IEEE draft 802.11ax)

242-tone RU, 2 stream MCS table (from IEEE draft 802.11ax)

Testing OFDMA

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

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

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

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

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

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.

Closing Thoughts

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.

Discuss this in the Forums