Mounting 3 T301s on light-pole for 360 coverage.

[michael_miller_]

Working on a project right now for a large outdoor WIFI deployment.  We will be mounting t301s units on light poles to create 360 coverage around the light poles.  I would like to mount the APs between 10-15ft high and all three at the same height around the pole.   I was told I need to keep the APs 3ft apart so should I mount the APs at 10ft - 13ft -16ft around the pole?   What is the proper mounting for t301s 360 coverage?  

[klaus_heidelber]

The T301s black edition would be nice...

[michael_brado]

...but would absorb more heat.

[john_d]

Maybe I'm too much of a wifi nerd now, but looking up on a pole and seeing a Ruckus AP is one of the few things that'd convince me to try out public wifi 😉

I call it a feature!

[michael_miller_]

For this type of setup would you hard code channels on the APs or let Backgound or ChannelFly auto adjust.  

[john_d]

How many neighboring APs do you see around you? If the answer is a lot (which often is the case for outdoor APs) you might find ChannelFly advantageous. The main downside is that certain types of clients do not cope with channel hopping well. However, I'd expect most of your outdoor patrons will be using reasonably recent Android / iOS devices, which ought to handle this situation pretty well. I would strongly recommend keeping 802.11r enabled for FT Roaming. Even though it's not theoretically required, it seems to result in better roaming / channel hopping behavior for a lot of clients.


If you find a lot of rapid channel switches, you may want to consider the following mitigations. Based off my two years of experimenting with Channelfly in a busy apartment complex, my order of preference is:

1. Play with the ChannelFly MTBC (mean time between change) setting. By default, it's 60 (target of 1 channel change per hour), but can be increased to something as big as 1000. I've found values around 300 result in more acceptable amounts of hopping (a few channel changes per day) but with 9.13 I've found that 120 is quite tolerable as well. This is a command line setting — consult your CLI reference guide for your type of controller for details on how to set it.
2. Set up ChannelFly in run-stop mode. This is in the AP Group settings — basically allows you to configure ChannelFly to stop running after X minutes of AP uptime. It's basically a fancier automatic channel selection algorithm, but the downside is that you won't have the dynamic abilities of ChannelFly anymore (for example, the channel you selected was great yesterday, but today some bandwidth hog brought his MiFi unit and happened to choose the same channel as one of your APs). For an outdoor environment I expect the RF landscape would constantly change, so I'd prefer the first approach.

Another fun tip: One approach I've been liking lately is making two identical AP group: One with CF in run-stop mode, one with CF not in run-stop mode (always on). Then you can easily move AP's between these two AP groups with the web UI or via a script. You could imagine enabling CF during off-peak hours, or using it when you notice poor airtime stats (e.g. a lot of busy time or a lot of retries that signify interference) on a particular AP.