(BeeStack) Link Status Messages at ZEDs break Neighbour Table?

[leper]

Hi All,

We have recently started adding more routers to our ZigBee networks and we noticed a degradation in performance of our ZEDs when we increased the router population over a certain size. What we have found is that link status messages from routers are causing ZEDs to add the origin router to their neighbour table - if the number of routers ever exceeds the size of the neighbour table, the ZED starts overwriting old NT entries causing the network to fall over.

There might be some elusive setting in BeeStack that is causing the ZED to process link status messages; we would expect that the default behaviour should be to ignore them? We're using BeeStack 2.0.0.

Thanks,

Tim

[leper]

The problem seems to be that the parent is not being correctly marked as a parent in the ZED's neighbour table (it gets marked as a sibling instead), meaning that the entry for the parent can be overwritten. We've found that setting mDefaultReuseAddressPolicy_c to TRUE in the End Device seems to mitigate the problem initially (i.e. the parent is marked with the correct relationship when it is joined for the first time), but when we turn the original parent off and force the ZED to do a NWK Rejoin it will change over to a new parent and mark this new parent as a 'sibling' in the NT. From then onwards we get the same problem where the parent entry in the NT (the one that is incorrectly listed as a sibling) is overwritten by incoming Link Status messages from neighbouring routers.

We think we can get around this by manually modifying the parent's NT entry to be a parent if we observe the NT change - that might come with its own baggage but at least it's a possible way forward.

This also makes us wonder about the Freescale ZED implementation and orphan rejoining (which we are not using at the moment) - we've never been able to work out what orphan rejoining is for or how it works ... or why FS implemented this at all. But given that the ZED maintains a list of parent candidates in its neighbour table (using Link Status messages), is it the case that orphan rejoin uses those existing entries without doing a scan, and that's what makes it useful?

[Wlodek_D_]

Hello Tim Warren,

Had your issue got resolved? If yes, we are going to close the discussion in 3 days. If you still need help, please feel free to reply with an update to this discussion.

Thanks,

Wlodek_D.