Earth Orbiting Support Systems for commercial low Earth orbit data relay: Assessing architectures through tradespace exploration

Author's Accepted Manuscript

Earth Orbiting support Systems for commercial low earth orbit data relay: Assessing Architectures through tradespace exploration Gianluca Palermo, Alessandro Golkar, Paolo Gaudenzi

www.elsevier.com/locate/actaastro

PII: DOI: Reference:

S0094-5765(15)00064-8 http://dx.doi.org/10.1016/j.actaastro.2015.02.011 AA5349

To appear in:

Acta Astronautica

Received date: 16 August 2014 Revised date: 20 November 2014 Accepted date: 9 February 2015 Cite this article as: Gianluca Palermo, Alessandro Golkar, Paolo Gaudenzi, Earth Orbiting support Systems for commercial low earth orbit data relay: Assessing Architectures through tradespace exploration, Acta Astronautica, http: //dx.doi.org/10.1016/j.actaastro.2015.02.011 This is a PDF file of an unedited manuscript that has been accepted for publication. As a service to our customers we are providing this early version of the manuscript. The manuscript will undergo copyediting, typesetting, and review of the resulting galley proof before it is published in its final citable form. Please note that during the production process errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain.

Earth Orbiting Support Systems for Commercial Low Earth Orbit Data Relay: Assessing Architectures through Tradespace Exploration

Gianluca Palermo PhD Student, Sapienza Università di Roma, Via Eudossiana 18, 00184 Rome Italy, +39-06-44585738, [email protected] Alessandro Golkar, PhD Assistant Professor, Skolkovo Institute of Science and Technology, 100 Novaya Ulitsa, Skolkovo Russia, +7-495-280-1481, [email protected] Visiting Scholar, Massachusetts Institute of Technology, 77 Massachusetts Avenue, Cambridge MA, United States, [email protected] Paolo Gaudenzi, PhD Professor, Sapienza Università di Roma, Via Eudossiana 18, 00184 Rome Italy, +39-06-44585738, [email protected]

Abstract As small satellites and Sun Synchronous Earth Observation systems are assuming an increased role in nowadays space activities, including commercial investments, it is of interest to assess how infrastructures could be developed to support the development of such systems and other spacecraft that could benefit from having a data relay service in Low Earth Orbit (LEO), as opposed to traditional Geostationary relays. This paper presents a tradespace exploration study of the architecture of such LEO commercial satellite data relay systems, here defined as Earth Orbiting Support Systems (EOSS). The paper proposes a methodology to formulate architectural decisions for EOSS constellations, and enumerate the corresponding tradespace of feasible architectures. Evaluation metrics are proposed to measure benefits and costs of architectures; lastly, a multicriteria Pareto criterion is used to downselect optimal architectures for subsequent analysis. The methodology is applied to two case studies for a set of 30 and 100 customer-spacecraft respectively, representing potential markets for LEO services in Exploration, Earth Observation, Science, and CubeSats. Pareto analysis shows how increased performance of the constellation is always achieved by an increased node size, as measured by the gain of the communications antenna mounted on EOSS spacecraft. On the other hand, nonlinear trends in optimal orbital altitude, number of satellites per plane, and number of orbital planes, are found in both cases. An upward trend in individual node memory

1

capacity is found, although never exceeding 256 Gbits of onboard memory for both cases that have been considered, assuming the availability of a polar ground station for EOSS data downlink. System architects can use the proposed methodology to identify optimal EOSS constellations for a given service pricing strategy and customer target, thus identifying alternatives for selection by decision makers. Keywords LEO data relay, Earth Orbiting Support Systems, Commercial Satellite Data Relay

1. Introduction Infrastructures pervade every human activity and are bringing a revolution to the concept of life in the modern age. It would be inconceivable to think of humanity nowadays without thinking at the significant technological progress that took place in the last century to develop infrastructures such as healthcare, transportation, energy, the Internet, and other large-scale complex utility networks that shape everyday life. Such is the remarkable state of terrestrial infrastructure. On the other hand, no such developments have been observed today in the space business. Very few infrastructure has been established in orbit, with few notable exceptions such as the Global Positioning System (GPS), GLONASS, and the Galileo satellite navigation infrastructure [1], and the Tracking Data Relay Satellite System (TDRSS) for inspace data and telemetry relay from geostationary orbit [2]. Common ground segment systems to serve multiple missions exist, yet they lack the flexibility and scalability to be considered fullfledged infrastructures in the broad sense of the word. Several infrastructures can be built to serve the space industry, and develop services for the benefit of future space missions, as well as science and exploration endeavours. This paper intends to address the likely next step in establishing in-space services, that is, the development of an infrastructure for on-orbit data processing, data storage, and data relay, through non-

2

geostationary spacecraft constellations. We name these constellations Earth Orbiting Support Systems (EOSS). Interest in these constellations arouse in recent years due to the increase in data rate and data volume of LEO spacecraft. For instance, the Sentinel-1 Earth Observation (EO) mission [3] launched in 2014 provides an overall input/output throughput of about 1,950 Mbit/s, with a End of Life (EOL) data storage capacity exceeding 1,410 Gbit [4], and produces 1.3 Tb/day of data, compared to the 0.3 Tb/d of its predecessor Envisat [5]. The spacecraft is also equipped of an Optical Communication Payload (OCP) to transmit data to the ground through a geostationary relay link with a data rate of about 600 Mbps [6]. Sentinel-1 is part of ESA’s GMES/Copernicus programme [7], which satellites feature comparable challenges in terms of data rate and timely ground access. Furthermore, new LEO concepts such as EO CubeSats are finding an increasing use in practical applications [8]. High data rate LEO CubeSats are not viable today due to link and power constraints. It is also of interest to gain prompt access to uplink commands to the spacecraft, for instance to increase the responsiveness and adapt to new requests or changes in operational scenarios. All these applications could be enabled by non-GEO relay infrastructure such as EOSS. The focus of the paper is to conduct tradespace exploration enumerating and evaluating architectures for the infrastructure, and identifying configurations of interest for more detailed design studies. The remainder of this paper is structured as follows. Section 2 discusses background and motivations for the development of EOSS infrastructure. Section 3 provides a brief literature survey on the state of the art of on-orbit data storage, processing, and relay services. Section 4 illustrates the overview of the integrated approach and associated assumptions that have been adopted in this paper to develop the tradespace exploration study of EOSS. Section 5 shows the results obtained applying the proposed integrated approach to the exploration of the tradespace of EOSS infrastructure in Low Earth Orbit. First, the results section shows the application of the approach to two test cases: one with 30 and one with 100 representative customer spacecraft (defined “customers” hereafter), which characteristics in

3

terms of reference market and size are illustrated. The paper closes with Section 6, where conclusions are drawn from the research, along with the identification of interesting avenues for future work.

2. Background and Motivations Conventional space missions do not rely on orbiting infrastructures to meet their objectives; they are conceived to perform all functions required for a mission and are designed to communicate with pre-specified ground segment systems. Interconnectivity between spacecraft, which is a first-order requirement to establish a flexible and scalable in-space infrastructure, is allowed only if such capability is designed a priori on the ground as in the case of certain satellite constellations such as Iridium and Globalstar first and second generation [9-11]. Traditional satellite interconnectivity does not typically allow the addition of new, heterogeneous nodes, which do not form part of the primary mission. Ad-hoc network topology reconfigurability [12] forms a second important requirement for a flexible data infrastructure; while this technology has found extensive use for terrestrial applications, such as in mobile networks and in smart energy grids to name two notable examples, so far ad-hoc network reconfigurability has not been demonstrated in space operations. Non-GEO infrastructure is crucial to provide affordable services to a whole range of missions for which a GEO data relay is not an option due to antenna size or link capacity constraints. While GEO assets such as TDRSS are of great value to missions benefiting of relay services, such as constant coverage for any Earth orbit, they also impose the requirement to customers in LEO to sustain LEO-to-GEO links through a combination of relatively large aperture antennas and medium-to-high power transmitters. TDRSS is thus not an appealing solution for small satellites or for spacecraft not equipped for long-range communications. LEO constellations such as Teledesic [13] have been proposed in the past, however, the development of such concepts never advanced to the production stage due to the lack of materialization of the initially

4

projected customer demand. As these constellations were conceived for a specific purpose (in the case of Teledesic, for Internet connectivity) their business case was tightly coupled to a specific revenue source. On the other hand, constellations such as TDRSS thrived thanks to their flexibility in serving a diverse portfolio of customers. Nevertheless, the limitations of such data relay systems start to appear as small satellite platforms become of more importance to the scientific and engineering community. LEO-to-GEO links suffer of delays due to in-space propagation that may be significant for some categories of applications, such as in telecommunications. Non GEO infrastructure addresses this problem by providing LEO-to-LEO services that could be used by a wide variety of customers, including Earth observation spacecraft in Sun Synchronous Orbit (SSO), small satellites and CubeSats, Earth science missions, and so forth. Nevertheless, LEO-to-LEO systems shall not be seen as the panacea of all space ills; a new set of challenges is brought in by data routing [14, 15], storage, and processing services in LEO, including the need for onboard TT&C equipment to sustain fast handovers, low access time per individual node, interference management, need for novel communications protocols, and other technical challenges [16, 17]. It is reasonable to expect, therefore, that there exists an envelope of market and technical conditions for which the establishment of a LEO-to-LEO infrastructure makes a sound business and engineering proposition. Seen in a commercial perspective, proxy variables for such feasibility boundaries are represented by a positive return on investment, and some measure of technical complexity from a supplier and customer perspective of LEO-to-LEO services. This paper conducts a systems architecture analysis with an integrated approach capable of eliciting and assessing technical tradeoffs between delivered performance benefits and costs associated with LEO-to-LEO relays, and identifying efficient architectures of LEO infrastructure for more detailed design studies. In order to substantiate the development of the integrated approach, the following section summarizes a literature survey that has been

5

conducted to inform the research, identifying the state of the art in space infrastructures with emphasis on on-orbit data storage, processing, and relay services.

3. Literature Survey The majority of satellite missions in LEO adopt a store and forward approach to communications, where payload data is collected over the target area of interest and successively downloaded to ground stations along with telemetry [18]. The main advantage of this communications architecture relies in its simplicity, yet it assumes that each mission has access time reserved with certain ground stations. On the other hand, ground stations impose constraints on the satellite orbit and provide only partial coverage to the spacecraft. The need to maintain real-time access both to unmanned and manned spacecraft led NASA in the 1970s to develop the Tracking Data Relay Satellite System (TDRSS), a constellation of GEO satellites providing near-worldwide coverage and data relay services. TDRSS has been maintained and upgraded over the years, and supported missions of the likes of the Space Shuttle, the Hubble Space Telescope, Space Station Freedom, the International Space Station, and others. While TDRSS and similar GEO data relay systems are invaluable to many missions worldwide, they were conceived at a time in which satellites tended to grow and be large in mass and capabilities. A notable example of this growing mass trend is represented by the European Envisat Earth Observation platform, which made use of ESA’s Artemis GEO data relay system [19]. However, industry is currently witnessing an increasing role played by small satellite systems, which transitioned from having purely educational goals to having the ability to serve a wide variety of needs such as in Earth science and Earth observation [20]. These low-mass systems are equipped with modern instrumentation operating at high data rates, thus requiring high data rate downlinks to Earth in order to function. Here it comes the same issue encountered in the 1970s by the developers of the TDRSS constellation, however, the business landscape has changed since then; several customer missions cannot sustain the burden of

6

LEO-to-GEO communications, while they need high performance and high coverage to the ground at the same time, with reduced economic budgets compared to the past. Furthermore, new emerging technologies such as free-space optical communications [21] are enabling new paradigms for space communications, such as the space Internet [22], a concept advocated by the IOAG Space Internetworking Strategy Group [23]. The development of non-GEO infrastructure such as the proposed EOSS may be instrumental to these new systems, thus paving the way towards the development of new services in space. This assumes a positive closure of the business case for the EOSS infrastructure, if its commercial development and operations are desired. In order to assess this closure, the following section illustrates an integrated approach to enumerate and evaluate EOSS architectures, and identify the ones that are more promising for subsequent study, and identifying the envelope boundaries within which the development of EOSS infrastructure is commercially sound.

4. Approach This section presents the integrated approach that has been developed to characterize the trade space of EOSS constellations for commercial data relay services. An overview of the approach is shown in the functional flow block diagram illustrated in Figure 1. The approach is structured in five steps, namely Formulation, Enumeration, Simulation, Evaluation, and Downselection. Steps are further decomposed in sub-steps, each pertaining to four different functional areas: business, economics, technical, and systems. Step 1 - Formulation The scope of Formulation (Step 1) is to define the architectural problems and the boundary conditions of the trade space analysis. The main outcomes of formulation are the set of assumptions for the analysis and the architectural design matrix that defines the main architectural decisions for EOSS and alternative options for each decision. This step is composed of two sub-steps: first, a customer database is developed (step 1.1); then in sub-step

7

1.2 the architectural design matrix is defined, by finalizing the definition of architectural decisions and related alternative options. Table 1 shows the architectural design matrix that has been used for all the scenarios that have been considered.

Figure 1 - EOSS Integrated Tradespace Exploration Approach

Table 1 – Architectural Design Matrix Architectural decisions Option ID EOSS Altitude Number of satellites per plane Number of orbital planes EOSS antenna gain Storage capacity per EOSS node

Decision alternatives [1] [2] [3] 700 km 800 km 900 km 8 10 12 3 4 5 44 dB 50 dB 56 dB 32 Gbit 256 Gbit 512 Gbit

[4] 14 6 -

8

The following assumptions define the architectural tradespace. It is assumed that EOSS communication payloads have the ability to track customer satellite during operations. Second, it is assumed that the orbital motion of EOSS nodes on odd orbital planes is north-south, while it is south-north on even planes. Third, it is assumed that contacts between spacecraft can be established instantaneously as a function of the line of sight; satellite attitude, interference, and signal lock-in, lock-out times are not considered in the simulation. Fourth and last, inter-satellite connectivity is assumed among EOSS satellites, which then communicate with a polar ground station to downlink data that is relayed for customers, using a store-and-forward approach. This paper assumes a single polar ground station for approach demonstration purposes; however, the methodology here presented is general and can be applied for any number of ground stations with an arbitrary spatial distribution as defined by the designer. The number and location of ground stations is an input provided by the designer as it is rarely the case that new ground stations are developed to serve a particular mission. The proposed tool can be used in fact to assess the impact of an increasing number of ground stations on the evaluation metrics for the EOSS constellation as defined by stakeholders. Following the formulation of the architectural design matrix and of analysis assumptions, the approach moves to Enumeration.

Step 2 - Enumeration The scope of Enumeration (Step 2) is to define all the architectures that are defined by the architectural design matrix, where each architecture is defined as a set of architectural decisions. Following enumeration (step 2.1), constraints are imposed to rule out infeasible combinations from the design matrix (step 2.2) and thus obtain the set of feasible architectures onto which conduct successive analysis.

9

Step 3 - Simulation Once Enumeration is complete, Simulation (Step 4) is conducted for each architecture that has been created. Simulation consists in modelling the lifecycle of the architecture to evaluate total benefit delivered, defined as the total data volume transferred through the EOSS constellation over its lifecycle. During lifecycle simulation, the customer database provides the orbit-related information to the orbital propagator implemented in the simulator (step 3.1 in Figure 1): orbital parameters are acquired from up-to-date real Two Line Element (TLE) strings for customers, while for EOSS nodes the TLEs are internally generated on the basis of three of the architectural decisions related to orbital propagation: altitude, number of satellites per plane, number of orbital planes. The simulator estimates range and access time of each EOSS node–customer pair to calculate data rate and service availability for each customer at each simulation step (step 3.2 in Figure 1); a 90th percentile cutoff on range has been assumed to remove outlier contacts from the simulation. Bandwidth quota allocation has been implemented through a Concurrent Access and Quality of Service policy (step 3.3 in Figure 1). The policy is illustrated in more detail in Figure 2: it assumes a Time Division Multiplex Access (TDMA) communications scheme, where a single simulation time-frame has been divided into slots: during the time frame considered, for each EOSS node, such slots are assigned to the customers served by that node, proportionally to their designated quotas and in the order of precedence determined by each customer’s priority. A Quality of Service (QoS) module allocates the bandwidth of each EOSS node according to the priority and assigned customer bandwidth quota to be served by that node. Service priority of customer i , defined as yi , is calculated as the product of customer bid per data unit pi and average daily data volume of the customer di :

10

 i  pi  di

(1)

Equation (1) is the criterion used as cardinal ranking for customer prioritization in the simulation. In case two customers have equal ranking, the simulation assigns higher priority to the customer with highest price per data unit. This criterion ensures revenues maximization to EOSS in case of partial fulfilment of customer requests, for instance, due to on-board storage capacity saturation at a given time step.

Figure 2 – Concurrent Access policy

Following allocation of bandwidth quotas, residual capacity may be available on certain EOSS nodes. Such extra capacity is thus allotted in equal parts as extra service allocation to highest priority customers.

11

Data rates and data volumes transferred during each simulation step are estimated on the basis of real-time link budgets, made as a function of range, frequency, and gain values for each EOSS node – customer pair (step 3.4 in Figure 1). Service scheduling is determined as a function of each node’s residual storage capacity and customer priority determined by concurrent access and Quality of Service policies. The node that allows the maximum data volume transfer (based on range, residual storage and residual bandwidth) is assigned to each customer at each time-step. Service availability is calculated on the basis of all node-customer access windows. A data volume equal to on-board storage capacity assigned to each customer represents demand. It is assumed that as soon as the customer transfers its data volume to the EOSS infrastructure, its on-board storage is refilled with new payload data. Note that customers do not access the ground station directly, but rather downlink data through the proposed EOSS constellation that serves as a store-and-forward data relay system. The choice to employ a polar ground station for the model presented here, although not binding, descends as a logical consequence of the fact that all EOSS orbital planes are polar: this assumption allows to simplify ground access dynamics, and maximizes the number of access opportunities. Table 2 illustrates the range of assumptions of customer bid value and data volumes considered in the simulation. The last two rows of the table show the TDMA time-slot allocation policy, which drive bandwidth quotas for each customer.

Table 2 – Quality of Service Policy assumptions Customer bid ($/GB)

[1 – 5] $/GB

Data volume (customer on-board memory storage)

[5 – 750] GB

TDMA time-slot allocation policy Customer bid

1 $/GB

2 $/GB

3 $/GB

4 $/GB

5 $/GB

Assigned time-

10%

30%

30%

60%

100%

slots per frame

12

Step 4 - Evaluation Following lifecycle simulation, architectures go through an Evaluation cycle (step 4), where they are rated using proxy metrics for performance, cost, and utilization efficiency. Table 3 shows the metrics that have been used to evaluate architectures. The evaluation metrics here presented do not represent all the possible measures to evaluate satellite constellation architectures. The goal in this paper is to demonstrate how various metrics could be included in the proposed framework for architectural assessment. Future work on EOSS architectures could for instance include the evaluation of latency, defined as the time required for a data package (or file) to move from its originator satellite to the ground. Latency represents a driving requirement in several applications in Earth Observation, including military, disaster management, maritime surveillance, and others. Table 3 – Evaluation Metrics EOSS Constellation cost, including: 

RDT&E & Operations



Production



Launch



Ground segment

Average EOSS connection datarate

A conservative base estimate for RDT&E first unit cost estimate of EOSS is assumed to be C0=150 MUSD FY2014. The cost Cn for the n-th spacecraft recurring unit is estimated assuming a learning curve model [24] with a learning curve factor of 0.8: C n  C0  n

ln  ln 2

(2)

Based on a worst-case link budget estimate for the spacecraft to satisfy node-to-ground downlink requirements, it has been assumed for the single EOSS spacecraft a mass of 450 kg (see Appendix 2 for more details). First unit costs for each architecture are then obtained applying percentage modifiers that are function of assumed antenna gain and on-board memory storage, as illustrated in Table 4.

13

Table 4 – EOSS RDT&E first unit cost modifiers Antenna gain RDT&E first unit cost modifier On-board memory storage capacity RDT&E first unit cost modifier

44 dB

50 dB

56 dB

+5%

+10%

+20%

32 Gbit

256 Gbit

512 Gbit

+0.5%

+4%

+8%

Economies of scale have been taken into account and the incidence of architectural choices on cost has been estimated using a 75% learning curve factor, a typical factor observed in production lines [25]. Launch costs have been calculated starting from the assumed satellite mass and by determining the number of satellites that can be grouped in one single launch (depending on mass and designated orbits). The model uses Falcon 9 as the intended carrier, and all launch-related parameters are referred to this launcher. The paper assumes a fixed launch vehicle choice, as the mass of EOSS nodes being envisioned does not vary significantly in the tradespace. However, future assessments including drastic size variations of EOSS nodes may entail including the launch vehicle selection problem within the tradespace exploration. Ground station and operations costs have been estimated approximately with typical values from the literature [18]. The metrics module acquires access times, data rates and exchanged volumes, costs and pricing schemes, and calculates different parameters to be variously combined and presented as a set of figures for cost and utility. These metrics are the subject of the trade-off analysis in which architectural variables are systematically varied to assess the effect of the changes on such metrics. In order to eliminate outliers, the results in the tradespace are filtered according the following rule: only architectures that provide availability and data rate values above the 10th percentile are considered for further study.

14

The proposed architectural framework is designed as a modular structure. It therefore allows the inclusion of additional evaluation metrics into the assessment, as desired by stakeholders and driven by intended applications. Such metrics can be embedded in the approach presented in this paper with no significant modifications in the framework. Step 5 - Downselection In Downselection (Step 5), a Pareto non-dominance criterion [26] is used to identify the architectures with the most efficient tradeoffs across the metrics of interest. As a result, the approach identifies architectures of interest for more detailed design study. The approach here presented identifies architectures for EOSS serving a set of pre-defined customers. In order to validate the model and to gain insights on the architectural problem, two case studies have been described and implemented, as discussed in the following section. 5. Results Two scenarios have been considered in order to simulate different conditions under real load conditions for the constellation. The first scenario is populated with a database of 30 customers, representative of a modest load for the EOSS infrastructure. The second scenario is one populated by 100 customers. Customers have been drawn among Exploration, Earth Observation, Science, and CubeSat missions that are already operational and flying – in order to provide a realistic assessment of opportunities that could be offered by EOSS. Figure 3 shows the customer composition for the two cases. The full list of customers that have been considered for the two scenarios is available in Appendix 1 of this paper.

Figure 3 - EOSS Cases considered – Customers composition

15

Figure 4 – EOSS tradespace, 30 customers

Figure 5 – EOSS tradespace, 100 customers Figures 4 and 5, show the EOSS tradespace for the 30 and 100 customer cases, respectively.

16

Each point in the figures represents a particular architectural configuration of EOSS with respect to the aforementioned architectural variables. The x-axis of the plots shows the average data rate supported by the infrastructure, while the y-axis shows total cost as estimated by the model. Average data rate can be considered a measure of capacity of the infrastructure, as it represents one of the most important metrics of performance of the system. The southeast frontiers of the figures are the respective Pareto fronts for each of the two cases. Pareto architectures are labeled with a numerical code representing the ID of decisions for each architecture according to the architectural design matrix, as illustrated in Figure 6.

Figure 6 – Pareto front architectures nomenclature System architects can use this plot to choose Pareto efficient EOSS architectures at different levels of lifecycle cost. It is interesting to notice the three different regions of the Pareto front (see Figure 7 for an illustrative example). In the first region, small increases in cost lead to significant increases in available data volume (Region 1). This is a region of the tradespace offering low cost architectures, which however could be significantly improved by modest increases in budget available. In the second region, increases in cost are commensurate to increases in data volume (Region 2). This region includes architectures that represent best compromises in the tradespace, in the sense of offering adequate performance for the associate total cost. In the third region, small increases in data volume correspond to large increases in cost (Region 3). This last region offers architectures that are high performing, albeit carry a significant cost burden required to achieve that marginal increase in performance compared with best compromise solutions that are included in Region 2.

17

Figure 7 – EOSS Tradespace regions (30 customers)

The analysis of Pareto fronts offers the opportunity to identify and compare different EOSS architectures for different assumptions on number of customers to be served and on average data rate capacity supported by the infrastructure. Figures 8 and 9 show two examples of proposed constellations for the 30 customers case. The first one offers an average ~160 Mbps service to customers, for a lifecycle cost of ~3,000 MUSD (architecture ID 31132). The second architecture instead offers an average ~200 Mbps service for a total lifecycle cost of ~4,800 MUSD (architecture ID 13232). It can be seen how in this case a ~17% increase in performance corresponds to a ~60% increase in cost.

18

Figure 8 – 30 customers case, architecture 31132

Figure 9 – 30 customers case, architecture 13232

An element of interest to designers is to assess how Pareto optimal architectures vary for an increasing performance, in this case represented by an increasing average data rate. In particular, it is of interest to understand whether increased performance is better achieved by increased size of individual nodes, either by larger antenna gains or larger onboard memory capacity, or by increased size of the constellation - by virtue of a larger number of satellites per plane, or a larger number of orbital planes. Such kind of tradeoffs are of interest as their assessment is non-trivial; total performance and lifecycle costs are obtained by holistic considerations of development, launch, and operations costs, while performance is assessed looking at the lifecycle simulation of the proposed EOSS architecture with the desired number and mix of customers. Figures 10 and 11 show the results of this analysis for the 30 customers and 100 customers cases, respectively, as considered in this paper. In the figures, Pareto optimal architectures have been sorted by increasing data rate. Each line plot represents the architectural decision option; plots thus show how the choice of Pareto optimal decisions varies for an increasing datarate performance. Analysis of these plots allows designers to identify trends in the tradespace. For example, looking at the 30 customers case, it can be seen how

19

the choice of an orbital altitude is not monotonic over the Pareto front. That is, one does not necessarily raise or lower the altitude to achieve a higher performance capacity. An upward trend can be instead noticed in the number of satellites per plane and number of orbital planes, although certainly non monotonic, due to nonlinearity in the cost/performance tradeoff introduced by orbital configurations, development, and launch costs. A remarkable upward monotonic trend is observed in the antenna gain variable. It seems clear in this case therefore that increased architecture performance always implies an increased performance of the individual node – much more than the increased performance of the constellation per se, as measured by the number of satellites per planes and the number of orbital planes. On the other hand, increased memory storage capacity is not necessarily required, due to the relatively low volume of traffic generated by 30 customers that allows the constellation to provide continuous service given its ability to downlink data to the ground before new data requests from customers are generated. Analysis of Figure 11 leads to slightly different conclusions for the 100 customers case, although with several similarities to the analysis conducted up to now. While in the 30 customers case different orbital altitudes can be observed on the Pareto front, the lowest altitude (option 1) is always chosen in the 100 customers case. This effect is due to the increased number of customers, which reduces the need for the constellation to be tailored to meet specific customer needs – since an increased number of transaction opportunities is available in the system. Increased node size appears to be a preferred option for increased capacity also in the 100 customers case, in addition to a similar trend observed for onboard memory storage. Nevertheless, the highest memory option of 512 Gbits never appears on the Pareto front, as it appears to be not required due to the assumed ground link availability. Indeed, designers could observe different trends by trading ground station availability as part of the systems architecting problem formulation.

20

Figure 10 – Pareto front analysis (30 customers case)

21

Figure 11 – Pareto front analysis (100 customers case)

22

We validated the lifecycle cost model used in the EOSS tradespace benchmarking its results with existing infrastructures. The results of the benchmark are shown in Table 4. It must be noted, however, that no infrastructure such as EOSS currently exists in orbit; therefore, this benchmark must be interpreted as the best possible validation effort, yet only an approximate one for rough order of magnitude comparison.

Constellation name Iridium Globalstar first generation* O3B**

Table 4 – EOSS cost model validation results Analog EOSS Estimated EOSS Actual cost architecture ID cost [BUSD [BUSD FY2014] FY2014] 12421 7.2 9.0

Relative error (%) -20%

33232

4.9

4.0

23%

31133*

1.2*

1.3*

15%

(*): Globalstar second generation is not included in the assessment to maintain fairness in the validation, being an incremental development making use of existing Globalstar infrastructure.

(**): As discussed in the paper, the cost of 12 out of 24 recurring spacecraft has been discounted from the costs of architecture 23232 to allow a fair comparison of EOSS with the O3B constellation (which is not included in the EOSS tradespace).

A first validation has been performed comparing total lifecycle cost of an EOSS architecture with characteristics similar to Iridium. Consider architecture 12421 in the 100 customers tradespace considered previously. Such architecture presents characteristics that are similar to Iridium's architecture: EOSS architecture 12421 has 6 polar orbital planes with 10 satellites each, at an altitude of 700 Km, while Iridium consists of 6 polar orbital planes, hosting 11 satellites each, at an altitude of approximately 780 Km. Total EOSS lifecycle cost (LCC) is estimated at $7.2 billion FY2014. Total LCC for Iridium was estimated at $5.6 billion FY1994 [27], approximately equivalent to $9.0 billion FY2014; the error is thus approximately 20%, within reasonable range for an order of magnitude comparison. We further validated our model validating the costs of EOSS with Globalstar first generation. Due to the absence of intersatellite links in the first generation of the Globalstar platform, and due to the orbital characteristics of the constellation – namely, a higher orbital altitude, 1,400 km, than those considered in the model, the different

23

orbital inclination (52 degrees instead of 90 degrees, entailing different launch costs) it is not possible to compare EOSS architectures matching all the same characteristics of Globalstar. Nevertheless, we considered architecture 33232, having similar characteristics to Globalstar. The selected architecture has 4 orbital planes with 12 satellites each, at an altitude of 900 Km, while Globalstar consists of 8 orbital planes, hosting 6 satellites each, at an altitude of approximately 1400 Km. The total number of satellites (48) is the same for both constellations. Total EOSS lifecycle cost in this case is estimated at $4.9 billion FY2014. Total LCC for Globalstar was estimated at $2.5 billion FY1994 [28], approximately equivalent to $4.0 billion FY2014. Taking into account the above mentioned differences between the two constellations, an EOSS cost estimate being approximately 23% in excess of Globalstar's cost is deemed acceptable. We did not validate against Globalstar second generation, being this an incremental development based on the first generation system (particularly on the ground segment side.) An additional validation can be made, with some degree of approximation, using the O3B constellation [29] as a data point. In the O3B case, differences with EOSS are even more significant. Changes include a higher orbital altitude in Medium Earth Orbit (in lieu of LEO), and a smaller total number of satellites deployed: 16 satellites at full configuration (12 satellites deployed as of end of 2014), versus the 24 satellites of the minimal EOSS configuration. Final costs cannot be precisely defined since the O3B constellation has not been fully deployed at the time of writing of this article. For the aforementioned reasons, we compare EOSS architecture 31133, which is the one in the tradespace that is closest in total capability and system characteristics to the partially deployed O3B constellation made of 12 satellites, for which total cost is known ($1.3 billion FY2013 [30].) We discount from such architecture (made of 24 satellites) a cost apportionment equal to the excess number of spacecraft with respect to O3B (12 units), times the average satellite cost ($125 million FY2014 per unit, averaging on the entire production batch including a proportional quota for launch, operations, and ground

24

segment costs.) The resulting cost estimate is 1.2 billion FY2014, only 15% away from the actual cost. There are several limitations to the cost validation exercise that has been conducted. We compared EOSS costs to the cost of analog constellations that have been developed in the past, that feature very heterogeneous technical requirements. For instance, the space segment of the Iridium constellation features inter-satellite links, whereas Globalstar platforms do not. This difference changes the cost allocation between the space and ground segment of the constellation. Due to its inter satellite link features, the space segment of Iridium is more expensive than Globalstar's; on the other hand, the ground segment of the latter is more expensive as it requires additional gateways for its functioning. Gumbert et al. discussed these specific differences in the cost structure of the two constellations in [28]. We also included the cost comparison with the recent O3B constellation; however, due to its peculiar orbital height of 8,000 km, variations in space segment development cost are expected.

Nevertheless, the

exercise complies with the scope of the validation, of providing a “rough order of magnitude” sanity check of the cost estimating tool used for the analysis of EOSS. It is worthwhile to point out that the cost estimate of EOSS is independent of the number of customers served: the two scenarios presented (30 and 100 customers) have been considered with the purpose of evaluating how the subset of optimal architectural configurations changes in relation to EOSS’s different workload conditions, while still considering, for the two scenarios, the same full set of possible architectural configurations.

6. Conclusion

This paper illustrates the opportunities in deploying a LEO satellite constellation as a data relay backbone intended to support customer LEO satellites in Data Transfer and TT&C.

25

The choice of a LEO position is a point of interest as it can overcome many of the limits that can be found in equivalent GEO relay solutions, as the limited possibility of frequencies reuse, which limits

the

system’s

data

relay

capabilities,

the

complexity

of

(LEO)

customers’

telecommunication equipment, the high system’s sensitivity to node failures. A systems architecting approach has been used for the exploration of different architectures suitable for the purpose. Technical, market, economics and business aspects have been examined with the analytical support of the Pareto optimality theory. Two scenarios (30 and 100 customer spacecraft) have been considered in order to evaluate how the proposed infrastructure is expected to respond under different load conditions and to assess how the investment strategy should change accordingly. Two principal features have been modelled and distinguish the present architecting framework: the pricing model and the intended customer target. The pricing model has been developed by contemplating different tariffs and Quality-of-Service levels for different categories of customers. Three categories of customers have been considered: missions for which the continuity and availability of connection is a priority requirement, whereas data transfer rate is not a critical aspect (e.g. manned missions). Second, missions that require high data-rates to be transferred within a reasonable time, and that need a considerable availability rate for the relay service (e.g. Earth Observation missions). Third and last, missions with limited communication equipment, that do not have strict requirements on the data transfer rate and on the availability side, and that can take significant advantage from the proposed infrastructure even if served on a residual basis (e.g. cubesats). Nonlinear trends in optimal orbital altitude, number of satellites per plane, and number of orbital planes, are found in both cases considered. An upward trend in individual node memory capacity is found, although never exceeding 256 Gbits of onboard memory for both cases that have been considered, assuming the availability of a polar ground station for EOSS data downlink. The methodology presented in this paper can be used by system architects to identify

26

optimal EOSS constellations for a given service pricing strategy and customer target, thus identifying alternatives for selection by decision makers.

7. Acknowledgments The authors are indebted with the students of the 11th Master Course in Satellite Systems and Services of the University of Rome La Sapienza and with Prof. Rick Fleeter who lectured in the course and coached the students during the educational teamwork project that paved the way for the present study.

27

8. References [1] Hoffmann-Wellenhof, Lichtenegger, Wasle, GNSS Global Navigation Satellite Systems: GPS, GLONASS, Galileo & more, Springer, New York, 2008. [2] J. Teles, M.V. Samii, C.E. Doll, Overview of TDRSS, Advances in Space Research, 16 (1995) 67-76. [3] G. Taini, A. Panetti, F. Spataro, C. Bruno, Sentinel-1 Satellite System architecture: Design, performances and operations, in: Geoscience and Remote Sensing Symposium (IGARSS), 2012 IEEE International, IEEE, Munich, Germany, 2012, pp. 1722-1725. [4] A. Panetti, R. Torres, S. Lokas, C. Bruno, R. Croci, M. L’Abbate, M. Marcozzi, A. Pietropaolo, P. Venditti, GMES SENTINEL-1: Mission and Satellite System Overview, EUSAR 2012, (2012). [5] J. Louet, S. Bruzzi, ENVISAT mission and system, in: IEEE (Ed.) Geoscience and Remote Sensing Symposium, IGARSS '99 Proceedings, IEEE, 1999, pp. 1680-1682. [6] L. Wolfram, Hybrid Optical/RF Payloads for current and future Datalink Applications, in: 31st AIAA International Communications Satellite Systems Conference, American Institute of Aeronautics and Astronautics, 2013. [7] J. Aschbacher, M.P. Milagro-Pérez, The European Earth monitoring (GMES) programme: Status and perspectives, Remote Sensing of Environment, 120 (2012) 3-8. [8] D. Selva, Rule-based System Architecting of Earth Observation Satellite Systems, in: Aero/Astro, Massachusetts Institute of Technology, Cambridge, MA, 2012. [9] G.M. Comparetto, A Technical Comparison of Several Global Mobile SatelliteCommunications Systems, Space Commun, 11 (1993) 97-104. [10] F. Dietrich, P. Metzen, P. Monte, The Globalstar cellular satellite system, Antennas and Propagation, IEEE Transactions on, 46 (1998) 935-942. [11] Globalstar, Globalstar signs contract for new satellite constellation, in: S. Now (Ed.), 2006. [12] G.R. Ash, Dynamic routing in telecommunication networks, McGraw-Hill, 1997. [13] D.P. Patterson, Teledesic: a global broadband network, in: Aerospace Conference, 1998 IEEE, 1998, pp. 547-552 vol.544. [14] M. Mohorcic, M. Werner, A. Svigelj, G. Kandus, Adaptive routing for packet-oriented intersatellite link networks: performance in various traffic scenarios, Wireless Communications, IEEE Transactions on, 1 (2002) 808-818. [15] M. Werner, G. Berndl, B. Edmaier, Performance of optimized routing in LEO intersatellite link networks, in: Vehicular Technology Conference, 1997, IEEE 47th, 1997, pp. 246-250 vol.241. [16] A. Golkar, Federated Satellite Systems: an Innovation in Space Systems Design, in: 9th IAA Symposium on Small Satellites for Earth Observation, IAA, Berlin, Germany, 2013. [17] I. Lluch, A. Golkar, Satellite-to-satellite coverage optimization approach for opportunistic inter-satellite links, in: Aerospace Conference, 2014 IEEE, 2014, pp. 1-13. [18] J. Wertz, D. Everett, J. Puschell, Space Mission Engineering: The New SMAD, Microcosm Press, Hawthorne CA, 2011. [19] V. Angelopoulos, The ARTEMIS Mission, Space Science Reviews, 165 (2011) 3-25. [20] D. Selva, D. Krejci, A survey and assessment of the capabilities of Cubesats for Earth observation, Acta Astronautica, 74 (2012) 50-68. [21] H. Hemmati, Deep Space Optical Communications, John Wiley & Sons, Inc., Hoboken, New Jersey, 2006. [22] K. Bhasin, J.L. Hayden, Space Internet architectures and technologies for NASA enterprises, in: Aerospace Conference, 2001, IEEE Proceedings., 2001, pp. 2/931-932/941 vol.932. [23] C.D. Edwards, M. Denis, L. Braatz, Operations concept for a Solar System Internetwork, in: Aerospace Conference, 2011 IEEE, 2011, pp. 1-9.

28

[24] Yelle, Louis E. The learning curve: Historical review and comprehensive survey, Decision Sciences 10.2, 1979, pp.302-328, doi: 10.1111/j.1540-5915.1979.tb00026.x . [25] O. de Weck, Lecture S3: Integrated Lifecycle Modeling, in: 16.886 Air Transportation Systems Architecting, Massachusetts Institute of Technology, Cambridge MA, 2009. [26] O.L. de Weck, M.B. Jones, Isoperformance: Analysis and Design of Complex Systems with Desired Outcomes, Systems Engineering, Vol.1, 2006, pp.45-61. [27] S. Finkelstein, S.H. Sanford, Learning from corporate mistakes: The rise and fall of iridium, Organ Dyn, 29 (2000) 138-148. [28] Cary C. Gumbert, Michael D. Violet, Daniel E. Hastings, Walter M. Hollister, and Robert R. Lovell. Cost per Billable Minute Metric for Comparing Satellite Systems, Journal of Spacecraft and Rockets, Vol. 34, No. 6, 1997, pp. 837-846. [29] Williamson, M., Connecting the other three billion, Engineering & Technology , vol.4, no.4, pp.70,73, 28 Feb. - 13 Mar. 2009. [30] de Selding, P.B., Soyuz Delivers First Four O3b Satellites to Orbit, Space News, June 25, 2013.

29

Appendix 1 EOSS Customers Lists Table A – 30 Customers Case List Name Type ISS Exploration Pleiades 1A Earth Observation Ikonos 2 Earth Observation Quickbird 2 Earth Observation Cosmo Skymed 1 Earth Observation Rapideye 1 Earth Observation Spot 5 Earth Observation Geoeye 1 Earth Observation Orbview 2 Earth Observation NOAA 1 Earth Observation NOAA 19 Earth Observation Landsat 7 Earth Observation TerraSar X Earth Observation WorldView 1 Earth Observation Jason 2 Earth Observation

Name Arirang 2 TRMM Rasat Tandem-X Theos Radarsat 2 Calipso Cloudsat Coriolis Cubesat XI-V Swisscube M-Cubed Cubebug 1 Firefly Compass-1

Type Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Science Science Science CubeSat CubeSat CubeSat CubeSat CubeSat CubeSat

Table B – 100 Customers Case List Name Type ISS Exploration Pleiades 1A Earth Observation Ikonos 2 Earth Observation Quickbird 2 Earth Observation Cosmo Skymed 1 Earth Observation Cosmo Skymed 2 Earth Observation Cosmo Skymed 3 Earth Observation Cosmo Skymed 4 Earth Observation Rapideye 1 Earth Observation Rapideye 2 Earth Observation Rapideye 3 Earth Observation Rapideye 4 Earth Observation Rapideye 5 Earth Observation Spot 5 Earth Observation Spot 6 Earth Observation Geoeye 1 Earth Observation Orbview 2 Earth Observation NOAA 1 Earth Observation NOAA 2 Earth Observation NOAA 3 Earth Observation NOAA 4 Earth Observation NOAA 5 Earth Observation NOAA 6 Earth Observation NOAA 7 Earth Observation

Name TRMM Rasat Tandem-X Cryosat 2 Arirang 3 Prism Theos Radarsat 2 SMOS Saudisat 1C Saudisat 2 Saudisat 3 Lapan-Tubsat Topsat SCD 1 SCD 2 Ziyuan 1-02C Ziyuan 3 Jugnu SAC-D Calipso Cloudsat Parasol Coriolis

Type Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Science Science Science Science

30

NOAA 8 NOAA 9 NOAA 10 NOAA 11 NOAA 12 NOAA 13 NOAA 14 NOAA 15 NOAA 16 NOAA 17 NOAA 18 NOAA 19 Landsat 7 Landsat 8 TerraSar X WorldView 1 WorldView 2 Eros A1 Eros B Deimos 1 UK-DMC 2 Beijing 1 Aqua Aura Jason 2 Arirang 2

Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation Earth Observation

Grace 1 Odin DLR-Tubsat Nustar Meteor-M 1 Haiyang 2A CubeSat XI-IV CubeSat XI-V SwissCube M-Cubed CubeBug-1 Zacube-1 CubeBug-2 FunCube-1 EstCube-1 AAUsat 3 Opusat Firefly Beesat Jugnu Masat 1 NEE-01 Pegasus Vermont Lunar Cute-1 Compass-1 SEEDS II

Science Science Science Science Science Science CubeSat CubeSat CubeSat CubeSat CubeSat CubeSat CubeSat CubeSat CubeSat CubeSat CubeSat CubeSat CubeSat CubeSat CubeSat CubeSat CubeSat CubeSat CubeSat CubeSat

31

Appendix 2 Link Budget for EOSS-node to ground downlink In this appendix we calculate the minimum DC power needed by a single EOSS node communication payload required to satisfy the node-to-ground link-budget requirements. The following worst case assumptions are made. -

EOSS node-to-ground antenna gain: 44dBi Ground Station Antenna Gain: 48dBi EOSS node altitude: 900 km Max node-to-ground distance (slant range) = 3000Km RF carrier: 19 GHz Bandwidth: 200 Mhz Minimum data rate: 400 Mbit/s

Since the minimum number of satellites per plane considered in this study is 8, at a minimum altitude of 700 Km, the polar ground station is always able to establish a connection with an EOSS node. As a consequence, the infrastucture is always connected to ground facilities and the minimum data rate value will occur in correspondence of a slant range of approximately 3000 Km. We consider the following link budget equations: E b Pt Ll Gt Ls La G r  N0 kT s R

(A1)

where: Pt = transmitter power Ll = transmitter-to-antenna line loss Gt = transmit antenna gain Ls = space loss La = transmission path loss Gr = receive antenna gain k = Boltzmann's constant Ts = system noise temperature and: Eb S W  N0 N R

(A2)

32

where: S = received signal power N = received noise power W = bandwidth of receiver R = data bit rate Eb = energy per bit No = noise power spectral density W = bandwidth,Hz Based on equations (A1) and (A2), the minimum RF power needed in order to achieve a minimum data rate of 400 Mbit/s is estimated approximately at 20 Watt for the node-to-ground transmitter. On the whole, four transmitters are included in each EOSS node: one for node-tocustomer link (30 Watt RF-power), one for the node-to-ground link (20 Watt RF-power) and two for intersatellite links (30 Watt RF-power each). The total RF power employed by an EOSS node is thus estimated to be 110 Watt RF, requiring a total DC power of about 315 Watt, considering a DC-to-RF efficiency of 35% [A1]. With the use of a parametric power-to-mass model from the literature [A2], shown in equation (A3), the mass of a single EOSS node can be approximately estimated to be 450 Kg as follows:

0.73 M wet  4.6PPL  140

(A3)

References [A1] Satellite Communications Payload and System, Teresa M. Braun, Wiley-IEEE Press, October 2012 [A2] Philip N. Springmann and Olivier L. De Weck. "Parametric Scaling Model for Nongeosynchronous Communications Satellites", Journal of Spacecraft and Rockets, Vol. 41, No. 3 (2004), pp. 472-477.

Gianluca Palermo

33

Gianluca Palermo received the Master's Degree in Electronic Engineering and a Postgraduate Master Degree in Satellites and Space Services (Cum Laude) at the University of Rome - La Sapienza (Italy). He completed a Scientific Mission at the Universidade de Aveiro (Portugal) focused on Software Defined Radio Digital Receivers and on their use as Satellite Beacon Receivers. He contributed to the design and assembly of Alphasat satellite's 20GHz and 40GHz receiving stations at ISCOM labs of the Italian Ministry of Economic Development. Mr. Palermo contributed to a spin-off company of the University of Rome working on Earth Observation satellite data exploitation.

34

Alessandro Golkar

Alessandro Golkar is Assistant Professor at the Skolkovo Institute of Science and Technology (Skoltech) in Moscow, 
Russian Federation, a private university opened in collaboration with MIT. He received a Ph.D. in Aeronautics and Astronautics from MIT. He is the Director of the Strategic Innovation Research Group (SIRG) at Skoltech. His research interests lie in the areas of systems architecture, project management, systems engineering, and spacecraft design analysis and optimization. Before MIT, Alessandro received a Laurea degree in Aerospace Engineering in 2006 and a Laurea Specialistica degree in Astronautics Engineering in 2008 from University of Rome “La Sapienza”, Italy.

35

Paolo Gaudenzi

Paolo Gaudenzi serves as a Professor of Aerospace Structures within the Department of Mechanical and Aerospace Engineering of the Università di Roma La Sapienza, where he coordinates the aerospace structures section. He is the director of the Ph.D. course in Aeronautical and Space Engineering and of the professional Master course in Space Systems and services at La Sapienza. Paolo Gaudenzi has published more than 100 articles and one book on Smart Structures. He received his laurea degree in Civil Engineering from the Università di Roma La Sapienza, as well as his Ph.D. degree in aerospace engineering.

36

Paper: Earth Orbiting Support Systems for Commercial Low Earth Orbit Data Relay: Assessing Architectures through Tradespace Exploration Authors:  Mr. Gianluca Palermo (PhD Student, Sapienza Università di Roma)  Prof. Alessandro Golkar (Assistant Professor, Skolkovo Institute of Science and Technology – Visiting Scholar, Massachusetts Institute of Technology)  Prof. Paolo Gaudenzi (Professor, Sapienza Università di Roma) Highlights     

A tradespace exploration study for future LEO data relay satellite constellations. Study proposes Earth Orbiting Support Systems for future data relay services. Study identifies optimal EOSS architecture for subsequent detailed design. Two case studies are discussed as demonstration of the proposed methodology. Study discusses recurrent optimal design decisions in the EOSS tradespace.

37