NB-IoT or LoRa: choose for the installation, not just the radio
Coverage, infrastructure and operating responsibilities determine connectivity for each lighting point.
The main difference is who operates the network
NB-IoT uses an operator’s mobile network; an own LoRa network needs local infrastructure to connect devices to the platform. For lighting, the choice depends on coverage, point distribution, maintenance and recurring costs. Lux AITHA offers LoRa and NB-IoT variants sharing the Zhaga Book 18 interface and DALI control, with connectivity selected for the site.
Comparing radios without mapping the installation often conceals the actual problem. A street with many nearby points and a suitable router location presents different conditions from isolated points distributed across a municipality. Responsibilities also differ: maintaining a private network is not the same as purchasing mobile service per device and managing its contract, configuration and operating conditions throughout the deployment.
For the published Lux AITHA LoRa implementation, the network is private and proprietary at 868 MHz in the EU, not LoRaWAN. Router LoRa links nodes to AITHANEX or the agreed system through 4G, Ethernet or WiFi. Lux AITHA NB-IoT communicates through the mobile network without an intermediate Router LoRa; a compatible operator service is still required at the installation.
Neither option is universally cheaper or more reliable. A comparison should include installation, connectivity, equipment access, spares and diagnostic time. Low upfront cost may transfer obligations into operation. Shared infrastructure can spread costs across many points, but still needs locations, power supplies and maintenance owners. Identifying these dependencies early is more useful than comparing subscription prices in isolation.
Confirm the service and test the site
For NB-IoT, check service availability, bands supported by the module and the SIM and contract conditions. Mobile coverage for phones does not automatically demonstrate usable NB-IoT coverage. Access conditions, roaming and connectivity to the backend must be reviewed with the operator for the intended country and installation. Assumptions from another deployment may not apply to a different service agreement.
Testing should use the actual device and antenna at the intended mounting position. A measurement taken at street level does not necessarily describe a luminaire or a closed cabinet. Observe network registration, data delivery and command response over a representative period, rather than simply checking that the device connects once. Record configuration alongside the results so later comparisons remain meaningful.
For an own LoRa network, study node-to-router links, obstacles and the router’s Internet connection. Frequency and configuration must respect the regulatory conditions of the region. A catalogue distance or favourable simulation does not remove the need to verify communication at difficult points. Include the router’s backhaul in testing because local radio success alone does not establish delivery to the application.
Latency, energy and maintenance
The useful latency measurement covers the complete process, from a command to verified execution. It depends on the network, device, configuration and application. Energy-saving modes may affect when equipment is available to receive messages. Instant action should not be promised without measuring the proposed system. The required response time should follow the operating task rather than a generic radio comparison.
Energy use should not be compared through one generic figure either. Message frequency, signal conditions, retries and configuration affect consumption. In connected lighting, controller power is also part of the luminaire installation and must be checked against its interface. Battery life achieved by another type of sensor is not a Lux AITHA specification and should not be used to describe this product.
Recovery after an interruption is an important maintenance criterion. Decide how to distinguish communication loss from a lighting fault, which information remains recorded and how service resumes. A private network also requires router checks; a mobile network needs a procedure for investigating the service, SIM and device without attributing every incident to the operator. Clear responsibilities shorten diagnosis even before extra monitoring is added.
Turn comparison into acceptance tests
Start with four concrete questions: where the points are, who maintains infrastructure, what communication the operation needs and what lifecycle cost is acceptable. Answers eliminate unsuitable options before secondary features are compared. Then agree acceptance evidence for coverage, information delivery, commands and recovery for each variant under consideration. Each requirement should have an observable outcome and someone responsible for accepting it.
If both options are viable, a pilot should use comparable conditions and record exceptions. Comparing a well-positioned mobile node with a private network lacking a suitable router site is not useful. Document observed differences alongside configuration and environment, so the outcome can be explained and reproduced as the installation expands. A pilot result without its conditions is difficult to apply elsewhere.
The Lux AITHA technical datasheet identifies product interfaces and variants; the operator confirms the specific available service. For LoRa architecture, the guide to private LoRa versus LoRaWAN helps avoid confusing protocols. Separating general technical knowledge from product conditions prevents a possible benefit of a technology from becoming an unsupported guarantee for the installation.