LoRa and LoRaWAN are wireless communication technologies. LoRa is a physical layer modulation technique that enables long-range transmissions, while LoRaWAN defines the communication protocols and system architecture for networks using LoRa modulation. Key features of LoRa include long range, low power consumption, and robustness against interference. LoRaWAN defines end device classes, activation methods, security procedures, and MAC commands. Popular open-source LoRaWAN network servers include LoRaServer.io and The Things Network, which support device connectivity and management.

1. LoRa and LoRaWAN. Features of
technologies and usage recommendations
Bogdan Kostiv, Embedded Software Developer

2. Agenda
 LoRa general information;
 LoRaWAN basics;
 LoRaWAN device types and messages structure explanation;
 LoRaWAN security;
 LoRaWAN end-device activation;
 LoRaWAN server solutions;

3. LoRa
 LoRa is a proprietary spread spectrum modulation scheme that is derivative of Chirp Spread Spectrum
Modulation (CSS);
 LoRa is a PHY layer implementation and is agnostic with to higher-layer implementations;
Key features:
• Bandwidth Scalable (both bandwidth and frequency);
• Constant Envelope / Low-Power
• High Robustness
• Multipath / fading Resistant
• Doppler Resistant
• Long Range Capability
• Enhanced network capacity - (multiple spread signals can be transmitted at the same time and on the
same channel)

4. LoRa. Range vs Power
Source: https://lora.readthedocs.io/en/latest/

5. LoRa modulation
Source: https://lora.readthedocs.io/en/latest/
Chirp Spread Spectrum modulation (CSS)

6. LoRa packet structure
Typical LoRa modem employs two types of packet format, explicit and implicit. The explicit packet includes a short header
that contains information about the number of bytes, coding rate and whether a CRC is used in the packet.
The explicit header provides information on the payload, namely:
• The payload length in bytes.
• The forward error correction code rate.
• The presence of an optional 16-bits CRC for the payload.

7. LoRaWAN Networks

8. LoRaWAN classes

9. LoRaWAN device classes

10. LoRaWAN device class A
• The first receive window RX1 uses a frequency that is a function of the uplink frequency and a data rate
that is a function of the data rate used for the uplink.
• The second receive window RX2 uses a fixed configurable frequency and data rate. The frequency and
data rate used can be modified through MAC commands.

11. LoRaWAN device class B
In addition to Class A receive slots, class B device opens extra receive slots at
scheduled times.

12. LoRaWAN device class B, beacon-less temporary
operation

13. LoRaWAN device class C

14. LoRaWAN PHY structure
Uplink PHY
Downlink PHY

15. LoRaWAN MAC message format
MAC Header

16. LoRaWAN MAC payload format
Frame Header
FCtrl downlink frames Content
FCtrl uplink frames Content

17. Adaptive Data Rate Control
• If the uplink ADR bit is set, the network will control the data rate and Tx power of the end-device through
the appropriate MAC commands.
• If the ADR bit is not set, the network will not attempt to control the data rate nor the transmit power of the
end-device.
• When the downlink ADR bit is set, it informs the end-device that the Network Server is in a position to
send ADR commands. The device MAY set/unset the uplink ADR bit.
• When the downlink ADR bit is unset, it signals the end-device that the network temporarily cannot
estimate the best data rate.

18. Confirmed Data Feature

19. Confirmed Data and Frame Pending Features

20. LoRaWAN MAC port and application fields
FPort values:
• 0 indicates that the FRMPayload contains MAC commands only;
• 1..223 (0x01..0xDF) are application-specific;
• 224 is dedicated to LoRaWAN Mac layer test protocol;
• 225..255 (0xE1..0xFF) are reserved for future standardized application extensions;
Payload encryption keys:

21. MAC Commands for Class A Devices (R1.1)

22. MAC Commands for Class A Devices (R1.1)

23. MAC Commands for Class A Devices (R1.1)

24. MAC Commands for Class B Devices (R1.1)

25. MAC Commands for Class C Devices (R1.1)

26. LoRaWAN Security
Source: https://lora-alliance.org/sites/default/files/
2019-05/lorawan_security_whitepaper.pdf

27. LoRaWAN Security
Source: https://lora-alliance.org/sites/default/files/
2019-05/lorawan_security_whitepaper.pdf

28. LoRaWAN End-Device Activation (OTAA and ABP)
Over-The-Air Activation (OTAA) — end-devices follows a join procedure to participating in data exchanges
with the network server. An end-device has to go through a new join procedure every time it has lost the
session context information.
Activation by Personalization (ABP) — directly ties an end-device to a specific network. Activating an end-
device by personalization means that the device contains all required data/keys for communication. Join
request — join accept procedure is not needed for this type of activation.

29. LoRaWAN End-Device Activation (OTAA and ABP)
OTAA Pros:
• Session key generation during join procedure - better security;
• There is possibility to join to new network (re-join);
• Network settings can be specified during join procedure;
OTAA Cons:
• More complex procedure in comparing with ABP;
ABP Pros:
• Join procedure is not necessary;
ABP Cons:
• Less secure, since a chance of session key compromising is higher (improved in R1.1);
• The only way to update session keys is to re-flash end device.

30. LoRaWAN End-Device Activation Data
DevEUI - Device EUI, set by manufacturer, unique per device
AppEUI - Application EUI - identifies the end application (leplaced with JoinEUI)
AppKey - Application Key, used in OTAA to generate session keys
DevAddr - Device Address, identifies a device on a particular network
NwkSKey (R1.0) or NwkSEncKey, SNwkSIntKey, FnwkSIntKey (R1.1) - Network Session Key(s), encrypts the
packet metadata
AppSKey - Application Session Key, encrypts the packet payload
DevNonce - a random nonce sent from device to network during a join request to prevent rogue device re-
playing the join request
AppNonce - a nonce sent from network to device during a join response that allows the device to generate the
session keys
NetID - Network Identifier, uniquely identifies the network

31. LoRaWAN OTA End-Device Activation

32. LoRaWAN End-Device types and states
End-Device: DevAddr, AppSKey,
network session keys ( R1.1: SNwkSIntKey,
FNwkSIntKey, and NwkSEncKey;
R1.0: NwkSKey)
Network Server: DevAddr, network session
keys, App Serevr info
App Server: DevAddr, AppSKey
End-Device: DevEUI, AppKey(R1.0),
NwkKey(R1.1), AppEUI/JoinEUI.
Join Server: DevEUI, AppKey,
NwkKey,
App Server: no information is required

33. Semtech LoRaWAN Stack
The concept follows the Request-Confirm and Indication-Response architecture.
The LoRaMAC layer offers MCPS (MAC Common Part Sublayer) services, MLME (MAC layer
management entity) services and a MIB (MAC information base).
In general, the LoRaMAC layer utilizes MCPS services for data transmissions and data receptions, and
MLME services to manage the LoRaWAN network. The MIB is responsible to store important runtime
information and holds the configuration of the LoRaMAC layer.
Repository https://github.com/Lora-net/LoRaMac-
node

34. LoRaServer.io

35. LoRaServer.io

36. LoRaServer.io Main Features
• Device Class A, B and C support
• Adaptive data-rate support
• Live frame-logging
• Multi-tenant
• APIs and integration
• LoRaWAN 1.0 and 1.1 compatible

37. Thethingsnetwork.org

38. Thethingsnetwork.org

39. Thethingsnetwork.org

40. References
• https://lora-alliance.org/
• https://lora.readthedocs.io/en/latest/
• https://github.com/Lora-net (Semtech)
• https://www.loraserver.io/
• https://www.thethingsnetwork.org/
• https://www.youtube.com/watch?v=cUhAyyzlv2o&list=PLmL13yqb6OxdeOi97EvI8QeO8o-PqeQ0g

41. Thank you!
Questions?