• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 55 subscribers
  • Views 847 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC2530: Network status: many to one route failure

Daniele Coati
Intellectual 270 points
Part Number: CC2530
Other Parts Discussed in Thread: Z-STACK, , Z-STACK-ARCHIVE, CC2652R, CC1352P, CC2538

Hi All,

I have a zigbee network with a coordinator, 20 routers (using zstack 3.0.1) and 5 end devices. The network is using many to one routing and source routing.

I am trying to understand some routing problems in the network.

For instance the end devices should send a report every 10 minutes to the coordinator, but the coordinator does not always receive them.

I tracked down the issue to routing failures reported by the routers by a "Network status: many to one route failure".

Attached you can find a sniffer trace of the situation, for example packet number 137820 is a report from the end device followed by a route failure.

Questions:

  1. What could cause this issue?
  2. Can someone explain to me why the route failure message contains as "network status destination address" the network address of the device sending the report?

trace.zip

  • 0
    TI__Guru**** 202266 points

    Hi Daniele,

    Your sniffer log implies 108 nodes connected, did you mean there are 5 end devices per router?  Is the ZC a CC2530 device?  What all changes have you made to the Stack configuration for both the ZC/ZR devices?  You can refer to Section 5.4 of the Z-Stack 3.0 Developer's Guide for more information on MTO Routing Protocol.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Intellectual 270 points

    Hi Ryan,

    there are 20 routers and 5 end device total, for some reason sometimes the sniffer report failures to decrypt messages and so ubiqua shows all these "fake" network addresses.

    No modifcation was made for the network layer on the routers, the coordinator has these defined:

    -DSRC_RTG_EXPIRY_TIME=255
-DCONCENTRATOR_ENABLE=TRUE
-DCONCENTRATOR_DISCOVERY_TIME=120
-DMAX_RTG_SRC_ENTRIES=60
-DCONCENTRATOR_ROUTE_CACHE=FALSE
-DDEF_NWK_RADIUS=15
-DREQUEST_RADIUS=8
-DROUTE_DISCOVERY_TIME=13
-DNWK_LINK_STATUS_PERIOD=60
-DMAX_NEIGHBOR_ENTRIES=15
    -DZDNWKMGR_MIN_TRANSMISSIONS=0

    I really can't understand these routing failures, any idea?

    Regards,

    Daniele

  • 0 in reply to Daniele Coati
    TI__Guru**** 202266 points

    Hello Daniele,

    It appears that the ZRs have too many neighbors in their Link Statuses as compared to the allowed MAX_NEIGHBOR_ENTRIES.  Perhaps they are missing the link status messages of other ZR devices that they have established routes with or have determined that the links are insufficient for stable packet transmissions.  I would recommend that you modify the ZR settings to compensate.

    It is clear that you are taking recommendations from SWRA427 but please be advised that this report used a Z-STACK-ARCHIVE solution.  Are you planning on further increasing the number of nodes in your network?  For Z-Stack 3.0 you will need to use a CC2538 or CC2652R/CC1352P/CC1352R1 for the ZC to properly store all TCLK table entries. https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/t/892515 

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Intellectual 270 points

    Hi Ryan,

    thanks for the feedback. I will try to test increasing the MAX_NEIGHBOR_ENTRIES and keep you updated.

    I am aware of the CC2530 limitations, in this specific case the coordinator is still running an older version of the stack (z-stack home 1.2.2).

    I have another question for you, but I am not really sure if it is related to the problem above.

    I noticed that in some rare cases a router will send a leave network message with rejoin equal to true to an end device; in z-stack what are the cases that trigger the router to send this type of message? Can this be related to the MAX_NEIGHBOR_ENTRIES value?

    I can provide another sniffer trace if necessary.

    Regards,

    Daniele

  • 0 in reply to Daniele Coati
    TI__Guru**** 202266 points

    Hi Daniele,

    Leave commands can be issued due to incorrect network security settings causing miscommunication, child aging (ZED has not updated since NWK_END_DEV_TIMEOUT_DEFAULT), a child communicating with a parent to which it is not associated, or the ZR has too many children directly connected (gNWK_MAX_SLEEPING_END_DEVICES).

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Intellectual 270 points

    Hi Ryan,

    this end device in particular (supplied from a third party) is sending a zcl report every 10 minutes but does not send any mac data request to its parent. When the parent router receives the first mac data request from the end device after a very long time it then reply with the leave message.

    Is my understanding correct? Only mac data requests are kept into consideration when aging a child?

    Regards,

    Daniele

  • 0 in reply to Daniele Coati
    TI__Guru**** 202266 points

    That is correct, this appears to be the issue.  You may need to consider setting zgChildAgingEnable to FALSE on your ZR.

    Regards,
    Ryan