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, Test Setup, Results - Downlink}

Introduction

Wireless router makers have been telling us that beamforming improves performance since the technique became part of 802.11n. However, 802.11n allowed multiple forms of beamforming and both ends of a wireless link need to use the same beamforming method. So the technique seldom, if ever, produced any real benefit in 802.11n.

The framers of the 802.11ac specification observed beamforming's failure to launch in 802.11n, so agreed on only one beamforming method in 802.11ac. Both ends of a wireless link still need to support beamforming for maximum effect. But now with only one method to implement, consumer wireless makers are adding the feature in most of their 11ac products.

If you want an excellent description of beamforming in 802.11ac (and before), I highly recommend Chapter 4 in Matthew Gast's 802.1ac: A Survival Guide.

Since beamforming now should actually work in 802.11ac gear, I decided it was time to take a performance look-see. But first, let's set expectations. According to Gast,

"Beamforming increases the performance of wireless networks at medium ranges. At short ranges, the signal power is high enough that the SNR will support the maximum data rate. At long ranges, beamforming does not offer a substantial gain over an omnidirectional antenna, and data rates will be identical to non-beamformed transmissions."

The example plot below shows what beamforming performance gain might look like. There is no difference at short distances (high signal levels) or long distances (low signal level). But somewhere in the mid-range, you'll get an undetermined amount of higher throughput for an undeterminate distance (range of signal levels).

Beamforming rate vs. range improvement example

Beamforming rate vs. range improvement example

Gast says beamforming power gains are expected to be around 3 dB, which should typically result in a one step increase in data (MCS) rates. But as we all know, an increase in link rate doesn't necessarily mean an increase in link throughput. It all depends on the algorithms built into the AP and client's drivers.

Both access points and clients can use beamforming. But given the higher processing power and larger distance between antennas in access points, most beamforming performance gain should be expected in downlink transmissions from AP to client.

A final point to note is that the standardized beamforming method (known as Null Data Packet [NDP] sounding) is part of 802.11ac, which is a 5 GHz only standard.

Explicit vs. Implicit Beamforming

There are two main types of beamforming. Explicit, which includes 802.11ac's standard method requires transmitter and receiver to exchange information about the radio channel.

Implicit
beamforming, which is used in some 802.11n products, doesn't require support on both ends of the wireless link. Instead it infers channel characteristics based on lost frames.

Test Setup

I used a NETGEAR A6200 for my test client because I know that NETGEAR has baked beamforming into the V1.0.0.26 installer package I used. I originally was going to use a NETGEAR R7000 for the router, but the latest firmware seems to have removed beamforming enables that I swear were in there in an earlier version. NETGEAR also said they have a new firmware coming later this month that improves beamforming performance. So, despite my mistrust of ASUS' firmware when it comes to subtle things like beamforming, I loaded the latest 3.0.0.4.374_583 onto an RT-AC68U to use as the test router.

I'm not sure how closed chamber testing and beamforming interact, so I went with open-air testing, setting the ASUS router to Auto 20/40/80 MHz bandwidth mode with 153 as the primary channel. I tested only in 5 GHz because I wanted to be sure that the standard 802.11ac explicit beamforming method would be used. The RT-AC68U has enables for both Explicit and Implicit beamforming, both of which are enabled by default. So I left both methods on for the "On" tests and disabled both for "Off".

I ran three sets of one minute up and down tests using IxChariot's throughput script with TCP/IP using my good ol' test locations A, C and D, i.e.

  • Location A: AP and wireless client in same room, approximately 6 feet apart.
  • Location C: Client in upper level, approximately 25 feet away (direct path) from AP. One wood floor, sheetrock ceiling, no walls between AP and Client.
  • Location D: Client in upper level, approximately 35 feet away (direct path) from AP. One wood floor, one lower level sheetrock wall, sheetrock ceiling between AP and Client.

After looking at the initial results, I decided to add another test location ("prep") that had a slightly lower signal level. This one is about 15 feet from test location D on the same floor.

Results - Downlink

Since beamforming helps only mid-level signals, I didn't expect any throughput gain in Location A, but did in Location C and/or D. The downlink comparison chart below summarizes the results. The RSSI levels shown next to the plot locations were measured using MetaGeek's inSSIDer. They are useful only to note the difference in signal level from location to location.

Beamforming Test Summary - Downlink

Beamforming Test Summary - Downlink

Location C shows about 4% lower throughput, which I'd say is within the bounds of measurement error (I'm assuming 5%), so let's call that no change. Location D, with a signal level 33 dB lower than the Location A reference level, shows a 12% improvement in the beamforming run. The new "Prep" test location is only two dB lower than Location D but shows a 14% improvement with beamforming enabled.

I had wanted more of a signal level difference in the new test location. Unfortunately, in the location where inSSIDer read approximately -72 dBm, the connection was not stable enough to produce a reliable ping or run the IxChariot test. This result supports the earlier point that beamforming will not extend your wireless range.


Results - Uplink

I expected no throughput improvement in the uplink direction and that's about what I got, with one exception. The new "Prep" location showed a 17% improvement with beamforming enabled. While that looks impressive, keep in mind that represents only a 4 Mbps average throughput gain in the test.

Beamforming Test Summary - Uplink

Beamforming Test Summary - Uplink

However, the IxChariot composite plot of the two tests shows steadier throughput with beamforming enabled as the primary reason for higher average throughput.

Test Location "Prep" comparison - uplink

Test Location "Prep" comparison - uplink

The gallery below has all the comparison plots with beamforming enabled and disabled for all locations, uplink and downlink .

Closing Thoughts

To my surprise, it looks like beamforming can provide a slight performance improvement. And even more surprising, it worked with two different vendors' products (although both are Broadcom-based).

My results, however, come nowhere near those NETGEAR touted in its announcement last year of its "Beamforming+" upgrades. I've marked up the announcement's plot with percentage calculations of the improvements NETGEAR showed it obtained with its beamforming implementation.

NETGEAR Beamforming throughput improvement - annotated

NETGEAR Beamforming throughput improvement - annotated
[Source: NETGEAR announcement]

I can agree with the 12% improvement—the most I obtained. But I wasn't able to obtain a stable link at low enough levels to obtain the 51% and 85% (!) improvements NETGEAR claims it can deliver. Note that NETGEAR's plot represents bi-directional throughput and that might account for some of the difference.

So I guess I'll have to circle around to this again in a few weeks once NETGEAR releases its new R7000 firmware.

Discuss this in the Forums