Automatic link failure detection methods in ZigBee networks

Question

Given a ZigBee mesh network with several nodes in it. There are established links between each node via router nodes.

If Node A wants to send a message to Node Z for the first time then Node A must perform a Route Discovery to determine which intermediate nodes will forward its message.

The Route Discovery mechanism is described here. According to it the route with the lowest cost will be stored in a Routing Tables of the nodes.

So far everything is fine, every node knows what to do, they can reach each other.

---

Now, an intermediate node, between Node A and Node B breaks down, so the currently stored route becomes unusable.

What happens in this case? I imagine that when Node A wants to send a message, it will travel all the way to the broken link where it will get stuck. The last node in the route will send back a message about the failure which will trigger a new Route Discovery by Node A, then a new route will be found and everything will be alright again.

It is generally fine (given I was correct); the network recovers. But I am wondering if there are any algorithms or methods that provide a network monitoring feature which continuously checks the state of the links presented in the Routing Tables. So Node A can be notified about the failure before it wants to send another message to Node Z, and instead of running into a dead end, it can start with a Route Discovery at once. So basically what I'm thinking of is a service which periodically checks the links.

---

I understand that as ZigBee is usually used on battery powered, low-power devices such a mechanism would be not energy efficient.

So in general what are now the most effective link failure detecting mechanisms that can be used in a low-power, wireless sensor network, especially in a ZigBee mesh network?

Answer 1

From what I've found, it seems that some implementations (e.g. TI's Z-STACK) recommend refreshing the routing table every so often to avoid 'dead' nodes:

Yes, I waited 5 to 10 minutes. What is "some time"? I have seen cases where it takes a few minutes to recover. For example, if I cycle power on the gateway, it takes maybe a minute or two for the closest nodes to connect, then another minute or two for each successive level. But I waited much longer than this for the mesh to recover from this routing change.

---

Yes, it might takes up to many minutes. So, if you want 5 or minutes, will your device come back? It is recommend to call NLME_RouteDiscoveryRequest() periodically to maintain the routing table.

You can read more about what NLME_RouteDiscoveryRequest() does in the developer guide (see page 11/12):

The following figure shows an example of the many-to-one route discovery procedure. To initiate many-to-one route discovery, the concentrator broadcast a many-to-one route request to the entire network. Upon receipt of the route request, every device adds a route table entry for the concentrator and stores the one hop neighbor that relays the request as the next hop address. No route reply will be generated.

Many-to-one route request command is similar to unicast route request command with same command ID and payload frame format. The option field in route request is many-to-one and the destination address is 0xFFFC. The following Z-Stack API can be used for the concentrator to send out many-to-one route request. Please refer to the ZStack API documentation for detailed usage about this API.

ZStatus_t NLME_RouteDiscoveryRequest( uint16 DstAddress, byte options, uint8 radius )

Fault Tolerance in ZigBee Wireless Sensor Networks is an interesting paper with some more information about how ZigBee networks tolerate node failure. It appears that the implementation used there reconstructed the network when one of the nodes was removed (the exact method of this is not clear, unfortunately), so that the malfunctioning node is no longer included in the mesh. In some cases, this led to sensors becoming 'orphaned' before requesting to rejoin the mesh network via a different route.

In summary, from the resources I've found: it depends on your implementation, but most will re-evaluate the routing table reasonably frequently to avoid broken nodes from harming the network. I suspect you'll be able to get a more accurate response if you ask the vendor of your specific ZigBee implementation, since the exact operation will vary.