LoRaWAN Repeater vs Additional Gateway: Which Solves Coverage Gaps Better?
A LoRaWAN coverage gap does not automatically mean that a repeater—or another gateway—is required. The first task is to identify why the endpoint is difficult to reach. For projects using the Robustel R1520LG LoRaWAN Gateway, an additional gateway creates another independent LoRaWAN receiving point with its own IP backhaul. A standards-based LoRaWAN Relay addresses a narrower problem: extending communication between selected end devices and the existing gateway/network when direct coverage is insufficient. The R1520LG is discussed here only as the additional-gateway option; its current datasheet does not list LoRaWAN Relay functionality.
Imagine a building automation project where almost every wireless sensor reports correctly except several meters in a basement plant room. The first suggestion is predictable: “Can we put a LoRa repeater halfway down the corridor?” That may eventually be the right answer. But the same symptom could also result from poor gateway placement, a heavily shielded room, an unsuitable antenna installation, or a wider area that really needs another gateway.
Choosing the hardware before identifying the failure often turns one coverage problem into another maintenance problem.
Do Not Choose the Remedy Before Diagnosing the Dead Zone
Start with the endpoint that is failing. A Robustel LoRaWAN gateway receives devices normally elsewhere in the building, so the network is not completely unavailable. The question is why this particular path fails.
Walk the radio path physically:
- End device
- → local enclosure or room
- → walls, floors and structures
- → gateway antenna position
- → gateway
Then determine whether the failure is:
- Localised RF shielding. A meter sits behind reinforced concrete, below ground or inside a metal service area while nearby devices communicate normally.
- Poor gateway placement. The gateway was installed where power and Ethernet were convenient rather than where the LoRaWAN radio path was strongest.
- A wider coverage boundary. A separate building, distant utility room or new project zone sits beyond the practical coverage of the existing gateway.
- An installation problem. Antenna placement, feeder loss, orientation or a physical obstruction is reducing a link that should otherwise work.These situations should not receive the same remedy.
A useful first test is to temporarily reposition either the gateway antenna or a test gateway. If the difficult device becomes stable, the team has evidence that the problem is radio topology rather than sensor provisioning or the Network Server.
Only after the dead zone has been characterised should the design branch towards a Relay or another gateway.
A LoRaWAN Relay and an Additional Gateway Change Different Parts of the Network
The word “repeater” requires care in LoRaWAN projects.
Traditional radio systems often use repeaters that simply receive and retransmit signals. LoRaWAN now has a specific standardized Relay mechanism. The LoRa Alliance’s TS011-1.0.1 Relay defines bidirectional relaying of LoRaWAN frames between an end device and the Gateway/Network Server when the end device has insufficient direct gateway coverage.
That does not mean any product marketed as a “LoRa repeater” is automatically a standards-based LoRaWAN Relay.
For procurement, the distinction should be explicit:
- Generic repeater: Vendor-specific behaviour that must be evaluated on its own architecture and compatibility.
- LoRaWAN Relay: An implementation designed around the LoRa Alliance Relay specification.
- Additional LoRaWAN gateway: Another full gateway receiving LoRaWAN traffic and forwarding it to the Network Server through an IP backhaul.These options solve coverage differently.
A Relay introduces another radio stage between the difficult device and the wider network. An additional gateway changes the network topology by putting a full receiving point closer to that device. This difference affects much more than range.
| Design question | LoRaWAN Relay approach | Additional gateway |
|---|---|---|
| Primary purpose | Reach endpoints with insufficient direct gateway coverage | Add another independent LoRaWAN receiving location |
| IP backhaul at new point | Not the same requirement as a full gateway | Required for gateway-to-LNS connectivity |
| Power and installation | Can potentially suit constrained locations, depending on Relay implementation | Requires power and a suitable gateway installation |
| Standards support | Relay support must be confirmed across the intended implementation | Uses normal gateway/LNS architecture |
| Traffic path | Introduces an additional radio relay stage | Endpoint can communicate directly with the added gateway |
| Capacity effect | Does not create a complete new gateway receive site | Adds gateway radio resources at a new location |
| Coverage overlap | Focused extension for affected devices | Can provide wider overlap for multiple devices |
| Operations | Adds another radio component to provision and maintain | Adds another gateway to monitor, backhaul and maintain |
This is why comparing the two only by hardware price is misleading.
The engineering question is which network function the missing coverage actually requires.
Compare the Failure You Remove with the Failure You Add
A coverage fix should improve the system rather than simply move the weak point.
Suppose a Relay restores communication with six meters in the basement. The radio problem has been solved, but the project now needs to understand the operational behaviour of that Relay:
- Which devices and network components support the selected Relay architecture?
- How is it provisioned?
- How is its availability observed?
- What happens if it fails?
- How is its power source maintained?
- Does the application tolerate the additional radio path?
- Can another technician replace it without redesigning the network?
A full additional gateway creates a different set of responsibilities. A Robustel R1520LG LoRaWAN Gateway placed closer to the basement requires a suitable power source and Ethernet, Wi-Fi or cellular backhaul. It also becomes another managed gateway in the estate.
The trade-off is that the new site is not serving only as an intermediate radio hop. It becomes another independent LoRaWAN reception point.
This distinction matters when the coverage problem grows. If one isolated meter room is difficult to reach, installing another full gateway may be disproportionate.
If an entire new building wing contains dozens of devices with weak links, investing in a second gateway may address the network topology more directly than introducing a relay for a growing number of endpoints.
The cost comparison should therefore include:
- Hardware
- installation
- backhaul
- power
- commissioning
- monitoring
- replacement
- future expansion
A lower purchase price is not necessarily the lower-cost coverage remedy over the operating life of the site.
Three Coverage Gaps Lead to Three Different Decisions
The easiest way to understand the choice is to look at three different failures.
A Shielded Basement Meter Room
Most devices in the building communicate reliably with the existing gateway, but five utility meters sit below ground behind heavy concrete. First test whether gateway or antenna relocation improves the path without weakening other important areas.
If the site genuinely has one small isolated pocket and a standards-based Relay architecture is supported by the selected devices and network environment, Relay may deserve evaluation. Installing another complete gateway for a handful of endpoints could add more power, backhaul and management infrastructure than the problem requires.
The decision is not “Relay is cheaper.” It is: The coverage problem is small enough that a focused extension may be appropriate.
A New Building Beyond the Existing Coverage Area
The original LoRaWAN project served one warehouse. Six months later, another warehouse opens across the site. There are now dozens of new sensors, and measurements show that the original gateway provides inconsistent reception in the second building.
This is no longer one isolated shadow. Adding another Robustel LoRaWAN gateway gives the new building its own receiving point while allowing both gateways to participate in the same wider LoRaWAN architecture.
Robustel’s Voytech Systems building automation case study demonstrates this type of gateway densification. Its architecture uses one or more R1520-LG gateways forwarding LoRaWAN traffic to a site-local Sitelink Controller; when additional coverage is required, more gateways can be introduced as additional reception points rather than creating a chain of proprietary repeaters.
The lesson from the case is architectural rather than numerical. A larger coverage zone can be expanded by adding gateway reception where the devices actually are.
A Remote Site with No Existing IP Network
The third situation looks similar on an RF map but creates a different infrastructure decision. A group of sensors sits far enough from the current gateway that another receiving point would solve the radio path. However, the location has no Ethernet or Wi-Fi. Now the decision must include backhaul.
A cellular-capable gateway can potentially turn that remote location into an independent LoRaWAN collection point, whereas a Relay approach may avoid adding a full IP-connected site if the coverage requirement is sufficiently narrow and the required Relay support is available.
Robustel’s Cibicom nationwide LoRaWAN case study shows the other end of this design choice. Cibicom operates distributed gateway infrastructure in difficult-to-access locations and uses LTE450 to transport gateway traffic back to its server systems. The original deployment used the legacy Robustel R3000-LG; Robustel identifies the R1520LG as the current replacement model.
This does not prove that every remote coverage gap needs a cellular gateway. It shows what changes when the new coverage point becomes part of the permanent network infrastructure: backhaul, power, monitoring and maintenance become part of the design.
When the Robustel R1520LG LoRaWAN Gateway Is the Better Additional Coverage Point
The Robustel R1520LG LoRaWAN Gateway fits coverage expansion where the project needs another full LoRaWAN receiving point rather than only an intermediate radio extension.
That situation becomes more likely when:
- A whole building or site zone needs stronger coverage
- Many endpoints benefit from the new location
- Coverage overlap is desirable
- The project expects future sensor growth in the same area
- Ethernet, Wi-Fi or cellular backhaul is practical
- The new location needs to operate as a managed network node
- An external or site-local LNS already supports multiple gateways
The Robustel R1520LG supports up to eight simultaneous LoRaWAN receive channels and provides Ethernet, Wi-Fi and cellular connectivity for IP backhaul. It can forward to an external LNS or support a local ChirpStack-based architecture. These characteristics make it suitable for adding a conventional gateway reception point without changing the end devices into a vendor-specific repeating architecture.
The gateway still does not guarantee that the coverage gap disappears.
The new installation requires its own:
- RF survey
- Antenna position
- Regional configuration
- Power
- Backhaul
- LNS configuration
- Monitoring
- Maintenance plan
Adding hardware at the wrong position merely creates a second poorly placed gateway. For a short visual explanation of why a gateway has a broader network role than simply extending radio range, Robustel’s “Why Do You Need a LoRaWAN Gateway” video provides useful context. The distinction becomes important when deciding whether the new site needs only radio extension or a complete LoRaWAN-to-IP network point.
Use a Coverage Remedy Decision Tree
Instead of starting procurement with “Repeater or Gateway?”, work through the coverage fault in this order.
1. Is the problem really RF coverage?
Confirm that the endpoint is provisioned correctly and that the failure is not at the LNS or application layer.↓
2. Can gateway or antenna placement remove the problem?
Test before adding another network component.↓
3. Is the dead zone small and isolated?
If yes, evaluate whether a supported LoRaWAN Relay architecture is appropriate.↓
4. Does a whole zone or growing group of endpoints need better reception?
If yes, another gateway becomes more relevant.↓
5. Can the new gateway location obtain power and IP backhaul?
If not, compare cellular backhaul with the practical requirements of a Relay approach.↓
6. What happens when the added component fails?
Include monitoring, replacement and site access in the decision.↓
7. Which design remains simpler after the next expansion?
The last question is particularly useful. A Relay that cleanly solves one difficult room may be a sensible targeted solution. A network that accumulates multiple relay devices every time another building is added may be signalling that its gateway topology needs to change.
Conversely, installing a full industrial gateway for every isolated sensor shadow can create unnecessary infrastructure. The right architecture should remain understandable after the original commissioning engineer leaves the project.
FAQs
Q1. Does LoRaWAN support repeaters?
LoRaWAN has a standardized Relay mechanism defined by the LoRa Alliance for situations where an end device has insufficient direct gateway coverage. However, the term “LoRa repeater” is also used for other products and architectures. Projects should verify whether the proposed solution implements the LoRaWAN Relay specification and whether the required devices and network components support it.
Q2. Is adding another LoRaWAN gateway always better than using a Relay?
No. A full gateway adds an independent receiving point and is useful when a larger zone or many endpoints need additional coverage. For a small, isolated coverage pocket, that infrastructure may be disproportionate. A supported Relay approach can be worth considering when the problem is narrow and the project accepts its additional radio and operational requirements.
Q3. Can the Robustel R1520LG be used to extend LoRaWAN coverage?
Yes. The Robustel R1520LG LoRaWAN Gateway can be deployed as an additional gateway location where another independent LoRaWAN receiving point is required. This use should not be confused with LoRaWAN Relay functionality; the current R1520LG datasheet does not list Relay support. The new site still needs suitable antenna placement, power, backhaul and LNS configuration, so adding the gateway should follow RF validation rather than substitute for it.
Q4. Does a LoRaWAN Relay increase network capacity?
A Relay should not be treated as the equivalent of installing another full gateway. Its primary purpose is to transport frames for endpoints that lack sufficient direct gateway coverage. If the real problem is high traffic load or the need for another independent receiving site, gateway capacity and network topology should be assessed separately.
Q5. Should I try moving the gateway before adding more hardware?
Usually, yes. If a coverage gap results from poor placement, antenna position or local obstruction, changing the existing installation may solve the problem without adding another managed network component. Test the difficult endpoint after a controlled placement change before committing to either a Relay or another gateway.
Conclusion
A LoRaWAN repeater or Relay and an additional LoRaWAN gateway are not two interchangeable ways to buy more range. A Relay is relevant when selected endpoints cannot reach the existing network directly and the project supports the required Relay architecture. Another gateway is more appropriate when the network needs an independent receiving point for a larger area, additional coverage overlap or future device expansion.
The Robustel R1520LG LoRaWAN Gateway fits the second model: it can add a complete LoRaWAN reception and IP-backhaul point to an existing architecture, but it still needs deliberate placement and infrastructure planning.
Start with the dead zone rather than the product. Diagnose what the existing network is missing, then add the smallest new network function that solves that specific problem without creating unnecessary operational complexity.
Explore more articles about Robustel’s LoRaWAN gateway in industrial IoT:
About the Author
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.