Wi-Fi mobility in hospitals



Most client devices that use Wi-Fi in a hospital are computing devices such as computers on wheels, laptops, tablets, and smartphones. With very few exceptions, the applications that run on these devices do not rely on a persistent network connection. In fact, temporary disruptions in network connectivity usually go unnoticed by users because the applications handle those disruptions gracefully.

In contrast, most applications on medical devices cannot handle disruptions in network connectivity. A disruption of even a tenth of a second (100 milliseconds) can cause a failure in transmission of data from a medical device to the network. Loss of even one data packet can wreak havoc with an application that expects a continuous stream of data.

In a typical hospital, providing a persistent Wi-Fi network connection for a stationary medical device can be difficult. Wi-Fi radio frequency (RF) transmissions between the device and an infrastructure endpoint, called an access point (AP), may be absorbed by lead walls or human bodies, redirected by metal objects and surfaces, or disrupted by sources of RF interference.

When a medical device is mobile, providing a persistent Wi-Fi network connection for that device is even more challenging. The device may move from a location where it has an unobstructed RF connection with an AP to a second location where the connection with the AP is more tenuous to a third location where the connection is lost. As soon as a connection becomes suboptimal or tenuous, the device must switch, or roam, from its current AP to another AP.

Done quickly and effectively, roaming can ensure a persistent network connection and protect the applications that rely on such a connection.

Figure 1: A typical Wi-Fi deployment is a set of overlapping “cells” of coverage.


When Roaming Occurs

In a typical Wi-Fi deployment in a hospital, a large area is covered by the radio signals of many APs, with each AP offering a “cell” of coverage. As shown in Figure 1, the coverage areas or cells of many APs overlap. Overlapping coverage cells are a prerequisite for roaming.

A Wi-Fi client device typically associates, or establishes a connection, with the AP that provides the strongest RF signal. Because the signal is strong, the client and AP can negotiate a high data rate for transmissions. As the client moves away from the AP, the strength of the signal decreases and the relative impact of interference sources in the area increases. Some transmitted data packets are not received, forcing the sender to retry the transmission. To maintain the reliability of data transfer over the connection, the client and AP negotiate a lower data rate.

If the client continues to move away from the AP, then it eventually reaches the edge of the cell of coverage for that AP. Beyond the edge, the client is out of range and the connection with the AP is lost. The edge of coverage for one AP may be well within the coverage area of another AP. Before losing its connection with the first AP, the client must roam to the second AP and thereby preserve its connection to the network.

While the most common trigger for roaming is the movement of a client, it is possible for a stationary client to roam. Suppose that a stationary medical device is within range of two APs and connected to one of them. If a nurse positions his or her body between the device and the connected AP, the body may block enough of the Wi-Fi signal to disrupt the connection, thereby forcing the device to switch, or roam, to the other AP.  

How Roaming Works

The roaming process has four steps: Evaluate, Scan, Select, and Roam.

Evaluate:In the Evaluate step, the client determines if its connection with the current AP is suboptimal. The most common way to evaluate the current connection is to examine the strength of the RF signal from the current AP. This signal strength is represented by a received signal strength indication (RSSI) which is typically measured in dBm, or decibels (dB) referenced to one milliwatt (mW or m). If the RSSI for the current AP is stronger than threshold value, then the current signal is considered strong enough, and the client will stay connected to the current AP.

Scan:If the connection is less than optimal, then the client will proceed to the Scan step, where it scans the vicinity for other APs. The client radio checks some or, more commonly, all of the frequency channels on which APs may be operating. For each AP that the client finds, the client records information about the AP, including the RSSI for that AP.

There are two types of scans: active and passive. With an active scan, the client radio issues a probe request on a channel and listens for probe responses from APs operating on that channel. With a passive scan, the client radio does not probe but simply listens for beacons from APs on the channel. Active scans are faster and more reliable than passive scans, but active scans are not allowed on some channels, notably Dynamic Frequency Selection (DFS) channels in the 5 GHz band.

Figure 2: As its connection becomes suboptimal, a client evaluates other APs within range.


Select:After obtaining information from all APs that are in range, the client evaluates the APs and selects the one that is likely to offer the best connection, as shown in Figure 2. With rare exceptions, the client will compare APs based on RSSI. Because roaming is a disruptive operation, the client will not switch from its current AP to a second AP unless the second AP offers a significantly stronger signal.

Roam:If the client selects an AP other than the one to which it is connected, then the client must roam from the current AP to the new AP. Because a Wi-Fi client cannot be connected to two APs at the same time, the client cannot associate to the new AP until it first disconnects from the current AP.  Once the client associates with the new AP, the two APs must interact to ensure that the infrastructure is aware that the client has moved from one AP to another.

After associating to the new AP, the client must reauthenticate to the network on which the APs reside. While the process of disconnecting and  reconnecting typically takes only a few milliseconds, the reauthentication process can take much longer – so long, in fact, that it can disrupt applications that require a persistent connection.

Optimized Roaming

The most straightforward way to optimize roaming is to accelerate the reauthentication process. Most hospitals require the Enterprise version of Wi-Fi Protected Access 2® (WPA2®), which is the industry standard for strong Wi-Fi security at Layer 2. With WPA2-Enterprise, when a client associates to an AP, the client and AP conduct a mutual authentication using IEEE 802.1X using an Extensible Authentication Protocol (EAP) type such as PEAP or EAP-TLS. EAP authentication requires several interactions with an authentication server on the network. If there is network congestion or if the authentication server is on a network that is remote from the AP, then EAP authentication may take hundreds or even thousands of milliseconds.

The first time a client associates to an AP on a hospital network, a complete EAP authentication must be performed. When a client roams, however, the EAP reauthentication process can be streamlined so that no interaction with an authentication server is required. There are three methods for accelerating EAP reauthentications:

1.    Cisco Centralized Key Management (CCKM), which is supported by Wi-Fi infrastructure products from Cisco and by clients that are certified for CCX

2.    Opportunistic Pairwise Master Key (OPMK) caching, which is supported with WPA2 by some controller-based Wi-Fi infrastructures

3.    IEEE 802.11r pre-authentication, which does not enjoy broad support today


Another way to optimize roaming is to optimize scanning. Two ways to optimize scanning are:

1.    Reduce the number of channels that are scanned

2.    Use active, not passive, scanning

Even though the 2.4 GHz band supports 11-14 channels, depending on the regulatory domain for your part of the world, APs in a hospital will operate on only three of those channels. Rather than scanning all 11-14 channels, a client should scan only three. The 5 GHz band supports even more channels than the 2.4 GHz band, and APs may operate on any or all 5 GHz channels. It still may be possible, however, to limit the channels that a client scans when making a roaming decision.

A mobile medical device may not want to scan DFS channels. That’s because active scans are not allowed on DFS channels. A client must do passive scans, and passive scans take much longer than active scans. Mobile medical devices cannot skip DFS channels, however, if any APs to which those devices can connect are operating on those channels. Network administrators must weigh the pros and cons of using DFS channels for mobile medical devices.


Many applications that operate on medical devices require persistent network connections. As the use of Wi-Fi on medical devices increases, so will the need for seamless roaming of those devices. Seamless roaming requires several sophisticated processes that, unfortunately, are not supported by all Wi-Fi client radios. Medical device makers must choose their Wi-Fi radios carefully, and network administrators in hospitals should include roaming tests in the criteria for selecting medical devices.

For more details on Wi-Fi roaming in hospitals, read the Laird Technologies white paper, Wi-Fi: The Importance of Mobility in Hospitals.

About the author. . .  Before becoming Director of Product Marketing for Laird’s Connectivity Products Business Unit,  Chris Bolinger was the Vice President of Engineering for Summit Data Communications, Inc., a company that he helped found in early 2006 when he left the Wireless Networking Business Unit of Cisco Systems.  Prior to joining Cisco in 2000, Bolinger worked as a software engineer for five years and a Product Manager for nine years at software companies such as Sterling Software and PLATINUM technology. Bolinger earned a B.S. in Computer Science at the University of Akron and an MBA at George Mason University.


Please or Register to post comments.

Blog Archive
Newsletter Signup
Connect With Us

Sponsored Introduction Continue on to (or wait seconds) ×