# Routing in All-Optical LEO Constellations with High-Altitude Ground Stations

Benoit Coeugnet, Pablo G Madoery, Juan A Fraire, Jorge M Finochietto, Halim Yanikomeroglu

► To cite this version:

Benoit Coeugnet, Pablo G Madoery, Juan A Fraire, Jorge M Finochietto, Halim Yanikomeroglu. Routing in All-Optical LEO Constellations with High-Altitude Ground Stations. MECOM 2024 - IEEE Middle East Conference on Communications and Networking, Nov 2024, Abu Dhabi, France. pp.157-162, 10.1109/MECOM61498.2024.10880869. hal-05357384

HAL Id: hal-05357384

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

Submitted on 10 Nov 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
# Routing in All-Optical LEO Constellations
with High-Altitude Ground Stations

*Invited Paper*

Benoit Coeugnet*†, Pablo G. Madoery*‡, Juan A. Fraire†‡, Jorge M. Finochietto‡, Halim Yanikomeroglu*

* Non-Terrestrial Networks Lab, Department of Systems and Computer Engineering, Carleton University, Ottawa, Canada

† Inria, INSA Lyon, CITI, UR3720, 69621 Villeurbanne, France

‡ CONICET - Universidad Nacional de Cordoba, Cordoba, Argentina

***Abstract***—The recent proliferation of non-terrestrial networks (NTNs) utilizing low Earth orbit (LEO) satellites and high-altitude platform stations (HAPS) has garnered significant attention. Establishing an all-optical network in LEO constellations has been explored, leveraging HAPS used as high-altitude ground stations (HAGS) in conjunction with traditional ground stations (GS). This approach is appealing for Earth observation missions spanning a fully connected network between LEO satellites and a delay-tolerant stochastic partition between HAGS and GS. To address the emerging routing challenges arising from weather-related impairments, we first develop new routing solutions that mitigate these issues. Secondly, we compare the performance of our new routing solutions to the classic contact graph routing (CGR), demonstrating improved performance for NTN networks. Finally, we conclude by outlining future research directions.

***Index Terms***—High-Altitude Platform Stations, LEO Satellite Networks, LEO Mega-Constellations, Free-Space Optical Links.

## I. INTRODUCTION

Earth observation is a significant source of space-based data that must be transmitted to Earth for analysis. These observations can generate enormous amounts of data that must be transmitted from satellites to Earth. In this scenario, the primary transmission bottleneck lies in the space-to-Earth link.

LEO satellites orbit at altitudes above 300 km, which brings them close enough to form a dense constellation and serve as relays for more distant satellites. The HAGS is a variant of high-altitude platform stations (HAPS) [1], which utilize platforms at 20 km in the stratosphere to enhance communication coverage over large regions [2]. HAPS are often linked to free-flying configurations and have been extensively studied as part of a space-air-ground integrated network, surveyed in [3].

To enhance faster transmission, [4] introduced the concept of using free-space optical (FSO) links to achieve greater transfer speed between LEO satellites and Earth. To achieve seamless optical connectivity in the architecture, including optical inter-satellite links (OISLs) and ground-satellite optical links (GSLs), [5] proposed the concept of HAGS (High Altitude Ground Stations) to address FSO link disruptions in the presence of clouds. The HAGS serve as store-and-forward nodes to enhance connectivity and data rate retaining data from LEO satellites until suitable weather conditions enable their download to the ground. Even if this approach relies on the delay-tolerant network (DTN) paradigm [6], it introduces new

challenges in routing that may require awareness of climate conditions.

Building upon the findings of [5], this paper introduces the concept of multi-LEO satellites with OISLs and novel routing solutions that consider weather conditions. This study case is unique due to its full connectivity in the LEO constellation, enabling bundles (a data unit in the Bundle Protocol [7]) to flow seamlessly between satellites. This full connectivity enables new routing possibilities and reduces constraints on the network. However, since the entire network is not a DTN, conventional routing solutions are ill-equipped to handle these distinctive challenges. This paper aims to properly introduce new ways of thinking about routing in these networks and their implementations, and demonstrate the improvements over classic CGR implementations.

The paper is structured as follows: Section II provides an overview of existing routing solutions and the HAGS architecture; Section III presents the novel routing solutions developed to mitigate the weather issue; and Section IV demonstrates the performance improvement achieved through our new routing solutions. Future avenues in the domain are opened in Section V, and finally, Section VI summarizes our findings.

## II. BACKGROUND

***Network Nodes:*** LEO and HAPS are recognized as key network elements for emerging NTN networks in 5G/B5G/6G networks [8]. As mentioned by [9], such systems have already been deployed, enabling collaborative LEO-HAPS for tasks offloading [10].

***Network Links:*** Implementing optical terminals in HAPS to link with LEO satellites was first introduced in [4], where the authors proposed the stratospheric optical relay stations. The OISLs and their associated difficulties are described in detail in reference [11]. They represent a significant technological challenge with the potential to enable ultra-fast and highly reliable connectivity. Furthermore, the optical links can play a significant role in security, as demonstrated in [12].

***Network Routing:*** First introduced in [13], CGR relies on a contact plan and Dijkstra's algorithm to find the possible route for a bundle. CGR is designed to address the challenges of communication in the DTN. It uses a contact graph, which is a dynamic representation of the network whose parameters are
<figure><img src="image_2.png" /><figcaption>Figure 1: Overview of the architecture.</figcaption></figure>

updated as a function of the data history of the nodes [14]. It includes deterministic connectivity patterns, with a duration of each contact opportunity. Each available connection between nodes is referred to as a contact. To discover new routes, we will use the *first-depleted* approach as explained in [14], based on suppressing the volume bottleneck in the previously computed route. CGR employs a routing strategy that selects the available route with the shortest arrival time. A route is considered available if sufficient time remains during the contact period to transmit the bundle. Notably, [15] and [16] have provided studies when the contact plan is uncertain, which is meant to represent a real case scenario.

**HAGS:** Most notably, recent research has demonstrated the benefits of a hybrid architecture combining one LEO satellite with a HAGS-GS pair [5].

### III. SYSTEM MODEL

Our study focuses on a different aspect of the network, where the contact plan is certain, yet uncertainty exists between HAGS and GS due to weather conditions. Unlike previous works, we do not consider rerouting to the constellation a solution, as the bottleneck lies between these nodes. Instead, our solutions adopt a “prevention is better than cure” approach, prioritizing sending bundles to the best available HAGS rather than rerouting in case of errors. This paper aims to build upon this foundation by achieving two objectives: first, to evaluate the performance of the HAGS-based architecture in scenarios involving larger numbers of satellites and ISLs; second, to further enhance these results by incorporating weather considerations into our routing scheme.

#### A. System Architecture

We employed the architecture proposed in [5] and shown in Figure 1, which involves a LEO satellite constellation

transmitting data to a destination node on Earth. In this HAGS-based model, each LEO satellite is equipped with a FSO terminal, enabling direct data transmission from the satellite to the HAGS and other LEO satellites. This facilitates seamless data sharing between satellites at all times.

We assume that predicted weather information is available when required by the routing solution. This assumption is reasonable, as Earth-based weather data can be easily transmitted to the LEO constellation and then shared with all network satellites. For instance, previous research [17] has developed a model to predict cloud coverage from open weather data. Since only cloud coverage data is necessary, the amount of data is not overwhelming. While more precise weather data could further enhance routing performance, a reasonable level of precision is sufficient, allowing for infrequent updates.

**Cloud Coverage Model:** We employ an exponential distribution to model the weather, which captures cloud coverage's random and memory-less nature. This distribution is characterized by the mean time to failure (TTF) and the mean time to recovery (TTR), which respectively represent the time to cloud coverage (TCC) and the time to clear sky (TCS).

#### B. Routing Schemes

Two novel routing solutions were designed to minimize the impact of weather conditions. For comparative purposes, we also employed a basic CGR implementation to serve as a benchmark for evaluating our developed solutions. Notably, our routing scheme operates under a fully deterministic contact plan, with the only source of uncertainty being the unpredictable nature of weather conditions.

**Greedy Routing:** In this paper, we first use a basic version of CGR (see Algorithm 1), which we called greedy because it chooses the best route in terms of arrival time for each
bundle, regardless of the weather. Therefore, it tries to get the maximum out of each contact.

**Algorithm 1: Greedy routing implementation**

**Data:** contactPlan
1 **forall** bundles **do**
2 &nbsp;&nbsp;&nbsp;&nbsp;routes ← Dijkstra's algorithm on contactPlan
3 &nbsp;&nbsp;&nbsp;&nbsp;**forall** route ∈ routes **do**
4 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;**if** route.arrivalTime < minArrivalTime **then**
5 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;minArrivalTime ← route.arrivalTime
6 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;bestRoute ← route
7 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;**end**
8 &nbsp;&nbsp;&nbsp;&nbsp;**end**
9 **end**

**Equal Routing:** Our initial contribution was an equal distribution routing scheme. This approach ensures that each HAGS receives an equal share of bundles, as we observed that the greedy routing solution often directs many bundles to a single HAGS. While this routing solution does not explicitly consider weather conditions, it assumes uniform cloud coverage across each HAGS-GS pair. Notably, the implementation is straightforward, requiring only minor modifications compared to the greedy solution. The critical change involves selecting the second-to-last hop based on a simple rule: the chosen HAGS is determined by calculating the bundle's number modulo, which is the total number of HAGS. We opted for a round-robin distribution, routing one bundle to each destination individually rather than batch-processing them. This approach allowed us to avoid requiring the total number of bundles up front, and we observed slightly improved performance.

**Algorithm 2: Equal routing implementation**

**Data:** contactPlan
1 **forall** bundles **do**
2 &nbsp;&nbsp;&nbsp;&nbsp;routes ← Dijkstra's algorithm on contactPlan
3 &nbsp;&nbsp;&nbsp;&nbsp;**forall** route ∈ routes **do**
4 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;**if** route.node[-2] = bundle.number %
5 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;层数OfHags **then**
6 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;**if** route.arrivalTime < minArrivalTime **then**
7 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;minArrivalTime ← route.arrivalTime
8 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;bestRoute ← route
9 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;**end**
10 &nbsp;&nbsp;&nbsp;&nbsp;**end**
11 **end**

The Algorithm 2 shows the implementation of the equal routing. The line 4 checks if the second to last node of the current route equals the chosen HAGS. Therefore, the first bundle will reach the first HAGS, the second one will reach the second HAGS, the sixth one will be routed to the first HAGS, and so on. The reason for checking the second-to-last

node is that the last node is the destination, and the previous node is the GS associated with the HAGS.

**Weighted Routing:** To properly take into account the weather, we designed a solution that computes the proportion of Clear Sky (CS) in a HAGS (h) by calculating

$$CS_h = TCC_h / (TCC_h + TCS_h)$$

and then the percentage of bundles that need to be sent to a HAGS h by doing

$$CS_{h\%} = \left( CS_h / \sum_i CS_i \right) \times 100.$$

To be more precise in our routing, we created a proportionally distributed vector of 100 components, where each component is the destination HAGS. This means that the vector has the right proportion of HAGS according to the percentage computed and is proportionally distributed across the vector. Then we take the number of the bundle we need to route modulo 100, and the vector gives the HAGS on which the bundle needs to arrive. The pseudo-code is available in Algorithm 3.

**Routing Parameters:** Our simulations employ a local contact plan that accurately represents real-world behavior. We also utilize a source routing approach, where the source node determines a path that is subsequently followed by other nodes without further computation. This approach effectively avoids loops in the LEO network, which are caused by the non-delay-tolerant nature of this part of the network. In DTN, traditional per-contact routing approaches store bundles in queues for specific links. However, this method neglects the delays introduced by permanent links due to non-instantaneous sending. To avoid these drawbacks, we adopted per-node routing, allowing bundles to consistently reach their destinations in LEO satellites. Although this may seem a compromise, it has minimal practical impact, as contacts will eventually reappear due to the network's inherent nature. Our routing scheme optimizes transmission to targeted HAGS nodes while enabling seamless scalability, providing an added benefit.

## IV. EVALUATION AND ANALYSIS

The analysis was conducted by extending DtnSim, a discrete event-driven simulator based on the Omnet++ framework. Accessible via a public repository<fnref n="1" />, it was introduced in [18]. Each LEO, HAGS and GS is modeled by an Omnet module, where data generation, routing, and forwarding are managed within sub-modules. Another module takes care of the cloud coverage, as discussed in Section III.

**Invariants:** We employed the Systems Tool Kit (STK) to simulate a week-long interaction between the Iridium constellation and the KSAT's GS network, similar to [5]. We set the number of LEO satellites to five, with continuous ISL links forming a line topology. Similarly, we considered five HAGS-GS pairs. These values were chosen to limit computing time

<footnote n="1">¹DtnSim is publicly available at: https://gitlab.inria.fr/jfraire/dtnsim.git. The results in this paper are available under the support-hags branch.</footnote>
### Algorithm 3: Weighted routing implementation

**Data:** *contactPlan*

1 **forall** HAGS **do**

2 | cloudCover<sub>h</sub> ← (tcc<sub>h</sub>/(tcs<sub>h</sub> + tcc<sub>h</sub>) × 100)

3 **end**

4 **forall** HAGS **do**

5 | distribution<sub>h</sub> ←
6 | cloudCover<sub>h</sub>/sum(cloudCover) × 100)

6 **end**

7 **forall** i < distribution.size() **do**

8 | **forall** j < distribution[i] **do**
9 | | **while** hagsMapping[index] ≠ 0 **do**
10 | | | index ++
11 | | **end**
12 | | hagsMapping[index] = hagsNumber
13 | | index ← index + (100 / distribution[i])
14 | **end**
15 | hagsNumber ++
16 **end**

16 **end**

17 **forall** bundles **do**

18 | routes ← Dijkstra's algorithm on *contactPlan*
19 | **forall** route ∈ routes **do**
20 | | hagsModulo ← bundle.number % 100
21 | | **if** route.node[-2] = hagsMapping[hagsModulo]
22 | | | then
23 | | | | **if** route.arrivalTime < minArrivalTime **then**
24 | | | | minArrivalTime ← route.arrivalTime
25 | | | | bestRoute ← route
26 | | | **end**
27 | **end**
28 **end**

and yield valuable results. One LEO satellite has 1000 files, each 100 GB, that must be delivered to the destination. Each link has a data rate of 8 Gbps, requiring 100 seconds of line-of-sight to transmit a file entirely. The value of 1000 bundles was

arbitrarily chosen to facilitate comparison between different routing solutions and serve a purely experimental and visual purpose. To ensure statistical precision, we performed 100 repetitions of each simulation for each satellite as a source, resulting in a total of 500 simulations per plotted value. Additionally, we computed the corresponding 95% confidence intervals.

**Variables:** The value of TCS was fixed at 25 hours. Additionally, the value of TCC differs for each HAGS, allowing for variation in cloud coverage. One HAGS has an average TCC value, while two others represent the extremes, which are used to compute the ratio between the more and less cloudy areas. The remaining two HAGS are positioned at the average of the average and the extreme values. Furthermore, curves for an average TCC of 1.05 hours are included on the plots, demonstrating that the results can be extrapolated to various averages of TCC. This also demonstrates that the ratio of cloud cover is the essential factor until the bottleneck is shifted from the weather to the satellite-to-earth segment of the network.

**Metrics:** The performance is evaluated using three key metrics: a) Delivery Ratio (**DR**) measuring the percentage of files successfully delivered, b) Delivery Delay (**DD**) calculated as the difference between file generation time and arrival time and c) Buffer Occupation (**BO**) characterized by mean and maximum values, computed as an average of each HAGS.

a) *Delivery Ratio:* Figure 2 illustrates the evolution of delivery ratios for varying ratios of cloud coverage. In the presented examples, the ratio of cloud cover increases by a factor of up to 40 in the most cloudy area compared to the less cloudy counterpart.

We observe that both equal and weighted routing solutions lie above the greedy routing. This is because bundles keep getting stored in HAGS after the simulation ends, as they are sent opportunistically, implying that some HAGS received significantly more bundles than their clear sky percentage. For small values of the ratio of cloud cover, the equal and weighted solutions are nearly indistinguishable from one another, which is readily understandable since cloud coverage is almost identical, resulting in similar routing decisions for both solutions.

<figure><img src="image_3.png" /><figcaption>Figure 2: Delivery ratio for each routing solution.</figcaption></figure>

<figure><img src="image_4.png" /><figcaption>Figure 3: Delivery delay for each routing solution.</figcaption></figure>
For larger values of the ratio of cloud cover, the equal solution continues to distribute bundles evenly among every HAGS, leading to a performance loss due to the same reason as greedy routing.

It's worth noting that the weighted distribution's performance remains consistent, demonstrating that the solution worked effectively by utilizing each HAGS at its full potential. The 100% delivery ratio was not achieved because the average uptime of all GS was insufficient to allow 1000 bundles to reach their destinations.

b) *Delivery Delay*: The delay comparison requires caution when examining Figure 3, as the delay value is only recorded when the bundle reaches the destination node. To be able to compare the scenarios, we have artificially added all the remaining bundles to the simulation with a delay of 168h (equal to 1 week, the total duration of the simulation). So if 950 bundles were received at the destination, the remaining 50 will have a delay of 168h. This approach is not entirely accurate, as the actual delay to reach the final node would likely be greater. However, it provides a reasonable basis for comparing the different routing solutions. As usual, the greedy routing solution takes much longer on average to deliver the bundles. For a small ratio, equal and weighted are close, and for a

larger ratio, weighted becomes more and more appealing, as intended, by keeping the delay constant as the ratio increases. This shows us that the weighted routing solution has a better delivery ratio with also less delay compared to the other schemes.

c) *Buffer Occupation*: Figure 4 displays the buffer occupation metrics for HAGS, indicating that the gains in delivery ratio also come with better buffer management. In Figure 4a, the weighted solution demonstrates a reduction in the average time spent in HAGS buffers, as bundles are distributed in proportion to the availability of clear sky conditions. This implies that bundles take a longer time to reach the optimal HAGS-HS pair from the LEO constellation, resulting in increased transmission delays between LEO satellites and HAGS. As all HAGS spend approximately the same amount of time on average transmitting to their GS, regardless of cloud coverage differences, the decrease in average buffer occupancy can be attributed to the delay in transmitting bundles from LEO satellites to HAGS, which has increased, and the transmission from HAGS to GS, which has remained constant.

Similarly, Figure 4b reveals a decreasing trend in maximum buffer occupancy as HAGS can transmit more bundles while waiting for LEO satellites to transmit them. In contrast, other

<figure><img src="image_5.png" /><figcaption>(a) Average time of a file in all HAGS buffers for each routing solution.</figcaption></figure>

<figure><img src="image_6.png" /><figcaption>(b) Max buffer occupancy for each routing solution.

Figure 4: Buffer metrics for each routing solution.</figcaption></figure>

<figure><img src="image_7.png" /><figcaption>(a) Delivery ratio for each routing solution.</figcaption></figure>

<figure><img src="image_8.png" /><figcaption>(b) Max buffer occupancy for each routing solution.

Figure 5: Results for two sources for the bundles.</figcaption></figure>
routing solutions experience increasing average buffer occu-
pation time and maximum buffer occupancy due to bundles
becoming stuck in HAGS buffers and unaware of cloud cover-
age. Notably, the greedy routing solution yields a significantly
worse result than the others.

*Two sources:* To further validate our routing solutions, we conducted experiments where two LEO satellites sent 500 bundles each. The results for delivery ratio and maximum buffer occupancy are presented in Figure 5. Each simulation is repeated 500 times to ensure statistical accuracy. This scenario illustrates that multiple sources do not present a challenge for our routing methodologies, as evidenced by the results: the weighted distribution still yields better delivery ratios (Figure 5a) and lower maximum buffer occupancy (Figure 5b). Notably, greedy routing consistently underperforms other solutions in all scenarios. These results are a consequence of the per-node routing decision.

V. FUTURE WORKS

This paper addresses the issue of *vertical congestion*, where transmission from space to Earth is the limiting factor. However, it does not account for *horizontal congestion* that can happen in the LEO constellation. For instance, when two satellites send their bundles to a single LEO without considering that this LEO will require twice as much time to route these bundles. Future research directions may consider this issue by exploring more complex LEO satellite constellations with multiple ISLs between satellites, congestion in different network parts, and weather variations within individual HAGS-GS pairs. Leveraging machine-learning algorithms could represent a significant next step to address these challenges.

VI. CONCLUSION

We evaluated two new routing solutions alongside greedy routing for a full-optical HAGS-based satellite network. Our approach demonstrated that even without considering cloud coverage, it can significantly improve the delivery ratio and buffer occupancy by evenly distributing bundles across each HAGS. By incorporating weather information into our decisions, the results become even more compelling and consistent across various cloud coverage scenarios, indicating successful mitigation of weather-related issues. Our architecture's robustness was further demonstrated by its performance under concurrent traffic conditions, which had no significant impact on the effectiveness of our routing solutions.

ACKNOWLEDGMENTS

This work has been supported in part by the National
Research Council Canada's (NRC) High Throughput Secure
Networks program within the Optical Satellite Communica-
tions Consortium Canada (OSC) framework, Mitacs, the EU's
H2020 R&D program under the Marie Skłodowska-Curie grant
agreement No 101008233 (MISSION project) and the French
National Research Agency (ANR) projects ANR-22-CE25-
0014-01.

REFERENCES

[1] M. S. Alam, G. Karabulut Kurt, H. Yanikomeroglu, P. Zhu, and N. D. Dao, "High altitude platform station based super macro base station constellations," *IEEE Communications Magazine*, vol. 59, no. 1, pp. 103–109, 2021.

[2] G. Karabulut Kurt, M. G. Khoshkholgh, S. Alfattani, A. Ibrahim, T. S. J. Darwish, M. S. Alam, H. Yanikomeroglu, and A. Yongacoglu, “A vision and framework for the high altitude platform station (HAPS) networks of the future,” *IEEE Communications Surveys & Tutorials*, vol. 23, no. 2, pp. 729–779, 2021.

[3] J. Liu, Y. Shi, Z. M. Fadlullah, and N. Kato, "Space-air-ground integrated network: A survey," *IEEE Communications Surveys & Tutorials*, vol. 20, no. 4, pp. 2714–2741, 2018.

[4] D. Giggenbach, J. Horwath, and B. Epple, "Optical satellite downlinks to optical ground stations and high-altitude platforms," *16th IST Mobile and Wireless Communications Summit*, pp. 1–4, 2007.

[5] P. G. Madoery, J. A. Fraire, J. M. Finochietto, H. Yanikomeroglu, and G. K. Kurt, “A novel non-terrestrial networks architecture: All optical LEO constellations with high-altitude ground stations,” *IEEE International Conference on Communications Workshops (ICC Workshops)*, 2024. [Online]. Available: http://arxiv.org/abs/2403.15659

[6] V. Cerf, S. Burleigh, A. Hooke, L. Torgerson, R. Durst, K. Scott, K. Fall, and H. Weiss, “Delay-tolerant networking architecture,” Internet Requests for Comments, RFC Editor, RFC 4838, April 2007.

[7] K. Scott and S. C. Burleigh, “Bundle protocol specification,” Internet Requests for Comments, RFC Editor, RFC 5050, November 2007.

[8] S. Kota and G. Giambene, “6G integrated non-terrestrial networks: Emerging technologies and challenges,” *IEEE International Conference on Communications Workshops (ICC Workshops)*, pp. 1–6, 2021.

[9] M. Agnew, L. Renouard, and A. Hegyi, “EDRS-SpaceDataHighway: Near-real-time data relay services for LEO satellites and HAPS,” *AIAA Int. Communications Satellite System Conference (ICSSC)*, 2012.

[10] L. Zhang, H. Zhang, C. Guo, H. Xu, L. Song, and Z. Han, “Satellite-aerial integrated computing in disasters: User association and offloading decision,” *IEEE International Conference on Communications (ICC)*, pp. 554–559, 2020.

[11] C. Carrizo, M. Knapek, J. Horwath, D. D. Gonzalez, and P. Cornwell, “Optical inter-satellite link terminals for next generation satellite constellations,” *Free-Space Laser Communications XXXII*, vol. 11272, p. 1127203, 2020.

[12] O. B. Yahia, E. Erdogan, and G. Karabulut Kurt, “On the use of HAPS to increase secrecy performance in satellite networks,” *IEEE International Conference on Communications Workshops (ICC Workshops)*, pp. 1–6, 2021.

[13] S. Burleigh, “Dynamic routing for delay-tolerant networking in space flight operations,” 2008. [Online]. Available: https://ntrs.nasa.gov/citations/20150014822

[14] J. A. Fraire, O. De Jonckère, and S. C. Burleigh, “Routing in the space internet: A contact graph routing tutorial,” *Journal of Network and Computer Applications*, vol. 174, p. 102884, 2021.

[15] P. G. Madoery, F. D. Raverta, J. A. Fraire, and J. M. Finochietto, “Routing in space delay tolerant networks under uncertain contact plans,” *IEEE International Conference on Communications (ICC)*, pp. 1–6, 2018.

[16] P. R. D'argenio, J. A. Fraire, A. Hartmanns, and F. Raverta, "Comparing statistical and analytical routing approaches for delay-tolerant networks," *Quantitative Evaluation of Systems (QEST)*, vol. 13479, pp. 337–355, 2022.

[17] M. Polnik, A. Arulselvan, and A. Riccardi, “Scheduling space-to-ground optical communication under cloud cover uncertainty,” *IEEE Transactions on Aerospace and Electronic Systems*, vol. 57, no. 5, pp. 2838–2849, 2021.

[18] J. A. Fraire, P. G. Madoery, F. Raverta, J. M. Finochietto, and R. Velazco, “Dtnsim: Bridging the gap between simulation and implementation of space-terrestrial DTNs,” *6th International Conference on Space Mission Challenges for Information Technology (SMC-IT)*, pp. 120–123, 2017.