LoRa Gateway vs LoRaWAN Gateway: What Are You Actually Buying?
A device may receive LoRa radio signals without providing a complete LoRaWAN network. The Robustel R1320LGe LoRaWAN Gateway illustrates the distinction: it receives LoRaWAN packets and forwards them to ChirpStack, while the external network server performs the central network-management role.
The practical difference is not the wording printed on the enclosure. It is which parts of the data path the purchased device actually owns.
One Sensor Message Reveals the Missing Responsibilities
Consider a water utility installing wireless level sensors across several pumping stations.
A sensor successfully transmits a message, and a nearby gateway receives it. The project team may assume the data is now ready for its monitoring platform. In reality, several steps still separate the radio message from a usable alarm or measurement:
Sensor
→ LoRa radio transmission
→ gateway radio concentrator
→ packet forwarder
→ Ethernet Wi-Fi or cellular backhaul
→ LoRaWAN Network Server
→ application and payload processing
→ utility monitoring platform
A forwarding product such as the Robustel R1320LGe LoRaWAN Gateway receives LoRaWAN packets at the remote site and sends them to a central ChirpStack platform. The gateway provides the radio reception and IP forwarding layer, while the LoRaWAN Network Server remains a separate system responsibility.
If it forwards packets but does not include a network server, the organisation must provide an external LNS.
If the application expects named values such as water level, temperature or battery condition, another layer must decode the sensor payload and pass the resulting data to the business system.
This is where terminology creates procurement risk. The phrase LoRa gateway is often used informally for several different devices, while LoRaWAN gateway usually suggests participation in a LoRaWAN architecture. Neither label alone proves that the product includes an LNS, payload codecs, cellular backhaul or fleet management.
The buyer should inspect the complete responsibility chain instead of purchasing by category name.
Need a quick visual overview first? Watch “What Is a LoRaWAN Gateway?” for a concise introduction to where the gateway sits between LoRaWAN end devices, IP backhaul and the wider network architecture before we separate those responsibilities in more detail.
LoRa Describes the Radio Link
LoRa is a chirp spread spectrum modulation technology used for long-range, low-power radio communication. It defines how compatible radios transmit and receive signals, but it does not by itself specify the complete network architecture above the radio link. Semtech’s official overview provides further background on the underlying LoRa technology.
A device using LoRa radio can be part of:
- A standard LoRaWAN network
- A proprietary point-to-point design
- A private star network using custom software
- Another application-specific radio system
That flexibility explains why a product described only as a LoRa gateway requires closer examination.
It may be:
- A radio bridge between LoRa devices and a serial or IP interface
- A concentrator receiving several LoRa channels
- A packet-forwarding device intended for LoRaWAN
- A complete LoRaWAN gateway with routing and remote-management capabilities
- A gateway that also hosts an LNS or local application software
The presence of a LoRa radio does not confirm which of these responsibilities the product performs.
A buyer using standard LoRaWAN sensors should therefore verify more than frequency compatibility. The gateway must also support the required LoRaWAN packet-forwarding architecture and connect correctly to the chosen network server.
LoRaWAN Defines a Wider Network Architecture
LoRaWAN defines the communication architecture that connects end devices, gateways, network servers and application systems.
In a conventional LoRaWAN architecture, gateways relay radio traffic between end devices and the Network Server through an IP backhaul connection. The LoRa Alliance’s Back-End Interfaces specification describes the radio gateway as the forwarding layer: it receives uplink packets and passes them to the Network Server, while downlink transmission requests move in the opposite direction.
Receiving a radio packet therefore does not mean that the gateway has completed network processing, decoded the sensor payload or delivered usable data to the customer’s application.
The Robustel R1520LG LoRaWAN Gateway illustrates why the exact architecture must be checked at product level. It can forward packets to an external LNS through supported forwarding methods, but it can also support a built-in ChirpStack deployment. These two configurations use the same gateway hardware while assigning the Network Server responsibility to different locations.
The LNS performs responsibilities that should not automatically be attributed to the gateway, including LoRaWAN network-level processing and directing messages towards the relevant application layer. The application or integration system must then interpret the payload and expose the resulting information to the customer’s operational platform.
Each layer consequently has a different owner and failure mode.
| Layer | Main responsibility | Typical project question |
| End device | Measure and transmit data | Does the sensor use the correct regional LoRaWAN settings? |
| LoRa radio link | Carry the wireless signal | Can the gateway receive the device from its installed location? |
| Gateway concentrator | Receive LoRaWAN radio packets | Does the hardware support the required frequency and channel architecture? |
| Packet forwarder | Send packets upstream | Which forwarding method is supported? |
| Backhaul | Connect the gateway to the server | Will the site use Ethernet Wi-Fi or cellular connectivity? |
| LoRaWAN Network Server | Operate the LoRaWAN network layer | Where will the LNS run and who will maintain it? |
| Application layer | Process payloads and expose data | Who converts sensor bytes into meaningful values? |
| Business platform | Use the information | How will the data reach the BMS SCADA or cloud application? |
Calling the entire chain a “LoRa gateway solution” hides these boundaries. The radio may work correctly while the project remains incomplete because the LNS, backhaul or application integration has not been assigned.
What a LoRaWAN Gateway Usually Provides
A LoRaWAN gateway normally contains a LoRa concentrator and software that transfers received packets towards an LNS. Industrial products may add routing, VPN, Ethernet, Wi-Fi, cellular connectivity and remote-management functions.
Semtech describes a conventional LoRaWAN gateway as a system containing a LoRa radio front end controlled by a host platform. The host and its software connect the radio side to the upstream network.
For buyers, the useful questions are more specific:
Which regional frequency does the gateway support?
EU868, US915, AU915 and AS923 are not interchangeable ordering details. The gateway and end devices must use the frequency plan permitted and configured for the target region.
Which packet-forwarding method is available?
A product may support a traditional UDP packet forwarder, LoRa Basics Station, a platform-specific connector or only one defined server architecture. The selected method must be compatible with the intended LNS and security model.
How does the gateway reach the LNS?
A building may use Ethernet. A remote utility cabinet may depend on cellular connectivity. A temporary installation may use Wi-Fi. Backhaul loss prevents packets from reaching an external server even when the LoRa radio continues receiving sensor messages.
Does the gateway provide local storage or buffering?
This is not a universal gateway function. Where offered, the exact data retained, storage limit and forwarding behaviour must be verified. Buffering should not be described as guaranteed zero data loss.
How will the fleet be managed?
A web interface may be sufficient for one gateway. A distributed deployment may need central configuration, firmware management, status visibility, logs and remote access.
The Robustel LoRaWAN gateway portfolio combines LoRaWAN radio functions with different backhaul, LNS and management architectures. This illustrates why two products carrying the same gateway category can serve different system roles.
Robustel’s Real-world example: LoRaWAN reception still needs dependable IP backhaul
In Robustel’s Cibicom case study, LoRaWAN gateways were deployed across hard-to-access locations in Denmark, including mast and third-party sites. The gateways collected LoRa device traffic and carried it over Cibicom’s LTE450 network to central server systems before the data was forwarded to customer back-end platforms. The project used the legacy Robustel R3000-LG LoRaWAN Gateway, whose current replacement model is the Robustel R1520LG LoRaWAN Gateway. The deployment illustrates an important architectural boundary: successful LoRaWAN radio reception does not remove the need for a reliable backhaul path and server infrastructure.
What the Gateway May Not Include
The most expensive mistakes occur when buyers assume that every LoRaWAN gateway includes functions that actually belong elsewhere.
A Gateway May Not Include an LNS
A packet-forwarding gateway sends radio packets to an external LNS. It does not necessarily register devices, manage network sessions or provide the central server layer itself.
The Robustel R1320LGe LoRaWAN Gateway, for example, is positioned as a compact forwarding gateway. It collects LoRaWAN end-device data and forwards it to ChirpStack through 4G LTE Cat 4, Ethernet or Wi-Fi backhaul. The product should not be described as hosting the central ChirpStack server merely because it connects to that platform.
This architecture fits distributed coverage points where the organisation already operates a central ChirpStack environment.
An LNS May Not Decode the Business Meaning of a Payload
A LoRaWAN sensor may transmit a compact byte sequence. Turning that sequence into temperature, pressure, battery voltage or an alarm state requires a suitable codec or application process.
Some network platforms include payload-processing tools, but buyers should not assume that every gateway or LNS already understands every sensor model.
The project must establish:
- Who supplies the codec
- Where the codec runs
- How units and data types are validated
- Whether downlink commands are required
- How decoded data reaches the target application
A Gateway May Not Provide the Business Application
Gateway status dashboards and LoRaWAN device management are not the same as an operational dashboard for facilities, utilities or manufacturing.
The system may still require:
- A BMS
- A SCADA platform
- A cloud IoT application
- An energy-management system
- A customer database
- An alerting or reporting service
The gateway creates or supports the data path. It does not automatically deliver the final business workflow.
Three Architectures Buyers Commonly Confuse
The terminology becomes easier when products are grouped by responsibility.
| Architecture | What the purchased device does | What remains elsewhere |
| LoRa radio bridge | Receives LoRa signals and passes data to another host | LoRaWAN processing packet forwarding LNS and application logic |
| LoRaWAN forwarding gateway | Receives LoRaWAN packets and forwards them over IP | External LNS payload processing and business application |
| LoRaWAN gateway with built-in LNS | Receives packets and hosts the network server locally | Application integration lifecycle management and project-specific processing |
A fourth category adds data integration or edge computing, but that capability should not be treated as a default feature of all LoRaWAN gateways.
The correct architecture depends on the application scenario.
A municipality deploying dozens of coverage points may prefer forwarding gateways connected to one central LNS. A single industrial site may choose a gateway with an embedded LNS to keep the network contained. A BMS project may need another integration layer to decode payloads and present data through building protocols.
The hardware should follow the assigned architecture. It should not determine the architecture after purchase.
Robustel’s Real-world example: the LoRaWAN gateway does not have to own every layer
Robustel’s case study with Voytech Systems shows this separation clearly. Robustel R1520-LG LoRaWAN Gateways receive traffic from wireless building sensors and forward it over IP to Voytech’s Sitelink Controller. The Sitelink platform hosts the local LoRaWAN network and application servers and presents the resulting information as BACnet objects to the existing BMS. The architecture has been used to reduce sensor cabling in building projects while retaining familiar BMS integration.
The architectural lesson is more important than the product combination: in this deployment, the gateway does not own the complete LoRaWAN and BMS processing chain. Network-server, application-server and BACnet responsibilities are assigned to another system.
How Robustel Gateway Architectures Clarify the Difference
The Robustel R1320LGe LoRaWAN Gateway and Robustel R1520LG LoRaWAN Gateway demonstrate two distinct responsibilities within the same product category.
R1320LGe as a Forwarding Gateway
The R1320LGe focuses on collecting LoRaWAN packets and forwarding them to ChirpStack. It combines:
- Eight LoRaWAN receive channels
- 4G LTE Cat 4
- One physical SIM and one eSIM
- Ethernet
- Wi-Fi
- PoE-PD
- RCMS management
Its role is appropriate when the network server is centralised and each site mainly needs LoRaWAN coverage plus dependable IP backhaul. Its RobustOS hardware and limited SDK resources also reinforce that it should not be positioned as a general-purpose edge-computing platform.
R1520LG as a Flexible LoRaWAN Gateway
The R1520LG supports a broader network architecture. It can connect to an external LNS through supported packet-forwarding methods or use an internal ChirpStack configuration.
It also provides:
- Ethernet Wi-Fi and cellular backhaul
- Two physical SIM slots
- RS-232 and RS-485
- PoE-PD
- RCMS and RobustVPN
- RobustOS Pro and optional application capabilities
Its datasheet lists external LNS options including UDP, LoRa Basics Station and LORIOT, together with internal ChirpStack and E2C ChirpStack configurations.
That flexibility does not make the R1520LG automatically better than a forwarding gateway. A distributed network that already has a central LNS may not need local server functions at every site.
The product distinction is architectural:
- R1320LGe primarily forwards LoRaWAN traffic to a central ChirpStack platform.
- R1520LG can support either a forwarding architecture or a contained site with a built-in LNS.The later decision—whether the LNS should be internal or external—depends on deployment scale, ownership and lifecycle requirements and should be evaluated separately.
Assign Every Responsibility Before Ordering
A purchasing specification should identify the owner of every required function.
| Procurement question | Required answer |
| Which radio technology do the sensors use? | LoRaWAN or another LoRa-based protocol |
| Which regional frequency plan applies? | Exact region and permitted frequency |
| Who receives the radio packets? | Selected gateway and antenna system |
| Who forwards packets upstream? | Gateway software and forwarding protocol |
| How does the site reach the server? | Ethernet Wi-Fi or cellular backhaul |
| Where does the LNS run? | Gateway local server private infrastructure or cloud service |
| Who manages device sessions and network policies? | Named LNS owner |
| Who decodes sensor payloads? | Codec engine application or integration platform |
| Where does the operational data go? | BMS SCADA cloud or customer system |
| Who manages the gateways? | Local team RCMS or another device-management platform |
| What happens when backhaul fails? | Tested buffering retry and recovery process |
| Who maintains the full system? | Defined IT OT integrator or service-provider team |
This exercise exposes missing components before installation.
It also prevents overbuying. A project that only needs a forwarding node should not pay for an edge platform it will not operate. A self-contained site should not purchase a radio bridge and discover later that no device owns the LoRaWAN network layer.
Preguntas frecuentes
Q1. Is a LoRa gateway the same as a LoRaWAN gateway?
The terms are often used interchangeably, but they do not guarantee identical functions. LoRa describes the radio modulation, while LoRaWAN defines a wider network architecture involving end devices, gateways and network servers. A product described only as a LoRa gateway may use a proprietary data path, so buyers should verify its packet-forwarding and LNS compatibility.
Q2. Does a LoRaWAN gateway always include a Network Server?
No. Many LoRaWAN gateways forward packets to an external LNS. Other models can run an embedded server. The Robustel R1520LG LoRaWAN Gateway supports both external packet-forwarding and internal ChirpStack directions, while the Robustel R1320LGe is positioned primarily as a forwarding gateway.
Q3. Can a gateway decode LoRaWAN sensor data?
Some gateways or edge platforms include payload-codec workflows, but this is not a universal gateway responsibility. A basic forwarding gateway can deliver the encrypted or encoded LoRaWAN message upstream without converting it into named application values. Confirm where payload decoding occurs and whether the exact sensor model is supported.
Q4. Why does a LoRaWAN gateway need Ethernet Wi-Fi or cellular connectivity?
The LoRa radio connects sensors to the gateway. Ethernet, Wi-Fi or cellular connectivity carries gateway traffic to an external network server or application platform. These are separate links. Good LoRaWAN coverage does not help when the gateway’s IP backhaul is unavailable or incorrectly configured.
Q5. What should be tested before purchasing a LoRaWAN gateway?
Test the intended sensors, regional frequency, gateway position, packet-forwarding method, LNS connection, backhaul, payload decoding and target application. Also verify restart recovery, remote management and behaviour during a backhaul interruption. A radio reception test alone does not prove that the complete LoRaWAN data path works.
Conclusión
The Robustel R1320LGe LoRaWAN Gateway fits distributed sites that need to receive LoRaWAN packets and forward them to a central ChirpStack platform. The Robustel R1520LG LoRaWAN Gateway fits projects that need a choice between external packet forwarding and an internal LNS architecture.
Neither product should be selected from the words LoRa or LoRaWAN alone.
LoRa identifies the radio technology. LoRaWAN defines the network architecture built around that radio. The gateway connects those layers, but an LNS, payload-processing workflow and business application may still be required.
Before ordering, follow one sensor message from transmission to its final operational use. Any step without an assigned component and owner remains a gap in the design.
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.