SM dropping off PMP450i AP often

We’re in the early stages of setting up PMP 450 equipment on CBRS.

We have three PMP 450m APs, all running 20.2.1, on separate towers. We have a PMP 450i, 20.2.2, on a fourth solar powered tower. We have a handful of clients on the three PMP 450m APs. They appear to be running well. We recently connected our first customer on the PMP 450i and the customer is complaining that his cloud cameras are showing a lot of disconnects. It looks like the SM, PMP 450b high power, also on 20.2.2, is falling off the AP fairly often.

I’m still learning the PMP log messaging. I believe the log says the there are errors which cause it to be disconnected. I think it sees errors for up to 20 minutes at a time before re-connecting, based on outage logs in cnMaestro (cloud) going back beyond the log items on the SM.

I don’t see anything, that makes sense to me, in the logs of the AP or the SM telling me what the errors are so that I can figure out what I need to fix.

I appreciate any clues to get me pointed in the right direction with this.

AP Session Log:

Session Dump for LUID 2

07/05/2021 : 14:57:20 MST :  Event: SES_MSG, MsgType: PAREQ, NewState: IN SESSION, Flag 0
    repeated   18 times

SM Session Log:

07/05/2021 : 09:16:41 MST : Event: SMCBRSMSG, NewState: REGISTERING, Flag 0
repeated 3 times
07/05/2021 : 09:21:41 MST : Event: SMSESFAIL, MsgType: SES_CBRS_TO, NewState: OOSERVICE, Flag 0
07/05/2021 : 09:23:02 MST : Event: SMSESACTIVATE, NewState: REGISTERING, Flag 0
07/05/2021 : 09:23:11 MST : Event: SMAUTHENMSG, NewState: REGISTERING, Flag 0
07/05/2021 : 09:23:11 MST : Event: SMSESMSG, MsgType: SES_CBRS_TMP_ACCESS, NewState: REGISTERING, Flag 29
07/05/2021 : 09:23:11 MST : Event: SMAUTHORMSG, NewState: REGISTERING, Flag 0
07/05/2021 : 09:23:11 MST : Event: SMCBRSMSG, NewState: REGISTERING, Flag 0
repeated 3 times
07/05/2021 : 09:23:13 MST : Event: SMSESINS, NewState: REGISTERED, Flag 29
07/05/2021 : 09:23:13 MST : Event: SMAUTHORMSG, NewState: REGISTERED, Flag 0
repeated 2 times
07/05/2021 : 10:41:47 MST : Event: SMSESFAIL, MsgType: SMVCERR, NewState: OOSERVICE, Flag 185
07/05/2021 : 10:43:02 MST : Event: SMSESACTIVATE, NewState: REGISTERING, Flag 0
07/05/2021 : 10:43:17 MST : Event: SMSESFAIL, MsgType: REGREQTOMAXERR, NewState: OOSERVICE, Flag 0
07/05/2021 : 10:44:32 MST : Event: SMSESACTIVATE, NewState: REGISTERING, Flag 0
07/05/2021 : 10:44:47 MST : Event: SMSESFAIL, MsgType: REGREQTOMAXERR, NewState: OOSERVICE, Flag 0
07/05/2021 : 10:46:01 MST : Event: SMSESACTIVATE, NewState: REGISTERING, Flag 0
07/05/2021 : 10:46:04 MST : Event: SMSESFAIL, MsgType: SMREGGNTREJ, NewState: OOSERVICE, Flag 1
07/05/2021 : 10:47:19 MST : Event: SMSESACTIVATE, NewState: REGISTERING, Flag 0
07/05/2021 : 10:47:34 MST : Event: SMSESFAIL, MsgType: REGREQTOMAXERR, NewState: OOSERVICE, Flag 0
07/05/2021 : 10:48:49 MST : Event: SMSESACTIVATE, NewState: REGISTERING, Flag 0
07/05/2021 : 10:48:49 MST : Event: SMAUTHENMSG, NewState: REGISTERING, Flag 0
07/05/2021 : 10:48:55 MST : Event: SMSESFAIL, MsgType: SMREGGNTREJ, NewState: OOSERVICE, Flag 1
07/05/2021 : 10:51:34 MST : Event: SMSESACTIVATE, NewState: REGISTERING, Flag 0
07/05/2021 : 10:51:37 MST : Event: SMAUTHENMSG, NewState: REGISTERING, Flag 0
07/05/2021 : 10:51:49 MST : Event: SMSESFAIL, MsgType: REGREQTOMAXERR, NewState: OOSERVICE, Flag 0
07/05/2021 : 10:53:04 MST : Event: SMSESACTIVATE, NewState: REGISTERING, Flag 0
07/05/2021 : 10:53:04 MST : Event: SMAUTHENMSG, NewState: REGISTERING, Flag 0
07/05/2021 : 10:53:19 MST : Event: SMSESFAIL, MsgType: REGREQTOMAXERR, NewState: OOSERVICE, Flag 0
07/05/2021 : 10:54:34 MST : Event: SMSESACTIVATE, NewState: REGISTERING, Flag 0
07/05/2021 : 10:54:43 MST : Event: SMAUTHENMSG, NewState: REGISTERING, Flag 0
07/05/2021 : 10:54:49 MST : Event: SMSESFAIL, MsgType: REGREQTOMAXERR, NewState: OOSERVICE, Flag 0
07/05/2021 : 10:56:04 MST : Event: SMSESACTIVATE, NewState: REGISTERING, Flag 0
07/05/2021 : 10:56:04 MST : Event: SMAUTHENMSG, NewState: REGISTERING, Flag 0
07/05/2021 : 10:56:04 MST : Event: SMSESMSG, MsgType: SES_CBRS_TMP_ACCESS, NewState: REGISTERING, Flag 29
07/05/2021 : 10:56:04 MST : Event: SMAUTHORMSG, NewState: REGISTERING, Flag 0
07/05/2021 : 10:56:03 MST : Event: SMCBRSMSG, NewState: REGISTERING, Flag 0
repeated 3 times
07/05/2021 : 10:56:03 MST : Event: SMSESINS, NewState: REGISTERED, Flag 29
07/05/2021 : 10:56:03 MST : Event: SMAUTHORMSG, NewState: REGISTERED, Flag 0
repeated 2 times
07/05/2021 : 12:13:08 MST : Event: SMSESFAIL, MsgType: SMVCERR, NewState: OOSERVICE, Flag 185
07/05/2021 : 12:14:22 MST : Event: SMSESACTIVATE, NewState: REGISTERING, Flag 0
07/05/2021 : 12:14:37 MST : Event: SMSESFAIL, MsgType: REGREQTOMAXERR, NewState: OOSERVICE, Flag 0
07/05/2021 : 12:15:52 MST : Event: SMSESACTIVATE, NewState: REGISTERING, Flag 0
07/05/2021 : 12:15:52 MST : Event: SMSESFAIL, MsgType: SMREGGNTREJ, NewState: OOSERVICE, Flag 1
07/05/2021 : 12:17:07 MST : Event: SMSESACTIVATE, NewState: REGISTERING, Flag 0
07/05/2021 : 12:17:19 MST : Event: SMAUTHENMSG, NewState: REGISTERING, Flag 0
repeated 1 times
07/05/2021 : 12:17:22 MST : Event: SMSESFAIL, MsgType: REGREQTOMAXERR, NewState: OOSERVICE, Flag 0
07/05/2021 : 12:18:37 MST : Event: SMSESACTIVATE, NewState: REGISTERING, Flag 0
07/05/2021 : 12:18:37 MST : Event: SMAUTHENMSG, NewState: REGISTERING, Flag 0
repeated 2 times
07/05/2021 : 12:18:52 MST : Event: SMSESFAIL, MsgType: REGREQTOMAXERR, NewState: OOSERVICE, Flag 0
07/05/2021 : 12:20:06 MST : Event: SMSESACTIVATE, NewState: REGISTERING, Flag 0
07/05/2021 : 12:20:21 MST : Event: SMSESFAIL, MsgType: REGREQTOMAXERR, NewState: OOSERVICE, Flag 0
07/05/2021 : 12:21:36 MST : Event: SMSESACTIVATE, NewState: REGISTERING, Flag 0
07/05/2021 : 12:21:42 MST : Event: SMAUTHENMSG, NewState: REGISTERING, Flag 0
07/05/2021 : 12:21:42 MST : Event: SMSESMSG, MsgType: SES_CBRS_TMP_ACCESS, NewState: REGISTERING, Flag 28
07/05/2021 : 12:21:42 MST : Event: SMAUTHORMSG, NewState: REGISTERING, Flag 0
07/05/2021 : 12:21:41 MST : Event: SMCBRSMSG, NewState: REGISTERING, Flag 0
repeated 3 times
07/05/2021 : 12:21:42 MST : Event: SMSESINS, NewState: REGISTERED, Flag 28
07/05/2021 : 12:21:42 MST : Event: SMAUTHORMSG, NewState: REGISTERED, Flag 0
repeated 2 times
07/05/2021 : 13:33:34 MST : Event: SMSESFAIL, MsgType: SMVCERR, NewState: OOSERVICE, Flag 185
07/05/2021 : 13:34:49 MST : Event: SMSESACTIVATE, NewState: REGISTERING, Flag 0
07/05/2021 : 13:34:58 MST : Event: SMSESFAIL, MsgType: SMREGGNTREJ, NewState: OOSERVICE, Flag 1
07/05/2021 : 13:36:13 MST : Event: SMSESACTIVATE, NewState: REGISTERING, Flag 0
07/05/2021 : 13:36:28 MST : Event: SMSESFAIL, MsgType: REGREQTOMAXERR, NewState: OOSERVICE, Flag 0
07/05/2021 : 13:37:43 MST : Event: SMSESACTIVATE, NewState: REGISTERING, Flag 0
07/05/2021 : 13:37:49 MST : Event: SMSESFAIL, MsgType: SMREGGNTREJ, NewState: OOSERVICE, Flag 1
07/05/2021 : 13:39:03 MST : Event: SMSESACTIVATE, NewState: REGISTERING, Flag 0
07/05/2021 : 13:39:09 MST : Event: SMAUTHENMSG, NewState: REGISTERING, Flag 0
repeated 2 times
07/05/2021 : 13:39:12 MST : Event: SMSESMSG, MsgType: SES_CBRS_TMP_ACCESS, NewState: REGISTERING, Flag 29
07/05/2021 : 13:39:12 MST : Event: SMAUTHORMSG, NewState: REGISTERING, Flag 0
07/05/2021 : 13:39:12 MST : Event: SMCBRSMSG, NewState: REGISTERING, Flag 0
repeated 3 times
07/05/2021 : 13:39:14 MST : Event: SMSESINS, NewState: REGISTERED, Flag 29
07/05/2021 : 13:39:14 MST : Event: SMAUTHORMSG, NewState: REGISTERED, Flag 0
repeated 2 times

Quick question… are you using NAT on your 450b’s along with firmware 20.2.2? If yes, then you should update your firmware to 20.2.2.1 immediately as it fixes an issues that breaks NAT.

1 Like

No, we bridge through to the router inside.

Can you post a screen shot of the AP’s link status page showing the SM having issues? Can you also post a screen shot of the AP’s radio config page?

1 Like


It may not be related to CBRS, When we have a CBRS issue the log usually throws up CBRSFail or something very clearly labeled as CBRS. You could disable CBRS for a bit and see if the link stops dropping Just make sure your SM is scanning all default frequencies because I’m not sure about the Follow Me when changing CBRS state. The logs you posted I have seen plenty before, With session count and registration requests makes it look like a RF link issue to me. If the SM stays in session long enough what are the power levels, SNR, and Modulation after a link test uplink and downlink.

On the radio config page, there are a few settings that I’d change.

  • Enable auto contention
  • Set broadcast repeat count to 0
  • Set SM receive target level to -60

Is there any reason why you’re trying to use a 40MHz channel? You might want to try using a 20MHz channel and seeing if you have less issues with CBRS. You can check to see if the SM’s having grant issues by checking the AP’s Logs → CBRS Log. Select the SM, and then click save and it will refresh the page with that CBSD’s logs.

Is the SM having issues nNLOS?

Next time the SM is connected, please post a screen shot of the Tools → Link Status page. This will show the SM’s various signal levels and modulation from both perspectives.

2 Likes

I think Eric is on the right track, though one thing I noted was the frame size: 2.5ms

Do you have any other equipment in the area that could be using a different frame size? This is more important when transmitters are close to each other as raw rf power can desensitize a receiver regardless of the frequency transmitted and the receivers filters.

1 Like

The CBRS grants seem to be okay. But, I may be clueless. :slight_smile:

We’re using a 40MHz channel because we’re in a valley, well, several valleys. SAS thinks the whole band is pretty available. We’re trying to serve several customers at 100Mbps off the same tower/AP. Wider channels facilitate that goal.

I was seeing some probable interference on 3650 - 3700 ( the pre-SAS CBRS) I didn’t see anything in Spectrum Analyser. But my bandwidth test showed less than expected uplink speeds. There is one other WISP in the area who may still be using the pre-SAS CBRS frequencies and hardware. So I moved to another frequency used by an AP on a tower about 5 miles away, pointing into the same valley from the opposite direction using the same settings.

I think this subscriber has LoS, But I haven’t been there, yet.

SM tools Link Status


We only have one CBRS AP per tower so far.

Byvarea near a tower we refer to the ability for one ap to hear another AP. This is important as two that are not perfectly in sync will cause strange issues such as SMs dropping off for no reason.

1 Like

RF signals seem fine, Judging from the link capacity numbers I assume modulations levels are 64qam or higher. I would enable Signal to Noise Ratio Calculation during Link Test to see what the modulation percentages are. Next I would look at sync, is the AP generating or using an external source? If it’s external look at the AP Home>Event Log and see if it is losing the sync source. Also in AP Home>Sync Status can give you more information. Look for: Sync Pulse Status : Receiving Sync (100.0% Sync pulses received)

1 Like

So, with one AP per tower, we still need to spend extra on sync hardware since adding a GPS chip to the AP is cost prohibitive for a $3000-$6000 AP? Boss is already upset with how expensive these units are. Also not happy with the reliability issues that CBRS/SAS bring to it.

As long as the AP’s and clients can’t hear each other and/or use a large enough guard band between AP’s, you’re fine not using GPS sync.

1 Like

This is where an omni antenna shows its main problem, down tilt they usually dont have much of an electrical down tilt and you cant tilt them down either. With a sector or a horn you can down tilt the antenna at the cost of range to near eliminate hearing the other APs.

As Eric pointed out if the APs can not hear each other and you have a large enough guard band (5 to 10mhz is usually good) then no need to sync but if they can hear each other or someone elses radios then sync will be required. Thankfully you do not need to use Cambium’s expensive cmm units. The Cambium ugps or packet flux’s sync injector (get cambium sync not canopy sync) plus syncbox jr are compatible options that are both affordable. We use the packet flux solution exclusively now and do not have any sync problems.

Sync is probably the most misunderstood concepts, it ensures all of your radios transmit at the same time, in the same direction. This makes same tower colocation and in cell colocation easier to deal with since everything is transmitting at the same time. This also allows for frequency reuse if needed but its major selling point is when you have multiple APs an SM can hear, you can be assured that the signal level is actually what is displayed and your other APs or SMs are not producing interference.

Shuffling channels seems to be helping. The client has been online for almost two days now.

We’re discussing adding SyncBox Jr. Aux port version to each tower.

Just to ensure compatibility, I would email Packetflux with your hardware version and get them to send you the correct syncbox as there are a few different ones for the aux port. Specify uGPS replacement and they will set you up with the correct one.

1 Like