LoRaWAN 101

A Technical Introduction

LoRa-Alliance.org
Who are the LoRa Alliance?
The LoRa Alliance is an open, non-profit association of
members (http://lora-alliance.org/)
Alliance members collaborate to drive the global success of
the LoRaWAN protocol
Mission: to standardize Low Power Wide Area Networks
ENABLING THINGS TO HAVE A GLOBAL VOICE
Strategy Committee Technical Committee
Roadmap & Security Specification & feature
updates
Marketing Committee Certification
Brand, Media, Trade-shows, Committee
Open House Test Specs & Accreditation LoRa-Alliance.org
Specification Updates
LoraWAN 1.0.0 -> 1.0.1 -> 1.0.2 -> 1.1

1.0.2 in final review now, release this quarter

Clarifications enabling NA certification program to launch
Moves regional parameters to separate doc
Much easier to make progress outside IPR process
Rapid increase in number of countries covered
Adds support for cluster of APAC countries
Commands to modify regional freqs & Tx powers

Specification is free to download now

https://www.lora-alliance.org/Contact/RequestSpecificationForm.aspx
LoRa-Alliance.org
Specification Updates
LoraWAN 1.0.0 -> 1.0.1 -> 1.0.2 -> 1.1

1.1 in development, due mid 2017

Adds:
Passive & Handover roaming capabilities
Class B clarifications
Class A/C temporary switching
Needs back-end interfaces to standardise
Alliance is committed to backward compatibility
LoRa-Alliance.org
 A Spread Spectrum Technology
Developed by Semtech Corporation (http://www.semtech.com/)
Chirped-FM modulation, symbols of ramping frequency
Processing gain = increased receive sensitivity
Enables longer range at expense of lower data rate

LoRa-Alliance.org
 0 1 2 3 4 5 6 7 Data Rate (DR)
LoRa Modulation FSK
Range
12 11 10 9 8 7 7 -- Spreading Factor (SF)
125 125 125 --
125 125 125 250 50K Bandwidth (BW) (kHz)
10937
Bitrate (BR) (bps)
5468
-108
3125
-120
537
976 1757 -123 Receive Sensitivity (dBm)
292 -126
-129
-133 -132
-136 Time-on-air & consumption
LoRa-Alliance.org
 ADR = Adaptive Data Rate
LoRaWAN can auto-magically manage SF for each
end-device:
To optimize for fastest data rate versus range
For maximize battery life, and
Achieves maximum network capacity

LoRa-Alliance.org
 License free Sub-GHz Frequencies
Europe: 868 MHz Band
Network channels can be freely attributed by the network
operator
3 mandatory channels that all gateways should constantly receive:

EU gateways are typically using 8 channels

End-devices must be capable of at least 16 channels
LoRa-Alliance.org
 License free Sub-GHz Frequencies
North America: 915 MHz Band
Upstream: 64 channels numbered 0 to 63, DR0 to DR3
Upstream: 8 channels numbered 64 to 71, DR4
Downstream: 8 channels numbered 0 to 7, DR8 to DR13

LoRa-Alliance.org
 Low Power Wide Area Network (LPWAN)
Bidirectional, acknowledged
Simple Star Network Topology Enables simpler network
Low data rate architecture:
Low cost No repeaters
Long battery life
No mesh routing complexity
Long Range

Ideal for:
Internet of Things (IoT) & Machine-to-Machine (M2M)
Industrial Automation
Low Power Applications
Battery Operated Sensors
Smart City, Agriculture, Metering, Street lighting

http://lora-alliance.org/What-Is-LoRa/Technology
LoRa-Alliance.org
LoRaWAN Network Topology
Gateways Network Application
Server Servers

Sub-GHz RF

LoRa-Alliance.org
 LoRaWAN Network Protocol Security
Based on 802.15.4 Security
AES-128
Enhancements:
Network Session Key (NwkSKey)
Application Session Key (AppSKey)

LoRa-Alliance.org
 Logical Data Flow (Programmers Model)
End-Devices
Gateway Network Application
Server Server

IP IP

Sub-GHz RF
Control Network Session Key (NwkSKey) Control

Data Application Session Key (AppSKey) Data

LoRa-Alliance.org
 Each end-device class has different behavior
depending on the choice of optimization:
Battery Powered Class A
Low Latency Class B
No Latency Class C

LoRa-Alliance.org
 Battery Powered Class A
Bidirectional communications
Unicast messages
Small payloads, long intervals
End-device initiates communication (uplink)
Server communicates with end-device (downlink) during
predetermined response windows:
Transmit RX1 RX2
RxDelay1
RxDelay2

LoRa-Alliance.org
 Low Latency Class B
Bidirectional with scheduled receive slots
Unicast and Multicast messages
Small payloads, long intervals
Periodic beacon from gateway
Extra receive window (ping slot)
Server can initiate transmission at fixed intervals
BCN PNG Transmit RX1 RX2 BCN
RxDelay1
RxDelay2
Ping Slot
Beacon Period
LoRa-Alliance.org
 No Latency Class C
Bidirectional communications
Unicast and Multicast messages
Small payloads
Server can initiate transmission at any time
End-device is constantly receiving
Transmit RX2 RX1 RX2
RxDelay1
RxDelay2
Extends RX2 until next TX

LoRa-Alliance.org
 Before an end-device can communicate on the LoRaWAN
network, it must be activated
The following information is required:
Device Address (DevAddr)
Network Session Key (NwkSKey)
Application Session Key (AppSKey)

Lets mention each of these in detail

LoRa-Alliance.org
 Device Address (DevAddr)
32-bit identifier
Unique within the network
Present in each data frame
Shared between End-device, Network Server, and Application
Server
Differentiates nodes within the network, allowing the
network to use the correct encryption keys and properly
interpret the data
LoRa-Alliance.org
 Network Session Key (NwkSKey)
128-bit AES encryption key
Unique per end-device
Shared between End-device and Network Server
Provides message integrity for the communication
Provides security for end-device to Network Server
communication

LoRa-Alliance.org
 Application Session Key (AppSKey)
128-bit AES encryption key
Unique per end-device
Shared between End-device and Application Server
Used to encrypt / decrypt application data messages
Provides security for application payload

LoRa-Alliance.org
 To exchange this information, two activation methods are
available:
Over-the-Air Activation (OTAA) Activation By Personalization (ABP)
Based on Globally Unique Identifier Shared keys stored at production time
Over the air message handshaking Locked to a specific network

LoRa-Alliance.org
 Over-the-Air-Activation (OTAA)
End-device transmits Join Request to application server
containing:
Globally unique end-device identifier (DevEUI)
Application identifier (AppEUI)
Authentication with Application key (AppKey)
End-device receives Join Accept from application server

(continued)
LoRa-Alliance.org
 Over-the-Air-Activation (OTAA)
End-device authenticates Join Accept
End-device decrypts Join Accept
End-device extracts and stores Device Address (DevAddr)
End-device derives:
Network Session Key (NwkSKey) Security
Application Session Key (AppSKey) Keys

LoRa-Alliance.org
 Activation By Personalization (ABP)
The following information is configured at production time:
Device Address (DevAddr)
Network Session Key (NwkSKey)
Application Session Key (AppSKey)

No over the air handshaking

Device is ready to communicate on the network without any
additional procedure.

LoRa-Alliance.org
 Confirmed-Data Message
Gateways Network Application
Server Servers

1. Vending Machine transmits data.

It is received by two Gateways.
LoRa-Alliance.org
 Confirmed-Data Message
Gateways Network Application
Server Servers

Data

2. Both gateways pass through

the data to the Network Server.
LoRa-Alliance.org
 Confirmed-Data Message
Gateways Network Application
Server Servers

3. The Network Server forwards the data to

the Vending Machine Applications Server
LoRa-Alliance.org
 Confirmed-Data Message
Gateways Network Application
Server Servers

4. The Vending Machine Applications

Server sends an acknowledgement
LoRa-Alliance.org
 Confirmed-Data Message
Gateways Network Application
Server Servers

ACK

5. The Network Server selects the best path (gateway) to transmit

the acknowledgement to the end-device.
LoRa-Alliance.org
 Confirmed-Data Message
Gateways Network Application
Server Servers

6. The Gateway transmits the

acknowledgement to the end-device
LoRa-Alliance.org
 Application Server Data Message
Gateways Network Application
Server Servers

Data

1. The Smoke Detector Application Server has

Data for the highlighted Smoke Detector
LoRa-Alliance.org
 Application Server Data Message
Gateways Network Application
Server Servers

Data
Zzzz

2. However, it has to wait until the Smoke Detector

wakes up and transmits a Data Message
LoRa-Alliance.org
 Application Server Data Message
Gateways Network Application
Server Servers

DL

3. When the Smoke Detect transmits,

the Data Message moves Upstream
LoRa-Alliance.org
 Application Server Data Message
Gateways Network Application
Server Servers

DL

4. Passed through the Gateway

LoRa-Alliance.org
 Application Server Data Message
Gateways Network Application
Server Servers

UL
DL

5. and the Network Server sends to the

Smoke Detector Application Server.
LoRa-Alliance.org
 Application Server Data Message
Gateways Network Application
Server Servers

DL
UL

6. The Smoke Detector Application Server can now

send the data message to the Smoke Detector.
LoRa-Alliance.org
 Application Server Data Message
Gateways Network Application
Server Servers

UL

7. The Network Server sends the Data Message

to the appropriate Gateway.
LoRa-Alliance.org
Thank you, come and join us
The LoRa Alliance
ENABLING THINGS TO HAVE A GLOBAL VOICE

LoRa-Alliance.org