LoRaWAN in Multiservice Projects: Gas, Water, and Heat in One Network 

Why the Multiservice Approach Is Becoming Relevant

In utility infrastructure, each resource will have developed separately over a long period of time. The water utility managed its own meters, the heat supply company was responsible for its own metering units, and the gas service took care of its devices and operating rules. At the process level, this is understandable, but at the data level, such fragmentation creates additional costs.

If each service builds its own communication channel, then parallel networks, different contractors, platforms and maintenance rules appear. For a new residential complex, this means more engineering decisions at the design stage, and for a municipality, it makes it harder to scale metering across districts, and for a homeowners’ association, it becomes more difficult to obtain a complete picture of consumption and the building’s technical condition.

The multiservice approach to resource management does not eliminate the sector-specific requirements of gas, water and heat. Instead, it solves a different task by creating a common communication foundation through which different devices can transmit data to a single system or to several metering systems using integrations. 

As a result, the network becomes infrastructure for urban data.

Market growth confirms that such solutions for multi-utility metering are no longer niche. According to IoT Analytics, the number of connected IoT devices worldwide reached 21.1 billion in 2025 and may grow to 39 billion by 2030. For the utility sector, this means a gradual shift from point-based connections to large-scale data collection following device integration from distributed facilities.

^{One Network – Multiple Services} 

How LoRaWAN Works in Metering Tasks

LoRaWAN belongs to the family of low-power wide-area networks. For water, gas, heat meters, this is an important combination, because meters and radio modules are often installed in basements, wells, technical cabinets, stairwells or rooms without a permanent power supply. The device must transmit small data packets and operate on battery power for years, rather than requiring regular maintenance.

In a typical setup, the radio module reads data from the meter or receives pulses from its output, then transmits them to a gateway. The gateway is connected to the network server, and from there the data is sent to an application system, consisting of a monitoring dashboard, billing system, dispatch center or facility management system. 

For the end user, it looks simple: readings appear in the interface without the need to visit apartments, basements or wells.

The strength of LoRaWAN for water, gas, and heat monitoring is that a single gateway can serve a large number of devices within a district, residential complex, industrial site, or municipal facility. At the same time, the network can be private, with the customer deploying its own gateways and controlling the infrastructure. This is convenient for projects where it’s necessary to manage coverage, security, and data transmission costs.

Of course, there are no universal networks without limitations. The radio signal depends on terrain, building density, construction materials, installation depth, and antenna placement. Therefore, before scaling, it’s important to carry out radio planning or a pilot project to test connectivity in basements, technical rooms, wells and remote areas. These are the points that most often become critical for the quality of the project.

Water: Mass Metering and Anomaly Detection

Water supply is one of the most typical scenarios for LoRaWAN, with water meters often installed on a large scale in apartments, commercial premises, building-level metering units, technical areas, pumping stations and wells. The amount of transmitted data is usually small, and the transmission frequency (sometimes several times a day or according to a set schedule), can be moderate.

For a water provider, remote metering reduces dependence on manual submission of readings. This is especially important when some subscribers forget to send data, access to meters is limited, and charges have to be based on estimated values. Automated collection makes it possible to see actual consumption more often and detect sharp deviations quicker.

For homeowners’ associations and property management companies, the value appears at the balance level. If the sum of apartment meter readings differs from the readings of the building-level meter, this is a reason to check for leaks, unmetered connections, faulty devices, or data errors. LoRaWAN doesn’t eliminate losses by itself, but makes them more visible for analysis.

In water projects, leakage, pressure or level sensors are often added to meters. This expands the scenario from metering to monitoring the condition of the network. For example, nighttime consumption may indicate a hidden leak, while a drop in pressure may point to a problem in a specific section. As a result, the dispatcher receives not only readings, but also early signs of an emergency situation.

^{From Metering to Control: How LoRaWAN Helps Detect Anomalies in Water Supply}

Gas: Careful Digitalization and Reliability Requirements

Gas metering requires a more cautious approach than water metering. Industry regulations, equipment certification, installation safety, and correct handling of devices are especially important here. That’s why, in gas projects, digitalization often relies on compatible radio modules, pulse outputs, specialized meters, and strictly regulated operation.

LoRaWAN can be useful where readings need to be collected regularly from a large number of gas devices without frequent physical access to them. This reduces the number of subscriber visits, helps minimize data entry errors, and gives the supplier a more timely view of consumption. The effect is especially noticeable in the private sector, cottage communities, distributed facilities, and residential complexes with a large number of subscribers.

At the same time, it’s important not to promise something that the technology cannot do on its own. Transmitting readings is not the same as automatic control of gas infrastructure. If a project requires remote shutoff, tamper detection, alarms, or additional safety functions, they must be provided at the level of compatible devices, regulations, and operational approval.

For the customer, the key criterion is not only communication range, but also data reliability. Gas readings are used for billing, so protection against message loss, correct device identification, an event log, and the ability to integrate with the metering system are important. The better the chain from meter to billing is designed, the fewer disputes arise during operation.

Heat supply differs from water and gas in that metering is often linked not only to consumption volume, but also to temperature schedules, load, weather, the operation of heat substations and the condition of the building. Because of this, remote collection of heat meter readings can be the first step toward more accurate energy monitoring and management.

The International Energy Agency notes that digitalization increases the flexibility of district heating systems, due to smart heat meters and advanced control tools that help better align supply and demand by using data on weather, consumption, and network operation. For cities and large residential complexes, this matters because heat remains one of the most expensive utility services.

LoRaWAN is suitable for transmitting regular data from heat meters, metering units and temperature sensors. In a residential complex, this may include monitoring by buildings, sections, individual heat substations, or commercial premises. For a heat supply company, it means monitoring distributed nodes and comparing actual consumption with calculated models.

For a homeowners’ association, such a system helps better understand where losses or imbalances occur. For example, if one entrance section consistently consumes more heat with a similar area and outdoor temperature, this is a reason to check settings, insulation, circulation, or equipment operation. Data does not replace an engineer, it helps them look for the problem with more direction.

^{Example of comparing actual monthly heat consumption by buildings/sections}

Where One Network Is Truly More Cost-Effective Than Several

A multiservice network is especially justified where device density is sufficiently high. For example, in a new residential complex, data collection can be planned in advance from apartment water meters, building-level metering units, heat substations, commercial premises and technical sensors. Here, one set of gateways serves several tasks, rather than only one type of metering.

For a municipality, similar logic works at the district level. If a network has been deployed for water metering, it can gradually be used for other devices, including flood sensors, manhole monitoring, container site monitoring, street lighting or technical facilities. This lowers the barrier for future scenarios because the basic communication infrastructure is already in place.

For utility providers, multiservice capability helps build joint projects. Water, heat, and gas can remain in separate metering systems, while data transmission can use a shared communication infrastructure. This is particularly relevant if the network is operated by a separate operator or if the municipality is looking at network scalability by creating a common foundation for urban services.

However, the benefit of multi-utility IoT network architecture appears only with the right organizational model. It’s necessary to define in advance who owns the gateways, who maintains the network, who is responsible for coverage quality, how data from different services is separated, and how operation is paid for. Without these agreements, even good technology can become a source of disputes.

What Questions Need to Be Resolved Before Launch

Before implementing LoRaWAN in a multiservice project, it’s worth starting with  a map of the facilities, rather than the choice of devices. Where are the meters installed? In which rooms is the signal weak? Which devices already have pulse outputs or digital interfaces? Which data is needed daily, and which is sufficient to collect once a month? These questions affect the equipment, coverage, and battery life.

The second important question is data transmission frequency. For commercial metering, regular scheduled readings are often sufficient, while emergency sensors require event-based transmission. Heat substations may need more frequent monitoring. The more often a device transmits data, the higher the load on the battery and the network, meaning that operating modes must match the real task.

The third question is integration. If the data remains only in a separate dashboard, its usefulness is limited. For a utility provider, transmission to billing or a metering system is important. For a property management company, exports, reports, and status monitoring matter. And for a municipality, consolidated analytics by facilities and districts is needed. Therefore, at the start, it’s necessary to understand where the data will go and who will work with it.

The fourth question is security and access control. In a multiservice network, data from different services and facilities may be transmitted, so it’s important to separate user roles, protect devices from substitution, record events, and control configuration changes. The more services that operate in one network, the more important governance rules become.

LoRaWAN and NB-IoT: Not Competitors in Every Case

In remote metering projects, LoRaWAN is often compared with NB-IoT. While such a comparison is useful, it shouldn’t be reduced to choosing the “best” technology. LoRaWAN is more often selected where the customer wants to control their own network, deploy gateways on their own premises, and connect a large number of devices with predictable data transmission costs.

NB-IoT, by contrast, is convenient where there is high-quality mobile operator coverage and no desire to build a private network. This may be the right solution for distributed facilities where installing gateways is not economically justified. According to GSMA, by November 2025, 140 commercial NB-IoT networks, 129 LTE-M networks, and 269 mobile IoT networks had been launched worldwide.

In practice, large projects may use a hybrid architecture. For example, LoRaWAN can be used within a residential complex or district, while NB-IoT is used for remote facilities. This makes it possible to choose connectivity based on installation conditions rather than a predefined technology.

For the customer, the name of the network is less important than the reliability of the result. Their focus is on whether readings are collected,  coverage is sufficient in problematic locations, operating costs are clear, device support is available, and integration with metering systems is in place. These are the parameters that determine the viability of the project after the pilot.

How to Evaluate the Results of a Pilot Project

Pilots for LoRaWAN smart metering muli-service projects should test not a presentation image, but a working operating model. It’s not enough to show that several devices transmit data to a screen. Instead, it’s necessary to test connectivity in difficult locations, transmission stability, the accuracy of readings, ease of maintenance, and the clarity of reports for those who will work with the system every day.

A good pilot includes different types of facilities: a basement, technical cabinet, well, room with thick walls, upper floors and a remote point. If the network is intended to serve gas, water, and heat, the pilot should test at least one typical scenario for each utility. In this case, the decision to scale will be based on data rather than assumptions.

It’s worth evaluating not only technical indicators in a potential multi-utility metering LoRaWAN network, but also the impact on the process. How many manual visits can be reduced? How much faster do readings appear? How many manual entry errors disappear? Is it possible to see communication gaps, low battery charge, tampering attempts, or abnormal consumption? These questions are directly related to the economics of implementation.

^{Criteria for Scaling a Multiservice Project}

Jooby RDC: From Meter Reading to Deviation Control

In a multiservice project, value is created not by an individual meter or radio module, but by the entire chain, covering measurement at the facility, data transmission, device status monitoring, and deviation analysis. In this logic, Jooby RDC solutions can be used as an infrastructure layer for remote metering of gas, water, heat, and electricity, where sensors, radio modules, gateways, and smart meters help collect data in LoRaWAN and NB-IoT networks.

Jooby RDC Dashboard complements this layer with a working panel for viewing readings, monitoring devices, and analyzing abnormal situations. For a utility provider, property management company, or a homeowners’ association, this is a way to see the connected infrastructure in one interface to detect data transmission gaps, disputed readings, signs of leaks, and unusual equipment behavior more quickly.

LoRaWAN in multiservice projects is useful where the task is more than connecting several meters, but creating a resilient foundation for remote data collection across different utilities. Gas, water, and heat remain separate engineering systems, but their data can be transmitted through a shared network and used for metering, deviation control, maintenance planning and more transparent operation. 

The success of such a project depends both on the communication technology used, as well as the right architecture. This architecture for a unified network should provide coverage in difficult locations, compatible devices, a clear maintenance model, integration with metering systems, and readiness to work with data regularly, not only at the launch stage.