Edge computing in LoRaWAN projects: why and when should you adopt it?
In a standard LoRaWAN architecture, sensors transmit their data to a gateway, which forwards it to the cloud for storage, analysis, and use. But as IoT projects grow in number and complexity, the demand for local data processing, closer to the ground, is increasing.
This is where edge computing comes in. In this article, we cover its main advantages and the use cases where this approach makes the most sense, to help you determine the most suitable solution for your project: should you deploy your LoRaWAN network with or without edge computing?
What is edge computing applied to LoRaWAN?
Edge computing, broadly speaking, consists of processing data as close to its source as possible, rather than routing everything to a centralized cloud.
In an IoT environment, this means processing can happen directly on the connected device or the gateway. In the latter case, the gateway moves beyond its traditional role as a radio bridge between sensors and a remote server: it embeds the LoRaWAN Network Server directly.
As the gateway has computing capabilities, it can process data locally and run application-level functions: generating alerts, making real-time decisions, triggering local actions…
Concrete example
A Kerlink gateway deployed on a water meter network can detect a consumption anomaly linked to a leak in real time, generate an alert and automatically trigger a corrective action, without waiting for remote cloud processing.
The advantages of edge computing for IoT
1. Lower infrastructure costs and a lighter digital footprint
The field feedback is clear: more than 90% of sensor-generated data goes unused.[1] Sending it all to the cloud means unnecessary traffic, storage, and cost.
Local processing filters data at the source, forwarding only what’s actually useful. This reduces:
- Cloud consumption: by shifting computing to the network edge, you reduce the volume of data that needs to be stored, processed, and historized in the cloud.
- Network consumption: On a cellular gateway where data transfer has a direct cost, local processing significantly cuts down on exchanges and on bills.
Good to know: local data processing is not particularly power-hungry. An edge gateway typically consumes only marginally more than a gateway used purely as a radio bridge.
2. Data sovereignty and security
In many industries, exposing business data to third-party cloud platforms is a real risk.
With edge computing, data is processed and stored on-site: it never travels through external infrastructure.
This architecture is a natural fit for environments with strict security requirements: defense, energy, sensitive facilities, air-gapped networks… It also helps address growing cybersecurity concerns by reducing the data exposure surface.
[1] 1 https://www.prnewswire.com/news-releases/ibm-connects-internet-of-things-to-the-enterprise-300058256.html
3. Faster deployment and simpler architecture
By embedding the LoRaWAN Network Server directly in the gateway, edge computing removes the intermediate layers that come with traditional IoT architectures. For small to mid-sized projects, there’s no need to set up and maintain a dedicated cloud infrastructure: the gateway itself becomes a fully self-contained processing node.
For integrators, this means shorter deployment timelines and a cleaner architecture, easier to maintain and to scale.
4. Responsiveness and service continuity
In many operational settings, a several-minute delay between event detection and alert delivery is simply not acceptable (industrial plants, energy distribution infrastructure, security systems…).
Edge computing enables near-instant response: the gateway detects, analyzes and acts on the spot, with no round trip to a remote server.
And if internet connectivity goes down (operator outage, planned maintenance, temporary dead zone), the edge gateway keeps running autonomously. Alerts are generated, local actions are executed, and data syncs back up once the connection is restored.
When is edge computing the right choice?
1. Isolated or hard-to-reach sites
Edge computing is often the preferred option when internet connectivity is absent, unreliable or prohibitively expensive: offshore oil platforms, mining sites, remote rural areas, deserts, islands…
On these sites, depending on a distant cloud to process data is a liability: any network outage can cut off alerts and bring operations to a halt. An edge gateway keeps running regardless.
This is exactly what Kerlink built the Wirnet iStation M2 for: an ultra-low-power outdoor gateway with built-in edge computing and solar compatibility for fully autonomous deployments. It also includes radio diagnostic tools which are a real asset when any on-site visit means a long, costly trip.
2. Small private LoRaWAN networks
Edge computing is a natural fit for smaller deployments: a commercial building, a logistics warehouse, a small industrial site, a residential property with energy or comfort sensors… In these setups, sensor counts are typically low and a single LoRaWAN gateway covers the whole site. Putting the intelligence in the gateway simplifies the architecture, streamlines deployment, and reduces total cost of ownership.
3. Smart building and local network integration
Smart building may be the use case where edge computing makes the most sense. In an intelligent building, data from LoRaWAN sensors often needs to talk to existing systems: BMS, HVAC, Modbus, BACnet…
In this type of configuration, edge computing makes it easier for the LoRaWAN network to communicate with the building’s local ecosystem, without relying on a cloud intermediary, and in a faster, simpler way to integrate.
To address this market, our Wirnet iFemtoCell gateway can embed Actility’s ThingPark All-in-One LNS and seamlessly connect sensors directly to building management systems.
This is a use case we’re following very closely at Kerlink, and one we’ll have news to share soon!
Standard gateway or edge gateway: how to choose?
The right choice depends on your deployment context and requirements.
Here are a few key reference points:
|
Criterion |
Standard gateway |
Edge gateway |
|
Network size |
Medium to large |
Small to medium |
|
Internet connectivity |
Reliable and permanent |
Intermittent or absent |
|
Acceptable latency |
Several seconds / minutes |
Near real-time required |
|
Data sovereignty |
Flexible |
Critical |
|
Integration with local systems |
Cloud |
Direct |
|
Infrastructure cost |
Higher |
Optimized |
|
Network redundancy |
Possible |
Single point |
A standard gateway remains the right choice for large public or private networks with stable connectivity, an existing cloud platform, and a high volume of sensors to manage centrally. Centralizing data processing enables a level of global supervision that’s hard to match with edge.
In practice, the two approaches aren’t mutually exclusive. Hybrid deployments are viable: edge gateways for isolated or sensitive sites, centralized cloud supervision for better-connected ones. What matters is matching the architecture to the real constraints on the ground.
Conclusion
Edge computing is gradually redefining what a LoRaWAN gateway is: no longer just a radio bridge, but an intelligent node capable of processing, deciding and acting locally. Responsiveness, data sovereignty, architectural simplicity… The benefits are tangible and address real operational challenges.
That said, edge doesn’t suit every situation. The choice between a standard gateway and an edge gateway comes down to several factors: network size, connectivity quality, operational requirements, etc.
At Kerlink, we build LoRaWAN gateways for both approaches, backed by field expertise earned on some of the most demanding deployments. Our team is here to help you find the right fit for your project.