What better way to spend a 38 degree (Celsius, or 100F) Brisbane summer day than to relax in the air conditioning and enjoy a Star Trek marathon?

Or, I could put my wireless nerd hat on and satisfy my curiosity as to whether my AP (Cisco Meraki MR33) and computer (Surface Pro 2017) were utilising beamforming.

The CWNP courseware does a great job of explaining and analysing beamforming, however I came across a great chapter in the book “802.11ac: A Survival Guide – Wi-Fi at Gigabit and Beyond” by Matthew Gast which goes into greater detail.  I’m not going to digest and translate the entire chapter here (though I highly recommend reading it), though I will provide a brief overview and I am going to illustrate how I confirmed if my stations were beamforming or not.

Beamforming Overview

As you may know beamforming was introduced as an optional feature of the 802.11n amendment, which some WLAN vendors implemented in proprietary ways (i.e. Cisco ClientLink).  802.11ac enables single user (SU) and multi user (MU) beamforming which aims to improve SNR (and hence throughput) between a wireless client and AP.  To quote the 802.11ac book:

“Beamforming gains are expected to be approximately 3 dB in the transmitted direction. In practice, this gain will typically be one step up in data rates (increasing one MCS number) for a mid-range transmission.”

Beamforming uses a calibration process called channel sounding between APs and wireless clients to determine if and how energy can be radiated in an optimal direction.

A summary of the steps to enable beamforming is:

1. The beamformer transmits a Null Data Packet (NDP) Announcement frame which identifies beamformees.
2. This is then followed by another NDP which is a sounding frame used by the received to analyse training fields for various subcarriers and calculates a response.
3. This response from the beamformee contains a feedback matrix.
4. The beamformer uses the feedback matrix to calculate a steering matrix to direct RF energy toward the beamformee.

Stations can act as beamformers and/or beamformees.

Beamformer	Beamformee	Beamforming
Access Point	Wireless Client	Unidirectional (typical)
Access Point & Wireless Client	Access Point & Wireless Client	Bidirectional

Beamforming Verification

First I took a look at the capabilities of my AP and Surface Pro in packet captures.

Meraki Access Point:

The highlighted beacon frame indicates VHT Capabilities of SU Beam-former & formee, and MU Beam-former.

Surface Pro:

Depending on how your wireless client device probes, you may see VHT capabilities in probe requests (or only HT capabilities; Wireshark filter: wlan.fc.type_subtype eq 4), or in the association response (Wireshark filter: wlan.fc.type_subtype eq 1).

The highlighted capabilities show the same capabilities as the AP for beamforming. So let’s take a look at the beamforming process.

Here is the beamformer sending the NDP Announcment:

Followed by the action frame back from the Surface Pro with its reported SNRs for both streams and its feedback matrix (I’ve truncated the list of subarriers):

The next QoS Data should be transmitted as beamformed.  To see if a packet has been beamformed we can apply the Wireshark filter of wlan_radio.11ac.beamformed == 1 and see if Beamformed is set to True in the 802.11 radio information:

Success! Interestingly I never see the Surface Pro send out an NDP Announcement despite it being capable of being a beamformer, perhaps that is a driver limitation.

Beamforming is enabled by default on Meraki APs with no way of disabling it, so to compare SNR and throughput between normal and beamformed packets I would have to find a wireless client device that can disable beamforming in the driver (i.e. it wouldn’t respond to an NDP Announcement with a VHT Action).  Please let me know in the comments if you have found a device you can do this with!