What is LoRaWAN and how does it work? Gateways, sensors and industrial use

LoRaWAN is an open wireless networking protocol that lets battery-powered sensors send small amounts of data over long distances using very little energy. It runs in unlicensed sub-GHz ISM bands (EU868 in Europe, US915 in North America), is standardized by the LoRa Alliance, and is one of the most widely used LPWAN (low-power wide-area network) technologies. In factories it is used to collect infrequent, small readings, such as temperature, meter pulses, levels and status, from places where running cable is impractical.

This guide explains how LoRaWAN works, what gateways and network servers do, the device classes, how to choose LoRaWAN sensors, how LoRaWAN compares with NB-IoT, Wi-Fi and 4G, and how to integrate it into an industrial data stack.

LoRa vs LoRaWAN

The two terms are often used interchangeably, but they describe different layers:

• LoRa (Long Range) is the physical layer. It defines how the radio signal is modulated using chirp spread spectrum (CSS). This modulation allows very weak signals to be decoded below the noise floor, which is where the long range and low power come from.
• LoRaWAN is the network (MAC) protocol that runs on top of LoRa. It defines how devices join the network, how data is encrypted, the roles of gateways and servers, the device classes, and how data rates are managed.

Put simply, LoRa is the radio and LoRaWAN is the rulebook. Because LoRaWAN is an open standard, sensors, gateways and server software from different vendors can interoperate.

How LoRaWAN works

LoRaWAN networks use a star-of-stars topology. Sensors do not talk to each other or form a mesh; they broadcast directly to gateways. A packet’s journey looks like this:

1. The end device takes a reading. A temperature sensor, for example, wakes up on schedule, measures, sends a few bytes of encrypted payload and goes back to sleep.
2. Gateways receive the packet. One or more gateways in range hear it. A gateway does not decode the payload; it forwards the packet along with signal metadata (RSSI, SNR).
3. The network server processes it. If several gateways forwarded the same packet, the network server deduplicates it, verifies the device identity and message integrity, and can send the device a data-rate adjustment.
4. The application server decodes it. The application-layer encryption is removed and a payload decoder turns raw bytes into meaningful values (e.g., 23.4 °C, 51% RH).
5. Data reaches the application. The result is typically forwarded over MQTT, HTTP or an integration to monitoring, alarming and reporting software or an industrial data platform.

Spreading factor and data rate

LoRa’s spreading factor (SF7 to SF12) trades range against data rate. A higher SF gives longer range and better building penetration, but the packet stays on air longer, which means a lower data rate and more energy per message. A lower SF is faster and more efficient at short range.

Adaptive data rate (ADR)

With ADR, the network server automatically sets each device’s spreading factor and transmit power based on the signal quality reaching the gateways. For stationary sensors ADR extends battery life and increases network capacity. Mobile devices usually need it configured with care.

Security

LoRaWAN protects data with AES-128 at two levels: a network session key verifies message integrity and device identity, and an application session key encrypts the payload end to end. Even the network server cannot read the content without the application key. Devices join the network in one of two ways: OTAA (Over-the-Air Activation), which derives fresh session keys at each join and is the recommended method, or ABP (Activation by Personalization), which hard-codes the keys into the device.

LoRaWAN device classes: A, B and C

LoRaWAN defines three classes based on when a device listens for downlink messages from the server:

Class	How it works	Power use	Typical use
A	Opens two short receive windows after each uplink, sleeps otherwise	Lowest	The vast majority of battery-powered sensors
B	Adds scheduled receive slots synchronized to a gateway beacon	Moderate	Devices that need commands at predictable intervals
C	Listens continuously except while transmitting	Highest	Mains-powered actuators and relay modules

Every LoRaWAN device must support Class A, and almost all industrial sensor applications run on it.

Choosing a LoRaWAN gateway

The gateway is the backbone of the network on site. Things to look at:

• Frequency plan. It must match your region, e.g., EU868 in Europe and Türkiye or US915 in the United States.
• Indoor or outdoor. Outdoor gateways need a rugged enclosure, an external antenna and surge protection. Inside a plant, steel structures, racking and machines affect the signal, so antenna placement matters as much as the gateway model.
• Backhaul. Ethernet, Wi-Fi or cellular. On a production network, wired Ethernet with PoE is usually the least troublesome.
• Packet forwarder and network server compatibility. The gateway must support a forwarding protocol compatible with the network server you plan to use, such as the open-source ChirpStack or The Things Stack.
• Embedded network server. Some gateways include one. It is handy for small deployments, but once you have several gateways or need high availability, a central network server is the better architecture.
• Coverage plan. How many gateways you need depends on the building, sensor locations and redundancy requirements. A site survey with real measurements beats trusting a datasheet range figure.

LoRaWAN sensor types in industrial settings

LoRaWAN sensors are built for small, infrequent readings. The use cases we see most often in plants:

Sensor type	Measures	Plant use
Temperature and humidity	Ambient temperature, relative humidity	Warehouses, cold rooms, raw-material storage, clean rooms
Pulse counter / meter reader	Water, gas, compressed-air meter pulses	Consumption tracking, leak detection, energy monitoring
Energy meter / current sensor	Current, power, energy	Utility equipment where cabling is difficult
Level sensor	Tank and silo levels	Raw material and chemical tank tracking
Vibration and temperature sensor	Summary vibration values (e.g., RMS), bearing temperature	Condition monitoring of motors, pumps and fans
Door/status contact	Open/closed, present/absent	Door monitoring, simple machine run status
Modbus-to-LoRaWAN converter	Modbus data from an existing device	Reading a remote device without cabling

Vibration sensors deserve a note. LoRaWAN’s data rate cannot carry continuous waveforms, so these sensors compute summary values on the device and send those. That is enough to trend auxiliary equipment, but detailed vibration analysis on critical machines calls for wired, high-sample-rate solutions. Our predictive maintenance page covers this in more depth.

LoRaWAN vs NB-IoT vs Wi-Fi vs 4G

LoRaWAN is not the only option. The right choice depends on how much data you send, how often, how the device is powered and who owns the infrastructure:

Feature	LoRaWAN	NB-IoT	Wi-Fi	4G / LTE
Spectrum	Unlicensed sub-GHz ISM	Carrier’s licensed LTE spectrum	Unlicensed 2.4 / 5 GHz	Carrier’s licensed spectrum
Range	Long (kilometer scale, depending on environment)	Long, depends on carrier coverage	Short (in-building)	Depends on carrier coverage
Data rate	Very low	Low	High	High
Power use	Very low, long battery operation	Low	High	High
Infrastructure ownership	Private network or operator/community network	Carrier	Your own network	Carrier
Per-device subscription	Not needed on a private network	SIM subscription	Not needed	SIM subscription
Indoor penetration	Good	Good	Moderate	Moderate to good
Best fit	Infrequent, small, battery-powered readings	Dispersed sites on carrier infrastructure	High bandwidth, mains-powered devices	Mobile assets, high data, remote sites

A practical rule: if the device has power and you can run Ethernet, wired always comes first. If the device runs on batteries, sends a small value every few minutes or hours, and cabling is hard, LoRaWAN is a strong candidate. NB-IoT suits dispersed sites with good carrier coverage, and 4G suits mobile assets that need more bandwidth.

Public vs private LoRaWAN networks

LoRaWAN can run on a public or community network operated by someone else, or on a private network you own. Public coverage varies widely by region. In factories the most common and most controlled approach is a private LoRaWAN network: gateways inside the plant, and the network server on the plant’s own server or in a controlled environment. Data stays on site, there are no per-device subscriptions, and the plant owns the network.

Regional rules matter too. Under EU868 (863–870 MHz), which applies in Europe and Türkiye, many sub-bands carry duty-cycle limits such as 1%, meaning a device may transmit only a small fraction of the time. That fits LoRaWAN’s design, but applications that want frequent updates must plan around it from the start.

Getting LoRaWAN data into your industrial data stack

The most neglected part of a LoRaWAN project is what happens after the sensor. Data that stays in a sensor vendor’s cloud dashboard cannot be combined with production data. A sound architecture:

1. The network server forwards decoded data over MQTT or HTTP to the plant’s data platform.
2. Each sensor is placed in the same naming structure as machine and line data (e.g., an ISA-95 hierarchy): which site, which area, which asset.
3. Data is stored in a historian and alarm rules are defined, for example a notification when a cold room leaves its temperature band.
4. Battery level, signal quality and last-seen time are monitored too, so sensors that go silent are noticed.

This puts wireless sensor data in the same Unified Namespace as PLC and CNC data, so energy, maintenance and quality reports draw from one source.

Common LoRaWAN mistakes

• Trusting datasheet range. Open-field figures do not hold inside a plant; steel and machinery change the picture. Don’t size the gateway count without a site survey.
• Using LoRaWAN for the wrong job. It is not suited to many-times-per-second data, control, or high-bandwidth applications.
• Setting uplink intervals too short. This drains batteries and runs into duty-cycle limits.
• Skipping payload decoders and the data model. Raw bytes and random device names make data impossible to report on.
• Not monitoring device health. Without battery and signal tracking, a sensor that stopped reporting weeks ago goes unnoticed.
• Leaving data in the vendor cloud. If sensor data does not reach the plant’s data platform, it cannot be correlated with anything else.

How VOLSOFT approaches LoRaWAN projects

VOLSOFT is an industrial software and integration engineering firm; we do not sell sensors or gateways. On LoRaWAN projects we select the network and sensors together with the customer, based on the use case and site conditions, and our job is to integrate that network and those sensors properly into the plant’s data infrastructure.

A typical project defines the use case and measurement points, selects suitable sensor and gateway types with the customer, configures the network server, and sets up payload decoders and the data model. The data then flows into Proxus, the industrial data platform our team develops and uses on every delivery. In Proxus, LoRaWAN data sits in the same Unified Namespace and historian as PLC, CNC and power meter data, and rules, alarms, dashboards and reports are built on that shared data. The platform runs on the customer’s own servers and buffers data when the network is down.

To assess where wireless sensors make sense in your plant, see our industrial IoT solutions page or contact us.

Summary

• LoRaWAN is an open, long-range, low-power wireless protocol for battery-powered sensors; LoRa is its physical layer.
• The network consists of end devices, gateways, a network server and an application server in a star-of-stars topology.
• Classes A, B and C define when a device listens for downlinks; most sensors are Class A.
• EU868 (863–870 MHz) applies in Europe and Türkiye; in factories, private networks are the common approach.
• LoRaWAN is strong for small, infrequent readings; the real value comes from combining that data with production data in one model.