Two different jobs

IoT Platform vs LoRaWAN Network Server

Two different jobs

IoT Platform vs LoRaWAN Network Server

A LoRaWAN network server handles the radio side: it authenticates devices, deduplicates uplinks arriving through several gateways, manages data rates, and hands you a JSON payload. An IoT platform starts where that stops. It decodes the payload into named readings, stores the history, draws the dashboards, evaluates the alert rules, and controls who sees what. Most deployments need both. Many organizations buy only the first and discover the gap later.

The confusion is understandable, because the two are often sold together and the boundary between them is invisible from the outside. It becomes visible on the day a working deployment delivers raw bytes to somebody who expected a dashboard.

Where the Line Falls

Neither piece is optional in a working deployment. They simply do different jobs, and knowing which does what is the difference between a sensible architecture and an expensive surprise.

Job

LoRaWAN network server

IoT platform

Authenticating a device onto the network

Yes

No

Removing duplicates when several gateways hear one message

Yes

No

Managing data rates and radio parameters

Yes

No

Queuing a downlink for delivery to a device

Yes

Decides when and why to send one

Turning a payload into named readings

No

Yes

Storing history for months

Rarely, and briefly

Yes

Dashboards

No

Yes

Alert rules and escalation

No

Yes

Users, roles and who can see what

Basic, operator focused

Yes, including customer-facing access

Separating one customer from another

No

Yes

Billing, plans and commercial packaging

No

Yes

 

Some vendors call the second column an application server rather than a platform. The words vary; the split does not.

What You Get With Only a Network Server

Plenty of deployments run on a network server alone, and for some of them that is exactly right. ChirpStack is open source and widely deployed. The Things Stack is available both as a hosted service and to run yourself. Both do the radio job properly.

What you get is devices joining, uplinks arriving deduplicated, downlinks queued, and a payload delivered to wherever you point it. What you do not get is meaning. The payload is bytes, and turning those bytes into a temperature that somebody can chart is your problem. So is storing them, drawing anything, deciding when a reading is worth waking somebody up about, and controlling which of your customers can see which devices.

That is a reasonable place to stop if you have engineers, a small number of device types, and somewhere else for the data to go. It stops being reasonable at about the point where somebody who is not an engineer needs to look at the data, or where a second customer appears.

What You Get With Only a Platform

The reverse case is less common and it catches people out just as often. Platforms such as ThingsBoard handle devices, dashboards and rules, and they are not LoRaWAN network servers. They expect something else to have already done the radio work.

If your devices are cellular or wired, that is fine, because there is no radio layer to run. If they are LoRaWAN, you still need a network server underneath, whether you run it, rent it, or receive it as part of something else. Buying a platform does not remove that requirement; it just makes it somebody's job to notice.

How the Two Actually Connect

In practice the join between them is smaller than people expect, and it happens on the gateway rather than in software.

Step

What happens

The gateway

Runs a packet forwarder, most commonly the Semtech UDP forwarder, and is configured with the address and port of a network server. That single setting is the boundary.

The network server

Receives the traffic, authenticates the devices, discards duplicates, manages the radio parameters, and passes the payload on.

The platform

Receives the payload, decodes it into named fields, and everything else follows from there.

 

That is why the two are so often bundled: once a gateway is pointed at a network server, whoever runs that server is well placed to hand the payload straight to a platform. It is also why the split is invisible until something goes wrong, at which point knowing which side of the line a problem sits on saves a great deal of time.

Which One Do You Actually Need?

Three questions settle it for most people.

Question

What the answer tells you

Does anybody who is not an engineer need to look at this data?

If yes, you need a platform. Raw payloads and a network server console are not something you can hand to an operations team, and building a viewer for them costs more than it looks.

Will more than one organization use it?

If yes, you need a platform. Separating customers, giving each their own view, and controlling who sees what a network server’s job is not and never has been.

Are your devices LoRaWAN?

If yes, you need a network server, whether you run it, rent it, or get it as part of a platform. If your devices are cellular or wired, you do not.

 

Most people asking this question answer yes to at least two, which is why most real deployments end up with both.

For completeness

Where ioX-Pulse and ioX-Bridge Sit

For completeness, since this is our site: ioX-Pulse is the platform, and ioX-Bridge is the LoRaWAN network server underneath it. They are separate products in the ioX-Connect suite, and either can be used with something else in place of the other. Most people running ioX-Pulse never need to touch the network server directly, which is the arrangement this page has been describing throughout.

ioX-Pulse showing a leak sensor and valve dashboard

ioX-Pulse

The platform: device management, dashboards, alerting and customer accounts.
Explore ioX-Pulse →
ioX-Bridge gateway connection view

ioX-Bridge

The LoRaWAN network server underneath: gateways, devices, decoding and delivery.
Explore ioX-Bridge →
FAQs

Answers to the questions we get most

Please reach out to us at: sales@iox-connect.com if you have any additional questions that are not addressed below.

A network server handles the radio side: it authenticates devices, removes duplicate uplinks received by several gateways, manages data rates, and hands over the payload. An IoT platform starts there, decoding the payload into named readings, storing history, drawing dashboards, running alert rules and controlling who can see what. They do different jobs and most deployments need both.
It is the software that manages the radio layer of a LoRaWAN deployment. It authenticates devices when they join, discards duplicates when several gateways receive the same transmission, adjusts data rates, queues downlinks for delivery, and passes uplink payloads on to whatever consumes them. It does not interpret those payloads.
Usually yes, if your devices are LoRaWAN. You need a network server for the radio layer, and you need a platform if anybody other than an engineer has to use the data or if more than one organization will see it. If your devices are cellular or wired there is no radio layer, so a platform alone is enough.
No. ChirpStack is a LoRaWAN network server. It does the radio job and does it well, and it does not decode payloads into named readings, store long-term history, draw dashboards or manage customer access. Those are platform responsibilities.
On the gateway side, a packet forwarder pointed at the network server's address and port, most commonly the Semtech UDP forwarder. On the other side, the network server passes the payload to the platform. The gateway setting is where the boundary between the two actually sits.
It is another name some vendors use for the platform layer. Terminology varies across the industry, but the split between the radio work and everything after it is the same whichever words are used.

Latest blog posts

Check out our recent blog posts for everything IoT related

LoRaWAN Lux Sensor
lorawan, LoRaWAN IoT, LoRaWAN temperature humidity, lux sensor, ambient monitoring sensor, smart building environmental sensor, greenhouse IoT sensor

LoRaWAN Temperature, Humidity & LUX Sensor - Three Measurements, One Device, Zero Wires

If you manage a commercial building, greenhouse, or warehouse, you already know that temperature, humidity, and light...
Read more
Water Leak Detection with LoRaWAN
lorawan, water leak detection sensor, water sensing rope, rope leak detector, lorawan water sensor

Water Leak Detection with LoRaWAN: How Rope Sensors Protect Facilities

A single undetected water leak can cause thousands of dollars in damage before anyone notices. In data centers,...
Read more
IoT platform — from device management to analytics

What Makes a Great IoT Platform? Core Features Every Business Should Look For

In a world where everything is becoming connected — from factory equipment and refrigeration units to entire building...
Read more