Best LoRaWAN Gateway Configuration by Application: Metering, Agriculture and Cities

The best LoRaWAN gateway configuration is determined by the application around it, not by one universally superior gateway. A Robustel LoRaWAN gateway used for utility metering may mainly forward thousands of small readings towards a central LNS, while an agricultural site may place more value on cellular backhaul and local operation when fixed connectivity is limited.

Consider three projects that all use LoRaWAN sensors. A utility is connecting meters across residential districts. A farm is monitoring soil, weather and irrigation assets over a dispersed site. A municipality is adding flood, parking and environmental sensors across several neighbourhoods. The radio technology is similar, but the gateway topology, backhaul, server architecture and operating model should not be. In this guide, “best” means the configuration that matches the application’s traffic, coverage and operational requirements, rather than a ranking of gateway products.

One LoRaWAN Configuration Does Not Fit Every Application

Before selecting hardware, define what the gateway needs to accomplish between the sensor and the application.

A Robustel LoRaWAN deployment can be simplified into several decisions:

Application question	Why it changes the gateway configuration
How geographically dispersed are the sensors?	Influences gateway placement and number of coverage points
How often do devices transmit?	Changes airtime and network-capacity considerations
Are payloads small and repetitive or more varied?	Influences application and data-processing requirements
Is fixed IP connectivity available?	Determines whether Ethernet, Wi-Fi or cellular backhaul is appropriate
Where will the LNS run?	Separates forwarding gateways from locally hosted network-server architectures
Does data need processing at the field site?	May require more than packet forwarding
How many sites will operations manage?	Makes remote configuration and fleet visibility more important
What happens when backhaul fails?	Determines how much local autonomy the site requires

A simple meter network, for example, may need little processing at the gateway. The important job is to receive LoRaWAN packets and forward them reliably towards a centrally operated Network Server.

A remote environmental site may have the opposite constraint. Device density could be relatively low, but unreliable WAN connectivity makes local operation and recovery more important.

Robustel’s LoRaWAN Gateway Applications video provides a short visual introduction to how LoRaWAN gateways fit into different application environments. The three scenarios below take the same idea further by looking at the configuration decisions behind each deployment.

Metering: Build for Distributed Devices and Repeatable Operations

Imagine a utility connecting water meters across apartment blocks and commercial districts.

Each endpoint may transmit relatively small readings, but the devices are geographically distributed and expected to remain in service for years. The project is unlikely to be managed as fifty isolated LoRaWAN networks. Operations teams typically need a repeatable architecture that can expand as more buildings or districts are added.

For this type of Robustel LoRaWAN gateway deployment, a practical architecture may look like:

Meters

→ local gateway coverage points

→ Ethernet or cellular backhaul

→ central LoRaWAN Network Server

→ metering platformThe important design characteristic is centralisation of the network layer while keeping radio coverage distributed.

A forwarding-oriented gateway can make sense where the utility already operates an LNS. The gateway does not need to host a separate Network Server at every building; it needs to receive LoRaWAN traffic and provide a reliable path to the common platform.

The Robustel R1320LGe LoRaWAN Gateway is positioned around this type of packet-forwarding architecture. Robustel lists smart utilities and metering among its intended scenarios, with Ethernet, Wi-Fi and 4G/LTE backhaul and support for forwarding towards compatible external LNS platforms. The product page currently notes that the R1320LGe remains under development, so final specifications and commercial availability should be confirmed for a project.

For an established deployment requiring greater architectural flexibility, the Robustel R1520LG LoRaWAN Gateway can also forward traffic to an external LNS through supported methods including UDP, LoRa Basics Station and LORIOT. It additionally provides an embedded ChirpStack option when a contained site needs local LNS operation.

The choice should therefore follow the operating model. A utility already managing one central LoRaWAN platform has little reason to create an independent LNS at every gateway simply because the hardware supports it.

Metering projects should also avoid converting gateway channel count into a fixed device limit. Reporting frequency, spreading-factor distribution, confirmed messages, downlinks and local radio conditions all influence network behaviour. A pilot with 50 meters does not by itself prove the same configuration will behave identically after large-scale rollout.

Agriculture: Design Around the Site That Has the Least Infrastructure

An agricultural project often starts from a very different problem.

Consider a farm using soil-moisture sensors, weather stations and tank-level monitoring across fields and irrigation infrastructure. The sensors may be widely separated, while Ethernet and mains power are available only around a few buildings. Some monitoring points may be several kilometres from the farm office, but actual coverage still depends on terrain, vegetation, antenna position and regional radio settings.

The most useful question is not whether a Robustel gateway has a quoted “long range.” It is:

Where can the gateway be installed so that LoRaWAN coverage, power, cellular connectivity and maintenance access all work together?

A suitable architecture could be:

Field sensors

→ one or more strategically located LoRaWAN gateways

→ cellular backhaul

→ local or external LNS

→ farm-management or monitoring application

The Robustel R1520LG LoRaWAN Gateway provides Ethernet, Wi-Fi and cellular backhaul together with external and embedded LNS options. This makes it possible to choose the server architecture separately from the radio site rather than assuming every agricultural deployment must depend entirely on continuous cloud connectivity.

If the gateway is installed outdoors, the physical protection layer also needs to be designed separately. The R1520LG itself is IP30; it should not be treated as an exposed outdoor gateway without a suitable enclosure. Power availability, antenna placement, temperature and lightning/surge protection remain site-engineering questions rather than features that LoRaWAN solves automatically.

Agriculture can also reach a point where packet forwarding alone is no longer the main requirement. A site may need to combine LoRaWAN sensors with wired instruments or process field data locally before sending it upstream. Robustel positions the LG3120e Industrial Edge Computing LoRaWAN Gateway for scenarios where LoRaWAN connectivity, an integrated LNS and local field-data processing are required together. Its current product page specifically includes smart farming and remote asset monitoring among the example applications. Robustel also currently marks the product as under development, so the required software package, licence and final specification should be confirmed before project design.

A real deployment from another sector demonstrates the same architectural principle without being an agriculture case.

Robustel real-world example: LoRaWAN monitoring for vaccines and laboratories with the R1520-LG

KoolZone operates distributed environmental monitoring across laboratories, hospitals and cold-chain environments. Robustel R1520-LG LoRaWAN Gateways connect sensors to cloud services through cellular backhaul, while RCMS provides remote visibility across the gateway estate. The application differs from agriculture, but the infrastructure problem is comparable: sensing locations are distributed, the local RF environment can be difficult, and sending an engineer to every site for routine troubleshooting is undesirable.

The transferable lesson is that remote applications should be designed around the weakest infrastructure condition—not around the best-connected location used during the pilot.

Smart Cities: Separate Coverage Expansion from Central Operations

A municipality introduces a third configuration problem.

Flood monitors may sit beside waterways, parking sensors along streets, environmental sensors on public buildings and other endpoints across areas with different power, access and backhaul conditions. Trying to make every gateway an independent LoRaWAN system would create unnecessary operational fragmentation.

A city-scale Robustel LoRaWAN architecture is more naturally organised as:

Distributed municipal sensors

→ multiple gateway coverage points

→ available IP backhaul at each site

→ shared LNS infrastructure

→ municipal or third-party applications

The gateway layer expands geographically while server and operational functions can remain central.

This is where backhaul becomes part of topology design. One gateway may use fixed Ethernet from a municipal building, while another depends on cellular connectivity from a cabinet or mast site. Standardising the LoRaWAN architecture does not require every physical site to have identical WAN infrastructure.

The Robustel R1520LG supports Ethernet, Wi-Fi and dual-SIM cellular connectivity together with RCMS-based remote management. These capabilities are relevant when gateway locations are spread across an area where physical access and available infrastructure differ from site to site.

Robustel X Cibicom example: nationwide LoRaWAN network backhaul over LTE450 for Cibicom

Cibicom operates a nationwide LoRaWAN network in Denmark and uses LTE450 to backhaul gateway traffic towards central server systems and customer platforms. The original project used the now-legacy Robustel R3000-LG LoRaWAN Gateway; Robustel identifies the R1520LG as its current replacement. Gateways are deployed at locations that can include masts and third-party properties, making access and ongoing operation part of the network design.

The case is useful because the architecture separates two scaling problems. LoRaWAN coverage expands by deploying radio gateways where required, while network and customer systems remain upstream. A city does not need to reproduce the complete application stack at every coverage point.

This also highlights why “best smart-city gateway” is an incomplete question. The stronger design question is whether each gateway site has the radio position, backhaul and operational support required to function as one part of the wider municipal network.

Compare the Three Applications by Configuration, Not Product Ranking

Metering, agriculture and smart-city deployments may all use the same LoRaWAN standard, yet the pressure on the gateway is different.

Decision area	Metering	Agriculture / remote field	Smart city
Typical topology	Many distributed endpoints with repeatable gateway sites	Sparse or dispersed sites shaped by terrain	Multiple coverage zones across public infrastructure
Main planning pressure	Scale and operational consistency	Coverage, power and backhaul availability	Geographic expansion and central management
LNS direction	Often central where many sites share one network	Local or external depending site autonomy	Common external LNS often suits distributed coverage
Backhaul priority	Ethernet or cellular depending building	Cellular often important where fixed WAN is absent	Mixed Ethernet/cellular infrastructure
Local processing	Usually limited unless integration requires it	More relevant where field data must be processed locally	Depends on municipal application architecture
Remote management	Important as gateway count grows	Important because sites can be difficult to reach	Important across a geographically distributed fleet
Robustel reference	R1320LGe or R1520LG depending LNS role	R1520LG; LG3120e where additional local data processing is required	R1520LG or forwarding-oriented architecture

The table is not intended to turn application names directly into product selections.

For example, not every metering project needs a forwarding-only gateway. A small private metering system may be better served by a Robustel R1520LG running a local ChirpStack instance. Likewise, an agricultural site does not need an edge-computing gateway merely because it is remote.

The configuration should change only when the application requirement changes.

Use the Traffic and Operating Model to Make the Final Choice

Before selecting from the Robustel LoRaWAN gateway portfolio, write down the proposed application as a simple operating statement.

For metering:

“Several gateway sites will collect low-volume readings from distributed meters and forward them to one centrally maintained LNS.”

That statement points towards a distributed forwarding architecture.

For agriculture:

“Sensors are spread across a remote site with no fixed WAN, and the gateway must use cellular connectivity while maintaining a clearly defined local operating model.”

That points towards a gateway with appropriate cellular backhaul and, where justified, local LNS capability.

For a city:

“Gateway sites will expand independently as coverage grows, while server and fleet-management functions remain centrally operated.”

That again favours a shared upstream architecture rather than isolated gateway networks.

Only after writing this statement should the project compare individual gateway capabilities.

A useful final checklist is:

If a feature cannot be connected to one of those requirements, it should not influence the decision simply because it appears on the datasheet.

Preguntas frecuentes

Q1. What are the most common LoRaWAN applications?

LoRaWAN is commonly used for distributed low-power sensing such as metering, environmental monitoring, building sensors, agriculture and municipal IoT. The network configuration varies significantly between these applications. Coverage, reporting frequency, backhaul availability, LNS architecture and application integration should be evaluated before choosing a gateway configuration.

Q2. What is the best LoRaWAN gateway configuration for smart metering?

A distributed architecture with gateways forwarding readings towards a centrally maintained LNS is often practical when many buildings or districts share one operating model. A forwarding-oriented Robustel LoRaWAN gateway may fit this arrangement, while smaller private networks may justify a gateway with an embedded LNS. The appropriate design depends on scale and ownership rather than meter count alone.

Q3. Which Robustel LoRaWAN gateway fits agriculture?

The Robustel R1520LG LoRaWAN Gateway fits projects requiring flexible cellular, Ethernet or Wi-Fi backhaul and either external or embedded LNS operation. Where the project also requires local processing or integration of LoRaWAN and wired field data, the LG3120e may be relevant, subject to confirmation of its current development status and required software configuration.

Q4. Do smart-city LoRaWAN gateways need cellular backhaul?

Not always. Some gateway sites may use municipal Ethernet or another existing IP network. Cellular backhaul becomes useful where fixed connectivity is unavailable or impractical. A city-scale architecture can use different backhaul methods at different locations while forwarding traffic towards the same central LoRaWAN infrastructure.

Q5. Should every LoRaWAN gateway run its own Network Server?

No. A built-in LNS can suit contained or locally operated sites, while an external LNS is often more practical when multiple gateways share one network and operating team. The gateway and Network Server are separate architectural responsibilities, so the server location should follow deployment scale, ownership, backhaul and recovery requirements.

Conclusión

There is no single best LoRaWAN gateway configuration for every application.

Metering commonly rewards a repeatable forwarding architecture and central network management. Agriculture places more pressure on radio placement, power, cellular backhaul and site autonomy. Smart-city networks need distributed coverage points that can be operated as part of one wider network rather than isolated gateway installations.

The Robustel LoRaWAN gateway portfolio supports different roles across these architectures, from forwarding-oriented deployments to the more flexible R1520LG and edge-oriented LG3120e. The correct model still depends on what responsibility the project actually assigns to the gateway.

Define the application first: what is being measured, where the devices are located, how often they communicate, where the LNS runs, how the gateway reaches it and who will maintain the system. Once those answers are clear, the appropriate gateway configuration becomes much easier to justify.

Explore more articles about Robustel’s LoRaWAN gateway in industrial IoT:

Acerca del autor

Robert Liao | Technical Support Engineer

Robert is an IoT Technical Support Engineer at Robustel, specializing in industrial networking and edge connectivity. A certified Networking Engineer, Robert focuses on the deployment and troubleshooting of large-scale IIoT infrastructures. His work centers on architecting reliable, scalable system performance for complex industrial applications, bridging the gap between field hardware and cloud-side data management.