A Survey on LoRaWAN Technology: Recent Trends, Opportunities, Simulation Tools and Future Directions

Abstract

Low-power wide-area network (LPWAN) technologies play a pivotal role in IoT applications, owing to their capability to meet the key IoT requirements (e.g., long range, low cost, small data volumes, massive device number, and low energy consumption). Between all obtainable LPWAN technologies, long-range wide-area network (LoRaWAN) technology has attracted much interest from both industry and academia due to networking autonomous architecture and an open standard specification. This paper presents a comparative review of five selected driving LPWAN technologies, including NB-IoT, SigFox, Telensa, Ingenu (RPMA), and LoRa/LoRaWAN. The comparison shows that LoRa/LoRaWAN and SigFox surpass other technologies in terms of device lifetime, network capacity, adaptive data rate, and cost. In contrast, NB-IoT technology excels in latency and quality of service. Furthermore, we present a technical overview of LoRa/LoRaWAN technology by considering its main features, opportunities, and open issues. We also compare the most important simulation tools for investigating and analyzing LoRa/LoRaWAN network performance that has been developed recently. Then, we introduce a comparative evaluation of LoRa simulators to highlight their features. Furthermore, we classify the recent efforts to improve LoRa/LoRaWAN performance in terms of energy consumption, pure data extraction rate, network scalability, network coverage, quality of service, and security. Finally, although we focus more on LoRa/LoRaWAN issues and solutions, we introduce guidance and directions for future research on LPWAN technologies.

1. Introduction

According to Cisco, it is predicted that 500 billion devices will be connected with the Internet of Things (IoT) paradigm by 2030. On the other hand, Industrial Internet of Things (IIoT) and machine-to-machine (M2M) connectivity are directly interconnected concepts and are key players in the next step of Industry 4.0 evolution and intelligent manufacturing [1,2]. These concepts (IoT, IIoT, M2M, and IR 4.0) have changed the method of interaction between people, devices, and machines around them. They pave the way for building ubiquitously connected infrastructures for supporting pioneering services and applications. Such paradigms with promising features are attractive to both customers and industry. Recently, we have witnessed massive IoT devices connected to the Internet in various solutions and purposely designed applications. The IoT and M2M devices are connected via low-power wide-area network (LPWAN) technologies wirelessly. They can react, sense their environment, and turn on anytime and anywhere to update data in real time to the cloud [3,4]. LPWANs are meant to solve several problems with existing short-range and communication cellular network technologies to address the IIoT applications. Massive IoT devices are connected in various applications (Figure 1) such as smart buildings, smart meters, smart agriculture, capillary networks, remote health care, connected cars, smart streets, traffic safety and control, remote manufacturing, smart grids, logistics, tracking, and fleet management [5,6,7].

Current LPWAN technologies can be apportioned to three categories of networks according to their needs for additional infrastructure: (1) based on a cellular infrastructure such as narrowband IoT (NB-IoT) [8,9] and (2) employing a third-party infrastructure such as SigFox [10], although autonomous LPWANs do not need any third-party infrastructure such as long range (LoRa) or long-range wide-area networks (LoRaWANs) [11].

For the first category, cellular technology-based LPWANs have a wide converge area, high capacity, long battery life, quality of service (QoS) provisions, and security. This type of LPWAN can be classified further into three main types: NB-IoT, LTE-M (Cat-M1), and extended coverage GSM IoT (EC-GSM-IoT). Figure 2 compares the main features of the three types of narrowband technologies. However, such networks do not use a license-free frequency band, are operated by commercialized networks based on data subscription, and are controlled by the mobile operator companies. It is not cost-effective in the long term due to the continuous subscription fees for the cellular network operators. Thus, it does not meet the standalone operation requirements, should follow the conditions of the operator company in terms of coverage availability, service cost, and number of connected devices, and cannot handle the heavy interference wave of IoT devices due to the dense population of cellular devices [12].

SigFox [10] and Telensa [13] are patented networks for the second category as service providers. The growth of SigFox started a speedy innovation cycle that raised the competition between various LPWAN technologies like LoRaWAN, LTE-M, and NB-IoT. The lack of fitting IoT standards and technologies encourages the development of such focused networks as SigFox, which is mainly developed for low data rate M2M IoT applications. Both SigFox and Telensa are similar to cellular networks that connect remote devices using ultra narrowband (UNB) technology. On the other hand, Ingenu Random Phase Multiple Access (RPMA) operates at the 2.4-GHz band. It is in the task group of IEEE 802.15.4 K as a founding member. Ingenu suffers interference from other technologies like Wi-Fi at high frequencies, with its propagation loss increasing. Furthermore, it utilizes RPMA modulation, including the coverage and higher link budget with high power consumption.

In the last category that includes Ingenu RPMA [13] and LoRa [14], the spread-spectrum (SS) technique replaced UNB at the physical layer for IoT applications, which uses wideband (noise-like signals) for data transmission and spreads the data stream across a considerably broader bandwidth than the actual data signal bandwidth. In SS-based systems, the data are delivered alternately by continually changing their carrier frequencies or their data patterns, which is different from narrowband, where a single RF band is used for data transmission. The transmitters of SS and narrowband operate at a similar level of transmit power. Thus, the SS-based technology’s transmitters can transmit at a lower spectral power density (W/Hz) than narrowband transmitters. This is one of the key advantages of LPWAN technologies based on SS and explains its popularity for low-power IoT devices. It is also difficult to detect, intercept, demodulate, and jam SS transmissions. The SS technique can be classified into DSSS, FHSS, and CSS categories. Ingenu had developed the proprietary RPMA as one SS-based LPWAN technology that relies on DSSS modulation. RPMA does not utilize sub-bands like SigFox, but it uses a 2.4-GHz ISM band to realize a worldwide LPWAN technology.

LoRa/LoRaWAN is open-source technology that can set up a private network autonomously and without a third-party infrastructure at a low cost. In contrast to SigFox and NB-IoT, LoRaWAN allows for the development of private networks and simple integration with a wide range of global network platforms (e.g., The Things Network). Because of its open access specs, LoRaWAN has piqued the curiosity of the research community almost from the moment it was introduced to the market. Despite different LPWAN family technologies, this paper mainly focuses on the recently proposed solutions to develop LoRa/LoRaWAN technology. Among all LPWAN technologies, LoRa has been chosen, depending on its market penetration and its enormous applications in industry, education, and communities. LoRa is a physical layer with low-energy and long-range communication technology operating in unlicensed radio bands at the sub-gigahertz level. LoRaWAN is the medium access control (MAC) protocol for the datalink layer and network layer on LoRa, backed and developed as a standard by the LoRa Alliance [15]. These features make LoRa networks a strong candidate for diverse IoT application deployments such as industrial sensor communications, smart cities, smart buildings, water quality measurement, remote environmental monitoring, smart meters, and intelligent agriculture.

Hence, this paper describes the multiple and various features of LPWAN technologies and contrasts them concerning their implementation features as a guideline to analyze their performance and possible benefits. The main contributions of this paper can be summarized as follows:

(i)

Conduct a thorough review of the emerging LPWAN technologies, concentrating on their main features and limitations;

(ii)

Perform an overview of LoRa/LoRaWAN technologies as a key player for IoT applications, especially in standalone network deployments;

(iii)

Examine and compare the commonly used LoRa/LoRaWAN simulation tools by highlighting their capabilities and features for enabling researchers to select the most suitable simulator based on their needs and programming skills;

(iv)

Highlight the challenges, recent solutions, and future directions to provide guidelines toward precise deployment of LoRa/LoRaWAN technology as a global network.

The rest of this article is structured as follows. In Section 2, we exhibit an overview of the considered LPWAN technologies and compare their main features. Section 3 focuses on LoRa/LoRaWAN technology and its technical features. In Section 4, we present the challenges and recent solutions to LoRaWAN. Section 5 surveys the available simulation tools to analyze LoRa/LoRaWAN performance. Then, we present the opportunity for enhancement and future works on LoRaWAN in Section 6. Finally, we conclude the article in Section 7.

2. LPWAN IoT Technologies

The crucial features of LPWAN technologies are a tremendous number of distributed devices across vast environmental distances with low-energy connectivity and unprecedented low costs. In this section, we introduce a thorough review of select LPWAN technologies that were developed to be used in the field of IoT applications and M2M communication.

2.1. NB-IoT

NB-IoT is 3GPP or 4GPP wireless access as a narrowband LPWAN technology that can collaborate in LTE or GSM under licensed frequency bands to achieve excellent performance. NB-IoT dominates a frequency bandwidth of 200 kHz for downlink and uplink communication [9], and its protocol is based on the LTE communication protocol. Thus, several concepts and building units of LTE’s physical and upper protocol layers are reprocessed by NB-IoT’s physical and upper protocol layers. In LTE M (Cat M1), the device receives a portion of the LTE carrier, as well as devices that are multiplexed across the LTE carrier, and the device takes advantage of the full leveraging capacity of the wideband LTE carrier. NB-IoT devices have these features in contrast to Cat M1: an NB-IoT carrier is present, shared capacity is given to all NB-IoT devices, and the capacity may be scaled by adding additional NB-IoT carriers. The implementation of NB-IoT can be offered through a software update and can be installed in three operating modes, as shown in Figure 3 and as follows:

(i)

Standalone: This scenario deploys in a standalone 200-kHz spectrum. For increasing coverage, NB-IoT uses all the transmission power at the base station. The use of this mode will typically be as a substitute for GSM carriers.

(ii)

In-band operation: This is deployed in a wideband LTE system, including one or more (180 kHz) LTE physical source blocks. NB-IoT signals must not be transmitted to the region’s LTE-reserved time–frequency tools (including legacy-controlled area signals and reference signals). Wideband LTE and NB-IoT technologies share their transmission power at the base station and can be useful for consuming the same base station hardware with the output of either not being affected [16].

(iii)

Guard band operation: This is deployed in the guard band of an LTE carrier and co-placed with an LTE cell, as the LTE channel shares the transmission power and the same power amplifier [17,18].

The efficiency of the battery is conducive to its cost. Single-carrier frequency-division multiple access (FDMA) is utilized by the NB-IoT uplink, while orthogonal FDMA (OFDMA) and quadrature phase shift keying modulation (QPSK) are used in the downlink [9]. The NB-IoT message has 1600 bytes as a maximum payload size. The uplink data rate is restricted to 20 kbps, while 200 kbps is the restriction for the downlink.

Figure 3. Operating modes of NB-IoT and Cat-M1.

Figure 3. Operating modes of NB-IoT and Cat-M1.

2.2. SigFox

SigFox is M2M technology designed by the French start-up SigFox company. It uses UNB technology to accomplish transmission ranges of many km in a license-exempt band within the power constraints [19]. In Europe, for example, the band used is between 868 and 868.2 MHz, whereas in other countries, the band used is between 902 and 928 MHz, based on local regulations. The autonomy, simplicity, cost-effectiveness, short messages, bidirectionality, and complementarity of the SigFox protocol are its primary goals. The flat architecture of the SigFox network is illustrated in Figure 4. It consists of three main components, namely (1) SigFox equipment (devices and base stations), (2) SigFox support or cloud systems (e.g., supervision, backend services, and storage), and (3) Web interface and API (front-end services and data) [20].

SigFox supports SigFox network operators (SNOs) and works with them as a partner to build their network structure and support it as a service. SNOs deploy proprietary equipment in the form of gateways equipped with cognitive software-defined radios, which are connected to the servers through an IP-based network infrastructure. When compared to LoRa (CSS), the SigFox physical layer is relayed using Gaussian frequency shift keying (GFSK) and differential binary phase shift keying (DBPSK) instead of CSS. It has 100 Hz of bandwidth to transmit data in channels and achieves lower noise levels, higher receiver sensitivity, ultra-low consumed power, and a cheap antenna design [21]. SigFox uses 192 kHz as the total of the spectrum, with a maximum throughput of 100 bps. Due to the lack of synchronization between the device and the network, frequency hopping and replicating the message twice are used in data transmission for a total of three random frequencies to obtain a high QoS.

The transmitted power of SigFox is 14 dBm, the equivalent to 25 mW, and typically, the end device’s receiver sensitivity is −124 dBm. According to the company, the maximum path loss that can be tolerated by SigFox is 160 dB, which is better than being pathless in conventional cellular networks [22]. SigFox further submits that up to 1 million terminals may be handled at each base station, with coverage in rural regions of 30–50 km and in urban areas of 3–10 km [23]. The daily uplink messages are limited to 140 messages, with a maximum payload length of 12 bytes with up to 100-bps data rates for compatibility with the regional regulations concerning license-free spectrum usage. Nevertheless, the daily downlink (DL) message numbers are limited to four messages with a maximum payload length of eight bytes, therefore having no acknowledgement for all uplink messages [24]. The end device sends uplink messages to the base station and then waits for a short duration to listen to any downlink from the base station.

Thus, SigFox is the right choice for sensor data acquisition but not for control actuators. SigFox uses both the variety in time and frequency as well as redundancies to improve the reliability of the uplink communication and overcome the lack of adequate support for uplink message acknowledgements [25]. The end devices can send a message many times across different frequency channels and choose a random frequency channel to broadcast their messages autonomously. Moreover, the base stations can scan all of the channels in order to decipher the messages. Therefore, in the EU region, the band from 868.180 to 868.220 MHz is split into 400 100-Hz channels, of which 40 are reserved and unutilized channels [26].

2.3. Telensa

Telensa is a spin-off from Plextek Company in the UK. The scalable, private networks Telensa offers ensure high-value infrastructure options such as smart metering, smart lighting, and smart cities having the capacities they require. It has focused on specific IoT utilization states such as smart lighting of streets and urban data and succeeded, with a large global install base of connected street lighting devices. It has the same endpoint silicon similar to SigFox, although it has its own communication protocols. Telensa claims that millions of lights are being controlled using its technology, and their products are suited to smart homes and cities, tracking, detection, monitoring, and recovery [27].

Telensa has lately emphasized several smart city applications, including urban IQ, for real-time data insights and urban data, among other applications. Currently, they are creating a new generation of light pole sensors that will incorporate smartphone artificial intelligence (AI) technology, allowing detailed real-time insights to be obtained at a reasonable cost for the first time. These multi-sensor pods combine the greatest developments in camera and radar imaging technology from the automotive sector with the newest artificial intelligence technologies from smartphones to create a powerful combination. They provide a unique opportunity to gain a thorough understanding of how roadways function. Because no videos are kept and no personal data are gathered, there is no risk to one’s personal information. For its part, Telensa leads an urban data project that builds on the changing economics of data collection and provides cities with the necessary tools to collect and use their data responsibly with full citizen oversight. This project is what is known as a city’s digital twin, and it is being driven by Telensa. Telensa claims that this project has the potential to improve the quality of life for everyone [28].

Figure 5 illustrates the UNB architecture, showing that Telensa’s network has designed vertical network stacks with integration to help offer end-to-end solutions and is fully integrated with third-party software for LPWAN applications [27]. Telensa created a proprietary UNB modulation mechanism for a wireless connection between its end nodes and base stations. The UNB modulation works in a license-free sub-GHz ISM band (60, 200, 433, 470, 868, and 915 MHz) at a low data rate connection. UNB is optimized for transmissions at low bandwidths [24]. With the very low bit rates, the radio receiver becomes significantly more sensitive than conventional cellular networks. This enables devices to transmit via a similar range to cell phones but for the longest distance and with much less power.

UNB is low-risk and the best in its class, with over 8 million UNB devices being used in 30 countries because of its proven record in offering rugged, efficient IoT solutions. In order to enhance easy integration within applications, Telensa standardizes its technology with ETSI low throughput network (LTN) specifications. It operates at a downlink rate of 500 bps and an uplink rate of 62.5 bps. Telensa and SigFox work together in the ETSI LTN group.

2.4. Ingenu RPMA

In 2010, Ingenu patented RPMA technology [29]. Ingenu has created LPWAN technology under the RPMA standard, providing a significantly larger connection capacity than SigFox or LoRa. It is mainly developed for machine communications and offers many advantages over conventional IoT and M2M connectivity solutions. Each access point can cover up to 300+ square miles, which is a superior range compared with cellular technologies. Ingenu RPMA is a technology that has been developed from the ground up using novel modulation techniques to decrease overall ownership costs while extending the range and increasing the link capacity compared with SigFox and LoRa networks. RPMA technology penetrates deeper and wider with high scalability compared with other wireless technologies, as shown in Figure 6. It aims to provide robust data transmission capabilities at a low cost and meet or exceed the data features that are expected by the industry based on cellular technologies. Efficient signal transmission handling plays an important role in achieving the required transmission gains. Among the significant features of transmission, one of its gains is the unit differences in signal power causing exponential coverage differences. RPMA attains its widest coverage by optimizing its receiver sensitivity, which results in a good signal power while maintaining a massive capacity. End devices may also alter their transmitting power to reach the nearest access point (AP) while minimizing interference with other nearby end devices. RPMA also maximizes the transmission power to the greatest extent permitted by government legislation by operating in the universal band and 2.4 GHz unlicensed, which allows for greater transmission power and offers a bandwidth of 80 MHz (up to 40 channels with a 1-MHz bandwidth and 1-MHz buffer). The RPMA is efficient, and its signal needs only a 1-MHz channel width for supporting an entire network. These important elements work together to provide a strong signal and industry-leading coverage per access point, as well as allow RPMA a great deal of freedom in terms of placing frequencies where there is less traffic [13]. However, because the 2.4-GHz frequency band is widely used by many other technologies, such as Bluetooth and Wi-Fi, there may be interference because the spectrum is more likely to be crowded.

RPMA has a longer range in open space and a higher link budget [21]. RPMA is capable of demodulating up to 1200 signals at the same time when they are sent on the same frequency. A strict synchronization between the AP and end devices is maintained to ensure that the end devices transmit a signal that fits inside specified frames of a specific size. The number of possible signals that might have been transmitted in each frame is in the thousands. End devices transmit their signals with a random delay that is short enough to not exceed the size of the frame in which they are transmitted. Moreover, to select the signal delay, the end devices individually calculate the optimal spreading factor for transmission, depending on the measurement of the strength of the downlink signal. The RPMA AP does not need previous knowledge about the spreading factor that the end device will pick because the AP brute-forces its way through all potential spreading factors and delay durations.

RPMA allows for bidirectional communication, although with minor link asymmetry. When utilizing DL communication, access points (APs) distribute signals for individual end devices before broadcasting them via CDMA. Ingenu stated that RPMA could achieve a receiver sensitivity of −142 dBm and a link budget of 168 dB with a maximum link budget of −142 dBm.

2.5. LoRa

LoRa is a modulation technology patented and acquired by Semtech Corporation in 2012 for wireless communications [30]. LoRa was created to operate on a sub-GHz frequency, specifically on unlicensed bands such as 915 MHz, 868 MHz, or 433 MHz, in accordance with the regional area regulations. LoRa is a physical layer based on chirp spread spectrum (CSS) modulation, which is not similar to other modulations used in other wireless networks [31]. LoRa was designed to be low-rate, low-power, and transmit with very a long-range in line-of-sight or rural area situations up to 10 or 20 km outdoors as a result of the higher sensitivity of LoRa CSS modulation enabling long-distance connectivity [32]. Its low energy consumption, coupled with long-distance communication, makes LoRa one of the potential candidates of LPWAN technologies for IoT applications [33]. As one of the most significant benefits of LoRa, the great receiver sensitivity is accompanied by an extremely wide communication connection budget. When utilizing LoRa modulation, the typical values of SNR for 10 and 12 spreading factors are −20 dB and −15 dB, respectively, resulting in receiver sensitivities of −134 dBm and −129 dBm, respectively, according to the manufacturer. However, these values are only somewhat equivalent to the average sensitivity of Wi-Fi or Bluetooth receivers, which is typically in the range from −40 dBm to −80 dBm [31].

Different options for orthogonalizing transmissions as much as is feasible are provided by LoRa, such as the carrier frequency (CF), spreading factor (SF), bandwidth (BW), and coding rate (CR), and collision-free communications can be achieved simultaneously. The LoRa radio can transmit with data rates from 250 bps to 5.5 kbps with CSS and up to 50 kb/s with FSK. The SF, CR, BW, and CF are transmission parameters of LoRa, which requires defining their values. The SF is from 7 to 12 as an integer value. There is an inverse relation between the SF and DR by means of increasing the symbol length due to a higher SF, thus decreasing the DR. The lower layers of LoRa are a property by Semtech, while the upper layer is specified by an open standard: LoRaWAN. To connect with a gateway, various end devices can use LoRa modulation, and the LoRa Alliance is developing that open standard [23].

In

Table 1. LPWAN technology comparison.

Property or Technology	NB-IoT	SigFox	Telensa	Ingenu RPMA	LoRa
Founder	3 GPP	SigFox	Telensa	Ingenu	Semtech
Standard	3 GPP Release 13 and 14	SigFox and ETSI LTN	Telensa and ETSI LTN	RPMA and IEEE 802.15.4 K	LoRa Alliance
Frequency band	Licensed 7–900 MHz	Sub-GHz ISM EU: 868 MHz US: 902 MHz	Sub-GHz ISM EU: 868 MHz US: 915 MHz AS: 430 MHz	2.4 GHz ISM	Sub-GHz ISM EU: 868 or 433 MHz US: 915 MHz AS: 430 MHz
Bandwidth	180 kHz	100 or 600 Hz DL:1.5 kHz	100 kHz	1 MHz	125,250,500 kHz
Modulation	DL: QPSK UL: π/4-QPSK, π/2-BPSK, QPSK	UL: UNB DBPSK DL: GFSK	UNB 2-FSK	UL: RPMA- DSSS DL: CDMA	CSS, FSK
MAC	TDMA-based MAC	ALOHA MAC	n/a	TDMA-based MAC	LoRaWAN/ALOHA-based
Protocol ownership	Standard	Proprietary	Standard	Proprietary	Partially proprietary
Data rate	UL: 64 kbps DL: 25 kbps	UL: 100 or 600 bps DL: 600 bps	UL: 62.5 bps DL: 500 bps	UL: 624 kbps DL: 156 kbps	LoRa: 0.3–37.5 kbps, FSK: 50 kbps
Range	Urban: 1.5 km Rural: 20–40 km	Urban: 3–10 km Rural: 30–50 km	Urban: 3 km Rural: 16 km (NLOS)	Urban: 15 km Rural: 48 km	Urban: 5 km Rural: 45 km
Link budget (dB)	189	EU: 162 US: 146	EU: 161 US: 149	EU: 168 US: 180	EU: 151 US: 171
Max. Payload size (bytes)	13	UL: 12 DL: 8	65k	64	250
Tx power (dBm)	35	24	14	21	21
Security	L2 security	No or encryption at higher level	Yes	AES 256 b	AES 128 b
Interference immunity	Low	Very high	Very high	Low	Very high
Adaptive data rate	No	No	No	Yes	Yes
Localization	No	Yes (RSSI)	No	No	Yes (TDOA)
Topology	Star	Star	Star or tree	Star or tree	Star-of-stars
Energy consumption	Low	Very low	Low	High	Very low
Link symmetry	No	No	No	No	Yes
Allow private networks	No	No	No	Yes	Yes
Over the air updates	No	No	Yes	Yes	Yes
Error Correction	CRC	UL: CRC-16 DL: CRC-8	Yes	CRC	FEC and CRC-8/16
Channel or orthogonal signal	12 carrier	360	multiple	40	EU: 10 US: UL 64+8, DL: 8 + SF
Nodes per gateway	52,000	>1,000,000	5000	500,000	>1,000,000
Cost	Moderate	Moderate	High	Low	Very low

, we compare and summarize the considered LPWAN technologies based on various specifications such as the standard, bandwidth, modulation, data rate, range, link budget, maximum payload, power efficiency, security, adaptive data rate, localization, allowance of private networks, availability, and battery lifetime. Hence, each technology can be selected based on the crucial factors of the IoT application and use cases. Solutions such as the RPMA and LoRa can be employed as a private network for the aforementioned applications, whereas Telensa, SigFox, and NB-IoT do not support private network deployment due to the signal coverage being dependent on the base stations of the service provider [8]. Furthermore, the RPMA and LoRa have adaptive data rate features, depending on the distance between device and gateway, that can minimize the time on-air and power consumption in the case of closed end nodes, whereas Telensa, SigFox, and NB-IoT do not support adaptive data rates. In contrast, LoRaWAN by the LoRa Alliance and RPMA by Ingenu have limited investigation of the proprietary LPWAN IoT solutions. LoRa exceeds RPMA in many factors, such as data payload size, link symmetry, and saving energy consumption, as depicted. There are several analytical works on the performance evaluation of data rate adaptation that attempt to represent the optimization issue but are failing miserably. There are a number of publications devoted to the evaluation of LoRaWAN’s performance, though they are mostly dedicated to energy consumption, communication range, and network capacity studies. Therefore, there is a necessity for intensive and rigorous analytical studies to optimize the performance for energy consumption, convergence time, and network scalability presently.

3. LoRaWAN Networking

With its star-of-stars network structure, LoRaWAN allows for secure bidirectional communication in both directions. Although LoRa/LoRaWAN technology offers many advantages in terms of low bit rate and power consumption, wide coverage, simplicity, the possibility of deploying a private network, security, and ease to manage due to its star-of-stars topology, recent studies have highlighted a number of potential issues with LoRa/LoRaWAN networks, particularly in terms of scalability in large-scale scenarios.

LoRaWAN is a cloud-based MAC layer networking protocol that is designed and maintained by the LoRa Alliance to define the upper layers of long-range wide-area networks with a LoRa physical layer. It is an LPWAN technology for battery-operated wireless connection of objects to the Internet in regional, national, or worldwide networks that aims at major IoT needs, including two-way communication, end-to-end protection, mobility, and localization. The LoRa physical layer supports long-range communication links, whereas the LoRaWAN protocol principally functions as a protocol to route the network layer between LoRaWAN gateways and LoRa devices. LoRaWAN also manages the data rate, communication frequencies, and transmission power for all nodes in the network, which are asynchronous and transmit data on demand. As shown in Figure 7, the transmitted data by an end device will be received by nearby gateways that forward the data payloads to the cloud server (The Things Network (TTN)) that is integrated into several IoT platforms. The duplicated packets will be filtered at the network server, which also manages the network and ensures data security. By using any of the available integrations, the received information is forwarded to application servers (Web-based dashboards and MobileApps.). A LoRaWAN technology architecture defines the three fundamental types of devices as follows:

• End devices (ED): These are devices that either take downlink (DL) traffic from the network server or generate uplink (UL) traffic for transmission to the gateways;
• Gateways (GW): These are the devices that demodulate LoRa communication and transmit it between the network server and the end devices in a wireless network. Wired or wireless access points link gateways to the Internet. The LoRaWAN gateway is sophisticated, concurrently listening to the radio on several channels and delivering thousands of ENs simultaneously;
• Network Server (NS): This is the device which serves as the core backend of a LoRaWAN network, collecting traffic from all end devices in the network and processing it on an application server.

LoRaWAN enables sensing nodes to transmit information as small packets with low energy consumption to a faraway gateway for many kilometers in one hop, and the technology is robust to interference [15]. LoRaWAN networks may be used for relatively dense installations with low latency and reliability requirements, and they are becoming increasingly popular [23].

When compared to other wireless technologies, LoRaWAN provides the option of private network installations as well as easy integration with a variety of WAN network platforms (e.g., TTN). Because of this and its open access specifications, LoRaWAN has attracted the interest of the scientific community, technology manufacturers, and service providers since its first appearance in the market [34].

The adaptive data rate (ADR) is included in the LoRaWAN network to choose a transmission speed that better fits the conditions of the channel. LoRaWAN works on free regional frequency bands such as 915 MHz in America, 868 MHz in Europe, and 433 MHz in Asia as the carrier frequency. It uses 125, 250, or 500 kHz as its bandwidth. For error detection and correction, LoRaWAN uses the coding rate and employed number of bits to show this. The combination of all aforementioned features made LoRaWAN a powerful technology for very long-range transmission in IoT applications.

Because of its specific modulation, LoRa is a multipurpose technology that can be versatile and function in different types of environments and application groups. LoRaWAN defines three operation modes as classes [35]: A, B, and C. All nodes must be initialized with Class A, as the default choice mode is considered when EDs send data at any time to the GW through an ALOHA-based LoRaWAN MAC protocol.

• Class A: This class uses two receiving windows at specific times following each UL transmission. As a timing diagram in Figure 8, at the beginning of these receiving windows, only DL transmissions are allowed. With regard to the first window, DL transmissions are carried out using the identical channel and data rate settings as the prior UL transmission. Nevertheless, the second window uses a static setting (i.e., DR0 (SF12/125 KHz)) at 869.525 MHz.
• Class B: This class is an optional mode for ED that needs to receive additional information from the base station as acknowledgment (ACK) that using this mode is better. Despite no former transmission from the EN, the GWs open more reception windows by transmitting synchronization beacons. The number of receiving windows allowed by Class B is more than Class A, but with more energy consumption than Class A. After each UL transmission, the extra regular receiving windows are opened, in addition to the synchronized opening of the two standard receiving windows, called ping slots. The GW beacons are sent periodically every 128 s to guarantee synchronization. The usable beacon window is a time period between two beacons. It is grouped into 2¹² ping slots of 30 ms, each counting from 0 to 4095 [36].
• Class C: The nodes keep their reception windows open all of the time, only shutting them when the UL sends a packet to one of them. These ENs increase power consumption, since Class C forces the devices to receive constantly, which is incompatible with Class B. The devices that support Class C do not implement Class B.

Selection of the mode operation or class depends on the application. Thus,

Table 2. LoRaWAN device class comparison.

Criteria	Class A	Class B	Class C
Access approach	ALOHA	Slotted ALOHA	ALOHA
Collision	High	Moderate	Moderate
Time of reception	2 s if ON	Relay on slot time	Always unless transmitting
DL latency	High	Moderate	Low
Real-time support	No	No	Yes
Most of time state	Sleeping	Beacon	Listening
Power consumption	Very low	Low	Moderate

can guide the right class selection by comparing the classes adopted on some criteria such as the access approach, collision, downlink latency, real-time support, and power consumption [37].

LoRaWAN Limitations

The limitations on LoRaWAN as a MAC layer are a result of limitations in the physical layer (LoRa). Obeying the duty cycle restriction that is imposed by authorities on corresponding frequency spectrum regulations in some regions is another possible bottleneck of a LoRaWAN network. Such limitations may substantially restrict the downlink traffic, present a minimum delay between the sequential packets sent by a device, and limit the peak throughput. In LoRa networks, duty cycle restrictions exist on the maximum time of the end devices to stay on or allow transmission per hour. This restriction decides the available time for each channel during packet transmissions, which changes randomly for different end nodes. Thus, it limits the number of transmitted packets from the end devices. Although this duty cycle increases the network’s robustness against interference, it is often not possible for a larger scale of deployment because of the 1% duty cycle limit on the downlink gateway transmissions, causing an additional delay.

4. LoRaWAN Issues and Recent Solutions

Although LoRaWAN offers many advantages in terms of low bit rate and power consumption, wide coverage, simplicity, and ease of management due to its star-of-stars topology, recent studies have raised several potential issues with LoRaWAN, particularly in terms of scalability in large-scale scenarios. In this section, we present several issues of LoRa networking with useful solutions based on recent studies. Several of these issues are addressed through deep investigations about their influence on the works of the LoRaWAN network. We have classified the considered studies into five categories based on the focused issues in each study.

4.1. Power Consumption

There are three important characteristics of LPWAN that can meet the key requirements of IoT applications, which are high energy efficiency, large-scale deployment, and low cost. Power efficiency is a major parameter in improving a system’s lifetime. This criterion is well met by LoRa networks, where LoRa nodes can operate with minimum maintenance for a longer lifetime of up to 10 years. Among the obstacles for LoRa networking is, therefore, power consumption. The consumed energy of the end devices can be divided into two types: (1) the energy consumption of the micro-controller, which varies according to the chosen host board, and (2) the consumed energy by wireless transmissions, which depends entirely on the LoRa technology and node activity [11].

Many studies have been conducted to improve the power efficiency in LoRa. The proposed solution in [38] is divided into two phases. In the first phase, an improved compressed sensing algorithm known as ISL0 is proposed by using a complicated trigonometric function rather than a Gaussian function for reconstructing network data and reducing the number of LoRa nodes that transmit data, thus avoiding collision and latency. In phase two, a sleep schedule mechanism is proposed for reliable data acquisition with monitoring of the device’s status. The network server configures the proposed sleep schedule. Hence, each node executes its sleep interval cyclically. Two modes are involved in the sleep schedule—sleep mode and semi-sleep mode—and the nodes in the semi-sleep mode are selected randomly in each cycle. This method enables the instantaneous detection of abnormal information and duly records the overall network data. The authors claimed that the results showed that the proposed approaches balanced the energy consumption among all nodes and maximized the network’s lifetime. The compressed sensing algorithm can substantially reduce the number of LoRa nodes that transmit data concurrently and then decrease the gateway delay, giving LoRaWAN a new idea for penetrating boundaries with the proposed sleep schedule as only being linked to sampling. The compression values and total number of nodes do not affect the network length. The merging of ISL0 algorithms and mechanisms for energy planning greatly improved the lifespan of the network without affecting the impact of the network observation.

The authors of [39] proposed three schemes for improving power consumption. The first scheme suggested an algorithm that prevents the collision between two colliding signals and thus recovers entire frames without any loss. The second scheme is a special MAC beacon-based protocol that is used to decode two or more overlapping LoRa signals using a collision resolution technique. The third strategy is to decode an algorithm that slightly disconcerts and overlays the characteristics of a LoRa physical layer as well as the overlays. The simulation results show that the decoding scheme can be further improved by the use of the already offered CRC in each frame under the suggested collision resolution process. Additionally, the simulation findings revealed that significant performance increases in terms of both device energy consumption and throughput were achieved when comparing the ALOHA LoRaWAN protocol with the CR-MAC protocol, as demonstrated by the simulation results. Furthermore, the proposed protocol reduced the delay significantly. The drawbacks considered were the size of the beacon (10 bytes) and retransmission times of the packet loss (one time only). In future work, the proposed protocol must be strengthened further by creating personalized retransmission policies.

In [33], the authors proposed an optimized energy model for sensor nodes based on LoRa/LoRaWAN technologies. The proposed models were evaluated to reduce the loss of energy by the sensing unit, MCU unit, and transmission unit. The energy of each unit was modeled individually to compare the consumed energy by each part of the LoRa node. The proposed model shows the effect of the selection of hardware and software for the sensor. Additionally, it shows the effect of transmission acknowledgement and the choice of different LoRa/LoRaWAN parameters. Therefore, it is very important to optimize these parameters to reduce the energy consumption of the end devices, such as the spread factor, payload size, bandwidth, and coding rate. The findings showed through the numerical results that with distinct LoRa/LoRaWAN parameters, the consumed energy shifted. Class A was most energy-efficient in LoRaWAN, which is the basis of the model. However, the study only evaluated the power consumption in the hardware parts of the LoRa nodes and did not suggest an approach to enhance the LoRa radio, merely mentioning the effect of ACK and parameter selection. The optimized energy models could be further enhanced in future work by LoRa power management algorithms to optimize the sensor node’s lifetime.

In [40], FREE is proposed as a fine-grained scheduling scheme for reliable and energy-efficient data collection. FREE computed the transmission schedule as a slot time (i.e., the transmitted data must be buffered in a scheduled time slot instead of transmitted directly). The study maximized the overhead phase, which was necessary to manage the allocated frequency channels, spreading factors, transmission powers, and time slots and synchronize the network. Collisions are the big issue of lost and retransmitted data, resulting in more power loss and representing a bottleneck of the standard LoRaWAN protocol. FREE overcomes this issue by utilizing different spreading factors and grouping acknowledgements to achieve scheduled concurrent transmissions. The solution was simulated by the LoRaSim simulator and compared with other methods for confirmable and unconformable transmissions. The results proved that FREE makes deployment quite scalable, accomplishing this with roughly 100% data delivery and a battery lifetime increased by 2 additional years until it became over a 10-year battery lifetime, regardless of the transmission type or network size. The drawback of this work is the excessive fairness between the devices in terms of power consumed. In order to use the allocations recorded in the previous data sets, this would entail a different allocation method.

4.2. Pure Data Extraction

Improvement of the data extraction rate (DER) aims to enhance the network throughput. In [41], the authors modeled the uplink nodes’ activity using a mathematical model based on collected experimental data by implementing DER as a new metric for measuring LoRa network performance. The transmitted messages in a LoRa network should be received at the backend system. In other words, each transmitted message must be received by at least one LoRa gateway. Thus, the authors defined the DER metric as the ratio of received to transmitted messages in a defined interval. The obtained ratio of the DER is a function of the node or gateway locations, number, and activity. LoRa exhibits the capture effect since it is a form of frequency modulation. The capture effect happens when two signals with different strengths reach the receiver. If the difference in the signals’ strengths is too small, the receiver will not be able to decode any of the received signals. Thus, the study suggests adding more gateways to enhance the LoRa throughput.

SF allocation was the focus of [42] to enhance the capacity of the LoRa network. An optimization for SF allocation in relation to the LoRa network’s capacity was defined by maximizing the packet success probability (PSP) to increase the connectivity of the end devices. During the SF allocation assignment process, the suggested method took both inter- and intra-SF interference into consideration. When the signal of interest has a signal-to-interference ratio (SIR) greater than a predetermined threshold, the capture effect is used to combine the two types of considered interference into the signal of interest. The propositioned scheme controls the SF distribution based on the assigned distances obtained from the problem optimization instead of conventional allocation, which is based on coverage distances according to the sensitivities of the LoRa’s physical layer. The authors used stochastic geometry for calculation of the PSP average and assigned SFs to the end devices according to the received power and SIR of the end devices. Although the proposed approach is complex, the global optimization solver can overcome this issue.

Another approach to maximize the LoRa network capacity based on SF network clustering was developed in [43]. A tree-based SF clustering algorithm allocates end devices to many subnetworks. Several transmission parameters of LoRa are considered to form multi-mesh subnets with different SFs that are rooted at the gateway for enabling simultaneous transmissions. The proposed approach balances the traffic load among the end devices using an SF capacity estimation based on the node number, data rates, and number of hops, thus avoiding bottlenecks of the subnets. The higher SF values increase the delay due to the greater air time required to transmit the packets. The authors claimed that their approach improved the network performance compared with the conventional SF allocation of the LoRaWAN network with a single hop. Nevertheless, the analysis ignored the positive impact of the offloading method since the time response was not fairly distributed among all the cluster heads. Moreover, the transmitted overhead raises the energy consumption at the relay nodes. Further investigation is required for faster prediction of the efficiency and connectivity of the SF based on higher speed data rates. The ADR can be utilized to enhance the DER and maximize network throughput.

The authors of [44] proposed extension modules for ns-3 by implementing the ADR in the LoRaWAN library to allow the simulation of a real LoRaWAN scenario. The introduced improvement optimized the data rate of the end nodes, and thus the conducted simulations achieved a minimal convergence time for the LoRa nodes. Therefore, an enhancement in the PDR was attained in a dynamic LoRa network. The authors claimed that their proposed ADR outperformed the standard algorithm in the considered scenarios, while their algorithm can be integrated easily to replace the existing ADR LoRaWAN network. However, it is particularly implemented on the TTN server. The network server algorithm fails for the DR0 nodes, with no downlink requirement supported already in numerous LPWAN situations.

4.3. Network Scalability

A number of studies focused on LoRaWAN network scalability. The scalability challenge of LoRaWAN installations occurs owing to the high number of end device request ACKs and the duty cycle constraint that the gateway must comply with. A lack of scalability may wreak havoc on the current scalability information, which is mostly commercial and assumes the best case scenario. In [41], the authors suggest adding more gateways to enhance LoRa scalability. The authors created a LoRa simulator, dubbed LoRaSim, based on the Python programming language. They terminated the network with a single gateway, which does not scale well with standard transmissions, while networks that automatically adjust the transmission parameters or have several gateways may scale better. The finding of the study is that LoRa network scalability increases if the ToA is minimized by the optimal configuration parameters as well. However, this model associates over-value attenuation in open space for LoRa ‘s signals. It needs to be evaluated on-site, as the majority of the coverage area includes conventional connections, which have been defined as connections to dynamic time links. Although the use of various gateways outperforms the present findings, the efficiency will further be improved by the optical location of the gateways in proportion to the application community.

In [45], the authors describe the results of LoRaWAN scalability research in which they created a mathematical model of the transmission process in order to analyze the scalability of LoRaWAN networks. After much deliberation, they came to the conclusion that the network’s capacity was only 1% of 51 byte frames per second. This amount of capacity equates to 5000 motes, each of which can transmit two messages each day on average. This capacity is reserved for uplink traffic that has been confirmed. In [46], a different method was used by the authors, who examined the scalability of a LoRaWAN network in which the end nodes broadcast messages regularly, regardless of the radio duty cycle. In their claim, the authors said that such an evaluation provided a lower constraint on the maximum number of nodes that could be serviced by a single portal. Another example of scalability research was carried out using a simulation model and the results of measurements with actual nodes. However, the measurements were not carried out in an interference-free environment as in the previous study. Only three particular parameter sets for the nodes were taken into consideration by the authors.

In [47], a scalability study for LoRaWAN was carried out using a stochastic geometry framework, and the results were presented. The authors demonstrated that the likelihood of coverage decreased exponentially with the rise in the number of end devices. The theoretical capability of LoRaWAN in terms of scalability and node throughput has been investigated in a number of research projects [48]. The detrimental impacts of interference were examined in densely crowded LoRaWAN cells. The authors have investigated several difficulties relating to co-distribution which, in particular, damages the scalability of LoRaWAN networks. All these studies proved that LoRaWAN networks should be configured properly to connect a great number of end devices.

The authors of [49] contrasted LoRaWAN with other communication technologies. LoRaWAN has benefits in its capacity for open standards, integrated security, GPS-free geolocation, long-distance communication, low energy consumption, and private deployment choices. In addition, the lower data rate, duty cycle restrictions, and benefits limit LoRaWAN networks in real-time applications. LoRaWAN is ideally suited to circumstances in which data transfers are infrequent (several packets a day), and the payload size is about 10–50 bytes. Smart cities, intelligent grids, intelligent farming, and remote monitoring systems are the areas of optimum use for LoRaWAN. The ALOHA-based MAC protocol of LoRaWAN limits its scalability and represents an obstacle for LoRa to lead other LPWAN technologies as the main representative in the wide-scale deployment of IoT applications.

In [50], the authors proposed a distributed queueing algorithm as an improvement to the MAC protocol of LoRaWAN. It uses a tree-splitting technique whose performance is independent of how many nodes share a channel. Unlike ALOHA, the distributed queueing method needs active nodes to contend in contention slots before sending data. The distribution of nodes between two logical queues is accomplished by the application of a set of rules. In the case of collision detection, nodes are categorized into groups and the first logical queue (collision resolution queue), and they wait for their turn to be transmitted. If no collisions are detected, the nodes are organized into the data transmission queue. The grouping of the colliding nodes decreases the collision probability in the later access attempts, since the simultaneous trails are minimized. The authors claimed that the obtained results show that the highest throughput of the modified MAC protocol is independent of the network size and shows improved throughput and delay while saving energy compared with the pure ALOHA MAC of Lo-RaWAN.

The performance level of the LoRaWAN technology is determined by the maximum number of nodes that can communicate on a LoRa channel, which determines the technology’s scalability in large-scale deployment situations. The study in [51] evaluated the level performance of LoRaWAN technology by investigating the number of packet collisions that might occur. The results show a rapid decrease in efficiency when the amount of devices that rely on the mechanic of communication of the ALOHA protocol is significantly increased. An introduction of a communication channel occupancy management mechanism may be possible to reduce the number of collisions before beginning a proposed transmission. An ADR algorithm can be used to minimize collisions and to allow automatic changes in the data rate if a collision is detected. The approach increases the energy consumption of the LoRa node when applying a collision avoidance method. Another suggestion is to eliminate the ACK mechanism, which could decrease the number of collisions [52].

4.4. Coverage Range and QoS

LoRa coverage is based on the deployment scenario of LoRa nodes and the LoRaWAN gateway in addition to the parameters of transmission, particularly the SFs, transmit power, channel bandwidth, and environmental conditions. Many empirical studies were conducted to assess LoRa coverage for both outdoor and indoor connectivity. Although LoRaWAN has a long range, especially in rural areas, and can perform well in dense deployment with obstacles, it may suffer from coverage problems. Furthermore, there is an inverse relationship between the data rates and connectivity range, which results in unacceptable performance for many industrial applications.

In [53], a measurement campaign conducted in a flat city in Finland is presented. The authors placed the gateway on an antenna tower 24 m above sea level. The study results compared the loss ratio of the transmitted packets and the RSSI based on the distance between the gateway and end nodes. Coverage up to 10 km was achieved with 33% packet loss. For the open sea area, the packet loss was 31% for ranges up to 15 km and 38% for ranges up to 30 km. This proves that LoRa can perform well up to 5 km, and then the network performance is degraded. In the study, the authors did not consider the ADR. In [54], the authors proposed a test methodology for experimentally evaluating the coverage of LoRaWAN coverage in a smart campus. The proposed scheme focused on the device definition, methods, and procedures. The method depends on a mapping phase to highlight the coverage of LoRaWAN in the tested environment. The method validation was carried out through a use case, and the obtained results demonstrated the effectiveness of the proposed methodology.

An empirical study was conducted in [55] to investigate the radio channel of LoRaWAN radio in the 868-MHz frequency band via comprehensive measurement campaigns in urban and rural areas for indoor and outdoor environments. The authors proposed a path loss model based on the results for LoRaWAN communications and compared it with the conventional models. Furthermore, the study evaluated the performance of LoRaWAN deployment based on real measurements in terms of coverage. The authors claimed that the proposed models were simple and accurate, and the achieved coverage ranges in urban areas were 8 km, while in rural areas, they reached 45 km. The overall conclusion reached is that larger spreading factors (SF12) may easily achieve coverage ranges of 5 km or greater in urban contexts, whereas lower spreading factors can achieve coverage ranges of under 5 km or greater in urban situations (SF7).

In [56], the authors suggested that LoRa+ should be a new method to address LoRaWAN’s QoS constraints. The research changed the LoRaWAN MAC layer for Class A and Class B such that the time space assigned to receive the channel parameters was moved instead of waiting for the packet transmission to conclude, as in the LoRaWAN standard. Those parameters are supplied before the transmission slot. Based on the simulation results, the authors claimed that the modified LoRa+ approach significantly decreased the required number of gateways and decreased the rate of error and rejected packets in comparison with LoRaWAN in small- and medium-sized networks [57]. By fine-tuning chosen radio characteristics, researchers have presented a simple and practical technique for improving the quality of service (QoS) of LoRaWAN. When optimizing the SF and CF parameters of LoRa, it is necessary to consider the LoRaWAN network traffic to improve the DER while simultaneously reducing the packet collision rate and the amount of energy spent. LoRaSim simulations demonstrate that the suggested optimization technique is successful in terms of boosting the DER, reducing the number of collisions, and conserving energy, as demonstrated by the results.

The research in [58] might be used to profile IoT devices, classify them based on their features, and detect network irregularities, among other uses. The k-means algorithm was used by the authors to categorize LoRaWAN packets based on their radio and network behavior. They put their method to the test on a genuine LoRaWAN network, and all of the data they collected were recorded in a secure database. The fact that LoRaWAN captures packets from many operators via the wireless interface is critical. Only a fraction of the 2169 devices engaged in the study were known to the considered operator, indicating that an operator cannot influence the entire system’s behavior but must instead monitor it. The study examined 997,183 packets from these devices. To their surprise, the results were in accordance with the current network behavior and provided early warnings of faulty devices, demonstrating the validity of the proposed approach.

4.5. Network Security

The LoRaWAN protocol is adjusted for low energy consumption and is designed to support large networks with large amounts of end devices. Innovative LoRaWAN features involve support for low-power, geolocation, redundant operation, and low-cost applications of IoT. However, the issue of security encompasses several properties and, in particular, the cryptographic methods used to implement security in LoRaWAN require more careful study. The insecurity problem is a major concern due to the resource limitations of the devices in LoRa and in LPWANs in general. The huge number of connected devices and transmitted data, among other factors, cause a highly sensitive security level. The authors of [39] investigated the key management mechanism of LoRaWAN environments and proposed a secure key management architecture, depending on smart contracts and a permission blockchain to improve the security and availability of LoRaWAN networks. The blockchain-based LoRaWAN architecture was modeled via a prototype, using open-source tools and hardware to validate its functionality and effectiveness. Different scenarios were considered for testing and evaluating the performance of the proposed approach. The authors claimed that the proposed scheme achieved similar performance with the standard ChirpStack configuration for various network sizes. The blockchain-based LoRaWAN architecture is also applicable to large-scale networks, where the end nodes are supposed to perform only one procedure of OTAA per day. Implementation in a real environment and adding new functions to the key management smart contract by enabling it to process OTAA requests are among the suggested direct future improvements.

With the aim of providing a secure communication link for LoRaWAN servers, the authors of [59] proposed an S2KG key generation procedure that has two sessions: join server-related links and symmetric key-based links. One public key and one of the symmetric key cryptographies are used for key creation procedures. Thus, every two servers can generate a unique session key. The generated session key will be used to encrypt the exchanged messages between each server pair and will be updated periodically based on the same procedure. The proposed S2KG procedure can provide mutual authentication, privacy, and message integrity. It also protects against replay eavesdropping attacks. However, a management policy for session keys needs to be added to establish highly secure LoRaWAN communication links. Moreover, the study focused on security between servers but ignored the security between the join server and manufacturer, which needs to be addressed in any future research.

5. LoRaWAN Simulation Tools

Computer modeling and simulation is the proper method to enrich the exploration of a system’s performance and evaluate tactics for its functioning in imaginative or predictive approaches. A simulation model is a design that considers computing algorithms, physical and mathematical terms, and engineering formulas that summarize the behavior and performance of a system’s intangible world case studies. LoRa network simulation is more significant since it can be exploited without costly implementation before the actual execution of the framework to design and evaluate a LoRa-based application. The field of LoRa offers highly specialized and freely available simulation tools. All these LoRa simulators have been developed and utilized in the literature for examining different LoRa scenarios. However, to the best of our understanding, none of the previous review studies compared these simulation tools enough in detail. Therefore, an overview of the most commonly used simulators to investigate LoRa/LoRaWAN performance is presented in this section.

5.1. LoRaSIM

LoRaSim has been developed based on SimPy as a discreet event simulator using Python to simulate, investigate, and analyze the LoRaWAN network scalability and collision functionality [41]. LoRaSim includes many Python scripts, with the base of them being loraDir.py, loraDirMulBs.py, directionalLoraIntf.py, oneDirectionalLoraIntf.py, LoRaWAN.py, and LoRaEnrgysim.py. The first script is for a lone gateway simulation, while loraDirMulBs.py is utilized to emulate several gateways (up to 24). DirectionalLoraIntf can emulate devices that are equipped with directional antennae and many networks, whereas oneDirectionalLoraIntf.py is for emulating gateways with directional antennae and many networks. A radio propagation model is implemented in LoRaSim, depending on the well-known long-distance path loss model. The radio transceiver sensitivity at room temperature concerning various LoRa SF and BW settings is estimated. It also considers many related parameters, such as the thermal noise power across, receiver bandwidth, noise figure, and SNR. Several packages are required for running LoRaSim smoothly, such as matplotlib, SimPy, and NumPy. LoRaSim offers a plotted view of deployments with no graphical interface, as shown in Figure 9. In contrast, it can show a data plot when users execute graphical code. Many improvements for LoRaSim were proposed to make it multipurpose [36,40,60,61,62,63] and support the downlink due to the original version supporting only the uplink. Thus, it can test scalability and energy consumption, as well as other performance metrics. Much of the information is seen on the command line and exported to File-Name.dat, which can show its content data using other graphical programs such as Gnuplot, seaborn, Mplot, or others.

5.2. NS-3

Ns-3 is an open-source discrete-event network simulator that was initiated in mid-2006 [64,65] and is still under heavy development now, written in C++ and Python. The ns-3 simulator supports a wide variety of protocols such as Wi-Fi, LTE, IEEE 802.15.4, SigFox, LoRa, and further networks. It also implements IP networking, supporting both simulation and emulation using sockets that aim at academics and research [66]. The ns-3 can be executed with pure C++, and some simulation components can be written with Python. It is modular and can function in graphical and command-line interfaces NetAnim for C++ and PyViz for Python. It also produces Pcap tracks that can be used for debugging. Standard software such as Wireshark [67] can be used to read the trace files for network traffic analysis. The ns-3 simulator offers a practical and well-structured setting with animation support using NetAnim, as shown in Figure 10.

A LoRaWAN module was developed and implemented in ns-3 to provide a powerful tool for enabling the simulation of a real LoRaWAN network instead of simulating a simplified MAC protocol. This add-on module allows the research community and developers to achieve a greater understanding of the behavior of the physical and MAC layers in LoRa networks, credited to the LoRaSim that allows the users to test a network with varying SFs based on gateway feedbacks. The LoRaWAN ns-3 module may be used to simulate LoRaWAN networks. Beyond the models created to represent different components of the network and the integrated helpers used to set them up, the ns-3 LoRaWAN module includes a packet tracker that can be used to monitor a network’s behavior and analyze its performance. It also includes facilities for storing the network topology in a file to debug and monitor. It also provides many scenarios as examples of simple to complex network use cases. The integrated LoRaWAN module meets the requirement of Class A devices. That means it can simulate the use cases where devices send uplinks and receive downlinks from the server. In comparison with LoRa’s two other available classes (Class B and Class C), the most power-efficient end devices are of this class. To deliver a highly configurable and agile solution, the physical layer, MAC layer, and transport and use are built. Concerning the LoRaWAN-based ns-3 module’s primary features, they are installations of the network server, ADR, confirmed messages, and support for multi-GW. Configurability of the LoRaWAN ns-3 module was proposed and allowed new algorithms to be implemented on the server side in [68]. In addition, investigational evaluation of LoRaWAN was conducted by ns-3 in [69], as well as improving LoRa performance with CSMA [70], the power consumption model [71], the scalability analysis model for a significant scale [66], and several models in [44,72,73,74,75].

5.3. FLoRa

A framework for a LoRa (FLoRa) simulator was developed to evaluate the LoRa network’s performance using the ADR mechanism. It proved the effectiveness of the ADR at increasing the PDR with improving energy efficiency. FLoRa is an end-to-end simulation framework for LoRa networks that relies on the OMNeT++ network simulator and also utilizes INET system components [76]. An open-source OMNeT++ library was designed to support the experimentation process for various network protocols. FLoRa code is created by C++, and it enables the development of LoRa networks that support the integration of LoRa nodes, gateways, and network server modules. Application logic can be implemented as separate modules that are linked to a network server. The network server and nodes support dynamic configuration parameters controlled via the ADR and considering collisions and the capture effect. The module includes an accurate modeling of the backhaul network and can simulate multiple gateways. At the end of the simulation, energy consumption statistics can be collected in each node and over the entire network [77].

Aside from that, the modules of the LoRaWAN MAC protocol strive to simulate the physical layer [78]. This offers a very strong graphical interface compared with the other simulation applications, since it is based on OMNeT++ and a graphical network description. The developed simulation module includes a sample scenario in the FLoRa simulations directory. The scenario has several features to simulate a network with 10 nodes that are placed randomly in a square network topology, with one gateway that is linked to a network server. Each node transmits a packet at a time based on an exponential distribution with a defined mean. For simulating a LoRa network, several parameters need to be selected, such as the simulation time, warm-up period, SF, the transmission power for each LoRa end node, backhaul network configuration, and links. The simulation statistics and tracing files are generated upon completion of the run. The simulation statistics can be viewed through the OMNeT++ GUI as in Figure 11.

5.4. CupCarbon

Carbon is an emerging framework for simulating smart city and IoT WSNs (SCI-WSN) [79]. Its aim is the design, visualization, debugging, and validating of distributed algorithms for environment observation and data gathering. It is used to simulate various IoT application scenarios for educational and scientific development projects. In addition, to visually explain the basic concepts of WSNs, it also supports the testing of different wireless topologies, protocols, and applications. CupCarbon supports two simulation environments that enable the design of mobility scenarios (fires and gas scenarios, vehicles and UAVs, and insects) and a discrete event simulation of WSNs and IoT applications. Networks can be simulated via an ergonomic and user-friendly GUI utilizing the OpenStreetMap framework to deploy sensors clearly on the map. It has a script named SenScript which enables the programming and configuration of sensor nodes individually and generates codes to be used in hardware platforms like Arduino, Raspberry Pi, and XBee. The nodes can be configured dynamically to distribute nodes into individual networks. CupCarbon supports the calculation of energy consumption and displays it as a function of the simulation time. Such functionality permits clarification of the network structure and realistic implementation before real deployments. It integrates propagation visibility with interference models and supports different communication interfaces, including LoRa, Wi-Fi, and ZigBee protocols [80]. CupCarbon is the fundamental kernel of the PERSEPTEUR ANR project to develop algorithms for the accurate simulation of signal transmission in a 3D city area [81]. The ground elevation model can be imported into a CupCarbon project by the Google Elevation API [82]. Many recent studies have utilized CupCarbon to analyze LoRa/LoRaWAN performance [80,83,84]. CupCarbon offers several objects which are easy to use and easy to customize [85]. CupCarbon offers a multi-agent simulation environment that enables simulations to be conducted and events and adjustments over time to be tracked, and it allows the reproduction of a 3D environment consisting of a floor, buildings, and different objects such as sensor nodes, as illustrated in Figure 12.

5.5. PhySimulator

PhySimulator was used as a link-level assessment for LoRa, which shows that, although the theoretical consideration is that spreading factors can be considered orthogonal, LoRa has a real problem with inter-spread factor collisions [5]. The objective of PhySimulator is to enforce LoRa’s relation level. MATLAB writes PhySimulator. The purpose of the simulator is to test the reception of two LoRa transmissions interfering with various diffraction variables [86]. In particular, each spread factor output is influenced by the packet, symbol, and bit error rate that interfere with some other spread factor. The user can use this simulator to edit several parameters (i.e., change the values of the variables’ codes). For instance, bandwidth, payload, and maximum tests can be modified per phase, among other variables, but cannot alter all these factors via a graphical interface. The user must edit them directly by changing the MATLAB code. There are several studies implemented using PhySimulator, such as field tests and capacity simulations of LoRaWAN in a seaport area conducted in [87], An effective algorithm for vehicular ad hoc network load balancing in [88], smart cities [89], realistic network planning [90], and the latest update by Hussein M., who called it LoRa+ [56].

5.6. Simulator Comparison

We compare the features of the considered simulators in this section to reach a useful conclusion about the preferences of each simulator. The operating system support, the type of license, interface, the availability of energy usage statistics, and the simulator’s programming language or environment, latest version, and updates are among the features we have compared in

Table 3. LoRa simulator comparison.

Features	LoRaSim	NS-3	FLoRa	CupCarbon	PHY Simulator
License type	Source is open	Source is open	Source is open	Free (education)	Free
Operating system	macOS, Linux, Windows	Linux, Windows	Linux, Windows, macOS	macOS	MacOS, Windows
Installation requirements	SimPy, NumPy, matplotlib	Import all libraries online	OMNeT++ 6 and INET 4.3.1	Java	Matlab
Type language	Python	C++, Python	C++	Java	MATLAB
GUI	Only plot	Yes	Yes	2D or 3D with OSM	Only plot
Community support	Limited	Very Good	Limited	Good	Good
Last update	2020	October 2020	November 2020	2020	2020
Last version	n/a	ns-3.32	6.0	3.8	n/a
Popularity	High	High	Medium	Little	High
Studies achieved by simulators	[36,41,61,91,92,93,94,95,96,97,98,99]	[44,66,68,69,70,71,72,73,74,75,100,101]	[76,78]	[80,82,83,84,85]	[56,87,88,89,90,102,103,104,105]

.

All five simulators are discrete events, support the LoRaWAN protocol, and can model the network as a sequence of discrete events in the time domain. This allows the simulators to switch to the next event if two consecutive events do not change, so the system does not need to be monitored continuously. Regarding the languages of programming used in the simulators’ implementations, all simulators are designed on well-known and supportive community programming environments. This is very important, as a specialist can quickly extend the capability of the simulator with the implementation of new modules as extensions for the existing simulators (e.g., enhance new network protocols or incorporate additional tools in the current environment).

In brief, Java is used for CupCarbon implementation; C++ is used for FloRa; Matlab is used for PhySimulator; Python is used for LoRaSim; and C++ and Python implementation are used for the Ns-3 LoRaWAN module. In contrast to other simulators, CupCarbon via 2D and 3D environments, FLoRa via OMNeT++, and Ns-3 via NetAnim and PyViz have broader graphical GUIs for the C++ and Python modules, whereas only a few plots offer PhySimulator, LoRaSim, MATLAB, and Pychrom environments in that order. All of the simulators studied were published in the scientific community, and according to the official websites of each simulator, CupCurbon, FloRa, and PhySimulator have more than two related publications, but PhySimulator has been updated by another version named LoRa+. While module ns-3 includes more than 20 related publications, and LoRaSim has 11 related publications according to the SCOPUS database, the last update was in November 2020, but some simulators have many extended versions with different names not included in these statistics. Nevertheless, ns-3 is an open-source project with a large community supporting it [106]. The ns-3 and LoRaSim modules have more publications in comparison with those of PhySimulator, CupCurbon, and FloRa. Therefore, some of the simulators provide more details on the installation process and the use of the equipment on their websites. All of them are open source, and GitHub provides their codes.

6. Opportunities and Future Research Directions

LoRa/LoRaWAN technologies have a bright future due to the growing adoption across industries worldwide. The technology, however, still has several constraints and limitations to overcome. As Section 4 introduced the various techniques to handle the issues of LoRaWAN deployments, the proposed approaches still need to improve the performance of LoRaWAN further. Depending on the previous analysis and investigations of research issues and recently proposed methods in Section 4 and Section 5, we emphasize some open challenges of the LoRaWAN technology in this section.

6.1. Scalability

Poor scalability can result in poor network performance. Presently, the majority of the information about the scalability of LoRa technology is commercial in nature and focuses on the best case scenario [107]. Thus, in order to properly analyze the performance levels of such networks in huge networks, it is necessary to have realistic models available. It is possible to achieve network scalability by reducing the amount of sent packets per node per day or increasing the number of gateways when the end device population expands rapidly, such as in dense installations. LoRa and LoRaWAN configuration parameters such as the SF, CF, transmission power, BW, CR, and DR directly affect the scalability of the network, which in turn impacts the generated traffic and energy resources [108]. Therefore, improving network scalability will optimize traffic, conserve energy, and extend the battery life of edge devices, which are three important goals [109]. This is because energy efficiency and data traffic are the total data transmissions from the sensor board to the gateway that have an effect on the performance [110]. Consequently, there is a real need to develop a new data-gathering procedure for LoRaWAN to cope with scalability issues in large-scale deployment scenarios [111,112]. That will positively affect energy conservation and play a significant role in improving LoRaWAN network scalability.

There are several metrics directly related to LoRaWAN network scalability. Thus, simulation-based performance evaluation for the proposed approaches needs to be conducted, depending on several scalability-related metrics such as energy consumption, PDR, throughput, coverage, and latency. Relying exclusively on simulations has long been recognized as one of the key pitfalls of research on wireless networks due to the typical oversimplifying assumptions of simulation models. Therefore, any simulation results for future improvements in LoRaWAN scalability need to and will be complemented with real experimentation for the proposed approaches using a LoRaWAN testbed for validation purposes. Most of the existing studies were conducted in a laboratory or limited outdoor areas. The results of the experiments, while proving that the proposed work was effective, are insufficient compared with real deployment environments. Therefore, it is necessary to further verify the reliability and scalability of the proposed work by deploying it in a real and large-scale environment. In [105], it outperformed the typical methods when the connectivity was good, but it functioned in a comparable manner when deployed over broad areas. The improvement over the benchmark solutions being independent of the channel model used was also demonstrated (no shadowing, uncorrelated, and correlated shadowing). A fog-based architecture was also demonstrated to be viable, which has the advantage of reducing the end-to-end latency by a factor of two. The limitation of this work is that the study was limited, and the proposed solutions were ordinary. The purpose of the research in [113] was to obtain better knowledge on how to optimize competition-based channel access mechanisms at the MAC layer for LoRa and LPWAN radio technology by conducting extensive tests on the LoRa channel activity detection and capture effect feature.

6.2. Regulation

The first opportunity and future work are more so action points for regulators rather than engineers. The big drawback of these networks is the hostile interference present in the unlicensed bands. Although LoRaWANs are envisioned with gateways at ground level, different proposals have suggested putting gateways in the air or even launching them into space [114,115,116]. Although it might be technically achievable, these networks will see many more devices due to the line of sight and see more collisions than there are gateways on the ground. For these scenarios and the LoRaWANs on the ground, it is strongly recommended to free up the spectrum for these networks, because there is a real need for these powerful networks as a good representative for LPWANs. The dedicated spectrum can also allow relaxed constraints for gateways such that gateways can transmit more downlink messages with a higher power, making the acknowledgements more reliable. Alternatively, with the spectrum freed up for these networks, improved spectrum management of unlicensed or shared bands is also an interesting route. With (private) spectrum management, different LPWANs, including SigFox and LoRa, can be rolled out in different or overlapping regions, allowing for other configurations and potentially sharing a spectrum. A third party could oversee the rules at several locations and verify if everybody is playing according to the rules.

6.3. Routing and Multi-Hop

Unfortunately, LoRaWAN, the current standard protocol for LoRa, supports only single-packet-at-a-time and single-hop transmission in a star-of-stars topology. LoRaWAN is a medium-access control protocol and does not provide any special support for the transmission of large messages. A star topology is simple and easy to manage. However, it limits the scalability of a LoRa wireless network. Although multiple gateways can be deployed to form multiple star topologies and extend the physical network range, a gateway in a LoRa network requires an Internet connection and has substantially higher cost and power consumption requirements than an end device. Multi-hop image transmission using LoRa is challenging. First, the performance of LoRa has rarely been studied in a wide range of applications, especially large message transmission. Without actual measurements, the feasibility of LoRa being used for large message transmission cannot be confirmed. Second, due to the small maximum transmission unit of LoRa, a large message such as an image must be transmitted using many packets. Such continuous traffic increases not only the network utilization but also the chance of packet collisions. Third, LoRa’s low physical layer data rate makes it difficult to broadcast additional data frequently enough to maintain the network topology while performing image transmission tasks, which may lead to serious network congestion or even paralysis. Since there is a huge number of routing protocols proposed in the literature for various ad hoc networking like MANET, VANET, WSN, and WMN. Thus, there is a real need for testing and adopting such protocols for LoRa/LoRaWAN networks to support the multi-hop state of packet transmission and, in addition, to enable communication in the node-node mode instead of node-gateway as in the existing architecture.

6.4. Energy Efficiency

In all wireless networks, energy-related constraints are considered the important factors that determine networks’ performance and characteristics because the nodes are battery-powered. Such constraints result in lower reliability of the communication medium and cause the loss of data during transmission from the end devices to the gateways and then the servers. Even though LPWAN technologies are low in power in comparison with other wireless networks, energy saving is among the key considerations to improve a LoRaWAN network’s performance. Most of the existing studies focused on Class A LoRaWAN devices, which are the most energy-efficient ones compared with the other classes. Therefore, more research needs to be conducted to evaluate the performance and energy efficiency of Class B and Class C devices. Additionally, scheduling algorithms and adaptive data rates that consider energy constraints are in high demand. Therefore, to maintain the nature of the low energy consumption of LoRa, it needs to be further studied to solve the energy issues caused by other factors. LoRaWAN no-battery communications are also feasible according to the results in [117] if the right configuration is chosen (i.e., the capacitor size and turn-on voltage threshold) for different application behaviors (e.g., transmission interval and UL and DL packet sizes (PSs)) as well as environmental conditions, (e.g., the energy harvesting rate). Only small-DL PSs should be considered for these devices because the DL in the second reception window significantly impacts performance. The authors in [118] presented a joint distributed queueing system for LoRa that balances inter-channel traffic. Compared with the DQ, the suggested technique decreases the control overhead by up to 70%. Regardless of the number of arrivals, the protocol achieves not only near-optimal throughput and access delay but also power efficiency.

6.5. Security

LoRaWAN needs to have the best data security system to stand out from other LPWAN technology market competitors. With raising awareness of user data privacy, data security-related issues have become a challenging element in all communication protocols. Some companies have developed a specific encrypted IC for LoRa devices to decrease the threats of data being decrypted by a third party. Simultaneously, LoRaWAN service providers have also built considerably safer links using IPSec and MQTTS technologies for protecting data transmission from gateways to network servers. Therefore, and due to data privacy issues, users will not be motivated to join the enterprise’s data flow ecosystem, and more data transmission providers will eschew large data servers like MQTT, CoAP, and LWM2M which appear in the market. The challenge will be in allowing such big companies to work individually under the LoRaWAN Alliance and maintaining data security and privacy. Activation by personal and over time air activation is a method of registering the end devices offered by LoRaWAN. ABP’s security method is sharing keys beforehand without them being sent on the network. The attacker is not able to decode the payload under this activation method. While OTAA uses an AES-128 key to encrypt and decrypt in the pre-shared AppKey, if an assailant tries to break the network encryption, they might be successful. Moreover, an attacker who is familiar with the protocol might be able to change the packet’s path to the desired destination due to unencrypted data. This issue needs more investigation and research into viable GITE solutions that can be produced. The gateway can collect routing from multiple nodes that could even be providing false data to disrupt the network. Thus, secure data transmission must be involved in LoRaWAN, analysis countermeasures, and different attacks. These topics need to be focused on in investigations.

Additionally, 5G security services have been deployed, installed, and tested in a real-world 5G-LoRaWAN testbed, demonstrating their feasibility and security viability [119]. This study aimed to enable handover roaming in LoRaWAN. The integration of LoRaWAN and 5G has been thoroughly examined, analyzed, and contrasted using two alternative methodologies. LoRaWAN joining procedures can be extended to enable the piggybacking of 5G security material to allow for roaming in LoRaWAN. The current LoRaWAN network does not need to be covered by 5G, but significant changes to the LoRaWAN and 5G specifications are required. Using 5G authentication services, the second solution has been chosen for deployment and validation because it adheres to nearly all standard procedures with just minor alterations. The LoRaWAN joining service and the 5G AUSF have successfully implemented this strategy with the necessary modifications for the IoT device (including in the 5G SIM card component) as outlined in [119].

7. Conclusions

At the cost of low data rates, LPWAN technologies supply long-range, low-power, and low-cost communication. In this paper, we discussed the common features LPWAN technologies employ, and their characteristics were tested in terms of various aspects, including bandwidth, modulation, data rate, range, link budget, maximum payload, power efficiency, security, adaptive data rate, localization, allowing private networks, battery lifetime, and availability. In addition, we showed how to pick the technology suitable for the field of application. On the other hand, LoRa technology as an emerging trend for IoT applications was the main focus among the LPWAN technologies in this paper. Among LPWAN technologies, LoRaWAN offers several advantages, including an open standard, low power consumption, long-range transmission, built-in security, the possibility of private deployments, and GPS-free geolocation. In addition, duty cycle constraints and low data rate LoRaWAN networks are the advantages of real-time application in Class B. Therefore, the investigations of LoRaWAN issues obtained by deploying LoRaWAN networks are discussed carefully. Furthermore, we evaluated recent approach solutions and presented some possible methods. However, some still have open issues such as network management, optimization ADR, high-density LoRaWAN installations, and device interoperability that need to be addressed more for practical use.