How Does a LoRaWAN Gateway Work? Network Server, Backhaul and Channels

The gateway sits on a shelf, the LED is on, the web interface says “connected” – and your application still shows no data at all. That’s when many people realize a LoRaWAN gateway does less than they assumed. In short, a LoRaWAN gateway is a radio receiver with an internet connection. It hears every LoRaWAN packet in range, attaches a timestamp and signal data, and passes it all to a network server, which handles decryption, device management and duplicate filtering.

Understanding that split makes buying and troubleshooting much easier. Nearly every gateway question – built-in server or not, Ethernet or cellular, 8 or 16 channels – comes down to one thing: which part of the data path lives in the gateway, and which lives elsewhere?

What does a LoRaWAN gateway do?

A sensor transmits its reading without knowing which gateway will pick it up; unlike a phone on Wi-Fi, it isn’t paired with any. Every gateway in range on the right frequency receives the packet but can’t read it: the payload is encrypted with AES-128, and the keys sit with the network and application servers, not in the gateway.

What the gateway adds is metadata: the exact time of reception, the frequency, the spreading factor, the received signal strength (RSSI) and the signal-to-noise ratio (SNR). It sends this, with the raw message, over its internet connection – the backhaul – to the network server. The backhaul can be Ethernet, Wi-Fi or cellular; the sensor never notices which.

In the other direction, the gateway transmits. When the network server schedules a downlink – an acknowledgment, a join accept or a configuration command – it hands the gateway the finished packet and an exact transmit time, so it lands in the sensor’s receive window. A Class A sensor only opens those windows briefly after its own uplink; miss them, and the command waits for the next uplink.

Inside is a concentrator chip that listens on many frequencies at once. In the RAK7268V2, that’s a Semtech SX1302 on a Mini PCIe card with eight channels. It decodes different spreading factors on the same frequency in parallel. Single-channel receivers from hobby projects hear only one frequency at one spreading factor.

LoRaWAN gateway vs network server: which does what?

The network server is the brain of a LoRaWAN network. It checks that a packet comes from a registered device, verifies the frame counter to reject replays, uses Adaptive Data Rate (ADR) to tune each sensor’s transmit power and spreading factor, and picks the gateway for each downlink. A join server handles activation, and an application server decrypts the payload for your software.

A key server job is deduplication. If three gateways hear the same transmission, the server gets three identical packets, each with its own reception values. It keeps one, discards the rest and routes any reply through the gateway with the best signal.

Here’s where each task lives, useful for comparing offers or narrowing down faults:

So a gateway alone gives you neither a dashboard nor payload decoders. Those come from the servers – whether a community network like The Things Network, a self-hosted ChirpStack, a commercial cloud service or a server running on the gateway itself.

Can a LoRaWAN gateway have a built-in network server?

Yes, many current gateways ship with one. The RAK7268V2 offers a “Built-in Network Server” work mode: you create an application in the web interface, register your sensors and forward the data to your software over MQTT or HTTP. No external server is required.

That suits small, self-contained projects: one building or site, a few dozen sensors, data that stays local anyway. It even works without a permanent internet connection. RAK also lets extra gateways join a central one running the built-in server as MQTT extenders.

The limits show as you grow: multiple sites, hundreds of sensors and central user and device management are much easier on an external network server. A common mistake: sensors registered on the built-in server while the gateway runs in forwarding mode, or vice versa. Each side looks fine alone, but there’s no data path. Decide on one mode before setup and write it down.

Packet forwarder vs Basics Station: how does a gateway talk to the server?

With an external network server, the gateway needs a protocol to reach it. The RAK7268V2 supports both common ones.

The Semtech UDP packet forwarder is the older approach. The gateway sends packets to the server over UDP, typically on port 1700, and in the reference configurations sends a short keepalive every 10 seconds to pick up downlinks. It’s lightweight and almost every network server understands it. But it doesn’t encrypt the connection, identifies the gateway only by its EUI, and needs the frequency plan set on the gateway by hand.

LoRa Basics Station is the modern successor. The gateway opens an encrypted WebSocket connection (WSS) to the server – on port 8887 for The Things Stack – and authenticates with a key or certificate. The server supplies the frequency plan automatically. The optional CUPS service updates credentials and configuration centrally.

If your server supports Basics Station, it’s usually the better choice, especially over cellular; use the packet forwarder when the server only speaks UDP. Either way, the gateway mode must match the server setting.

Do you need a 4G LoRaWAN gateway?

The best reception spot isn’t always next to a network jack. For an outbuilding without a data cable, a construction site or a utility room IT won’t wire up, a cellular LoRaWAN gateway fills the gap. Only the backhaul runs over the mobile network. Your sensors don’t need SIM cards.

The store carries the indoor RAK7268CV2 and the outdoor RAK7289CV2 variants for this. Both use an LTE Cat 4 module; for Europe that’s the Quectel EG95-E, covering LTE bands 1, 3, 7, 8, 20 and 28A, with a nano SIM. The nearly identical-looking RAK7268V2 without the “C” has a SIM slot but no modem, so always check the full model name.

LTE fits three cases: no wired connection on site, a temporary setup that shouldn’t wait for network work, and a backup link. RAK gateways can prioritize WAN links and fail over to LTE via ping or HTTP tracking when Ethernet drops, and they can buffer uplinks on the built-in microSD card during an outage. How well that works depends on the work mode, and late readings don’t help an alarm.

Don’t size the data plan on sensor payloads alone. The packet forwarder’s keepalive at a 10-second interval already adds up to 8,640 messages a day, plus statistics reports, remote management and firmware updates. Measure usage during a few days of trial operation, add headroom, and check reception at the actual mounting spot. And if a stable wired connection exists, Ethernet with PoE is almost always simpler and cheaper.

8 vs 16 channel LoRaWAN gateway: how many devices can one gateway handle?

Channel count is how many frequencies the gateway hears at once, not how many sensors it can manage. An 8-channel gateway like the RAK7268V2 fully covers the common EU868 channel plan: The Things Network uses exactly eight uplink frequencies between 867.1 and 868.5 MHz in Europe. On each of those channels, the concentrator receives packets at different spreading factors in parallel.

The sensor count depends mainly on airtime. A packet with 12 bytes of payload is on air for about 62 milliseconds at SF7 and just under 1.5 seconds at SF12. Five hundred sensors reporting every 15 minutes generate 2,000 packets per hour. At SF7, that’s just over two minutes of airtime per hour across eight channels – very relaxed. If the same sensors all transmit at SF12, the total is about 49 minutes, and the risk of collisions rises sharply. An 8-channel gateway can therefore handle several hundred sensors, as long as most of them are close enough for low spreading factors.

A 16 channel LoRaWAN gateway such as the 16-channel version of the RAK7289V2 or RAK7289CV2 has two SX1303 concentrators and two LoRa antenna connectors. That only helps if the network server and sensors actually use 16 frequencies; in the standard EU868 plan, the extra channels sit idle. The Things Stack can combine two non-overlapping frequency plans on supported gateways, but only if you set it up deliberately. More channels also don’t increase range or downlink capacity: a gateway transmits only one packet at a time, and in Europe the duty cycle limits transmit time on top of that.

So when are 16 channels worth it? In dense private networks with very many sensors in one place and an extended channel plan. For dead spots in distant parts of a building, a second 8-channel gateway elsewhere helps more than doubling channels at the original spot.

Does every sensor need its own LoRaWAN gateway?

No – that’s one of LoRaWAN’s big advantages. A gateway is shared infrastructure: any registered sensor in range can use it, whether a temperature probe, a door contact or a meter, with no fixed pairing. A well-placed gateway often covers an entire building.

Extra gateways help. If several hear the same sensor, deduplication on the network server ensures the reading arrives once. If one fails, another takes over – provided both are on the same network and don’t share a power circuit and internet connection.

So planning starts with the measurement points, not the gateways. Where are the hardest sensors, say in a basement or behind reinforced concrete? Test from there with a real device for several days and check RSSI and SNR on the network server. If a sensor is stuck at SF12, that’s a clear sign it sits at the edge of coverage. A gateway closer to that spot usually beats a bigger antenna.

LoRaWAN gateway online but no data: what to check

“Gateway online, but no data” is the most common problem with new installations. Online only means the gateway reaches its server; whether sensor packets arrive and get processed are separate questions. Walk the data path in four steps.

First, the radio: does the gateway’s live log show any packets from the sensor? If not, check the frequency band (EU868, not US915), the sensor’s activation and the distance. A sensor right next to the gateway can overload the receiver; keep a few meters of distance, ideally with a wall in between.

Second, the forwarding: is the gateway sending to the right server, with the correct address, the correct port and a matching frequency plan? With UDP, the gateway EUI registered on the network server must match the one configured on the gateway exactly. With Basics Station, a missing or wrong API key is a frequent culprit.

Third, the join: if a join request shows up on the network server but the sensor never joins, the DevEUI, JoinEUI or AppKey usually don’t match. It’s also possible that the join accept never reaches the sensor because the downlink is too weak.

Fourth, the application: if uplinks reach the network server while your dashboard stays empty, the payload decoder is often missing, the integration points to the wrong destination or the device ID doesn’t match. Always trace one known test device with a fixed interval through all four stages.

Where can you buy LoRaWAN gateways?

Once you know what a gateway does, the choice comes down to a few questions. Start with frequency: in Europe you need an EU868 device. Then location: indoor gateways like the RAK7268V2 are rated IP30 and belong in dry rooms, while a mast or facade calls for an outdoor housing such as the IP67-rated RAK7289V2. Then the backhaul: Ethernet with PoE where a cable exists, LTE where it doesn’t or as a backup. Also decide where your network server will run – on the gateway, self-hosted or in the cloud – and confirm the gateway supports the matching protocol. Channel count usually comes last: eight channels cover the standard EU868 plan, and 16 only pay off with an extended channel plan and high device density.

If you’re looking for a suitable LoRaWAN gateway, you’ll find our models in the LoRaWAN gateways category.

LoRaWAN Gateway FAQ

How far can a LoRaWAN gateway reach?

Mounting height and surroundings matter more than the device. In built-up areas, a well-placed gateway typically reaches a few kilometers, and in open country with an elevated antenna considerably more. An indoor gateway on the ground floor, by contrast, often covers only its own building and the immediate surroundings. Testing real sensors at the planned spot beats any rule of thumb.

Do you need an outdoor LoRaWAN gateway?

Only if the gateway will be mounted outside, for example on a mast or a facade, to cover a site or several buildings. That requires a weatherproof housing like the IP67 enclosure of the RAK7289V2, which also brings surge protection on the PoE input and a grounding point. For covering a building from inside, an indoor gateway is enough – it just doesn’t become weatherproof because its signal reaches outdoors.

Can a LoRaWAN gateway use Wi-Fi?

Yes, many models can join your network as a Wi-Fi client, including the RAK7268V2 with 2.4 GHz Wi-Fi. Ethernet is usually more reliable for continuous operation, since Wi-Fi can drop when the router restarts or the password changes. Wi-Fi is handy for initial setup, though: out of the box, the gateway opens its own access point for configuration.