How Integrators Can Build IoT Solutions Based on LoRaWAN and NB-IoT

First, define the customer’s task, not the technology

Many IoT projects start going wrong when connectivity is chosen too early. It’s easier for an integrator to sell a “LoRaWAN network” or “NB-IoT devices,” but the customer does not need a network. What the customer actually needs is to achieve specific aims: remote meter reading, alarm control, fewer site visits, monitoring of technical rooms, loss detection, integration with billing, or integration with dispatching systems.

Before designing the project, several parameters should be fixed: 

• what data needs to be collected 
• how often it should be transmitted 
• how many points will be connected during the first stage and after scaling
• where the devices are located 
• whether power is available 
• who will maintain the network 
• where the data should go
• what actions should be triggered after an event

For example, in smart metering, regular readings, consumption logs, tamper detection, battery status, and data transfer to a metering platform are important. For flood monitoring, it’s the event itself and response speed that matter. For industrial telemetry, thresholds, history, alarms, and data transfer to SCADA or another remote monitoring system will be considered the priorities.

LoRaWAN and NB-IoT solve different tasks

For an integrator, it’s important to understand the benefits of LoRaWAN and NB-IoT, and then use each technology correctly. Both belong to LPWAN solutions, but they differ in deployment logic, network responsibility, and operating model.

LoRaWAN for IoT integrators is suitable when the customer or integrator is ready to build their own or private network. This is convenient for residential complexes, industrial sites, municipal facilities, campuses, water utilities, heat networks, and other territories where many devices are located within one area. The advantage of LoRaWAN for IoT integrators is control over coverage, gateways, the server, connection policy, and further network expansion.

NB-IoT is chosen when mobile operator infrastructure needs to be used and there is no need to deploy proprietary gateways. This is convenient for distributed facilities located far from one another: meters in different settlements, remote cabinets, separate technical rooms, and facilities in areas where operator coverage is already available. 

The advantage of NB-IoT is a ready-made network, standardized cellular infrastructure, and the ability to launch projects faster without building a radio network.

The practical conclusion is simple: LoRaWAN is usually stronger where there are many devices in a controlled territory and a proprietary infrastructure is needed. NB-IoT is more convenient when facilities are widely distributed and mobile operator coverage is already available.

Architecture should be designed as a system, not as a set of devices

IoT deployment for integrators should begin with an architecture diagram. It should show the entire chain, including sensor or meter, radio module, data transmission network, server layer, IoT platform, integrations, user interfaces, and operating rules.

A typical architecture looks like this: the device collects data from a sensor, meter, or monitored unit; LoRaWAN or NB-IoT transmits the data to the server; the platform receives messages, decodes them, links them to facilities, stores history, displays statuses, and transfers the data further. After that, integration with billing, ERP, CRM, SCADA, a BI system, dispatching software, or a customer portal is possible.

At this stage, it’s vital to determine immediately where data normalization will be performed. Devices of different types may transmit payloads in different formats. If a unified processing layer is not prepared, the project will quickly turn into a set of fragmented integrations. Therefore, IoT platform integration solutions should include decoding, data quality checks, linking data to facilities, event processing, API, export, and logging.

Integrators need a verifiable coverage model

Connection quality cannot be guaranteed based only on a map or a facility description. For LoRaWAN, it’s necessary to assess gateway placement, installation height, antenna type, building density, basements, metal cabinets, shafts, and possible interference. For NB-IoT, the availability of a specific operator’s network must be checked exactly at the device installation points, including basements, technical rooms, and closed cabinets.

A pilot should be carried out before scaling. During the pilot, it’s important to verify not only whether data is transmitted, but also stability: RSSI/SNR for LoRaWAN, cellular signal quality for NB-IoT, the percentage of missed transmissions, retransmissions, message delivery time, device behavior in difficult locations, and battery consumption at the selected transmission interval.

A good practice is to divide points into typical and problematic ones. Typical points demonstrate the basic operability of the solution. Problematic points help identify in advance where additional LoRaWAN gateways, external antennas, another installation method, or an alternative connectivity technology may be required.

Devices should be selected based on service life and maintenance

For the customer, it’s not only the price of the device and support for the required protocol that matter. In an IoT project, autonomy, housing, protection rating, compatibility with specific meters or sensors, logging, remote configuration, tamper detection, battery status, and the ability to work in real facility conditions are critical.

For smart metering projects, it’s necessary to check the pulse coefficient, sensor connectivity and compatibility with the meter, cable length, installation method, sealing conditions, housing protection, and data transmission frequency in advance. For monitoring engineering infrastructure, the type of measured parameter, thresholds, accuracy, temperature range, and maintenance scenario must be defined.

Battery capacity should be considered separately. Because the data transmission frequency of batteries directly affects device service life, if the customer first asks for hourly transmission and then expects 10 years of operation without battery replacement, the integrator must show the trade-off between transmission frequency, autonomy, and maintenance cost.

The platform should cover not only data collection, but also operation

A successful IoT solution for system integrators does not end with device connection. After launch, a longer stage begins: operation. The platform should support not only viewing readings, but also device management, status monitoring, alarms, logs, object groups, user roles, and integrations.

For a utility provider or management company, practical functions are important, such as seeing when data is not coming in, receiving low battery warnings, monitoring tampering, filtering alarms, exporting readings, comparing periods, tracking connection quality, and quickly finding problematic points.

If the platform does not help maintain the device fleet, the integrator will have to compensate for this with manual work. At the pilot stage, this problem may be barely noticeable, but when scaling to thousands of devices within utility IoT networks, it becomes critical.

Integrations should be designed before deployment, not after it

In many projects, the customer first launches remote data collection and then asks to transfer data to billing, SCADA, ERP, or a dispatching system. If the integration layer has not been planned in advance, the project has to be reworked.

The integrator should determine in advance which systems will receive data, in what format, at what frequency, and who is responsible for exchange errors. For some projects, an API or regular export is sufficient. Others require MQTT, webhooks, OPC UA, Modbus TCP, or integration through an intermediate gateway.

It’s imperative to separate “raw” data from prepared business events. The operator does not always need the full stream of technical messages, what’s more important is to see clear statuses: the meter is not transmitting data, a threshold has been exceeded, tampering has been detected, the battery requires attention, or the facility needs inspection. This approach makes IoT system integration useful for business, as well as being technically correct.

Project economics should be calculated for the entire life cycle

For the customer, the total cost of an IoT solution consists of more than the price of devices, including survey, installation, connectivity, gateways or SIM cards, platform, integrations, support, battery replacement, site visits, updates, staff training, and system expansion.

For LoRaWAN, the cost of gateways, their placement, maintenance, and redundancy should be considered. For NB-IoT, operator tariffs, coverage quality, and dependence on an external network matter. For both technologies, device operation, incident handling, and integration support should all be taken into account.

The integrator benefits when they show the customer not only CAPEX, but also OPEX: how much one point will cost per year, how the number of site visits will change, which processes can be automated, where time losses will be reduced, and how the system will scale as the number of devices grows.

How an integrator should structure the project by stages

The optimal scenario with IoT deployment for integrators begins with a survey and formalization of requirements. At this stage, data should be collected about facilities, metering devices, installation conditions, coverage, requirements for transmission intervals, and future integrations.

The next stage is a pilot, which should include different types of facilities: simple, typical, and difficult. The pilot is needed not to demonstrate an attractive interface, but to verify connectivity, installation, data quality, staff response, platform operation, and compatibility with the customer’s processes.

After the pilot, the standard solution should be fixed: the device list, installation rules, transmission settings, coverage requirements, object structure in the platform, user roles, integration format, and maintenance regulations.

Only after all of these stages should scaling begin. Mass deployment should proceed in batches, with installation quality control, data verification, staff training, and a clear acceptance procedure for each zone.

Common IoT project mistakes

The most common mistake is choosing a technology without considering the facility. LoRaWAN may be ineffective without proper gateway placement, while NB-IoT may operate unstably in basements or metal cabinets if coverage has not been checked on site.

The second mistake is underestimating integrations. If data cannot be transferred to the customer’s systems, the IoT platform becomes an isolated interface rather than part of the operational infrastructure.

The third mistake in LoRaWAN and NB-IoT solutions is the absence of an operating model. It’s necessary to define in advance who responds to missing data, replaces batteries, maintains gateways, checks integration errors, and is responsible for keeping facility directories up to date.

The fourth mistake is making the first launch too broad. At the risk of stating the obvious, it’s far better to start with a limited pilot and prove the model works than to connect thousands of devices immediately and encounter problems with coverage, data, and support.

What the integrator should offer

A strong customer proposal should include not just equipment, but a ready-made IoT infrastructure architecture. This architecture should include devices and sensors, LPWAN network integration, LoRaWAN deployment or NB-IoT connectivity, a platform for data collection and management, integrations with external systems, a service model, and a scaling plan.

For the utility sector, this may include smart metering platforms and IoT networks for utility companies. For industrial facilities, remote monitoring systems for technical rooms, distributed nodes, and autonomous sensors. And for developers and management companies, the IoT architecture is likely to be based on unified infrastructure for water, gas, heat, electricity, and engineering event metering.

An integrator creates value when they understand how to build NB-IoT solutions with LoRaWAN that offer the customer a complete system, not a sensor or communication channel: device, network, platform, data, integrations, and operation. This approach helps launch IoT projects that remain manageable both at the pilot stage, but also after scaling to hundreds or thousands of connected points.