Definition
LoRaWAN is a network protocol built on the LoRa physical layer. End devices operate in Class A (most energy-efficient), Class B (supports downlink slots), and Class C (continuous listening); gateways only perform transparent forwarding (Packet Forwarder), with data distributed to application servers through the NS (Network Server).
End Device Types
Class A: After the terminal sends data, it opens two short receive windows. This is the most energy-efficient mode, suitable for uplink-only sensors; Class B: On the basis of Class A, it adds scheduled receive slots (Beacon synchronized), supporting downlink scheduling; Class C: Continuously listens except when sending, suitable for scenarios requiring real-time downlink (such as switch control), with the highest power consumption. The vast majority of LPWAN sensors use Class A.
Network Architecture
Terminal → Gateway (Packet Forwarder) → NS (Network Server, responsible for ADR, Join, routing) → AS (Application Server) or cloud platforms integrating NS+AS. Between the gateway and NS, encrypted UDP transmission is commonly used. Supports OTAA (Over-The-Air Activation) and ABP (Activation By Personalization) two network access methods. In China, private LoRaWAN networks can be deployed, or public LoRaWAN services such as Tencent Cloud and Alibaba Cloud can be joined.
Applications and Selection
LoRaWAN is suitable for AMR metering, environmental monitoring, agriculture, smart cities, etc. When selecting, considerations include: private deployment vs public cloud; gateway coverage and quantity; terminal Class type; integration method with existing systems (API, MQTT, etc.).
Join keys and session keys
The network protocol states how a device joins, how the frame counter blocks replay, how application data is encrypted, and which stretch belongs to the gateway, the network server, and the application server. Over-the-air activation derives session keys from a root key at join, and the device and the server each keep a counter. Activation by personalization writes the session keys into the device and the server in advance, which saves the join round trip, and the counters still have to be kept. In the standard architecture a gateway only transmits, receives, and forwards radio frames. It does not hold the application key. Capturing a gateway log is not the same as reading the application plaintext. A confirmed frame requires a downlink from the server. An unconfirmed frame is not guaranteed to arrive. Device class decides the chance of a downlink. The class that saves the most power opens only two short windows after its own uplink. The class that listens continuously keeps the receiver almost always on.
The conditions are regional parameters for frequency, power, and duty cycle that match the deployment, and a network server that uses the same set. When several gateways receive the same frame, the server removes the duplicates. The application should not treat them as several events. A downlink has to wait in a queue for that device's receive window. If the window is missed, it waits for the next uplink. A Class B device depends on a beacon to line up extra windows. If it cannot hear the beacon, it falls back to windows only after an uplink. Keys should be separable by device and by application. If the whole network shares one application key, one leaked device can decrypt the other devices' traffic.
Confirmed frames and the duty-cycle cap
After an activation-by-personalization device changes server, or an old backup is restored, the frame counter is smaller than the one the server remembers. Later frames are dropped as replays. The radio looks normal and the application is empty. Clearing the counter without clearing the server state at the same time is a common cause. If over-the-air activation joins again on every power-up, it consumes downlink windows and airtime, and both the battery and the channel get worse. Save the session, and join again only when the session is no longer valid. If every packet has to be confirmed, the gateway downlink duty cycle is exhausted first, and the far devices fail first.
If adaptive data rate on the device does not match the server, the server sends the downlink at the wrong rate and the device never hears it. If the channel table is missing one frequency, the device still transmits on that frequency and the server does not receive it. An application that treats a gateway identity as the device position is wrong. The gateway only says which gateway heard the frame. It is not a substitute for a satellite fix. Put the clock in the application payload. The network server's receive time is the arrival time, and a backlog or a buffer makes the two differ. When keys are rotated, overlap the old and new sessions. Replacing them all at once takes a batch of devices still on the old key offline together. Configuring the class as continuous receive, while the firmware sleeps like the most economical class, makes downlink commands time out across the board.
Keeping the session and the counter
A session from over-the-air activation should be kept in the device. Do not join again on every power-up. Joining often occupies downlink windows and makes the battery and the channel worse. An activation-by-personalization frame counter can only move forward. After an old backup is restored or the server is replaced, a smaller counter makes frames look like replays and they are dropped, while the radio figures stay completely normal. When the counter is cleared, clear the server state with it. Clearing only one side makes the device look online with no data.
Separate keys by device and by application. One application key for the whole network means one leaked device affects the others. Leave an overlap when keys are changed, so devices still on the old session keep working until the update finishes. When the server sends at the wrong rate, uplinks look normal and downlinks are all missing. Check which side decides adaptive data rate. If the channel table omits one frequency, the device will still transmit on it. A gateway identity is not a geographic position. The time in the application payload is the sample time. The time the server records is the time it was received. Device class has to match the firmware. Configuring continuous receive while the firmware still sleeps for long periods makes downlink commands time out.
Handle frame-counter rollover at the width the protocol defines. If the application judges duplicates with a smaller counter of its own, it drops data at the rollover. When a server is migrated, move the counters and the sessions with the keys. Moving only the keys and not the counters makes every device look like a replay and get rejected. If a Class B device cannot hear the beacon, the extra downlink windows disappear and only the short windows after an uplink remain, so a scheduled command waits longer. A continuously receiving device draws current close to being on all the time. Do not stock batteries using the life of the most economical class. The application server should drop duplicate uplinks. Several gateways hearing the same frame is normal. A key update should record the device identity and the time it takes effect. During the overlap both keys can decrypt, and the old key is retired when the overlap ends. If class, channel, or rate disagrees with the firmware, uplinks succeed now and then and downlinks mostly fail.