Combined Use of LoRaWAN Medium Access Control Protocols for IoT Applications

Abstract

The low power wide area networks (LPWANs) based on the LoRaWAN standard are suitable for Internet of Things (IoT) applications that involve a large number of low-power devices distributed over large areas. The LoRaWAN standard imposes some limitations on end-device configuration, such as the medium access strategies to be adopted, which depend on the region in which the network operates. In particular, in Europe, according to the ETSI regulations, a LoRaWAN end-device can use either a pure ALOHA medium access control (MAC) protocol or a polite medium access technique based on Listen Before Talk (LBT) Adaptive Frequency Agility (AFA). The aim of this work is to investigate the combined use of the two MAC protocols in the same LoRaWAN network. In particular, the work presents a simulative assessment of a LoRaWAN network that combines the use of Pure ALOHA and LBT AFA in realistic scenarios, under different workloads, when they work in compliance with the ETSI regulations. The work provides quantitative information that can help the network designer choose which protocol is more suitable for achieving the desired performance.

1. Introduction

The Internet of Things (IoT) paradigm is spreading across several sectors, providing connectivity between people, smart sensors, computing devices, robots, digital machines, etc. [1,2,3,4]. In particular, IoT applications can be found in several domains, including smart cities and smart homes [5,6,7,8], smart monitoring [9,10,11,12], healthcare [13,14], and factory automation [15,16,17,18,19]. Since IoT scenarios are highly heterogeneous and the number of IoT applications [20,21] is steadily growing, the selection of wireless technologies capable of meeting their needs is wide, spanning low-power short-range technologies, such as RFID and Bluetooth Low Energy [22,23,24], high-power technologies, such as cellular networks [25], and some amendments to the IEEE 802.15.4 and IEEE 802.11 standards for Industrial IoT [26,27,28,29,30].

As a complement of the aforementioned technologies, low power wide area networks (LPWANs) offer connectivity solutions for IoT applications that require low throughput, low power consumption, and wide coverage range using low-cost devices [31]. A very popular LPWAN standard is the Long Range Wide Area Network (LoRaWAN) [32]. LoRaWAN works on top of Long Range (LoRa) modulation [33] and defines a system architecture and protocol standards that aim to satisfy multiple key IoT requirements, such as low cost, low power, mobility support and easy network reconfiguration [34,35].

According to the LoRaWAN regional parameters [36], different rules are defined for both the medium access strategy and the parameter configuration, depending on the region in which the LoRaWAN devices operate. In particular, in Europe, two different uncoordinated channel access strategies [37] can be adopted, i.e., based on Pure ALOHA or on a polite spectrum access technique involving a clear channel assessment (CCA) prior to transmission. In fact, the norms imposed by the European Telecommunications Standards Institute (ETSI) allow the usage of either a duty-cycle limitation or a transmission management based on Listen Before Talk (LBT) Adaptive Frequency Agility (AFA). As discussed in [37], Pure ALOHA and LBT AFA differ in multiple aspects. As Pure ALOHA does not use any CCA mechanism, it works in an energy-efficient way under low workloads, but it may suffer from a significant number of collisions under high network traffic. In contrast, by running the CCA before starting a transmission, LBT AFA can mitigate the message loss due to overlapping transmissions, at the expense of increasing the energy consumption.

Some works in the literature compared the medium access control (MAC) protocols supported by LoRaWAN [38,39]. However, to our knowledge, none of them evaluated the performance obtained by combining Pure ALOHA and LBT AFA on the same LoRaWAN network when they work in accordance with the ETSI regulations [40,41]. In contrast, this paper presents a performance assessment of a LoRaWAN network that combines the use of the two supported MAC protocols when they work in compliance with the ETSI regulations, with the aim of providing the network designer with useful information to choose the most suitable protocol to reach the desired performance metrics. The assessment is performed through simulations in realistic scenarios under different workload conditions.

The structure of this paper is the following. Section 2 recaps the relevant literature. Section 3 outlines the main features of LoRaWAN, while Section 4 presents the MAC protocols supported by LoRaWAN. Section 5 describes the envisaged network configuration scenarios, while Section 6 addresses the performance evaluation and discusses the results obtained. Finally, Section 7 concludes the paper and outlines further research threads.

2. Related Work

LPWANs are capable of connecting a large number of devices distributed in wide areas and, for this reason, represent a promising option to replace or complement traditional cellular and short-range wireless technologies [42,43,44]. Among LPWANs, the LoRaWAN standard is emerging thanks to its interesting features that offer wide communication ranges with a low-cost network infrastructure that includes low-power devices.

LoRaWAN supports single-hop LoRa-based transmissions. Consequently, LoRaWAN cannot, at the same time, achieve a wide coverage range and a relatively high bit rate by setting the LoRa modulation parameters. For this reason, several works propose novel medium access strategies and routing protocols for LoRa-based networks [45,46,47,48,49]. Among them, the proposals in [48,49] exploit the Software-Defined Networking (SDN) paradigm to implement priority-based traffic management mechanisms and load balancing algorithms [50,51,52,53].

Furthermore, LoRaWAN only supports random MAC protocols, and therefore cannot provide real-time flows with bounded delays. For this reason, several works in the literature deal with the proposal and evaluation of alternative MAC protocols to LoRaWAN ones. For example, the works in [54,55,56] propose centralized MAC protocols for LoRa-based networks that are capable of supporting real-time communications through a Time Division Multiple Access (TDMA) channel access method.

The previously described works introduce multiple extensions to the LoRaWAN standard and often build directly on the LoRa physical layer. As a result, they require custom software implementation on LoRaWAN commercial-off-the-shelf (COTS) devices.

LoRaWAN supports uncoordinated channel access strategies based on Pure ALOHA or LBT AFA. Several state-of-the-art works deal with simple random MAC protocols (similar to standard ones) for LoRaWAN, such as Slotted ALOHA [57,58] or other protocols based on LBT [59,60], providing comparisons [61].

The work in [38] summarizes the restrictions that the ETSI norms impose on some timing parameters and presents a comparative performance evaluation of Pure ALOHA and LBT AFA. The aim of [38] is to compare the packet-loss ratio obtained by each protocol through different simulations on the same network. Conversely, this work investigates the combined use of the two MAC protocols in the same LoRaWAN network, that is, in the simulation, some of the end-devices adopt Pure ALOHA and the others adopt LBT AFA. The aim here is to provide quantitative information on which protocol an end-device shall use to meet the requirements of its traffic flows. Furthermore, differently from the work in [38], here, we evaluate multiple performance metrics, i.e., the packet loss ratio, the packet discard ratio, the end-to-end delay, and the energy consumption ratio per transmission.

A performance evaluation of a LoRaWAN network in which both protocols, i.e., the Pure ALOHA and LBT, are adopted is addressed in [39,62]. However, none of them takes into account the limitations imposed by the ETSI norms defined in [40,41]. On the contrary, this paper addresses a performance assessment of a LoRaWAN network in which both the devices that use ALOHA-based and the devices that use LBT-based MAC protocols work in accordance with the ETSI norms. In particular, this paper discusses the results obtained through simulations in realistic scenarios under different workloads and provides useful information about the performance of the two MAC protocols. In this way, the network designer can choose the MAC protocol that is more suitable to achieve the desired performance.

3. LoRaWAN Background

LoRaWAN defines a system architecture to wirelessly connect battery-operated devices distributed over a large area. The LoRaWAN specification [32] also includes a protocol stack optimized to provide support for low-cost, mobile, and bidirectional communications for IoT applications.

The LoRaWAN topology, shown in Figure 1, consists of a star-of-stars that includes several LoRaWAN end-devices, some gateways (GWs), and a network server (NS).

Communication between the end-devices and the NS is bidirectional and goes through the GWs. In particular, the end-devices exchange messages with the GWs through single-hop LoRa transmissions, while each GW communicates with the NS via an IP connection. GWs relay messages from the end-devices to the NS (uplink) and vice versa (downlink). Note that a given uplink (UL) message is sent by an end-device to the NS through one or more GWs. Conversely, a downlink (DL) message is sent by the NS to a single end-device through only one GW.

LoRaWAN builds on LoRa [33], a spread spectrum modulation technique derived from Chirp Spread Spectrum (CSS) technology. The LoRa modulation allows the configuration of multiple parameters [63] that have an impact on communication performance in terms of bit rate, coverage, energy consumption, and robustness to interference or noise. The main LoRa parameters are the carrier frequency (CF), bandwidth (BW), spreading factor (SF), coding rate (CR), and transmission power (TP). In a LoRaWAN network, the time required by a message transmission using specific LoRa parameters is called the time on air (ToA) and is calculated through the Equation (1) provided in [64],

$$ToA=\frac{2^{SF}}{BW}\left[NP+4.25+SW+max\left(⌈\frac{8PL-4SF+28+16CRC-20IH}{4(SF-2DE)}⌉\left(\mathcal{X}+4\right),0\right)\right]$$

(1)

where

• NP: number of preamble symbols.
• SW: the length of the synchronization word.
• PL: the size of the physical payload in bytes.
• CRC: a Boolean flag relevant to the presence of the cyclic redundancy check (CRC).
• IH: a Boolean flag relevant to the presence of the physical header.
• DE: a Boolean flag relevant to the data rate optimization status.
• $\mathcal{X}$: the value of the $\mathcal{X}$ parameter in formula $CR=\frac{4}{4+\mathcal{X}}$.

LoRa parameters can assume multiple values based on the region in which the LoRaWAN devices operate, according to [36]. By configuring these parameters, it is possible to tune the bit rate, coverage, and energy consumption. For example, as discussed in [65,66], increasing SF expands coverage but reduces the bit rate by approximately half, thus almost doubling ToA and energy consumption.

According to [67,68] the SFs are quasi-orthogonal, and therefore, simultaneous transmissions that use different SFs on the same channel are not totally immune to each other. However, in case the signal-to-interference ratio (SIR) of the received messages exceeds the isolation threshold specified in [67], the messages can be correctly decoded.

The LoRaWAN Adaptive Data Rate (ADR) algorithm [69] allows the use of the highest possible bit rate to prolong the battery life of the end-device. In this way, each end-device can individually set its bit rate and TP. If ADR is enabled, the NS is in charge of managing the bit rate and TP of the end-devices using defined LoRaWAN MAC commands; otherwise, each end-device individually manages its bit rate and TP. Note that the mobile end-devices commonly disable the ADR mechanism, especially when the radio channel attenuation varies quickly, as the NS would not be able to efficiently handle the runtime configuration of their bit rate and TP.

In LoRaWAN, three different classes of end-devices, i.e., Class A, B and C, are defined.

Class A (All) end-devices enable bidirectional communications while maintaining low energy consumption. In particular, Class A end-devices strongly favor UL communications, which are based on the communication needs of the end-device, while the transmission of DL messages is allowed only after the end-device has successfully sent an UL message, following the scheme shown in Figure 2.

Once an UL transmission is completed, the end-device opens two receiving windows. The first window (RX1 in Figure 2) begins $RX\_Delay1$ seconds (+/−20 $\mathsf{\mu }$s) after the end of the UL transmission, while the second one (RX2) begins $RX\_Delay2$ seconds (+/−20 $\mathsf{\mu }$s) after the end of the UL transmission. The minimum duration of a receiving window is equal to the time required by the end-device’s radio transceiver to recognize the preamble of the DL message. When a preamble is detected during a receiving window, the receiver remains active until the DL message is demodulated. If an end-device correctly demodulates a DL message during RX1 and it is the destination of the DL message, RX2 will not start. Note that the NS can send DL messages to specific end-devices at the start of each receiving window. After UL transmission, the end-device can only send a new message after receiving a DL message (in RX1 or RX2) or once RX2 has expired. Class B (Beaconing) end-devices support bidirectional communications with scheduled receiving windows. In fact, in addition to the Class A receiving windows, Class B end-devices open extra receiving windows at scheduled times. To implement this operational mode, the GWs periodically send a beacon to synchronize the end-devices. This way, the NS knows when the end-devices are listening. Class B end-devices realize a trade-off between energy consumption and latency of DL communication.

Class C (Continuously listening) end-devices support bidirectional communications with maximal receiving windows. This class of end-devices provides almost permanently open receiving windows, except for when they are transmitting. Class C end-devices are typically mains powered, as they consume more energy than the Class A and Class B ones, and guarantee the lowest latency to DL communications.

Since all LoRaWAN COTS devices must support Class A features, this paper explores the use of Class A end-devices.

As shown in Figure 3, in a LoRaWAN network, the application payload is encapsulated in the FRMPayload field of a LoRaWAN frame (MACPayload in Figure 3). The MACPayload also contains a frame header (FHDR) and an optional FPort field. In turn, the physical payload consists of a single-octet MAC header (MHDR) followed by the MACPayload and ending with a 4-octet message integrity code (MIC).

Figure 3 shows below each field the corresponding length in bytes. The maximum lengths of the FRMPayload (N) and MACPayload fields (M) are region-specific [36]. Note that for the LoRaWAN data messages (i.e., the ones with an nonempty FRMPayload field), the FPort field is mandatory. As a result, an overhead of 12 bytes is introduced in each LoRaWAN data message.

4. LoRaWAN Medium Access Control Protocols

The LoRaWAN regional parameters document [36] describes several aspects of LoRaWAN communication, such as the permitted transmission management strategies and some details on the channel frequencies that can be used. The document also suggests to refer to the specific norms of the region in which the LoRaWAN end-devices operate to obtain authoritative information.

For instance, in Europe, operation in the 868 MHz region is regulated by the ETSI norms EN 300 220 [40,41], in the sub-bands specified in the ERC Recommendation 70-03. As far as the channel access strategy is concerned, the ETSI regulations allow the choice of using either a Pure ALOHA MAC protocol with duty-cycle limitation or a polite spectrum access based on LBT AFA. These uncoordinated MAC protocols cannot support real-time traffic, as they do not enforce predictability and do not provide any time or frequency reservation mechanism. Consequently, an end-to-end delay bound cannot be calculated exactly or stochastically [70,71,72,73].

4.1. Pure ALOHA

The Pure ALOHA MAC protocol is a random medium access strategy that allows an end-device to transmit at any time, i.e., whenever it has a message to be transmitted.

Each end-device using Pure ALOHA-based medium access strategies must comply with duty cycle constraints ($\mathcal{DC}$) and maximum transmission power, where $\mathcal{DC}$ is defined as the maximum percent of time per hour that an end-device can transmit in a sub-band. For example, with a $\mathcal{DC}$ equal to 5%, an end-device can transmit 180 s per hour.

Table 1. Duty-cycle limitations of the sub-bands of the EU863-870MHz ISM band that match the ERC Recommendation 70-03.

Sub-Band	Frequency Band (MHz)	Number of 125 kHz-Channels	${\mathcal{DC}}^{\mathit{max}}$	${\mathit{TxPow}}^{\mathit{max}}$ (dBm)
h1.4	868.00–868.60	3	1%	14
h1.5	868.70–869.20	2	0.1%	14
h1.6	869.40–869.65	1	10%	27
h1.7	869.70–870.00	1	1%	14

shows the duty cycle constraints (${\mathcal{DC}}^{max}$) and maximum transmission power ($TxPo{w}^{max}$) in the EU863-870MHz ISM band relevant to the sub-bands that match the ERC Recommendation 70-03.

Since the ETSI limitations apply to the sub-bands, in the case that a number of 125 kHz-channels higher than one is available for transmission in a given sub-band, the transmission times on these channels must be jointly considered.

The current LoRaWAN specification exclusively uses transmissions with limited duty cycle to conform to the ETSI regulation [36].

4.2. Polite Spectrum Access

A polite medium access requires that the end-devices listen to the channel to sense if it is busy or not by running a CCA before transmitting. In particular, if the mean signal level detected at the CCA interval (${\mathsf{\Delta }}_{CCA}$) is below the CCA threshold, the end-device will start to send the message; otherwise, applying the AFA technique, the end-device switches to another channel and restarts the CCA before trying to transmit.

If the transmitter detects that all channels are busy, the transmission is delayed for a deferral interval (${\mathsf{\Delta }}_{def}$), i.e., the backoff delay. In this way, message collisions are prevented. Note that an end-device is not allowed to try to access the same channel before a random time interval (longer than a specific value) expires.

Table 2. Timing parameters of polite medium access based on LBT AFA.

Parameter	Limit
${\mathsf{\Delta }}_{CCA}^{min}$	160 $\mathsf{\mu }$s
${\mathsf{\Delta }}_{def}^{min}$	CCA interval (${\mathsf{\Delta }}_{CCA}$)
${\psi }_{{\mathsf{\Delta }}_{def}}^{min}$	Declared by the manufacturer
${\mathsf{\Theta }}_{CCA\_tx}^{max}$	5 ms
$To{A}_{tx}^{max}$	1 s
${\mathsf{\Lambda }}_{tx}^{max}$	4 s
${\mathcal{DC}}_{200kHz}^{max}$	≈2.78%
${\mathcal{T}}_{OffTime}^{min}$	100 ms

[40] shows the restrictions that the ETSI regulations impose on the usage of the MAC protocol based on LBT AFA.

As shown in Table 2, the minimum CCA interval (${\mathsf{\Delta }}_{CCA}^{min}$) shall be 160 $\mathsf{\mu }$s. If the target channel is busy, ${\mathsf{\Delta }}_{def}$ shall be larger than or equal to a specific value, i.e., ${\mathsf{\Delta }}_{def}^{min}$ that corresponds to the CCA length. The minimum time between two consecutive deferral intervals, here called ${\psi }_{{\mathsf{\Delta }}_{def}}^{min}$, is declared by the manufacturer. Once the CCA is performed, the end-devices must start the message transmission within a value ${\mathsf{\Theta }}_{CCA\_tx}^{max}$ declared by the manufacturer, which is lower than or equal to 5 ms. A single transmission shall last less than or equal to a $To{A}_{tx}^{max}$, i.e., 1 s. The maximum duration of a sequence of messages, called a transmission dialogue, shall end within ${\mathsf{\Lambda }}_{tx}^{max}$. According to the ETSI regulations, this value is equal to 4 s. Moreover, after each message transmission, an end-device shall be silent for a time interval, here called ${\mathcal{T}}_{OffTime}^{min}$, higher than or equal to 100 ms.

Finally, each end-device is allowed to transmit up to 100 s per hour over a 200 kHz spectrum. As a result, the duty cycle per 200 kHz spectrum (${\mathcal{DC}}_{200\mathrm{k}\mathrm{H}\mathrm{z}}^{max}$) is equal to approximately 2.78%.

5. Network Configuration and Performance Metrics

In this paper, we investigate how to take advantage of using, on the same network, both the MAC protocols available for LoRaWAN when they work in accordance with the ETSI norms. In our model, a group of end-devices uses Pure ALOHA while the other group adopts LBT AFA. To combine the use of the two protocols, we envisaged two possible approaches. The first one does not impose any constraint on how the two protocols are configured, while in the second case, channel separation is adopted.

The first approach, here called the SHC (SHared Channels) scenario, involves a LoRaWAN network in which the end-devices that use Pure ALOHA and those that use LBT AFA work on the same channels. In the second approach, here called the SPC (SPlit Channels) scenario, the channels available for transmissions are split into two different sets. This way, in the same LoRaWAN network, the group of end-devices that use the Pure ALOHA MAC protocol exploits a set of channels, while the other group of end-devices runs LBT AFA on the other set of channels. In particular, for the SPC scenario, we consider two configurations of channels (here called Configuration A and Configuration B) that differ for the number of channels used by the two considered MAC protocols.

In the SHC scenario, all the end-devices operate on the same set of channels, as shown in

Table 3. SHC scenario—channel configuration.

MAC Protocol	Sub-Band	Channel Frequency (MHz)	${\mathcal{DC}}^{\mathit{max}}$
Pure ALOHA	h1.4	868.10	1%
		868.30
		868.50
	h1.5	868.80	0.1%
		869.10
	h1.6	869.525	10%
	h1.7	869.85	1%
LBT AFA	h1.4	868.10	≈2.78%
		868.30	≈2.78%
		868.50	≈2.78%
	h1.5	868.80	≈2.78%
		869.10	≈2.78%
	h1.6	869.525	≈2.78%
	h1.7	869.85	≈2.78%

.

From Table 3 it is possible to obtain the overall duty cycle of each end-device that uses Pure ALOHA or LBT AFA (i.e., 12.1% and about 19.46%, respectively) as the sum of the duty cycle values of each used channel.

Table 4. SPC scenario—Configuration A.

MAC Protocol	Sub-Band	Channel Frequency (MHz)	${\mathcal{DC}}^{\mathit{max}}$
Pure ALOHA	h1.4	868.10	1%
		868.30
		868.50
	h1.6	869.525	10%
LBT AFA	h1.5	868.80	≈2.78%
		869.10	≈2.78%
	h1.7	869.85	≈2.78%

and

Table 5. SPC scenario—Configuration B.

MAC Protocol	Sub-Band	Channel Frequency (MHz)	${\mathcal{DC}}^{\mathit{max}}$
Pure ALOHA	h1.4	868.10	1%
		868.30
	h1.6	869.525	10%
LBT AFA	h1.4	868.50	≈2.78%
	h1.5	868.80	≈2.78%
		869.10	≈2.78%
	h1.7	869.85	≈2.78%

show the channels used by the end-devices in the configurations A and B of the SPC scenario according to the MAC protocol used.

In particular, in Configuration A (shown in Table 4), each end-device that adopts Pure ALOHA operates on four channels and can achieve an overall duty cycle of 11%, while each end-device that uses LBT AFA works on three channels and can reach a duty cycle up to about 8.34%.

In Configuration B of the SPC scenario (shown in Table 5), the end-devices that use Pure ALOHA exploit three channels and can achieve an overall duty cycle of 11%, while those that adopt LBT AFA work on four channels and can reach a duty cycle of about 11.12%.

In this work, the above-mentioned scenarios and configurations are evaluated against the performance metrics that are defined in the following subsection.

Performance Metrics

The performance metrics used in this work to assess LoRaWAN are the packet loss ratio (PLR), the packet discard ratio (PDR), the end-to-end delay (e2eDelay), and the energy consumption ratio per transmission ($EC{R}^{tx}$).

The PLR represents the ratio between lost and transmitted messages, measured at the application layer and expressed as a percentage, according to Equation (2):

$$PLR=\left(\frac{{\mathcal{N}}_{LOSTmsg}}{{\mathcal{N}}_{TXmsg}}\right)*100=(1-\frac{{\mathcal{N}}_{RXmsg}}{{\mathcal{N}}_{TXmsg}})*100$$

(2)

where ${\mathcal{N}}_{TXmsg}$, ${\mathcal{N}}_{RXmsg}$, and ${\mathcal{N}}_{LOSTmsg}$ are the number of messages transmitted, correctly received, and lost, respectively, measured by each end-device. This parameter is assessed for both protocols under consideration.

The PDR represents the ratio of the number of messages discarded by the MAC layer after performing the maximum number of backoffs to the number of messages received by the MAC layer from the application layer, measured by each end-device and expressed as a percentage, according to Equation (3),

$$PDR=\left(\frac{{\mathcal{N}}_{DISCmsg}}{{\mathcal{N}}_{GENmsg}}\right)*100$$

(3)

where ${\mathcal{N}}_{GENmsg}$ and ${\mathcal{N}}_{DISCmsg}$ are the number of messages received from the application layer and discarded by the MAC layer after performing the maximum number of backoffs, respectively, measured by each end-device. Note that the PDR is meaningful only for the end-devices that use LBT AFA. In fact, for the end-devices that adopt Pure ALOHA, the PDR is always equal to zero, as all the messages are sent without performing any channel assessment or backoff algorithm.

The e2eDelay is the time interval between message generation at the source node ($T_{Gen}$) and reception at the destination node ($T_{RX}$), measured at the application level, calculated as in Equation (4):

$$e2eDelay=T_{RX}-T_{Gen}$$

(4)

In the simulated scenarios, the source node is an end-device, while the destination node is the NS. To evaluate the delay on the LoRa link only, we assume that the delay introduced by the communication between the GW and the NS is equal to 0.

Finally, $EC{R}^{tx}$ is defined as the ratio between the average energy consumed per transmission by an end-device that adopts LBT AFA ($EC{R}_{LBTAFA}^{tx}$) and the one consumed by an end-device that uses Pure ALOHA ($EC{R}_{PureALOHA}^{tx}$), expressed as a percentage, according to Equation (5),

$$EC{R}^{tx}=\left(\frac{EC{R}_{LBTAFA}^{tx}}{EC{R}_{PureALOHA}^{tx}}\right)\ast 100$$

(5)

The following section describes how the simulation was performed and discusses the results obtained in the aforementioned scenarios, using different configurations and under different workload conditions.

6. Performance Evaluation

Here, an assessment of a LoRaWAN network is presented in which end-devices that use Pure ALOHA and other ones that adopt LBT AFA operate in the same area. Evaluation is performed through simulations using the OMNeT++ simulation environment [74,75]. In particular, we use the Framework for LoRa (FLoRa) [76], which in turn adopts components of the Internet Networking (INET) framework [77] to simulate the main features of the LoRaWAN class A end-devices, the LoRa physical layer, and the wireless channel. We developed the LBT AFA medium access scheme from scratch.

The imperfect orthogonality of the LoRa SFs is implemented as suggested in [67]. Moreover, a duty cycle check function is performed by the end-devices before each message transmission to ensure that the ETSI limitations are met.

The assessment is performed in a scenario that refers to a realistic industrial use case and is similar to the one adopted in [78]. The simulated network includes 200 end-devices (e.g., sensors) distributed over a sensing area of 1000 m × 1000 m, an NS, and a GW. As discussed in Section 5, a group of end-devices uses Pure ALOHA while the other set of end-devices adopts LBT AFA.

The NS and the GW are positioned in the middle of the sensing area. Some end-devices are stationary, and the others are mobile. The stationary end-devices are distributed in the sensing area so that the number of end-devices that use the same SF is always the same for all SFs. The mobile end-devices traverse the sensing area with an average speed of 0.3 m/s following the ChiangMobility model as in [38,47,79].

In the simulations, the LoRa Path Loss Oulu model [76] provided by FLoRa and the parameters experimentally found in a suburban environment in the work [80] are adopted.

The application layers of the end-devices are not synchronized with each other. Consequently, multiple end-devices can generate messages or attempt to transmit at the same time and message collisions may occur, especially in the Pure ALOHA MAC protocol case.

Each end-device that uses the LBT AFA MAC protocol reacts to an unsuccessful transmission attempt, i.e., to the case in which a channel is sensed as busy, with the adoption of the AFA technique. As a result, the end-device switches to another channel and restarts the CCA before trying to send. If all the channels available for transmission are busy, the message transmission is delayed, i.e., the end-device waits for a backoff delay before retrying transmission. In particular, the end-devices use an exponential backoff algorithm, and the maximum number of backoffs before dropping a message, here called $LB{T}_{backoffs}^{max}$, is set to 5. In the simulated scenarios, for every transmission attempt, the end-devices that use LBT AFA perform a CCA of 160 $\mathsf{\mu }$s, i.e., the minimum CCA interval according to [40] (see Table 2).

We consider end-devices that generate and transmit messages with an application payload of 20 bytes, as in [78]. No retransmission mechanism is adopted.

For each scenario and channel configuration, we simulate three different message generation patterns, i.e., Case L, Case M and Case H, which correspond to low, medium, and high traffic loads, respectively. In particular, stationary and mobile end-devices generate messages following an exponential distribution (ED) that defines the time interval between the generation of two consecutive messages. The message generation patterns in the three cases are shown in

Table 6. Message generation patterns.

Type of End-Devices	Case L	Case M	Case H
Stationary	ED with mean 120 s	ED with mean 60 s	ED with mean 30 s
Mobile	ED with mean 60 s	ED with mean 30 s	ED with mean 15 s

.

To better assess the performance of the two MAC protocols, we reduce the DL communications by using unconfirmed messages and disabling the ADR mechanism in all the end-devices. This way, there are no message losses due to the GW switching from receiving to transmitting states to transmit acknowledgments or ADR commands. Furthermore, as discussed in Section 3, the ADR mechanism should be disabled on the mobile end-devices, as generally it is not able to efficiently handle the LoRa runtime configuration. In this case, each end-device must individually manage its LoRa parameters. For this reason, we implement a custom algorithm that runs on each end-device instead of the ADR algorithm. The custom algorithm works as follows. During the configuration phase, a test application runs on a mobile end-device. This end-device moves in the sensing area and calculates the parameters that guarantee a message delivery ratio higher than a configurable threshold (e.g., 96% in our simulations) at multiple points, which correspond to multiple distances from the GW. For example, in the simulations we evaluated distances from the GW in steps of 10 m (a configurable value in the simulator). Based on the findings of the algorithm described above, the network designer configures the mobile end-devices to switch their LoRa configuration according to the distance from the GW.

The simulation time is 43,200 s, i.e., 12 h, to gather a significant amount of data. Moreover, each simulation is repeated ten times, varying the seed for random number generation to obtain statistically significant results.

Table 7. Simulation parameters.

Parameter	Value
ADR	Disabled
Application payload	20 bytes
BW	125 kHz
CR	4/5
$LB{T}_{backoffs}^{max}$	5
Mobility pattern	ChiangMobility [81]
Propagation Model	LoRa Path Loss Oulu [80]
Simulation time	12 h
TP	14 dBm
${\mathsf{\Delta }}_{CCA}$	160 $\mathsf{\mu }$s

shows the simulation parameters.

In the following, we show and discuss the results of the evaluated scenarios.

In particular, Section 6.1 presents the evaluation of a LoRaWAN network with 100 end-devices that use Pure ALOHA and 100 end-devices that adopt LBT AFA. Among the end-devices, 50% are stationary, while the other 50% are mobile. In the assessment in Section 6.1, we consider both the scenarios discussed above (i.e., SHC and SPC) and the channel configurations (A and B) under different traffic loads.

The SHC scenario is the most challenging one, because the end-devices that use Pure ALOHA and those that use LBT AFA compete for the same channels. Furthermore, differently from the SPC scenario, the SHC one does not require to split in two different sets the channels that can be used by each of the two protocols, thus allowing the end-devices to use all the available channels. For this reason, both Section 6.2 and Section 6.3 focus on the performance of the two protocols in the SHC scenario. In particular, Section 6.2 evaluates a LoRaWAN network with an equal number of stationary and mobile end-devices with varying percentages of end-devices that use Pure ALOHA and LBT AFA, respectively. Section 6.3 instead evaluates a LoRaWAN network with an equal number of end-devices that use ALOHA and LBT AFA with varying percentages of stationary and mobile end-devices, respectively. Finally, Section 6.4 summarizes the results obtained.

6.1. Assessment in Different Scenarios and Channel Configurations

Table 8. Average PLR under different traffic conditions.

Scenario	MAC Protocol	Type of End-Devices	PLR-Case L	PLR-Case M	PLR-Case H
SHC	Pure ALOHA	Stationary	6.08%	10.50%	18.68%
		Mobile	5.49%	9.73%	18.07%
	LBT AFA	Stationary	5.09%	8.78%	16.14%
		Mobile	4.30%	7.38%	14.32%
SPC Configuration A	Pure ALOHA	Stationary	6.68%	10.27%	18.46%
		Mobile	5.69%	9.30%	18.25%
	LBT AFA	Stationary	3.88%	7.62%	15.93%
		Mobile	3.59%	6.60%	13.77%
SPC Configuration B	Pure ALOHA	Stationary	7.07%	11.70%	21.79%
		Mobile	6.62%	11.11%	21.34%
	LBT AFA	Stationary	3.31%	6.15%	12.92%
		Mobile	3.18%	5.29%	10.96%

shows the average PLR of both stationary and mobile end-devices in all scenarios and configurations evaluated.

As expected, the PLR values increase with the traffic load, and the highest PLR values are experienced in Case H.

Furthermore, the results in Table 8 show that in the simulated scenarios, the PLR values obtained by LBT AFA are better than those achieved by Pure ALOHA. In particular, the difference increases with the workload. In fact, when the channels are sensed as busy multiple times, LBT AFA reduces the PLR by leveraging the AFA technique and also the exponential backoff algorithm if all the available channels are sensed as busy, before retrying to transmit.

In the SPC scenario, the end-devices that use LBT AFA perform better in Configuration B than in Configuration A, because in Configuration B they use four channels, instead of three. The PLR values obtained in the SPC scenarios are lower than those relevant to the SHC scenario, in which the end-devices that use LBT AFA work on seven channels, because the SHC scenario does not split the set of available channels. Consequently, the end-devices that adopt the LBT AFA have to compete for the channel access also with the end-devices that use Pure ALOHA.

Table 8 shows that no significant differences were found in PLR values between stationary and mobile end-devices. The slightly lower average PLR of the mobile nodes is because most of them transit over an area covered by low SFs. As a result, their transmissions require a low ToA; therefore, their message collision probability is also low because it is less likely that other end-devices will be using the same channel during the transmission of the messages.

Table 9. Average PDR under different traffic conditions (LBT AFA only).

Scenario	MAC Protocol	Type of End-Devices	PDR-Case L	PDR-Case M	PDR-Case H
SHC	LBT AFA	Stationary	1.69%	4.44%	6.90%
		Mobile	1.61%	4.62%	6.97%
SPC	LBT AFA	Stationary	1.74%	4.41%	6.91%
Configuration A		Mobile	1.83%	4.37%	7.00%
SPC	LBT AFA	Stationary	1.33%	4.36%	6.95%
Configuration B		Mobile	1.35%	4.31%	6.93%

shows the average PDR measured by the end-devices that use LBT AFA.

The results in Table 9 show that in the evaluated scenarios, the end-devices that adopt the LBT AFA MAC protocol discard some messages after performing the maximum number of backoffs. In particular, the PDR increases under a high workload, as in this case, the channels are often sensed as busy, and therefore, both the AFA technique and the backoff algorithm are used multiple times. In some cases, a message transmission attempt reaches the maximum number of backoffs without succeeding, and the message is discarded. The PDR values can be reduced by increasing the $LB{T}_{backoffs}^{max}$ parameter at the expense of increasing the energy consumption.

Finally, the stationary and mobile end-devices obtain similar PDR values.

The average and maximum e2eDelays of the stationary and mobile end-devices obtained in all the scenarios and configurations evaluated are shown in

Table 10. Average and maximum e2eDelay under different traffic conditions.

Scenario	MAC Protocol	Type of End-Devices	Case L— e2eDelay (s) Avg//Max	Case M— e2eDelay (s) Avg//Max	Case H— e2eDelay (s) Avg//Max
SHC	Pure ALOHA	Stationary	0.39//2.95	0.40//3.28	0.41//5.31
		Mobile	0.28//2.95	0.31//3.91	0.35//6.01
	LBT AFA	Stationary	0.93//12.87	1.22//21.35	1.45//22.85
		Mobile	0.85//17.79	1.16//21.38	1.60//27.96
SPC Configuration A	Pure ALOHA	Stationary	0.39//2.97	0.40//3.79	0.41//4.92
		Mobile	0.31//4.65	0.30//4.22	0.36//5.47
	LBT AFA	Stationary	0.96//13.44	1.19//16.41	1.46//22.18
		Mobile	0.87//18.04	1.15//21.39	1.59//37.18
SPC Configuration B	Pure ALOHA	Stationary	0.39//2.97	0.40//3.23	0.41//5.08
		Mobile	0.26//2.83	0.29//3.99	0.36//4.98
	LBT AFA	Stationary	0.87//12.50	1.19//19.01	1.45//22.31
		Mobile	0.74//13.14	1.13//23.27	1.55//34.09

.

As shown in Table 10, the Pure ALOHA MAC protocol significantly outperforms LBT AFA in terms of average and maximum e2eDelay. This is because the end-devices that use Pure ALOHA can transmit at any time if they have messages to send. In fact, Pure ALOHA end-devices do not perform any channel assessment before transmitting and do not adopt a backoff algorithm, and therefore, they do not delay their message transmission.

As it was expected, the highest maximum e2eDelay values are experienced in Case H, i.e., when the end-devices generate the highest number of messages. In fact, in this case, for both the MAC protocols under consideration, multiple messages can be enqueued in the MAC layer queue, and therefore, the e2eDelay also includes the time spent by the message in the MAC layer queue waiting for being transmitted. Moreover, in Case H, the probability that the channels are found to be busy with LBT AFA is higher than in the other cases. As a result, sometimes, the end-devices reach the maximum allowed number of backoffs before a successful transmission, and therefore, they experience the highest maximum e2eDelay values.

Finally,

Table 11. Average $EC{R}^{tx}$ under different traffic conditions.

Scenario	${\mathit{ECR}}^{\mathit{tx}}$— Case L	${\mathit{ECR}}^{\mathit{tx}}$—Case M	${\mathit{ECR}}^{\mathit{tx}}$—Case H
SHC	0.038%	0.050%	0.058%
SPC Configuration A	0.029%	0.036%	0.042%
SPC Configuration B	0.027%	0.036%	0.042%

shows the energy-consumption ratio per transmission in all the scenarios assessed.

As expected, the energy consumption of the end-devices that use LBT AFA is higher than that of the end-devices that use Pure ALOHA, as LBT AFA involves one or more CCAs before transmission. Furthermore, the highest $EC{R}^{tx}$ values are obtained in Case H, i.e., under the highest workload. In fact, in this case, the end-devices that adopt LBT AFA run a higher number of CCAs due to multiple (unsuccessful) transmission attempts on busy channels.

As shown in Table 11, the $EC{R}^{tx}$ values obtained in the SHC scenario are higher than those obtained in the two configurations of the SPC scenario. This is because in the SHC scenario, LBT AFA can use all the available channels, and therefore, a higher number of CCAs can be run before performing a backoff. However, the end-devices that use Pure ALOHA and those that use LBT AFA compete for the same channels. Consequently, the channels are sensed as busy multiple times, and therefore, the higher number of CCAs implies a higher energy consumption.

6.2. Impact of the Percentage of End-Devices That Use Pure ALOHA and LBT AFA

Figure 4, Figure 5 and Figure 6 show the impact on PLR of the percentage of end-devices that use Pure ALOHA and LBT AFA in the SHC scenario under different traffic conditions (i.e., Case L, M and H). In this evaluation, the number of stationary and mobile end-devices is the same (i.e., 100).

From Figure 4, Figure 5 and Figure 6, it can be seen that in all cases, the PLR increases with the number of end-devices that use Pure ALOHA. This is because with Pure ALOHA, a high number of collisions occurs, as end-devices transmit without performing any CCA. The graphs in Figure 4, Figure 5 and Figure 6 show similar trends. As the PLR values increase with traffic load, the maximum values are obtained in case H.

Table 12. Average e2eDelay with varying percentages of end-devices that use Pure ALOHA and LBT AFA.

MAC Protocol	Type of End-Devices	Case L— Avg e2eDelay (s)	Case M— Avg e2eDelay (s)	Case H— Avg e2eDelay (s)
Pure ALOHA	Stationary	0.39	0.40	0.41
20%	Mobile	0.24	0.31	0.35
LBT AFA	Stationary	1.23	1.78	2.13
80%	Mobile	1.16	1.87	2.58
Pure ALOHA	Stationary	0.39	0.40	0.41
50%	Mobile	0.28	0.31	0.35
LBT AFA	Stationary	0.93	1.22	1.45
50%	Mobile	0.85	1.16	1.60
Pure ALOHA	Stationary	0.39	0.40	0.41
80%	Mobile	0.25	0.33	0.34
LBT AFA	Stationary	0.73	0.94	1.09
20%	Mobile	0.59	0.79	1.08

shows the average e2eDelays of stationary and mobile end-devices obtained in the SHC scenario with varying percentages of end-devices that use Pure ALOHA and LBT AFA under different traffic conditions (i.e., Case L, M and H).

The results show that there are no significant differences in terms of average e2eDelay with varying percentages of end-devices that use Pure ALOHA and LBT AFA. In all the cases, Pure ALOHA outperforms LBT AFA because Pure ALOHA end-devices do not delay their transmissions applying a backoff algorithm, but transmit right away whenever they have messages to send.

6.3. Impact of the Percentages of Stationary and Mobile End-Devices

This subsection presents the results obtained in the SHC scenario with varying percentages of stationary and mobile end-devices, respectively. In this evaluation, the number of end-devices that use Pure ALOHA and LBT AFA is the same (i.e., 100).

Figure 7, Figure 8 and Figure 9 show the PLR under different traffic conditions (i.e., Case L, M and H).

As expected, the PLR values increase with the percentage of mobile end-devices because in our scenario, they send messages more frequently than stationary ones. Consequently, a higher number of mobile end-devices generates a higher network traffic, and this increases the PLR.

Table 13. Average e2eDelay with varying percentages of stationary and mobile end-devices.

MAC Protocol	Type of End-Devices	Case L—Avg e2eDelay (s)	Case M— Avg e2eDelay (s)	Case H— Avg e2eDelay (s)
Pure ALOHA	Stationary (80%)	0.38	0.40	0.41
	Mobile (20%)	0.28	0.39	0.40
LBT AFA	Stationary (80%)	0.89	1.20	1.43
	Mobile (20%)	0.72	1.23	1.51
Pure ALOHA	Stationary (50%)	0.39	0.40	0.41
	Mobile (50%)	0.28	0.31	0.35
LBT AFA	Stationary (50%)	0.93	1.22	1.45
	Mobile (50%)	0.85	1.16	1.60
Pure ALOHA	Stationary (20%)	0.39	0.39	0.41
	Mobile (80%)	0.28	0.30	0.35
LBT AFA	Stationary (20%)	0.90	1.24	1.44
	Mobile (80%)	0.87	1.22	1.51

presents the average e2eDelay values obtained with varying percentages of stationary and mobile end-devices under different traffic conditions.

As can be seen, in this scenario, the percentage of stationary and mobile end-devices does not have a significant impact on the average e2eDelay.

6.4. Discussion

The simulation results show that the PLR values obtained by LBT AFA are lower than those of Pure ALOHA. In particular, the difference increases with the traffic load. The reason for this result is that with Pure ALOHA, the end-devices transmit without performing any CCA; therefore, they may incur a high number of collisions. On the contrary, LBT AFA runs CCA before starting a transmission and uses AFA (and may resort to backoff) whenever the channel is found to be busy. Consequently, with LBT AFA, the packet loss decreases, but the CCA increases the energy consumption. Pure ALOHA outperforms LBT AFA in terms of average e2eDelay, as the end-devices that use Pure ALOHA do not adopt a backoff algorithm; therefore, they do not delay their transmissions.

The PLR increases with the number of end-devices that use Pure ALOHA because the end-devices transmit right away whenever they have messages to send (without running CCA). Our results show that the PLR increases with the percentage of mobile end-devices because in our scenario, they generate a higher network traffic than stationary ones. Furthermore, in our scenarios, neither the percentage of stationary and mobile end-devices nor the percentage of end-devices using Pure ALOHA and LBT AFA significantly impact the average e2eDelay.

When the messages to be transmitted are of equal importance, LBT AFA can be a good option, as it reduces collisions. However, in some scenarios, e.g., in the industrial communications, different end-devices typically transmit traffic flows with different criticality levels (e.g., alarms, and best-effort traffic). In these cases, the choice of the MAC protocol to be used by each end-device can help to meet the requirements of the relevant traffic flow. For example, the end-devices that can generate high-priority messages that have to be delivered as soon as possible (e.g., alarms) should prefer Pure ALOHA.

7. Conclusions

This paper proposed a simulative performance assessment in different scenarios and configurations of a LoRaWAN network that combines the use of the two MAC protocols supported by LoRaWAN, Pure ALOHA and LBT AFA, working in compliance with the ETSI regulations.

Summarizing, the results obtained show that in the assessed scenarios, LBT AFA obtains lower PLR values than Pure ALOHA. In particular, the benefits offered by LBT AFA become more evident as the workload increases.

However, end-devices that adopt LBT AFA experience a PDR that increases with the traffic load. This value represents the number of messages that are discarded because the maximum number of backoffs is reached. To reduce the number of messages discarded, it is possible to increase the $LB{T}_{backoffs}^{max}$ parameter. In this way, the probability of a message being sent increases, as a higher number of transmission attempts will be run before discarding it. However, on average, as each end-device will run a higher number of CCAs, the energy consumption will also increase.

As the $EC{R}^{tx}$ results show, in the scenarios assessed, Pure ALOHA consumes slightly less energy per transmission than LBT AFA because it does not perform any CCA. Furthermore, pure ALOHA experiences lower e2eDelays than LBT AFA because message transmissions are not delayed.

Based on the findings of this assessment, the network designer can determine which MAC protocol to use on each end-device depending on the desired performance target (i.e., PLR, PDR, e2eDelay, or energy consumption).

In particular, to achieve low PLR values, the LBT AFA MAC protocol is the preferred choice and setting a high $LB{T}_{backoffs}^{max}$ value can be an option to obtain low PDR values. On the contrary, if the primary target is to reduce the maximum message e2eDelay, the network designer can adopt Pure ALOHA, which is also able to offer low PLR under low and medium workloads.

Future work will deal with a priority-based traffic classification algorithm that runs on the LoRaWAN end-devices and allows the network designer to choose, for each traffic flow, the MAC protocol that best matches the flow requirements. Furthermore, we will also explore the use of the SDN paradigm to dynamically select LoRa parameters in mobile end-devices.