WiFi Capacity planning calculation

[PGP]

Reading through the Meraki doc "High Density Wi-Fi Deploymens" one of the calculations it mentions is

"Number of Access Points based on throughput = (Aggregate Application Throughput) / (Device Throughput)"

 I just wanted to check that device throughput is referencing the table in the document (and if so why did they use ~101Mbps when it shows ~102Mbps for 802.11ac 2SS ) or the AP throughput and is so how do i find that for the MR46.

The datasheet for the MR46 quotes "The 5 GHz 4x4:4 radio and the 2.4 GHz 4x4:4 radio offer a combined dual-radio aggregate frame rate of 2.98 Gbps*, with up to 2,402 Mbps in the 5 GHz band and 574 Mbps in the 2.4 GHz band"  so is the throughput 2,402 Mbps (based on using the 5Ghz frequency) and is so how  / or does the wired LAN connection affect this (that is to say wired via  either 100/1,000/2.5G BASE-T Ethernet).

[GIdenJoe]

There is alot that can be written about real world throughput when deploying access point.
Usually you can use predictive modelling for capacity planning inside predictive survey tools.

However real world will always differ a bit from predictive but it can give a good indicator.
In the end after your deployment has completed it is important to also gather data from your wireless deployment at busy times.

It is very important to know a few key details.
The MR46 AP does have 4x4:4 on 5 GHz and also on 2.4 GHz.  However there are no Wi-Fi 6(E) clients that support more than 2x2:2.  This means that in order to be able to use the 4x4:4 on your AP you need your clients spread out enough so the AP can use MU-MIMO to divise up it's 4x4 radio streams over 2 spatially separate 2x2:2 clients.  Also for Wi-Fi 6 clients you also have the OFDMA resource unit division for smaller frames over multiple clients.

Then you also need to consider the management overhead and how the clients will actually behave.
So while you theoretically can have really high MCS table values over many clients your clients will usually have alot of waiting to do before being able to transmit.

Long story short:  If you have few high capacity wireless clients you will have more chance to actually max out a 1 gig connection from the AP and have the necessity to at least use 2.5 Gbps ports on your switch.  If you have a really high amount of users on the same AP (like 40 or more) you will have more waiting due to contention and less chance to actually fill up your 1 gig connection.

I personally use Ekahau site survey for my designs and if capacity planning is a part of the survey you go about it this way:
You define an area and within that area you can define the amount of clients of each type and with the expected applications they will all be running concurrently. (for example: 10 idle smartphone 2x2 clients, 5 smartphone 2x2 clients using voice, 5 laptops doing mail and webtraffic and 2 laptops doing video conferencing).  With this information the survey software will calculate how much airtime those devices will take up divided over all the AP's in that area and keeping into account if you have any overlapping or co-channels.

[UKDanJones]

The biggest thing to remember is that Wi-Fi works one device Tx at a time. Very rarely have I seen OFDMA (part of the 802.11ax standard) or MU-MIMO in the ’real-world’. 

Your biggest limiting factor will be channel width and spatial streams (as previously stated most all clients are 2x2). 

Also, note that data-rate does not equal throughput!

You also need to consider QoS when thinking about capacity planning. If you use QoS and you have clients needing real-time apps (like voice) you're limited by the reduced nav timer spots available and the max retries of 3. This means you'll end up with 21 nav timer slots per channel. Using the fact that 802.11 is only usable below 40% utilisation you only have the capacity for 8.4 devices (although Cisco recommends 12 due to how quickly this all happens).

Application usage is more important than number of devices in my opinion. Very few users will be using real-time apps on more than one device at a time. 

[GIdenJoe]

QoS is well and good in enterprise environments where you can have policies on your devices to have them tag the traffic with the correct UP tag.  However if you are talking high density as in events or stadiums that comes flying out the window 😉

In the end if your airtime constantly full due to bad AP and channel design any application will suffer from that.  OP's original question is something well to consider before deploying a wireless deployment however the way of doing it by a simple calculation is a bit risky.

If I was able to fully capture wifi6(e) traffic I would be able to see how much OFDMA was actually being used.  If someone has alot of Wi-Fi 6 clients that do some voice calls you could try to capture that and see if it is actually being used.

[UKDanJones]

You’ll never hit 1Gbps throughput on an MR46. 

2.4 GHz @ 20 MHz @ 2SS - ~150Mbps

5 GHz @ 80 MHz @ 2SS (which you probably shouldn’t be using in anything other than an environment with a handful of APs) - ~ 650 Mbps

max throughput will be ~ ~800 Mbps

If you had the CW9164 and ran:

2.4 @ 20 MHz @ 2SS - ~150

5 @ 40 MHz @ 2SS - ~300

6 @ 80 MHz @ 2SS - ~650

then you might need more than 1 Gbps… but probably not…

most people will probably run:

2.4 - 20 MHz ~150 Mbps

5 - 20 MHz ~ 150 Mbps

6 - 80 MHz ~ 650 Mbps

950 Mbps

[PGP]

@GIdenJoe & @UKDanJones  - Thanks for this reply thread. I should say I have used both Airmagnet and Ekahau for designs  and appreciate what I am asking is all based around theory rather than real world.  

The area we are currently planning for is a "high'ish" density office with will have a high concurrency of video meetings so the  normal AP planning by coverage alone I feel would not work. So having been given the clients device spec (802.11ac 2SS on 5GHz) and the application usage I was trying to do a quick coffee break calculation on the AP numbers that will then be done for real in Ekahau in a few weeks time. I  could just use the client concurrency of 25 like Cisco and Meraki talk about but wanted to see if planning for application usage would derive a higher number of AP's.  For example (not real world numbers)  if  we have 1 floor with 400 users (assuming they average at 2 connected devices - 1 laptop doing video chat and 1 mobile just background syncing) that would require 32 AP's for 25 max connections . But you say 50% of the users will be on a video chat  (4Mb per call), the other 50% web browsing  (1Mb)  and allowing (0.5Mb for each mobile device background sync) that works out at 1600Mb required so was going to see what Meraki's formula worked that out to be.

[UKDanJones]

Your biggest issue in a space like that will be ensuring that your cell sizes are small enough and that your clients will balance out correctly and that you’re hitting your roaming thresholds in the right places. What you don’t want is a client connected to an AP miles away slowing everything down. In your example I’d be aiming for roughly 15 users per AP. Not all your users will actually be using real time apps all the time and having all their phones connecting and using airtime at the same time. There’s no simple calculation you can do on this. Most of it will be experience in that type of environment with the type of traffic you’re seeing. If I were putting this in for a client I’d ask them what they’d prefer… more APs at lower Tx to have more capacity or fewer APs for lower cost and build around that. If they’re looking to me for the ‘right number’. I’d give myself more wiggle room and add more capacity than I’d expect so that their experience was as good as it could be. 

[Paccers]

Only 950 Mbps? But my home router box says I can get up to 10.8Gbps 😛 /s

[UKDanJones]

🫠🤣

[GIdenJoe]

Aren't you conflating your results with a single user per band now or are you actually using real world based estimations on for example 4 beefy Wi-Fi clients on the 5 and 6 GHz band?

[UKDanJones]

I’m basing it on the available throughput of the channel. It doesn’t matter if I have 1 client using 80 MHz or 12 using RUs that equal 80 MHz. 

The only time you’ll need more than 1 Gbps (at the Ethernet port) is if you’re using 160 MHz channels in 6 GHz (which unless you’re in a very small space with very few APs, you won’t do). 

[GIdenJoe]

I consider the RU's to be used for the smaller payloads.
I'm just referring to if your 4x4 radio does it's work and provides 2 spatially separate 2x2 clients their full speed (MU-MIMO).

Wouldn't it be cool if to have a large room shielded on the outer wall and slightly reflective on the inner wall and have lab quality test scenario's?  Like an independent organization that actually measures the total throughput in various scenario's per device type, large and small files like you have the IMIX testing on SD-WAN and firewalls.

[UKDanJones]

I’ve managed to see MU-MIMO in my lab but I’ve never seen it real-world… not to say that it doesn’t happen, just I’ve never seen it. I've only seen OFDMA in 5 GHz twice outside of my lab…

Wi-Fi is great because it's so resilient, but that resilience often means that we don't see the newer features.

I haven't done too many 6 GHz deployments yet, only around 10 so hopefully we’ll see more in that space where we don't have to worry about legacy clients. 

[UKDanJones]

On this topic… Peter’s talk at WLPC was very good. https://youtu.be/CZdwHPq-j-Q

[alemabrahao]

Although this information helps a little in building a wireless network, I don't think it's very interesting to do it that way, even more so if it's for a client. My suggestion in this case, invest in software like Ekahau or NetSpot.

[UKDanJones]

Use Hamina - it's $330 for 6 months as powerful as Ekahau but cloud-based and doesn't require a crazy license and overpowered hardware. 

[alemabrahao]

But does it also have the ability to do an active site survey or just a predictive one?

[UKDanJones]

Available to the public… just designs at the moment. It won't be long for public access to surveys. 

[UKDanJones]

I suspect it'll be announced at WLPC Prague... but that's a guess

[GIdenJoe]

I appreciate competition in the survey area since that could bring prices down a bit.
However I can't see what you could mean with overpowered hardware?

For the predictive surveys your hardware does not matter since it's predictive 😉  And the Ekahau solution I use now runs on a normal corporate laptop.

For the actual surveys having the measurement device that is actually tested to be within 6dB error marging as opposed to over 20dB error on other NIC's is not overpowered but just necessary, not to mention it comes with a spectrum analyser built in.

Please elaborate!  (and easy with the shilling please, you make it look like you are working for Hamina .p)

[UKDanJones]

By hardware, I just mean the amount of RAM that Ekahau uses (because it's written in Java and not optimised at all - running my custom report takes hours on a top-spec MBP M2 but it is a large report with lots of photos etc.)  I still use Ekahau for my surveys (a design isn't a survey) and I have the SK2 but neither Sidekick is actually calibrated, the SK2 is just using ordinary NICs that you’d get for a laptop. 

I don’t work for Hamina but I do know lots of people at both companies. They’re all great! I’m hoping that Hamina helps to push Ekahau forward. 

But for someone who wants to do a few designs… Hamina would be my first suggestion as it’s a low price point, offers similar design functionality (it also offers 3D design unlike Ekahau) and runs in a browser. 

It’s also crazy fast (showing coverage patterns whilst dragging an AP around). In my experience, I’m waiting for Ekahau to render my last placement. 

[GIdenJoe]

I run it on a simple HP Elitebook.
However I do not do surveys for extremely large floorplans so I couldn't speak to that.

The only survey I ever did in a factory with a building of about 350 meters in length and 60 meters in width was still with the old airmagnet and was purely on-a-stick.  You can imagine the amount of steps I took 😉  (2 floors btw)

[UKDanJones]

Ouch 😫 

yeah, some of my projects are massive… for smaller stuff Ekahau is fine. When your .esx file is a few GB it starts to struggle!

[vronsdean]

I’m basing it on the available throughput of the channel. It doesn’t matter if I have 1 client using 80 MHz or 12 using RUs that equal 80 MHz. 

[UKDanJones]

Please tell me you’re using 20 MHz wide channels (unless it’s a really small deployment). 

[vronsdean]

I don’t work for Hamina but I do know lots of people at both companies. They’re all great! I’m hoping that Hamina helps to push Ekahau forward.  whatsapp mod
watch tv series