NV2 - increase NV2 client scan-for-AP b4 connect to AP
Unlike 802.11 or nstream, nv2 clients do not background scan for better APs to connect or roam to. All client nv2 connections want to stay connected to the original nv2 AP they first connected to. Longer nv2 client scan times would at least get equal client-connect loads distributed evenly among all nv2 APs of equal signal strength found in the client nv2 scan list.
North Idaho Tom Jones
As far as I know nstream and 802.11 also cannot do a background scan and then connect/roam to the best signalled AP. The background scan is possible, but only to 'see' what is out there. The client stays connected to what he was. So its only a manual tool the operator can use which in NV2 indeed is not even available. But correct me if I'm wrong! Maybe you have some script that forces de CPE to switch to another AP when that other one has better signal?
Second; I agree on the scan 'low frequencies first'. I observed the same when running a scan or when I have a CPE that is allowed to connect to two or three different AP's (Even with different SSID's). If both frequencies come with roughly the same strength the low ones are picked up first and if allowed used to connect.
But why have free roaming clients to start with? If you are using NV2 I'd presume all your clients are fixed installations? Like we have.
I just make sure all clients that have the option to connect to 2, or 3 different AP's it connects to the best one upon my decision as an operator.
Because I know what the average usage is on each AP.
So if I have 2 options for a client to connect to, I'd look to which AP gives the best signal and pick that one. But if signals are good for both AP's I decide to make it connect only to the one with the best P2MP network. And here comes the amount of connected CPE's as well the signals they all have in consideration. I know how the AP's perform in general.
So I'd balance the client load then more based upon my insight as network operator which usually beast any automated process. (Don't forget that most data that could be used in an automated decision making process is variable anyway. Signals vary, traffic vary, which clients are generating traffic vary.. etc.)
As soon as the decision is made that specific client will be add into the 'access list' of that preferred AP, and that same preferred AP will be add as first listing in the 'connect to' list of the CPE.
I might have both units (AP + CPE) to know about the other but in the AP's 'access list' only in a 'disabled' function. So only in case AP1 goes down, I stil allows the CPE to connect to AP2 so at least we can still serve the client. (Most of the times we disable the alternative 'connect to' listing because the setback is that when we do an upgrade on AP1 the clients jumps to AP2. After that we can upgrade AP2 so the client jumps back but for some clients it might be the other way around. And sometimes you just need to reboot an AP and I don't want the kind of client to jump to the alternative AP)
This is all manual work. MT units are pretty reliable so it happens rarely we have to make use of a 'backup AP' because one AP goes down.
A semi automated proces as you suggest imho is hardly achievable. Even when CPE's would automatically populate AP's in a more balanced way by numbers of associated clients to AP, it still doesn't mean you really balance the load on an AP. It is still pretty expectable that one AP has much more traffic then the other. And that variate between those AP's too....
The client would be best connect to an AP with little (overall) traffic then one with high traffic even with only a handful of clients.
I think the experience of the operator is a much more better decisive tool then any automated proces performed in these little intelligent devices.
We set everything manual and in 98% of the case we never have to adjust or change the client's CPE preferred AP any more...
Show your appreciation of this post by giving me Karma! Thanks.
Rudy R. Puister
WISP operator based on MT routerboard & ROS.