# Achieving reduced latency and energy efficiency in Direct-to-Satellite LoRaWAN communications

Florian Rolland, Zheng Zhou, Nicola Accettura, Pascal Berthou

► To cite this version:

Florian Rolland, Zheng Zhou, Nicola Accettura, Pascal Berthou. Achieving reduced latency and energy efficiency in Direct-to-Satellite LoRaWAN communications. 21st International IEEE Conference on Factory Communication Systems (WFCS 2025), Jun 2025, Rostock, Germany. 10.1109/WFCS63373.2025.11077617. [hal-05158569]

HAL Id: hal-05158569

https://hal.science/hal-05158569v1

Submitted on 11 Jul 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Achieving reduced latency and energy efficiency in Direct-to-Satellite LoRaWAN communications

Florian Rolland, Zheng Zhou, Nicola Accettura, and Pascal Berthou

LAAS-CNRS, Université de Toulouse, CNRS, UPS, Toulouse, France

Email: name.surname@laas.com

***Abstract***—Direct-to-satellite (DtS) communications are becoming increasingly popular in the field of connected objects, since Low Earth Orbit (LEO) satellites can be easily deployed at lower and lower costs. In fact, a DtS Internet of Things (IoT) paves the way for the development of an incredibly vast gamut of monitoring applications for very inaccessible areas, e.g., oceans, mountains, and deserts. In this context, the medium access protocol used for Long Range Wide Area Network (LoRaWAN) has recently been proposed as a viable solution for policing the communication between ground low power devices and LEO satellites equipped with LoRaWAN gateways. However, the default LoRaWAN medium access scheme is based on a “transmit first” policy that inevitably augments the collision rate among the increased number of concurrent devices in the satellite coverage. Instead, this paper focuses on a “listen first” policy enabled through LoRaWAN Class B beacons and the sole adoption of Activation-By-Personalization (ABP). In more detail, a wake-up strategy allowing ground LoRaWAN devices to intermittently switch on and off their own radio for listening to incoming beacons is studied and analyzed through simulations. By means of this investigation, it is possible to find the best timer settings guaranteeing a good compromise between energy-saving and the need to reduce the time to catch the first beacon. Some preliminary results related to the availability of a single LoRaWAN-enabled LEO satellite show that a reduction of 33% in energy consumption can be achieved at the cost of a slightly increased “first catch” time.

***Index Terms***—IoT, LEO, Wake-up strategies

## I. INTRODUCTION

The availability of very low power communication technologies connecting smart sensors and actuators to the Internet has definitely triggered the development of Internet of Things applications [1], including Smart Agriculture [2], Smart Grid and Smart Cities [3]. More recently, it has been recognized that it is possible to extend the scope of IoT to traditionally inaccessible areas, such as oceans, glaciers, or deserts, through the availability of nano satellites in the Low Earth Orbit (LEO) [4] providing ubiquitous Internet connectivity on the globe. The additional advantage of this configured scenario is its natural ability to provide a resilient infrastructure in case of disasters like tsunamis, earthquakes, or anything else that can affect the Internet access provided by terrestrial networks [4]. In this context, low power devices on the ground communicate through Direct-to-Satellite (DtS) IoT interactions by exploiting the medium access protocols defined for Low Power Wide Area Network (LPWAN) technologies [5]. Among these technologies, the most investigated ones are the Long Range Wide Area Network (LoRaWAN) developed by

Semtech and Narrowband IoT (NB-IoT) standardized by the Third Generation Partnership Project (3GPP).

However, an effective deployment of such an architecture is still hindered by some technological issues that need to be faced by the research community [6]. For instance, if low power devices are not aware of their own position on the planet, they cannot predict next satellite passes, so that they would be forced to continuously check if there is a satellite in their scope by either transmitting data (and waiting for an acknowledgment) or listening to beacons. In both cases, the induced energy waste dramatically reduces the lifetime of the concerned low power devices, while it is imperative to bound it in hostile environments. While the availability of a Global Navigation Satellite System (GNSS) transceiver would help the device in understanding its own location on the Earth, it would also make the DtS IoT architecture strictly dependent on the correct functioning of another technology, thus making the system not resilient in case of GNSS outages.

With this reasoning in mind, a GNSS-free wake-up strategy for DtS NB-IoT communications was designed [7], while the same problem has not been applied to DtS LoRaWAN connectivity. Timely, this paper deals with the definition of a wake-up strategy for DtS LoRaWAN networks able to save energy while minimizing the time needed by any ground end device to realize that a LEO satellite is in the scope. Ground devices implement LoRaWAN Class B, and they periodically switch on their radio to listen to possibly incoming Class B beacons broadcast from LoRaWAN gateways mounted on LEO satellites. It should be noted that the recommended way for a device to access the LoRaWAN network is to use the Over-The-Air Activation (OTAA) procedure, which forces a device to register in the associated network before trying to decode any downlink beacon. This registration is done by “transmitting first” a specific command to any LEO satellite equipped with a LoRaWAN gateway. This facet implies that any low power device should try to periodically send uplink OTAA Join Request frames until it gets the first downlink OTAA Join Accept frame, so that it can start listening to beacons. This strategy is not investigated in this preliminary analysis, since transmitting uplink is in general more energy consuming than listening for incoming downlink. In any case, the default OTAA-based configuration will be investigated in future works. Instead, this paper focuses on the alternative to OTAA, i.e., Activation By Personalization (ABP), which requires the device to be manually registered. In this way,
devices can use a “listen first” strategy to capture possible incoming Class B beacons, making it easily applicable in DtS contexts [8].

To help the reader dive into the investigation introduced so far, this contribution is organized as follows: Section II surveys the related work, while Section III describes the network scenario. Then, Section IV provides some simulation results with their analysis, and finally Section V draws conclusions.

## II. RELATED WORKS

The idea of using LoRaWAN Class B beacons to save energy has already been explored in the scientific literature. For example, on terrestrial LoRaWAN networks the ability to use Class B beacons has been proven to be a valid driver for Time Division Multiple Access (TDMA) on top of the default LoRaWAN Pure ALOHA access scheme [9]. In fact, by using beacons it is possible to make all devices aware of the same concept of time, thus making frame scheduling possible. It is also possible to skip listening to beacons in order to increase energy efficiency. This approach was adopted for DtS IoT by the SALSA algorithm [10]. Among the assumptions made in such a contribution, devices must be aware of both their own position and the satellite's one. The position is pre-configured on the device, while a signal is assumed to inform devices about the satellite's trajectory. In addition, each device is configured to use the OTAA activation procedure to perform a pre-registration with a terrestrial gateway. In [11], Pure and Slotted ALOHA are enhanced with the ability of each device to limit the uplink transmission rate to one frame per pass and make optimal use of bandwidth. However, devices must be aware of their own position and the trajectory of the satellite.

On the opposite, other works have tried to design DtS IoT communications by avoiding the previous knowledge of the satellite's orbital parameters. For instance, the algorithm proposed in [12] assumes that any device can calculate the visibility window by itself. However, the device is aware of its own position and knows the maximum elevation angle. The device needs to listen to a synchronization packet with satellite orbital information and UTC time. For energy efficiency, the device applies a wake-up strategy based on the worst visibility window of the satellite. This strategy ensures the reception of synchronization packets even in the shortest visibility windows. The proposed approach requires a modification to the LoRaWAN protocol, which is not a desirable feature. Instead, the approach described in [7] totally avoids the previous knowledge of the device position, while tackling NB-IoT DtS communications. Specifically, it has been shown that it is possible to use packets containing the satellite's orbital information to determine the satellite's next passage. A notable difference with respect to the approach presented in this paper is that the wake-up strategy is not based on the visibility window, but on the period of the standard synchronization packet supplied by 3GPP.

Other methods of waking up devices include the use of Wake-Up receivers (WuRX) [13], [14]. The main radio and the device are in sleep mode, while a secondary radio listens

for the wake-up radio signal. This method saves a great amount of energy, with near-zero latency. However, this approach was presented for ground networks with a range of only a few dozen meters, thus making it inapplicable in DtS IoT contexts.

## III. NETWORK SCENARIO

In this paper, a ground Class B LoRaWAN device tries to get connected to a single LEO satellite equipped with a LoRaWAN gateway. As part of the presented strategy, the LoRaWAN end device operates in “listen first” mode, i.e., it can transmit only after having listened to a beacon. LoRaWAN Class B enables the reception of beacons, which in turn favors downlink synchronization. In that, a “BEACON_RESERVED” time interval lasting 2.12 s is used by the LoRaWAN gateway on the LEO satellite to transmit a beacon frame that contains a preamble, a time precision field, a time field, and an optional gateway position field. The LEO satellite has a trajectory that is pre-calculated by the Skyfield library [15] with the Two-Line Elements [16] (TLE) data of Iridium 7 [17]. Specifically, its altitude is 780 km, while its inclination is 86.4°. Each beacon is transmitted every 128 s, according to the LoRaWAN specification [18].

The device is randomly placed on Earth with a latitude randomly picked between -75 and 75° according to the uniform distribution. Its longitude is also randomly selected between -180 and 180° according to the uniform distribution. A wake-up strategy is then implemented by each ground device as follows. It will alternate between a *Reception Window*, window for listening to beacons sent by satellite and a *Sleeping Time*, during which the device stops reception to save energy. The *Reception Window* is calculated as the sum of the transmission period (128 s) and one “BEACON_RESERVED” frame (2.12 s), for a total duration of 130.12 s. This specific size ensures the full reception of a beacon if a LoRaWAN enabled LEO satellite is passing within the scope of the device. Instead, the duration of the *Sleeping Time* is varied between 0 and 400 s with 0.5-second steps, and it is studied alongside this paper. The device is switched on and starts performing the wake-up strategy at a randomly picked delay with respect to the simulated satellite trajectory. In that, the delay is taken in the interval going from 0 to the time needed by the satellite to travel a single orbit, i.e., 100.3 min. This ensures that the results obtained are not influenced by the starting point of the simulation. In addition, the transmission can be received by the device if the elevation angle is greater than 30°. A frame is caught if it is fully received by the device.

Concerning the current drawn from batteries in a 1 hour time frame, the following values have been used, according to values specified for the SX1272 transmitter [19]: 11.2 mAh are consumed for listening, 2 µAh when it is turned off.

## IV. SIMULATION RESULTS

The preliminary results presented throughout this paper are obtained by means of ad-hoc Python-based simulations. In detail, a simulation scenario is related to a single end device on the ground trying to listen to the first Class B beacon from
<figure><img src="image_2.png" /><figcaption>Fig. 1. Impact of sleeping time on (a) first catch time and (b) energy consumption with a 130.12 s reception window.</figcaption></figure>

a single LEO satellite equipped with a LoRaWAN gateway. Each simulation scenario has been obtained by varying the random parameters introduced in the previous section, i.e., the latitude of the end device, its longitude, and the time when it is switched on. The satellite's trajectory is simulated from August 15, 2023 (Considered as a time reference in each scenario) to October 15, 2023 using Skyfield [15]. For each scenario, the library is used to calculate the beginning and end of each of the satellite's passages. A calculation is made to determine whether the satellite will transmit the entire Beacon packet during its passage. If so, the same calculation is made to determine whether the device has its receive window open during the entire transmission. If this condition is met, the package is considered received. A total of 4000 simulation scenarios have been considered. For each simulation scenario, 800 simulations were run, each featuring a specific value of the *Sleeping Time*, as pictured in the previous section. The resulting 4000 simulation outcomes related to any given value of *Sleeping Time* have been averaged and reported in the next part of this section.

Specifically, Fig. 1a shows the average time required to catch a beacon frame sent by the LEO satellite gateway as a function of the *Sleeping Time*. Two distinct behaviors can be detected. For values of the *Sleeping Time* ranging from 0 to 121 s, the First Catch Time slightly increases from 10.7 to 13.7 h with a constant slope. Instead, for a *Sleeping Time* higher than 121 s the First Catch Time increases faster and less regularly and the catch time increases much more significantly. This same pattern was observed for NB-IoT DtS in [7]. This is probably due to a sleeping period that is far too long in relation to the satellite's visibility time. The probability of missing a pass, and therefore of being tuned in before or after the pass, is becoming increasingly high. As a result, the time to catch the beacon frame can no longer be guaranteed. A maximum difference of 70 h for a 0.5-second variation in the *Sleeping Time* parameter can be observed.

Interestingly, Fig. 1b presents the relation between *Sleeping Time* and the energy consumed before catching the first Class B beacon. The two distinct behaviors observed before are also visible in this analysis. A significant reduction in energy consumption is observed, from 120 mAh for a *Sleeping Time*

of 0 to 79.4 mAh for a *Sleeping Time* of 121 s. Beyond that, however, the reduction is almost negligible. A minimum energy consumption of 75.3 mAh is reached for a sleep time of 391.5 s, yet this would correspond to a bigger First Catch Time. However, for values of the *Sleeping Time* bigger than 121 s, the variability in the measured energy consumption makes it preferable to choose the *Sleeping Time* in the range between 0 and 121 s.

Through these preliminary results, an optimal balance can be achieved between the time to catch beacon frames and energy consumption. With 121 s for the *Sleeping Time*, this reception can be ensured in 13.7 h on average, for a power consumption of 79.2 mAh. A device with continuous listening performs the same capture in an average of 10.7 h for 120 mAh, an increase of around 33%. The cost of these energy savings is only 3 h. From the analysis performed, it has been found that the variability of the first catch time is very high. For example, it ranges from 2 m to 89 h when the *Sleeping Time* is 121 s. For this reason, real-time applications cannot be supported when there is a single LoRaWAN-enabled satellite.

After studying the *Sleeping Time* parameter effect on the catch time and the energy needed, the same analysis has been done by varying the size of the *Reception Window* to be either half or double compared to the previous case. The considered network scenarios are unchanged. Fig. 2a shows the “first catch” time and the energy consumed in relation to *Sleeping Time*. The optimum parameter cannot be easily defined. Two optima can be selected. The first optimum for 27 s of *Sleeping Time* captures the beacon frame in 12.1 h for 95.4 mAh. The second optimum captures the beacon frame in 19.8 h at 79.6 mAh for a *Sleeping Time* of 116 s. The cost to ensure a lower latency of 7.7 h is 15.8 mAh. With the first optimum, a 33.6% energy saving for a cost of additional 9.5 h is observed with respect to continuously listening devices. Contrarywise to the case of a default size for the reception window, the data are more uncertain with a *Sleeping Time* of around 50 s, which is much lower than the 250 s observed earlier with the Fig. 1a and 1b. Fig. 2b shows the simulation results concerning a doubled *Reception Window*. The first beacon frame can be captured in 12 h with a consumption of 91.4 mAh for a *Sleeping Time* configured at 124 s, which is the
<figure><img src="image_3.png" /><figcaption>Fig. 2. Scatter plots showing the relationship between time for catching the beacon and energy consumed. Color intensity represents the sleeping time of nodes under two reception window configurations.</figcaption></figure>

optimal configuration for this specific *Reception Window*. In contrast to Fig. 2a, the data become more sporadic from 300 s and above. A 20.5% of energy can be saved at the cost of 1.72 h longer catch time with respect to continuous listening.

These first analyses of the influence of the reception window size show that it has a sufficient impact on speed to capture the beacon frame with reduced power consumption. The first configuration with a *Reception Window* of 130.12 s, nevertheless delivers the best performance in the scenario presented. In addition, the *Sleeping Time* configuration, whatever the window size used, is always around 121 s.

## V. CONCLUSION

The presented preliminary results are promising, since a 33% reduction in energy expenditure for an equivalent capture time with a continuous listening device averaging 13.7 hours is observed with a single satellite coverage. However, the proposed ad-hoc simulation does not take into account factors encountered in real-life conditions, such as collisions between LoRaWAN frames. Its implementation will be done on the M5Stack [20] COTS for real-life testing. In future works, this same analysis will be extended to LEO constellations. An in-depth investigation of the wake-up strategy period will also be performed in order to link it to the visibility time of the satellite pass. For completeness, the proposed approach will be compared with the “transmit first” policy inherent to OTAA-based activation in terms of latency and energy consumption. Finally, a comparison will be made with NB-IoT to see if LoRaWAN in DtS IoT can be a viable alternative.

## ACKNOWLEDGMENT

This work was financed by ANR under the STEREO project (grant ANR-22-CE25-0014).

## REFERENCES

[1] A. Al-Fuqaha, M. Guizani, M. Mohammadi, M. Aledhari, and M. Ayyash, "Internet of Things: A Survey on Enabling Technologies, Protocols, and Applications," *IEEE Commun. Surveys & Tutorials*, vol. 17, no. 4, 2015.

[2] M. N. Mowla, N. Mowla, A. F. M. S. Shah, K. M. Rabie, and T. Shongwe, "Internet of Things and Wireless Sensor Networks for Smart Agriculture Applications: A Survey," *IEEE Access*, vol. 11, 2023.

[3] A. Zanella, N. Bui, A. Castellani, L. Vangelista, and M. Zorzi, "Internet of Things for Smart Cities," *IEEE Internet of Things J.*, vol. 1, no. 1, Feb. 2014.

[4] Z. Qu, G. Zhang, H. Cao, and J. Xie, "LEO Satellite Constellation for Internet of Things," *IEEE Access*, vol. 5, pp. 18 391–18 401, 2017.

[5] J. A. Fraire, S. Céspedes, and N. Accettura, "Direct-To-Satellite IoT - A Survey of the State of the Art and Future Research Perspectives," in *AdHoc-Now*. Cham: Springer, 2019.

[6] Z. Zhou, M. Afhamisis, M. R. Palattella, N. Accettura, and P. Berthou, "Pervasive LPWAN Connectivity Through LEO Satellites: Trading Off Reliability, Throughput, Latency, and Energy Efficiency," in *Low-Power Wide-Area Networks: Opportunities, Challenges, Risks and Threats*. Cham: Springer, 2023, pp. 85–110.

[7] Z. Zhou, N. Accettura, and P. Berthou, "A Wake-up Strategy Enabling GNSS-Free NB-IoT Links to Sparse LEO Satellite Constellations," *IEEE Internet of Things J.*, pp. 1–1, 2025.

[8] T. Wu, D. Qu, and G. Zhang, "Research on LoRa Adaptability in the LEO Satellites Internet of Things," in *Proc. of IWCMC*, Jun. 2019, pp. 131–135.

[9] L. Chasserat, N. Accettura, and P. Berthou, "Short: Achieving Energy Efficiency in Dense LoRaWANs through TDMA," in *Proc. of WoWMoM*, Aug. 2020, pp. 26–29.

[10] M. Afhamisis and M. R. Palattella, "SALSA: A Scheduling Algorithm for LoRa to LEO Satellites," *IEEE Access*, vol. 10, 2022.

[11] S. Herrería-Alonso, M. Rodríguez-Pérez, R. F. Rodríguez-Rubio, and F. Pérez-Fontán, "Improving Uplink Scalability of LoRa-Based Direct-to-Satellite IoT Networks," *IEEE Internet of Things J.*, vol. 11, no. 7, Apr. 2024.

[12] Raydel Ortigueira, Samuel Montejo-Sánchez, Santiago M. Henn, J. Fraire, and S. Céspedes, "Satellite Visibility Prediction for Constrained Devices in Direct-to-Satellite IoT Systems," *IEEE Sensors J.*, 2024.

[13] T. Kumberg, R. Tannhaeuser, G. U. Gamm, and L. M. Reindl, "Energy improved wake-up strategy for wireless sensor networks," in *Sensors and Measuring Systems 2014; 17. ITG/GMA Symp.*, Jun. 2014, pp. 1–6.

[14] R. Piyare, A. L. Murphy, M. Magno, and L. Benini, "On-Demand TDMA for Energy Efficient Data Collection with LoRa and Wake-up Receiver," in *Proc. of WiMob*, Oct. 2018, pp. 1–4.

[15] "Skyfield — documentation," https://rhodesmill.org/skyfield/.

[16] D. Vallado and P. Cefola, "Two-line element sets - Practice and use," *Proc. of IAC*, vol. 7, pp. 5812–5825, Jan. 2012.

[17] "Technical details for satellite IRIDIUM 7," https://www.n2yo.com/satellite/?s=24793.

[18] "TS001-1.0.4 LoRaWAN® L2 1.0.4 Specification," Sep. 2023.

[19] L. Casals, B. Mir, R. Vidal, and C. Gomez, "Modeling the Energy Performance of LoRaWAN Sensors," vol. 17, no. 10, Oct. 2017.

[20] "M5Stack - Modular Rapid ESP32 IoT Development Board - ESP32 dev kits," https://m5stack.com/.