LoRaHART: Hardware-Aware Real-Time Scheduling for LoRa

LMAC is inspired by the 802.11 Distributed Coordination Function (DCF) [30]. When a node initiates a transmission on its assigned Channel/SF ($ch$/$sf$), it first waits for a Distributed Inter-Frame Space (DIFS) duration, during which it performs $12$ Channel Activity Detection (CAD) operations. If all CADs report an idle channel, the node randomly selects a backoff value $N_{\mathrm{BO}}\in \{0,1,\mathrm{\dots },b-1\}$ and periodically senses the channel and decrements this counter if the channel is idle. Here $b$ is an integer value which can be chosen empirically based on the number of nodes. In the event that the channel is sensed to be busy during this countdown, the node freezes its backoff counter, reverts to DIFS mode where it performs CAD, and resumes the countdown only when the channel is idle again. Moreover, nodes do not receive acknowledgments for data packets transmitted during this LMAC window; thus, each node may only get a single chance to transmit its message within RTx. For more details on LMAC, please see [16].

We derive a closed-form expression for the probability of a successful transmission ($P_{success}$) under the assumption that the maximum backoff value $b$ for a $ch/sf$ is limited by the ratio $T_{RTx}/T_{tx}$, where $T_{tx}$ represents the airtime of a message. This is a reasonable assumption because it ensures that in the worst-case, where backoff countdown freezes for a duration of $T_{tx}$ at each value, when the countdown completes there is still sufficient remaining time for the node to attempt a transmission in RTx. Furthermore, since any node transmitting after the current transmission must wait for a DIFS interval before sending a packet, we merge this DIFS duration into $T_{tx}$ for simplicity.

Suppose $N_{\mathrm{BO}}=s\le b-1$ for some node. Note, by the above assumption and a node transmits only when the backoff counter reaches $0$. Since backoff values are chosen uniformly at random from the range $\{0,\mathrm{\dots },b-1\}$, the probability of selecting any particular value $s$ is: $P_{\text{tx}}=1/b$. A transmission is considered successful if no other node selects the same backoff value $s$. The probability that none of the remaining $(k-1)$ nodes select the same value $s$ can be given as: $P_{success}={\left(1-1/b\right)}^{k-1}$.

Since each of the $k$ nodes is successful with probability $P_{\mathrm{success}}$ (independently), the expected number of total successful transmissions for a $ch$/$sf$ combination having $k$ contending nodes in the retransmission window can be obtained via linearity of expectation as: $𝔼[\text{\# successes}]={\sum }_k{P}_{success}=k\cdot P_{\mathrm{success}}$.

Messages are sorted based on periods following the rate monotonic strategy (Line 1), which takes $O(n\log n)$ time for $n$ messages. For each of the $h/p_i$ instances of message $m_i$, the algorithm evaluates up to $p_i/p_1$ candidate super-frames. This results in a total of $O\left(n\cdot h/p_1\right)$ invocations of MCP. Each invocation of MCP has a complexity of $O(n\log n)$, where $n$ is the maximum number of message instances in any super-frame. Therefore, the overall complexity for MFP is: $O\left(h/p_1\cdot n^2\log n\right).$ Note, if periods are harmonic and the ratio of largest to smallest period can be regarded as a constant (a common setting in many real-world industrial and IoT applications [28]), this complexity becomes quadratic.

The scheduling strategy of RT-LoRa differs fundamentally from that of LoRaHART. In RT-LoRa, all periodic application layer transmissions are assumed to have the same generation period which is a very strong assumption that greatly simplifies the scheduling problem unlike the transmission model considered in this paper. Thus, each periodic real-time transmission in RT-LoRa is required to be scheduled in every super-frame, eliminating the need for a message instance to super-frame packing algorithm. Further, under RT-LoRa, nodes select an appropriate SF for their transmissions based on reception quality of the gateway beacon as well as their QoS requirements. Specifically, RT-LoRa uses SF-based grouping, where each spreading factor is mapped to a subset of available channels, and messages within the same SF group are allocated to different channels. Scheduling within a super-frame is then performed by assigning one slot per transmission with the slot length based on SF-based airtime. In contrast, LoRaHART uses a two-stage scheduling mechanism that performs both super-frame mapping and intra-frame channel packing using a packing algorithm, which provides greater flexibility for heterogeneous periods and more efficient channel utilization. Nevertheless, RT-LoRa assumes the application layer operates asynchronously with the MAC layer. As a result, a message may miss its assigned slot within the current super-frame and must wait until the next super-frame for transmission. They provide a closed-form expression to compute this worst-case delay, and consider the generated schedule to be feasible if this delay is no more than the deadline for all the transmissions; otherwise, the transmission SF must be adjusted to generate a new schedule. Note, since the transmission model used in RT-LoRa is very simple (all period values are the same), their proposed scheduling approach cannot be applied for the model considered in this paper and hence we did not evaluate RT-LoRa in our experiments.

Consider any feasible schedule such that there is at least one message instance $m_{i,j}$ which is scheduled using a SF higher than its smallest feasible SF $s{f}_i$. Note the slot length used by $m_{i,j}$ is equal to or higher than $L_i$, because the slot length required to transmit the message using a higher SF is at least as much as the one required for $s{f}_i$. Then, we can swap the slot for $m_{i,j}$ with a slot of length $L_i$ so that the message instance can use its smallest feasible SF for transmission. The resulting schedule is also a feasible schedule, because in LoRaHART no concurrent transmission will be allocated to the same channel as $m_{i,j}$. $◀$

LoRaHART currently maps eight concurrent transmissions directly onto the eight available channels. Even if it does not fully exploit the orthogonality of LoRa’s spreading factors, it still aligns with the current hardware capabilities, by delivering a practical, hardware-aware solution for today’s deployments. If the hardware evolves and gateways begin to support more parallel demodulators, new opportunities will emerge. In particular, future versions of LoRaHART could leverage SF orthogonality to allow multiple transmissions on the same channel, provided they use different SFs. For instance, if a gateway supports 16 parallel demodulators, the MFP algorithm could be extended to schedule two sets of transmissions per super-frame, ensuring that two overlapping transmissions on the same channel do not share the same SF. To incorporate this into the existing design, minor modifications would be required in the MCP algorithm. Specifically, during the packing phase (lines 5–14), when adding a message instance $m_i$ to a channel $l$, an additional check should be introduced to verify that no other message in that channel uses the same SF within the slot under consideration. This can be enforced by augmenting each channel group $P_{1,l}$ with the set of SFs currently assigned in that slot and rejecting the addition of any new message with a duplicate SF. Similar care must be taken during the merging phase (lines 16–19), where the SF uniqueness constraint must be respected to avoid interference. This adaptation would improve channel utilization while preserving real-time guarantees, making it a promising direction for scaling LoRaHART alongside advancements in the LoRa gateway technology.

LoRaHART uses an offline scheduling approach, where the computed schedule is uploaded to the nodes prior to deployment. However, in real-world settings, dynamic changes such as node joins, departures or variations in required SFs (due to mobility or environmental factors) may necessitate schedule updates. Typically, nodes report such changes to the network server via metadata embedded in control messages or periodic link-quality monitoring. Once the network server detects a topology change, it can initiate re-scheduling. To avoid recomputing the entire schedule from scratch, we can use an incremental scheduling approach in LoRaHART. The existing transmission-to-super-frame mapping can be reused for all nodes whose transmission parameters (e.g., SF) remain unchanged. The scheduling algorithm can then be re-invoked with this partial mapping as the starting point. New or modified nodes can be scheduled using LoRaHART and if all new mappings are feasible, the updated schedule can be produced without impacting the rest of the network. To support this incremental scheduling, the MCP algorithm must also be adapted to ensure that existing message-to-channel assignments are preserved during re-packing. Specifically, when invoking MCP during incremental scheduling, the already scheduled messages (whose SFs or deadlines remain unchanged) should be treated as fixed assignments within their original super-frame and channel. The candidate message instances (from newly joined or modified nodes) are then packed into the remaining available channels and slots without altering the current placements. Thus, by anchoring pre-existing allocations and only attempting to fit the new/modified messages around them, the updated MCP ensures incremental packing is feasible and efficient, provided sufficient residual capacity is available.

We constructed a 40-node LoRa testbed to evaluate the performance of real-time scheduling algorithms on COTS LoRa hardware. Four design goals guided this setup: first, the testbed needed to support sparse deployments across a large university laboratory; second, a central controller was required to manage the firmware of all the nodes; third, each node needed a backhaul link for centralized metadata collection; and finally, synchronization across all 40 nodes was essential to enable real-time scheduling.

Backhaul links in testbeds are essential for loading firmware onto nodes and collecting ground-truth data, such as the packet count from each node, needed for performance calculations. However, LoRa’s narrowband modulation limits its capacity to transfer such data. Physically connecting all 40 nodes to a single controller would simplify firmware loading and data extraction, but this would compromise the distributed nature of the testbed. Instead, we deploy ten distributed controllers, each managing four LoRa nodes, along with a central controller that collates data. These controllers, implemented as single-board computers, communicate over WiFi. The distributed controllers load firmware and relay experimental information as needed between the LoRa nodes and the central controller.

The testbed uses Heltec Stick Lite V3 [4] LoRa nodes with integrated SX1262 LoRa radios. Communication between the LoRa nodes and distributed controllers (e.g., for firmware uploads and backhaul data transfers) is facilitated via an emulated USB-serial interface. Fig. 6a illustrates the connectivity between each component of the testbed, Fig. 6b shows an image of the testbed hardware and Fig. 6c shows the outdoor gateway. To address the requirement of supporting geographically distributed nodes, distributed controllers communicate through a network tunnel [10] with the central controller. As the LoRa gateway, we utilize a COTS LoRa gateway [27, 36]. To capture realistic performance, we conduct experiments both indoors and outdoors, as these represent typical deployment scenarios for LoRa networks. Indoor settings often involve higher multipath propagation and increased interference due to walls and objects, whereas outdoor conditions are more affected by non-line-of-sight (NLoS) propagation, with no direct line-of-sight to nodes. For outdoor experiments, the same central and distributed controllers were used, but with the gateway located outside the laboratory. Unlike the indoor setup, where many nodes had line-of-sight to the gateway, the outdoor setup had no nodes in direct line-of-sight to the gateway.

Before each experiment, the central controller generates a unique pre-compiled binary program for each LoRa node, as each node’s schedule is distinct, even under the same protocol. Once devices are confirmed as ready, the central controller issues a start command to initiate the experiment. Each LoRa packet in our experiments contains a 26-byte payload with the following data: 1) node ID, 2) a packet counter, 3) transmission start time, and 4) padding bits.

An experiment includes the following steps: loading a unique schedule consisting of multiple test cases into each LoRa node, nodes awaiting a start signal in terms of a gateway beacon and upon which executing super-frame by super-frame until all the test cases are completed. Upon receiving the first gateway beacon, all nodes set time $t=0$ and transmissions follow the schedule. The schedule for multiple test cases are loaded one after the other sequentially for convenience;

The LoRa devices in our testbed utilize built-in Temperature Compensated Oscillators (TCXOs) to maintain synchronization over prolonged periods. By sampling the micro-controller time every $30$ seconds over one hour, we observed no drift at the second-level accuracy. Hence, we set our slot size as a multiple of unit-second in our experiments.

In our experiments, multiple test cases were deployed in three groups consisting of $8$, $24$ and $40$ node testbeds to cater for low, moderate and high density deployments. We fix the minimum period, $p_1$, to $20$ seconds. This is a reasonable sensing/actuation period for real-time LPWAN applications [42]. For each test case, we selected at least four different period values – including the mandatory period of $20$ seconds – and randomly chose the remaining period values such that their Least Common Multiple (LCM) did not exceed $720$ seconds, due to storage limitations of the micro-controller. Each node was then randomly assigned a period from the selected list, ensuring that every period was allocated to at least one node. Finally, nodes were assigned SFs at random.

We set the following slot parameters calculated with respect to a packet size of $26$ bytes. We selected the slot lengths ($L$) as $1$ second for SF7, SF8 and SF9 transmissions, $2$ seconds for SF10 and SF11 transmissions, and $4$ seconds for SF12 transmissions. These are sufficient to accommodate the transmissions for the assigned SFs.

The duration allocated for the beacon segment is $2$ seconds as the packet size for beacon is comparatively small and therefore requires only $2$ seconds to transmit even with SF12. In our experiments, we set $T_{TDMA}$ to be fixed at $10$ seconds, followed by a multicast ACK segment of $3$ seconds and a retransmission RTx segment of $5$ seconds at the end of the super-frame. This ensures that even a SF12 transmission with a slot length of $4$ seconds can attempt a retransmission in the RTx segment if required with an additional time of one second allocated for LMAC’s DIFS and backoff mechanism.

Demand for each test case, $D$, is calculated as the ratio of total slot lengths occupied by the messages generated by $ℳ$ to $8$ times the total time duration for an hyper-frame. Test cases were then categorized by demand levels: $D\in [0.01,0.15]$ as low, $D\in (0.15,0.3]$ as moderate (mod), and $D\in (0.3,0.5]$ as high. Note that demand values higher than $0.5$ are not feasible since $T_{TDMA}$ is exactly half the duration of a super-frame in our experiments.

To achieve specific target demands ranging from $0$ to $0.5$, we systematically adjusted the periods and SFs of multiple nodes. Specifically, to increase demand, we decreased the periods (resulting in more frequent transmissions) or increased the SFs (leading to longer slot durations) and vice versa. These adjustments are performed iteratively on multiple nodes ensuring that the period and lcm requirements are met. Finally, the demand is recalculated after each iteration to check whether it is within an acceptable margin of $\pm 0.01$.

We compare with two baselines, RTPL and RTLS. We deploy RTPL on our testbed exactly as recommended in [12]. RTPL by design allocates a significantly higher duration than necessary for all SFs. For example, an SF7 packet of $26$ bytes with an airtime of $61.7$ ms is allocated $7$ seconds as recommended in RTPL. In Section 7.3, we remove this limitation when evaluating the schedulability of RTPL using our super-frame structure for a fair comparison. This under-utilization leads to inefficient use of the spectrum and hence RTPL could not schedule any moderate/high demand test cases in our experiments. For RTLS, we use slot lengths ranging from $3$ seconds for SF7 to $15$ seconds for SF12. These durations are calculated based on a $26$-byte data packet as suggested in [14].

Finally, for each demand range, we selected the test cases that were deemed schedulable by the protocols (all three for the low range, and RTLS and LoRaHART for the moderate and high ranges). As such, we deployed $20$ test cases for each demand range on the testbed.

In Fig. 7, we present the experiment results using standard box-plots comparing the performance of the three protocols in terms of Packet Reception Ratio (PRR) over the hyper-period. If a packet is successfully received and demodulated by the gateway before its deadline, then it contributes to PRR. Note that a packet could fail to be delivered to the gateway due to inherent transient failures of the wireless medium. Although protocols like LoRaHART and RTPL reduce the impact of such failures by supporting retransmissions, nevertheless they cannot deterministically guarantee packet delivery. Hence, the PRR for a test case can be lower than $1$ even if a test case is deemed to be schedulable by a protocol. Figs. 7(a) and 7(b) show the PRR for various values of demand in the low range ($D\in [0.01,0.15]$) comparing the performance of all three protocols; Fig. 7(a) (likewise Fig. 7(b)) illustrates the results for indoor (likewise outdoor) experiments. Similarly, Fig. 7(c) illustrates the results for moderate and high demand ranges, comparing the performance of LoRaHART and RTLS.

Figs. 7(a) and 7(b) show that for the low demand range, LoRaHART significantly outperforms both RTPL and RTLS in terms of achieved PRR, with its mean PRR value being arbitrarily close to $1$. In particular, for the indoor setting, the mean PRR value for LoRaHART is $0.98$, which is $25\%$ higher than the mean PRR for RTPL and $8\%$ higher than the mean PRR for RTLS. Similarly, for the outdoor setting, the mean PRR value for LoRaHART is $1$, which is $30\%$ higher than the mean PRR for RTPL and $10\%$ higher than the mean PRR for RTLS. It is noteworthy that the performance of LoRaHART does not vary much between the indoor and outdoor settings, illustrating its robustness and superior ability to handle transmission failures. In contrast, RTPL exhibits several missed deadlines, mainly due to demodulation issues arising at the gateway from more than $8$ concurrent transmissions. The degradation for RTPL is more pronounced with increasing demand and noise (outdoor vs. indoor), which is expected. RTLS, on the other hand, shows better performance than RTPL, because by design it limits the number of concurrent transmissions to no more than $6$, one per SF. However, RTLS still has a much lower PRR than LoRaHART, due to the absence of retransmissions.

In Fig. 7(c) we compare LoRaHART and RTLS for moderate and high demand values in the indoor setting (results are similar for the outdoor setting, but omitted due to space constraints). Here as well, LoRaHART significantly outperforms RTLS, achieving a mean PRR of $0.97$, which is $24\%$ higher than the mean PRR for RTLS. A final remark is that both RTPL and RTLS show much greater variability in their PRR values when compared to LoRaHART, and this is because, unlike LoRaHART, they both allow multiple concurrent transmissions with different SFs in the same channel. Although LoRa specification allows for such concurrency, it typically reduces the signal-to-noise ratio leading to lower PRRs.

Recall from Section 3 that a COTS LoRa gateway has only $8$ concurrent demodulators. Fig. 8 shows, from $t_0$ to $t_1$ (likewise from $t_2$ to $t_3$), a capture of all the $8$ channels during the runtime of RTPL (likewise LoRaHART). It can be seen that channels cumulatively occupy more than $8$ concurrent transmissions in RTPL, which cannot be successfully demodulated.

Our experimental observations reveal important performance implications for RT-LoRa when compared to LoRaHART. Like RTPL, RT-LoRa schedules the maximum number of parallel transmissions allowed, without restricting the number of CH/SF combinations. As a result, it faces the same gateway limitation on concurrent demodulations as RTPL. Under high network loads, when concurrent transmissions exceed hardware capacity, this bottleneck can lead to degraded Packet Reception Rates (PRR) as shown in Figure 7. In addition, recall that RT-LoRa does not incorporate any retransmission mechanisms for failed transmissions. This will further reduce the effective PRR for RT-LoRa even in comparison to RTPL.

Fig. 9 presents the results of the schedulability experiments that were conducted. Fig. 9(a) shows the acceptance ratios of the three protocols when they were evaluated with $1000$ test cases across a variety of demand ranges. These test cases were generated using the same technique as described in Section 7.2, with $250$ test cases for each demand range shown in the figure. The acceptance ratio of LoRaHART is significantly higher than that of RTLS, clearly demonstrating the superiority of the proposed scheduling strategy. RTLS heavily under-utilizes available channels due to its SF based scheduling, with spectrum not being used efficiently in each frame. This accumulates significantly across the hyper-frame, resulting in reduced schedulability for high-demands. When compared to RTPL, LoRaHART has an overall acceptance ratio that is $10\%$ higher, with the gap increasing for higher demand values. Taken together with the outcomes in Section 7.2, we can conclude that LoRaHART dominates both RTPL and RTLS in terms of acceptance ratio as well as PRR, and hence in terms of the ability to support LoRa-based real-time communication.

We also conducted experiments to evaluate the performance of the schedules in the above test cases that all use the same super-frame structure. For this comparison, we chose $20$ schedules with the highest demands for each protocol. Note these test cases may be different for each protocol. The PRR drop in Figure 9(b) for LoRaHART validates the gain achieved by the retransmissions using LMAC shown in Figure 7. We expect PRR to be similar across the three protocols, because all the schedules respect the COTS LoRa gateway restrictions and do not allow retransmissions. Hence, we need another metric such as throughput which measures the number of packets successfully delivered for comparison. However, an algorithm that prioritizes packing packets of lower SFs may achieve higher throughput due to their shorter airtimes. Such algorithms fail to fit the diverse range of SFs necessary to accommodate nodes operating across a LoRa network. This phenomena renders throughput an inadequate performance metric in this comparison. To address this limitation, we employ a new metric – Effective Cumulative Airtime Utilization (ECAU). ECAU reflects an algorithm’s packing efficiency in terms of received packets weighted by their corresponding airtime utilization. ECAU is defined as: ${\sum }_{m_z}{T}_{t{x}_z}$, where $m_z$ denotes a message, $T_{t{x}_z}$ denotes its airtime and the sum is computed across all the messages received within the hyper-period.

Fig. 9(c) shows the ECAU values for the three protocols across the $20$ test cases. In the figure, RTPL₁ is the implementation of RTPL as described earlier in this section, and RTPL₂ is a variant which ensures that the $8$ concurrent transmissions are mapped to $8$ different channels similar to LoRaHART. On an average, the ECAU value for LoRaHART is $45\%$ higher than RTPL₁ and RTPL₂ and $200\%$ higher than RTLS. This clearly demonstrates that LoRaHART is significantly better in managing airtime at higher demands, when compared to the baselines. This, taken together with the acceptance ratios, shows that LoRaHART outperforms both RTPL and RTLS in terms of effectively utilizing the LoRa wireless medium for real-time communication, with the performance gap widening as message demand increases.