IoT Stack

LoRaWAN and ChirpStack: how gateway management actually works

Published

LoRaWAN is a long-range, low-power radio protocol built for exactly the kind of sensor that needs to run for years on a small battery and report from somewhere WiFi and cellular can’t reliably reach: the far corner of a large site, underground, or spread across acres of farmland. A single LoRaWAN gateway can hear devices kilometres away, at the cost of a very low data rate, which is fine for a sensor that only needs to send a handful of bytes every few minutes.

Devices, gateways, and the network server: three different jobs

It helps to keep three roles separate. A device (a vibration sensor, a crack meter, a soil probe) transmits a radio packet. A gateway is essentially a very sensitive radio receiver: it listens for LoRaWAN packets and forwards whatever it hears, usually over the internet, without trying to understand or decode them. The actual intelligence lives in the network server: it decodes each raw packet, verifies the device is who it claims to be, deduplicates the packet if more than one gateway heard it, and hands a clean, decoded reading to your application.

ChirpStack is the open-source network server Nodenet runs for this layer. Without it, a gateway is just noise: raw radio frames with no way to know which device sent them or what the bytes inside mean.

Device authentication: OTAA vs ABP

Before a device’s readings mean anything, the network server needs to know it is really that device and not someone spoofing it. LoRaWAN offers two ways to establish this. OTAA (Over-The-Air Activation) has the device perform a join handshake with the network server the first time it powers on, negotiating fresh session keys, the modern default and the one most new deployments should use. ABP (Activation By Personalisation) has the keys pre-configured on both sides with no join handshake, simpler for constrained devices but less flexible if keys ever need to rotate. ChirpStack supports both, but OTAA is the safer default for anything left in the field long-term.

Why regional bands matter

LoRaWAN operates in unlicensed radio spectrum, and which frequencies are legally available varies by country: AU915 in Australia, US915 in the United States, EU868 across most of Europe, and several more. A gateway and every device talking to it need to agree on the same regional band, and a network server needs the right band’s configuration loaded to decode packets correctly. Get the region wrong and devices simply will not join, no error message pointing at "wrong band," just silence. Nodenet ships ChirpStack pre-configured for eleven regional band families, selected per tenant when LoRaWAN is enabled.

A real example: a crack meter on a structure with no site WiFi

Take a vibrating wire crack meter bolted to a retaining wall on the far edge of a large site, well outside WiFi range and with no mains power nearby. A battery-powered LoRaWAN sensor reads it daily, transmits a small packet to a gateway mounted on a site office roof, and goes back to sleep. ChirpStack decodes the packet, and the reading lands in the same pipeline as every other sensor on the site, next to MQTT-connected noise monitors and HTTP-polled weather stations, all normalised into one dashboard.

"Gateway management" in practice

In a self-managed setup, running a network server means standing up and patching ChirpStack yourself, configuring regional band files, managing device provisioning, and monitoring gateway uptime. As a managed service, that operational layer is handled for you: enable the service, pick your region, and start registering gateways and devices, on your own private network server, isolated from every other organisation on the platform from day one, whichever tier you’re on.

  • Devices transmit, gateways relay raw radio frames, the network server decodes and authenticates
  • OTAA is the modern, more flexible device authentication method; ABP is simpler but more rigid
  • Regional bands (AU915, US915, EU868, and others) must match between devices, gateways, and the network server
  • A gateway typically covers a radius of kilometres, at a much lower data rate than WiFi or cellular
  • Decoded LoRaWAN readings join the same pipeline as MQTT and HTTP sensors once past the network server

See our integrations page for the full protocol list, or our IoT stack overview for how LoRaWAN ingestion connects to storage, dashboards, and automation.

Ready to see this in your own dashboard?

Talk to us about your sites, your sensors, and your compliance requirements.

Request a demo