Architecture
LoRaWAN end devices communicate with gateways using spread spectrum modulation. Gateways forward data via IP to the NS (Network Server), which then interfaces with application servers. Classes A/B/C determine downlink slots and power consumption. Keys and the Join process (OTAA/ABP) must be strictly managed to prevent cloning.
Compared with cellular
Unlicensed band self-built networks are flexible, but QoS and interference are self-managed; cellular NB-IoT is operated by carriers. Hybrid gateways can integrate LoRa and 4G backhaul simultaneously.
Limitations
Duty cycle and packet size restrictions follow regional regulations; downlink capacity is limited, not suitable for video.
Network planning and gateway backhaul
LoRaWAN capacity is jointly constrained by spreading factor, bandwidth, gateway channels, and air-time occupancy. When planning, simulate node density and collision probability. When gateways connect to the cloud via Ethernet or 4G, separating the NS (Network Server) and AS (Application Server) facilitates multi-tenancy. Roaming and handover in LoRaWAN differ from cellular networks; crossing operators or NS requires pre-agreed Join Server settings and key derivation. In hybrid scenarios, critical alarms can use confirmed uplinks with retransmission strategies, but this consumes more duty cycle.
Security and Lifecycle
OTAA derives network session keys using the AppKey; if the private key is leaked, terminals can be cloned. ABP static sessions are more difficult to rotate. Frame counters should be enabled to prevent replay attacks and root keys should be updated in a versioned manner. Device recycling and second-hand circulation must support key erasure and re-registration. Compared to cellular modules, LoRa on unlicensed bands is prone to co-channel interference; site selection and antenna height greatly affect link budget, so on-site surveys cannot be skipped.
Engineering Practice Supplement
Starting from 'LoRaWAN', common on-site issues often concentrate on 'measured parameters meeting laboratory standards but difficult to reproduce in the field'. Beyond RF and protocol issues, check for power ground bounce, connector contact issues, and firmware race conditions. On the cellular side, it is recommended to collect RSRP/SINR, cell reselection, and PDP session reconstruction records; on the application side, have clear strategies for retries, idempotency, and queue persistence. When involving data security and compliance, document data collection scope, storage location, retention period, and third-party sharing in privacy policies and contract annexes to avoid high post-deployment remediation costs.
How the Join Server and the Session Keys Split the Work
LoRaWAN separates “may this device join” from “which session-key pair does this air interface use.” In OTAA, the device proves its identity to the Join Server with a root key, and the network server then delivers a short-lived network session key and application session key. The gateway only forwards radio frames. It does not store those keys. Taking a gateway away is not a key leak. A leak of the root key, or of the Join Server configuration, is what produces a cloned device. ABP skips the join. Session keys are written at manufacture. Replacing the network server in the field means rewriting every device, or the frame counters will not match and the server will drop legitimate packets as replays.
The protocol also requires the frame counter to increase steadily. If the counter returns to an old value after a power loss while the server still remembers a higher one, uplink is dropped quietly while the radio layer still shows a successful send. That has nothing to do with whether the LoRa modulation “reaches far enough.” The MAC state is inconsistent.
A Class A Window Opens Only After an Uplink
Class A opens two very short receive windows after each uplink. Downlink has to catch one of them. If the platform wants to push a configuration, it can only wait until the device next wakes on its own. Class B aligns extra windows to a beacon. Class C receives almost all the time, and both battery use and gateway downlink capacity rise sharply. Use Class A when downlink can follow uplink. Consider Class B only when commands must go out on a fixed beat and the device can afford the synchronization. Use Class C only for nodes that have plenty of power and frequent downlink.
Duty cycle, channel count, and the gateway’s eight-channel plan in the same area decide how many nodes fit. A high spreading factor and many confirmed frames cut one gateway’s useful capacity sharply. Confirmation is not a free reliability switch. If the device misses the ACK it retransmits, and the retransmission keeps occupying the unlicensed channel. Confirm a critical alarm. Leave periodic telemetry unconfirmed, and let the application use a sequence number to see the gaps. If backhaul from the gateway to the network server breaks, the air interface is still receiving. Integrity checks and application decryption have not happened yet. RSSI in the gateway log is not proof that the platform has stored the payload.
Confirmed Retransmissions Use Up the Region’s Airtime
A common mistake is to turn confirmed uplink on for every sensor and, on failure, retry at the shortest interval. A few nodes quickly exhaust the duty cycle of the unlicensed band, and the rest look like random packet loss. Another mistake is burning the same DevEUI, JoinEUI, and root key on the production line. Two devices fight over one counter. The network accepts for a while, then rejects the frame as a replay. Where several gateways overlap, skipping duplicate elimination delivers several copies of the same payload to the application server. If the application is not idempotent, it acts more than once.
ADR is often enabled by mistake. The network server looks at uplink statistics and suggests a lower spreading factor. If the node sits on a pallet that moves, or the antenna is occasionally blocked, the rate is lowered and the link suddenly is not enough, and it takes a long time to come back. Hand rate adaptation to the network only for fixed nodes on a stable channel. For nodes that move or are often shaded, lock a set of parameters already known to work, and cap how many uplinks the application may send per day.
The downlink window also has to be counted against the regional duty cycle. If the network server schedules downlink for many nodes in the same second, the gateway’s transmissions use up that channel’s time allowance, and later acknowledgements never get a slot. If the application treats “queued” as “the device has received it,” the device keeps the old configuration. Separate three states: queued, transmitted by the gateway, and confirmed by the device. A device in deep sleep does not hear the first window. The second window may use a different rate and channel. If the firmware opens only one of them, the platform shows a send and the device has no record.