Cisco Systems is announcing a new set of features that enhance its HDX (High Density Experience) suite. This blog is the third in a series that explains the new features that comprise the enhancements to HDX.
The first blog in the Enhancing HDX series is here. The second blog in the Enhancing HDX series is here.
What is 802.11v? What is BSS Transition Management? Why are these Important?
In this blog, two different series are intersecting: Enhancing HDX and the series looking at the lesser known but undeservedly underappreciated amendments to 802.11 and the features/benefits they provide.
Previous blogs briefly explained the basics of 802.11k “WLAN Radio Measurements” and specifically zoomed in on the Neighbor Request/Report and also explained the basics of 802.11r “Fast BSS Transition”
This blog will briefly explain the basics of 802.11v “Wireless Network Management” and will also explain how 802.11k Neighbor Request/Report and 802.11r “Fast BSS Transition” can provide a “better together” solution with 802.11v. It also explains where it fits in with High Density Experience (HDX).
Wireless Network Management (802.11v)
Wireless network management (WNM) enables devices comprising the WLAN to exchange information with the goal of improving the quality of experience when using the WLAN. Network administrators benefit from using WNM by having additional ability to fine tune the WLAN in order to provide improved reliability of services to their end users and the end users benefit in turn from using a WLAN that has been designed to provide more than mere connectivity.
Client devices and infrastructure may both use WNM to exchange operational information so that both clients and infrastructure have additional awareness of the WLAN conditions. That awareness can help provide a firm foundation for self-correcting events and actions to be implemented. In other words, WNM isn’t about being a “control freak”; it’s about raising the bar in the Wi-Fi ecosystem so as to create better Wi-Fi networks.
But not only does WNM provide information on the state of network conditions, it also provides a means to exchange location information, supports efficient delivery of multicast (group addressed) frames, and enables a power savings mode in which a client can sleep for longer periods of time without receiving frames or being disassociated from the AP.
Given this, it can be easily appreciated why WNM has often been described as a “kitchen sink” of features. This blog won’t take the time to go through each and every feature introduced in the 802.11v amendment. But in order to emphasize the potential richness of the feature set, the following is an alphabetized list:
The remainder of this blog is going to focus on BSS Transition Management. Future blogs will cover other aspects of 802.11v.
BSS Transition Management
Fortunately BSS Transition Management is easier to explain than the name may imply. Keep in mind that a WLAN is also referred to as an ESS (Extended Service Set). The ESS is comprised of one or more BSS (Basic Service Set). Each BSS is “served” by an Access Point.
BSS Transition Management is ESSentially (sorry, I couldn’t resist) network assisted roaming (or directed roaming) of a client device.
This is important to keep in mind because the previous blogs covered the 802.11r amendment aka “Fast BSS Transition” and 11k “Neighbor Report”. These features all complement one another.
BSS Transition Management introduces three new frames:
- BSS Transition Management Query (which is transmitted from a client to infrastructure)
- BSS Transition Management Request (which is transmitted from infrastructure to a client)
- BSS Transition Management Response (which is also transmitted from a client to infrastructure but is only done so following a BSS Transition Management Request)
In brief, the BSS Transition Management Query can be thought of as the client soliciting advice from the infrastructure. The client is basically asking “should I reassociate? If yes, then which AP should I reassociate to?” Optionally the client can include a list of the APs it can hear (which may or may not be part of the ESS that it is currently connected to. It can also include a reason code for making the query).
The BSS Transition Management Request can be thought of as the infrastructure offering advice to the client. The infrastructure is basically recommending “You should reassociate.” Optionally the infrastructure can include a list of the APs that are its own neighbor BSS’s (which must be part of the ESS that it is currently serving). The list that the AP provides can be used to assist the client in choosing a target AP especially for 11r actions.
The BSS Transition Management Request is very important because it can be offered in an unsolicited fashion, i.e., a BSS Transition Management Request can be transmitted from infrastructure to a client without having the client first send a BSS Transition Management Query.
This being said, it is equally important to keep in mind that the client is always responsible for making any association or reassociation decision to the ESS. The BSS Transition Request is literally a request. It’s not a demand or an order or a mandate. The client can choose to accept or reject the advice/recommendation/suggestion offered by the AP.
Accepting/rejecting the request is the primary function of the BSS Transition Management Response. The client can also include a reason code for acceptance or rejection. It is important to note that the response to the request is optional.
However, there are potential ramifications for a client rejecting the BSS Transition Management Response. To better understand that, we’ll take a look at the detailed structure of the BSS Transition Management Request frame format.
BSS Transition Management – frame format details
The figure below shows the components of the BSS Transition Management request frame
Let’s quickly walk through the frame, octet by octet (byte by byte) and bit by bit (as appropriate).
The Category and Action fields are basically used to identify a WNM frame and WNM frame type.
The Dialog Token is used as a unique identifier for frame exchanges (e.g.., a Dialog Token will be used to identify that a solicited Request corresponds to a Query or that a Response corresponds to an unsolicited Request).
The bits in the Request mode are where things get really interesting.
The first bit, Preferred Candidate List Included, is used to indicate that the Neighbor Report information element which accompanies the BSS Transition Management Request in the field called BSS Transition Candidate List Entries (refer to the trailing field in the figure above) is a list of preferred APs for the client to reassociate to or is simply a list of known APs that are candidate for reassociation..
The second bit, Abridged is used to hint at how the BSS Transition Candidate List Entries should be used by the client. If this bit is set, then this request frame is indicating to the client that the BSSIDs (MAC addresses of the APs) included in the BSS Transition Candidate list are recommended/preferred over BSSIDs not included in the list. If this bit is not set (i.e., cleared), then then this request frame is indicating to the client that there is no recommendation/preference with regard to any BSSID not included in the list.
The Validity Interval field is used to inform the client the amount of time (in beacon intervals) that the BSS Transition Candidate List is valid for.
Ordinarily the Neighbor Report information should be included since it is meant to offer assistance to the client in making a roaming (BSS Transition) decision. But there may be scenarios in which the infrastructure may not be able to recommend a better AP for the client to reassociate to.
But having said this, what should the client do if it does not receive the BSS Transition Candidate List Entries? Good question. Give yourself some bonus points if you asked this. The answer is that the client could do an 11k Neighbor Report request.
Another higher level question is: What should the client do if it receives an unsolicited BSS Transition Management Request? Also a good question but the answer is “it depends”.
To answer this fully, let’s look at the next bit: Disassociation Imminent.
In this case, the Disassociation Imminent bit is used to inform the client that it will be disconnected from the AP after the time indicated in the Disassociation Timer field. The Disassociation Timer is expressed in number of beacon intervals. Once the Disassociation Timer reaches zero, then the client can be disassociated at any time thereafter.
Okay, so ask again: what should the client do if it receives an unsolicited BSS Transition Management Request? Answer: if the Disassociation Imminent bit is set, then the client should strongly consider quickly engaging in 802.11r (Fast BSS Transition). If the Disassociation Imminent bit is not set, then the client can be a little more relaxed in its reassociation behavior.
As you can see from the above, the 11v BSS Transition Management Request frame can be used to trigger either (or both) 11r and 11k activity depending on how the request is formatted. Of course, including the Neighbor Report information element in an unsolicited request frame is equivalent to offering an unsolicited 11k Neighbor Report. Thus the use of 11v can be highly advantageous and efficient.
We’ll look at BSS Termination Included (and BSS Termination Duration), ESS Disassociation Imminent (and Session Information URL) in a future blog.
To wrap this up (for now) let’s look at what this means for HDX.
Using 11v BSS Transition Management to extend Optimized Roaming
The original HDX series of blogs examined Optimized Roaming in January 2014.
In brief, BSS Transition Management Request is used to warn a client that is dwelling in a poor RF zone that it is about to be disconnected. The advantage to the client for supporting BSS Transition Management is clear. Without this, a sticky client that is identified as an Optimized Roaming candidate may be abruptly disconnected. With it, the mechanism provides a modest level of courtesy.
Of course, Cisco has been supporting forms of network assisted roaming and directed roaming via its CCX program for many years. Furthermore, this is also a highly critical feature to support for Voice over Wi-Fi deployments in public environments.
Cisco is pleased to see that client devices are readily adopting this feature and expect it will be table stakes functionality in 2016 (if not sooner).
Please feel free to comment, share and connect with us on Facebook, Google+ and @Cisco_Mobility!
CONNECT WITH US