It’s not about RSSI
Just a quick post to talk a bit about RSSI, and why it’s NOT the best way to judge your Wireless LAN.
First a bit of history, more than a decade ago I started into Wireless Networking. Back then the only tools we had were the Cisco ‘Breadcrumbs’ RSSI meter built in the Cisco (Aironet) client software.
Back then we thought Coverage was the Holy Grail – how to get the most coverage with the least amount of Access Points. So getting a strong RF signal, as measured by RSSI was everything. Then we found RF Amplifiers – and we made some HUGE RF coverage circles.
Site surveying was running around with AP-on-a-Stick and measuring how far the RF coverage went. That was all. Just RSSI.
Sad to admit, but I did hundreds of these. (I can only sleep at night knowing that everyone did it that way and no one had any better idea back then of what else to do)
But today we know it’s NOT about the RSSI! Sure, you *must* have good signal. But good signal alone won’t give you a great Wireless LAN design. It’s all about the actual throughput of data over the RF medium.
The new Holy Grail in Wi-Fi is getting the network to provide the actual data throughput and specs needed by the client devices. That is all encompassing.
So instead of measuring only for RSSI, we really need to be measuring better the net throughput, under load, of our Wireless Networks.
Sure, an RF amplifier can transmit a strong signal a long ways… but the net result is you have clients that can see the AP, but the AP can’t see the clients. And you now have HUGE contention domains (Collision Domains) where all devices must wait for the others they can see on the same channel to ‘Share’ the RF medium.
Remember – it’s not about RSSI – it’s about consistent, measured, available throughput!
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 22nd 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 |
Seemingly Random Data
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.
Consistent vs Inconsistent Data
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.
