Expanding industrial monitoring in an existing manufacturing plant is not always straightforward. New communication cables can be expensive or impractical to install, especially when production must continue without interruption. The challenge is to collect additional data from machines and sensors without modifying the existing infrastructure or interfering with daily operations.
A hybrid LoRaWAN network offers a practical alternative by combining native LoRaWAN sensors with conventional wired sensors connected through local converters. The entire solution operates within a separate, secure network, isolated from the plant's existing operational technology (OT) infrastructure.
This article explores the architecture of such a system, its key components, and the security mechanisms that enable independent industrial monitoring without extensive cabling or changes to existing production control systems.
Why LoRaWAN makes sense for industrial monitoring
LoRaWAN (Long Range Wide Area Network) is a wireless communication protocol designed to transmit small amounts of data over relatively long distances while keeping power consumption low. Unlike conventional wireless technologies focused on high data rates, LoRaWAN is optimized for periodic measurements, status updates, and event-based communication.
These characteristics make it particularly useful in manufacturing environments where sensors may be distributed across production areas, often far from existing communication infrastructure. Battery-powered devices can operate without dedicated power connections, while gateways collect transmissions from multiple sensors.
However, LoRaWAN is not intended to replace industrial Ethernet or real-time control networks. Its asynchronous communication model makes it better suited to monitoring than to time-critical automation. Typical applications include temperature measurements, vibration indicators, equipment status, energy monitoring, and threshold notifications.
The network should transmit information that is useful for monitoring rather than continuous streams of raw data. For example, a LoRaWAN vibration sensor, such as the Advantech WISE-2410, can analyze measurements locally and send selected indicators instead of transmitting the complete vibration signal. Such sensors typically wake up at configured intervals (for example, every 15 minutes), record a short measurement sample, calculate indicators such as RMS velocity, peak acceleration or kurtosis, transmit them, and return to sleep. The result is a periodic snapshot of machine condition rather than continuous analysis, so short transient events between measurements may not be captured. These data are well suited to trend-based condition monitoring, while detailed fault diagnosis typically requires higher-resolution or continuous measurement.
This approach reduces radio traffic and energy consumption while keeping the monitoring system focused on its primary task: collecting operational data without becoming part of the production control process.
A hybrid architecture: combining wireless and wired sensors
One limitation of a purely wireless monitoring system is the availability of suitable sensors. Although many industrial measurements can be performed using devices with integrated LoRaWAN connectivity, specialized applications may require conventional wired sensors.
A hybrid architecture addresses this limitation by supporting two types of measurement devices.
Native LoRaWAN sensors
The first group consists of sensors with built-in LoRaWAN communication. These devices combine measurement, local processing, and wireless transmission in a single unit.
Depending on monitoring requirements, they may measure temperature, humidity, vibration, energy consumption (for example, cumulative meter readings), or other operating parameters. They are particularly useful in locations where communication cabling is unavailable and battery-powered operation is desirable.
Most battery-powered LoRaWAN sensors operate in Class A, the most energy-efficient device class. They initiate communication by sending an uplink message and open short reception windows afterward. Other device classes provide greater downlink availability but typically require more energy.
The choice depends on the measurement frequency, reporting requirements, available power, and operating conditions.
Conventional wired sensors with LoRaWAN converters
The second group consists of conventional industrial sensors connected to LoRaWAN converters through short wired connections.
A pressure sensor, proximity switch, ultrasonic sensor, or other industrial measuring device can provide a signal to a nearby converter. The converter reads the signal and transmits the relevant information over LoRaWAN.
Depending on the converter model, supported interfaces may include 4–20 mA, 0–10 V, digital or pulse inputs, and RS-485/Modbus RTU. The power requirements of both the sensor and the converter must be assessed separately from wireless connectivity.
This arrangement allows the monitoring system to use specialized sensors without extending communication cables across the production facility. Wiring remains local to the measurement point, while the connection to the central infrastructure is wireless.
The proposed architecture also avoids interference with existing machine control circuits. Wired sensors are dedicated to the new monitoring system rather than connected to operational PLC inputs or industrial communication buses.
Importantly, the architecture is not dependent on equipment from a particular manufacturer. Sensors, converters, and gateways can be selected from different vendors, provided their interfaces, communication protocols, and security capabilities are compatible. Multi-vendor integration also requires compatible LoRaWAN versions and regional settings, appropriate device profiles, and payload decoders for each sensor or converter.
Keeping the monitoring network separate from existing OT
A key requirement of the proposed architecture is complete separation from the plant's existing operational technology network.
Rather than connecting additional monitoring devices to industrial Ethernet switches or production controllers, the solution uses its own communication infrastructure. This includes LoRaWAN gateways, dedicated network connections, local servers, and monitoring applications.
The two networks operate independently, without routing or bridging between them. The monitoring system does not communicate with production PLCs, access existing industrial fieldbuses, or require modifications to automation software.
Maintaining separation also requires controlled administration, maintenance, software-update and data-export procedures, with no unintended connections to the production-control network. Service laptops must not bridge the two environments.
This separation has two important consequences.
First, deploying the monitoring system does not require changes to the production network configuration. Existing controllers, communication protocols, and control applications remain unaffected.
Second, the proposed architecture introduces no monitoring-network dependency into machine control. A sensor or gateway failure may interrupt data collection, while the existing control systems continue to operate independently.
The architecture also keeps collected measurements within the dedicated infrastructure. Data can be processed and visualized locally without relying on external cloud services or establishing connections to the plant's production systems.
Wireless communication reduces long communication-cable runs; local sensor wiring, converter power supplies, and a dedicated gateway backhaul may still be required. Gateways also require power. Their connections to the local server environment form a limited, dedicated network backbone rather than extensive cabling to individual sensors.
Key components of the LoRaWAN infrastructure
The proposed network follows the LoRaWAN star-of-stars architecture. End devices communicate directly with gateways, which forward received messages to a central network server.
Each component performs a specific function, from collecting measurements to managing communication and presenting data to users.
LoRaWAN gateways
Gateways form the connection between wireless sensors and the wired backbone of the monitoring network.
Their primary role is to receive radio transmissions from end devices and forward them to the LoRaWAN Network Server (LNS). They do not interpret measurement values or decrypt application data.
Industrial gateways are available in various configurations, including indoor and outdoor models. The appropriate device depends on environmental conditions, power availability, required radio capacity, and compatibility with the selected network server.
To improve availability, the proposed architecture assumes overlapping gateway coverage. A single message may be received by more than one gateway, allowing the network server to remove duplicates and reducing dependence on an individual reception point.
LoRaWAN network server and ChirpStack
The LoRaWAN Network Server manages communication between end devices and the application layer.
Its responsibilities include validating incoming messages, removing duplicates, managing connected devices, handling downlink traffic, and controlling radio parameters through mechanisms such as Adaptive Data Rate (ADR).
For this architecture, ChirpStack is proposed as the central LoRaWAN platform. As an open-source network server, it supports private LoRaWAN deployments and provides interfaces for managing devices, gateways, and integrations. In the separated-key configuration, a separate monitoring application—not ChirpStack—decrypts the application payload.
ChirpStack can operate on a local server within the dedicated monitoring network, keeping network management and communication under the plant operator's control.
Gateway traffic reaches ChirpStack through an MQTT broker, using either Gateway Bridge or an MQTT-capable forwarder. MQTT can also be used to deliver device data to other local software components.
Centralizing network management simplifies administration and supports the use of compatible hardware from different manufacturers.
Application layer and data visualization
In the separated-key configuration, the application first decrypts the payload using AppSKey and then applies the appropriate device-specific decoder to convert it into measurement values.
Depending on the monitoring requirements, the application can display current values, historical measurements, device status, and notifications when defined thresholds are exceeded. The application should also flag stale measurements and notify users when a device has not reported within its expected interval.
For example, temperature readings collected from different production areas can be presented through a common interface, regardless of whether they originate from native LoRaWAN sensors or conventional sensors connected through converters.
This provides a consistent monitoring environment without requiring direct access to existing production control systems.
The application remains part of the isolated network. Its role is limited to monitoring, analysis, and reporting rather than controlling equipment. Access for users outside the monitoring network—for example, from the plant’s office IT network—must be designed explicitly, for instance through dedicated workstations or a controlled, one-way data export, so that it does not create a path to the production network.
Security built into the network architecture
Separating the monitoring infrastructure from the production OT network is the first layer of protection. However, secure communication also depends on the mechanisms used by LoRaWAN and the configuration of individual system components.
The proposed architecture combines physical network separation, encrypted communication, device authentication, and restricted administrative access.
Encryption and separation of responsibilities
LoRaWAN uses AES-128-based cryptographic mechanisms to protect communication between end devices and the network infrastructure. Frame counters additionally protect against the replay of previously captured messages.
An important characteristic of the protocol is the separation between network security and application-data protection.
Network session keys support message integrity and network operations, while the application session key (AppSKey) protects the measurement payload. This allows the network server to validate and route messages without needing access to the measurement data. Gateways hold no keys at all and simply forward radio frames.
In the LoRaWAN 1.1 security model, network responsibilities are further separated through dedicated session keys. The proposed solution uses this model, where supported by the selected devices and infrastructure. Key separation through a Join Server is also possible with LoRaWAN 1.0.x devices, which still make up the majority of the market; in that case, the single root key (AppKey) is held by the Join Server rather than by ChirpStack.
Where application data must remain unreadable to ChirpStack, the deployment uses a separate local Join Server and application-side key handling. Device root keys and the plaintext AppSKey are kept outside ChirpStack; any AppSKey forwarded through it is wrapped using a key available only to the Join Server and the application. ChirpStack passes the wrapped AppSKey to the application in the join event and in the Join Server context attached to each uplink. Implementation details are provided in ChirpStack’s end-to-end encryption documentation.
This configuration has practical implications. Because ChirpStack cannot read the payload, its built-in payload codecs and integrations that rely on decoded data cannot be used, and decoding takes place in the monitoring application. Downlink payloads must also be encrypted by the application, which first obtains the next downlink frame counter from ChirpStack and then enqueues the already-encrypted payload.
All these components remain within the local monitoring infrastructure. No external service is required simply to separate network management from application-data access.
For wired sensors connected through converters, LoRaWAN encryption protects the radio transmission starting at the converter. The short wired connection between the sensor and converter remains a separate part of the measurement system.
Secure device activation with OTAA
Devices join the proposed network using Over-the-Air Activation (OTAA).
During this process, an end device sends a join request through the gateways. The network infrastructure authenticates the request and establishes session keys used for subsequent communication.
A successful new join establishes new session keys, reducing reliance on long-lived session credentials. Root keys must still be protected and managed throughout the device lifecycle.
OTAA does not, by itself, define a periodic session-key rotation schedule. Rejoin behavior and the preservation of required security state across restarts must be addressed by the device implementation and deployment policy.
OTAA also provides a structured way to provision devices without configuring a fixed set of session keys as the basis of their ongoing operation, as required by the alternative method, Activation by Personalization (ABP).
Fig. 4. OTAA device activation process
Securing local communication and access
The security model extends beyond the radio interface.
Most gateways provide the Semtech UDP Packet Forwarder and/or Semtech Basics Station, and some vendors also include the ChirpStack MQTT Forwarder or Gateway Bridge in their firmware. For gateway backhaul, the preferred options are Semtech Basics Station over WSS/TLS or MQTT over TLS, with authenticated gateway access. Legacy Semtech UDP links require additional protection; one option is to keep UDP local to the gateway and use Gateway Bridge to forward traffic over MQTT/TLS. Access to management interfaces should be restricted to authorized administrators, while users responsible only for monitoring receive separate permissions.
Together, these measures provide a layered security architecture rather than relying on wireless encryption alone.
Maintaining availability without interrupting production
Availability is an important consideration even when the network is used only for monitoring.
The proposed architecture assumes that end devices can be received by more than one gateway. If a gateway becomes unavailable, another gateway may still receive the same transmission, provided overlapping radio coverage is maintained.
Availability planning should cover the entire data path, including gateway power, dedicated network links, the MQTT broker, ChirpStack and application services. Overlapping gateway coverage alone does not protect against failures of shared back-end components. Backup power and recovery measures should be selected according to monitoring requirements.
However, LoRaWAN remains a best-effort communication technology. Redundant reception reduces certain failure risks but does not guarantee that every individual message will be delivered.
The most important design decision is therefore the separation between monitoring availability and production continuity.
The monitoring network is not responsible for controlling machinery. A temporary communication failure may result in missing measurements, but it does not affect the control signals required to operate the production process.
Installation follows the same principle. Device preparation and configuration should take place outside production areas where possible, while physical installation is limited to measurement points that can be accessed safely without interrupting operations.
Where a sensor cannot be installed without disturbing production, a different measurement method must be considered. Wireless communication reduces installation work, but it does not automatically make every measurement point accessible during normal operation.
Deployment considerations and limitations
Network planning should account for device count, payload sizes, reporting intervals, required data freshness and downlink demand. Radio airtime and applicable regional limits must be considered even in a private network. In the EU868 band, most sub-bands are limited to a 1% duty cycle, which also applies to gateways when they transmit downlinks. The ISM band is shared with other users, so a private network does not have exclusive use of the radio spectrum. Gateway placement and overlapping coverage should be validated by an on-site radio survey under representative operating conditions. Battery-life and network-capacity estimates should be based on the selected devices and reporting profile.
LoRaWAN is not a real-time communication technology. Depending on the spreading factor, a single transmission can occupy the channel for anywhere from tens of milliseconds to more than a second, and duty-cycle limits determine how soon a device may transmit again. Combined with best-effort delivery, this means that LoRaWAN should not be used for safety-critical alarms or for measurements that require a guaranteed, immediate response. It does not replace conventional wired communication in critical devices and safety systems; instead, it complements them with diagnostics and additional periodic measurements.
Key takeaways: Expanding industrial monitoring without rebuilding the plant
A hybrid LoRaWAN architecture makes it possible to collect additional industrial data while minimizing changes to existing infrastructure. The proposed approach offers several key advantages:
- Less cabling, easier deployment—Wireless communication reduces the need for extensive cable runs, while short wired connections support conventional industrial sensors.
- Independent monitoring infrastructure—Dedicated gateways, a local network server, and an application layer operate separately from existing OT systems.
- Security by design—Network isolation, encrypted communication, device authentication, and controlled access help protect collected data.
- Production continuity—The monitoring network operates independently of machine control systems, reducing the risk of interference with ongoing production.
- Vendor flexibility—Compatible sensors, converters, and gateways from different manufacturers can be combined to meet specific monitoring requirements.
- Complementary role—LoRaWAN complements, rather than replaces, wired communication for critical measurements and safety-related alarms.
The goal is simple: collect more industrial data without disrupting the systems that keep production running.
