Private LoRa versus LoRaWAN: different architectures
Sharing radio technology does not imply a shared protocol, network server or compatibility between devices.
LoRa is radio; LoRaWAN defines a network
LoRa is a radio technology; LoRaWAN defines a network protocol and architecture. A private network can use a proprietary protocol over LoRa or implement LoRaWAN. Lux AITHA LoRa uses its own private network at 868 MHz in the EU, coordinated by Router LoRa: it is not a LoRaWAN device.
This distinction prevents a common specification error: requesting a LoRa node and assuming it will work with any existing LoRaWAN infrastructure. Two devices may share a frequency band and modulation without understanding the same messages. Interoperability depends on the protocol, device identification, data format and application integration, as well as the radio characteristics selected for the deployment.
Private describes who controls a network, not which protocol it uses. LoRaWAN supports private, public and other operating models. Comparing private with LoRaWAN therefore requires clarification of whether private means proprietary. In this article, an own private LoRa network refers to the published Lux AITHA implementation, not to every possible private network using LoRa radios.
The LoRa Alliance explains the distinction between LoRa and LoRaWAN and describes a topology involving nodes, gateways and servers. This establishes the general operation of the standard; it does not demonstrate that a particular product implements LoRaWAN. Purchasing or integrating a device requires a specific manufacturer statement and documentation for the proposed version, rather than inference from a radio label.
Follow the message through the system
In a typical LoRaWAN architecture, devices transmit to gateways that carry messages over IP to a network server. The server participates in communication management and passes information towards the application. The project must decide who operates these components, how devices are provisioned and how the application obtains its data. Those decisions remain necessary even when the radio infrastructure is already available.
A proprietary architecture over LoRa can organise communication differently. For Lux AITHA LoRa, Router LoRa concentrates the device network and connects to AITHANEX or the agreed system through 4G, Ethernet or WiFi. Its published datasheet does not require a LoRaWAN network server. The router is separate from the luminaire, rather than being a component within the lighting controller itself.
This affects inventory and maintenance responsibilities. Teams need to understand node and router configurations, Internet backhaul and ownership of each segment. A working radio link is insufficient if the router’s upstream connection fails. Equally, an Internet connection at the gateway does not prove that every lighting point communicates adequately. Testing must cover both directions and all relevant segments of the route.
Interoperability, security and regional bands
LoRaWAN provides a shared communication framework, but business data still needs integration. The application must interpret information and relate it to real assets. With a proprietary protocol, documented interfaces and supplier responsibilities become particularly important. Neither option removes the need to model data, permissions and maintenance workflows. Standardised radio communication and a usable management application are separate layers of the system.
LoRa modulation is not a complete security system. Protection depends on the protocol and implementation, including identity, credentials, permissions and message handling. Specific encryption or authentication mechanisms cannot be inferred merely because a product uses LoRa. An evaluation should request evidence of those mechanisms and define how they will be managed throughout the device’s operating life, including replacement and decommissioning.
In the EU, a configuration at 868 MHz must respect the regulatory conditions applying to the selected subband. Power, channel use and transmission time cannot be chosen freely simply to increase range. Obstacles, antennas, mounting locations and interference affect a link. A distance observed in favourable conditions is not a substitute for measurements in the streets or premises of the actual project.
Choose against explicit requirements
If a contract requires interoperability with a LoRaWAN network, check explicit LoRaWAN support before choosing the equipment. The LoRa label is not sufficient evidence. If a proprietary network is acceptable, evaluate infrastructure, integration documentation and supplier continuity. The choice follows actual responsibilities and constraints, not which name sounds more familiar or which architecture happens to be available for a demonstration.
A useful pilot verifies the complete path: an event at the node, reception by infrastructure, delivery to the application and a return command where appropriate. It also tests failure and recovery of each link. Recording times, states and errors helps separate radio, backhaul and application problems instead of attributing every interruption to the same component or interpreting every missing message as a device fault.
The Lux AITHA technical datasheet documents the private network and product variants. Keeping the statement not LoRaWAN in the specification prevents an unrelated capability from being assumed. If another architecture is required, review it as a separate integration requirement. A general possibility of the technology must not be presented as an already published function of this particular product.