Understanding the Difference Between the LoRaWAN Network Server and Application Server
In many LoRaWAN projects, one of the most common sources of confusion is the difference between the Network Server and the Application Server. Although both are essential components of a LoRaWAN system, they serve very different purposes. Understanding their roles can help you design, deploy, and troubleshoot your network more effectively.
Data packet
A LoRaWAN data packet (payload) consists of two parts: MAC commands and application data. Each part is encrypted with a specific security key.
The LoRaWAN Architecture in Brief
A typical LoRaWAN system consists of four key layers (here we removed the Join Server for clarity):
Each layer performs a distinct function. Let’s look at the Network Server and Application Server more closely.
The Network Server
The Network Server (NS) manages all the communication logistics of the LoRaWAN network.
When a device sends data, several gateways might receive the same uplink. The Network Server collects these packets, checks their integrity, and decides which gateway should be used for the downlink response.
Its primary responsibilities include:
- Packet de-duplication (removing duplicates from multiple gateways)
- Message integrity verification (MIC check)
- Decrypting MAC commands
- Handling MAC commands such as Adaptive Data Rate (ADR) and LinkCheck
- Session management (device activation, frame counters, network keys)
- Forwarding application payloads to the Application Server
Essentially, the Network Server ensures that data from devices travels reliably and securely through the LoRaWAN network.
Think of the Network Server as a postal sorting center - it receives many letters (packets), verifies their origin, removes duplicates, and forwards the right envelope to the right destination.
The Application Server
Once the Network Server has done its job, the Application Server (AS) takes over.
The Application Server deals with the actual sensor data — the information your end users care about. It decrypts the application payload using the AppSKey and converts the raw bytes into meaningful values such as temperature, humidity, or battery voltage.
Typical tasks of the Application Server include:
- Decrypting the application payload
- Decoding raw data into human-readable sensor values
- Storing and displaying sensor data in dashboards or databases
- Sending commands back to devices (for example, turning an actuator on or off)
You can think of the Application Server as the recipient of the letter - it opens the envelope and interprets the contents.
How Network Server and Application Server process the payload
Many users expect the Network Server to immediately show sensor readings such as temperature or soil moisture. However, that’s not its job. The Network Server only handles the LoRaWAN protocol layer — not the meaning of the data.
The Application Server (or a decoder running on it) is responsible for translating the raw payload into something readable. So when you see a payload like 016A03, that’s still encrypted or encoded data from the Network Server. The Application Server is what turns it into something meaningful like:
Temperature: 26.6 °C
Battery Voltage: 3.7 V
Example Data Flow
| Step | Component | Action |
|---|---|---|
| 1 | Device | Sends LoRaWAN packet with encrypted payload |
| 2 | Gateway | Forwards the packet to the Network Server |
| 3 | Network Server | Validates, de-duplicates, and decrypts the network layer |
| 4 | Network Server to Application Server | Sends the application payload to the Application Server |
| 5 | Application Server | Decrypts and decodes the payload for end users |
Comparison of features
| Feature | Network Server | Application Server |
|---|---|---|
| Primary Role | Manages LoRaWAN communication | Processes and interprets data |
| Keys Used | NwkSKey | AppSKey |
| Manages ADR, Frame Counters | Yes | No |
| Knows Device Data Meaning | No | Yes |
| Output | Raw, encrypted payload | Decoded, meaningful values |
Example with The Things Stack
The Things Stack (TTS) is commonly referred to as a LoRaWAN Network Server. However, it also includes an Application Server component. Both parts are built into the same platform, even though they handle different functions.
When you register a device in TTS, you also create an application. This application runs on the Application Server. Don’t confuse this Application Server with external IoT integration platforms like AWS IoT, Azure IoT, or ThingsBoard. Those platforms can only receive already-decoded data. They cannot decrypt LoRaWAN application payloads.
Each registered device is associated with an application. Within that application, you can define payload formatters (decoders) to interpret the raw data sent by your devices. These formatters can be application-wide or device-specific.
When the Network Server receives a message from a device, it first checks and processes the payload. A LoRaWAN payload may contain:
- MAC commands (used for network control), and/or
- Application data (sensor readings).
If the payload includes application data, the Network Server forwards it to the Application Server. The Application Server then decrypts the application payload using the AppSKey and optionally decodes it according to your payload formatter.
Meanwhile, any MAC commands are processed by the Network Server, since they relate to network-level functions such as Adaptive Data Rate (ADR) or link checks.