Lack of Wi-Fi Mobility Can Cripple UCLack of Wi-Fi Mobility Can Cripple UC
Unified communications on mobile devices is great, until you start moving and find that calls drop and you have to reconnect repeatedly.
May 6, 2019
You have a full schedule, so you grab your lunch and sit down for a few minutes. There’s an important project review conference call starting just as you sit down. You take the call on your tablet and finish lunch while on the call. The next meeting is in another part of the building, so you start walking. Then your connection to the network changes and your conference call drops. ARRG!!! Why won’t the call stay connected while you’re moving? Cell phones manage to stay connected while you’re driving! What happened is that your tablet switched from one access point (AP) to another, but mobile roaming wasn’t properly configured, so your tablet now has a new IP address.
The above scenario is repeated many times a day in many organizations. While the details may be different, the result is the same: The call drops when the mobile device switches APs. Increasing the density of APs (while reducing the cell size to prevent adjacent channel interference) exacerbates the problem. In the worst case, simply walking across a classroom or auditorium could cause a switch.
Mobility
Wi-Fi mobility can work. It just requires that the Wi-Fi system be configured to support mobility. There are several mobility choices and the correct selection depends on your network architecture. First, an organization might not have mobility configured at all. In this case, when a client moves between APs, the client gets a new IP address. One way to avoid address changes is to use roaming at Layer 2.
A small organization might use a single wireless VLAN per SSID, with roaming at Layer 2 (the data-link layer). There are two Layer 2 roaming situations:
The client roams between APs connected to the same controller. The wireless controller remains the connection endpoint for the client.
The client roams between APs that connect to different controllers. As long as both controllers are on the same subnet (i.e., the same Layer 2 domain), the client’s connection record moves from the original controller to the new controller. This is transparent to the client.
If clients are able to roam between APs in situation 1 but not in situation 2, intermittent connectivity will result. Sometimes a client will be able to roam (situation 1) and sometimes it won’t (situation 2, but the handoff isn’t working).
There’s another catch with Layer 2 roaming. We don’t recommend extending Layer 2 very far -- it creates a large failure domain when (not if) a spanning tree loop forms. Troubleshooting spanning tree loops is time consuming. You have to physically break the network into individual segments by unplugging links in order to diagnose where the fault is occurring.
The preferred configuration is to use Layer 3, placing each controller (and SSID) on a separate subnet. When the client roams to an AP that’s on the second controller, the client’s connection record is copied (not moved) to the second controller and is marked as Foreign, meaning that it has to handle packets that are forwarded from the original controller. The original controller’s record is marked as an Anchor record. Traffic to the client goes to the IP address associated with the original controller, which then forwards it to the second controller via an Ethernet-over-IP tunnel. More configuration is required and more troubleshooting when it has problems, but it’s better and safer design than stretching Layer 2 across the infrastructure.
Other Factors
Calls on a Wi-Fi network can can drop due to many other factors, some of which will create intermittent symptoms. A common problem is duplex mismatch, where one end of a link is configured for full duplex and the other end is configured for auto-negotiation (see my Netcraftsmen post, “Auto-Negotiate Duplex or Not?”). It is best to configure the network for auto-negotiation, even though duplex mismatch can be detected by a network management system that alerts on frame check sequence and late collision errors.
Intermittent operation can also occur when a single AP is supporting too many clients, such as in an auditorium or public assembly location. The specific problems include overloaded AP radios that run out of bandwidth, overloaded DHCP address pools that prevent clients from getting an address, and uplink congestion at network aggregation points. Network monitoring provides visibility into these problems. Configure the NMS to report on the number of clients per AP, DHCP pool utilization, and interfaces that record a large number of packet drops or discards. Packet drop statistics are best reported using a Top-10 report and interface utilization is best shown using the 95th Percentile metric for each day, also sorted and filtered to show the Top-10 interfaces.
Wireless controller failures can also create interesting scenarios. In this case, the Wi-Fi network is designed with a primary and backup controller. The APs are distributed between the two controllers, and there are more APs than a single controller can handle. When a controller fails, is taken offline for software upgrade, or is isolated by a network failure, the affected APs attempt to register with the other controller. When the operational controller’s AP count reaches the license limit, additional APs will be left out. The first to re-register will win and the remainder will be Not Registered (yes, that’s the status description for one vendor). The Not Registered APs will seemingly be selected at random, depending on when they notice that the controller they were using is no longer available.
Your network management system should alert you to the controller’s failure. Hopefully, your Wi-Fi vendor will allow you to specify AP priority, allowing the controller to register only those APs that you consider important. But you’ll have had to take the time to decide which APs are important and which aren’t and apply the appropriate Wi-Fi controller configuration. In either case, any clients that were using the Not Registered APs will no longer have service, potentially affecting mobility. A better solution is to make sure that you have enough controllers to handle all APs, but that’s not always possible when working at the financial layer -- i.e., working within budget constraints that limit the number of controllers and licenses you can afford.
The final factor is the use of RF heat maps within the Wi-Fi manager to control AP radio transmit power. These maps rely on accurate AP location information to determine the distances between APs. If the maps are inaccurate or if the AP locations on those maps are incorrect, then the Wi-Fi management system won’t be able to optimize the RF environment. The resulting Wi-Fi coverage is unpredictable and can leave holes that impact mobile UC users.
Summary
Use a network management system to provide visibility into network problems that affect the wireless infrastructure. Careful AP placement and the proper configuration of the controllers is essential. Beware of using Layer 2 roaming in large networks, because a broadcast storm or spanning tree loop in one part of the network will affect the entire Layer 2 network.
Pay attention to detail when designing your Wi-Fi network and you’ll be rewarded with a system that seamlessly handles UC.
