Just what we needed (really), another letter in the alphabet soup of 802.11 standards. This one, 802.11r, is also known as Fast Basic Service Set Transition (more details on the standard here).

The 802.11 standard was originally conceived to operate around individual access points (APs). This is a far cry from the high density AP network designs increasingly being installed in hospitals - and the wireless medical devices and other mobile applications they support.

In a conventional WiFi network it takes about 100 ms to re-associate with a new AP, and several seconds to re-authenticate connections using 802.1x (a common security requirement in many hospitals). This time lag can potentially result in several second gaps in patient monitoring waveforms, missed alarms, and dropped wireless VoIP phone calls. Another problem fixed in 802.11r is that a client radio does not know if the required quality of service (QoS) resources are available in the new AP until after it has associated with the new AP.

Roaming has become such an issue that Meru and Extricom designed WiFi network products where there is no roaming because all the APs are on the same channel. This is an example of a radically different design solution that still conforms with the standards.

The more conventional work around, especially on cellular WiFi networks like Cisco's, is to run an application or set of wireless devices on their own VLAN or SSID - a solution with very limited practicality.

The Problem with Standards

Like any standard, 802.11 provides a requirements and specification framework for implementing wireless connectivity. This provides cross vendor interoperability and a high degree of reverse compatibility (where new products are compatible with preexisting ones). However, like all standards, 802.11 is open to interpretation and variability in implementation - all of which can still remain within the standard.

Probably the worst example of this is HL7, where vendors (who pretty much drove the whole process) minimized the impact of supporting HL7 by making certain things "options" or provided additional "flexibility" in the standard in order to reduce the need to rewrite their preexisting software. What we got was a big improvement over custom interfaces, but a far cry from plug and play integration. The wiggle room in 802.11 is much tighter. Yet, when optimizing a radio implementation for low level capabilities like power conservation or AP roaming, vendors can (and do) implement different approaches - which can (and usually do) meet the standard.

By creating more detailed standards like 802.11r, the IEEE is tightening up the standard to ensure greater commonality in how vendors implement features like fast roaming. This helps ensure cross vendor interoperability and provides for improved backwards compatibility going forward.

More on 802.11r

So, on to the details. This new standard establishes security and QoS connections for the client radio at the new access point, before it roams between the two, so the transition can take place in less than 50ms. Up to this point, all the heavy lifting of fast roaming had to be implemented in the client radio device driver. The need to enhance low level capabilities (like power conservation and roaming) have driven some medical device vendors to invest heavily in developing or modifying WiFi radio device drivers or even design their own component radios.

Vendors and end-user buyers (i.e., hospitals) note that 802.11r will rewrite most of the authentication and key management structure of the IEEE 802.11i, so implementing - and especially validating - 802.11r may be more complex that it might first appear.

Hat tip: dailywireless.org