This document discusses LoRa/LoRaWAN technology. It begins with an overview of LoRa modulation technique and LoRaWAN protocol. It then covers topics like end device activation methods (ABP and OTAA), deployment models (community network, IoT operator, system integrator), and a demonstration of an "IoT village" using ThingsLog devices and The Things Network.

1. LoRa/LoRaWAN
Nikolay Milovanov
ThingsLog/NBU
nmilovanov@{thingslog.com,nbu.bg}

2. Agenda
• LoRa
• LoRaWAN
• End device activation
• Some additional but important LoRaWAN details
• Deployment models
• Demo – IoT “village” with TTN and ThingsLog

3. LoRa
Long Range

4. Introduction
• LoRa (Long Range) is a spread spectrum modulation technique
derived from chirp spread spectrum (CSS) technology.
• Developed by Cycleo of Grenoble, France and acquired by Semtech the
founding member of the LoRa Alliance.
• Patented under EU patent 13154071.8
• LoRa is currently actively developed by Semtech Corporation with the help of
LoRa Alliance (more than 500 members)

5. Modulation
• Modulation – the process by
which some characters of the
carrier frequency are varied in
accordance with the message
signal
• Purpose:
• To transmit messages over long
distances
• To transmit signals from various
sources over a common channel

6. What kind of modulation is LoRa
• CSS - wideband linear frequency modulated chirp pulses to encode
information.
• CSS is old military technology especially good for transmitting signals
over long distance in a noisy environment
• Since it is wideband it has quite “good” negative effect on the other
”narrowband” technologies using the same spectrum
• We call it a virus effect with the addition of more and more LoRa
devices the other technologies start to suffer.

7. Some definitions
• Frequency band:
• ISM1 – free, regulated frequency spectrum. Used for industrial, medical and non
telecommunication purposes.
• In Europe for LoRa we may use 868 MHz, USA and North America 915 MHz
• Bandwidth (difference between upper and lower frequencies of a frequency
channel)
• Wider channel -> higher bandwidth
• From an end-node to a gateway is better to use narrower channel and vice verse from a
gateway to an end node a wider one.
• Spreading factor – number of bits per symbol
• The lower the SF -> the higher the number of bits per symbol, higher speed -> lower time ->
shorter range
• Collision – two transmissions of a signal, that happened in the same media at the
same time

8. Frequencies
• ISM frequencies
https://en.wikipedia.org/wiki/ISM_band
• ISM - radio spectrum reserved
internationally for industrial, scientific and
medical (ISM) purpose other than
Telecommunications
• Wonder why telecom’s are also using it?!?
• For LoRa are used
• Europe 868 MHz / 433 MHz
• US/Latin America 915 MHz
• Asia/Oceania
• Country dependent
Europe North America
Frequency 867-869 MHz 902-928 MHz
Channels 10 64+8+8
Channels Bw UP 125/250 kHz 125/500 kHz
Channels Bw DN 125 kHz 500 kHz
Tx Power UP +14 dBm +20 dBm (+30 dBm
allowed)
Tx Power DN +14 dBm +27 dBm
SF UP 7-12 7-10
Data Rate 250 bps – 50 kbps 980 bps – 21.9 kbps
Link Budget UP 155 dB 154 dB
Link Budget DOWN 155 dB 157 dB

9. Some more definitions
• Duty cycle – percentage of time in which certain resource is busy
• In Europe in ISM (868 MHz) duty cycle is between 0.1% and 10% for just 1 of
them.
• On average duty cycle is considered as 1%
• It is so no matter are you an end node or a gateway
• A bit of math:
• Depending of the spreading factor one LoRa transmission is between 100ms
up to 2-3 seconds
• 1% of time is 864 seconds (14,4 min) on a daily basis
• This is actually sufficient for a couple of hundreds transmissions per day
• Many networks limit additionally that number to some harsher policy like 30
seconds per day per end node

10. Radio Link Budget
• The budget is calculated based on the power of transmitter, sensitivity of the receiver, antenna gain and the
path losses
• The budget decreases with time and distance
• Radio link budget with LoRa1:
• Power of the transmitter is up to 25mW (14 dB) (limited by ISM)
• Receiver sensitivity - 138 (141) dB
• Antenna gain is between 0dBm и 9dBm (could be a bit more)
• Many kinds of path losses
• Possible budget is around 151 -154 dB, which is actually a tremendously good number
• In LoRa budget depends further from the spreading factor – this number is for SF12, for SF7 is around 125
dBm
1. Примерна калкулация на бюджета на радио връзката при LoRa - https://smartmakers.io/en/lorawan-range-part-1-the-
most-important-factors-for-a-good-lorawan-signal-range/
LORA – 154 dB
NB-IoT – 148-151 dB
5G/4G/2G < 140 dB

11. Antennas
• Antenna gains helps us to “transmit” further the energy of the radio wave
• Sensitivity of the antenna is its ability to hear better “the signal” and to
transfer the signal with minimal losses to the ”receiver” radio module
• Typically we have a kind of backward compatibility
• Better gain means better hearing
• However:
• Longer antenna with high gain may help us to transmit the energy of the radio wave
or hear signals from a longer distance but we may loose some nodes that are closer
to the antenna
• Shorter antenna with low gain may not transmit so further away but we may receive
well signals from a shorter distance

12. Radiation patterns of certain antennas

13. Golden rules
• Location matters. Direct visibility between a transmitter and receiver is the
“most” valuable thing in that business.
• Avoid obstacles in the area near the antenna. Mount the antenna a couple
of meters above the roof.
• The feeder cable between is quite important. You have to use a specialized
cable with the right impedance and low attenuation.
• Connectors between the antenna and the gateways are equally important.
Use good “heavy” N-connectors.
• Don’t place the antennas close to other transmitters (mobile operator base
stations). There is quite a good chance those to work on a closer
bandwidth and to introduce extra noise (harmonics).

14. LoRa Coverage
bandwidth
Range
wifi
2G-5G
LoRa, SigFox
NB-IoTzigbee
zwave

15. LoRaWAN

16. LoRaWAN
• LoRa modulation is a technology from
the physical layer
• On top of it is needed a protocol stack
to handle:
• the communication between end nodes
and gateways
• between gateways and network core
• Even between different LoRa networks
• It is the protocol that makes LoRa
something useful and reusable
• LoRaWAN is developed by LoRa
Alliance
• Current version 1.1
1. LoRaWAN specification https://lora-alliance.org/sites/default/files/2018-04/lorawantm_specification_-v1.1.pdf
2. More information about LoRAWAN https://lora-alliance.org/lorawan-for-developers

17. LoRaWAN architecture
Basic elements:
• End Nodes
• Transmit data wirelessly to one or more
gateways
• Gateways - receive/transmit data
between nodes and the core of the
network
• Network Server – manages the
network, strips redundant packets,
forwards data between radio and
application part
• Application Server
• Handles the integration between
network and apps.

18. What does that mean for us?
• Each end node and LoRaWAN gateway has to speak certain version of
that protocol
• LoRaWAN versions are cumulative, e.g v1.1 contains all messages
from v.1
• From end user perspective from the protocol we can obtain
information about:
• Kinds of end devices - ABP or OTAA
• Security (AAA, encryption)
• Mechanisms for data integrity, data speed adaptation

19. How does it look like?
Data format
Messages from the
MAC layer

20. Classes of End Nodes
• Class A – bi-directional end-
devices, each uplink transmission is
followed by two short receive
windows. Mostly sleeping.
Downlink shall wait for the next
uplink
• Class B – bi-directional end-devices
with scheduled time slots, based
on time synchronized beacons
from the gateway, network server
knows when the node is listening
• Class C – almost continuously open
receive windows, only closed when
transmitting
Class C – on power actuators, devices listen
continuously, no latency in downlink
Class B – battery powered actuators, energy
efficient with latency controlled downlink
Class A – battery powered, energy efficient
Batterylife
Downlink Network Communication Latency

21. Receiving Windows
• Following each uplink transmission
the end-device MUST open two
short receive windows.
• The receive window start times are
defined using the end of the
transmission as a reference.
• RX1 opens RECEIVE_DELAY1 1
seconds (+/- 20 microseconds) after
the end of the uplink modulation.
• RX2 uses a fixed configurable
frequency and data rate and opens
RECEIVE_DELAY2 1 seconds (+/- 20
microseconds)
• RX1 uses frequency that is a
function of the uplink frequency
• RX2 uses fixed configured
frequency

22. Data encryption in LoRaWAN
• There are two keys in LoRaWAN
• NwkSKey – network encryption key. Crypt/decrypt happens between network server and end device. The secret lays
in both.
• AppSKey – payload encryption key. Crypt/decrypt happens between application handler and the end device. The
secret key exists in both.
• In each LoRa node we have to „provision“ both keys + address of the device.

23. End device activation

24. 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

25. Over the Air Activation
(OTAA)
End-device transmits a Join Request to
application server containing:
Globally unique end-device identifier (DevEUI)
Application identifier (AppEUI), and
Authentication with Application key (AppKey)
End-device receives Join Accept from the
application server
End-device authenticates Join Accept
End-device decrypts Join Accept
End-device extracts and stores Device
Address (DevAddr)
End-device derives security keys:
Network Session Key (NwkSKey)
Application Session Key (AppSKey)

26. ABP vs OTAA
OTAA
• Pros:
• Session keys are only generated when required
• If the device changes to a new network, it can re-join
to generate new keys
• rather than having to be re-programmed.
• Network settings like RxDelay and CFList can be
specified at join time.
• Cons:
• A scheme is required to pre-program each device with
a unique DevEUI and AppKey, and the correct AppEUI.
• The device must support the join function and be able
to store dynamically generated keys.
ABP
• Pros:
• The device does not need the capability or resources to
perform a join procedure.
• The device does not need to decide whether a join is
necessary at any point, since it is never necessary.
• No scheme is necessary to specify a unique DevEUI or
AppKey.
• Cons:
• The scheme to generate the NwkSKey and AppSKey
must ensure they are unique, to prevent a widespread
breach if a single device is compromised.
• The scheme must be secure to prevent the keys being
obtained or derived by rogue parties.
• If the device is compromised at any time, even before
activation, the keys may be discovered.
• Movement to a new network happens only if you can
create in the new network exactly the same device with
the same keys

27. When to use what?
• With care, either method can be just as secure and effective as the
other.
• OTAA is the easiest way to achieve some basic security and flexibility.
• ABP is easier and more effective from network point of view.
• ThingsLog LoRa data loggers (LPMDL-1103) use both:
• OTAA for configuration over the air
• ABP for sending counters

28. Deployment models
and solutions

29. Community network
• Driving forces
• Some guys or community just bought and installed a couple of gateways
• It is in interest of the community to maintain and use the network
• Example: Village of Novi Han is difficult for manual metering especially during the winter
• Local utility company deployed a gateway on top of the community center
• Now the whole village is metered over LoRa network
• Soon people from the community start adding gadgets to monitor and control their homes
• What about the spectrum?
• Spectrum is free, anybody from the community can add and use the newly build network
• What about the others – for example a telecom that would like to use the same spectrum in
the same area
• ISM is not for telecommunication purposes, most likely collisions will happen between telecom and
community network

30. How big a community network could be?

31. IoT operator (pay per use)
• IoT operator is a community, local or global operator offering IoT
network connectivity
• An example for a global public IoT operator is The Things Network
• An example for a global private IoT operator is Everynet or LoRaIoT
• An example for local, Bulgarian private IoT operator is IoT
http://www.iotnet.eu/
• Telecoms
• KPN, Swisscom, Vivacom and many others

32. Deployment by a system integrator
• The customer buys the network equipment (gateways, antennas,
feeder cable), network server with a particular purpose
• The system integrators offers a complete tailor made solution for his
customer
• Could be based on equipment from multiple manufacturers
• The customer and the system integrator supports the network
together depending on the exact arrangements

33. In how many network can a single LoRa
device send data
• Answer – in many
• Each network that has the addresses and the keys could receive data
from the device and can forward it towards the application layer
• LoRa/LoRaWAN network stack eases the migration from network to
network
• Networks can even operate in parallel and “old” network to be
abandoned gradually step by step
• It is not difficult to switch from a deployment model to deployment
model

34. Advantages/Disadvantages of each of the
models
• Community operator
• Community builds, cares and supports its own network
• Operator
• You have somebody to take care and resolve issues
• Telecom
• Have the best gateway spots in the country
• Have professional team able to support the equipment even in the worst time of the
year
• In the end everything costs time and money
• If you and your community want to save some bucks build your own LoRa network
• If you want a partner specialized in IoT get and IoT operator
• If you want to add something to your existing plan and it to work in a carrier grade
way buy IoT service from the local telecom

35. Demo time

36. Agenda
• Gateway coverage
• IoT village
• Demonstration of smart metering and monitoring with UND-1101, LPMDL-1103 and TTN

37. Gateway coverage
• Best place to check for your area
https://ttnmapper.org/

38. IoT Village

39. LPMDL-1103
• Supports 868MHz, 915 MHz or
433 MHz
• 2 pulse inputs
• 2 on/off inputs
• Configurable over the air
• Works with 2xAA Lithium
batteries or 1x3.6 A size Lithium
battery
• In either case able to do more
than 10K transmissions

40. Questions
nmilovanov@thingslog.com