Contact us
Any question or remarks? Just write us a message!
Wireless mesh networks are often selected because they can extend coverage, route around obstacles and connect large numbers of devices.
But every additional node, hop and retransmission can affect response time.
This makes mesh network latency an important design parameter in industrial IoT, professional lighting, building automation and distributed sensing systems.
The challenge is not simply to achieve the lowest possible latency.
In many applications, the more important goal is to achieve latency that remains predictable as the network grows, traffic increases and radio conditions change.
This article explains what creates latency in wireless mesh networks, why response times often increase at scale and how network architecture can improve timing predictability.
Mesh network latency is the time required for data to travel from one device to another through a wireless mesh network.
A packet may travel directly to a gateway:
device → gateway
Or it may be forwarded through several intermediate devices:
device → node → node → gateway
Each stage adds processing, waiting and transmission time.
End-to-end latency may include:
In most low-power IoT systems, radio propagation itself contributes very little to the overall delay.
The largest delays usually come from waiting, contention, routing and failed transmissions.
A network may have an average latency of 100 milliseconds but occasionally take several seconds to deliver a packet.
For some applications, that variation is more problematic than the average itself.
Three metrics should therefore be considered.
The typical time required to deliver a packet.
This is useful for understanding general network performance, but it can hide occasional large delays.
The longest expected or measured delivery time.
This matters when the application must guarantee that a command or alert is delivered within a defined period.
The variation in latency between packets.
A network with an average latency of 100 milliseconds may behave very differently depending on whether packets consistently arrive between 90 and 110 milliseconds or fluctuate between 20 milliseconds and three seconds.
For synchronized systems, predictable timing can be more valuable than the lowest average result.
Many wireless networks use contention-based access.
Before transmitting, a device checks whether the radio channel appears to be free. If another device is already transmitting, it waits and tries again.
This approach is practical in small or lightly loaded networks.
As the number of devices and messages increases, several devices may attempt to communicate at similar times.
This can cause:
The network may perform well under normal traffic but experience large latency spikes during busy periods.
Every hop adds delay.
An intermediate node must:
The effect depends on the protocol and schedule.
A five-hop path does not always take exactly five times as long as a one-hop path, but longer routes generally create more opportunities for delays and failures.
Hop count is therefore an important factor when planning network topology.
Packets may need to be sent again when:
A retransmission adds at least one more transmission cycle.
In a multi-hop route, failure on one link can delay the entire end-to-end delivery.
If the network is congested, retransmissions also create additional traffic, increasing latency for other devices.
Mesh networks adapt when links or nodes become unavailable.
This resilience is one of their main advantages, but finding or activating an alternative route can take time.
Latency may temporarily increase when:
Frequent route changes can create unpredictable response times even when packets are eventually delivered successfully.
A network has limited radio capacity.
Application messages must share that capacity with:
When the network approaches its capacity limit, packets wait longer before they can be transmitted.
This is why latency should be tested under realistic peak traffic rather than only under normal average load.
Some applications need to send one command to many devices.
Examples include:
If group communication is implemented inefficiently, it can create large amounts of repeated traffic.
A command that appears to be one logical message may produce many individual transmissions across the network.
This can temporarily increase latency for both the group message and unrelated application traffic.
Low-power devices often keep their radios switched off for much of the time.
This reduces energy consumption but can increase latency.
A message may need to wait until the receiving device wakes up.
There is therefore a natural trade-off:
The correct balance depends on the application.
A temperature sensor may tolerate several seconds of delay.
A lighting controller or alarm-related device may need to respond much faster.
Firmware distribution can generate much more data than normal device operation.
A network that usually carries short sensor messages may suddenly need to distribute a large firmware image to hundreds of nodes.
Without traffic control, this can:
Maintenance traffic should therefore be scheduled and managed as part of the network architecture.
Adding more devices does not always increase latency immediately.
If traffic remains low and coverage improves, additional forwarding nodes may even create better routes.
Problems appear when the increase in device count also increases:
The relationship between network size and latency is therefore determined by traffic density, not only by the number of registered nodes.
A network of 1,000 devices sending one short message every hour may create less traffic than 100 devices exchanging data several times per second.
When evaluating scalability, engineering teams should ask:
Professional lighting is a good example of an application in which timing matters.
A building, tunnel or industrial site may contain hundreds or thousands of lights.
When a group command is sent, users expect the installation to respond as one system.
If devices react at visibly different times, the network may appear unreliable even if every command is eventually delivered.
Lighting applications may require:
In such systems, jitter can be particularly noticeable.
The goal is often not to make every packet arrive as fast as technically possible, but to make a large group of devices respond within a controlled and narrow time window.
Industrial monitoring systems often tolerate slightly higher latency than control systems, but timing still matters.
A sensor may need to report:
If the network becomes congested, critical information may be delayed behind routine telemetry.
A production-ready design should therefore distinguish between:
Traffic prioritization and scheduling can help ensure that important messages are not delayed by less critical communication.
Building automation combines many applications with different timing requirements.
For example:
Using one network for all of these applications requires careful traffic planning.
The system should define:
There is no universal answer.
Acceptable latency depends on the application and user expectation.
A simplified classification may look like this:
Suitable for:
Suitable for:
May be required for:
Low-power wireless mesh is not appropriate for every hard real-time control application.
Systems requiring extremely low and guaranteed response times may be better served by wired communication or specialized industrial wireless technologies.
The correct design starts with a clear timing budget rather than a general requirement for “low latency.”
Latency describes how long communication takes.
Determinism describes how predictable that time is.
A network may be fast on average but non-deterministic:
Another network may consistently deliver packets within 150–200 milliseconds.
For many industrial applications, the second result is more useful because the application can be designed around known behaviour.
Determinism is especially important for:
Scheduled wireless communication reduces random competition for the radio channel.
Instead of every node attempting to transmit whenever it has data, devices communicate during defined time slots.
This can reduce:
Time-Slotted Channel Hopping, or TSCH, combines time scheduling with channel hopping.
Devices are synchronized and communicate during assigned opportunities. Successive transmissions may use different radio channels.
This can improve resilience to interference and make network behaviour easier to control.
Scheduled communication does not eliminate latency.
A packet may still need to wait for its assigned slot, travel through multiple hops or be retransmitted.
The advantage is that delays can become more structured and predictable.
embeNET is a wireless mesh networking platform for professional and industrial IoT applications.
Its networking architecture is compatible with 6TiSCH and uses the TSCH mode of IEEE 802.15.4.
Communication is organized into synchronized time slots, which helps reduce collisions in dense networks and gives devices controlled access to the radio channel.
The platform is designed for networks ranging from dozens to more than 1,000 devices.
It provides:
These capabilities allow engineering teams to examine network behaviour and manage communication at a system level rather than treating each radio link independently.
embeNET also supports multiple 2.4 GHz and sub-GHz hardware platforms, enabling network architecture to be maintained across different product generations and radio environments.
Latency should be tested under conditions that reflect the final deployment.
A laboratory test with ten devices placed in the same room does not provide enough information for a network expected to support 1,000 nodes across a large site.
Measure one-hop, multi-hop and edge-of-network devices separately.
This helps identify whether latency increases gradually or whether specific routes create bottlenecks.
Generate realistic bursts:
Average traffic tests may hide the conditions that create the worst delays.
Test the network around:
A robust network should maintain acceptable performance when individual channels are degraded.
Disable forwarding nodes and observe:
Measure application latency while firmware is being distributed.
Normal network operation should not become unusable during maintenance.
Useful metrics include:
Averages alone can hide rare but important delays.
Review:
Sending less data can often improve performance more effectively than increasing radio speed.
Where possible, use multicast or controlled group delivery rather than sending identical commands separately to every device.
Poorly positioned nodes can create long or unstable routes.
Adding or relocating forwarding devices may reduce hop count and retransmissions.
Firmware updates, diagnostics and background telemetry should not block urgent application messages.
Better antenna design, frequency selection and device placement can reduce retries and improve timing.
In dense or time-sensitive networks, scheduled communication can reduce the unpredictable delays caused by contention.
Latency problems cannot always be reproduced in a laboratory.
Production telemetry should make it possible to identify:
Additional hops increase latency, but the result depends on scheduling, routing and link quality.
A stable three-hop route may perform better than an unreliable direct link requiring repeated transmissions.
Raw data rate is only one factor.
Channel access, contention, routing and retries often have a greater effect on small IoT packets.
Averages can hide extreme delays.
Percentiles and maximum latency provide a better view of user experience and application risk.
Some mesh architectures can support responsive applications, especially when communication is scheduled and traffic is controlled.
The required timing must still be validated for the specific application.
Device count matters, but traffic behaviour matters more.
A large quiet network may outperform a smaller network with frequent simultaneous transmissions.
Mesh network latency should be a major selection criterion when:
It may be less important when devices send infrequent, non-urgent telemetry.
The goal is not to select the network with the lowest number in an ideal benchmark.
The goal is to select a network whose timing remains acceptable under the real conditions of the deployment.
Before selecting a wireless mesh technology, define:
Then test those requirements at the planned network scale.
A network that responds quickly during a small demonstration may not remain predictable after hundreds of devices are installed.
embeNET provides a production-ready wireless mesh networking layer for industrial and professional IoT systems.
Its TSCH-based architecture coordinates access to the radio channel, supports synchronized communication and helps reduce the collisions and congestion that create unpredictable delays.
Build large IPv6 mesh networks with integrated diagnostics, firmware distribution and support for multiple hardware platforms.
Any question or remarks? Just write us a message!
contact@embe.tech
Czarnowiejska 36/017, 30-054 Kraków
