Keywords

1 The LPWAN Umbrella: A Snapshot of Common Features

The burgeoning Industry 4.0 paradigm, introduced in 2011 as a German government initiative to improve efficiency in the industry, aims at exchanging and collecting information along the whole life cycle of a product. This information is stored in a repository to create a virtual “digital twin” of the product itself. The digital twin can exploit the valuable information collected all along the product value chain to implement forecasting models, minimizing losses against unexpected events, thus improving the overall business process. Generally, the ensemble of both the physical and cyber components is referred to as a cyber-physical system (CPS). In particular, the operation phase is where Industry 4.0 meets the Internet of things (IoT), leading to Industrial IoT (IIoT).

For this reason, IIoT is considered an evolution rather than a revolution as for the consumer counterpart. Indeed, low-cost, low-power consumption, battery-powered wireless devices were already available, in the late 2000s, with the advent of the so-called wireless mesh network protocols. In particular, the availability of reliable IEEE802.15.4 radios paved the way to international standards devoted to process automation and utility networks, like the well-known IEC62591 (a.k.a. WirelessHART) and IEC62734 (a.k.a. ISA100.11a). On the other side, wireless in factory automation is still mainly based on customary solutions derived from consumer market technologies such as WiFi (IEEE802.11) and Bluetooth (IEEE802.15.1), due to stringent time constraints.

This consolidated scenario started to change recently, due to the widespread diffusion of protocols originally designed for the IoT and the smart things, that contaminated the industrial automation as well. New actors came into play, allowing for multi-km network coverage by mimicking the mobile systems approach. The term coined for addressing such technologies is low-power wide-area network (LPWAN). A survey, carried out by the ON World research firm in 2018 on IIoT topics [1], confirms the interest toward these technologies. In the survey, more than 100 industrial automation vendors, end-users, systems integrators, and service providers were contacted, and 19% of respondents affirmed they were planning the development of an LPWAN network.

It is worth stressing that the main design goals of LPWAN technologies are wide-coverage and low-power operation, resulting in low data rate (usually in the order of few kilobits per second) and high latency (usually in the order of seconds or minutes). Accordingly, LPWANs are well-suited for niche areas, including delay-tolerant machine-type communication (MTC), which typically emphasizes low-power consumption for low-cost devices. Such applications are addressed with the term massive MTC (or mMTC), in contrast to the critical MTC (or cMTC) applications [2], with the latter needing ultra-low latency and ultra-high reliability.

Although the LPWAN family includes several members with different characteristics, the most common features are: (a) large area coverage, (b) low-power consumption, (c) low-cost and, (d) scalability [3]. In Fig. 1, a generalized diagram of an LPWAN system is sketched. The network architecture mimics cellular networks; one or more base stations (BS) are the centers of a wireless star network (single-hop topology) and provide connectivity to backend servers using a backhaul network. As better explained in the following, this configuration allows to move most of the complexity in the cloud, where higher computational resources are available, and permits to reduce energy consumption (wireless routing is not required) and cost (due to the centralized network management).

Fig. 1
figure 1

A generic LPWAN network architecture

Full size image

1.1 Large Area Coverage

LPWANs are generally based on single-hop wireless links; consequently, wide coverage in possible hybrid indoor/outdoor scenarios must be ensured by means of very good receiver sensitivity. For this reason, excluding very few examples (notably, the solutions derived from mobile communications, as NB-IoT, and proprietary solutions, as Ingenu), most of LPWAN technologies operate in the license-free sub-GHz region of the spectrum. One of the advantages is that, compared to other license-free bands, both the attenuation and the multipath fading are lower. Additionally, the radio environment is generally less crowded, resulting in a reduced number of interferences.

The price to pay is the reduced available bandwidth, which limits the overall throughput. When possible, the limited number of physical channels is increased through virtual channels, exploiting some kind of message orthogonalization permitted by advanced digital modulation techniques. The good news is that when narrowband modulations are adopted, most of the noise and interferences can be filtered out, which greatly improves the power budget. The power budget is generally more than 150 dB (even though maximum transmitting power is necessarily reduced for limiting the energy consumption), thus allowing for multi-km links.

1.2 Low-Power Consumption

Smart things (i.e., IIoT end nodes) are typically battery-powered; thus, reasonably long lifetime (in the order of several years for many real-world applications) must be ensured by very-low-power consumption. The wireless mesh approach, underlying WirelessHART and ISA100.11a, is not a viable solution since wasting precious energy in overhearing to other devices and relaying their traffic is not tolerable. For this reason, borrowing the approach pursued in mobile networks, the preferred choice is a star topology. Additionally, the BS is generally connected to a wired infrastructure, and it can always be on, thus easily allowing for event-based node communications (since uplink is of main interest in most of the applications).

Another important knob for controlling energy consumption is the careful choice of the medium access control (MAC) strategy, which must be simple enough to require minimal computational resources (for reducing the cost) but must minimize the collisions as well. For all these reasons, based on the assumption that the nodes transmit sporadically, a common solution is the use of pure ALOHA, a distributed random access MAC protocol in which end devices transmit without performing any carrier sensing. Note that the radios are already equipped with carrier sensing capabilities, so the listen-before-talk (LBT) mechanism (as the carrier sense multiple access with collision avoidance–CSMA/CA–used in most of the short-range wireless networks) can be implemented as well. However, LBT is not effective in dense radio environments [4], thus discouraging its adoption.

An additional mechanism for reducing the consumption is duty cycle limitation, i.e., forcing quite periods among consecutive transmissions. Very often, such a constraint is mandatory to fulfill regional regulatory requirements related to license-free bands.

1.3 Low Cost

The (I)IoT idea is effective only if the cost per device is very low, in the order of a few USD, including the cost for connectivity. For this reason, LPWANs successfully compete with legacy licensed solutions, as the cellular-like communications. LPWAN networks permit new players to implement a cellular network, without the need of a subscription to a third-party provider. Accordingly, the backend infrastructure must be simple as well. The use of the Internet as the backbone, similarly to all the other IoT approaches, goes in the right direction. Another common approach is the use of transparent BSs (often named gateways), for which data coming from (and going to) the field via the wireless link are opaque. By this, their complexity is greatly reduced, and security-related operations for authentication and encryption are moved into the backend.

1.4 Scalability

As previously stated, target applications include mMTC; hence, one of the key requirements of all LPWANs is supporting a massive number of devices sending small chunks of data. Thus, network scalability is a challenge. The spectrum scarcity, as mentioned earlier, must be compensated by using different diversity techniques, including efficient modulations and some form of orthogonal multiplexing.

On one side, centralized backend, able to check the overall network status in real-time, helps in implementing an adaptive selection of channels and data rates. On the other, recall that most of the communications occur from the field toward the BS. Therefore, it is generally preferred to rely on simple distributed mechanisms, e.g., simple message retransmission or a random selection of channel and data rate.

2 Different LPWAN Flavors

Many different technologies are covered by the LPWAN umbrella, including both proprietary and standardized approaches. The solutions that attracted the highest interest are probably NB-IoT, SigFox, and LoRa/LoRaWAN. Some works exist that try to compare these technologies, all sharing similar design goals (e.g., as reported in [5]). In the following sections, basic characteristics of NB-IoT, SigFox, and LoRa are outlined, whereas LoRaWAN solution is discussed in detail in Sect. 3. Although NB-IoT seems to offer the best coverage, the most diffused LPWAN, well-accepted by both the academia and the industrial world, is LoRaWAN, for its flexible backend implementation and for permitting to manage very diverse applications.

2.1 NB-IoT

In the past, the 3rd Generation Partnership Project (3GPP) group proposed some amendments in mobile networks to encompass requirements of low-power and wide-area networking applications. MTC has been supported in Long-Term Evolution (LTE) since Release 10, in which the 3GPP defined a new profile, called CAT-0, which reduced system complexity offering a maximum data rate of 1 Mbps, but keeping the same 20 MHz maximum system bandwidth of regular services. In Release 13, two new categories, CAT-M1 and Narrowband IoT (NB-IoT), have been defined, which lowered the available bandwidth to 1.4 MHz and 200 kHz, respectively. NB-IoT communication coexists with LTE, operates in licensed frequency bands (e.g., 700, 800, and 900 MHz), and occupies a single resource block of regular LTE transmission.

In particular, NB-IoT specifications have been developed according to the following main design goals [6]:

  • enhanced indoor coverage, obtained by a maximum coupling loss (MCL, the metric chosen by the 3GPP to evaluate the radio coverage and defined as the ratio of the power at the transmitter to the sensitivity at the receiver) in the order of 164 dB,

  • support for a large number of low-demanding nodes per single BS. The goal was to manage smart metering applications, considering the estimated household density in London, where there are 1517 households per square km, and Tokyo, where there are 2316 households per square km. In both cases, the inter-cell distance is in the order of 1.7 km,

  • support for low-throughput nodes; indeed, the MCL of 164 dB, should ensure an end-user data rate of 160 bps for both the uplink and downlink exchanges,

  • support for low-complexity and low-cost implementation of devices, as required by typical IoT applications; in turn, better power efficiency is achieved, thus extending the lifetime of battery-powered devices,

  • capability of delivering exception reports in less than 10 s for at least 99% of the devices.

NB-IoT defines three different usages: stand-alone (reusing GSM frequencies bands), guard-band operation (leveraging on unused resource blocks within an LTE carrier’s guard band), and in-band operation (leveraging on resource blocks within an LTE carrier). The NB-IoT amendment can be considered as a new air interface tailored for simple devices that can be connected to a network operator/provider exploiting the well-established LTE infrastructure. It uses the single-carrier frequency division multiple access (FDMA) in the uplink and orthogonal FDMA (OFDMA) in the downlink, and the adopted modulation is the quadrature phase-shift keying (QPSK) [7]. The data rate is limited to 200 kbps for the downlink and 20 kbps for the uplink, with a maximum payload size of 1600-byte per message. Standardization of NB-IoT continued in Release 14 and 15 to include localization methods based on observed time difference of arrival, multicast services (e.g., for over-the-air update), as well as latency and power consumption reduction [8].

The NB-IoT protocol stack is split into two planes, the control and the user one. The access stratum (AS) layer occupies the level 2 of the stack, and it is in charge of transporting data over the wireless connection and managing radio resources. The data transportation is offered via the packet data convergence protocol (PDCP), which determines the 1600-byte payload limit, whereas the radio resource management provided by the radio resource control (RRC) protocol aims at minimizing signaling by suspending/resuming the operation of the user plane. Above AS, there is non-access stratum (NAS), which conveys non-radio signals exchanged among the user equipment (UE) and the core network. NAS handles authentication procedures, performs security controls, and manages mobility and bearer, while the routing is performed using Internet protocol (IP). The UEs access the medium according to the contention-based random access channel (RACH) procedure. First, a preamble is transmitted; if the transmission fails, the preamble is re-transmitted for a maximum number of retries, which depends on the desired coverage enhancement (CE) level; subsequently, the next CE level is adopted. Once the preamble is correctly received, the associated random access response is received by the UE. Finally, the contention resolution process is started by the transmission of a scheduled message, and it is concluded when the user equipment receives the associated contention resolution message.

2.2 SigFox

NB-IoT offers relatively high data rates, high-power BSs, and advanced features for routing and multicasting. On the opposite side, we find SigFox proprietary solution, which exploits so-called ultra-narrowband (UNB) communication. Although SigFox operates in unlicensed ISM bands (e.g., 868 MHz in Europe, 915 MHz in North America, and 433 MHz in Asia), its business model is similar to the one used by mobile operators. SigFox deploys its BSs equipped with proprietary software-defined radios (SDRs). An IP-based network is used to connect the BSs to the backend servers, representing Sigfox Cloud. End-users must integrate their applications with the SigFox Cloud, by means of the two available methods: the “Callback API” and the “REST API.” In particular, Callbacks are HTTP requests implementing one-way only notification messages, thus permitting to retrieve messages from the devices. On the other hand, the REST APIs implement bi-directional HTTP data flows used for administrating the behavior of the devices and implementing related services.

The SigFox protocol stack includes the radio-frequency layer, implementing the modulation scheme and providing services to the data link layer performing the medium access control and error detection. Finally, the users’ requirements and specifications are managed at the application layer. The adopted modulation is binary phase-shift keying (BPSK) with very limited bandwidth (100 Hz). When devices operate in the EU, the unlicensed region between 868.180 and 868.220 MHz is divided into 400 different channels (including 40 reserved). Unfortunately, the maximum throughput is 100 bps. This bandwidth choice has been dictated by the needs of minimizing the noise level (thus obtaining exceptional sensitivity), the end device cost, and the power consumption. End-device design cost is reduced since precise and stable oscillators are not required [9], thanks to processing carried out in the BSs, as better explained in the following.

Sigfox uses a random frequency and time division multiple access (RFTDMA) strategy to transmit frames. RFTDMA allows the nodes to access the medium randomly both in time and frequency, without performing any contention-based mechanisms. Although it can be related to the pure ALOHA protocol, it allows choosing the carrier frequencies from a well-defined continuous interval (let’s call it B), and not from a predefined discrete one. At the BS side, the SDR listens at the full available bandwidth B instead of recognizing the actual carrier used by the transmitting device. Thus, message preambles are continuously searched within the whole B band, and, once recognized, the whole message frames are demodulated/decoded. Such an access scheme, on the one hand, limits the power consumption but possibly introduces interference among active nodes, especially if other co-located wireless systems are in the field. For instance, in [9], it is reported that in order “to ensure a high level of performance (e.g., PER below 10%), the highest number of nodes which can communicate at the same time is approximately 100, if the number of available channels is 360. At the same time, with the increase in the number of sensors, an avalanche effect is triggered, which drastically lowers the performance level.”

A SigFox frame consists of a 4-byte preamble and a 2-byte frame synchronization field, followed by a 4-byte device identifier, up to a 12-byte payload, a variable length Hash code for authentication, and a 2-byte cyclic redundancy check (CRC) field for error detection.

Initially, uplink-only communication was supported, but later asymmetric bidirectional communications have been permitted. Subsequently, two-way communication has also been permitted, in which a downlink payload can be transferred after a node explicitly sets a request flag within an uplink. The communication is always started by nodes, thus minimizing the time spent in listening the medium. The maximum number of uplink messages is 140 messages per day, while the message payload length for each uplink is limited to 12 bytes, as previously stated. Moreover, up to four downlink messages per day with a maximum user payload of 8-byte are permitted (and obviously, acknowledgment of every uplink message is not supported).

Communications reliability is provided by retransmissions, featuring time and frequency diversity. Each end-device message is transmitted three times by default over different frequency channels. The SDR approach at the BS allows the simultaneous reception of messages in multiple channels so that transmission frequency is randomly chosen.

2.3 LoRa

The LoRa radio technology has been originally introduced (and patented) by Semtech. LoRa adopts chirp spread spectrum (CSS) modulation in order to code, with a single chirp frequency trajectory, SF (spreading factor) bits. Consequently, each transmitted symbol is SF bits long. The choice of CSS has been motivated by the very good correlation properties shown by chirp symbols; virtual channels and adaptive data rate strategy can thus be easily achieved by transmitting messages with different SF values. In detail, the chirp bandwidth BW is fixed (BW = 125, 250, or 500 kHz), while the chirp duration can be calculated as T C = 2SF∕BW. Accordingly, a higher SF means a lower data rate but a better noise immunity (thanks to additional processing gain). Forward error correction mechanism has been considered to increase robustness again noise and interference, but the price to pay is a reduced throughput; however, several coding rates (CR) can be specified in the range from CR = 4∕5 to CR = 4∕8.

3 The LoRaWAN Solution

A complete communication solution has been designed around the LoRa physical layer, which is known as LoRaWAN. Regarding the physical layer (i.e., the previously described LoRa), LoRaWAN specifications add other constraints that depend on the regional parameters. For instance, when operated in Europe, the allowed bandwidth is BW ∈ [125, 250] kHz and SF ∈ [7..12]. Accordingly, a single physical channel can host up to six quasi-orthogonal virtual links (one per SF value [10]). Unfortunately, due to the different symbol duration, the actual data rate ranges from about 300 bps to 11 kbps. The message payload has a maximum length in the range of 51-byte (at SF = 12) to 242-byte (at SF = 7).

3.1 The LoRaWAN Architecture

LoRaWAN specifications are drafted by the LoRa alliance, which includes the device manufacturers, end-users, and research institutions. In particular, LoRaWAN provides upper layers of the protocol stack above the radio, defining the data link layer, which leverages on the pure ALOHA medium access strategy (despite clear channel assessment is somehow permitted). Regarding the network level, the network topology is hybrid wireless and wired star-of-stars, consisting of multiple BSs (gateways) tunneling into/from a wired backhaul/backbone uplink and downlink messages. The main design goals are reduced complexity, thus lowering implementation and maintenance costs, on the wireless side. Target applications are based on uplink only, whereas downlink, despite being permitted, should be limited to increase efficient bandwidth utilization [11]. Concerning the gateways, it is interesting to note that each one executes a software (the so-called packet forwarder) to forward messages using an implementation-specific protocol. In particular, the gateway only tunnels LoRa frames, i.e., the data are opaque.

According to the previous description, each LoRaWAN comprises two tiers: one includes wireless connectivity to end devices, and the other is the backend. All the network management procedures are carried out in a centralized way in the backend. In more detail, the network reference model described in the LoRaWAN specifications consists of two or three different kinds of servers (depending on the specification release): network server (NS), application server (AS), and join server (JS), as shown in Fig. 2. Note that the implementation details are out of the scope of the specifications, while only the operations to be carried out are described.

Fig. 2
figure 2

LoRaWAN network reference model

Full size image

NS is the logical entity, implementing the center of the star topology. It is in charge of checking the frame format and authentication, and providing acknowledgments if required. Additionally, it manages the LoRaWAN data link protocol features, e.g., as data rate adaptation strategy. Once authenticated, NS forwards an incoming uplink to the appropriate AS and queues downlink from any AS to deliver the useful payload to the proper end-device. If a JS is present, Join-request and Join-accept messages (by which the affiliation procedure is carried out) are forwarded to the end-devices and to the JS by the NS, respectively. JS, introduced in the LoRaWAN Release 1.1, is in charge of managing the affiliation of end-devices in a secure (i.e., encrypted) way. Finally, since the application-level protocol is not described in the specifications, AS has to implement it for delivering data to the final user. A comprehensive evaluation of delays along the whole route from the end-device to the end-user is provided in [12]; the capability to access the same end-node data in multiple end-user locations is described in [13].

Roaming is supported as well; accordingly, three roles exist for an NS: serving NS (sNS), home NS (hNS), and forwarding NS (fNS). Only sNS controls the data link layer behavior of the end-device, while hNS is connected to the AS, and several additional fNS can be connected to other gateways. If sNS does not change, passive roaming is carried out. On the contrary, when handover roaming is enabled, the end-device is managed by the visited network, though user data are still forwarded to the original hNS. Specifications do not provide any details of the protocols to implement interfaces between fNS and gateway, and between hNS and AS. Only the communications among NSs and JS-NS interfaces are described. In the latter case, the HTTP protocol must be used, encoding the payloads using JSON objects. As a matter of fact, several different proprietary implementations may exist. Such an architecture makes it easy to decouple the owner of the infrastructure from the owner of the data, enabling new business scenarios.

3.2 Security

Both IoT and IIoT rely on the fundamental principles of “connectivity to all” and “connectivity with all”; as a consequence, security issues are the main concern. LoRaWAN specifications already include mechanisms for ensuring confidentiality, integrity, and availability (CIA) since the very first release [14]. A preliminary step performed by the manufacturer of the end-device, or by the operator in charge of the commissioning, requires to configure each node with the root keys that will be used for deriving actual enciphering keys and both the device and the network identifiers. This information is needed to proceed with the personalization and activation procedures, usually carried out before the affiliation. In particular, two different approaches exist for the activation, namely, over-the-air activation (OTAA) or activation by personalization (ABP).

The preferred OTAA procedure is a flexible and secure way of obtaining session keys from the backend servers. The node first transmits a join_request message, received by the NS and further processed with information coming from the JS (if any). The JS has been introduced in LoRaWAN v1.1 to allow a complete separation between network and application domains, each one leveraging a different key. Once the message is validated, a join_accept message is sent back as a confirmation. The enciphered payload of the join_accept is used by the end-device to derive the actual session keys from the root keys. The specifications require these keys to be device-related; thus, possible disclosure should affect only the compromised device without affecting the rest of the network. In the ABP procedure, the session keys can be preventively stored in the device by the manufacturer, which should pay attention to track and match a unique device identifier, as the DevEUI, with the keys themselves. On the other hand, if the device has not been preventively configured by the hardware manufacturer, it is responsibility of the end user application to manage and deploy these keys on the devices in the field. Nevertheless, in both cases, the session keys stored in the node must match the corresponding keys stored in the backend servers. Thus, the ABP operates with a reduced security level and should be considered only for preliminary/debugging activities.

In particular, according to LoRaWAN specifications, several session keys are defined and used. At the network level, they are used by NS for generating and checking the message integrity code (MIC) or to encipher the MAC commands. User data, on the contrary, are protected at the session-level using a session key used for de/en-ciphering the application payload. Resuming, confidentiality and integrity of MAC commands are carried at the network level, whereas user data confidentiality is implemented at the application level, as shown in Fig. 3. Obviously, security on the backend is mandatory as well, but implementation is left out to the implementer.

Fig. 3
figure 3

LoRaWAN security model

Full size image

4 LPWAN Exploitation for Industrial Applications

As already stated in Sect. 1, the Industry 4.0 paradigm requires the interaction of devices and human operators in order to improve the overall process efficiency and automation processes. As a consequence, wireless communication systems are of main importance, thanks to their inherent scalability and non-invasiveness. In this respect their introduction, LPWANs have been seen as promising technologies for those non-critical industrial applications requiring broad coverage but tolerating low bandwidth and delays. As a matter of fact, the LPWAN simplicity complemented by good energy efficiency is truly interesting for cost-effective IIoT deployments. Similarly, the robustness with respect to multipath and fading is appreciated in industrial environments. Not surprisingly, manufacturers started selling rubberized versions of LPWAN devices purposely designed for the harsh industrial domain.

Comparing the LPWAN architectures with the wireless fieldbuses, purposely designed for control process applications, as the IEC62591 (WirelessHART) or the IEC62734 (ISA100.11a), several similarities can be highlighted. WirelessHART defines a Network Manager logical entity that is in charge of managing the node behavior; the ISA100.11a specifications define a System Manager, performing the same functionality. It is evident that LPWAN backend servers, such as the LoRaWAN Network Server, can provide equivalent capabilities. However, LPWANs generally lack important features, notably a synchronization mechanism [15]. As a consequence, any time information provided at the backend level results in relatively poor accuracy.

4.1 From Pure ALOHA to Scheduled MAC Protocols

Wireless industrial communication systems generally leverage on guaranteed access strategies, in which nodes are granted access to the medium according to a predefined resource assignment to easily ensure network timeliness. This strategy is adopted in many popular polling- or time division multiple access (TDMA)-based protocols. For instance, the aforementioned WirelessHART and ISA100.11a both use time-slotted channel hopping (TSCH) strategy, which adds frequency diversity (i.e., the adoption of different communication channel on a slot basis), to improve interference immunity and perform simultaneous transmissions on multiple (orthogonal) channels. Indeed, industrial applications are generally based on a limited, fixed number of devices deployed at the beginning of the plant lifetime, so that scheduling can be effectively carried out. On the contrary, LPWANs have been designed having scalability in mind, with applications possibly including thousands, if not millions, of devices. For this reason, as previously highlighted, the most common approach is pure ALOHA, which is prone to message collisions but does not require any a priori knowledge, thus minimizing implementation complexity.

Unfortunately, the performance of pure ALOHA is quite poor in crowded environments; it is well-known that the maximum throughput is about 18% of a perfectly synchronized solution. For mitigating the efficiency losses, slotted ALOHA and TDMA mechanisms have been overlayed to the original LPWAN. In the slotted access, the time is divided into slots (having a fixed length according to the maximum message length), and the nodes can access the channel only at the beginning of a slot. In the TDMA scheme, a scheduler has to be implemented in the backend to assign transmission intervals (and transmission frequency/data rates) to end-devices, thus virtually avoiding collisions. In particular, the openness of the LoRaWAN standard makes it attractive for researchers, as confirmed by the several publications aimed at demonstrating the superior performance obtainable using slotted ALOHA or scheduled mechanisms (e.g., consider [16,17,18,19,20,21,22]). Since the transmission policy is changed only, full compatibility with the original specifications is generally guaranteed.

The primary hypothesis for both slotted ALOHA and TDMA approaches is a common sense of time shared by all the network nodes; for this reason, some synchronization mechanisms must be implemented in order to minimize the impact of local clock drift. The MAC layer in LoRaWAN (and generally speaking in all LPWANs) supports neither synchronization nor low-level timestamping and must be purposely added. Instead, the synchronized downlink is permitted only based on reference time dissemination using downlink beacon messages to identify a repeating superframe arrangement. In [22], the LoRaWAN end-device takes a local timestamp right before sending a synchronization request. Once the gateway receives this request, the corresponding timestamp in the GW (global) time reference is taken as well and retransmitted to the end-device in the following synchronization acknowledge message. Given such a pair of timestamps, the offset between the node (local) and the GW (global) clocks is estimated. By collecting several offsets estimation, it is possible to evaluate the clock skew to correctly identify borders of slots in the local time domain.

4.2 Extending the LPWAN Coverage

As stressed in previous sections, most LPWAN solutions adopt a single-hop architecture, which is a star topology where nodes are directly connected with one (or more) BSs, thus greatly simplifying the overall system and permitting centralized management. However, in crowded environments, this single-hop massive channel access may pose additional challenges in terms of offered quality of service (QoS), limiting the overall network reliability, scalability, and flexibility. Most of the issues come from the very channel access mechanism, which, as stated in the previous Sect. 4.1, is pure ALOHA.

However, once more complex but powerful schemes as TDMA are implemented (providing time synchronization), multi-hop topologies can be easily implemented [23,24,25]. The advantage is that lower transmission power is permitted, still ensuring large-area coverage, at the expanse of increased latency (that is not a strict requirement in most of LPWAN target applications). Many researchers worked on this approach, as confirmed by the available literature. It must be stressed that protocol stack complexity is greatly increased as well, so that many solutions try to balance the network performance preferring the star topology and moving into the multi-hop only if QoS is degrading. Indeed, in order to preserve the node lifetime (i.e., reducing the overall power consumption, largely using deep-sleep states), the following technologies are generally required:

  • network-wide time synchronization,

  • TDMA-like channel access, for avoiding collisions among relaying nodes,

  • adaptive transmission power levels,

  • simple, flexible, and scalable joining procedure,

  • energy-aware, adaptive, and resilient routing protocol.

It is interesting to note that the availability of two receive windows for downlink communications provided by the LoRaWAN solution paves the way for a relayer-based approach for transparently doubling the coverage in both uplink and downlink directions. In particular, in [26], it is suggested the exploitation of a so-called e-Node, which transparently forwards copies of any incoming uplink, leveraging on the deduplication mechanism natively implemented by NS. On the contrary, on the downlink, the message is forwarded in the second receiving window so that if the end-node is able to immediately receive the message in the first window, overhearing is avoided; otherwise, if direct link is not permitted due to the actual link budget, a second opportunity is naturally provided.

4.3 Limitations and Future Directions

Since LPWANs have been originally designed for applications tolerating low-data rate and sporadic communications, their usage can be easily extended to condition monitoring of industrial equipment, facilities, and environments. The recent research activity is mainly focused on overcoming limitations imposed by the simple but not-so-efficient MAC protocols, showing that performance comparable with standard solutions currently used in process control (e.g., WirelessHART and ISA100.11a [20]) can be obtained. On the contrary, there are no real advantages in managing cyclic communications with refresh time shorter than 1 second. LPWANs are the quick-and-dirty solution for filling the current gap in mMTC communications waiting for large deployments of 5G networks. It has to be considered that Rel-16 of 3GPP specifications is focused on IIoT-related enhancements, and several activities of the 3GPP are ongoing for supporting time-sensitive communication integration and deterministic applications [27]. However, the two approaches can coexist, and possible adoption of 4G/5G technologies as LPWANs backhaul/backbone has already been proposed [28].

5 LPWAN Simulations

Performance evaluation of any wireless technology is important to understand its suitability against key performance indicators laid by applications. It also plays a vital role in the design and optimization of the wireless links and the overall network performance. Usually, evaluation is required both from the link-level and the system-level perspective, often carried out by theoretical modeling, simulations, or empirical measurements. All these tools are employed, although independently, but often empirical measurements in simple scenarios are used as a benchmark to perform full-scale simulations and fine-tune analytical models. In LPWAN systems, designed to collect data from a massive number of devices, system-level performance of the protocols is imperative to metric their performance in terms of coverage, scalability, and reliability. Also, these technologies often provide various degrees-of-freedom in the selection of MAC/PHY layer parameters. Therefore, the design and optimization of the network performance require fine-tuning these parameters under dynamic interaction among the devices at the protocol level, which is only possible by extensive simulations.

In contrast to simulations, test-beds cannot scale due to cost and experimental repeatability issues. Additionally, mostly measurements (to find path loss, packet loss rate) are carried out with a limited number of devices communicating with the network at a time. However, the network behavior is different when many devices use the network simultaneously, and therein the interference becomes the primary source of packet loss and coverage reduction (outage) [29, 30]. In this case, the deployments are though helpful to predict the coverage boundaries, e.g., for SFs in LoRa, but they cannot help to analyze the network scalability. Meanwhile, the theoretical models usually study a limited aspect of the physical and medium access layer using assumptions, limitations, and abstractions that still need extensive validation through simulations. Moreover, MAC layer features and enhancements, such as new MAC design, adaptive data rate (ADR) scheme, power-control algorithms, SF allocation scheme, the mutual interaction between downlink and uplink traffic, and retransmission scheme, are difficult to model analytically and usually lag behind the simulation-based analysis.

Industrial applications demand timeliness and reliability, whereas the LPWAN technologies are not feasible for real-time monitoring unless low-scale deployment is of interest. Instead, it is suitable for smart-city applications, metering, and logistics (tracking). Despite the fact, there are many studies that show that the design of a MAC is feasible to support lazy-control and soft-realtime applications as discussed in Sect. 4.1. Although there is no extensive simulation framework for evaluating the industrial use cases and all these studies are concluded based on the limited test-beds, we summarize the simulation environments available in the literature that could be exploited to evaluate the full potential of these proposals.

In what follows, the discussion is focused on the available design and validation tools for LoRaWAN, which, as previously stated, is currently the most diffused example of LPWANs. Considered tools range from radio planning applications to link- and system-level simulation environments. In particular, their designs, abstractions, and details of implementation are briefly sketched out. In the end, we highlight the potential research directions, especially for designing a unified solution to evaluate the LoRa network performance. For details on test-beds- and theoretical-based studies, the reader can refer to [31].

5.1 Radio Planning Tools

Radio network planning, concerned with the topographic maps and a precise propagation modeling, is important for network planning and deployment to provide adequate coverage in the area of interest. A measurement-based analysis of coverage is performed in [32, 33], and a generalization on propagation models is achieved. However, it is vital to have a radio planning tool that takes into account the topographic information of the deployment area and, together with propagation models, provides coverage information rapidly. Two prominent radio planning tools are from CloudRF [34] and ATDI [35].

CloudRF is an online service for modeling radio propagation, with its core in open source tool SPLAT – a terrestrial RF path and terrain analysis tool. CloudRF supports LoRa with a low receiver threshold of −140 dBm with a dedicated sub-noise floor color schema. Also, it uses various propagation models (including but not limited to Irregular Terrain Model, Okumura-Hata, Cost231-Hata, Ericsson 999, ECC33, ITU-R P.525) suitable for the UHF spectrum. Incorporating high-resolution LIDAR data enables to plan in urban areas with a high degree of precision. For wide-area plots, there is 30 m terrain data worldwide, which includes clutter like buildings and vegetation.

ATDI provides a commercial radio coverage prediction and planning tool for LoRa that takes into account the urban buildup and building impact (shadowing, absorption) predictions for indoor device deployments.

5.2 Link-Level Simulations

The link-level simulations are crucial to analyze the performance of LoRa modulation, especially under the impact of self-interference. In [36], a link-layer simulator, known as PhySimulator, is designed to analyze the impact of self-interference in LoRa. PhySimulator investigates the performance of a reference device receiving a useful LoRa signal in the presence of interfering signals using the same or different SFs. Especially, it quantifies the signal-to-interference ratio (SIR) thresholds for which interference rejection of other LoRa signals does not work for all combinations of SFs. The simulator exposes the non-orthogonality of SFs; that is, it shows that the collisions between packets using different SFs can indeed cause packet loss [36]. On the other hand, a BER model for LoRa modulation in AWGN channels is proposed in [37], which is then further used in system-level simulations.

5.3 System-Level Simulations

System-level simulations (SLS) are usually performed to determine the overall network performance. SLS allows the system designers to evaluate the impact of various parameters such as node density or traffic loads, interaction between uplink and downlink traffic, macrodiversity, and medium access protocols on the system performance. Meanwhile, it allows the abstraction of many link-level details that would otherwise add time complexity. In LPWAN systems, it is infeasible to conduct a testbed-based scalability analysis, which is also reproducible, with a high density of devices. In this respect, many system-level results, covering different aspects of LoRaWAN system, are presented in the literature using custom-built simulators such as ns-3 compatible LoRaWAN module [37, 38], python-based [39], and OMNeT++-compatible [40]. In these simulators, various components and algorithms for link and medium access layers are implemented at different scales, while the generic components of a LoRaWAN-specific simulator can be outlined as follows:

  1. 1.

    Propagation model: takes into account the path loss model, Fading, and shadowing phenomenon.

  2. 2.

    Reception model: defines the packet success based on bit error rate (BER) curves or signal-to-noise ratio (SNR) and SIR thresholds.

  3. 3.

    Interference model: considers the effect of concurrent transmissions on a reference transmission. Specific to LoRa, capture effect plays an important role where both the time and power capture are relevant. In addition, both the co-SF and inter-SF spreading interference need to be considered.

  4. 4.

    Medium access layer: although ALOHA is a de facto medium access choice, slotted-ALOHA and LBT/CSMA are also appealing to enhance scalability as discussed in Sect. 4.1.

  5. 5.

    Uplink/downlink traffic: to transfer sensory information from the field devices to the gateway (i.e., uplink communication) is of primary interest in LoRaWAN, it also provides support for downlink for various functions, e.g., network management (handshaking, network joining, exchange of security keys), and adapting communication parameters.

In the following, we outline the three main flavors of system-level simulators for LoRaWAN.

5.3.1 LoRaSim

LoRaSim [39] is a python-based discrete-event simulator, which is designed to analyze the scalability of a LoRa network under periodic uplink only traffic. It supports the simulation of scenarios with multiple gateways and directional antenna; however, it does not support the downlink traffic. For uplink traffic, the devices can be configured to use any possible value of transmission parameters (SF, frequency channel, bandwidth, coding rate, and transmission power).

In LoRaSim, the successful reception of the uplink packets depends on the selected transmission parameters and multiple other factors, including distance-dependent path loss, fading, packet collisions, and receiver sensitivity of the devices. LoRaSim uses the long-distance path loss model and log-normal shadowing. The packet collision model in LoRaSim is based on two main assumptions: (a) two transmissions in orthogonal channels (i.e., transmissions at different frequency channels or different spreading factors) do not collide; (b) in non-orthogonal channels (i.e., using same channel and SF), a collision is marked when two packets overlap in time; however, the stronger of the two packets is still decoded successfully given that the SIR difference between the packets is more than 6 dB and at least 5 symbols in the preamble are detected. The collision model mainly considers the time- and power-capture effect of LoRa as experimentally characterized in [39]. A pseudocode of the packet collision model is given in Algorithm 1.

There are many simulators that are derived from LoRaSim including LoRaEnergySim [41], LoRaWANSim [42], and LoRaFREE [43]. LoRaEnergySim includes an energy consumption model missing from LoRaSim, while LoRaWANSim extends LoRaSim to extend support for ACKs and downlink reception. LoRaFREE incorporates the impact of imperfect orthogonality of spreading factors, and the duty cycle limitation at both the devices and the gateway. Moreover, LoRaFREE supports bidirectional communication by adding the downlink support and the retransmission strategy for confirmed uplink transmissions. It also provides energy consumption profiling.

Algorithm 1 Pseudocode for LoRaSim packet collision model

5.3.2 FLoRa

FLoRa [40], which stands for Framework for LoRa, is a simulation framework to perform end-to-end simulations of LoRaWAN networks, which includes the accurate modeling of the backhaul link to NS. FLoRa is based on the OMNeT++ network simulator and uses components of the INET framework. It allows the creation of a LoRa network using the modules as LoRa nodes, gateway(s), and a network server. Application logic can be created as an independent module, which is connected to the network server. The other salient features include (a) dynamic management/configuration of parameters using ADR [40]; (b) node-wide collection of energy consumption statistics, where the time and power collision model is the same as in Algorithm 1; and (c) support for multiple gateways.

5.3.3 ns-3 LoRaWAN Module

LoRaWAN module is implemented in ns-3 by multiple independent researchers, where ns-3 is a generic open-source network simulator. The two prominent ones are reported in [37] and [38], which support a packet collision model with co-SF and inter-SF interference and a LoRa network with multiple gateways. The ns-3 module in [37] supports both the confirmed uplink and the downlink traffic via a simple network server, while the module in [38], although originally lacked the downlink traffic as well as confirmed uplink traffic, now supports both.

In LoRaSim and the other simulators (except LoRaFREE) derived from it, the collision model assumed perfect orthogonality between SFs. However, the ns-3 modules consider the same channel transmissions over a different SF as interference. The main difference between the two is how the link-layer performance, i.e., collisions, is modeled. In [37], a BER model in additive white Gaussian noise (AWGN) channel is developed based on Matlab simulations. The BER model considers the interference from different SFs by calculating instant SNR values. On the contrary, in [38], the outage condition is based on the SIR, which is calculated for each spreading factor using the cumulative interference. Each interference power is weighted by the amount of overlap with the useful signal. A transmission is successful only if the SIR calculated independently for each spreading factor is above the minimum threshold. The underlying algorithm is given in Algorithm 2.

In ns-3, other than implementing standard ALOHA-based MAC, CSMA and p-CSMA schemes with LBT are implemented and evaluated in [44] and [45], respectively. Table 1 summarizes the salient features of the simulators reported in the literature.

Table 1 Salient features of the LoRaWAN system-level simulators (SLS)a
Full size table

5.4 Stress-Test Tools for Network Server

The simulators discussed earlier are mainly concerned with the testing of the LoRa PHY layer and LoRaWAN protocol. Therefore, the LoRa network up to the gateways is only being evaluated by SLS simulators. There are other unique tools that are designed to test the scalability of the network server (NS). In this respect, two tools that stand out are Mbed LoRaWAN Stack Simulator [46] and LoRahammer [47].

Algorithm 2 Pseudocode for ns-3 packet collision model

Mbed simulator provides a virtual environment to run LoRaWAN stack without a PHY layer. It uses a fake LoRa radio driver, yet allows to measure the performance of the NS functionality. To do this, the fake radio intercepts the packet (to get the encrypted packet and select data rate and frequency) whenever the LoRaWAN stack wants to drive the radio. The packet is delivered directly to NS, which cannot differentiate a fake radio from the real one. This approach includes two-way data, acknowledgments, and OTAA joins function. This notable infrastructure helps engineers develop, test, and deploy LoRaWAN devices.

LoRahammer is designed to perform stress testing of NS. In a large IoT network, NS must handle millions of messages per second. In order to test the NS design capability to handle these messages in a timely manner, LoRahammer simulates the behavior of traffic from a large infrastructure with massive devices.

Figure 4 shows a comparison of the Mbed LoRaWAN simulator and LoRahammer with respect to a real-life LoRaWAN network.

Fig. 4
figure 4

Working principle of Mbed simulator and LoRahammer for testing a Network Server (NS)

Full size image

5.5 Limitations and Future Directions

There is a lack of system-level simulation environments for LPWANsFootnote 1 except for LoRaWAN. The simulators for LoRa/LoRaWAN are growing rapidly with the adoption and maturity of the technology, but there is still a lack of a comprehensive framework that covers all important aspects to understand the potential of the technology fully; a few examples are:

  • All available simulators use simplified path-loss, fading, and shadowing, while it is required to build a system-level simulator on realistic propagation models with digital terrain models, clutter, and buildings.

  • Many scheduled-MAC protocols for industrial use cases and scenarios are proposed and tested in limited details, but a detailed system-level analysis is needed.

  • Mostly the simulation environments consider class-A devices; however there is a need for a simulation setup with heterogeneous device roles

  • There is no simulator which models the device mobility. LoRa is susceptible to mobility, which worsens the performance as it cannot cope with the network dynamics. Therefore, it is important to incorporate mobility models in the simulators.

Considering these requirements, there must be an effort to build a simulation framework, where the various inputs from the research community can be integrated (as a module) and tested in a unified fashion such that each new proposal could be compared fairly and squarely.

6 Conclusions

In this chapter, we presented an overview of emerging LPWAN technologies, and discussed their potential for industrial IoT, especially for delay-tolerant monitoring applications demanding wide-coverage and low-power operation of devices. We explained the basic properties and protocol stack functionalities of different LPWAN flavors, including NB-IoT, SigFox, and LoRa/LoRaWAN, and shifted our focus to LoRaWAN for its predominant position in the industry/research. We discussed the limitations of LoRaWAN medium access and indoor coverage and established directions for future works. In the end, we discussed the significance of performance analysis of LPWANs based on simulations and summarized available options to conduct simulations at different levels in a LoRa network, including radio planning, link-level and system-level simulations, and end-to-end stress testing of a LoRaWAN network.