How LoRaWAN Gateways Work: A Practical Guide for Resource Providers 

However, when choosing a solution for the implementation of remote meter reading, attention is often focused on meters and sensors rather than the gateway. So, while people understandably want to know about what resources the meters and sensors measure, how they’re powered and how long the battery lasts, it’s actually the gateway that determines the reliability of a system.

The LoRaWAN gateway is often perceived as a humble “communication box”, but in practice, this is the piece of hardware responsible for transferring data from hundreds or thousands of devices to the metering system and its overall success.

LoRaWAN is considered ideal for a smart metering system, such as a network created for the supply of water, gas, heat, and electricity, as well as for monitoring flooding, pressure, temperature, and the condition of engineering infrastructure. It is an LPWAN technology, designed not for streaming video or large files, but for short messages from a large number of low-power devices. According to IoT Analytics, the number of connected IoT devices worldwide was expected to reach 21.1 billion by the end of 2025 and 39 billion by 2030. This demonstrates the overall growth in demand for large-scale data collection networks and here we explain how LoRaWAN works step by step.

^{Growth of IoT Devices Worldwide: Global Number of Connected Devices, Billion}

What Is a LoRaWAN Gateway in Simple Terms?

A LoRaWAN gateway is a device that receives radio signals from LoRaWAN sensors, meters, and modules, and then sends this data via the internet to a network server. In the opposite direction, it can send commands to devices, for example, to configure the transmission interval or confirm that a message has been received.

In the LoRaWAN architecture, the gateway does not understand the business meaning of the data. It doesn’t determine how many cubic meters of water a subscriber has consumed or calculate a building’s balance. The gateway’s task is to receive a radio packet, convert it into an IP packet, and forward it on. The LoRa Alliance describes this architecture as “star-of-stars”, where end devices transmit messages to one or more gateways. The gateways then forward them to a central LoRaWAN network server via a standard IP connection where the information is made available in a data collection platform.

This is an important difference from conventional systems, where a device is linked to a specific base station. In LoRaWAN, the same packet can be received by several gateways. The network server then removes duplicates, assesses reception quality, and forwards only the necessary data to the application.

For a resource provider, this means the network can be built flexibly, with one gateway serving many meters in a building, district, industrial zone, or distributed infrastructure. However, connection quality depends not only on the gateway itself, but also on the installation location, antenna, mounting height, surrounding buildings, interference, and the data transmission scenario.

LoRaWAN Network Architecture Explained: What Elements Make Up a LoRaWAN Network?

A typical LoRaWAN network consists of four layers: end devices, gateways, a network server, and an application system.

End devices are water, gas, heat, and electricity meters, radio modules for older meter models, and various sensors, including those for temperature and pressure , manhole opening, and equipment status. The devices typically involved in LPWAN architecture transmit short messages over the LoRa radio channel and often run on batteries for several years, spending most of their time in sleep mode.

The gateway receives the radio signal from the devices and sends it to the internet. To connect to the server, it can use Ethernet, Wi-Fi, 4G/LTE, or another communication channel. In utility projects, Ethernet is most often used where a stable wired network is available, while mobile communication is used where the site is remote or no ready-made infrastructure exists.

The network server manages the radio network: it checks packet validity, removes duplicates, controls communication parameters, routes messages, and manages acknowledgements and downlink commands.

The application system works with the decrypted data: it displays readings, generates reports, transfers data to billing, CRM, SCADA, or dispatching systems.

This separation is useful for network scalability. For example, a water utility can start with a pilot project in several buildings and then expand to an entire district without fully replacing the architecture.

How Data Travels From the Meter to the Metering System

Imagine an apartment building equipped with smart water meters with LoRaWAN modules. Every few hours, each meter wakes up, creates a message containing the readings, battery level data, and service information, and then sends it over the radio channel.

The gateway, installed on the roof, a technical floor, or in a room with good coverage, receives this signal. If several gateways are located nearby, the packet may be received by multiple devices at once. This is not an error, but a normal feature of LoRaWAN, because the network server selects the required packet and filters out duplicates.

Using packet forwarding, the gateway then sends the data to the network server via the internet. The server verifies the authenticity of the message, applies security rules, identifies the device, and forwards the payload to the application. There, the data becomes understandable to the user and will include meter number, facility, apartment, current reading, date and time, and possible events or errors.

^{Data Path in a LoRaWAN Network: From Meter to Metering System}

If the system uses confirmed messages, the server can send a response back. However, in LoRaWAN, it’s important not to overuse downlink commands. The network operates most efficiently when the main traffic flows from devices to the server, while reverse commands are used sparingly and only in important cases.

Why a Gateway Is Not Just a “Signal Booster”

Sometimes a LoRaWAN gateway is mistakenly perceived as a repeater that simply boosts the radio signal. This oversimplification can lead to incorrect network design.

A gateway does not amplify every message and does not, by default, create a “sensor – gateway – gateway – server” chain. What it does do however is serve as an access point between the LoRa radio segment and the IP network. That’s why, when designing a network, it’s important to consider not only range, but also radio coverage, capacity, the number of devices, message frequency, and the quality of the internet connection.

For example, a single gateway may reliably receive signals from devices over a considerable distance in open terrain (otherwise known as the signals Rf coverage). However, in dense urban environments, basements, reinforced concrete, metal doors, shafts, and engineering structures can significantly change the real-world picture. Therefore, there are no definitive answers to the questions of how many meters can one gateway serve and how far can LoRaWAN transmit, without a site survey and load calculation.

For utility projects, the gateway should be treated as an infrastructure element, not as an accessory to a meter. The stability of data collection depends on its placement and configuration, especially if the network is expected to operate for years.

Main Types of LoRaWAN Gateways

Gateways can generally be divided into indoor and outdoor models. Indoor gateways are installed inside buildings, in control rooms, server rooms, technical rooms, entrances, or offices. One indoor vs outdoor gateway difference is that while they are easier to install, they are usually less suitable for covering large areas if there’s no option to place the antenna externally.

Outdoor gateways are designed for installation outside, on rooftops, masts, or façades. They have a protected enclosure, resistance to temperature, moisture, and dust, and support for connecting an external antenna, grounding, and backup power.

For resource providers, an outdoor gateway often becomes the main option for covering city blocks, pumping stations, boiler houses, wells, industrial sites, and municipal infrastructure.

Backhaul should be considered separately – the channel through which the gateway connects to the internet. Ethernet is usually more stable and predictable. Mobile communication is convenient for remote sites, but requires checking operator coverage, signal quality, tariffs, and SIM card reliability. In critical projects, redundancy may be used: for example, Ethernet as the primary channel and LTE as the backup.

What the Gateway Installation Location Affects

In terms of IoT gateway installation requirements, their location is often more important than the equipment’s nominal power. A well-chosen placement point has a greater effect than trying to compensate for a poor radio environment with a more expensive device.

In urban areas, height, a minimum number of obstacles, access to power, vandalism protection, and a stable internet connection are usually important. A roof or an upper technical floor often provides better coverage than a basement or a room inside the building. If most meters are located in basements, gateway density may have to be increased through additional coverage points or a different placement scheme.

For rural and distributed sites, terrain, distances, the availability of masts, trees, metal structures, and seasonal changes need to be taken into account. For example, foliage in summer can degrade the radio channel, while in winter the equipment must operate reliably at low temperatures.

Before large-scale deployment, to establish the best placement for IoT gateways,it’s advisable to carry out radio planning and test measurements. In practice, this reduces the risk of discovering after purchasing the equipment that some meters regularly fail to connect.

How Many Devices Can One Gateway Serve?

In theory, a single LoRaWAN gateway can receive messages from a large number of devices. However, the actual capacity depends on the transmission frequency, message size, SF (spreading factor) used, number of channels, interference level, duty cycle limits, and the share of confirmed messages.

If a meter sends a short packet once or several times per day, the network load will be low. If hundreds of devices send data every few minutes, the load increases sharply. In addition, devices with a poor signal use slower transmission modes, occupy the air longer, and reduce the overall network capacity.

In the European EU863-870 band, the LoRa Alliance recommends a 1% duty cycle limit, meaning that a device may transmit for no more than 1% of the time in the corresponding band. This is necessary to reduce interference and allow devices to coexist in the unlicensed spectrum.

^{LoRaWAN Gateway Capacity: Key Load Factors}

Why Downlink Should Be Used Carefully

In remote metering projects, the main task is usually to regularly receive data from devices. This is uplink traffic. Reverse messages from the server to the device, or downlink, are needed less often, such as for acknowledgements, configuration changes, synchronization, or special commands.

The problem is that downlink puts a heavier load on the gateway and the radio channel. If the system requires every message from every meter to be acknowledged, the network may become less stable, especially with a large number of devices. Therefore, confirmed messages should be used only where they are truly necessary.

For resource providers, this is a practical issue. For example, daily water or heat readings can often be transmitted without constant acknowledgement if the system monitors missed messages and retransmissions. Critical emergency events – such as leakage, enclosure opening, or a sudden pressure drop – may require more reliable delivery logic.

A well-designed LoRaWAN network is a balance between reliability, energy consumption, data frequency, and radio channel capacity.

Security: What the Gateway Sees and What Remains Protected

In LoRaWAN, security is built into the protocol level. The LoRa Alliance states that the specification uses two cryptographic domains: the Network Session Key for interaction between the device and the network server, and the Application Session Key for protecting data at the application level. AES algorithms are used for authentication, integrity, and encryption.

This means that the gateway should not have access to the contents of the payload. What the gateway does is forwards the packet, but doesn’t decrypt the meter readings. In a properly designed architecture, the data is decrypted at the application or server level, where the corresponding keys are available.

However, security depends not only on the standard, but also on implementation. It’s important to store keys properly, use OTAA activation where possible, protect access to gateways, update firmware, restrict administrative interfaces, and control physical access to the equipment.

For municipalities, homeowners’ associations, and resource providers, this is especially important because metering data can be sensitive, and the network must operate for a long time without constant manual maintenance.

LoRaWAN and NB-IoT: Where the Gateway’s Role Differs

Resource providers often compare LoRaWAN and NB-IoT. Both technologies are suitable for transmitting small amounts of data from a large number of devices, but their architectures are different.

In NB-IoT, the device connects to a mobile operator’s network. The resource provider usually does not directly manage the radio network or install its own base stations. This is convenient when operator coverage is good, tariffs are clear, and there is no desire to maintain dedicated infrastructure.

In LoRaWAN, an organization can build a private network and control gateway placement, coverage, the server side, and data transmission rules. This is especially useful for residential complexes, urban districts, water utilities, industrial sites, and municipal projects where many devices are concentrated within a limited area.

The choice does not always have to be “either-or.” In some projects, LoRaWAN is used for dense local infrastructure, while NB-IoT is used for individual remote sites. The key is to calculate not only the device cost, but also the cost of connectivity, maintenance, coverage, integration, and network ownership over several years.

How to Assess Whether a Site Is Ready for LoRaWAN Deployment

Before purchasing gateways and meters, it’s worth answering several practical questions. How many devices need to be connected now, and how many will appear in 2–3 years? Where are they located: in apartments, basements, wells, technical rooms, or outdoors? And how often does the data need to be received: once a day, once an hour, or every 15 minutes?

It’s also important to understand which data is critical. For commercial metering, the regularity of readings is important. For emergency sensors, the speed of event transmission matters. For dispatching engineering facilities, a combination may be important in order to cover periodic data plus immediate alerts.

The next step is a site survey. Radio coverage, possible gateway installation points, availability of power, internet connectivity, installation conditions, and equipment protection requirements are checked. After that, the approximate number of gateways can be calculated and the antenna type selected.

Integration should be considered separately. Data should not simply arrive on the server, it must reach the systems where people actually work with it: billing, personal accounts, dispatching systems, ERP, SCADA, or analytics platforms.

Common Mistakes in Network Design

The first mistake is planning coverage based only on the rated range. In real-world conditions, concrete, metal, basements, terrain, and dense urban development matter more than advertised kilometers. That’s why pilot measurements are almost always more useful than a theoretical estimate.

The second mistake is installing the gateway where it’s convenient to connect power, rather than where radio coverage is better. Sometimes moving the device several floors higher or installing an external antenna can improve connection quality several times over.

The third mistake is transmitting data too frequently. If the business task requires one reading per day, it does not always make sense to send data every five minutes. This increases radio channel load, shortens battery life, and makes scaling more difficult.

The fourth mistake is failing to account for maintenance. The gateway must be accessible for diagnostics, updates, power checks, and SIM card or antenna replacement. At the same time, it must be protected from moisture, lightning-related risks, vandalism, and accidental shutdowns.

Which Gateway Characteristics Matter When Choosing One

For resource providers, radio parameters are not the only important factor. What’s also necessary is to consider the full set of characteristics, including frequency band, number of channels, support for the required region, enclosure type, power supply, redundancy, communication interfaces, support for PoE, LTE, GPS, remote management, and event logging.

The frequency plan must comply with regional requirements. In October 2025, the LoRa Alliance published Regional Parameters RP002-1.0.5, which describes LoRaWAN parameters for different regulatory regions. This is important to consider when certifying devices and choosing equipment for a specific country.

For outdoor installations, attention should be paid to the enclosure protection rating, operating temperature range, lightning protection, connector quality, and the ability to mount the device on a mast or wall. For resource supply facilities, remote diagnostics are also important: backhaul channel status, reception level, number of packets, errors, and reboots.

A good gateway is not just a radio module in an enclosure, it’s an infrastructure node that must operate reliably without the constant presence of an engineer.

Example Solution: Jooby Gateways for LoRaWAN Networks

For remote metering projects, it’s vital to choose a gateway by the number of channels, as well as by connection stability, security, remote maintenance capabilities, and reliable operation in unstable conditions. Jooby Gateways – gateways for data collection in LoRaWAN networks – can be considered as an example of such a solution.

Jooby gateways are available in indoor and outdoor versions, including 8- and 16-channel models, as well as versions with backup power. They can be used in water, gas, heat, and electricity supply projects where stable data collection from meters, radio modules, and sensors is required.

OpenVPN and WireGuard are provided for secure connections, while the White List function helps filter out unnecessary traffic before it’s transmitted to the network server. Packet buffering reduces the risk of data loss during temporary communication interruptions, and remote software updates simplify gateway maintenance without site visits.

For locations without stable internet access, a mesh architecture based on ChirpStack can be used, where one Border Gateway connects to the server, while the other gateways operate as Relay nodes. This makes it possible to expand LoRaWAN coverage across remote and distributed sites without connecting every gateway to the internet.

Where LoRaWAN Gateways Deliver the Greatest Value

LoRaWAN usually delivers the greatest value where many devices transmit small data packets and laying cables is not economically feasible. This includes apartment buildings, residential complexes, boiler houses, pumping stations, wells, heat substations, industrial sites, parking facilities, municipal facilities, and distributed urban infrastructure.

For water utilities, this may include collecting readings from building-level and individual meters, pressure monitoring, leak detection, and tank level monitoring. For heat supply, it can include monitoring heat substations, temperature, pressure, and consumption. While for developers, it means preparing buildings for operation with remote metering infrastructure already built in.

For homeowners’ associations and property management companies, LoRaWAN can be a way to move away from manual meter reading, disputes caused by late data submission, and lack of transparency in consumption. However, the result depends on proper task definition, meaning that the network must be designed for real-world scenarios, not simply for equipment installation.

^{LoRaWAN Project Cost: What the Budget Consists Of}

Practical Conclusion

A LoRaWAN gateway is a key element of a remote meter reading network. It connects meters and sensors with the server infrastructure, but its role is not limited to simple signal transmission. The stability of the entire system depends on the choice of gateway, installation location, antenna, internet connection, and network settings.

For resource providers, developers, municipalities, and homeowners’ associations, it’s important to start with the question “what task should the network solve?”, rather than how much the gateway costs. The number of devices, transmission frequency, installation conditions, data requirements, security, integration, and maintenance must all be taken into account.

LoRaWAN is well suited for large-scale metering and monitoring where energy-efficient devices, long-range communication, and control over dedicated infrastructure are required. However, the technology reveals its advantages only when properly designed. A correctly installed gateway can collect data from hundreds of devices for years, while a poorly placed one can become the weak link even in an expensive project.

With the continued rise in IoT connectivity, the practical approach to gateway deployment is straightforward: survey the site, test coverage, calculate the load, choose the appropriate gateway type, and plan in advance how the data will be used in metering, dispatching, and resource management. This is how a LoRaWAN network turns from a set of devices into a working tool for decision-making