Yeah, I can't stress enough how nice the primary, secondary, tertiary color code system is - moving away from a single color code system was worth the time involved. Even if you put each ap in a sector in as a "primary" (which we do for self-install/contractor installs), it'll still look for the better of the available ap's and lock to that - essentially doing exactly what your script is. Our tech's who know the area will put only the sector they know should be primary as such and the rest as secondary. There's even the option for it to intelligently move to the sector that will provide the most throughput. I don't know how it picks that, but I presume it's to avoid crowding to one sector, which I like. If another sector isn't as heavily loaded, but the signal is only a little bit worse, a bit of smart balancing that way could be nice. I've never followed up to see if that's how it actually works in the real world, but we set it that way anyway.
-Steve D On Mon, Nov 17, 2014 at 5:48 PM, Aaron Schneider via Af <af@afmug.com> wrote: > Hi Matt > > This is what most customers use the primary/secondary/tertiary color > codes for. That in conjunction with the rescan timers will automatically > make the sms rescan to try to get back on a primary color code if they had > to use a backup to register. > > Regards, > > Aaron > > > Sent from my Verizon Wireless 4G LTE smartphone > Any typos or strange word placement aren't my fault! > > > -------- Original message -------- > From: Matt via Af > Date:11/17/2014 2:35 PM (GMT-06:00) > To: af@afmug.com > Subject: Re: [AFMUG] System Release 13.2 is Official > > > If we know about this issue before release and documented it in the > release notes, it could have been spun as > > a "feature", but that opportunity is gone now :) > > > > The concern is how long it takes the SM to scan for the AP on each boot > up, right? How about a flag that tell that > > SM that when it is rebooted, it should first try to connect with the AP > it was connected to prior to reboot, and to initiate > > the scan only if that fails? Or do you need a button that says "turn off > all 2.5 center frequencies"? > > Not so sure on this. We use same color code on all AP's currently. > Occasionally an SM will get on a non-ideal signal AP in the cluster > etc and stick there. To fix this every night a perl script scans all > SM's in the system and logs signal strength etc. If the MAC of the AP > an SM is registered too has changed it reboots the SM and waits for it > to register again and records the MAC of the AP it registered too. > > It sure would be nice if there was a SNMP command to trigger a new AP > Eval scan instead of reboot but there is not. Would sure also be nice > if there was SNMP command to trigger a link test from the SM rather > then just the AP. > > I see a better solution as a primary scan list and a secondary scan > list. Primary list is the small list of frequencies and channel sizes > we use 95 percent of time. The secondary list is the full list we > scan when we try X seconds and cannot connect. Such as the situation > when interference moves in and we can only find a couple 5mhz channel > remotely clean. > > > > Not promising to make any enhancements as we try to make a bugfix > release for the 13.2 issues, > > but definitely looking for feedback on the best way(s) to reduce the > scan time. >
