Space Habitat Data Centers—For Future Computing

: Data from sensor-bearing satellites requires processing aboard terrestrial data centres that use water for cooling at the expense of high data-transfer latency. The reliance of terrestrial data centres on water increases their water footprint and limits the availability of water for other applications. Therefore, data centres with low data-transfer latency and reduced reliance on Earth’s water resources are required. This paper proposes space habitat data centres (SHDCs) with low latency data transfer and that use asteroid water to address these challenges. The paper investigates the feasibility of accessing asteroid water and the reduction in computing platform access latency. Results show that the mean asteroid water access period is 319.39 days. The use of SHDCs instead of non-space computing platforms reduces access latency and increases accessible computing resources by 11.9–33.6% and 46.7–77% on average, respectively.


Introduction
Terrestrial cloud data centres have high powering [1][2][3] and cooling (using water) [4,5] costs. These have prompted the design of solutions [6][7][8][9][10] that reduce power consumption and water footprint. The water footprint can also be reduced by leveraging free air cooling [11,12] to a limited extent. The ocean provides free water cooling and can host data centres [13][14][15], at the risk of degrading marine biodiversity.
Siting data centres in space can reduce the water footprint [16][17][18][19]. The approach in references [16,18] utilises small satellites to realize space-based data centres. Small satellites used as data centres have reduced uptime when faults occur because they are unmanned. It is also challenging to upgrade the computing payload in small satellites being used as data centres. Outer space also hosts satellites and spaceships [19][20][21]. Spaceships such as space habitats can support humans (making it easy to address faults) and host a larger computing payload. This paper proposes a manned space habitat data centre (SHDC) for processing space and non-space application data.
The discussion in this paper addresses the challenge of reducing the water footprint of data centres. The paper proposes that data centres be sited in outer space (Earth's orbit) and make use of asteroid water for cooling to reduce Earth's data centre water footprint. The proposed data centre is located in a space habitat data centre. The use of an SHDC (space-based) also enables low latency computing platform access by satellites with data requiring processing.
The contributions of the paper are further discussed below: The paper proposes manned space habitat data centres (SHDCs) for data processing. In addition, the paper presents the architecture for the design of the proposed SHDC. This is done by describing the aspects related to the access and use of asteroid water for cooling the SHDC. In addition, the paper describes communications between SHDCs, computer-resource-constrained space assets, and the ground segment. The paper also describes SHDC design and computing entities enabling data The paper considers data centre operators seeking to process space data and site data centres near water sources. Let α be the set of terrestrial data centre operators.
The set of terrestrial data centres deployed by the ath operator, α a , α a α is given by The cooling indicator of the ith Earth-based terrestrial data centre from the ath operator α i a , α i a α a is denoted I α i a {0, 1}. The indicator values I α i a = 0 and I α i a = 1 signifies that data centre α i a is not and is water cooled respectively. In addition, let β α i a , t y , t y t; t = {t 1 , t 2 , . . . , t Y } be the water footprint of the Earth-based terrestrial data centre α i a at the epoch t y . Furthermore, let γ be the set of ground locations of terrestrial data centres.
The location indicator of data centre α i a at location γ b , γ b γ at epoch t y is denoted I α i a , γ b , t y {0, 1}. The data centre α i a is not located and is located at γ b at epoch t y when I α i a , γ b , t y = 0 and I α i a , γ b , t y = 1 respectively. In the discussion here, terrestrial data centres utilise Earth's water resources. The Earth's water resource being used is at a temperature that is suitable for data centre cooling. The use of terrestrial data centres poses a challenge to water security when where w(γ b ) is the amount of water resources available at the bth Earth-based terrestrial location γ b . Let φ be the set of applications requiring access to water resources such that In addition, let w(φ c , γ b ); φ c φ be the water footprint of the cth application φ c at location γ b . The demand for water by other application gives rise to water access challenges given the condition The relation in (6) holds true under different conditions such as If (6) and (7) holds true, the data centre water footprint is less than that of other applications. The data centre water demand overwhelms water supply in the considered Earth locations and is described as case C1. The case where (6) and (8) holds true is one in which data centre water footprint is roughly equal to that of other applications and is described as case C2. The water demand of data centres and existing applications jointly overwhelms the water supply source in cases C1 and C2. The discussion here reduces data centre water footprint.
Let St and ϑ be the set of small satellites and space vehicles requiring data processing, respectively.
Let C I St d , t y and C I ϑ e , t y , ϑ e ϑ be the amount of idle computing resources on-board the dth small satellite St d and the eth space vehicle ϑ e at epoch t y respectively. In our consideration, a small satellite entity can host multiple applications. This has not been considered in (9). Instead, the relation in (9) aims to provide a mathematical formulation for the set of small satellites and not the set of C4 : C5 : The conditions in C1-C2 describe challenges associated with reducing terrestrial data centres reliance on Earth's water resources. The condition in C3, C4, and C5 describes challenges associated with accessing computing resources for processing small satellite data.

Proposed Solution
This section presents the solutions proposed to address the identified challenges. It has three parts. The first, second and third presents SHDCs network architecture, SHDC computing resource access (C3-C5) and asteroid water access in the SHDC (C1-C2), respectively.

SHDC Network Architecture
The proposed solution reduces data centre demand on Earth's water resources. Instead of realizing the data centre by integrating the storage and computing capabilities aboard small satellites, the use of a manned SHDC is proposed. The use of small satellites and space vehicles in a distributed architecture is suited for realizing edge nodes. However, it is challenging to upgrade computing payload after launch. Manned SHDCs support the upgrade of data centre computing payload or replace of damaged payload components.
The proposed SHDC comprises the cooling system (CLS), the server and computing system (SCS), and the communication system (CCS). The CCS enables communications with space edge-computing nodes, other SHDCs, and ground stations. The CLS's coolant is asteroid water. This is feasible as meteorites and asteroids host water reservoirs [46,47]. The relation between the CLS, SCS, CCS, and the Earth segment is in Figure 1. The SCS receives workload from the terrestrial ground station gateway (TSGW) via the CCS. In Figure 1, the SHDC in low Earth orbit (LEO) executes the workload received from space and terrestrial assets.

Proposed Solution-SHDC Access to Computing Resources
Inter-communication between SHDCs becomes necessary when SHDCs are in the range of space vehicles or other SHDCs have insufficient computing resources as described in C3-C5. This can be addressed by increasing SHDC computing capability or launching more SHDCs. Let θ be the set of SHDCs. θ = θ 1 , θ 2 , θ 3 , . . . , θ J The computing capability and idle computing resources of the jth SHDC, θ j , θ j θ is denoted C 1 θ j and C I θ j , t y , respectively. The mean of the idle computing resources is determined and shared with other SHDCs. The mean idle computing resource available on each SHDC is determined over a given duration. The ( j + 1)th SHDC θ j+1 , θ j+1 θ is most suitable for data processing if The process of accessing computing resources in an SHDC network is shown in Figure 2. If the SHDC does not have sufficient computing resources, the workload is fragmented and processed in a distributed manner in a SHDC network.

SHDC Network Architecture
The proposed solution reduces data centre demand on Earth's water resources. Instead of realizing the data centre by integrating the storage and computing capabilities aboard small satellites, the use of a manned SHDC is proposed. The use of small satellites and space vehicles in a distributed architecture is suited for realizing edge nodes. However, it is challenging to upgrade computing payload after launch. Manned SHDCs support the upgrade of data centre computing payload or replace of damaged payload components.
The proposed SHDC comprises the cooling system (CLS), the server and computing system (SCS), and the communication system (CCS). The CCS enables communications with space edge-computing nodes, other SHDCs, and ground stations. The CLS's coolant is asteroid water. This is feasible as meteorites and asteroids host water reservoirs [46,47]. The relation between the CLS, SCS, CCS, and the Earth segment is in Figure 1. The SCS receives workload from the terrestrial ground station gateway (TSGW) via the CCS. In Figure 1, the SHDC in low Earth orbit (LEO) executes the workload received from space and terrestrial assets.

Proposed Solution-SHDC Access to Computing Resources
Inter-communication between SHDCs becomes necessary when SHDCs are in the range of space vehicles or other SHDCs have insufficient computing resources as described in C3-C5. This The computing capability and idle computing resources of the ℎ SHDC, , is denoted ( ) and ( , ) , respectively. The mean of the idle computing resources is determined and shared with other SHDCs. The mean idle computing resource available on each SHDC is determined over a given duration.
The process of accessing computing resources in an SHDC network is shown in Figure 2. If the SHDC does not have sufficient computing resources, the workload is fragmented and processed in a distributed manner in a SHDC network. The SHDC intended for use in Figure 2 is hosted in an international computing space station with provider-specific interfaces (PSIs). In addition, the SHDC is located in the low Earth orbit. However, it is sited at an altitude that is higher than that of the targeted small satellite networks being considered. The PSIs enable computing platform service providers to host data centres in the space habitat. The CLS, SCS, and CCS are present in each SHDC. PSIs are attached to the international computing space station via space computing nodes (SCNs). The role of PSIs, SCNs, The SHDC intended for use in Figure 2 is hosted in an international computing space station with provider-specific interfaces (PSIs). In addition, the SHDC is located in the low Earth orbit. However, it is sited at an altitude that is higher than that of the targeted small satellite networks being considered. The PSIs enable computing platform service providers to host data centres in the space habitat. The CLS, SCS, and CCS are present in each SHDC. PSIs are attached to the international computing space station via space computing nodes (SCNs). The role of PSIs, SCNs, and computing and algorithm execution entities is shown in Figure 3. Each data centre comprises a PSI through which subscribers' access computing services via the CCS. Figure 3 has 8 PSIs. The concerned PSIs is given as PSI x, x = {1, 2, 3, 4, 5, 6, 7, 8} and are attached to the subsystem monitoring chambers via the SCNs. SCNs host sensors and enable data transfer from the PSI to the subsystem monitoring chambers. The architecture also shows sub-components supporting SHDC functioning. These are the living space for data centre engineers, store, and subsystem monitoring chambers. The subsystem monitoring chamber hosts components that monitor data centre performance and water availability for SHDC cooling. The store hosts the spare sub-systems and devices. It is allocated to different organizations and can be replenished by trips to the SHDC. Each PSI communicates with ground-based entities and satellites via the CCS. The SHDC's computing payload is operated by the engineers in the living space. The engineers execute maintenance procedures in a manner similar to terrestrial data centres.

SHDC-Supplying Asteroid Water
The SHDC requires access to asteroid water for cooling. The supply of asteroid water involves three entities i.e., space water reservoir entity (SWRE), asteroid water mining entity (AWME), and the computing platform service provider. The SWRE and AWME can also supply water to other outer space applications that require access to water and products that can be directly derived from water. In the consideration here, the SWRE is located in a low temperature location in Earth orbit but at a significantly higher altitude than that of the SHDC. The SWRE is far from the sun because the maximum low Earth orbit altitude is significantly lower than the Sun-Earth distance. This large separating distance implies that heat from the sun does not significantly increase the asteroid water temperature. In addition, the SWRE enables the execution of other space applications. Examples of such are space applications requiring the provision of hydrogen fuel for space-based applications as identified by Molag et al [48]. The SWRE receives information on SHDC location and stores and supplies asteroid water to the SHDC via water supply vehicles. The water supply vehicles ensure the supply of low-temperature asteroid water (accessed from the SWRE) to a given SHDC. They incorporate cooling systems to maintain asteroid water at low temperature. In addition, the use of a water supply vehicle reduces the asteroid water supply delay in comparison to the case where asteroid water is mined and directly supplied to the SHDC. Relations between the AWME, SWRE, and SHDC are shown in Figure 4. The flowchart showing SWRE and SWR functionality is shown in Figure 5.

Performance Formulation
The performance model assumes that small satellites have limited computing capability necessitating accessing additional computing resources. In existing work [19,44], the data requiring processing is transmitted to the terrestrial cloud computing platform. The formulated metrics are the The architecture also shows sub-components supporting SHDC functioning. These are the living space for data centre engineers, store, and subsystem monitoring chambers. The subsystem monitoring chamber hosts components that monitor data centre performance and water availability for SHDC cooling. The store hosts the spare sub-systems and devices. It is allocated to different organizations and can be replenished by trips to the SHDC. Each PSI communicates with ground-based entities and satellites via the CCS. The SHDC's computing payload is operated by the engineers in the living space. The engineers execute maintenance procedures in a manner similar to terrestrial data centres.

SHDC-Supplying Asteroid Water
The SHDC requires access to asteroid water for cooling. The supply of asteroid water involves three entities i.e., space water reservoir entity (SWRE), asteroid water mining entity (AWME), and the computing platform service provider. The SWRE and AWME can also supply water to other outer space applications that require access to water and products that can be directly derived from water. In the consideration here, the SWRE is located in a low temperature location in Earth orbit but at a significantly higher altitude than that of the SHDC. The SWRE is far from the sun because the maximum low Earth orbit altitude is significantly lower than the Sun-Earth distance. This large separating distance implies that heat from the sun does not significantly increase the asteroid water temperature. In addition, the SWRE enables the execution of other space applications. Examples of such are space applications requiring the provision of hydrogen fuel for space-based applications as identified by Molag et al. [48]. The SWRE receives information on SHDC location and stores and supplies asteroid water to the SHDC via water supply vehicles. The water supply vehicles ensure the supply of low-temperature asteroid water (accessed from the SWRE) to a given SHDC. They incorporate cooling systems to maintain asteroid water at low temperature. In addition, the use of a water supply vehicle reduces the asteroid water supply delay in comparison to the case where asteroid water is mined and directly supplied to the SHDC. Relations between the AWME, SWRE, and SHDC are shown in Figure 4. The flowchart showing SWRE and SWR functionality is shown in Figure 5.
Symmetry 2020, 12, x FOR PEER REVIEW 10 of 21 computing platform access latency and the accessible computing resources in the space segment. This section has two parts. The first and second parts formulate cloud platform access latency and accessible computing resources in the space segment respectively. Relations between asteroid water mining entity (AWME), water storage, and access by platform service providers.

Figure 5.
Relations between the AWME, space water reservoir entity (SWRE), and space water reservoir (SWR) in the supply of asteroid water for the space habitat data centre (SHDC).

Figure 4.
Relations between asteroid water mining entity (AWME), water storage, and access by platform service providers.
Symmetry 2020, 12, x FOR PEER REVIEW 10 of 21 computing platform access latency and the accessible computing resources in the space segment. This section has two parts. The first and second parts formulate cloud platform access latency and accessible computing resources in the space segment respectively. Relations between asteroid water mining entity (AWME), water storage, and access by platform service providers.

Figure 5.
Relations between the AWME, space water reservoir entity (SWRE), and space water reservoir (SWR) in the supply of asteroid water for the space habitat data centre (SHDC).

Figure 5.
Relations between the AWME, space water reservoir entity (SWRE), and space water reservoir (SWR) in the supply of asteroid water for the space habitat data centre (SHDC).

Performance Formulation
The performance model assumes that small satellites have limited computing capability necessitating accessing additional computing resources. In existing work [19,44], the data requiring processing is transmitted to the terrestrial cloud computing platform. The formulated metrics are the computing platform access latency and the accessible computing resources in the space segment. This section has two parts. The first and second parts formulate cloud platform access latency and accessible computing resources in the space segment respectively.

Computing Platform Access Latency
This section develops the performance model describing the access latency associated with using the computing resources aboard computing platforms, i.e., data centres. The formulation is different from that associated with using the space edge computing platform found in Wang et al. [19]. In the formulation here, data centres are considered to be suitable as seen in [44] and not edge-computing nodes (existing in Wang et al. [19]) are considered. The formulation extends the consideration of space edge computing nodes to that of accessing computing resources aboard data centres located in the stratosphere and in space (SHDC). The consideration of the SHDC here extends [44] where the suitability of a space-based data centre is recognized but without any mathematical formulation. The novelty of the formulation in comparison to existing work in Wang et al. [19] is that it considers that satellites process their data on data centres instead of space edge computing platforms. However, it is recognized by Denby et al. [44] that the use of space-based computing platforms is beneficial. This is because data centres host a significant number of servers and have more computing resources in comparison to the space edge-computing node.
The small satellite St d can access computing resources from platforms sited in different locations i.e., terrestrial, stratosphere or space (i.e, SHDC). Let ymmetry 2020, 12, x FOR PEER REVIEW 11 of 21

.1. Computing Platform Access Latency
This section develops the performance model describing the access latency associated with sing the computing resources aboard computing platforms, i.e., data centres. The formulation is ifferent from that associated with using the space edge computing platform found in Wang et al 9]. In the formulation here, data centres are considered to be suitable as seen in [44] and not dge-computing nodes (existing in Wang et al [19]) are considered. The formulation extends the onsideration of space edge computing nodes to that of accessing computing resources aboard data entres located in the stratosphere and in space (SHDC). The consideration of the SHDC here xtends [44] where the suitability of a space-based data centre is recognized but without any athematical formulation. The novelty of the formulation in comparison to existing work in Wang t al [19] is that it considers that satellites process their data on data centres instead of space edge omputing platforms. However, it is recognized by Denby et al [44] that the use of space-based omputing platforms is beneficial. This is because data centres host a significant number of servers nd have more computing resources in comparison to the space edge-computing node.
The small satellite Ϛ can access computing resources from platforms sited in different cations i.e., terrestrial, stratosphere or space (i.e, SHDC). Let be the set of stratosphere-based omputing platforms: The altitude of the small satellite Ϛ , SHDC , space vehicle, stratosphere-based omputing platform , are ℎ(Ϛ ), ℎ , ℎ( ) and ℎ( ) respectively. In addition, let ℎ Ϛ , , , { , , , } denote the link speed between the small satellite and computing latform entity at the epoch . The amount of data from small satellite Ϛ requiring access to omputing resource aboard the computing platform entity is denoted (Ϛ , ). The computing latform access latency for stratosphere computing platforms, Г is given as It is also feasible that the small satellite accesses a stratosphere computing platform via other tratosphere computing platforms through inter-platform links. This is necessary when small atellite has transmit power constraints. The compute resource (or platform) access latency Г is iven as , , ≠, . ( , , ) and ℎ , , are the size of data transmitted and ter-platform link speed between the th and ( + )th stratosphere computing platforms at e epoch respectively. ℎ( ) and ℎ( ) are the altitude of the th and ( + )th tratosphere computing platforms respectively. The compute resource access latency for the terrestrial cloud computing platforms Г is given s be the set of stratosphere-based computing platforms: puting Platform Access Latency is section develops the performance model describing the access latency associated with e computing resources aboard computing platforms, i.e., data centres. The formulation is t from that associated with using the space edge computing platform found in Wang et al the formulation here, data centres are considered to be suitable as seen in [44] and not mputing nodes (existing in Wang et al [19]) are considered. The formulation extends the ration of space edge computing nodes to that of accessing computing resources aboard data located in the stratosphere and in space (SHDC). The consideration of the SHDC here [44] where the suitability of a space-based data centre is recognized but without any atical formulation. The novelty of the formulation in comparison to existing work in Wang ] is that it considers that satellites process their data on data centres instead of space edge ing platforms. However, it is recognized by Denby et al [44] that the use of space-based ing platforms is beneficial. This is because data centres host a significant number of servers e more computing resources in comparison to the space edge-computing node. e small satellite Ϛ can access computing resources from platforms sited in different s i.e., terrestrial, stratosphere or space (i.e, SHDC). Let be the set of stratosphere-based ing platforms: e altitude of the small satellite Ϛ , SHDC , space vehicle, stratosphere-based ing platform , are ℎ(Ϛ ), ℎ , ℎ( ) and ℎ( ) respectively. In addition, let , , { , , , } denote the link speed between the small satellite and computing entity at the epoch . The amount of data from small satellite Ϛ requiring access to ing resource aboard the computing platform entity is denoted (Ϛ , ). The computing access latency for stratosphere computing platforms, Г is given as s also feasible that the small satellite accesses a stratosphere computing platform via other here computing platforms through inter-platform links. This is necessary when small has transmit power constraints. The compute resource (or platform) access latency Г is s , ≠, . ( , , ) and ℎ , , are the size of data transmitted and atform link speed between the th and ( + )th stratosphere computing platforms at ch respectively. ℎ( ) and ℎ( ) are the altitude of the th and ( + )th here computing platforms respectively. e compute resource access latency for the terrestrial cloud computing platforms Г is given = metry 2020, 12, x FOR PEER REVIEW 11 of 21

. Computing Platform Access Latency
This section develops the performance model describing the access latency associated with ing the computing resources aboard computing platforms, i.e., data centres. The formulation is fferent from that associated with using the space edge computing platform found in Wang et al ].
In the formulation here, data centres are considered to be suitable as seen in [44] and not ge-computing nodes (existing in Wang et al [19]) are considered. The formulation extends the nsideration of space edge computing nodes to that of accessing computing resources aboard data ntres located in the stratosphere and in space (SHDC). The consideration of the SHDC here tends [44] where the suitability of a space-based data centre is recognized but without any athematical formulation. The novelty of the formulation in comparison to existing work in Wang al [19] is that it considers that satellites process their data on data centres instead of space edge mputing platforms. However, it is recognized by Denby et al [44] that the use of space-based mputing platforms is beneficial. This is because data centres host a significant number of servers d have more computing resources in comparison to the space edge-computing node. The small satellite Ϛ can access computing resources from platforms sited in different ations i.e., terrestrial, stratosphere or space (i.e, SHDC). Let be the set of stratosphere-based mputing platforms: The altitude of the small satellite Ϛ , SHDC , space vehicle, stratosphere-based mputing platform , are ℎ(Ϛ ), ℎ , ℎ( ) and ℎ( ) respectively. In addition, let Ϛ , , , { , , , } denote the link speed between the small satellite and computing atform entity at the epoch . The amount of data from small satellite Ϛ requiring access to mputing resource aboard the computing platform entity is denoted (Ϛ , ). The computing atform access latency for stratosphere computing platforms, Г is given as It is also feasible that the small satellite accesses a stratosphere computing platform via other atosphere computing platforms through inter-platform links. This is necessary when small tellite has transmit power constraints. The compute resource (or platform) access latency Г is en as , , ≠, . ( , , ) and ℎ , , are the size of data transmitted and ter-platform link speed between the th and ( + )th stratosphere computing platforms at e epoch respectively. ℎ( ) and ℎ( ) are the altitude of the th and ( + )th atosphere computing platforms respectively.
The compute resource access latency for the terrestrial cloud computing platforms Г is given 1 , Symmetry 2020, 12, x FOR PEER REVIEW 11 of 21

Computing Platform Access Latency
This section develops the performance model describing the access latency associated with using the computing resources aboard computing platforms, i.e., data centres. The formulation is different from that associated with using the space edge computing platform found in Wang et al [19]. In the formulation here, data centres are considered to be suitable as seen in [44] and not edge-computing nodes (existing in Wang et al [19]) are considered. The formulation extends the consideration of space edge computing nodes to that of accessing computing resources aboard data centres located in the stratosphere and in space (SHDC). The consideration of the SHDC here extends [44] where the suitability of a space-based data centre is recognized but without any mathematical formulation. The novelty of the formulation in comparison to existing work in Wang et al [19] is that it considers that satellites process their data on data centres instead of space edge computing platforms. However, it is recognized by Denby et al [44] that the use of space-based computing platforms is beneficial. This is because data centres host a significant number of servers and have more computing resources in comparison to the space edge-computing node.
The small satellite Ϛ can access computing resources from platforms sited in different locations i.e., terrestrial, stratosphere or space (i.e, SHDC). Let be the set of stratosphere-based computing platforms: The altitude of the small satellite Ϛ , SHDC , space vehicle, stratosphere-based computing platform , are ℎ(Ϛ ), ℎ , ℎ( ) and ℎ( ) respectively. In addition, let ℎ Ϛ , , , { , , , } denote the link speed between the small satellite and computing platform entity at the epoch . The amount of data from small satellite Ϛ requiring access to computing resource aboard the computing platform entity is denoted (Ϛ , ). The computing platform access latency for stratosphere computing platforms, Г is given as It is also feasible that the small satellite accesses a stratosphere computing platform via other stratosphere computing platforms through inter-platform links. This is necessary when small satellite has transmit power constraints. The compute resource (or platform) access latency Г is given as , , ≠, . ( , , ) and ℎ , , are the size of data transmitted and inter-platform link speed between the th and ( + )th stratosphere computing platforms at the epoch respectively. ℎ( ) and ℎ( ) are the altitude of the th and ( + )th stratosphere computing platforms respectively.
The compute resource access latency for the terrestrial cloud computing platforms Г is given as 2 , . . . , Symmetry 2020, 12, x FOR PEER REVIEW 11 of 21

Computing Platform Access Latency
This section develops the performance model describing the access latency associated with using the computing resources aboard computing platforms, i.e., data centres. The formulation is different from that associated with using the space edge computing platform found in Wang et al [19]. In the formulation here, data centres are considered to be suitable as seen in [44] and not edge-computing nodes (existing in Wang et al [19]) are considered. The formulation extends the consideration of space edge computing nodes to that of accessing computing resources aboard data centres located in the stratosphere and in space (SHDC). The consideration of the SHDC here extends [44] where the suitability of a space-based data centre is recognized but without any mathematical formulation. The novelty of the formulation in comparison to existing work in Wang et al [19] is that it considers that satellites process their data on data centres instead of space edge computing platforms. However, it is recognized by Denby et al [44] that the use of space-based computing platforms is beneficial. This is because data centres host a significant number of servers and have more computing resources in comparison to the space edge-computing node.
The small satellite Ϛ can access computing resources from platforms sited in different locations i.e., terrestrial, stratosphere or space (i.e, SHDC). Let be the set of stratosphere-based computing platforms: The altitude of the small satellite Ϛ , SHDC , space vehicle, stratosphere-based computing platform , are ℎ(Ϛ ), ℎ , ℎ( ) and ℎ( ) respectively. In addition, let ℎ Ϛ , , , { , , , } denote the link speed between the small satellite and computing platform entity at the epoch . The amount of data from small satellite Ϛ requiring access to computing resource aboard the computing platform entity is denoted (Ϛ , ). The computing platform access latency for stratosphere computing platforms, Г is given as It is also feasible that the small satellite accesses a stratosphere computing platform via other stratosphere computing platforms through inter-platform links. This is necessary when small satellite has transmit power constraints. The compute resource (or platform) access latency Г is given as , , ≠, . ( , , ) and ℎ , , are the size of data transmitted and inter-platform link speed between the th and ( + )th stratosphere computing platforms at the epoch respectively. ℎ( ) and ℎ( ) are the altitude of the th and ( + )th stratosphere computing platforms respectively.
The compute resource access latency for the terrestrial cloud computing platforms Г is given as ccess Latency s the performance model describing the access latency associated with ources aboard computing platforms, i.e., data centres. The formulation is iated with using the space edge computing platform found in Wang et al here, data centres are considered to be suitable as seen in [44] and not existing in Wang et al [19]) are considered. The formulation extends the ge computing nodes to that of accessing computing resources aboard data ratosphere and in space (SHDC). The consideration of the SHDC here suitability of a space-based data centre is recognized but without any n. The novelty of the formulation in comparison to existing work in Wang ers that satellites process their data on data centres instead of space edge owever, it is recognized by Denby et al [44] that the use of space-based eneficial. This is because data centres host a significant number of servers g resources in comparison to the space edge-computing node. Ϛ can access computing resources from platforms sited in different stratosphere or space (i.e, SHDC). Let be the set of stratosphere-based are ℎ(Ϛ ), ℎ , ℎ( ) and ℎ( ) respectively. In addition, let , } denote the link speed between the small satellite and computing epoch . The amount of data from small satellite Ϛ requiring access to rd the computing platform entity is denoted (Ϛ , ). The computing r stratosphere computing platforms, Г is given as t the small satellite accesses a stratosphere computing platform via other platforms through inter-platform links. This is necessary when small er constraints. The compute resource (or platform) access latency Г is . ( , , ) and ℎ , , are the size of data transmitted and between the th and ( + )th stratosphere computing platforms at ly. ℎ( ) and ℎ( ) are the altitude of the th and ( + )th z ,

EER REVIEW 11 of 21
Access Latency elops the performance model describing the access latency associated with resources aboard computing platforms, i.e., data centres. The formulation is sociated with using the space edge computing platform found in Wang et al on here, data centres are considered to be suitable as seen in [44] and not s (existing in Wang et al [19]) are considered. The formulation extends the edge computing nodes to that of accessing computing resources aboard data stratosphere and in space (SHDC). The consideration of the SHDC here he suitability of a space-based data centre is recognized but without any tion. The novelty of the formulation in comparison to existing work in Wang siders that satellites process their data on data centres instead of space edge However, it is recognized by Denby et al [44] that the use of space-based is beneficial. This is because data centres host a significant number of servers ting resources in comparison to the space edge-computing node. ite Ϛ can access computing resources from platforms sited in different al, stratosphere or space (i.e, SHDC). Let be the set of stratosphere-based the small satellite Ϛ , SHDC , space vehicle, stratosphere-based , are ℎ(Ϛ ), ℎ , ℎ( ) and ℎ( ) respectively. In addition, let , , } denote the link speed between the small satellite and computing he epoch . The amount of data from small satellite Ϛ requiring access to board the computing platform entity is denoted (Ϛ , ). The computing y for stratosphere computing platforms, Г is given as that the small satellite accesses a stratosphere computing platform via other ng platforms through inter-platform links. This is necessary when small power constraints. The compute resource (or platform) access latency Г is , latform Access Latency n develops the performance model describing the access latency associated with uting resources aboard computing platforms, i.e., data centres. The formulation is hat associated with using the space edge computing platform found in Wang et al ulation here, data centres are considered to be suitable as seen in [44] and not nodes (existing in Wang et al [19]) are considered. The formulation extends the space edge computing nodes to that of accessing computing resources aboard data in the stratosphere and in space (SHDC). The consideration of the SHDC here ere the suitability of a space-based data centre is recognized but without any rmulation. The novelty of the formulation in comparison to existing work in Wang it considers that satellites process their data on data centres instead of space edge forms. However, it is recognized by Denby et al [44] that the use of space-based orms is beneficial. This is because data centres host a significant number of servers omputing resources in comparison to the space edge-computing node. satellite Ϛ can access computing resources from platforms sited in different rrestrial, stratosphere or space (i.e, SHDC). Let be the set of stratosphere-based orms: e of the small satellite Ϛ , SHDC , space vehicle, stratosphere-based form , are ℎ(Ϛ ), ℎ , ℎ( ) and ℎ( ) respectively. In addition, let { , , , } denote the link speed between the small satellite and computing at the epoch . The amount of data from small satellite Ϛ requiring access to urce aboard the computing platform entity is denoted (Ϛ , ). The computing latency for stratosphere computing platforms, Г is given as asible that the small satellite accesses a stratosphere computing platform via other mputing platforms through inter-platform links. This is necessary when small nsmit power constraints. The compute resource (or platform) access latency Г is

Computing Platform Access Latency
This section develops the performance model describing the access latency associated with using the computing resources aboard computing platforms, i.e., data centres. The formulation is different from that associated with using the space edge computing platform found in Wang et al [19]. In the formulation here, data centres are considered to be suitable as seen in [44] and not edge-computing nodes (existing in Wang et al [19]) are considered. The formulation extends the consideration of space edge computing nodes to that of accessing computing resources aboard data centres located in the stratosphere and in space (SHDC). The consideration of the SHDC here extends [44] where the suitability of a space-based data centre is recognized but without any mathematical formulation. The novelty of the formulation in comparison to existing work in Wang et al [19] is that it considers that satellites process their data on data centres instead of space edge computing platforms. However, it is recognized by Denby et al [44] that the use of space-based computing platforms is beneficial. This is because data centres host a significant number of servers and have more computing resources in comparison to the space edge-computing node.
The small satellite Ϛ can access computing resources from platforms sited in different locations i.e., terrestrial, stratosphere or space (i.e, SHDC). Let be the set of stratosphere-based computing platforms: The altitude of the small satellite Ϛ , SHDC , space vehicle, stratosphere-based computing platform , are ℎ(Ϛ ), ℎ , ℎ( ) and ℎ( ) respectively. In addition, let ℎ Ϛ , , , { , , , } denote the link speed between the small satellite and computing platform entity at the epoch . The amount of data from small satellite Ϛ requiring access to computing resource aboard the computing platform entity is denoted (Ϛ , ). The computing platform access latency for stratosphere computing platforms, Г is given as It is also feasible that the small satellite accesses a stratosphere computing platform via other stratosphere computing platforms through inter-platform links. This is necessary when small satellite has transmit power constraints. The compute resource (or platform) access latency Г is given as ccess Latency ps the performance model describing the access latency associated with sources aboard computing platforms, i.e., data centres. The formulation is ciated with using the space edge computing platform found in Wang et al here, data centres are considered to be suitable as seen in [44] and not (existing in Wang et al [19]) are considered. The formulation extends the dge computing nodes to that of accessing computing resources aboard data tratosphere and in space (SHDC). The consideration of the SHDC here suitability of a space-based data centre is recognized but without any n. The novelty of the formulation in comparison to existing work in Wang ders that satellites process their data on data centres instead of space edge owever, it is recognized by Denby et al [44] that the use of space-based beneficial. This is because data centres host a significant number of servers ng resources in comparison to the space edge-computing node.
Ϛ can access computing resources from platforms sited in different stratosphere or space (i.e, SHDC). Let be the set of stratosphere-based are ℎ(Ϛ ), ℎ , ℎ( ) and ℎ( ) respectively. In addition, let , } denote the link speed between the small satellite and computing epoch . The amount of data from small satellite Ϛ requiring access to ard the computing platform entity is denoted (Ϛ , ). The computing or stratosphere computing platforms, Г is given as at the small satellite accesses a stratosphere computing platform via other platforms through inter-platform links. This is necessary when small wer constraints. The compute resource (or platform) access latency Г is . ( , , ) and ℎ , , are the size of data transmitted and d between the th and ( + )th stratosphere computing platforms at z , ϑ e , α i a denote the link speed between the small satellite and computing platform entity q at the epoch t y . The amount of data from small satellite St d requiring access to computing resource aboard the computing platform entity q is denoted D St d , t y . The computing platform access latency for stratosphere computing platforms, Γ 1 is given as

Computing Platform Access Latency
This section develops the performance model describing the access latency associated with using the computing resources aboard computing platforms, i.e., data centres. The formulation is different from that associated with using the space edge computing platform found in Wang et al [19]. In the formulation here, data centres are considered to be suitable as seen in [44] and not edge-computing nodes (existing in Wang et al [19]) are considered. The formulation extends the consideration of space edge computing nodes to that of accessing computing resources aboard data centres located in the stratosphere and in space (SHDC). The consideration of the SHDC here extends [44] where the suitability of a space-based data centre is recognized but without any mathematical formulation. The novelty of the formulation in comparison to existing work in Wang et al [19] is that it considers that satellites process their data on data centres instead of space edge computing platforms. However, it is recognized by Denby et al [44] that the use of space-based computing platforms is beneficial. This is because data centres host a significant number of servers and have more computing resources in comparison to the space edge-computing node.
The small satellite Ϛ can access computing resources from platforms sited in different locations i.e., terrestrial, stratosphere or space (i.e, SHDC). Let be the set of stratosphere-based computing platforms: The altitude of the small satellite Ϛ , SHDC , space vehicle, stratosphere-based computing platform , are ℎ(Ϛ ), ℎ , ℎ( ) and ℎ( ) respectively. In addition, let ℎ Ϛ , , , { , , , } denote the link speed between the small satellite and computing platform entity at the epoch . The amount of data from small satellite Ϛ requiring access to computing resource aboard the computing platform entity is denoted (Ϛ , ). The computing platform access latency for stratosphere computing platforms, Г is given as It is also feasible that the small satellite accesses a stratosphere computing platform via other stratosphere computing platforms through inter-platform links. This is necessary when small satellite has transmit power constraints. The compute resource (or platform) access latency Г is given as Symmetry 2020, 12, x FOR PEER REVIEW 11 of 21

Computing Platform Access Latency
This section develops the performance model describing the access latency associated with using the computing resources aboard computing platforms, i.e., data centres. The formulation is different from that associated with using the space edge computing platform found in Wang et al [19]. In the formulation here, data centres are considered to be suitable as seen in [44] and not edge-computing nodes (existing in Wang et al [19]) are considered. The formulation extends the consideration of space edge computing nodes to that of accessing computing resources aboard data centres located in the stratosphere and in space (SHDC). The consideration of the SHDC here extends [44] where the suitability of a space-based data centre is recognized but without any mathematical formulation. The novelty of the formulation in comparison to existing work in Wang et al [19] is that it considers that satellites process their data on data centres instead of space edge computing platforms. However, it is recognized by Denby et al [44] that the use of space-based computing platforms is beneficial. This is because data centres host a significant number of servers and have more computing resources in comparison to the space edge-computing node.
The small satellite Ϛ can access computing resources from platforms sited in different locations i.e., terrestrial, stratosphere or space (i.e, SHDC). Let be the set of stratosphere-based computing platforms: The altitude of the small satellite Ϛ , SHDC , space vehicle, stratosphere-based computing platform , are ℎ(Ϛ ), ℎ , ℎ( ) and ℎ( ) respectively. In addition, let ℎ Ϛ , , , { , , , } denote the link speed between the small satellite and computing platform entity at the epoch . The amount of data from small satellite Ϛ requiring access to computing resource aboard the computing platform entity is denoted (Ϛ , ). The computing platform access latency for stratosphere computing platforms, Г is given as It is also feasible that the small satellite accesses a stratosphere computing platform via other stratosphere computing platforms through inter-platform links. This is necessary when small satellite has transmit power constraints. The compute resource (or platform) access latency Г is given as It is also feasible that the small satellite accesses a stratosphere computing platform via other stratosphere computing platforms through inter-platform links. This is necessary when small satellite has transmit power constraints. The compute resource (or platform) access latency Γ 1 is given as orm Access Latency evelops the performance model describing the access latency associated with g resources aboard computing platforms, i.e., data centres. The formulation is associated with using the space edge computing platform found in Wang et al ation here, data centres are considered to be suitable as seen in [44] and not des (existing in Wang et al [19]) are considered. The formulation extends the ce edge computing nodes to that of accessing computing resources aboard data the stratosphere and in space (SHDC). The consideration of the SHDC here the suitability of a space-based data centre is recognized but without any lation. The novelty of the formulation in comparison to existing work in Wang onsiders that satellites process their data on data centres instead of space edge s. However, it is recognized by Denby et al [44] that the use of space-based s is beneficial. This is because data centres host a significant number of servers puting resources in comparison to the space edge-computing node. ellite Ϛ can access computing resources from platforms sited in different trial, stratosphere or space (i.e, SHDC). Let be the set of stratosphere-based s: of the small satellite Ϛ , SHDC , space vehicle, stratosphere-based , are ℎ(Ϛ ), ℎ , ℎ( ) and ℎ( ) respectively. In addition, let , , , } denote the link speed between the small satellite and computing t the epoch . The amount of data from small satellite Ϛ requiring access to aboard the computing platform entity is denoted (Ϛ , ). The computing ncy for stratosphere computing platforms, Г is given as puting Platform Access Latency is section develops the performance model describing the access latency associated with he computing resources aboard computing platforms, i.e., data centres. The formulation is t from that associated with using the space edge computing platform found in Wang et al the formulation here, data centres are considered to be suitable as seen in [44] and not mputing nodes (existing in Wang et al [19]) are considered. The formulation extends the ration of space edge computing nodes to that of accessing computing resources aboard data located in the stratosphere and in space (SHDC). The consideration of the SHDC here [44] where the suitability of a space-based data centre is recognized but without any atical formulation. The novelty of the formulation in comparison to existing work in Wang ] is that it considers that satellites process their data on data centres instead of space edge ing platforms. However, it is recognized by Denby et al [44] that the use of space-based ing platforms is beneficial. This is because data centres host a significant number of servers e more computing resources in comparison to the space edge-computing node. e small satellite Ϛ can access computing resources from platforms sited in different s i.e., terrestrial, stratosphere or space (i.e, SHDC). Let be the set of stratosphere-based ing platforms:

Computing Platform Access Latency
This section develops the performance model describing the access latency associated with g the computing resources aboard computing platforms, i.e., data centres. The formulation is rent from that associated with using the space edge computing platform found in Wang et al In the formulation here, data centres are considered to be suitable as seen in [44] and not -computing nodes (existing in Wang et al [19]) are considered. The formulation extends the ideration of space edge computing nodes to that of accessing computing resources aboard data res located in the stratosphere and in space (SHDC). The consideration of the SHDC here nds [44] where the suitability of a space-based data centre is recognized but without any hematical formulation. The novelty of the formulation in comparison to existing work in Wang [19] is that it considers that satellites process their data on data centres instead of space edge puting platforms. However, it is recognized by Denby et al [44] that the use of space-based puting platforms is beneficial. This is because data centres host a significant number of servers have more computing resources in comparison to the space edge-computing node. The small satellite Ϛ can access computing resources from platforms sited in different tions i.e., terrestrial, stratosphere or space (i.e, SHDC). Let be the set of stratosphere-based puting platforms: The altitude of the small satellite Ϛ , SHDC , space vehicle, stratosphere-based puting platform , are ℎ(Ϛ ), ℎ , ℎ( ) and ℎ( ) respectively. In addition, let , , , { , , , } denote the link speed between the small satellite and computing form entity at the epoch . The amount of data from small satellite Ϛ requiring access to puting resource aboard the computing platform entity is denoted (Ϛ , ). The computing form access latency for stratosphere computing platforms, Г is given as puting Platform Access Latency is section develops the performance model describing the access latency associated with he computing resources aboard computing platforms, i.e., data centres. The formulation is t from that associated with using the space edge computing platform found in Wang et al the formulation here, data centres are considered to be suitable as seen in [44] and not mputing nodes (existing in Wang et al [19]) are considered. The formulation extends the ration of space edge computing nodes to that of accessing computing resources aboard data located in the stratosphere and in space (SHDC). The consideration of the SHDC here s [44] where the suitability of a space-based data centre is recognized but without any atical formulation. The novelty of the formulation in comparison to existing work in Wang 9] is that it considers that satellites process their data on data centres instead of space edge ting platforms. However, it is recognized by Denby et al [44] that the use of space-based ting platforms is beneficial. This is because data centres host a significant number of servers ve more computing resources in comparison to the space edge-computing node. e small satellite Ϛ can access computing resources from platforms sited in different s i.e., terrestrial, stratosphere or space (i.e, SHDC). Let be the set of stratosphere-based ting platforms:

Computing Platform Access Latency
This section develops the performance model describing the access latency associated with g the computing resources aboard computing platforms, i.e., data centres. The formulation is erent from that associated with using the space edge computing platform found in Wang et al . In the formulation here, data centres are considered to be suitable as seen in [44] and not e-computing nodes (existing in Wang et al [19]) are considered. The formulation extends the sideration of space edge computing nodes to that of accessing computing resources aboard data res located in the stratosphere and in space (SHDC). The consideration of the SHDC here nds [44] where the suitability of a space-based data centre is recognized but without any hematical formulation. The novelty of the formulation in comparison to existing work in Wang l [19] is that it considers that satellites process their data on data centres instead of space edge puting platforms. However, it is recognized by Denby et al [44] that the use of space-based puting platforms is beneficial. This is because data centres host a significant number of servers have more computing resources in comparison to the space edge-computing node. The small satellite Ϛ can access computing resources from platforms sited in different tions i.e., terrestrial, stratosphere or space (i.e, SHDC). Let be the set of stratosphere-based puting platforms: The altitude of the small satellite Ϛ , SHDC , space vehicle, stratosphere-based puting platform , are ℎ(Ϛ ), ℎ , ℎ( ) and ℎ( ) respectively. In addition, let Ϛ , , , { , , , } denote the link speed between the small satellite and computing form entity at the epoch . The amount of data from small satellite Ϛ requiring access to puting resource aboard the computing platform entity is denoted (Ϛ , ). The computing form access latency for stratosphere computing platforms, Г is given as Symmetry 2020, 12, x FOR PEER REVIEW 11 of 21

Computing Platform Access Latency
This section develops the performance model describing the access latency associated with using the computing resources aboard computing platforms, i.e., data centres. The formulation is different from that associated with using the space edge computing platform found in Wang et al [19]. In the formulation here, data centres are considered to be suitable as seen in [44] and not edge-computing nodes (existing in Wang et al [19]) are considered. The formulation extends the consideration of space edge computing nodes to that of accessing computing resources aboard data centres located in the stratosphere and in space (SHDC). The consideration of the SHDC here extends [44] where the suitability of a space-based data centre is recognized but without any mathematical formulation. The novelty of the formulation in comparison to existing work in Wang et al [19] is that it considers that satellites process their data on data centres instead of space edge computing platforms. However, it is recognized by Denby et al [44] that the use of space-based computing platforms is beneficial. This is because data centres host a significant number of servers and have more computing resources in comparison to the space edge-computing node.
The small satellite Ϛ can access computing resources from platforms sited in different locations i.e., terrestrial, stratosphere or space (i.e, SHDC). Let be the set of stratosphere-based computing platforms: The altitude of the small satellite Ϛ , SHDC , space vehicle, stratosphere-based computing platform , are ℎ(Ϛ ), ℎ , ℎ( ) and ℎ( ) respectively. In addition, let ℎ Ϛ , , , { , , , } denote the link speed between the small satellite and computing platform entity at the epoch . The amount of data from small satellite Ϛ requiring access to computing resource aboard the computing platform entity is denoted (Ϛ , ). The computing platform access latency for stratosphere computing platforms, Г is given as

Computing Platform Access Latency
This section develops the performance model describing the access latency associated with using the computing resources aboard computing platforms, i.e., data centres. The formulation is different from that associated with using the space edge computing platform found in Wang et al [19]. In the formulation here, data centres are considered to be suitable as seen in [44] and not edge-computing nodes (existing in Wang et al [19]) are considered. The formulation extends the consideration of space edge computing nodes to that of accessing computing resources aboard data centres located in the stratosphere and in space (SHDC). The consideration of the SHDC here extends [44] where the suitability of a space-based data centre is recognized but without any mathematical formulation. The novelty of the formulation in comparison to existing work in Wang et al [19] is that it considers that satellites process their data on data centres instead of space edge computing platforms. However, it is recognized by Denby et al [44] that the use of space-based computing platforms is beneficial. This is because data centres host a significant number of servers and have more computing resources in comparison to the space edge-computing node.
The small satellite Ϛ can access computing resources from platforms sited in different locations i.e., terrestrial, stratosphere or space (i.e, SHDC). Let be the set of stratosphere-based computing platforms: The altitude of the small satellite Ϛ , SHDC , space vehicle, stratosphere-based computing platform , are ℎ(Ϛ ), ℎ , ℎ( ) and ℎ( ) respectively. In addition, let ℎ Ϛ , , , { , , , } denote the link speed between the small satellite and computing platform entity at the epoch . The amount of data from small satellite Ϛ requiring access to computing resource aboard the computing platform entity is denoted (Ϛ , ). The computing platform access latency for stratosphere computing platforms, Г is given as It is also feasible that the small satellite accesses a stratosphere computing platform via other u − h Symmetry 2020, 12, x FOR PEER REVIEW 11 of

Computing Platform Access Latency
This section develops the performance model describing the access latency associated wit using the computing resources aboard computing platforms, i.e., data centres. The formulation different from that associated with using the space edge computing platform found in Wang et [19]. In the formulation here, data centres are considered to be suitable as seen in [44] and no edge-computing nodes (existing in Wang et al [19]) are considered. The formulation extends th consideration of space edge computing nodes to that of accessing computing resources aboard da centres located in the stratosphere and in space (SHDC). The consideration of the SHDC her extends [44] where the suitability of a space-based data centre is recognized but without an mathematical formulation. The novelty of the formulation in comparison to existing work in Wan et al [19] is that it considers that satellites process their data on data centres instead of space edg computing platforms. However, it is recognized by Denby et al [44] that the use of space-base computing platforms is beneficial. This is because data centres host a significant number of serve and have more computing resources in comparison to the space edge-computing node.
The small satellite Ϛ can access computing resources from platforms sited in differen locations i.e., terrestrial, stratosphere or space (i.e, SHDC). Let be the set of stratosphere-base computing platforms: It is also feasible that the small satellite accesses a stratosphere computing platform via othe 11 of 21 odel describing the access latency associated with ing platforms, i.e., data centres. The formulation is ace edge computing platform found in Wang et al considered to be suitable as seen in [44] and not [19]) are considered. The formulation extends the that of accessing computing resources aboard data ce (SHDC). The consideration of the SHDC here based data centre is recognized but without any rmulation in comparison to existing work in Wang ss their data on data centres instead of space edge d by Denby et al [44] that the use of space-based se data centres host a significant number of servers son to the space edge-computing node. ting resources from platforms sited in different (i.e, SHDC). Let be the set of stratosphere-based , , … , }

SHDC
, space vehicle, stratosphere-based , ℎ( ) and ℎ( ) respectively. In addition, let speed between the small satellite and computing of data from small satellite Ϛ requiring access to form entity is denoted (Ϛ , ). The computing ing platforms, Г is given as u 11 of 21 e model describing the access latency associated with puting platforms, i.e., data centres. The formulation is e space edge computing platform found in Wang et al are considered to be suitable as seen in [44] and not et al [19]) are considered. The formulation extends the es to that of accessing computing resources aboard data space (SHDC). The consideration of the SHDC here ace-based data centre is recognized but without any he formulation in comparison to existing work in Wang rocess their data on data centres instead of space edge nized by Denby et al [44] that the use of space-based ecause data centres host a significant number of servers parison to the space edge-computing node. mputing resources from platforms sited in different ace (i.e, SHDC). Let be the set of stratosphere-based = { , , … , } (17) Ϛ , SHDC , space vehicle, stratosphere-based ℎ , ℎ( ) and ℎ( ) respectively. In addition, let ink speed between the small satellite and computing ount of data from small satellite Ϛ requiring access to platform entity is denoted (Ϛ , ). The computing puting platforms, Г is given as ance model describing the access latency associated with omputing platforms, i.e., data centres. The formulation is g the space edge computing platform found in Wang et al res are considered to be suitable as seen in [44] and not g et al [19]) are considered. The formulation extends the odes to that of accessing computing resources aboard data in space (SHDC). The consideration of the SHDC here space-based data centre is recognized but without any f the formulation in comparison to existing work in Wang s process their data on data centres instead of space edge cognized by Denby et al [44] that the use of space-based s because data centres host a significant number of servers omparison to the space edge-computing node. computing resources from platforms sited in different space (i.e, SHDC). Let be the set of stratosphere-based e Ϛ , SHDC , space vehicle, stratosphere-based ), ℎ , ℎ( ) and ℎ( ) respectively. In addition, let e link speed between the small satellite and computing mount of data from small satellite Ϛ requiring access to ng platform entity is denoted (Ϛ , ). The computing omputing platforms, Г is given as u+x 11 of 21 ncy erformance model describing the access latency associated with oard computing platforms, i.e., data centres. The formulation is h using the space edge computing platform found in Wang et al ta centres are considered to be suitable as seen in [44] and not in Wang et al [19]) are considered. The formulation extends the uting nodes to that of accessing computing resources aboard data re and in space (SHDC). The consideration of the SHDC here y of a space-based data centre is recognized but without any velty of the formulation in comparison to existing work in Wang satellites process their data on data centres instead of space edge it is recognized by Denby et al [44] that the use of space-based . This is because data centres host a significant number of servers es in comparison to the space edge-computing node. access computing resources from platforms sited in different ere or space (i.e, SHDC). Let be the set of stratosphere-based satellite Ϛ , SHDC , space vehicle, stratosphere-based re ℎ(Ϛ ), ℎ , ℎ( ) and ℎ( ) respectively. In addition, let ote the link speed between the small satellite and computing . The amount of data from small satellite Ϛ requiring access to omputing platform entity is denoted (Ϛ , ). The computing phere computing platforms, Г is given as , W 11 of 21 atency performance model describing the access latency associated with aboard computing platforms, i.e., data centres. The formulation is with using the space edge computing platform found in Wang et al data centres are considered to be suitable as seen in [44] and not g in Wang et al [19]) are considered. The formulation extends the puting nodes to that of accessing computing resources aboard data here and in space (SHDC). The consideration of the SHDC here ility of a space-based data centre is recognized but without any novelty of the formulation in comparison to existing work in Wang at satellites process their data on data centres instead of space edge r, it is recognized by Denby et al [44] that the use of space-based ial. This is because data centres host a significant number of servers urces in comparison to the space edge-computing node. n access computing resources from platforms sited in different sphere or space (i.e, SHDC). Let be the set of stratosphere-based ll satellite Ϛ , SHDC , space vehicle, stratosphere-based are ℎ(Ϛ ), ℎ , ℎ( ) and ℎ( ) respectively. In addition, let denote the link speed between the small satellite and computing . The amount of data from small satellite Ϛ requiring access to e computing platform entity is denoted (Ϛ , ). The computing tosphere computing platforms, Г is given as u ,

REVIEW 11 of 21
ccess Latency ps the performance model describing the access latency associated with ources aboard computing platforms, i.e., data centres. The formulation is iated with using the space edge computing platform found in Wang et al here, data centres are considered to be suitable as seen in [44] and not (existing in Wang et al [19]) are considered. The formulation extends the ge computing nodes to that of accessing computing resources aboard data tratosphere and in space (SHDC). The consideration of the SHDC here suitability of a space-based data centre is recognized but without any n. The novelty of the formulation in comparison to existing work in Wang ers that satellites process their data on data centres instead of space edge owever, it is recognized by Denby et al [44] that the use of space-based beneficial. This is because data centres host a significant number of servers g resources in comparison to the space edge-computing node. latform Access Latency n develops the performance model describing the access latency associated with uting resources aboard computing platforms, i.e., data centres. The formulation is hat associated with using the space edge computing platform found in Wang et al ulation here, data centres are considered to be suitable as seen in [44] and not nodes (existing in Wang et al [19]) are considered. The formulation extends the space edge computing nodes to that of accessing computing resources aboard data in the stratosphere and in space (SHDC). The consideration of the SHDC here ere the suitability of a space-based data centre is recognized but without any rmulation. The novelty of the formulation in comparison to existing work in Wang it considers that satellites process their data on data centres instead of space edge forms. However, it is recognized by Denby et al [44] that the use of space-based orms is beneficial. This is because data centres host a significant number of servers omputing resources in comparison to the space edge-computing node. satellite Ϛ can access computing resources from platforms sited in different rrestrial, stratosphere or space (i.e, SHDC). Let be the set of stratosphere-based orms: tion develops the performance model describing the access latency associated with mputing resources aboard computing platforms, i.e., data centres. The formulation is that associated with using the space edge computing platform found in Wang et al formulation here, data centres are considered to be suitable as seen in [44] and not ting nodes (existing in Wang et al [19]) are considered. The formulation extends the of space edge computing nodes to that of accessing computing resources aboard data ed in the stratosphere and in space (SHDC). The consideration of the SHDC here where the suitability of a space-based data centre is recognized but without any l formulation. The novelty of the formulation in comparison to existing work in Wang hat it considers that satellites process their data on data centres instead of space edge latforms. However, it is recognized by Denby et al [44] that the use of space-based latforms is beneficial. This is because data centres host a significant number of servers re computing resources in comparison to the space edge-computing node. all satellite Ϛ can access computing resources from platforms sited in different , terrestrial, stratosphere or space (i.e, SHDC). Let be the set of stratosphere-based latforms:

Computing Platform Access Latency
This section develops the performance model describing the access latency associated with using the computing resources aboard computing platforms, i.e., data centres. The formulation is different from that associated with using the space edge computing platform found in Wang et al [19]. In the formulation here, data centres are considered to be suitable as seen in [44] and not edge-computing nodes (existing in Wang et al [19]) are considered. The formulation extends the consideration of space edge computing nodes to that of accessing computing resources aboard data centres located in the stratosphere and in space (SHDC). The consideration of the SHDC here extends [44] where the suitability of a space-based data centre is recognized but without any mathematical formulation. The novelty of the formulation in comparison to existing work in Wang et al [19] is that it considers that satellites process their data on data centres instead of space edge computing platforms. However, it is recognized by Denby et al [44] that the use of space-based computing platforms is beneficial. This is because data centres host a significant number of servers and have more computing resources in comparison to the space edge-computing node.
The small satellite Ϛ can access computing resources from platforms sited in different locations i.e., terrestrial, stratosphere or space (i.e, SHDC). Let be the set of stratosphere-based computing platforms:

Computing Platform Access Latency
This section develops the performance model describing the access latency associated with using the computing resources aboard computing platforms, i.e., data centres. The formulation is different from that associated with using the space edge computing platform found in Wang et al [19]. In the formulation here, data centres are considered to be suitable as seen in [44] and not edge-computing nodes (existing in Wang et al [19]) are considered. The formulation extends the consideration of space edge computing nodes to that of accessing computing resources aboard data centres located in the stratosphere and in space (SHDC). The consideration of the SHDC here extends [44] where the suitability of a space-based data centre is recognized but without any mathematical formulation. The novelty of the formulation in comparison to existing work in Wang et al [19] is that it considers that satellites process their data on data centres instead of space edge computing platforms. However, it is recognized by Denby et al [44] that the use of space-based computing platforms is beneficial. This is because data centres host a significant number of servers and have more computing resources in comparison to the space edge-computing node.
The small satellite Ϛ can access computing resources from platforms sited in different locations i.e., terrestrial, stratosphere or space (i.e, SHDC). Let be the set of stratosphere-based computing platforms: The altitude of the small satellite Ϛ , SHDC , space vehicle, stratosphere-based computing platform , are ℎ(Ϛ ), ℎ , ℎ( ) and ℎ( ) respectively. In addition, let ℎ Ϛ , , , { , , , } denote the link speed between the small satellite and computing platform entity at the epoch . The amount of data from small satellite Ϛ requiring access to computing resource aboard the computing platform entity is denoted (Ϛ , ). The computing platform access latency for stratosphere computing platforms, Г is given as u+x , t y are the size of data transmitted and inter-platform link speed between the uth and (u + x)th stratosphere computing platforms at the epoch t y respectively. h

EW 11 of 21
Latency e performance model describing the access latency associated with s aboard computing platforms, i.e., data centres. The formulation is with using the space edge computing platform found in Wang et al , data centres are considered to be suitable as seen in [44] and not ng in Wang et al [19]) are considered. The formulation extends the mputing nodes to that of accessing computing resources aboard data phere and in space (SHDC). The consideration of the SHDC here bility of a space-based data centre is recognized but without any e novelty of the formulation in comparison to existing work in Wang hat satellites process their data on data centres instead of space edge er, it is recognized by Denby et al [44] that the use of space-based icial. This is because data centres host a significant number of servers ources in comparison to the space edge-computing node. an access computing resources from platforms sited in different sphere or space (i.e, SHDC). Let be the set of stratosphere-based all satellite Ϛ , SHDC , space vehicle, stratosphere-based are ℎ(Ϛ ), ℎ , ℎ( ) and ℎ( ) respectively. In addition, let denote the link speed between the small satellite and computing h . The amount of data from small satellite Ϛ requiring access to u and h PEER REVIEW 11 of 21 rm Access Latency evelops the performance model describing the access latency associated with g resources aboard computing platforms, i.e., data centres. The formulation is associated with using the space edge computing platform found in Wang et al tion here, data centres are considered to be suitable as seen in [44] and not des (existing in Wang et al [19]) are considered. The formulation extends the ce edge computing nodes to that of accessing computing resources aboard data the stratosphere and in space (SHDC). The consideration of the SHDC here the suitability of a space-based data centre is recognized but without any lation. The novelty of the formulation in comparison to existing work in Wang onsiders that satellites process their data on data centres instead of space edge s. However, it is recognized by Denby et al [44] that the use of space-based s is beneficial. This is because data centres host a significant number of servers puting resources in comparison to the space edge-computing node. ellite Ϛ can access computing resources from platforms sited in different trial, stratosphere or space (i.e, SHDC). Let be the set of stratosphere-based s: of the small satellite Ϛ , SHDC , space vehicle, stratosphere-based , are ℎ(Ϛ ), ℎ , ℎ( ) and ℎ( ) respectively. In addition, let , , , } denote the link speed between the small satellite and computing t the epoch . The amount of data from small satellite Ϛ requiring access to u+x are the altitude of the uth and (u + x)th stratosphere computing platforms respectively. The compute resource access latency for the terrestrial cloud computing platforms Γ 2 is given as It is also feasible that the small satellite accesses the terrestrial cloud computing platform via high-altitude platform (HAP). This becomes necessary when there is transmit power limitation aboard small satellites. The compute resource access delay, in this case, is denoted Γ 2 and given as

. Computing Platform Access Latency
This section develops the performance model describing the access latency associated with ing the computing resources aboard computing platforms, i.e., data centres. The formulation is ferent from that associated with using the space edge computing platform found in Wang et al ]. In the formulation here, data centres are considered to be suitable as seen in [44] and not ge-computing nodes (existing in Wang et al [19]) are considered. The formulation extends the nsideration of space edge computing nodes to that of accessing computing resources aboard data tres located in the stratosphere and in space (SHDC). The consideration of the SHDC here tends [44] where the suitability of a space-based data centre is recognized but without any thematical formulation. The novelty of the formulation in comparison to existing work in Wang al [19] is that it considers that satellites process their data on data centres instead of space edge mputing platforms. However, it is recognized by Denby et al [44] that the use of space-based mputing platforms is beneficial. This is because data centres host a significant number of servers d have more computing resources in comparison to the space edge-computing node.
The small satellite Ϛ can access computing resources from platforms sited in different ations i.e., terrestrial, stratosphere or space (i.e, SHDC). Let be the set of stratosphere-based mputing platforms: The altitude of the small satellite Ϛ , SHDC , space vehicle, stratosphere-based mputing platform , are ℎ(Ϛ ), ℎ , ℎ( ) and ℎ( ) respectively. In addition, let Ϛ , , , { , , , } denote the link speed between the small satellite and computing tform entity at the epoch . The amount of data from small satellite Ϛ requiring access to mputing resource aboard the computing platform entity is denoted (Ϛ , ). The computing tform access latency for stratosphere computing platforms, Г is given as It is also feasible that the small satellite accesses a stratosphere computing platform via other atosphere computing platforms through inter-platform links. This is necessary when small ellite has transmit power constraints. The compute resource (or platform) access latency Г is en as , , ≠, . ( , , ) and ℎ , , are the size of data transmitted and er-platform link speed between the th and ( + )th stratosphere computing platforms at epoch respectively. ℎ( ) and ℎ( ) are the altitude of the th and ( + )th atosphere computing platforms respectively. The compute resource access latency for the terrestrial cloud computing platforms Г is given It is also feasible that the small satellite accesses the terrestrial cloud computing platform via h-altitude platform (HAP). This becomes necessary when there is transmit power limitation oard small satellites. The compute resource access delay, in this case, is denoted Г and given as z , t y Th St d , mmetry 2020, 12, x FOR PEER REVIEW 11 of 21

. Computing Platform Access Latency
This section develops the performance model describing the access latency associated with ing the computing resources aboard computing platforms, i.e., data centres. The formulation is fferent from that associated with using the space edge computing platform found in Wang et al 9]. In the formulation here, data centres are considered to be suitable as seen in [44] and not ge-computing nodes (existing in Wang et al [19]) are considered. The formulation extends the nsideration of space edge computing nodes to that of accessing computing resources aboard data ntres located in the stratosphere and in space (SHDC). The consideration of the SHDC here tends [44] where the suitability of a space-based data centre is recognized but without any athematical formulation. The novelty of the formulation in comparison to existing work in Wang al [19] is that it considers that satellites process their data on data centres instead of space edge mputing platforms. However, it is recognized by Denby et al [44] that the use of space-based mputing platforms is beneficial. This is because data centres host a significant number of servers d have more computing resources in comparison to the space edge-computing node.
The small satellite Ϛ can access computing resources from platforms sited in different cations i.e., terrestrial, stratosphere or space (i.e, SHDC). Let be the set of stratosphere-based mputing platforms: The altitude of the small satellite Ϛ , SHDC , space vehicle, stratosphere-based mputing platform , are ℎ(Ϛ ), ℎ , ℎ( ) and ℎ( ) respectively. In addition, let Ϛ , , , { , , , } denote the link speed between the small satellite and computing atform entity at the epoch . The amount of data from small satellite Ϛ requiring access to mputing resource aboard the computing platform entity is denoted (Ϛ , ). The computing atform access latency for stratosphere computing platforms, Г is given as It is also feasible that the small satellite accesses a stratosphere computing platform via other atosphere computing platforms through inter-platform links. This is necessary when small tellite has transmit power constraints. The compute resource (or platform) access latency Г is ven as , , ≠, . ( , , ) and ℎ , , are the size of data transmitted and ter-platform link speed between the th and ( + )th stratosphere computing platforms at e epoch respectively. ℎ( ) and ℎ( ) are the altitude of the th and ( + )th atosphere computing platforms respectively.
The compute resource access latency for the terrestrial cloud computing platforms Г is given It is also feasible that the small satellite accesses the terrestrial cloud computing platform via gh-altitude platform (HAP). This becomes necessary when there is transmit power limitation oard small satellites. The compute resource access delay, in this case, is denoted Г and given as z , t y + D

Computing Platform Access Latency
This section develops the performance model describing the access latency associated with using the computing resources aboard computing platforms, i.e., data centres. The formulation is different from that associated with using the space edge computing platform found in Wang et al [19]. In the formulation here, data centres are considered to be suitable as seen in [44] and not edge-computing nodes (existing in Wang et al [19]) are considered. The formulation extends the consideration of space edge computing nodes to that of accessing computing resources aboard data centres located in the stratosphere and in space (SHDC). The consideration of the SHDC here extends [44] where the suitability of a space-based data centre is recognized but without any mathematical formulation. The novelty of the formulation in comparison to existing work in Wang et al [19] is that it considers that satellites process their data on data centres instead of space edge computing platforms. However, it is recognized by Denby et al [44] that the use of space-based computing platforms is beneficial. This is because data centres host a significant number of servers and have more computing resources in comparison to the space edge-computing node.
The small satellite Ϛ can access computing resources from platforms sited in different locations i.e., terrestrial, stratosphere or space (i.e, SHDC). Let be the set of stratosphere-based computing platforms: The altitude of the small satellite Ϛ , SHDC , space vehicle, stratosphere-based computing platform , are ℎ(Ϛ ), ℎ , ℎ( ) and ℎ( ) respectively. In addition, let ℎ Ϛ , , , { , , , } denote the link speed between the small satellite and computing platform entity at the epoch . The amount of data from small satellite Ϛ requiring access to computing resource aboard the computing platform entity is denoted (Ϛ , ). The computing platform access latency for stratosphere computing platforms, Г is given as It is also feasible that the small satellite accesses a stratosphere computing platform via other stratosphere computing platforms through inter-platform links. This is necessary when small satellite has transmit power constraints. The compute resource (or platform) access latency Г is given as , , ≠, . ( , , ) and ℎ , , are the size of data transmitted and inter-platform link speed between the th and ( + )th stratosphere computing platforms at the epoch respectively. ℎ( ) and ℎ( ) are the altitude of the th and ( + )th stratosphere computing platforms respectively.
The compute resource access latency for the terrestrial cloud computing platforms Г is given as It is also feasible that the small satellite accesses the terrestrial cloud computing platform via high-altitude platform (HAP). This becomes necessary when there is transmit power limitation aboard small satellites. The compute resource access delay, in this case, is denoted Г and given as z , α i a , t y Th Symmetry 2020, 12, x FOR PEER REVIEW 11 of 21

Computing Platform Access Latency
This section develops the performance model describing the access latency associated with using the computing resources aboard computing platforms, i.e., data centres. The formulation is different from that associated with using the space edge computing platform found in Wang et al [19]. In the formulation here, data centres are considered to be suitable as seen in [44] and not edge-computing nodes (existing in Wang et al [19]) are considered. The formulation extends the consideration of space edge computing nodes to that of accessing computing resources aboard data centres located in the stratosphere and in space (SHDC). The consideration of the SHDC here extends [44] where the suitability of a space-based data centre is recognized but without any mathematical formulation. The novelty of the formulation in comparison to existing work in Wang et al [19] is that it considers that satellites process their data on data centres instead of space edge computing platforms. However, it is recognized by Denby et al [44] that the use of space-based computing platforms is beneficial. This is because data centres host a significant number of servers and have more computing resources in comparison to the space edge-computing node.
The small satellite Ϛ can access computing resources from platforms sited in different locations i.e., terrestrial, stratosphere or space (i.e, SHDC). Let be the set of stratosphere-based computing platforms: The altitude of the small satellite Ϛ , SHDC , space vehicle, stratosphere-based computing platform , are ℎ(Ϛ ), ℎ , ℎ( ) and ℎ( ) respectively. In addition, let ℎ Ϛ , , , { , , , } denote the link speed between the small satellite and computing platform entity at the epoch . The amount of data from small satellite Ϛ requiring access to computing resource aboard the computing platform entity is denoted (Ϛ , ). The computing platform access latency for stratosphere computing platforms, Г is given as It is also feasible that the small satellite accesses a stratosphere computing platform via other stratosphere computing platforms through inter-platform links. This is necessary when small satellite has transmit power constraints. The compute resource (or platform) access latency Г is given as , , ≠, . ( , , ) and ℎ , , are the size of data transmitted and inter-platform link speed between the th and ( + )th stratosphere computing platforms at the epoch respectively. ℎ( ) and ℎ( ) are the altitude of the th and ( + )th stratosphere computing platforms respectively.
The compute resource access latency for the terrestrial cloud computing platforms Г is given as It is also feasible that the small satellite accesses the terrestrial cloud computing platform via high-altitude platform (HAP). This becomes necessary when there is transmit power limitation aboard small satellites. The compute resource access delay, in this case, is denoted Г and given as Th 11 of 21 ance model describing the access latency associated with computing platforms, i.e., data centres. The formulation is g the space edge computing platform found in Wang et al tres are considered to be suitable as seen in [44] and not ng et al [19]) are considered. The formulation extends the nodes to that of accessing computing resources aboard data d in space (SHDC). The consideration of the SHDC here a space-based data centre is recognized but without any of the formulation in comparison to existing work in Wang tes process their data on data centres instead of space edge ecognized by Denby et al [44] that the use of space-based is because data centres host a significant number of servers comparison to the space edge-computing node. computing resources from platforms sited in different r space (i.e, SHDC). Let be the set of stratosphere-based ite Ϛ , SHDC , space vehicle, stratosphere-based Ϛ ), ℎ , ℎ( ) and ℎ( ) respectively. In addition, let e link speed between the small satellite and computing amount of data from small satellite Ϛ requiring access to ting platform entity is denoted (Ϛ , ). The computing computing platforms, Г is given as ellite accesses the terrestrial cloud computing platform via comes necessary when there is transmit power limitation ource access delay, in this case, is denoted Г and given as z , α i a , t y is the link throughput between the stratosphere cloud platform Symmetry 2020, 12, x FOR PEER REVIEW 11 of

Computing Platform Access Latency
This section develops the performance model describing the access latency associated w using the computing resources aboard computing platforms, i.e., data centres. The formulation different from that associated with using the space edge computing platform found in Wang et [19]. In the formulation here, data centres are considered to be suitable as seen in [44] and n edge-computing nodes (existing in Wang et al [19]) are considered. The formulation extends t consideration of space edge computing nodes to that of accessing computing resources aboard da centres located in the stratosphere and in space (SHDC). The consideration of the SHDC he extends [44] where the suitability of a space-based data centre is recognized but without a mathematical formulation. The novelty of the formulation in comparison to existing work in Wa et al [19] is that it considers that satellites process their data on data centres instead of space ed computing platforms. However, it is recognized by Denby et al [44] that the use of space-bas computing platforms is beneficial. This is because data centres host a significant number of serv and have more computing resources in comparison to the space edge-computing node.
The small satellite Ϛ can access computing resources from platforms sited in differe locations i.e., terrestrial, stratosphere or space (i.e, SHDC). Let be the set of stratosphere-bas computing platforms: It is also feasible that the small satellite accesses a stratosphere computing platform via oth stratosphere computing platforms through inter-platform links. This is necessary when sm satellite has transmit power constraints. The compute resource (or platform) access latency Г given as rmance model describing the access latency associated with rd computing platforms, i.e., data centres. The formulation is sing the space edge computing platform found in Wang et al centres are considered to be suitable as seen in [44] and not Wang et al [19]) are considered. The formulation extends the ng nodes to that of accessing computing resources aboard data and in space (SHDC). The consideration of the SHDC here of a space-based data centre is recognized but without any lty of the formulation in comparison to existing work in Wang ellites process their data on data centres instead of space edge s recognized by Denby et al [44] that the use of space-based his is because data centres host a significant number of servers in comparison to the space edge-computing node. ess computing resources from platforms sited in different e or space (i.e, SHDC). Let be the set of stratosphere-based tellite Ϛ , SHDC , space vehicle, stratosphere-based ℎ(Ϛ ), ℎ , ℎ( ) and ℎ( ) respectively. In addition, let e the link speed between the small satellite and computing he amount of data from small satellite Ϛ requiring access to puting platform entity is denoted (Ϛ , ). The computing ere computing platforms, Г is given as satellite accesses the terrestrial cloud computing platform via becomes necessary when there is transmit power limitation resource access delay, in this case, is denoted Г and given as z , t y and D

R REVIEW 11 of 21
Access Latency ops the performance model describing the access latency associated with sources aboard computing platforms, i.e., data centres. The formulation is ciated with using the space edge computing platform found in Wang et al here, data centres are considered to be suitable as seen in [44] and not (existing in Wang et al [19]) are considered. The formulation extends the dge computing nodes to that of accessing computing resources aboard data stratosphere and in space (SHDC). The consideration of the SHDC here e suitability of a space-based data centre is recognized but without any on. The novelty of the formulation in comparison to existing work in Wang iders that satellites process their data on data centres instead of space edge owever, it is recognized by Denby et al [44] that the use of space-based beneficial. This is because data centres host a significant number of servers ing resources in comparison to the space edge-computing node. e Ϛ can access computing resources from platforms sited in different , stratosphere or space (i.e, SHDC). Let be the set of stratosphere-based . ( , , ) and ℎ , , are the size of data transmitted and ed between the th and ( + )th stratosphere computing platforms at vely. ℎ( ) and ℎ( ) are the altitude of the th and ( + )th platforms respectively. rce access latency for the terrestrial cloud computing platforms Г is given hat the small satellite accesses the terrestrial cloud computing platform via (HAP). This becomes necessary when there is transmit power limitation The compute resource access delay, in this case, is denoted Г and given as z , α i a , t y are the size of data transmitted from the small satellite to the HAP and from the HAP to the terrestrial data centre respectively.
The parameters Γ 1 , Γ 1 , Γ 2 and Γ 2 describe the latency associated with computing resource access latency in the context of existing work. Terrestrial cloud computing platform access is supported in references [19,44] when small satellites have compute resource constraints. In the proposed scheme, small satellites access idle computing resources on space vehicles and the SHDC. Let Γ 3 and Γ 4 denote the compute resource access delay for the space vehicle and the SHDC.
The scenarios in Γ 3 and Γ 4 do not consider the context where data is forwarded from the space vehicle to the SHDC. This is feasible when a new SHDC is deployed and it is necessary to transmit data from the space vehicle to the SHDC. In this case, the compute resource access latency is denoted Γ 4 and given as

Accessible Computing Resources in Space Segment
The use of SHDCs increases accessible space segment computing resources. In an existing mechanism [19], the small satellite's computing resources are used. In the case of orbital edge computing, the accessible computing resources is denoted C 1 ra and given as C I St g , t y is the amount of idle computing resources aboard other LEO satellites used for applications besides orbital edge computing. The small satellites used in orbital edge computing can also utilise the idle computing resources aboard satellites used in other applications. The total amount of accessible computing resources given that small satellites and space vehicles provide computing resources is denoted C 2 ra and given as In the event that space vehicles and SHDCs provide access to computing resources, the total amount of accessible computing resources is denoted C 3 ra and given as

Feasibility and Performance Evaluation
This section discusses feasibility, evaluation results and has two parts. The first and second part presents results on feasibility of accessing asteroid water for SHDC cooling and analysis of performance benefits in the quality of service (QoS), respectively.
The analysis in this section has two goals. The first goal is to investigate the feasibility of accessing asteroid water to realize zero WUE SHDC operation. This is done with the aim of identifying suitable asteroids, their near-Earth-orbit dates, and determines the maximum, minimum and mean duration of accessing asteroid water resources. The second goal is to examine how the use of SHDC enhances the quality of service from the satellite space computing perspective.

Feasibility of Accessing Asteroid Water Resources
This section presents asteroids whose water can be used for cooling SHDCs. The analysis conducted also examines the feasibility of accessing water from near-Earth-orbiting asteroids. The analysis to be conducted in this case requires accessing data on water bearing asteroids. This investigation is important and should be conducted to identify asteroids that have water which can be accessed and used to realize cooling in SHDCs. The conduct of analysis enabling the identification of these asteroids makes it feasible to achieve the goal of realizing a zero WUE. The data to be used in this regard is that of water bearing asteroid data which is obtained from the Asterank database [49], analysed, and presented in Table 1. Analysis examines the feasibility of mining water from asteroids for a 20-year period as shown in Table 2. The maximum, minimum and mean access intervals are 690 days and 81 days and 319.39 days, respectively. In Table 2, the access interval is in the format [x; y] for dates [a, b, c]. x and y are the number of days between dates a and b and dates b and c, respectively. The results on the length of days where asteroid water can be accessed for zero WUE SHDC operation is obtained from the analysis of results presented in Table 2.
The results of analysis that is presented in Table 1 aim to identify asteroids that have water suitable for use in cooling SHDCs. In addition, the near-Earth approaches dates and the feasible number of days for which asteroids (with water) can be approached is also presented. Asteroids are accessed with the aim of ensuring that SHDC operation in the absence of earth's water resources is feasible.

Performance Evaluation and Benefits-Computing-Resource-Related QoS
The performance evaluation also examines how the use of the proposed SHDCs enhances the quality of service (QoS) for satellite-computing-based applications. The analysis presented in this section is important to demonstrate that the use of the proposed SHDC enhances computing related QoS in the context of space=based computing. In the existing context, i.e., Wang et al. [19], where space edge computing paradigm is used, recourse to terrestrial computing platforms becomes necessary when computing resources aboard space edge computing platforms are exhausted. The existing scenario being considered in this simulation is one in which the use of computing resources aboard space edge computing platforms is infeasible. This arises when all computing resources aboard space edge computing platforms are currently being used for processing data obtained from deployed and in-orbit satellites. Two performance metrics have been examined. These are the computing resource access latency and the amount of accessible computing resources.
The parameters used to investigate the compute resource access latency and the associated performance benefits are investigated using the parameters shown in Table 3. In this regard, the simulation discusses the results of performance evaluation from the perspective of accessing the entity hosting the computing resources. In Table 3, the link speed is of the order of gigabits per second and megabits per second. This range of values is considered feasible for realistic satellite communications as seen in Saeed et al. [50]. Furthermore, the size of satellite data is of the order of kilobytes and megabytes. This is also considered feasible for satellite applications as seen in Saeed et al. [50].  The compute resource access latency is evaluated for the existing scheme without and with the use of forwarding links. The compute resource access latency (compute platform access latency) for terrestrial data centres, stratosphere-based data centres, and the SHDC without forwarding links is shown in Figure 6. The analysis shows that using HAP computing platforms and SHDC instead of terrestrial computing platforms reduces the compute resource access latency by 11.9% and 33.6% on average, respectively. In addition, accessing the SHDC instead of HAP computing platforms reduces computing resource access latency by 24.5% on average.    The results in Figures 7 and 8 show the forwarding latency when the HAP computing platform and terrestrial computing platforms are accessed through HAP forwarding links respectively. Results in Figures 7 and 8 shows that the forwarding latency increases with forwarding HAPs. Analysis of results in Figures 7 and 8 shows that increasing the number of forwarding HAPs from 1 to 3, 1 to 2, and 2 to 3 increases the forwarding latency by {96.1%, 61.3%, 90%} and {44.7%, 35.6%, 14.2%} on average respectively. The use of the SHDC instead of HAP and terrestrial data centres via forwarding reduces the computing platform access latency. Extensive simulations show that the compute resource access latency is reduced by up to 98.5% on average.    The accessible computing resources are also investigated as an important QoS metric. The launch and use of SHDCs increases the amount of computational resources available for satellite data processing. This is because the SHDCs can host a significant number of servers in comparison to existing space edge computing platforms found in Wang et al [19]. The accessible computing resources are investigated using the performance evaluation parameters presented in Table 4.   The evaluation also investigates how the use of SHDCs enhances space segment accessible computing resources. The simulation uses test SHDCs hosting a limited number of servers and five LEO space vehicles. Two space vehicles are utilised for executing algorithms and processing data related to space astronomy. Three LEO SHDCs (each with three servers) are considered. The utilised values are in Table 4. The investigation of accessible computing resources for the existing scheme is done considering two cases. In the first case, the existing orbital edge computing [19] is considered.
The second case is one in which the computing resources on space vehicles are accessed in addition to that of existing orbital edge computing. The accessible computing resources are also investigated as an important QoS metric. The launch and use of SHDCs increases the amount of computational resources available for satellite data processing. This is because the SHDCs can host a significant number of servers in comparison to existing space edge computing platforms found in Wang et al. [19]. The accessible computing resources are investigated using the performance evaluation parameters presented in Table 4.
The result of the accessible computing resources is shown in Figures 9 and 10. The simulation also investigates how the use of up to two SHDCs enhances accessible computing resources. The result in this case is shown in Figure 10. Analysis shows that using one SHDC and two SHDCs instead of existing scheme without and with space vehicles increases accessible computing resources by {65.3%, 46.7%} and {77%, 64.7%} on average, respectively. In addition, increasing the number of SHDCs from one to two improves accessible computing resources by 33.8% on average.
The result of the accessible computing resources is shown in Figures 9 and 10. The simulation also investigates how the use of up to two SHDCs enhances accessible computing resources. The result in this case is shown in Figure 10. Analysis shows that using one SHDC and two SHDCs instead of existing scheme without and with space vehicles increases accessible computing resources by {65.3%, 46.7%} and {77%, 64.7%} on average, respectively. In addition, increasing the number of SHDCs from one to two improves accessible computing resources by 33.8% on average.   also investigates how the use of up to two SHDCs enhances accessible computing resources. The result in this case is shown in Figure 10. Analysis shows that using one SHDC and two SHDCs instead of existing scheme without and with space vehicles increases accessible computing resources by {65.3%, 46.7%} and {77%, 64.7%} on average, respectively. In addition, increasing the number of SHDCs from one to two improves accessible computing resources by 33.8% on average.

Conclusions
The discussion proposes solutions to reduce the high water footprint for cloud data centres and sites data centres in space habitats. The space habitat data centre is cooled using water mined from asteroids. The feasibility of using space habitat data centres is studied by asteroids with water content. Data analysis shows that water from asteroids can be accessed once a year. The use of space habitat data centres also increases the accessible computing resources in the space segment.
Author Contributions: Conceptualization A.P.; validation, A.A., writing-original draft and, editing-A.A. and K.O., review, project administration and funding acquisition. All authors have read and agreed to the published version of the manuscript.