[Zigbee-mesh] How to initiate the route discovery manually?

[Tu Hoang]

Hi everyone,

I am making a zigbee mesh with just coordinator and routers only. I intended to have the mesh to cover a very large areas with nodes that can be moved (not frequently). I am using SDK4.1.0, for coordiantor , i uploaded the CLI example inside and for the router  i used the exact same example of lilght bulb with the only change is that i exclude every parts relating to notification led or button.

Tell my if i am wrong but from what i learn, when the nodes send a message to another node, without having the address in the routing table it will initalise the route discovery by (1) sending route request or (2) after some time out when it did not received a MAC ACK from the node it try to send to. My expectation is that i will work like a charm since it is almost the same as the example but it did not. It has a really annoying that even with the router is very far from the coordinator, even with very low LQI and miss a lot of MAC ACKs, it still persistently try to send to the coordinator and not every try to broadcast route requeset. And for the first condition to start a route discovery, when the router send route requests, the coordinator can definitely hear it (i have a sniffer just right by coorfinator side).

So my question is that i want to start the route discovery manually to have better control over the mesh. is there any way i can do that. If not, is there any solution for the route discovery. 

Thank you in advances,

Best regards,

Tu

[Marte Myrvold]

Hi Tu,

It is generally recommended not to move the devices around too much in Zigbee. They should be able to notice broken routes and repair them, but it is still best to place them where they are supposed to be from the beginning. However, I do not see why you should turn the coordinator off and restart it after the other devices has joined the network. I have not heard anything about this optimizing the network in our stack at least, and I cannot say I have seen anything about it in the general Zigbee specifications either. And as far as I understand, the mesh network should be formed when a device joins the network and is then added to the coordinator or routers neighbor table, so it is a part of the joining process.

As for your issue with the route discovery, I got an update from the Zigbee team today. They were able to reproduce your issue when using only a coordinator and some routers, and turning off one of the routers to simulate it moving out of range. What they saw was that despite many retries, just one ZCL command that does not reach the destination is not enough to trigger route discovery to search for a new path in the stack. This was observed by looking at the network traffic and the sequence numbers of the packets. However, when they continued sending packets, and the sequence number thus increased, it eventually sent the commands to trigger route discovery. So it seems like after enough packets without ACKs the node will initiate route discovery.

Best regards,

Marte

[Tu Hoang]

Hi Marte,

I am very happy to hear that your team can reproduce the issue i have. But I still have to ask for some more detail just to be sure.

So, when you wrote "when using only a coordinator and some routers, and turning off one of the routers to simulate it moving out of range." Does this mean turning off one router will have the same effects as moving it out of range. If yes, then can you explain why. Secondly, does it means that the sequence number of ZCL packet should be different from message to message in order to trigger route discovery? Then, in your experiment, do they use binding and configure report to send message or just make a custom user ZCL packet like me. Does this 2 methods have the same effect on creating route? And finally, If missing a number of ACKs from message will initiate route discovery, can i just have ZCL command sent at a more frequent interval to make the process faster? and what is your Zigbee team set up for doing the experiment

Anyway, by looking at your answer, i think that the hack that hubitat use have the same mechanism here. They turn off the coordinator to make sure that its routers not receive any ACK to initalize route request. And I think that the reason why i stil can not initialize route request is because routers still receive some ACK from the coordinator. May be this time i will try to have a more precise testing environment.

Thank you very much for your support, I will update if there is some progress in the re-test. You have been a great help to me.

Best regards,

Tu

[Marte Myrvold]

Hi Tu,

I am glad to help!

For the other devices in the network it will be the same, as turning it off or moving it out of range will make it unreachable. The other devices do not know whether it was turned off or moved away, only that they do not get any ACKs from it.

When you send a new message, the sequence number should increase. The stack will try to resend the packet, so if you look at the network traffic, you will see multiple packets with the same sequence number being sent. But in order to make the device initiate route discovery you will have to send multiple packets with different sequence numbers before it does so.

They used the CLI Agent to control the light bulb from the Light control example. So they sent a match_desc request to discover the bulb, then a simple_desc_req to discover the clusters of the bulb. After this they just sent a normal ZCL On/Off command (from the On/Off cluster) to the bulb multiple times. So it should be the same as when you are sending a custom ZCL packet.

Sending the command at a more frequent interval should make the process faster, as long as you do not send it too fast. Also remember that the stack will by itself try to resend the same packet if it does not get any ACK (without increasing the sequence number, as it is still the same packet being sent).

I have attached some screenshots of the network traffic capture of this behavior below.

The first picture is the first time the CLI Agent sends the On/Off command to the bulb, and you can see that it is being resent multiple times, as it does not receive an ACK. You can see they are the same packet, as they all have the same sequence number, which is 4.

Now we are at sequence number 12, so multiple packets have been sent without receiving ACK. So the CLI Agent realizes that the bulb is out of range, and it sends a route request to try to find the bulb (without success here as well, since the bulb is turned off).

Best regards,

Marte

[Tu Hoang]

Hi Marte,

I want to give you some update on this problem. So, this time, follow your instruction, i decided to be more patient with the route discover and yes, after 12 no-ACKs packets, the route discovery did happen. Each packets i wait for 20s to send so it is about 4 minutes. Not bad at all, isn't it.

But this time there is another problem when the router receive route reply there will be some packets sending through that route until the next link status sent. I check for the link status, it is only having 1 link to the node that reply the route request. I guess that the link status somehow reset the routing table or temperary routing table.  I am still using the custom user message. So, I capture the result and send it to you.

In my mind i have some suspection that need your help. Is there something wrong with the route request/ route reply in my capture because when i read the command option in replay, all of the bit is false. Or is it because that there is some link status message of the coordinator reaching the router without the sniffer sniffing so the routing table was update.

Thank you and please reply soon, here is the packet sniffer capture you can apply the filter (zbee_nwk.src == 0xf392) || (zbee_nwk.dst == 0xf392) to check the data. Also, the network key is 660413b435c99c87763e8bc10c7abc49. route_request_after_12_no_ack_packet. .pcapng

Best regards,

Tu

[Marte Myrvold]

Hi,

I have started looking at your sniffer capture, but I have not been able to figure out the problem yet, so I will keep looking. Is the problem the additional NWK addr req messages, the APS Acks, and the additional Route Requests before the Link Status message from the router?

Tu Hoang said:

Or is it because that there is some link status message of the coordinator reaching the router without the sniffer sniffing so the routing table was update.

The Coordinator should not receive any Link Status messages from the router if they are not in range of each other without going through other routers. This message is a one-hop broadcast message, so it will only be broadcasted to neighbors with a radius of 1. It will not be forwarded to other devices in the network.

Best regards,

Marte