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

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 com- munication, 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 algo- rithms 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 mod- ules 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. 1 Received: Added at production Revised: Added at production Accepted: Added at production DOI: xxx/xxxx FLoRaSat 2: Simulating Cross-Linked Direct-to-Satellite IoT LEO Constellations with Joint Access and Routing Evaluation Alexander Y. Choquenaira-Florez1 Benoit Coeugnet1 Robin Ohs2 Juan A. Fraire 1,3 Hervé Rivano1 1Inria, INSA Lyon, CITI, Villeurbanne, France 2Saarland Informatics Campus, Saarland University, Saarbrücken, Germany 3CONICET, Universidad Nacional de Córdoba, Córdoba, Argentina Correspondence Corresponding author Alexander Y . Choquenaira-Florez. Email: alexander.choquenaira-fl[email protected]

Direct-to-Satellite IoT (DtS-IoT) has emerged as a promising solution for extending IoT connectivity to re- mote 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 FL ORASAT 2, an open-source, event-driven simulator based on OMN ET++. The first version of FL ORASAT focused on device-to-satellite communication, providing a unique tool to study LoRa/LoRaW AN-based DtS-IoT systems. The present work advances FL ORASAT 2 into a full end-to-end simulation framework by integrating Medium Access Control (MAC) protocols with constellation-grade routing models, including constellation creation, dy- namic 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 re- silience under Doppler effects, congestion, and intermittent visibility, while expanding the satellite and device modules to support multiple MAC protocols beyond LoRaW AN. To the best of our knowledge, FL ORASAT 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 FL ORASAT 2 as a versatile platform for the de- sign and optimization of next-generation satellite IoT systems. K E Y W O R D S Satellite Communication, LEO satellite, L ORAWAN, L ORA, IoT, Simulation, OMN ET++ 1 INTRODUCTION The growing number of space projects 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 2. Additionally, it also impacts the IoT community, which is continually exploring diversification in its applications 3. Low-Earth Orbit (LEO) satellites, such as CubeSats, are at the heart of the emerging space age since their unique character- istics 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 N B-I OT and L ORA. 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 4. Abbreviations: IoT, Internet of Things; LEO, Low-Earth Orbit; DtS-IoT, Direct-to-Satellite IoT. International Journal of Satellite Communications ;:1–17 wileyonlinelibrary.com/journal/ © Copyright Holder Name 1 2 Choquenaira-Florez ET AL . This type of application is known as Direct-to-Satellite IoT (DtS-IoT), which, besides its benefits, addresses critical and challenging problems 5 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, FL ORASAT (Framework for LoRa-based Satellite IoT) was initially introduced in 6 as an open-source event-driven simulator. It replicates the behavior of LoRa/LoRaW AN-based IoT systems and their interactions with satellite networks. The authors demonstrated the efficiency and benefits of FL ORASAT for studying and analyzing the performance of L ORAWAN DtS-IoT networks. The FL ORASAT simulator leverages the well-known OMN ET++ framework with its INET extension for the Internet stack and a L ORAWAN protocol implementation adapted from the open-source simu- lator FL ORA 7. At this point in time, FL ORASAT 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 8 introduced FL ORASAT 2 to address the challenges of cross-linked DtS-IoT satellite constel- lations, 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 benchmark- ing 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 FL ORASAT 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, FL ORASAT 2 is the only open-source simulator that integrates access and routing layers for the system-level evaluation of DtS-IoT constellations. Specifically, FL ORASAT 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 LoRaW AN. This integration is validated through an additional benchmark scenario that evaluates the joint impact of routing and MAC on delivery performance, thereby transforming FL ORASAT 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 LoRaW AN, broadening the applicability of FL ORASAT 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 FL ORASAT’s unique characteristics is provided in Section 2. Section 3 introduces the novel developments and advancements in FL ORASAT 2, including its extended architecture supporting constellations, explaining the new modules. The novel routing sandbox in FL ORASAT 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. ‡ To aid the reader, all new content introduced in this archival-quality extension of the conference paper is highlighted in dark blue. FLoRaSat 2: Simulating Cross-Linked Direct-to-Satellite IoT LEO Constellations 3 T A B L E 1 Comparison of Tools Based on Functionalities Simulator Orbital Propagator Packet Simulation DtS-IoT Open Source Constellation- Grade STK 9 ✓ × × × ✓ Hypatia 10 ✓ ✓ × ✓ ✓ OpenSAND 12 ✓ × × ✓ ✓ GMAT 13 ✓ × × ✓ × Orekit 14 ✓ × × ✓ × SILLEO-SCNS 15 ✓ × × ✓ ✓ FL ORASAT 6 ✓ ✓ ✓ ✓ × FL ORASAT 2 (this paper) ✓ ✓ ✓ ✓ ✓ 2 FLORASA T 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, FL ORASAT (Framework for LoRa-based Satellite IoT) was initially introduced in 6 as an open-source, event-driven simulator that replicates the behavior of LoRa/LoRaW AN-based IoT systems and their interactions. It was designed to address the re- quirements 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, FL ORASAT is a unique tool. STK 9, a widely used licensed software, offers robust analytical capabilities but precise complementary development to implement routing functionality. Another appealing alternative, Hypatia 10, is an open-source tool software based on NS-3 11, that provides a framework for easy and quick implementation of constellations comparable to FL ORASAT. 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 12. 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)13, an open-source platform independently developed by NASA in collaboration with the industry. GMAT only supports design and trajectory satellite optimization. Sim- ilarly, Orekit, written in Java, is an accurate and efficient tool for the design of space flight dynamics applications 14. 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 FL ORASAT. Finally, SILLEO-SCNS appears as a noteworthy open-source option capable of simulating and analyzing satellite constellations, includ- ing 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 V ersion FL ORASAT leverages the well-established OMN ET++ framework with the INET extension, which provides internet stack services and incorporates the open-source FL ORA implementation. The authors also customized the physical layer (L ORA) and the link layer (L ORAWAN) 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 16 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 17. FL ORASAT follows the LORAWAN standards by implementing Class B while retaining legacy Class A support for compatibility. • Channel Model: Inspired by 18, FL ORASAT employs a simple channel model for attenuation, interference, and the capture effect at the receiver. These factors significantly affect uplink and downlink performance. 4 Choquenaira-Florez ET AL . The early version of FLoRaSat 6 was focused on the L ORA /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 FL ORASAT 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 de- signing 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 FL ORASAT’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 §. 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 OneWeb19,20 or Starlink systems. The satellite positions generated by this module were validated against reference values extracted from STK 9, 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 21. T A B L E 2 Module Parameters and Metrics Constellation Creator Topology Control Statistics Parameters Parameters Metrics • Number of gateways • Index • Initial mean anomaly • RAAN • Altitude • Eccentricity • Orbit inclination • Plane Count • Interplane Spacing • Minimum Elevation • Data Rate (ISL, Ground) • Delay (ISL, Ground) • Update Interval • Walker Type • ISL Status • Interplane Spacing • Plane Count • Hopcount • Distance • Delivery Ratio • Packet Loss • Throughput • Drop heatmap • E2E Delay • Avg. queue size • Protocol Overhead • Failure comparison § GitLab repository: https://gitlab.inria.fr/jfraire/florasat/-/tree/FLoRaSat_v2 FLoRaSat 2: Simulating Cross-Linked Direct-to-Satellite IoT LEO Constellations 5 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 22; 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 temporar- ily or permanently disables inter-satellite links. The idea is to test routing algorithms for their adaptability to failures, which complements FL ORASAT’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 FL ORASAT-CLI (Command Line Interface), a functionality to analyze simulation results through metrics and visualizations efficiently. FL ORASAT 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 imple- mentation 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, FL ORASAT-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 FL ORASAT-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 OMN ET++ 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 FL ORASAT 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 L ORA and L ORAWAN operations within satellite and ground devices. Previously, to ensure seamless communication, these tasks included multiplexing and retransmitting L ORAWAN 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 FL ORASAT 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. 6 Choquenaira-Florez ET AL . FLoRaSat Satellite Packet Forwarder ISL Packet Forwarder LoRaWan GW Mobility App End-Point Packet Generator Ground Station Ground Visualizations Pre-Processing Statistics Creator Constellation ISL Control EventManager Control Topology Routing Directed Routing DDRA Routing Disco Routing App End-Point Mobility Device F I G U R E 1 The extended architecture of FL ORASAT. Orange modules were introduced in FL ORASAT 2. RoutingBase handlePacket(Packet pkt) : void handleTopologyChange() : void preparePacket(Packet pkt) : void wrapUpPacket(Packet pkt) : void handlePacketDrop(Packet pkt, Reason reason) : handleQueueSize(int size, int maxSize) : void DirectedRouting handlePacket(Packet pkt) : { ... } handleTopologyChange() : { ... } preparePacket(Packet pkt) : { ... } wrapUpPacket(Packet pkt) : { ... } handlePacketDrop(Packet pkt, Reason reason) : { ... } handleQueueSize(int size, int maxSize) : { ... } DDRARouting handlePacket(Packet pkt) : { ... } handleTopologyChange() : { ... } preparePacket(Packet pkt) : { ... } wrapUpPacket(Packet pkt) : { ... } handlePacketDrop(Packet pkt, Reason reason) : { ... } handleQueueSize(int size, int maxSize) : { ... } DiscoRouting handlePacket(Packet pkt) : { ... } handleTopologyChange() : { ... } preparePacket(Packet pkt) : { ... } wrapUpPacket(Packet pkt) : { ... } handlePacketDrop(Packet pkt, Reason reason) : { ... } handleQueueSize(int size, int maxSize) : { ... } F I G U R E 2 Structure of the RoutingBase Abstract Class and implementations 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. FLoRaSat 2: Simulating Cross-Linked Direct-to-Satellite IoT LEO Constellations 7 • 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 D ISCO ROUTE . 4.1 Directed Routing DIRECTED routing is a simple algorithm that employs the Manhattan distance as the heuristic to select the next hop, as sug- gested 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. d1 = Ax – Bx  + Ay – By  d2 = 1 + Ay + Ax – Bx  + (w – 1) – By  d3 = w – Ay + Ax – Bx  + 0 – By  d = min(d1, d2, d3) (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. d1 = Ax – Bx  + Ay – By  d2 = 1 + Ay + Ax – Bx  + (w – 1) – By  d3 = w – Ay + Ax – Bx  + 0 – By  d4 = 1 + Ax + (v – 1) – Bx  + Ay – By  d5 = v – Ax + 0 – Bx  + Ay – By  d6 = v – Ax + w – Ay + 0 – Bx  + 0 – By  d7 = v – Ax + 1 + Ay + 0 – Bx  + (w – 1) – By  d8 = 1 + Ax + w – Ay + (v – 1) – Bx  + 0 – By  d9 = 1 + Ax + 1 + Ay + (v – 1) – Bx  + (w – 1) – By  d = min(d1, d2, d3, d4, d5, d6, d7, d8, d9) (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 period- ically 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 ≤ TMAX M × VMAX LMIN (3) 8 Choquenaira-Florez ET AL . where TMAX is the maximum tolerable delay normally default to 500ms, M is the average number of hops in the constellation, VMAX is the maximum link transmission data rate, and LMIN refers to the minimum packet length. 4.3 DiscoRoute This routing algorithm 26 is specially focused on mega-constellations comprising hundreds or thousands of satellites but only applies to Walker-Delta constellations. D ISCO ROUTE 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 DISCO ROUTE 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 27. 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 28. 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 sched- ule access-based approaches 28. 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 FL ORASAT 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 inte- gration 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 FLoRaSat 2: Simulating Cross-Linked Direct-to-Satellite IoT LEO Constellations 9 LoRaPhy Preamble MacFrame Routing Header LoRaApp Packet F I G U R E 3 Structure of the L ORAWAN packet after processing 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. 10 Choquenaira-Florez ET AL . F I G U R E 4 Configuration file Iridium Constellation F I G U R E 5 Configuration file for Starlink constellation 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. D ISCO ROUTE 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 FL ORASAT 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 FL ORASAT-CLI to analyze these metrics and generate corresponding graphs, demon- strating one major strength of FL ORASAT. Figure 6 presents some graphics generated using the FL ORASAT-CLI with the scenario simulation detailed. Next, we will analyze each of these graphics in detail. FLoRaSat 2: Simulating Cross-Linked Direct-to-Satellite IoT LEO Constellations 11 3 3.5 4 4.5 5 5.5 6 0.8 0.9 1 DDRA Disco Hops CDF 3.333.32 4k 5k 6k 7k 8k 9k 10k 11k 12k 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 DDRA Disco Distance[km] CDF 5273.18km5552.27km 350 400 450 500 550 600 650 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 DDRA Disco E2EDelay[ms] CDF 386.83ms379.77ms 0 20040060080010001200140016000 10 20 30 40 50 60 70 80 90 100 DDRA Disco Time(s) Packetloss [%] 1.925% 1.834% a) Hops c) End-to-End Delay b) Distance d) Packet-loss comparison F I G U R E 6 Comparative graphs created by the FL ORASAT-CLI for the first benchmark. Hop Count and Distance Although both algorithms exhibit a similar average number of hops, D ISCO ROUTE 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 FL ORASAT-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 D ISCO ROUTE algorithms. Both exhibit similar delays. However, the plot slightly suggests that, under regular conditions, D ISCO ROUTE achieves better perfor- mance 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. 12 Choquenaira-Florez ET AL . b) Disco a) DDRA F I G U R E 7 Analysis of routes preprocessed by FL ORASAT-CLI 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. D ISCO ROUTE 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. FLoRaSat 2: Simulating Cross-Linked Direct-to-Satellite IoT LEO Constellations 13 1000120014001600 a) Hops c) End-to-End Delay b) Distance d) Packet-loss comparison F I G U R E 8 Comparative graphs created by the FL ORASAT-CLI for the second benchmark. 6.2 Comparison of Routing Algorithms DDRA vs. D IRECTED The second scenario tests the ability of D IRECTED 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 FL ORASAT-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 FL ORASAT-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). 14 Choquenaira-Florez ET AL . F I G U R E 9 Configuration Iridium Constellation for MAC Evaluation Packet Loss Comparison Finally, the Figure shows a slightly better performance of DDRA. This can be explained by the fact that D IRECTED 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 uni- formly 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. FLoRaSat 2: Simulating Cross-Linked Direct-to-Satellite IoT LEO Constellations 15 2 4 6 8 10 12 Number of Repetition by Message 70 75 80 85 90 95 100Delivery Ratio of Messages at Ground a) Delivery Ratio of Messages at Ground by Repetitions Without ISL With ISL 2 4 6 8 10 12 Number of Repetition by Message 1000 1100 1200 1300 1400Messages at Ground b) Messages received at Ground by Repetitions Without ISL With ISL 2 4 6 8 10 12 Number of Repetition by Message 75 80 85 90 95 100Delivery Ratio of Messages at Sat c) Delivery Ratio of Messages at Sattelites by Repetitions Without ISL With ISL With ISL, received by the route path satellites 2 4 6 8 10 12 Number of Repetition by Message 86 88 90 92 94Extraction Rate d) Extraction Rate by Number of Repetitions Without ISL With ISL 2 4 6 8 10 12 Number of Repetition by Message 0 2000 4000 6000 8000 10000 12000 14000Collisions e) Collisions by Number of Repetitions Without ISL With ISL 2 4 6 8 10 12 Number of repetition 50 100 150 200 250 300 350 400 450Delay (seconds) f) Average Delay to Ground since Message Generation Mean Delay Mean Delay with ISL F I G U R E 10 Comparative graphs for both scenarios. 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. 16 Choquenaira-Florez ET AL . 6.4 FL ORASAT 2 Limitations Despite the potential of these new modules, they have some limitations. Their use requires proficiency in C++ and OMN ET++, 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 OMN ET++ 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 FL ORASAT 2, an advanced publicly available simu- lation 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 FL ORASAT-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 FL O- RASAT 2’s unique ability to validate routing algorithms and assess complex constellation designs effectively. Together, these advancements position FL ORASAT 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 FL ORASAT to adapt to new MAC scheme protocols. Although the integration of a new MAC protocol into FL ORASAT 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 FL ORASAT ’s robustness in practical deployments. This feature can significantly extend FL ORASAT 2s 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, FL ORASAT 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.

1. Leyva-Mayorga Iea. LEO small-satellite constellations for 5G and beyond-5G communications. Ieee Access. 2020;8. doi: 10.1109/AC- CESS.2020.3029620 2. Palattella MR, Accettura N. Enabling internet of everything everywhere: LPW AN with satellite backhaul. In: 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: Springer. 2019:241–258. https://doi.org/10.1098/rspa.1937.0036 6. Fraire JA, Madoery P , Ait Mesbah M, Iova O, V alois F. Simulating lora-based direct-to-satellite iot networks with florasat. In: IEEE. 2022; Belfast, United Kingdom:464–470 FLoRaSat 2: Simulating Cross-Linked Direct-to-Satellite IoT LEO Constellations 17 7. Slabicki M, Premsankar G, Di Francesco M. Adaptive configuration of LoRa networks for dense IoT deployments. In: IEEE. 2018; Taipei, Taiwan:1–9 8. Choquenaira-Florez A Y , Ohs R, Fraire JA, Rivano H. FLoRaSat 2: Simulating Cross-Linked Direct-to-Satellite IoT LEO Constellations. In: 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: ACM IMC. 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 (GMA T). 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: European 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: IEEE. 2017; Madrid, Spain:124–127 17. V ogelgesang K, Fraire JA, Hermanns H. Uplink transmission probability functions for LoRa-based direct-to-satellite IoT: A case study. In: 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: IEEE. 2015; San Diego, California:1–6 19. OneWeb F. OneWeb Amendment Phase 1. https://fcc.report/IBFS/SA T-MPL-20200526-00062/2379565.pdf; 2020. [Accessed 26-08-25]. 20. OneWeb F. OneWeb Amendment Phase 2. https://fcc.report/IBFS/SA T-MPL-20200526-00062/2379706.pdf; 2020. [Accessed 26-08-25]. 21. Chen Q, Guo J, Y ang 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: IEEE. 2014; Chengdu, China:357–361 25. Dijkstra EW. A note on two problems in connexion with graphs :287–290; 2022 26. Stock G, Fraire JA, Hermanns H. Distributed on-demand routing for leo mega-constellations: A starlink case study. In: 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, Y uen 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