Robustel R1520LG LoRaWAN gateway supports both external and embedded LoRaWAN Network Server architectures, making it a useful example of why LoRaWAN network design should be planned as a sequence of responsibilities rather than as a collection of gateways. Radio coverage, IP backhaul, LNS ownership and the final application are separate layers, and each can fail while the others remain operational.
A network that receives sensor packets but cannot deliver them to the application is not healthy. Neither is a cloud dashboard that remains online while a remote gateway has lost its backhaul. Good LoRaWAN design therefore begins by assigning ownership and failure conditions to every layer.
Design the LoRaWAN Network as Layers
A LoRaWAN endpoint does not communicate directly with a business dashboard. Its radio message may be heard by one or more gateways, forwarded over IP, processed by the network server, passed through an application layer and only then become useful operational information.
Breaking this path into layers makes troubleshooting much easier because each layer has a different responsibility.
LoRaWAN Architecture Ownership Map
| Network layer | Primary responsibility | Common failure | Robustel relevance |
|---|---|---|---|
| End device | Produce and transmit valid LoRaWAN messages | Battery, sensor, configuration or antenna problem | Robustel gateway cannot repair endpoint hardware |
| LoRa radio / gateway | Receive uplinks and provide the radio bridge | Poor coverage, interference or gateway failure | Robustel R1520LG, R1320LGe, LG3120e and LG5120 |
| IP backhaul | Carry gateway traffic toward the LNS | Ethernet, cellular or Wi-Fi outage | Different Robustel gateways provide different backhaul options |
| LoRaWAN Network Server | Manage LoRaWAN network functions | LNS availability or configuration problem | External LNS, embedded ChirpStack or integrated LNS depending on model |
| Application integration | Decode and use the data | Codec, API, database or mapping error | Edge-integrated Robustel models can assume more local responsibility |
| Fleet operations | Maintain the gateway estate | Drift, old firmware, undetected outage | RCMS supports supported Robustel gateway operations |
This separation avoids a common troubleshooting mistake: assuming that one green status indicator proves the full data path is working.
Coverage and Capacity Are Different Design Problems
A site can have excellent coverage and still experience capacity problems if too many devices transmit too frequently. It can also have a lightly loaded network that fails because a handful of sensors sit behind difficult structural obstacles.
Coverage therefore asks whether the gateway can receive a usable radio signal from the intended devices. Capacity asks whether the combined traffic pattern can be handled with acceptable performance.
The two interact. A weak endpoint may use a lower data rate and occupy more airtime, while repeated transmissions add traffic that would not appear in an ideal link-budget calculation.
Coverage vs Capacity in a Robustel LoRaWAN Design
| Symptom | More likely coverage-related | More likely capacity-related | Robustel design response |
|---|---|---|---|
| One remote sensor is unreliable | Yes | Less likely | Review antenna position, obstacles and endpoint location |
| Many nearby devices fail during busy periods | Less likely | Yes | Review traffic profile and airtime |
| Devices in one plant room perform poorly | Yes | Possibly | Survey that physical area before adding network capacity |
| Retransmissions rise across a large area | Possibly | Yes | Check both RF quality and aggregate traffic |
| A second gateway improves difficult areas | Often | It may also provide additional reception diversity | Validate before treating gateway density as the only solution |
The Voytech Systems LoRaWAN building-automation case study demonstrates why this distinction matters in buildings. The deployment used multiple R1520LG gateways as receiving points where appropriate, while Voytech's own Sitelink platform hosted the local network and application server functions.
The case therefore supports a useful architectural lesson: gateway placement and LNS placement are separate design choices.
Choose the LNS Architecture Before Scaling the Gateway Estate
There are several valid ways to place the LoRaWAN Network Server.
A centralized external LNS can simplify policy and fleet management when many gateway sites belong to one network. The gateway forwards traffic over IP and the central platform remains responsible for the LoRaWAN network.
A local LNS moves that responsibility closer to the site. This can reduce dependence on a remote service for selected operations, but it also means that network-server configuration and lifecycle become part of the local gateway or site responsibility.
Neither is automatically better.
External vs Embedded LNS Architecture
| Design question | External LNS | Embedded/local LNS | Robustel example |
|---|---|---|---|
| Where is LoRaWAN network control hosted? | Central or third-party platform | At the site | R1520LG supports both directions |
| What happens if IP backhaul fails? | Gateway cannot deliver new packets to the remote LNS | Local LNS may remain available for local network functions | Must be tested against the actual application |
| How are multiple sites governed? | Central policy can be simpler | Each local instance needs lifecycle control | Depends on operations model |
| Is local application integration required? | Often handled elsewhere | Can be closer to field data | LG3120e/LG5120 extend this further |
| Is an existing ChirpStack deployment already present? | Forwarding may be sufficient | Embedded server may be unnecessary | R1320LGe is designed around ChirpStack forwarding |
Robustel LoRaWAN network design video is particularly relevant here because it demonstrates the gateway's local configuration and embedded ChirpStack path. The video should be viewed as a configuration reference, while the architecture decision still depends on who should own the LNS in production.
How the Robustel R1520LG LoRaWAN Gateway Supports Different LNS Architectures
The Robustel R1520LG LoRaWAN Gateway supports UDP, LoRa Basics Station and LORIOT for external LNS connectivity, while embedded ChirpStack allows the network server to run locally. That means the same hardware platform can participate in a centralized LNS design or in a site-controlled network-server architecture.
This flexibility is useful during design, but it also places more responsibility on the project team. An embedded LNS should not be selected simply because the feature exists. The team needs to define how it will be configured, backed up, updated and recovered, and whether the application can still function when upstream connectivity is unavailable.
The R1520LG also provides dual cellular SIMs, Ethernet and Wi-Fi backhaul options. These give the designer several possible IP paths, but multiple interfaces do not automatically create a resilient network. The actual routing and recovery behaviour still needs to be configured and verified.
Backhaul Failure Is Different from LoRaWAN Radio Failure
The Cibicom nationwide LoRaWAN backhaul case study illustrates this boundary at network scale. Cibicom's deployed gateways collected LoRa traffic from distributed sites and used LTE450 backhaul to deliver that traffic toward central server systems.
The original project used the legacy R3000-LG rather than the current R1520LG, so the case should not be used as proof of R1520LG field performance. Robustel identifies R1520LG as the current replacement model. The useful evidence is architectural: a nationwide LoRaWAN radio layer still depends on a dependable IP path between gateway sites and the server infrastructure.
For a remote site, this means the backhaul should be tested separately from the radio. An engineer should be able to distinguish “gateway cannot hear the sensor” from “gateway heard the sensor but cannot reach the LNS.”
Edge Processing Changes the Gateway's Responsibility
Some projects need more than an LNS decision.
Robustel LG3120e LoRaWAN edge gateway provides an integrated LNS, more than 300 pre-built sensor codecs and the E2C Field Suite for bringing supported LoRaWAN, Modbus, OPC UA and BACnet data into local edge workflows. Node-RED and local visualization add application responsibility that would otherwise sit elsewhere.
Robustel LG5120 LoRaWAN gateway moves this approach toward facilities and building automation. KNX, M-Bus, P1, isolated RS-485, LoRaWAN and local automation software can all coexist on the same platform.
That consolidation can reduce the number of separate boxes at the site, but it also changes the failure domain. If one gateway owns radio reception, network-server functions and local application logic, failure of that device affects more than one layer.
RobustOS Pro Matters When the Gateway Owns Local Applications
For R1520LG, LG3120e and LG5120 deployments where local Linux-based functionality is relevant, RobustOS Pro provides the Debian-based operating environment underneath the supported gateway software.
The practical benefit is not simply that Linux is available. It is that local software, data integration and network services can run close to the field equipment when the architecture requires them.
That also creates lifecycle responsibility. Local applications need controlled versions, tested updates and recovery procedures. Moving functionality from a central server to a gateway does not remove software operations; it relocates them.
Commission One Complete Data Path Before Scaling
Before installing dozens of gateways, validate one representative path from endpoint to application.
A useful commissioning test sends a known LoRaWAN message from a real sensor, verifies that the intended gateway receives it, confirms delivery through the selected backhaul, checks LNS processing and then verifies that the application receives the expected data.
Repeat the test during a backhaul interruption and after gateway power recovery if those failures matter to the deployment. The result should describe what continues to function locally and what stops when each dependency is unavailable.
FAQ
Q1. Do LoRaWAN gateways need a network server?
Yes. LoRaWAN architecture includes a network-server function. It may run externally, on a private server, in a cloud service or locally on selected gateways. The location is an architecture decision rather than a property of LoRaWAN radio alone.
Q2. Can one LoRaWAN network use multiple gateways?
Yes. Multiple gateways can receive traffic from the same endpoint network, and adding receiving points can improve coverage. The network server manages the forwarded traffic. Gateway count should follow site coverage and traffic requirements.
Q3. What is the difference between a LoRaWAN gateway and an LNS?
The gateway provides the radio-to-IP bridge, while the LoRaWAN Network Server manages network functions above that radio layer. Some products combine the two, but the responsibilities remain logically distinct.
Q4. Does the Robustel R1520LG have a built-in LoRaWAN Network Server?
Yes. The Robustel R1520LG LoRaWAN Gateway supports embedded ChirpStack as well as external LNS connectivity through documented forwarding options. The embedded server should be selected only when local LNS ownership fits the operating model.
Q5. What happens to LoRaWAN when the internet connection fails?
That depends on the architecture. A gateway forwarding to a remote LNS may continue hearing sensor packets but cannot deliver them upstream while the backhaul is unavailable. Local LNS or buffering functions can change the behaviour, but the exact recovery path must be verified for the chosen gateway and application.
Decision conclusion
Robustel R1520LG LoRaWAN gateway is particularly useful in network designs where teams need a choice between external LNS connectivity and embedded ChirpStack while retaining multiple IP backhaul options. That flexibility should be used to implement a defined ownership model rather than to avoid deciding where the network server belongs.
A sound LoRaWAN architecture separates radio coverage, capacity, backhaul, LNS and application responsibility. Once each layer has an owner, failure condition and acceptance test, scaling the gateway estate becomes much more predictable.
