1. Introduction
LoRa is a widely used long range communication technology for the Internet of Things (IoT). It uses a proprietary spread spectrum modulation currently owned by Semtech [
1]. It can trade data rate with coverage using multiple Spreading Factors (SF) which typically range from 7 to 12. Depending on the SF value, the channel bandwidth (BW) as well as other modulation characteristics, LoRa can achieve a data rate of up to approximately 22 kbps. The higher the SF and the lower the channel bandwidth, the lower the data rate and, thus, the longer the transmission time. Moreover, parallel transmissions performed on different SFs but on the same channel can be simultaneously decoded by the gateway. LoRa mainly uses license-free sub-gigahertz radio frequency bands (e.g., EU868, US915 [
1]) that are subject to radio duty cycle regulations. For example, in the European Union (EU) the nodes are allowed to transmit up to 1% of the time. However, LoRa chips for the 2.4 GHz band have recently been announced by Semtech. All those characteristics in addition to its resistance to potential external interference make LoRa an easy-to-use wireless data collection solution in agriculture, environmental monitoring, and smart-city applications [
2].
The main LoRa-based protocol, called LoRaWAN, provides registration, security, and acknowledgement services for LoRa-enabled IoT devices [
3]. A LoRaWAN architecture consists of (a) a core—usually wired—network which implements mechanisms to provide the above mentioned services, (b) one or more gateways, and (c) the IoT devices (end-nodes). The end-nodes can reach the gateway(s) in a single hop. In order to achieve high energy-efficiency and low implementation complexity, LoRaWAN does not perform any specific medium access policy for uplink transmissions. In fact, a Pure Aloha transmission policy is adopted [
4]. To increase the probability of packet delivery, multiple gateways can be deployed at different locations. However, it has been shown that LoRaWAN presents a high number of collisions and decreased performance in presence of high number of nodes [
5,
6], especially for confirmed traffic [
7].
However, a common problem that occurs in rural areas, as well as in specific deployments such as in mines [
8] and forests [
9], is the lack of a seamless power source to allow the installation of multiple gateways as well as their interconnection with a core network infrastructure. Even in the case where solar-powered gateways are employed, their availability depends on weather conditions, thus, seamless operation cannot always be guaranteed. In this paper, we assume such a scenario, where the gateway is not available at all times but it can be turned on periodically to carry out the data collection. The problem of gateway unavailability also appears in low orbit LoRa satellites [
10]. Since a satellite gateway can provide coverage to only a part of earth’s surface at every time, only a few nodes can successfully upload data in real time.
Since many typical applications in agriculture or in environmental monitoring are not time-critical, a solution to the gateway unavailability problem is to allow sensing nodes to buffer their data in on-board storage and transmit it in bulk when the gateway becomes available. Since the bulk data collection may have to be achieved as fast as possible, nodes tend to transmit their packets with a high rate, which may saturate the channel. In this case, an Aloha-based approach fails to achieve a high delivery ratio due to high number of collisions. However, in the use cases under consideration, we assume that data traffic is somewhat predictable and, thus, efficient scheduling of transmissions in time slots without significant overhead can be achieved in order to reduce or eliminate collisions and reduce the data collection time. Nevertheless, the problem under consideration requires computation and dissemination of the schedule. Both schedule computation and dissemination are two very challenging problems because (a) the schedule has to be as efficient as possible in terms of data collection time, (b) as compact as possible in terms of size, and (c) to be transmitted to the nodes as quickly as possible over low-rate and duty cycle-restricted wireless links.
In our previous work [
11], we investigated the gains of using two centralised scheduling algorithms when the number of nodes and their transmission settings (e.g., reliable SFs) are known. The proposed algorithms assign SFs and allocate time slots for transmissions, aiming at generating collision-free schedules with the minimum possible data collection time. The missing parts of this work were that (a) no theoretical background of the Aloha-based data collection methods was provided. (b) The proposed heuristics did not provide any performance guarantees while there was no comparison with the optimal solution even for small-scale scenarios, (c) we neglected the assessment of the transmission of the schedule to nodes which constitutes one of the major problems in LoRa networks scheduling, and finally, (d) the solutions were not experimentally validated. Hence, in this paper, we extend our previous work to add the following contributions:
We describe the weaknesses of an Aloha transmission policy for efficient bulk data collection and we formulate the problem of finding the minimum transmission rate to achieve a certain success probability of packet delivery for each node. This transmission rate provides the lower bound of the bulk data collection time in Aloha approaches.
We formulate and solve the optimal time-slotted scheduling problem that minimises the data collection time in LoRa-based networks.
We implement a prototype of the proposed approach in a proof-of-concept to assess the practicality and performance of the schedule dissemination time and the ability of the nodes to compute the schedule with their own resources.
The rest of the paper is organised as follows:
Section 2 surveys recent related works.
Section 3 introduces the bulk data collection problem and describes the limitations of the Aloha MAC in this context. In
Section 4, we present preliminary information regarding time-slotted communications and in
Section 5 we formulate the optimal scheduling optimisation problem.
Section 6 presents theoretical and simulation results, while
Section 7 describes how a proof of concept was realised along with experimental results from the testbed. Finally,
Section 8 concludes the paper and presents ideas for future directions.
2. Related Research
The bulk data transmission problem has been investigated in the literature in the context of opportunistic or delay tolerant networks [
12]. Different types of communication protocols have been used, from IEEE802.11 [
13] to IEEE802.15.4 [
14] and RFIDs [
15]. In contrast to those technologies, our work focuses on the data collection from devices placed in large geographical areas, thus, a long range protocol such as LoRa is required. Supporting bulk data transmissions over LoRa-based networks is constrained by various limitations and unique characteristics (e.g., duty cycle, multiple pseudo-orthogonal spreading factors, etc.) that do not apply to other conventional networking solutions.
We have recently studied the bulk data collection problem in LoRa-based networks from different perspectives [
11,
16,
17,
18]. In [
11,
16], heuristic approaches were proposed to compute the time-slotted schedule with online and offline schemes, respectively. The offline approach assumes that a set of information such as the number of devices and their SFs is known in advance by the gateway. In contrast, in the online approach [
16], only partial knowledge is assumed, allowing this approach to adapt to dynamic changes such as frequent topology changes. Nevertheless, this comes at the expense of higher energy consumption and longer data collection time than the offline approach. Both approaches are centralized, where the schedule is computed at the gateway and disseminated to the end devices. An alternative approach was proposed for Industrial IoT deployments [
18], where the authors investigated a decentralized approach, where end devices can autonomously compute their schedule by receiving the minimum possible information from the gateway. This work was designed to meet specific industrial network criteria, such as fast joining times, low power consumption, and low overhead. However, the schedule length tends to increase substantially as the number of devices increases, which greatly increases the data collection time. Finally, the problem of collecting data using LoRaWAN over a single channel was examined in [
17]. In this work, optimal SF assignments are proposed so that the average probability of successful packet delivery is maximized. However, this approach is still Aloha-based and does not eliminate collisions. Unlike the previous works, in this paper, we present the complete picture of the bulk data collection problem, we formulate and solve the optimal scheduling problem to minimize the data collection time considering collision-free scheduling and allocation of SFs, and we study practical implementation aspects such as the schedule transmission.
We rely on a time-slotted medium access control (MAC) approach to enable efficient bulk data transmissions in LoRa-based networks. In the literature, similar MAC approaches have been considered as they typically offer higher reliability than that of Pure Aloha [
19]. In [
20,
21,
22], various time-slotted MAC strategies are used to mitigate the collisions in dense LoRa/LoRaWAN networks and, thus, improve their scalability. Similar MAC strategies are also considered in [
23,
24,
25,
26] to meet the requirements of soft real-time industrial applications. In [
27,
28,
29], time slots are used to enable low-power multi-hop communications in LoRa-based networks to extend the coverage in harsh environments like underground deployments. In addition to that, the Time Slotted Channel Hoping mechanism of the IEEE802.15.4e standard is employed to enable LoRa-based mesh networking [
30]. Unlike the profound advantages of the aforementioned time-slotted solutions in terms of reduced packet collisions, they can barely be used for bulk data collection because of the absence of a scheduler to allocate slots to the nodes or because they follow a slotted-Aloha approach which does not eliminate collisions. Since in bulk data collection, the nodes tend to use a high data rate to quickly expedite all transmissions, non collision-free approaches may suffer for long data collection times.
3. The Problem of Bulk Data Collection
In this section, we describe some general requirements to achieve bulk data collection and we present a theoretical uplink analysis of an Aloha-based LoRa MAC to show that the average data collection time increases exponentially with the number of nodes.
3.1. Requirements
In order to achieve bulk data collection, as the gateway cannot be available at all times, a mechanism to (almost) simultaneously wake up the nodes once the gateway becomes available must exist. A simple way to achieve that is to schedule the data collection process at predefined times. Apparently, due to the clock drift of the nodes, some of them will wake up earlier than others. Taking into account experimental data from our previous work [
31], the maximum clock drift does not exceed 100 ppm, which is translated to a few seconds of time assuming that the data collection is executed once per day. However, having in mind that the data collection may take several hours to be completed (see experimental results in
Section 6), the waking up waiting cost is negligible compared to the duration of the data collection. The gateway can initiate the data collection process after this short period of time. In the case of non-coordinated transmissions, such as in an Aloha approach, this can happen by simply sending an initialisation packet. However, if the transmissions are time-synchronised, the gateway needs to compute the schedule and send it to the nodes before starting the data collection. As we already mentioned, the computation and the transmission of the schedule are two critical operations that may considerably affect the reliability of the system as well as the data collection time. These two operations are the two main research subjects of the current paper.
Moreover, since the gateway is expected to be online for multiple hours per day, new nodes can periodically wake up and register with the gateway. If the gateway is not present at that time, the node can return to sleep mode and wake up at a future time to try to register again. Since a gateway system consists of multiple transceivers and the registration takes place at a different frequency, registrations do not affect the data collection process. As a consequence, even if a joining node tries to register during the data collection phase, the latter would not be interrupted/interfered by the registration activity. Registrations can also be accelerated by considering a similar process to LoRaWAN’s personalised activation (ABP). In this case, the gateway is aware of the new nodes while the corresponding DevAddr address as well as the security keys can be stored in the devices.
3.2. Data Collection Using Pure and Slotted Aloha MAC
In this subsection, we formulate a data collection time minimisation problem, as a function of the minimum required transmission rate and a given success probability of delivery. We show that reliable bulk data collection in Aloha (Pure and Slotted) cannot be achieved in a short amount of time even for a low number of nodes.
In
Table 1 we define a set of notations and their meaning to assist in the understanding of remainder of the presentation.
Aloha-based MAC protocols, such as used in LoRaWAN, do not apply any mechanism to coordinate packet transmissions. Indeed, each node transmits its packets whenever data are available and the duty cycle restrictions are met. In this case, some of the packets are delivered while others are lost due to collisions. Specifically, the collision rate depends on this transmission rate. For example, allowing the nodes to transmit in sparse intervals decreases the collisions but prolongs the data collection time. Assuming that all nodes transmit the same amount of packets , the average data collection time is then equal to , where is the packet transmission rate.
In order to model an Aloha MAC behaviour for the bulk data collection scenario, we assume that all nodes’ packets are equal in length and their transmissions follow a Poisson distribution with intensity
packets/s. Assuming the best-case scenario of no inter-SF collisions, transmissions only collide when they overlap in SF, time, and power [
6]. Given the analysis provided in [
17], if a node at distance
x from the gateway transmits a packet with SF
f, the transmission will be successful if it does not overlap with any other packets in the network having the same SF within the transmission time
. Alternatively, due to the capture effect, the packet can be decoded if the received power of other packets with the same SF is less than the current one by at least
. As shown in
Figure 1, considering a log-distance path loss model, the potential interfering nodes are those whose distance from the gateway is below
with
[
17], where
is the path loss exponent.
Consequently, given a uniform distribution of nodes with SF
f, the number of potential interfering nodes is
, where
is the number of nodes with SF
f and
d is the range of the deployment for the given SF. The probability of successful delivery
is that within a vulnerability period with duration
, none of those potential interfering nodes starts a transmission. Hence, we have:
The shorter the distance x to the gateway, the higher the probability of success delivery due to less interferers. The worst case situation appears for nodes that are on the border of the deployment range (i.e., ). In this case, all nodes with the same SF are potential interferers and the minimum success probability is then equal to .
As the transmission rate of the nodes decreases, the success probability increases, but so does the data collection time. This means that there is a certain (maximum) transmission rate
that satisfies a minimum success probability for all the nodes in the network. The question that arises is: how long is the data collection time given this rate and the desired minimum allowed success probability? In order to answer this question, we formulate the following optimisation problem:
Equation (
3) requires that the probability of “at least
packets (i.e.,
) are successfully delivered” is greater than or equal to a given value
, and
is large enough. Equation (
5) guarantees that the duty cycle constraint
C is not exceeded (if there is no duty cycle restriction then
, for example, in 2.4 GHz LoRa). We must note that in presence of a slotted-Aloha protocol, the vulnerability period reduces from 2
to
. Thus, Equation (
4) can be modified accordingly.
The solution of the optimisation problem gives the theoretical upper bound for the transmission rate (i.e.,
) and, hence, the lower bound for the required data collection time. The example of
Figure 2 depicts the theoretical data collection time for a scenario with 100 to 1000 nodes and a minimum transmission success probability of 0.9. All nodes use a 100-byte packet size, transmit 100 packets, and reach the gateway with SF7. We can observe that the data collection may take several hours even for low node numbers. This is because the data collection time depends on the packet rate
which is computed by solving the aforementioned optimization problem. As the number of nodes increases, the number of collisions increase as well. That means that
has to be increased considerably in order to make transmissions sparser and, thus, reduce the number of collisions. It is obvious from this analysis that an Aloha MAC (Pure or Slotted) cannot achieve a reliable bulk data collection in a reasonable period of time. We should mention that optimally assigning SFs such that the probability of delivery is maximised, can alleviate the problem of collisions [
17]. However, even in this case the data collection time remains very long.
5. The Optimal Data Scheduling Problem
In this section, we formulate the optimal data scheduling problem, that is the optimal arrangement of nodes’ transmissions into slots and frames. This formulation does not take into account acknowledgements since (a) acknowledgments are optional, and (b) the size of the acknowledgements is dynamic and depends on the actual number of nodes and the number of received packets in the frame. Moreover, acknowledgements are natively supported by the frame structure of TS-LoRa in the SACK packet which can be easily added into the following formulation. Nevertheless, for fair compare reasons of the optimal solution with the Aloha (which considerably suffers for the downlink traffic [
33]), we skip its formulation. The network is composed of a set of
N nodes. Depending on the distance of a node
i from the gateway, a set of possible SFs
is required and is allocated during the registration of the node with the gateway. For example, if a node can reach the gateway with SF7, all higher SFs will also allow the node to reach the gateway and can be used for different transmissions of the node in the schedule. Each node
i has an amount of data to transmit, denoted by
. Each transmission of
i can be scheduled using a SF
f (
) with an associated payload
. Given
f and
, we can calculate the packet transmission time
[
34].
Let be the set of available spreading factors. To each SF , we associate a set of time slots starting at time j, where is the global upper limit in number of slots. These slots have duration for the given node’s payload and SF, where corresponds to the guard time.
We associate a set of forbidden slots to each slot . This set contains all the slots of the same SF (i.e., ), and of other SFs (i.e., ) such that , for 1% duty cycle. If a node uses to transmit data, then the duty cycle restriction forbids the node to use any slot in . Apparently, this constraint can be eliminated when no radio duty cycle restrictions exist.
Given the previous input parameters of the problem, we define the following set of binary variables:
The linear program to optimally schedule bulk data transmissions is defined as follows:
The objective function (
6) seeks to minimise the length of the longest frame among all SFs. The end of the frame occurs at time
because the last transmission starts at
and lasts for
amount of time. To determine which slot is the last one used, we need to multiply
with the sum over all variables
. Indeed, there can be only one node using a slot, so this sum is either 0 (the slot is not used) or 1 (the slot is used by one node). Thus, the result of
gives the time
of the longest frame. To get a linear equation removing the maximum function, we add the following set of constraints:
where
is a continuous variable whose purpose is to keep track of the maximum frame length, which is what we want to minimise in our problem.
Summarising, Equation (
7) verifies that at most one node can use a slot. Equation (
8) forbids a node to use non-permitted SFs. Equation (
9) ensures that all nodes get to send their total amount of data. Finally, Equation (
10) verifies the duty cycle restrictions using sets
defined above. This last constraint can be eliminated in the case of LoRa operating in the 2.4 GHz ISM band where no radio duty cycle restrictions exist [
35].
The hardness of the model stems from the fact that a very large range of slots for all 6 SFs (or 8 for 2.4 GHz LoRa) is evaluated for each possible transmission. This results in a very long sequence of possible iterations. The problem can be alleviated by setting a maximum frame length per SF which is translated to a maximum number of slots to be evaluated. However, we need to define how this value is chosen. For example, allowing too many slots in each frame increases dramatically the number of binary variables of our model (recall that there is a single y variable per node and per slot). On the contrary, if we do not reserve enough slots for each SF, especially for SF7 which is the most utilised spreading factor, the linear program can still find a solution with the given slots. In this case, the schedule will be optimal only for the given settings but not globally optimal. Since most of the transmissions are accommodated in the SF7 frame, the value of is selected through a trial and error method so that the frame of SF7 is large enough to find the optimal schedule.
Nevertheless, the linear program still requires to test a high number of variables per transmission, upper-bounded by
, which may limit the practicality of the computational solution to low node numbers only. For deployments with many nodes, time-efficient heuristics such as the
Light and
Global heuristics presented in [
11] can be used. The two heuristics differ in the way they handle transmissions and how they divide the schedule into frames. The first algorithm,
Light, schedules only the first transmission for each node and repeats that in subsequent frames. The second approach,
Global, computes the schedule for all transmissions and, as a consequence, produces a sequence of frames that may differ to each other. As a result,
Global can compute more efficient schedules than
Light in terms of data collection time, however, this comes at the expense of a higher computation cost, a larger schedule size, and a higher implementation complexity.
7. Proof of Concept and Experimental Results
7.1. System Setup and Procedure
In order to verify our approach also in experiments with real node deployments, we created a proof-of-concept implementation consisting of 10 nodes located across two adjacent, multi-floor buildings. Independent, co-located LoRaWAN networks also existed in the area. The top view with indicative node positions is illustrated in
Figure 7. The gateway is located at the first floor on the edge of the upper-hand building. The maximum (reliable) indoor range that was achieved with SF7 was approximately 60 m using typical 2 dBi antennas for both the nodes and the gateway. This low range is justified by the presence of multiple concrete and stone walls which cause a very strong signal attenuation. The purpose of the experiments is not to show the superiority of the scheduling approaches over the rest of the methods since this would require a network of at least 100 nodes along with very high financial and time resources. Thus, we limit the purpose of the experiments to assess the following practical issues:
to assess the feasibility of using time-slotted scheduling algorithms under real conditions,
to assess the downlink transmission time of the schedule,
to assess the feasibility of computing the schedule on the nodes instead of computing it centrally on the gateway and then disseminating it to the nodes, and
to assess confirmed transmissions.
LoRa-enabled devices from Pycom in the Netherlands where used for the purpose of the experiments. For experimental efficiency, an amount of data was already generated and loaded onto the nodes’ storage module. Each node position was initially evaluated for its connectivity requirements in terms of transmit power and SF. We did this test manually, however LoRaWAN’s ADR mechanism can be used to automatically calculate and adjust the SF according to the latest conditions (the embedded code of the gateway and the nodes is available at
https://github.com/deltazita/offline-lora (accessed on 3 February 2021) and at
https://github.com/deltazita/ts-lora (accessed on 3 February 2021)).
Table 3 summarises the experimental parameters and their corresponding values.
The entire process of computing the schedule, communicating it to the nodes, and receiving the data is illustrated in
Figure 8. Moreover, an overview of the network architecture is presented in
Figure 9. We used a Raspberry Pi (here representing the network server) to compute the schedule. The Raspberry Pi can also optionally send additional information related to the experimental process, such as the guard time, the synchronisation rate, and the channel bandwidth. A gateway is responsible for registering nodes to the network, while another gateway is used for data collection. A third gateway can optionally be used for statistic collection in case of confirmed transmissions (i.e., the nodes can send out data about the ack rate). All the gateways communicate with the Raspberry Pi via secure WiFi links. The data gateway receives the schedule and forwards it to the nodes. To do so, the nodes must have their radio on and listen to a specific channel, BW, and SF. These settings are fixed and do not change throughout the process, thus, they can be flashed into the nodes during their setup by a system administrator. In the experiments, we used the highest SF in the network so that all nodes regardless of their SF can receive the schedule. An alternative approach would be to send the schedule multiple times based on the available SFs in the network. However, this would require additional setup time and probably to a waste of energy for the nodes, unless multiple LoRa gateways were used (one gateway for each available SF).
We run each experiment 10 times and the average results are presented along with the minimum and the maximum values. We measure the schedule transmission time, the data collection time, the active radio time and the packet delivery ratio for the 10-node testbed.
Data transmissions are performed in the allocated time slots using the assigned SFs as computed by the scheduler. The nodes have their radio off during the rest of the period, however, they periodically need to turn on their radio to receive synchronisation packets from the gateway. The synchronisation is achieved using an additional slot at the end of a frame as it was presented in
Section 4.1. The reader can find more information about this mechanism in [
31].
7.2. Transmission of the Schedule
Here, we present experimental results related to the transmission of the schedule. This includes an evaluation of the capability of the gateway to efficiently compute and encode the schedule. No physical presence of the nodes themselves is required. As a consequence, we can experiment with more than 10 nodes.
In Light, the schedule consists of a set of tuples indicating the node id, the SF, and the slot number (i.e., [id, sf, slot]). For example, in our 10-node deployment this results in a 70 byte schedule. Some extra bytes are added to indicate the gateway id, the guard time, and the sync packet rate. In total, 78 bytes are sent. In terms of transmission time this translates to 35 ms with SF7 or 698 ms with SF12.
Global uses a more sophisticated data encoding to represent the repetition of the frames in the schedule. Recall that in Global all the packets are scheduled, thus, a collection of frames is generated. A straightforward solution would be to include the node ids, their SFs, and their slots for all the computed frames in the schedule. However, this solution does not scale because the number of bytes increases linearly with the number of transmissions. On the contrary, since a big range of successive transmissions is scheduled on the same SF and slot, one way to reduce the total number of bytes is to use a run-length encoding data compression algorithm. For example, in our testbed, only the last transmission of one node is relocated to SF8. Thus, all the previous transmissions can be indicated using a single tuple. The general encoding pattern of a node’s transmissions is the following: [id first_frame_sf last_frame_sf sf slot, start_frame_sf’ end_frame_sf’ sf’ slot’, ...]. In our experiments, the total schedule length with Global is 154 bytes. In terms of transmission time this translates to 6.3 ms and 1.23 s with SF7 and SF12, respectively.
Every node that receives the schedule, decodes the data and calculates the frame length for its assigned SF. In Global, this must be done for all the assigned SFs which incurs additional coding effort. The schedule transmission is followed by a very short init packet which actually initiates the data collection process. In the Aloha-based approach, the schedule transmission is omitted, thus, only the init packet is used.
Table 4 illustrates the total theoretical schedule transmission time for different node populations using SF7. We examine the scenario where the schedule is sent based on an ideal setup where no duty cycle restrictions are imposed as well as when the duty cycle rules are followed. We should note that the first case occurs when transmissions are sent in non-restricted bands (e.g., 2.4 GHz LoRa). We can observe that, in the first case, the transmission of the schedule is quite fast for up to 100 nodes.
Light scales very well with less than 4 s transmission time for 1000 nodes. On the contrary, as the number of nodes increases,
Global’s schedule becomes very long and, thus, difficult to be transmitted in a reasonable period of time, especially when the duty cycle rules have to be followed. This is because each node’s transmissions may jump from one SF to another causing many non-periodic slot allocations in successive frames. Letting the nodes know these SF jumps, requires extra bytes and, thus, more time.
To overcome the scalability issue of
Global, we follow an alternative approach [
11]. We disengage the computation of the schedule from the gateway (network server) and we move this process to the nodes. In this way, we transmit only the list of nodes and their minimum SFs, and we let the nodes compute the schedule. Since this list is usually multiple times shorter in size than the schedule, it can be transmitted in a shorter amount of time. It should be noted that this action leads to a trade-off between processing and communication time. In order to evaluate this trade-off, we implement
Global on our testbed devices. Due to the limited memory resources (only 4 MB), the nodes compute the entire schedule but they generate a list of transmissions (i.e., slots and SFs) only for their own id. The input transmission time, as well as the schedule computation time, are displayed in
Table 5. The results show an up to 78% improvement in total transmission time in the case without duty cycle restrictions and an over 800% improvement when the duty cycle rules are followed. We also need to stress here that the energy consumption in processing mode is comparable to the receiving cost (i.e., ∼50 mA), so the nodes do not spend more energy compared to when the schedule was transmitted by the gateway.
7.3. Confirmed vs. Non-Confirmed Traffic
Finally, in the last experiment, we assess the behaviour of the approaches when re-transmissions can occur. For the needs of these experiments, we also developed approaches that allow re-transmissions of packets in order to capture the effect of acknowledgments in the data collection time and in other measurements. All the nodes transmit 100 unique packets, while maximum 3 retransmissions per packet are allowed before the packet gets dropped. For the time-slotted approaches (i.e., Slotted-Aloha,
Light,
Global, and TS-LoRa) the acknowledgments are sent in groups during the SACK packet. The periodicity of the SACK packet is communicated to the nodes at the beginning of the process. In the Pure Aloha approach, acknowledgements are sent similarly to LoRaWAN, using two receive windows.
Figure 10 depicts the average data collection time, the PDR, and the active radio time for the experiments. Due to the low number of nodes, all collision-free approaches presented identical results. Thus, the label “CF” refers to all these approaches, while the label “CF-ACK” refers to their confirmed version. Moreover, we must mention that the two heuristic scheduling approaches were able to generate optimal schedules. The results reveal that in terms of data collection time, there is a 10% overhead due to synchronisation compared to the optimal solution. This overhead is apparently higher in case of re-transmissions. The two Aloha approaches present the highest overhead due to higher number of collisions and, thus, more time is required because of the re-transmissions. As it was expected, the PDR is very high for the collision-free approaches and ranges from 98% to 99.8%. Because no intra-network collisions occur, some packets were lost due to the path-loss effects and the presence of external interference. Slotted-Aloha performs close enough in confirmed traffic. This is because in our implementation acknowledgements are sent straight away after the reception of packet (unlike LoRaWAN where 1 or 2 s delay is imposed). Finally, as it was expected, the slotted approaches exhibit a higher energy cost compared to Pure Aloha without acknowledgements but they present a better performance than Aloha in the case of confirmed transmissions. The reason that this occurs is that in the frame structure of TS-LoRa (which is also followed by
Light and
Global), the acknowledgements are sent in groups at the end of the slot. This minimizes the number of bytes received by the nodes and, thus, their energy consumption.