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

Trace one uplink through two gateways and the network server to the application; count unique events; test downlinks against class timing and path evidence.

Trace one uplink through two gateways, the network server, and the application.Keep gateway reception records separate from the unique device event and application result.
Unique device events are distinct from gateway copies.Gateway copies should be deduplicated before counting readings accepted by the service.
Test a downlink against class timing and gateway evidence.Use the device receive opportunity and observed path to bound the reply claim.

Major section

Start Simple · 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 shows end devices sending data via gateways to the network server, routing to join and application boundaries. — 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)

The network server can verify it without decrypting application content.

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.
AppSKey protects application payload confidentiality at the application boundary.

Major section

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

Class B designs need scheduled receive evidence and a plan for missed schedule signals.

At the outer level, a LoRaWAN frame carries an MHDR, a MAC payload, and a message integrity code ( MIC ).
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.
Retest when payload size, message cadence, downlink promise, or application command semantics change.

Major section

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

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 valid MIC and fresh frame counter support network-side authenticity and replay checks; they do not prove that the decrypted application reading is semantically correct.
Control Boundary RulesGateway 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.

Major section

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

Class A designs must tolerate waiting for the device to transmit before receive windows open.

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.
Retest SignalsRetest 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)

Downlink Review PatternA 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.
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.

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.
The network server can verify it without decrypting application content.
Class B designs need scheduled receive evidence and a plan for missed schedule signals.

Retrieval practice

Recall check 1 of 4

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?

ADevices store one gateway address before sending each uplink.

BGateways relay heard uplinks; the server deduplicates and routes them.

CApplications choose the gateway before each sensor transmission.

DFixed gateway assignments remove 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 4

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." To prove that affected sensor groups have alternate gateway reception and a reviewable routing path, what evidence is missing? Choose the most complete answer.

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 4

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.

Retrieval practice

Recall check 4 of 4

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

Q4A network server is replaced while field devices stay the same. What should be retested?

ARetest nothing because unchanged device firmware supposedly freezes server behavior.

BRetest gateway power alone, skipping new server acceptance and routing decisions.

CRetest dashboard colors alone, skipping network control and application delivery.

DRetest acceptance, deduplication, ADR, downlink timing and app routing.

Show answer

Answer: D The server owns decisions that can change even with identical devices.

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.
D · The server owns decisions that can change even with identical devices.

B: keep gateway receptions separate from unique device events. C: the most complete architecture review record. A adds independent power and backhaul evidence; D adds measured application delivery. Those are relevant partial evidence, while C is the most complete answer.