Mesh Calculations

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.

Mesh Calculations – Diagram 1.

Mesh calculations - A diagram of a switch , rap , map , and map.

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.

Mesh Calculations – Diagram 2.

Mesh calculations - diagram of a switch , rap , map , and map.

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.

NC-Expert Blog

By Rie Morgan July 23, 2026
Few phrases trigger a knowing smile from experienced Wi-Fi engineers quite like this one, "It's the client's fault." Someone's video call drops while walking through the office or a warehouse scanner pauses between aisles, voice handsets crackle as users move from one floor to another... then, almost immediately, someone points at the device and confidently declares, "Well... clients decide when to roam." Technically, they're correct. But, practically, that's only part of the story. Roaming is one of the most fascinating aspects of Wi-Fi because it isn't controlled by a single device or a single setting. It's a partnership between the client, the infrastructure, and the RF environment. When that partnership breaks down, blaming one side rarely tells the whole story. Let's bust another myth... Yes, Clients Make the Decision Let's start with the important truth: in almost every Wi-Fi deployment, the client device ultimately decides when to leave one AP and join another. Laptops, smartphones, tablets, barcode scanners, medical devices, and countless IoT products all use their own roaming algorithms. Some roam aggressively whereas some cling to their current AP for far too long. Others seem convinced that losing the connection entirely is preferable to switching. Every Wi-Fi engineer has encountered at least one stubborn client that appears almost “emotionally attached” to a particular AP. :) Client behavior matters, but that's not where the story ends.
By Rie Morgan July 17, 2026
Every Wi-Fi engineer has heard some version of it, "Can't we just install the access points where the old ones were?" Or perhaps, "The floorplan looks straightforward. Let's save some time and skip the survey." Occasionally, someone even says the dangerous words, "We've done hundreds of these buildings. They're all basically the same." That's usually the point where experienced wireless engineers quietly smile, knowing that the building is about to teach everyone a valuable lesson because: buildings don't read design guides, concrete doesn't care about your deployment schedule, metal doesn't respect your project budget, and radio waves have never once agreed to cooperate, simply because everyone wanted them to. Let's talk about why a site survey isn't an optional luxury... it's one of the most valuable engineering tools available. Every Building Is Different At first glance, two office buildings may appear identical: same square footage, same number of floors, similar room layouts, yet their wireless behavior can be dramatically different: one may have reinforced concrete walls, another may contain extensive glass partitions, the warehouse may be filled with moving inventory, a hospital may have elevators, imaging equipment, and countless reflective surfaces, a manufacturing facility may contain machinery that wasn't mentioned on any floorplan, and remember: even furniture changes RF behavior! Anyone who has performed enough surveys eventually develops a healthy respect for one simple fact: the building always gets a vote, too!
By Rie Morgan July 13, 2026
There is something wonderfully satisfying about seeing a Wi-Fi channel get wider: twenty megahertz becomes forty. Forty becomes eighty. Eighty becomes one hundred and sixty. This begs the question: more bandwidth must mean more speed... right? Well... sometimes. Like many things in Wi-Fi engineering, the answer begins with, "It depends." The idea that wider channels always deliver better performance has become surprisingly common. It's an understandable conclusion because, in theory, wider channels can carry more data. More lanes on a highway should allow more traffic to flow. But Wi-Fi isn't driven by theory alone. The RF environment has an annoying habit of reminding us that physics always gets the final vote. Let's explore why bigger isn't always better... More Lanes... But Fewer Roads Imagine a city with only a handful of highways. If you combine four lanes into one giant superhighway, each individual vehicle might travel faster. Unfortunately, you've also eliminated several independent routes that other drivers could have used. That's exactly what happens with channel bonding: - An 80 MHz channel occupies the same spectrum as four adjacent 20 MHz channels. - A 160 MHz channel consumes eight. While you've increased the potential throughput available to one transmission, you've dramatically reduced the number of separate channels available for everyone else. In an empty environment, this is often perfectly acceptable. But, in a busy enterprise? Not so much.