Hello..
Can we tie a LUID to a specific Subscriber. I mean if the AP reboot, all the connected Subscribers are re assign to their existing LUID.
Riyaaz,
The LUID number that an SM is assigned is based on the order that the SM registers to the AP after it has been rebooted.
After the the SM has registered to an AP, it will have the same LUID until the AP is rebooted again.
Best,
Cambium Jonathan
I got the point. It would be helpful if we can have an option to tie the LUID with the subscriber MAC in futur software release. This is because when using an NMS to monitor the Received signal strength that an AP is receiving from its subscribers, it is basically done using LUID, but it tomorrow the AP reboot, for sure each SM will hv a different LUID based on the registration timing to the AP. Thus, this will lead to an erroneous plotting in the NMS.
example:
Lets say an AP is receiveing a signal level of -50 for SM1 and -70 for SM2
As I'm monitoring the RX signal from the AP, LUID2 will be SM1 and LUID3 will be SM2
Now:
Day 1 - SM1 got LUID 2 and SM2 got LUID 3 - the NMS plot the rssi graph appropriately. everything is fine, we got stable signals, life is good.
Day 2, for whatever reason the AP reboot - SM1 got LUID3 and SM2 got LUID2 - the operator came in and hv a look at the NMS and found SM1 signal buried to -70 and panic on board.
Where, in reality the Rx level are still the same, the data became erroneous because of LUID changed. Hope you got my point...
Any advice about this issue.
Riyaaz..
This is because when using an NMS to monitor the Received signal strength that an AP is receiving from its subscribers, it is basically done using LUID, but it tomorrow the AP reboot, for sure each SM will hv a different LUID based on the registration timing to the AP. Thus, this will lead to an erroneous plotting in the NMS.???
Can you configure your NMS to look at the ESN of the radio rather the LUID?
We have built some custom scripts to poll and track data for the PMP450 AP's. We've run into this situaion of the LUIDs shifting data around as well, and not keeping accurate historical data for any particular end-user. We have implemented a work around based on MAC, but it certainly would be a benefit to us and possibly others if we could statically assign LUIDs as mentioned above.
As a possible alternative, if the AP would simply keep the LUID associated with a particular MAC by storing that table on NVRAM, and then basing future LUID assignment on that table, or using next available when a new SM came online that wasn't in the table, that would help stabilize the data.