Large ZigBee Networks and Source Routing
ZigBee Pro utilizes Ad hoc On-Demand Distance Vector ("AODV") for routing across the mesh network. In AODV, the network is silent until a connection is needed. At that point the network node that needs a connection broadcasts a request for connection. Other AODV nodes forward this message, and record the node that they heard it from, creating an explosion of temporary routes back to the needy node. When a node receives such a message and already has a route to the desired node, it sends a message backwards through a temporary route to the requesting node. The needy node then begins using the route that has the least number of hops through other nodes. Unused entries in the routing tables are recycled after a time. When a link fails, a routing error is passed back to a transmitting node, and the process repeats.
In applications where a device must transmit data to many remotes, AODV routing would require performing one route discovery for each destination device to establish a route. If there are more destination devices than there are routing table entries, established AODV routes would be overwritten with new routes, causing route discoveries to occur more regularly. This could result in larger packet delays and poor network performance. Utilizing many-to-one routing and source routing helps solve these problems.
It is generally recommended to use many-to-one routing when there are more than 40 nodes in a single PAN.
In networks where many devices must send data to a central collector or gateway device, AODV mesh routing requires significant overhead. If every device in the network had to discover a route before it could send data to the data collector, the network could easily become inundated with broadcast route discovery messages.
Many-to-one routing is an optimization for these kinds of networks. Rather than require each device to do its own route discovery, a single many-to-one broadcast transmission is sent from the data collector to establish reverse routes on all devices.
The many-to-one broadcast is a route request message with the target discovery address set to the address of the data collector. Devices that receive this route request create a reverse many-to-one routing table entry to create a path back to the data collector. The ZigBee stack on a device uses historical link quality information about each neighbor to select a reliable neighbor for the reverse route.
When a device sends data to a data collector, and it finds a many-to-one route in its routing table, it will transmit the data without performing a route discovery. The many-to-one route request should be sent periodically to update and refresh the reverse routes in the network. Applications that require multiple data collectors can also use many-to-one routing. If more than one data collector device sends a many-to-one broadcast, devices will create one reverse routing table entry for each collector.
In contrast to many-to-one routing that establishes routing paths from many devices to one data collector, source routing allows the collector to store and specify routes for many remotes. To use source routing on a network, many-to-one routes must first be established on the network from remote nodes to the central data collector.
Enabling many-to-one routing using an XBee-based central collector
Using many-to-one routing with an XBee-based central collector node is easy: the AR command is used to enable many-to-one broadcasting on a device. The AR command sets a time interval (measured in 10 second units) for sending the many to one broadcast transmission. Setting AR to 0xFF disables many-to-one broadcasting on the device. Setting AR to 0 will cause a device to immediately send a single a many-to-one broadcast.
Using Source Routing with XBee Serial API
In order to use source routing with the XBee Serial API, the following steps must be taken:
- To store source routes for remote nodes:
- Remote nodes must first send a unicast transmission to the central collector
- Upon receipt of a unicast, the XBee will emit a route record indicator frame (XBee API frame type 0xA1)
- The information from the route record frame must be interpreted and stored by your application for later use
- To transmit using a source route:
- Configure the XBee with the source route using Create Source Route (XBee API frame type 0x21)
- Transmit request (XBee API frame types 0x10 or 0x11)
- Interpretation of the Transmit Status (XBee API frame 0x8B)
When source routing is used, the 16-bit addresses in the source route are inserted into the RF payload space. This means the RF payload will be reduced by two bytes per intermediate hop. However, it is up to the user to account for the payload size reduction when using source routing. For example, if NP returns 84 bytes, and a source route must traverse 3 intermediate hops (3 16-bit addresses), the total number of bytes that can be sent in one RF packet is 78.
Using Source Routing with a ConnectPort Gateway
If many-to-one routing is enabled on the mesh network (i.e. the AR parameter is set to less than 0xFF on the gateway), the ConnectPort will automatically capture and automatically utilize source routes when transmitting to remote nodes. Simply address your transmissions as you would normally.
Because the handling of source routing is automatic when using a ConnectPort X gateway it can be difficult to determine what the maximum payload size should be. It is recommended to use the value returned from 'NP' less the maximum source routing overhead (10 hops, or 20 bytes).