LoRa & LoRaWAN

Modulation, Network Architecture, Device Classes, ADR, Security, Deployment, and Review Evidence

Intermediate LoRaWAN module index that introduces the LoRa and LoRaWAN pathway, distinguishes modulation from network architecture, and guides learners through architecture, device classes, ADR, security, deployment, and review chapters.
Radio Remi, your wireless guide

Your guide: Radio Remi

“Range, power, and data-rate is a triangle — pick two honestly, then measure the third in the real room.”

Start Simple

A city team does not start a LoRaWAN review by choosing a gateway or a spreading factor. It starts with a simple promise: small devices need to report modest facts from places where power, distance, and maintenance are constrained. Follow that promise through the module. First separate LoRa radio from LoRaWAN network behavior, then ask what evidence would prove the path from device to gateway to network service to application owner.

In 60 Seconds

LoRa is a radio modulation technique. LoRaWAN is the network architecture and protocol system that uses LoRa radios to move small device messages through gateways, network services, and application services. This module teaches the difference between the radio layer and the network layer, then builds toward architecture review, device classes, adaptive data-rate policy, joining and keys, deployment checks, and troubleshooting evidence.

Minimum Viable Understanding

  • LoRa and LoRaWAN are not the same thing. LoRa describes the physical radio modulation; LoRaWAN defines device behavior, gateways, network services, message security, classes, and application handoff.
  • Gateways forward radio frames; they do not own device sessions. Network services handle deduplication, message counters, joins, routing, and downlink scheduling.
  • Device class is an availability contract. Class A, B, and C change when a device can receive downlinks and what the system must budget for listening windows.
  • Deployment review is evidence-based. Channel plan, link budget, gateway placement, join method, key handling, ADR policy, and failure logs must be reviewable.

Learning Objectives

By the end of this module, you will be able to:

  • Separate LoRa radio concepts from LoRaWAN network architecture.
  • Trace a LoRaWAN uplink from end device to application service.
  • Compare device classes and explain their downlink behavior.
  • Review ADR, link budget, gateway placement, and channel-plan decisions.
  • Identify joining, key, frame-counter, replay, and message-integrity evidence.
  • Use review chapters and quizzes to validate a LoRaWAN deployment design.

Architecture At A Glance

The core LoRaWAN path is a shared radio path into one or more gateways, followed by network-layer filtering, session handling, and application delivery.

LoRaWAN architecture route with end devices, gateways, network service, join and session handling, and application service handoff.
Figure 1: LoRaWAN architecture route showing end devices, gateways, network service, join and session handling, and application service handoff.
Radio

LoRa modulation

Understand spreading factor, bandwidth, coding, link budget, and how radio settings affect airtime and robustness.

Network

LoRaWAN architecture

Trace end devices, gateways, network services, application services, joins, frame counters, and message routing.

Operation

Classes and ADR

Review receive-window behavior, downlink timing, adaptive data-rate policy, and what evidence confirms the chosen class.

Release

Deployment evidence

Collect channel-plan, join, key, gateway, coverage, queue, downlink, and troubleshooting records before approval.

Learning Pathway

Use the module as a sequence. Start with the difference between LoRa and LoRaWAN, then move from radio behavior into network architecture, operating policy, and review evidence.

LoRaWAN learning pathway from fundamentals through radio layer, network architecture, device behavior, deployment review, and assessment.
Figure 2: LoRaWAN learning pathway showing fundamentals, radio layer, network architecture, device behavior, deployment review, and assessment.

Recommended route:

Module Decisions To Review

LoRaWAN design choices affect each other. A good review does not approve one setting in isolation.

LoRaWAN decision review with message need, radio settings, gateway placement, device class, ADR policy, security joining, and deployment evidence.
Figure 3: LoRaWAN decision review showing message need, radio settings, gateway placement, device class, ADR policy, security joining, and deployment evidence.

Key review questions:

  • What message size, direction, and urgency does the application need?
  • Which radio settings are allowed for the local channel plan?
  • Which gateways can hear the device, and how is duplicate uplink handling verified?
  • Which device class is used, and how are downlink windows tested?
  • When is ADR allowed, disabled, or bounded?
  • Which join method, key material, frame counters, and replay checks are recorded?
  • What evidence shows that missed uplinks, failed joins, and downlink queue limits are handled?

What Good Evidence Looks Like

A LoRaWAN review package should be specific enough for another reviewer to reproduce the decision.

LoRaWAN release evidence map with channel plan, link budget, gateway placement, device class, ADR policy, joining and keys, traffic evidence, and troubleshooting logs.
Figure 4: LoRaWAN release evidence map showing channel plan, link budget, gateway placement, device class, ADR policy, joining and keys, traffic evidence, and troubleshooting logs.

Include:

  • Channel plan and allowed radio settings.
  • Link budget assumptions and field check notes.
  • Gateway placement and duplicate-uplink evidence.
  • Device class choice and downlink-window test.
  • ADR policy, exclusions, and rollback condition.
  • Join method, key ownership, message counters, and replay checks.
  • Traffic samples for accepted, rejected, retried, and missed messages.
  • Troubleshooting notes with root cause and owner.

Chapter Review Checklist

Before leaving the module index, make sure you can answer:

  • Which parts of the design belong to LoRa, and which belong to LoRaWAN?
  • What evidence proves the gateway path and network-service path are distinct?
  • How does the selected device class affect downlinks?
  • How are ADR changes bounded and reviewed?
  • Which join and key evidence is required before release?
  • Which chapter should a learner open for architecture, radio, deployment, or review questions?

Knowledge Check

Common Pitfalls

Missed messages can come from channel plan, gateway hearing, deduplication, counters, queues, downlink timing, or application routing. Separate the layers before fixing.

ADR is a policy that must be bounded and reviewed. It needs field evidence, exclusion cases, and a rollback condition.

Gateways are important infrastructure, but they are not the place to mix application ownership, key ownership, or network-session decisions without evidence.

A deployment review should keep examples of missed uplinks, failed joins, rejected counters, and queued downlinks, not only successful traffic.

Summary

This module starts by separating LoRa radio behavior from LoRaWAN network behavior. It then builds the review path through modulation, architecture, device classes, ADR, security, deployment, troubleshooting, and assessment. Treat every design choice as a traceable decision with evidence: channel plan, link budget, gateway path, network-service behavior, class behavior, join and key handling, and release ownership.

Start Here

Back to All Modules