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!

Posted by Wi-Fi Coops

2 Comments

  1. Excellent blog! I’ve never seen a client initiate beamforming, even though it’s theoretically possible via the standard. Most vendor implementations are for downlink only. Additional info about the usefulness (or lack thereof) of MU-MIMO (mostly due to TxBF overhead) can be found here: https://www.brighttalk.com/webcast/5522/252893
    The NDP announcement only specifies a maximum of one beamformee (by AID), and that’s not required. The reason that it does so is to indicate which STA will send it’s Action No Ack (TxBF feedback matrix, which is usually ~1500B) first, in order to be slightly more efficient than having to poll ALL STAs. The NDP itself is a PHY header only at BPSK (6Mbps).

    Devin

    Liked by 1 person

    Reply

    1. Thanks, Devin! I’ve been meaning to watch that webinar of yours. Appreciate the additional information, love your work!

      Like

      Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s