Hi,
After the recent SAS issues with Federated, an issue that I believe can be solved came up. The Frequency Scan Selection List we have programmed in our SM’s omits the 5, 7 and 15MHz bandwidith (and also the ‘2.5MHz’ channels) to reduce downtime and speed up our installation process. However, the AP’s “Channel Hunt” process following a grant termination can end up selecting one of these bandwidths. This creates an extended outage until we are forced to manually go back and re-set the AP to the channel size we want. Since CBRS grants are in 10MHz sizes, would it be possible to prevent the AP from choosing a channel bandwith that does not align with 10Mhz? (10, 20, 30 + 40)
I asked about this in ticket #336052 however we were told that it’s not possible as it is SAS controlled.
I asked Federated about this and they tell me, “As for the hunting for and subscribing to different channels, those are settings within the CBSD, the SAS does not control what channels the CBSD requests from it.”
So Cambium told me one thing and Federated told me something different.
I guess I am asking for a new feature. Does it seem worthwhile to Cambium to implement?
Hi. I see your concern. You don’t have, for example, 15MHz configured as a scanning BW setup in the SMs. I suspect what is happening in your case is, a subset of your grants were terminated by the SAS due to the outage, and our older AP software would have shrunk the bandwidth to continue operation on the remaining granted spectrum. What version of software were you running during the recent FW outage?
The Release R21.1 and later software has a change where, if a subset of the spectrum is terminated, rather than simply shrinking the Bandwidth to the remaining channels, our algorithm would invoke the channel hunt. And our channel hunting algorithm attempts to find a channel of bandwidth 10, 20, 30, or 40, up to but not exceeding the bandwidth you desired via the last time you had configured/requested grants.
Can you send me an engineering.xml of one of these AP’s that experience this problem you describe? Or, if this is a 450m, a field_diags.cgi? Let me know if you need instructions on gathering those. Not only is there some persistent logging related to channel hunt that will remain after any reboots you have done since the outage, but it will also allow me to examine the SAS log and attempt to trace what happened.
Hello, We are using CANOPY 20.3.1.1 AP currently.
I sent you a PM with the engineering file.
We will look at upgrading to v21
The BW change from 20 MHz to 15 MHz can happen on older SW if the center frequency configured for the AP is not properly aligned to the 10 MHz raster. For example, if the center frequency is selected as 3615 and the BW is 20 MHz, the AP will ask for three grants: 3605-3610, 3610-3620, and 3620-3625. If the first or the last grant is terminated by the SAS, the AP at older SW does not trigger a channel hunt, but keeps operating on the remaining grants, which in this case add up to 15 MHz. If the center frequency had been, for example, 3620, then the AP would have asked for two grants only: 3610-3620, and 3620-3630. If the SAS terminates one of the two grants, devices at older SW would change the BW to 10 MHz in this case. In general, we recommend selecting center frequencies on the right raster, not only to avoid this scenario, but also to decrease the probablity of a grant being impacted. Having three grants with a 20 MHz channel gives three opportunities to the SAS to terminate or suspend a grant.
Understood. Thank you for the reply!
I took a look at the log your provided. It is as myself and Lucia had suspected.
To summarize: late in the evening (central time) of Feb 3rd you lost 1 of your 3 multigrants due to apparent SAS congestion causing a single grant termination , dropping you down to 15Mhz. Looks like you took corrective operator action a couple hours later.
Then again in the early morning hours of Feb 8th, you lost 2 of your 3 multigrants due to apparent SAS congestion causing terminations which dropped you down to only 5MHz.
The FW SAS code fixes they are testing now should address the primary concern and prevent future congestion. But just to be safe, to prevent being moved to a 5MHz or 15MHz sized spectrum should you run into any future unexpected terminations, it’s a good idea to move to a 21.1 or later software release and/or align your channel to be on a 10MHz raster as Lucia had suggested.