10 LoRaWAN Network Architecture
End Devices, Gateways, Network Server Control, Join and Application Boundaries, Downlink Scheduling, and Release Evidence
10.1 Start Simple
A LoRaWAN gateway is closer to a listener than a device owner. It hears radio frames and forwards packet records. The network server decides what to accept, deduplicate, route, and schedule. Start by tracing one uplink from device to gateway set to network server to application service. If that path is clear, downlink timing, joins, roaming, and troubleshooting have a place to attach.
Phoebe’s Why
Antenna gain is a fixed transmit (or receive) power redistributed in space, not extra power from nowhere – concentrate it into a narrow cone and every other direction gets less. This chapter’s whole point is that a gateway is a listener that lets multiple gateways hear the same uplink so the network server can deduplicate; that only works if the gateway antenna does not commit its sensitivity to one direction. A near-omnidirectional gateway antenna hears devices scattered every which way, at the cost of less gain toward any one of them than a directional link would offer. The end device pays the same price in reverse: since it does not know which gateway, if any, will hear it, it also cannot aim a beam – which is exactly why the campus example later in this chapter uses three separate gateways positioned around campus instead of one high-gain antenna pointed at a subset of sensors.
The Derivation
EIRP combines conducted power and antenna gain:
\[\mathrm{EIRP(dBm)} = P_t(\mathrm{dBm}) + G(\mathrm{dBi})\]
Directivity ties gain to the solid angle \(\Omega\) (steradians) the antenna concentrates power into:
\[G = \frac{4\pi}{\Omega}\]
so for two antennas fed the same power, the ratio of coverage solid angle is the inverse of the ratio of linear gain:
\[\frac{\Omega_1}{\Omega_2} = \frac{G_2}{G_1}\]
Worked Numbers: Omni Gateway Versus a Directional Swap
- EU 868 MHz device EIRP cap (as established in the Frequency Bands chapter): about 41 mW \(\approx 16.1\) dBm. With a typical 2.15 dBi dipole-class device antenna, conducted power \(\approx 16.1 - 2.15 = 13.9\) dBm \(\approx 25\) mW – matching the commonly quoted 25 mW class of LoRaWAN end-device radios
- Typical omnidirectional gateway antenna: \(G \approx 3\) dBi (illustrative, standard fiberglass omni figure) \(\rightarrow\) linear \(10^{0.3} = 2.00\); \(\Omega = 4\pi/2.00 = 6.28\) sr, close to a full sphere – consistent with “near-omnidirectional”
- Swap to a directional gateway antenna at 12 dBi: linear \(10^{1.2} = 15.8\); \(\Omega = 4\pi/15.8 = 0.793\) sr
- Solid-angle shrink: \(6.28/0.793 = 7.92\times\) – almost exactly the \(10^{(12-3)/10} = 7.94\times\) gain the directional antenna adds (matching, since \(G \propto 1/\Omega\) exactly)
The directional swap buys about 9.0 dB more received power from devices inside its narrow lobe, but stops hearing roughly seven out of every eight directions the omni antenna covered. That is precisely why the campus deployment example in this chapter spreads three gateways around the site instead of pointing one high-gain antenna at part of it – the “gateway set can hear the device group” evidence this chapter’s release record asks for depends on that wide pattern.
Overview: LoRaWAN Architecture Is a Boundary Map
LoRaWAN architecture is a star-of-stars network pattern for small IoT messages. End devices transmit LoRa radio frames. One or more gateways may hear the same uplink. Gateways forward packet records and reception metadata over IP. The network server validates traffic, deduplicates gateway copies, handles MAC behavior, schedules downlinks, and routes payloads toward application systems.
The beginner mistake is to treat a gateway like a Wi-Fi access point, router, or device owner. In LoRaWAN, the gateway is a forwarding point. The network server is where the architecture makes most of its control decisions.
For example, if sensor S-17 is heard by gateways G1 and G2 during the same uplink, the application should receive one temperature event, not two competing events. The release record therefore needs the device identifier, both gateway reception records, the network-server duplicate-handling evidence, the application route, and the owner who accepts the payload meaning. That same record should say what happens if G2 is moved to a new roof or the server route changes.
A useful architecture diagram is therefore less about drawing every cable and more about proving boundaries. It should let a reviewer trace one uplink from device to gateway set to network server to application owner, then trace one downlink request back through the network-server queue to the class-specific receive opportunity. If either path depends on a hidden setting, the architecture is not ready for release.
If you only need the intuition, remember this: approve a LoRaWAN architecture only when the device group, gateway hearing path, network-server boundary, join boundary, application owner, device-class promise, ADR policy, and retest trigger are visible.
The One-Minute Architecture Review
End Device
Sends uplinks, keeps counters, follows the selected class behavior, and opens receive opportunities according to the device mode.
Gateway
Receives LoRa frames and forwards packet records with metadata. It does not own application meaning or MAC policy.
Network Server
Validates, deduplicates, manages MAC behavior, controls ADR decisions, schedules downlinks, and routes payloads.
Application Boundary
Owns payload meaning, business action, application-level acknowledgements, and requests for downlinks.
Architecture Claims That Need Evidence
- Coverage claim: which device groups can be heard by which gateway set?
- Server claim: which network server owns validation, deduplication, routing, MAC behavior, and scheduling?
- Activation claim: which join or session-state boundary is in scope, and who owns exceptions?
- Application claim: which service owns payload meaning, command intent, and release acceptance?
- Retest trigger: gateway movement, antenna change, server migration, activation-policy change, device-class change, payload change, or application timing change.
Overview Knowledge Check
Practitioner: Build the Architecture Release Record
A release-ready LoRaWAN architecture record is not a decorative diagram. It is a set of claims that another reviewer can verify from packet records, server settings, join evidence, gateway metadata, application route evidence, and the operations owner for future changes.
The record should be specific to the device group and deployment condition. A campus meter design, a rural environmental sensor, and a mobile asset tag may all use LoRaWAN, but they do not share the same gateway evidence, downlink promise, ADR assumptions, or retest triggers.
Minimum Record Fields
Worked Review: Campus Occupancy Sensors
A campus project adds three gateways and claims the LoRaWAN network is redundant. A stronger review does not approve the claim from gateway count alone. It asks which sensor groups each gateway can hear, whether duplicate uplinks are deduplicated before application delivery, which network server owns route decisions, and whether the application can wait for the selected device-class receive behavior.
The release statement becomes narrower and stronger: "Device group A is heard by gateway set 1 under the final antenna placement; duplicate gateway copies converge at the network server; payloads route to the occupancy application; Class A is accepted because commands can wait for the next device uplink; gateway or antenna movement reopens the review."
Practitioner Knowledge Check
Under the Hood: Server Boundaries, Downlinks, and Retests
Under the hood, LoRaWAN architecture is a set of control boundaries. The end device owns its local transmit behavior and class behavior. The gateway forwards radio observations. The network server makes network-layer decisions. Join handling creates or validates session state. Application systems interpret payload meaning and request application-driven downlinks.
When these boundaries blur, reviews become fragile. A successful uplink does not prove that downlinks are schedulable. A gateway record does not prove application acceptance. A dashboard value does not prove that activation, counters, or duplicate-copy handling are correct.
A packet trace should also preserve the frame evidence that explains which boundary is being tested. At the outer level, a LoRaWAN frame carries an MHDR, a MAC payload, and a message integrity code (MIC). The frame header includes fields such as DevAddr, FCtrl, FCnt, and optional FOpts. The FPort value separates MAC-command use from application payload use; in review records, note when port 0 is carrying MAC behavior rather than ordinary application data. Keeping these fields visible prevents a "packet arrived" log from hiding whether the evidence belongs to addressing, counters, MAC behavior, integrity, or application delivery.
Control Boundary Rules
- Gateway evidence is path evidence. It helps prove who heard a frame and with what metadata; it does not prove payload meaning.
- Network-server evidence is control evidence. It should show validation, duplicate handling, routing, ADR policy, downlink queue behavior, and owner accountability.
- Join evidence is session evidence. It should show how activation or loaded session state becomes usable, how counters behave, and how exceptions are recovered.
- Application evidence is meaning evidence. It should show decoder behavior, acceptance rules, command intent, and integration ownership.
- Class evidence is timing evidence. It should show when the device can hear downlinks and whether the application promise fits that timing.
Downlink Review Pattern
A downlink is not simply "the application sends a message to the device." The application requests a downlink. The network server decides whether it can schedule that message, chooses a gateway path that fits recent evidence, and waits for a receive opportunity that the device class actually provides.
Class A designs must tolerate waiting for the device to transmit before receive windows open. Class B designs need scheduled receive evidence and a plan for missed schedule signals. Class C designs need energy-source and operations review because the device listens far more often.
Retest Signals
- Retest when a device group moves, gateway placement changes, antenna orientation changes, or a backhaul path changes.
- Retest when payload size, message cadence, downlink promise, or application command semantics change.
- Retest when the network server, join boundary, route integration, ADR policy, or queue behavior changes.
- Retest when activation method, key custody, frame-counter recovery, or reset handling changes.
- Retest when operations ownership changes and the previous release owner can no longer answer exception questions.
Under-the-Hood Knowledge Check
10.2 Summary
LoRaWAN network architecture separates radio forwarding, network control, activation, application meaning, downlink timing, and release ownership. End devices transmit. Gateways forward what they hear. The network server validates, deduplicates, controls MAC behavior, schedules downlinks, manages ADR decisions, and routes payloads. Join and application boundaries must stay explicit, because a gateway record, a dashboard value, or a single successful uplink does not prove the whole architecture. A release-ready review records gateway evidence, server ownership, activation behavior, application routing, selected class, exceptions, and retest triggers.
10.3 Key Takeaway
LoRaWAN architecture is approved by boundary evidence: who heard the device, who made the network decision, who owns activation and payload meaning, when the device can receive, and what change reopens the review.
10.4 See Also
LoRaWAN Introduction
Start here when the LoRa versus LoRaWAN boundary or workload fit is still unclear.
LoRa Modulation and Spreading Factors
Use this for radio settings, airtime evidence, spreading-factor choices, and ADR handoff vocabulary.
LoRaWAN Device Classes Review
Use this when the application promise depends on downlink timing and receive-window behavior.
LoRaWAN Security and Joining Review
Use this when activation, key custody, frame counters, or reset recovery affect the architecture decision.