Meraki

AndrewTergis · ‎Sep 16 2020

Are any Cisco Meraki products able to reliably keep more than 200 clients associated and authenticated (WPA2,TKIP/AES) at a low transfer bandwidth (<1Mbps)?

I've done a fair amount of research and I understand some the challenges around dense deployments. Unfortunately we are in a situation we need to cover many hundred small IoT devices with a single AP. They are in too close a proximity to reliably cover them with multiple access points. Fortunately they produce very little network traffic, however it's important that the access point is able to keep the devices reliably connected.

We've tried some access points that have failed spectacularly in this condition: Once some connection limit is exceeded, they can get latched in an inoperable state. In this state no traffic would get to it's destination, and the whole system was unable to recovery. We'd need to reset the device and pray that the connection limit isn't exceeded again.

Total failure is unaccepable - we just need a wireless system that will allow *some* traffic to keep going out while overloaded so that the system can settle itself.

Thank you in advance for your assistance!

PhilipDAth · ‎Sep 17 2020

Originally you mentioned 200 clients and I see that you are now talking about supporting 400 clients.

There are 23 non-overlapping 5Ghz channels (give or take a few for different regulatory zones). I'd go straight to 4 x MR56 APs.

And before spending any money, I'd use the Meraki trial program so you can test this out yourself.

https://documentation.meraki.com/Getting_Started/Meraki_Free_Trials

I'd ask for:

4 x MR56

1 x MS120-24P (you'll want a PoE 802.3at switch to power all of this)

Being a trial you can test having 1, 2 3 or 4 APs on, and see the impact. And then you'll know for sure exactly what you need to buy and how it will perform.

When doing your testing, try to run any config for 24 hours before you start collecting results. A new system spends 24 hours measuring the environment and adjusting its operating parameters before it reaches its optimal state.

https://documentation.meraki.com/MR/Monitoring_and_Reporting/Location_Analytics/Meraki_Auto_RF%3A__W...

If you are not happy with the kit you can simply return the trial and walk away at no cost to yourself.

View solution in original post

PhilipDAth · ‎Sep 16 2020

You would need to use a pair of MR56's. One wont do it.

https://meraki.cisco.com/product/wi-fi/indoor-access-points/mr56/

You would have to use 5Ghz only. You would have to disable the lower speed data rates (so probably only allow 12Mb/s and above). Otherwise the beacons consume too much air time. You would have to use 20Mhz wide channels only.

And if you want it to work more reliable, you would only use WiFi6 IoT devices that support the IoT extensions. But I doubt that would be possible. IoT devices tend to lag behind a lot being more concerned with price than reliable operation.

MerakiDave · ‎Sep 16 2020

@AndrewTergis I'm not sure which makes & models you might have already tried, but if it's just a single AP to be able to prove this out, I'd suggest getting an MR46 or MR56 trial unit and deploying it with the recommendations @PhilipDAth mentioned as well. Meraki trials are completely no cost, no obligation, and it's new equipment so should you keep it, no need to return and replace the trial unit, it just gets converted to a purchase.

[updated] In the newer firmware releases and in newer chipsets since acW2 APs, there is no longer a software limitation of 128 clients per radio (which you would normally never want if those clients were actual end users). But with IoT deployments much more mainstream now, you can support up to 256 clients maximum per radio on acW2 APs and up to 512 clients per radio on ax APs. So you might be ok in that regard given it's an IoT environment with really lightweight requirements. But there are many other factors to consider, and just because an AP might support that many clients per radio, doesn't mean it's a good idea, 😁

You'll need to carefully consider the IoT application itself and understand it's network traffic footprints, and really understand what's going to drive the duty cycle in that airspace, and consider the RF environment, noise floor, etc and the various considerations that come up during a site survey.

AndrewTergis · ‎Sep 17 2020

Thank you @MerakiDave and @PhilipDAth for the suggestions! Yes, this is a risky and non-ideal situation. The devices are configured with a randomized connection back-off, but there are still conditions in which all of them can reset at once. Like during a power loss or operator error. Fortunately it's perfectly acceptable if there's a momentary loss of connectivity, but we found that the low-density wireless access points we've been using could totally crumble in this situation. They'd get latched in a state where no clients were given enough error-free airtime to recover the whole batch.

Fortunately (and unfortunately) the devices are very close together, so the AP can be located very close to the clients. So i'm hoping we can tune the transmit power to keep this batch of devices *somewhat* isolated from the rest of the RF environment. Unfortunately we're intending to deploy this AP into a variety of unknown customer sites, so we don't have any control over the rest of the RF environment.

I'm going to see if I can run some tests on an MR56 👍

AndrewTergis · ‎Sep 17 2020

Although, since you sound quite knowledgeable:

If you had to cover 400 devices in a 10 foot by 10 foot space, would you even consider multiple APs? To me it seemed like the APs would need to be unacceptably close, that the RSSI margins would be too thin to reliably distribute clients across the APs. Aside from dropping the transmit power and praying, are there any other tactics to bring to bear?

PhilipDAth · ‎Sep 17 2020

I'd put the APs 300mm or greater apart. We don't need a 50/50 distribution - we just can't them all on one AP.

The clients will end up spread across both APs. Clients use many factors when deciding which AP to attach to and it all depends on the client.

A lot of clients will probably get the same or similar RSSI in your case, so if they decide on that basis they'll probably randomly choose one or the other. Others will do it based on the order of beacon received which will also be quite random.

The other thing is if an AP starts to get overloaded compared to the one next to it then they may do client load balancing and ask some of the clients to move.

https://documentation.meraki.com/MR/Other_Topics/Client_Balancing

HOWEVER, some clients are two dumb to process these messages and may simply disconnect. And you're dealing with IoT devices ... There is a chance you may have to disable client load balancing if you do have issues with disconnects.

Because you are in such a small space, I would set the minimum bitrate to something like 24Mb/s or 54Mb/s.

https://documentation.meraki.com/MR/Radio_Settings/Minimum_Bitrate_Control

I'd go with 54Mb/s if all the clients support it (if they dont they will completely fail to connect). This will improve spectral efficiency tremendously.

Another option you could use (I personally wouldn't as it is introducing too much complexity) is to use something like a pair of MR46Es (you might even need three) and directional antennas (like patch antennas) so the signal is focused in a specific direction.

https://meraki.cisco.com/product/wi-fi/indoor-access-points/mr46e/

https://meraki.cisco.com/product/wi-fi/wireless-accessories/wireless-accessories-antennas/wireless-a...

If you are bored, about 50% of this high density design guide applies to your case.

https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/...

PhilipDAth · ‎Sep 17 2020