Every LoRaWAN project meets the same confusion in week one. The team stands up a network server, sees device data arriving, and asks why they still need another platform. Or they sign up for an application platform, register a sensor, and ask why nothing shows up. Both questions have the same answer: LoRaWAN deployments run on two distinct layers that are often mistaken for one, and each does a job the other deliberately does not.
Getting the split right saves weeks. What follows is what each layer owns, where the boundary sits, and how the two connect in practice.
What the network server owns
A LoRaWAN network server (LNS) is radio infrastructure management. It authenticates devices when they join, deduplicates the same packet arriving through multiple gateways, schedules downlinks through the best gateway, manages adaptive data rate to preserve battery, and enforces the LoRaWAN MAC layer. ChirpStack, The Things Stack, and carrier-operated servers such as Actility all live here, and we compared the public and private options in private vs public LoRaWAN networks.
What the LNS hands you at the end of all that work is a decrypted payload: a few dozen bytes of binary, plus radio metadata. No dashboards, no users, no alerts, no history worth querying. That is not a gap in the product. It is the design.
What the application platform owns
An IoT application platform starts where the packet stops mattering and the data starts. It decodes the binary payload into named variables, stores them as queryable time series, and turns them into the things people actually buy: dashboards, alerts, user accounts with permissions, reports, and integrations with the rest of the business.
The layer that increasingly separates application platforms from each other is intelligence. Storing a temperature reading is table stakes. Forecasting where it will be in six hours, flagging that a sensor started drifting two days before it fails, and converting a prediction into a work order is where the value concentrates. TagoIO runs this in Analysis scripts and built-in analytics and AI, so forecasts, anomaly flags, and recommendations appear inside the same UI as the live data, rather than in a separate BI tool someone has to remember to open.
The boundary in one sentence
The network server makes sure the packet arrives once, securely, and efficiently. The application platform makes the packet mean something to a human or another system. If a task involves radio, joins, gateways, or spreading factors, it belongs to the LNS. If it involves a user, a chart, a threshold, a forecast, or an ERP, it belongs to the application platform.
Confusing the layers costs real time. Teams try to build alerting inside an LNS with webhooks and scripts, and end up maintaining a fragile application platform they never intended to write. Or they expect an application platform to diagnose gateway coverage, which it cannot see. Each layer is deliberately blind to the other’s job.
How the two connect
In practice the integration is a data bridge. The LNS pushes every decoded uplink to the application platform over HTTPS or MQTT, and downlinks flow back the same way. TagoIO ships pre-built integrations for the major network servers, including The Things Network, ChirpStack, and carrier networks, plus a connector library of hundreds of sensors, so payload decoding is configuration rather than code.
A typical production stack ends up as: sensors, gateways, an LNS (public network or private ChirpStack), and TagoIO on top for everything a customer sees. The LNS choice and the platform choice are independent decisions, which is healthy: you can switch network operators without rebuilding your application, and vice versa.
Do you ever need only one?
Sometimes. A pure coverage study can live on an LNS alone. A cellular or Wi-Fi deployment skips the LNS entirely and speaks directly to the application platform. But if the project involves LoRaWAN sensors and anyone other than an engineer looking at the data, you need both layers, and the honest budget line includes both from the start.
If you have an LNS running and want to see the application layer working against it, TagoIO connects in minutes. Book a demo or start free.
