Showing posts with label probing. Show all posts
Showing posts with label probing. Show all posts

Thursday, December 20, 2012

Wi-Fi Clients Follow the Data Rates Advertised by the AP

As a follow-up to my previous post on Wi-Fi probing behavior and configured data rates, I thought I'd round-out the discussion showing how the client ultimately follows the AP's lead when it comes to communicating it's Basic and supported data rates when it connects to the WLAN.

It's very important for an AP to ensure that the clients attempting to connect to the WLAN support the mandatory (termed 'Basic') data rates configured as part of the network policy. Doing so ensures that all clients can properly decode and receive management frames like beacons as well as broadcast and multicast traffic that is essential to successful network connectivity, which are all sent out using one of the Basic data rates. Beacons and broadcasts are typically sent at the lowest Basic data rate, while multicast may be sent out at the highest Basic data rate depending on the AP vendor.

The communication of the Basic and supported data rates must occur in both directions, so both parties can understand the capabilities of the other.

Clients that are actively scanning send out a list of supported data rates, but don't mark any as Basic since that is the responsibility of the AP. This is just a raw list of data rates the client is capable of transmitting and receiving.

Probe Request Supported Data Rates


APs advertise it out during beacons so that clients that are passively scanning can make decisions on whether or not they can connect to that AP. APs will also include their list of supported rates in the probe response. Both frame types contain the same list of Basic and supported rate information, distinguishing which rates are mandatory for operation in this BSS (basic service set). Notice that 802.11n rates are carried in the HT Capability Information Element, listed as supported MCS sets for various numbers of spatial streams. Clients will include this element in the association request as well.

Probe Response Basic and Supported Data Rates


Finally, once it comes time to connect, the client will actually adjust it's supported data rate list contained in the Association Request frame in order to align with the policy advertised by the AP; this time listing which data rates are Basic (mandatory) and which ones are supported. Differences between the client and AP may still exist for the supported data rates, but the Basic data rates must match. Using the list found in the association request, the AP makes the determination whether or not the client is allowed to connect to the WLAN.

Association Request Basic and Supported Data Rates;
"Data Rate Follow-Back" behavior of Wi-Fi Clients

I call this the "Data Rate Follow-Back" behavior of Wi-Fi clients :) You won't find that in any book as a standard term, it's just my own terminology.

Cheers,
Andrew

Wi-Fi Probing Behavior and Configured Data Rates

Today, I'd like to highlight what happens under-the-covers when a client tries to connect to an AP after data rates have been manipulated. Specifically, I'm talking about the probing behavior of both the client and the AP. If you've ever wondered how this works, I'm here to tell you about it today!

A standard WLAN best practice to improve performance is to disable low data rates on the APs in an enterprise network. This helps to increase overall network capacity by eliminating overhead caused from management frames sent out at the lowest configured Basic data rate, and to ensure data frames aren't sent at the low data rates which consume large amounts of airtime for application traffic.

First, let's briefly describe how probing works in a legacy WLAN deployment, when the AP supports all 802.11b data rates (1, 2, 5.5, 11 Mbps). In this scenario, the client sends out a Probe Request at the lowest data rate it supports, typically 1 Mbps. The AP will issue a Probe Response back to the client, again at 1 Mbps. They both understand each other, life is happy!

Now let's examine what happens when data rates have been manipulated on an AP, for instance all 802.11b data rates have been disabled and 6 Mbps is now the lowest Basic data rate.

Probe Request and Response Behavior
After Data Rate Manipulation

The client probes at 1 Mbps (as usual) since it doesn't know "what's out there" yet. It's trying to discover all the nearby APs that it could connect to and what their capabilities are. So, it sends out the Probe Request at the lowest data rate it supports to achieve the maximum visibility and trigger all nearby APs to respond.

Probe Request at 1 Mbps

Now, what our AP with manipulated data rates does is the interesting part. Even though it can properly receive and decode the client's Probe Request at 1 Mbps, it is only configured to support 802.11g/n data rates (6 Mbps and higher). So what does it do? It issues a Probe Response at it's configured lowest data rate. After all, the configuration policy now states that all 802.11b data rates are disabled, so let's respond to the client at our lowest Basic data rate of 6 Mbps. If the client is 802.11g capable it will still be able to decode the frame and process the response. We also inform the client in the Probe Response of the supported rates and which ones are mandatory (the meaning of 'Basic' rate).

Probe Response at 6 Mbps

Therefore, the probe response behavior of APs is directly tied to the configured Basic data rates; APs always respond at the lowest Basic data rate, NEVER a disabled data rate. Think about the implications this has on WLAN network operation:

  • Clients that don't support the lowest Basic data rate can't connect to the WLAN. In this example, 802.11b-only clients that don't support 802.11g/n would not be able to connect.
  • Clients that have too low an SNR to decode the lowest Basic data rate won't be able to connect to the WLAN; they won't be able to decode the response frame from the AP. Data rate manipulation can effectively be used to limit the size and "association range" of a Wi-Fi access point (but not the "coverage range" since the signal still travels just as far and can cause interference even though it can't be decoded). Now think about the implications on association range if we made 18 Mbps the lowest Basic data rate.
It's worth noting that 802.11n requires at-least one legacy 802.11a/b/g data rate configured as a Basic data rate. Therefore, WLAN vendors that have the ability to allow only 802.11n clients and reject legacy 802.11a/b/g clients do so through other methods unrelated to data rate manipulation, typically by rejecting association requests by clients that don't advertise support for 802.11n MCS rates.


Cheers,
Andrew