Mesh Calculations

Thought I’d take some time to discuss bandwidth using Mesh APs and the associated mesh calculations.

This blog entry is aimed at a slightly advanced level, so I am working on the assumption that you already know how a Mesh works.

Basically, the node APs (MAPS or Node APs – do we call them “NAPs”?) are nodes that connect wirelessly back to a main node, sometimes called a Root AP or RAP. The nodes build a mesh that is self-building and self-repairing without any user intervention. If a node in the path to the RAP (this is the guy that connects the wired world, remember) fails, it just works its way around it, and rebuilds the path automatically.

All good so far but, with wireless, the available bandwidth on a network connection can be assumed to be 50% of the connection speed (simple math assumption for this exercise). This bandwidth is shared by everyone on the channel. You, your neighbors, and so on.

Well the problem here is that all the mesh APs are going to be on the same channel. They usually service one radio for clients (maybe two in certain circumstances) but then all connect one radio on a common channel for the path back to the RAP (this is called the “Backhaul”).

We can assume 4 Mesh APs share the bandwidth ¼ each, right? Well… maybe. If the Mesh APs are all one hop from the RAP, they will share the bandwidth 1/n (where n is the number of APs). See Diagram 1.

What if we connect our APs differently? Take a peek at Diagram 2.

If 2 APs are one hop away from the RAP (called children of the RAP – that would make a great horror story, but I digress…), then they will share the bandwidth to the RAP. We know this calculates out to approximately 1/n each.

Then we connect the next 2 APs, each one hop away from the above mentioned children (technically, children of the children, so grandchildren of the RAP as it were). Now the math gets different. The data from these APs will first go across the wireless link up to the first hop (children), then continue over the wireless link a second time, up to the RAP.

So, data from a MAP (which is two hops away) crossed the network twice. Similarly, data from a MAP three hops away will cross the network three times.

This means that when you calculate the available bandwidth, you have to take into account the number of hops away the node is.

The calculation actually becomes a share of 1 / [(1xhop_1_aps) + (2xhop_2_aps) + (3xhop_3_aps)] and so on.

The configuration, from above, becomes 1 / [(1*2) + (2*2)], which means that having the 4 APs laid out so the 2 “grandchildren” APs link back to the two “children” APs will give each AP effectively 1/6 of the available bandwidth.

This is an oversimplification because, in a real mesh network, two distant MAPs may be far enough apart to not interfere which causes the numbers to improve slightly but, in general, it is a real-world phenomenon that causes rapid deterioration of bandwidth when you start deploying mesh networks with large depth (large number of hops away from the RAP). So you can summarize this discussion on Mesh, by saying “It’s not just the number of MAPs you have, it’s a function of the total the number and the number of hops they are away from the RAP”.

This is the bad news about mesh. Mesh is built for comfort and not for speed.

If you are looking to make your mark in the IT Industry, then NC-Expert offers excellent training courses aimed at relevant IT industry certifications –  contact us  today to get started.