Designing a Reliable and Low-Latency LoRaWAN Solution for Environmental Monitoring in Factories at Major Accident Risk

Abstract

In this article, we propose a reliable and low-latency Long Range Wide Area Network (LoRaWAN) solution for environmental monitoring in factories at major accident risk (FMAR). In particular, a low power wearable device for sensing the toxic inflammable gases inside an industrial plant is designed with the purpose of avoiding peculiar risks and unwanted accidents to occur. Moreover, the detected data have to be urgently and reliably delivered to remote server to trigger preventive immediate actions so as to improve the machine operation. In these settings, LoRaWAN has been identified as the most proper communications technology to the needs owing to the availability of off the shelf devices and software. Hence, we assess the technological limits of LoRaWAN in terms of latency and reliability and we propose a fully LoRaWAN compliant solution to overcome these limits. The proposed solution envisages coordinated end device (ED) transmissions through the use of Downlink Control Packets (DCPs). Experimental results validate the proposed method in terms of service requirements for the considered FMAR scenario.

1. Introduction

Safety can be defined as the state of being free from unacceptable risks which can potentially cause damages to humans, environment or properties [1]. Public safety is very important in industrial environments especially in high-risk fields such as oil and gas, chemical industry or nuclear reactor plants where any event or accident can lead to catastrophic consequences both for humans, i.e., the workers and/or those who are living in the surrounding areas, and for the environment. These kinds of scenarios are typically categorized as Factories at Major Accident Risk (FMAR). A mapping of the most frequent major accidents in this context has been produced in Italy in 2013 by the ISPRA (Istituto superiore per la protezione e la ricerca ambientale—High Institute for Environmental Protection and Research) [2] and they are mainly due to release of dangerous substances (liquid or gas), fires, and explosions. The possible causes are several, such as machinery or piping break up, watertight loss, tanks overfill, mistakes during the handling procedures, submission of material on already filled cans, blending of incompatible materials, valves break up, accidental falls or vehicle collisions, and, more generally, spillover of cisterns.

Activities of ensuring compliance with procedures to prevent major accidents are traditionally in charge of humans control, and, as such, they are naturally error prone. On the other hand, with the rapid development of the numerous innovations in manufacturing and in information and wireless communications technologies, we have assisted in the last years to the birth of the new Industry 4.0 era [3]. In this scenario, the Internet of Things (IoT) is a hot topic nowadays either from a research point of view and from an application perspective as well [4]. Needless to say, IoT may provide great support to safety in the considered FMAR scenario in which workers and machines operate in a shared environment and a great amount of heterogeneous information can be collected by sensors and automatically delivered to a Central Controller (CC) allowing a real time control of the whole activity chain (and, as a consequence, of the associated risks). More specifically, the most important sensing technologies in the considered application scenario are represented by sensors for detecting gases with the purpose of avoiding fires and explosions involving flammable gas leakages as well as for controlling the level of oxygen in the atmosphere. In particular, electrochemical and catalytic gas sensors were chosen in this work, whose main focus is the implementation of a reliable limited time delay transmission system using a LoRa radio channel to transmit dangerous gas concentration detected by the sensors. For this purpose, we refer to the wearable device embedding sensing and communications capabilities described in Section 3, which is under development within a collaboration between the University of Siena and INAIL (Istituto nazionale per l’assicurazione contro gli infortuni sul lavoro—Italian National Institute for Insurance against Accidents at Work). Regarding in particular the communication aspects, the considered IoT scenario is characterized by low power devices transmitting infrequent short bursts of data over a low power wide area network. Indeed, the devices cannot have any external power supply (i.e., they run on batteries and they are installed in areas where frequent batteries substitution cannot be always guaranteed). Accordingly, they are expected to be very power efficient. Moreover, most of the detected data are not critical and, as such, can be referred to as Regular Packets (RPs). However, in some cases, i.e., when the concentration of gases crosses a pre-defined threshold, the detected data have to be urgently and reliably delivered and, accordingly, they are referred to as Urgent Packets (UPs). In this setting, one of the most promising communications technologies is represented by the Long Range (LoRa) one, together with the associated LoRa Wide Area Network (LoRaWAN) protocol.

When designing a LoRa-based network infrastructure, the adoption of LoRaWAN provides several advantages with respect to other customized Media Access Control (MAC) protocols. First of all, there is a large availability of open source LoRaWAN servers which can be easily installed and employed to rapidly set-up LoRaWAN networks. As a matter of fact, most of the Gateways (GWs) currently available on the market support the LoRaWAN protocol. In terms of range and coverage, this technology provides a far longer range than Wireless Fidelity (WiFi) or Bluetooth connections [5], applicable for indoor as well as outdoor scenarios, especially in remote areas where the cellular networks have poor connections. Moreover, when setting up dense network infrastructures, upper layer protocols like MAC ones are developed in LoRaWAN with the aim of managing the whole network infrastructure as well as the coexistence of large quantity of end devices (EDs). Moreover, LoRaWAN provides several built-in features that can be very important for the scenario at hand such as: (i) security in the transmission by means of Advanced Encryption Standard (AES-128) end-to-end data encryption; (ii) Possibility of boosting the capacity through the use of multiple channels; (iii) Adaptive Data Rate (ADR) and power consumption by controlling the Spreading Factor (SF), the Bandwidth (BW) and the Coding Rate (CR).

Finally, LoRaWAN provides a number of different message types which allow to set up unconfirmed (UNCONF) or confirmed (CONF) data transmissions (by means of Acknowledgement (ACK)) and a downlink (DL) channel to send information back to ED as well as the Over-The-Air Authentication (OTAA), a procedure that simplifies the association of an ED to the network by means of Join request messages.

The rest of the paper is structured as follows. In Section 2, the state of the art of LoRa solutions for reliable communication and related works are presented. In Section 3, we introduce the sensing and communication parts describing the main sensor characteristics, power consumption analysis and server architecture. Then, the proposed approach is described in Section 4. The main experimental results and discussions are presented in Section 5. Finally, concluding remarks are given in Section 6.

2. State of the Art

Various works have investigated the reliability of LoRa networks. In [6], the authors investigate the problem of collision and propose two distinct mechanisms for collision free transmission, namely TDMA (Time-Division Multiple Access)-based and FDMA (Frequency Division Multiple Access)-based with an ultimate aim of increasing the reliability of the service. The first mechanism allows all clusters to transmit in sequence where up to six EDs belonging to the same cluster can transmit using different SFs in parallel whereas the latter allows all clusters to transmit in parallel, each cluster on its own frequency. However, within each cluster, all EDs transmit in sequence. The simulation results provide better performances than standard LoRaWAN in terms of Packet Delivery Rate (PDR) even if the number of EDs is high. Similarly in [7], a two-step lightweight scheduling is proposed to divide nodes into groups where similar transmission powers are used in each group to reduce the capture effect. The nodes are guided by the GW coarse-grained scheduling to use different SFs to enable simultaneous transmissions through the use of beacon signals at every pre-defined interval, thus reducing packet collisions. The validity of the proposed scheme is assessed using NS-2 simulations showing better performance than legacy LoRaWAN in terms of packet error ratio, throughput, and energy efficiency. However, inter-SF transmission is still a problem due to the loss of the orthogonality between the two signals [8,9]. Since the ALOHA mechanism of the LoRaWAN drastically decreases the performance because of the non-negligible on-air collision probabilities, some authors in literature have proposed the synchronization of LoRa networks by assigning slots to each node using fine-grained scheduling [10].

In order to overcome the problems of classical ALOHA in LoRaWAN, Zorbas et al. [11] propose a time-slotted mechanism where data are buffered locally and transmitted whenever a GW is available by avoiding bursts of collisions. Similarly, in [12] a Time Slotted (TS)-LoRa that allows the nodes to organize autonomously and determine their slot positions in a frame is proposed. This is achieved by sharing an easy-to-compute hash algorithm between the network server and the nodes able to map the nodes’ addresses that are assigned during the join phase into unique slot numbers. Moreover, this mechanism ensures backward compatibility with legacy LoRaWAN nodes and liberates TS-LoRa from the huge schedule dissemination overhead. The last slot in each frame is used for sending synchronization ACK responsible for handling time synchronization and ACKs. The considered TS-LoRa achieves a very high packet delivery ratio for all the tested SFs.

The availability of CONF messages is one of the important features in the LoRaWAN networks that is not available in some of its competing low power technologies like Sigfox, Bluetooth Low Energy (BLE) etc. This feature can be used in those scenarios where data reliability is concerned. However, very few works in literature have investigated the CONF traffic, its effects and, more in general, the DL viability. Marais et al. [13] provides an analysis of use cases requiring CONF traffic and concludes that CONF traffic is viable in small networks, especially when data transfer is infrequent. Additionally, aspects likes duty-cycle regulations, SF12 for RX window 2, maximum re-transmission numbers and ACK_TIMEOUT transmission back-off interval negatively impact the viability of the CONF traffic. Similarly, Capuzzo et al. [14] conclude that the performance of a single LoRaWAN cell can significantly degrade when the fraction of nodes that require CONF traffic grows excessively. Moreover, they also suggest that it is necessary to carefully choose the maximum number of transmission attempts for CONF packets, based on the node density and traffic load to get the best performances. In addition, various works in the literature [15,16,17,18] investigate the applicability as well as criticism of DL in LoRaWAN networks and its possible negative impact on performances when not well implemented. To sum up, LoRaWAN technology has limitations that need to be carefully considered for its use in the considered FMAR scenario. In particular, one of the most critical issues is related to the use of the CONF mode to provide link reliability. Indeed, as discussed in [19], the use of ACK in DL can significantly drain the network capacity since GWs must be compliant with duty-cycle regulations. This problem is also studied in detail in [20] where the authors propose a solution called sub-band swapping where a first receiving window is opened on the dedicated downlink (DL) channel and a second one on the uplink (UL) channel to alleviate the duty cycle’s bottleneck. Another line of investigation deals with the use of ad-hoc control schemes which deviate from the standard LoRaWAN ACK mechanism [21,22].

One of the most closely paper to ours is [6], where collision free mechanism based on clustering of EDs is provided with the aim of increasing the reliability. The authors provide various optimized solutions by maximizing the number of EDs in a service area via maximum possible channel utilization. However, the considered test scenario is built with the aim of enabling massive IoT (mIoT) and it differs then from ours (FMAR) in the following aspects:

• The considered solution is more generally focused on a air pollution monitoring system where there is the requirement of sending RPs containing the measurement report at every pre-defined interval within a given time window (400 s–1600 s).
• The EDs should be perfectly synchronized with the GW in time so that the transmission times for the users are accurate. In this case, they have introduced some guard times which require major infrastructural modifications both at ED and GW level.
• It does not consider the FMAR scenario; especially the situations of UP delivery is not considered in their work: this aspect deals not only with the reliability but also with the stringent latency constrains.
• The EDs are assumed fixed.

In this paper, we propose a reliable and low-latency communications solution which is suitable for the considered FMAR scenario and that is fully LoRaWAN compliant. On the other hand, to the best of our knowledge all the previous works in the literature addressing the problem of reliability in LoRa deviate from LoRaWAN standard and, as such, would require a brand-new firmware update at both nodes’ and GW level. Conversely, the aim of the solution proposed in this work is to integrate the standard LoRaWAN configurations: this would make the implementation of this system almost straightforward since only minor modifications on the server side of the network infrastructure are required. As a matter of fact, the proposed solution may exploit already existing LoRaWAN networks and thus may be installed without any need for major infrastructural integration. Accordingly, this work proposes a fully operating experimental setup and the viability of the proposed scheme is demonstrated by means of a fully operating LoRaWAN network infrastructure whereas in all the referenced works the results could be achieved only by means of simulations. To sum up, this work does not require any modification in the current LoRaWAN protocol and is fully compliant with the current standard.

3. The Integrated Sensing and Communication Platform

3.1. Sensor Node Architecture

The sensor node was fully custom designed to fulfill the requirements of the application scenario and to comply with the constrains in terms of physical dimensions, measurement accuracy and energy consumption. Its architecture is reported in Figure 1 and it encompasses 3 gas sensors, two electrochemical amperometric gas sensors [23] and a catalytic gas sensor. The sensors used in this application, all manufactured by Alphasense, Braintree, UK, are the CO-A4 for the measurement of carbon monoxide concentration (CO) and the O2-A1 for the measurement of oxygen concentration (O₂), while the catalytic sensor, for the detection of potentially explosive atmospheres, is the CH-A3.

Electrochemical and catalytic gas sensors, as well as many other chemical sensors, behave linearly in the working range. The average response time (t90) for all the used sensors is less than than 15 s from producer specifications. From tests reported in Figure 2, Figure 3 and Figure 4 we verified the sensor responses. The response times, for the CO sensor tested from 0 ppm to 28 ppm of CO in air, for the O₂ sensor tested from 20.9% to 10% of O₂ in nitrogen and for the explosive gas sensor tested with steps of 0.2% of methane in air, do not exceed what expected and for all the tested sensors is in general around 10 s. This induces a time delay which is relatively small and aligned with commercial gas detecting systems performance. Considering the application scenario, for example a small room or an operator entering into a tank, the sensor response time is smaller than the time required to a gas to fill the room volume or the time an operator takes to enter into a tank. Hence, this aspect does not represent a critical issue for the developed architecture as it is actually a delayed or unreliable data transmission.

The digital part of the node is based on a low power ARM microcontroller from STMicroelectronics (STM32LQT5), that embeds 12 bits Analog to Digital Converters (ADCs) and Digital to Analog Converters (DACs) used to acquire signals from the sensors front end and to provide the correct biasing of electrochemical sensors. The microcontroller can save and read data from an Secure Digital (SD) card memory storage for logging purposes and to load sensors calibration parameters. The node sends data through the LoRa radio channel exploiting an RFM95 transceiver by HopeRF, interfaced through an SPI bus.

In Figure 5, the current absorption of the sensor node microcontroller and LoRa transceiver parts is shown. The measurement was taken during a sensors data acquisition phase followed by a 20 bytes LoRaWAN packet transmission using SF = 7. From this plot, it is possible to measure the maximum time delay from the sensor data acquisition phase end and the radio transmission start. The measurement was obtained by clocking the microntroller at 32 MHz, acquiring data from the ADC channels and processing them. The acquisition and processing time (few milliseconds) is negligible with respect to the LMIC stack packet elaboration, however, this time delay is below 50 ms.

The final prototype of the node with gas sensors is reported in Figure 6.

3.2. LoRaWAN Communication Platform: LoRa Node, GW and Server

In the following we provide a brief outline on the overall technology and the network architecture considered in this work.

LoRaWAN protocol is based on the LoRa transmission technology, a proprietary modulation patented by Semtech. LoRa operates in the unlicensed Sub-GHz (below 1 GHz) Industrial, Scientific and Medical (ISM) bands, with three operating frequencies: 433 MHz, 868 MHz and 915 MHz. It exploits the Chirp Spread Spectrum (CSS) modulation technique which allows to achieve extremely high receiver sensitivity values (up to −146 dBm): in these conditions, very long transmission ranges are obtained (up to some kms in urban areas and some tens of kms in rural areas) with limited power consumption. LoRa is then the ideal candidate for a plethora of wide area IoT applications, with a large number of connected devices. LoRaWAN networks adopt a star-of-stars topology, which enables multiple GWs to receive packets from a large quantity of EDs: GWs are in charge to transfer the packets to a central network server which manages the network aspects related to security, scalability and reliability. EDs are divided in 3 Classes (Class A, Class B and Class C) which differ for their ability to receive DL packets from the GW. Class A devices are the simplest and less power hungry ones and, as such, they are by far the most common ones. However, all the three ED typologies are bi-directional in operation. Every ED must be registered with a network before performing communication. These activation processes are of two types: (a) OTAA; the most secure and recommended for EDs and (b) Activation by Personalization (ABP); less secure and requires hardcoding the device address as well as the security keys in the device. Moreover, one of the important aspects of LoRaWAN is the use of frequency plan and its duty cycle regulations. More specifically, duty cycle indicates the fraction of time a resource is busy. As an example, when a ED transmits on a channel for 3 time units every 10 time units, the device has a duty cycle of 30%. As for the transmission frequencies, they are specified in the LoRaWAN regional parameters document [24]. Note that the words frequency and channel are used interchangeably throughout the paper. The duty cycle policy is often regulated by the government and it applies to an entire sub-band. This means that if a user transmits in one of the channels of a given sub-band, it cannot use any of the frequencies of the same sub-band for a time interval regulated by the duty cycle policy. Specifically, the duty cycle values for different sub-bands are regulated by the ETSI EN300.220 standard and are reported below [25].

• g (863.0—868.0 MHz): 1%
• g1 (868.0—868.6 MHz): 1%
• g2 (868.7—869.2 MHz): 0.1%
• g3 (869.4—869.65 MHz): 10%
• g4 (869.7—870.0 MHz): 1%

The above regulations apply to both EDs and GWs. In the followings, we briefly describe the main components of overall system.

3.2.1. RFM95 Radio Transceiver

RFM95 LoRa module is a radio transceiver manufactured by HopeRF [26]. It has a receiver sensitivity of −148 dBm and power amplifier of +20 dBm. Consequently, it has a maximum link budget of 168 dBm. It requires 3.3 V of voltage supply and draws a minimum RX current of 10.3 mA. The choice of this transceiver is due to its low cost and its low power consumption with a very good receiver sensitivity, suitable for the proposed application scnario.

3.2.2. LPS8 GW

LPS8 is an open source LoRaWAN GW [27] which acts as a bridge between the ED and the network infrastructure. It has a backhaul Internet connectivity that connects it to the remote network server. The LPS8 uses a Semtech packet forwarder, a software responsible for forwarding packets to the server and includes a SX1308 LoRa concentrator. It allows users to send data and reach extremely long ranges at low data-rates providing 10 parallel demodulation paths. The receiver has a sensitivity of up to −140 dBm with SX1257 Tx/Rx front-end.

3.2.3. Chirpstack LoRaWAN Server

We consider ChirpStack open-source LoRaWAN Network Server stack [28] for the server side. Chirpstack provides open-source components to form the network infrastructure. Any instance of each component can be installed locally or in a cloud platform to construct the overall network infrastructure. Moreover, this infrastructure provides a user-friendly web-interface for device management and Application Programming Interfaces (APIs) for integration.

It is also important to highlight that by default Chirpstack uses Message Queue Telemetry Transport (MQTT) protocol for publishing and receiving application payloads. MQTT is used by ChirpStack GW Bridge, ChirpStack Network Server, and ChirpStack Application Server. Figure 7 provides the overall network architecture including the sensor node/ED described in the previous subsection.

3.3. Communication Service Requirements

As discussed in detail in Section 1, in order to avoid fires and explosions in the presence of faults and gas leakages, it is necessary to promptly communicate to the CC any anomalous concentration of gases. In the considered system, this kind of data is referred to as UPs. Accordingly, UPs are characterized by stringent requirements in terms of reliability and latency. More specifically, in the scenario at hand we have identified as minimum requirements a packet loss rate (PLR) and end-to-end latency (l) of 0.1% and 500 ms, respectively. Moreover, basing on the required resolution of the data collected from the sensors, the UPs payload is set to 20 bytes. Basing on these requirements, we have limited our LoRaWAN system to use only SF7-10, since with SF11 and SF12 the time on air exceeds 500 ms [29]. Finally, packets retransmissions are not allowed for UP packets which, as such, can be transmitted in UNCONF mode only.

4. The Proposed Communication Strategy

In the following, we will focus on the approach proposed in this paper to provide the required reliability. To this aim, we exploit the DL communication scheme provided by standard LoRaWAN: DL packets are sent by a Network Server to only one ED through one or more GWs. To elaborate, in the proposed system a remote central LoRaWAN server shown in Figure 7 is capable of performing various tasks such as reception of data from the EDs forwarded by GWs, exploitation of the collected data with further processing, and more importantly scheduling of DL messages to the EDs for enabling coordinated transmissions. We describe each aspect in detail in the following subsections.

4.1. Clustering of EDs

In our system, the central server not only collects the sensor data from the EDs, but it is also responsible of forming clusters of users in close proximity. This task is achieved assuming that the system is equipped with a localization system where the server is aware of users’ locations. More specifically, the creation of clusters of users is performed with the aim of coordinating the transmissions of close users to avoid possible packets collisions. Indeed, it is highly probable that a critical event such as the presence of gas is jointly detected by all the EDs of the cluster.

The clustering algorithm and the specific localization technology to be adopted in the system are still under investigation and are beyond the scope of this paper. Figure 8 depicts the overall vision of the system where several GWs are installed inside the service area and the clusters of users are associated to the closest GW (represented by different colors). In the figure DCP stands for downlink control packets, which are regularly transmitted by GWs to the associated EDs as detailed in the next section. Note that ED-GWs association is fully in charge of the server and is only to provide a separated control mechanisms, i.e., it is completely transparent to the EDs which are actually connected to each GW as in standard LoRaWAN.

4.2. Coordination of ED Transmissions through Downlink Control Packets (DCPs)

We refer to the Class A DL operation in which the Network Server transmits a DL packet to an ED after the reception of an UP packet precisely at the beginning of one of two possible receiving windows. More precisely, the ED opens Class A RX1 and RX2 receiving windows after RECEIVE_DELAY1 and RECEIVE_DELAY2 secs respectively. The DL data rate for RX1 depends on the corresponding UL whereas RX2 uses a fixed data rate depending on the region.

In the considered scenario, each node transmits RPs periodically every predetermined (long) time intervals (e.g., several minutes) in UNCONF mode. We program the server in such a way that for every received RP a corresponding DCP is scheduled. Specifically, the DCP message is intended to control the eventual transmission of UPs. The adopted control mechanism, which is discussed in detail in the next section, acts independently on each cluster since it is highly unlikely that in the considered scenario EDs of different clusters have to transmit an UP at the same time (the potentially dangerous event is local and infrequent).

Hence, upon the necessity of delivering an UP to the system, the ED transmits according to the control information specified in the last received DCP. More specifically, we opted to choose the UNCONF mode also for UPs. The rationale for this choice will be given in the next section.

One of the important aspects that has to be taken into consideration while designing any LoRaWAN system is to comply with the duty cycle regulations as discussed in Section 3. This poses some stringent constrains in the process of allocating the resources to the EDs. Owing to the per sub-band duty cycle regulations, we have various possibilities to assign the resources to the EDs for the next UPs. In particular, one of the feasible choice is to differentiate the sub-bands for the two types of packets, i.e., allocating fixed non-overlapping sub-bands for the RPs and UPs. Indeed, this not only allow the isolation in terms of frequencies but also address the issue of duty cycling in the case when it is necessary to transmit an UP when the time elapsed form the last RP is lower than the minimum time established by duty cycling restrictions. In particular, the server assign different sub-bands for RPs and UPs so that duty cycling restrictions are independently established for the two kinds of transmissions. An illustrative example is given in Figure 9, where 5 EDs in close proximity, i.e., belonging to the same cluster, are allocated sub-band g (Channel (Ch0-4) with frequencies 867.1, 867.3, 867.5, 867.7, 867.9 MHz) and g1 (Channel (Ch5-7) with frequencies 868.1, 868.3, 868.5 MHz) for UPs and RPs respectively. To elaborate, each EDs transmit RPs by randomly selecting one of the available frequencies from g1 whereas the UPs are transmitted using different frequencies in sub-band g to avoid collisions. Such frequencies can be selected by each ED according to the last DCP received from the server which is in charge of isolating the UP transmissions of the same cluster. Considering 5 channels in sub-band g, it is worth noting that we can allocate a maximum of 5 different channels to 5 EDs in each cluster. However, we also have the possibility to accommodate more users in the cluster by assigning different SFs as shown in the next section.

4.3. The Problem of DL Priority

In standard LoRaWAN, the GWs work in half duplex mode only, i.e., they cannot receive and transmit simultaneously. Moreover, in commercial GWs, if there is the need to send a DL message, the reception of any incoming signal is interrupted, i.e., the concurrent UL packet is lost. Accordingly, the mechanism proposed in this paper for coordinating simultaneous UL UPs, which is based on periodic delivery of DCPs, could dramatically affect the PLR of UPs.

It is then of paramount importance to evaluate the PLR due to GW transmissions. To this aim, it is worth noting that the UL packet is lost by the concurrent DL transmission either when the DL packet is ongoing at the UL packet arrival time, or if it is started during the reception of the UL packet, since the GW gives priority to transmission anyway. Accordingly, denoting by $\tau$ and D the durations of a DCP and of an UP, respectively, the PLR of UPs is equal to the probability that at least one DCP is generated in the interval $\Delta =\tau +D$. To elaborate, in the considered setting DCPs are created as a response of RPs transmitted in the UL by each node. Accordingly, the DCPs arrival process statistics is equivalent to that of RPs generation process. Let then denote by T the rescheduling period set by each ED. Owing to inevitable clock drifts, the actual rescheduling time can be modeled as a random variable (rv) $r=T+\delta$, where $\delta$ is the clock error.

In the considered scenario we deal with internal clocks which are natively embedded inside the ED microcontroller. This choice allows to save cost, energy, and complexity with respect to external clocks. In this case, it is shown in [30] that the clock errors are unbiased and that they can be reasonably modeled as independent and identically distributed (IID) Gaussian rvs, i.e., $\delta ~\mathcal{N}(0,\sigma )$. Accordingly, also the interarrival times r are IID rvs, i.e., the arrival process of DCPs belong to the class of renewal processes [31]. More specifically, we have $r~\mathcal{N}(T,\sigma )$.

From the theory of renewal processes, it is possible to evaluate the time asymptotic density $w\left(x\right)$ for the the time elapsed from a generic time till the next arrival, i.e.,

$$\begin{array}{c}w\left(x\right)=\frac{1}{T}\left(1-F_r\left(x\right)\right)\end{array}$$

(1)

where $F_r\left(x\right)$ is the cdf of r. In the following, we are interested in evaluating the probability that an UP does not experience any collision with DCPs. To this aim, it is reasonable to assume that different nodes are characterized by independent clocks and independent time delays, and, hence, the probability $P_C$ that the an UP does not experience any collision can be evaluated as the product of individual probabilities of all independent events. To elaborate, let us denote by N the number of EDs and by $\tau =\left\{{\tau }_1,{\tau }_2,\dots ,{\tau }_N\right\}$ the DCP time duration of each node. Such terms depends on the SF used by the correspondent nodes to transmit DCPs, i.e., the higher SF the longer $\tau$. Since the adopted SFs in the UL depend on the channel conditions of each ED, e.g., the distance from the GW, it is reasonable to consider $\tau$ as a set of i.i.d. rvs with individual pdf $f_{\tau }\left(t\right)$. Similarly, also D depends on the SF adopted by the ED to transmit an UP and, hence, it can be characterized by a given pdf $f_D\left(y\right)$.

Accordingly, the probability $P_C$ that the an UP does not experience any collision with DCPs for given $\tau =\left\{{\tau }_1,{\tau }_2,\dots ,{\tau }_N\right\}$ and D is:

$$\begin{array}{c}{\displaystyle P_C\left(\tau ,D\right)=\prod _{n=1}^N\left(1-\frac{1}{T}\underset{0}{\overset{{\tau }_n+D}{\int }}\left(1-F_r\left(x\right)\right)dx\right)}\end{array}$$

(2)

and the marginal probability is:

$$\begin{array}{c}{P}_C={\left[{\displaystyle \underset{t}{\int }\underset{y}{\int }\left(1-\frac{1}{T}\underset{0}{\overset{t+y}{\int }}\left(1-F_r\left(x\right)\right)dx\right)f_{\tau }\left(t\right)f_D\left(y\right)dtdy}\right]}^N\end{array}$$

(3)

with $PLR=1-P_C$.

In the interesting case where $PLR\ll 1$, the expression in (3) can be manipulated to get an easy to understand approximation of the PLR. To elaborate, when $T\gg \tau +D$ (i.e., small PLR), we have $1-F_r\left(x\right)\approx 1$ thus yielding:

$$\begin{array}{c}{P}_C\approx {\left(1-\frac{\mathbb{E}\left(\tau \right)+\mathbb{E}\left(D\right)}{T}\right)}^N\end{array}$$

(4)

$$\begin{array}{c}PLR\approx N\frac{\mathbb{E}\left(\tau \right)+\mathbb{E}\left(D\right)}{T}\end{array}$$

(5)

5. Experimental Results and Discussion

In the following we describe the experimental testbed to assess the possibility of achieving the required service requirements using the proposed LoRaWAN solution based on DL control and clustering.

5.1. Test Scenario

We consider an indoor testbed at the premises of the Department of Information Engineering and Mathematical Science (DIISM) of the University of Siena. The environment is made of several rooms at the same level and includes the presence of machinery and obstacles, movements of objects and people. In this setting, we deployed several EDs and GWs inside the building for different test scenarios. In particular, we have conducted a preliminary set of tests to evaluate the PLR in the presence of a single ED transmitting in UNCONF mode. In this case, we have verified that the PLR is always well below the required limit of 0.1% even in the SF7 case. These results are in line with the LoRa coverage expectations and are not reported here for the sake of brevity. Hence, we focus on the results obtained in three different experimental setup characterized by the presence of possible collisions and of concurrent DL transmissions. In all the reported results, we consider only the PLR of UP packets, since RPs are not critical in the considered scenario. We report the parameter settings for the three different scenarios in

Table 1. Parameter settings for experimental tests.

Test	${\mathit{N}}_{\mathbf{ED}}$	${\mathit{N}}_{\mathbf{GW}}$	${\mathit{N}}_{\mathbf{UP}}$	$\mathbf{\Delta }{\mathit{t}}_{\mathbf{RP}}$	$\mathbf{\Delta }{\mathit{t}}_{\mathbf{UP}}$
1	2	1	20,000	70 s	Random (120–130 s)
2	8	1	20,000	70 s	Random (120–130 s)
3	8	2	20,000	70 s	Random (120–130 s)

where $N_{ED}$, $N_{GW}$, $N_{UP}$, $\Delta t_{RP}$, and $\Delta t_{UP}$ denote the number of EDs, GW, and UPs, and the RPs and UPs inter-packet arrival times, respectively. In order to achieve consistent statistics and reduce the experimental time, we have kept the RPs inter-packet arrival times to relatively low values. Moreover, the UPs are generated by forcing the triggering of gas sensors at random intervals. In the following, we report the description of each scenario, rationale for performing the particular test, the results obtained and the corresponding discussion.

5.2. Test 1: Analysis of PLR in the Presence of Collisions

In the first set of experiments, as reported in Table 1, we deployed two EDs, namely ED1 and ED2 nearly close to each other at distance of approximately 20 m from the GW. Both nodes asynchronously transmit RPs every 70 s using Ch5. In addition, both nodes are triggered to transmit synchronously the UPs at random intervals using Ch0. The SFs adopted for transmitting the UPs are set according to the DCP commands. In this case, we force the users to transmit at the same time using the same channel to assess the possibility of isolating the two transmissions in the SF domain.

We summarize the results in

Table 2. Analysis of PLR between SF7 and SF8.

Node	SF	PLR (%)
ED1	7	94.3
ED2	7	35
Both	7	29.66
Node	SF	PLR (%)
ED1	7	4.7
ED2	8	3.23
Both	7 and 8	0.12

,

Table 3. Analysis of PLR between SF8 and SF9.

Node	SF	PLR (%)
ED1	8	17.96
ED2	8	84.88
Both	8	3.46
Node	SF	PLR (%)
ED1	8	32
ED2	9	0

and

Table 4. Analysis of PLR between SF9 and SF10.

Node	SF	PLR (%)
ED1	9	5.18
ED2	10	0

where we report the PLRs for different cases. We neglect the PLR due to DL transmissions discussed in Section 4.3 and which will be separately assessed in Test 2. As expected, the results reveal significant packet losses when transmitting with the same SF. On the other hand, in the case of different SFs, the node transmitting with higher SF has a much lower PLR. i.e., it is able to often capture the packet even in the presence of interference owing to quasi inter-SF orthogonality. Nevertheless, in the SF7-8 case there is a residual probability (slightly higher than the constraint of 0.1%) that the packet is lost by both EDs, while this probability goes to zero for the SF8-9 and SF9-10 cases. Since it is highly probable that concurrent UPs will report the same information to the server, e.g., a gas concentration is higher than the threshold, in many cases it could be sufficient to receive only one UP to prevent the accident. Under this hypothesis, the 0.1% constraint can be satisfied when a maximum of 3 nodes in a cluster are assigned the same frequency and different SFs, namely, SFs 8–10. Considering the 5 channels in sub-band g, a cluster can be composed of 15 EDs.

5.3. Test 2: Analysis of the PLR in the UL Due to DL

We have deployed 8 EDs where ED1-7 transmit asynchronous RPs every T = 70 s (with SF7) whereas ED8 is triggered to transmit also the UP at a random interval of 120–130 s with SF9. According to the notation used in (5) the considered scenario corresponds to N = 8, $\mathbb{E}\left(\tau \right)=72$ ms, $\mathbb{E}\left(D\right)=247$ ms, yielding a predicted PLR of 3.6%.

In the considered setting we force ED1-7 to use a random channel from sub-band g1 whereas ED8 is allowed to transmit using Ch0 from sub-band g.

Table 5. Analysis of PLR in UL due to DL transmission.

Node	SF	PLR (%)
ED8 (UPs)	9	3.66

reports a PLR of 3.66% which is indeed a very high value and is certainly unacceptable in our case. It is worth noting that this value almost perfectly matches the PLR predicted by (5).

A possible way for overcoming this problem is to duplicate each GW. More specifically, only one of the 2 GWs is configured to transmit the DCPs, so that the other is always free to receive UPs.

As a matter of fact, there are several papers that propose full-duplex or multi-cast GWs to overcome this problem. However, as discussed in Section 2, such feature is not present in off-the-shelf GW solutions.

5.4. Test 3: Analysis of Residual Loss with Two GWs

The final test is performed with considering the same scenario of Test 2 in the presence of an additional GW configured to receive only UP packets.

Table 6. Analysis of residual loss using double GW for ED8.

Test Set	SF	Number of Loss Packets
1	7	10
2	8	8

reports the total number of lost packets for ED8 for two different SFs. It is worth noting that in this case the residual PLR is by far less than 0.1% even for small SFs (7–8), which confirms that the double GW solution provides the required service levels in the considered scenario.It is also important to stress that the use of double GW is effective if and only if the proposed transmission scheme is adopted: this highlights the viability and importance of such scheme. In particular, the required service levels cannot be achieved just using two GWs.

5.5. Discussions

In

Table 7. Performance comparison with other works from the literature.

Paper/Scenario	Proposed Scheme (LoRaWAN Compliance)	Reliability (PDR)	Latency Constraint	Number of Nodes Simulated
[15]/General	Standard LoRaWAN MAC (✓)	0.6 (CONF) 0.8 (UNCONF)	Not discussed	100
[7]/General	New MAC protocol RS-LoRa (✗)	0.84	Not discussed	100
[6]/Air pollution monitoring (mIoT)	TDMA-based FDMA-based (✗)	≈1	Not available	<2000
Our/FMAR	Coordinated transmission through DCP (✓)	>0.999	<500 ms	15/cluster can be accommodated

we have summarized some of the performances of various schemes from the literature related to reliability of LoRaWAN networks. Even though there is a huge gap between these papers and ours, we did our best to compare the performance levels with the ones achieved in this work.

In particular, the achieved reliability values are reported with the corresponding number of nodes used in the simulations. As mentioned in Section 2, the closely paper to ours is [6] which provides significant results in terms of reliability with the accommodation of nearly 2000 users. However, this scheme doesn’t provide any specific solution to address the problem of urgent traffic delivery, i.e., the latency problem is not specifically addressed. As a matter of fact, the authors just speculate that the proposed solution can handle urgent traffic if the number of EDs is small without actually simulating this scenario. Moreover, the nodes are considered to be fixed so that it is possible to design a fixed frequency/time scheduling procedure in which all the nodes are perfectly synchronized with the GW, a situation which is not verified in the FMAR time varying scenario considered in our paper. Finally, the solution provided in [6,7] deviates from standard LoRaWAN and requires modification of the MAC layer. To sum up, the results obtained through our scheme not only validate the proposed algorithm but also provide important intuitions in enabling a real FMAR scenario where both reliability and latency requirements are very critical.

6. Conclusions

In this work, we have proposed a LoRaWAN compliant reliable and low-latency solution to fulfil the requirements of a FMAR scenario. To this aim, a low-cost and low-power wearable device was developed to detect the leakage of hazardous and flammable gases. The proposed approach allows to reliably transmit urgent data to the central server. This goal is achieved by leveraging the transmission of DL control messages aimed at avoiding collisions among concurrent transmissions. Finally, we validated the proposed approach with extensive experimental tests in an industrial-like scenario. Numerical results suggest that LoRaWAN can be exploited to obtain the required level of reliability in the considered scenario.