Why the 802.11k and Neighbor Report are Important?

A lot of air time (pun intended) has been provided for the PHYsical layer amendments to the 802.11 standard. These would include 802.11n, 802.11ac, 802.11ad, and others. These amendments tend to get a lot of publicity because they have increased the speed/throughput of 802.11 over the years (from 1-2 Mbps in 1997 for the original 802.11 spec to “gigabit” in 2013 with the 11ac and 11ad amendments).

But what about those amendments that simply aren’t as “sexy” and provide only MAC layer enhancements? Aren’t these important too?

The answer is YES and in this short series of blogs, we’ll spend some time looking at the lesser known but undeservedly underappreciated amendments to 802.11, especially 802.11k, 802.11r, and 802.11v and the features/benefits they provide.

This first blog will explain the basics of 802.11k “WLAN Radio Measurements” and will specifically zoom in on the Neighbor Request/Report.

Wireless LAN Radio Measurements (802.11k)

Wireless Local Area Network (WLAN) Radio Measurements can enable any device, AP or client, with the capability to better understand the environment in which it is operating. A variety of requests can be generated for which the device receiving a request can respond with a report.

As one example, an AP could ask a client “how well are you hearing me?” using a Link Measurement request. The client would respond with a Link Measurement report (conversely, a client could ask an AP “how well are you hearing me?”).

Since the ability to measure and collect information is provided, a device submitting a request can make a better informed decision as to its “next steps” in adapting to/compensating for the dynamics of the WLAN environment.

Information obtained from a measurement and/or report can be made available to upper layers of the measuring and/or requesting device where it may be used for a range of applications. Such applications may be engaged in attempting to preserve the QoE (Quality of Experience) for the end user.

As one example, in order to preserve the QoE for applications such as VoIP and video streaming, WLAN Radio Measurements may be used by client device to collect information from the AP prior to that client device disassociating from one AP and reassociating to a new AP. This can dramatically speed up reconnecting from one AP to another AP in the same WLAN.

802.11k describes the following measurements:

1. Beacon
2. Frame
3. Channel Load
4. Noise Histogram
5. STA Statistics
6. Location Configuration Information
7. Neighbor Report
8. Link Measurement
9. Transmit Stream/Category Measurement

This blog will focus on the request/report measurement pair for Neighbor Report.

Neighbor Report

The “Neighbor Report” request is sent from a client to an AP. The AP returns a “Neighbor Report” report containing information about neighboring APs that are known candidates for the client to reassociate with (should the client choose to do so). Therefore, the Neighbor Report request/report pair enables the client to collect information about the neighboring APs of the AP it is currently associated to and this information may be used as identification of potential candidates for a new point of attachment while roaming. NOTE: The content of the neighbor report is shown at the conclusion of this blog.

The benefits of the neighbor/request report are as follows:

1. Speeds up scanning – instead of the client engaging in time consuming scanning activity (either actively probing for APs or passively listening to every channel for beacons) the client can instead narrow its list down to the known available neighbors. This is especially useful in high density environments where multiple WLANs can be heard by the client
2. Reduces client power consumption – the time taken by scanning (especially active scanning) also consumers battery power for the client. Since the neighbor report provides information before roaming, less power may be consumed
3. More efficient use of WLAN “air time” – active scanning is not only time consuming from the perspective of client resources (cpu, memory, radio, etc.), it’s also “air time” consuming. For example, a client that is not neighbor aware will likely engage in so-called wildcard probe requests (some clients will burst these). In this scenario, typically every AP that hears the probe request will generate a probe response. In other words, for a single client, a number N of APs will generate N probe responses. If multiple clients engage in wildcard probing, then the RF environment can quickly become “polluted” with management traffic simply because the clients are not using neighbor request. This has a negative impact for the entire WLAN

Cisco support for Neighbor Request/Report

Cisco WLAN infrastructure has supported the 11k Neighbor Request/Report since release 7.4.

Furthermore, this has been a staple feature in our VoWi-Fi solution for over 10 years (via CCX certification) and is further testimony as to Cisco’s pioneering work in making WLAN reliable for all types of IP traffic.

We’re happy to see this feature proliferating in the industry with VoWi-Fi.

Neighbor Report Information Element (IE) details

byte	function	value	description
1	Element ID	fixed	identifies Neighbor Report IE
2	length	variable	depends on the number and length of optional subelements, minimum = 13 (decimal) if no optional subelements are present
3-8	BSSID	variable	MAC address of AP client is being advised to associate to
9-12	BSSID Information	variable	includes reachability of AP, security, capabilities of AP, mobility domain of the AP indicated by this BSSID
13	Operating Class	variable	Operating Class indicates the channel set of the AP indicated by this BSSID.Country, Operating Class, and Channel Number together specify the channel frequency and spacing for the AP indicated by this BSSID.
14	Channel Number	variable	Channel Number indicates the last known operating channel of the AP indicated by this BSSID.
15	PHY Type	variable	The PHY Type field indicates the PHY type of the AP indicated by this BSSID.
16-	Optional Subelements	variable

 

 

Please feel free to comment, share and connect with us on Facebook, Google+ and @Cisco_Mobility!