LoRa & LoRaWAN · Study deck

LoRaWAN Network Architecture

A water meter transmits once and two rooftop gateways hear it.

Radio Remi is your guide for this deck.

network

Radio Remi, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Explain: A star-of-stars diagram is useful only when its trust boundaries are explicit. Figure: LoRaWAN star-of-stars trust-boundary architecture from end devices and separates radio forwarding, network control, join material, and application decryption.
Explain: 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.
Explain: The gateway-selection step is worth tracing concretely, because it is easy to assume the network server just replays the downlink through whichever gateway happened to hear the uplink.

Major section

Start Simple · Eddie's Math Bridge: Gateway Gain And Coverage Shape

LoRaWAN is a low-power radio system in which gateways hear device messages and pass them to a network service.

A gateway is one of those radio listening points.
A device may send well but listen only at short times.
A heard frame is not the same as an accepted reading.

Open DIY LoRaWAN gateway enclosure containing a Raspberry Pi, concentrator, PoE adapter, radio connection, and field wiring

Major section

Overview: LoRaWAN Architecture Is a Boundary Map · Practitioner: Build the Architecture Release Record

LoRaWAN architecture is a star-of-stars network pattern for small IoT messages.

One or more gateways may hear the same uplink.
Gateways forward packet records and reception metadata over IP.
The beginner mistake is to treat a gateway like a Wi-Fi access point, router, or device owner.

LoRaWAN architecture path: end devices transmit, gateways forward, the network server decides, and application systems receive routed payload meaning.

Major section

Under the Hood: Server Boundaries, Downlinks, and Retests

Under the hood, LoRaWAN architecture is a set of control boundaries.

The gateway forwards radio observations.
The network server makes network-layer decisions.
A successful uplink does not prove that downlinks are schedulable.
A gateway record does not prove application acceptance.

Downlink scheduling is a boundary-crossing action: application intent, network-server queueing, gateway selection, device receive opportunity, and verification must all line up.

Major section

Under the Hood: Server Boundaries, Downlinks, and Retests (continued)

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 ).
Network-server evidence is control evidence.: It should show validation, duplicate handling, routing, ADR policy, downlink queue behavior, and owner accountability.

Major section

Under the Hood: Server Boundaries, Downlinks, and Retests (continued)

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.
A release record that treats "the MIC checked out" as proof the application payload is trustworthy is collapsing two different boundaries into one.
Application evidence is meaning evidence.: It should show decoder behavior, acceptance rules, command intent, and integration ownership.

Major section

Under the Hood: Server Boundaries, Downlinks, and Retests (continued)

Retest when payload size, message cadence, downlink promise, or application command semantics change.

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.
Class evidence is timing evidence.: It should show when the device can hear downlinks and whether the application promise fits that timing.
Retest when activation method, key custody, frame-counter recovery, or reset handling changes.

Major section

Under the Hood: Server Boundaries, Downlinks, and Retests (continued)

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.
Retest Signals Retest when a device group moves, gateway placement changes, antenna orientation changes, or a backhaul path changes.

Major section

Under the Hood: Server Boundaries, Downlinks, and Retests (continued)

Retest when the network server, join boundary, route integration, ADR policy, or queue behavior changes.

Retest when operations ownership changes and the previous release owner can no longer answer exception questions.
A star-of-stars diagram is useful only when its trust boundaries are explicit. Figure: LoRaWAN star-of-stars trust-boundary architecture from end devices and separates radio forwarding, network control, join material, and application decryption.
The gateway-selection step is worth tracing concretely, because it is easy to assume the network server just replays the downlink through whichever gateway happened to hear the uplink.

Major section

Count Radio Copies Separately from Water Readings

The server finds that 33 readings were heard by both.

The number of distinct readings heard by at least one is 38 + 35 − 33 = 40.
The two forwarding paths carried 73 reception records, but those records describe only 40 device events.
The listening sites forward observations.

LoRaWAN star-of-stars trust-boundary architecture from end devices and gateways through network, join, and application servers.

Major section

Count Radio Copies Separately from Water Readings (continued)

A schema error can therefore reject content even after a valid radio frame reaches the server.

The same test history suggests B heard 35 of the 40 readings, but that is only evidence for the observed interval.
They should not if the application consumes the deduplicated event identity correctly.
This example gives the architecture a measurable division of work.

Major section

Count Radio Copies Separately from Water Readings (continued)

The gateway with the strongest past uplink is not automatically a successful return path: timing, radio availability and the device's receive window still govern the transmission.

Packet-forwarder logs explain what each site heard; server logs explain what was accepted and scheduled; application logs explain what the accepted content caused.
Joining those records makes a missing reading traceable without confusing diversity of reception with duplication of physical events.
It also lets operations judge the value of a second gateway using evidence rather than counting boxes on a diagram.

Major section

Summary · Key Takeaway

LoRaWAN network architecture separates radio forwarding, network control, activation, application meaning, downlink timing, and release ownership.

Gateways forward what they hear.
The network server validates, deduplicates, controls MAC behavior, schedules downlinks, manages ADR decisions, and routes payloads.
A release-ready review records gateway evidence, server ownership, activation behavior, application routing, selected class, exceptions, and retest triggers.

A LoRaWAN pump alarm crosses the end device, gateway forwarder, IP backhaul, network server, and application service with distinct stack boundaries.

Deck summary

Key takeaways

LoRaWAN is a low-power radio system in which gateways hear device messages and pass them to a network service.

LoRaWAN architecture is a star-of-stars network pattern for small IoT messages.
Under the hood, LoRaWAN architecture is a set of control boundaries.
A dashboard value does not prove that activation, counters, or duplicate-copy handling are correct.
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.

Retrieval practice

Recall check 1 of 3

Radio Remi says: answer from memory, then check your reasoning.

Q1A team says each LoRaWAN sensor will be assigned to one gateway so routing is predictable. What should the architecture review correct first?

AEvery device must store a gateway address before sending a valid uplink.

BGateways forward heard uplinks; the network server owns deduplication and routing.

CThe application service should choose the uplink gateway before each transmission.

DGateway assignment removes the need for a network server.

Show answer

Answer: B A LoRaWAN end device is not bound to one gateway in the way a Wi-Fi client associates with an access point.

Retrieval practice

Recall check 2 of 3

Radio Remi says: answer from memory, then check your reasoning.

Q2A release record says only: "Three gateways are installed, so the LoRaWAN architecture is redundant." What evidence is missing?

AIndependent gateway power and backhaul records, to show the infrastructure has separate failure paths.

BOnly a prettier network diagram, because the installed hardware is already sufficient evidence.

CGateway-hearing records, route ownership, class behavior, exceptions, and retest triggers.

DApplication delivery rates during normal operation, to show the installed network carries the sensor workload.

Show answer

Answer: C Gateway count is not enough; the review needs observed path and ownership evidence.

Retrieval practice

Recall check 3 of 3

Radio Remi says: answer from memory, then check your reasoning.

Q3A cloud application requests an urgent LoRaWAN command for a battery device that normally sends one uplink per day. What should architecture review conclude?

AThe command is automatically immediate because the application submitted it to the network server.

BThe gateway can deliver the command whenever it wants, so class behavior does not matter.

CA successful previous uplink proves that every future downlink will arrive immediately.

DCheck device class, receive window, scheduling, gateway path, timing, and fallback.

Show answer

Answer: D An urgent downlink crosses application, network-server, gateway, and device-class boundaries.

Print reference

Answers

Answer key.

B · A LoRaWAN end device is not bound to one gateway in the way a Wi-Fi client associates with an access point.
C · Gateway count is not enough; the review needs observed path and ownership evidence.
D · An urgent downlink crosses application, network-server, gateway, and device-class boundaries.