Home Featured Articles Practical LoRa Implementation Considerations

Practical LoRa Implementation Considerations


by L-com Global Connectivity

Low Power Wide Area Networks (LPWAN) are an emerging niche in the internet-of-things (IoT) space that is particularly targeted to serve long range, low throughput applications. According to OnWorld, revenues from LPWAN equipment and services are expected to reach $56 billion by 2022. This is no surprise; LPWAN technologies are expected to account for 7 billion of the 30 billion IoT/M2M devices estimated to be deployed by 2025 [16]. The narrowband (NB) and ultra-narrowband (UNB) technology enables an increased receiver sensitivity and thus a higher link distance while also saving on battery life. LPWAN variants all boast an average battery life of 5 years, while Sigfox and LoRa sensor nodes have the potential to go well beyond 10 years, given that the node is often in a low current consuming state such as ideal, sleep, or hibernation.

Of the many LPWAN technologies appearing, some of the most often cited are LTE-M1, NB-IoT, Sigfox, and LoRa. Where LTE-M1, NB-IoT, and Sigfox are proprietary technologies, some aspects of LoRa are not. LTE-M1 and NB-IoT leverage cellular LTE bands while Sigfox and LoRa devices leverage the unlicensed ISM bands. Both the Sigfox and LoRa PHY layer technologies are proprietary although Sigfox shares their designs with vendors who can then sell Sigfox-enabled chips and devices with a certification. While Sigfox devices are cheaper than LoRa, the modulation scheme is mainly based on uplinks from sensor nodes and the small available bandwidths through Sigfox lessen the data rates of these transmissions. Sigfox also provides the network (i.e. base stations, gateways, cloud services, etc.) for their customers while LoRa users must develop the expertise to design or use one. 

With that being said, each LPWAN solution, cellular or noncellular, is just an additional tool to serve the many available and not yet available IoT applications. Each can serve a unique purpose based on its cost, link budget, power budget, spectrum space, modulation scheme, etc. This article explores the benefits of LoRa for the consumer, industrial, and agricultural industries as well as providing an exploration of the pros and cons of major aspects of any IoT network: data reliability and security. 

LoRaWAN: The Benefits of an Open Source Platform

LoRa, short for “long range,” is a strong contender in the LPWAN market, supporting public and private entities by utilizing both licensed and unlicensed bands. The PHY LoRa layer was patented in June 2014 and the LoRaWAN MAC layer was released in January of 2015. The open source aspect of LoRaWAN network protocol can very likely further speed up the evolution of this platform. CableLabs recently generated an open source LoRa server project with a user-friendly cloud-based interface for customizing a LoRa network and integrating a LoRa server into existing infrastructures [1]. This grew from The Things Network (TTN) solution for LoRa, where any hobbyist/researcher is able to install a gateway and connect it to the organization’s central network server, thereby extending the network’s coverage. There is an updated map displaying gateways connected to TTN [11]. Additionally, as with any open source technology, there is an increasing amount of literature to support its implementation [2]-[3].  So far, this does not yet compare to LTE-M1’s reach in the United States as Verizon is leveraging their established infrastructure of 2.4 million square miles of coverage [4]. Even so, as with many platforms in the past, the crowdsourced solution may kick off slower but has the potential to catch up and even surpass proprietary solutions. If that is not the case, LoRa is likely to continue to serve many discrete applications across the commercial, industrial, and agricultural industries. While the LoRa chips are proprietary where Semtech is still the sole manufacturer, there have already been several successful implementations of LoRa using open source platforms with software-defined radios (SDR) such as GNU Radio [8]. 

Brief Overview

The physical (PHY) LoRa layer utilizes a FM chip spread spectrum (CSS) modulation scheme with forward error correction (FEC). The spread spectrum technique offers the advantage of an immunity to noise and interference while performing at low power consumption and bandwidths. The unique LoRa chirp signal brings the added benefit of an inherent resistance from channel degradation mechanisms such as multipath and fading. The medium access control (MAC) layer can vary, where LoRaWAN [5] is an open platform developed by the non-profit organization LoRa-Alliance and Symphony Link is a proprietary MAC developed by Link Labs [6]. As shown in Table 1, LoRa technology can operate at many frequencies from 150 MHz to 1 GHz but is predominantly used at particularly sub-GHz ISM bands, depending upon the geographical location it is being used in. 

Table 1

LoRaWAN Network Topology

LoRaWAN leverages the star-of-stars topology where end-devices transmit and receive messages to and from gateways. The multiple access, or one-to-many architecture, makes it so that one gateway can communicate with thousands of end-devices in the network. The gateways then send the messages to centralized network servers via a robust and high throughput link such as cellular or ethernet. 

The information is then finally processed through an application server that handles data management such as firmware upgrades and mobile network operator (MNO) subscriptions. Essentially, the gateways are all receiving on the same channels, but get uploaded to the cloud (network server and application server)  where the encryption occurs.

 The things network (TTN) offers network servers that support over a thousand gateways globally with a level of customization for applications. Users leveraging the things network servers can use multiple application programming interfaces (API), software development kits (SDK), and other programs to integrate applications with TTN and ultimately enable communication with a user’s end-devices on the Internet. The CableLabs LoRaWAN application server project is an application server that aims to provide a complete solution for developing a private LoRaWAN infrastructure without the additional complexity in code that comes with a public and distributed network. 

LoRaWAN End-Device Classes 

Based upon the ALOHA protocol, the system is designed to be completely asynchronous where there is no clock signal between the sender and receiver. While this does diminish the data rate, payload size and limits the amount of listening an end-device can do, it is the compromise necessary to increase the range. It also has inherent security as transmission may be difficult to track and therefore be interfered with.

As shown in Table 2, there are three classes that an LoRaWAN end-device can fall under: A, B, and C. All classes are able to uplink (transmit) messages at any time. Class A EDs are optimized for battery life and in order to accomplish this can downlink (receive) messages at two slotted intervals. Class B EDs are optimized for low latency through the use of additional slotted intervals outside of the two already allocated spots. Class C EDs are optimized for even less latency with the maximum amount of receive slots. The highest to lowest supply current modes are as follows: transmit, receive, synthesizer, standby, idle, and sleep. For both classes B and C, the ED must stay and the high supply current receive mode and therefore has a much shorter battery life. 

Table 2

LoRa Transceivers

Of the twelve LoRa transceivers listed on Semtech’s website, there are eight that can be used in the 915 MHz unlicensed band in North America. While there are reference designs for the implementation of the SX1261 and SX1262 [9], the SX127x line of transceivers is the best documented, with reference designs and sample software readily available online as well as development kits [10]. 

Table 3 reveals some of the major differences in the SX127x line of transceivers; the SX1272/3 offer three bandwidth options while the SX1276/7/9 offer ten, a difference can also be seen in the spreading factors. The frequency, bandwidth, and spreading factor selectivity leads to a level of customization with variable data rates and receiver sensitivity. By adjusting parameters such as the spreading factor (SF), range, payload size, and bandwidth, an engineer can optimize a system based on their requirements. The narrower the bandwidth, the higher the sensitivity of the receiver and longer the range with the trade-off of a higher power consumption and time-on-air. The orthogonal spreading factors (SF) enable the transmission of multiple spread signals simultaneously on the same channel without affecting the sensitivity of the receiver. Adjusting the SF allows a designer to strike a balance between data rate and range or power. A higher SF would therefore increase the effective range of a signal but lessen the data rate. It should also be noted that an increase in SF significantly increases the time-on-air.  

LoRa gateways are commercially available through Tektelic, Link Labs, Adaptative Modules, Gemtek, Aaeon, Lorix, Lorier, Multitech, Kerlink, Laird, and TTN. Gateways have also been custom designed and implemented through the use of single-board computers (SBC) such as the Raspberry Pi or BeagleBone with concentrator boards such as the iC880A [17]. Picocell gateways can also be generated from reference designs on Semtech’s website using the SX1308 chip [18].  Aside from being able to custom-build LoRa hardware from support online, industries and individual organizations can utilize this as well as in-house knowledge to build a private network. 

Table 3

LoRa Considerations for Industrial IoT Applications

The growing industrial IoT (IIoT) market has recently seen a need for LPWANs, particularly in the oil and gas realm, where long-range remote sensing of the flow rate and pressure of oil pipelines is critical in preventing environmental catastrophes. The 2.5 million miles of pipeline just in the U.S. call for many thousands of EDs to be employed over a secure low-latency network. Industry 4.0 users prioritize data reliability and security well beyond the preference for easy data access, standards, cost-effectiveness, and even minimal battery changes [12]. This clearly indicates that a low latency and highly secure network is necessary for any LPWAN that is implemented. 

WirelessHART and ISO 100.11a are the most notable industrial wireless sensor network (IWSN) standards. As shown in Table 4, they both function in the 2.4 GHz unlicensed spectrum with a maximum range of 200 meters. The throughput is over five times the maximum data rate available through LoRa and transmission times are over ten times faster. These standards also guarantee a quality of service (QoS) and thus, a level of determinism with traffic. Still, LoRa-based architectures can be customized to offer a QoS as well as relatively short signal time-on-air through the use of the larger 500 kHz bandwidth with a correspondingly large SF. This would, in turn, shorten the link distance.

 LoRa Considerations for Agricultural Applications

LPWANs can find utility in agricultural applications; for instance, in smart irrigation where soil moisture levels can be remotely monitored so that plants can be watered accordingly. These IoT-based systems have been proven to reduce water wastage by 30%, saving nearly 100,000 gallons of water per acre [15].  Remote monitoring similar to this necessitates large link distances, and, in outdoor environments photovoltaic (PV) cells can be used for energy harvesting so that battery maintenance is a minimal occurrence. While security may not be as much of a consideration as it is in IIoT, agricultural LPWAN applications would likely prioritize cost-effectiveness, data reliability, and easy data access. LoRa is a strong contender as there is no need for an organization to acquire a license to use spectrum space,  immediately saving on cost. Furthermore, a private LoRaWAN network can be built by hired experts without relying on a third-party network operator. The data reliability can be optimized as listed below and, with current open source LoRa platforms in development, there is a relatively simple method to access data. 

Table 4

LoRaWAN Data Reliability Considerations

Class C EDs offer the lowest latency with the trade-off of battery life which, as stated earlier, may not be that high a priority. Moreover, a higher occupied bandwidth may be used to realize higher data rates. Data reliability is still an issue since as the channel load increases, so does the collision rate; at full channel load the collision rate can go up to 80%. This lack of determinism can be mitigated with the use of acknowledgements (ACK) where the receiving device confirms a message by transmitting a data frame with the ACK bit set to 1. The downside to this is that anytime a gateway is sending this information to EDs, it is not receiving and can therefore lose traffic. Redundancy can potentially solve this problem so that while one gateway is acknowledging, the other is listening. This way, major modifications to the LoRaWAN protocol are potentially sidestepped so that a user can still take advantage of the excellent link budget even with the low reliability that comes without a synced clock signal between the receiver and transmitter. Even so, depending upon the application, a small amount of packet loss may be acceptable. For instance, if the flow rate is monitored as volume of flow (m3) per minute as opposed to volume per hour or per day. In other words, the amount of acceptable loss in messages depends heavily upon the nature of the messages, so that if there is repetition in the messages/measurements themselves, some loss is insignificant. Soil moisture readings over the course of an hour will most likely remain somewhat constant. Redundancy in transmissions, sensor nodes, and gateways can therefore lead to more data reliability. 

LoRa variants such as Symphony Link have been implemented that increase data reliability through a one-to-one pairing between the ED and gateway, slotted transmit/receive intervals and highly utilized acknowledgements. While this allows for higher data rates, it can limit the range of a signal so repeaters are often used. Backscatter techniques have also been proven to vastly extend the range of a LoRa signal [13]. 

LoRa Security Considerations

End-devices in a LoRaWAN network have a unique 64-bit identifier and all communication is done using a 32-bit device address. The security is handled using Advanced Encryption Standard (AES-128) with two session keys: the Network Session Key and Application Session Key. The network session key is shared by the ED and network server to create and confirm the message integrity code (MIC) — a specific signature added to each data frame to encrypt transmissions (even if the transmissions are identical). The application key performs a similar task for application data. 

Despite multiple levels of encryption, the payload length is always the same, leading to methods for hackers to access or interfere with data through the use of commercial off-the-shelf (COTS) jamming equipment [14]. With thousands of devices, key management and frame counters implementation can become complicated, but may be necessary for ED and gateway security. Moreover, the use of a licensed band may be an additional requirement for security. Developers and manufacturers may also add other layers of encryption; for instance, the commercially available MAC Symphony Link comes with remote firmware upgrades, public key infrastructure (PKI), and transport level security (TLS). 

Figure 1: LoRa uses the star-of-stars topology where thousands of end-devices can connect to a gateway which, in turn, communicates to the cloud via a high throughput (IP) link
Source: https://www.thethingsindustries.com/technology/network-server


The LoRa platform offers a frequency and bandwidth customizable hardware that allow for adjustments in data rate, time-on-air, and link distance. The balance between power budget and link budget often leads to a number of necessary trade-offs, but can optimized to fit a particular application. The open source aspect of LoRa community with the LoRaWAN MAC layer may make this LPWAN a desirable option when cost is a major consideration. As with any wireless sensor network (WSN), there are latency, determinism, and security issues that can be tailored to be more robust. 


1. https://www.loraserver.io/

2. https://github.com/Lora-net/LoRaMac-node

3. https://media.ccc.de/v/33c3-7945-decoding_the_lora_phy

4. https://opendevelopment.verizonwireless.com/news/article/Verizon-LTE-CatM-Launch

5. https://www.lora-alliance.org/the-alliance

6. https://www.link-labs.com/symphony

7. https://www.semtech.com/products/wireless-rf

8. https://pubs.gnuradio.org/index.php/grcon/article/view/8

9. https://www.semtech.com/uploads/documents/AN1200.40_SX1261-2_Reference_Design_Explanation_V1.0.pdf

10. https://www.semtech.com/uploads/documents/AN1200.19_SX127x_RefDesign_STD.pdf

11. https://www.thethingsnetwork.org/map

12. https://www.isa.org/intech/201504web/

13. https://longrange.cs.washington.edu/files/loRaBackscatter.pdf

14. Aras, Emekcan, et al. “Exploring the Security Vulnerabilities of LoRa.” 2017 3rd IEEE International Conference on Cybernetics (CYBCONF), 2017, doi:10.1109/cybconf.2017.7985777.

15. https://modernag.org/water-conservation/soil-sensors-next-drop-iot-technology/

16. https://onestore.nokia.com/asset/200178/Nokia_LTE_Evolution_for_IoT_Connectivity_White_Paper_EN.pdf

17. https://www.thethingsnetwork.org/docs/gateways/start/build.html

18. https://www.semtech.com/products/wireless-rf/lora-gateways/SX1308