# FLoRaSat 2: Simulating Cross-Linked Direct-to-Satellite IoT LEO Constellations with Joint Access and Routing Evaluation

Alexander Y Choquenaira-Florez, Benoit Coeugnet, Robin Ohs, Juan A Fraire, Hervé Rivano

► To cite this version:

Alexander Y Choquenaira-Florez, Benoit Coeugnet, Robin Ohs, Juan A Fraire, Hervé Rivano. FLoRaSat 2: Simulating Cross-Linked Direct-to-Satellite IoT LEO Constellations with Joint Access and Routing Evaluation. International Journal of Satellite Communications and Networking, inPress. hal-05424077

HAL Id: hal-05424077

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

Submitted on 18 Dec 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
# FLoRaSat 2: Simulating Cross-Linked Direct-to-Satellite IoT LEO Constellations with Joint Access and Routing Evaluation

Alexander Y. Choquenaira-Florez<fnref n="1" /> | Benoit Coeugnet<fnref n="1" /> | Robin Ohs<fnref n="2" /> | Juan A. Fraire<fnref n="1" />,<fnref n="3" /> |
Hervé Rivano<fnref n="1" />

## Correspondence

Corresponding author Alexander Y.

Choquenaira-Florez.

Email: alexander.choquenaira-florez@inria.fr

## Abstract

Direct-to-Satellite IoT (DtS-IoT) has emerged as a promising solution for extending IoT connectivity to remote regions where terrestrial infrastructure is impractical or economically unfeasible. In such scenarios, Low-Earth Orbit (LEO) satellites act as mobile in-orbit gateways, but their dynamic nature and reliance on constrained Inter-Satellite Links (ISLs) introduce significant challenges for medium access, routing, and end-to-end performance evaluation. To address these issues, we present FLORASAT 2, an open-source, event-driven simulator based on OMNET++. The first version of FLORASAT focused on device-to-satellite communication, providing a unique tool to study LoRa/LoRaWAN-based DtS-IoT systems. The present work advances FLORASAT 2 into a full end-to-end simulation framework by integrating Medium Access Control (MAC) protocols with constellation-grade routing models, including constellation creation, dynamic ISL topology control, and a sandbox for benchmarking routing algorithms such as Directed, DDRA, and DiscoRoute. Notably, it introduces K-MAC, a repetition-based MAC scheme designed to improve resilience under Doppler effects, congestion, and intermittent visibility, while expanding the satellite and device modules to support multiple MAC protocols beyond LoRaWAN. To the best of our knowledge, FLORASAT 2 is the only open-source simulator capable of jointly evaluating access and routing layers for constellation-grade DtS-IoT networks. Through extended benchmark scenarios on Starlink- and Iridium-like constellations, we demonstrate how the integration of MAC and routing enables a more realistic and holistic assessment of network performance, positioning FLORASAT 2 as a versatile platform for the design and optimization of next-generation satellite IoT systems.

## KEYWORDS

Satellite Communication, LEO satellite, LORAWAN, LORA, IoT, Simulation, OMNET++

## 1 | INTRODUCTION

The growing number of space projects<fnref n="1" />, including innovative, cost-effective launch solutions and affordable nano-satellites such as *CubeSats*, has revamped the popularity of satellite communications. This opens up a possibility for telecommunication operators to expand Internet of Things (IoT) coverage and offer potential constant worldwide services<fnref n="2" />. Additionally, it also impacts the IoT community, which is continually exploring diversification in its applications<fnref n="3" />.

Low-Earth Orbit (LEO) satellites, such as *CubeSats*, are at the heart of the emerging space age since their unique characteristics can play a critical role in the new IoT era. These features include short orbital periods of 90 minutes at an altitude of 500 km and cost-effective and rapid deployment capabilities. Moreover, cost-effective satellites can act as mobile IoT gateways, providing connectivity to a geographic area for 6-12 minutes, up to 2-4 times daily. IoT devices can directly communicate with the gateway onboard LEO satellites using technologies with low power and long range, such as NB-IoT and LORA. These advantages can unlock applications in less accessible regions (e.g., oceans, deserts, poles, and other remote areas) where IoT gateways may not be economically justified⁴.

<footnote n="1">¹Inria, INSA Lyon, CITI, Villeurbanne, France</footnote>

<footnote n="2">²Saarland Informatics Campus, Saarland University, Saarbrücken, Germany</footnote>

<footnote n="3">³CONICET, Universidad Nacional de Córdoba, Córdoba, Argentina</footnote>
This type of application is known as Direct-to-Satellite IoT (DtS-IoT), which, besides its benefits, addresses critical and challenging problems⁵ such as transmission distances and channel dynamics, among others. The core network of the DtS-IoT system extends into the space domain. It must operate over low-bandwidth Inter-Satellite Links (ISLs), which also suffers from periodic changes due to the orbital dynamics.

In response to these difficulties, FLORASAT (Framework for LoRa-based Satellite IoT) was initially introduced in⁶ as an open-source event-driven simulator. It replicates the behavior of LoRa/LoRaWAN-based IoT systems and their interactions with satellite networks. The authors demonstrated the efficiency and benefits of FLORASAT for studying and analyzing the performance of LORAWAN DtS-IoT networks. The FLORASAT simulator leverages the well-known OMNET++ framework with its INET extension for the Internet stack and a LORAWAN protocol implementation adapted from the open-source simulator FLORA⁷. At this point in time, FLORASAT was positioned as a unique, comprehensive, and efficient solution for satellite network simulations. However, FLORASAT was strictly focused on the device-to-satellite link, ignoring the effect of the packet forwarding across the cross-linked LEO constellation.

The recent ASMS paper in⁸ introduced FLORASAT 2 to address the challenges of cross-linked DtS-IoT satellite constellations, with relevance for next-generation systems such as Starlink and Iridium. This conference paper expanded the original tool with modules for constellation design, dynamic ISL topology, routing, and event management, and proposed a routing sandbox to implement and benchmark algorithms such as Directed, DDRA, and DiscoRoute. Through dedicated use cases on Starlink and Iridium, the simulator was validated as a versatile platform for analyzing routing performance and benchmarking constellation-grade DtS-IoT networks. However, the ASMS paper lacked the modules and interfaces needed to couple the routing and access layers, preventing an effective end-to-end evaluation of DtS-IoT constellations.

This journal paper builds directly on the conference version of FLORASAT 2 by extending its original routing-focused design with a comprehensive integration of Medium Access Control (MAC) protocols‡. While the conference paper introduced routing-focused modules, the present work advances the simulator into a full end-to-end framework by coupling MAC and routing layers. To the best of our knowledge, FLORASAT 2 is the only open-source simulator that integrates access and routing layers for the system-level evaluation of DtS-IoT constellations. Specifically, FLORASAT 2 now incorporates a new K-MAC protocol, enabling repetition-based transmissions tailored to cope with Doppler effects, congestion, and intermittent visibility in LEO constellations, and expands the architecture of satellite and device modules to support multiple MAC schemes beyond LoRaWAN. This integration is validated through an additional benchmark scenario that evaluates the joint impact of routing and MAC on delivery performance, thereby transforming FLORASAT 2 from a routing-centric simulator into a versatile platform for holistic DtS-IoT constellation analysis. The specific contributions of this journal extension are:

* **Integration of MAC protocols:** Extension of the simulators architecture to jointly evaluate MAC and routing layers, enabling end-to-end performance analysis under realistic medium access conditions.

* **Design of K-MAC:** Introduction of a novel repetition-based MAC scheme tailored for LEO constellations, improving resilience against Doppler shifts, congestion, and intermittent visibility.

* **Extended device and satellite modules:** Support for multiple MAC schemes beyond LoRaWAN, broadening the applicability of FLORASAT 2 to diverse DtS-IoT scenarios.

* **New benchmark scenario:** Evaluation of the joint impact of MAC and routing on delivery performance, demonstrating the benefits of integrated protocol design compared to routing-only approaches.

The remainder of this paper is structured as follows. An overview of FLORASAT's unique characteristics is provided in Section 2. Section 3 introduces the novel developments and advancements in FLORASAT 2, including its extended architecture supporting constellations, explaining the new modules. The novel routing sandbox in FLORASAT 2 is presented in Section 4. Section 5 presents and provides some details of the integration of Medium Access Control (MAC) protocols with routing algorithms. Use case scenarios and their results are analyzed in Section 6, detailing the evaluation criteria for the MAC protocols. Finally, Section 7 summarizes the conclusions and future research directions.

<footnote>‡ To aid the reader, all new content introduced in this archival-quality extension of the conference paper is highlighted in dark blue.</footnote>
<table><caption>TABLE 1 Comparison of Tools Based on Functionalities</caption><thead><tr><td>Simulator</td><td>Orbital Propagator</td><td>Packet Simulation</td><td>DtS-IoT</td><td>Open Source</td><td>Constellation-Grade</td></tr></thead><tbody><tr><td>STK<sup>9</sup></td><td>✓</td><td>×</td><td>×</td><td>×</td><td>✓</td></tr><tr><td>Hypatia<sup>10</sup></td><td>✓</td><td>✓</td><td>×</td><td>✓</td><td>✓</td></tr><tr><td>OpenSAND<sup>12</sup></td><td>×</td><td>✓</td><td>×</td><td>✓</td><td>✓</td></tr><tr><td>GMAT<sup>13</sup></td><td>✓</td><td>×</td><td>×</td><td>✓</td><td>×</td></tr><tr><td>Orekit<sup>14</sup></td><td>✓</td><td>×</td><td>×</td><td>✓</td><td>×</td></tr><tr><td>SILLEO-SCNS<sup>15</sup></td><td>✓</td><td>×</td><td>×</td><td>✓</td><td>✓</td></tr><tr><td>FLORASAT<sup>6</sup></td><td>✓</td><td>✓</td><td>✓</td><td>✓</td><td>×</td></tr><tr><td>FLORASAT 2 (this paper)</td><td>✓</td><td>✓</td><td>✓</td><td>✓</td><td>✓</td></tr></tbody></table>

## 2 | FLORASAT OVERVIEW

One of the main challenges in the DtS-IoT domain is its evaluation since real in-orbit deployments are expensive and mostly inaccessible. As a result, the need for a realistic simulator that implements IoT and satellite dynamics is evident. To this end, FLORASAT (Framework for LoRa-based Satellite IoT) was initially introduced in<sup>6</sup> as an open-source, event-driven simulator that replicates the behavior of LoRa/LoRaWAN-based IoT systems and their interactions. It was designed to address the requirements for realistic simulation tools in DtS-IoT application environments. These include (i) an accelerated and effective simulation to analyze LEO orbits over long periods and (ii) a realistic implementation of the physical and medium access layers, accompanied by detailed modeling of the End-to-End (E2E) network layer.

### Related Tooling

In this context, FLORASAT is a unique tool. STK<sup>9</sup>, a widely used licensed software, offers robust analytical capabilities but precise complementary development to implement routing functionality. Another appealing alternative, Hypatia<sup>10</sup>, is an open-source tool software based on NS-3<sup>11</sup>, that provides a framework for easy and quick implementation of constellations comparable to FLORASAT. However, it lacks support for DtS-IoT scenarios. On the other hand, OpenSAND is an open-source software tool designed to provide an easy and flexible way to emulate an E2E satellite communication system<sup>12</sup>. However, it does not provide a comprehensive graphical interface that allows visual inspection of the entire constellation or packet tracking in flight. Another potential solution is the General Mission Analysis Tool (GMAT)<sup>13</sup>, an open-source platform independently developed by NASA in collaboration with the industry. GMAT only supports design and trajectory satellite optimization. Similarly, Orekit, written in Java, is an accurate and efficient tool for the design of space flight dynamics applications<sup>14</sup>. While Orekit is an excellent choice for space-related software development, its API is comparably low-level. Moreover, it does not provide ISL contact computation, benchmark, or constellation out-of-the-box evaluation capabilities as FLORASAT. Finally, SILLEO-SCNS appears as a noteworthy open-source option capable of simulating and analyzing satellite constellations, including ISL connectivity. However, its analytical capabilities are limited. Table 1 summarizes the features and capabilities of all the identified related tooling.

### 2.1 | Core Features in Original Version

FLORASAT leverages the well-established OMNET++ framework with the INET extension, which provides internet stack services and incorporates the open-source FLORA implementation. The authors also customized the physical layer (LORA) and the link layer (LORAWAN) to the DtS-IoT configuration. Next, we provide an overview of the core features of the original version.

* **Orbital Mechanics:** The system uses Contact Plan Designer<sup>16</sup> to create an orbital processing pipeline and respond to the changes in the orbital dynamics.

* **Beacon-Based Radio:** Beacons can play a critical role in announcing satellite presence<sup>17</sup>. FLORASAT follows the LORAWAN standards by implementing Class B while retaining legacy Class A support for compatibility.

* **Channel Model:** Inspired by<sup>18</sup>, FLORASAT employs a simple channel model for attenuation, interference, and the capture effect at the receiver. These factors significantly affect uplink and downlink performance.
The early version of FLoRaSat⁶ was focused on the LORA / LORAWAN MAC layer between the satellite and the devices on the ground. Only a simplistic “right-up and down-left” hard-coded routing method was implemented for managing uplink and downlink traffic. This was insufficient to address the analysis demands of emerging multi-satellite DtS-IoT constellations with data exchange in orbit. The remainder of this paper presents FLORASAT 2, which addresses the crucial aspect of constellation analysis in DtS-IoT.

## 3 | FLORASAT 2: CONSTELLATION MODULES

This section introduces new and additional features developed to enhance its capabilities and address critical challenges in designing simulation scenarios based on cross-linked satellite constellations. We have developed several new modules to enhance the simulators capabilities and address challenges in modeling more sophisticated scenarios.

These additions expand FLORASAT’s functionality by incorporating modules that simulate cross-link capabilities. Each new module enables more accurate environmental representation, especially modeling ISL communications, for a detailed analysis and interpretation. The code developed for this work is publicly available<fnref n="8" />. Next, we will describe the new major modules in detail, outlining their functionality, parameters, and outputs. The routing sandbox is analyzed separately in Section 4.

### 3.1 | Constellation Creator

The Constellation module configures the necessary orbital parameters for each satellite. The module enables the definition of complex satellite constellations, such as Walker-Delta and Walker-Star, directly from high-level Walker notation, reducing the risk of errors associated with manual configuration. It also allows users to implement complex constellations, such as OneWeb¹⁹,²⁰ or Starlink systems.

The satellite positions generated by this module were validated against reference values extracted from STK⁹, a widely used tool in research and industry. Comparison showed minimal differences in latitude and longitude values, demonstrating the reliability of the module’s results. The parameters required for the constellation module are detailed in Table 2 and obtained through a configuration file at the beginning of the simulation, where we can highlight the interplane spacing, which defines the relative offset in the argument of latitude between neighboring satellites in adjacent orbital planes²¹.

<table><caption>TABLE 2 Module Parameters and Metrics</caption><thead><tr><th>Constellation Creator</th><th>Topology Control</th><th>Statistics</th></tr><tr><th>Parameters</th><th>Parameters</th><th>Metrics</th></tr></thead><tbody><tr><td><ul><li>Number of gateways</li><li>Index</li><li>Initial mean anomaly</li><li>RAAN</li><li>Altitude</li><li>Eccentricity</li><li>Orbit inclination</li><li>Plane Count</li><li>Interplane Spacing</li></ul></td><td><ul><li>Minimum Elevation</li><li>Data Rate (ISL, Ground)</li><li>Delay (ISL, Ground)</li><li>Update Interval</li><li>Walker Type</li><li>ISL Status</li><li>Interplane Spacing</li><li>Plane Count</li></ul></td><td><ul><li>Hopcount</li><li>Distance</li><li>Delivery Ratio</li><li>Packet Loss</li><li>Throughput</li><li>Drop heatmap</li><li>E2E Delay</li><li>Avg. queue size</li><li>Protocol Overhead</li><li>Failure comparison</li></ul></td></tr></tbody></table>

<footnote n="8">⁸ GitLab repository: https://gitlab.inria.fr/jfraire/florasat/-/tree/FLoRaSat_v2</footnote>
## 3.2 | Topology Control

On the other side, the *Topology* module is responsible for managing communication channels between satellite modules and ground modules. Additionally, this module is responsible for periodically updating the inter-plane ISLs and Ground-Satellite Link (GSL) to account for changing distances caused by movements. The parameters considered for the topology control can be detailed in Table 2. We can highlight the minimum elevation, which is the minimum angle required to establish a connection between ground stations and satellites²²; data rate, the amount of data transmitted per unit time; Walker type that indicates the type of Walker constellation, such as *Star* or *Delta*.

## 3.3 | Event Manager

Due to the harsh environment and the lack of repair capabilities, we have implemented an *Event Manager* module that temporarily or permanently disables inter-satellite links. The idea is to test routing algorithms for their adaptability to failures, which complements FLORASAT's ability to test congestion handling mechanisms. This is done according to a scenario file loaded by the simulator during startup.

## 3.4 | Visualization and Metrics

We developed FLORASAT-CLI (Command Line Interface), a functionality to analyze simulation results through metrics and visualizations efficiently. FLORASAT uses C++ as its primary programming language, which is unsuitable for performing statistical and graphical analyses. Alternatively, Python offers a wide range of specialized packages for data analysis, e.g., *Pandas*, *Matplotlib*, and *Scipy*, among others. This module serializes the collected results into well-defined CSV files for Python use.

However, the pre-processing step requires managing large amounts of data to calculate output metrics. We use a *Rust* implementation to handle this task efficiently, which reduces runtime and avoids memory limit problems. The *Rust* code is built as a cdylib library, which allows a direct import in Python code. Finally, FLORASAT-CLI supports the creation of comparative graphs and charts for metrics detailed previously. All the plots in the use case analyses presented in Section 6 are obtained from FLORASAT-CLI.

Due to its flexible architecture, it is essential to highlight that additional graphs, metrics, or output formats can be easily incorporated into the module.

## 3.5 | Extended Architecture

This subsection overviews the redesigned architecture, emphasizing the integration of new modules to enhance modularity, scalability, and efficiency in complex scenarios.

The initial architecture adopted a modular design, with an OMNET++ module reflecting each component. As new modules were introduced, the architecture was extended, necessitating a thorough explanation of the behavior and interaction between all modules. Figure 1 presents the new architecture, where each block represents a module of FLORASAT with its main components. Next, we will explore each components features and interactions, providing insights into their roles.

As core components, the *Device* and *Satellite* modules are primarily responsible for implementing LORA and LORAWAN operations within satellite and ground devices. Previously, to ensure seamless communication, these tasks included multiplexing and retransmitting LORAWAN frames between satellites and ground devices. In this new version, the modules have now been extended to support additional MAC protocols as we describe in the following sections. These modules also manage mobility operations, which are crucial in simulation scenarios. On the other hand, the constellation module considers the parameters detailed in Table 2 to create each element of the constellation accurately. Closely related, the routing sandbox (described in the following section) utilizes the specified routing algorithm to establish connections across the network. Finally, given that the statistics module requires a high computational cost, it is not directly integrated into FLORASAT because it can significantly influence the simulation speed (simulated seconds per real second). Managing this last module separately allows the simulator to maintain an efficient and flexible simulation environment.
<figure><img src="image_2.png" /><figcaption>FIGURE 1 The extended architecture of FLORASAT. Orange modules were introduced in FLORASAT 2.</figcaption></figure>

<figure><img src="image_3.png" /><figcaption>FIGURE 2 Structure of the *RoutingBase* Abstract Class and implementations</figcaption></figure>

## 4 | FLORASAT 2: ROUTING SANDBOX

The *Routing* sandbox is based on an abstract class to facilitate the creation and seamless integration of new routing algorithms required by satellites and ground stations to enable support for a wide variety of routing algorithms. Additionally, the module facilitates the easy and fast integration of new routing algorithms, which expands its utility for researching and developing new routing strategies.

The abstract class is called *RoutingBase* and defines functions that each novel routing algorithm must implement. An example of this structure can be seen in Figure 2. We describe each function below and the main aspects to consider when implementing new routing algorithms.

* **handlePacket**: It is responsible for the further processing of the packet and routing instructions. If the packet arrives at the destination, it should execute the appropriate steps that depend on the routing algorithm. Otherwise, the function should determine the next hop by calling `sendMessage` or drop the packet if necessary and call `dropPacket`. This function is the only mandatory one for new routing algorithms extending the *RoutingBase*.

* **handleTopologyChange**: The topology control calls this function after any predictable topology change. It can be used to calculate new routes and store the next hop inside a forwarding table or to reset the state.

* **preparePacket**: This function is not required for all routing algorithms since it performs additional operations on the packet. An example of an operation could be calculating the full path to the destination satellite and storing it in the packet header.

* **wrapUpPacket**: Similar to the previous function, it is not always required. This function is called before a packet is sent to a GSL. An example of using this function can be removing routing protocol-specific headers before the packet is reinserted into the regular network.
* **handlePacketDrop:** It notifies the routing module when a packet is dropped. This function can be applied to congestion control or fault recovery scenarios.

* **handleQueueSize:** This function reports the current and maximum processing queue size to the routing module. For example, it can be used as a trigger when a specific queue length is reached to send congestion notifications to neighboring satellites.

Below, we list some routing algorithms implemented in the latest routing module in FLoRaSat 2: DIRECTED routing, DDRA, and DISCOROUTE.

## 4.1 | Directed Routing

DIRECTED routing is a simple algorithm that employs the Manhattan distance as the heuristic to select the next hop, as suggested in$^{23}$. The algorithm selects the next hop from an open list of potential nodes. Calculating the Manhattan distance requires specific considerations. In the case of a Walker-Star type constellation, assuming a network with $v$ planes and $w$ satellites per plane, the Manhattan distance between A and B can be determined using Equation 1.

$$ 
\begin{aligned}
d_1 &= |A_x - B_x| + |A_y - B_y| \\
d_2 &= 1 + A_y + |A_x - B_x| + |(w-1) - B_y| \\
d_3 &= w - A_y + |A_x - B_x| + |0 - B_y| \\
d &= \min(d_1, d_2, d_3)
\end{aligned} 
\quad (1) $$

On the other hand, if the algorithm is applied to Walker-Delta constellations, the Equation 2 should be considered. It adds the new possible paths for horizontal cyclic edges from left to right, along with the vertical and horizontal cyclic hop.

$$ 
\begin{aligned}
d_1 &= |A_x - B_x| + |A_y - B_y| \\
d_2 &= 1 + A_y + |A_x - B_x| + |(w-1) - B_y| \\
d_3 &= w - A_y + |A_x - B_x| + |0 - B_y| \\
d_4 &= 1 + A_x + |(v-1) - B_x| + |A_y - B_y| \\
d_5 &= v - A_x + |0 - B_x| + |A_y - B_y| \\
d_6 &= v - A_x + w - A_y + |0 - B_x| + |0 - B_y| \\
d_7 &= v - A_x + 1 + A_y + |0 - B_x| + |(w-1) - B_y| \\
d_8 &= 1 + A_x + w - A_y + |(v-1) - B_x| + |0 - B_y| \\
d_9 &= 1 + A_x + 1 + A_y + |(v-1) - B_x| + |(w-1) - B_y| \\
d &= \min(d_1, d_2, d_3, d_4, d_5, d_6, d_7, d_8, d_9)
\end{aligned} 
\quad (2) $$

## 4.2 | DDRA

The Dynamic Detection Routing Algorithm (DDRA), initially proposed in$^{24}$, is a reactive algorithm that optimizes shortest path selection. The algorithm divides the satellite's period into time slices, where the constellation routing topology remains constant. Following this technique, there are two types of changes: predictable changes, which occur when a new topology is loaded in the next time slice, and sudden changes, generated by congestion or failures.

DDRA employs the DSPA techniques introduced by$^{25}$, using the precomputed shortest path to each satellite at each time slice as the potential optimal route. This does not guarantee that packets will take the shortest path but can significantly reduce processing power consumption. Additionally, the authors propose a congestion control mechanism where each satellite periodically monitors the number of packets in its queue. The satellite reports its congestion status to neighboring nodes if it exceeds a specified threshold. The threshold is calculated as follows:

$$ Threshold \leq \frac{T_{MAX}}{M} \times \frac{V_{MAX}}{L_{MIN}} \quad (3) $$
where $T_{MAX}$ is the maximum tolerable delay normally default to 500ms, $M$ is the average number of hops in the constellation, $V_{MAX}$ is the maximum link transmission data rate, and $L_{MIN}$ refers to the minimum packet length.

## 4.3 | DiscoRoute

This routing algorithm<sup>26</sup> is specially focused on mega-constellations comprising hundreds or thousands of satellites but only applies to Walker-Delta constellations. DISCORoute uses the orbital elements to calculate the minimum number of ISL hops between a satellite pair. Leveraging the deterministic nature of satellite orbital parameters, this algorithm aims to optimize inter-plane hops by prioritizing transitions near the poles, where the distance between pairs of satellites is smaller than at the equator. According to the authors, the DISCORoute algorithm requires shorter processing times than DDRA and offers greater scalability.

# 5 | MAC MODULES

## 5.1 | Background for MAC

MAC protocols are mainly responsible for managing the effective access to shared resources, which are particularly critical in satellite communications since these are expensive and limited. In the satellite domain, the primary role of a MAC is to regulate the multiple access to the satellites’ resources, in the uplink and downlink processes, guaranteeing an efficient use by avoiding interference, reducing collisions, and minimizing the energy waste<sup>27</sup>.

The MAC layer should implement mechanisms that prioritize a diverse set of application requirements. For example, in satellite communications, guaranteeing the Quality of Services (QoS) is critical, since these applications support heterogeneous traffic such as video, voice, telemetry, ground-observation, among others. Also, but no less important, it should consider security and reliability since the environment of these applications exposes them to potential threats, and the harsh medium can create link errors and intermittent connectivity. In addition, there are a number of technical challenges that MAC protocols in the satellite domain should address<sup>28</sup>. Particularly in LEO systems, the fast-moving objects create significant Doppler shifts, which complicate synchronization.

For satellite networks, the MAC protocols are generally classified into two main categories: random access and fixed schedule access-based approaches<sup>28</sup>. Random Access protocols, such as ALOHA and its derivatives, allow transmissions whenever they have information to send. However, despite its simplicity, it also increases the probability of collisions, requiring re-transmissions and reducing the network efficiency. In contrast, fixed schedule access-based protocols require a request before the transmission, thereby reducing the probability of collision and guaranteeing the QoS required. Some examples of these protocols include Time Division Multiple Access (TDMA) and Frequency Division Multiple Access (FDMA), among others.

## 5.2 | MAC and Routing Integration

The integration of MAC protocols with routing algorithms provides FLORASAT the potential to consider several constraints and congestion conditions to improve the network efficiency. This integration has the potential to reduce and monitor critical aspects of IoT applications, such as E2E latency, packet loss, among other measurements. Additionally, it also provides the ability to optimize the routing strategy, giving more priority to routes with lower congestion. Overall, MAC and routing integration provide a more adaptive, resilient, and efficient communication simulator to address the unique challenges of DtS-IoT applications.

We can summarize the process that we followed as follows: First, the required operations for the physical and data link layers are performed. Several related chunks are attached to the packet, including the LoRaPhy and MacFrame, which encapsulate critical information for the correct transmission and interpretation. Then, before the transmission begins, the routing algorithm selects the optimal route across the satellite constellation and adds this information to the packet. At this stage, the overall structure is visible in the Figure 3.

The LoRaPhy chunk typically includes classical parameters that define how the signal is physically transmitted, such as spreading factor, bandwidth, and power, among others. The MacFrame chunk adds traditional information like addresses. The
<figure><img src="image_4.png" /><figcaption>**FIGURE 3** Structure of the LORAWAN *packet* after processing</figcaption></figure>

Routing Header incorporates information related to the routing path, such as identifiers of the first and last satellite, the number of hops, etc. Finally, the LoRaAppPacket section contains application data. Then, the structure is modified according to the requirements of the network process.

## 5.3 | K-Mac

The MAC scheme presented in this work is a repetition-based protocol designed to enhance the probability of successful delivery, particularly in scenarios with Doppler effects, congestion, and intermittent visibility of satellites, among others. In this scheme, each device transmits the same message *N* times. To maintain simplicity in the scheme, a single transmission window was utilized for each message, with multiple repetitions scheduled. Consequently, four parameters are available for setting:

* **Time to start the transmission:** Represents the delay between the creation of the message and the transmission of its first repetition.

* **Time between the transmissions:** Specifies an idle interval between consecutive repetitions to avoid collisions.

* **Time to next message:** Indicates the interval between transmissions on the same device.

* **Number of repetitions (N):** Represents the total number of repetitions of each message that will be transmitted.

Note that to define the duration of the transmission window, we need to consider the number of repetitions, the time to start the transmission, and the time between transmissions.

## 6 | USE CASES

In this section, we evaluate the new modules presented in this work. To this end, we propose three benchmark scenarios: the first two evaluate the integration of the MAC protocol and Routing algorithms with a constellation of LEO satellites, applying different routing algorithms, and comparing their performance. On the other hand, the third scenario evaluates the performance of the new MAC scheme over a constellation of LEO satellites by comparing two cases: one that applies a routing algorithm, and another where the satellites retain the messages until they reach the transmission range.

For the first two scenarios, twenty globally distributed ground stations transmit through the satellite constellation to the nearest end device selected from a total pool of thirty available end devices. The resulting scenario is configured with a total runtime of 30 simulated minutes, with a packet generation interval of 50 seconds. Additionally, the satellites' queue capacity is set to 40 for ISL transmissions. For downlink transmissions, the network is configured to execute them rapidly and immediately to avoid potential congestion scenarios and allow a more concrete analysis of the integration between routing mechanisms and the MAC protocol.

The last scenario consists of a constellation of 66 satellites, 20 globally distributed ground stations, and 288 devices that transmit to the nearest ground station. The simulation is configured with a total runtime of more than 10 hours and considers two distinct cases: with ISL and without ISL. For the first case, the ISL links are enabled, and the DDRA routing algorithm is applied. Conversely, in the second case, the ISL links are disabled, and the data should be retained until the destination comes within the transmission range.
<figure><img src="image_5.png" /><figcaption>FIGURE 4 Configuration file Iridium Constellation</figcaption></figure>

<figure><img src="image_6.png" /><figcaption>FIGURE 5 Configuration file for Starlink constellation</figcaption></figure>

Simulations were executed in a Docker-based Ubuntu Linux environment (Kernel 6.10.14) with 13 GB of RAM, running on a macOS host system with an Apple M3-Pro processor.

## 6.1 | Comparison of Routing Algorithms DDRA vs. DISCROUTE

The first scenario consists of a Walker-Delta Starlink constellation composed of 1584 satellites. Main parameters are configured in a config file, which is then loaded by the FLORASAT simulator. The values used in this benchmark scenario are shown in Figure 5.

After setting the simulation parameters, running the simulations will generate CSV files containing the collected runtime metrics for both algorithms. We use the FLORASAT-CLI to analyze these metrics and generate corresponding graphs, demonstrating one major strength of FLORASAT. Figure 6 presents some graphics generated using the FLORASAT-CLI with the scenario simulation detailed. Next, we will analyze each of these graphics in detail.
<figure><img src="image_7.png" /><figcaption>FIGURE 6 Comparative graphs created by the FLORASAT-CLI for the first benchmark.</figcaption></figure>

## Hop Count and Distance

Although both algorithms exhibit a similar average number of hops, DISCOROUTE performs slightly better than DDRA in average hop count. We also noticed in the Figure 6-a) that both algorithms reach at most 6 hops. Furthermore, these results also explain why the average route length and the packet loss performance of both algorithms are similar, as can be seen in Figure 6-b) and Figure 6-d). Additionally, the CDF grows faster for DDRA, which indicates its capability to deliver a higher proportion of packets with fewer hops or distances.

Leveraging the preprocessed routes generated through FLORASAT-CLI, we extract and analyze the shortest and longest routes packets take. Figure 7 shows the routes and hops through the satellite constellation. Projection angles were adjusted to enhance visualization. The Figure 7 confirms the observations described earlier. Given the configuration of this scenario, where the destination is the closest device, the number of hops has decreased significantly. This capability enables detailed analysis across the network, providing insights into the routing algorithms and identifying potential bottlenecks.

## E2E Delay

The Figure 6-c) shows the average E2E delay CDF for delivered packets using DDRA and DISCOROUTE algorithms. Both exhibit similar delays. However, the plot slightly suggests that, under regular conditions, DISCOROUTE achieves better performance compared to DDRA. This can be explained by the fact that DDRA incorporates failure response mechanisms, which can result in additional hops and transmission time.
a) DDRA

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

b) Disco

<figure><img src="image_9.png" /><figcaption>**FIGURE 7** Analysis of routes preprocessed by FLORASAT-CLI</figcaption></figure>

*Packet Loss Comparison*

Finally, the Figure 6-d) shows the packet loss for the previously mentioned scenario. Under the conditions, both algorithms demonstrate similar packet loss performance. DISCOROUTE shows a slight advantage in reducing packet loss compared to DDRA. Since, in this design, the destination is the nearest device, the failure response capabilities from DDRA do not impact the overall performance of the network. Moreover, it is necessary to highlight that the failure response capabilities from DDRA will provide significant benefits under more challenging conditions, such as high failure probability.
<figure><img src="image_10.png" /><figcaption>FIGURE 8 Comparative graphs created by the FLORASAT-CLI for the second benchmark.</figcaption></figure>

## 6.2 | Comparison of Routing Algorithms DDRA vs. DIRECTED

The second scenario tests the ability of DIRECTED and DDRA algorithms. It is based on a Walker-Star Iridium constellation composed of 66 LEO satellites. The main parameters of the constellation can be seen in Figure 4.

Similar to the previous case, we use the FLORASAT-CLI to generate graphics, which we will discuss in detail next. The Figure 8 evidences that under the scenario conditions, both simulations exhibit similar performance. We support this observation through the visualizations created using FLORASAT-CLI.

### *Hop Count and Distance*

We observed a similar performance against previous simulations, although with slight differences in Figure 8 panels (a) and (b). There is a reduction in the average hop count terms, but the opposite effect occurs in terms of distance. Both differences can be explained by the size of the constellations, which forces packets to cover longer paths.

### *E2E Delay*

The Figure indicates that both algorithms have similar performance. However, there is a slight advantage for DDRA that can be explained by the faster growth in the CDF values for hop count and distance in Figure 8 panels (a) and (b).
<figure><img src="image_11.png" /><figcaption>FIGURE 9 Configuration Iridium Constellation for MAC Evaluation</figcaption></figure>

### Packet Loss Comparison

Finally, the Figure shows a slightly better performance of DDRA. This can be explained by the fact that DIRECTED covers a greater distance than DDRA, which may contribute to packet losses. Despite this, there is no significant difference in the performance of both algorithms.

## 6.3 | MAC Evaluation

The third scenario consists of a Walker-Delta Iridium constellation, which is composed of 66 satellites and 288 devices uniformly distributed across the Earth. The parameters can be seen in Figure 9. Each device is therefore at an equal distance from the others on a 3D map and transmits five messages. The main objective of this scenario is to evaluate the impact of increasing the repetitions on the MAC scheme. Therefore, each message will be sent between one and twelve times, depending on the scenario.

Both parameters, 'time to start transmission' and 'time between transmissions', are random values between 0 and 60 seconds. For each repetition, the parameter 'time to next message' is set to the maximum time that the longest scenario is expected to take. In this scenario, the longer simulation involves 12 repetitions, which may take a maximum of 12 minutes to complete. A new message will be generated approximately every 12 minutes, with a small random offset of up to 1 minute. The simulations run until no devices have packets to transmit. In this case, the total simulation time took approximately 1.1 hours. The Figure 10 presents a comparison of both scenarios. Next, we will analyze it in detail.

### Analysis at ground

In the first repetitions, there was a better performance for the scenario without ISLs. However, after the 5th repetition, the ISL case overpasses the non-ISL's results. This phenomenon occurs because, for lower repetitions, the messages often fail to reach the route path satellite to start the routing process. This behavior can be seen in Figures 10 panels (a) and (b).

### Analysis at satellites

For both scenarios, the reception rate at satellites is very high (over >95%). As Figure 10-c) suggests, the messages that reach the route path satellite to start the route process are very low. This can be explained by the fact that the devices transmit the messages to all the satellites within range. However, the routing process only starts if the messages reach the satellite calculated by the routing algorithm; this difference decreases with the repetitions.

### Collisions

We can see in Figure 10-e) that for both scenarios, with and without ISL, the number of collisions increases with the repetitions, reaching a maximum of 14,000 collisions. These results are consistent with expectations, since more repetitions increase the probability of collisions reflected in the plot.
<figure><img src="image_12.png" /><figcaption>FIGURE 10 Comparative graphs for both scenarios.</figcaption></figure>

Average delay

Finally, Figure 10-f) highlights the difference in the time delay between the scenarios. We noticed that for the ISL scenario, the delay is significantly lower (~ 50 – 85 s), which means that the messages arrive faster at the destination than without the ISL scenario (~ 450 s). For more repetitions, the ISL scenario provides a better delay ratio. This difference highlights the most significant benefit of employing ISL.
## 6.4 | FLORASAT 2 Limitations

Despite the potential of these new modules, they have some limitations. Their use requires proficiency in C++ and OMNET++, which can pose a steep learning curve for unfamiliar users. Additionally, the system requirements for large-scale simulations are demanding, potentially impacting performance and execution time. While OMNET++ is designed for serial execution inherent to discrete-event simulations, it supports multiple simulations running in parallel and allows multithreaded execution of C++ routines within individual events. Lastly, the visualization and statistics module is limited to comparing two algorithms simultaneously, restricting the scope for more complex and comprehensive evaluations.

## 7 | CONCLUSION AND FUTURE WORK

The main contribution of this work is the development and enhancement of FLORASAT 2, an advanced publicly available simulation tool tailored for analyzing cross-linked DtS-IoT constellations. This includes essential new modules, such as constellation creation, dynamic topology control, routing, and event management, which enable precise and flexible modeling of large-scale DtS-IoT satellite networks. Additionally, integrating a flexible routing sandbox facilitates the seamless implementation and evaluation of diverse routing algorithms tailored for constellation-grade DtS-IoT scenarios.

A standout contribution is the FLORASAT-CLI module, a robust Python-based analytics and visualization tool used to analyze two representative use cases: the evaluation of Starlink and Iridium topologies. These use cases demonstrate FLORASAT 2's unique ability to validate routing algorithms and assess complex constellation designs effectively. Together, these advancements position FLORASAT 2 as a versatile E2E simulation platform, providing researchers with a comprehensive resource for analyzing and optimizing satellite communication and IoT networks.

Additionally, this journal paper introduces the K-MAC scheme. This simple repetition-based approach addresses critical challenges in DtS-IoT scenarios, including the Doppler effect and short visibility periods. The use cases employed to validate the proposed scheme demonstrate the flexibility in variable conditions, and due to its simplicity, it emerges as a promising candidate scheme for specific scenarios. This new feature also demonstrates the inherent flexibility of FLORASAT to adapt to new MAC scheme protocols.

Although the integration of a new MAC protocol into FLORASAT was successfully achieved, future developments should focus on the development and addition of a potential dedicated MAC Sandbox that facilitates the seamless implementation, integration, and evaluation of customized MAC protocols, ensuring FLORASAT's robustness in practical deployments. This feature can significantly extend FLORASAT's utility for research and development of MAC protocols in specific application scenarios. Moreover, this sandbox will enable detailed studies of the performance of MAC protocols, supporting the exploration of adaptive MAC schemes and machine learning-driven optimizations. By incorporating these enhancements, FLORASAT 2 will solidify its role as a pivotal tool for next-generation DtS-IoT systems.

## ACKNOWLEDGMENT

This project has received funding from the European Union's Horizon 2020 research and innovation program under the Marie Skodowska-Curie grant agreement No 101008233 (MISSION) and the French National Research Agency (ANR) under the project ANR-22-CE25-0014-01.

## REFERENCES

1. Leyva-Mayorga Iea. LEO small-satellite constellations for 5G and beyond-5G communications. *IEEE Access*. 2020;8. doi: 10.1109/ACCESS.2020.3029620

2. Palattella MR, Accettura N. Enabling internet of everything everywhere: LPWAN with satellite backhaul. In: 2018 Global Information Infrastructure and Networking Symposium (GIIS)IEEE. 2018; Greece:1-5

3. Centenaro Mea. A survey on technologies, standards and open challenges in satellite IoT. *IEEE Communications Surveys & Tutorials*. 2021;23(3):1693-1720. doi: 10.1109/COMST.2021.3078433

4. De Sanctis Mea. Satellite communications supporting internet of remote things. *IEEE Internet of Things Journal*. 2015;3(1):113-123. doi: 10.1109/JIOT.2015.2487046

5. Fraire JA, Céspedes S, Accettura N. Direct-to-satellite IoT-a survey of the state of the art and future research perspectives: Backhauling the IoT through LEO satellites. In: International Conference on Ad-Hoc Networks and WirelessSpringer. 2019:241-258. https://doi.org/10.1098/rspa.1937.0036
6. Fraire JA, Madoery P, Ait Mesbah M, Iova O, Valois F. Simulating lora-based direct-to-satellite iot networks with florasat. In: 2022 IEEE 23rd International Symposium on a World of Wireless, Mobile and Multimedia Networks (WoWMoM)IEEE. 2022; Belfast, United Kingdom:464-470

7. Slabicki M, Premsankar G, Di Francesco M. Adaptive configuration of LoRa networks for dense IoT deployments. In: NOMS 2018-2018 IEEE/IFIP Network Operations and Management SymposiumIEEE. 2018; Taipei, Taiwan:1-9

8. Choquenaira-Florez AY, Ohs R, Fraire JA, Rivano H. FLoRaSat 2: Simulating Cross-Linked Direct-to-Satellite IoT LEO Constellations. In: 2025 12th Advanced Satellite Multimedia Systems Conference and the 18th Signal Processing for Space Communications Workshop (ASMS/SPSC)IEEE. 2025:1-8

9. Ansys Inc. STK (Systems Tool Kit). Online resource; 2024. [Accessed 26-08-25], https://www.ansys.com/products/missions/ansys-stk.

10. Kassing Sea. Exploring the Internet from space with Hypatia. In: Proceedings of the ACM Internet Measurement ConferenceACM. Association for Computing Machinery 2020

11. Riley GF, Henderson TR. The ns-3 network simulator:15-34; Springer. 2010

12. Thales Group. OpenSAND. Online resource; [Accessed 26-08-25], https://www.opensand.org/references.html.

13. NASA. General Mission Analysis Tool (GMAT). Online resource; [Accessed 26-08-25], https://software.nasa.gov/software/GSC-17177-1.

14. Maisonobe L, Pommier V, Parraud P. Orekit: An open source library for operational flight dynamics applications. In: 4th international conference on astrodynamics tools and techniquesEuropean Space Agency Paris. 2010:3-6.

15. Kempton BS. A Simulation Tool to Study Routing in Large Broadband Satellite Networks. Online resource; 2020.

16. Fraire JA. Introducing contact plan designer: A planning tool for DTN-based space-terrestrial networks. In: 2017 6th International Conference on Space Mission Challenges for Information Technology (SMC-IT)IEEE. 2017; Madrid, Spain:124-127

17. Vogelgesang K, Fraire JA, Hermanns H. Uplink transmission probability functions for LoRa-based direct-to-satellite IoT: A case study. In: 2021 IEEE Global Communications Conference (GLOBECOM)IEEE. 2021; Madrid, Spain:01-06

18. Janhunen J, Ketonen J, Hulkkonen A, Ylitalo J, Roivainen A, Juntti M. Satellite uplink transmission with terrestrial network interference. In: 2015 IEEE global communications conference (GLOBECOM)IEEE. 2015; San Diego, California:1-6

19. OneWeb F. OneWeb Amendment Phase 1. https://fcc.report/IBFS/SAT-MPL-20200526-00062/2379565.pdf; 2020. [Accessed 26-08-25].

20. OneWeb F. OneWeb Amendment Phase 2. https://fcc.report/IBFS/SAT-MPL-20200526-00062/2379706.pdf; 2020. [Accessed 26-08-25].

21. Chen Q, Guo J, Yang L, Liu X, Chen X. Topology Virtualization and Dynamics Shielding Method for LEO Satellite Networks. IEEE Communications Letters. 2020;24(2):433-437. doi: 10.1109/LCOMM.2019.2958132

22. Werner M, Jahn A, Lutz E, Bottcher A. Analysis of system parameters for LEO/ICO-satellite communication networks. IEEE Journal on Selected Areas in Communications. 1995;13(2):371-381. doi: 10.1109/49.345881

23. Pohl I. Heuristic search viewed as path finding in a graph. Artificial intelligence. 1970;1(3-4):193-204. doi: 10.1016/0004-3702(70)90007-X

24. Tan H, Zhu L. A novel routing algorithm based on virtual topology snapshot in LEO satellite networks. In: 2014 IEEE 17th International Conference on Computational Science and EngineeringIEEE. 2014; Chengdu, China:357-361

25. Dijkstra EW. A note on two problems in connexion with graphs. In: Edsger Wybe Dijkstra: his life, work, and legacy, Springer-Verlag, 2022:287-290

26. Stock G, Fraire JA, Hermanns H. Distributed on-demand routing for leo mega-constellations: A starlink case study. In: 2022 11th Advanced Satellite Multimedia Systems Conference and the 17th Signal Processing for Space Communications Workshop (ASMS/SPSC)IEEE. 2022; Graz, Austria:1-8

27. Ortigueira R, Fraire JA, Becerra A, Ferrer T, Cespedes S. RESS-IoT: A scalable energy-efficient MAC protocol for direct-to-satellite IoT. IEEE Access. 2021;9:164440-164453. doi: 10.1109/ACCESS.2021.3134246

28. Le TTT, Hassan NU, Chen X, Alouini MS, Han Z, Yuen C. A survey on random access protocols in direct-access LEO satellite-based IoT communication. IEEE Communications Surveys & Tutorials. 2024;27(1):426-462. doi: 10.1109/COMST.2024.3385347