1. Introduction
Terrestrial, maritime, and aerospace transportation solutions are increasingly relying on automated tasks and on energysaving enhancements, such as route optimization, edge and cloud processing via machine learning algorithms, as well as the convergence of communication, positioning, and sensing tasks at the receiver side or in the edge/cloud. The networks needed to support the wireless tasks in future transportation solutions are no longer limited to terrestrial networks, but they are being expanded with satellitecommunication networks, such as those based on LEO satellites. Such expansion is needed in order to increase the coverage areas and the enduser ubiquitous access to wireless services and to provide equal accessibility worldwide. LEO orbits have altitudes ranging between about 200km to 2000km above the Earth’s surface (below the VanAllen radiation belts), which makes LEO satellites cheaper to build and launch in comparison with satellites launched to MEO and GEO orbits. The lower costs of building and launching LEO satellites (compared to MEO and GEO ones) have also enabled better commercial viability of autonomoustransportation services. As a result, there is a significant effort worldwide to build new LEObased systems for a variety of broadband and narrowband communications (e.g., Iridium, Oneweb, Starlink, Kuiper), Internet of Things (IoT) solutions (e.g., Hiber, Astrocast, Athena, Myriota) Earth Observation (e.g., Iceye, RapidEye, Capella Space), autonomous transportation (e.g., Pulsar, GeeSpace), and, possibly, new Position, Navigation, and Timing (PNT) systems. Integrative solutions of edge/cloud solutions with LEO have already been proposed, e.g., in [
1].
Many LEO communication megaconstellations are already deployed in the sky, such as SpaceX Starlink, OneWeb, Amazon Kuiper, accompanied by smallersized more specialized constellations, for example, for IoT applications, such as Myriota, Hiber, Inmarsat, and others. In addition, the emerging concept of Low Earth Orbitbased Positioning, Navigation, and Timing (LEOPNT) [
2,
3,
4,
5] is receiving more attention in the research world by focusing on alternative satellitebased navigation methods via LEO satellites.
Based on payload applications, LEO constellations can be broadly distributed into three categories: (i) remote sensing (which includes Earth Observation); (ii) wideband and narrowband communications; and (iii) navigation—with the latter having extensive use in transportation and logistics. In terms of orbital altitudes, LEO orbits present practical advantages over MEObased solutions in terms of lowerlatency communications, shorter positioning time, possible higher positioning accuracy, higher image resolution and lower launching, building, and maintenance costs than MEO and GEO satellites [
6].
A novel challenge brought in by the combination of intelligent transportation solutions with LEObased wireless links is the highspeed relative motion between the LEO satellites and the vehicle of interest, which can be in the order of thousands of meters per second. The design of future LEO systems should be able to take into account not only the target application scenario (such as intelligent transportation via highspeed trains or Unmanned Autonomous Vehicle (UAV)) but also the multidimensional services to be offered by future LEO systems in terms of communication, positioning, and sensing targets. Optimization methods to ensure such codesign are tremendously important and have not yet been addressed in the context of designing LEOsystem parameters to the best of the Authors’ knowledge. Two LEO systems are currently being built with the specific target of future mobility and unmanned vehicles, namely GeeSpace from the Geely Technology Group in China and Pulsar from Xona Space Systems in the United States. Currently, there is very little public information about the design parameters of these two systems. We will include a discussion about the known design parameters of these systems later in our paper.
The aim of this paper is to offer a comprehensive survey of optimization methods that are showing promising results and can be used in the context of LEOsystem design and also to provide examples and design recommendations for chosen scenarios, covering both the LEO space components (i.e., constellation optimization) and the Earth and vicinitytoEarth components (i.e., ground segment and receiver optimization for terrestrial and aerial vehicles). The chosen application area is the area of the intelligent transportation systems, as this is a broadencompassing area covering multimode receivers (terrestrial, maritime, airborne), allspeed scenarios (from stationary receivers to ultra highspeed receivers), and challenging constraints in terms of communication, positioning, and sensing target metrics. To sum up, this paper’s contributions are:
An overview of LEO system design considerations for various applications, including highspeed intelligent transportation;
A comprehensive survey of optimization methods for LEO system design, targeting challenging application scenarios, such as future autonomous transportation;
The target optimization metrics and typical optimization problems involved in the threesegment architecture of any LEO system presented in a compact form;
Addressing in detail the space segment and constellation optimization by taking into account aspects not widely addressed so far in the current literature, such as launch and maintenance costs and payloads, constellation management and scaling, and topology models;
Summarizing, in a concise form, the optimization tradeoffs related to space, ground, and user segments in LEO design, targeting the performance metrics specific to allspeed (and in particular to highspeed) scenarios of autonomous vehicles;
Design recommendations for future LEO systems for navigation, sensing, and communication purposes.
The remainder of this paper is structured as follows:
Section 2 covers an overview of the related works from the literature that either have a similar purpose to our paper or showcase the general status of the LEO networks.
Section 3 introduces the general architecture of LEO systems and the different segments where optimization can be utilized.
Section 4 shows the mathematical formulation of generic optimization problems and classifies the optimization methods.
Section 5 introduces highspeed scenarios that arise within the LEO networks and explains the requirements of such systems.
Section 6 details the optimization problems of interest within the space segment and provides examples of optimization objectives, criteria, parameters, and methods.
Section 7 and
Section 8 repeat this process for ground and user segments. A few illustrative simulationbased examples are also included here. Last but not least, we provide our recommendations for selecting optimization tools for LEO networks in
Section 9 before finalizing the paper in
Section 10.
2. Related Works
The work related to LEO system design and optimization for autonomous transportation applications is typically focused on only one of these two domains: a LEO focus only or a focus on the intelligent/autonomous transportation side only. Moreover, the papers with LEO tend to only focus on one LEO segment at a time, among the three architectural segments (space, ground, and user), which are described in more detail in
Section 3.
Few papers are also addressing the LEO and autonomous transportation aspects. For example, the authors in [
7] focused on LEO networks for communication between autonomous vehicles, with a testbed example based on a UAV. No optimization aspects were addressed and the speed of the UAV used in the testing was not mentioned. The two LEO commercial systems targeting the automotive industry, namely Pulsar of Xona Space [
8] and GeeSpace of Geely Technology Group [
9], have very little publicdomain information regarding the design parameters or the adopted optimization steps. It is known that both Pulsar and GeeSpace systems aim at offering centimeterlevel positioning to end users and acting as enhancers of Global Navigation Satellite Systems (GNSS)based positioning technology, but the exact design parameters and mechanisms for achieving these targets are not yet available in the open literature.
The authors in [
10] focused on groundsegment optimization of large LEO constellations. The optimization metric was the overall system capacity and the optimization output was the number of ground stations. MonteCarlo (MC) optimization was employed.
Similarly in [
11], the authors presented their review of the literature surrounding marine systems and unmanned vehicles, with numerous reallife and academic examples of stateofart systems, which included highspeed scenarios that utilized LEO satellite systems, such as Iridium. Particularly, the work in [
11] considered LEO networks in terms of remotecontrol applications. However, the focus mostly stayed on the transportation domain; the satellite constellations themselves were only briefly mentioned and optimization aspects were not discussed for any scenario.
The work in [
12] addressed the problem of navigation services via MEO and LEO satellites for autonomous vehicle applications, which have stringent positioning requirements of decimeterlevel accuracy. Several possible LEO advantages in terms of complementary positioning methods to MEO GNSS were listed, such as stronger received signals, better resilience to interference, and fast LEO satellite speeds, enabling carrier phase differential precise positioning. No optimization method was discussed in [
12], but several optimization metrics were presented, such as CarriertoNoise Ratio (
$C/{N}_{0}$), jamming mitigation ability, and materialpenetration ability (e.g., LEO signal penetration through brick or concrete walls).
In [
13], a Genetic Algorithm (GA)based optimization, with Geometric Dilution of Precision (GDOP) and the number of satellites as optimization metrics, was employed for spacesegment optimization of a LEObased navigation system relying on a Walker constellation. It was found that good LEO coverage for navigation purposes can be reached with constellations between 180 and 264 and satellites placed at orbital altitudes between 900 and 1500 km.
The work in [
14] explored possible Dense Small Satellite Network (DSSN) applications on LEO networks, focusing mostly on the DSSN in terms of its architecture, requirements, and performance. The work did a good job in determining parameters that needed to be optimized for DSSN networks and determined the boundaries the LEO networks were subject to, but it did not address the actual process of optimization. However, some optimization methods for resource management were mentioned but not presented in detail.
In [
15], the authors proposed a SoftwareDefined Networking (SDN)enabled LEO constellation satellite network and formulated an optimization problem for SDN controller placement and assignment. They also developed mathematical models and provided SDN networkrelated cost metrics, such as migration and reconfiguration costs. While the study covered SDN network optimization in great detail, it limited its scope by focusing the analysis on the Iridium constellation, effectively excluding optimization aspects regarding the constellation itself.
The work conducted in [
16] analyzed the handover performance in a Low Earth Orbitbased NonTerrestrial Network (LEONTN) via systemlevel simulations, with a focus on the groundsegment optimization. The work was separated into two phases. First, it conducted a performance analysis of a conventional FifthGeneration of Cellular Networks (5G) new radio handover algorithm in LEONTN scenarios in order to find optimal parameters with respect to chosen key performance indicators. Secondly, there was a comparison in several terrestrial scenarios based on urban macroscenarios with highspeed trains.The results in [
16] showed that the mobility results were dominated by handovers happening too late, which were causing failure cases. However, due to the assumptions made within the simulations, the study in [
16] focused solely on the ground segment, and it did not take into account independent or joint optimizations aspects of the space and user segments.
The authors in [
17] considered a Speech Emotion Recognition (SER) application for autonomous vehicles, for which a 5Genabled SpaceAirGround Integrated Network (SAGIN) was designed. As such, the work explored ground, space, and user segments for the application of interest, but it only provided the design and architecture of the network, without explaining the related optimization processes. However, the usersegment optimization related to SER was covered in great detail, as they explained the Artificial Intelligence (AI) model used for acoustic data modeling.
The authors in [
18] discussed LEO communication architectures to support highspeed UAV, and, in particular, the resource allocation in uplink connectivity. A convex optimization problem in terms of throughputs and energyefficiency metrics was formulated in [
18] and solved via Matlab CVX software (a software for disciplined convex programming).
Table 1 summarizes the related work and what we bring with respect to existing studies and surveys.
3. The ThreeSegment Optimization Architecture in LEO
A typical LEO satellite network has a threesegment architecture:
Ground Segment includes the GroundStation (GS) infrastructure, which serves as a control unit for the satellite constellation and manages internal parameters;
Space Segment includes the satellite constellation (as well as the propagating signals from satellite to ground);
User Segment refers to any and all applications that the system serves (i.e., cellular networks, PNT applications, transportation, UAV etc.) as well as to any LEO receiver.
Figure 1 provides the ’big picture’ regarding this architecture. The space segment is comprised of satellites in the sky. In LEO constellations, these satellites can carry omnidirectional or directional (beamforming) antennas. The latter case is the one most encountered in LEO megaconstellations nowadays, and it is the one illustrated in
Figure 1, where each satellite beam can serve a certain end user. The ground segment hosts the GS satellite network and is complemented by a number of GSs, placed all over the Earth, with the main tasks of monitoring, managing, and controlling the platforms and the signals sent by the satellites. The ground segment typically does not interact with the user segment, but only with the space segment. Last but not least, the user segment comprises all user devices enabled with a LEOsupporting chipset; such devices can serve a myriad of applications needing communication, navigation, and/or sensing capabilities. Onboard LEO chipsets on such user devices can also support integration with other chipsets, such as 5G chipsets, IoT chipsets, or Inertial Navigation Sensors (INS). In the case of Earth Observation constellations, the GS network is used mostly for sensordata downloads. In this paper, we assume this threesegment architecture applies to all LEO networks.
Each of the segments has processes that require optimization;
Table 2 summarizes the optimizationrelated problems that have been actively addressed in the scientific community in recent years for each segment of the abovementioned architecture. These optimization problems are shown together with examples of optimization objectives, parameters of interest, as well as common metrics used in the optimization process. An important note is that, while the optimization objective of each problem varies, any optimization objective can be categorized according to the target problem, e.g., as shown in
Table 2.
Below, we group the optimization criteria related to LEO networks under three main optimization classes. We show some examples for each category, and we specify if the example cost functions are to be maximized (max.) or minimized (min.):
 1.
Coveragerelated aspects:
Min. Satellite Revisit Time: This revisit time is the time elapsed between consecutive observations of the same point on Earth by a satellite. The lower this time, the better the performance.
Max. Satellite Availability: The availability refers to the percentage of time that the service performance provided by the satellite reaches the user equipment in a desired location. Therefore, the higher the availability, the better the system performance.
Min. Satellite Orbit Drift: Deviation of the satellite from the planned orbit due to atmospheric drag and gravity.
 2.
Costrelated aspects:
Min. Production Cost: This refers to the production and maintenance cost of satellites, GS, and tools; the lower, the better.
Min. Launch Cost: This is the cost related to launching satellites to the desired orbits; the lower, the better.
Min. Deorbiting Cost: This is the cost to deorbit a satellite (i.e., take satellite out of the constellation) after its lifespan ended; the lower, the better.
Max. Satellite Lifespan: This is the time a satellite spends operating in acceptable conditions; the higher, the better.
 3.
Performancerelated aspects:
Min. Latency: The time delay before a full data transfer takes place for a communication, sensing, or navigation task. The lower the time, the better the performance.
Max. Stability: The property that is inversely related to the need for change within the system. The higher the stability, the better the performance.
Max. Throughput: The amount of data (signals, supported number of users, etc.) passing through the system; it is of particular importance for communicationrelated applications, and typically, the higher, the better. However, some navigation and sensing applications do not require high throughputs; in such cases, throughputs targets may be removed from the optimization parameters.
Max. SignaltoNoise Ratio (SNR) or $C/{N}_{0}$: SNR and $C/{N}_{0}$ are measures of the signal quality after unwanted modifications that the signal may suffer during transmission, capture, storage, conversion, and processing. The higher the SNR and $C/{N}_{0}$, the better; a minimum value for SNR or $C/{N}_{0}$ typically needs to be guaranteed for good functioning of the system.
While
Table 2 cannot cover every possible problem related to the LEO segments, it provides a very good example of both the scope and the complexity of the entire system’s optimization. This paper focuses on the example problems listed
Table 2 and on various aspects related to those problems, with the note that additional optimization problems such as those related to packet routing and medium access control may exist, but they fall outside the scope of the current paper.
Figure 2 provides a map for the optimization processes with respect to each of the three architectural segments, with a focus on autonomous transportation regarding the user segment. The main takeaway idea from
Figure 2 is that certain optimization methods can be used to solve different problems in different segments, as a method’s applicability is determined by problem formulation as well as the problem’s nature.
Although spacesegment optimization may deal with additional problems such as controller placement for LEObased SDN (a controller in terms of SDN is an application that manages flow control for improved network management and application performance), its primary design problem is
constellation optimization. Constellation optimization is one of, if not the most, critical aspect of LEO spacesegment design, as the constellation parameters are directly related with critical operating parameters of all enduser applications, such as communication and navigation on autonomous vehicles. Some examples are: the orbital altitudes directly affect the latency of LEO satellite networks; the orbital plane positioning of satellites directly determine the coverage areas, which, at its turns, is related to the feasibility of user applications. In addition, the optimization of such parameters will have to deal with and successfully satisfy any regulatory criterion set by entities, such as International Telecommunication Union (ITU), Federal Communications Commission (FCC), or any other local or international regulatory entity. Related to the regulatory aspects, physicallayer parameters (e.g., frequency allocations, used modulations, maximum transmitted powers, etc.) must be taken into account in order to keep unintentional interference with the rest of systems (radio astronomy, already functioning GNSS systems etc.) to a minimum degree [
43,
44]. Additionally, it should not be a surprise that some of the optimization parameters regarding different architectural segments (as well as some metrics) relate with each other in varying proportions, as seen from
Table 2.
In contrast to the space segment, the user segment deals with optimization problems that occur for particular application interests, and, as a result, it includes a very large number of optimizationrelated problems that are generally casespecific. Technically, any application that uses both LEO satellite systems and can be optimized is included in the ’usersegment’ terminology. A simple example would be a communication network with swarm drones that uses LEO satellites, which have optimization aspects ranging from data transmission to network topology to the actual goal of the swarm application, such as obstacle avoidance or drone tracking. Another straightforward example is the satelliteselection problem in GNSS; this refers to finding the optimal number of satellites to track if there are more available satellites than necessary. As GNSS information can used in a variety applications, it is a broad enough problem to be provided as an example in
Table 2. Additionally, the satelliteselection optimization problem is also an optimization problem that has to happen at the usersegment side, as it heavily depends on the user/vehicle’s location and continuous motion. Of course, one can only select among visible satellites in cases where coverage is not an issue, and this is also related to the spacesegment design. Therefore, the satelliteselection optimization problem is a good example of how problems from different LEO segments relate with one another.
Unlike the other segments, the ground segment is quite straightforward to design, as it is generally the segment that monitors the network for controlrelated purposes. Due to this aspect, the ground segment has only one significant optimization problem: GS planning. This problem deals with the sky coverage of the GS and focuses on geographic and costrelated aspects.
There also exists optimization problems that require being addressed in all three segments (not present in
Table 2) for clarity purposes and because they fall outside the scope of this paper). These include more general aspects of the physical layers specific to different segments, such as the signal and antenna/beamformingrelated optimizations, resourcemanagement for individual devices within the network, such as satellites or vehicles, channel coding aspects, and multipleaccess optimization. Likewise, some problems require handling from multiple segments, such as channelbased optimization, Multiple Access Channel (MAC) design, handovers, and security. More details about the segmentbysegment optimization problems are presented in the next sections.
4. Categorization of Optimization Methods
Before going into highspeed scenarios and examining optimization processes in different segments, it is useful to introduce what constitutes an optimization problem and to provide a classification of different optimization methods based on their optimization objectives.
A typical unconstrained optimization problem can be written as in
Table 3, according to one of the four types listed there. These four types are based on whether the inputs and outputs are scalars or vectors, respectively.
The target optimization function
$f(\xb7)$ or functions
${f}_{i}(\xb7),i=1,\dots ,N$ can be either minimized or maximized; for simplicity, we formulate everything in terms of a minimization problem, with the equivalence
$ma{x}_{x}f\left(x\right)=mi{n}_{x}(f\left(x\right))$. In
Table 3,
$\mathcal{S}$ is the scalar optimization search space, and
${\mathcal{S}}^{M}$ is the vector optimization search space. The constrained optimization problems can be easily formulated starting from the formulas in
Table 3 by adding some constraints or boundaries, such as, for example,
${g}_{i}\left(x\right)\le 0,i=1,\dots ,{M}_{1}$ or
${h}_{j}\left(x\right)\le 0,j=1,\dots ,{M}_{2}$, where
${g}_{i}(\xb7)$ and
${h}_{j}(\xb7)$ are functions defining the constraint on the solution
x.
When we have a singleobjective or a multimodal optimization problem (i.e., a single scalar function of a scalar or vector input), there is usually, at most, one optimization solution ${x}^{*}$ (scalar) or ${\mathbf{x}}^{*}$ (vector).
When we have a multiobjective optimization problem, several objectives (${f}_{i},i=1\dots ,N$) must be minimized simultaneously, and therefore, there usually exists a tradeoff between the different functions ${f}_{i}$. The optimal solution is called Pareto optimal ${x}^{*}$ (scalar) or ${\mathbf{x}}^{*}$ (vector), and it is a set of noninferior solutions in the sense that no other solutions can be found that can minimize one of the objective functions ${f}_{i}$ without increasing the value of another of the objective functions ${f}_{j},j\ne i$.
Furthermore, we classify the optimization methods that have applications in LEO networks according to
Figure 3. It is straightforward to see the relation between
Figure 3 and
Table 2, as
Figure 3 includes most of the methods listed in
Table 2. However, it is also important to show the relation between
Table 3 and
Figure 3 by noting which methods are suitable for which types of optimization problems. We will focus on explaining this relation for the remainder of this section.
On one hand, many of the methods in
Figure 3 are methods inherently developed to deal with singleobjective optimization problems in mind; for example, traditional heuristic algorithms, such as the Greedy Search [
45] and Dijkstra Algorithm [
46], minimize the defined cost (i.e., node or transmitterreceiver distance, network traffic/throughput, etc.). Similarly, linear solvers, such as MixedInteger Linear Programming (MILP), are also applicable for singleobjective optimization problems; however, they can also be expanded to operate with multiobjective or multimodal problems, given accurate and cleverly formalized problem models, e.g., as shown in [
47].
On the other hand, recent and advanced methods are suitable for all types of mathematical optimization problems seen in
Table 3. The complex search algorithms, such as Simulated Annealing (SA) [
48], and evolutionary algorithms, such as GA [
49] and Particle Swarm Optimization (PSO) [
50], are methods that originally dealt with a singleobjective optimization problem again, but they now have improved versions that extend the method to multimodal and multiobjective problems (i.e., MultipleObjective Simulated Annealing (MOSA) [
51], MultipleObjective Genetic Algorithm (MOGA) [
52], NonDominated Sorting Genetic Algorithm II (NSGAII) [
53], MultipleObjective Particle Swarm Optimization (MOPSO) [
54], and HybridResampling Particle Swarm Optimization (HRPSO) [
55]). Similarly, the Neural Network (NN)based methods [
56], such as Deep Neural Network (DNN) [
57] and Convolutional Neural Network (CNN) [
58], are typically designed for a particular problem, which can be any type of optimization problem from
Table 3.
Other methods, such as Kalman Filtering (KF)based methods (i.e., basic KF [
59], Extended Kalman Filter (EKF) [
60], Unscented Kalman Filter (UKF) [
61], Adaptive Kalman Filter (AKF) [
62]), and SupportVector Machine (SVM) [
63], are methods that solve singleobjective multimodal optimization problems, but, similarly to the abovementioned cases, they are flexible in the sense that they can be extended to other types of optimization problems via modifications. KF methods, in particular, are very suitable for estimation problems under accurate underlying problem models.
An important method to discuss in detail is the MC optimization. Despite also being a bruteforce optimization method that relies on the problem model, MC is unique in the sense that most simulations regarding LEO networks are constructed as a MonteCarlo loop due to its ability to directly propagate parameters through the system model. This makes it so that the methods that require environment observations or interactions, such as evolutionary algorithms, are methods that are jointly utilized with MC loops. However, it should also be noted that the MC loop does not refer to an MC optimization in such cases; the parameters are optimized according to the actual optimization method utilized. For detailed explanations regarding MC, we advise dedicated sources such as [
64,
65].
Since LEO networks have a high number of optimizationrelated problems from all the types shown in
Table 3, it should not be surprising that many of the discussed methods are suitable for multiple types of optimization problems. However, it should be noted that a method being suitable for a problem does not mean that it performs optimally or that it is feasible to apply for that particular problem. We will discuss the differences and tradeoffs between different methods in detail in the next sections, when we examine the optimization problems in different segments of a LEO system.
Last but not least, an important aspect, which has a significant impact to the overall system in practical applications concerning autonomous vehicles, is the overhead of the optimization engines. In the case of an online optimization (i.e., optimization that takes place during the system operation), the overhead mainly refers to the time delay added to the system by the optimization procedure as well as to the required system resource allocation to perform the optimization. Examples of online optimization tasks are network routing and handover management (see
Table 2).
When we perform the optimization before the system is operational, this is referred to as an offline optimization part. Examples of offline optimization are the GS planning and constellation optimization (see
Table 2). In an offline optimization task, the main overhead is the required timetoconverge and complexity of the optimization method. These two parameters typically determine the feasibility of a method.
The variety of the implementation specifics, such as the chosen implementation language (e.g., Python, C, C++, etc.), as well as the available hardware will have an impact on the system overhead. We will provide additional observations with respect to the overheads when we present the optimization methods in detail in later sections. Generally, the overhead of an optimization method needs to be examined on an implementationandscenariodependent basis.
5. HighSpeed Scenarios Based on LEO Satellites for Future Autonomous Vehicles
An autonomous vehicle, or a driverless vehicle, is a vehicle that operates itself and performs necessary functions with minimal (or no) human intervention through its ability to sense its surroundings. There are six levels of automation according to [
66]; level 0 refers to the no automation case where the vehicle is completely dependent on a human driver and level 5 refers to the fullautomation case, where the vehicle is completely independent in all cases and necessitates no human intervention. Most of the realistic autonomous vehicles nowadays are between levels 2 and 4.
For autonomous vehicles, the notion of highspeed scenarios include any case that deals with high speeds regardless of their domain; a highspeed case can be as simple as providing cellular connectivity to mobile devices inside a fastmoving train, going over 250km/h, or it can be as complex as the need of instant wireless communication between different highspeed drones and flying taxis to avoid collision. For our discussions in this paper, we will consider LEOsatellite system scenarios that either require high speeds in parameters, as in the drone example, or scenarios that occur in highspeed vehicle motions, as in the train example.
If we aim to achieve full automation in highspeed cases, future networks of autonomous vehicles will have stringent requirements in terms of communications, positioning, and sensing characteristics, which are not yet fully met by current cellular and IoT technologies. A summary of these stringent requirements is given in
Table 4, together with example studies from the literature that have addressed these challenges to some extent and offered various solutions to them. It is also straightforward to see that the requirements listed in
Table 4 can be perceived as boundaries for the optimization problems that have the overlapping metrics from
Table 2.
However, it is also important to discuss existing limitations of highspeed scenarios for autonomous vehicles. One limitation in the current terrestrial technologies in terms of autonomous vehicle services is the requirement for ubiquitous and seamless coverage, which should be as close to
$100\%$ as possible. In order to address this challenging limit, satellitebased networks, such as leo, as well as their integration with terrestrial networks, have begun being investigated in the literature, e.g., in [
78].
Another very important aspect, which becomes even more significant in highspeed scenarios due to time/delays and computation constraints, is the security aspect. Good and uptodate surveys on the security aspects in automotive transportation and unmanned vehicles can be found in the literature, for example, in [
79] (blockchain solutions for UAV), ref. [
80] (physical layer security for UAV), ref. [
81] (quantum cryptography for UAV), ref. [
82] (integrated network security for terrestrial and aerial transportation), ref. [
83] (a systematic literature review on AI in UAV safety), etc. Security aspects are very broad and are not typically a part of the design optimization of the space or ground segments, as there are many security solutions that can be devised in the postdesign stage, such as using multisystem multifrequency receivers, using various encryption methods or authentication signals, etc. While we highly recognize the importance of ensuring high security mechanisms for communication, sensing, and positioning purposes in autonomous transportation, it is our opinion that we cannot deal with the security aspects as normal optimization parameters, and therefore, the security part is seen as outside the scope of the current survey. That being said, we would like to point out that some of the optimization methods that we cover in this paper are also utilized in securityrelated aspects in autonomous vehicle implementations. Some examples include: [
84], where the authors implement Reinforcement Learning (RL) to maximize the robustness of UAV dynamics control to cyberphysical attacks, and [
85], where the authors implement a ProportionalIntegral Derivative (PID) controller using PSO as a tuning method to achieve high stability.
Furthermore, another optimization aspect that directly relates to security is resource management. Generally speaking, security measures require their own share of computational resources, so any optimization that handles management of resources within a LEO system must consider the requirements of the possible security applications, even if as briefly as only a threshold or reserve. Such threshold is typically straightforward to define as an additional boundary in the optimization problem.
A similar, scenariobased limitation that arises frequently in LEO satellite systems is the problem of the satellite handovers (i.e., changing enduser connection from one satellite to another), which heavily impacts the requirements of autonomous vehicle systems in terms of latency, throughput, and accuracy. Due to the low orbital altitude ( 200–2000 km) of LEO constellations, LEO satellites move at higher speeds (i.e.,
$7.5$ km/s at 600 km altitude) than MEO and GEO satellites [
16]. This effectively means that, for any particular autonomous vehicle, the satellite is available for only up to a few minutes before a handover is required [
14], even when the LEO constellation is dense enough to provide 100% coverage for the area of interest. The frequency at which the handovers happen changes dynamically as the vehicle moves, and it can highly affect the latency, throughput, and accuracy targets, especially in highspeed motion scenarios with opposite directions with respect to the satellite’s movement. Again, this remains a limitation that is being investigated to various degrees by academia in studies such as [
40,
42].
6. SpaceSegment Optimization Aspects
As mentioned earlier in
Section 3, the main optimization problem of the space segment in LEO design is the constellation optimization. This section focuses on LEO constellation characteristics and constraints through a detailed survey of significant design elements, existing constellations, and key performance parameters, as well as applicable optimization methods.
The main goal is to show the steps to adopt toward a feasible and optimized constellation design to provide service to transportation vehicles and to meet the emerging demands of more autonomy and reliability.
There are many approaches in constellation optimization and one area that is still lacking in the current literature is the area of multitarget and restrictiondriven optimization. Pure geometrybased solutions are easy to sketch and small satellite constellations are not necessarily demanding in terms of the minimum number of satellites. However, a realistic optimization of the constellation should take into account the factors that are most restrictive, such as the orbit topology, satellite launch cost, radiation requirements [
86], satellite redundancy, atmospheric drag (i.e., the force exerted on satellites due to their movement through air), the need for propellant and maneuvering, etc. All these aspects are addressed in detail in the following subsections.
6.1. Orbit and Constellation Elements
The selection of the orbital parameters for the constellation affects the overall design and mission output. In
Table 5, the main parameters describing a constellation are depicted, which can be leveraged to optimize the constellation [
87].
The orbital parameters of the constellation generates its topology mainly dominated by the type and region of coverage. The coverage can be regional, zonal, or global with continuous or intermittent visibility. The coverage is typically 1fold to 4fold. The communication and surveillance applications usually require 1fold coverage, and 4fold coverage is essential for positioning and navigation applications [
92].
The coverage equation is modeled by
where
$\mathcal{C}$ is the coverage parameter,
$\epsilon $ is the elevation angle of the viewing cone of the satellite,
h is the satellite altitude,
${R}_{E}$ is the Earth radius, and
$\theta $ is the central angle of coverage [
87]. An illustrative example of these parameters is provided in
Figure 4.
6.2. Constellation Topology
The major constellation topologies are the following four topologies:
Table 6 presents the mathematical modeling of the two most encountered constellation topologies, namely Walker and Flower constellations. In
Table 6,
i is the inclination of orbit,
${N}_{T}$ is the total number of satellites,
${N}_{P}$ is the number of orbitalplanes of the constellation,
F is the relative phasing parameter between adjacent orbital planes, and
h is the Satellite (Sat) altitude.
$\Delta {\Omega}_{jk}$ is the RAAN and
$\Delta {M}_{jk}$ is the mean anomaly with respect to the reference Sat, with
j as the orbital plane number and
k as the Sat number within the orbital plane. For Flower constellations,
${N}_{p}$ is the number of orbital revolutions of Sat, and
${N}_{d}$ is the number of rotations of the rotating reference frame; for the Earthcentered, Earthfixed frame (ECEF),
${N}_{d}$ is equal to the number of days. These design parameters are related as
${N}_{p}\frac{2\pi}{n}={N}_{d}\frac{2\pi}{{\omega}_{E}}$. Here,
n is the orbital mean motion of the Sat, and
${\omega}_{E}$ is the angular velocity of the rotating frame.
${F}_{d}$,
${F}_{n}$, and
${F}_{h}$ are independent integers for phasing.
$\Delta {\Omega}_{k}$ is the RAAN, and
$\Delta {M}_{k}$ is the mean anomaly, with
k as the Sat number with respect to first Sat [
101,
102].
Figure 5 visualizes examples of constellations at various altitudes and with various number of orbital planes and inclinations.
6.3. LEO Satellite Constellations
In the literature, we can find many constellations that have most of their satellites already in the sky (e.g., Globalstar, Orbcomm, Iridium, …). However, not all LEO constellations are fully operational. Some of them are partially deployed (e.g., Starlink, Oneweb), and some others are only planned to be launched in the relatively near future (e.g., Amazon Kuiper or Facebook Athena). In
Table 7, we have listed some of the most promising/currently relevant LEO constellations. Currently, LEO constellations are typically used for narrowband and broadband communications and Earth observation. The main advantage of LEO lower altitudes (compared to MEO) is the relatively low latency, fundamental for voice applications and high performance internet connection. Traditionally, LEO constellation were placed in the higher end of LEO altitudes (e.g., >800), e.g., Globalstar, Orbocomm, and Iridium. On the contrary, due to the latest progress in satellite construction and launching, we are able to put in orbit smaller satellites in a more efficient way, placing in an orbit multiple satellites in a single launch. Besides the constellation names,
Table 7 also lists some relevant parameters describing these constellations, as well as some references for the most advanced readers.
Table 7 summarizes fundamental orbit parameters, such as the total number of satellites in the constellation, the number of independent orbital planes
${N}_{P}$, the altitude (or altitudes)
h considered during the constellation design, and the orbital plane inclination
i. In addition,
Table 7 also shows the frequency band used for the considered constellations, as well as the typical satellite mass and the main purpose of the constellation.
6.4. Launch Services and Constraints
The newspace approach offers exponential growth in contrast to the traditional space by making use of small satellite technology, new manufacturing techniques, commercial offtheshelf components, by taking relatively higher risks, and by applying fast development cycles. This has prompted an ecosystem where more and more satellites and constellations are being deployed to offer terrestrial services for emerging markets. With new financing models, the outcome is novel and comprised of futuristic space companies, platforms, subsystems manufacturers, launch providers, and ground station services [
115,
116,
117]. With the newspace ecosystem, the launch services have also emerged in new categories [
118,
119].
Dedicated Launches: A dedicated launch has one major payload that controls the mission requirements on the whole.
Traditional Rideshare Launches: Standard ridesharing consists of a primary mission where surplus mass and volume used by other satellite missions.
Dedicated Rideshare Launches: Dedicated rideshare launches are multimission launches to deploy dozens of satellites with relatively similar orbital parameters.
To meet the requirements of newspace missions, launch broker and services providers joined the launch vehicle manufacturers with reinvented business practices. The Launch Service Provider (LSP) matches a spacecraft with a launch opportunity, providing a standardized separation system with physical integration of the spacecraft to the launch vehicle and with the management of the launch campaign. This has further lowered the barriers for new and nontraditional players to deliver a product to space.
With traditional rideshares and dedicated rideshares, the cost of launch has decreased significantly [
120]. However, the action of launching satellites as a secondary payload or as part of a rideshare has various constraints, as the launch schedule and insertion orbit are marked by primary payload or through a compromise among all payloads in the rideshare. This also adds restriction on with propellant volume and pressure of any secondary payload’s satellite design, thus limiting the secondary payload to maneuver to preferred orbital planes [
121]. For missions with stringent orbital and design requirements, this may not be a feasible solution and a dedicated launch may be too costly [
122]. In the case of constellations, such constraint piggyback launches add complexity to the constellation design and optimization [
6]. A rough numerical estimate for the overall costs of a microsatellite (10–100 kg Sat) for a fiveyear mission lifetime observed by Liddle et al. [
123] is given in the following equations, where
C refers to cost of the part of the satellite, denoted by its subscript.
According to [
123], the payload, platform, and launch costs are approximately equal to each other, while the operation cost is approximately half of the payload cost (and also of the launch cost).Thus, with the abovementioned approximations, one could compute the total cost as:
To acquire the flexibility offered by a dedicated launch with costs comparable to rideshare launches, there is a demand for dedicated microlaunchers. With more satellite clusters and constellations planned to be launched in coming years, many companies are building these launchers to meet these demands [
124]. The target of the launch vehicles is to deliver a payload from 10 to 300 kg to LEO with costs matching to the current rideshare costs [
121].
Table 8 gives a classification of Launch Vehicle (LV) according to their payload capacity to LEO.
6.5. Constellation Deployment
Deployment for an optimal constellation for continuous global coverage requires multiple satellites separated within an orbital plane and distributed over several orbital planes at desired altitudes and inclinations. Deploying a globalcoverage constellation with the existing launch paradigms would require a dedicated launch for each orbital plane. This would result in very high launch costs beyond the budget of usual missions [
120,
125]. As cost is one of the prime optimization parameters, developing an efficient way to deploy a constellation is essential [
126]. This requires addressing the constellation configuration, satellite design, and launch opportunities simultaneously [
6]. As presented in [
127], constellation deployment may be distributed in direct injection, where Sat is placed by LV, and indirect injection, where either the LV or Sat performs nonplanner maneuvers to achieve the final orbit. However, Impulse per unit of Mass (needed to perform a maneuver) (
$\Delta V$) for such orbital transfers is very high. An alternative indirect injection approach is to utilize orbital perturbations due to Earth’s oblateness to transfer Sat different orbital planes and populate the constellation. This idea was first patented by King and Beidleman to use natural perturbations to separate the orbital planes with RAAN. The nodal precession due to Earth’s oblateness varies with altitude, inclination, and eccentricity at different rates. The nodal precession using SecondDegree Zonal Harmonic of the Earth’s Gravity Field (
${J}_{2}$) is given by Equation (8) [
128], where
${\dot{\Omega}}_{{J}_{2}}$ is the rate of change in
$\Omega $ due to
${J}_{2}$,
${R}_{E}$ is radius of Earth,
a is the semimajor axis,
e is eccentricity,
i is the orbital inclination, and
n is the mean motion of the Sat.
The plane separation would first require an inplane maneuver, which requires less
$\Delta V$ to change the orbit for a different nodal precession rate and after the drift period required for desired plane separation maneuver back to the mission orbit [
121]. For constellation deployment, [
129] uses drag to achieve inplane maneuvering and nodal precession to achieve outofplane maneuvering. FORMOSAT3/COSMIC satellite mission is presented in [
130], where six deployed satellites used inplane thrust maneuvers for orbit raising and utilized differential nodal precession to achieve different orbital planes. A detailed study to deploy a multiplane constellation using nodal precession is also presented in [
131].
Using orbital perturbations for plane separation results in a longer time for full constellation deployment, whereas a dedicated launch induces high mission costs, resulting in a tradeoff between deployment time and launch cost [
125].
6.6. Constellation Maintenance
6.6.1. Orbital Perturbations
The orbital elements under the influence of perturbations result in osculating elements. These perturbations are due to Earth’s oblateness, atmospheric drag, solar radiation pressure, and third body effects. These timedependent osculating elements change differently for satellites at different points in orbital planes. This results in a relative drift between each satellite changing the constellation pattern and ground coverage over time. The inplane Sat spacing and planetoplane RAAN spacing vary over time, requiring maneuvers for corrections. For LEO Sat, the most significant perturbations are due to Earth oblateness, atmospheric drag, and solar radiation pressure [
132].
Earth’s gravitational potential due to nonspherical earth is presented in spherical harmonics.
${J}_{2}$ has the major effect; the higher order zonal, sectoral, and tesseral harmonics in order of magnitude are three times smaller than
${J}_{2}$.
${J}_{2}$ produces secular rates in RAAN
$\Omega $, argument of perigee
$\omega $, and mean motion
n. The Argument Of Latitude (AOL)
u, which is defined as the sum of
$\Omega $ and true anomaly
$\theta $, also experiences a secular change as a result of
${J}_{2}$. The nodal precession is the rate of change of RAAN, whereas the apsidal precession refers to the precession of the line of nodes on the orbital plane. The atmospheric drag affects the semimajor axis
a and eccentricity
e of the orbit.
${J}_{2}$ or drag does not affect the inclination. The third body effects for LEO satellites are also very small in comparison to
${J}_{2}$. Deviations in
a,
e, and
i will result in secular drifts in
$\Omega $,
$\omega $, and
n [
93].
6.6.2. Station Keeping
Station keeping refers to maintaining the satellites in a space box within defined tolerances through either absolute station keeping, where the position is maintained with respect to the central body reference frame, or relative station keeping, where the Sat position is maintained relative to the position of other Sat(s). The initial differences in the Sat orbits and perturbations accumulated over time disrupts the constellation geometry and necessitates stationkeeping maneuvers. The perturbations in orbit are short periodic, long periodic, and secular, with each requiring different compensation through either intrack or crosstrack orbital maneuvers. The major advantages of absolute station keeping reported in [
87] in comparison to relative station keeping are a priori Sat position estimates, more robust control, less propellant requirements, less complexity, and cost. It also highlights that for autonomous station keeping, the absolute station keeping is better as it is implemented with a larger sequence of small
$\Delta V$ maneuvers, rather than a few small impulsive maneuvers. Sat station keeping can be achieved through low thrust maneuvers or impulsive maneuvers. Both maintenance schemes and propulsion systems are widely studied for LEO constellations.
The authors in [
133] study the inplane station keeping of a Walker constellation, considering Earth’s gravity field and solar radiation pressure, and bringing the satellites to the defined tolerance band for the position by two periodic impulsive maneuvers. The study also gives the
$\Delta V$ estimates for constellation maintenance. The authors in [
134] study the station keeping in constellation as a multiobjective optimization problem with minimum fuel consumption and time constraints. The chosen scheme, intrack and crosstrack tolerances, as well as the maintenance schemes set the requirements for the propulsion system of the satellites.
6.6.3. Space Radiation
One of prominent problem for electronics in space is the ionizing radiation that disturbs or destroys semiconductors. The primary sources of radiation in space are: the Galactic cosmic rays, the solar proton events, and the trapped radiation in Earth’s magnetic field. The impact of this radiation on the satellite platform and subsystems can be grouped as follows:
Satellite Charging and Internal Charging (SCIC): It is the accumulation of charge on the outer surface of the satellite or on the interior surfaces. This causes potential variations between the spacecraft surfaces and the ambient plasma, resulting in ElectroStatic Discharges (ESD)related anomalies.
Single Event Effects (SEE): Single event effects are caused by the impact of highenergy chargedparticlesensitive electronics of Sat subsystems.
Total Ionizing Dose (TID) and Displacement Damage (DD): The total ionizing dose refers to the energy produced through the passage of electrons and protons through materials, resulting in degradation.
To withstand the radiation environment, the electronic components should be specially designed and qualified for highradiation environments (radiation hardening), which makes the components very expensive. Lately, the usage of nonhardened components has been growing to meet the price pressure. The radiation in nearEarth space has been concentrated into socalled radiation belts, starting from an altitude around 1500 km to 2000 km. Therefore, based on the operational altitude and region of the SCIC, the satellite designer can estimate the TID to select components and device radiation shielding and protection [
135]. Koons et al. surveyed space anomalies from various databases in [
136] and concluded that the largest anomalies recorded were due to ESD and charging. The second largest group was SEE, whereas the surface degradation due to radiation damage, especially for solar arrays, formed the thirdmost group of recorded anomalies. As the radiation level and its type are dependent on orbital parameters, the optimization of Sat electronics depends on orbit design.
6.6.4. Satellite (Sat) Replacement
A failure of one or more satellites can result in the service deterioration for a constellation providing global coverage. In such a case, having spare satellites and a good replacement strategy are parts of the constellation design in order to make sure that, in the case of a failed or terminated satellite, a replacement is deployed without much delay [
89].
Cornara et al. discuss replacementandspare strategies in [
127,
137], dividing them into categories with noreplacement planned, launchondemand by ground spares, or ondemand manufacturing, Sat spares in parking orbit and inorbit spares. In the case of navigationandcommunication satellite constellations, continuous service and reliability are achieved by overpopulating the constellation with one or two extra satellites per orbital plane. In [
138], an inventorymanagement approach for megaconstellation satellite replacement was proposed since traditional spare strategies cannot be applied due to limited scalability. The strategy implements spares as a supply chain with ground facilities as suppliers, satellite parking orbits as warehouses, and inplane orbital spares as retailers in order to minimize the sparestrategy cost. The service ability and the satellite reliability drive the selection of the strategy for replacement.
6.6.5. EndofLife (EOL) DeOrbiting
In addition to the maintenance during the mission lifetime, a Sat in a constellation requires an EOL scheme to remove satellites from their orbit upon failure or termination. At the end of life, a Sat is required to fulfill the disposal requirement to reenter the atmosphere within a 25year limit. This limitation is implemented in national legislation in order to reduce the accumulation of orbital debris and lower collision risks. Moreover, a dysfunctional satellite in a megaconstellation might pose a threat to the constellation itself via collision risk. The orbital decay depends on the ballistic coefficients of Sat and the solar activity at the EOL time. The ballistic coefficient
${B}_{C}$ is given as:
where
${C}_{d}$ is the coefficient of drag,
m is the satellite mass, and
$\mathcal{A}$ is the crosssectional area. The solar activity is indicated by the solar radio flux at a wavelength of
$10.7$ cm, also referred to as the solar index. F10.7 changes with the 11year solar cycle changing the minima and maxima. This parameter is important to estimate the Sat orbital decay as drag correlates with the solar cycle.
If the 25year limitation cannot be satisfied, the mission designers need to employ alternative disposal strategies. These include:
Uncontrolled Reentry, where the decay time of Sat is decreased by changing the Sat areatomass ratio physically. This is the most costeffective disposal scheme. Sometimes, this scheme may initially require one or more maneuvers to facilitate the decay;
Controlled Reentry, where orbital maneuver are carried out to induce controlled orbital decay and burnup in the atmosphere. This would require the Sat to maintain attitude and have a propulsion system for deorbiting. This would also require the maneuvers to be incorporated into design with EOL fuel budget, resulting in increased platform mass and overall costs;
Graveyard Orbit Placement, where the Sat(s) maneuver to graveyard orbit, defined due to lack of its value for space missions. This is common for GEO and MEO satellites [
87,
137]. The mission design for a LEO constellation would require incorporating an EOL strategy for Sat.
6.6.6. Space Debris
When designing a satellite constellation, one should also address potential spacedebrisrelated problems. A high number of satellites at a certain orbital altitude increases the risk of those satellites colliding with each other. An orbital satellite collision can generate a cloud of debris, which can render even more satellites nonfunctional and can degrade the spacesegment functionality. A collision with satellites belonging to other owners can also lead to liabilities with heavy economic consequences. Even when collisions can be avoided by avoidance maneuvers, frequent maneuvering will increase operational cost and will require inorbit consumables. Therefore, the collision risk and the required avoidance maneuvers should be estimated for the space segment.
To assess the collision risk, typically, an annual collision probability with a large space object along with orbital lifetime is estimated. The estimation requires an estimate of the satellite projection area, the orbital parameters of the satellite, and the satellite launch date. The collision risk analysis is usually performed using a predictive model database of space objects and space debris. The same database is required for collision avoidance maneuver budget estimation. For example, the European Space Agency (ESA) provides a MASTER (Meteoroid and Space Debris Terrestrial Environment Reference) database and a DRAMA (Debris Risk Assessment and Mitigation Analysis) software package for this task. The spacesegment optimization for space debris avoidance is a complex task, which cannot be easily integrated into the general optimization tasks addressed in this paper, and it is omitted in the current framework.
6.7. Optimization Metrics Related to the Space Segment
The spacesegment optimization, as mentioned above, includes all optimization steps that take place within the satellite constellation, and such optimization steps can happen in multiple layers. An example analogy is the network optimization in [
15]. However, in the broadest meaning of the term, the spacesegment optimization refers to the parameters of the constellation, see, e.g.,
Table 5 (and thus named ‘constellation optimization’). The aim of constellation optimization is to distribute multiple satellites with similar types of functions into similar or complementary orbits in order to accomplish specific tasks under shared control.
It is possible to classify the optimization objectives that fall into the chosen application area into the following three categories: (i) coverage, (ii) cost, and (iii) performance (see also the discussion in
Section 3). As the space segment is the first LEO segment for which we discuss specifics, we will provide the commonly used metrics following this categorization. For the ground and user segments, our focus will be solely on presenting the metrics rather than where they fit in the categorization.
The coverage metric, which refers to the ground coverage of the satellites from the perspective of the space segment, enables whether or not the target application (e.g., communication, positioning, or sensing) is able to operate in a stable manner. It is traditionally calculated geometrically, and ensuring its continuity is optimized via secondary metrics, such as minimizing the satellite revisit time or maximizing daily visibility time, with a focus on local or global maximal coverage, depending on the application goals. We have already provided an example model for ground coverage calculation in Equation (
1).
The choice of a suitable performance metric is very important and, naturally, applicationdependent. For the space segment, some of the commonly known metrics are the Dilution of Precision (DOP)based metrics, such as GDOP [
139] and Time Dilution of Precision (TDOP) [
140], and the system level metrics, such as
$C/{N}_{0}$, SNR and SignaltoInterferenceplusNoise Ratio (SINR).
It should be noted that such metrics are not exclusive to the space segment. In order to avoid repetition, we divide the metrics between the three LEO segments (see
Figure 1) when a particular metric is used in multiple segments. For example, as DOP metrics, such as GDOP and TDOP, are widely used in usersegment optimization, we will describe those metrics in
Section 8, while the other metrics such as SNR, SignaltoInterferenceplusNoise Ratio (SINR), and
$C/{N}_{0}$, used widely for all three segments, are presented here.
The most basic definition of SNR is the ratio of signal power to noise power, often expressed in decibels, as seen in Equation (10). Here,
${P}_{\xb7}$ denotes the power of the signal or noise in watts, measured at equivalent times and within the same system bandwidth.
SINR is a very similar metric to SNR. It is often expressed in decibels (dB), as in Equation (11). Similarly to Equation (10),
${P}_{\xb7}$ denotes power in watts.
$C/{N}_{0}$, while close to SNR, is a much more commonly used metric for applications regarding LEO constellations. It is usually expressed in decibelHertz and refers to the ratio of the carrier power
${P}_{carrier}$ to the noise power
${P}_{noise}$ per unit bandwidth. It is calculated as in Equation (12), where notation from Equations (10) and (11) carries over in terms of units and definitions.
Minimizing the costs is a logical objective for any commercial service; for a straightforward example, using a minimal number of satellites operating at low altitudes can increase the reallife feasibility of applications, as those parameters directly reduce the manufacturing and launch costs. However, the tradeoff between constellation altitude and coverage depends on application. With a lower altitude, the satellite signal reaches the receiver at a higher SNR, but more satellites are needed to provide the coverage. As for a mathematical explanation, we have already presented a cost model from [
123] in Equation (7).
Another significantly more complex metric that is required for the optimization process of most advanced methods, such as the Machine Learning (ML)based approaches, is the applicationspecific objective function. This metric has different names and serves different purposes depending on the literature area; some examples are the ’fitness function’ (for evolutionary algorithms), ’the reward function’ (for RLbased methods), and ’the cost function’ (for the dynamic optimization methods). Such functions are typically designed to include a high number of nonlinearities that best represent the important system characteristics based on the application. With regards to the space segment, an objective function can simply be any of the already mentioned metrics (i.e.,
$C/{N}_{0}$ for GNSS or LEOPNT applications as well as for high communication throughputs), some combination of them (i.e.,
$C/{N}_{0}$ and GDOP), or completely custom crafted as in [
20,
74]. As an example, we present Equation (13), which defines an objective function
$f\left(x\right)$ that combines the
$C/{N}_{0}$ and the launch cost
${C}_{launch}$ using some weights
${w}_{1}$ and
${w}_{2}$, where
x is the vector of the required parameters for the calculations. Note that in a typical MLbased method, these weights are finetuned by the optimization process, but they can also be tuned manually, which is typical for evolutionary algorithms.
6.8. Applicable Optimization Methods for Space Segment
Looking back at
Table 2, we can identify the commonly used constellation optimization methods as:
Bruteforce approaches, such as the MC method (typically used to evaluate constellation designs together with theoretical modeling approaches [
141,
142]);
MLbased methods [
22,
146];
Other methods: in addition to the abovementioned methods, there are also some advanced algorithms that have evolved from the previous ones, such as MOGA [
19] or HRPSO [
55], that combine the optimization process with analytical methods to improve or expand the optimization performance.
In the remainder of this subsection, we will provide overviews for the general versions of the most common methods.
6.8.1. Genetic Algorithm (GA)
GA, originally introduced in [
147], is an evolutionary algorithm that is used to find solutions to optimization problems, which relies on biologically inspired genetic operators: crossover, mutation, and selection. We provide the steps of the plain GA in Algorithm 1. However, it should be noted that numerous variants of GA exist, such as an expansion to the multiobjective optimization problems (MOGA [
52]) or the ones that follow specific operator criteria, for example, the selection criteria seen in NSGAII [
53], which we will cover in more detail at the ground segment.
Although we believe Algorithm 1 is sufficient as an overview, how to apply genetic operators in context can be confusing. To clarify what this means from a constellation optimization perspective, we provide the following example.
The population represents the collection of possible constellations, individuals represent particular constellations, and the genomes represent the parameters of a particular constellation. The crossover operation determines the parameter vectors of the offspring from the parameters of the parents, as per the biological counterpart. Thus, if we consider the genome consisting only of the altitude and number of satellites, the offspring would have the number of satellites from the first parent and altitude from the second. Following the crossover, the mutation operator introduces diversity to the population by mutating the genes of the offspring with some probability. Again, a very simple arbitrary example would be to have the mutation operator increase the altitude by 50 km with a
$40\%$ chance, reduce it by 20 km with a
$40\%$ chance, and have no changes with
$20\%$ chance.
Algorithm 1 GA 
Step 1: Population Initialization Initialize the population with N individuals, based on problem range and constraints. Step 2: Evaluate the Fitness Function Evaluate the value of the fitness (objective) function for each individual in the population. Step 3: Apply Selection Select individuals from the population using some selection criteria. A simple example is selecting randomly, but other selection metrics can be used depending on application. Step 4: Apply CrossOver Apply the crossover genetic operator to the parents (i.e., produce a total of $\frac{N}{2}$ offsprings from the parents, with parameters carrying over from either parent with some probability). Step 5: Apply Mutation Apply the mutation genetic operator to the parents and offsprings (i.e., change genomes of an individual according to some joint probability of the mutation happening, what parameter to change, and how it changes) Step 6: Termination Repeat steps 2–5 until a termination criteria is met (i.e., total iterations, change in optimality metric, etc.).

The last point of discussion regarding GA is the overhead of the method. While GA, like all the other evolutionary algorithms, requires a population that interacts with the environment (which naturally makes it an online method), it is typically applied to optimization problems via simulations in an offline manner. This is especially true in the case of constellation optimization, where parameters such as the number of satellites, the satellite inclination angles, etc., are almost impossible to modify once a satellite is launched on the orbit. As a result, the significance of the overhead comes from the required time and the computational complexity of the optimization method; both of which are primarily determined by the utilized software simulator and its computational complexity rather than by the optimization method itself. However, since an implementable optimization result obtained via GA will require a fairly complex simulation, the method’s overhead is difficult to generalize and must be examined case by case on a perimplementation and perscenario basis.
6.8.2. Particle Swarm Optimization (PSO)
PSO, originally introduced in [
50], is another popular evolutionary algorithm that iteratively optimizes a problem by improving upon candidate solutions with respect to given metrics. The set of possible solutions are called the swarm and particular candidate solutions are called the particles, which have position and velocity vectors for each dimension of the particle (which can be defined as parameters of interest). Each particle’s movement is influenced by both its individual best and the best within the swarm, which is expected to move the swarm toward an optimal solution.
Algorithm 2 summarizes the PSO algorithm, and we provide the velocity update equation in Equation (14) and the position update equation in Equation (15), both of which are given for particle
i and dimension
d.
t refers to time (or iteration),
${w}_{1}$,
${w}_{2}$, and
${w}_{3}$ are scalar weights,
v refers to the vehicle speed vector in 3D space,
$\mathbf{x}$ refers to the current position (vector form),
${\mathbf{p}}_{i}$ is the best known position of particle
i,
${\mathbf{p}}_{g}$ is the best known position in the swarm, and
$\left\right\xb7\left\right$ is the Euclidean metric or the distance between vectors.
Similarly with the GA, the PSO also have variants; the straightforward one is the expansion to the multiobjective optimization MOPSO [
54]. More complex improvements work by including extra heuristics or mathematical strategies to guide the particle’s through the search space in a more informed manner; an example seen in [
55] uses different resampling methods in a hybrid manner to achieve this, similar to particle filtering applications.
Algorithm 2 PSO 
Step 1: Swarm Initialization Initialize the swarm with N particles, based on problem range and constraints. Randomly initialize their positions and velocities within the search space. Step 2: Fitness Function Evaluation Evaluate the value of the fitness (objective) function for each particle in the swarm. Update the particle best and swarm best for each particle. Step 3: Position and Velocity Iteration Iterate the position and velocity of each particle according to the Equations (14) and (15). Enforce limits if any particle goes outofbounds of the search space. Step 4: Termination Repeat steps 2–3 until a termination criteria is met (i.e., total iterations, change in optimality metric, etc.).

As another evolutionary algorithm, PSO has almost identical overhead properties as GA. However, while the traditional PSO is typically faster to converge to a solution compared with GA [
148], it also has certain ’pitfalls’ that can prevent or significantly alter the required number of iterations to reach a solution (i.e., particles getting stuck in the local minimum or maximum).
6.8.3. Simulated Annealing (SA)
SA, while similar to evolutionary algorithms, is a metaheuristic algorithm that specializes in finding an approximation to the global optimal solution in large search spaces. It was originally introduced in [
48] and was inspired by the annealing procedure of metalworking. Similar to evolutionary algorithm counterparts, variants that expend the method exist, such as MOSA [
51].
SA is ideal for computationally hard optimization problems where exact algorithms prove infeasible; even though it only achieves an approximate solution, it is typically enough for many practical problems. In general, SA algorithms assume a system initialized with a positive temperature and a starting solution (represented by point
X, typically a vector of parameters of interest). At every iteration, the algorithm randomly (or heuristically, in improved versions of the algorithm similar to PSO variants) selects a point close to the current one and decides to accept it according to the acceptance criteria, which is typically a probabilistic objective function that depends on the system temperature. The system’s temperature gradually decreases, and the final solution is considered an approximation to the global optimal. We present the procedure in Algorithm 3.
Algorithm 3 SA 
Step 1: System Initialization Initialize the system with an initial temperature ${T}_{0}>0$ and generate a starting point ${X}_{0}$, which will also be initialized as the best known point ${X}^{*}$. Step 2: Move to Neighbors Check a neighboring point ${X}_{s}$ and decide if the neighbor is ‘better’ according to an acceptance criteria. The acceptance criteria must have some probability of accepting ‘worse’ neighbors related to the temperature of the system (highertemperature systems have a higher probability of accepting ‘worse’ neighbors). If the neighbor is accepted, move to it and assign ${X}_{s}={X}^{*}$; otherwise, stay in the current point. Step 3: Enforce Annealing Schedule Repeat Step 2 until an ‘equilibrium condition’ is satisfied (in practicality, this condition can be quite complex or very simple. For example; after a number of iterations, or after every point change). When this condition is met, decrease the temperature of the system and move back to Step 2. Step 4: Termination Repeat steps 2–3 until a termination criteria is met (i.e., total iterations, minimum temperature, etc.).

Overheadwise, SA is similar to both GA and PSO in the sense that it is typically applied in an offline manner while inherently being an online method. However, since the main strength of the SA method is finding an approximate solution to the global optimum when the exact methods fail, its time and computation properties are mainly an issue of feasibility rather than overhead. Typically, the overhead of the SA method is not a point of critical consideration when SA reaches an acceptable solution, which, in practice, is finetuned with the initial starting solution to shorten the computation time.
6.8.4. Theoretical Modeling and MLBased Approaches
Technically, theoretical modeling can also be seen as an optimization technique because it is included in steps that relate to the optimization process as a whole, such as a necessity in methods and metrics as criteria, as we have briefly touched upon in this section. Alternatively, they can be used as a system model, typically within simulations (i.e., a bruteforce approach, MC Optimization, solvers, etc.). Needless to say, it would not be possible for us to cover an extensive amount of models in detail, and covering examples makes little sense as they serve as optimization methods only for the particular case they model. Thus, we believe the models we include in our discussions with respect to the methods and metrics are sufficient to demonstrate the role of modeling in an optimization context related to the segments.
Similarly, MLbased methods are tricky and difficult to explain briefly, as the networks themselves are designed in a case basis. The study we have cited in
Table 2 with regards to ML is [
22], where the authors utilize a DNN to modulate and demodulate the signal at terminal and relay nodes to optimize constellations in twoway relaying with physicallayer coding. Regarding their work, the details are complex and are not suited for overview in this paper. However, we will provide an overview about the general NN structure in its stead.
An NN consists of layers, which are mathematical manipulations characterized by the neurons (or nodes) within the layer. A neuron is just a place where computation happens, inspired by the neurons in the human brain that fire when stimulated. In a neuron, input data matrix
X is multiplied by the weight matrix
W and is propagated through an activation function
$\Theta (\xb7)$ to generate the output matrix
Y:
This operation assigns significance to inputs with regard to the task the network is trying to learn and determines whether and to what extent that input should progress further through the network to affect the ultimate outcome. This process is called ’training’. While, in practice, it is limited by the available data, in theory, it does not terminate until the operation stops altering the weights used in the operation according to an optimality criterion (typically, a gradient descent is utilized for this purpose).
An NN layer is a row of such neurons that turn on or off according to their activation functions, as the input is fed through the network. Each layer’s output is simultaneously the subsequent layer’s input, starting from an initial input layer receiving the data. An extremely simple NN with only one layer is shown in
Figure 6 to serve as an example.
A DNN, as the name suggests, is a type of NN. The adjective ’deep’ refers to the use of multiple layers in the network. Typically, a DNN utilizes a very large number of layers but is a forward network. This means that the NN architecture does not loop or backpropagate. Other types of NNs utilize such architectures, such as a CNN or Recurrent Neural Network (RNN). We will cover the RNN variant in the ground segment; however, we will refrain from presenting an overview of the other MLbased optimization methods.
In the context of datadriven approaches (which includes NN and its variants), online and offline optimization refer to their counterparts in learning theories, namely the online learning and offline learning. Online learning indicates that the learning takes place as the data come in, while the offline learning indicates the existence of a static dataset from which the learning is performed. MLbased methods can be constructed to operate with either of the two learning methods, or, in many cases, simultaneously, with both methods. The learning method imposes additional constraints to the feasibility of the method (the obvious example being the computation time constraint for online learning case, which operates in realtime). As with the other complex cases, these additional constraints need to be taken into account when an implementation decision is made to use MLbased methods in practice.
6.9. Method Comparisons for the Space Segment
A comparison of the optimization methods presented in
Table 2 and explained throughout this section is presented in
Table 9 in terms of their applicability for LEO spacesegmentrelated optimizations. We compare the methods under three categories, which we loosely define as:
Convergence Speed: Overall performance in terms of the time it takes for the method to reach a solution and computational complexity. For datadriven methods, this roughly relates to how big of a dataset is required.
Global Convergence: Overall performance in terms of finding the global optima. Many methods can get stuck in a local optima, especially for complex optimization problems.
LargeScale Applicability: Overall performance in terms of how many different problems can be solved utilizing the method and how simple it is to formulate optimization problems (or find/create datasets) to use the method, with respect to the denoted segment.
An important remark is about the theoretical modeling: we intend for the method of theoretical modeling to represent our interpretations of the approach in general rather than the individual performance of models. As a result of this ’simplification’, the corresponding row in the table reflects the abovedefined categories as a generalization.
7. GroundSegment Optimization Aspects
The main optimization problem with respect to the ground segment refers to the optimization of the number and placement of ground stations all over the Earth in such a way that they are able to offer good monitoring, management, and control of all LEO satellites in the sky. However, currently, there are very few studies in open access describing optimization methods for LEO ground segments. In contrast, many such studies exist for MEO GNSS systems, and it is to be expected that some of the optimization mechanisms previously proposed for GNSS are also applicable in the LEO context. As a result, in this section, we will present the metrics and methods that have seen successful in either case.
7.1. Optimization Metrics Related to the Ground Segment
The study in [
149] looked at the coverage as the optimization metric in the context of Beidou GNSS and aimed at having the same satellite in view for a predetermined interval of time by at least four ground stations (thus, they called this metric a ‘quadruple coverage’ metric). Although the study compared only two deployments based on 18 ground stations each (thus, there was no complex optimization problem involved), it served as a good example of utilizing sky coverage percentage as a metric for the general optimization goal of maximizing coverage in GS planning.
The sky coverage is a metric such that it requires a mathematical model to operate with, which is typically constructed slightly differently depending on the objective of the analysis. In [
149], the authors defined it as
‘the percentage of observing time to a certain satellite by at least M stations within a specified time period’ and formulated it from the GS visible curve to the satellite using simplified geometric calculations.
The problem of finding the best location of a GS was addressed in [
150] in the context of MEO SatelliteBased Augmentation System (SBAS). The target metrics for the geographical location optimization were the scintillation fade depth, the GDOP, the number of visible satellites, the ionospheric delay, and the rainfall attenuation, which were all varying metrics indicating the signalavailability level. While the problem was formulated as a multimodal optimization problem, no final optimal solution was given, but rather a tradeoff criterion by criterion was presented.
The number of satellites and GDOP are related metrics; as the number of satellites in view increases, the value of GDOP decreases, which ensures good accuracy. In [
150], the authors followed the GDOP calculations from [
151] and used GDOP as the optimization metric. The GDOP is defined in Equation (18) based on the least square solution seen in Equation (17).
Above, $\Delta y$ is the position offset as obtained from the least squares solution of the linearized pseudorange measurement model of the system, H is the satellite geometry matrix, and $\Delta x$ is the net error in the pseudorange value. $tr(.)$ refers to the trace operation.
Note that, in order to formulate the set of equations whose least squares solution provides the GDOP, a modeling process is required that expresses the geometry between the users (for our case, this is the geometry between the GS and the satellite). In addition, modified versions of GDOP such as the weighted GDOP [
151] also exist, which include a weight matrix
W to the model, as in Equation (19).
Following the optimization metric definitions from [
150], the scintillation fade depth
$F{D}_{s}\left(p\right)$ at level
$\rho $ is calculated in dB, as summarized in Equation (20), where
${\sigma}_{s}$ is the standard deviation of the signal for a desired period,
$t\left(\rho \right)$ is the time percentage factor, and
$\rho $ is the percentage availability within the range
$0.01\%<\rho <50\%$.
For other optimization metrics from [
150], the authors utilized the model by Klobuchar (a detailed explanation can be found in [
152]) for the ionospheric delay and the International Telecommunication Union—Radiocommunication unit (ITUR) model for the rainfall attenuation.
Another groundsegment optimization problem was addressed in [
26] in the context of generic highthroughput satellites (with unspecified orbit altitudes) and using a machinelearning optimization via deep learning with Long ShortTerm Memory (LSTM). The principle in [
26] was to allow redundant ground stations (or gateways) in such a way that the effect of rain attenuation was mitigated during the groundtosatellite and satellitetoground communications. The rain attenuation was modeled by ITUR models in this study as well, and the optimization metric was the Carrier to Interference plus Noise Ratio (CINR), which is expressed in Equation (22) at a discrete sample (or time instant)
n and for the
ith gateway, where
${h}_{i}\left[n\right]$ is the wireless channel amplitude at sample
n for the
ith gateway,
${\sigma}_{s}$ is the noise variance for the groundtoair channel,
${I}_{i}$ is the interference level affecting each gateway site, and
${P}_{i}$ is the average transmission power.
Yet another groundsegment optimization in the context of optical groundtosatellite links was investigated in [
153], targeting the Link Outage Probability (LOP) as the optimization metric and considering three bruteforce methods and a fixed maximum number of ground stations (namely 66) with fixed locations. The optimization output was a subset of ground station locations that offer the lowest LOP, which is defined as a function of
Moutof
Navailability given by Equation (23), where
M refers to the smallest number of available GS required at a given time,
N refers to the total number of GS in the network,
${A}_{i}$ is the availability of
ith GS, and
${q}_{i}=1{A}_{i}$.
7.2. Applicable Optimization Methods for Ground Segment
Looking back at the stateofart methods from
Table 2 and the example studies from the previous subsection, which mostly utilize traditional methods for simple analysis, we can identify the main applicable optimization methods for the groundsegment optimization as NSGAII, LSTM, and Iterative Ground Station Deployment based on Marginal Revenue Maximization (IGSDMRM). In this subsection, we will provide an overview for these methods.
7.2.1. NonDominated Sorting Genetic Algorithm II (NSGAII)
NSGAII, originally introduced in [
53], is an improvement over MOGA [
52], which has three characteristics; i) it uses an elitist principle; ii) it uses an explicit diversitypreserving mechanism (called crowding distance); iii) it emphasizes nondominating solutions. We provide the steps of NSGAII in Algorithm 4. It is to be noted that the individuals that form the population are the possible solutions that we are interested in. For example, for the GS planning problem, a possible implementation is to define a GS network distributed randomly in the area of interest as an
individual; such
individual will be made up of a set of four vector parameters, namely the 3D position, the elevation angle, the number of GS, and the overall manufacturing cost. The parameters of an
individual are thus not limited to scalars only, but they can be vectors or a set of vectors themselves. Furthermore, as NSGAII is an advanced variation of GA, it has identical overhead properties with it.
Algorithm 4 NSGAII 
Step 1:Population Initialization Initialize the population withN individuals based on problem range and constraints. Step 2: Value Evaluation Evaluate the value of the objective function for each individual in the population. Step 3: NonDominated Sort with Crowding Distance Select $\frac{N}{2}$ individuals to be the ’parents’ in the next generation, according to the following criteria: a. Prioritize individuals with better nondomination criteria. b. Between individuals of similar nondomination criteria, prioritize individuals with lower crowding distance. Step 4: CrossOver Apply the crossover genetic operator to the parents (i.e., produce a total of $\frac{N}{2}$ offsprings from the parents, with parameters carrying over from either parent with some probability). Step 5: Mutation Apply the mutation genetic operator to the parents and offsprings (i.e., change parameters of an individual according to some joint probability of the mutation happening, what parameter to change, and how it changes) Step 6: Termination Repeat steps 2–5 until a termination criterion is met (i.e., total iterations, change in optimality metric, etc.).

7.2.2. Long ShortTerm Memory (LSTM)
LSTM, originally introduced in [
154], is a special kind of RNN that is particularly good at learning longterm dependencies within a system. All RNN have the form of a chain of repeating modules of NN. In a standard RNN, this repeating module has a very simple structure, such as a single
$tanh$ layer. The upper plot in
Figure 7 illustrates this structure, where
${x}_{t}$ is the input to the network at time
t and
${h}_{t}$ is the output of the network at time
t.
LSTM also has this chainlike structure as it is a RNN itself, but the repeating module has a different, more complex structure seen in the lower plot of
Figure 7. In the lower plot of
Figure 7,
x and
h are also the inputs and outputs of the network, respectively,
${C}_{t}$ is the cell state of the network at time
t,
$\Theta $ is a chosen activation function (typically the sigmoid function), the circular red elements represent component wise operations, and the rectangular yellow elements represent the network layers who perform operations according to Equations (24)–(29). In these equations,
f represents the output of the ’forget’ layer,
i represents the output of the ’input’ layer,
o presents the output of the ’output’ layer, and
$\widehat{C}$ represents the output of the cell state estimation layer. The variables
${W}_{\xb7}$ and
${b}_{\xb7}$ refer to the weight matrix and bias of the layer, noted by their subscripts (
$o,i,f,c$), respectively. The subscript
t refers to time, and the other subscripts
f,
i,
c, and
o denote the different layers, as explained above.
We remark that the Equations (26) and (29) use the $tanh(\xb7)$ operator only as an example of an output activation function to emphasize that such operator is typically a different one than the other layer’s activation functions. Any other activation function can also be used in its place for the output depending on the application, but $sigmoid$ and $tanh$ are typical for LSTM.
As for the overhead, studies such as [
155,
156] provide optimal LSTM designs that boost the performance and reduce the overhead for their cases of interest, but for the general purpose, it remains a necessity to perform per case evaluations as any other MLbased method.
7.2.3. Iterative Ground Station Deployment based on Marginal Revenue Maximization (IGSDMRM)
Unlike NSGAII and LSTM, which are relatively general and proven methods in the literature, IGSDMRM is a recent method proposed in [
27]. It is an iterative optimization method for the GS planning problem in the context of LEO satellite networks. The optimization goal is to maximize the system throughput capacity
${C}_{tot}$, which is defined by Equation (30), where
${C}^{UL}$ is the user link capacity,
${C}^{FL}$ is the feed link capacity, and
D is the capacity of the LEO network. The subsets
${s}_{m}$ and
${b}_{n}$ represent
${m}^{th}$ satellite and
${n}^{th}$ beam, respectively. Both
${C}^{UL}$ and
${C}^{FL}$ are calculated from Equation (31), where
${B}_{c}$ is the link bandwidth and
$M(.)$ is the mapping from SNR to spectrum efficiency under the DVBS2X transmission scheme.
The following steps summarize the IGSDMRM optimization procedure, adapted from [
27]:
 Step 1:
Divide the area of interest into smaller grids. In [
27], the authors divide the entire world into
${1}^{\circ}$ latitude by
${1}^{\circ}$ longitude and granularity grids.
 Step 2:
Calculate the traffic demands of the satellite. In [
27], the hotspot model is assumed for the traffic model, and the notation is such that
F denotes the traffic demand for the grid and
${F}_{s}\left({X}_{i}\right)$ denotes the traffic demand for satellite
s at position
${X}_{i}$.
 Step 3:
Calculate the marginal revenue for each possible GS deployment using the following:
Calculate the spherical distance between the satellite position and the GS, then calculate the corresponding geocentric angle.
Calculate the path loss, link budget, and spectrum efficiency.
Calculate the achievable link capacity.
Take the gridded revenue as $min(C\left({X}_{i}\right),{F}_{s}\left({X}_{i}\right))$
 Step 4:
Choose the location with the maximal marginal revenue as the GS deployment location.
As for the overhead, the original paper [
27] does not include a detailed analysis about computation complexity/convergence time for the method, so the literature is in need of more implementations that utilize IGSDMRM before we can provide a generalized insight on this aspect.
7.3. Method Comparisons for the Ground Segment
Finally, we compare the discussed optimization methods throughout this section in
Table 10. Note that we intend for the theoretical modeling entry to be a generalization for modeling and bruteforce approaches rather than as an indicator of the performance of particular models.
8. UserSegment Optimization Aspects
The user segment can be seen as the largest segment in terms of optimization challenges, as it has the highest number of metrics and parameters related to the system optimization, and they are highly scenario or applicationspecific. Even when narrowed down to the area of transportation and UAV, any optimization problem that involves a LEO satellite system is included in this user segment, and therefore, there is still a wide pool of optimization problems to be formulated and addressed. In this section, we present a few selected problems in order to focus on the user perspective, as previously presented in
Table 2, but it is also worth noting that we can also optimize some aspects of the LEO space and groundsegments from the usersegment point of view.
A concrete example is the satelliteselection problem when it is expected to have a huge number of satellites in the sky. This satelliteselection problem refers to the problem of selecting the best subset of available (or visible) satellites at the receiver in order to attain specific communication, positioning, or sensing targets. This problem relies on the hypothesis that having a bigger constellation does not directly mean one can achieve a better performance metric, for example, in terms of DOP [
5]. If the constellation is excessively large, the information provided by two or more satellites that are close to each other is highly correlated and thus not adding value when increasing the number of processed satellite signals, and we can consider that the satellite system would be overpopulated in such cases. In addition, the receiver processing complexity increases with the number of satellite signals to be processed; therefore, selecting the best satellites to process is important. In this case, the optimization problem becomes figuring out which of those satellites we have in view are most representative and, for example, which configuration would provide the best geometric distribution among other factors. We can optimize and select those satellites with the best score metrics (individually analyzed or combined) using the methods and metrics from
Table 2.
Figure 8 shows an illustration of this optimization from the user perspective in a GNSS scenario. In
Figure 8, the satellites in view depicted with a red circle are redundant (e.g., DOP contribution is bad, elevation is very low, etc.). Thus, the best approach would be that these satellites are not to be further considered, but only a subset of the available satellites (e.g.,the one with some high scores according to the defined performance metrics) is to be used for further processing.
In the rest of this section, we present various metrics and parameters that are used and/or adjusted in order to keep a good general performance of the system, and we present an overview of various optimization methods that have seen used in applications in recent years. This section addresses the optimization problems from the usersegment perspective.
8.1. Optimization Metrics Related to the User Segment
Of the metrics seen from
Table 2 related to the user segment, some of them have already been presented in previous sections; for example, we presented GDOP in Equation (18), which is also utilized in the user segment for the satelliteselection problem. Thus, we will present an overview of the metrics that have not yet been covered in the other segments here. We will also omit basic parameter metrics as the definition of the parameter is sufficient enough of an explanation for these metrics, such as the antenna elevation in satellite selection, travel time and distance in UAV data acquisition or latency, and the number of ping pongs in the handover planning.
It is best if we start with introducing metrics similar to GDOP that are not dependent on the models utilized in the system. One such metric is the TDOP, which is closely related to GDOP as another DOP metric. It is presented in Equation (32), where the notation from Equation (18) carries, and 4 refers to the fourth element of the trace vector, which represents time, thus the name. Other DOP metrics also exist in the literature, all of which are covered in earlier studies in detail, such as in [
157].
Another metric that is seen commonly in network performance evaluation is the Bit Error Rate (BER), which is a unitless metric that is defined as in Equation (33).
BER is a very simple error metric that simply looks at the error percentage in bits. Other similar metrics from
Table 2 that look at the error percentage of a particular parameter are the handover and failure percentages, which can be written in terms of Equation (33) by replacing bits with the parameter of interest. However, one should also note that these types of metrics can also be utilized together with models, as seen with BER in [
36].
A slightly different but very informative performance metric we still need to address is the Root Mean Square Error (RMSE), which is a widely utilized error metric in datadriven optimization approaches. RMSE is a comparative metric that provides a performance relative to something else; ML methods typically use a test dataset for this purpose, and in the case of using RMSE as a tracking error, it is simply the actual trajectory of the tracked target. We provide the RMSE calculation in Equation (34), and we also provide a similar comparative error metric called Mean Absolute Error (MAE) in Equation (35). In both equations,
n refers to the total number of data points,
${y}_{i}$ refers to the prediction in point
$i=1,\dots ,n$ (i.e., the output of a NN or the estimated point in trajectory), and
${x}_{i}$ refers to the true value in point
i (e.g., the labels of the data in a NN or the point in the real trajectory for tracking). More examples of comparative error metrics can be found in the literature, for example, in [
158].
As for the other metrics that include models, the user segment also utilizes coverage as a metric, which we have discussed in the space and ground segments. Another such metric is the network energy calculation for the UAV data acquisition problem. We will provide an example by following the network energy consumption model from [
36], where a wireless sensor network is optimized and energy consumption is one of the three major metrics utilized. In [
36], the authors model the total energy consumption of the network as in Equation (36), where
${E}_{ij}$ refers to the energy consumed for communication between node
j and the channel head node
i,
${E}_{iu}$ refers to the energy consumed for communication between the UAV node
u and the channel head node
i, and
N refers to the total number of channel head nodes.
${E}_{ji}$ is modeled as in Equation (37), where
${P}_{{t}_{ji}}$ is the transmit power and
${R}_{ji}$ is the bit rate of the communication channel between node
j and channel head node
i.
${E}_{iu}$ is modeled similarly as in Equation (38) but between channel head node
i and the UAV node
u.
Lastly, a more arbitrary metric could be the overall complexity of a design. Given a satellite selection problem from the point of view of the user receiver, a first approach could be trying to reduce the complexity by reducing the number of satellites being tracked. In this sense, we can make use of DOP metrics such as GDOP and TDOP, received power strength such as $C/{N}_{0}$, or even simple parameter metrics, such as the satellite elevation from the user location, to optimize the number of satellites to be tracked.
In the literature, we can find some studies that utilize a similar idea but are typically applied to GNSS scenarios. For example, in [
159], the authors proposed a DOP optimization based on TDOP, in which the subset of satellites with the best TDOP were used for obtaining the PNT solution. In [
160], the authors proposed a method called the ‘QuasiOptimal Technique’, in which more than four satellite DOP measurements are considered to optimize the satellite subset selection. The authors in [
161] proposed a less computational intensive method compared to [
160] but using a similar approach. In [
162], the authors propose a weighted leastsquaresbased DOP algorithm. The algorithm uses different metrics, besides the DOP, in order to weight the final optimal subset of satellites. In [
163], the authors propose a bruteforce method, in which they compute DOP metrics for the different subsets of all satellites in view and take as the optimal subset those satellites with the lowest DOP metric. Finally, in [
164], the authors analyze the optimal number of satellites to be selected until the DOP metric becomes saturated. Thus, including a higher number of satellites does not improve the metrics significantly.
8.2. Illustrative SimulationBased Examples
In order to show examples of some of the metrics described in the previous subsection, we have carried out some simulations with specific LEO constellations. Oneweb and Starlink LEO constellations were selected as more representative and promising among the future LEO megaconstellations.
Figure 9 shows the coverage map for these two LEO constellations considering two different elevation masks,
${10}^{\circ}$ and
${50}^{\circ}$, respectively. Moreover, the average number of satellites in view in the whole Earth is also shown. We notice from
Figure 9a,c that, in both OneWeb and Starlink constellations, when a small elevation angle is considered (e.g.,
${10}^{\circ}$), the average number of satellites in view is very large, with more than 100 and more than 300 satellites in view for Oneweb and Starlink, respectively. These values were obtained considering the designed planned constellations, which will be operative in the coming years. The planned constellations are designed for having 7808 and 34,404 for Oneweb and Starlink, respectively, distributed at different altitudes and orbital planes configurations, with a Walker star constellation topology. The visibility conditions were configured as those satellites with a higher elevation angle than the chosen elevation masks (i.e.,
${10}^{\circ}$ or
${50}^{\circ}$) from the userlocation perspective. In addition,
${10}^{4}$ Earth user locations were considered for all the simulations in
Figure 9,
Figure 10 and
Figure 11. To better model the orbits, a Simplified Deep Space Perturbation model (SDP4) [
165] was used along with the Matlab Satellite Communication Toolbox. The SDP4 model accounts for the effects of the oblateness of the Earth and atmospheric drag effects in the satellite orbit, among other effects.
Figure 10 depicts DOP metrics, namely GDOP, Position Dilution of Precision (PDOP), TDOP, Vertical Dilution of Precision (VDOP), and Horizontal Dilution of Precision (HDOP), for Oneweb and Starlink constellations. From
Figure 10, we can observe that both constellations offer a similar DOP performance. GDOP is <1 for both Oneweb and Starlink, respectively, but only when considering a low elevation mask (e.g.,
${10}^{\circ}$). If the minimum elevation to consider visibility is increased, the amount of satellites contributing to the measurements is largely decreased, as well as its spatial diversity, negatively influencing to these DOP values. For example, GDOP measurements considering a high elevation mask (e.g.,
${50}^{\circ}$) become approximately 12 in both constellations. The rest of DOP metrics are kept below 1 in both cases with a low elevation mask and much larger considering a high elevation mask. DOP metrics are examples of optimization metrics that can be inserted in usersegment optimization.
Finally,
Figure 11 shows the
$C/{N}_{0}$ probability distribution function for Oneweb and Starlink LEO constellations, respectively.
For the simulations, we considered a rural scenario with a Line of Sight (LOS) condition. This means that direct vision between user receiver and satellites was achieved, as well as low density of scatters and multipath components. To simulate a realistic satellitetoground channel in the described scenario, we used the freely available QuaDRiGa [
166,
167] framework. This channel model is a Matlabbased software developed by Fraunhofer HHI that enables the modeling of radio wireless channels by generating realistic radio channel impulse responses. The specific parameters the software uses to simulate the satellite channel models are described in [
168], which, in turn, are modified versions of ThirdGeneration Partnership Project (3GPP)/ITUR channel models.
From
Figure 11, we can observe that the received
$C/{N}_{0}$ from OneWeb satellites is about 5 dB lower with respect to the Starlink constellation. Oneweb typical
$C/{N}_{0}$ is about 45 dBHz, while Starlink is 50 dBHz. The
$C/{N}_{0}$ levels are mainly influenced by: (i) the carrier frequency used by each constellation and (ii) the altitude of the orbit. Even though both constellations use a similar carrier frequency, in Kuband (e.g., 12 GHz), their orbital altitude and orbital configuration is different. While Oneweb satellites are to be at altitudes of about 1200 km, Starlink satellites are to be distributed in orbits closer to the Earth, between 300 km and 600 km, thus offering a better link budget than those placed at higher altitudes. This is the main reason for the difference between
$C/{N}_{0}$ levels; nevertheless, the
$C/{N}_{0}$ distributions, as seen from the histograms in
Figure 11, are very similar, and they resemble an exponential distribution. Such information can be incorporated into an optimization problem, for example, by imposing the constraint of a minimum desirable
$C/{N}_{0}$ at any Earth point or in a target region.
As we have seen in
Figure 9,
Figure 10 and
Figure 11, we have many different metrics that can be used from the user perspective to optimize those satellites contributing more and in a better way to the final PNT solution.
8.3. Applicable Optimization Methods for User Segment
Besides the overlapping methods that we have already explained in
Section 6 and
Section 7,
Table 2 identifies the main applicable optimization methods for our selected problems in the user segment as ML, RL, MultiAgent Reinforcement Learning (MARL), and KF, as well as the more traditional approaches, such as search methods based on modeling and routing algorithms (Dijkstra, A*, etc.). In this subsection, we will provide an overview of these methods with the exception of the MLbased approaches (including RL and MARL), which are too complex for us to provide a brief mathematical overview in this paper. Although we will include these methods in our comparison discussions, for details regarding those methods and how they can be used with regards to the user segment in LEO networks, we encourage readers to refer to the cited studies [
30,
32,
41,
42].
Before we start with the optimization methods, it is worth briefly talking about some traditional methods. Although not exactly methods of optimization, some traditional methods are still used to address some of the problems we included in
Table 2, at the very least, as a reference for more complex methods. Such a method is the ’Elevation Method’, which is a simple and straightforward method of satellite selection in the user segment. The method sorts the satellites using their elevation angles and keeps the
n satellites with the largest values. If there are more satellites above the mask than there are tracking channels, the lowest elevation satellites are excluded. While such a method of removing the lowest satellites can increase the DOPbased performance metrics, it lacks other important factors, such as satellite health or weighting factors. Simply looking at the elevation angle discards the possibility of using these additional metrics. Similarly, the ’Longest Period Method’ focuses on the visibility of the satellites and chooses the one with longest time spans, which contains almost all of the negatives associated with the elevation method but with different metrics. Other methods, such as the ’Downdate Method’ proposed in [
31] or the method utilized in [
29], combine some of the traditional ideas together, such as applying a greedy search metric to the ranking idea of these traditional methods.
8.3.1. Kalman Filtering (KF)
KF, first introduced in [
59], is an estimation method that uses a series of measurements observed over time and estimates the unknown variables within the system by estimating a joint probability distribution over the known variables for each time frame. It requires a dynamical system model represented by two equations: a state Equation (39) and an observation Equation (40).
In the above equations,
F represents the state transition matrix,
H represents the observation matrix,
B is the control input model,
${x}_{k}$ is the state vector
${z}_{k}$ is the observation vector,
${w}_{k}$ is the system noise vector,
${v}_{k}$ is the observation noise vector, and
${u}_{k}$ is the control vector. The subscript
k denotes the iteration number (or alternatively, time or sample).
We provide the steps of the linear KF process in Algorithm 5, where notation from the state and observation equations carry over, and $\widehat{x}$ is the predicted estimation vector, $\widehat{P}$ is the estimated covariance matrix, R is the covariance matrix of the measurement noise, and Q is the covariance matrix of the process noise.
If the system represented by Equations (39) and (40) are not linear or the noises are not Gaussian, the process seen in Algorithm 5 requires modifications, which is where the modified KF methods, such as EKF and UKF, emerge.
Algorithm 5 KF 
Step 1: Initialization Initialize the parameters of the state and observation models given in Equations (39) and (40) (initial states, observations, matrices, noises, etc.). Step 2: Predict State and Covariance ${x}_{k}=F{\widehat{x}}_{k1}$ ${P}_{k}=F{\widehat{P}}_{k1}{F}^{T}+Q$ Step 3: Compute Kalman Gain (K) $S=H{P}_{k}{H}^{T}+R$ $K={P}_{k}{H}^{T}+{S}^{1}$ Step 4: Correction ${\widehat{x}}_{k}={x}_{k}+K(zH{x}_{k})$ ${\widehat{P}}_{k}={P}_{k}+KH{P}_{k}$ Step 5: Termination Repeat steps 2–4 until a termination criterion is met (i.e., total iterations, change in optimality metric, etc.).

Both EKF and UKF apply a linearization step to
H and/or
F matrices before the equations in steps 2–4 of Algorithm 5 are applied to address this issue. In the case of EKF, the nonlinear matrix
H is approximated via a Taylor series expansion about the estimated state vector, as in Equation (41), where the notation from Equations (39) and (40) carries over.
In the case of UKF, an unscented transformation is applied, as seen in Equation (42), where
${\chi}^{v}$ are the sigma points describing the measurement noise and
${\chi}^{x}$ are the sigma points describing the prior predicted states.
${n}_{x}$ is the number of weighted samples, which is chosen as a sum of the number of process states and the dimensions of
${w}_{k}$ and
${v}_{k}$. Again, notation carries over from Equations (39) and (40).
While KF can be used as an offline or online algorithm depending on what the optimization objective is (i.e., what the system model from Equations (39) and (40) represents), in practical applications concerning autonomous vehicles, it is typically used in an online fashion. Although not always in the LEO context, the most common examples of KF implementations in the field of autonomous vehicles are sensor fusion [
169] and/or trajectory tracking [
170]. The method typically does not consume significant resources from the system and adds negligible delay to the operation; thus, it remains a highly utilized method, although not always for optimization but rather as a method for estimation, tracking, etc.
8.3.2. Search Methods
Search methods are optimization calculations or algorithms that are employed to solve a search problem to varying degrees of optimality. There are a vast number of such methods, but we will do our best to give overviews for the commonly used ones with respect to the user segment problems seen in
Table 2.
We start with some bruteforce methods. Continuing with the satellite selection problem, an ’optimal’ bruteforce method would be to look at all possible combinations of
k out of
n satellites to determine the best performance. Such bruteforce methods are optimal in terms of returning the best possible outcome but are distinctly nonoptimal in terms of overhead, i.e., computational cost and time. If there were
n healthy satellites above the mask, a receiver with
k channels would have to evaluate
${N}_{opt}$ geometries, where
${N}_{opt}$ is given by a simple combination, as shown in Equation (43). However, it is easy to see that the number of geometries to evaluate can quickly become infeasible as
n and
k change.
Another bruteforce approach is to utilize a greedy heuristic to make the combination more feasible. This ’Greedy Search’ method is similar to the optimal, but the difference is that instead of calculating all possible combinations, the search focuses on the best subset of a chosen satellite, iterating over all the satellites. For an example, if we take an initial case with
$n=10$ satellites, all subsets continuing 9 satellites are calculated first, and then the one with the best metric is selected to continue evaluating another subset of eight satellites. This results in an improved speed over the straightforward combination calculation, but it runs the risk of missing the global optimum. In addition, the overhead may still remain nonoptimal.
More sophisticated search methods are typically employed to solve problems related to network routing optimization, which can be formulated as shortest path problems. The first algorithm we would like to introduce is the wellknown ’Dijkstra’s Algorithm’, originally introduced in [
46] to find the shortest path between two given nodes. Nowadays, the common variant finds the shortest path from a ’source’ node to all the other nodes in the network. We provide the steps in Algorithm 6.
This algorithm can be seen as a brutesearch type of algorithm as it typically ends when the entire network is known (therefore, the overhead remains at the nonoptimal levels). However, it can also be coupled with models depending on the available information about the network and how accurate its cost calculation and dynamic model is.
Algorithm 6 Dijkstra’s Algorithm 
Step 1: Initialization Given the network graph, assign a cost value to every node in the network; the cost value of a node is the total cost value of the shortest path discovered so far between that node and the source node. Initially, this means 0 for the source node and inf for all other nodes. Furthermore, create a list for unvisited nodes and initialize it with all the nodes in the network. Set the current node as the source node. Step 2: Calculate Cost to Neighbors For the current node, consider all of its unvisited neighbors and calculate their cost values through the current node. Compare the newly calculated cost to the current assigned value and assign the smaller one. Step 3: Update Current Node Remove the current node from the unvisited list and assign the neighbor with lowest cost as the current node that is in the unvisited list (a visited node will never be checked again). Step 4: Termination Repeat steps 2–4 until a termination criterion is met (i.e., destination node is found, all routes in the network are known, etc.).

Another wellknown algorithm is the ‘A* Search Algorithm’, which is a very similar algorithm to Dijkstra, except it includes a heuristic while selecting which nodes to explore next. As we have shown in Algorithm 6, Dijkstra decides which node to explore next based on the path cost. If we define the path cost from the current node to node
n as
$g\left(n\right)$, then the decision function
$f\left(n\right)$ can be written as in Equation (44) for Algorithm 6.
To employ the A* Search instead of Dijkstra, this decision function must be modified, as seen in Equation (45), where
$h\left(n\right)$ is some heuristic function, for example, a state value function, or a greedy function.
The general advantage of A* over Dijkstra is that as it uses a heuristic to select the nodes to explore, it is significantly faster than Dijkstra, which results in a more optimal overhead. However, as a result, its ability to find the global optimum is dependent on the heuristic function’s ability to represent the real network.
8.4. Method Comparisons for the User Segment
Finally, we compare the discussed optimization methods throughout this section in
Table 11, similar to the way we did in
Section 6 and
Section 7. Note that the traditional and search methods entries are generalization terms that do not refer to the individual performance of the methods but to our interpretation of the overall performance of similar methods that utilize the same type of approach with varying success.
9. Design Recommendations
In this section, we compile our comparisons of the methods from
Table 9,
Table 10 and
Table 11 in order to provide general recommendations for the optimization problems related to each LEO segment when having the application class of autonomous vehicles in mind. Our design recommendation can serve as a basis for the future design of LEObased networks to meet the stringent requirements for autonomous transportation, as listed in
Table 4.
Regarding the space segment, the current studies show that the best tradeoff between various performance metrics can be achieved with the evolutionary algorithm variants (such as MOGA and MOPSO), as well as with MLbased approaches, such as constructing an DNN for the optimization problem, given a good dataset that represents the system high dynamics. However, specifically for the space segment, MLbased approaches seem to be a scarce case in the literature, which we attribute to the lack of available quality data regarding constellation optimization. As a result, we recommend focusing on the evolutionary algorithms, where the dominated methods are between GA and PSO variants that make use of smart modifications to guide the methods through the search space.
In terms of the groundsegment optimization, our literature review has shown that LSTM typically provides the best solution for the majority of applicable cases, followed by NSGAII. Regarding the drawbacks of LSTM, as with most other datadriven approaches, its performance highly depends on the availability of a good training dataset that is able to reflect the main characteristics of the optimization problem at hand. In reality, such a quality dataset might not be easy or feasible to acquire. Therefore, our design recommendation for groundsegment optimization is to use NSGAII optimization engines, providing a good tradeoff between different performance metrics. Indeed, in terms of performance, NSGAII is not far behind LSTM, but since it does not depend on available training data, its application range is wider than the one of LSTM, and it is, in our opinion, more suitable for the application areas relying on stringent requirements, such as those from autonomous transportation. That being said, NSGAII performance is heavily affected by the choice of the algorithm criteria, such as the probability models related to genetic operators, but fairly accurate models can be found in the literature and are relatively common.
As for the user segment, it is difficult to provide meaningful generic design recommendations, as this is the segment with the most amount of challenges and possible applications, as well as the segment most heavily affected by the nature of the abovementioned problems or applications. We have provided different illustrative examples for characterizing the usersegment performance, e.g., based on $C/{N}_{0}$ or based on the average number of satellites in view by a terrestrial autonomous vehicle, and these can be used as a starting point for further exploration. In addition, the areas of applications from the usersegment point of view comprise communication, sensing, and navigation domains, with typically contradictory criteria to meet (e.g., wide receiver bandwidths and high carrier frequencies are highly suitable for highthroughput applications, while narrow bandwidths and smaller carrier frequencies are better for good link budgets and navigation applications in heavy urban or indoor scenarios).
There are two general notes we would like to add on top of our recommendations in the previous paragraphs. The first is about the modeling part; as it should be apparent from explanations in
Section 6,
Section 7 and
Section 8, underlying theoretical models are needed and included in most steps of all methods, at the very least in the evaluation metrics. Thus, it is a logical conclusion that there will be models that will influence the results in an equal or higher manner than the influence of choosing a particular optimization method in a per case basis. However, creating generic models is again a challenging issue, especially in problems with conflicting goals, such as most multiobjective multimodal problems, as the modeling parameters are typically hard to tune simultaneously in an optimal direction. This is one reason why optimization methods are widely utilized while still depending on partial or simplified models of the problems they are optimizing.
The second note is about MLbased methods, which include, for example, the NN and RL methods in
Figure 3. It is important to remember that, despite their largescale spread in the literature in all kinds of applications and problems, ML methods are still considered mostly ’black box’ models, which means that, while we are able to reliably explain ’what’ works in such models, we rarely have sufficient explanations to ’why’ or ’how’ they work, and the reproducibility of results cannot be automatically ensured. Due to this, they are very difficult to reproduce, which can lead to complications if applied in largescale realworld applications and, in particular, for LEO system design for autonomous transportation applications.
10. Conclusions, Open Directions, and Future Studies
Our paper gave a broad overview of the optimization methods that can be used in the context of LEO system design for communication, navigation, and/or sensing applications within the future autonomous transportation applications. The optimization methods were presented both at a general level and segmentbysegment, following the threesegment architecture of most satellite systems (namely space, ground, and user segments). We have thoroughly identified the optimization metrics and constraints at each of the segments, and we compared various optimization methods in terms of their complexity, convergence characteristics, and feasibility. We have shown that the typical optimization issues in the LEOsystem design context are complex, multiobjective, and multimodal optimization problems, and therefore, they are to be tackled separately, segmentbysegment, with the target application criteria in mind. The targets in the context of future autonomous vehicles are stringent, as depicted in
Table 4, and they can be reached with a combination of various complex optimization mechanisms, such as ML or PSO for the space segment, LSTM or NSGAII for the ground segment, and a scenariodependent optimization approach for the user segment. However, for the sake of higher control and reproduction of the results, it is our view that MLbased approaches are not the bestfittoproblem in the context of LEO system design for autonomous vehicles, especially for safetycritical transportation applications, and therefore, methods such as PSO or NSGAII are to be preferred.
In addition to the segmentspecific optimization tasks addressed here, we have mentioned various other issues, such as space debris, standardization constraints, and security targets, which can be further incorporated as optimization boundaries, but which are too broad to be inserted in a single optimization problem.
While our paper has covered a broad area of LEO design aspects, issues such as physicallayer optimization (e.g., modulation, channel coding, and carrier frequency choice), medium access control (e.g., multiaccess control scheme and joint multiaccessphysical layer optimization), network routing aspects, or security aspects have not been addressed in detail and remain a matter of future investigation.
Furthermore, as future directions, there is currently a dichotomy of approaches regarding communication, sensing, and, especially, positioning applications with LEO signals: on one hand, one could use any of the existing systems (e.g., such as those listed in
Table 7) as signals of opportunity or as a basis for offering novel services to the end users; on another hand, one could design completely new systems, such as the ongoing efforts towards a LEOPNT concept. In the former case, the burden of the optimization problems will stay mainly within the receiver (thus at the usersegment part) because the infrastructure is assumed to be already deployed; in the later case, a threesegment optimization is needed in a joint or disjoint (segmentbysegment) manner.
Interesting new research directions in this domain comprise the integration of LEO and MEO solutions, such as a GNSS receiver onboard LEO satellites to better support the PNT targets, integration of cellular (5G, SixthGeneration of Cellular Networks (6G)) networks with LEO networks, the use of RL other ML approaches for increased security in the wireless communication and navigation links, beamformingbased positioning via ML, and LEObased edge computing.
Our future work will focus on designing novel LEOPNT constellations by applying the identified segmentbysegment optimization methods in order to achieve improved accuracy for indoor and denseurban positioning of devices with global coverage.