1 Introduction

Data centers play an important role in cloud computing platforms (CCPs). This is because they perform the functionality of data storage and algorithm execution. Data centers have been observed to consume a high amount of electricity [1,2,3] and also have a high water footprint [4,5,6]. The need to reduce the water footprint of data centers has received significant research attention [7,8,9]. An important direction in reducing the water footprint of data centers is to adopt the use of non-terrestrial data centers. This has received sufficient consideration as seen in [10,11,12,13,14,15]. The uses of the stratosphere platforms as computing platforms and data centers have received consideration in [11, 12]. In this case, stratospheric platforms are observed to have the benefit of improved power usage effectiveness (PUE) [13]. This is because they benefit from free stratospheric cooling. Hence, energy aboard stratosphere based data centers is mainly used for powering the onboard server load.

Nevertheless, the power efficiency aboard stratosphere based data centers can be further improved. The further improvement being proposed in this case aims to reduce the amount of electricity and power being used to maintain the server payload at a given location and altitude. The presented research proposed an approach to improve the power efficiency and the PUE of stratosphere based data centers (SBDCs) by considering the mechanical payload of the servers. The paper makes the following contributions:

  1. 1.

    First, the paper proposes the three parameter model for analysing the PUE of SBDCs. The existing perspective considers electrical energy usage as being distributed between the tasks of powering the SBDC cooling system and ensuring the operation of the SBDC server payload. In this perspective, additional tasks that utilize electricity are considered auxilliary and as supporting functions for the SBDC. The proposed perspective considers that PUE is influenced by three energy consumption components aboard the SBDC. These are: (1) Powering the server payload, (2) Cooling the server payload, and (3) maintaining the mechanical payload of the computing subsystem comprising the servers in the considered SBDC. The proposed three parameter model aims to reduce the amount of electrical energy expended in monitoring the mechanical payload of servers constituting the computing system. This is done with the aim of enhancing the PUE of the SBDC while considering a mode holistic perspective to energy usage in the SBDC.

  2. 2.

    Second, the research proposes an intelligent server analytic architecture. This architecture presents a framework which ensures that light weight servers are selected for use aboard the SBDC. The role of the proposed architecture is important in the case of the SBDC because it reduces the physical weight of the server payload. This results in a reduction of the energy being used to maintain the SBDC at a given altitude and location. The observed reduction occurs because of the lower weight of lighter server payload components. The proposed architecture considers the weight of the server payload comprising servers from different vendors. In addition, the architecture considers the reliability of the server from heterogeneous vendors. Due to the large search space for different server models, an intelligent approach that is integrated with the internet is considered. The intelligent approach evaluates server suitability by accessing information on the weights and dimensions. The goal of the intelligent approach is realized via the design of server specifications search crawlers (S3C).

  3. 3.

    Third, the paper formulates the PUE for two considered scenarios. The first scenario considers the existing case where the weight of the server payload is not considered. The second scenario considers the proposed case. Furthermore, the presented research evaluates the performance benefits of using the proposed intelligent architecture. This is done via MATLAB simulation.

The rest of the paper is organized as follows. Section 2 discusses the existing work. Section 3 describes the problem being addressed. Section 4 presents the proposed solution. Section 5 evaluates the performance benefits. Section 6 is the conclusion.

2 Existing Work

Pham et al. [16] introduce the paradigm of aerial computing realized via the use of aerial access networks. The aerial access networks comprise low altitude platform, high altitude platforms (stratospheric platforms) and low earth orbiting satellites. In [16], the components of the aerial access network are integrated with nodes used in edge computing applications. Aerial computing in the context of [16] is intended to be integrated with sixth generation communication networks. This is being done with the aim of designing a data analytic platform for aerial networks and applications. However, the discussion has not examined how the proposed architecture influences the PUE and energy efficiency.

Cheng et al. [17] proposes the space—air ground integrated network architecture. The concerned network architecture achieves the goal of executing computing offloading for internet of things applications. The architecture integrates satellite, aerial and terrestrial networks. This integration enables the realization of ubiquitous coverage and addressing the challenges of: (1) remote coverage, (2) handling uneven data traffic, and (3) latency reduction via edge caching. The major aim of the research in [17] is the design of a computing offloading policy for internet of things application. In the considered context, the integrated network architecture considers how inadequate network coverage of terrestrial computing edge nodes causes an inability to use terrestrial computing edge nodes. In this case, satellite and aerial computing nodes and networks with remote coverage capability are deemed suitable. The candidate aerial and space computing nodes are satellite in low earth orbit and geostationary orbit alongside unmanned aerial vehicles and high altitude platforms. However, the use of aerial network assets is deployed with the aim of providing remote networking capabilities. The data storage, and computing aspects require further research consideration. In [17], aerial and space network nodes provide remote links to cloud computing assets. The presented research has not considered how to reduce the latency associated with executing the relaying of data in the research consideration.

Hassan et al. [18] proposes the design of networked and computing services for subscribers in an in-flight scenario. The computing services is provided for subscribers aboard an aircraft using satellite links In the considered case, a floating fog paradigm is proposed. Floating fog is realized using multiple ocean based floating fog stations. The floating fog station is hosted on the ocean and comprises computing payload. The ocean based computing payload executes the functionality of (1) Function virtualization, (2) Data Analysis, (3) Data storage and (4) Cache management. The use of floating fog stations is suitable for the case where flight takes place over a route spanning a significant maritime resource i.e. ocean. In addition, it is assumed that the span of the ocean exists on the lower altitude dimension corresponding to the flight path of the concerned aerial vehicle. In this case, an architecture that provides connection continuity is required. However, this requires additional research consideration.

Li et al. [19] present the context of an unmanned aerial vehicle enabled wireless sensor network (U-WSN). In the U-WSN, the unmanned aerial vehicle functions as a communication node. The research in [19] defines the requirements of the U-WSN architecture. The discussion presents the different roles of unmanned aerial vehicles (UAVs) in wireless sensor networks (WSNs). These roles involve the use of satellite networks and links. The discussion in [19] recognizes the role of flying servers. However, the integration of flying servers into U-WSNs requires further consideration.

The need to provide mobile edge computing services to migrating users is addressed by Nguyen et al. [20]. It is also recognized that terrestrial mobile edge computing systems are unsuitable for use in scenarios such as desert areas and emergency scenarios. A satellite and terrestrial network that incorporates the capability of mobile edge computing is proposed. It is recognized that the flight time of the unmanned aerial vehicle limits access to the aerial computing assets and entities. Hence, the use of the alternative aerial computing entities with improved long term coverage is desired. The suitability of high altitude platforms (stratospheric platforms) for use as data centers is recognized in [21]. This is a significant step towards the realization and use of non-terrestrial computing platforms. The discussion in [21] also recognizes the feasibility of free cooling as high altitude platform data centers are in a low temperature environment with temperatures in the range  − 15 °C to 50 °C. However, additional analysis towards evaluating the PUE and operational efficiency of non-terrestrial data centers i.e. high altitude platform data centers.

The usefulness of high altitude platforms as data centers is also recognized by Alam et al. [22]. In this case, high altitude platforms are used in the context of a super macro base station as a flying data center. In its role as a flying data center, the high altitude platform is expected to provide a backup computing capability for use in emergency and disaster related scenarios. The use of the high altitude platforms is intended to provide a use case for non-terrestrial related computing and communications. However, the role of aerial data centers in reducing operational cooling costs thereby enhancing energy efficiency of a cloud computing platform is important and should be explored.

Ke et al. [23] proposes the adoption and integration of high altitude communication nodes into edge computing networks for data storage and processing in internet of things applications. In the proposed network architecture, the edge servers are integrated into the high altitude platform communication node. The proposed network architecture incorporates an edge compute-high altitude platform. In this case, the computing capability of the network is limited to the computing capacity of the edge node. In this case, the high altitude platform mainly functions as a communication node with the edge computing server functioning in an auxilliary role. It is important to consider the case where the storage and processing of big amounts of data requiring the use of a data center with higher processing capacity is required.

The discussion in this aspect shows that the use of the high altitude platforms has received significant consideration in wireless networks. High altitude platforms are used as nodes in non-terrestrial communication networks [17,18,19,20,21,22] with support from edge nodes in mobile edge computing networks [23]. High altitude platforms have also received consideration for use as free-cooling stratosphere based computing platforms as seen in [11,12,13].

In addition, it can be seen that the use of stratospheric computing platforms i.e. high altitude platforms as data centers in future computing networks and applications has received consideration as seen in [11,12,13]. This is because of the nature of the stratosphere. The stratosphere comprises three regions i.e. the lower stratosphere where commercial aircraft flights are hosted, the middle stratosphere and the upper stratosphere. The stratospheric computing platforms being used as data centers are hosted in the middle stratosphere and upper stratosphere. The middle stratosphere and upper stratosphere are cold (low temperature) and dry regions [24]. Due to these environmental conditions, the considered regions are suitable for cooling stratospheric computing platforms and the dryness (indicating low moisture content) implies that water will not interfere and tamper with the function of the electronics aboard stratospheric computing platforms.

Furthermore, the stratosphere has been found to host life forms and present useful opportunity in studying how life may have arrived on earth [25]. Hence, it is important to preserve the region of the stratosphere for the purposes of the conduct of research in this direction. Nevertheless, it is important to utilize the environmental benefits of the stratosphere for the benefits of free cooling in computing platform related applications. This can be realized by putting smaller platforms and systems in the stratosphere. In this case, the smaller platforms and systems are being considered because they have a lower surface area thereby having reduced and limited interaction with the organisms in the stratosphere.

3 Problem Description

The challenge being addressed concerns a stratospheric cloud platform data center (SCP–DC). The SCP–DC comprises the computing sub-system (CoSS), cooling sub-system (CSS), network sub-system (NSS) and the payload mechanical support system (PMSS). The CoSS hosts the server payload that performs the functionality of the data storage and algorithm execution. The CSS hosts the heat exchanger payload and gear responsible for removing the heat arising due to server operation. The NSS hosts communication related payload enabling inter SCP–DC communications alongside uplink and downlink related data transfer. The PMSS is responsible for ensuring that the SCP–DC’s structure is maintained at a given altitude and location.

Let \(\alpha\) and \(\beta\) denote the set of CoSS and NSS communication units aboard the SCP–DC such that:

$$\alpha = \left\{ {\alpha_{1} ,\alpha_{2} , \ldots , \alpha_{I} } \right\}$$
(1)
$$\beta = \left\{ {\beta_{1} ,\beta_{2} , \ldots , \beta_{J} } \right\}$$
(2)

Each communication unit has sub-components. The jth communication unit, \(\beta_{j} , \beta_{j} \epsilon \beta\) has sub-components such that:

$$\beta_{j} = \left\{ {\beta_{j}^{1} ,\beta_{j}^{2} ,\beta_{j}^{3} , \ldots , \beta_{j}^{M} } \right\}$$
(3)

The PMSS also has server specific components considered alongside the structure of the SCP–DC. The components associated with the ith server, \(\alpha_{i} , \alpha_{i} \epsilon \alpha\) from this perspective is denoted as \(\gamma \left( {\alpha_{i} } \right)\). The power associated with operating, cooling and maintaining the server \(\alpha_{i}\) at the epoch \(t_{y} , t_{y} \epsilon t, t = \left\{ {t_{1} ,t_{2} , \ldots , t_{Y} } \right\}\) are given as: \(P_{1} \left( {\alpha_{i} ,t_{y} } \right), P_{2} \left( {\alpha_{i} ,t_{y} } \right)\) and \(P_{1} \left( {\gamma \left( {\alpha_{i} } \right),t_{y} } \right)\), respectively.

In addition, the operational power associated with the mth sub-component of the jth communication unit, \(\beta_{j}^{m}\), \(\beta_{j}^{m} \epsilon \beta_{j}\) at the epoch \(t_{y}\) is denoted as \(P_{1} \left( {\beta_{j}^{m} ,t_{y} } \right)\). In the consideration, the weight of the server payload dominates that of the components in the CSS, and NSS. Hence, the functionality of the PMSS is localized to the CoSS. In the existing perspective without considering the weight of server payload and the role of the PMSS, the PUE \(\vartheta_{1}\) is given as:

$$\vartheta_{1} = \mathop \sum \limits_{i = 1}^{I} \mathop \sum \limits_{j = 1}^{J} \mathop \sum \limits_{m = 1}^{M} \mathop \sum \limits_{y = 1}^{Y} \left( {\frac{{P_{1} \left( {\alpha_{i} ,t_{y} } \right) + P_{2} \left( {\alpha_{i} ,t_{y} } \right) + P_{1} \left( {\gamma \left( {\alpha_{i} } \right),t_{y} } \right) + P_{1} \left( {\beta_{j}^{m} ,t_{y} } \right)}}{{P_{1} \left( {\alpha_{i} ,t_{y} } \right)}}} \right)$$
(4)

The relation in (4) assumes that all servers, associated cooling and communication subsystems components are active. Let \(I\left( {v,t_{y} } \right) \epsilon \left\{ {0,1} \right\}, v\epsilon \left\{ {\alpha_{i} ,\beta_{j}^{m} } \right\}\) denote the activity status of the entity \(v\). The entity \(v\) is active and inactive when \(I\left( {v,t_{y} } \right) = 1\) and \(I\left( {v,t_{y} } \right) = 0\), respectively. Considering the inclusion of the activity status, the PUE \(\vartheta_{1}\) re-written as \(\vartheta_{1}{\prime}\) is now given as:

$$\vartheta_{1}{\prime} = \mathop \sum \limits_{i = 1}^{I} \mathop \sum \limits_{j = 1}^{J} \mathop \sum \limits_{m = 1}^{M} \mathop \sum \limits_{y = 1}^{Y} \left( {\frac{{P_{1} \left( {\alpha_{i} ,t_{y} } \right)I\left( {\alpha_{i} ,t_{y} } \right) + P_{2} \left( {\alpha_{i} ,t_{y} } \right)I\left( {\alpha_{i} ,t_{y} } \right) + P_{1} \left( {\gamma \left( {\alpha_{i} } \right),t_{y} } \right) + P_{1} \left( {\beta_{j}^{m} ,t_{y} } \right)I\left( {\beta_{j}^{m} ,t_{y} } \right)}}{{P_{1} \left( {\alpha_{i} ,t_{y} } \right)I\left( {\alpha_{i} ,t_{y} } \right)}}} \right)$$
(5)

In the case where the role of the PMSS is considered, the PUE before and after considering the activity status are denoted as \(\vartheta_{2}\) and \(\vartheta_{2}{\prime}\) are given as:

$$\vartheta_{2} = \mathop \sum \limits_{i = 1}^{I} \mathop \sum \limits_{j = 1}^{J} \mathop \sum \limits_{m = 1}^{M} \mathop \sum \limits_{y = 1}^{Y} \left( {\frac{{P_{1} \left( {\alpha_{i} ,t_{y} } \right) + P_{2} \left( {\alpha_{i} ,t_{y} } \right) + P_{1} \left( {\gamma \left( {\alpha_{i} } \right),t_{y} } \right)\left( {1 - \varsigma \left( {\gamma \left( {\alpha_{i} } \right),t_{y} } \right)} \right) + P_{1} \left( {\beta_{j}^{m} ,t_{y} } \right)}}{{P_{1} \left( {\alpha_{i} ,t_{y} } \right)}}} \right)$$
(6)
$$\vartheta_{2}{\prime} = \mathop \sum \limits_{i = 1}^{I} \mathop \sum \limits_{j = 1}^{J} \mathop \sum \limits_{m = 1}^{M} \mathop \sum \limits_{y = 1}^{Y} \left( {\frac{{A\left( {i,j,k,m,y} \right)}}{{P_{1} \left( {\alpha_{i} ,t_{y} } \right)}}} \right)$$
(7)
$$A\left( {i,j,k,m,y} \right) = \left( {P_{1} \left( {\alpha_{i} ,t_{y} } \right) + P_{2} \left( {\alpha_{i} ,t_{y} } \right)} \right)I\left( {\alpha_{i} ,t_{y} } \right) + P_{1} \left( {\gamma \left( {\alpha_{i} } \right),t_{y} } \right)\left( {1 - \varsigma \left( {\gamma \left( {\alpha_{i} } \right),t_{y} } \right)} \right) + P_{1} \left( {\beta_{j}^{m} ,t_{y} } \right)$$
(8)

where \(\varsigma \left( {\gamma \left( {\alpha_{i} } \right),t_{y} } \right)\) is the reduction in the electrical power expended in the PMSS due to the server weight reduction after the incorporation of the proposed ISAA architecture.

Due to the inclusion of more non-zero, non-negative parameters, the relations \({\vartheta }_{2}{\prime} > {\vartheta }_{1}{\prime},\) and \({\vartheta }_{2} > {\vartheta }_{1}\) holds true. In this case, it is desired that the PUE in (6) and (7) satisfy the conditions: \({\vartheta }_{2}>{\vartheta }_{sp}, {\vartheta }_{2}{\prime} >{\vartheta }_{sp}\) where \({\vartheta }_{sp}\) is the specified and desired PUE value for the SCP–DC. A mechanism that achieves this for the SCP–DC aerospace system is proposed.

4 Proposed Solution

The proposed mechanism which ensures that the SCP–DC’s PUE target is not exceeded is presented in this aspect. The mechanism enables the realization of the scenario described by the relation \({\vartheta }_{2}>{\vartheta }_{sp}\). The consideration of the PUE evaluated in \({\vartheta }_{2}\) leads to the notion of the proposed three parameter model being considered for the enhanced modelling of the SCP–DC. The discussion here is divided into two parts. The first part presents the proposed intelligent server analytic architecture. The second part focuses on the integration of the information elements in the proposed ISAA alongside the interaction with providers deploying the SCP–DC.

  1. A.

    Proposed Intelligent Server Analytic Architecture (ISAA)

In the proposed ISAA, the physical attributes of servers being used in the SCP–DCs CoSS is considered. The consideration of the server weights and influence of gravity is deemed necessary as SCP–DCs do not have a robust and sturdy physical supporting based as it is available in terrestrial data centers. In addition, the reduction of the server weights is beneficial from a launch perspective which has also been found to be applicable to the launching of space assets such as satellite. However, the case of the SCP–DC can be considered as a partial launch since the SCP–DC’s final destination is not beyond the earth’s atmosphere. From this perspective, it is also important that the SCP–DC hosts lightweight servers as the payload in its CoSS. The use of lightweight servers aboard the SCP–DC also has the benefit of yielding a smaller SCP–DC with reduced size, surface area and lower (limited reduction) with life forms in the stratosphere. This provides a form of sterilization for future life studies in the stratosphere.

The ISAA proposes the inclusion of the server weight as an important element in SCP–DC launch planning. This leads to the use of previously unconsidered logistical information fields in the context of non-terrestrial data centers. The ISAA proposes the inclusion of the logistics domain in the launch and use of non-terrestrial data centers where there are access challenged coupled with the absence of a solid supporting structure and base like land. Though, this is applicable in different context to non-terrestrial data centers, the focus here is on the SCP–DC in the context of the three factor model. In the case of the SCP–DC, the weight of each server is important in determining the SCP–DCs airborne load. In this case, servers are loaded aboard the stratosphere based high altitude platforms as additional payload. The inclusion of the logistical domain enables consideration of cases where the cloud computing service provider using SCP–DCs seeks to migrate payload to a new high altitude platform.

In addition, the proposed ISAA considers that the computing payload is owned by the cloud computing service provider (CCSP), the stratosphere based platform is owned by the aerospace platform service provider (APSP). The decoupling of CCSP and APSP is necessary to enable computing service providers focus on delivering excellent computing services to subscribers. The novelty of introducing the APSP lies in its capability to create an interaction between the aerospace domain and the computing domain. The interaction is intended to improve the PUE of the SCP–DC. Previously, these domains were not related with regard to the stratosphere based centers. Relations between the CCSP, and APSP showing the role of the mediating server selection entity (SSE) is presented in Fig. 1. In Fig. 1, the SSE takes the service specifications from the CCSP and the APSP and finds suitable server payloads. The CCSP’s service specification comprises the: (1) Desired storage capacity, (2) Desired computing capacity, (3) Total power consumed by the entire server payload, and (4) Desired payload weight and launch cost. The APSP ‘s service specifications mainly comprises the desired: (1) Payload host costs and (2) Desired payload weight.

  1. B.

    Server Selection Entity (SSE): Integration and Realization

Fig. 1
figure 1

Relations between the APSP, CCSP and the SSE in the proposed ISAA

Full size image

The SSE plays a critical role in the CCSP–APSP relations. It integrates information from several server original equipment manufacturers. In this case, each server manufacturer or vendor populates the SSE with information on server weight, dimensions, computing capacity and power consumption. The identified information elements can be provided via a manual SSE population or via an intelligent algorithm. The intelligent algorithms execute an autonomous population of the SSE vendor specific database (SVSD). In its implementation, the SSE is a cloud based entity that fuses specifications from the APSP and the CCSP. These fused specifications serve as the search query which forms the input into the compute payload selector entity (CPSE). The CPSE integrates with the internet and multiple SVSDs. The role of the SSE is shown in greater detail in Fig. 2.

Fig. 2
figure 2

Implementation and relations between sub-entities in the realization of the SSE

Full size image

The scenario presented in Fig. 2 shows a service provider perspective to the realization of the SSE’s intended functionality. Besides the APSP and CCSP, the service provider functionality of the SVSD aggregator (SVA) compiling the SVSD is introduced. The CPSE functionality enables the provisions of user server preference input. Each SVSD is realized via a novel document format enabling the extraction of the required information. The definition of a new document format is required to enable the intelligent SSE population algorithm extract the required data and make it available to the SSE via the SVA. Currently, server specification information is available and can be accessed in the portable document format (.pdf). The data available in the.pdf format is not easily extracted, accessed and used for the purposes of the SVSD and SSE in the manner being proposed in ISAA. As an alternative, the required information can be maintained aboard a cloud hosted database which is populated by the server vendor.

In Fig. 2, the combination of the APSP, CCSP and the CPSE are hosted aboard a cloud computing platform (via terrestrial data center, mini data center or single server installation). The SSE and the SVSDs are each hosted aboard own separating computing platforms. The contents of each SVSD are aggregated at the SVD aggregator (SVA). The user server search specifications are provided by a user to the CPSE via an internet link.

5 Performance Evaluation and Analysis

The performance evaluation is conducted via numerical simulation in MATLAB. The MATLAB simulation package is used to investigate the relations presented and formulated in (4) and (6). The relations in (5) and (7) have not been considered in this case. This is because, server utilization and load allocation are considered to be executed with optimal placement for the computing load being implicitly assumed.

The simulation is done using the parameters in Table 1. In the simulation, the SCP–DC is considered to comprise servers with different physical specifications and power ratings. Furthermore, the cooling effect is deemed to be dynamic with different aspects of the stratosphere having varying temperature thereby leading to varying effects of stratospheric cooling on the concerned SCP–DC. In the simulation, the SCP–DC maintains its physical support from the atmospheric effect of gliding and partly from the electrical energy being used for mechanical support.

Table 1 Simulation Parameters
Full size table

The performance results for the PUE given that the SCP–DC at an altitude of 16 km with specifications shown in Table 1 is shown in Fig. 3. The results in Fig. 3 show that the PUE for the SCP–DC before and after the incorporation of the proposed ISAA architecture exceed the ideal PUE value of unity i.e. 1. PUE values that exceed unity i.e. 1 are deemed to indicate less power efficiency in the data centers in comparison to PUE values of unity i.e. 1. This is because of the consideration of the mechanical load i.e. weight due to the server payload in the CoSS aboard the SCP–DC. However, the introduction of the proposed mechanism leads to an improvement in the PUE as seen in the results shown in Fig. 3. Analysis of the results in Fig. 3 shows that the proposed mechanisms improve the PUE by 43.9% on average.

Fig. 3
figure 3

Results showing the PUE in the existing mechanism (Existing Case) and proposed mechanism (Proposed Case)

Full size image

The energy expended in supporting the weight is deemed as a ratio of the potential energy for maintaining the SCP–DC at a given altitude. In this case, the SCP–DC is deemed to leverage on soaring and gliding effects of the stratosphere on the concerned SCP–DC. The result obtained in this case is shown in Table 2. A graphical plot of the results presented in Table 2 is shown in Fig. 4. Analysis of the results shown in Table 2 and Fig. 4 indicates that the proposed case results in an improved PUE in comparison to the existing case. There is a non-linear variation in the PUE variation with the SCP–DC altitude. This is because the parameter associated with the reduction in server weight due to the use of proposed mechanism and architecture is stochastic in the MATLAB simulation. Analysis of the results in Fig. 3 shows that the use of the proposed architecture i.e. ISAA in the Proposed Case results in an improvement in the PUE for the SCP–DC altitudes ranging from 16 to 30 km. The mean PUE is enhanced on the overall by 59.6%. Therefore, the use of the proposed mechanism enhances PUE for SCP–DC located at altitudes spanning the lower to middle stratosphere.

Table 2 Performance simulation result showing influence of SCP-DC altitude on PUE
Full size table
Fig. 4
figure 4

Simulation Results showing variation of PUE with the SCP–DC Altitude

Full size image

In addition, the research conducts investigation with the aim of determining the relations between the weight reduction proportion (%) and the PUE. This is because it is important to evaluate the proportion of weight reduction that results in a PUE which is close to the ideal value of unity (1). The result of the performance evaluation is shown in Figs. 5 and 6. Figure 5 shows the PUE for a weight reduction proportion in the range 10–98%. In this case, the PUE that has been obtained significantly exceeds and is distant from the ideal value of unity (1). The PUE in Fig. 6 is shown for weight reduction proportion values in the smaller range of 98.7–99.8%. In this case, the PUE values are significantly higher and also exceed unity (1) by a greater margin.

Fig. 5
figure 5

Simulated PUE for the case of weight reduction proportion with values 98.7–99.8%

Full size image
Fig. 6
figure 6

Simulated PUE for the case of weight reduction proportion with values 10–98%

Full size image

6 Conclusion

The presented research addresses the challenge of re-evaluating the power usage effectiveness associated with stratosphere based computing platforms. It is recognized that existing consideration has not included the need to provide power for maintaining the computing system comprising server payload in the stratosphere at a high altitude. This aspect is now considered with the goal of designing an intelligent architecture enabling the identification and use of light weight server systems in the stratosphere based computing platform mostly realized via the use of high altitude platforms. In addition, the research introduces a decoupled approach and considers the existence of service capabilities from the cloud computing service provider domain, aerospace service provider domain and computing payload identification domain. An intelligent architecture enabling the identification of light servers to be used in the computing system of the stratosphere based data centers is proposed and presented. In addition, the influence of the proposed architecture in enhancing the PUE when the weight is reduced is also investigated. This is done via performance simulation. Results show that the use of the proposed mechanisms improves the PUE by 43.9% on average. In addition, the use of the proposed architecture aboard a stratosphere based computing platform for varying altitude reduces the PUE on an overall average by 59.6%. Furthermore, the reduction of the weight of the servers significantly by up to 98% is also observed to enhance the PUE and move its value closer to unity (1).