LoRaWAN Network Server
This page documents the Ignition 8.1 build of the LoRaWAN module (artifact LoRaWAN-8.1.modl, minimum Ignition 8.1.33).
For the latest release, which targets Ignition 8.3 and adds a Connections > LoRaWAN web UI (settings, gateways, devices, and decoder editor), see the current documentation.
Overview
The LoRaWAN module transforms Ignition into a complete LoRaWAN network server. It accepts connections from LoRaWAN gateways using the Semtech Packet Forwarder UDP protocol, manages device registrations, handles device activation (OTAA join server and ABP), and exposes all device and gateway data through the real-time managed [LoRaWAN] tag provider.
The implementation targets the LoRaWAN specification TS001-1.0.4 (Link Layer, L2 1.0.4) with regional parameters RP002-1.0.5.
The module implements LoRaWAN 1.0.x only. LoRaWAN 1.1 is not supported.
Features
- LoRaWAN Network Server - Semtech Packet Forwarder UDP network server
- Multi-Gateway Support - Connect multiple gateways with automatic uplink deduplication (
DevAddr:FCnt, 5-second window; best gateway chosen by RSSI then SNR) - OTAA & ABP Activation - Over-the-Air Activation (join server with DevNonce replay protection and session-key derivation) and Activation By Personalization
- Class A & C Devices - Battery-optimized (Class A) and always-listening (Class C) device support. Class B is not implemented.
- MAC Command Engine - LinkCheck, LinkADR, DutyCycle, RXParamSetup, DevStatus, NewChannel, RXTimingSetup, TXParamSetup, DLChannel
- Adaptive Data Rate (ADR) - Automatic optimization of device transmission parameters
- Downlink Queue - Per-device queue (max 10), confirmed-downlink retry, and RX2 fallback
- Device Status Tracking - Periodic and on-demand DevStatusReq (battery and margin)
- JavaScript Payload Decoders - GraalJS sandbox with the ChirpStack/TTN
decodeUplink(input)contract; decoded fields become dynamic tags - Managed Tag Provider - All device and gateway data exposed via the
[LoRaWAN]tag provider - CSV Bulk Import/Export - Bulk device and gateway management
- Scripting API -
system.lorawan.*functions for device, gateway, and decoder management
Technical Specifications
| Specification | Value |
|---|---|
| Module ID | com.operametrix.ignition.lorawan |
| Module Name | LoRaWAN |
| Artifact | LoRaWAN-8.1.modl |
| Current Version | 1.4.0 |
| Minimum Ignition Version | 8.1.33 |
| Built Against SDK | 8.1.53 |
| Required Module | None |
| Scope | Gateway, Designer |
| License | Proprietary — © 2026 OperaMetrix SAS (paid, with trial) |
On the 8.1 build there is no admin web UI (it is an 8.3-only feature): only the network Settings have a gateway page, and everything else is driven by script, CSV, and tags. See Configuration.
Licensing
The LoRaWAN module is a paid module and participates in Ignition licensing. It runs in trial mode until licensed.
When the trial expires, the network layer is disabled: the UDP server, uplink, and downlink processing stop, [LoRaWAN] tags report a Bad_TrialExpired quality, and the downlink REST endpoint returns HTTP 503. Registered gateways, devices, and decoders are untouched.
Re-activating the license restarts the network layer live, with no module restart. Activate a license or reset the trial from Config > System > Licensing. Licenses are available from the OperaMetrix marketplace.
Supported Regions
The module supports 11 regional frequency plans, default EU868 — see Configuration → Supported Regions for the list.
Architecture
The module implements a LoRaWAN network server inside the Ignition gateway. When a device transmits data:
- LoRaWAN gateways receive the RF transmission and forward it via UDP (Semtech Packet Forwarder protocol) to the module's UDP server (default port 1700)
- The network server performs uplink deduplication across multiple gateways
- The device registry validates the frame (OTAA join or data frame), verifies the MIC, and manages session keys
- Payload decoders (JavaScript) transform raw bytes into meaningful values
- All data is exposed in real time through the
[LoRaWAN]tag provider (Devices/*,Gateways/*,_Meta/*) - For downlinks, messages are queued and transmitted during the device's RX window
Configuration is persisted in the gateway's internal localdb via PersistentRecord (there are no Ignition "resources" or OpenAPI CRUD routes on this build); device runtime state (session, downlink queue, nonces, status) is stored as a JSON blob per device.
Data Flow
- Uplink: Device transmits → Gateway receives → UDP to Ignition → frame decrypted/verified/decoded → Tags updated
- Downlink: Queue via tags or REST → Wait for RX window → Gateway transmits → Device receives
- Join (OTAA): Device sends JoinRequest → Server validates DevNonce and MIC → JoinAccept sent → Session established