Designing wireless networks (WLAN’s) is not all about “signal strength” and “dBm”, it’s also important to put the right number of wireless Access Points (APs) in to provide the level of network capacity you need. Too many APs wastes customer money and in the worst case scenarios simply generates interference and network overheads instead of extra capacity. Install too few APs and at busy times, you risk the Wi-Fi performance taking a nose-dive.
This article is a response to a question posed by Lee Badman (@wirednot) on his Wi-Fi question of the day (#WIFIQ) on Twitter:-
#WIFIQ 7/10/17 When planning your Wi-Fi for capacity, what’s a typical per-user bandwidth requirement / SLA you go for? How do you verify?
(A question which may well have been prompted by the latest release of Ekahau Site Survey (version 9.0) which includes an overhaul of it’s Wi-Fi capacity planning engine.)
Before I start, I should note that I see that there are two types of Wi-Fi capacity. Firstly, there is Throughput in terms of “how many Megabits can we get”. The second, which is just as important is what I call Associative Capacity – How many AP’s/radios do I need to supply in order to ensure that all client devices can associate to the network.
This article focuses on the former, providing enough raw throughput to client devices.
Things to Consider
In order plan capacity and work out how many APs you need a number of things need to be considered: –
For the former, it’s not as simple as reading the numbers off the side of the box. The amount a single AP can deliver will be much lower – less than 100 Mbps in some cases, depending on the configuration of the AP and the clients which will be looking to connect to it. Although reliable test figures aren’t readily available, we can do some ballparking. (As an aside, it’d be great to collate real world throughput data somewhere…)
Example Wi-Fi Capacity Scenario.
Consider this scenario,
The clients supported by DummyNet Inc all support a single Spatial Stream, a 20 MHz channel and are expected to average 802.11ac data rate MCS 7. Short Guard Interval is disabled on the AP, and the 2.4 GHz radio is disabled.
In this scenario how much bandwidth will an AP provide?
However much is advertised on the box, the amount of throughput an AP can deliver is going to be constrained by the client capabilities and it’s configuration. In this case,with one stream, a 20 MHz channel width and MCS 7, clients will will be likely to associate at a data rate of 72.2 Mbps. Real world performance will be in the order of 40-45 Mbps, taking into account of network overheads, etc, AND assuming that there is only a modicum of interference, etc, etc. (There are other things to consider, but let’s leave it at that for now.)
In this example, the answer to our “how much bandwidth” question is a very modest 45 Mbps per AP. (We’ll probably leave the Smart Rate Ethernet out for now then!)
How much bandwidth do users require?
Without a reliable capture of network requirements backed up by real world usage data this question is very, very difficult to answer. In my experience it’s rare to get a good set of accurate usage data, but with some effort you get answers to questions which describe how the WLAN is going to be used.
To calculate how much bandwidth people require we need to understand the applications which they will be running, and how much they’ll be using them. But even if we could reliably get the former, the latter is very hard to estimate.
Let me illustrate,
How much bandwidth does e-mail need?
Take e-mail. Even if you get large attachments mailed to you, what kind of bandwidth do you need to get a good user experience? In the time it’s taken you to read this article, you may have received mail. An average Words Per Minute of 200 would mean it’s taken you 2-3 minutes to get here. That’s 2 x 60 = 120 Mb or 15 MB’s worth of e-mail downloaded even at a lowly 1 Mbps!
Looking at my own inbox this morning, it’s not even close to 1 MB. (On a “bad” day it might go as high as 50 MB – if i receive a bunch of floor plans, for example.)
Bandwidth required for ‘Web browsing’
Web pages are tricky too. Once upon a time I measured how much data got transferred to a laptop which was aggressively scrolling down a tumbler feed. I think the answer was 25 MB in about a 30 seconds, which equates to about 8 Mbps.
Do we need to provide 8 Mbps for web browsing then, to support this?
I’d suggest not, as it’s not a real world usage scenario. For most users, similarly to e-mail, content is loaded and then time is spent actually reading it. A great example is the Daily Mail here in the UK. (Forgive me http://www.dailymail.co.uk) Open the page and Boom! All the images load very quickly, no doubt opening a whole host of separate TCP/IP connections. According to Windows Task Manager, my tablet consumed between 1 and 5 Mbps for about 30 seconds to load all the content in that web page. If I chose to actually read anything, more would be downloaded, but then significantly more time would be spent reading the articles. I’d wager that most web pages are far less resource hungry and the time to consume would likely be at least an order of magnitude beyond the time taken to download, at virtually download speed.
Building up a picture
The illustrations above suggest that perhaps we could cater for general purpose web and e-mail usage with as little as 1 Mbps per user (assuming no other background traffic or apps in use), but even that’s not quite the whole picture. For the majority of office users I’d suggest that, assuming the office isn’t some kind of “Google Zoo” where everyone is so bored that they spend their entire working day browsing the web, watching the clock tick inexorably forward, much time is spent not actually using the network resources at all.
Consider how much time you spend doing other stuff – from chatting to colleagues to actually producing stuff.
Because of this we can probably actually contend this 1 Mbps for normal office use – allocating 1 Mbps to share between a number of people.
How many times can we allocate that 1 Mbps? If we over-do it, then inevitably a number of people will regularly try and use it at once, resulting in a slow experience for everyone. At the other extreme, we could not contend it at all – giving everyone 1 Mbps, despite the fact that it’ll be idle 95% of the time, arguably, not providing value to the network owner.
Similarly, we might need to allocate, say 10 Mbps for some high definition video conference facility. Do we contend this? The risks are greater if we do as real-time applications are less able to make use of buffering, etc, and if that 10Mbps isn’t there when it’s needed, service users will immediately notice.
From another angle, arguably, Senior Management should be given a less contended connection to ensure their work is uninterrupted. Their time is often valuable and interruptions to their work can have very expensive consequences. (Although, perhaps in some working cultures some members of a Senior Management Team would have the same as their staff order that have a realistic view of the performance of the infrastructure they commissioned?)
From yet another angle, we also need to consider whether most people will use the WLAN at all. If all users have a wired desktop in the office, are we catering for just mobile usage? Maybe only 1 in 5 people will actually use the wireless network at all, so that floor-plan that has 200 desks on it will only have 40 wireless users and our contention can immediately be five-fold what it might have been should everyone require a connection.
So clearly, the answer varies by use case. Perhaps we can risk some users having slightly worse performance than others, but at other times we do need to plan for “Peak Utilisation” – ensuring that we provide enough capacity for the real worst-case scenario when everyone needs their bandwidth at the same time.
Planning for growth?
One final thing to think about is, is today’s peak utilisation going to be adequate throughout the life of the network? Consumption of data through wireless media such as Wi-Fi is only going to grow over time; more devices; more apps; higher definition video. It is therefore unlikely that a network designed to meet today’s capacity requirements only will operate effectively 5 years time. Some degree of growth should generally be accounted for.
Similarly, we should consider what plans there are for the “wires” which are likely to be providing a significant portion of any office’s data bandwidth. Are we planning for the eventuality where most users will stay desk based or will they become more mobile and rarely bother to plug in, even when wired connections are available? Or, pushing the boat out further, is the office likely to go “wires free”, and expect everything, including telephony to run over the WLAN?
So, I’ve not really provided any answers here, but hopefully highlighted some of the complexities I’ve encountered when planning capacity. These musings also hopefully illustrate why Signal Strength is not enough to design a wireless network. The number of APs required for a successful WLAN deployment can vary massively based purely on capacity requirements and is often dictated by these requirements, not by measuring signal strength. Indeed, a network designed to meet a capacity plan may well meet (or exceed) signal strength requirements for 90% of the floor space by default. In these cases the game changes to one of managing interference; making sure that all the capacity planned is actually realised and not lost to Co-Channel Interference.
The one piece of advice I would give is to make sure that all the requirements are gathered to enable you to make judgement calls on network capacity. Write down everything you’re told, all the conclusions you draw and all the assumptions you inevitably have to make. Show your working out where you can, giving the chance to review and challenge to whoever needs to. This will ensure that any incorrect assumptions or errors in your calculations are picked up and exposed before the wrong number of APs get nailed to the walls and ceilings.
IF you have had a chance to check out Ekahau version 9, I would be interested in your thoughts on the “SLA” numbers and descriptions. My own view is that the the SLA’s are too high. Using the term “SLA” implies, to me, the provision of un-contended “peak” bandwidth. Therefore, I’d suggest that providing 4 Mbps should be described as “pretty darn high” rather than “normal”.
As a starter, I’d probably pitch:-
But even these figures make me nervous and need to be caveat’d with “It Depends…;)”. What is a ‘normal office’ these days?
Perhaps Ekahau need bigger SLA’s in order to err on the side of over-provisioning. Otherwise many relative novices may end up woefully under provisioning a network if 1 Mbps is described as “normal”. Similarly many enterprises will wish to keep costs down and would be delighted from the Bill of Materials resulting from a network designed with a 1 Mbps per user ‘SLA’ – even though their ‘normal office’ is actually completely “wires free”! If initially over provisioned (a little), at least a WLAN it will work on day one!