Friday, April 15, 2016

Deploying Wi-Fi in the Real World

Note, this blog post was written for and originally appeared in Network Computing on 4/14/2016:

Over the last decade, the proliferation of WiFi has been tremendous. However, this proliferation is fueled by one major misconception: Deploying Wi-Fi is EASY! How difficult can it be to go to your local big-box or consumer-electronics store, buy the shiniest WAP router you can find, and plug it in? When WiFi was new and consumers and business were wary about deploying a seemingly complex and unknown technology, this messaging made a lot of sense. Plus, back in the day, deploying WiFi was actually fairly easy. When data rates were low and the modulation and coding schemes (MCS) were simple, WiFi networks were quite tolerant to errors in deployment and issues in the environment.
Moreover, WiFi is a very robust protocol designed to work in the presence of interference -- even self-interference from other access points on your own network. The success of WiFi is at least partially due to its durability; WiFi as a protocol will continue to try and pass data, long after logic and sound engineering principles indicate that it should have already crashed and burned.
However, as WiFi became more popular, there's been ever-increasing demand for higher speeds and capacity. While we cannot break the laws of physics, engineering as a discipline is all about using mathematics to “bend” the laws of physics. Hence, we add more mathematical complexity to squeeze more performance: more complex MCS rates like quadrature amplitude modulation (QAM), MIMO, and transmit beamforming MU-MIMO. We also increase the channel size, which allows us to push more data on the channel. There is always a price, however: As we add more complexity, we add more fragility or sensitivity. Modern WiFi now requires much better signal-to-noise ratios (SNR), accurate antenna alignment, and position feedback from the client devices so we know where they are relative to the access point.

WiFi.jpg

WiFi
(Image: iSergey/iStockphoto)
Consumer marketing continues to promote WiFi ease of use, but so have many enterprise WiFi vendors, telling customers to put APs wherever they wanted, and that the APs would figure it all out in the firmware. However, we no longer live in a “best effort” era, where if the WiFi works for you great, and if not, too bad. WiFi is a requirement, and bad WiFi is bad for business. Just look at the hotel industry, where the importance of fast WiFi is consistently rated more important than clean sheets and towels!
As with any complex engineering system, the ultimate success of a WiFi network comes down to the following, all which have their own set of challenges:
Proper understanding of WiFi requirements and constraints. Formulating requirements are often overlooked or disregarded, because on the surface, requirements seem deceptively easy: WiFi is a commodity, and it should be readily obvious what's needed! Unfortunately, this is generally not true. Most customers and end users are not WiFi experts, nor do they usually even have more than a passing knowledge of networking or information technology. Hence, they don’t appreciate what is impossible vs. impossible, or what is easy and cheap vs. what is difficult and expensive.
Accordingly, expectations can be skewed because many requirements and constraints end up in direct conflict, such as providing both the best performance and the cheapest price, or providing WiFi coverage everywhere while hiding the access points from view to preserve aesthetics. If deploying in an existing building, there are often hidden constraints that may not emerge until the deployment, such as the ease or difficulty of running backhaul cabling, or walls that are made out of materials that are more RF shielded or RF transparent than previously thought.
Requirements and expectations also change unpredictably over time, both during the life of the project as well as the life of the WiFi network as a whole. If a WiFi network installed today has an expected lifetime of three to five years or more, then it needs to handle devices and user expectations that don’t exist today. The networks we design today must be designed for the iPhone 10. How do we design a network to handle client devices, and client expectations, that don’t yet exist or haven’t even been conceived of yet?
Proper product selection. Again, picking the right solution is deceptively easy in a world where WiFi is thought of as a commodity, and thus WiFi vendors and WiFi solutions are treated as interchangeable, not only by the customers, but by the vendors and solution providers themselves. The reality is that most network vendors have optimized their products and services to meet the typical requirements of specific vertical markets like hospitals, schools, stadiums, and SMB; a solution tuned for one environment may be a very poor choice for another, because the requirements are very different.
However, WiFi systems are sufficiently complicated that no reseller, system integrator, or even WLAN engineer, can possibly be an expert in all of the diverse offerings from multiple access point vendors, so most tend to deploy equipment from either a single or a small set of sources. The vendors actively encourage this with pricing promotions and training and certification programs because, like all businesses, they like having a loyal customer-base and the repeat business it generates.
Proper implementation. We have endless debates in the WLAN industry about site surveys, and the validity of performing predictive modeling vs. going on-site to perform pre-deployment and post-deployment surveys. A predictive model is, by definition, a model, which is a simplified mathematical representation of reality. The modeling tools we have today, such as Ekahau, AirMagnet, and TamoGraph, are quite mathematically sophisticated at computing RF propagation, but they can only ever be as accurate as the inputs you put in. Garbage in produces garbage out.
Since every environment is at least somewhat unique in its construction, on-site surveys are obviously better, but these require specialists with custom, hard-to-learn tools and take a lot of time. This makes site surveys quite expensive in terms of both cost and time, and most customers who perceive the WiFi as “easy” don’t want to pay for it, so they tend not to get done or, at best, rushed.
So what do we do as WiFi engineers? The best we can. We try to standardize on a set of solutions and best practices, but not make this standardization so rigid that we cannot be flexible and adapt to unique requirements or unusual constraints. We also build robust designs that are built conservatively with a lot of margin for capacity and growth. We may not know what the iPhone 10 is, but we can safely assume it will consume more data and that there will be more of them compared to what we are used to today.
We also hopefully build service contracts to periodically tune and refine the WLAN while it is in operation. Undoubtedly, channels will need to be tweaked, coverage may need to be extended, or capacity may need to be increased over the life of a network. Finally, we as WiFi engineers must continue to hone our craft. WiFi is still a rapidly changing technology, and our understanding of what works in practice and what doesn’t will keep evolving as we deploy more networks and encounter real-world issues.

1 comment: