Designing a LoRaWAN Network: From Pilot to City-Scale Deployment

A pilot starts with data requirements and SLA

Before planning gateway placement, it’s important to define in advance what data the network must deliver and under what conditions. 

Even in metering projects, transmission profiles can vary significantly. In some cases, 1–2 messages per 24 hours are sufficient, in others, event-based transmission is required (for example, tampering or accident), and in others, regular downlink is needed for remote configuration or acknowledgments. 

If these parameters are not fixed, the pilot typically becomes averaged and then scales poorly to the city level.

At this stage, it is useful to divide requirements into three layers:

Data requirements – transmission frequency, acceptable latency, packet loss ratio, behavior during temporary IoT sensor connectivity loss (buffering/retry).

Operational requirements – response time to degradation, maintenance windows, target availability by area.

Security requirements – key management, access control, auditing, segmentation.

From this set of requirements, ADR rules, acknowledgment policies, and infrastructure placement principles will later emerge.

Pilot as an engineering validation of the radio environment, not a demonstration of connectivity

Pilots are often conducted in “convenient” areas where everything is predictable. While such a scenario will allow you to see whether the technology works in principle, what it won’t do is show how the network will behave in problematic locations. 

For a project intended to scale to a city, the pilot must include different types of radio environments, for example, dense urban areas, underground spaces, metal shielding, and distributed sites.

During the pilot, it’s important to collect diagnostic metrics and store them in a monitoring system, otherwise, scaling becomes guesswork. In addition to packet delivery, metrics typically include RSSI/SNR, data rate (DR) and spreading factor (SF) distribution, packet loss and retransmission causes, and actual airtime usage.

A separate topic is ADR (Adaptive Data Rate). This mechanism optimizes data rate, airtime, and energy consumption by controlling transmission parameters (spreading factor, bandwidth, TX power). 

ADR should be enabled deliberately during the pilot and is particularly useful for static devices, helping to reduce airtime load while maintaining reliability. If ADR is not validated during the pilot, the network may degrade as the number of devices grows due to inefficient airtime usage.

Placement of initial gateways: coverage, capacity, and repeatability

In city projects, gateway placement errors often appear later. During the pilot, everything may work as intended, but after expansion, unstable zones emerge, retransmissions increase, and load concentrates on certain gateways. To avoid this, two aspects are typically considered simultaneously:

Coverage. First, a backbone layer is formed using LoRaWAN gateways deployment. First, the gateways should be installed in locations with good radio conditions: sufficient height, clear line of sight, and minimal shielding. Then, based on measurements and quality metrics, targeted solutions are added to areas with persistent coverage gaps.

Capacity. Even if coverage appears sufficient, it’s important to assess whether the network can handle future traffic load. In practice, this means controlling airtime for messages, applying a careful acknowledgment policy to avoid excessive downlink, and properly configuring ADR so that transmission modes reduce network load without compromising delivery reliability.

To optimize LoRaWAN network capacity at city scale, repeatability also becomes a requirement. If a pilot gateway is unique in terms of special installation, connectivity, or power conditions, replicating such a node dozens of times will be difficult and expensive. Therefore, it’s useful to standardize typical deployment options during the pilot.

Connectivity and availability: the network starts beyond the radio channel

It’s important to remember when looking to design a LoRaWAN network that connectivity does not end at the gateway. For stable operation, three things are necessary: gateway internet connectivity, the reliability of that connectivity, and clear recovery procedures in case of failures. 

In addition, basic security measures are required, including network segmentation, secure communication channels, and access control for gateway administration.

Gateway internet connectivity. The gateway must reliably forward received radio packets to the server side. As such, it’s essential to determine in advance which type of connection is used (wired, LTE, etc.), what level of availability is required, and how diagnostics will be organized: what constitutes an incident, who responds to it, and how much time is allowed for recovery.

Situations where the problem is not in radio but in the absence of internet. Sometimes, a difficulty arises with smart city IoT networks where it’s impossible or too expensive to provide direct internet connectivity at certain sites. In these instances, architectures are considered where not every gateway connects directly to the internet.

One option is a gateway mesh architecture:

• the Border Gateway has internet connectivity and is connected to the network server
• relay Gateways forward traffic to the Border Gateway via a local mesh network

A mesh architecture does not replace internet connectivity as such, but helps in complex locations where it’s easier to route data to a point with internet access than to provide a separate communication channel at each site.

Core and observability: what is needed to prevent the network from becoming a “black box”

The transition from a pilot to deployment at the district level usually reveals the main problem, which is that the network becomes more complex, and without observability (a system that allows understanding the state of the network and the causes of deviations through metrics and events), it’s difficult to distinguish a local incident from systemic degradation. 

Given this potential issue, it makes sense during the pilot to establish a basic observability layer that involves metrics for gateways and devices, configured alerts, and clear reports on coverage quality.

In practice, this means that the platform should provide answers to the operations team without lengthy manual analysis of logs and data. For example, it should show in which areas radio quality has decreased, that is, where typical reception metrics (SNR/RSSI) have worsened, where packet loss or retransmissions have increased, and where delays or message losses have grown as a result. 

In addition, the platform should help quickly identify unstable gateways for LoRaWAN (in terms of availability and connection quality to the server side) and groups of devices that lose connectivity more often than others or switch to less efficient transmission modes. 

At city scale, this type of monitoring and reporting layer makes it possible to manage the IoT network coverage based on clear metrics and maintain stable service quality.

Scaling: district model and capacity management

Scaling, particularly of smart metering networks, usually occurs in waves: pilot – first district – several districts – city. At each stage, it’s important to maintain uniform standards, because infrastructure and devices will otherwise begin to “live” by different rules, significantly complicating operation.

From an engineering perspective, at city scale the network is most often limited by radio channel capacity and by how exactly devices transmit data. As a result, the project team must define in advance the data exchange profile in the network: set the frequency of message transmission, determine the volume of data in each message, define cases where delivery confirmation is required, and assess what additional service traffic is generated by network responses (downlink).

It’s also important to properly configure ADR, which helps to select transmission modes so that messages occupy less airtime while maintaining delivery reliability.

Jooby products: devices for every level of scaling

When scaling a LoRaWAN project, it’s more convenient when hardware and software support the entire development path of the network — from pilot to city level. In this logic, solutions are typically required at several levels:

Device level (end devices). Radio modules, sensors, and metering solutions that can be standardized in terms of installation and data transmission profile. This allows maintaining repeatability as the device fleet grows.

Infrastructure level. Base stations/gateways for building a LoRaWAN network at the site, district, and city levels, with the ability to unify configurations and operational procedures.

Platform level. Centralized monitoring of the network and devices, control of communication quality, data collection, and integrations with billing/SCADA/IoT platforms.

The Jooby portfolio includes devices for the field level, infrastructure components for building a LoRaWAN network, and software. This makes it possible to develop the project in stages, following LoRaWAN network design best practices, and without changing the architecture each time the coverage area is expanded.

A city-scale LoRaWAN network differs from a pilot in that standards, observability, and capacity management are critical. The pilot must be an engineering validation of a specific type of radio environment, not a demonstration in a convenient area.

Be aware that sometimes challenges occur in LoRaWAN scaling which will usually require a stable backhaul layer and an operational model that allows managing quality by districts. ADR and traffic policy become key tools for preserving LoRaWAN capacity optimization and device lifetime. 

And for complex locations that are part of LoRaWAN network deployment but have limited internet access, relay/mesh gateway architectures can be considered as a separate tool for network expansion.