Multi-Network Timing Considerations#

Leaving the Always-On Network#

If the node participates in an always-on network as coordinator or router, it is important that the application does not poll and/or send data too frequently on the sleepy network(s). Every poll on the sleepy network(s) results in a temporary absence from the always-on network, which directly affects the throughput of the always-on network. This section provides the results of experimental measurements performed on Silicon Labs devices. This information will help the application designer to avoid throughput degradation on the always-on network. As we will show later in this section, a certain threshold in terms of “away time” from the always-on network should not be exceeded in order to maintain the throughput on the always-on network at an acceptable level.

The following table provides the average time a multi-network node spends during a complete network switch, and of typical polling and data-sending transactions of a sleepy end device. Data packets exchanged during the tests determining average time were frames 127 bytes long, or the highest size allowed by the 802.15.4 physical layer.

A complete network switch, which involves retuning the radio on a different channel with different transmission power, takes about 420 μs. During the network switch, the node will not be able to receive or transmit on any network.

It takes on average about 2.25 ms for a sleepy end device to poll a parent that does not have data to transmit to the child, while it takes about 8 ms to poll the parent and receive a data packet from the parent.

Similarly, it takes about 8.8 ms to send data to the parent and then poll the parent, without receiving a data packet. Finally, it takes about 14.5 ms to send data to the parent, poll for data, and receive a data packet from the parent.

Note: For each polling transaction, add the network switch time twice to the overall transaction time (the first switch to the sleepy network and second switch to the always on network).

To estimate how the throughput of the always-on network degrades as the traffic on the sleepy network increases, we deployed a three-node network as shown in the Implementation Examples figure, where the multi-network node is the coordinator of an HA network (Network A) and is joined as sleepy end device to an SE network (Network B).

Traffic was sent continuously on Network A so that maximum throughput is always achieved. Traffic on Network B was exchanged at different rates. All the data packets exchanged in these tests were encrypted at both network and APS layers and had an 82-byte payload (the maximum achievable payload with network and APS encryption for a single ZigBee fragment).

The figure below illustrates how the maximum achievable throughput on Network A degrades as the traffic on Network B increases. All the values are expressed as a fraction of the maximum throughput achieved when no traffic is exchanged on Network B (about 53.5 packets per second).

The interval between SED network activity in the following figure indicates how often the multi-network node leaves the always-on network to perform a data transaction on the sleepy network. In an SED data transaction, the multi-network node polls, the coordinator sends a data packet, and the multi-network node sends an APS acknowledgment to the coordinator.

We found the following results:

• By leaving the always-on network every 5 seconds, a multi-network node achieves a throughput of 99.8%,

• By leaving the always-on network every 2 seconds a multi-network node achieves a throughput of 99.0%,

• By leaving the always-on network every quarter of a second the throughput drops to about 91%.

Notice that these tests represent an average scenario where traffic is non-bursty, that is, every two subsequent data transactions on the sleepy network are well-spaced. Therefore, the multi-network node is always able to go back to the always-on network after one data transaction on the sleepy network. Other tests have shown that heavy bursts of outgoing traffic on the sleepy network can lead a multi- network node to spend longer time intervals on the sleepy network, which in turn can further reduce the throughput on the always-on network. For instance, exchanging the same amount of traffic as one data transaction every quarter of a second in a bursty fashion would further reduce the throughput to about 86.4%.

To summarize, traffic on the sleepy network directly affects the throughput of the always-on network. However, both the rate of such traffic and also its distribution in time are important. The application designer should take into account these results when defining the type and the amount of traffic that will be exchanged on the sleepy network.

Note: The application designer should keep the length of a single interval of time away from the always-on network as short as possible, by spacing polls and data sends on the sleepy network(s).

The multi-network application designer has full control of how long and how often a multi-network node leaves the always-on network for the sleepy network. A single network sleepy end device automatically polls again for data if the incoming packet from the parent has the frame pending bit set. However, if a multi-network node is also participating in an always-on network, the automatic poll is delayed by 100 ms.

Note: A multi-network node that participates in an always-on network and a sleepy network is guaranteed to switch back to the always- on network after one poll on the sleepy network. If the frame pending bit of the incoming packet is set, the node will poll again after 100 ms.

Some special operations can occasionally occur on the sleepy network that can cause a multi-network node to stay on the sleepy network for a prolonged time interval. We measured how throughput on the always-on network is affected during these special operations. Refer to the following table for more details.