Comparative Assessment of the LoRaWAN Medium Access Control Protocols for IoT: Does Listen before Talk Perform Better than ALOHA?

Abstract

Low-Power Wide-Area Networks (LPWANs) are emerging as appealing solutions for several Internet of Things (IoT) applications, such as healthcare, smart cities and Industry 4.0, thanks to their ease of deployment, low energy consumption and large coverage range. LoRaWAN is one of the most successful LPWAN standards, as it supports robust long-distance communications using low-cost devices. To comply with the ETSI regulations, LoRaWAN can adopt as medium access control (MAC) layer either a pure ALOHA approach with duty-cycle limitations or a polite spectrum access technique, such as Listen Before Talk (LBT). The two approaches have their pros and cons that need to be carefully evaluated. The studies in the literature that so far have addressed an evaluation of MAC protocols for LoRaWAN refer to a previous and now obsolete version of the ETSI regulations, therefore they do not take into account the current limits on the timing parameters for polite spectrum access, such as that maximum time an end-node is allowed to be transmitting per hour. For this reason, the contribution of this work is two-fold. First, the paper discusses the restrictions that the current ETSI regulations impose on some timing parameters of the two kinds of MAC protocols for LoRaWAN. Second, the paper provides comparative performance assessments of the two protocols through simulations in realistic scenarios under different workload conditions.

1. Introduction

The IoT paradigm is presently successfully applied to a broad set of scenarios with very heterogeneous requirements, such as smart cities, healthcare, and smart environments [1]. For instance, an IoT-based monitoring system such as the virtual biosensor for MEDIcal WARNing precursor (MEDIWARN) helps the medical team to better understand the patients’ clinical condition and take prompt action in response to the health conditions [2]. Moreover, in Industry 4.0 ecosystems, IoT is one of the enabling technologies for offering a broad spectrum of services to any device of the automation system [3]. As the IoT application scenarios are very heterogeneous, the network designer must carefully identify the communication technologies that best meet the different requirements of the diverse IoT applications. In particular, a broad spectrum of wireless communication systems has recently been considered for IoT applications. Among them, short-range technologies such as Near Field Communication (NFC) [4], very long-range ones such as WiMAX [5], low-power technologies such as Bluetooth Low Energy (BLE) [6,7,8], high-power ones such as cellular networks (3G/4G/5G) [9,10,11], and some amendments to the IEEE 802.11 and the IEEE 802.15.4 standards [12,13,14,15].

In addition to the above-mentioned technologies, Low-Power Wide-Area Networks (LPWANs) are also a promising option for the IoT scenario [16,17], as they offer energy-efficient connectivity to a high number of low-throughput devices distributed over wide areas.

Among the LPWANs, the Long-Range Wide-Area Network (LoRaWAN) standard is emerging thanks to its low-cost and low-power consumption. LoRaWAN [18,19] is based on the well-known Long-Range (LoRa) technology and can adopt two different uncoordinated channel access methods [20], i.e., an ALOHA-based approach and a polite spectrum access strategy based on the Listen Before Talk (LBT) technique, i.e., on carrier sensing. As it will be discussed in Section 6.2 of this work, the latest regulations imposed by the European Telecommunications Standards Institute (ETSI) [21,22] introduce some restrictions on the use of LBT. However, all the works in the literature that so far have dealt with LoRaWAN refer to a previous and now obsolete version of the ETSI regulations [23], therefore they do not take into account the limits for the polite spectrum access timing parameters that are reported in [21].

Compared to existing works in the relevant literature, the contribution of this paper is two-fold. First, the paper provides a clear and complete overview of the restrictions that the latest ETSI regulations, i.e., the ones in [21,22], impose on the MAC protocols that can be used in a LoRaWAN network. Second, the work compares the performance of the two medium access schemes working in compliance with [21,22] through simulations in realistic scenarios under different workload conditions.

The paper is organized as follows. Section 2 deals with related works, while Section 3 outlines the LoRaWAN standard. Section 4 and Section 5 discuss the ALOHA-based and LBT-based medium access strategies, respectively. Section 6 presents the ETSI regulations on the EU863-870MHz ISM Band. Section 7 provides a qualitative comparison between the two protocols under study, while Section 8 compares the results of comparative assessments obtained through simulation. Finally, Section 9 gives conclusions and hints for future works.

2. Related Work

LoRa is a promising long-range communication technology for several application domains, such as mobile robotics [24], industry [25,26,27,28], healthcare [29], and consumer [30] applications. LoRaWAN [18] is standardized by the LoRa Alliance and defines a network architecture based on LoRa. LoRa is the physical layer, while LoRaWAN defines the medium access control mechanism.

Several works presented LoRaWAN implementations and performance assessments. For instance, the work in [31] proposes a methodology to assess the architectural delays of LoRaWAN implementations, while other works addressed the performance evaluations of both standard and customized versions of the MAC protocols to be used over LoRa. However, to the best of our knowledge this work is the first one that takes into account the duty-cycle limitations imposed by the newest ETSI regulations when evaluating LoRa-based networks with the ALOHA-based and the Listen Before Talk protocols, respectively. In fact, the previous and now obsolete version of the ETSI regulations did not impose any limitation on the maximum transmission time per node when using an LBT-based approach. Consequently, in the existing comparative assessments based on such previous regulations, the LBT-based approaches were strongly favored over the ALOHA-based ones.

Some custom versions of polite spectrum access techniques for LoRa were presented in the works in [32,33,34], which describe the proposed MAC protocols and compare them with the ALOHA-based MAC scheme adopted by plain LoRaWAN devices. The results obtained show that the proposed approaches achieve a lower collision ratio than ALOHA, at the expenses of a moderate increase of energy consumption. However, the comparative results between the ALOHA-based and LBT-based approaches proposed in [32,33,34] are not up-to-date, since they refer to an obsolete version of the ETSI regulations [23] that did not foresee duty-cycle restrictions for the LBT-based approaches. Moreover, the non-conformance of the considered approaches to the duty-cycle restrictions also impairs their implementation on devices compliant to the current ETSI regulations.

Another interesting topic that is relevant to the two protocols considered in this paper is the coexistence on the same network of devices working according to ALOHA-based and LBT-based access schemes. For example, the works in [35,36] address the performance evaluation of mixed networks in which the ALOHA and LBT approaches coexist. However, the above-mentioned works do not deal with the limitations imposed by the recent ETSI regulations defined in [21,22], while this work gives a detailed overview of the current ETSI regulations. Moreover, the works in [35,36] do not provide a comparison between the two kinds of MAC protocols for LoRaWAN in the same conditions. Conversely, this paper provides a performance comparison of LoRa networks using either the ALOHA-based protocol or the LBT-based protocol used in compliance with the ETSI regulations. This work therefore presents a fair performance comparison through simulation results obtained in a realistic scenario under diverse traffic and load conditions.

3. LoRaWAN

A LoRaWAN network typically works over a star-of-stars topology, as shown in Figure 1, in which the end-nodes communicate with the network server through gateways.

The message exchange between the end-nodes and the gateway takes place on a single LoRa hop. The gateways are connected to the network server via standard IP connections and they transparently relay the messages from the end-nodes to the network server (uplink communications), and vice versa (downlink communications). Each uplink message is sent by an end-node to the network server through one or multiple gateways, while a downlink message is sent by the network server to a single end-node through a single gateway.

3.1. LoRa

LoRa is a spread spectrum modulation technique, patented by Semtech, that exploits the Chirp Spread Spectrum (CSS) technology. LoRa supports robust long-range transmissions and operates in the unlicensed sub-GHz ISM band.

A LoRa device can be configured setting some customizable parameters [37], such as the Transmission Power (TP), Carrier Frequency (CF), Spreading Factor (SF), Frequency bandwidth (BW) and Coding Rate (CR), in order to tune the communication performance (e.g., coverage range, data rate and robustness to interference or noise) and energy consumption. The values that can be used for each parameter depend on the region where LoRa devices are deployed [19] and on hardware limits.

Among these parameters, here we discuss how the SF, CR and BW affect a LoRa transmission.

The SF allows adjustment of the coverage range, data rate and energy consumption. A higher SF increases the sensitivity and coverage range, as well as the Time on Air (ToA), i.e., the duration of a packet transmission. Each increase in SF approximately halves the transmission rate and therefore it roughly doubles the ToA and the energy consumption. In the light of several works in the literature, such as [38,39], radio communications using different SFs are orthogonal to each other, so messages on different SFs can be successfully sent simultaneously. On the other hand, the work in [40] demonstrates that the SFs are quasi-orthogonal, i.e., simultaneous transmissions on a specific channel using different SFs are not immune to each other. However, the transmitted messages can be correctly decoded when the Signal-to-Interference Ratio (SIR) of each received message is above an isolation threshold, defined in [40].

The CR affects the robustness against interference. A higher CR value offers more robustness but increases the ToA, and vice versa.

Finally, a higher BW provides a higher data rate and hence a shorter ToA, but a lower sensitivity, due to the additional noise. Conversely, a lower BW provides a higher sensitivity, but a lower data rate.

3.2. Adaptive Data Rate

LoRaWAN provides the Adaptive Data Rate (ADR) mechanism [41] to optimize the network on the use of the fastest possible data rate. Each end-node can individually set any of the possible data rates and TP. This way, thanks to the ADR mechanism, each fixed end-node can adapt its data rate and TP.

The ADR mechanism can be enabled either by the end-node or the network server on demand. However, if possible, it is suggested to enable ADR to prolong the battery life of the end-node and maximize the network capacity.

If the ADR mechanism is enabled, the network server controls the data rate and TP of the end-nodes through specific MAC commands. Further details about the recommended ADR algorithm can be found in [41]. If ADR is disabled, the end-node controls its data rate following its own strategy. Typically, a mobile end-node disables ADR depending on its mobility patterns.

In the case that the radio channel attenuation varies fast and constantly, ADR cannot be used, as the network server is not able to control the data rate of the end-nodes. In such a case, it is up to the application layer of the end-nodes to handle the data rate control task, according to the network conditions.

4. Plain Medium Access Scheme

LoRaWAN networks can adopt two different MAC protocols. However, the current LoRaWAN specification [18] only addresses the pure ALOHA access scheme, according to which each end-node can attempt a transmission whenever it generates a new message. This channel access mechanism may be combined with a retransmission scheme, as discussed in Section 4.2, according to which a message is retransmitted if the relevant acknowledgement is not received.

LoRaWAN defines three device classes, i.e., Class A, B and C, with different capabilities. These classes exploit a simple pure ALOHA medium access scheme for uplink transmissions, while they differ for the downlink communication capabilities.

For Class-A devices downlink communication is allowed only after a successful uplink transmission, so they have the lowest power consumption. This class of devices strongly favors uplink communications. Class B devices can periodically wake up to receive scheduled downlink data traffic, therefore, they provide for additional receive windows for downlink traffic without prior successful uplink transmissions. Finally, Class C devices continually listen to the channel, except when they are transmitting. They are typically mains powered.

Since the Class-A devices are the ones with the widest diffusion in the market, in the next Subsection we provide some details about the medium access scheme they use.

4.1. Transmission Timing of Class-A Devices

Figure 2 shows the structure of an uplink transaction for a Class-A device, i.e., how the device behaves every time it accesses the physical medium and transmits a message.

Once a message is generated, the end-node attempts to transmit. After each uplink transmission the end-node opens two receive windows. The first receive window, named RX1 in Figure 2, starts $RXDelay1$ seconds (+/− 20 $\mathsf{\mu }$s) after the end of the uplink transmission. The second receive window, named RX2 in Figure 2, starts $RXDelay2$ seconds (+/− 20 $\mathsf{\mu }$s) after the end of the uplink transmission.

The duration of a receive window is longer than or equal to the time required by the radio transceiver of the end-node to effectively detect a downlink message, i.e., to identify a preamble.

If a preamble is detected during one of the receive windows, the receiver stays active until the downlink message is demodulated. Every time a message intended for an end-node is correctly demodulated by the node during the first receive window, the second receive window will start.

The network server can transmit a downlink message to a specific end-node at the beginning of any receive windows.

After a transmission, the end-node can transmit a new message only either after receiving a downlink message (in the first or second receive window) or when the second receive window of the previous transmission has elapsed, i.e., when the uplink transaction (as depicted in Figure 2) has expired.

4.2. Retransmission Policies

LoRaWAN uses data messages to transfer both MAC commands and application data, which can be combined in the same message. A message can be confirmed if it requires an acknowledgement (ack) by the receiver or unconfirmed otherwise.

Both confirmed and unconfirmed uplink messages are transmitted NbTrans times at maximum, until a downlink message is correctly decoded following one of the transmissions. The NbTrans parameter can be configured to obtain the required Quality of Service (QoS) for the uplink transmissions in terms of reliability.

The end-nodes wait until the uplink transaction has expired and perform frequency hopping before retransmitting. Each end-node can set the delay between two consecutive retransmissions. If the corresponding ack is received, the device stops the retransmissions. The retransmission of an unconfirmed uplink message is stopped when a valid message is received during the RX1 or the RX2 window.

5. Polite Spectrum Access

5.1. Listen before Talk

A polite spectrum access imposes that each device perform a clear channel assessment (CCA) before transmitting (hence the Listen Before Talk name). This way, the device can check if the channel is busy or not.

If the average signal level detected over the CCA listening interval is lower than the CCA threshold, the device starts the message transmission. Otherwise, the channel access, i.e., the message transmission, is delayed of a deferral interval (backoff delay) to avoid mutual interference and therefore message collisions. In the latter case, the device cannot attempt to access the same channel until a random time interval (longer than a specific value) has expired. Alternatively, the device can switch to another channel and start again the CCA before attempting to transmit. This approach is called Adaptive Frequency Agility (AFA) and is discussed in the next Subsection.

The LBT-based schemes can differ in two aspects, i.e., the way the CCA is performed and the approach adopted when the channel is sensed as busy.

5.2. Adaptive Frequency Agility

The polite spectrum access can be improved by combining the plain LBT with an AFA technique (this approach is named LBT AFA). This way, if the transmitter detects that the sensed channel is busy, it changes channel.

Various algorithms can be used to implement channel adaptivity. The best option should allow distribution of the generated traffic over the available channels and avoid the use of busy channels.

6. ETSI Regulations EU863-870MHz ISM Band

The ETSI regulations in [21,22] impose some restrictions on the strategies that a LoRa transmitter can adopt to access the physical medium. In particular, in this work we focus on the EU863-870MHz ISM Band, i.e., a license-free spectrum in which any device can transmit complying with the ETSI regulations. The latter allow the choice of using either a duty-cycle limitation, as discussed in Section 6.1, or an LBT AFA transmission management, which is also subject to restrictions, as described in Section 6.2.

The current LoRaWAN specification exclusively uses pure ALOHA with duty-cycle-limited transmissions to comply with the ETSI regulations in the EU863-870MHz ISM Band [19].

6.1. Duty-Cycle Limitation

The maximum duty cycle is defined as the maximum percentage of time per hour during which a node can transmit on a sub-band. For instance, a duty cycle of 10% allows 360 s of transmission time per hour.

Each device that uses an ALOHA-based medium access strategy must comply with limitations on the duty cycle and maximum transmission power.

Table 1. EU863-870MHz ISM Band duty-cycle limitations.

Sub-Band	Frequency Band (MHz)	Available Channels	Maximum TX Power (dBm)	Maximum Duty Cycle
h1.4	868.00–868.60	3	14	1%
h1.5	868.70–869.20	2	14	0.1%
h1.6	869.40–869.65	1	27	10%
h1.7	869.70–870.00	1	14	1%

shows the limitations in the four sub-bands identified in the EU863-870MHz ISM Band.

In a sub-band more than one channel can be available for transmission, as shown in Table 1. We assume that each channel has a frequency bandwidth of 125 kHz. Please note that the ETSI limitations refer to the sub-bands, therefore the transmission times on all the channels of the same sub-band must be jointly considered.

6.2. Polite Spectrum Access Timing Parameters

The limitations imposed by the ETSI regulation on the use of LBT-based medium access schemes are reported in

Table 2. Polite spectrum access timing parameters.

Parameter	Limit
Minimum CCA interval	160 $\mathsf{\mu }$s
Minimum value of the deferral interval	CCA interval
Smallest interval between two adjacent deferral intervals	Declared by the manufacturer
Maximum time between the end of a listening interval and the start of a transmission	CCA time declared by the manufacturer (not exceeding 5 ms)
Maximum duration of a single transmission	1 s
Maximum duration of a transmission dialogue or a polling sequence	4 s
Maximum allowed cumulative transmission time per hour over a 200 kHz portion of spectrum	100 s/1 h per 200 kHz of spectrum
The minimum interval during which a specific transmitter shall remain off after a transmission on the same channel	100 ms

[21].

According to the ETSI regulations, the minimum CCA interval must be 160 $\mathsf{\mu }$s. When the target channel is sensed busy, the deferral interval must be greater than or equal to the CCA interval, while the minimum interval between two adjacent deferral intervals shall be the one declared by the manufacturer.

The LBT approaches are limited in terms of the maximum transmit time, as a single transmission must be less than or equal to 1 s, while a message sequence must stop within 4 s.

Moreover, an LBT transmitter must be silent for at least 100 ms after a transmission.

The maximum cumulative transmission time per device must be less than 100 s per hour, i.e., a duty cycle of about 2.8% per 200 kHz spectrum is allowed. However, the use of AFA techniques, which enable the device to switch to a different channel every time the target channel is found busy during the CCA, allows achievement of a higher value of maximum duty cycle across channels.

The polite spectrum access parameters shall be declared by the manufacturer, but they must not exceed the values reported in Table 2.

7. Qualitative Comparison

ALOHA-based and LBT-based medium access schemes differ in various aspects, as discussed in [20]. The first approach does not involve any carrier sense mechanism; therefore, it is energy-efficient under low traffic conditions. Conversely, in case of high network traffic or when several nodes are far away from the gateway, ALOHA-based schemes may experience a high number of transmission failures due to collisions.

The approaches based on LBT can potentially mitigate the issue of transmissions overlapping and hence message loss thanks to the feature of listening the channel before starting a transmission. However, LBT slightly increases the energy consumption per node, as it requires the use of CCA mechanisms. Please note that if a retransmission mechanism is supported, LBT could perform better than ALOHA even in terms of energy consumption and it could achieve a message delivery ratio higher than or equal to the one of ALOHA with a lower number of retransmissions.

The use of an adaptive data rate technique is expected to increase the performance of both approaches, as it aims to reduce the ToA of each message sent. This way, the message transmissions experience a lower interference probability and use a smaller portion of the allowed duty cycle per node. As a result, each node can transmit a higher number of messages.

The ALOHA-based approach must comply with the limitations on the duty cycle shown in Table 1. Consequently, a fair use the four sub-bands identified in the EU863-870MHz ISM Band allows achievement of an overall duty cycle of 12.1%.

The LBT mechanism must comply with the restrictions of polite spectrum access reported in Table 2. Since a device can transmit 100 s per hour per 200 kHz spectrum, an overall transmit time of 700 s can be achieved. This means 300 s in the sub-band h1.4, 200 s in the sub-band h1.5, and 100 s in both the sub-bands h1.6 and h1.7. As a result, the LBT approach provided with an adaptive frequency agility mechanism able to evenly allocate the transmissions over the various portions of the spectrum allows a duty cycle of about 19.4% (i.e., a higher value than the one allowed by the ALOHA-based approach).

8. Simulative Assessment

This section presents the simulative assessment of both the ALOHA-based and LBT-based MAC protocols working on top of the LoRa technology.

The simulator was developed using the OMNeT++ simulation environment. The plain LoRaWAN Class-A devices are simulated using the FLoRa [42] framework that, in turn, uses components from the INET framework. Conversely, the LBT scheme was developed from scratch using the wireless channel provided by FLoRa. In our assessment, like in FLoRa, concurrent transmissions using different SFs on the same channel are assumed to be orthogonal.

Each node is provided with a duty-cycle check function to ensure that the ETSI limitations in terms of duty cycle are met.

The metrics used to compare the two MAC protocols is the Packet Loss Ratio (PLR), defined as the ratio between the number of lost messages ($n_{lostMsg}$) and the overall number of transmitted messages ($n_{txMsg}$) measured at the Application layer. The PLR is expressed as a percentage, according to Equation (1).

$$PLR=\left(\frac{n_{lostMsg}}{n_{txMsg}}\right)\ast 100$$

(1)

8.1. Simulated Scenario

The considered scenario is a realistic industrial use case similar to the one presented in [43]. It consists of an area of 5000 m × 5000 m (here called sensing area) in which a variable number of end-nodes, both mobile and stationary, needs to send messages to a central server.

The simulated network topology includes a network server, a gateway and a variable number of end-nodes.

Among the end-nodes, the 75% of them are stationary, while the other ones are mobile. The network server and the gateway are located in the center of the sensing area. The stationary nodes are randomly distributed around the gateway, while the mobile nodes move with speed equal to 0.3 m/s according to the ChiangMobility model available in the INET framework.

According to the number of end-nodes and their position within the sensing area, different scenarios are generated. Each one is simulated with two different MAC configurations, i.e., pure ALOHA and LBT.

Moreover, we evaluate the PLR using confirmed (see Section 8.3) or unconfirmed messages (see Section 8.4) to understand how much the downlink traffic affects the PLR. If the performance degradation is low, then it is worth adopting confirmed messages and retransmission mechanisms.

8.2. Simulation Settings

In our simulations, a propagation model based on the lognormal shadowing model, called LoRa Path Loss Oulu [42], with the realistic parameters experimentally found in a suburban environment [44] is adopted.

We set the transmission power to 14 dBm (i.e., 25 mW). Such a value is compliant with the ETSI regulations and was adopted in several works in the relevant literature, such as [36,43].

The application layers of the different nodes are not synchronized, therefore the message generation time and/or the transmission time can be the same on multiple nodes. In this case, with the ALOHA-based medium access scheme collisions occur. Conversely, with the LBT-based approach unsuccessful transmission attempts (due to a busy channel) occur. In our scenario, with the LBT-based approach in 2 cases out of 10 the nodes wait for a backoff delay before retrying transmission, while in 8 cases out of 10 they run an AFA mechanism. The probability of performing one action or the other is a configurable parameter. LBT uses a CCA interval of 200 $\mathsf{\mu }$s.

We consider an application payload of 20 bytes for all the messages generated by the end-nodes, as in [43].

The stationary and mobile nodes generate messages with period derived from an exponential distribution. In the simulations described in Section 8.3 and Section 8.4 the stationary and mobile nodes set the mean of that distribution to 600 s and 120 s, respectively. Conversely, in order to assess diverse traffic conditions, in the simulations reported in Section 8.5 we use different values as the mean of the exponential distribution, i.e., (15 s, 30 s, 60 s) for stationary nodes and (5 s, 10 s, 20 s) for mobile nodes, respectively.

The simulation time was set to 12 hours. The relevant simulation parameters are summarized in

Table 3. Simulation parameters.

Parameter	Value
Coding Rate	4/5
Frequency bandwidth	125 kHz
Transmission Power	14 dBm
Application payload	20 bytes
CCA interval	200 $\mathsf{\mu }$s
Action after sensing a busy channel	Backoff delay (20%)
	AFA (80%)
Simulation time	43,200 s (12 h)
Propagation model	LoRa Path Loss Oulu [44]

.

8.3. Simulation Results - Confirmed Messages

This section presents the performance assessment of a network configuration in which confirmed messages, i.e., messages that require an ack from the receiver, are sent. In particular, for each received message the network server immediately sends an ack through the gateway during one of the two windows used for the downlink communications (see Figure 2).

Three different scenarios are assessed with 20, 40 and 80 nodes, respectively, using both the MAC protocols considered in this study.

In the simulated scenarios, the stationary nodes (75% of the total number of nodes) use the ADR mechanism, as suggested in [18] (see Section 3.2), while the mobile nodes are evaluated with and without ADR to assess to what extent the latter impacts on the PLR depending on the mobility pattern used. Each scenario is simulated four times to evaluate all the possible node configurations.

Table 4. Average PLR - Confirmed messages.

Nodes	MAC Protocol	ADR	Avg PLR 20 Nodes	Avg PLR 40 Nodes	Avg PLR 80 Nodes
Stationary nodes	ALOHA	Enabled	13.61%	20.98%	35.66%
	LBT	Enabled	14.71%	19.33%	37.42%
Mobile nodes	ALOHA	Enabled	18.95%	31.04%	46.31%
	ALOHA	Disabled	19.19%	30.82%	35.59%
	LBT	Enabled	19.45%	30.04%	44.07%
	LBT	Disabled	18.68%	31.61%	35.87%

shows the average PLR of both the stationary and mobile nodes using the pure ALOHA and LBT.

The measured average PLR highlights several aspects. First, the PLR obtained by the ALOHA approach is similar to the one of LBT in the assessed scenarios. This indicates that due to the pattern of data flows only a few times the channel is detected as busy during the CCA. Consequently, ALOHA and LBT operate in a similar way. Second, the PLR performance quickly degrades with an increasing number of network nodes. The use of confirmed messages entails that the network server, and therefore the gateway, sends an ack every time a message is correctly received. The increase of the number of nodes and, consequently, of the number of messages received by the server, leads to an increase of the number of acks (and of ADR commands, if such an option is enabled) to be sent. Since the gateway cannot send and receive at the same time, whenever it stays in transmit state it will lose several messages sent by the end-nodes. Finally, on average, the use of ADR mechanism has a negative impact on the PLR of the mobile nodes. This is in line with the LoRaWAN standard that in fact suggests disabling ADR in mobile nodes.

8.4. Simulation Results - Unconfirmed Messages

This Section presents the performance assessment of a network configuration in which unconfirmed messages are sent, i.e., no acks are required.

The assessed configuration reduces to a minimum downlink communications in order to avoid the message loss due to the frequent switching of the gateway from the receive to the transmit state for transmitting acks and/or ADR commands. For this reason, here unconfirmed messages are used and the plain ADR is disabled.

However, in order to realize a robust communication system in which each node is aware of the data rate values (and therefore of the SF values) that can be used for reliable transmission, a data rate control mechanism is needed. As a consequence, we propose and implement a custom approach to accomplish a smart data rate control that is able to provide the end-nodes with the values of SF that can be used for message transmissions. This way, both the stationary and mobile nodes (the latter often cannot use the plain ADR, as suggested in [18]) can choose the SF from a set of recommended values.

The proposed solution foresees a dynamic list of recommended SF values and therefore of data rate values that each node periodically updates. The update occurs thanks to the network server that regularly sends six beacons, one for each possible SF value (from 7 to 12), through the gateway. Each end-node updates its list according to the beacons received. If no beacons are received, the list will not be updated. The update period of the list and hence the beacon period is configurable. The proposed approach introduces a kind of synchronization between the network server and the end-nodes that provide a custom ADR mechanism with limited requirements in terms of downlink communications.

According to this approach, the nodes that are closer to the gateway should receive more beacons and have a larger set of SFs to use for transmissions than the nodes that are further away.

In the simulative assessment the beacon period was set to 30 s.

Table 5. Average PLR - Unconfirmed messages.

Nodes	MAC Protocol	Avg PLR 20 Nodes	Avg PLR 40 Nodes	Avg PLR 80 Nodes	Avg PLR 100 Nodes	Avg PLR 200 Nodes
Stationary nodes	ALOHA	15.63%	17.20%	19.01%	18.65%	19.70%
	LBT	16.44%	16.37%	18.03%	18.45%	18.49%
Mobile nodes	ALOHA	17.41%	18.04%	16.97%	17.01%	18.73%
	LBT	14.09%	16.85%	19.05%	15.80%	16.74%

shows the average PLR of both stationary and mobile nodes that send unconfirmed messages using pure ALOHA or LBT as MAC protocol.

The results in Table 5 show that unconfirmed messages allow support of a higher number of nodes than confirmed messages (see Table 4), while maintaining the PLR low. However, the pattern of data flows used for the simulations does not allow determination of which of the two MAC protocols performs better in terms of PLR because in the assessed traffic conditions LBT only occasionally detects a busy channel and therefore it mostly performs like ALOHA after the CCA (without backoff delay or AFA). For this reason, in Section 8.5 further evaluations in different traffic conditions are presented.

8.5. Further Evaluations under Different Traffic Conditions

In this Section we consider a scenario with 100 end-nodes and the following configurations that differ for the message generation periods:

• Configuration a:
  • Stationary nodes: Exponential distribution with a mean of 60 s.
  • Mobile nodes: Exponential distribution with a mean of 20 s.
• Configuration b:
  • Stationary nodes: Exponential distribution with a mean of 30 s.
  • Mobile nodes: Exponential distribution with a mean of 10 s.
• Configuration c:
  • Stationary nodes: Exponential distribution with a mean of 15 s.
  • Mobile nodes: Exponential distribution with a mean of 5 s.

Table 6. Average PLR varying traffic conditions.

Nodes	MAC Protocol	Avg PLR Configuration a	Avg PLR Configuration b	Avg PLR Configuration c
Stationary nodes	ALOHA	25.16%	31.77%	41.18%
	LBT	22.69%	29.74%	39.72%
Mobile nodes	ALOHA	24.01%	28.55%	37.08%
	LBT	21.56%	26.49%	35.41%

shows the PLR results obtained in the three different configurations.

The assessed network configurations involve a higher number of message transmissions than the ones addressed in Section 8.3 and Section 8.4. Consequently, the channel is sensed busy multiple times and, if LBT is used as MAC protocol, an end-node waits for a backoff delay or runs an AFA mechanism before retrying transmission. This way, LBT reduces the PLR. In fact, as shown in Table 6, in networks with high traffic load (such as the three assessed configurations), LBT performs better than ALOHA in terms of PLR.

9. Conclusions

This paper presented an overview and a comparative performance assessment of the ALOHA and LBT medium access schemes when used in a LoRaWAN network in compliance with the current ETSI regulations. The assessment was performed through simulations. The evaluations refer to the impact on the PLR of using confirmed or unconfirmed messages and the ADR mechanism. Moreover, the performance of the two protocols under study were assessed under different workload conditions.

The results show that for a large deployment of LoRaWAN nodes, unconfirmed messages should be used to avoid a significant PLR increase due to downlink communications. Moreover, a comparison between the PLR of mobile nodes with and without enabling the ADR mechanism confirms that the plain ADR should be disabled in mobile nodes, in agreement with the LoRaWAN standard.

Finally, the obtained PLR values prove that LBT performs better than ALOHA under high traffic load because, whenever the channel is found busy, LBT reacts waiting for a backoff delay or running an AFA mechanism before retrying transmission. This way, LBT avoids losing several messages, differently from ALOHA, in which each node transmits without sensing the channel through a CCA mechanism. Conversely, under low traffic conditions the PLR results of the two assessed MAC protocols are similar.

In our study, the simulation time was set to 12 hours to collect statistics on a significant number of transmitted messages. We are aware that the results depend on some factors, such as the position of the nodes, the transmission power, and the propagation model parameters. In fact, simulations were repeated with different positions of the nodes and different generation times of the messages (both derived by a random generator), so as to obtain the average PLR with a confidence interval lower than $\pm 1\%$. The transmission power was set to a value (25 mW) that is typically used in the literature and compliant with the ETSI regulations. The propagation model here adopted is the LoRa Path Loss Oulu [42], which is based on the lognormal shadowing model with some specific parameters, i.e., realistic parameters experimentally found in a suburban environment [44]. Depending on the environment, different parameters can be adopted, and this may influence the obtained PLR performance.

Future work will address how to take advantage of the findings in this paper to tune the LoRaWAN parameters in order to support medical monitoring systems, as discussed in [45]. In fact, LoRaWAN allows provision of connectivity over very large geographical areas without a wired infrastructure and using low-cost devices. This way, several patients distributed in a big hospital consisting of several buildings can be remotely monitored in a centralized way by the medical staff. For this reason, LoRaWAN can be suitable for the MEDIWARN system [2] and could also represent a valid easy-to-deploy technology for field hospitals built to deal with monitoring of patients in emergency situations.

Another interesting topic for future investigation is the implementation of the quasi-orthogonality of the SFs in the simulator to assess if and to what extent it impacts on LoRaWAN performance in different scenarios and the use of LoRaWAN in Software Defined Networking architectures [46] to find optimized solutions for the dynamic selection of LoRa physical parameters.