Cisco 11v BSS Transition Management Frames

Welcome to my first post in what will hopefully become a series of posts on Wi-Fi technologies. Today, I want to talk about 802.11v. More specifically, the BSS Transition Management component of the 802.11v standard.

One of  problems encountered in wireless networks with mobile devices is "sticky" clients. As a wireless device moves around an area where an ESS is deployed, it makes the choice of which AP to associate to. This choice is usually made based off of RSSI; the client will connect to the AP that it hears the best signal from. As that client moves away from the AP it initially associated towards other APs that have a better RSSI, the client may choose to associate to the new AP.

The problem is the "may choose" part. The decision to roam is entirely up the client. Some clients will only roam when they can no longer hear the AP they initially connected to. Some clients will allow users to configure a roaming aggressiveness setting so they can tune how likely their client is to roam. Either way, the decision to roam is the client's to make. This will lead to sub-optimal conditions where a client would be better served if it would just roam to a different AP.

802.11v BSS Transition Management to the rescue. The 11v BSS Transition Management function allows a wireless distribution system to request a client that supports 11v to roam to an AP that will serve the client better. The client still makes the decision to honor the request or not, but it does offer more control over the roaming process.

There are 3 types of 11v BSS Transition Management frames: query, request, and response. A query can be made from a client that supports 11v after it roams to make sure that the AP it roamed to is the best one. A request is a frame sent from a DS to a client requesting that it roam to a different AP. This request can include a BSSID and channel of an AP that the client could roam to. Finally, the response is sent by a client to a DS in reply to a request. All three types are seen over the air as 802.11 action frames. 

To see 802.11v in action, you need a client that supports it. Apple devices that support iOS 7 or better support 11v. Windows 10 encourages 11v, but you will need a wireless adapter and driver that supports it. As always, make sure you have the latest drivers; sometimes the drivers that ship with your device don't support the latest features. To see if a client truly supports 802.11v Transition Management, you can capture an association request frame from a client. If you want to learn how to do this with a Cisco WLC and lightweight APs, see this article. Here's an association request from my Windows 10 laptop with an Intel 8260 adapter. The information element (IE) is under tagged parameters/Extended Capabilities.

Figure 1

You will also need to enable 11v support on your wireless network. On Cisco wireless networks, this is set at the WLAN level in the Advanced tab.

Figure 2

The Disassociation Imminent option sets a flag in 11v request telling the client that it needs to roam, or it will be disassociated after a certain amount of time. In this dialog, "TBTT" is equal to the beacon interval.

To save my fingers from typing "BSS Transition Management," I'm going to abbreviate it as "BTM." No matter how hard I tried, I could not get my Windows 10 laptop to send a BTM query. I also did testing roaming back and forth between two APs, and never once did I see a BTM request from the DS. Something was missing in the configuration of my Cisco wireless network. It turns out that there are only two conditions under which a Cisco AP will send a BTM request: If you have aggressive load balancing enabled on the WLAN, or if you have optimized roaming enabled at the radio level.

Aggressive load balancing allows an administrator to attempt to balance the number of clients associated to APs in an area. If more than one AP can hear the probe response ACK from a client, the controller will try to steer the client to a less-loaded AP when it attempts to associate. Aggressive load balancing combined with 11v BTM will allow the client to associate to an AP, after which the AP will send a BTM request, asking the client to move to a less loaded AP.

Figure 3

Without 11v, aggressive load balancing will deny association to the more loaded AP until the client reaches a defined number of attempts, after which it will allow the association.

I setup the scenario in Figure 3 with my Cisco wireless network. AP1 was using channel 64,60 and AP 2 was using channel 36,40. I also had two more APs in sniffer mode watching the same channels. Aggressive load balancing was enabled for the WLAN. Two devices were already connected to AP 1 when I tried to connect a third device that supported 11v.

Figure 4

You can see in Figure 4 that immediately after associating, the client is sent a BTM request, because the AP already has two other clients connected to it, and nearby AP2 has none. The details of the BTM request are shown below. A reference on the details of BTM request frames can be found at Allen Huotari's excellent Cisco Blog post.

Figure 5

The latest version of Wireshark does not completely decode the BTM request frame, but I have indicated the important sections of the candidate list section. Underlined in red is the BSSID of the AP the client is being requested to roam to, and highlighted in yellow is the channel number of the target AP. 0x24 translates to 36 is decimal, so we are seeing the expected channel of AP2.Note that the disassociation imminent flag is set, telling the client it needs to roam or it will be disassociated. Take a look at the disassociation timer field, which is set to 1953. This correlates to the "Disassociation Time" in Figure 2.

The client responds with a BTM response frame, shown below.

Figure 6

The key items to look for here are that the "BSS Transition Target BSS" matches the BSSID given in the BTM request, and that the values for the Dialog token field match.

The other scenario in which a Cisco wireless DS will send a BTM request is when optimized roaming is enabled, and the AP detects that the connection between the AP and client is not ideal and thinks that asking the client to roam to another AP would provide better connectivity. Optimized Roaming is configured globally for the entire radio (802.11a or 802.11b), under Wireless->Advanced.

Figure 7

Optimized Roaming can assess the health of a client's connection by using RSSI, data rate, or both. By default, only RSSI is considered. For Optimized Roaming to work, Coverage Hole Detection must be enabled for the same radio band. It is under the Coverage Hole Detection section where you can set the RSSI values that will trigger an Optimized Roaming condition.

Figure 8

Optimized Roaming does not depend on 11v. Without 11v support, Optimized Roaming will simply disassociate a client in the hopes that it will re-associate to a better AP. With 11v enabled, the Cisco AP will send a BTM request to the client, telling it where to go. This should result in a better roaming experience for the client, since it will not have to scan the channel for the next AP.

To see this in action, you can enable client and 11v events debugging on the WLC. Here is what I saw when my client triggered an Optimized Roaming event:

*apfMsConnTask_5: Nov 07 11:25:49.305: e4:b3:18:67:54:d0 Optimized Roaming : Client RSSI(-77) is lower than the association RSSI threshold(-74), reject the association request
*apfMsConnTask_5: Nov 07 11:25:49.305: e4:b3:18:67:54:d0 Client is triggering BSS Transition*

apf80211vTask: Nov 07 11:25:49.306: e4:b3:18:67:54:d0 apf80211vSendPacketToMs: 802.11v Action Frame sent successfully to wlc
*apf80211vTask: Nov 07 11:25:49.306: e4:b3:18:67:54:d0 Setting Session Timeout to 4 sec - starting session timer for the mobile
*apf80211vTask: Nov 07 11:25:49.306: e4:b3:18:67:54:d0 Setting Session Timeout to 40 sec - starting session timer for the mobile 

On the air, the Optimized Roaming BTM request looks similar to the aggressive load balancing one shown in figure 5. In my scenario, my client was connected to AP2, and a BTM request was sent to suggest I move to AP1.

Figure 9

Again, the target BSSID is underlined in red and the channel is highlighted in yellow. I'll leave it up to the reader to confirm that the BSSID matches what you would expect from looking at figure 4. A key difference between this frame and the one shown in figure 5 is the value of the disassociation timer. It's close to 400, and is an order of magnitude smaller. This correlates with the "Optimized Roaming disassociation time" value in Figure 2.

Overall, the BSS Transition Management feature is a good way to gracefully tell clients that they should roam, and where they should roam too. I see this being an important feature in wireless VoIP networks. A key takeaway from this blog is that in order to see any benefit from 11v features in Cisco wireless networks, you either have to use aggressive load balancing or Optimized Roaming. I don't really recommend aggressive load balancing, and together with Optimized Roaming it could cause some unwanted problems. Remember that Optimized Roaming requires Coverage Hole Detection.

That's it for now. I hope to add more entries in the future. Stay tuned!