Routing in ZigBee is automatically handled by the networking layer, and the application developer usually does not need to be concerned with its behavior. However, it is useful to have a feel for how the network behaves when a route needs to be discovered or repaired.

Broadcast messages

Broadcast messages don’t have any explicit routing, but we introduce them here because they are important to understanding the behavior of route discovery.

In this short example, the broadcast message is sent to every device in the network radiating out from the sender (A). Because this network is three hops from A to the outermost devices, the sequence of three snapshots shows the propagation of the message. Note that in a real system the transmission of each hop would not be synchronized in this fashion.

First broadcast

Second broadcast

Third broadcast

No network level acknowledgments are made, but each ZR passes it along to all neighbors with up to three retries (not pictured), virtually guaranteeing that all properly functioning devices receive it.

Note! as these messages impose a large bandwidth burden on the network, they should be used as little as possible during normal operation. The network layer limits the number of simultaneous broadcasts to 8 in an 8 second period. This is required so that ZRs can avoid repeating the same broadcast.

Route discovery

Route discovery is initiated when a unicast message is sent from one device to another and there is no pre-existing route. In this case, device A is sending a message to device C.

We assume that there is no existing route so the networking software will begin the process of route discovery. For simplicity, assume that the routing tables of all devices are blank:

Initial Routing Tables

Routing tables for A,B,C,D all blank.

Find the destination

A will broadcast a message to the entire network asking the device C to reply. This broadcast message also serves to establish a temporary route back to A, as each intermediate device records the device from which it received the message.

Routing table entries for C

Routes are updated on intermediate nodes — note that these are temporary entries that have a shorter lifetime than regular entries and are not intended for re-use.

Ember! Because A is a one-hop neighbor, B and D do not need to store routing information about it.

Destination	Next Hop
A	B

Note! C could have used either B or D as its next hop back to A. ZigBee leaves this choice to the implementation; Ember uses a weighting algorithm to choose the most apparently reliable next hop.

Destination replies to sender

When the message reaches device C, C will send a special unicast message (called a Route Response message) back to A using the temporary route constructed in step 1. This message is used by intermediate devices to establish a (permanent) route back to C.

Routing table entries for A

Destination	Next Hop
C	B

Ember! Because C is a one-hop neighbor, B does not need to store routing information about it. D is not involved in this part of the discovery process because it was not selected by A in the above step (see the explanatory note).

When the message reaches device A, the route discovery is complete and the new route can be used to send data messages from A to C.

ZigBee PRO behavior

ZigBee PRO networks will detect asymmetric RF links and avoid them during route discovery. This improves the reliability of the discovery process and the resulting routes.

ZigBee PRO introduces “Many To One Routing” – MTOR – and source routing behavior, useful for certain large networks. MTOR is discussed in the following section.

Unicast Messages

After route discovery, messages can be sent from A to C because A examines its routing table and discovers that the next hop is B.

Routes that have not been used within a certain timeout period (1 minute in EmberZNet 3.0 and later) are marked for re-use and new routes may then overwrite that memory location. In some cases a new route may be needed and one or more intermediate devices will not have an available routing table entry; in this case the message will be reported as undeliverable to the sending node. TBD: note degree of vendor-specific behavior here.

The application specifies if an end-to-end acknowledgement should be sent by the receiver (this is called an APS acknowledgement). If yes, the sender will be notified upon successful delivery of in the case of a timeout waiting for acknowledgement. In the case of a timeout, the route may need to be repaired.

Above: unicast message (green) with acknowledgement (blue).

Route repair

When a unicast message is sent with an acknowledgement requested, the sending device will be informed when the message is successfully delivered. If does not receive this acknowledgement, it can then take steps to repair the route.

Route repair follows exactly the same steps as route discovery, above, but the damaged node (B, in this case) does not participate, resulting in a different route choice.

The routing table for A is updated:

Destination	Next Hop
C	D

And the message is successfully delivered along the new path. In the case that no alternative path is available, the sender will be informed that the message could not be delivered. In EmberZNet PRO this is a 0×66 EMBER_DELIVERY_FAILED response.

Ember! Ember EmberZNet PRO will attempt to deliver a message again before performing the route repair. Route repair is performed automatically when EMBER_APS_OPTION_RETRY and EMBER_APS_OPTION_ENABLE_ROUTE_DISCOVERY are both set in the message options.