[OpenWrt-Devel] Multiple OpenWrt devices collectively managed?

[David Lang]

On Mon, 23 Mar 2015, Janne Cederberg wrote:

> I was thinking the same thing David mentioned, namely, that
> determining channel change criterion is probably not trivial. Are you
> guys familiar with Cisco Meraki?

Thinking about the problem a bit more.

First off, I don't believe that this can be completely automated due to the 
inability to check other channels while providing service, but I do think that 
the initial setup of such a system can be greatly simplified.

first off, the situation that I'm talking about is setting up a multi-AP network 
with a wired backbone in an area that has some other wifi activity. In my 
particular focus, this is setting up a conference network where there is already 
some wifi in place (and they don't turn it off), but if you are setting up a 
business network and have another company in adjacent offices (or on an 
adjoining floor) you have the same basic problems. The setup and calibration 
will take place when things are generally fairly idle.

After the APs are deployed and live, scan standard channels for beacons (on 2.4 
only bother with 1,6,11,14 the others shouldn't be considered). some of the 
SSIDs are going to indicate networks that are giong to be busy, some are going 
to be phones, printers, etc that may have bursts of activity, but are not going 
to be ongoing major interference sources. It will take a person to categorize 
these, although a SSID that is seen on multiple channels is probably one to be 
concerned about. Interference sources on channels may or may not be significant. 
It's going to be a judgement call.

Then put all the APs on the same channel and beacon frequencly for a bit to map 
out what APs see each other at what strength.

Then try to figure out a channel plan that minimizes interference from outside 
sources and other APs. Include estimates on how low the power can be turned down 
to reduce AP <-> AP interference.

The admin needs the ability to insert modifications (i.e. "I know that a vendor 
will be using channel X in this area heavily", insert an interference soruce 
that wasn't detected)

Deploy the plan, then designate one or more mobile devices as targets and 
monitor them closely as they move around the area. This requires an app on the 
mobile device that can report the signal strength of the AP with each handhake 
(fancy ping). If any dead areas are found, increase transmission power on the 
closest APs to provide coverage. sometimes you will need to go back and 
regenerate a plan.

This is a map coloring problem, but you don't know the shape of the vairous 
areas (because of the shielding/absorbing/reflecting properties of structures), 
the areas are 3-dimentional, and on 2.4GHz you don't have enough channels to do 
a non-interference job in any case, so there is no one right answer, or even oen 
clearly best answer. So different starting points in channel assignment and 
different orders of walking through the APs to assign channels will result in 
different plans.

Since bodies will affect the range, either a fudge factor will need to be put 
in, or a walkaround test will need to be doen once crowds form.

The entire test will need to be done independently on 2.4GHz vs 5GHz

Ideally the software that's doing this lets you take an image and place the APs 
on that image to then produce a graphical representation of the expected 
coverage (scale of coverage circles based on the signal strength that the APs 
hear each other, assume that the picture and AP locations are fairly close to 
scale accurate. Ideally the mobile app lets the people moving them around the 
facility tag where they are easily to help show the effects of 
walls/antennas/etc.

If you have "extra" radios (either APs with multiple independent radios per 
band, or APs that you aren't having users connect to), you may be able to do 
some scanning while things are live to detect unexpected interference, but 
generating and testing a plan is disruptive enough that you need to think hard 
before you try changing things.

Since a lot of this is going to depend on where the APs are deployed, and what 
antennas are put on them (and how the APs/Antennas are positioned), the planning 
system is not going to be able to fix a bad layout, it can help make it less 
painful, but there should always be the visualization of what's going on so that 
an experienced person can look at what the computer decided to do and decide to 
modify it or throw it out.

I've never had the time to go through all of these steps manually when deploying 
to a location, but they are what I'm thinking of, and I make it a point to see 
what sort of effect the different types of walls have on the signals when 
planning for an event. I would love to be able to backstop my educated guesswork 
with actual measurements to help me find problem spots.

David Lang
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel