Contact us
Any question or remarks? Just write us a message!
A low-power radio does not automatically create a low-power mesh network.
Battery life in a wireless IoT system depends on far more than the power consumption of the transceiver itself. Devices may spend energy listening for traffic, searching for a network, forwarding packets, repeating failed transmissions, maintaining routes and downloading firmware.
As a result, a network that looks efficient in a small laboratory test can behave very differently after hundreds of devices are deployed in a real building, factory or outdoor installation.
This article explains what makes a mesh network truly low power, which factors have the greatest impact on energy consumption and how engineering teams can balance battery life with reliability, latency and scalability.
A low-power mesh network is a wireless network in which devices can communicate through multiple hops while keeping radio activity and energy consumption under control.
In a mesh topology, a device does not always need to reach the central gateway directly. Its data can travel through other devices:
sensor → intermediate node → gateway
This can extend network coverage and make it easier to connect devices in large or obstructed environments.
However, every additional communication activity consumes energy. A device may need to:
The goal of a low-power mesh network is therefore not simply to minimize transmission power.
It is to reduce the total amount of radio activity required to keep the network reliable and operational.
Battery-life estimates are often based on a simplified calculation:
battery capacity ÷ average current consumption
In practice, the average current depends on many variables that may change over time.
These include:
Two physically identical devices can have different battery life if one is located near the gateway and the other must forward traffic from several neighbouring nodes.
This is why battery life should be evaluated at the system level rather than only from a radio data sheet.
Transmitting a packet requires energy, but the duration of the transmission is usually short.
The total impact depends on:
A device that sends one short message every hour may consume very little energy. The same device sending frequent status reports, acknowledgements and routing information can have a very different power profile.
Listening can be as important as transmitting.
A device may need to keep its receiver active to detect:
If a device listens continuously, the receiver can dominate total power consumption.
Low-power protocols therefore use strategies such as duty cycling, scheduled receive windows and synchronized communication to keep the radio asleep whenever possible.
When a packet is lost, the device may need to send it again.
Packet loss can be caused by:
Retransmissions consume additional energy on both the sender and receiver side. In a multi-hop network, one failed packet can also create repeated activity across several intermediate nodes.
A network with low nominal traffic can therefore become power-hungry if communication is unreliable.
Mesh networks must determine how packets should travel through the network.
Routes may change when:
Frequent route discovery and maintenance create control traffic. In unstable networks, devices may spend significant energy searching for new paths rather than transmitting useful application data.
Some mesh devices act only as endpoints. Others also forward packets.
Forwarding increases network coverage, but it creates additional work for selected nodes.
A device positioned in a central part of the network may:
For battery-powered networks, routing design must avoid placing excessive forwarding load on a small group of devices.
Firmware updates can be among the largest data transfers performed by an embedded device.
Updating one device may be straightforward. Updating hundreds or thousands of devices across a low-bandwidth mesh network is much more demanding.
The network must manage:
An inefficient update mechanism can consume large amounts of energy and occupy the network for an extended period.
A device that loses connectivity may repeatedly scan channels or attempt to reconnect.
This can be especially costly for battery-powered devices.
Common causes include:
A device that spends most of its time searching for the network may drain its battery much faster than expected.
One of the most important differences between wireless network architectures is how devices access the radio channel.
In contention-based systems, devices attempt to transmit when they believe the channel is free. If several devices transmit at the same time, packets may collide and need to be repeated.
This approach can work well in small or lightly loaded networks. As traffic and device density increase, however, collisions and retries can become more frequent.
Scheduled communication takes a different approach.
Devices are assigned specific opportunities to transmit or receive. This reduces the need to compete randomly for access to the channel.
A more predictable schedule can help devices:
This does not mean that every scheduled network will automatically deliver the lowest possible energy consumption. Schedule design, traffic patterns and device roles still matter.
However, predictable access to the radio can make power consumption easier to control in dense networks.
Time-Slotted Channel Hopping, or TSCH, organizes communication into synchronized time slots.
During each slot, a device may:
Devices can therefore keep their radios asleep outside the communication periods assigned to them.
TSCH also changes radio channels according to a defined sequence. This channel hopping can reduce the impact of narrowband interference and improve resilience when individual channels are temporarily degraded.
The combination of synchronized slots and channel hopping can provide several advantages:
embeNET uses the TSCH mode of IEEE 802.15.4 as part of its 6TiSCH-compatible architecture. It is designed to support large wireless mesh networks while reducing congestion and coordinating communication between nodes.
Energy efficiency and reliability should not be treated as separate goals.
An unreliable network wastes energy.
Every failed transmission may require:
At the same time, reducing radio activity too aggressively may make the device slow to respond or unable to receive important commands.
The engineering challenge is therefore to find the correct balance between:
The right configuration depends on the application.
A sensor that reports once every hour can sleep for long periods.
An emergency lighting controller may need to receive commands quickly.
A vibration-monitoring device may generate bursts of data when an abnormal condition is detected.
A single low-power configuration will not suit all three cases.
As a mesh network grows, the relationship between device count and power consumption is not always linear.
Adding more nodes may increase:
The effect depends on network architecture.
A well-designed system should prevent every device from processing every message. It should also control multicast, routing and management traffic as the number of nodes grows.
When evaluating a low-power mesh network, ask:
A network that is efficient with 20 nodes may not remain efficient with 1,000.
Frequency choice also affects energy consumption.
The 2.4 GHz band offers:
However, it is also used by Wi-Fi, Bluetooth and other technologies, which may increase interference in busy environments.
Sub-GHz communication can offer:
This may reduce the number of hops or retransmissions required to reach a gateway.
However, sub-GHz systems may involve:
The best frequency depends on geography, device size, environment and traffic requirements.
The objective is not always to maximize range. It is to create stable links that reduce unnecessary retries and network recovery activity.
embeNET supports both 2.4 GHz and sub-GHz hardware platforms, allowing engineering teams to select the radio environment that best fits the application.
Firmware updates deserve separate consideration because they create unusual traffic.
Normal application messages may contain only a few bytes. A firmware image may contain tens or hundreds of kilobytes.
For a battery-powered device, receiving the image may require the radio to remain active much longer than during everyday operation.
At scale, update efficiency depends on:
A production-ready networking platform should treat firmware distribution as a core fleet-management function rather than as an afterthought.
embeNET includes automated firmware updates designed for large deployed networks, along with telemetry and diagnostic services that help operators monitor the state of connected devices.
Battery-life claims should always be examined in context.
Before selecting a technology, ask for information about the conditions under which measurements were performed.
Confirm:
Determine:
Test in conditions that reflect the real deployment:
Measure what happens when:
Average performance during ideal conditions is not enough.
Include firmware distribution in power testing.
A network may appear highly efficient during normal operation but create a major battery cost during updates.
Consider energy use across the entire device lifecycle:
Sleep current is important, but devices may spend more time awake than expected because of listening, retries or network maintenance.
Reducing transmit power can weaken links and create more retransmissions. A slightly stronger, reliable transmission may sometimes consume less total energy than several failed low-power attempts.
Shorter radio links may require less transmit power, but every hop creates another receive and transmit operation.
The correct number of hops depends on topology and link quality.
Mesh provides alternative paths, but routing and channel access still need to be designed properly.
A congested or unstable mesh can perform worse than a simple star network.
Long sleep periods can reduce energy use, but they may also increase response time.
Applications must define which is more important and how much delay is acceptable.
Low-power mesh is a strong candidate when:
Typical applications include:
A different technology may be more suitable when the application requires:
embeNET is a wireless mesh networking platform for professional and industrial IoT applications.
Its embedded Node stack provides IPv6 and UDP connectivity over a 6TiSCH-compatible architecture based on IEEE 802.15.4 TSCH.
The platform is designed to support networks ranging from dozens to more than 1,000 devices. It includes:
Because the networking layer is available across hardware from multiple semiconductor vendors, manufacturers can select platforms based on power, cost, availability and product requirements without tying the complete network architecture to one chip family.
Before choosing a low-power mesh network, evaluate:
The lowest-power radio is not necessarily part of the lowest-power network.
The most efficient system is usually the one that minimizes unnecessary communication while maintaining stable routes, predictable access to the radio and sufficient reliability for the application.
embeNET provides a production-ready networking layer for scalable, low-power industrial IoT systems.
Use synchronized TSCH communication, IPv6 networking, built-in diagnostics and large-scale firmware distribution without developing the complete wireless mesh infrastructure from scratch.
Any question or remarks? Just write us a message!
contact@embe.tech
Czarnowiejska 36/017, 30-054 Kraków
