The “Magic” of Wireless Mesh

This document is also available for download via a PDF White Paper.

The Wireless Mesh Cost vs Throughput Spreadsheet.

 

The “Magic” in magic is really just a combination of illusion and mis-direction.  And yet we are entertained by being convinced we’ve seen something that breaks known physical laws.

We know the woman really isn’t being sawn in half, yet we don’t mind suspending reality for a couple of minutes while we try and figure out how the magician is doing his magic.

In the world of Wireless Mesh, sometimes WLAN professionals get too caught up in the mis-direction and illusion of getting something for nothing that we forget all about the laws of physics that determine connections and throughput and watch as our customers suspend reality hoping to get something for nothing, and not paying any penalties.

In reality, there is nothing “magic” about Wireless Mesh. It follows known laws concerning RF propagation, packet transfers, and network packet protocols.

I believe that Wireless Mesh does have it’s place in WLAN Design… but many people, in their quest to save a bit of money end up ruining their Wi-Fi network by employing mesh incorrectly.

To emphasize this point, I’ve developed an Excel Spreadsheet and made it available to download. (Link to Mesh Analysis Spreadsheet) – this spreadsheet, like all good spreadsheets, pulls the variables out where you can see them. All the fields colored in Green are the input points for the algorithms. You, as a WLAN designer can choose your own amounts for these.

Here are the variables you can enter to drive the equations in the Spreadsheet:

• Expected net TCP data rate on the 2.4GHz Access Frequency
  • I started using a value of 25Mbs to reflect a network where the bulk of the client devices are still 802.11g
• Expected net TCP data rate on the 5GHz Mesh Frequency
• This is estimated at a value consistent with an 802.11n connection
• Remember – the Mesh AP’s must be within range to have great SNR to maintain this data throughput!
• Number of Clients per 2.4GHz Access Point
• Cost of a wired Ethernet Backhaul connection
• Including Cat 5e cabling, installation, and cost for a switch port
• Sample Size of the Mesh Network
• number of Access Points to provide coverage for clients, as well as enough Mesh AP’s to maintain high throughput speeds between 5GHz Mesh RF connections.
• Average Loss in Percentage per additional Hop.
  • I’ve started with the minimum loss of 50%, in actuality there could be 10% to 15% more loss because of overhead and other issues.

802.11g	2.4GHz dedicated to Access	25	Mbs
802.11an	5GHz dedicated to Mesh	75	Mbs
Number of Clients per Access Point		25	Clients/AP
Cost Per Access Point – Installed		$600	/AP
Cost per wired Backhaul Connection		$400	/Cable Drop & Switch Port
Sample Size of Wireless Mesh Network		50	Access points
Average Loss per each additional hop		60%	% loss

 

Remember, you are the one to make these assumptions. This is not something that I’m making up – you put in your actual costs, size of system, assumptions on data throughput and number of clients per access point.

You can use this spreadsheet to work with your customers/clients to help them better understand the value and costs of providing Wireless Mesh versus other alternatives like Ethernet cable or a dedicated Wireless Bridge.

As an aside, I like to keep these in order both in my mind, as well as in the mind of my customers. Order of AP backhaul desired:

• Fiber
• Copper
• Dedicated Wireless Bridge
• One-Hop Wireless Mesh
• and way down here in the very last position
• a Multi-Hop Wireless Mesh

 

Also remember the first hop is ‘free’ – only kind of – since there isn’t the requisite 50% loss on this first hop. The receiving Mesh AP doesn’t need to re-transmit the packet on the 5GHz channel. The client packet comes into AP #1 on 2.4GHz, AP #1 then re-transmits the packet on 5GHz, then AP #2 receives the packet and places it directly on it’s Ethernet port.

But for subsequent Mesh Hops, AP #2 would have to re-transmit the packet on the same 5GHz channel it came in on… thus the 50% drop (Plus additional loses due to overhead issues) Each subsequent hop also results in this drastic degradation of data throughput.

Here are some graphical examples of this process of going to multiple hops. The horizontal access is number of Mesh AP’s – one more than the Mesh Hop (two meshed AP’s equals one Mesh Hop).

Note the gradual reduction in total cost as you add more Mesh Hops. It is true that adding Mesh rather than Ethernet will save you money, but only on the installation costs, not the actual cost of the Access Point.  But also note the drastic drop in throughput as you add more hops.

In this graph we can see as the average cost per installed AP drops (savings from the Ethernet cabling costs as you go with more and more Mesh Hops) the actual cost per kilobyte for each end user skyrockets. This is a function of more and more client devices sharing less and less actual Ethernet backhaul.

In this final graph we’ll focus on comparing the savings in percentage of lowered backhaul costs, compared with the loss of throughput. The “Sweet Spot” is at two Mesh AP’s or one Mesh Hop. Each additional Mesh Hop barely adds much in the way of cost savings, but instead has a huge drop in throughput.

Learn from the experience of others, and don’t get caught with a Wireless Mesh system that doesn’t provide for the requirements of your client devices.

Wireless Mesh isn’t “Magic” – it’s merely an illusion of cost savings – you still can’t break the laws of physics.

 

(a note that I’m not talking about Strix or Firetide Wireless mesh so hold your comments on those vendor’s proprietary solutions)

 

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 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. 

Next Page »