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 (Programmer’s 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)

Let’s 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