Space Habitat Data Centers—For Future Computing

Abstract

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.

1. 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 processing and communications. In addition, the benefits of using the SHDC is formulated and investigated via performance simulation and evaluation.

2. Background

Avgerinou et al. [1] examine the power consumption in modern data centres. The discussion recognizes that the operation of data centres poses significant impact as regards increasing carbon dioxide emissions. In addition, data centre facilities comprise active and redundant powering and cooling systems. The power and cooling systems are recognized to consume a significant amount of power. The global power consumption of data centres increased by 19.7% over a five-year period spanning 2007 to 2012. The paper presents analysis of the power usage effectiveness of data centres for the period 2009–2016. The role of the data centre location in influencing the PUE is also examined. The presented results show that the lowest PUEs are obtained for data centres sited in Nordic countries (average PUE of 1.71) and northern/central Europe (average PUE of 1.72). The discussion by Avgerinou et al. [1] aims to determine the best practices that can be used to enhance data centre energy efficiency, i.e., ensure a low PUE figure is obtained and also reduce their carbon dioxide emissions. This is aimed at ensuring the environment friendliness of data centres to be deployed in the future. The focus of the discussion by Avgerinou et al. [1] is twofold. The first is determining the measures that can reduce the degrading effect of data centres on the environment. This is because they have identified other measures such as the use of energy from alternative and sustainable sources in future data centre operation. The second is determining best practices that can provide useful information for data centre operators enabling them to improve data centre facility energy efficiency. A similar perspective but with focus on analysing the PUE trends is also examined by Hintemann et al. [2].

Though the use of free cooling is recognized as suitable, its use here is limited to the terrestrial environment. However, the use of free cooling with relation to data centres applies to other domains such as the underwater environment. The suitability of the underwater environment has received research consideration in several studies by Periola [13], Periola et al. [14] and Cutler et al. [15].

The need to reduce the water footprint is considered by Wang et al. [3]. Water usage effectiveness (WUE) is recognized as a metric that is important to data centre operation. The challenge being addressed in Wang et al. [3] is the optimization of water usage and power consumption for a data centre coupled with a micro-grid system. The discussion presents a scheduling mechanism aiming to reduce the costs and fees associated with energy payment and water usage. The joint optimization i.e., reducing water and electricity costs is the novelty of the contribution in Wang et al. [3]. This is done with the aim of determining the combination of water and electricity usage that results in the most profitable operation of the data centre facility. The analysis of results in Wang et al. [3] recognizes that the ideal WUE figure is zero. However, a figure of WUE is assumed to be infeasible. This is because the focus of the analysis by Wang et al. [3] is the optimization of terrestrial data centre systems. A condition that can make the WUE ideally zero is the use of a cooling system that is not reliant on Earth’s water resources. However, the conduct of research to determine the existence and feasibility of cooling systems with a zero WUE was not considered in Wang et al. [3]. Instead, the focus is on determining the optimal water and power usage for a given data centre with different computing workload sizes.

Zhang et al. [11] recognize the potential and role of free cooling technologies in enhancing data centre power usage effectiveness. Different free cooling technology strategies such as direct fresh air, rotating wheel heat exchanger, heat pipe back rack and water driven free cooling system are recognized. The use of air free cooling and heat pipe back rack approach is recognized to have low power consumption; while the use of rotating wheel heat exchanger and water free cooling approach has high power consumption. The required use of pump in the case of water free cooling approach contributes to the high costs. However, the discussion in Zhang et al. [11] aims to identify free cooling technologies suitable for reducing data centre operational costs. Nevertheless, it is important to note that the use of water free cooling technologies is suitable for situations with a high cooling load. However, additional and required evaluation of the environmental effects of using water as a free cooling medium for data centres does not receive consideration.

The evaluated and examined literature focuses on the design of different free cooling strategies with a focus on terrestrial data centres. However, data centres can also benefit from free cooling in other locations such as the stratosphere [13] and in underwater environments [13,14]. In addition, data centres are not used in isolation but constitute important entities in cloud radio access networks as seen by Periola [13]. Therefore, it is important that data centres are sited close to subscribers to achieve low latency content access. However, previous focus has been on enhancing the PUE and reducing the WUE. Preferential locations for siting data centres are naturally cold-climate locations such as Scandinavia, North America, and Europe. This is because countries in these locations have a natural low environmental temperature. However, this is not so for subscribers in locations such as the African continent.

Therefore, subscribers in Africa seeking to access content from data centres located in distant European locations experience high content access latency. The use of underwater data centres is recognized in references [13,15] to be capable of reducing the latency for content access with regard to coastal subscribers. The siting of data centres in the ocean is different from that of using terrestrial data centres.

The use of underwater data centres poses long-term questions and concerns such as scalability and long-term environment friendliness and sustainability. For example, the suitability of the ocean will attract several data centre operators. This increases the competition for the use of suitable ocean zones and locations. Therefore, it is important to design suitable mechanisms enabling an equitable sharing of the ocean’s resources for several potential data centre operators in the future. The concern of long-term environment friendliness and sustainability arises because of the increase in ocean temperature due to the presence of multiple underwater data centres. This increase in ocean temperature poses an existential threat to life under the ocean. These challenges constitute a limitation on the large-scale use of underwater data centres for future computing and networking applications.

In addition, the discussion has not considered the processing of the increasing amount of data arising from deployed in–orbit satellites. This is considered in Wang et al. [19], who propose a space edge computing paradigm comprising multiple satellites. The satellites can acquire, store, process and forward data from end user stations. Examples of considered end user stations are vehicles, airplanes, ships, buoys and sensors. The satellites can virtualize on–board resources to form a resource pool. The motivation for using the proposed space edge computing system is to improve the quality of service for a space-based internet of things system. This results in lower latency and improved coverage of terrestrial–satellite communications. The satellites in the proposed edge computing mechanism are reconfigurable and software defined satellites. A challenge that is not considered in Wang et al. [19] arises with the sufficiency of computing resources aboard intelligent satellites that are nodes in the space edge computing network. For example, the size of the space-based edge-computing platform is not noted to increase with the number of launched and in-orbit satellites. An increase in the number of launched satellites can overwhelm the computing capacity of the computing nodes in the space edge computing network.

The use of multiple edge computing platforms with increased computing resources is suitable and beneficial to address such a challenge. However, the use of multiple space-based edge-computing platforms has the potential drawback of increased overhead arising due to the need to execute additional and required potential network coordination. The use of space-based data centres with increased computational resources is suitable in this regard. In addition, the siting of data centres in space is beneficial because of the low dependence on Earth’s water resources, thereby enabling the realization of zero WUE.

There has been an increasing maturation of space technology leading to more emerging applications. This has led to increased activity in space exploration and colonization via space vehicles and space habitats.

Space technologies find applications in planetary science and space colonization. Space colonization has received attention from private organizations interested in commercializing space. Yakolev [22] recognizes that the use of space houses (realizable via space habitats) is required for Mars exploration.

Smitherman et al. [23] recognize the role of space habitats in missions such as asteroid retrieval, access and deep space missions. Space vehicles also have varying capabilities depending on crew size and scientific payload. Space habitat design concepts are derivable from international space station and space launch system design perspectives. Concepts from these perspectives ultimately aim to provide a comfortable living space in orbit. The suitability of space habitats for deep space exploration is considered in Smitherman et al. [23]. The use of space habitat is proposed for asteroid retrieval, lunar and Martian vehicle servicing, and deep-space operation missions. The discussion here does not consider the suitability of space habitats or other space technologies to enable the execution of computing-related applications in space. The potential of space habitat technologies for computing applications has not been considered.

Griffin et al. [24] identify the knowledge gaps required for space habitat design. The presence of an autonomous communication system aboard space habitats is deemed to be of medium priority. However, the discussion in Griffin et al. [24] does not present space habitat network architecture. Instead, the focus of Griffin et al. [24] is on the launch and radiation aspects of space vehicle design. The study by Smitherman et al. [25] describes how habitat modules can be aggregated in realizing the deep space gateway. The large volume enclosed in the space habitat is used as a research facility to support deep space science related research and technology development. These applications focus on realizing space mining. However, other possible applications are not considered.

Kalam [26] discusses the application of space habitats in Mars exploration aiming at addressing the Earth-based challenge of energy security via lunar solar energy conversion. Lia et al. [27] propose reusing space habitat technologies to realize solutions that address Earth’s challenges. This is suitable because space stations are designed to operate in a harsh environment. The discussion in this regard shows that the advances in space technology enables the realization of solutions that play a significant role in developing novel and sustainable solutions that address Earth-based challenges.

Space applications aim to leverage on space for human benefit [28,29,30]. The emergence of several mega-constellation projects such as SpaceX’s satellite mega-constellation, OneWeb satellite mega-constellation, Telesat mega-constellation, and the Amazon Kuiper mega-constellation are recognized applications that exploit space for wireless communications is recognized by Morad et al. [29].

The applications in references [28,29,30] exploit space technologies to realize space commercialization [31,32,33,34] and space continental initiatives [35]. Davis [32] recognizes increasing private sector role in space commercialization. The discussion in Davis [32] identifies and addresses regulatory space commercialization challenges. Current efforts in space commercialization largely target communications and Earth observations [29,36].

Shammas et al. [36] examine space commercialization from the perspective of hosting more applications besides Earth observations and communications. In addition, Shammas et al. [36] note the increasing private sector in space supply provision and space mining. The applications in Shammas et al. [36] exclude scientific experiments that focus on deriving knowledge from space related activities [37,38].

The increasing deployment of terrestrial cloud platforms is expected to process space data and support access to multi-media content and cloud services for wireless subscribers. This requires installing more high-water footprint terrestrial data centres. A high-water footprint reduces water availability for other applications. Data centres can be sited in locations like the stratosphere to reduce the water footprint. However, the siting of data centres in the stratosphere poses interference risks to radio astronomy. Such interference is similar to that posed by mega-constellation satellite networks [38,39,40,41]. The realization of a space habitat computing platform does not pose interference risks to radio astronomy.

Adams [42] considers leveraging on the outer space environment aided by a nitrogen-filled pod for realizing cooling and eliminating explosion hazards. The use of nitrogen has high costs. Moreover, the production of the nitrogen in Adams [42] requires using Earth’s resources.

The use of computing platforms also enhances satellite data processing. Intelligent satellites are suitable as space edge-computing nodes [43,44] that reduce satellite to computing platform transmission latency. Wang et al. [19] describes capabilities enabling the use of satellites as edge nodes. The intelligent satellite is used in edge computing to realize low latency data processing in satellite internet of things. The shift to space of edge nodes reduces the long-term reliance on Earth’s resources. However, this perspective is not considered by Wang et al. [19].

Lai et al. [43] propose a novel network that incorporates edge computing in geostationary networks. The space edge node is a geostationary satellite. Denby et al. [44] propose the orbital edge-computing paradigm. Orbital edge computing proposes collocating sophisticated processing hardware along with sensors in small satellites. The discussion in Denby et al. [44] differentiates between cloud computing and edge nodes and recognizes that cloud platforms require backhaul network access. The discussion in reference [42,43,44] notes that siting data centres in space is appealing to computing. Research in reference [16,19,43,44] describes strategies explaining how edge computing enhances satellite network applications.

An alternative approach to accessing computing resources by space assets is presented by Straub et al. [45]. Straub et al. [45] propose using space vehicle’s idle computing resources by satellites for data processing. Space vehicles with idle computing resources constitute the space computing platform. A computing bottleneck occurs when space vehicles do not have sufficient resources to host external applications. The use of small satellite edge nodes can be used to resolve this bottleneck challenge.

However, Denby et al. [44] point out that the availability of computing platforms can enhance data processing. Therefore, an absence of in-orbit computing platforms degrades space data processing. This can be addressed by increasing space segment computing resources. Therefore, space data processing via space computing platforms reduces water footprint, computing platform access latency, and enhances accessible space segment computing resources.

Water is suitable for data centre free cooling at the risk of increased water insecurity. It is also important to reduce data transfer latency between small-satellite and computing platforms. The perspective in this paper is that advances in space technology can be used to address these challenges.

3. Problem Description

The paper considers data centre operators seeking to process space data and site data centres near water sources. Let $\alpha$ be the set of terrestrial data centre operators.

$$\alpha =\left\{{\alpha }_1,{\alpha }_2,\dots ,{\alpha }_A\right\}$$

(1)

The set of terrestrial data centres deployed by the $ath$ operator, ${\alpha }_a,{\alpha }_a ϵ \alpha$ is given by

$${\alpha }_a=\left\{{\alpha }_a^1,{\alpha }_a^2,\dots , {\alpha }_a^{\mathrm{I}}\right\}$$

(2)

The cooling indicator of the $it{h}^{}$ Earth-based terrestrial data centre from the $at{h}^{}$ operator ${\alpha }_a^i, {\alpha }_a^i ϵ {\alpha }_a$ is denoted $I\left({\alpha }_a^i\right) ϵ \left\{0,1\right\}$. The indicator values $I\left({\alpha }_a^i\right)=0$ and $I\left({\alpha }_a^i\right)=1$ signifies that data centre ${\alpha }_a^i$ is not and is water cooled respectively. In addition, let $\beta \left({\alpha }_a^i, t_y\right), t_yϵ t;t=\left\{t_1, t_2,\dots , t_Y\right\}$ be the water footprint of the Earth-based terrestrial data centre ${\alpha }_a^i$ at the epoch $t_y$. Furthermore, let $\gamma$ be the set of ground locations of terrestrial data centres.

$$\gamma =\left\{{\gamma }_1,{\gamma }_2,\dots , {\gamma }_B\right\}$$

(3)

The location indicator of data centre ${\alpha }_a^i$ at location ${\gamma }_b, {\gamma }_b ϵ \gamma$ at epoch $t_y$ is denoted $I\left({\alpha }_a^i,{\gamma }_b,t_y\right)ϵ \left\{0,1\right\}$. The data centre ${\alpha }_a^i$ is not located and is located at ${\gamma }_b$ at epoch $t_y$ when $I\left({\alpha }_a^i,{\gamma }_b,t_y\right)=0$ and $I\left({\alpha }_a^i,{\gamma }_b,t_y\right)=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

$${\displaystyle \sum }_{a=1}^A{\displaystyle \sum }_{i=1}^I{\displaystyle \sum }_{b=1}^B{\displaystyle \sum }_{y=1}^{Y}I\left({\alpha }_a^i\right)I\left({\alpha }_a^i,{\gamma }_b,t_y\right)\beta \left({\alpha }_a^i, t_y\right) \ge {\displaystyle \sum }_{b=1}^{B}w\left({\gamma }_b\right)$$

(4)

where $w\left({\gamma }_b\right)$ is the amount of water resources available at the $bt{h}^{}$ Earth-based terrestrial location ${\gamma }_b$.

Let $\varphi$ be the set of applications requiring access to water resources such that

$$\varphi =\left\{{\varphi }_1,{\varphi }_2,\dots ,{\varphi }_C\right\}$$

(5)

In addition, let $w\left({\varphi }_c,{\gamma }_b\right); {\varphi }_c ϵ \varphi$ be the water footprint of the $ct{h}^{}$ application ${\varphi }_c$ at location ${\gamma }_b$. The demand for water by other application gives rise to water access challenges given the condition

$$\left({\displaystyle \sum }_{a=1}^A{\displaystyle \sum }_{i=1}^I{\displaystyle \sum }_{b=1}^B{\displaystyle \sum }_{y=1}^{Y}I\left({\alpha }_a^i\right)I\left({\alpha }_a^i,{\gamma }_b,t_y\right)\beta \left({\alpha }_a^i, t_y\right)\right)+\left({\displaystyle \sum }_{c=1}^C{\displaystyle \sum }_{b=1}^{B}w\left({\varphi }_c,{\gamma }_b\right)\right)\ge {\displaystyle \sum }_{b=1}^{B}w\left({\gamma }_b\right).$$

(6)

The relation in (6) holds true under different conditions such as

$$\left({\displaystyle \sum }_{a=1}^A{\displaystyle \sum }_{i=1}^I{\displaystyle \sum }_{b=1}^B{\displaystyle \sum }_{y=1}^{Y}I\left({\alpha }_a^i\right)I\left({\alpha }_a^i,{\gamma }_b,t_y\right)\beta \left({\alpha }_a^i, t_y\right)\right)>\left({\displaystyle \sum }_{c=1}^C{\displaystyle \sum }_{b=1}^{B}w\left({\varphi }_c,{\gamma }_b\right)\right)$$

(7)

$$\left({\displaystyle \sum }_{a=1}^A{\displaystyle \sum }_{i=1}^I{\displaystyle \sum }_{b=1}^B{\displaystyle \sum }_{y=1}^{Y}I\left({\alpha }_a^i\right)I\left({\alpha }_a^i,{\gamma }_b,t_y\right)\beta \left({\alpha }_a^i, t_y\right)\right)\cong \left({\displaystyle \sum }_{c=1}^C{\displaystyle \sum }_{b=1}^{B}w\left({\varphi }_c,{\gamma }_b\right)\right)$$

(8)

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 $Ϛ$ and $\vartheta$ be the set of small satellites and space vehicles requiring data processing, respectively.

$$Ϛ=\left\{{Ϛ}_1,{Ϛ}_2,{Ϛ}_3,\dots ,{Ϛ}_D\right\}$$

(9)

$$\vartheta =\left\{{\vartheta }_1,{\vartheta }_2,{\vartheta }_3,\dots ,{\vartheta }_E\right\}$$

(10)

Let $C_I\left({Ϛ}_d, t_y\right)$ and $C_I\left({\vartheta }_e, t_y\right), {\vartheta }_e ϵ \vartheta$ be the amount of idle computing resources on-board the $dt{h}^{}$ small satellite ${Ϛ}_d$ and the $et{h}^{}$ space vehicle ${\vartheta }_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 applications that are being hosted by a given small satellite entity. For example, the small satellite ${Ϛ}_d$ hosting multiple applications can be described as

$${Ϛ}_d=\left\{{Ϛ}_d^1, {Ϛ}_d^2,\dots ,{Ϛ}_d^F\right\}$$

(11)

The computing resources required to execute the $ft{h}^{}$ application ${Ϛ}_d^f, {Ϛ}_d^f ϵ {Ϛ}_d$ at epoch $t_y$ is denoted ${\mathrm{C}}_1({Ϛ}_d^f, t_y)$. Small satellites expected to process data have a challenge accessing computing resources when

$$\mathrm{C}3: {\displaystyle \sum }_{d=1}^D{\displaystyle \sum }_{f=1}^F{\displaystyle \sum }_{y=1}^Y{C}_1\left({Ϛ}_d^f, t_y\right)\ge {\displaystyle \sum }_{d=1}^D{\displaystyle \sum }_{y=1}^Y{C}_I\left({Ϛ}_d, t_y\right)$$

(12)

$$\mathrm{C}4: {\displaystyle \sum }_{d=1}^D{\displaystyle \sum }_{f=1}^F{\displaystyle \sum }_{y=1}^Y{C}_1\left({Ϛ}_d^f, t_y\right) \ge {\displaystyle \sum }_{e=1}^E{\displaystyle \sum }_{y=1}^Y{C}_I\left({\vartheta }_e, t_y\right)$$

(13)

$$\mathrm{C}5: {\displaystyle \sum }_{d=1}^D{\displaystyle \sum }_{f=1}^F{C}_1\left({Ϛ}_d^f, t_y\right)<{\displaystyle \sum }_{d=1}^D{\displaystyle \sum }_{f=1}^F{C}_1\left({Ϛ}_d^f, t_{y+1}\right)<{\displaystyle \sum }_{d=1}^D{\displaystyle \sum }_{f=1}^F{C}_1\left({Ϛ}_d^f, t_{y+2}\right)$$

(14)

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.

4. 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.

4.1. 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.

4.2. 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 $\theta$ be the set of SHDCs.

$$\theta =\left\{{\theta }_1,{\theta }_2,{\theta }_3,\dots ,{\theta }_J\right\}$$

(15)

The computing capability and idle computing resources of the $jt{h}^{}$ SHDC, ${\theta }_j, {\theta }_{j }ϵ \theta$ is denoted $C_1\left({\theta }_j\right)$ and $C_I\left({\theta }_{j },t_y\right)$, 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 $\left(j+1\right)t{h}^{}$ SHDC ${\theta }_{j+1}, {\theta }_{j+1} ϵ \theta$ is most suitable for data processing if

$$\max \left({\displaystyle \sum }_{y=1}^Y{C}_I\left({\theta }_1,t_y\right), \dots ,{\displaystyle \sum }_{y=1}^Y{C}_I\left({\theta }_{j },t_y\right),{\displaystyle \sum }_{y=1}^Y{C}_I\left({\theta }_{j+1},t_y\right)\right)={\displaystyle \sum }_{y=1}^Y{C}_I\left({\theta }_{j+1},t_y\right)$$

(16)

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, 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=\left\{1,2,3,4,5,6,7,8\right\}$ 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.

4.3. 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.

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 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.

5.1. 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 ${Ϛ}_d$ can access computing resources from platforms sited in different locations i.e., terrestrial, stratosphere or space (i.e, SHDC). Let $\mathsf{𝒻}$ be the set of stratosphere-based computing platforms:

$$\mathsf{𝒻}=\left\{{\mathsf{𝒻}}_1,{\mathsf{𝒻}}_2,\dots ,{\mathsf{𝒻}}_{\mathrm{V}}\right\}$$

(17)

The altitude of the small satellite ${Ϛ}_d$, SHDC ${\theta }_j$, space vehicle, ${\vartheta }_e$ stratosphere-based computing platform ${\mathsf{𝒻}}_z,{\mathsf{𝒻}}_z ϵ \mathsf{𝒻}$ are $h\left({Ϛ}_d\right), h\left({\theta }_j\right), h\left({\vartheta }_e\right)$ and $h\left({\mathsf{𝒻}}_z\right)$ respectively. In addition, let $Th\left({Ϛ}_d,q,t_y\right), q ϵ \left\{{\theta }_j,{\mathsf{𝒻}}_z, {\vartheta }_e,{\alpha }_a^i\right\}$ 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 ${Ϛ}_d$ requiring access to computing resource aboard the computing platform entity $q$ is denoted $D\left({Ϛ}_d,t_y\right)$. The computing platform access latency for stratosphere computing platforms, ${\Gamma }_1$ is given as

$${\Gamma }_1={\displaystyle \sum }_{y=1}^Y{\displaystyle \sum }_{z=1}^V{\displaystyle \sum }_{d=1}^D\left(\frac{D\left({Ϛ}_d,t_y\right)}{Th\left({Ϛ}_d ,{\mathsf{𝒻}}_z,t_y\right)}+\frac{\left(h\left({Ϛ}_d\right)-h\left({\mathsf{𝒻}}_z\right)\right)}{3\times {10}^8}\right)$$

(18)

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 ${\Gamma }_1^{\prime }$ is given as

$$\begin{gathered} {\Gamma }_1^{\prime }={\displaystyle \sum }_{y=1}^Y{\displaystyle \sum }_{u=1}^V{\displaystyle \sum }_{d=1}^D\left(\frac{D\left({Ϛ}_d,t_y\right)}{Th\left({Ϛ}_d,{\mathsf{𝒻}}_u,t_y\right)}+\frac{D\left({\mathsf{𝒻}}_u,{\mathsf{𝒻}}_{u+x},t_y\right)}{Th\left({\mathsf{𝒻}}_u,{\mathsf{𝒻}}_{u+x},t_y\right)}+\frac{\left(h\left({Ϛ}_d\right)-h\left({\mathsf{𝒻}}_z\right)\right)}{3\times {10}^8} \\ +\frac{\left|h\left({\mathsf{𝒻}}_u\right)-h\left({\mathsf{𝒻}}_{u+x}\right)\right|}{3\times {10}^8}\right), \end{gathered}$$

(19)

${\mathsf{𝒻}}_u ϵ \mathsf{𝒻}, {\mathsf{𝒻}}_{u+x} ϵ \mathsf{𝒻}, {\mathsf{𝒻}}_u \ne , {\mathsf{𝒻}}_{u+x}. D\left({\mathsf{𝒻}}_u,{\mathsf{𝒻}}_{u+x},t_y\right)$ and $Th\left({\mathsf{𝒻}}_u,{\mathsf{𝒻}}_{u+x},t_y\right)$ are the size of data transmitted and inter-platform link speed between the $u{\mathrm{th}}^{}$ and $\left(u+x\right){\mathrm{th}}^{}$ stratosphere computing platforms at the epoch $t_y$ respectively. $h\left({\mathsf{𝒻}}_u\right)$ and $h\left({\mathsf{𝒻}}_{u+x}\right)$ are the altitude of the $u{\mathrm{th}}^{}$ and $\left(u+x\right){\mathrm{th}}^{}$ stratosphere computing platforms respectively.

The compute resource access latency for the terrestrial cloud computing platforms ${\Gamma }_2$ is given as

$${\Gamma }_2={\displaystyle \sum }_{y=1}^Y{\displaystyle \sum }_{i=1}^I{\displaystyle \sum }_{d=1}^D\left(\frac{D\left({Ϛ}_d,t_y\right)}{Th\left({Ϛ}_d ,{\alpha }_a^i,t_y\right)}+\frac{\left(h\left({Ϛ}_d\right)\right)}{3\times {10}^8}\right).$$

(20)

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 ${\Gamma }_2^{\prime }$ and given as

$${\Gamma }_2^{\prime }={\displaystyle \sum }_{y=1}^Y{\displaystyle \sum }_{a=1}^A{\displaystyle \sum }_{d=1}^D {\displaystyle \sum }_{z=1}^Z\left(\left(\frac{D\left({Ϛ}_d,{\mathsf{𝒻}}_z,t_y\right)}{Th\left({Ϛ}_d,{\mathsf{𝒻}}_z,t_y\right)}+\frac{D\left({\mathsf{𝒻}}_z,{\alpha }_a^i,t_y\right)}{Th\left({\mathsf{𝒻}}_z,{\alpha }_a^i,t_y\right)}\right)\right)+\left(\frac{\left(h\left({Ϛ}_d\right)\right)}{3\times {10}^8}\right).$$

(21)

$Th\left({\mathsf{𝒻}}_z,{\alpha }_a^i,t_y\right)$ is the link throughput between the stratosphere cloud platform ${\mathsf{𝒻}}_z$ and the $i{\mathrm{th}}^{}$ terrestrial cloud platform of the $ath$ operator.

$D\left({Ϛ}_d,{\mathsf{𝒻}}_z,t_y\right)$ and $D\left({\mathsf{𝒻}}_z,{\alpha }_a^i,t_y\right)$ 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 ${\Gamma }_1, {\Gamma }_1^{\prime }, {\Gamma }_2$ and ${\Gamma }_2^{\prime }$ 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 ${\Gamma }_3$ and ${\Gamma }_4$ denote the compute resource access delay for the space vehicle and the SHDC.

$${\Gamma }_3={\displaystyle \sum }_{y=1}^Y{\displaystyle \sum }_{e=1}^E{\displaystyle \sum }_{d=1}^D\left(\frac{D\left({Ϛ}_d,t_y\right)}{Th\left({Ϛ}_d ,{\mathsf{\vartheta }}_{\mathrm{e}},t_y\right)}+\frac{\left|h\left({Ϛ}_d\right)-h\left({\mathsf{\vartheta }}_{\mathrm{e}}\right)\right|}{3\times {10}^8}\right),$$

(22)

$${\Gamma }_4={\displaystyle \sum }_{y=1}^Y{\displaystyle \sum }_{j=1}^J{\displaystyle \sum }_{d=1}^D\left(\frac{D\left({Ϛ}_d,t_y\right)}{Th\left({Ϛ}_d,{\mathsf{\theta }}_{\mathrm{j}},t_y\right)}+\frac{\left|h\left({Ϛ}_d\right)-h\left({\mathsf{\theta }}_{\mathrm{j}}\right)\right|}{3\times {10}^8}\right).$$

(23)

The scenarios in ${\Gamma }_3$ and ${\Gamma }_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 ${\Gamma }_4^{\prime }$ and given as

$$\begin{gathered} {\Gamma }_4^{\prime }={\displaystyle \sum }_{d=1}^D{\displaystyle \sum }_{e=1}^E{\displaystyle \sum }_{j=1}^J{\displaystyle \sum }_{y=1}^Y\left(\frac{D\left({Ϛ}_d,t_y\right)}{Th\left({Ϛ}_d,{\mathsf{\vartheta }}_{\mathrm{e}},t_y\right)}\right)+\left(\frac{D\left({\vartheta }_e,{\theta }_j,t_y\right)}{Th\left({\vartheta }_e,{\theta }_j,t_y\right)}\right)+\left(\frac{\left|h\left({Ϛ}_d\right)-h\left({\vartheta }_e\right)\right|}{3\times {10}^8}\right) \\ +\left(\frac{\left|h\left({\theta }_j\right)-h\left({\vartheta }_e\right)\right|}{3\times {10}^8}\right). \end{gathered}$$

(24)

5.2. 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_{ra}^1$ and given as

$$C_{ra}^1={\displaystyle \sum }_{y=1}^Y\left(\left({\displaystyle \sum }_{d=1}^D{C}_I\left({Ϛ}_d,t_y\right)\right)+\left({\displaystyle \sum }_{g=1}^G{C}_I\left({Ϛ}_g^{\prime },t_y\right)\right)\right).$$

(25)

$C_I\left({Ϛ}_g^{\prime }, t_y\right)$ 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_{ra}^2$ and given as

$$C_{ra}^2={\displaystyle \sum }_{y=1}^Y\left(\left({\displaystyle \sum }_{d=1}^D{C}_I\left({Ϛ}_d,t_y\right)\right)+\left({\displaystyle \sum }_{g=1}^G{C}_I\left({Ϛ}_g^{\prime },t_y\right)\right)+\left({\displaystyle \sum }_{d=1}^D{C}_I\left({\mathsf{\vartheta }}_{\mathrm{e}},t_y\right)\right)\right).$$

(26)

In the event that space vehicles and SHDCs provide access to computing resources, the total amount of accessible computing resources is denoted $C_{ra}^3$ and given as

$$C_{ra}^3={\displaystyle \sum }_{y=1}^Y\left(\left({\displaystyle \sum }_{j=1}^J{C}_I\left({\theta }_j,t_y\right)\right)+\left({\displaystyle \sum }_{d=1}^D{C}_I\left({\mathsf{\vartheta }}_{\mathrm{e}},t_y\right)\right)\right).$$

(27)

6. 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.

6.1. 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. List of water bearing asteroids and the near-Earth approach dates.

s/n	Name	Near-Earth Approach Dates
1	1991 DB	6 March 2027; 29 February 2036; 17 June 2083—three approaches
2	Seleucus	24 March 2037; 6 April 2040; 8 May 2069; 27 March 2072–4 Approaches
3	1998 KU2	15 October 2025; 31 July 2042; 18 September 2069p; 28 June 2086; 18 October 2096—five approaches
4	2001 PD 1	3 October 2021; 23 September 2031; 1 September 2041; 1 November 2118—four approaches
5	1992 NA	27 October 2029; 14 August 2055; 25 October 2066; 12 October 2092; 08 August 2118—five approaches
6	2002-AH29	19 January 2032; 2 April 2047; 6 April 2062; 28 January 2092; 19 February 2107—five approaches
7	David-Harvey	16 December 2033; 10 December 2072; 17 December 2111—three approaches
8	1999 VN6	27 November 2031; 22 November 2047; 25 November 2056; 1 December 2072; 01 December 2088; 30 November 2104—six approaches.
9	2001 XS 1	08 December 2049; 08 December 2097—two approaches
10	2001 SJ262	17 October 2057; 06 October 2062; 14 October 2103—three approaches
11	1997AQ 18	11 May 2022; 21 December 2023; 16 August 2028; 14 June 2033; 16 December 2034; 1 May 2038; 30 September 2039; 31 July 2044; 30 December 2045; 31 May 2049; 14 December 2050; 26 April 2054; 18 September 2055; 5 January 2056; 24 July 2060; 28 December 2061; 27 May 2065; 14 December 2066; 26 April 2070; 18 September 2071; 5 January 2072; 27 July 2076; 29 December 2077; 1 June 2081; 15 December 2082; 30 April 2086; 28 September 2087; 1 January 2088; 6 August 2092; 17 December 2098; 7 May 2102—31 approaches
12	2002 DH2	6 July 2046; 8 April 2049; 10 Mar 2052; 22 February 2055; 6 July 2108—five approaches
13	Betulia	7 June 2028; 8 May 2090; 13 May 2103—three approaches
14	Sigurd	12 October 2022; 18 September 2027; 7 August 2032; 2 October 2045, 30 August 2050; 20 September 2068; 19 August 2073; 15 October 2086; 9 September 2091; 8 August 2096; 30 September 2109—11 approaches
15	1991XB	30 November 2067; 28 November 2118–2 Approaches
16	2000-YO-29	24 December 2027; 10 June 2040; 26 December 2049; 17 June 2062; 28 December 2071; 21 June 2084; 29 December 2093; 26 June 2106; 31 December 2115—eight approaches

. Analysis examines the feasibility of mining water from asteroids for a 20-year period as shown in

Table 2. Access dates and intervals for water bearing asteroids.

s/n	Access Dates	Access Intervals	Access Dates	Access Intervals
1	3 October 2021	[248;181]	27 November 2031	[81;227]
2	11 May 2022		19 January 2032
3	12 October 2022	[435;688]	7 August 2032	[322;212]
4	21 December 2023		14 June 2033
5	15 October 2025	[536;223]	16 December 2033	[390;469]
6	6 Mar 2027		16 December 2034
7	18 September 2027	[127;192]	29 February 2036	[414;431]
8	24 December 2027		24 Mar 2037
9	7 June 2028	[100;437]	1 May 2038	[539;215]
10	16 August 2028		30 September 2039
12	23 September 2031		6 2April 2040	95
			10 June 2040

. 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 $\left[x; y\right]$ for dates $\left[a, b, c\right]$. $x$ and $y$ are the number of days between dates $a$ and $b$ and dates $b$ and $c$, respectively.

Therefore, the data analysis shows that the operation of SHDCs while achieving a zero WUE due to non-reliance on Earth’s water resources is achievable and feasible. In addition, asteroid water access enabling the realization of zero WUE SHDC operation can be expected at least 81 days and by at most 690 days after water is accessed from a given asteroid. In a case where multiple asteroids fall within the near-Earth-orbit window, having access to asteroid water after a period of 319.39 days is feasible. 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.

6.2. 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. Compute resource access latency simulation parameters.

S/N	Parameter	Value
1	Number of satellites in space segment	10
2	Number of epochs	15
3	Maximum Size of Data–Satellite [1, 2, 3, 4, 5]	[1.48, 1.47, 1.25, 1.33, 1.45] Mbytes
4	Maximum Size of Data–Satellite [6, 7, 8, 9, 10]	[1.42, 1.47, 1.41, 1.46, 1.33] Mbytes
5	Minimum Size of Data–Satellite [1, 2, 3, 4, 5]	[1.04, 148.9, 353.6, 317.9, 852.81] Kbytes
6	Minimum Size of Data–Satellite [6, 7, 8, 9, 10]	[12.37, 82.31, 92.30, 113.00, 6.71] Kbytes
7	Mean Size of Data–Satellite [1, 2, 3, 4, 5]	[866.37,777.78,567.04,917.37,811.12] Kbytes
8	Mean Size of Data–Satellite [6,7, 8, 9, 10]	[718,665.93, 920.20, 844.61, 763.45] Kbytes
9	Maximum Link Speed–Satellite [1, 2, 3, 4, 5]	[2.99, 2.98, 2.92, 2.93, 2.68] Gbps
10	Maximum Link Speed–Satellite [6, 7, 8, 9, 10]	[2.82, 2.73, 2.69, 2.76, 2.83] Gbps
11	Minimum Link Speed–Satellite [1, 2, 3, 4, 5]	[380.17, 380.57, 930, 280.8, 124.44] Mbps
12	Minimum Link Speed–Satellite [6 7 8 9 10]	[32.67, 237.97, 776.48, 107.31,156.90] Mbps
13	Mean Link Speed–Satellite [1, 2, 3, 4, 5]	[1.47, 1.87, 2.01, 1.69, 1.28] Gbps
14	Mean Link Speed–Satellite [6, 7, 8, 9, 10]	[1.395, 1.49, 1.26, 1.25, 1.35] Gbps
15	Altitude–Satellite [1, 2, 3, 4, 5]	[780.5, 791.0, 711.6, 631.04, 766.63] km
16	Altitude–Satellite [6, 7, 8, 9, 10]	[798.7, 760.4, 614.1, 574.4, 759.9] km
21	Number of Space Habitat Data Centers	3
22	Space Habitat Data Center Altitude–[1, 2, 3]	[921.1, 252.5, 383.7] km
23	Number of High Altitude Platforms	4
24	High Altitude Platform Altitude (Mesosphere)–[1, 2, 3, 4]	[25.4, 74.1, 67.5, 71.9] km
25	Size of Data Transmitted by High Altitude Platforms–[1, 2. 3, 4]	[1.4, 0.997, 0.45, 1.96] Mbps
26	Inter–High Altitude Platform Link Speed	[1.92, 0.69, 0.08] Mbps

. 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 Figure 7 and Figure 8 show the forwarding latency when the HAP computing platform and terrestrial computing platforms are accessed through HAP forwarding links respectively. Results in Figure 7 and Figure 8 shows that the forwarding latency increases with forwarding HAPs. Analysis of results in Figure 7 and Figure 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 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. Simulation parameters for investigating accessible computing resources.

S/N	Parameter	Value
1	Number of Satellites	10
2	Number of Epochs	15
3	Number of Space Vehicles and Space Habitat Data Centres	5, 3
4	Maximum Satellite Computational Resources [1, 2, 3, 4, 5]	[85.7, 90.2, 97.7, 97.2,96.9] Gbytes
5	Maximum Satellite Computational Resources [6, 7, 8, 9, 10]	[96.2, 94.0, 84.8,90.7, 88.7] Gbytes
6	Minimum Satellite Computational Resources [1, 2, 3, 4, 5]	[1,1.76, 13.9, 0.32, 4.94] Gbytes
7	Minimum Satellite Computational Resources [6, 7, 8, 9, 10]	[7,1,1.02,1.27,0.45] Gbytes
8	Mean Computational Resources on Satellites [1, 2, 3, 4, 5]	[52.6, 52.4, 58.4, 39.2, 61.3] Gbytes
9	Mean Computational Resources on Satellites [6, 7, 8, 9, 10]	[50.3, 38.7, 43.2, 39.3, 57.0] Gbytes
10	Number of servers on Space Habitat Data Centres 1, 2, 3	3 Servers per SHDC
11	Computing Capability of Servers on SHDC 1-[1, 2, 3]	[65.5, 22.3, 50.1] Gbytes
12	Computing Capability of Servers on SHDC 2-[1, 2, 3]	[43.9, 24.3, 40.8] Gbytes
13	Computing Capability of Servers on SHDC 3-[1, 2, 3]	[11.0, 5.7, 42.0] Gbytes
14	Compute utilization of Servers on SHDC 1-[1, 2, 3]	[36.3%, 21.3%, 7%]
15	Compute utilization of Servers on SHDC 2-[1, 2, 3]	[47.7%, 72.5%, 24.8%]
16	Compute utilization of Servers on SHDC 3-[1, 2, 3]	[18.8%, 5.2%, 43.6%]
17	Compute Resources on Space Vehicles-[1, 2, 3, 4, 5]	[49.8, 32.6, 72.2, 7.5, 51.1] Gbytes
18	Space Vehicle 1 Fully utilised (No computing resources)	Yes
19	Space Vehicle 2 Fully utilised (No computing resources)	Yes
20	Space Vehicle 3 Fully utilised (No computing resources)	No
21	Space Vehicle 4 Fully utilised (No computing resources)	No
22	Space Vehicle 5 Fully utilised (No computing resources)	No
23	Compute Resource Utilisation on Space Vehicles-[3, 4, 5]	[63.8%, 37.2%, 28.8%]

. 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 Figure 9 and Figure 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.

7. 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.