Motivation

MTOR and source routing are required for operation of larger networks (see Advanced Essay on understanding network size.) Imagine a network like the one pictured here:

If we recall the discussion on route discovery and routing we can see two areas where the network will suffer under large load.

Note! In this diagram we introduce the “gateway” device — this is the device that has a connection to the outside world and is therefore the most likely destination for sensor readings and the source for control messages. Gateways will always be depicted in this way. The gateway may or may not be the ZC depending on the application configuration, so we do not always give it a ZC tag. The ZigBee term for this device is concentrator.

Twenty messages sent simultaneously through two intermediate devices

Bandwidth for route discovery

First is route discovery. In the standard method of route discovery, each of the cloud of ZigBee devices (which could be much larger than 20!) must separately discover a route to the gateway (A).

This consumes a huge amount of bandwidth and may be especially problematic if all devices in the network power on at once (in the case of a power failure, for example). It also unnecessarily limits the maximum size of the network.

Memory for outbound routes

Next, imagine that A must send configuration or control messages to each of its outlying devices. With the traditional routing method, this would require at least 20 separate routing table entries for A. B and C are also likely to have extreme demands on their routing tables as two devices between A and the outlying devices.

While routing table size may be increased to the limit of the device, it’s also clear that this places an extreme burden on intermediary devices and may create further bandwidth problems as the routing tables fill up and the network is forced to re-discover routes that could not be stored. Like the bandwidth problem, the memory problem also unnecessarily limits the maximum size of the network.

The Solution

The primary insight leading to MTOR is that the traffic pattern in this kind of network is not arbitrary — typically, traffic will flow from outlying devices to the gateway and back from the gateway to specific outlying devices. Most traffic is not sent between any two arbitrary devices in the network. This allows optimization of the two main types of traffic.

MTORR

The many to one route request is sent by the gateway at regular intervals. This special message is broadcast to the entire network, and each device uses it to store its next hop back to the gateway.

All outlying devices discover the route back to the gateway in a single broadcast — a bandwidth approximately constant with the size of the network!

If an outlying device needs to send a message to the gateway and it has not yet received an MTORR establishing the route, the application can either wait for the next MTORR (at an application-configurable interval) or it can elect to consume additional bandwidth and use the normal route discovery method.

In the case of route failure a few options are available: wait for automatic repair at the next MTORR broadcast interval, attempt to repair it through normal route discovery OR just send a broadcast to the entire network destined for the gateway. In all cases careful consideration should be given to avoid storming the network and causing all the same problems MTOR was designed to avoid! In most cases, waiting is the best choice, but if that does not work within the latency requirements, then the broadcast is probably the best choice, as a discovery is actually more costly than a broadcast anyway due to the return routing AND it is unclear how MTOR and regular routes will interact if they are both used in a system.

See also: http://portal.ember.com/node/2793 for information on how MTORs are actually created.

Source Routing

While the memory requirement for storing routes cannot be eliminated (unless you want a very limited functionality network!), it can be concentrated on the gateway device. In many applications this makes good sense, because the gateway device has additional resources for communicating with the outside world — also, there is only one gateway that requires added memory, so its additional cost can be spread out over the total investment.

As indicated above, messages sent to the gateway when using MTOR will store each intermediate device in the message body itself. This allows the gateway to store that route for later use. Devices along the way do not store any more information — and the route back to the gateway was already stored during the MTORR, making this very efficient.

When the gateway needs to send a message to the outlying device, it retrieves the route and sends a special message that contains its own route. The intermediate devices will read this self-contained route and send the message on to the next hop.

In the case of route failure, the gateway can wait until another incoming message arrives, refreshing the source route, or it can use the normal routing. It may even be worth considering sending a broadcast, since the overhead may be lower (if, for example, only a single packet needs to be sent).

Note! Packets sent using source routing have a smaller maximum packet size because the payload must also contain the route information. 2 bytes per hop plus fixed overhead is required. TBD: include fixed overhead amount for EmberZNet

Conclusion

MTOR is an important part of building larger networks – without its optimized use of bandwidth and memory, ZigBee networks would be forced to greatly restrict either network size or network traffic.