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.
