Are client-troubleshooting WiFi sensors really necessary?

Troubleshooting WiFi problems has been the bane of the network engineer’s existence for nearly a decade. So often these problems go undiagnosed that clients have even since stopped reporting them. Bad WiFi chalked up as just part of everyday life.

Yet the role enterprise WLAN plays has literally become a critical part of an ever-growing ecosystem of both end user and IoT devices. Add to that the technology advancements in 802.11 and the task of maintaining a reliable WiFi network has become nearly out of reach of the average WLAN engineer. To solve this conundrum WLAN vendors, have a long history of attempting to solve the problem with hardware sensors and detailed active site surveys.

While site surveys and wireless sensors can play an important role in monitoring client WiFi performance, neither of these approaches fully and continuously reflect actual network conditions experienced by the clients and devices the network is intended to serve— particularly today with mobile devices that generate the vast majority of wireless traffic.

Site surveys are snapshots that are neither spatially nor “real-time” representative, and AP-monitoring data collection can only measure wireless conditions at those fixed AP locations, not at the changing locations of mobile clients. To combat this, WiFi sensors have been promoted by a handful of vendors to help solve the problem.

The pitfalls of WiFi sensors for client troubleshooting

WiFi sensors are discrete hardware devices equipped with specialized WiFi radios –designed to measure the RF environment as well as perform network connectivity and other tests against the existing WiFi infrastructure.

They effectively act as a high-performance client device on the WiFi network, continuously testing WiFi performance when connected through the APs deployed in their vicinity. These sensors perform cyclic end-user synthetic traffic tests and spectrum analysis – measuring metrics such as throughput, packet loss, latency, retry rates, airtime and channel utilization – attempting to mimic client transactions of well behaving clients. But are these systems and their measurements really useful and worth the time and expense, especially, when the existing WiFi infrastructure provides 90% of this information already?

Not really.

That’s not to say that wireless sensors used for troubleshooting client WiFi issues aren’t useful. In certain problem areas, when used on a limited basis, these systems can be help figure out very specific RF problems. But as a wholesale, campus-wide continual monitoring solution, few enterprises are buying into wide-spread deployments because the price/value ratio simply doesn’t justify the cost. 

Most enterprise networks are made up of hundreds of different client devices running literally thousands of different operating systems. Each has a different WiFi chip, antenna, OS, CPU, and memory and behaves differently with different parts of the network. That begs the question: can a purpose built homogenized device really mimic your real-world network enough to produce valuable insights?

If you want to mimic an end-user, why imitate an end user that really isn’t one? WiFi sensors don’t run the same hardware, operating system or the same apps as an end user and only represent what a user might run. They also don’t represent any client level issues and misconfigurations that happen in the real world.

Sensor systems, by definition, can only provide an idealized representation of a lab condition network and don’t provide a complete or completely accurate view of the user experience other than to address one aspect of the network: the access medium. These systems also don’t correlate WiFi data with data from other network layers.

It’s important to understand that WiFi networks and the user experience on them are dependent on the wired network applications and other network services like DHCP, DNS and authentication systems.  To truly understand what a client is experiencing, all of these aspects must be taken into consideration and measured together accordingly.

Moreover, WiFi sensors require all the same overhead and operational support as your WiFi network. That is to say, Ethernet cabling, power, switch ports and installation costs. Within a small, problem area, this might work fine – but campus wide? Forget it.

Why deploy a completely separate sensor network on top of your WiFi infrastructure when all the information from clients and the network itself can be used to accomplish the same goal? Wouldn’t it be better to let the devices on the network do the talking?

The good news is that in most enterprise network environments, the WiFi session information, including user’s identity, device MAC address and association time, among other things, is usually recorded by the management software. Therefore, a complete view of the user’s WiFi connection activity is already available on the infrastructure side. And sensors WiFi sensors already exist. They are the client devices themselves.

Clients as the ultimate sensor

Every time real clients access the network, there is a treasure trove of data about that client’s user experience that can be collected and analyzed– from RF and connectivity all the way to application performance. These real client transactions can be used to greater affect than synthetic transactions, especially from a hardware sensor.

What’s more, if synthetic transactions are to be performed, better they be performed by a software agent sitting on an actual client device such as a laptop or a smartphone.  

Because these devices also have a WiFi radio, their scans can also reveal unique insights about large-scale wireless network deployments which are difficult or impossible to glean from site surveys, WiFi sensors, RF sniffers or infrastructure side logs. Quite simply, laptops and smartphones represent real network users, and their data is representative in the way that measurements from hardware sensors cannot be.

Instead of deploying costly and cumbersome WiFi sensors, tapping into existing client devices and correlating this data within a full-stack network analytics system provides an extremely accurate picture of what’s actually going on and a better way to identify real client WiFi issues.

Big data network analytics comes of age

What’s really needed is a big data network analytics platform to analyze this data, run complex algorithms including machine learning on this data, and yield actionable insights that administrators can use to proactively improve user experience. Fortunately, they now exist.

Big data network analytics platforms collect data about client user experience from passive data collection about clients from the infrastructure itself, WiFi data from WLAN controllers, packet analysis of live traffic, SYSLOG data from network services, and even NetFlow from routers.

By combining an infrastructure perspective of the client with a view from the actual client itself, troubleshooting wireless user’s problems can be performed faster, cheaper and better.  And this is what all network managers want.

So, if you’re looking for a way to troubleshoot wireless clients, all the data exists in your network today. You just need a good network data analytics platform to ingest it all and automatically analyze it for you. This will quickly get you to the heart of client WiFi issues with insight into the all-important user and device experience without going broke or crazy.