Article
LoRa: An Excellent Long-Range Wireless Technology
Considerations for Implementation in Building Automation andControl Applications
Graham Martin, Chairman & CEO EnOcean Alliance
LoRa stands for LOng RAnge radio. With a reach of up to 10+ km, it’s ideal for e.g. sending a meter reading signal from asmart meter to a central collection point a few kilometres away, once or twice a day (1). Or transmitting data on outdoor airquality, water levels in rivers and reservoirs, rainfall data or parking space availability. In the words of the LoRa Alliance,
this proprietary wireless technology (exclusively owned and all chips supplied by Semtech Corporation, USA) - together with
its wide-area network protocol, LoRaWAN - “provides low power, long range connectivity within large-scale commercialimplementations” (2). Most applications feature a low sensor density and building-to-building outdoor communication in
peripheral urban and rural areas (LoRa Alliance mission statement: “for large public networks”).
So: how suitable is a slow-transmitting Long Range radio for home and building automation applications? A LoRaWAN
signal that travels 10km is seconds long and very energy-hungry. Even using shorter range versions of LoRa, this is overkill
for many building automation applications. Let’s look at some of the considerations to be taken into account before
adopting LoRa for such applications. LoRa’s claim to suitability in a building automation context stems mainly from theassumption that there is no need to install an extensive infrastructure of gateways or receivers in a large building when asignal can travel from the basement to the 25th floor. However, these long and energy-hungry signals are less than ideal formany building automation and control applications. In many cases the resulting latency is not only a user issue, but also
falls outside national specifications. More importantly, the long range and signal length characteristics of LoRa raise issues
about security, duty cycle and interference or collisions. If all signals from the building can travel hundreds of meters oreven a few kilometers, anyone within this radius could pick up and ultimately hack this signal / system. And when there are
too many signals within this radius, the potential for interference, collisions and significant loss of signals threatens to cause
network failure.

Spreading Factors
To enable optimization of different applications and their requirements, LoRa offers different configurations fortransmitting data. It can differentiate between several spreading factors (SF). They basically change data rate in thespectrum between SF7 and SF12 and directly influence range, energy consumption, data package size and latency times.
Long-range applications are typically taken care of by higher SF configurations (e.g. SF12) - less suitable for most building
automation applications. Such applications are typically taken care of by lower SF configurations (e.g. SF7, 8 or 9).
The highest range (i.e. >10 km typically attained @ SF12) calls for a data burst lasting approx. 1.5 seconds - bringing thegreatest risk of interference, collisions, eavesdropping and latency issues. Typical battery life in building monitoring andcontrol applications would be just a few months, even with a high-cost, high-power battery (3). The shortest free-field range
e.g. a few hundred meters (typically attained @ SF 7) calls for a 28 ms (or 56 ms) data burst - with a lower risk of interference,collisions or eavesdropping. High-cost, high-power battery life for typical building automation sensors could be around 4years at the rate of 1 data burst with 6 Bytes of payload data every 15 minutes (3). In this case, the indoor range of such
LoRa sensors is similar to other low-power wireless sensor solutions requiring significantly less energy and air-time, virtuallyeliminating the theoretical minimized-infrastructure advantage of LoRa (3),(4).

Power Supply ConsiderationsLoRa sensors mostly use batteries. They must be sourced, stocked, installed, replaced and disposed of - and constitute animportant cost and reliability factor. High-capacity battery dimensions can also be a limiting factor in device design/cost.
Wired power supply may be used, but obviously eliminates many of the advantages of a wireless communication byreducing placement flexibility, adding to installation time and cost etc. Therefore, battery lifetime is a key consideration.
Here’s a typical LoRaWAN marketing claim(5) “LoRaWAN end devices are optimized to operate in low-power mode and canlast up to 10 years on a single coin cell battery”.
A study performed by the School of Computer Science & Engineering, Nanyang TU, Singapore (3) concluded that sending a6 Byte payload sensor signal every 15 minutes would result in a battery lifetime of 1.37 years using SF12, and 4.60 years
using SF7.

Article
Table 1. LoRa packets energy budget breakdown with PL = 6 Bytes, CR = 4/8, BW = 125kHz, 15 minutes per packet for SF7& SF12 and battery capacity of 3.7V 2Ah.
StatesMCU Active
MCU sleepSF7 2dBm
Radio TX
Radio Sleep

SF1220dBm

MCU Active
MCU sleep
Radio TX
Radio Sleep

Time (ms)Energy (mJ)

Budget (%)

40.50
899959.50
38.85
899961.15
Total
933.0
899067.00
926.70899071.30
Total

0.50
71.28
4.36
89.10
165.2412.25
71.21
380.7389.01
553.20

0.30
43.14
2.64
53.92
4.60 years
2.22
12.87
68.82
16.09
1.37 years

Source (3): Known and Unknown Facts of LoRa: Experience from a Large Scale Measurement Study,
School of Computer Science and Engineering. Nanyang Technological University SG
This study is based on a relatively high-cost, large, high-power battery (3.7V, 2Ah) for home and building automation
purposes. Expanding this to cover coin-cell batteries (2x CR2477 or CR2032)(5) gives the results that a single coin-cellbattery-powered LoRa sensor sending a 6-Byte data payload signal every 15 minutes (very typical for a building and home
automation sensor application) would only last from a few weeks to a few months. Using SF7 with 2 x CR2477 would give
1.87 years battery life whilst using the single coin cell battery CR2032 would give 0.41 years. The cost of maintaining
batteries over a 10- year period would be significant, in many cases exceeding the original cost of the sensor by manyfactors. Battery failure can also cause malfunction of the system. In a commercial environment, when a facility
management company is responsible for maintenance, the costs can increase even more (7). It is therefore common practice
to replace batteries every year and at significant cost. (8)(9).
A 2020 study published by Professor Michael Kroedel (4) states that “the most suitable wireless technology can only beidentified, case by case, according to the „use cases“. And concludes that LoRa is less suitable for the majority of home andbuilding automation & control systems. Prof. Kroedel finds that other low-energy wireless technologies such as EnOceanand Z-Wave, or even BLE and Zigbee, are much better suited to such applications. One reason for this is the high energy
and high latency times required by LoRa signals. Armin Pelka (6) expanding on the study from Singapore (3) compares theenergy requirements for one LoRa communication cycle (at SF12 and SF7) with exactly the same data / communication
cycle using the EnOcean Standard.
Table 2

Energy Requirement Comparison
per Communication Cycle
LoRa SF12553,20 mJ

LoRa SF7165,24 mJ

Energy (mJ)

EnOcean
1,26 mJ

Assumptions: 6 Byte Data Payload, 15 Minute Between Transmissions
Sources (3)(6) Nanyang Technological University, Singapore & Armin Pelka

Article
Duty Cycle Considerations
The Duty Cycle is important for LoRaWAN deployments in order to manage radio frequency usage and prevent interference.
It refers to the percentage of time that a device is allowed to transmit on a particular frequency channel within a specifictime period e.g. per hour or minimum pause necessary between transmissions of a particular device.
In Europe, for example, the European ETSI regulatory body has set limitations on the Duty Cycles to ensure fair and efficientuse of the radio spectrum. The Duty Cycle restrictions are designed to prevent any single device or network frommonopolizing the available bandwidth, which could lead to interference with - or malfunction of - other devices ornetworks. For the 868 MHz frequency band, which is used in Europe for LoRaWAN and other SRDs, the regulatory limit fora given frequency channel is a 1% Duty Cycle meaning that a device can transmit on that channel for up to 1% of the total
time (i.e. a device is only allowed a maximum transmission time of 36 seconds per hour or per 1 second transmission timea minimum 100 second pause before another transmission can be performed). For most home and building automation &control applications using low-power wireless technologies, this is not an issue. Even LoRa using SF7 or SF8 seems uncriticalin this respect. However, using the highest SF’s this may become an issue in certain building automation applications (10) asshown in Table 3.

Table 3. Airtime limitations Source (10)Telegram with 8 bytes payload size and 13 bytes overhead size.
Spreading factor

SF7SF7SF8SF9SF10SF11SF12Bandwidth [kHz]

250

125

125

125

125

125

125

Airtime [ms]28,356,6102,9185,3370,7741,41482,8Max. messages per hour

1.272

636

349

194

97

48

24

Min. pause between messages [s]2,85,710,3

18,537,174,1148,3Interference & Collision Considerations
Interference is a significant challenge in LoRaWAN networks, as in any wireless communication system. It occurs when
unwanted signals or noise disrupt the intended communication between LoRa devices - leading to reduced communication
quality, higher error rates and potential loss of data packets. Interference problems in LoRaWAN include Signal Degradation,
Frequency Overlap, Intermodulation and Adjacent Channel Interference.
Collisions in LoRaWAN networks relate to Airtime Utilization, Data Loss, Retransmissions, Network Performance, Spreading
Factors and Collisions, Network Density and no built-in Collision Detection.
Table 4 (5)(6) illustrates that in a network with 30 nodes at SF12, each sending a signal every 10 minutes, the collision
probability is already at a dangerous 8,2% level and the network will break down completely at less than 100 nodes. At SF9the network will reach this dangerous level at around 200 nodes. At SF7 such issues will arise at around 1.000 nodes within
the network. In comparison, an EnOcean network (specifically developed for home and building automation & control) canhandle a network of 3.000 nodes with less than 0,1% collision probability.
Table 4.

Collision Probability % vs. Sensor Nodes
Transmission Every 10 minutes (schematic)
100%
80%
60%
40%
20%
330
LoRa SF 7300
LoRa SF 9LoRa SF 120%
3000
EnOceanArticle“Foreign network” disturbances
LoRA popularity inevitably brings the acute, unsolvable problem of data collisions from LoRa networks nearby and further
afield - and owned by third parties, whose actions are beyond the control of the individual network operator. LoRa network
collision levels will reach critical/unacceptable levels with just tens, hundreds or a few thousand nodes depending upon theSF used. In an urban area the LoRa user can take measures to minimize the risk of interference and collisions within his own
network, but has absolutely no influence on neighbouring networks - which could amount to dozens, hundreds or eventhousands of networks featuring tens of thousands of nodes - leading to complete network breakdown. Such problems areexacerbated by LoRa’s inherent characteristics and can impact all SF configurations.

Sources:
1.

“The Power Struggle for Smart Building Automation Protocols” by Peter Smith, Head of Sales & Marketing,IAconnects Technology Ltd. https://www.iaconnects.co.uk

2.

http://pages.lora-alliance.org.pages.services/Buildings-Vertical-Market)

3.

“Known and Unknown Facts of LoRa: Experiences from a Large Scale Measurement Study” by School of Computer
Science & Engineering, Nanyang Technological University, Singapore
https://dr.ntu.edu.sg/bitstream/10356/142869/2/Known%20and%20unknown%20facts%20of%20LoRa%20exp
eriences%20from%20a%20large-scale%20measurement%20study.pdf

4.

“Smart Building trends - a comparison of wireless standards for automation and control” by Prof. Dr. Michael
Krödel, Institut für Gebäudetechnologie. https://www.ashb.com/wp-content/uploads/2020/11/IS-2020-161.pdf

5.

LoRaWAN, https://www.thethingsnetwork.org/docs/lorawan/what-is-lorawan/

6.

Ingenieurbüro Armin Pelka, http://www.pelka.de

7.

Xidas_WP.pdf, www.eu.mouser.com

8.

www.tcsecurity.co.uk/index.php/faqs

9.

www.abpa.de/media/wartung_jab_18_angebot.pdf

10. TTN airtime calculator for LoRaWAN, https://www.thethingsnetwork.org/airtime-calculator