A LoRaWAN gateway can hear radio packets, but it does not decide which device sent them, whether they are valid, or where their data should go. That intelligence lives mainly in the LoRaWAN network server.
The network server is the traffic controller at the centre of a LoRaWAN network. It receives packets forwarded by gateways, removes duplicate copies, manages the radio relationship with end devices, and passes useful data toward an application. It also coordinates downlinks travelling in the opposite direction.
You can use a free community network, operate an open-source server yourself, or buy a managed commercial service. The radio devices may be similar in all three cases; what changes is who operates the network core, who controls the data, and what level of support and reliability you receive.
LoRaWAN architecture in a nutshell
A simplified LoRaWAN data path looks like this:
End devices → gateways → network server → application server
- End devices are sensors, meters, trackers, buttons, alarms, or actuators. They transmit small LoRaWAN radio packets.
- Gateways listen on several LoRa channels and forward received packets over Ethernet, Wi-Fi, or cellular internet. They do not normally interpret the application data.
- The network server validates and manages LoRaWAN traffic, coordinates gateways and radio parameters, and routes messages onward.
- The application server receives the device payload, decodes values such as temperature or tank level, stores them, displays them, or triggers business actions.
A separate Join Server may participate when a device activates securely. In a small platform these functions can appear inside one product and one web console, but they remain different architectural responsibilities. The LoRa Alliance Backend Interfaces specification defines communication between network servers, Join Servers, and other networks.
Unlike a Meshtastic mesh, LoRaWAN end devices do not normally relay one another’s messages. A device sends one radio transmission, and any gateway in range may receive it. This is called a star-of-stars architecture. Read LoRaWAN vs. Meshtastic: which to choose and when for the broader distinction.
What a network server actually does
Deduplication
The same uplink may be heard by two, five, or twenty gateways. Each gateway forwards its copy, including signal and timing metadata. The network server recognises that these copies represent one transmission and delivers only one logical message to the application. It can retain the gateway metadata for coverage analysis and for choosing a suitable gateway for a downlink.
Security and frame validation
The server checks LoRaWAN frame integrity, device identity, frame counters, and replay protection. Depending on the LoRaWAN version and architecture, network-session keys protect the network layer while the application payload remains protected for the application side. A network server should not be confused with the database or dashboard that ultimately uses the sensor reading.
MAC commands and radio management
LoRaWAN includes MAC commands for managing the radio link. The network server may request different data rates or transmit powers through Adaptive Data Rate, change channel parameters, manage receive windows, obtain device status, and schedule downlinks. These decisions must respect the regional frequency plan and local duty-cycle or dwell-time rules.
Device activation: OTAA and ABP
Over-the-Air Activation (OTAA) is the preferred method for most deployments. A device sends a join request, the network verifies it with the Join Server, and fresh session keys and network parameters are established. This supports cleaner key management and new sessions after a device rejoins.
Activation by Personalization (ABP) places the session information in the device in advance. It can be useful in limited or specialised situations, but it lacks the normal OTAA join exchange and requires more care with frame counters, session keys, and device reprovisioning. ABP does not mean “no security”; it means the session was provisioned rather than negotiated over the air.
Routing and integrations
After processing an uplink, the network server sends the relevant message and metadata toward the correct application server or integration. Depending on the platform, that may use MQTT, HTTP webhooks, cloud queues, gRPC, or another API. A downlink follows the reverse path: application to network server, then through a selected gateway to the device at an allowed receive opportunity.
The role of the Join Server
The Join Server is the trust anchor for OTAA. It stores or works with device root keys, authenticates join requests, derives session keys, and securely provides the appropriate keys to the network and application sides. Separating this responsibility can let a device manufacturer provision a device once while allowing it to join different standards-compliant networks later.
In LoRaWAN 1.1, the separation of network and application security responsibilities is especially explicit. A user may never see a separate Join Server menu because a platform can bundle it into the same deployment. The component still matters conceptually: the Network Server manages the network session, while the Join Server controls activation credentials. The The Things Stack glossary describes its Join Server as storing root keys, generating session keys, and securely sending them to the appropriate servers.
Major LoRaWAN network-server options
| Platform or network | Operating model | Best suited to | Main trade-off |
|---|---|---|---|
| The Things Network / The Things Stack | Free community network, managed cloud, or self-hosted editions | Learning, community coverage, pilots, and production fleets | The community tier is shared and governed by fair-use rules; commercial tiers add operational commitments |
| ChirpStack | Open-source and normally self-hosted | Private networks, local control, labs, integrators, and edge deployments | You operate and support the infrastructure |
| Helium IoT | Crypto-incentivized gateway coverage connected to compatible LNS platforms | Using distributed third-party coverage without owning every gateway | Coverage, routing, Data Credits, and LNS operation are separate concerns |
| AWS IoT Core for LoRaWAN | Managed cloud LNS integrated with AWS services | Teams already building their IoT application in AWS | Cloud dependency, usage-based cost, and AWS operational complexity |
| Actility ThingPark, LORIOT, Everynet, and similar services | Commercial managed, on-premises, carrier, or hybrid offerings | Enterprise, utility, industrial, and telecom deployments | Contracts and cost in exchange for support, scale, and deployment options |
The Things Stack and The Things Network
The names are related but not interchangeable. The Things Stack is the LoRaWAN platform developed by The Things Industries. It includes Network Server and Application Server functions plus gateway, identity, device, integration, and Join Server services. The Things Network is the public community network that uses The Things Stack.
The free community environment is commonly presented through The Things Stack Sandbox. It is useful for learning, hobby deployments, community projects, and early prototypes, and is free subject to fair use. Community gateways can contribute coverage, allowing a correctly registered LoRaWAN device to be received without its owner necessarily operating the nearest gateway.
Free does not mean identical to a commercial service. A shared community tier is not the right place to assume a contractual service-level agreement, dedicated capacity, private routing policy, or guaranteed support. For a business deployment, The Things Stack Cloud offers managed plans, while Enterprise and Open Source deployments can run on infrastructure controlled by the operator. The current The Things Network documentation is the starting point for the community network.
This range of options makes The Things Stack unusually flexible: a prototype can begin in the community, while a production project can choose managed commercial hosting or a private installation. Migration still requires planning; do not assume moving keys, device identities, integrations, and live sessions is a one-click operation.
ChirpStack
ChirpStack is an open-source LoRaWAN Network Server for building private or public networks. It provides a web interface for managing tenants, applications, gateways, device profiles, and devices, along with APIs and integrations for delivering data to other systems.
ChirpStack is a strong choice when you want to keep the network core on your own VPS, data centre, industrial PC, or edge server. It is hardware-independent at the gateway level and supports common gateway connections such as LoRa Basics Station and Semtech packet-forwarder approaches. It can also use an external Join Server and supports LoRaWAN backend-interface features.
The software licence does not remove the operational work. Someone must install and update the service, secure its database and message broker, manage certificates, monitor gateway connections and queues, back up configuration and keys, and recover it after a failure. That is an advantage when control and privacy matter, but a burden when the team merely wants sensor data delivered reliably.
Helium IoT Network
Helium is different from a conventional hosted LNS. Its IoT network provides a large, community-operated LoRaWAN gateway layer in which eligible Hotspot operators can receive crypto-economic rewards. Device traffic consumes Data Credits. The radio coverage and incentive system are therefore part of Helium, while the organisation using that coverage connects its own compatible LoRaWAN Network Server.
Older articles often refer to the original Helium Console as though it were still the universal server for Helium devices. The current Helium IoT documentation instead describes routing traffic to an LNS and includes guidance for running ChirpStack. Operating an LNS directly on Helium involves routes, device-address allocation, an Organizationally Unique Identifier, and Data Credits; many users will prefer a provider that hides some of this complexity.
Choose Helium because its available gateway coverage and commercial model fit the deployment—not because cryptocurrency changes how a LoRaWAN sensor works. Verify useful coverage where devices will actually be installed, and confirm which LNS or connectivity provider will manage provisioning, routing, support, and billing.
AWS IoT Core for LoRaWAN
AWS IoT Core for LoRaWAN is a managed LoRaWAN network server integrated with the wider AWS IoT platform. Gateways connect using LoRa Basics Station, devices are provisioned in AWS, and messages can be routed into AWS services for rules, storage, analytics, alerts, and application processing.
It makes sense when the application already uses AWS and the team wants one cloud security, monitoring, and integration environment. It avoids maintaining an open-source LNS, but does not eliminate architecture work: devices, gateways, destinations, permissions, payload decoding, costs, and observability still need to be designed.
AWS uses pay-as-you-go pricing rather than a simple free community model. It also supports selected public-network connectivity and passive roaming arrangements; availability and partners can vary by region. This is a managed private network core, not an automatic promise of worldwide radio coverage.
Other commercial options
The commercial landscape extends well beyond the largest community and cloud names. Current established options include:
- Actility ThingPark, offering carrier-grade, enterprise, hosted, on-premises, and smaller all-in-one deployment models. Actility is now part of Netmore.
- LORIOT, with public community access for evaluation and professional cloud, on-premises, and hybrid LNS options.
- Everynet, focused on carrier-grade public LoRaWAN coverage and neutral-host connectivity, including partnerships used for roaming and coverage extension.
Gateway manufacturers, mobile operators, regional network operators, and IoT platform vendors may also bundle an LNS. Evaluate the exact product rather than the logo: ask about supported LoRaWAN versions and regions, gateway protocols, tenant isolation, Join Server support, roaming, data export, key ownership, service levels, retention, pricing, and migration.
What self-hosting involves
A small private LNS can run on modest hardware, but a production service is more than launching a container. The practical workload commonly includes:
- deploying the LNS, database, message broker, and required supporting services;
- configuring the correct regional frequency plan and gateway protocol;
- managing device identities, root keys, API credentials, and TLS certificates;
- building integrations to the real application or data platform;
- monitoring gateways, packet flow, downlink queues, disk use, and service health;
- installing security and platform updates without losing device service;
- backing up configuration and secrets, then testing restoration;
- designing redundancy if downtime would affect operations.
Self-hosting makes sense for a private campus, factory, farm, research network, regulated environment, local-only installation, or organisation with competent operations staff. It can also be attractive when internet connectivity is intermittent and the application must continue locally. It makes less sense when nobody owns maintenance or when the supposed saving is smaller than the cost of one outage.
Roaming and peering between LoRaWAN networks
LoRaWAN networks do not form a radio mesh, but their backends can exchange traffic. With roaming, a device belonging to its home network can use gateways associated with a visited network, subject to compatible regional radio settings, server support, routing policy, and usually a technical or commercial agreement.
Passive roaming lets the home network retain the LoRaWAN session and MAC control while using visited-network gateways. Handover roaming transfers more serving responsibility to another network and is less universally supported. The LoRa Alliance defines the relevant backend interfaces; actual availability depends on the platform and agreements.
Peering hubs reduce the need to configure every network-to-network relationship manually. For example, Packet Broker exchanges LoRaWAN traffic between participating forwarder and home networks and supports policy controls over join, MAC, application, and metadata traffic. Actility offers ThingPark Exchange, while other operators establish bilateral or hub-based roaming.
Roaming is not automatic merely because two networks use LoRaWAN. Nor does seeing a public gateway guarantee that your private server can use it. The networks must recognise one another, route the relevant device address or join identity, and permit the traffic.
How to choose a network server
| Choose this model | When it fits | Check before committing |
|---|---|---|
| Community network | Learning, hobby projects, civic experiments, and low-risk prototypes | Local coverage, fair-use limits, support expectations, data path, and whether the project may become commercial |
| Self-hosted open source | Privacy, local processing, infrastructure control, custom integrations, or disconnected sites | Operational skills, backups, security, upgrades, redundancy, and total maintenance cost |
| Managed commercial service | Production systems needing support, predictable operations, scaling, and contractual commitments | SLA, regional coverage, pricing units, data ownership, export options, lock-in, roaming, and support response |
| Cloud-native LNS | The rest of the application already lives in the same cloud ecosystem | Integration benefits versus cloud complexity, egress, permissions, and long-term cost |
For a first experiment, the nearest active community network is often the simplest start. For one building or farm with private gateways, ChirpStack can provide excellent control if you are willing to operate it. For a fleet tied to business obligations, a managed platform with clear support and service terms is usually easier to justify. Large deployments should run a proof of concept using the real devices, gateways, frequency plan, payload sizes, and downlink patterns before selecting a long-term platform.
LoRaWAN network servers are not Meshtastic MQTT brokers
Both systems may use MQTT somewhere in their software, but they are not interchangeable. A LoRaWAN Network Server implements LoRaWAN device sessions, MAC commands, joins, frame counters, gateway selection, and routing. A Meshtastic MQTT broker carries Meshtastic packets between internet-connected Meshtastic nodes or clients.
Meshtastic does not use TTN, ChirpStack, Helium LoRaWAN routing, AWS IoT Core for LoRaWAN, or LoRaWAN Join Servers. A Meshtastic radio cannot join a LoRaWAN network merely because both products use LoRa modulation or similar frequency bands.