– Historically constellations of communication satellites were designed to function optimally for a specific expected global demand. This estimation is based on assumptions of the number of users and the average activity per user, both of which ar e highly uncertain. This uncertainty can cause deployed constellations having a capacity far lower than demand, lowering performance and creating opportunity cost, or far higher than demand, potentially bankrupting the company that owns the system as incom e cannot recoup the initial investment. An approach has previously been proposed wherein a satellite constellation is deployed in stages with each stage increasing the capacity of the constellation through reconfiguration of on -orbit satellites and launch of new satellites. This method has been previously demonstrated to significantly reduce the lifecycle cost of low -earth orbit communication satellite constellations. Recent proposals for satellite constellations to support global broadband internet provide rs have introduced new technologies as well as new methods of constellation design resulting in far larger constellations than previously envisioned (mega -constellations). Renewed interest and investment in the development global broadband networks demand a return to this topic to investigate its impact in this space. a - Graduate Student, School of Systems and Enterprises, 1 Castle Point on Hudson b - Assistant Professor, School of Systems and Enterprises, 1 Castle Point on Hudson 1. Introduction 1.1 Motivation The concept of providing internet from space has regained pop ularity over the past few years, and with this resurgence in popularity has come a significant technological and monetary investment from both the government and private sector. Since 2014 over a dozen companies have applied to the Federal Communications Commission (FCC) to construct vast constellations of low or very low earth orbit (LE O, VLEO) satellites as part of a network to provide broadband satellite internet access. Many of these proposed constellations contain thousands of satellites with the largest, SpaceX’s Starlink system, containing 11,943 individual satellites. Due to the greatly increased scale of these proposals compared to earlier satellite communication constellations (Iridium, GlobalStar) the term “mega- constellations” was coined to refer to these new systems. In addition to this vastly increased scale, many new tech nologies are being incorporated into these new constellations that were not present in the communication satellite constellations of the 1990s. These new technologies, such as the use of digital communication payloads, multi -beam antennas, and advanced mod ulation and frequency use schemes help to increase the performance of individual satellites. Cost reductions from advanced manufacturing processes and reduced launch costs also help to reduce the cost of performance in these systems. In 2015, potential s atellite broadband provider OneWeb secured a significant investment of $500 million to begin production of their satellite network. Since then, investment into their company has skyrocketed to over $3.4 billion [1 3]. The satellite- based broadband industry is expected to account for only $4 billion in revenue this year, but by 2024 revenue is expected to rise to $22 billion, and to $41 billion by 2029 [1 4]. Along with dedicated providers such as OneWeb and space industry players such as SpaceX, major corporations such as Facebook and Amazon have given commitments to enter this industry [1 5]. Investment into this industry in 2018 was the highest it has ever been, with over $3.2 billion in total capital investment from a variety of sources, including almost $2 billion in venture capital investment, an increase of 22% over last year. Traditionally, satellite constellation syste ms are sized and constructed to meet a capacity estimated by market studies and extrapolations based on current demand. This estimate i s subject to great uncertainty, as was shown in the case of the satellite telephone networks of the 1990s. Due to the unexpectedly rapid development of terrestrial cellular networks as well as uncompetitive pricing of satellite phone handsets and service c harges, demand for satellite telephone services was far lower than anticipated. This caused the bankruptcy of Iridium and Globalstar companies, whose satellite constellations were vastly oversized for their market. There is still significant uncertainty in the size of the satellite broadband internet market in ten years’ time . Broadband satellite internet has the capability to reach millions of customers currently unserved by terrestrial networks. Conservative estimates place the number of global broadban d subscribers before the end of the decade at ten million, while other estimates approach twenty five million. Projections of Broadband Internet Demand, From [3] As there is still significant uncertainty regarding the future size of the broadband internet market, there is significant risk in the process of designing a broadband satellite constellation for a specific forecasted capacity. Chaize [5] proposed an alternative, flexible approach to satellite constellation design in which a constellation is deployed progressively, starting with a smaller, more affordable constellation with a lower capacity that can be increased in stages through the launch of additional satellites. This ‘staged deployment’ methodology was shown to decrease the lifecycle cost of a satellite constellation compared to a traditional architecture that is optimized for a fixed capacity. This approach provides the system architects with real optio ns that allow them to tailor the evolution of the system to an unfolding demand scenario by embedding flexibility into the design of the system. This staged deployment method is well suited for use within the design space of currently proposed broadband s atellite constellations. The vastly increased size and cost of proposed satellite broadband constellations as well as the new technologies included therein demand a return to this topic. 1.2 Background Chaize has previously demonstrated the effects of st aged deployment on the economics of satellite constellations within the design space of constellations of the1990s and early 2000s. This analysis used a trade space previously developed by de Weck and Chang [8]. Chang [9] developed methods for calculating capacity of communication satellite constellations consistent with this architecture trade space design method. Del Portillo[4] performed a detailed analysis of the capacity of Telesat, SpaceX, an d OneWeb’s proposed systems Numerous accepted methods of evaluating spacecraft lifecycle costs exist, as detailed in [10]. For this analysis, the Unmanned Spacecraft Cost Model (USCM) was chosen to model lifecycle cost. Building upon the methods developed by Chaize, this paper analyzes the benefits of the flexibility enabled by staged deployment on lifecycle cost in the presence of uncertain demand. 1.3 Paper Objectives The objectives of this paper are as follows: To develop a trade space representative of the proposed satellite constellations to provide global broadband internet access, to determine the possible architecture evolutions for broadband satellite systems, and to demonstrate the cost savings provided by staged deployment within this design sp ace for a selected subset of potential demand scenarios . 2.0 Staged Deployment Strategy 2.1 Traditional Approach The traditional approach to constellation design first establishes a required capacity for the system based on market studies and extrapola tions of current demands. The two quantities that must be estimated are the expected global number of subscribers N Users and the average activity level per user, AUser. The number of duplex channels that the system has to provide to satisfy this demand, N Ch, represents the instantaneous capacity requirement. 𝑁𝑁𝐶𝐶ℎ=𝑁𝑁𝑈𝑈𝑈𝑈𝑈𝑈𝑈𝑈∗𝐴𝐴𝑈𝑈𝑈𝑈𝑈𝑈𝑈𝑈 𝑈𝑈𝑆𝑆∗365 12∗24∗60 (1) Where US is the percent global system utilization, a fractional value between 0 and 1 representing the amount of satellites currently available (i.e. over populated areas). After the required number of channels is determined, a constellation is designed that minimizes lifecycle cost (LCC) while meeting this capacity requirement . LCC includes RDT&E, satellite manufacturing, satellite launch, deployment of ground stations, operations and satellite replenishment. 2.2 Flexible Approach The flexible staged deployment approach developed by Chaize forsakes this process of sizing constellations in favor of a process that embeds flexibility by choosing an initial architecture that will give system architects the ability to adapt to market conditions. This poses new challenges to designers. The first challenge is that, instead of choosing a single architecture, architects must choose a ‘path’ of architec tures that will allow them to progressively scale up their system. These paths are informed by legacy components from the initial stage which reduce the number of future developments available. The second challenge is that the chosen path must be demonstra ted to be viable across all possible demand evolution scenarios, and as such uncertainty must be modeled into the design process. 2.4 Economic Advantages Afforded by Flexibility The inclusion of flexibility in the design of a system allows the existenc e of decision points throughout the lifecycle of the system. At a decision point, the parameters that are subject to future uncertainty are analyzed, and a decision is made to adapt to them in the best possible manner. As these decision points are distribu ted throughout the lifecycle of the project, rather than in the initial design phase (as is the case with the traditional, single capacity design approach), uncertainty is reduced, thus reducing risk. In the analysis of staged deployment of satellite con stellations, demand is the uncertain parameter. The decision that this parameter informs is whether or not to expand the architecture of a satellite constellation beyond its current state in order to increase the capacity of the system. This approach repre sents an economic opportunity compared to the traditional way of designing systems because it allows designers to make decisions based on current and not future conditions. Two mechanisms explain this advantage. Staged deployment attempts to minimize the initial development costs of the system by deploying an affordable system. While this process does reduce initial costs, costs to transition between stages can be large, potentially offsetting the initial savings. However, since those expenditures are pushe d towards future times, they are discounted. With discount rate r and cost Q , and t years between the current time and the time the cost will be incurred , the Present Value ( PV) of the cost considered is given in Equation 2. 𝑃𝑃𝑃𝑃(𝑄𝑄)= 𝑄𝑄 (1+𝑟𝑟)𝑡𝑡 (2) The present value, or cost, for deploying a new stage decreases with increasing t. Thus the first economic advantage afforded by staged deployment is that it spreads some expenditures (satellite production, launches) over time. A value of r = 0.55 was used for this analysis, identified as representative of these types of projects in [5]. The second advantage afforded by staged deployment is that future stages are deployed with greater knowledge of market conditions. If conditions are unfavorable, no additi onal capacity is deployed and expenditures are kept low. Likewise, if demand is large enough and revenues are sufficient, capacity can be increased with reduced risk. Note that the presence of sufficient revenue is not considered in this analysis. 3.0 Development of Trade Space 3.1 Choice of Design Variables The architectural decisions under study in this paper are captured in the design vector, x = [h,e,i,f,Pt,A, ISL]. The constellation design vector is defined by its circular orbital altitude, h , minimum elevation angle of ground station antennas, e, satellite transmitter power, Pt, antenna type, A , type of inter -satellite link, ISL , and inclination of overlapping orbits, i. These variables contained within the vector were chosen for their compatibility with methods of trade space valuation developed by Chaize [5] and detailed in section 3.4 . The trade space examined in this paper is a full factorial exploration of this vector between reasonable upper and lower bounds of every entry in the vector. The bounds of these variables were determined via analysis of several proposed designs for LEO constellations to provide broadband internet. In the traditional method of developing a constellation architecture, the value of these va riables are constant th roughout the life of the system. With staged deployment, the values of some of these variables are allowed to change at each decision point. For technical or physical reasons only certain elements of the design vector can be changed after initial deployme nt of the system. The elements that comprise the design of an individual satellite, f, Pt, A, and ISL, are assumed to be constant over the lifetime of the system as satellites on orbit cannot be modified and the addition of multiple satellite models introd uces unnecessary and unrealistic complexity to the model as the cost of developing additional satellite models would deter this approach from ever being implemented. The elements of constellation design, h , e, and i , are allowed to evolve at each decision point. This allows the decomposition of the design vector into two parts , xflex, comprised of constellation design elements which will change along the architecture path, and xbase, comprised of satellite design elements that will not change along the arch itecture path. 3.2 Parameters of Proposed Systems. In order to develop a trade space representative of the design space for modern LEO broadband internet constellations, the designs of several proposed constellations were examined. FCC applications by five companies : LeoSat, OneWeb, Telesat, Kepler, and SpaceX, were used to benchmark the architectural design space. As shown in Table 1 below, designs vary greatly even when certain parameters (e.g. altitude and plane inclination in the case of LeoSat and OneWeb) are similar. Table 1: Orbital Parameters of Proposed LEO and VLEO Constellati ons The above table informs the bounds of the trade space for elements of x flex. The systems proposed by OnWeb, Telesat, and SpaceX are in the more advanced stages of development than those proposed by LeoSat and Kepler, and thorough analysis of these sy stems has been conducted by del Portillo [4]. These systems were used to benchmark the trade space boundaries for elements of x trad. Values for these systems are shown in Table 2. Table 2: Satellite Design Parameters of Proposed LEO and VLEO Constellati ons Provider Inclination Altitude No. Sats Min. Elevation Angle LeoSat 90° 1400 km 78 10° Kepler 98.6° 600 km 140 10.4° OneWeb 87.9° 1200 km 720 55° 99.5° 1000 km 37.4° 1248 km 53° 1150 km 53.8° 1110 km 74° 1130 km 81° 1275 km 70° 1325 km 53° 345.6 km 48° 340.8 km 42° 335.9 kmTelesat 117 SpaceX 11943 40°20° Provider Frequency Transmit Power Antenna Diameter Inter Satellite Links OneWeb Ka, Ku 22.5 dBW 2.4 m None Telesat Ka, Ku 26.9 dBW 3.5 m Optical Mesh SpaceX Ka, Ku, V 33.2 dBW 3.5 m Optical Mesh 3.3 Chosen Trade Space The trade space chosen for this paper is shown below, informed by the design parameters of proposed systems. Upper and lower bounds of variables that expressed in units, rather than choices, have been extended beyond the values of proposed systems in order to ensure that the trade space represents the vast majority of feasible architectures. This trade space simplifies several key aspects of constellation design process, including ground stat ion architecture and user terminal architecture. Design parameters dealing with these aspects of the system are held constant for all designs within the trade space . As the goal of this study is to examine the relative, rather than absolute, benefits of st aged architecture, this assumption does not have significant impact on the analysis performed. Another simplification of the trade space is the inclusion of only three choices for inclination of overlapping orbits. In reality proposed systems such as Space X’s Starlink use a variety of inclinations for their overlapping orbits. Due to the extreme enumeration of the tradespace that would result from simulating this type of constellation as well as the lack of available literature from SpaceX justifying this choice, this particular design option was omitted. Inclinations of 30° and 50° were chosen to serve 75% and 95% of the world’s population respectively, per [7]. Table 3: Chosen Architectural Trade Space 3.4 Choice and Determination of Evaluation Metrics Evaluation of the trade space requires metrics by which individual systems can be compared . Chosen metrics were Lifecycle Cost and Capacity, (number of supportable users). These variables have previously been used by Chaize to demonstrate the value of flexibility in a trade space of systems representative of previous generation satellite telephony systems. 3.4.1 Modeling of Capacity Calculations for capacity (adapted from [6] ) integrate the link budget equation for space -based radiofrequency communications with bandwidth, frequency, and time division concerns. It is assumed that the bottleneck for capacity in all cases is the downlink to users. The link budget is governed by the following equation typically evaluated in decibels : 𝐸𝐸𝑏𝑏𝑁𝑁𝑜𝑜� =𝐸𝐸𝐸𝐸𝐸𝐸𝑃𝑃+𝐺𝐺𝑇𝑇�−𝐿𝐿𝑓𝑓𝑓𝑓−𝐿𝐿𝑂𝑂𝑂𝑂ℎ𝑒𝑒𝑟𝑟−𝑘𝑘−𝐸𝐸𝑑𝑑 (3) Variable Units Range Step Altitude km 400-1600 200 Min. Elevation ° 15-60 15 Inclination of Overlapping Orbits - None, 30°, 50° Frequency Band - Ka/Ku, V Transmitter Power W 200-2200 400 Antenna Diameter m 2-4 1 ISL Geometry - None, Ring, Mesh Total Architectures Considered: 9072 Where R d is the data rate that can be provided in bits per second. All proposed systems use frequency division multiple access (FDMA) and time division multiple access (TDMA) schemes to establish channels for downlink to users. The combination of these two channel division methods is referred to as MF -TDMA. The number o f channels that can be delivered for an MF -TDMA system for a given data rate is governed by the equation below. 𝑁𝑁𝐶𝐶ℎ,𝑆𝑆𝑆𝑆𝑂𝑂=𝑍𝑍 2𝐾𝐾𝐵𝐵𝑆𝑆𝑆𝑆𝑡𝑡 𝐵𝐵𝑇𝑇+𝐵𝐵𝐺𝐺𝑅𝑅𝑑𝑑𝑇𝑇𝑓𝑓−𝐹𝐹 𝑛𝑛+𝑅𝑅𝑑𝑑𝑇𝑇𝐺𝐺 (4) Where all variables other than data rate R d are variables conce rning bandwidth allocation that are held constant for all simulated systems due to assumptions detailed in section 3.5 . The total capacity of the system can then be calculated by multiplying the capacity of an individual satellite by the number of satellit es in the constellation. From the number of channels, the user capacity of the satellite can be calculated using equation ( 1). The variable U S in equation (1) is global percent utilization of the system, a number between 0 and 1. This variable represent s the percentage of satellites serving customers at any given time, i.e. satellites that are over inhabited areas and not over large ‘dead’ zones such as oceans, deserts, or the Arctic and Antarctic circles. For purely polar systems with no inter- satellite links this quantity is typically ~0.1 per [12]. This value increases to 0.7 for systems utilizing Ring ISL architecture, in which data can be transmitted between satellites in the same orbit, and 0.9 for systems utilizing Mesh ISL architecture, in which d ata can also be transmitted to satellites in adjacent orbits. 3.4.2 Modeling of Lifecycle Cost Lifecycle costs (LCC) were evaluated from the USCM and the model proposed in [11]. LCC consists of numerous cost elements, some recurring ( CR) and some nonrecurring ( CNR). Recurring costs consist satellite production costs ( CP), of launch costs ( CL), and operation and maintenance costs ( CO). Nonrecurring costs consist of RDT&E costs ( CRD). Where T is the lifetime of the system , NSat,i is the number of sat ellites deployed in year i (including replacements over the lifetime of the constellation ), and LCap is the number of satellites that can be accommodated in a single launch and r is the discount rate. , LCC for a single architecture can be computed from these terms as follows. LCC calculations for flexible systems are given in section 4.2. 𝐿𝐿𝐿𝐿𝐿𝐿 =𝐿𝐿𝑅𝑅𝑅𝑅+∑𝑁𝑁𝑆𝑆𝑆𝑆𝑡𝑡,𝑖𝑖�𝐶𝐶𝐿𝐿 𝐿𝐿𝐶𝐶𝑆𝑆𝐶𝐶+𝐶𝐶𝑃𝑃�+𝐶𝐶𝑂𝑂 (1+𝑟𝑟)𝑖𝑖𝑇𝑇 𝑖𝑖=0 (5) 3.5 Assumptions and Limitations of Model Several major assumptions are inherent to the model of the trade space . The most important of these are those involved in the determination of the capacities of the system. As shown in this figure from [4], the beam footprints for several propos ed systems (Telesat, SpaceX, and OneWeb) vary in both size and shape. In reality, constellation design and optimization of the parameters in the trade space chosen for this analysis would be done in conjunction with optimization of FDMA, TDMA, and beam pattern parameters. For the performance of this analysis, these variables were held constant, as adding them to the trade space would not have added additional flexibility to the system while greatly complicating capacity analysis. Parameters for FDMA, TDMA and beam pattern schemes for both Ka/Ku and V band systems were taken from SpaceX’s FCC filings for their Ka/Ku and V band systems respectively. SpaceX’s FDMA, TDMA, and beam pattern schemes were chosen due to their and the fact that their design is representative of a unified engineering effort and thought process for both Ka/Ku and V band systems, a nd their system is conventional in its use of fixed size, circular beams. Figure 2: Beam footprints of several proposed systems , from [4] 3.6 Presentation of Trade Space Of the over 9000 members of the trade space, the vast majority have very similar, relatively low lifecycle costs. The pareto frontier is comprised of the non -dominated systems along the lower edge of the group having the highest capacity o f all systems at a similar lifecycle cost. Figure 3: Simulated Trade Space with Normalized Bounds 4.0 Valuation of Flexibility 4.1 Identification of Viable Paths and Evolution Rules In order to determine realistic architecture path s, formalized options for evolution need to be established. These rules characterize the possible changes in the elements of x flex during evolutions, after the parameters of x base have been established . These rules are governed by what reasonable changes t o the system can be made. As there is a cost associated with the evolution of the system, ΔC , it is assumed that each evolution of the system involves the addition of new satellites. S tationary ground stations can be configured to interact only with satellites at elevations greater than their minimum elevation , but cannot interact with satellites below their initial elevation as this would require reposition of the ground station antenna . Finally, an additional sub -constellation can be added to p urely polar systems, but only one inclined subsystem can be present in a satellite system, and the inclination of a subsystem cannot be changed once deployed. With these limitations in mind t he following evolution rules are proposed: 1. The number of satellit es increases with each evolution 2. Elevation ( e) can increase or decrease, but cannot be reduced below its original value 3. Inclined orbits can be added to purely polar systems, but cannot be changed or removed 4.2 Decision Model for Architecture Evolution The decision to expand a satellite constellation in real life is contingent upon a number of factors including current demand, expectations of future growth, technical ability, and presence of sufficient revenue to fund the expansion. The decision model us ed in this analysis is greatly simplified and is equivalent to the model used by Chaize [5]: if the demand in year t exceeds the capacity of the system in that year, the evolution of the system to a new architecture that can support the demand is undertak en. This removes uncertainty relating to future demand and funding considerations from the analysis. 4.2 Computation of Lifecycle Cost for Flexible Architecture Evaluation s of lifecycle cost for flexible systems over simulated demand cases are given in [5]. Lifecycle cost for a single flexible architecture path is given in equation (6). 𝐿𝐿𝐿𝐿𝐿𝐿𝑃𝑃𝑆𝑆𝑂𝑂ℎ=𝐿𝐿𝑅𝑅𝑅𝑅+∑ (∑�𝑁𝑁𝑆𝑆𝑆𝑆𝑡𝑡,𝑖𝑖�𝐶𝐶𝐿𝐿,𝑗𝑗 𝐿𝐿𝐶𝐶𝑆𝑆𝐶𝐶+𝐶𝐶𝑃𝑃,𝑗𝑗�+𝐶𝐶𝑂𝑂,𝑗𝑗 (1+𝑟𝑟)𝑖𝑖�𝑇𝑇𝑗𝑗 𝑖𝑖=𝑂𝑂𝑗𝑗+∆𝐿𝐿𝑗𝑗,𝑗𝑗+1)𝑁𝑁𝑆𝑆 𝑗𝑗=1 (6) Where NS is the number of stages deployed, tj and Tj are the year of deployment of and year of retirement (due to deployment of the next stage or reaching the end of the system lifetime) of stage j, and C L,j, CP,j, and CO,j, are the yearly launch, production, and O&M costs of stage j, and ∆𝐿𝐿𝑗𝑗,𝑗𝑗+1 is the cost of transitioning from stage j to stage j+1 . 4.3 Method for Valuing Flexibility The value of embedding flexibility is equal to the difference between the lifecycle cost of the traditional architecture that can meet the forecasted demand and the lifecycle cost of the architecture path that can meet this demand. The percent cost reduction afforded by flexibility is given in equation (7). After the value of embedding flexibility into the system is determined, the price to embed this flexibility can be d etermined. If the cost of embedding flexibility is less than the value that it provides, the flexibility should be embedded into the system in question. % 𝐸𝐸𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 =𝐿𝐿𝐶𝐶𝐶𝐶𝑇𝑇𝑈𝑈𝑆𝑆𝑑𝑑−𝐿𝐿𝐶𝐶𝐶𝐶𝑃𝑃𝑆𝑆𝑡𝑡ℎ 𝐿𝐿𝐶𝐶𝐶𝐶𝑇𝑇𝑈𝑈𝑆𝑆𝑑𝑑 (7) 5.0 Case Study Trends for the value of flexibility in satellite communication system constellations are characterized in [5]. For this analysis, two specific scenarios were chosen to demonstrate the value of flexibility in systems designed to deliver broadband internet. These cases are the ‘High Growth’ (Scenario A) and ‘Low Growth’ (Scenario B) cases forecasted by the Northern Sky Research group in [3]. 5.1 Definition of Scenario s The lifetime TSys chosen for study is 10 years, with options for expansion every two yea rs. Demand at each decision point for Scenario s A and B are listed below. The per -user activity rate, A User, is set to 6hr/week, representative of the average amount of time spent on the internet in an average week in U.S. households per [ 2]. Table 4: U ser Demand in Scenarios A and B Note that there is an implicit assumption that one system will be serving the entire customer base. With scenarios established, traditional architectures can be established. 5.2 Determination of Traditional Architecture Traditional architectures for each scenario, x trad,A and xtrad,B, are th e pareto -optimal (minimum lifecycle cost) architectures with capacities greater than Cap Max. Parameters of these systems for Scenario A and B are given below. Time (yrs) Demand (Scenario A) Demand (Scenario B) 0 2,500,000 2,500,000 2 3,750,000 3,150,000 4 6,000,000 4,250,000 6 10,325,000 6,350,000 8 16,250,000 8,150,000 10 23,000,000 9,500,000 Table 5: Parameters of Traditional Architectures for Scenarios A and B 5.3 Choice of Flexible Architectures Choice of a flexible architecture path begins with the choice of the initial stage and values of xbase. Note that the ideal starting point for a path may not be a pareto -optimal architecture, as a path may become more optimal as it evolves. For this analysis the pareto -optimal initial architecture was chosen for both cases. Parameters of the the initial architecture are shown below. The variables of xflex are the parts of the initial architecture that can be altered in order to increase the capacity of the system. Table 6: Parameters of Initial Architecture For the first several stages in each scenario several possible evolutions exist. In both cases the optimal evolution path does not immediately deploy an overlapping sub -constellation, but rather waits until the third evolution to deploy a new constellation. This particular evolution incurs significant cost due to the high number of satellites that m ust be launched, and waiting several years to do so allows the present cost of the evolution to decrease significantly. Evolution paths for scenarios A and B are shown in tables 7a and 7b below. Parameter xtrad,A xtrad,B Units h 1,600 1,400 km e 30 15 ° i None 30° - f Ka/Ku Ka/Ku - Pt 1,600 1,400 W A 2 3 m ISL Ring Mesh - Cap 23,054,294 10,040,895 Users LCC 123.81 50.52 $B Parameter xinitial Units h 1,600 km e 30 ° i None - f Ka/Ku - Pt 200 W A 2 m ISL Ring - Cap 2,561,588 Users LCC 10.44 $BXflex Xbase Table 7a: Optimal Architecture Path in Scenario A Table 7b: Optimal Architecture Path in Scenario B. 5.4 The Value of Flexibility in These Cases In both scenarios the introduction of flexibility into the system was effective in reducing the lifecycle cost of the system. Additionally, there is room for cont inued expansion in both cases, as neither the altitude nor minimum elevation of each system have reached their final capacity -maximizing values . Table 8: Value of Flexibility in Scenarios A and B 6.0 Conclusions and Future Work The addition of flexibility to satellite broadband systems via staged deployment does indeed create value in cases where market growth is present. In order to determine whether or not this value in fact yields an economic opportunity additional research must be done into pricing the flexibility. An additional productive avenue of future research would be to further refine this analysis to yield only paths that generate sufficient revenue to fund the evolution of the system. Time (yrs) NUser (Scenario A) Capacity Evolution 0 2,500,000 2,561,588 None 2 3,750,000 4,996,524Decrease altitude to 1400 km, increase elevation to 30° 4 6,000,000 7,747,109 Decrease altitude to 1200 km 6 10,325,000 11,620,663 Add an overlapping constellation at 30° 8 16,250,000 27,945,155Increase altitude to 1400 km, increase elevation to 45° 10 23,000,000 27,945,155 None Time (yrs) NUser (Scenario B) Capacity Evolution 0 2,500,000 2,561,588 None 2 3,150,000 3,293,471 Increase Elevation to 30° 4 4,250,000 4,996,524 Decrease Altitude to 1400 km 6 6,350,000 7,686,960 Add an overlapping constellation at 30° 8 8,150,000 11,620,663 Decrease altitude to 1200 km 10 9,500,000 11,620,663 None Variable Scenario A Scenario B Units LCC, xtrad 123.81 50.52 $B LCC, path 103.89 38.90 $B Value of Flexibility 19.92 11.62 $B % Cost Reduction 16 23 %