LoRaWAN Gateway Placement Guide: How Many Gateways Do You Need?
A LoRaWAN gateway count should come from the coverage topology of the site, not from dividing floor area by a quoted radio range. The Robustel R1520LG LoRaWAN Gateway is a useful reference because its PoE-PD, Ethernet and cellular options allow placement decisions to be driven by radio conditions rather than by the nearest network socket alone.
Consider a food-processing campus with a production hall, cold-storage warehouse, utility building and several outdoor tanks. A gateway installed in the main communications room may receive most sensors during the pilot, yet equipment behind insulated walls and in a basement pump room remains intermittent. Moving the gateway improves one zone but weakens another.
The planning question is therefore not simply “How many LoRaWAN gateways cover this many square metres?” It is “Which parts of the site need independent coverage points, and what problem would each additional gateway solve?”
Turn the Site Plan into Coverage Zones
Before choosing gateway locations, divide the site according to radio and operational conditions rather than administrative boundaries.
A single Robustel LoRaWAN gateway may see sensors across several rooms or buildings where propagation is favourable. Conversely, two devices separated by only a short distance may behave very differently if one sits behind reinforced concrete, below ground or inside a dense plant area.
For the food-processing campus, useful zones might be:
- Production areas with large metal machinery
- Cold stores with insulated walls and doors
- Offices with relatively conventional construction
- Basement utility rooms
- Detached plant buildings
- Outdoor tanks or meter locations
- Areas where loss of sensor visibility has higher operational impact
The objective is not to assume that every zone needs its own gateway. It is to identify where one proposed receiving point is likely to face different RF conditions.
This is also where the previous range question becomes an input rather than the answer. A field test may show that the proposed Robustel R1520LG location receives the production hall reliably but not the basement. Placement planning then decides whether to relocate the gateway, change the antenna arrangement or create another receiving point.
For a short overview of why these receiving points are needed in a LoRaWAN architecture, Robustel’s Why Do You Need a LoRaWAN Gateway video provides a useful visual introduction. The important point for placement planning is that gateways form the radio access layer between distributed end devices and the wider IP-connected LoRaWAN system.
Place the First Gateway Where It Solves the Most Difficult Coverage Problem
The geometric centre of a site is not automatically the best gateway position.
In an industrial building using a Robustel R1520LG LoRaWAN Gateway, a communications room may be attractive because Ethernet and power already exist there. From an RF perspective, however, that location may be surrounded by concrete walls, electrical equipment or metal cabinets.
A better candidate position may be:
- Higher within the building
- Closer to several difficult sensor zones
- Outside a heavily screened plant room
- Near a vertical riser serving several floors
- In a location where the LoRaWAN antenna can be positioned more effectively
Infrastructure still matters. Moving a gateway to improve LoRaWAN reception creates little value if the new position has no viable power or backhaul.
The R1520LG supports Ethernet, Wi-Fi and cellular connectivity and can receive power through PoE-PD on ETH0, giving an installer more options when the best RF position does not coincide with an existing power outlet. These features increase placement flexibility; they do not make every position equally suitable.
A Robustel building deployment shows how this works in practice: cutting BMS cabling costs with LoRaWAN and the Robustel R1520-LG.
In Robustel’s case study with Voytech Systems, R1520-LG gateways receive traffic from wireless building sensors and forward it to a local Sitelink Controller. One proof of concept demonstrated LoRa communication across 14 floors, while another deployment used more than 200 sensors in a three-storey office. These are deployment-specific results rather than product coverage limits.
The more relevant placement lesson appears when coverage needs to expand: Voytech’s architecture allows additional R1520-LG gateways to be introduced as further receiving points within the same LoRaWAN system.
That is usually a more defensible engineering approach than trying to force one gateway position to serve every difficult zone.
Add Gateways for a Defined Reason, Not Because the Site Looks Large
An additional Robustel gateway should correct an identified limitation. Adding hardware without identifying the failure mode can increase cost without materially improving the network.
Four reasons commonly justify another receiving point.
Coverage Gaps
A basement, detached building or screened plant area may remain unreliable after reasonable placement and antenna adjustments.
In this case, an additional gateway can create another path between the end device and LoRaWAN infrastructure. It should be positioned around the failed zone rather than simply placed at an arbitrary midpoint.
Coverage Overlap and Resilience
Some applications may justify overlapping reception from more than one gateway.
This is different from fixing a dead zone. The intention is to avoid making a critical part of the site dependent on one receiving location. Whether this is necessary depends on the consequence of losing that gateway and the wider LNS architecture.
Multiple gateways do not automatically create complete network redundancy. They may still share the same power source, IP backhaul, building or upstream server.
Traffic Distribution
Device count alone does not provide a fixed gateway-count formula.
A site with many infrequently reporting meters may create a different radio load from a smaller estate transmitting more frequently or relying heavily on confirmed messages and downlinks. Channel utilisation, airtime and traffic behaviour should therefore be reviewed when moving from pilot to production.
An eight-channel gateway specification should never be converted directly into “X devices per gateway.”
Physical or Operational Separation
Sometimes geography itself justifies separate coverage points.
A campus may contain buildings hundreds of metres apart, while a utility network may contain pumping stations spread across an entire district. Extending one radio footprint may be less practical than operating several gateway sites connected to the same central LoRaWAN platform.
A useful placement decision matrix is:
| Observed problem | Move existing gateway first? | Review antenna installation? | Consider another gateway? |
|---|---|---|---|
| One screened basement area | Sí | Sí | If the gap remains |
| Separate buildings | Sometimes | Sí | Often |
| Large multi-floor structure | Sí | Sí | Where zones remain weak |
| Critical area needs overlapping reception | Not necessarily | Sí | Often |
| High traffic concentration | Limited value | Limited value | Possibly |
| Poor cellular backhaul | Possibly | Cellular antenna only | Not necessarily |
| Gateway loses power | No | No | Only if power paths are independent |
The table deliberately avoids a universal gateway quantity. The correct response depends on why the original topology is insufficient.
Indoor, Urban and Rural Sites Produce Different Topologies
The same Robustel LoRaWAN gateway portfolio may be deployed across buildings, municipal infrastructure and remote sites, but the resulting network layouts should not look identical.
Buildings: Think Vertically and Around Materials
A multi-storey building is not simply an outdoor map turned upright.
Concrete slabs, lift shafts, fire compartments, technical rooms and metal plant equipment can divide a relatively small floor area into several RF zones. One well-positioned gateway may serve surprisingly broad areas, while another building may need additional receiving points around shielded sections.
The Voytech deployment is useful precisely because it demonstrates that multi-floor propagation should be validated in the actual building rather than assumed from floor count.
Urban and Campus Networks: Think in Overlapping Zones
A municipal or campus deployment introduces streets, separate buildings, changing antenna heights and multiple ownership boundaries.
The planning unit becomes a coverage zone, not an individual room. Candidate gateway positions may be rooftops, technical buildings, street infrastructure or communications cabinets, subject to power, access and backhaul availability.
A Robustel R1520LG can support cellular backhaul where fixed connectivity is unavailable, which can make previously impractical RF positions operationally viable.
Rural and Wide-Area Networks: Think in Sites, Access and Backhaul
Open terrain may offer favourable LoRa propagation, but a wide-area network introduces another constraint: each gateway becomes an infrastructure site that must be powered, connected and maintained.
Robustel’s case study with Cibicom provides a useful wide-area reference: nationwide LoRaWAN network backhaul over LTE450 in Denmark.
Cibicom operates a nationwide LoRaWAN network with gateways at locations that can include masts and third-party properties. The original project used the legacy Robustel R3000-LG LoRaWAN Gateway, with the R1520LG now identified by Robustel as the replacement model. Gateway traffic is backhauled through Cibicom’s LTE450 network towards server systems and customer platforms.
The relevant lesson for placement is operational. A theoretically attractive RF position at the top of a mast also creates an access, power, backhaul and maintenance obligation. Wide-area gateway planning therefore needs to optimise the site as a whole, not radio coverage alone.
Match the Gateway Role to the Final Topology
Once the required coverage points are understood, the project can decide what each Robustel LoRaWAN gateway actually needs to do.
A site with one or several gateways may use the Robustel R1520LG LoRaWAN Gateway where flexible backhaul and LNS architecture are required. The current product supports external LNS connectivity through UDP, LoRa Basics Station and LORIOT, while an embedded ChirpStack option supports contained local architectures.
For a more distributed packet-forwarding topology, the Robustel R1320LGe LoRaWAN Gateway is positioned around forwarding LoRaWAN traffic to a compatible external LNS. It provides cellular, Ethernet and Wi-Fi backhaul together with PoE-PD, and Robustel lists metering and municipal deployments among its intended use cases. The current product page also states that the product remains under development, so specifications should be confirmed for an actual project.
This creates two different architectural examples:
Contained or flexible site
Sensors → R1520LG → built-in or external LNSand
Distributed forwarding network
Sensors → multiple forwarding gateways → central LNSNeither topology is universally superior.
A building with one technical team may prefer a contained local architecture. A utility or municipal operator managing many coverage points may prefer to centralise the Network Server while keeping gateways focused on packet forwarding.
The gateway count should therefore be decided before assigning unnecessary software responsibilities to every coverage point.
Freeze the Gateway Count Only After the Site Test
The final number of gateways should be an output of commissioning, not an assumption carried unchanged from the quotation stage.
For a Robustel gateway deployment, start with the planned positions and test the complete topology using representative sensors.
The validation should answer:
- Do critical endpoints reach at least one intended gateway reliably?
- Do locations requiring overlap reach the expected independent gateways?
- Are difficult areas still dependent on unusually favourable temporary antenna positions?
- Is each gateway’s power and IP backhaul viable at the final position?
- Does the production traffic model introduce behaviour that was absent during the pilot?
- Can the operating team identify which gateway or path has failed?
- Can another gateway be introduced later without redesigning the complete LNS architecture?
Record the actual gateway locations, antenna positions, representative RF observations, power source and backhaul method.
This creates a repeatable topology rather than a collection of gateways installed wherever a signal happened to work during commissioning.
For rollout programmes, it is often more useful to define several standard site patterns than one universal gateway count. A small office, large industrial building, distributed campus and remote utility site may each have a different baseline architecture.
That is more defensible than specifying “one gateway per X square metres.”
Preguntas frecuentes
Q1. How many LoRaWAN gateways do I need?
There is no fixed gateway quantity that applies reliably to every site. Building materials, terrain, sensor location, traffic behaviour, required coverage overlap and maintenance requirements all affect the result. Start with candidate coverage zones, validate representative endpoints and add gateways where a specific radio, capacity or resilience requirement remains unresolved.
Q2. Can one LoRaWAN gateway cover an entire building?
Sometimes, but building size alone cannot answer the question. Floor construction, plant rooms, metal structures, basements and antenna position may be more important than total area. The Robustel R1520LG LoRaWAN Gateway has been used in multi-floor building deployments, but actual coverage must still be validated at the intended site.
Q3. Should LoRaWAN gateways be installed in the centre of the site?
Not necessarily. A central position may be useful in an open environment, but a central communications room can also be a poor RF location. Gateway placement should balance difficult sensor paths, antenna position, power, backhaul and maintenance access rather than relying on geometric centre alone.
Q4. When should I add a second LoRaWAN gateway?
A second gateway is justified when it solves an identified problem such as a persistent dead zone, separated building, required coverage overlap or traffic constraint. Before adding hardware, verify that the issue cannot be addressed more appropriately through gateway relocation, antenna installation or correction of the end-device position.
Q5. Does adding more gateways always improve LoRaWAN reliability?
No. Additional receiving points can improve coverage or provide overlapping radio paths, but they do not automatically provide end-to-end redundancy. Gateways may still share power, backhaul, LNS or other infrastructure. Reliability planning must identify each failure domain rather than treating gateway quantity as a substitute for system design.
Conclusión
A LoRaWAN gateway placement plan should begin with coverage zones and operational constraints, not a universal radius or gateways-per-square-metre formula.
The Robustel R1520LG LoRaWAN Gateway provides flexible backhaul and LNS options for individual or multi-gateway sites, while forwarding-oriented architectures can use distributed gateway points connected to a central Network Server. The right topology depends on what each location must cover and how the resulting network will be operated.
Identify the difficult zones first. Place the initial gateway where it resolves the most important paths. Add another only when testing shows a specific coverage, capacity or resilience requirement that the existing topology cannot satisfy.
The correct gateway count is therefore not a number taken from a datasheet. It is the smallest validated topology that meets the project’s coverage and operational requirements without creating unnecessary infrastructure.
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.