Content uploaded by Franco Criscola
Author content
All content in this area was uploaded by Franco Criscola on Mar 02, 2023
Content may be subject to copyright.
AAS 23-174
DEVELOPMENT OF A SIMULATOR FOR COVERAGE PLANNING
OF A 6G/IOT CONSTELLATION
Franco Criscola*
, Arnau Singla†
, Elena Ponce‡
, Anna Calveras§
, Joan A.
Ruiz-de-Azua¶
, and David Canales||
The uprising of 6G/IoT low-Earth orbit satellite constellations in the last
decades has brought on challenges in designing an efficient way to handle
its operation. The objective of this paper is to present a solution to this
management problem and showcase an important component of this solu-
tion: an orbital simulator. This algorithm aims at accurately propagating
the motion of the spacecraft while simultaneously computing the interac-
tions between the satellite and various entities, including users, ground
stations, target areas, and the Sun. These results are then used by a second
component, the scheduler, so that a task plan is developed.
INTRODUCTION
Since the beginning of the space era post-World War 2, low-Earth orbit (LEO) has been at
the frontier of exploration in the hands of government agencies (e.g. NASA, ESA, JAXA,
etc). However, in the past three decades, the cost and risk of launching spacecraft (s/c)
have decreased, and huge interest in LEO has emerged from privately-owned corporations;
interest in the form of telecommunications.1This influx is correlated to the numerous ad-
vancements in technology seen since the beginning of the 21st century, many of which have
come from the space sector itself. More recently, improvements to the current Internet
network have gained popularity amongst researchers due to its relatively stagnant growth.
Ground networks have not caught up to the rapid development of advanced technologies,
while even more groundbreaking research is occurring for 6th generation networks (6G).2
The rise of 5G and the Internet of Things (IoT) has been, for lack of a better word, revo-
lutionary, and has left behind the preexisting foundations of telecommunications, leaving
*PhD student, Aerospace Engineering Department, Embry-Riddle Aeronautical University, Daytona Beach,
United States.
†PhD student, Space Communications in i2CAT Foundation, Universitat Politecnica de Catalunya, Barcelona,
Spain.
‡School of Aeronautics and Astronautics, Purdue University, West Lafayette, United States.
§Associate Professor, Network Engineering, Universitat Polit`
ecnica de Catalunya, Barcelona, Spain.
¶Director of Space Communications Research Group, Space Communications in i2CAT Foundation, i2CAT,
Barcelona, Spain.
||Assistant Professor, Aerospace Engineering Department, Embry-Riddle Aeronautical University, Daytona
Beach, United States.
1
companies in search of solutions.3Solutions that come in the form of Non-Terrestrial Net-
works (NTN).2, 4
Non-Terrestrial Networks integrate with current terrestrial systems to promote global
connectivity with a three-dimensional architecture that combines terrestrial networks with
NTNs. A typical structure of an NTN is represented in Figure 1. These NTNs are com-
posed of elements in varying altitudes, from airplanes and high-altitude balloons, to LEO
satellites and beyond.5They are particularly useful in high traffic areas, such as densely
populated cities, and on the opposite end of the spectrum where regions of the globe lack
the infrastructure to communicate with the existing networks.3The main idea behind an
NTN is for a user to connect to the closest node, which then passes on information to other
nodes if necessary until the service or network provider is reached.3
Figure 1: Non-terrestrial network structure.5
The subject of this paper is an NTN composed of s/c. These elements of the network
are generally developed using current technologies like large Geosynchronous Equatorial
Orbit (GEO) satellites. Unfortunately, this method creates high latency due to its far dis-
tance from users and ground stations, defeating the purpose of a high speed 6G network,
and creates high cost for the companies attempting to create such a network.6The altitude
of the orbit may be decreased, which creates problems like ”dead-zones”, but this could
furthermore be fixed by increasing the number of satellites and creating an interconnected
network of satellites called a Distributed Satellite System (DSS).1,7 Moreover, increasing
the number of satellites requires s/c mass and size to decrease to stay within project budget.
The result is then a large constellation of small and cheap satellites in LEO interconnected
by a network with one objective. However, designing such complex systems causes previ-
ously unseen issues, such as inefficient constellation planning.8Increasing the size of the
2
DSS and lowering the orbit means that the coverage time of satellites on particular areas,
like ground stations and areas of interest, decreases substantially.9Thus, satellite operators
lose the ability to manually command the s/c’s link to a ground station. It is then necessary
to automate this process by creating an optimized and generalized management tool, so that
each s/c autonomously creates its own schedule in such a way that no satellite performs the
same task simultaneously, every region of interest has connectivity to the DSS, and every
constellation that uses the tool adapts it to fit its needs.9To optimize the administration
of these satellite networks, this paper presents a tool, denominated Constellation Manage-
ment System (CMS), that consists of two main parts: a simulator and a scheduler. This
investigation focuses on the former.
Currently, several constellation management tools exist10–13 that are used to optimize
task plans. However, they all lack a few key properties:
• Easy customization.
• Versatility for different applications: current state of the art is focused to a constella-
tion type and mostly about Earth observation.
• Easy to upgrade.
Due to the above mentioned characteristics, there is a gap that this investigation attempts
to fill. A goal for this tool is to work independently from any other software. Usually,
conflicts arise between the scheduler and the chosen orbital simulation software. There are
multiple orbital simulators that are currently used in the commercial and educational envi-
ronments.14 These are generally closed source, and hence require a purchase and training to
use. Similarly, their general purpose characteristics create problems when trying to merge
them with other software. As such, the simulator used for the CMS is designed indepen-
dently as an algorithm to be built specifically for constellation management. This enables
for easy combination of the two modules of the CMS: the scheduler and the simulator.
The role of the simulator is to receive telemetry from satellite handlers, called operators,
and propagate the motion of the s/c for a certain period of time. This telemetry, or state,
includes s/c position, velocity, and attitude. The software then computes the windows of
coverage (WoC) for desired events, namely Sun-charging and battery charge generation,
ground station (GS) visibility, user equipment (UE) visibility, and target area (TA) visibil-
ity, taking into account the field-of-view (FOV) of the various entities and attitude of the
satellite. These windows represent the start and end times of a particular event. Once all
WoC are determined, they are passed on to the scheduler, which creates an optimized task
list and calendar for each satellite in the constellation. The scheduler is outside the scope
of this paper, but a more detailed description, including results and discussion, is found in
a complimentary paper.15 Ground stations and UEs are specifically related to 5G/IoT con-
stellations, but other types of entities can be input into the software for other uses, such as
Earth observation. The coming sections first introduce the state of the art of management
tools, as well as the disadvantages of using existing simulation engines in this particular
context. Then, the algorithms designed for the CMS are presented, giving emphasis to the
3
self-check procedures designed to test this new software. These methods include double-
checking the propagation method employed and the WoC computation by using already
proven software. A detailed showcasing of the simulator is shown, alongside results ob-
tained from using an example constellation and a prototype CMS. Lastly, a short summary
of this paper is presented for the reader’s convenience.
STATE OF THE ART OF CONSTELLATION MANAGEMENT TOOLS
With the advent of satellite constellations in the late 20th and early 21st centuries, engi-
neers and researchers have known of the giant logistical problem that large constellations
create. This started with Iridium,16 a privately operated telecommunications constellation,
but has been a constantly reoccurring challenge for operators because each constellation de-
signed is different, with varying number of satellites and functionality, hence constellation
managers tend to design tools uniquely tailored for their own satellites.17 In most cases,
these organizations, federal or otherwise, have developed management tools for their spe-
cific constellations to plan and schedule tasks. Some examples include:
• The Automated Planning/Scheduling Environment (ASPEN)10 created by NASA as
an automated planning tool, designed to be for use of generic independent satellites
for EO purposes.
• The Advanced Planning and Scheduling Initiative (APSI)11 established by ESA to
provide a framework for future growth of AI technologies in scheduling.
• The Extensible Universal Remote Operations Planning Architecture (EUROPA)12
also initiated by NASA as a manual planner and analyzer.
• The Distributed Spacecraft Coordination Planning and Scheduling (D-SpaCPlanS)13
developed for the privately owned Iridium constellation by Stottler Henke Associates,
Inc, and a few others designed for EO satellites.18
The aforementioned tools tend to be exclusive for the organizations that developed them
or for the constellation and use it was built for. Few have the capability of being open to
any entity that wants to use the tool. Thus, it appears that, although lots of research and
investment have gone into the development of management and planning tools, none have
gone to develop such tools standardized for telecommunications.
STATE OF THE ART OF SIMULATION ENGINES
It may seem somewhat redundant to design a brand new orbit simulator when other
options already exist. Two of the most well-known software include NASA’s General Mis-
sion Analysis Tool (GMAT) and AGI’s Systems Tool Kit (STK).14 Specifically, STK has
been previously applied in a similar context regarding NTNs, where connectivity to ground
stations was studied and analyzed using the software,19 and both GMAT and STK can accu-
rately and reliably simulate orbital motion. These are proven software used by companies
4
throughout the world in commercial applications, however they lack a few necessary prop-
erties needed in this project. The simulator for the purposes of this investigation must have
the following characteristics:
• Simulator and scheduler must be able to effectively communicate with each other.
Thus, the programming language must be compatible for both.
• Using advanced, non-specific user interfaces presents an issue, as merging the simu-
lator and scheduler will require a third party to connect both algorithms.
• Using closed-source software requires licensing and installation of software which
may not be available for potential users.
• A key property of the simulator must be its easy upgrade-ability and customize-
ability with other parameters, including but not limited to battery state computation,
inter-satellite links, FOV propagation, and most importantly non-numerical propaga-
tion methods, for instance machine learning techniques.20
Due to the aforementioned issues, it appears ideal to create an independent, open-source
simulator that smoothly integrates with the scheduler and be upgraded with any new prop-
erties or developments that may be desired. This fact opens the door for advanced machine
learning algorithms to replace the numerical propagators, as is discussed in a later section.
CONSTELLATION MANAGEMENT SYSTEM
The CMS is designed to be flexible and modular. The goal is for it to be able to adapt
to any future 6G/IoT constellation with different applications as well as be completely
automated and upgrade-able. This is particularly beneficial for when higher-level artificial
intelligence (AI) and machine learning techniques are developed to work alongside the
current system. The sections below briefly describe the architecture of the CMS as a whole
and branch off into the focus of this investigation, the simulator. Figure 2 shows the general
architecture of the CMS.15 The dotted-line boxes represent user, control, and operation data
transfer between nodes, which include ground stations (GS), user equipments (UE), the
NTN, and the customer. Ground stations are defined as entities that enable communication
between the s/c and the Core Network (CN), which in turn communicates with the Mobile
Network Operator (MNO). User equipments are entities that transfer user data to the s/c.
The Mission Provider (MP) is the entity that control the satellites via operation data. The
final data type, control data, is necessary for operation of the satellite and it flows between
the CN and the s/c via other nodes, as seen in the figure. Within the NTN, the Mission
Provider Aggregator (MPA), the Mission Planning System (MPS), and Ground Station
Aggregator (GSA) form the CMS.
The main workhorse of the CMS is the MPS,15 the node that contains the simulator and
scheduler*. The MPS delivers telemetry data from the constellation to the simulator, and
*For the sake of this investigation, a lot of detail regarding data transfer between agents and the scheduler
was omitted, so that the simulator is prioritized.
5
Figure 2: Constellation management system architecture.
the algorithm then propagates the state of the s/c and returns final state and windows of
coverage (WoC), which also includes battery charge. The scheduler within the MPS finally
receives these events, or WoC, and develops an optimum task plan for each satellite to
follow based on a set of constraints and optimized criteria.15 In the next section, the details
of the simulator are provided.
A CONSTELLATION SIMULATOR FOR 6G/IOT PURPOSES
As mentioned in the previous section, the simulator is enclosed within the MPS. Its pur-
pose is to propagate the state of every satellite in the constellation, and to simultaneously
compute the WoC of different events. It is divided into three sections: input loading, WoC
computation, and output generation. See Figure 3 for a visual representation of the simu-
lator’s architecture. The inputs, which include satellite list, UE, GS, and TA coordinates,
solar panel and battery characteristics, sensors’ FOV, and simulation time, are loaded into
the algorithm. The algorithm then downloads the s/c’s most recent state for the specific
satellite and propagates its motion whilst computing the chosen WoC. The process is re-
peated for all s/c in the list. These WoC are then uploaded into an online database and
downloaded into an XML file to be handed off to the scheduler. The coming sub-sections
describe this process in more detail.
The simulator is designed in JAVA to facilitate integration with the scheduler and other
software, and uses an open-source library called Orekit.21 The advantage of using JAVA is
its simplicity and its facility to merge with the schedule. Similarly, Orekit was chosen due to
it being an open-source library built for JAVA as well as its abundance of functions related
to state propagation and WoC computation. The WoC, including for sun-charging events,
are all partially computed using this library’s functions. These windows represent the final
output of the simulator alongside the position and velocity vector of the satellite. The
scheduler receives these as inputs and creates the final task plan. This method of simulation
is preferred over existing software due to the desire of separating the simulator from other
6
interfaces, so the only task operators are required to perform is input the necessary details,
without dealing with complex interfaces or prior knowledge of the tool.
Figure 3: Simulator structure.
A. Input Loading
To effectively propagate the motion of the s/c and schedule the tasks, several inputs
are first required. The current prototype uses direct inputs from text files (.txt) and Tom’s
Obvious Minimal Language (TOML)22 files. Table 1 shows these inputs more clearly. The
satellite list is the most important input. This list is in the form of a text file and includes
the official names of the s/c in the constellation. These satellites are read by the algorithm
and their state retrieved from Celestrack, a non-profit website that stores satellite’s two-line
elements (TLEs).3A TLE is a standard way developed by the North American Aerospace
Defense Command (NORAD) to represent a s/c’s state at a specific epoch.23 The solar
panel and battery information for each satellite is also added to the algorithm via a text file,
which includes solar panel area, quantum efficiency, panel normal direction, and battery
Table 1: Simulator inputs.
Inputs
Satellite List TA List
GS List UE List
GS/UE half-FOV Antenna half-FOV
Spacecraft Attitude Solar Panel Properties
Battery Voltage Simulation Time
7
voltage. This method will be replaced in a future prototype by a TOML file. All coordinates
and epochs are defined in the J2000 reference frame, considering UTC time definition,
including the TLEs retrieved from Celestrack.
In order for the algorithm to receive the geographical information of all GSs, UEs, and
TAs, a TOML file is generated and read in the program. These file types are an altered form
of a text file that are specifically designed to be easily read by external software. Whereas
the former is read verbatim by software, a TOML file is broken down into categories within
the file that is interpreted by built-in functions in JAVA, the chosen language for the CMS.
Figure 4 illustrates an example TOML file. In the figure, categories and sub-categories
are shown in double square-brackets. The built-in functions recognize these categories,
e.g. ”TAs” and ”TAs.vertices”, and then find the name of each instance, e.g. ”name TA”,
”ID TA”, ”latitude”, etc, and read its value. This method is ideal when dealing with tab-
ulated data as is the case for GSs, UEs, and TAs. To locate the GSs, UEs, and TAs, the
created TOML files must include latitude, longitude, and a chosen name, as well as the
elevation angle for GSs and UEs. This elevation angle represents the location’s half-FOV
in the form of its complimentary angle, i.e. 90◦−half-FOV = elevation angle.
Figure 4: TOML example file.
Finally, the s/c’s antenna half-FOV, simulation time, and s/c attitude are directly input
into the algorithm’s functions argument, and so are chosen to obtain the results. Future
prototypes will replace this method of input loading with a user-interface that is merged
with the scheduler, facilitating result generation and user accessibility.
B. WoC Computation
The second section of the simulator involves propagating the retrieved TLE and com-
puting the WoC for the desired satellites and locations. Once the inputs are loaded into
the algorithm, the simulator uses the SGP424 model to propagate the motion of the satel-
lites. The SGP4 propagator is a perturbation based statistical model that takes into account
Earth’s oblateness, the Moon’s gravitational pull, atmospheric drag, and other lesser per-
turbations.24 Simultaneously, the software creates event detectors that are combined with
the propagator to tag when certain conditions are met. These tags are interpreted as the
start and end of a WoC, and the dates are stored until the end of the propagation.
The WoC represent the duration for which a satellite remains in visibility of some object.
8
In the current prototype, these ”objects” include GSs, UEs, TAs, and the Sun. However, the
simulator is designed in such a way that other types of events may be added, such as Inter-
Satellite Links (ISLs) which are out of the scope of this paper. Events are defined by three
elements: first contact or acquisition of signal, last contact or loss of signal, and, lastly,
the state of the s/c at the time of each contact. To compute the WoC, the process requires
an elevation angle for GSs and UEs, field-of-view for the satellites’ antenna, vertices of
a polygon for TAs, and geographic coordinates (latitude and longitude) for all locations.
Stations and equipments are modeled as locations on the Earth’s surface, and hence both
shall be referred to as ”locations” in this investigation. Manual adjustment is required for
the WoC when the TLE begins while an event is on-going. In this case, the first trigger
occurs when the visibility is ending. If this occurs, the software marks the beginning of the
event as the beginning of the propagation. Similarly, if the propagation ends while an event
is ongoing, the end of the event is marked as the end of the propagation.
The GS and UE events correspond to straightforward visibility calculations. However,
two conditions must be met. The satellite has to be within the location’s FOV, and the
location has to be within the satellite’s FOV. To create the TAs, several cities are picked,
and a TOML file is created using their coordinates. These cities form the vertices of a
N-sided polygon, where N represents the number of cities. The larger the N, the smoother
the edges of the TA become. Note that the presented method is only an approximation,
and more accurate models will be created in future work. When any portion of the TA
is within the s/c’s FOV, an event is triggered. Sun visibility events are much simpler,
as the only thing that has to be taken into account is the direct line-of-sight between the
celestial body and the s/c. Lastly, the Sun-charging WoC information is utilized to compute
the battery charge generated during each of the events. To compute the battery charge, a
realistic approach corresponds to considering the orientation of the solar panel within the
s/c’s reference frame, as well as the exact distance from the s/c to the Sun. The Sun’s
luminosity has been determined as L = 3.828 ×1026 Watts.25
P=L
4π|rS|2(1)
The power per unit area at the location of the s/c is a function of the luminosity and distance
to the Sun, and is found by Eq. 1, where rSis the position vector of the Sun relative to the
s/c. The variable P represents the power per unit area at the location of the satellite, but
not all of this radiation is absorbed by the solar panel. The final power that the s/c receives
from the Sun depends on the angle θthat relates the direction normal to the satellite’s solar
panel and rS.
Pabs =P Aη cos θ(2)
The total power absorbed, Pabs, is finally calculated in Eq. 2, where ηis the quantum
efficiency26 and Ais the area of the solar panel. The quantum efficiency is defined as the
amount of photons converted into electrons within the system. Since the duration of the
event varies with each satellite, calculating the average charge is not accurate. Instead,
the total period is broken down into small periods of time, δt. Note that a smaller δt gives
higher-fidelity results at the expense of increasing run-time. Multiplying the results of Eq. 2
9
by δt would give a result in units of energy (joules, J), but in order to automate the system
and efficiently merge with the scheduler, the algorithm uses the voltage of the on-board
batteries to convert the energy received into units of charge (coulombs, C):26
Q=XLAη cos θ
4π|rS|2Vδt (3)
Combining Eq. 1 and Eq. 2 with the process described in this paragraph gives Eq. 3. To
obtain the total charge for each event, Q, δQ is summed over the duration of the event.
C. Output Generation
Figure 5: Simulator action flow.
The final section of the simulator involves using a database to emulate the store-and-
forward approach used by telecommunications satellites, and finally the generation of an
XML file type to transfer the results to the scheduler operators. Once the propagation is
completed and all WoC are calculated, the information is uploaded to an online database
and from there re-downloaded and sent to the MPS as an XML file to be handled appro-
priately. This data flow is represented in Figure 5. A future goal of the CMS is to become
a commercial service, and due to this reason, a database is a useful and efficient way for
operators to analyze the telemetry stored. InfluxDB is the selected database. Such database
consists of a time-series data platform, and as such, it is specifically chosen to handle the
dates generated by the simulator. The advantage of this database is its ability to read and
10
write data in real-time, and so it serves a highly valuable purpose in 5G/IoT services.27 This
database also works using a JAVA library, which of course gives an advantage over other
databases that do not possess open-source libraries. The setting up of the database is han-
dled via inputting the necessary set-up values. This process is not necessary other than in
back-end functionality, so users are not required to know how to set-up this database. Var-
ious formats can be used to transfer data from the simulator to the scheduler via InfluxDB.
An XML file type is used over others due to its amenability. The data is presented and
organized in any way, and similarly is easily read by external software. This format can be
easily replaced by another type if necessary. After the various WoC are uploaded onto the
database, a separate function queries the database, interprets the dates, and generates the
XML file. Currently, the data is passed onto the scheduler manually, but future iterations
of the prototype will automate this method.
TESTING AND RESULTS
To test the current prototype of the simulator and scheduler, a sample constellation, Low
Earth Multi-Use Receiver 2 (LEMUR-2), is selected alongside two GSs (GS2 and GS11),
ten UEs spread out between the continental United States and Spain (UE101-UE110), and
two TAs (TA30-TA33) separated into two regions each (Spain north-east, Spain center,
US west, US east). Figure 6 below shows the TAs in orange and locations enumerated.
The LEMUR-2 is a LEO constellation that provides IoT services to users worldwide and
performs remote sensing functions.28 The goal of this selection is to emulate the most
realistic scenario for the simulator, in which a global-reach constellation, like LEMUR-
2, performs various functions for several users across the world. To test the accuracy of
the simulator, STK was selected as the tool to compare with the outputs provided by the
simulator. This software is also used to compare the WoC. The simulation scenario is
propagated for four days, starting November 25th, 2022, and with only four satellites that
are randomly selected out of the whole constellation.
A. Simulator Engine Results
In order to test the accuracy of the SGP4 propagator, the motion of a satellite is sim-
ulated in the simulator as well as STK. The chosen satellite is from the same LEMUR-2
constellation, with codename ”LEMUR-2-SPIRE-MINIONS” and ID 41992. The initial
TLE for the s/c is presented in Table 2. Figure 7 shows the plotted state over time output
by the simulator. To evaluate the accuracy of the simulator, an error plot is computed as the
Euclidean norm of the vector difference between STK’s output and the presented simulator
in meters for a limited number of points. The state of the s/c obtained from the algorithm
is accurate, as seen in Figure 8. Even though there does seem to be some error with respect
to STK, the magnitude of this discrepancy is less than two meters for the chosen satellite.
B. Events Computation
The inputs mentioned in the previous section are required to pursue the computation of
the WoC. For the presented scenario, these values are chosen in order to create extensive
11
WoC so the scheduler is tested efficiently. For simplicity, they are the same for all four
satellites, as well as all areas and locations. The attitude of the s/c is fixed throughout the
propagation towards Nadir. The inputs (Table 3) are added into the necessary file types as
described in previous sections. The various JAVA and Orekit functions within the algorithm
are able to read the text and TOML files and interpret the TAs’ and locations’ coordinates.
Figures 9a and 9b display the beginning and end of a GS WoC using these inputs. This
visual corresponds to a November 28th event, as seen in Table 4. Figure 9a shows the
satellite’s (green) and the GS2’s (blue) FOV at the start time of the event. Figure 9b shows
the moment at which the event ends. The WoC starts at the instant in which the center
of the green disk (red) is within the blue disk while the center of the blue disk (green) is
inside the green disk. Both conditions must be met in order to trigger an event, and it ends
the instant such a condition is broken. Table 4 shows a few of the WoC obtained from the
simulator for GS2 (Cape Canaveral, Florida, USA) in the right column, and the same events
calculated with STK on the left column. It is clear from these results that the algorithm is
reliable within a margin of a few fractions of a second when computing WoC for this GS.
This discrepancy is most likely due to tolerance limits within the algorithm.
The same procedure is followed for UEs and TAs, and these results are presented in
Tables 5 and 6 for UE105 (Colton, New York, USA) and TA33 (US West). Similarly to the
Figure 6: Target/service areas and ground stations.
Table 2: Simulation initial conditions.
Epoch 2022-11-25 18:20:23.737Z
Position Vector (5,675.023; 3,768.913; -12.595) km
Velocity Vector (0.543; -0.809; 7.590) km/s
12
Table 3: Scenario inputs.
Input Type Value
GS half-FOV 70◦
UE half-FOV 55◦
Antenna half-FOV 70◦
Spacecraft Attitude Nadir Pointing
Panel Efficiency 25%
Panel Area 0.3 m2
Battery Voltage 24 V
Panel Normal Direction (-1 0 0)
Table 4: GS WoC comparison.
Date STK Simulator
2022-11-26 15:11:06.245 15:11:06.250
15:14:31.784 15:14:31.778
2022-11-27 16:03:45.000 16:03:45.006
16:06:45.828 16:06:45.819
2022-11-28 15:23:20.606 15:23:20.606
15:27:30.007 15:27:30.002
Figure 7: Trajectory of satellite 41992.
13
Figure 8: Position vector error plot.
(a) Instant of WoC beginning. (b) Instant of WoC end.
Figure 9: Florida GS example WoC.
GS results, the accuracy of the simulator is within a tenth of a second for UEs, and a few
seconds for TAs. Finally, WoC of the Sun are also accurate when compared to STK as seen
in Table 7. This table compares dates from both simulator and STK, which were nearly
identical. The battery charge is computed for each of these events, however the units are
converted to amp-hours (A·hrs) as this unit is typically used to represent charge within the
14
Table 5: UE WoC comparison.
Date STK Simulator
2022-11-26 02:17:21.851 02:17:21.757
02:19:46.549 02:19:46.641
2022-11-28 02:29:57.325 02:29:57.237
02:32:28.513 02:32:28.598
2022-11-28 15:20:05.713 15:20:05.625
15:22:39.161 15:22:39.245
industry. On average, each Sun-charging event generated 1.93 A·hr.
Table 6: TA WoC comparison.
Date STK Simulator
2022-11-26 03:46:12.334 03:46:10.862
03:57:52.285 03:57:47.906
2022-11-27 17:29:45.620 17:29:48.648
17:43:25.001 17:43:27.704
2022-11-28 16:50:53.752 16:50:56.911
17:02:57.707 17:03:00.527
Table 7: Sun-charging comparison.
Date Charge STK Simulator
2022-11-25 1.936 A·hr 18:42:43.801 18:42:43.796
19:41:41.745 19:41:41.791
2022-11-25 1.931 A·hr 20:16:03.394 20:16:03.211
21:15:00.988 21:15:01.211
2022-11-25 1.927 A·hr 21:49:22.615 21:49:22.612
22:48:20.735 22:48:20.616
2022-11-25 1.923 A·hr 23:22:41.873 23:22:41.999
00:21:40.015 00:21:40.007
To further test the algorithm, results were generated for the same locations and satellites
but decreasing the s/c’s FOV by half to 35◦. Of the events selected in Table 4, only one
remains, with its duration shortened from 250sto only 38s. Windows for UE105 also di-
minished in length to only 90sat its longest, compared to 120s−180sin the previous case.
Lastly, multiple satellites, GSs, UEs, and TAs were input into the constellation simultane-
ously, which is visually appreciated in Figure 10. Multiple revolutions for each satellite are
displayed in this plot, which precess at locations near the equator over time due to uneven
gravitational fields. The green dots in the figure represent the various user equipments, and
in red the two ground stations in USA and Norway mentioned in previous sections. In all of
these scenarios, the simulator proved accurate when compared to STK, so it is determined
that all scenarios will provide accurate data, given enough computational power.
15
Figure 10: Trajectory of all satellites.
C. Scheduler Results
The WoC discussed in the previous section were delivered to and analyzed by the sched-
uler. This algorithm developed a task plan to manage the given satellites based on automatic
optimization schemes. Figure 11 shows the generated scheduler for satellite LEMUR-2-
SPIRE-MINION, and Figure 12 shows an enlarged portion of that same plot. The first
figure shows the duration of each event in the vertical axis, with each rectangle represent-
ing a single event. The horizontal axis represents the timeline of the simulation. The second
figure shows a close-up look at a single event, with the different data transfer types shown
in various colors. Mobile originated (MO) data is an upload from a UE to the s/c or a down-
load from the s/c to a GS, while mobile terminated (MT) data is a download from a GS to
the s/c or an upload from the s/c to an UE. For more information regarding the scheduler
and a more detailed look at the CMS, see the complimentary paper [ 15] published at the
this meeting.
16
Figure 11: Resulting schedule representation for a single satellite.
Figure 12: Detailed resulting schedule representation for a single satellite.
FUTURE WORK
More work is to be done to upgrade and optimize the simulator. Firstly, an important
consideration for satellite constellations is at what times a satellite establishes a link with
another satellite. This connection is referred to as inter-satellite links (ISLs), and including
these new WoC will give more data for the scheduler to optimize the task plan. Another
upgrade is to improve TA definition since, as described previously, the current approach is
to manually select cities within a region to form a polygon. However, this method creates
areas that do not necessarily reflect the boundaries of a whole country. These two upgrades
will certainly add more robustness to the scheduler, but it is also adding more strain to the
17
satellite’s on-board computer running the simulation. More advanced concepts to tackle
this run-time issue lie in the realm of machine learning. The endgame of future upgrades
is to develop a digital twin.20 A digital twin is a virtual simulation within the satellite
that autonomously computes the state of the s/c over time without the need for user input.
Rather than numerically propagating the state of the satellite, the algorithm would predict
the state of the s/c over time based on previous information about the s/c’s state using neural
networks and machine learning techniques. The process involves an initial guess, followed
by reinforcement of correct behaviors, and repeating this method until the output is the
correct state.
SUMMARY
To conclude, a challenge 6G/IoT services are facing is introduced, and a solution is pre-
sented in the form of DSNs. Various current methods of managing DSNs are also shown,
however none fit the criteria needed for telecommunication networks. Similarly, two com-
mon simulation engines are talked about, but also do not meet the needs of the CMS. A
final solution is ultimately described in i2CAT+ERAU’s Constellation Management Sys-
tem. A key element in this product is the orbital simulator, whose objective is to receive
satellite states and propagate them as initial conditions while computing windows of cov-
erage for ground stations, user equipments, Sun visibility, and target areas. Results from
current simulations were illustrated and the results discussed. The simulator needs to be
expanded upon with other features necessary for an accurate task planner to be generated.
These include inter-satellite links, link budget considerations, and an API.
ACKNOWLEDGEMENTS
This research was partially supported by the Embry-Riddle Aeronautical University Fac-
ulty Research Development Program and GAANN fellowship. Assistance from colleagues
in the Space Trajectories and Applications Research group at Embry-Riddle Aeronauti-
cal University is acknowledged as is the support from the College of Engineering and
Aerospace Engineering department. This work has been founded by the Government of
Catalonia in the scope of the NewSpace Strategy for Catalonia.
REFERENCES
[1] G. Curzi, D. Modenini, and P. Tortora, “Large Constellations of Small Satellites: A Survey of Near
Future Challenges and Missions,” Aerospace, Vol. 7, No. 9, 2020, p. 133.
[2] M. Giordani and M. Zorzi, “Non-Terrestrial Networks in the 6G Era: Challenges and Opportunities,”
IEEE Network, Vol. 35, No. 2, 2021, pp. 244 – 251.
[3] E. M. Ponce, “Development of an event simulator for satellite networks with 5G applications,” Univer-
sidad Carlos III de Madrid, 2022.
[4] T. Kellermann, R. P. Centelles, D. Camps-Mur, R. Ferr´
us, M. Guadalupi, and A. C. Aug ´
e, “Novel
Architecture for Cellular IoT in Future Non-Terrestrial Networks: Store and Forward Adaptations for
Enabling Discontinuous Feeder Link Operation,” IEEE Access, Vol. 10, 2022, pp. 68922–68936.
[5] “TIP’s Non-Terrestrial Connectivity Solutions Project Group Relaunch: New Partnerships and
New Scope,” https://telecominfraproject.com/tips-non-terrestrial-\
connectivity-solutions-project-group- relaunch-new- partnerships-new-\
scope/. Accessed: 2023-01-04.
18
[6] J. A. R. d. Azua, A. Calveras, and A. Camps, “Internet of Satellites (IoSat): Analysis of Network
Models and Routing Protocol Requirements,” IEEE Access, Vol. 6, 2018, pp. 20 390 – 20 411.
[7] D. Selva, A. Golkar, O. Korobova, I. L. Cruz, P. Collopy, and O. l. d. Weck, “Distributed Earth Satellite
Systems: What Is Needed to Move Forward?,” Journal of Aerospace Information Systems, Vol. 14,
No. 8, 2017, p. 412–438.
[8] C. A. Lopez, “In pursuit of autonomous distributed satellite systems,” Universitat Polit`
ecnica de
Catalunya, 2019.
[9] C. A. Rigo, L. O. Seman, E. Camponogara, E. M. Filho, and E. A. Bezerra, “Task scheduling for optimal
power management and quality-of-service assurance in CubeSats,” Acta Astronautica, Vol. 179, 2021,
p. 550–560.
[10] A. Fukunaga, G. Rabideau, S. Chien, and D. Yan, ““Aspen: A framework for automated planning and
scheduling of spacecraft control and operations,” Proc. International Symposium on AI, Robotics and
Automation in Space, 1997, pp. 181–187.
[11] R. Steel, M. Ni ´
ezette, A. Cesta, S. Fratini, A. Oddi, G. Cortellessa, et al., “Advanced Planning and
Scheduling Initiative MrSpock Aims for XMAS,” Language, Vol. 1050, 2009, p. 3.
[12] J. Frank and A. Jonsson, “Constraint-based Attribute and Interval Planning,” NASA Ames Research
Center, 2002.
[13] R. A. Richards, R. T. Houlette, and J. L. Mohammed, “Distributed Satellite Constellation Planning and
Scheduling,” FLAIRS Conference, 2001, pp. 68–72.
[14] J. A. Ruiz-De-Azua, Contribution to the Development of Autonomous Satellite Communications Net-
works. PhD thesis, Universitat Polit`
ecnica de Catalunya, 2020.
[15] A. Singla, F. Criscola, E. Ponce, D. Canales, A. Calveras, and J. A. Ruiz-De-Azua, “Towards 6G
Non-Terrestrial Networks - An Autonomous Constellation Management Engine,” Submitted to 33rd
AAS/AIAA conference, 2022.
[16] S. R. Pratt, R. A. Raines, C. E. Fossa, and M. A. Temple, “An operational and performance overview
of the IRIDIUM low earth orbit satellite system,” IEEE Communications Surveys & Tutorials, Vol. 2,
No. 2, 1999, pp. 2–10.
[17] P. Wang, G. Reinelt, P. Gao, and Y. Tan, “A model, a heuristic and a decision support system to solve the
scheduling problem of an earth observing satellite constellation,” Computers & Industrial Engineering,
Vol. 61, 2011, pp. 322–335.
[18] M. Abramson, D. Carter, S. Kolitz, M. Ricard, and P. Scheidler, “Real-Time Optimized Earth Observa-
tion Autonomous Planning,” NASA Earth Science Technology Conference, Pasadena, CA, 2002.
[19] F. Xhafa, X. Herrero, A. Barolli, and M. Takizawa, “Using STK Toolkit for Evaluating a GA Base
Algorithm for Ground Station Scheduling,” IEEE Xplore, 2013.
[20] J. Trauer, Schweigert-Recksiek, C. Engel, K. Spreitzer, and M. Zimmermann, “WHAT IS A DIGITAL
TWIN? – DEFINITIONS AND INSIGHTS FROM AN INDUSTRIAL CASE STUDY IN TECHNI-
CAL PRODUCT DEVELOPMENT,” International Design Conference, 2020.
[21] “OREKIT,” https://orekit.org/. Accessed: 2022-12-20.
[22] “TOML,” https://toml.io/en/. Accessed: 2022-12-13.
[23] D. Ly, R. Lucken, and D. Giolito, ““Correcting TLEs at Epoch: Application to the GPS Constellation,”
Journal of Space Safety Engineering, Vol. 7, 2020.
[24] I. V. Baranov, “SGP4 Propagation Program Design and Validation,” Canadian Space Agency, 2009.
[25] E. Mamajek, A. Prsa, G. Torres, P. Harmanec, M. Asplund, P. Bennett, et al., “IAU 2015 Resolution B3
on Recommended Nominal Conversion Constants for Selected Solar and Planetary Properties,” Solar
System Astrophysics, 2015.
[26] A. Afif, B. Asprillia, and W. Priharti, “Design and Implementation of Battery Management System for
Portable Solar Panel with Coulomb Counting Method,” 2nd InCEAS, 2020.
[27] “InfluxData,” https://www.influxdata.com/. Accessed: 2022-12-25.
[28] J. Cappaert, “The Spire Small Satellite Network,” Handbook of Small Satellites, 2020, pp. 1–21.
19
