Uplink Transmission Policies for LoRa-Based Direct-to-Satellite IoT

Direct-to-Satellite IoT (DtS-IoT) is a promising approach to deliver data transfer services to IoT devices in remote areas where deploying terrestrial infrastructure is not appealing or feasible. In this context, low-Earth orbit (LEO) satellites can serve as passing-by IoT gateways to which devices can ofﬂoad buffered data to. However, transmission distances and channel dynamics, combined with highly constrained devices on the ground makes of DtS-IoT a very challenging problem. Here, we present LoRa-based approaches to realize scalable and energy-efﬁcient DtS-IoT. Our study includes the Long Range-Frequency Hopping Spread Spectrum (LR-FHSS) physical layer, currently on the roadmap of future space IoT projects. Speciﬁcally, we propose uplink transmission policies that exploit satellite trajectory information. These schemes are framed with a theoretical Mixed Integer Linear Programming (MILP) model providing an upper bound on performance as well as inspiration for scheduled DtS-IoT solutions. Simulation results provide compelling evidence that trajectory based policies can duplicate the amount of IoT nodes, while speciﬁc variants can further boost the scalability by 30% without incurring energy penalties. We also quantify that LR-FHSS can improve the deployment scalability by a factor of 75x at the expenses of 30% higher device’s power consumption compared to the legacy LoRa modulation.

ABSTRACT Direct-to-Satellite IoT (DtS-IoT) is a promising approach to deliver data transfer services to IoT devices in remote areas where deploying terrestrial infrastructure is not appealing or feasible.In this context, low-Earth orbit (LEO) satellites can serve as passing-by IoT gateways to which devices can offload buffered data to.However, transmission distances and channel dynamics, combined with highly constrained devices on the ground makes of DtS-IoT a very challenging problem.Here, we present LoRa-based approaches to realize scalable and energy-efficient DtS-IoT.Our study includes the Long Range-Frequency Hopping Spread Spectrum (LR-FHSS) physical layer, currently on the roadmap of future space IoT projects.Specifically, we propose uplink transmission policies that exploit satellite trajectory information.These schemes are framed with a theoretical Mixed Integer Linear Programming (MILP) model providing an upper bound on performance as well as inspiration for scheduled DtS-IoT solutions.Simulation results provide compelling evidence that trajectory based policies can duplicate the amount of IoT nodes, while specific variants can further boost the scalability by 30% without incurring energy penalties.We also quantify that LR-FHSS can improve the deployment scalability by a factor of 75x at the expenses of 30% higher device's power consumption compared to the legacy LoRa modulation.

I. INTRODUCTION
The number of deployed devices and services in the Internet of Things (IoT) has been growing dramatically over the past number of years [1].However, many of the IoT deployments have been focused on urban, semi-urban and rural areas as they are served well by terrestrial IoT low-power and widearea networks.However, there is a significant opportunity and need for IoT deployments also in very rural and remote The associate editor coordinating the review of this manuscript and approving it for publication was Cong Pu .
areas for services such as in environmental and ecological monitoring, remote wildlife monitoring, remote gas and oil exploration, geological and natural disaster monitoring, and monitoring services from buoys on the open sea [2].Areas such as the Artic/Antarctic, the open ocean and seas, or remote areas such as large forest areas, natural parks, and similar remote land areas have seen much less deployment of IoT due to a lack of low-cost terrestrial network connectivity and only high-cost, high-energy satellite connectivity.However, recently low-cost Low Earth Orbit (LEO) satellite technology enabling efficient and global connectivity to IoT devices is starting to change this, thus making IoT deployments in remote areas feasible [2].
The so-called Internet of Remote Things comprises indirect and Direct-to-Satellite IoT (DtS-IoT) access modes [3], [4].Specifically, DtS-IoT reduces the dependency on ground gateways and, thus, simplifies the communication to remote areas [4].Recent works have considered feasible satellite constellations for DtS-IoT [1], [5] and new start-up companies such as Kepler, 1 Astrocast, 2 and Lacuna Space3 are working on deploying specific satellite constellations for IoT [6].
In line with exploring the DtS access mode, recent studies have shown the feasibility of using Low-Power Wide-Area technologies (LPWA), such as LoRa/LoRaWAN4 and NB-IoT for low power communication over a satellite link [7]- [9], which differs from satellite constellations devoted to broadband Internet access that employ high-frequency bands to achieve higher and persistent data rates.Furthermore, the idea of using nano-satellites, together with LPWA technologies over a satellite link, enables lower-cost and delay-tolerant solutions for IoT connectivity compared to traditional satellite networks [10], [11].More recently, the new Long Range-Frequency Hopping Spread Spectrum (LR-FHSS) [12] modulation has also attracted interest for satellite communication.
While the feasibility of using LoRa and other LPWA modulation schemes in DtS-IoT is being established, little work has investigated Medium Access Control (MAC) transmission policies, which highly impact scalability and energy efficiency, especially in the uplink.In respect to scalability, the question is how many devices can be supported by a passing-by satellite based gateway at LEO with one or two transmissions per day.Indeed, the satellite coverage might include thousands of devices and the basic LoRaWAN Aloha MAC protocol is known to suffer from low scalability and high collisions in dense deployments.Energy efficiency is another critical issue as devices in remote areas have to operate autonomously for long periods of time based on batteries or constrained energy harvesting techniques.
In this paper, we study different uplink transmission approaches for the DtS use case in terms of scalability and energy consumption on top of the basic LoRa modulation (henceforth Legacy LoRa, or LoRa-L) and the recently introduced LR-FHSS modulation [12].We take advantage of the specifics of satellite communication and propose schemes tailored to profit from LEO satellite pass dynamics.To the best of our knowledge, this is the first assessment of LR-FHSS for use in ground-to-satellite links.The specific contributions of this paper are: • A set of applicable and practical transmission policies tailored to constrained IoT devices and the dynamics of LEO satellite pass-over for LoRa-L and LR-FHSS.
• An upper bound Mixed-Integer Linear Programming (MILP) model to frame the proposed policies with optimal theoretical collision-free and energy-efficient resource allocation.
• An extensive simulation campaign considering realistic satellite passes in DtS-IoT deployments to determine the achievable scalability and energy efficiency of the proposed transmission approaches using LoRa-L and LR-FHSS.The paper is organized as follows: Section II summarizes related work.The system model is provided in Section III.The proposed uplink transmission policies are introduced in Section IV, and evaluated by means of simulations in Section V. Conclusions are provided in Section VI.

II. RELATED WORK
LPWANs play now a major role in the IoT, enabling applications in sectors such as smart cities, asset tracking, environmental monitoring, and intelligent transport systems [13].To this end, telecommunication operators have embraced and deployed these new networks based on LoRa/LoRaWAN, NB-IoT (as part of 3GPP 5G specification) or Sigfox as the enabling technologies [14], [15].The recent spur in space projects, and more notably in LEO satellites [2], is emerging as an appealing approach to extend the IoT service.In this paper we focus on LoRa/LoRaWAN-based DtS-IoT.
At the physical layer, LoRa's chirp-based spread spectrum communication has been studied for satellite-based data collection systems [8], [9].Further studies have discussed adaptations to the satellite channel of the spread spectrum modulation [16], [17].Later on, the reception of LoRa signals from satellites was successfully assessed for different spreading factors (SF) in [18].However, scalability issues of the integrated LoRa/LoRaWAN stack [19] might hinder a sustainable throughput in wide-area coverage scenarios such as envisioned in DtS-IoT.
Recently, a new LoRa modulation, called LR-FHSS, has been proposed by Semtech and announced by Lacuna as the candidate for future LoRa-based LEO communications.LR-FHSS uses a fast Frequency Hopping Spread Spectrum technique that transmits replicas of the packet header and the packet itself, fragmented into 50 ms-duration per fragment.Several physical layer configurations are available in what are called Data Rates (DR). 5In Europe, DR8 and 9 operates over a bandwith of 137 kHz, while DR10 and 11 over 336 KHz.The details of coding rate, header repetitions, and physical bit rate of each DR are available in [12].In general, a DR allows for sending the packet header multiple times, with only one repetition needed for a correct packet extraction at the receiver.After the header's replicas, the fragments, called intra-packets, are transmitted sequentially to the gateway, following a random hop selection.The authors in [12] demonstrate large improvements in network scalability of LR-FHSS compared to LoRa-L.LR-FHSS offers more flexibility and resource diversity (i.e.frequency hopping) compared to LoRa-L modulation, which improves the network scalability at the cost of individual end-devices capacity.These extensions to the LoRa-L physical layer make LR-FHSS suitable for LEO satellite IoT deployments.
In terms of medium access control, there have been a good number of studies devoted to establishing the benefits and limitations of the LoRaWAN Aloha-based MAC protocol.Both theoretical and experimental approaches demonstrate how scalability, energy consumption, network throughput, and fairness of terrestrial LoRaWAN deployments are impacted by the MAC protocol design [20]- [22].Solutions to improve the network performance consider the IoT traffic characteristics, the network topology and dynamics, and the network surroundings, among other aspects, and propose strategies that explore from adapting/improving the random-based access scheme to provide on-demand access scheduling [23]- [27].Furthermore, in LoRaWAN, each device typically uses a fixed SF for data transmission, which is usually assigned based on the distance from the gateway [28].Thus, previous works have considered the SF in planning techniques together considering gateway and devices location [29].Other works seek to optimize the Adaptive Data Rate (ADR) mechanism, which assigns SF based on distance/RSSI measurements, seeking to dynamically optimize data rates, airtime, and energy consumption [30].Related works have also considered the number of connected devices by means of specific algorithms [31].Others have leveraged matching theory to provide fair average data rates [32], [33].
However, the findings of these works do not directly translate to a DtS-IoT scenario using LoRa/LoRaWAN over a satellite link, where the link length is hundreds of km with highly dynamic channel behavior, and where part of the network infrastructure, i.e., the LoRaWAN gateway, is orbiting in space at very high speeds.Similarly, there has been little research devoted to evaluating the LoRaWAN MAC protocol performance together with SF allocation schemes in Earth-tosatellite communications, in particular for the DtS-IoT access mode.Recent studies provide general surveys of existing channel access schemes [34], [35].In [8], using the position information of sensors and the satellite, the authors propose a joint power adaptation and access channel scheme that aims at improving the LoRaWAN performance over a satellite link.Wu et al. [36] provide a methodology for adapting an evaluation of LoRaWAN to satellite communications, with a very brief exploration of the relation between throughput and offered load when using the standard Aloha-based MAC protocol.None of the aforementioned works study the effects of different SF (or DR) allocation in the dynamic earthto-satellite environment, nor involve evaluations of massive deployments (>1000 up to 200k nodes).Moreover, to the best of our knowledge, this is the first study that includes the new LR-FHSS modulation and compares it with LoRa legacy under the same DtS-IoT scenario.

III. SYSTEM MODEL
The global trend in satellite IoT is to use satellites as a backhaul, that is to transport data from IoT devices via satellite connected gateways on the ground [3].A more appealing, but challenging architecture implies Direct-to-Satellite IoT (DtS-IoT) links, where the IoT devices directly transmit data to the passing-by satellite(s) [4], [37].Compared with geostationary satellites, Low-Earth Orbit (LEO) satellites, orbiting below 1000 km height, can establish links with devices on the surface at reduced power budgets and round trip time delays [38].However, the dynamics of near-Earth orbits demand for constellations of several LEO satellites to approximate continuous coverage [1].Resulting LEO pass over regions with IoT devices create a highly dynamic channel, where specific medium access schemes need to be designed.Furthermore, the network operation should avoid expensive handshakes and allow for power-saving periods when the satellite is not ''visible'' in the sky.These objectives can be accomplished by a convenient beacon approach inspired by the LoRaWAN Class-B mode [5].The system model discussed below comprises these particular aspects of a LoRabased DtS-IoT deployment.

A. DtS-IoT LEO CONSTELLATIONS
A complete end-to-end DtS-IoT deployment comprises (i) of the IoT devices deployed on the ground, (ii) the passing-by satellites collecting, sending and storing data from/to devices, and (iii) the ground core network delivering or receiving data from the LEO satellites.The feasibility of DtS-IoT deployments is being confirmed by in-orbit demonstration such as the LacunaSat-1 nano-satellite [39].However, the long-term vision is to deploy constellations of hundreds of nano-satellites to provide more frequent data exchange opportunities [5].As a result, DtS-IoT systems will evolve from very high latency scenarios (data is carried on a single/few satellites until the ground core network becomes visible) to moderate/low latency in dense constellations, especially when supported by multiple ground stations or intersatellite links.Delay tolerance is thus an inherent aspect of DtS-IoT which gives an advantage in designing transmission schemes aimed at choosing the optimal transmission instant over each LEO satellite pass.
Fig. 1 illustrates a typical satellite pass (black line is the satellite trajectory over 1200 seconds) over a circular region with uniform distribution of IoT devices (blueish colored dots) fixed in Earth Center Inertial (ECI) coordinates.Thus, distances between IoT devices and the satellite can be computed for each time [40], depending on the latitude/longitude location of each device.While some devices experience a zenithal pass, others reach and see the satellite closer to the horizon.As a result, each device-satellite pair will perceive a time-evolving channel path loss, which differs from traditional and more static IoT systems.This condition affects the received power at the satellite, which would require different modulation parameters (i.e., SFs in LoRa modulation) for each device to ensure correct packet delivery at the orbiting gateway.

B. CHANNEL AND PACKET MODELS
The channel modeling of DtS-IoT scenarios is still an open research topic.A thorough revision of traditional satellite channel models can be found in [35].A recent comparison of models that best capture the DtS-IoT scenario characteristics is presented in [41], but with no introduction of a new or better channel model.Other studies, such as [42], calculate the received power signal using a free space path loss model.Similar to [42], in our analysis, we employ a simple channel model that accounts for attenuation, interference, and the capture effect at the receiver, considering that those are the aspects that have the most impact on the performance of the uplink transmission policies under evaluation.
The power signal in dBm at the satellite receiver is calculated as [1]: where P T is the end-device transmission power, G T and G R are the transmitter and receiver antenna gains, respectively, and L FS is the propagation loss.L FS follows the standard free space path loss.Based on P R and the interference from other frames, a successful demodulation (i.e., extraction of the packet) occurs if the reception sensitivity values are higher than where BW is the bandwith, NF is the noise figure, and SNR f is the signal to noise ratio.If the sensitivity value is met, and a packet does not generate a collision, the receiver is able to process a given number of simultaneous received packets.Due to the large device-to-satellite distances, propagation time must be taken into account, and recomputed dynamically during the satellite pass.The propagation time is computed by where d is the channel range and c the speed of light.Also, given the low data rates of IoT protocols, airtime of frames are considerable.The airtime in LoRa-L can be obtained from conveniently available calculators. 6For LR-FHSS, we use the airtime values from [12], for each DR.Concurrent transmissions on the same channel can interfere with each other based on difference in signal strengths or modulation (we disregard interference from other sources, as DtS-IoT deployments are targeted to remote rural areas with likely reduced RF sources).Different modulations (i.e.Spreading factors) in LoRa-L are not fully orthogonal [43], which means that multiple time-overlapping packets at the gateway may only be successfully extracted if the difference in RSSI is less than an indicated threshold (i.e., capture effect).Thus, the collision model takes into account the fading effect of the signal, the channel in which the packet is sent, the SF of the packet, and their cross interference.As a result, packets transmitted based on our model follow the following checks, in the following order, before extraction: • Packet lost: if the packet does not meet the RSSI sensitivity threshold for the respective SF or DR, it is discarded.
• Packet collided: If the packet overlaps in time with other packet(s) and does not overpower the concurrent transmissions as per the aforementioned thresholds, it is discarded.
• Packet not processed: LoRaWAN gateways can process a limited number of concurrent packets (given by the electronics in the reception chain).If such a number is reached, the packet is discarded.
• Packet extracted: If the packet was not discarded due to any of the previous reasons, it is successfully extracted at the satellite.

C. FREQUENCY BANDS
Due to the large surface covered by the passing-by LEO satellite, packets from both urban and remote rural regions could be received simultaneously in the orbiting gateway.
In such cases, terrestrial deployments over populated regions could drastically increase the uplink channel interference to the detriment of devices in isolated areas.To avoid this issue, operation over licensed satellite frequencies is envisioned, although with limited scalability as specific operators will own the rights to transmit over that spectrum. 7 large-scale space-terrestrial integration in these cases can still be supported by recent multi-band devices such as LoRa Edge LR1120 from SemTech.Besides GNSS localization capabilities, this modern chipset implement legacy LoRa and LR-FHSS modulations over i) sub-GHz band (150-960 MHz), ii) 2.4 GHz ISM band, and iii) satellite S-Band (1.9-2.1GHz).Thanks to these features, a single IoT device can now switch between terrestrial IoT bands and space-specific frequencies for transmission, which is in the spirit of the proposed space-terrestrial integrated DtS-IoT paradigm.
For application use cases involving very remote regions where the covered surface does not include sources of interference (e.g., oceans, poles), the terrestrial ISM LoRa band can also be leveraged for DtS-IoT. 8In fact, the terrestrial band could also be exploited for the uplink in presence of moderated interference (e.g., minor overlap with other LoRa deployments), as previous studies have addressed.We briefly review them below.
In [42], the authors study the impact of terrestrial network interference on a satellite uplink transmission.The results show a good opportunity to utilize shared frequency bands in areas where the interference level is low enough.Consequently, a control system with intelligent control logic and link quality monitoring could help make the decision when to deploy the shared frequencies and when to stay within the dedicated satellite frequencies.Other authors have also proposed using cognitive radio mechanisms to aid the use of shared frequencies under conditions of interference [1], [45].As for the impact of satellite downlink transmission on the performance of the terrestrial network, the authors in [46] provide a study that shows that the satellite network can still be integrated even if the satellite spot beams fully overlap the terrestrial network coverage.They concluded that the satellite network could be integrated if the terrestrial network parameters consider the satellite transmission.In such cases, the system performance degradation due to satellite interference is small.
Regarding the downlink frequency, the definition of a suitable unique frequency band for the downlink is still an open discussion topic among the LoRa/LoRaWAN satellite community at the time of writing.Nevertheless, even if a future LoRaWAN based satellite service will use different downlink frequencies compared to the current terrestrial frequency bands, the essence of our work remains valid as it is focused on uplink channel access techniques.

D. DATA FRAMES
We aim to study different transmission policies for LoRa-based data collection in DtS-IoT based on the aforementioned pass, channel, extraction, and collision models.Devices' uplink transmissions are organized in frames that are triggered by a LEO satellite using beacons (by frames we mean a period of time composed by an uplink and a downlink episode, see Fig. 2).To this end, a beacon is periodically transmitted by the satellite using the most robust spreading factor (SF), e.g., SF12 (or DR8 in the case of LR-FHSS).Devices that receive and decode beacons are assumed to a) be in line of sight with the satellite, and b) experience good enough channel conditions to at least reach the gateway with the most robust SF12 (the beacon is modulated on such SF).Thus, a device is allowed to participate in the transmission (collection) phase of the frame, which immediately follows the beacon period.
However, the exact transmission time within the frame and the transmission configuration (i.e., SF in LoRa-L or DR in LR-FHSS) depends directly on the policy used.Independent of the transmission policy used, a maximum of one uplink transmission is permitted per each device in each frame.Subsequent frames can be used for extra uplink transmissions by the same device.Consequently, a question arises as to what frame length should be used?Although, the transmission policy has a major impact on the answer to achieve the optimal frame length, there are other system constrains that contribute to the answer as well (e.g., the satellite passing time).
On the one hand, the frame length (T f ) has to be longer than T b α , where T b denotes the beacon time, for a satellite to transmit periodic beacons and meet the duty cycle constraint (α).On the other hand, the frame has to be short enough for a device to transmit n times in n different frames, considering the maximum clock drift of a device between two satellite passes.Thus, T f also depends on the satellite passing time T p , downlink duty cycle α, and the devices' maximum clock drift D m .More specifically, the following equation describes the conditions that govern the frame length for a device to have a chance to transmit n packets over n frames during a satellite pass: Based on the frame length constraints from equation ( 4), we find that it is possible to define T f = 120 seconds for DtS-IoT, which is the maximum beacon period specified in LoRaWAN Class-B mode [47].This assumes that the system will accomplish an overall duty cycle of nearly 1% in the worst uplink case of SF12 (whose airtime is 1.32 seconds, at 20 Bytes and coding rate 4/5).Of course, we assume that beacon duration T b and frame duration T f , as well as the beacon transmission channel are fixed and known to ground devices to decode it properly.
At the device side, two possible beacon reception modes can be envisioned.One is where nodes have no satellite trajectory information, and will need to enable a (synchronized) reception window for every possible beacon.If no beacon is received, the node enters sleep mode and waits for the next beacon.This mode would be similar to LoRaWAN class-B [47].This mode demands a higher power consumption due to the periodic power-on of the reception chain, even when no satellite is present.Another possibility is for the device to exploit the satellite(s) trajectory information so that the reception is only enabled when line-of-sight with a satellite is present.Although this scheme yields a better energy efficiency, computation power and memory resources are needed to receive, compute, propagate and store the trajectory information.In both cases, nodes with no data to send might decide not to enable beacon reception to boost their lifetime.However, this cannot be done for too long a time so as to keep the clock drift of a device within the allowed limits.
In all uplink transmission phases, nodes trigger a random back-off time for transmit, such as for the Aloha-based behavior in LoRaWAN (non-slotted Aloha).The back-off random selection is repeated for each newly received beacon, with the expectation of reducing concurrent transmissions and thus collisions.This is relevant not only for the sake of energy efficiency, but also for unconfirmed packet transmissions, as assumed in the current system model.

IV. UPLINK TRANSMISSION POLICIES
Based on the described frame and back-off based model, the key differences between policies are the SF and DR chosen by nodes for each transmission and frame interval.As discussed below, the decision to transmit or avoid a frame opportunity is also a factor in the transmission policy.The following policies starts from simple/baseline, to complex, where devices consider the satellite trajectory.All transmission policies assume a) the presence of a periodic beacon in the downlink, b) a back-off process to schedule an uplink transmission within the frame, c) the uplink transmission is performed without sensing the channel (as in pure-ALOHA), and d) the uplink transmissions is unconfirmed (i.e., no acknowledgments in the downlink).

A. BASELINE POLICIES
The LoRa-based DtS-IoT transmission policies consider 1) conservative and 2) random baselines as follows.

1) CONSERVATIVE
All devices use the most robust SF12 (or DR8 in case of LR-FHSS) no matter the distance to the satellite, in order to ensure that all packets are able to reach the gateway.This configuration is similar to the LoRaWAN protocol trial reported in [19].

2) RANDOM
The devices randomly choose an SF between SF7 to SF12 (DR8 to DR11 in LR-FHSS) with the expectation that it will arrive to the satellite.Packet losses are expected in cases where an SF was chosen that was unsuitable for the distance between device and gateway.

B. TRAJECTORY-BASED POLICIES
Trajectory-based policies are fundamental in DtS-IoT as they assume the IoT devices can infer by some means the distance (and its expected variation in the immediate future) to the satellite.This information can be made available to the device by one or a combination of the following strategies: (i) extrapolating the RSSI of one or more of the received beacons to derive the distance, (ii) process the measured frequency shift of the beacon to determine the speed of the satellite (Doppler effect is well studied in LoRa/LoRaWAN devices in LEO channels [9], [48], [49] and also an available metric in most chipsets), or (iii) exploit provisioned orbital parameters (i.e., Two-Line Elements or TLE files [50]) so that the device can propagate the satellite position in time and obtain an accurate trajectory of the gateway, which can then be compared with a one-time measurement of the local position of the device (available via GPS receivers in modern LoRa chipsets 9 ), in the case of stationary IoT devices.Based on available trajectory information calculated by any of these approaches, we study four possible trajectory-dependent transmission policies: 1) plain trajectory, 2) trajectory random, 3) trajectory skip, and 4) trajectory random skip.

1) PLAIN TRAJECTORY
Based on the aforementioned information, the device can derive and choose the minimum SF (or maximum DR in LR-FHSS) to transmit in the current frame.Implementations might consider error margins for the decision depending on the accuracy of the distance determination mechanism.

2) TRAJECTORY RANDOM
Same as the plain trajectory policy, but instead of directly implementing the minimal SF for the transmission, it is used as a floor for a uniform random selection between the minimum SF and SF12 to select the final SF.As a result, an equal or higher than the minimal SF will be used for the transmission.The same procedure is used in LR-FHSS as well.The random trajectory approach is thus expected to provide further diversity beyond the plain trajectory scheme at the expense of a less optimal resource (energy) utilization.Indeed, in plain Trajectory, every node in similar channel conditions (i.e., devices geographically closer to each other) chooses the same SF or DR, which increases the overall collision probability.

3) TRAJECTORY SKIP
The trajectory random scheme enhances diversity, but its behavior is limited to a single beacon, lacking a more comprehensive vision of the LEO satellite pass.Instead, the trajectory skip approach aims at letting devices choose not to transmit in a given frame but store the data in memory for a future (hopefully better) transmission opportunity, so that congested frames can be conveniently avoided.To this end, this scheme assumes that the transmitted beacon includes information on the expected number of devices that need to be served by the satellite during the frame (N ).This number can either be estimated from past passes [51], or can be provisioned by mission operation and control, based on knowledge about active network users.
Based on the N received in the beacon, each device can exploit the output of a so-called skip function S to determine the probability of not transmitting in the current frame and retry in the next one.By observing the throughput results for different skip values in the scenario presented in Section V, we empirically found the sigmoid function shape properly follows the optimal skip probability to maximize the results.To fit S, we leverage a skip parameter p skip , which depends on the scenario (access protocol, number of channels, etc.).The resulting skip function is thus defined as follows: where S(N , p skip ) is the probability of skipping the current frame, and p skip the skip parameter fitted for each scenario.
In particular, the lower p skip , the higher the chances a node will choose to skip a frame and, thus, the lower the probability that this frame will experience collisions.To properly fit p skip , we iterated over 100 simulations following a binary search pattern in the LEO pass illustrated in Fig. 1.We found that p skip = 4, 000 and p skip = 100, 000 provide satisfactory results for LoRa-L and LR-FHSS respectively.
In any case, after the skip function is evaluated, the device chooses the minimal SF (or maximal DR) as in the plain trajectory scheme.

4) TRAJECTORY RANDOM SKIP
This policy uses the same skip function introduced in trajectory skip, but instead of choosing the minimal SF after the skip function evaluation, the device randomly chooses a SF equal or higher to enhance diversity, as in the trajectory random scheme.

C. OPTIMAL TRANSMISSION SCHEDULE BOUND
In order to identify a theoretical upper bound on the performance of possible transmission policies, we consider an a-priori calculated scheduled transmission policy that assume a ''God-like'' view, i.e. a central scheduler (e.g., in the satellite or a network sever on the ground) that has total information on the system state, e.g. each device's traffic pattern, packet size, on a per frame basis.The scheduler would be able to compute a fine-grain transmission schedule for each of the served devices within each beacon frame.
Even though it is unlikely to leverage this amount of information in a real system, the outcome of such a scheduler can be used as a theoretical upper bound reference that maximizes the channel utilization.However, most controlled, centralized and simpler DtS-IoT deployments might consider such a tight control of the uplink traffic.In such case, scalability and energy efficiency would come at the expense of computation resources to compute the perfect schedule and the need for extra downlink traffic to disseminate the schedule to devices.The schedule computation can be done on the ground and be transmitted to the satellite, requiring extra downlink/uplink traffic, representing an interesting trade-off between computation resources and data communication to/from the satellite.This trade-off is out of scope of this paper.
The theoretical scheduler is based on the same time division scheme using downlink beacons and uplink periods, as illustrated in Fig. 2. Knowing the traffic pattern from each device a-priori, the scheduler aims at selecting the best (i.e., the most robust) spreading factor required to guarantee successful transmissions with no collisions from devices transmitting over the same time frame, at the same time it minimizes the energy consumption.To achieve this, the following assumptions hold in this model: (i) LoRa/LoRaWAN packet payloads are of fixed size; (ii) frame duration is fixed; and (iii) a spreading factor is selected on a frame-by-frame basis, with the most robust being the prevailing one (i.e., if two, or more, spreading factors are feasible for the duration of a single time frame, the model prefers the higher-more robust-spreading factor).The scheduler works under similar restrictions as the ones operating for our proposed uplink transmission policies, i.e., it only allows one transmission per device at a given time frame (Eq.7), for a given packet count on each node (Eq.8), it only allows packets to be transmitted over one channel at a time (Eq.9), the number of transmissions scheduled over the fixed-duration frame is limited by the packets' transmission times-known as air times in LoRa/LoRaWAN-, which in turn depend on the selected SF (Eq.10), and no packet transmission is scheduled when the link is not feasible even for the highest SF (Eq.11).The computation of such a theoretical collision-free and energyoptimal scheduler can be described by means of a Mixed Integer Linear Programming model (MILP) using the parameters in Table 1 and formalized with the following set of equations: • Eq. ( 6): Objective function aiming at allocating the maximum data delivery possible among all nodes n, beacons b.Airtime function A is added as secondary objective (A in seconds is always lower than D in Bytes) to prioritize faster SFs when frames are not time-constrained (i.e., saving nodes' transmission power).
• Eq. ( 7): Constraint indicating that for each node n, frame b, and channel c, at the most one packet can be transmitted, no matter the chosen spreading factor sf .
• Eq. ( 8): Constraint modeling the maximum packet transmission per node n (P n ).For example, in the scenario below, we assume that each node have 3 packets to transmit during the satellite pass.
• Eq. ( 9): Constraint forcing each packet to exist in one channel at the most.
• Eq. ( 10): Constraint limiting the number of packets in each frame based on the frame length (B), and each transmitted packet air time (A(D, sf )).One constraint is present for each channel.
• Eq. ( 11): Constraint that forces all p n,b sf = 0 in case sf is lower than the minimum spreading factor required to reach the satellite (Sf (n, b)).The big-M method [52] is leveraged to this end.It is worth mentioning that the model as stated is applicable to LoRa-L only, as such an optimal model for LR-FHSS would need to consider sub-channels and frequency hopping sequences for intra-packets, which is not trivial to formalize by means of a MILP.max: Subject to :

V. PERFORMANCE EVALUATION
To validate and compare the performance of the proposed policies, we have developed a simulation tool based on the Simpy library in Python 3, called LoRa-Space. 10 Our simulation tool is based on the FREE [27] and LoRaSim [19] simulators.The simulator reads the fixed Earth-Center Inertial (ECI) position of devices on the surface uniformly distributed in a circular region, and the time-evolving dynamic pass of the LEO satellite (as illustrated in Figure 1).The LEO satellite trajectory is computed with the Two-Body propagator and exported using the Systems Toolkit (STK) from AGI.The LEO is configured with a polar orbit at 600 km altitude, an inclination of 98 degrees, a right ascension of the ascending node (RAAN) of 20 degrees, and an argument of perigee of 0 deg.The resulting topology is illustrated in Figure 3 at different times of the pass, where the evolution of the satellite position along the orbital trajectory can be observed.Nevertheless, obtained results discussed below are applicable to any location with a satellite pass crossing the central point of the circular region over which devices are deployed.The remaining simulation parameters are summarized in Table 2.
Even though the designed uplink transmission policies are by definition independent of the frequency band, we design the simulation scenario to represent two simultaneous cases: i) the utilization of a space-specific uplink frequency (interference-free S-Band, at 2.0 GHz), and ii) the utilization of a shared band with the terrestrial LoRa service (single channel at 868.1 MHz and three channels at 868.1, 868.3 and 868.5 MHz according to EU868 and EU863-870 LoRaWAN  the packet error rate of cognitive radio techniques over mild interference areas as discussed in Section III-C is left as future work. We consider 0 dB gain antennas on the devices at 868 MHz, which should be pointing perpendicularly to the surface (i.e., helicoidal antennas, as used by Lacuna Space [39]).We assume the passing satellite has a 12 dB antenna gain, which allows it to reach the devices on the surface even at low elevation conditions.Since equation ( 2) from the channel model captures the received power values based on frequency, we compute that the 2.0 GHz S-Band simulations incur in a 7.25dB of extra path loss with respect to the 868 MHz case.Since the transmission power for the devices is set to the maximum allowed of 14 dBm, we choose to compensate for the free space loss difference by increasing the antenna gains.
Although we evaluated LoRa-based DtS-IoT networks for 1-and 3-channel configurations, given that single channel behavior exhibits similar trends as the 3-channel configuration, we only discuss results from the latter.Furthermore, for the LR-FHSS case, we evaluate DR8-9 modulations, corresponding to a 137 kHz channel bandwith.
For all settings, we assume packets with a fixed payload size of 20 Bytes and each device can buffer up to 10 packets between two satellite passes.To determine the packet extractions, we employ a bandwidth BW = 125 KHz in LoRa-L, NF = 6dB, and an SNR f as indicated in Table 3.In the case of LR-FHSS, Table 4 shows the assumed sensitivity values. 11or simultaneous receptions at the satellite, we consider a maximum of 16 demodulated packets at the gateway. 12For LR-FHSS, there is no such limit of simultaneous packets, instead, simultaneous receptions depend on the gateway's processing bandwidth performance, allowing hundreds of intra-packets to be processed at the same time [12].We set it to 500 in the simulator.To account for collisions, we employ the interference thresholds indicated in Tables 5 and 6, which were obtained experimentally in the case of LoRa-L [43], and estimated in the case of LR-FHSS.
Results are presented for three performance indicators, namely a) network scalability, b) power consumption, and c) pass utilization.

A. NETWORK SCALABILITY
To determine the scalability, we investigate the effective delivery of packets to the orbiting gateway.Results for LoRa-L and LR-FHSS summarized in Figs . and 5, respectively, with a confidence interval (CI) of 95%, which is shown as a slight shadow around each of the curves.
In the case of LoRa-L, MILP achieves a 100% extraction rate as expected.It provides perfect scheduling that reduces collisions to zero while minimizing energy consumption at each node (as observed in Fig. 6).The scheme is conservative in the sense that it chooses the most robust SF for a transmission opportunity within a frame, but profits from the a priori knowledge of the offered load.In general terms, all policies that use knowledge of the satellite's trajectory perform better than the baseline approaches.Knowing the trajectory allows for choosing a better opportunity of transmission in terms of link quality.It also ensures that no packets are lost due to lower-than-required received power at the receiver, as is observed in Fig. 4.b), detailing the packets lost.When using TLE information, such losses are reduced to zero.
Although the knowledge of the trajectory improves the extraction rate for larger networks, it is inefficient at taking advantage of the diversity of SF that are sufficient to reach the satellite.The improvement in performance is observed when choosing a random SF higher than the minimum required, reducing collisions and improving the extraction rate, as observed in the LoRa-L Traj.Rnd (compared to LoRa-L Traj.) and LoRa-L Traj.Rnd Skip (compared to LoRa-L Traj.Skip).
Compared to MILP, the best performance is achieved by the LoRa-L Trajectory Random Skip policy.In this policy, whilst using a basic heuristic, it shows how spreading transmissions over time improves the extraction ratio, getting closer to the perfect scheduling provided by the oracle.At an averaged extraction ratio of 60%, trajectory schemes duplicate the served devices of the conservative baseline (from 250 to 500 nodes).As the network becomes saturated (extraction ratio below 50%), skip-based policies exhibit a better pass utilization (discussed below) outperforming plain trajectory schemes by more than 30% (i.e., 1700 to 2300 nodes).
In the case of LR-FHSS, the first thing to note is the vast increase in network size achieved by the LR-FHSS modulation, when tested under the same DtS-IoT scenario as legacy LoRa.For the worst-performing policy, namely the conservative, there is an approximate 75 times increase in the number of nodes supported before dropping to a 20% successful extraction.As for the other policies, successful extraction naturally decreases with the increase in network size, but the observed decay occurs at a much slower rate than in LoRa-L.The best-performing policies only see a steep reduction of extracted packets when surpassing 150k nodes.Different from the behavior in LoRa-L, in this scenario with LR-FHSS, the schemes that use a random DR once the maximum DR has been established (i.e., based on the satellite's trajectory), suffer a reduction in the actual delivery of packets when compared to its non-random counterparts.This may be explained by the fact that LR-FHSS supports a larger network by exploiting different types of diversities (i.e., in frequency and time).Hence, a frame does not suffer from saturation unless the network is really large, reducing the benefits of skipping a frame to find a better future opportunity, such as in the case observed for LoRa-L.

B. POWER CONSUMPTION
In this section, we study power consumption in terms of the time spent in uplink packet transmission as the dominant source of power consumption.It is expected for the satellite to consume the same amount of energy regardless of the policy in use, since it follows the same pattern of beacon transmission and listening for the entire frame duration in all policies.The power consumption results are illustrated in Fig. 6 a) for LoRa-L and in Fig. 6 b) for LR-FHSS.
In the case of LoRa-L, it can be observed that using a fixed conservative allocation of SF (SF12 in this case) results in the most expensive approach in terms of power consumption.As the trajectory-based policies force the devices to wait for better channel conditions, devices end up wasting less energy using expensive SF to reach the satellite when the trajectory suggests that a less expensive SF will be available for use √ n for a 95% confidence interval with n-1 degrees of freedom, where n is the number of random seeds used for the simulations (see Table 2).
along the satellite's pass.The reduced power consumption of the random policy is explained due to the more diverse allocation of SF.However, such an allocation comes at the cost of selecting SFs that will not provide enough signal power to reach the satellite, causing packet losses and the con- √ n for a 95% confidence interval with n-1 degrees of freedom, where n is the number of random seeds used for the simulations (see Table 2).
sequent waste of energy.This phenomenon is observed when examining the effective rate achieved by the random policy in the table in Fig. 6 a).The energy cost of randomness is also appreciated in the random trajectory-based policies (i.e., Trajectory random and Trajectory random skip), although in those cases, the additional energy consumption is attributed to the random selection of power-consuming SF that favor the reduction of collisions when exploiting SF diversity (see Fig. 4).As for the LR-FHSS case, the more energy consuming policy continues to be the conservative approach.When compared to the conservative policy in LoRa-L, the average here is higher, which highlights that the airtime of the lowest data rate of LR-FHSS is higher than its corresponding approach in LoRa-L.The proposed trajectory-based policies, in the case of LR-FHSS, reduce the power consumption when compared to the conservative approach, although not a significant difference is observed among them.Instead, the random approach provides the least energy consuming policy, but once again, at the cost of wasting packet transmissions that will not reach the satellite with enough power to be demodulated (see Fig 5).

C. PASS UTILIZATION
The satellite pass utilization is a particular and not obvious aspect to analyze in DtS-IoT systems.In particular, delay tolerance in IoT enables a wiser exploitation of the transmission opportunities, as the very first chances of delivering data to the satellite are naturally closer to the horizon, and thus, in the worst channel conditions.This can be observed in Figs.7 and 8, where each packet transmission for each of the 6k nodes (LoRa-L) and 200k nodes (LR-FHSS) are scattered along the complete satellite pass (figure plotted for 3 packets per node).The figures quantify the fairness of the pass utilization by means of the Jain Index (JI) [53], which is computed over the number of transmissions in each frame (JI = 1 fair distribution, JI = 0 unfair distribution).
It is evident that the first (and last) seconds of the pass are populated with robust SF and DR modulations (reddish dots), to overcome the large distances to the gateway.On the other hand, more efficient modulations (blueish dots) tend to occur at the center (i.e., zenith) of the pass.
Exceptions, as expected, are the conservative and random policies, which have no awareness of the satellite trajectory.Specifically, the conservative policy, always using SF12 and DR8, fails to exploit better channel conditions, while random policy eventually chooses the most aggressive SF and DR even when the satellite is rising in the horizon.Trajectory and trajectory random policies are able to take advantage of the trajectory information and make an accurate choice of SF and DR in each case.Nevertheless, a significant part of the satellite pass remains unused, especially the periods where the satellite is in the zenith of the devices, at the center of the pass, missing transmission opportunities over close (good) distances.In particular, the JI fairness is equal among conservative, random, and non-skip trajectory policies because in all cases devices attempt to transmit the 3 packets in the buffer in the first three possible frames.Thus, resulting in JI that is rather low (0.52).
This unfair allocation phenomena originated in the skip policies introduced in Section IV.Skip policies can be parametrized (p skip ) so that devices can choose to eventually skip potentially less efficient frames and wait for the central period of the pass.As expected, plain trajectory skip exhibits more aggressive SF and DR than trajectory random skip, which aims to profit from diversity by also using most robust modulations even during good channel conditions.Also, in both cases, JI improves notably to 0.89 in LoRa-L and 0.73 in LR-FHSS.
Finally, the MILP outcome in Fig. 7 confirms that the most efficient SF and DR allocation closely follows the trajectory of the satellite.The figure shows that the model delivers an ordered transmission schedule among all nodes, only feasible with centralized scheduling.Notably, the plot indicates that the central area of the pass also uses some robust SF (reddish), even though the channel would allow for a more aggressive one (blueish).This is because the optimization criteria of the model fully populates the center of the pass with SF7 and SF8, leaving only room to exploit the diversity of higher SFs.This is confirmed by the metrics reported in Table 7, where the frame count and total frame duration is reported.In particular, the theoretical model shows that the channel can be occupied 11576 seconds out of the 12000 second satellite pass, rendering a 96.4% channel utilization for a total of 12278 nonoverlapping transmitted frames.It is interesting to note that JI is slightly lower than skip policies, which evidences that a fair distribution of transmission among frames is not the only aspect in achieving an optimal schedule, as expressed in Eq. ( 6).In other words, the centralized scheduling allows to operate on the most efficient configuration taking the best out of the diversity and power efficiency trade-off.

VI. CONCLUSION
In this work, we delved into the direct-to-satellite IoT (DtS-IoT) paradigm to deliver efficient and global-wide data connectivity to remote and constrained IoT devices by means of orbiting satellite based gateways in low-Earth orbit.
A beacon-based system model on top of LoRa-L and LR-FHSS modulations was proposed together with multiple DtS-IoT specific uplink transmission policies that take advantage of available information of the satellite trajectory.Simulation results showed that the proposed Trajectory-based approaches outperform the baseline approaches, i.e., a conservative or random selection of Spreading Factors and Data Rates in LoRa-L and LR-FHSS, respectively.It has been shown that exploiting the trajectory information can help to, at least, duplicate the network scalability compared to non-trajectory aware schemes.Specifically, skip-based trajectory uplink transmission policies provide a 30% boost when the network approaches saturation.We demonstrated that such a gain in LoRa-L does not come at the expense of energy efficiency, which can notably be enhanced by more aggressive centralized scheduling solutions based on a novel MILP model specifically tailored for LoRa-based protocols.In addition to that, LR-FHSS modulation was observed to yield a factor 75 multiple in the served nodes, quantifying its benefits for satellite-based IoT.However, this comes at the expense of 30% more device power consumption compared to LoRa-L.Indeed, and profiting from its delay-tolerant nature, we claim that approaching the medium access control in DtS-IoT as a resource allocation problem can bring substantial benefit as the optimal exploitation of the scarce resources can be approximated with the proposed heuristics.
Therefore, future work includes the exploration of efficient wake-up schemes, confirmed uplink transmissions, and practical time-slotted scheduling approaches [27] likely complemented by suitable learning techniques [54] that could further improve the reported scalability, energy efficiency, and pass utilization metrics.

FIGURE 1 .
FIGURE 1. LEO satellite pass dynamics, distance and channel indicators, and SF selection at each reception power.

FIGURE 2 .
FIGURE 2. Data frames along a LEO satellite pass.

FIGURE 3 .
FIGURE 3. Dynamics of the evaluation scenario in 3D (left) and 2D (right) views.As a deployment example, IoT devices are uniformly distributed in a circle around −22.55, −64.85 deg latitude, longitude, with a radius of 20 deg.Chosen latitude and longitude position are arbitrary for the purpose of the image as any location on the planet would create the same LEO pass dynamic.Satellite pass starts at t = 0 seconds, reaching the zenith of the center of the area at t = 600 seconds, and terminating the pass at t = 1200 seconds.The line-of-sight cone of the satellite is indicated by the cyan volume.regional parameters).For this last case, we assume no interference from populated areas, representing a satellite pass over an open ocean or the North/South poles.The impact on

FIGURE 4 .
FIGURE 4. Scalability results for LoRa-L with 3CH: a) comparison of average extraction ratio for all uplink policies for different network sizes; b) details for each uplink policy of packets' behavior for different network sizes.The shadowed area behind the lines in the extraction ratio shown in a) stand for x minus the margin of error (lower end), and x plus the margin of error (upper end), where the margin of error is 2.045 * σ/ √ n for a 95% confidence interval with n-1 degrees of freedom, where n is the number of random seeds used for the simulations (see Table2).

FIGURE 5 .
FIGURE 5. Scalability results for LR-FHSS with 3CH and DR8/DR9 modulations: a) comparison of average extraction ratio for all uplink policies for different network sizes; b) details for each uplink policy of packets' behavior for different network sizes.The shadowed area behind the lines in the extraction ratio shown in a) stand for x minus the margin of error (lower end), and x plus the margin of error (upper end), where the margin of error is 12.71 * σ/ √ n for a 95% confidence interval with n-1 degrees of freedom, where n is the number of random seeds used for the simulations (see Table2).

FIGURE 6 .
FIGURE 6.Power consumption results for LoRa-L and LR-FHSS with 3CH and DR8/DR9 modulations.Colors in bars indicate the contribution each SF or DR to the average transmission time of the nodes.The table presents the averaged transmission seconds per node (Tx Secs.), the averaged extracted bytes per node (Ext.Bytes), and the effective rate (Eff.rate) indicating the extracted bits over the total transmission time.

FIGURE 7 .
FIGURE 7. Pass utilization for LoRa-L with 3CH transmission policies.