This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Network Topology - Parent-Child Relationship Lost

Other Parts Discussed in Thread: Z-STACK

I've used the ZDO_IEEE_ADDR_RSP to generate the topology of the network.  It has worked fine, but I'm finding that after the network is running for several weeks (nodes leaving network and rejoining) that the discovery ends early.  The children of a node are not appearing in the AssocDevList.  I rewrote the routine to pull the short address from the database to pass to ZDO_IEEE_ADDR_REQ, rather than from the parents AssocDevList.  This allowed me to get a complete picture of the network, but its broken up into 7 or 8 mini-graphs.  Is there away to avoid the loss of the parent-child relationship?  Also is there a way to recover this information?

Also, I'm seeing some nodes have two or three parents?  Any suggestions for fixing this?


Thanks!

  • This also worries me .. It's possible that one day I might have 200+ nodes in my building ... is Z-Stack stable enough to do this?

    Z-Stack is golden certified so I'm assuming they have some pretty big nasty networks in the wild that are running successfully?

  • Rob,

    You've seen this as well with your network?  How many nodes (routers, end devices) are you currently running?

    Thanks.

  • Hi,

    I think that in your case there are no problems with the network.

    The inherent property of  ZigBee network is to route data between a source and a sink automatically. This means the network 'data' topology (from the data traveling point of view) changes from time to time due to the changes of external conditions. Given the wireless nature of ZigBee solution one can expect that this topology will change quite often.

    Subject to the network consisting of the routers only, the parent-child relationship doesn't matter for the data routing. So the 'parent-child-based topology' doesn't reflect current routes and corresponds to the moment of the network formation. As times goes by, both the short addresses and the parent-child relationships can change and to get the connected graph one need to be sure that these changes don't happen during the topology discovery procedure and that the corresponding information about every node is updated.

    Regards,

    Ilya

  • Ilya,

    Thank you for your response. Just to clarify.

    You stated:

    "As times goes by, both the short addresses and the parent-child relationships can change and to get the connected graph one need to be sure that these changes don't happen during the topology discovery procedure and that the corresponding information about every node is updated."

    So are you saying the topology discovery should only be generated at the formation of the network?   What if two months down the road, I decide to add additional nodes, and wish to see the topology?  Is there a means to have this "corresponding information about every node updated"?

    Thanks

  • Hi Michael,

    the topology discovery can be performed any time you need but some aspects should be taken into account.

    Let the network be COORD<-RouterA<-RouterB<-RouterC and the topology has been successfully discovered. Assume that at the one moment the RouterC due to some reasons restarted with clearing of the network state. In such a case it can connect to the RouterA directly (as a child) and change its network address. Therefore, if you try to get the information about the associated devices from the RouterB (say, by means of ZDO_IEEE_ADDR_RSP) there will be no RouterC in the list or, in some situations, there will be the old network address of the RouterC. The same procedure for the RouterA will give the required result, i.e. the current (valid) network address of the RouterC in the list. If the network consists of more nodes, the procedure ought to be repeated for all of them.

    It should be noted that to identify the RouterC one need to have the actual mapping between the MAC and the network address. As one of the possible mapping solutions, the usage of  ZDO_END_DEVICE_ANNCE_IND can be considered.

    Another point here is the network stability. If the network is large and some nodes are unstable (change the network state frequently), there is a probability that the topology discovery procedure will result in the non-connected graph.

    Regards,

    Ilya

  • Wow thanks for this post!  I'm now confident in the way I'm tracking the network because of your great example.

  • Ilya,

    Thank you so much for your response.  Initially the network was stable and the discovered network topology worked.  For a period of time during some testing routers were swapped, exchanged, or unstable.  With over 30 routers and using network topology discovery as described in TI's document, I would only see four of the routers.

    Since I had the actual mapping, as you described, between the MAC and the network address, I decided to use my table to discover the topology.  With this method I ended up with a topology that is a non-connected graph with some children even having multiple parents.  Below is an example with 11 nodes.

     :

    I now have the network back to stable state.  Do you know of a method or means to recover from this and restore the parent child relationship? Thanks.

  • Hi Michael,

    As no node can have multiple parents, the information is outdated somewhere. I'd recommend to try the ZDP_MgmtLqiReq()/ZDP_MgmtLqiRsp() commands to get the info about the relationships.

    Regards,

    Ilya