What Is a LoRaWAN Network Server (LNS) and How Does It Fit Your IoT Stack?

If you're researching LoRaWAN, you'll quickly encounter the term "LNS" or "LoRaWAN Network Server". It's a critical piece of the architecture, yet it's often confused with the gateway, the application, or the entire platform. This guide breaks down what the LNS does, where it sits in the stack, and how different LNS choices affect your deployment.

The LoRaWAN Architecture in 60 Seconds

A LoRaWAN network has four layers:

What the Network Server Actually Does

The LNS is responsible for several critical functions that make LoRaWAN work reliably at scale:

• →Device authentication: When a sensor joins the network (OTAA join procedure), the LNS verifies its identity using cryptographic keys and issues session keys for encrypted communication.
• →Deduplication: In a multi-gateway deployment, the same sensor packet is often received by several gateways simultaneously. The LNS deduplicates these, selecting the best copy and discarding the rest.
• →MAC layer management:The LNS controls adaptive data rate (ADR), managing each device's spreading factor and transmit power to optimise airtime and battery life across the network.
• →Downlink scheduling: When the application needs to send a command or configuration to a device, the LNS determines the optimal gateway and timing for the downlink transmission, respecting duty cycle constraints.
• →Routing: The LNS routes decoded payloads to the correct application server, typically via MQTT, HTTP webhooks, or gRPC integrations.

Popular LNS Options

The LoRaWAN ecosystem offers several network server options, each with different trade-offs:

Each option represents a different trade-off between control, cost, and operational overhead. Open-source solutions like ChirpStack give you maximum flexibility but require you to host, maintain, and scale the server yourself. Managed cloud solutions reduce operational burden but introduce vendor dependency and ongoing subscription costs.

The Self-Hosted ChirpStack Dilemma

ChirpStack is the most popular open-source LNS for good reason: it's feature-rich, actively maintained, vendor-neutral, and gives you complete control over your network. But running it in production means provisioning servers, managing PostgreSQL and Redis databases, configuring TLS certificates, handling backups, scaling for growth, and keeping everything patched and monitored. For organisations whose core competency is IoT applications rather than infrastructure, this operational overhead diverts engineering time from the product.

This is exactly the gap that ChirpCloud fills. ChirpCloud is a fully hosted ChirpStack service: you get the same powerful API, device management, and integration capabilities, but the underlying infrastructure is managed for you. No servers to provision, no databases to tune, no certificates to rotate. Your devices, applications, and integrations work exactly as they would with self-hosted ChirpStack, but without the operational burden.

When paired with EdgePilot managed gateways, ChirpCloud gives you a complete LoRaWAN stack where neither the gateway layer nor the network server require any infrastructure management on your part. You focus entirely on your sensors, your data, and your application.

LNS vs Gateway: Separate Concerns

A critical architectural point that's often missed: the LNS and the gateway layer are separate concerns. A gateway doesn't care which LNS it forwards packets to. It simply takes LoRa radio packets, wraps them in an IP packet, and sends them to a configured server address.

This means your LNS choice and your gateway infrastructure choice are independent decisions. You can run ChirpStack on your own servers while using managed gateways from EdgePilot. You can switch from The Things Stack to ChirpStack without replacing a single gateway. The gateway configuration simply points to a new server address, a change that a managed service can push across the entire fleet in minutes.

Why This Separation Matters

Keeping gateway management and LNS operation separate gives you maximum flexibility. You can choose the best LNS for your application requirements without worrying about gateway compatibility. You can migrate between LNS platforms as your needs evolve. And you can delegate the operational burden of gateway management to a specialist while retaining full control of your network server and application logic.

With EdgePilot managed gateways you get professionally maintained infrastructure at the gateway layer, with the freedom to run whichever LNS best fits your stack. And if you want a fully managed LNS too, ChirpCloud gives you hosted ChirpStack with zero infrastructure to manage. Together, they form a complete LoRaWAN stack where you own the devices and the data, and we handle everything in between. Get in touch to discuss how managed gateways and hosted LNS fit into your architecture.