Le partenaire pour la captation, transmission et mise à disposition de vos données
The LoRaWAN gateway is a strategic component of any IoT project. It captures radio frames from LoRaWAN sensors and forwards them to your LoRaWAN Network Server (LNS) via IP connectivity (Ethernet, cellular, sometimes Wi-Fi). Its selection directly affects coverage, quality of service, security, monitoring and operating costs.
A poor choice can lead to coverage gaps, radio congestion, message loss, complex deployments and expensive maintenance. Conversely, a well-chosen gateway simplifies commissioning, secures scalability and reduces total cost of ownership (TCO) over time.
In this article, we review the criteria that really make a difference, with practical guidance and field-proven points of attention.
At a glance: the 7 criteria that really matter to choose your LoRaWAN gateway
1
Real radio coverage (not just “theoretical range”)
2
Capacity (traffic/messages, density, duty cycle, multi-channel support)
3
LoRaWAN compatibility and operating modes (UDP vs Basics Station/WSS, CUPS)
4
IP backhaul and network constraints (Ethernet, cellular, NAT, DNS, NTP)
5
Security and hardening (HTTPS, certificates, access control, updates)
6
Robustness (indoor/outdoor, IP rating, temperature, power, lightning protection)
7
Operations and support (monitoring, logs, configuration backup, SLA)
1- Coverage and range: think “real site”, not “marketing kilometres”
The first question is simple: what area do you need to cover, and under what conditions?
Outdoors, a LoRaWAN gateway can cover several kilometres—if the environment is clear, the antenna is well positioned and the radio plan is coherent.
Indoors, range depends heavily on building materials (reinforced concrete, metal structures, technical rooms), antenna placement and sources of interference.
What to check on the gateway:
- Radio sensitivity and concentrator performance (multi-channel capability, simultaneous reception).
- Antenna options (connector type, gain, remote antenna support, cable quality/attenuation, lightning protection).
- Radio diagnostics tools (RSSI/SNR, data rates, received messages, errors, “last seen”, maps/heatmaps on the LNS side).
Field tip: on complex sites (industrial facilities, campuses, multi-storey buildings), antenna placement (height, clearance, cable attenuation) and, if needed, multiple gateways are usually far more effective than simply “adding power”.
2. Capacity: size for traffic, not for the number of sensors
You often read “X sensors per gateway”. In practice, the real limit mainly depends on radio traffic (airtime) and the environment. Two projects with 200 sensors can behave very differently.
What impacts capacity:
- Transmission frequency (one message per hour vs one per minute)
- Payload size (and therefore radio airtime)
- Data rate / spreading factor: the more “robust” it is (e.g. SF12), the longer the transmission → higher airtime consumption
- Radio quality: in challenging indoor environments, devices often use lower data rates → reduced effective capacity
- Regulatory constraints (duty cycle) and channel plan
Concrete example: in a connected building (200 temperature, humidity, energy or door sensors), a “standard” gateway may be sufficient if messages are infrequent. However, if some sensors transmit often (meters, alarms, anomalies) or if radio conditions are poor (high spreading factors), delays and collisions may occur.
What to check:
- Concentrator capacity (multi-channel support, generation, performance)
- LNS indicators: collision/loss rates, data rate distribution, gateway load, latency, “uplinks received vs forwarded”
- Traffic targets: messages per day per sensor, including peak scenarios (alarms, recovery after outages)
3. LoRaWAN compatibility and modes: UDP, Basics Station, CUPS… the real issue
The key point is how the gateway communicates with your LNS. This choice affects security, operations and network prerequisites.
a) UDP Packet Forwarder (Semtech UDP)
- Simple, widely used, compatible with many legacy LNS platforms
- Often less mature in terms of operations (observability, configuration management), with security highly dependent on the overall architecture
b) Basics Station (WS/WSS)
- More modern and often preferred for production deployments
- Can operate in WSS (TLS): requires proper NTP, DNS and certificate/CA management
- Generally cleaner from an operational perspective (depending on the LNS and integration)
b) CUPS (Configuration & Update Server)
- Remote provisioning and configuration updates for Basics Station
- Very useful for fleets (URL rotation, credentials, parameters) and zero-touch provisioning
What to check before choosing your LoRaWAN gateway:
- Does your LNS support Basics Station and/or CUPS?
- Does the gateway properly handle WSS (CA trust store, root certificates, hostname verification)?
- Do you need zero-touch provisioning (CUPS), or is manual configuration sufficient?
Which mode to choose?
| Mode | Recommended when… | Strengths | Points of attention |
|---|---|---|---|
| UDP Packet Forwarder | PoC, maximum compatibility, legacy LNS | Simple, widely supported | Security and observability depend on architecture, less industrial configuration management |
| Basics Station (WSS) | Production, need for modern transport | TLS, often better operational framework | Requires NTP/DNS/CA, exact URL and path |
| CUPS | Fleet deployment, central provisioning | Zero-touch, config/credential rotation | Requires CUPS infrastructure and outbound network rules |
| Embedded LNS | Isolated network, local autonomy, small private network | Everything local (registry, profiles, apps) | LNS features vary, integrations must be checked (MQTT/HTTP, codecs, etc.) |
4. IP backhaul: Ethernet vs cellular, NAT, DNS, NTP
LoRaWAN radio is only part of the story. The gateway must also be reliable on the IP side—otherwise you end up with a gateway that “hears everything” but “forwards nothing”.
Key points to check:
- Ethernet: DHCP or static IP, VLANs, DNS, possible proxy
- Cellular: radio quality, SIM/APN management, “keep-online” watchdog, power consumption, data limits
- Inbound access reality: many APNs use CGNAT → no direct remote access
- NTP: essential if you use TLS (WSS, HTTPS, MQTTs, etc.)
Practical advice: if you plan remote operations, ensure your access architecture (VPN, bastion host, allowed IPs, tunnels) is clearly defined from day one. A gateway that is “manageable” but unreachable in production quickly becomes a problem.
5. Security and reliability: separating LoRaWAN security from IP security
What LoRaWAN secures (network level)
LoRaWAN provides radio-level security through keys and protocol mechanisms (encryption, authentication, anti-replay counters, etc.). This is handled between devices, the LNS and the application—not by the gateway alone.
What the gateway must secure (IP and administration level)
This is often where the real risks lie.
To check:
- HTTPS administration, server certificate handling if required
- Access control (allowed IP lists, built-in firewall, user accounts/roles if available)
- Trusted root CAs to validate remote servers (WSS/HTTPS/MQTTs)
- Secure firmware updates and patch cadence
- Logs (syslog/export) for audit and troubleshooting
“Day-2” reliability
- Connectivity watchdogs, scheduled reboots if needed
- Log export, configuration backup and restore
- Network diagnostic tools (DNS, routing, reachability, etc.)
6. Deployment and maintenance: what really costs money is “day 2”
A well-chosen gateway significantly reduces operating costs.
What to look for:
- Clear configuration wizard or web interface
- Configuration export/import (to replicate deployments)
- Controlled firmware updates (ideally traceable)
- Diagnostic tools (network, radio, logs, backhaul status)
- Monitoring: compatibility with your tools (SNMP, syslog, metrics, depending on the model)
Best practice:
Favour a model that allows you to standardise deployments (templates, procedures, backups) rather than handling everything on a case-by-case basis.
7. Robustness and operating environment: indoor, outdoor, industrial
The right hardware depends on the field conditions.
Indoor: compact design, simple power supply, suitable antenna, easy mounting
Outdoor: weatherproof enclosure (IP65/IP67), temperature range, UV resistance, condensation management
Industrial: vibration, dust, humidity, interference, power constraints, lightning/ESD protection
What to check:
- IP rating and operating temperature range
- Power supply type (PoE, DC, redundancy)
- Lightning and antenna protection (surge arresters, grounding)
8. Technical support and associated services: often underestimated
Hardware alone is not enough. Your gateway supplier should be able to help with:
- LNS compatibility
- Radio and network diagnostics
- Security best practices
- Update procedures
- Clear and comprehensive documentation
Useful services include:
- Monitoring tools
- Commissioning guides
- Training
- Architecture support (LAN/APN, security, VPNs, certificates)
Conclusion
Choosing the right LoRaWAN gateway means finding the right balance between radio coverage, capacity, LNS compatibility, IP security, field robustness and operational simplicity.
A suitable gateway allows you to:
- Connect your sensors reliably
- Secure access and communications
- Industrialise deployments
- Reduce maintenance costs
- Scale your network without re-architecting it
20/01/2026