The Unknown Unknowns of Wi-Fi
"There are known knowns; things that we know we know. There are known unknowns; that is to say there are some things we do not know. But there are also unknown unknowns -- the ones we don't know we don't know. And if one looks throughout [history], it is the latter category that tends to be the [most problematic]." -Donald Rumsfeld, former United States Secretary of Defense
And what are Known Unknowns?
For one, we know that we don't know precisely which nearby APs and client devices are causing CCI. We know that nearby APs and clients on the same channel COULD cause CCI, but no tool exists that would allow us to view the exact Wi-Fi traffic that a given client device is "hearing" on its channel. Wi-Fi scanners could tell us that a nearby AP has the potential to interfere, but scanners don't capture traffic. Wi-Fi protocol analyzers capture traffic, but they run on third-party radios. What a protocol analyzer "sees" and what a production Wi-Fi client device "hears" may be two very different things.
At least we know that CCI is an unknown. At least if a user contacts support and says, "the Wi-Fi sucks", we can keep the thought in the back of our minds that there could be a nearby AP or client that's screwing up the channel.
But what if that user never calls? We may then be introduced to the dreaded Unknown Unknown. We may not even know that there is some unknown happening in the air that is causing sub-standard Wi-Fi.
"And so what?", you may say. "If there's a problem with the Wi-Fi and the user never calls, that's the user's problem."
In the short term, yes. But what about when that Unknown Unknown problem causes a Crowd Failure" (definition: A Wi-Fi network that tests well, but fails when a large number of users become active on the network)? Maybe some organizations forgive the Wi-Fi guys if the Wi-Fi doesn't work under stress. Many don't.
If you work for an organization that doesn't forgive Crowd Failures -- or if you won't forgive yourself for Crowd Failures -- then I must humbly suggest that you eliminate as many Unknown Unknowns as you possibly can.
Yes, this blog post has a real-life inspiration.
I was doing a couple of days of work at a hospital. When we got there, the network engineer told us that a few Wi-Fi users have problems sometimes, but that the network is mostly solid.
Sensing a possible Unknown Unknown, I asked for permission to interview users. Nothing in-depth; these would be working doctors & nurses, and I didn't want to take time away from their care for patients, just a minute or two about their typical Wi-Fi experience.
Sure enough, the hospital Wi-Fi had problems. "The patient data entry application loses its connection before I can finish entering the data." "The barcode scanners don't work sometimes, and I have to enter the patient data manually." "The Wi-Fi goes in and out in the Emergency Room."
We stuck around and fixed as many problems as we could, as quickly as we could. Some tweaks were made to the Wi-Fi; some problems were not caused by Wi-Fi.
By the time the project ended, the users seemed happy (at least, that's what they told us). I was happy, because I knew that we had rooted out a few Unknown Unknowns. Talking to Wi-Fi users can be an essential tool in preventing Crowd Failures, and other embarrassing, high profile Wi-Fi problems.
For those of us who follow United States politics, the above quote is a famous one. And for those of us who work in Wi-Fi, being aware of Unknown Unknowns can make the difference between good Wi-Fi and bad.
What are the Known Knowns of Wi-Fi?
AP status (up or down). AP channel. Number of associated client devices. Data statistics. We can gather these pieces of information from WLAN controllers or wireless management systems.
What are the Known Knowns of Wi-Fi?
AP status (up or down). AP channel. Number of associated client devices. Data statistics. We can gather these pieces of information from WLAN controllers or wireless management systems.
And what are Known Unknowns?
For one, we know that we don't know precisely which nearby APs and client devices are causing CCI. We know that nearby APs and clients on the same channel COULD cause CCI, but no tool exists that would allow us to view the exact Wi-Fi traffic that a given client device is "hearing" on its channel. Wi-Fi scanners could tell us that a nearby AP has the potential to interfere, but scanners don't capture traffic. Wi-Fi protocol analyzers capture traffic, but they run on third-party radios. What a protocol analyzer "sees" and what a production Wi-Fi client device "hears" may be two very different things.
At least we know that CCI is an unknown. At least if a user contacts support and says, "the Wi-Fi sucks", we can keep the thought in the back of our minds that there could be a nearby AP or client that's screwing up the channel.
But what if that user never calls? We may then be introduced to the dreaded Unknown Unknown. We may not even know that there is some unknown happening in the air that is causing sub-standard Wi-Fi.
"And so what?", you may say. "If there's a problem with the Wi-Fi and the user never calls, that's the user's problem."
In the short term, yes. But what about when that Unknown Unknown problem causes a Crowd Failure" (definition: A Wi-Fi network that tests well, but fails when a large number of users become active on the network)? Maybe some organizations forgive the Wi-Fi guys if the Wi-Fi doesn't work under stress. Many don't.
If you work for an organization that doesn't forgive Crowd Failures -- or if you won't forgive yourself for Crowd Failures -- then I must humbly suggest that you eliminate as many Unknown Unknowns as you possibly can.
Yes, this blog post has a real-life inspiration.
I was doing a couple of days of work at a hospital. When we got there, the network engineer told us that a few Wi-Fi users have problems sometimes, but that the network is mostly solid.
Sensing a possible Unknown Unknown, I asked for permission to interview users. Nothing in-depth; these would be working doctors & nurses, and I didn't want to take time away from their care for patients, just a minute or two about their typical Wi-Fi experience.
Sure enough, the hospital Wi-Fi had problems. "The patient data entry application loses its connection before I can finish entering the data." "The barcode scanners don't work sometimes, and I have to enter the patient data manually." "The Wi-Fi goes in and out in the Emergency Room."
We stuck around and fixed as many problems as we could, as quickly as we could. Some tweaks were made to the Wi-Fi; some problems were not caused by Wi-Fi.
By the time the project ended, the users seemed happy (at least, that's what they told us). I was happy, because I knew that we had rooted out a few Unknown Unknowns. Talking to Wi-Fi users can be an essential tool in preventing Crowd Failures, and other embarrassing, high profile Wi-Fi problems.
***
If you like my blog, you can support it by shopping through my Amazon link, becoming a Patron on Patreon, or by donating bitcoin to 1CcEkG8DJD6VWUr27GwtGzPWRQDFt3qgye
Thank you.
Twitter: @Ben_SniffWiFi
Thank you.
Twitter: @Ben_SniffWiFi
ben at sniffwifi dot com
This comment has been removed by the author.
ReplyDeleteGreat content, thanks for sharing.
ReplyDeletewww.jdflooringinstallers.com