top of page

TECHNICAL CONSULTANCY SERVICE

See the range of ellenex LoRaWAN Products

 

Product & Technical Questions? Contact Us
Other Ellenex Products? Find them here 

Ellenex End to End Solutions: Find them here

Architectural Framework of LoRaWAN Network

While mainstream LPWAN deployments frequently rely on public cloud platforms for backend telemetry processing, critical infrastructure, defense installations, and industrial manufacturing environments increasingly mandate on-premise, physically air-gapped deployments. Bridging sub-GHz low-power wireless sensors into legacy Operational Technology (OT) ecosystems—such as Supervisory Control and Data Acquisition (SCADA) platforms, Programmable Logic Controllers (PLCs), and Building Management Systems (BMS)—requires translating non-deterministic, packet-constrained LPWAN transmissions into deterministic, polling-based industrial protocols including BACnet, Modbus, and OPC UA.​

​

Fundamentals of LoRaWAN Protocol and Network Topology

LoRaWAN utilizes a star-of-stars network topology designed to prioritize energy efficiency, lower protocol complexity, and maximize battery longevity. Unlike traditional wireless mesh topologies that incur significant radio overhead, routing table maintenance, and continuous receiver power consumption to relay peer traffic, LoRaWAN end nodes communicate directly with surrounding multi-channel gateways.

​

Core Architectural Components

The standard LoRaWAN network architecture is organized into five functional layers, forming a end-to-end data processing pipeline:

​

  • LoRaWAN End Devices (Sensors and Actuators): Edge nodes equipped with physical transducers, low-power microcontrollers, and LoRa radio transceivers. These units collect field metrics such as fluid flow, differential pressure, temperature, ambient air quality, or vibration, digitize the signals, and broadcast encrypted sub-GHz radio frames to nearby gateways.

  • LoRaWAN Gateways (RF Concentrators): Multi-channel radio frequency bridges equipped with advanced baseband processors, such as the Semtech SX1302 or SX1303, capable of concurrently demodulating transmissions across multiple frequency channels and orthogonal Spreading Factors ranging from SF7 to SF12. Gateways operate exclusively at the physical layer; they do not possess application decryption keys or decrypt payload contents. Instead, they encapsulate received RF MAC frames into IP packets and forward them to the Network Server via cellular, Ethernet, or satellite backhauls using protocols such as Semtech UDP or LoRa Basics™ Station.

  • Network Server (LNS): The central operational hub of the LoRaWAN architecture. The LNS authenticates device credentials, eliminates duplicate packets forwarded by multiple gateways receiving the same RF broadcast, executes Adaptive Data Rate (ADR) algorithms to optimize RF output power and Spreading Factors, schedules downlink traffic, and maintains frame counter synchronization.

  • Join Server (JS): The cryptographic authentication entity that manages Over-The-Air Activation (OTAA) requests. The Join Server validates device identities, processes root keys stored in secure hardware modules, and derives operational session keys, distributing them to the Network Server and Application Server without revealing root security credentials over intermediate networks.

  • Application Server (AS): The endpoint platform holding application decryption keys. The Application Server decrypts application payloads, converts binary telemetry arrays into structured variables, runs domain-specific analytics, and integrates data into enterprise software via REST APIs, gRPC streams, or MQTT brokers.

​

Device Operational Classes

LoRaWAN defines three distinct operational profiles—Class A, Class B, and Class C—to balance downlink communication latency against end-device power consumption:

​

  • Class A (Asynchronous / Power Optimized): Mandatory for all LoRaWAN devices, Class A provides the most energy-efficient operating profile. Communication is strictly uplink-initiated. Following an uplink broadcast, the device opens two precise, post-uplink receive windows, designated as RX1 (opened after a configurable delay, typically 1 second) and RX2 (opened typically 2 seconds post-uplink). Downlink control traffic from the Network Server can only be delivered during these post-uplink windows. If no downlink frame is received, the transceiver enters a deep-sleep state until the next sampling interval, enabling battery operational lifespans exceeding a decade on primary lithium cells.

  • Class B (Beacon-Synchronized / Deterministic Latency): Class B devices retain Class A uplink behavior while opening additional, scheduled downlink receive slots, termed "ping slots," independent of uplink activity. To synchronize these ping slots across the network, gateways periodically broadcast time-stamped synchronization beacons. Class B end devices align their internal timing circuits to these gateway beacons, providing deterministic downlink latency suitable for control applications, such as automated valve operation, while preserving low power consumption.

  • Class C (Continuous Listening / Main-Powered): Class C devices keep their receiver continuously active whenever the transmitter is idle. This continuous listening profile provides near-zero downlink latency, enabling immediate reception of command frames. Because an active receiver draws continuous operating current (typically 10 mA to 20 mA), Class C devices generally require dedicated solar systems or mains electrical power. Class C is typically deployed for smart lighting nodes, industrial relay controllers, and automated switches.

​

Cryptographic Security Architecture and Protocol Evolution

LoRaWAN utilizes symmetric Advanced Encryption Standard (AES) cryptography with 128-bit key lengths to guarantee payload confidentiality, message integrity, and mutual authentication across the radio network. Devices join the network via Over-The-Air Activation (OTAA)—which dynamically derives session keys during a cryptographic handshake—or Activation-by-Personalization (ABP), where session keys are hardcoded into the device during manufacturing.

​

LoRaWAN v1.0.x Security Model

In the legacy LoRaWAN v1.0.x specification, security relies on a single 128-bit root key, the Application Key (AppKey), shared between the end device and the network backend. During the OTAA activation exchange, this single root key derives two operational session keys:

  • Network Session Key (NwkSKey): Utilized by the Network Server to calculate and verify the Message Integrity Code (MIC) embedded within frame headers, ensuring message integrity and authenticating the sender.

  • Application Session Key (AppSKey): Utilized end-to-end between the sensor node and the Application Server to encrypt application telemetry using AES-128 in Counter (CTR) mode, keeping user telemetry private from intermediate gateway operators.

 

Legacy v1.0.x implementations exhibit operational security constraints. Because both session keys derive from a single AppKey, the Network Server administrator must be trusted with security credentials that could expose network isolation. Furthermore, v1.0.x join requests use pseudo-random device nonces (DevNonce). If a device resets without non-volatile memory persistence, predictable or reused DevNonce values make the activation process susceptible to join-request replay attacks.

​

LoRaWAN v1.1 Security Architecture

The LoRaWAN v1.1 standard introduces a dual root key architecture managed by a Join Server, isolating network management credentials from application layer privacy. Under v1.1, the Network Key (NwkKey) handles network authentication and MAC command security, while the Application Key (AppKey) is dedicated strictly to end-to-end application payload encryption.

From these dual root keys, the Join Server derives five specialized operational session keys:

  • Forward Network Session Integrity Key (FNwkSIntKey): Calculates the MIC for uplink data frames, ensuring uplink message integrity.

  • Serving Network Session Integrity Key (SNwkSIntKey): Calculates the MIC for downlink data frames and validates uplink MICs during network roaming operations.

  • Network Session Encryption Key (NwkSEncKey): Encrypts and decrypts MAC commands transmitted over the air between the device and the LNS.

  • Application Session Key (AppSKey): Encrypts and decrypts application telemetry end-to-end between the sensor and the Application Server.

  • Join Session Keys (JSSEncKey and JSNwkSIntKey): Secure communication exchanges between the Join Server and the LNS during re-keying or roaming session setups

LoraWAN Architecture.png

What are the advantages of LoRaWAN for Industrial IoT?

LoRaWAN (Long Range Wide Area Network) has emerged as a premier communication standard for industrial Internet of Things (IoT) deployments. Designed specifically for battery-powered sensors transmitting periodic small data payloads, LoRaWAN delivers a uniquely balanced combination of extreme signal range, long battery life, and complete network ownership. By leveraging unlicensed sub-gigahertz radio frequencies and open protocol standards, it allows industrial enterprises to deploy scalable, low-cost monitoring networks across challenging environments.

​

Exceptional Coverage Range and Deep Penetration

LoRaWAN uses Chirp Spread Spectrum (CSS) modulation, which spreads radio signals across a wider frequency band to achieve high processing gains. This enables gateways to pick up and demodulate faint radio signals operating well below the noise floor. As a result, a single gateway can cover distances of up to 10–15 kilometers in open areas and 2–5 kilometers in dense industrial facilities, while penetrating heavy concrete walls, metallic equipment, and subterranean structures.

​

Ultra-Low Power Consumption and Multi-Year Battery Life

Unlike cellular or Wi-Fi devices that require constant active connections, LoRaWAN end devices operate on a sleep-first architecture. Sensors remain in a micro-ampere deep-sleep state for over 99% of their operational life, waking only briefly to sample metrics and broadcast small data packets. When paired with high-density primary battery chemistries (such as Lithium Thionyl Chloride), sensors can operate reliably for 5 to 10+ years without maintenance.

​

High Network Scalability and Density Management

LoRaWAN uses an efficient point-to-multipoint "star-of-stars" network topology that avoids the routing overhead and energy strain associated with mesh networks. Modern multi-channel gateways can listen to multiple channels simultaneously and demodulate overlapping transmissions on different spreading factors. Furthermore, Adaptive Data Rate (ADR) algorithms automatically adjust device output power and data rates, keeping network channels clear and allowing a single gateway to support tens of thousands of active sensors.

​

Cost-Effective Unlicensed Spectrum

LoRaWAN operates within license-free sub-gigahertz Industrial, Scientific, and Medical (ISM) frequency bands (e.g., 868 MHz in Europe, 915 MHz in North America/Australia, 923 MHz in Asia). Because it does not rely on commercial cellular carrier networks, organizations do not pay recurring monthly SIM subscription fees per sensor. The financial model relies on a one-time capital expenditure for hardware, delivering significantly lower long-term Operational Expenditure (OpEx).

​

Private Network Sovereignty and Data Privacy

Industrial operators can deploy entirely private, on-premise LoRaWAN infrastructure by placing their own gateways and network servers on-site. This eliminates reliance on public cellular network availability, guarantees complete control over network uptime, and keeps sensitive operational telemetry air-gapped within the enterprise network without routing traffic through third-party servers.

LPWAN Paradigms

LoRaWAN vs NB-IoT and LTE-M

Industrial IoT deployments require choosing an appropriate connectivity standard based on geographic topology, power access, operational cost structures, and data requirements. LoRaWAN, Narrowband IoT (NB-IoT), and LTE Category M1 (LTE-M / Cat-M1) represent the primary industrial LPWAN technologies.

Spectrum models differ across these standards:

  • Unlicensed Sub-GHz ISM Bands: LoRaWAN operates in license-free spectrum, allowing private or public network deployments with zero recurring cellular data fees.

  • Licensed Cellular LTE Bands: NB-IoT and LTE-M operate within carrier spectrum, relying on mobile network operator infrastructure and recurring subscription SIM plans.

LoRaWAN operates in unlicensed sub-gigahertz ISM spectrum (868 MHz in Europe, 915 MHz in North America, 923 MHz in Asia-Pacific). This allows industrial enterprises to deploy private LoRaWAN networks by installing gateways directly on-site. Private deployments eliminate dependence on commercial cellular coverage, ensure data sovereignty, and avoid recurring monthly cellular subscription fees.

​

In contrast, NB-IoT and LTE-M are 3GPP cellular standards that operate within licensed telecommunications spectrum. They require active commercial SIM cards and subscription plans for every node. While cellular LPWAN offloads gateway infrastructure management to mobile network operators (MNOs), it incurs ongoing operational expenses (OpEx), introduces carrier dependency, and can leave coverage gaps in remote industrial areas.

​

NB-IoT uses narrow 180 kHz sub-carrier channels to maximize signal penetration through dense building materials and deep underground structures. However, NB-IoT does not support active cell tower handover; moving assets must renegotiate network connections, which consumes battery power.

​

LTE-M offers higher data throughput (up to 1 Mbps) and native support for full cell handover and voice communication (VoLTE). These capabilities make LTE-M suitable for mobile asset tracking and fleet management. However, LTE-M's wider 1.4 MHz channel bandwidth results in higher baseline operating power consumption compared to LoRaWAN, reducing battery longevity for simple periodic sensors.

​

Public vs Private LoRaWAN Network​

The decision to choose public or private LoRaWAN infrastructure depends on operational ownership requirements, coverage needs, and management capabilities. Public networks operated by connectivity providers offer broad geographic coverage without gateway maintenance. Private networks provide complete control over network security, device density, and data management, making them common in industrial processing, water treatment, and mining environments.

​

​Private Network

High-security installations—including power generation plants, water treatment facilities, defense sites, and industrial manufacturing complexes—often forbid external internet egress, requiring completely air-gapped LoRaWAN architectures.

​

Embedded Gateway Network Server Architecture

In an Embedded LNS deployment, the Network Server, Join Server, Application Server, and payload decoders are integrated directly into the gateway's onboard Linux operating system. The gateway hardware receives incoming RF frames, decrypts $AppSKey$-encrypted payloads locally, executes JavaScript payload decoders, and outputs formatted metrics directly over local physical Ethernet ports via protocols like Modbus TCP, BACnet/IP, or local MQTT. This eliminates dependencies on external cloud backhauls, preserves operational continuity during WAN outages, cuts round-trip downlink actuation latency from seconds down to milliseconds, and creates a secure air-gap where telemetry never leaves the facility.

​

Distributed On-Premise LNS Infrastructure

For large campuses or multi-building industrial plants requiring gateway redundancy across extensive coverage areas, an embedded LNS on a single gateway can create uncoordinated coverage islands. Instead, organizations deploy containerized, enterprise-grade Network Servers, such as ChirpStack, on local virtual machines or bare-metal edge servers connected to the plant LAN. Under this topology, lightweight concentrator gateways forward raw RF frames over local VLANs using secure protocols like LoRa Basics™ Station (authenticated via TLS client certificates) to the central on-premise LNS stack. The centralized server performs frame deduplication, manages network-wide Adaptive Data Rate (ADR) profiles, coordinates Class B beacon transmissions across multiple gateways, and distributes decoded telemetry to local SCADA or BMS platforms.

​

Air-Gapped Network Time Synchronization Mechanics

Class B operations require microsecond-accurate time synchronization across gateways to broadcast synchronized beacon frames at exact 128-second intervals. In standard cloud deployments, gateways obtain precise timing by locking onto global navigation satellite signals via integrated GPS/GNSS modules, deriving a 1-Pulse-Per-Second (1PPS) hardware pulse.

In air-gapped industrial facilities located in deep basements, shielded mechanical rooms, or underground shafts where satellite signals are unavailable, network-based timing mechanisms are used:

  • Precision Time Protocol (IEEE 1588 PTP): Gateways with hardware-timestamping network interface cards lock onto a local PTP Grandmaster clock deployed on the air-gapped LAN, achieving sub-microsecond clock alignment to synthesize the 1PPS signal required for Class B beaconing.

  • Network Time Protocol (NTP) with Software Drift Compensation: Where network switches lack PTP support, gateways synchronize to local redundant NTP servers. To account for network packet jitter, the gateway's packet forwarder runs continuous drift-compensation algorithms, adjusting local software clock phase counters to maintain Class B beacon timing within the required 1-microsecond window.

​

Public Network

While on-premise networks serve air-gapped, high-security facilities, public and community LoRaWAN networks provide widespread, multi-tenant coverage across cities, regions, and nations. Understanding public architectures is essential for enterprises evaluating multi-site supply chain tracking, smart utility metering, or hybrid deployments that blend local private coverage with broad public radio networks.

​

Public Network Operators (PNOs) and Community Networks

Public LoRaWAN topologies decouple gateway ownership and radio infrastructure management from end-user application management:

  • Public Network Operators (PNOs): Telecom operators and dedicated LPWAN providers (such as Everynet, Orange, or Actility ThingPark networks) deploy cell-tower-mounted macrocell gateways to offer connectivity as a service. Enterprises pay subscription fees based on message volume or device counts without needing to buy or maintain physical radio infrastructure.

  • Community and Decentralized Networks: Initiatives like The Things Network (TTN) and the Helium Network build global coverage through crowdsourced gateway deployments. TTN operates an open-access multi-tenant infrastructure using shared cloud Network Servers. Helium employs a decentralized blockchain-based architecture where physical "hotspot" owners earn tokens for providing radio coverage, forwarding packets to private or public Network Servers via standardized routing protocols.

​

NetID, DevAddr Assignment, and Multi-Tenant Packet Routing

Because all LoRaWAN gateways in a geographic region listen on the same unlicensed radio spectrum (e.g., EU868 or US915), a public gateway receives unencrypted RF frames from every surrounding sensor regardless of network ownership. Public networks rely on structured addressing protocols to route packets efficiently to the correct tenant's Network Server without decrypting application data:

  1. Network Identifier (NetID): A 24-bit unique identifier assigned to network operators by the LoRa Alliance. The NetID forms the prefix for device dynamic network addresses (DevAddr) allocated during activation.

  2. Device Address (DevAddr): A 32-bit address assigned to an end node during the OTAA Join exchange. The most significant bits reflect the operator's NetID.

  3. Upstream Packet Filtering: When a public gateway receives an uplink frame, it forwards the frame header to its central LNS. The LNS inspects the DevAddr prefix; if the NetID matches its own network, it processes the packet. If the NetID belongs to a peered network, the LNS routes the packet to the target operator's backend via standardized LoRaWAN Roaming interfaces. Unrecognized frames are dropped immediately, minimizing processing overhead.

​

LoRaWAN Roaming Architecture

The LoRaAlliance Roaming Specification enables seamless message transport across distinct public and private network domains:

  • Passive Roaming: The home network server (hLNS) maintains session state, cryptographic keys, and frame counters for the device. A visited network server (vLNS) receives RF traffic from its local gateways, identifies the NetID embedded in the DevAddr, and forwards the encrypted uplink packet directly to the hLNS over a secure IP transport (HTTPS/gRPC). Downlinks follow the reverse path back through the vLNS gateway.

  • Handover Roaming: The control of the device's radio session is temporarily transferred from the hLNS to the vLNS as the node moves geographically across network boundaries, allowing the visited network to manage MAC commands and link parameters directly.

Private vs Public LoRaWAN Network Comparision Table.jpg

Industrial Application for LoRaWAN Sensor

LoRaWAN has become a dominant connectivity standard for industrial remote monitoring due to its ability to transmit sensor data across wide geographic areas and deep structural barriers with multi-year battery life. Below is a brief overview of how LoRaWAN sensors are applied across key industrial sectors, especially in water infrastructure monitoring.

​

Water and Wastewater Monitoring

Water utilities deploy LoRaWAN pressure transmitters, flow meters, and level sensors across distribution networks and wastewater facilities to track pipeline health and prevent water loss. Operating asynchronously on primary batteries, these sensors monitor pressure fluctuations, detect transient surges like water hammer, measure flow rates, and track groundwater levels across expansive service territories. By eliminating the need for expensive trenching or recurring cellular SIM contracts, LoRaWAN enables continuous, cost-effective monitoring of underground valve vaults, manholes, and distant pumping stations.

​

Tank Level Monitoring

LoRaWAN level sensors provide continuous inventory visibility for fuel storage depots, chemical facilities, water reservoirs, and industrial storage tanks. Utilizing either submersible hydrostatic pressure transducers or non-contact ultrasonic and radar sensors, these nodes calculate precise fluid or bulk material volume in real time. The automated transmission of level data prevents dangerous tank overfill incidents, eliminates manual dipstick measurements in hazardous zones, and streamlines supply chain logistics for off-grid distribution sites.

​

Environmental Monitoring

Environmental monitoring networks use ruggedized LoRaWAN nodes to continuously measure ambient temperature, air quality, toxic gas levels, groundwater depth, and weather conditions in remote or harsh locations. Because these devices can operate autonomously for 5 to 10 years on a single battery, organizations can deploy vast early-warning systems for flood detection, watershed management, and industrial emissions compliance. This long-term autonomy drastically reduces field maintenance costs while maintaining reliable data collection across sensitive ecosystems.

​

Smart Agriculture

Agricultural operations deploy LoRaWAN sensor arrays across expansive farmland to support precision agriculture and optimize resource management. By placing multi-depth soil moisture sensors, microclimate monitors, and valve pressure gauges throughout crops, farmers gain real-time visibility into soil hydration and atmospheric conditions. Integrating these sensor insights with automated irrigation controllers minimizes water and energy consumption, improves crop yields, and allows remote farm management across thousands of acres using a single local gateway.

​

Industrial Infrastructure Monitoring

Industrial facilities, manufacturing plants, and refineries install LoRaWAN sensors to continuously monitor asset health, facility environments, and critical machinery. Sensors attached to pumps, motors, steam traps, and pressure lines track operational parameters such as surface temperature, structural vibration, line pressure, and hazardous gas leaks. This real-time telemetry drives predictive maintenance strategies, allowing plant operators to identify early equipment wear, prevent catastrophic failures, reduce unplanned downtime, and maintain strict worker safety standards across hazardous zones.

​

Integration with Operational Technology

Bridging low-power, packet-constrained LoRaWAN networks with deterministic OT systems requires specialized translation engines that convert binary LPWAN payloads into industrial register maps and object models.

​

Integration with Building Management Systems (BMS) via BACnet/IP

Integration with Building Management Systems operating over BACnet/IP relies on an edge gateway or local Network Server running an embedded virtual BACnet server. When a wireless sensor broadcasts a compressed, encrypted radio payload, the local LoRaWAN Network Server decrypts the frame, executes a JavaScript payload decoder, and extracts discrete physical measurements like temperature, humidity, or differential pressure. The translation engine automatically maps these decoded numerical variables directly to standard BACnet object instances—such as mapping a room temperature reading to an Analog Input (AI-1) object or a water leak alarm to a Binary Input (BI-1) object.

​

To ensure seamless operation alongside traditional wired HVAC controllers, the gateway responds to standard BACnet broadcast requests (Who-Is) with synthetic identification responses (I-Am), exposing all configured wireless sensors as native BACnet devices on the local IP network. Furthermore, the virtual server implements BACnet Change of Value (COV) services. Rather than forcing the BMS to continuously poll slow-changing environmental metrics, the gateway fires an asynchronous COV message only when a value changes beyond a set threshold. In supervisory platforms like the Niagara Framework or Schneider EcoStruxure, integrators can auto-discover these virtual objects and drag them directly into existing control loops, schedules, and alarm blocks without writing custom drivers.

​

Integration with SCADA and PLCs via Modbus TCP

Integrating wireless field sensors into traditional Programmable Logic Controllers (PLCs) and industrial SCADA engines is achieved by mapping LoRaWAN payloads into Modbus TCP register maps. Because Modbus uses a simple, flat 16-bit register architecture, the edge gateway provides an embedded Modbus TCP Slave service that translates decoded multi-byte sensor metrics into specific memory offsets. For example, a 32-bit floating-point vibration measurement is converted into IEEE 754 format and packed across two contiguous 16-bit Holding Registers (such as Registers 40001 and 40002).

​

From the perspective of factory PLCs (such as Siemens S7 or Rockwell ControlLogix), the wireless LoRaWAN gateway appears as a standard wired Modbus I/O module. The PLC's communication processor periodically issues standard Modbus Read Holding Registers (Function Code 03) or Read Discrete Inputs (Function Code 02) requests over local Ethernet to poll current sensor values. The gateway immediately returns the latest decoded metrics stored in its local memory array, decoupling the PLC’s real-time scan cycle from the non-deterministic wireless time-on-air delays.

​

Modern SCADA Integration via OPC UA

For enterprise-scale industrial automation environments, OPC UA provides an object-oriented, semantically rich data framework that goes beyond plain memory registers. Integration between an on-premise Network Server (such as ChirpStack) and an OPC UA SCADA platform (such as Ignition or Siemens WinCC) is managed by a dedicated microservice bridge. The bridge subscribes to decoded event streams published by the local LNS over local gRPC calls or MQTT topics.

​

Upon receiving telemetry, the microservice bridge dynamically constructs or updates an OPC UA node hierarchy matching the LoRaWAN device profile. Each sensor variable is mapped into an OPC UA Variable Node accompanied by detailed metadata, including engineering units, valid range thresholds, source timestamps, and quality status flags (e.g., Good [0x00000000]). SCADA clients subscribe to these node paths, receiving event-driven updates whenever new wireless telemetry arrives, enabling plant-wide visualization and analytics with full semantic context.

​

Local Middleware Execution Pipelines (Node-RED & Local Brokers)

Before telemetry ever reaches BACnet, Modbus, or OPC UA adapters, it passes through a local middleware execution pipeline residing directly on the edge server or gateway. When raw radio frames arrive, the local LNS passes the binary byte array through dedicated payload codecs (typically written in JavaScript). These codecs perform bit-masking and bit-shifting operations to unpack compressed binary data into structured JSON objects containing variables like temperature, battery voltage, and tamper status.

​

To enable custom edge logic, advanced gateways embed visual computing engines like Node-RED alongside localized MQTT brokers (e.g., Mosquitto). Node-RED flows allow integrators to filter out signal noise, calculate moving averages, convert measurement units, or evaluate local threshold conditions before pushing data downstream. Decoupling data distribution through a local MQTT pub/sub broker ensures that edge analytics engines, local time-series databases, and industrial protocol translators can independently consume the same telemetry stream without needing internet connectivity or opening inbound network ports.

​

Ellenex Industrial LoRaWAN Sensors

Ellenex develops industrial-grade LoRaWAN sensors and telemetry devices specifically engineered for long-term deployment in demanding operational environments. Designed for off-grid infrastructure monitoring and remote asset monitoring, Ellenex sensors combine rugged IP-rated hardware, ultra-low-power electronics, and long-range wireless connectivity to deliver reliable data without relying on wired infrastructure or recurring cellular subscription fees.

​

Pressure Monitoring

Essential for monitoring pipeline integrity, hydraulic networks, HVAC systems, and gas pipelines, Ellenex pressure sensors enable near real-time detection of pressure drops, leaks, bursts, and transient surges (water hammer). They deliver high-accuracy gauge, absolute, or differential pressure readings across industrial processing and municipal utility applications. Relevant Products: PTS2, PTS3, PTC2, PTD2, and PTF2 (gauge/absolute pressure sensors), alongside PDS2 and PDT2 (differential pressure sensors).

​

Level Monitoring

Engineered for precise liquid and bulk storage visibility, Ellenex level sensors measure fluid column depth in storage tanks, fuel depots, chemical vessels, water reservoirs, wells, and open channels. They eliminate manual dipstick measurements, prevent dangerous overflow incidents, and streamline inventory management in off-grid environments. Relevant Products: Submersible and surface liquid level sensor families including PLS2, PLS3, PLM2, and PLC2.

​

Water Quality Monitoring

This monitoring solution is designed for environmental compliance, wastewater management, aquaculture, and water treatment systems, these sensors continuously track key chemical and physical parameters in remote waterways and treatment facilities. They operate autonomously in harsh chemical environments with minimal maintenance required. Relevant Products: Ellenex Water Quality (WQ) product series, featuring dedicated LoRaWAN pH sensors, ORP (Oxidation-Reduction Potential) sensors, turbidity sensors, salinity sensors, and dissolved oxygen probes.

​

Environmental Monitoring

Built for outdoor perimeters, watershed tracking, and agricultural microclimates, Ellenex environmental sensing nodes measure meteorological conditions, soil hydration, dust buildup, and ambient air flow. They support early-warning flood management, disaster prevention, and automated precision irrigation control. Relevant Products: Ellenex LoRaWAN environmental and agricultural sensor series for soil moisture, ambient humidity, rainfall, air velocity, and dust collection monitoring.

​

Temperature Monitoring

Crucial for cold-chain management, industrial processing, pipe heat tracing, and thermal equipment protection, Ellenex temperature devices deliver precise thermal telemetry from liquids, gases, or solid surfaces. Featuring high IP-rated enclosures, they maintain stable operation under extreme environmental conditions. Relevant Products: Ellenex IP68 LoRaWAN Temperature Sensors and interface modules (such as the RM1-L / RM4-L) supporting Pt100 and Pt1000 RTD temperature probes.

​

Distance Monitoring

Utilizing non-contact acoustic or optical time-of-flight technology, Ellenex distance sensors determine the proximity, height, or fill level of fluids and solid surfaces without direct material contact. This non-contact design makes them ideal for corrosive chemical storage, open channel flood gauging, and asset position tracking. Relevant Products: Ellenex LoRaWAN Non-Contact Ultrasonic and Radar Distance Sensor series (such as the DU and DRC series).

Frequently Asked Questions about LoRaWAN

​​What is the typical operational range of a LoRaWAN sensor?

LoRaWAN sensors can transmit telemetry across 2 to 5 kilometers in dense urban or industrial settings with physical obstructions, and up to 10 to 15 kilometers in open rural environments with clear line-of-sight. This extended coverage is enabled by Chirp Spread Spectrum (CSS) modulation, which allows multi-channel gateways to receive and decode weak signals even when operating below the environmental noise floor.

​

What is the difference between LoRa and LoRaWAN?

LoRa refers specifically to the physical radio modulation technology that converts digital data into wideband frequency-chirped radio signals. LoRaWAN, on the other hand, is the open upper MAC-layer networking protocol governed by the LoRa Alliance that manages device authentication, network topology, cryptographic key exchanges, adaptive data rates, and data routing between edge sensors, gateways, and cloud servers.

 

How do LoRaWAN sensors achieve 5 to 10+ years of battery life?

Industrial LoRaWAN sensors achieve multi-year longevity by operating on an asynchronous sleep-first profile (primarily Class A mode), remaining in a micro-ampere deep-sleep state for over 99% of their operational life. Sensors wake up only briefly at scheduled intervals to sample transducer metrics, broadcast small data payloads, check for optional downlink messages during two short receive windows, and immediately return to sleep.

 

How does a Building Management System (BMS) ingest LoRaWAN telemetry via BACnet/IP?

Answer: To integrate wireless sensors into BMS platforms (such as Niagara Framework, Schneider EcoStruxure, or Johnson Controls Metasys), an edge gateway or local LNS acts as a virtual BACnet Server.

When the local LNS decrypts a sensor payload, its translation engine maps the decoded variables to synthetic BACnet Object Instances:

  • Numerical values (e.g., ambient temperature, humidity, differential pressure) map to Analog Input (AI) objects.

  • Binary flags (e.g., water leak alarms, door contact state) map to Binary Input (BI) objects.

Supervisory BMS controllers issue standard BACnet Who-Is discovery requests across the local subnet; the gateway responds with I-Am packets, exposing the wireless sensors as native BACnet devices. Facility engineers can then drag these objects directly into existing BMS control logic, schedules, and alarm blocks.

 

How does LoRaWAN protect sensitive industrial telemetry and prevent cyber attacks?

LoRaWAN implements native enterprise security using standard 128-bit AES encryption divided into separate cryptographic layers. Network session keys authenticate frame headers and verify message integrity at the network server, while separate application session keys encrypt telemetry end-to-end between the field sensor and the enterprise platform, ensuring network operators cannot read user payload data.

​

Can a LoRaWAN network operate completely offline in an air-gapped facility?

Answer: Yes. While cloud-based LoRaWAN servers are common for smart city deployments, industrial and high-security sites (such as power generation plants, water treatment facilities, or defense sites) frequently require air-gapped private networks. In an air-gapped setup, an Embedded Gateway LNS or a localized on-premise Network Server (such as containerized ChirpStack) is installed directly inside the facility's local area network (LAN). The gateway receives radio broadcasts, decrypts payloads, and exposes data locally over Ethernet using protocols like Modbus TCP, BACnet/IP, or local MQTT brokers. No data ever leaves the facility, zero internet connectivity is required, and full operation continues even during external wide area network (WAN) outages.

​

How do I connect wireless LoRaWAN sensors to a PLC or SCADA system using Modbus?

Programmable Logic Controllers (PLCs) cannot directly process raw sub-GHz wireless radio frames. Integration is accomplished at the network edge using an industrial LoRaWAN gateway running an embedded Network Server (LNS) or a local middleware translator. When a wireless sensor transmits a compressed radio packet, the local gateway decrypts the payload and executes an onboard JavaScript decoder to unpack binary bytes into numerical values (such as temperature, pressure, or flow). The gateway’s embedded Modbus TCP Slave service maps these decoded metrics directly into specific 16-bit Holding Registers or Discrete Inputs. The plant PLC simply polls these local Ethernet registers on its standard scan cycle, reading the wireless field sensors as if they were standard wired remote I/O modules.

​

Can LoRaWAN be used for real-time control and actuation applications?

Yes, while battery-powered Class A sensors prioritize energy conservation over downlink availability, LoRaWAN defines Class B and Class C operational modes specifically for actuation. Class B devices open synchronized, deterministic time slots for periodic downlinks, while continuously powered Class C devices keep their receivers active at all times, delivering near-zero latency for controlling valves, relays, and industrial switches.

​

Why are LoRaWAN payloads transmitted in raw binary format, and how are they decoded at the edge?

LoRaWAN field devices use compact binary encoding (hex/byte arrays) rather than verbose text formats like JSON or XML to minimize radio time-on-air, conform to regional RF duty-cycle limits, and maximize battery lifespan. When the local Network Server receives the raw binary uplink, it routes the byte array through a specialized JavaScript payload codec (uplink converter) assigned to that device profile. The script uses bit-masking and bit-shifting operations (such as parseBytesToInt or parseBytesToFloat) to extract discrete variables (e.g., converting bytes 0–1 into a temperature reading). The output is a structured JSON object passed downstream to OT middleware, local MQTT brokers (such as Mosquitto), or industrial protocol translators.

​

Is LoRaWAN suitable for real-time closed-loop control and safety interlocks?

No. LoRaWAN is designed for soft real-time supervisory monitoring, environmental tracking, predictive maintenance, and auxiliary control, rather than hard real-time safety interlocks. Because LoRaWAN operates on an unacknowledged, ALOHA-based stochastic RF medium where packet collisions and spectrum duty-cycle restrictions occur, transmission latency is non-deterministic.

While Class B (beacon-synchronized ping slots) and Class C (continuous listening) modes offer low-latency downlinks for control commands (such as operating valves or relays), any automated control loop using wireless actuators must incorporate local fail-safe watchdog timers. If an actuator loses communication with the edge gateway for a predefined duration, it should automatically default to a safe physical state.

A Guide to Industrial LoRaWAN IoT Sensors

Low-Power Wide-Area Networks (LPWAN) represent a fundamental shift in wireless telecommunications, specifically engineered for long-range, low-bit-rate communication among battery-constrained devices. At the foundation of the Long Range Wide Area Network (LoRaWAN) protocol stack is the LoRa physical layer (PHY), a proprietary radio modulation technology based on Chirp Spread Spectrum (CSS) modulation. CSS modulation was originally developed for military and radar applications due to its resilience against electromagnetic interference, multipath fading, and signal attenuation. By spreading a narrow-band baseband signal across a wider frequency bandwidth using continuously varying frequency pulses called chirps, LoRa achieves processing gains that allow receivers to demodulate signals operating below the thermal noise floor.

​

The physical transmission layer is governed by four primary operational parameters: Spreading Factor, Bandwidth, Coding Rate, and Transmission Power. The Spreading Factor defines how many chirps represent a single symbol of payload data. Bandwidth specifies the frequency span allocated for the modulation sweep, while the Coding Rate incorporates Forward Error Correction (FEC) by adding redundant parity bits to restore corrupted data frames in noisy radio environments. Together, these parameters define how data is modulated and transmitted through the radio frequency spectrum.

​

A fundamental trade-off exists within the LoRa physical layer between receiver sensitivity, transmission speed, and energy consumption. Selecting a higher Spreading Factor increases receiver processing gain, allowing gateways to decode faint signals over significantly longer distances or through dense physical obstructions. However, higher Spreading Factors reduce the effective data transfer rate and exponentially increase the packet's Time-on-Air. Because extended transmission times keep the radio transceiver active longer, higher Spreading Factors draw more energy per transmission.

​

To maintain communication reliability, transceivers incorporate features such as Low Data Rate Optimization during long transmission windows to compensate for clock drift caused by environmental variations. By balancing Spreading Factor, Bandwidth, and Coding Rate, LoRaWAN networks optimize link performance for diverse field scenarios. Remote sensors deployed in harsh or distant environments can prioritize extended range, while nodes situated near gateways operate at lower spreading factors to maximize data rates and conserve battery power.

What is LoRaWAN?

image.png
LoRaWAN for all Industries.png
bottom of page