Disconnects. Session timouts dependent on traffic load and LOS conditions

Products PMP
1

Who else is having trouble with PMP450 disconnects in NLOS conditions?

For the past year or so I have been troubleshooting disconnect issues with clients that are NLOS or with partial obstructions.  They tend to disconnect for 1 minute at a time multiple times per day if there is traffic on them.  On the AP, the reg counter increments.  the behavior is similar to locally ending a session that relys on a SM timeout.  It's as if the session locks up in some way and when the client times out, it attempts to connect again.  I'd like to note quickly, that I'm seeing this same behavior on all of my PTP450 links even though they are LOS, though different grades of LOS.  The issue appears worse with higher traffic loads on links that have greater fresnel interference.  Noise has a factor too, if it is present, but for now, I've tested in bands with -100dBm noise floors and confirmed that no other signals were present within 50Mhz.

I upgraded from PMP430 and PTP230.  These are non-MIMO versions of the 450 line, which the 450 line is based on.  They run in the same conditions without any disconnect issues.  The major difference between the 430 line and the 450 line being MIMO.

I've focused on a single case, which is a 3Ghz PMP 450 SM that is less than 1 mile from a 3Ghz 450 AP.  The signal travels through some trees for about 100ft.  The signal is -65dBm.  This is a good signal, but poor LOS.  I see no reason this should not run stable.

Cambium, is there a way to turn off MIMO?  This seems like the next logical troubleshooting step.  I know you will ask me to submit my CNUT caputers, but I've already had multiple cases about this issue over the past year.  It seems like I need to give more focus to the problem before any attention is paid to it.  You're only suggestion to me over the course of our 450 use has been to try the 13.4 beta.  You told me it addressed some disconnect issues.  It seemed to help!  But it didn't fix it completely.  Whatever you did to 13.4, you probably need to do more.  I think there is a modulation issue locking up sessions.  It has something to do with MIMO or maybe 256... I don't know.  Give me the ability to turn these things off and I can test.

2

Are you using PMP450 on 3.65? Are you seeing any LBT events in the LBT log?

3

Yes, I am using 3.65 gear, but have no LBT events.

I see similar issues with 5Ghz PTP450, 3Ghz PTP450, and 3Ghz PMP450.

The SMs log this:

02/05/2011 : 23:20:18 UTC : Event: SMSESFAIL, MsgType: OOS, NewState: OOSERVICE, Flag 0
02/05/2011 : 23:21:03 UTC : Event: SMSESACTIVATE, NewState: REGISTERING, Flag 0
02/05/2011 : 23:21:03 UTC : Event: SMAUTHENMSG, NewState: REGISTERING, Flag 0
02/05/2011 : 23:21:03 UTC : Event: SMSESINS, NewState: REGISTERED, Flag 16
02/05/2011 : 23:21:03 UTC : Event: SMAUTHORMSG, NewState: REGISTERED, Flag 0
repeated 2 times

On a PTP link, this is logged on the slave:

11/17/2015 : 03:48:15 UTC : Event: AUTHEN_RESET, NewState: IDLE, Flag 0
11/17/2015 : 03:48:34 UTC : Event: AUTHEN_REQ, NewState: AUTHENTICATING, Flag 0
11/17/2015 : 03:48:34 UTC : Event: AUTHEN_FAIL, NewState: IDLE, Flag 0
11/17/2015 : 03:48:47 UTC : Event: AUTHEN_REQ, NewState: AUTHENTICATING, Flag 0
11/17/2015 : 03:48:47 UTC : Event: AUTHEN_CHAL, NewState: AUTHENTICATING, Flag 0
11/17/2015 : 03:48:47 UTC : Event: AUTHEN_SUC, NewState: AUTHENTICATED, Flag 0

On PTP link, this is logged on the master:

11/17/2015 : 03:48:16 UTC : Event: AUTHEN_RESET, NewState: IDLE, Flag 0
11/17/2015 : 03:48:47 UTC : Event: AUTHEN_REQ, NewState: AUTHENTICATING, Flag 0
11/17/2015 : 03:48:47 UTC : Event: AUTHEN_SUC, NewState: AUTHENTICATED, Flag 0

4

We still have our entire 450 network on 13.2.1 and the 100 network on 13.1.3 (besides a few test sites here and there). I have many near-LOS SMs on both 3.6 and 5GHz. My house is on 3.6GHz w/ a reflector a mile away from the tower (sector is at 220 feet) and I have a large maple tree about 100 feet away from my SM directly in the path. It seems to hold up just fine. It can get a little bumpy when the wind is blowing the tree around a bit.

If you're trying to plow through a forest, I'm sorry, but it's just not going to happen. We tried it. Multiple trees especially when wet and blowing in the wind produced very unstable sessions like you describe.

On the main status page of problematic SMs, what does the Beacons % say? Any less than 90% or so will generally reveal that the SM isn't hearing all of the AP's management frames (like the beacon). SM says, well, I must've lost session, I'll re-register now. This is one of the reasons they gave us MIMO-A mode, and it certainly helps, but nothing is perfect.

5

Channel Bandwidth :     10.0 MHz
Cyclic Prefix :     1/16
Air Delay :     5100 ns, approximately 0.474 miles (2506 feet)
Receive Power :     -61.5 dBm
Signal Strength Ratio :     -1.0 dB B-A
Signal to Noise Ratio :     35 B / 34 A dB
Beacons :     100 %
Transmit Power :     21 dBm

The SNR sometimes drops to 24 of phase A and the Beacons sometimes reads 99%.  Of course, I have no idea what the readings would be when the session actually drops.  It can be hours between drops on this particular link.  It is plowing through trees for about 100ft.  I can barely see the tower through the branches though.

Running 13.4 on our 450 network (3Ghz and 5Ghz) and 11.2 on our 100 network (2.4Ghz and 900Mhz)

6

These disconnects are driving me nuts.  My AP has four SMs attached to it and I caught one of the SMs disconnecting.  It did it three times in a row.  Once for a minutes, again for only 15 seconds, then again for 30 seconds.

From the AP:

02/08/2011 : 13:49:36 UTC : Event: AUTHOR_REQ, NewState: AUTHORIZING, Flag 0
02/08/2011 : 13:49:36 UTC : Event: SET_PARAMS, NewState: AUTHORIZING, Flag 0
02/08/2011 : 13:49:36 UTC : Event: SEND_PARAMS, NewState: AUTHORIZING, Flag 0
02/08/2011 : 13:49:36 UTC : Event: AUTHOR_SUC, NewState: AUTHORIZED, Flag 0
02/08/2011 : 13:51:49 UTC : Event: AUTHOR_REQ, NewState: AUTHORIZED, Flag 1
02/08/2011 : 13:51:49 UTC : Event: SET_PARAMS, NewState: AUTHORIZED, Flag 0
02/08/2011 : 13:51:49 UTC : Event: SEND_PARAMS, NewState: AUTHORIZED, Flag 0
02/08/2011 : 13:51:49 UTC : Event: AUTHOR_SUC, NewState: AUTHORIZED, Flag 1
02/08/2011 : 13:54:46 UTC : Event: AUTHOR_REQ, NewState: AUTHORIZED, Flag 1
02/08/2011 : 13:54:46 UTC : Event: SET_PARAMS, NewState: AUTHORIZED, Flag 0
02/08/2011 : 13:54:46 UTC : Event: SEND_PARAMS, NewState: AUTHORIZED, Flag 0
02/08/2011 : 13:54:46 UTC : Event: AUTHOR_SUC, NewState: AUTHORIZED, Flag 1

I captured the home page of the SM just as it came back online and got this.  I'm not sure if its an indication of interference or just what the page might look like before it is connected to the AP.

Channel Bandwidth : 10.0 MHz 
Cyclic Prefix : 1/16 
Air Delay : 5000 ns, approximately 0.465 miles (2457 feet) 
Receive Power : -57.9 dBm 
Signal Strength Ratio : 2.0 dB B-A 
Signal to Noise Ratio : 12 dB MIMO-A 
Beacons : 0 % 
Transmit Power : 17 dBm 

After I refreshed, I got this:

Channel Bandwidth : 10.0 MHz 
Cyclic Prefix : 1/16 
Air Delay : 5000 ns, approximately 0.465 miles (2457 feet) 
Receive Power : -58.5 dBm 
Signal Strength Ratio : 1.0 dB B-A 
Signal to Noise Ratio : 36 B / 37 A dB 
Beacons : 100 % 
Transmit Power : 18 dBm 

You might think I just got a lot of noise for some reason, but I'm not sure how.  The other SMs on the AP did not disconnect.  There were three other SMs on this particular AP and they stayed online during this event.

Any ideas?  It's happening all over the place.  The SMs somehow lock up their sessions and then have to reconnect.  I've tried changing frequencies and verified through spectrum scans that the noise floor is flat.  There's nothing out there!

7

could the power adjustment be a hint?  I'm taking wild guesses.  Maybe I'll try setting the SM target level high enough that it doesn't trigger any changed on the SM and see what happens.

This was from the SM session log:

02/08/2011 : 13:49:15 UTC : Event: SMSESFAIL, MsgType: SMVCERR, NewState: OOSERVICE, Flag 205
02/08/2011 : 13:49:27 UTC : Event: SMSESACTIVATE, NewState: REGISTERING, Flag 0
02/08/2011 : 13:49:27 UTC : Event: SMSESINS, NewState: REGISTERED, Flag 13
02/08/2011 : 13:49:27 UTC : Event: SMAUTHORMSG, NewState: REGISTERED, Flag 0
repeated 2 times
02/08/2011 : 13:51:39 UTC : Event: SMSESFAIL, MsgType: OOS, NewState: OOSERVICE, Flag 0
02/08/2011 : 13:51:57 UTC : Event: SMSESACTIVATE, NewState: REGISTERING, Flag 0
02/08/2011 : 13:51:57 UTC : Event: SMSESINS, NewState: REGISTERED, Flag 14
02/08/2011 : 13:51:58 UTC : Event: SMAUTHORMSG, NewState: REGISTERED, Flag 0
repeated 2 times
02/08/2011 : 13:54:36 UTC : Event: SMSESFAIL, MsgType: OOS, NewState: OOSERVICE, Flag 0
02/08/2011 : 13:54:46 UTC : Event: SMSESACTIVATE, NewState: REGISTERING, Flag 0
02/08/2011 : 13:54:46 UTC : Event: SMSESINS, NewState: REGISTERED, Flag 13
02/08/2011 : 13:54:46 UTC : Event: SMAUTHORMSG, NewState: REGISTERED, Flag 0
repeated 2 times
02/08/2011 : 13:56:26 UTC : Event: SMSESFAIL, MsgType: SMVCERR, NewState: OOSERVICE, Flag 205
02/08/2011 : 13:56:34 UTC : Event: SMSESACTIVATE, NewState: REGISTERING, Flag 0
02/08/2011 : 13:56:34 UTC : Event: SMSESINS, NewState: REGISTERED, Flag 14
02/08/2011 : 13:56:34 UTC : Event: SMAUTHORMSG, NewState: REGISTERED, Flag 0
repeated 2 times

Power adjust log:

02/08/2011 : 13:47:22 UTC : Event: SMSESMSG, MsgType: PAREQTO, NewState: REGISTERED, Flag 0
02/08/2011 : 13:47:22 UTC : Event: SMSESMSG, MsgType: PASRSP, NewState: REGISTERED, Flag 2
02/08/2011 : 13:51:28 UTC : Event: SMSESMSG, MsgType: PAREQTO, NewState: REGISTERED, Flag 0
repeated 1 times
02/08/2011 : 13:53:56 UTC : Event: SMSESMSG, MsgType: PASRSP, NewState: REGISTERED, Flag -2
02/08/2011 : 13:58:35 UTC : Event: SMSESMSG, MsgType: PAREQTO, NewState: REGISTERED, Flag 0
02/08/2011 : 13:58:35 UTC : Event: SMSESMSG, MsgType: PASRSP, NewState: REGISTERED, Flag 2

8

Hi, Can you please try 14.1.1 build 8 open beta release recently and update if you still see the issue ? Thanks, Chitrang

9

I've been running 14.1.1 for three days now with no noticable difference.

37001 - LUID: 004 -55.6 (-59.5 B / -57.8 A):-1.7 Path B:QPSK:48% 16-QAM:34% 64-QAM:18%
Path A:QPSK:37% 16-QAM:33% 64-QAM:30%		 27 B / 26 A NA 8X/6X MIMO-B -54.5 (-57.0 B / -58.0 A):0.0 36 B / 38 A NA 8X/8X MIMO-B 3.485914e-05 20 2
10

Hi,
Can you post Event log as well.
are you using RADIUS authentication?

11

We are having the same issues with NLOS customers in Kentucky . We have been contact with Cambium sent logs multiple times downgraded firmware and we are still have issues .Have you had any luck getting these issues resolved. Can you email any fixes you might have found to work. Thanks . nmontgomery@teachky.org