LoRa Overview

LoRa (Long Range) is a proprietary wireless modulation technology developed by Semtech, based on Chirp Spread Spectrum (CSS) modulation.

It is designed for long-range, low-power, and low-data-rate communication — ideal for IoT applications such as sensors and meters.

Key features:

Long range: 2–15 km communication distance (depending on frequency band, antenna, and environment)
Low power consumption: suitable for battery-powered devices
Strong interference resistance: operates reliably even under low signal-to-noise ratio (SNR) conditions
Low data rate: typically 0.3 kbps to 50 kbps

LoRa defines only the physical (PHY) layer — that is, how signals are modulated and transmitted — but not the higher-level networking or communication protocols.

LoRaWAN Overview

LoRaWAN (LoRa Wide Area Network) is a MAC (Media Access Control) and network layer protocol built on top of the LoRa physical layer.

It is standardized and maintained by the LoRa Alliance to enable large-scale, low-power IoT networks.

A LoRaWAN network typically includes four main components:

Component	Description
End Device (Node)	Collects sensor data (temperature, GPS, etc.) and transmits it using LoRa
Gateway	Receives LoRa packets from end devices and forwards them to the network server over IP (Ethernet, cellular, Wi-Fi)
Network Server	Manages message routing, de-duplication, security checks, and MAC commands
Application Server	Decodes application payloads and delivers data to user applications

Typical LoRaWAN network implementation from end to end

LoRaWAN Characteristics:

Supports bi-directional communication (uplink + downlink)
Provides AES-128 encryption for security
Uses a Star-of-Stars network topology
Defines three device classes (A, B, and C) for different power and latency requirements

ED - End Device
- directly to all gateways within range, usingtransmit LoRa
GW - Gateways
- PF - Packet forwarder (conf-local)
- BS - Basics station (conf-remote)
- Forwarding between LoRa and IP
LNS(NS) - LoRaWAN network server
- Ensures the authenticity and integrity
- servers that route messages from End Devices to the right Application, and back.
AS - Application server
- Securely handling sensor app data
JS - Join Server
- Manages the OTAA process
- Its role is to store root keys, generate session keys and to send those securely to the Network Server and Application Server of choice

LoRaWAN Protocol Stack

LoRaWAN Classes

LoRaWAN defines three types of end devices — Class A, Class B, and Class C — to balance power consumption and downlink latency for various use cases.

Class A

Devices support bi-directional communication between a device and a gateway.
Uplink messages (from the device to the server) can be sent at any time (randomly).
The device then opens two receive windows at specified times (1s and 2s) after an uplink transmission.

Communication behavior:

Each uplink transmission is followed by two short receive windows:
- RX1: opens a fixed delay (e.g., 1 second) after uplink
- RX2: opens after another fixed delay (e.g., 2 seconds total)
Downlink messages can only be received during these windows.

Advantages:

Minimal power consumption
Simplest implementation; mandatory for all devices

Disadvantages:

High downlink latency — the server must wait until the next uplink before it can send data

Typical use cases:

Periodic environmental monitoring
Smart metering (gas, water, electricity)

Class B

Devices extend Class A by adding scheduled receive windows for downlink messages from the server.
Using time-synchronized beacons transmitted by the gateway, the devices periodically open receive windows.

Communication behavior:

In addition to Class A’s two receive windows, Class B devices open extra periodic receive slots.
Devices receive time-synchronized beacons from the network server to align receive slots.
The server can schedule downlink messages to be sent in these known windows.

Advantages

Enables scheduled downlink communication from the network
Lower latency compared to Class A
Maintains moderate power consumption

Disadvantages:

Requires periodic beacon synchronization
Slightly higher power usage

Typical use cases:

Smart street lighting
Devices needing periodic command updates

Class C

Devices extend Class A by keeping the receive windows open unless they are transmitting.
This allows for low-latency communication but is many times more energy consuming than Class A devices.

Communication behavior:

The device keeps its receiver open continuously, except when transmitting uplink data
The server can send downlink messages at any time, achieving near-real-time response

Advantages:

Lowest downlink latency (almost real-time)
Ideal for remote control or command-response systems

Disadvantages:

Highest power consumption, suitable only for mains-powered devices

Typical use cases:

Gateways or always-on controllers
Actuators, relay modules, or valve controllers

End-Device Activation

Activation of an end-device can be achieved in two ways, either via Over-The-Air Activation(OTAA)

when an end-device is deployed or reset, or via Activation By Personalization (ABP) in which the two

steps of end-device personalization and activation are performed in one step.

Over-The-Air Activation (OTAA)

End-Devices follow a Join Procedure prior to participating in data exchanges with a Network Server. An

end-device SHALL initiate a new Join Procedure every time it loses the session context information.

Activation By Personalization (ABP)

Activation by personalization ties an end-device directly to a specific network, thus bypassing the Join-Request – Join-Accept procedure.Activating an end-device by personalization means that the DevAddr and the two session keys

NwkSKey and AppSKey are stored directly in the end-device instead of being derived from DevEUI ,

JoinEUI and the AppKey .

Procedure of OTAA activation

Security keys generated during the Join procedure

Sending a join request message to the join server

Sending a join accept message to an end device

Session keys are shared with the network server and the application server

Secure transmission of data packets

Data Stored in End-Device after Activation

After activation, the following information is stored in the end-device: a device address(DevAddr), a

network session key(NwkSKey), and an application session key(AppSKey).

End-device address

The DevAddr consists of 32 bits and identifies the end-device within the current network. The DevAddr

is allocated by the Network Server of the end-device.

Network session key

NwkSKey is a network session key specific to the end-device. It is used by both the Network Server

and the end-device to calculate and verify the MIC(message integrity code) of all data frames to ensure

data integrity.

Application session key

AppSKey is an application session key specific to the end-device. It is used by both the Application

Server and the end-device to encrypt and decrypt the payload field of application-specific data frames.

Specification

More about LoRa and LoRaWAN, please read the specification:

[Protocol Specifications](https://lora-alliance.org/lorawan-for-developers/)

Quick Start Guide

Articles

What is LoRa and LoRaWAN

Quick Start Guide

Articles

What is LoRa and LoRaWAN