I wrote a nice Perl script to change each of our towers a will back when
that came available to assign each AP a cc and keep the subs
where they need to be or allow them to move between.
Took about 2 or 3 mins for each tower LOL
On 11/17/2014 08:13 PM, Steve D via Af wrote:
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
<mailto: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 <mailto: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.
