Network Latency#

Methodology#

The goal of the approach presented here is to provide meaningful metrics that match real use-case scenarios, and to offer a method for comparing Z-Wave and Z-Wave Long Range (LR) performance. Z-Wave uses a standardized message format called Command Classes. From a latency perspective, the most important types of commands are Set, Get and Report. The Set command is used to control devices, while the Get command requests the current state of a device, which is provided by a Report command. Depending on the network architecture, sending these commands can result in longer and more complex message sequences, including routing and acknowledgment mechanisms. However, the latency of these commands reflects the communication latency from the application's perspective. There are specific command classes for a wide variety of use-cases such as lamps, sensors, door locks and others.

In these measurements, the Binary Switch Command Class was chosen as a performance indicator for the command types mentioned above. In all cases, S2 encapsulation was used, which ensures the highest level of secure communication.

Binary Switch Command Class#

The Binary Switch Command Class is used to control the on/off state of supporting nodes, for example, a smart switch or a simple smart bulb. Being one of the simplest command classes, it is suitable for measuring and comparing Z-Wave network performance. The structure of the three commands for this command class can be seen below:

Binary Switch Set Command:

Binary Switch Get Command:

Binary Switch Report Command:

Latency of set Command#

One-way latency is an important quality metric of an IoT protocol, as it represents the responsiveness of the network. When a user presses a light switch, the delay until the light bulb turns on corresponds to the one-way latency. Similarly, in a smoke detection scenario, one-way latency corresponds to the time needed for the alarm message to reach the gateway or associated safety devices in the network. The Binary Switch Set command is a good performance indicator for one-way latency in Z-Wave network. As mentioned earlier, a typical network includes a gateway that interacts with the Z-Wave network via a Serial API controller. In the measured scenario, the gateway decides to turn on the end device and sends out the corresponding API command. Latency is defined as the elapsed time between the beginning of the Serial API frame and the moment the message reaches the application layer, allowing the end device to switch. The frame acknowledging the command is not included in this measurement, as it does not impact user experience.

Binary Switch Set Command:

Latency of get Command#

Round-trip latency is another important metric of an IoT protocol, representing the time needed to poll information from end devices - for example, to read the status of a sensor.

The Binary Switch Get latency is a good performance indicator for round-trip latency, as upon receiving a Get command, the end device responds with a Report frame. In this scenario, the round-trip latency of a Binary Switch Get command is measured. Latency is defined as the elapsed time between the start of the outbound Serial API frame and the end of the received (inbound) Serial API frame containing the report from the end device.

Binary Switch Get Command:

Measurement Results#

Always Listening Device#

As expected, using more hops or lower data rates results in increased latency. For one-way latency, all test scenarios perform below 200 ms, which is considered ideal for user interaction–related use cases. For round-trip latency, this threshold is maintained only at the higher data rates. The data demonstrates that Z-Wave Long Range can achieve consistently low latency by using a star network topology that removes the need for multi-hop routing and its associated delays.

Z-Wave Long Range and classic 100 kbps* modes use a 40-byte preamble, while classic 40 kbps and 9.6 kbps modes use a shorter 10-byte preamble for singlecast messages. As a result, for small payloads, such as Binary Set/Get commands used in these tests, the performance of 100 kbps and 40 kbps modes can be similar, since the shorter preamble compensates for the lower data rate.

*In the case of classic Z-Wave, this applies to channel configuration 2, which is used in most regions (EU, US, India, China). For more information, consult the official ITU-T G.9959 specification.

Frequently Listening Device#

*For details on adding a Command Class to an application, see How to Implement a New Command Class.

For frequently listening devices, classic Z-Wave maintains lower latency at 250 ms wake-up intervals, whereas Z-Wave Long Range (LR) performs better at 1000 ms intervals. According to the specification, a transmitting node must attempt three normal singlecast transmissions before switching to beaming. Therefore, the measured latency includes the accumulated delay from these three transmission attempts.

The measurements highlight the difference between the classic and LR beaming techniques. Classic Z-Wave uses continuous beams that match the wake-up interval of the frequently listening (FL) device, ensuring the device wakes up by the end of the beam transmission. This means the latency will always be at least the duration of the wake-up interval. In contrast, Z-Wave Long Range uses fragmented beams, where each fragment has a statistical chance of waking up the end device. Because of this probabilistic behavior, the variance in latency is higher for LR, as seen in the 99th percentile results. However, fragmented beaming allows other devices to communicate between beam fragments, whereas continuous beams completely occupy the channel for the entire beam duration.