WLAN Design – A Compromise between Quality and Cost

As with many things in live, WLAN design is a compromise. Somehow not getting everything you want, but in order to make both sides agree. In our case, this negotiation is usually between designing the Wireless LAN to meet specific and defined goals, contrasted with staying inside of some arbitrary budget.

The sad part to this story is what happens when there are no negotiations, and price ends up driving the design. So you might want to treat this as a morality tale – and learn from the mistakes of others.

One of the great things about 802.11 Wi-Fi is its inherent resiliency. This is built into the protocol at the very lowest levels. Since we’re using CSMA/CA – we must find mechanisms to give some level of reliability to the wireless packet transfer – these techniques actually work. Some times to the detriment of the overall network throughput.

This extra resiliency can also be an issue when counteracting the “build it cheap” mentality. You can design a ‘workable’ wireless LAN that can send packets from end to end, and thus the bean counters love the cheap price and say that “it works” because some packets can flow. Yet this inexpensive design does not meet even the lowliest of performance criteria.

I personally come from the school of thought that great Wireless LAN design happens during the preliminary meetings, far before any actual design work happens. Way back when discussing the features and capabilities desired by those who will actually be using the Wi-Fi network.  This is the time that can make or break a great WLAN design.

It must be at this early stage where expectations are being set… this is where a good WLAN designer takes his/her stand. Each level of expectations has an appropriate cost tied to it. Mistakes at this stage usually happen when people talk about expectations in one meeting, and the money people come up with a budget in an entirely different meeting.

Anxious for the work/contract, many WLAN designers accept both – yet mutually exclusive – expectations. Then later when the system isn’t performing end up blaming everyone and everything involved with the project except the people who are truly at fault. The designers themselves, for allowing the project to move forward with disparate goals.

I’m positive I’m not alone in this next experience. Directly after finishing a large WLAN installation, and doing post verification surveys to “prove” the design meets the written design goals and expectations, you’re feeling quite good about a job well done and about ready to pack it up and head to the next job. You feel confident the wireless network will meet the RF Coverage, Data Throughput, and User Experience outlined in the scope of work… then out of the blue the local contact says something along the lines of…

 “Now that the Wi-Fi is working, we can use this for Voice, right?”

Aaaarrgghh – it’s happened to me so many times in the past, I now have a document that I have the customer sign before the start of the design works that explicitly states “This WLAN design does not, and will not support Voice over IP over Wi-Fi” – and have the customer sign and date it in front of me.

Even then, I’ve still had customers come back and expect Voice to work on their data designed wireless LAN.

The downside of this dilemma between a quality wireless LAN design that meets stated criteria, and one that barely works usually comes down to costs. The almighty buck drives the project and if we as WLAN Professionals don’t stop it early enough in the process we’ll be part of those being blamed for the network’s failure.

Below are just a small sample of networks I’ve been involved in fixing, after the fact, to try and salvage some of the sunk cost of the current Wi-Fi system that is not meeting the needs of the customer.

I’m sure you also have many of these types of examples. Feel free to share yours in the comments below.

Treat this like a warning – please do not repeat these mistakes in your own practice!

• Using Mesh instead of Wireless Bridges
• Thinking you can push Wi-Fi from the outside in, without CPE
• Not doing a Link Budget to see if the connection will work
• Not doing an onsite RF analysis to measure wall RF loss
• Doing point to point links without knowing if any obstacles are in the Fresnel Zone
• Installing Mesh instead of bringing cable to all the Access Points
• Stringing a series of standard Omni Mesh AP’s to ‘pretend’ to be a bridge link
• Not running simple calculations to see how much ‘Pipe’ will be shared between customers
• Putting indoor AP’s under the eaves to save money out outdoor Access Points
• Using Omni antennas directly against some wall or post
• Using High-Gain Omni antennas 15m high above a warehouse floor
• Using High-Gain Omni antennas 25m above an outdoor parking lot
• Using Point to Multipoint setup in 2.4GHz and wondering where your bandwidth went to
• Putting an AP to cover the ground on the 22^nd floor because that’s where the Ethernet drop was
• Putting too many AP’s close together to ‘get’ high density client deployment
• Doing a pre-installation site survey then never returning for verification
• Using SoHo equipment in an enterprise deployment and hoping for the best
• Not ever testing the copper plant – wondering why not getting gig speeds
• Having network bottlenecks between AP’s and Controller
• Thinking if a handheld device can see the AP, why can’t the AP see the handheld device
• Designing for merely coverage, then wondering why throughput doesn’t work
• Cutting out half the AP’s of a great design, because you don’t have budget for it
• Aiming a Point to Point link directly at a wall, since the customer didn’t have rights to be above the wall

Each of the above sentences has at least one full-page story to emphasize the point, but I’m not going to waste the time to go into all the depressing details. Each of the above problems was caused by someone NOT designing for the needs of the customer, but just wanted to stay within some arbitrary budget.

The process should be to make the budget and the Wi-Fi expectations to match.

As my friend Jared mentioned to me this morning,

“You can fail in your design by designing for the budget—then the system won’t meet the needs of the clients. Or you can fail by designing for the needs of the clients—and fail to get the deal because it now costs too much.”

We can mitigate that situation by better communication—much earlier in the cycle to make sure both goals are met at the same time. Or at least the expectations are set to match the budget and what the customer will receive for that amount of money.

This is NOT an easy problem for WLAN professionals – but it is one that will define our collective reputations. 

Seeing Patterns in Random Data

What we are after is very consistent data connections for our customers and clients. Below is one way to help quantify that your Wireless LAN is giving your clients consistent results. I know not everyone enjoys statistics… but sometimes with just a little massaging of data, in this case sorting the data first, will help allow you to see patterns–information–in your data. Rather than just take a single sample of data throughput, take a bunch. In this case I took 25 samples – the more the better. Now you can see more than a single snapshot in time – but a set of datapoints that we can learn much more from than a single point.

When looking at collected data, sometimes it seems to be quite random in nature. Looking at this random data, folks can make mistakes in analysis. One method we use to help ‘clean up’ this random data is to first sort the collected data from high to low, and graph according to percentage. This allows us to see graphically the differences between data sets.

As an example, I’ve put together the following sample data sets. Each has the exact same Maximum, Minimum and Average… but obviously, much different results. This is the value of this sorting method, it allows one to quickly see differences in data.

Maximum	20
Minimum	5
Average	11.36
Datapoints	25

The first is a graph showing the two sets of data, fairly random looking. Both look like they are quite similar in nature, both inconsistent, and with a fairly same average.

But when you take this same information and sort it first, you can see distinct differences in the resulting graphs. One set of data is much more consistent than the other. Even though they both have the same averages.

We’d like to see very flat lines, showing customer experiences to be fairly consistent across the board. The higher the lines the higher the client’s throughput results.

A line with it’s curve toward the bottom left represents a fairly low consistent result. A diagonal line represents high variability – more inconsistency. A line with the curve in the upper right represents consistently higher results.

Another way to use these ‘sorted’ graphs is to look at the 50% line – this represents the ‘average’ someone would achieve. The 80% line on the bottom represents that 80% of all collected data meets or exceeds this number.

This is a good telltale sign for following the 80/20 rule. Don’t waste too much time and money trying to fix the last 20% – put the bulk of your resources towards getting the 80% to be as consistent (flat) as possible.

Words Have Meanings?

Many decades ago I lived in Taiwan for a couple of years and learned Mandarin Chinese. Of all the tens of thousands of possible Chinese characters, there are only some 400 or so different sounds in the language. So many of the same characters (words) end up having the exact same sound. To counteract this obvious chance for confusion, sometimes Chinese people write out an imaginary copy of the character in question on the palm of their hand. A bit awkward, but it helps to convey which character goes with which sound.

In the English language, we too have difficulties at times with words having the same sound, but entirely different meanings. Some even represent a noun, and a verb with the exact same sound. For example, take the word Shift.

• Shift – to change gears on a car
• Shift – a type of woman’s apparel
• Shift – a time period for work
• Shift – what a Defense does in American Football
• Shift – an improvised knife used as a weapon

Thus we need context around the word to help us determine which version we are referring to.

As another example – the word Braces:

“You wouldn’t want to confuse the Braces holding up Larry King’s pants, with the Braces straightening his teeth, with the guest who Braces for the next question.”

In our world of Wireless LANs we too have to be careful in the use of various terms and words that can have different possible meanings.

We banter about the term ‘Spectrum Analyzer’ but which version might we be referring to:

• A $30,000 Spectrum Analyzer used in electronics labs?
• A $4,000 Cognio Spectrum Analyzer with custom ASICs?
• A $2,000 AirMagnet Spectrum Analyzer with software to share with WiFi NIC data?
• A $400 MetaGeek Spectrum Analyzer?
• An Atheros chipset with WiFi mode turned off and listening as a Spectrum Analyzer?
• Or finally what Xirrus calls a Spectrum Analyzer – but is just WiFi data in tabular format?

All are referred to as a Spectrum Analyzer – but they all have far different resolutions, and capabilities. Not that the most expensive is best – you’ll need to use the one that can show you the raw (non-Modulated) RF at the resolution you need to solve your current problem.

Set SoapBox = ON

Xirrus – just calling something a Spectrum Analyzer doesn’t make it one. No more than calling me a Marathon Runner makes me one. (I have ‘run’ (managed) the electronic timers at a Marathon – that doesn’t mean I actually competed) If your device cannot ‘see’ raw non-modulated RF – don’t call it something it isn’t. It might fool your customers – but not anyone who actually knows what a Spectrum Analyzer is!

Set SoapBox = OFF

Other words we use in the pursuit of our Wireless LAN systems that can be confusing include the word Interference.

We have:

• Raw RF Interference – non-802.11 modulated
• Co-Channel Interference – 802.11 packets on the same frequency
• Adjacent Channel Interference – 802.11 packets on nearby frequencies
• Interference because AP’s and Clients are sharing the same frequency with all neighboring devices on the same channel. (Like a hub has interference from all connected devices)

Each of these effects on our data throughput differently, and each need different tools to help troubleshoot and solve the “Interference”.

Or how about the simple term Noise that gets thrown around all the time. Which version of Noise are you referring to:

• Thermal Noise?
• Non-802.11 Modulated RF signals?
• 801.11 RF on the same channel?
• 802.11 RF on nearby channels?
• Ambient RF noise floor?
• Broken Packets on the same frequency?

Which of these above is what you are thinking of for the ‘N’ in SNR? Which version of “Noise” is used in your Wi-Fi NIC?

Spectrum Analyzers can tell some of these, a Wi-Fi NIC that is in promiscuous mode can see others. Knowing when to use which tool is very important.

In conclusion – remember just like the words Shift and Braces – we need to be very precise in the use of confusing Wireless LAN terms.  It will help clear up any confusion if you can be very precise when communicating terms like Spectrum Analyzer, Interference, and Noise.

« Previous Page — Next Page »