AIAA-2003-6317

ENHANCING THE ECONOMICS OF COMMUNICATIONS SATELLITESVIA ORBITAL RECONFIGURATIONS AND STAGED DEPLOYMENT

Olivier L. de Weck∗ , Richard de Neufville† and Mathieu Chaize‡

Massachusetts Institute of Technology, Cambridge, MA 02139, USA

The “traditional” way of designing constellations of communications satellites is tooptimize the design for a specified global capacity. This approach is based on a forecastof the expected number of users and their activity level, both of which are highly uncer-tain. This can lead to economic failure if the actual demand is significantly smaller thanthe one predicted. This paper presents an alternative flexible approach. The idea is todeploy the constellation progressively, starting with a smaller, more affordable capacitythat can be increased in stages as necessary by launching additional satellites and recon-figuring the existing constellation in orbit. It is shown how to find the best reconfigurableconstellations within a given design space. The approach, in effect, provides system de-signers and managers with real options that enable them to match the system evolutionpath to the actual unfolding demand scenario. A case study demonstrates significanteconomic benefits of the proposed approach, when applied to Low Earth Orbit (LEO)constellations of communications satellites. In the process, life cycle cost and capacityare traded against each other for a given fixed per-channel performance requirement.The benefits of the real options approach demonstrably increase, with greater levels ofdemand uncertainty. A generalized framework is proposed for large capacity systemsfacing high demand uncertainty.

NOMENCLATUREAuser = Average user activity, [min/month]Cap = Capacity, [# of users]Capmax = Maximum capacity, [# of users]DA = Antenna diameter, [m]Dinitial = Initial demand, [# of users]IDC = Initial development costs, [$]ISL = Inter satellite links, [0,1]LCC = Life cycle cost, [$B]LCC∗ = Life cycle cost of optimal path, [$B]Nuser = Number of system users (subscribers)Nch = Number of (duplex) channelsOM = Operations and maintenance costs, [$]PV = Present Value (FY2002), [$]Pt = Satellite transmit power, [W]S = Stock price, [$]Tsys = System lifetime, [years]Us = Global system utilization [0...1]h = Orbital altitude, [km]path? = Optimal path of architecturesr = Discount Rate, [%]x = Design vectorxtrad = Best traditional design vector∆C = Evolution costs (transition matrix), [$]

∗Assistant Professor, Department of Aeronautics and Astro-nautics, Engineering Systems Division (ESD), Member.

†Professor of Engineering Systems and of Civil and Environ-mental Engineering, Engineering Systems Division.

‡Graduate Research Assistant, Department of Aeronauticsand Astronautics, Member.

Copyright c© 2003 by Olivier L. de Weck. Published by theAmerican Institute of Aeronautics and Astronautics, Inc. with per-mission.

∆t = Time step for the binomial tree, [years]ε = Minimum elevation angle, [deg]µ = Expected return per unit time, [%]σ = Volatility, [%]

INTRODUCTIONIn 1991, the forecasts for the U.S. terrestrial cellular

telephone market were optimistic and up to 40 millionsubscribers were expected by the year 2000.1 Simi-lar projections were made for the potential size of themobile satellite services (MSS) market. The absenceof common terrestrial standards such as GSM in Eu-rope and the modest development of cellular networksat that time encouraged the development of “big” LowEarth Orbit (LEO) constellations of communicationssatellites such as Iridium and Globalstar2 with ini-tial FCC license applications in December 1990 andJune 1991, respectively. The original target marketfor those systems was the global business traveller, outof range of terrestrial cellular networks. However, bythe time the aforementioned constellations were de-ployed in 1998 and 2000, the marketplace had beentransformed. The accelerated development and stan-dardization of terrestrial cellular networks resulted inover 110 million terrestrial cellular subscribers in 2000in the U.S. alone. This exceeded the 1991 projectionsby more than 100%. The original market predictionsfor satellite services, on the other hand, proved to beoverly optimistic.

The coverage advantage of satellite telephony wasnot able to offset the higher handset costs, service

1 of 14

American Institute of Aeronautics and Astronautics

Space 200323 - 25 September 2003, Long Beach, California

AIAA 2003-6317

Copyright © 2003 by Olivier de Weck. Published by the American Institute of Aeronautics and Astronautics, Inc., with permission.

AIAA-2003-6317

charges and usage limitations relative to the terres-trial competition. As a result of lacking demand, both,Iridium and Globalstar had to file for bankruptcy inAugust 1999 (>$B4 debt) and February 2002 ($B3.34debt), respectively. Nevertheless, a steady demand forsatellite based voice and data communications existsto this day, albeit at a significantly lower subscriberlevel than originally expected.

Traditional approach

The cases of Iridium and Globalstar illustrate therisks associated with the traditional approach to de-signing high capital investment systems with high fu-ture demand uncertainty. The traditional approachfirst establishes a capacity requirement based on mar-ket studies and “best guess” extrapolations of currentdemand. The two quantities that have to be estimatedare the expected global number of subscribers, Nuser,as well as their average individual activity level, Auser.The number of (duplex) channels that the system hasto provide to satisfy this demand, Nch, represents theinstantaneous capacity requirement:

Nch =Nuser ·Auser

Us · 36512 · 24 · 60

(1)

where Us is the global system utilization, a frac-tion between 0 and 1. Substituting numbers that arerepresentative of Iridium one might have expected aglobal subscriber base, Nuser = 3 · 106, and an aver-age monthly user activity of Auser = 125 [min/month].Global system utilization, Us, is typically around 0.1according to Lutz, Werner and Jahn.2 This numbercaptures the fact that only a fraction of satellites isover inhabited, revenue generating terrain at any giventime. Substituting these values in Eq.(1) results in aconstellation capacity of Nch = 85, 616. The capacityof Iridium is quoted as 72,600 channels.4

Next comes the process of designing a constellationthat meets this capacity requirement, Nch, while min-imizing lifecycle cost, LCC. Lifecycle cost includesRDT&E, satellite manufacturing and test, launch, de-ployment and checkout, ground stations, operationsand replenishment. A trade space exploration for LEOsatellite constellations was previously developed by deWeck and Chang.3 The most important “architec-tural” design decisions for the system are captured bya design vector, x = [h, ε, P t, DA, ISL]. Each entry ofthe design vector is allowed to vary between reasonableupper and lower bounds. The constellation is definedby its circular orbital altitude, h, and minimum eleva-tion angle, ε. The communications satellite design isdefined by the transmitter power, Pt, the service an-tenna diameter, DA, and the use of intersatellite links(ISL = 1 or 0).

Other parameters, such as the constellation type

(polar), system lifetime, Tsys = 15 [yr], or the multi-access scheme (MF-TDMA)2 are held constant. Thecommunications quality (performance) is also heldconstant for all systems with a per-channel data rate of4.8 [kbps], a bit-error-rate of 0.001 and a link marginof 16 [dBi]. A multidisciplinary simulation of the sys-tem maps x to the corresponding capacity, Nch, andlifecycle cost, LCC. The simulation is benchmarkedagainst Iridium and Globalstar to validate the under-lying models.3 One may explore this design space,also called “trade space”, using optimization9 or a fullfactorial numerical experiment, see Figure 1.

� ��� � � � � ��� � ��� � ��� � ��

� �

� � �

� �� � � � � � � � ��� � � � � ����� ��� � � � ��� �

!"# $% &%' $( )*+!((,- ./ 0�1 � 2 �3� ��� � �3� � 4 ��� � � 5 01 � 2 � � � � � 4 63� � 1 � � �

7� 1 � � �8 1 � �

2 � �9� � � � 22 � � � :

� ; 2 � �<� � � � 22 � � � :

=�> ? ? @ AB C C B D EF G H > F I

JLK ? F @ A> H M @ ? F E=�@ H F

N O P O Q ROLS T U�V O SW X Q Y V Y Z [ Z \ ]�S T O ^ Z \ ]_ N O ` \ Z Q O

acbd

Fig. 1 Trade space of 600 LEO constella-tion architectures: h(400, 800, 1200, 1600, 200) [km],ε(5o, 20o, 35o), Pt(200, 600, 1000, 1400, 1800) [W], DA =(0.5, 1.5, 2.5, 3.5) [m], ISL(1, 0)

Each asterisk in Figure 1 corresponds to a partic-ular LEO constellation design. The non-dominateddesigns approximate the Pareto front17 and are themost interesting, since they represent the best achiev-able tradeoff between capacity and lifecycle cost. For atarget capacity Nch = 86, 000 (scenario A) we find theintercept of the vertical dashed line and the Paretofront. The design xtrad = x184 = [800, 5, 600, 2.5, 1]is the best choice for this requirement and the simu-lator predicts a capacity, Nch = 80, 713 and lifecyclecost LCC = 2.33 [$B] (with r=0) for this solution.Note that this constellation is quite similar to Iridium,xIridium = [780, 8.2, 400, 1.5, 1].

In the traditional approach one would select this de-sign and implement the constellation accordingly, seeFigure 2. The traditional approach for selecting ar-chitectures (designs) thus implies designing for a fixedtarget capacity. When demand is uncertain, this re-quired capacity can be difficult to estimate and therisks can be significant. In reality, future demandshould be described by a (unknown) probability den-sity function.

2 of 14

American Institute of Aeronautics and Astronautics

AIAA-2003-6317

Fig. 2 Satellite Constellation x184 has 5 circularpolar orbits at an altitude of h = 800 [km] and aminimum elevation angle of ε = 5o. The 50 satel-lites have a transmitter power of Pt = 600 [W],an antenna diameter of DA = 2.5 [m] and inter-satellite links. This constellation has a capacity ofNch = 80, 713 channels and an expected lifecycle costof LCC = 2.33 [$B].

Consider scenario B in Figure 1. If the actual de-mand is larger than that of the nominal scenario A,requiring a capacity Nch on the order 5 · 105, therewill be a missed opportunity. The chosen system,xtrad = x184 will be saturated and cannot satisfy theexcess demand estimated at 14.72 million users. Com-petitors will gladly fill the gap.

A more serious situation is scenario C in Figure 1,where significant excess capacity is available in thesystem. In that case (see Iridium, Globalstar) therevenue stream may not be sufficient to recuperatethe initial investment. If the actual market is only,Nuser ≈ 350, 000 instead of the 3 million expected, acapacity of Nch ≈ 10, 000 would have sufficed to pro-vide service. The difference in lifecycle cost betweenxtrad = x184 and the most affordable low capacitysystem x34 = [800, 5, 200, 1.5, 1] with a capacity ofNch,34 = 9, 692 and lifecycle cost of LCC34 = 1.47[$B] is $860 million. This must be viewed as a wastedinvestment into architecture x184. Ideally, one wouldwant the ability to adjust the capacity of the systemto the evolving demand. This is the main subject ofthis article.

Flexible Approach

This article introduces a staged deployment ap-proach for designing constellations of communicationssatellites in order to reduce the economic risks. Stageddeployment is a particular way of introducing flexibil-ity in a system. It reduces the economic risks of aproject by deploying it progressively, starting with a

smaller and more affordable capacity than the one re-quired by the traditional approach. When there isenough money to increase the capacity or if demandfor the service exceeds the current capacity, the sys-tem is upgraded to a new stage with a higher capacity.This approach does not design for a target capac-ity but tries to find an initial architecture that willgive system managers the flexibility to adapt to mar-ket conditions. This, however, poses new challengesto designers. A first issue is that the possible evolu-tions from an initial architecture to higher capacityones have to be identified and understood. An idealstaged deployment would follow the Pareto front ofFigure 1. This, however, is not necessarily feasible.Fundamentally this is true because staged deploymentimplies the use of legacy components (the previouslydeployed stages) which reduces the number of designdegrees of freedom in subsequent stages of the system.Consequently, the structure of the trade space and therelationship between architectures have to be clearlydefined and modelled. A second issue is that the priceto pay to embed flexibility into the design is not easilydetermined. The reason is that the technologies in-volved may not be known or accurately modelled. Alast issue is that the requirements are not an expectedlevel of demand that is fixed through time but an un-certain demand. This uncertainty has to be modelledand integrated in the design process. This marks a dis-tinct departure from the traditional approach becausemarket conditions are directly taken into account bydesigners. The key idea is to consider the ability tostage deploy in the future as a “Real Option”.

Literature Review

Economics of constellations of communicationssatellites

The technical principles of communications satel-lites are relatively well known and are presented byLutz, Werner and Jahn,2 among others. To comparethe performances of constellations with different ar-chitectures, Gumbert5 and Violet6 developed a “costper billable minute” metric. Six mobile satellite phonesystems were analyzed with this metric.7 The set ofsystems studied contained LEO, MEO, GEO and el-liptical orbit systems. A methodology called the Gen-eralized Information Network Analysis (GINA) wasdeveloped by Shaw, Hastings and Miller8 to assess theperformance of distributed satellite systems. GINAwas applied to broadband satellite systems and is be-ing extended to evaluate scientific missions. Jilla9

refined the GINA methodology to account for multi-disciplinary design optimization (MDO) and proposeda case study for broadband communications satel-lites. Kashitani10 proposed an analysis methodologyfor broadband satellite networks based on the works of

3 of 14

American Institute of Aeronautics and Astronautics

AIAA-2003-6317

Shaw and Jilla. The study compared LEO, MEO andelliptic systems and showed that the best architecturedepends on customer demand levels. An architecturaltrade methodology has been developed by de Weck andChang3 for the particular case of LEO communicationsystems. The simulator implemented by de Weck andChang has been used to generate the results shown inFigure 1.

Flexibility in Space Systems

The vast majority of space systems are designedwithout any consideration of flexibility. One of themain reasons is that operations in space are difficultand expensive. Also, it is difficult to convince design-ers to incorporate flexibility when the requirement forit cannot absolutely be proven a priori. Moreover, itmust be said that flexibility is not for free and thatvarious forms of upfront performance, mass, reliabil-ity and cost penalties must often be accepted in orderto embed flexibility in a complex, technical system.Saleh11 and Lamassoure12 studied on-orbit servicingfor satellites and the potential economic opportunityit might represent. On-orbit servicing provides theflexibility to increase the lifetime of the satellites orto upgrade their capabilities. Lamassoure proposed toconsider the decision of using on-orbit servicing as areal option.

Staged Deployment for Space Systems

Staging the deployment of a space system to re-duce the economic and technological risks has beenenvisioned for both military and scientific missions.Miller, Sedwick and Hartman13 studied the possibil-ity of deploying distributed satellite sparse aperturesin a staged manner. The first stage serves as a tech-nology demonstrator. Additional satellites are addedto increase the capability of the system when desired.The Pentagon also plans to deploy space-based radars(SBR) in a staged manner.14 A first SBR constella-tion will be launched in 2012, but will not provide fullcoverage. This will allow the tracking of moving tar-gets in uncrowded areas. To enhance the capability ofthis constellation, a second set of satellites could belaunched in 2015, “as-needed and as-afforded”. TheOrbcomm constellation is an example of a constella-tion of communications satellites that was deployed ina staged manner. A short history of this system ispresented by Lutz, Werner and Jahn.2 The Orbcommconstellation started its service even though not allof its satellites were deployed. Satellites were addedthrough time, in accordance with a predefined sched-ule. The advantage of this approach is that the systemstarted to generate revenue very early. However, deci-sion makers did not take into account the evolution ofthe market and did not adapt their deployment strat-

egy accordingly.Kashitani10 compared the performances of systems

in LEO and MEO orbit and their behavior with respectto different levels of demand. His conclusion was thatelliptical systems were more likely to adapt to marketfluctuations because they could adjust their capacityby deploying sub-constellations. Having the ability toadd “layers” to a constellation with sub-constellationscould enable an efficient staged deployment strategy.

Staged Deployment in other DomainsThe staged deployment strategy has been consid-

ered in different domains. Ramirez15 studied the valueof staged deployment for Bogota’s water-supply sys-tem. Three valuation frameworks were compared: netpresent value (NPV), decision analysis (DA) and realoptions analysis (ROA). The flexible approach alloweda decrease in the expected life cycle costs of the sys-tem. Takeuchi et al.16 proposed to build the Interna-tional Fusion Materials Irradiation Facility (IFMIF) ina staged manner. The full performance of the facility isthen achieved gradually in three phases. The claim isthat this approach reduces the overall costs for IFMIFfrom $M 797.2 to $M 487.8.

STAGED DEPLOYMENTEconomic opportunity

Embedding flexibility in a system allows the exis-tence of decision points through time. At a decisionpoint, the values of parameters that were uncertainare analyzed. Depending on these values, a decision ismade to adapt to them in the best possible manner.Since uncertain parameters are observed through time,uncertainty is reduced, thus reducing the risks of theproject.

Decisions can be of various types, ranging from ex-tending the life of a project to cancelling its deploy-ment. This article focuses on the flexibility providedby staged deployment when demand is the uncertainparameter. The decision in this case is about whetheror not to move to the next stage in the deploymentprocess. This approach represents an economic oppor-tunity compared to the traditional way of designingsystems because it takes current market conditionsinto account. Two mechanisms explain this advantage.The staged deployment strategy tries to minimize theinitial deployment costs by deploying an affordablesystem but, the expenditures associated with transi-tion between two stages can be large. However, sincethose expenditures are pushed towards future times,they are discounted. Indeed, if r is the discount rate,Q the cost for deploying a new stage and t the numberof years between the initial deployment of the systemand the time the new stage is deployed, the present

4 of 14

American Institute of Aeronautics and Astronautics

AIAA-2003-6317

value (PV ) of the cost considered is given by Equa-tion (2):

PV (Q) =Q

(1 + r)t (2)

The higher t is, the smaller the cost for deploying anew stage is in terms of present value. Consequently,the first economic advantage of staged deployment isthat it spreads expenditures in time.

The second mechanism is that the stages are de-ployed with respect to market conditions. If the marketconditions are unfavorable, there is no need to de-ploy additional capacity. Expenditures are kept low toavoid economic failure. On the other hand, if demandis large enough and revenues realized are sufficient,the capacity can be increased. The economic risks areconsiderably decreased with this approach since stagescan be deployed as soon as they can be afforded andwhen the market conditions are good.

Paths of architectures

The flexible approach implies that elements of thesystem can be modified after initial deployment. Thisconcept can still be represented in a trade space suchas the one of Figure 1. With the traditional approach,architectures were considered “fixed” that is to saythat their design vector, x, could not evolve after theinitial deployment of the system. With staged deploy-ment, evolutions of those variables are allowed. Fortechnical or physical reasons, certain design variablesof a system may not be changed after its deployment.This motivates a decomposition of the design vectorinto two parts (see Equation 3):

• xflex gathers all the design variables that are al-lowed to change after the deployment of the sys-tem. Those design variables are the ones thatprovide flexibility to the system.

• xbase represents all the design variables that can-not be modified after the deployment of the sys-tem. Those design variables thus represent thecommon base that the stages will share.

x =[

xflex

xbase

](3)

The deployment of a new stage will be reflected by achange in xflex. This implies that a staged deploymentstrategy will move from architecture to architecturein the trade space as new stages are deployed. Theevolutions that are of interest increase the capacityof the system. These “paths of architectures” can benotionally represented in the original trade space suchas the one represented in Figure 3.

The lifecycle cost of a staged deployed system, how-ever, does not correspond to the sum of the pro-rated

***

***

*

**

**

*

**

������� ��� ��������� � �

*

� ��� ��� ���

*

* � ������ � �!�#"$�

%'&

%)(

%+*%),%-����.�� � ���� /$���� �� .

Fig. 3 Example of a path of architecturesin a Trade Space. The series of architectures(A1 → A2 → A3 → A4) represents a valid path. In or-der to be valid all four architectures have to sharethe same sub-vector xbase.

LCC of the inidividual systems A1 through A4. Thiswill be discussed further. The selection of a systemdiffers from the traditional approach with staged de-ployment. Instead of a fixed architecture one selectsan architectural path, and most importantly the initialstage, A1. Whether or not the architecture path is ac-tually followed, depends on the evolution of uncertainparameters over time as well as the decisions made bysystem managers.

Identifying Sources of Flexibility

Potential sources of flexibility must first be iden-tified, by selecting the elements of the design sub-vector, xflex, as well as their range (or “bandwidth”)of flexibility. This was applied to the case of LEOconstellations with the aforementioned design vector,x = [h, ε, Pt, DA, ISL] and the allowable values shownin the caption of Figure 1.

On-orbit modification of satellites is virtually im-possible, even though there is increasing interest inreconfigurable spacecraft. On-orbit servicing is notyet sufficiently developed to consider satellite hard-ware modification or swap-out. Consequently, designvariables such as Pt, Da or ISL have to be consid-ered fixed. These three design variables define theindividual satellite design. An advantage of keepingthe satellites identical across stages are manufacturingeconomies of scale and learning curve savings.

The remaining design variables are h and ε; theydrive the constellation arrangement.18 The altitudeh can be changed after the satellites are deployedbecause it does not necessitate any changes in thehardware of the system. This will, however requirecarrying additional fuel and phased array antennas inorder to adjust the size and shape of the beam patternat various altitudes. These two variables form xflex

5 of 14

American Institute of Aeronautics and Astronautics

AIAA-2003-6317

and we may write:

x =[

xflex

xbase

]=

h ε︸ ︷︷ ︸

xflex

Pt DA ISL︸ ︷︷ ︸xbase

T

(4)

An example of a path in the trade space is givenin Figure 4. Note that all satellites are identical inthis “family” of architectures. Here, Cap = Nuser isused as capacity, rather than the number of channels,Nch. Nuser can be solved from Eq. (1) and is moreconvenient to use as a capacity metric from here onout, since it can directly be related to the uncertainmarket demand.

� � � � � � � � � � � �

� � �

�� � � ���� ��� � � ����� ��� ��� � � ! "#� � � "�� � $

%&' () *)+ (, -./%,,01 23

�4� ��� � � ��5 6 � � � � �47 � �98 � : � ;<�4� 6�� � = = � � � 6<>?� ��= � � @A� 6

8 � : � �8 � : �4B

8 � : ��C

8 � : � � 8 � : �4B 8 � : �9C

D E B � � � � � @A$B � � � � = = � � �C9� = � 6 � �

D E F � � � � @A$G � � � � = = � � �G4��= � 6 � �

D E#H � � � � @�$� � B�� � � = = � � �F ��= � 6 � �

I � � @A� ;<� 6�� 6= � J?� = � � � : � � 6� �� � ; �9� ��� � �

Fig. 4 Staged deployment path at the low ca-pacity end of the trade space. All satellites instages 1,2,and 3 are identical: xbase = [Pt, DA, ISL] =[200, 0.5, 1]. The minimum elevation is held constantat ε = 5o.

It can be noted that the number of satellites in-creases with each additional stage. Also, Stage 1is non-dominated and corresponds to design vectorx1 in the trade space, however, the system becomes“suboptimal” as it grows, i.e. its distance from thePareto front grows. There also exist paths that startsub-optimal and become more optimal as the systemgrows. Moreover, as h or ε are modified, the config-uration of the satellites in the system changes. Con-

sequently, the staged deployment strategy consists oftwo parts:

• the launch of additional satellites

• the reconfiguration of on-orbit satellites from theprevious stage to form a new constellation

The flexibility that has to be brought to the systemis thus ability to add satellites and to move on-orbitsatellites to increase the capacity. The technical fea-sibility, astrophysical constraints and optimization ofsuch maneuvers are currently under investigation.19 Itis important to know if this flexibility can indeed re-duce the economic risk compared to the traditionalapproach, even if an upfront penalty (e.g. extra fuel)must be incurred. This means that the value of thisflexibility has to be estimated. Real Options Analysis(ROA) is helpful in this context, since it can providethe value of flexibility without having to consider thetechnical details of how to embed it.

Real Options Analysis

A real option is a technical element embedded ini-tially into a design that gives the right but not theobligation to decision makers to react to uncertainconditions. In this study, it is considered that flexi-bility is provided by real options that give the abilityto change h and ε after a constellation is deployed.Therefore, the real options give the opportunity to re-configure constellations after they have been deployed.The key technical elements of the real option are addi-tional propellant and phased array antennas for beampattern tuning. Consequently, there exist differenttechnical solutions to embed this flexibility. However,they will not be considered in the first phase of theapproach. Indeed, the real options approach allowsdesigners to focus on the value of flexibility withouthaving any technical knowledge of the way to embedit. It is assumed that it is feasible to embed this flexi-bility and the price to pay for it is neglected initially.From there, the cost of a flexible system that can adaptto an uncertain environment is compared to the lifecycle cost of the best traditional system, xtrad. Thedifference between those costs will define the value offlexibility. If the life cycle costs of the flexible approachare smaller than the life cycle costs obtained with thetraditional approach, an economic opportunity is re-vealed and the difference between those costs defines amaximum price one would be willing to pay to embedflexibility. From there, technical ways to implementthose real options could be sought, priced and com-pared with this maximum price. On the other hand, ifthe flexible solution does not present any value, thenother sources of flexibility should be envisioned. Thesteps of this approach are summarized in Figure 5.

6 of 14

American Institute of Aeronautics and Astronautics

AIAA-2003-6317

� ����� � � � � ���� � � ������ � � � � ��� � � � �

�

��� ��� � ����� � � ��� ��� � � � �

�

��� � � � ��� � � ��� ��� � � � �

�

� �� � �! � � � "�� #�� ���� � ������ � � ��� ��� � � � ���

$ ��� �� �%�� "��� � ��#���&'� ��"�� � ��� �

� � %���"�� � ���(���� � � ��� ��� � � � �)� � *�� � %�� #)� %���+� � � ��� �+� �)� �� �� � �

, � � ��� ��� � � � � � �- %������ .����� &'��� .�.�� .

���

���

���

#��

#��

#��

/ 0012 03045 637083967022 : 6;< =< :<4 >

Fig. 5 General Real Options reasoning framework.

This article only focuses on the first two steps of theframework. The identification and selection of sourcesof flexibility has already been discussed. The valu-ation methodology for a staged deployment strategywill be discussed in the next section. None of thesesteps consider detailed technical ways of embeddingthe real options. For satellite constellation reconfigu-ration, these aspects are being addressed by Scialomand will be discussed in the future.19 Consequently,the approach discussed here tries to reveal economicopportunities rather than study their technical details.The main interest of this methodology is that it canprevent seeking technical solutions that provide flexi-bility without economic value. On the other hand, ifan economic opportunity is revealed for a particulartype of flexibility, it can motivate research into newtechnical solutions.

FLEXIBILITY FRAMEWORKAssumptions

To find the best staged deployment strategy, aframework has been developed to seek paths of ar-chitectures with the greatest values. This frameworkimplicitly assumes that a simulator exists that achievesa mapping between x and performance, capacity, Capand lifecycle cost, LCC.3 Moreover, the sources offlexibility should already have been identified throughpartitioning of the design vector, see Eq.(4).

Flexibility has value in the presence of uncertainty.In this study, the uncertain parameter is demand. Sev-eral assumptions were made. First, the system shouldbe able to provide service for a certain maximum,target demand. This means that a targeted capac-ity Capmax is set and that a path can be consideredif and only if at least one of the architectures in thepath has a capacity higher or equal to Capmax. This

assumption sets constraints on the paths to considerbut also defines the traditional design with which thefinal solution is going to be compared with, xtrad.

A second assumption is that the flexible system triesto adapt to demand. As soon as demand is higherthan the current capacity, the next stage of the systemis deployed. This can be represented by a decisiontree.20 This assumption is natural for systems thatprovide a service without trying to generate profits.For instance, for a water supply system, it is vital thatthe system adapts to demand. A third assumption isthat the price to embed flexibility into existing designsis not taken into account. This is because the valueof a real option is considered first, and not its price.A last assumption is that demand follows a geometricBrownian motion, which is represented as a binomialmodel in discretized time. This assumption will beexplained in the presentation of the model for demand.

The organization of the flexibility valuation frame-work for staged deployment has been summarized inFigure 8. This section will present each step of theprocess.

Definition of Parameters

The maximum achievable capacity that the systemshould provide, Capmax should be defined. In thisstudy, the capacity corresponds to a certain numberof users, Nuser, to which the system can ultimatelyprovide service. Capmax is usually only achieved aftera number of stages. A minimum capacity, Capmin, canalso be defined. This is a conservative lower bound onthe capacity that will certainly be needed. A path ofarchitectures can be selected if and only if the smallestcapacity it provides (given by the first architecture) ishigher than Capmin and the highest capacity it canprovide (given by the last architecture) is higher thanCapmax. These considerations will thus reduce thenumber of paths to consider. The discount rate, r ,alsohas to be set as well as several parameters that allowmodelling the demand: µ, σ, ∆t and Dinitial. Finally,the total lifetime of the system considered, Tsys, hasto be defined.

Best Traditional Architecture, xtrad

The framework compares the staged deploymentstrategy with the traditional approach as explainedabove. The traditional approach will select the non-dominated architecture that is closest to Capmax, butgenerally with a slightly higher capacity. The first stepof the framework is to determine this architecture de-noted xtrad as discussed earlier in the article. The lifecycle cost of this architecture is LCC(xtrad) and it willeventually be compared with the life cycle cost of thebest path. If the Pareto front is already known, xtrad

can be easily obtained. Otherwise, an optimization

7 of 14

American Institute of Aeronautics and Astronautics

AIAA-2003-6317

algorithm9 can determine xtrad by searching for thearchitecture with minimal life cycle costs among thearchitectures with a capacity greater than Capmax.

Identification of the Feasible Paths

From the decomposition of the design vector pre-sented in Eq. (3), paths of architectures can be gener-ated.20 These need to satisfy certain conditions. First,it is assumed that the deployment of a new stage al-ways implies an increase in system capacity. A betterway to adapt would be to increase or decrease capac-ity to get as close as possible to the actual demand(with some safety margin). The systems concerned bythis research, however, are large capacity systems withlow operations costs relative to the initial deployment(investment) cost. In this situation, decreasing the ca-pacity does not present any value since the reduction ofthe operations costs expected may be smaller than theinvestments necessary to decrease capacity. This is incontrast with capacity adaptation in the airline indus-try, where operations costs are a major concern, wherethe Cash Airplane Related Operating Costs (CAROC)represent 60% of the operating budget. In that casethe decommissioning of assets during low demand pe-riods can be beneficial. The expense of operating areliable satellite constellation with 21 satellites is nottoo different from operating one with 50 satellites.Consequently, it is assumed that the capacity of thesystem increases as new stages are deployed. A secondcondition that paths need to meet is that the initial ca-pacity of the path is higher than Capmin and that thelast architecture has a capacity higher than Capmax.The details of finding feasible paths, starting from afamily of architectures that share a common xbase arediscussed by Chaize.20

Modelling of Demand Uncertainty

To represent the uncertainty in the size of the mar-ket and its evolution, it is assumed that demand fol-lows a geometric Brownian motion. This assumptionis commonly used in the financial domain to model theprice of a stock, S. The discrete-time version of thismodel is given by the following equation:

∆S

S= µ∆t + σΓ

√∆t (5)

S represents the current stock price, Γ is a randomvariable with a standardized normal distribution and∆t the time step of the discretization. Consequently,∆SS represents the rate of change of the stock price dur-

ing a small interval of time ∆t. µ and σ are constantsin this formula. Their meaning can be understoodwith simple mathematical considerations. The ex-pected value and the variance of the rate of change

of S are:

E

[∆S

S

]= µ∆t (6)

var

(∆S

S

)= σ2∆t (7)

Consequently, if the current value of the stock is S,the expected variation of it in the time interval ∆t isµS∆t. Therefore, µ is the expected return per unittime on the stock, expressed in a decimal form. It canalso be noted that σ2 is the variance rate of the rel-ative change in the stock price, whereby σ is usuallycalled the volatility of the stock price. The volatil-ity, σ, “scales” uncertainty in future prices. Moreover,the bigger the time step considered is, the bigger thevariance of the relative change in stock prices will be.This mathematical property reflects the fact that un-certainty increases with a receding time horizon.

The Wiener model involves random variables, con-sequently a common method consists in running aMonte-Carlo simulation over the price of the stock(here the demand, Nuser(t) replaces S). Figure 6shows an example of such a demand simulation. Thestarting demand is 50,000 subscribers (similar to Irid-ium in 1999). In the first two year the demand remainsflat. Two sharp increases in demand in years 3 and10 could potentially trigger deployment of additionalstages.

� � � � � ���� �

��� �

��� �

�

� � �

� � �

� � � � ���

�� ����� ��� � � � �

� ����� !"#�$%

&'� �(� )�*�+,� - .�)� � )'/0- 1 - )'/0-2*2� 3/0- )21 � 45� � 3 -76� �(8�3 � 1 - )

Fig. 6 Wiener stochastic demand model withS(0) = Dinitial = 50, 000, µ = 0.08, σ = 0.4 (per an-num) and ∆t = 1 month. System Lifetime, Tsys is15 years.

Using Monte Carlo simulation, there is an infinitenumber of potential future demand scenarios to con-sider. When the time intervals considered are bigenough, however, a binomial model can be used asa time discrete representation of the stock price. Thebinomial model simplifies the Wiener model by stat-ing that the stock price S can only move up or down

8 of 14

American Institute of Aeronautics and Astronautics

AIAA-2003-6317

during an interval of time leading to a new price Su orSd. There is a probability p to move up and a prob-ability 1 − p to move down. To be consistent withthe Wiener model, this representation needs to pro-vide the same expected return and variance when ∆tapproaches zero. Hull21 demonstrates that it can beachieved by setting p, u and d in the following manner:

u = eσ√

∆t (8)

d =1u

(9)

p =eµ∆t − d

u− d(10)

When used over many periods, the binomial modelprovides a tree for the price of the stock. The bino-mial tree can also be used to represent the potentialevolutions of the level of demand over time. To do so,the lifetime of the system needs to be divided into acertain number of time intervals, µ and σ need to bedefined and an initial value for demand Dinitial has tobe chosen. An example is given in Figure 7.

� � � � � � � �� � �

� � �

� �

� �

� � �

�� ����� ��� � � � �

� ����� !"# $ %& $'()& �($*

+, -�. �� � /�0 � � �,1 . ��23� ��� -�4�56.747� / / -�8

9;:9�< = � > 9@?

9@A = � > 9@? B9�B = � > 9@? A9@= � > 9@? <= � > 9@? :

99

= � > 9@?

99

= � > 9@?

Fig. 7 Example of one scenario out of 25 = 32 inthe binomial tree (n = 5) for a 15 year lifetime with3 year intervals.

In a binomial tree, a particular series of up and downmovements will be called a scenario. An example of ascenario has been represented in Figure 7. The set ofall the possible scenarios will be noted as D. If thereare n periods, a scenario will be a series of n up anddown movements of demand. Consequently, there are2n possible scenarios. Since the up and down move-ments are independent events in terms of probability,the probability of a scenario will be:

P (scenario) = pk(1− p)n−k (11)

where p is the probability of going up (given by Equa-tion (10) ) and k the number of up movements in thescenario. To model uncertainty it is thus sufficient toknow the set of all the possible scenarios D and theirassociated probabilities.

Life Cycle Costs of Flexible Architectures

For a flexible architecture, the actual life cycle costwill depend on the evolution of demand and the result-ing additional deployments. Different life cycle costswill therefore be obtained for each demand scenario.To compare a path of architectures with a traditionalarchitecture, only one life cycle cost should be con-sidered. To solve this issue, an average life cyclecost is defined for each feasible path of architecturesbased on the probabilities of the different scenarios; ifLCC

(si

pathj

)is the life cycle cost of pathj for scenario

si then, the expected life cycle cost of this path is:

E[LCC

(pathj

)]=

∑n

i=1P (si)LCC

(si

pathj

)(12)

Since an average value is considered, the results willhave to be interpreted with caution. In particular,the fact that the average life cycle cost of a path issmaller than the life cycle cost of the optimal tradi-tional design, xtrad does not imply that it is true forall possible demand scenarios. However, this frame-work always considers a worst-case situation for stageddeployment since it is assumed that a new stage is de-ployed every time demand exceeds the capacity of thesystem. In reality, decision makers take into accountother parameters than the level of demand and an in-crease in capacity will be decided only if it is judgedprofitable. Therefore, even though the life cycle costscan get higher than the traditional life cycle cost forcertain demand scenarios, one has to keep in mindthat in reality, the decision of deploy a next stage de-pends not only on the demand level at decision time.Moreover, if a deployment is decided, this implies thatdemand exceeded the capacity of the system and thatthere is a significant number of potential customers.Even though the deployment of a new stage implies acost, the fact that the level of demand is large enoughto warrant it, ensures that revenues will be significanttoo.

It is essential to understand how the life cycle costsof a path for a particular scenario of demand arecomputed. For a flexible system, three types of ex-penditures can be identified:

• Initial development costs (IDC): This corre-sponds to the price of deploying the first constel-lation in the path, A1. Of course, these costs donot include the price of the real options consid-ered since these have been neglected up to thispoint.

• Operations and maintenance costs (OM)These costs capture the operational costs of adeployed constellation, including orbital mainte-nance, servicing of ground stations as well as re-plenishment of failed satellites.

9 of 14

American Institute of Aeronautics and Astronautics

AIAA-2003-6317

• Evolution costs (∆C): These correspond to thenecessary investments to deploy the next stage ofthe path. For instance, in the case of LEO constel-lations, the deployment of a new stage will implythe manufacture and launch of new satellites. Thecosts associated with this evolution will thus betaken into account in ∆C.

Once IDC, OM and ∆C are known for a path, thelife cycle costs can be computed for a given scenario.These expenditures are spread over time accordingto certain principles and discounted to obtain theirpresent value, see Equation (2). In year one, theexpenditures are IDC and OM. They correspond tothe initial deployment of the system and the begin-ning of operations. Then, if no deployment decision ismade, the additional costs are equal to OM for everysubsequent year. When demand exceeds the currentcapacity of the system, a new stage is deployed. Theadditional costs are then equal to the evolution costs∆C between the “old” and “new” architectures as wellas the OM costs for that year. When the capacity isincreased, OM generally has to be increased as wellbecause the system gets larger and requires more main-tenance. Consequently, from the knowledge of IDC,OM and ∆C, the life cycle costs of a path, given aparticular demand scenario, can be computed.

Comparison of the Traditional and the Flexibleapproach

The average life cycle costs of the paths that satisfythe requirements are computed. The path that pro-vides the minimum average life cycle cost is identified.This life cycle cost is noted LCC? and the optimalpath is called path?. From there, LCC(xtrad) andLCC? are compared. The difference between thosetwo values reveals the magnitude of the economic op-portunity associated with staged deployment.

The different steps of the flexibility valuation frame-work are summarized in Figure 8. This frameworkhas been applied to the particular context of reconfig-urable constellations of communications satellites inLEO. The results obtained with this framework arepresented in the next section.

CASE STUDY RESULTSPresentation of the case

The framework has been applied to the particularcase of LEO constellations of communications satel-lites. It is assumed that real options are initiallyembedded in the design that allow constellations tobe reconfigured after their initial deployment. Thissection presents a particular case study in which thesize of the market considered is close to the one Irid-ium originally expected. However, the average life

��� � � ����� � � � � � � �

� ��� ��� � � ���� � � ��� ��� � ���

� � ��� � � ���� �� ���� � � � � � !"�

��� � � � �#� ���$ � � �

%&� ��� �#� ' �( � � ��� � � � � )�� ��� � ���! * � ��� � � � � � � � � � !"� � �

+ !"� � � �( ���,� � ���,- � !"��!"�#� �(. ����!"� � )���� � �

/�0 12 0 3

/�0 1�2 0 3/�0 1�254 6

/(0 1�7 3�8 9 0":�;

1�0 8 <�=

> = ?�=σµ∆8

@#A B

C /�/ED A 10 8 < DC /�/�7 3 8 9 0 : ;

F @ / A G�HIA∆/

3 A C /�/J#K <

3 A C /�/J K <

Fig. 8 Flexible architecture valuation process forstaged deployment.

cycle costs obtained will not be compared with Irid-ium (≈ 5$B) for two reasons. First, as explained byde Weck and Chang,3 LCC is difficult to determineexactly. Moreover, according to the same study, theIridium constellation is not Pareto optimal and theframework compares the staged deployment strategywith a best traditional design. Consequently, an ar-chitecture that is Pareto optimal and that can providethe same capacity as the Iridium constellation needsto be determined first. This architecture will then becompared to the relevant paths of architectures for dif-ferent values of the discount rate r. The influence ofr on the value of flexibility will then be analyzed. Ini-tially the discount rate is set to r = 0.1 (nominal case).

Determination of xtrad

The Iridium constellation was originally designedwith a ≈ 10 year lifetime. Tsys is thus set to 10years. About 3 millions subscribers were expected, soCapmax is set to 2.8 · 106 subscribers. The best tradi-tional architecture xtrad can be determined from thetrade space for these particular values as discussed inthe introduction. This architecture is xtrad = x184 =[800, 5, 600, 2.5, 1] with a capacity, Nch = 80, 713, anddiscounted lifecycle cost of LCC = 2.01 [$B] (withr=10%). Note that this constellation is shown inFigure 2 and is quite similar to Iridium, xIridium =[780, 8.2, 400, 1.5, 1]. This architecture has a “market”capacity of Cap(xtrad) = 2.82 · 106 subscribers. Thisparticular architecture will be compared to the stageddeployment strategy. Hence, demand scenarios needto be generated.

10 of 14

American Institute of Aeronautics and Astronautics

AIAA-2003-6317

Binomial Tree Demand Model

To generate the binomial tree, Dinitial, µ, σ and ∆tneed to be defined. The time step ∆t is set to 2 years.Consequently, decisions concerning the deployment ofthe constellation will be taken every two years. More-over, the expected increase in demand per time unitµ is assumed constant. It is set to µ = 20% per year.The volatility is set to σ = 70%. The parameter σ di-rectly affects the span of the binomial tree. For valuesof σ smaller than 70%, the maximum demand that canbe attained is smaller than Capmax and the probabil-ity to have a demand higher than the one targeted isequal to zero. That is why σ is set to this particularvalue. The Iridium constellation only had 50000 sub-scribers after almost one year of service.2 This valuewill be considered for Dinitial. Also, the initial archi-tectures are constrained to deliver a capacity at leastequal to the initial demand and Capmin = Dinitial.From there, the binomial tree can be generated andthe demand scenarios are obtained.

Value of Flexibility

The value of flexibility can a priori be defined as thediscounted money saved compared to the traditionalapproach that is to say the difference between the lifecycle cost of xtrad with the average life cycle cost ofthe optimal path, LCC?. This difference is shown inFigure 9.

� � � � � � � � �

� � �

��� � � � �� ��� ����� � � � �

� ��� �� !" �#�#$ �% &��' () *

+ , - . /

021 3 425

6 7 7�8

9�:92;

9=<

92>

9 �

Fig. 9 Difference between the life cycle cost of theoptimal traditional design xtrad and the average lifecycle cost of the optimal path LCC? : A1 → A2 →A3 → A4 → A5.

This difference is LCC(xtrad) − LCC(path?) =2.01 − 1.46 = .55 [$B]. This economic opportunity ofnearly $550 million represents a quarter of the lifecyclecost of the traditional architecture. The key charac-teristics of the fixed, traditional architecture and theoptimal staged deployment path are shown in Table 1.

Table 1 Comparison of traditional architecturextrad and optimal reconfiguration path, path∗

# h ε Pt DA ISL Capxtrad 184 800 5 600 2.5 1 2.8E6A1 32 1600 5 200 1.5 1 6.6E4A2 33 1200 5 200 1.5 1 1.2E5A3 38 1200 20 200 1.5 1 5.1E5A4 39 800 20 200 1.5 1 1.8E6A5 44 800 35 200 1.5 1 7.1E6

The optimal staged deployment path in terms ofsatellite constellations is shown in Figure 10. Gener-ally, the number of satellites increases with each stage.Interestingly, the optimization chooses satellites of rel-atively low capability (e.g. small transmitter power,Pt = 200 [W]) relative to other choices in the designspace. It appears to be better to launch a set of small,light weight, affordable satellites and to add more ofthem as needed, rather than deploying a constellationwith few, high-powered (e.g. Pt = 1, 800 [W]), heavysatellites. This supports the arguments of those whoclaim that “swarms” of smaller satellites provide moreflexibility than constellations with few, extremely ca-pable satellites. It is noteworthy that not every stagetransition requires an altitude change. Most reconfig-urations require plane changes, but not all of them,e.g. for A1 → A2 both constellations have four (4)planes. This information provides the basis for op-timizing the constellation reconfiguration process andfor estimating the amount of extra fuel to carry on-board the satellites.19

Influence of the Discount Rate r

The value of flexibility and the optimal path, path∗,may change for different values of the discount rate,r. To gauge the effect of the discount rate it is neces-sary to scale the value of flexibility with respect to thelife cycle cost of the traditional design. Consequently,the value of flexibility will be computed as the per-centage of money saved with respect to the traditionalapproach:

V alue =LCC(xtrad)− LCC(path?)

LCC(xtrad)(13)

To study the influence of the discount rate on theeconomic opportunity of staged deployment, an op-timization is run over the paths of architectures forvalues of r ranging from 0% to 100% with a step of5%. For each value of the discount rate, the optimalpath is obtained as well as the value of flexibility as-sociated to it. The results obtained are presented inFigure 11.

It can be seen that the value of flexibility increaseswith the discount rate. The reason is that the higher

11 of 14

American Institute of Aeronautics and Astronautics

AIAA-2003-6317

�������� � � � � � ���� � �� �� � �������������� ��������� � � � � � ���� � �� �� ���������������� ����� �� � � � � � ��� � �� �� ����������� ������ ��� � � �� � � � � �!���� � �� �� ��������� ������ �

������ �� � � � � �� ���� � �� �� ��������� ������ �

" #$% &'( )$ '*+, - +#( ./&+0$1'$243#'$25

Fig. 10 Optimal staged deployment path, path∗,for a discount rate of r = 10 %.

� � � ��� ��� ��� � � � � �� � ��� � ������

���

���

���

���

���

� �

�� � � � ��������� � ����� � �

! "# $%&' (# % )*+*#* , -./0

Fig. 11 Value of flexibility in % of money savedwith respect to r.

r is, the less expensive the deployment of additionalstages appears in terms of net present value and themore valuable it is. This is the first mechanism thatjustifies the value of flexibility.

Surprisingly, for a discount rate equal to zero, thestaged deployment strategy still presents an economicvalue. The reason is that average life cycle costs areconsidered. Consequently, for certain demand scenar-

ios, a reconfiguration may not be necessary and the lifecycle costs corresponding to the initial architecture,A1, are typically smaller than the life cycle cost of thetraditional architecture, xtrad. However, even thoughthe average life cycle cost considered are smaller thanLCC(xtrad), the actual life cycle costs during the lifeof the system may be higher for certain demand scenar-ios. This does not imply that flexibility has no valuein this case. Indeed, the framework considers a worstcase scenario for staged deployment that is to say thatadaptation to demand is done whenever possible. Inreality, the decision of increasing the capacity dependson other factors, in particular the availability of moneyto achieve the evolution. Consequently, even thoughthe staged deployment solution could ultimately re-veal to be more expensive for a discount rate of 0%and a significant increase in demand, it should be keptin mind that the decision to deploy the next architec-ture belongs to the managers and is not an automaticprocess.

Also, the value of flexibility can be over 30% whichis a significant value. Moreover, this is an averagevalue which means that for situations where demanddoes not grow, the economic risk is lowered at least by30%. This article does not claim that Iridium couldhave avoided bankruptcy by applying staged deploy-ment, since low market demand was a consequenceof competing terrestrial networks - a fact that wouldhave been unaltered by staged deployment. Rather,the claim is that the economic risk could have beenreduced by an amount close to 30% (roughly $B 1.8out of the total loss of $B 5.5) with staged deploymentand orbital reconfiguration.

For high discount rates, the curve flattens out. Eventhough the value of flexibility increases with the dis-count rate, it cannot go over a certain limit. Indeed,since the architectures considered are constrained toprovide an initial capacity at least equal to Capmin =Dinitial, the life cycle costs of the paths will alwaysbe greater or equal to the life cycle cost of the Paretooptimal architecture that provides a capacity greaterthan Dinitial. Consequently, there is an asymptoticvalue for flexibility.

CONCLUSIONSValue of Staged Deployment

This paper demonstrates the economic value ofstaged deployment for LEO constellations of commu-nications satellites. In particular, a case study re-vealed how this strategy could lower the life cycle costsof Iridium-like systems by more than 20%. This isachieved by spreading the cost of adding more capacityover time and by giving system managers the flexibil-ity to adapt system capacity to the unfolding market

12 of 14

American Institute of Aeronautics and Astronautics

AIAA-2003-6317

demand. This approach asks designers to think dif-ferently about the trade space. Indeed, it proposes toseek “paths of architectures” in the trade space ratherthan Pareto optimal architectures. Moreover, it takesinto account technical data and a probabilistic rep-resentation of demand through time. Consequently,the staged deployment strategy represents a real chal-lenge for designers. It does not ask them to design afixed system from a specific set of requirements, a wellaccepted practice, but to design a flexible system thatcan adapt to highly uncertain market conditions. Thisflexibility needs to be embedded before the deploymentof the system. This implies that a real options think-ing is adopted. Real options are not necessarily usedafter the deployment of the system. Designing ele-ments into a system that may not be used conflictswith established practices in engineering. In conclu-sion, designers will need to understand the value ofdesigning a system with real options and decision mak-ers should seek to quantify the value of investing insuch flexibility.

The principles of the approach presented in this pa-per go beyond satellite constellations. The generalframework can be applied to systems with similar char-acteristics. Future studies could focus on the valueof staged deployment for different systems facing ahigh uncertainty in future demand with importantnon-recurring costs. If economic opportunities arerevealed, such studies could motivate the search forinnovative, flexibility-enabling technical solutions.

Future Work: Orbital Reconfiguration

Orbital reconfiguration has revealed itself as valu-able for constellations of satellites. To determine iforbital reconfigurations, such as the ones required bythe path shown in Figure 10, are feasible with onboardpropellant or other means, the flexibility will have tobe priced. Optimization of satellite constellation re-configuration is therefore becoming an important, ifpoorly explored, research topic.19 Other issues willhave to be studied. Indeed, if the altitude of the satel-lites is changed, the hardware of the satellites requiresmodifications. To produce a particular beam patternon the ground, the characteristics of the antenna varywith the altitude of the satellites. Reconfigurationwithin the satellites themselves will thus have to beconsidered in more detail. Actually, significant inter-est now exists for intra-satellite flexibility (within asingle spacecraft) and this topic may reveal more chal-lenging technically. This article, on the other hand,focused on inter-satellite flexibility.

Other Opportunities for Satellite Constellations

The flexibility that was studied concerned a possi-ble increase of the capacity of a constellation. It would

be interesting to study the value of having the flexi-bility to change the functionality of the constellations,i.e. the type of service offered (voice, data, internetconnectivity/IP, paging, multimedia, Earth observa-tion...) and to develop a similar framework for thispurpose. Indeed, the Iridium constellation was de-signed primarily for mobile telephone communicationsat a data rate of 4.8Kbps per duplex channel. If ithad possessed the flexibility to change its per-channelbandwidth or modulation , it might have provided adifferent type of service and attracted new revenuestreams.

If orbital reconfiguration appears too expensive dueto excessive ∆V (fuel) for plane and altitude changes,another type of constellations could be considered toachieve staged deployment. For instance, hybrid con-stellations that consist of multiple layers of satellites atdifferent altitudes could be envisioned. Those constel-lations could be deployed in a staged manner, one layerat a time. Moreover, elliptical layers or those with res-onant orbits could be deployed to increase the capacityonly for certain parts of the globe, thus adapting to thevariations in the geographic distribution (latitude andlongitude) of demand.

ACKNOWLEDGEMENTSThis research was supported by the Alfred P. Sloan

Foundation under grant number 2000-10-20. Thegrant is administered by Prof. Richard de Neufvilleand Dr. Joel Cutcher-Gershenfeld of the MIT Engi-neering Systems Division with Mrs. Ann Tremellingserving as fiscal officer. Dr. Gail Pesyna from theSloan Foundation is serving as the technical monitor.Mr. Darren Chang was helpful in understanding theLEO constellation simulator used in this study.

References1W. J. Ciesluk, L. M. Gaffney, N.D. Hulkover, L. Klein, P.

A. Olivier, M. S. Pavloff, R. A. Pomponi, and W. A. Welch.An evaluation of selected mobile satellite communications sys-tems and their environment. MITRE Corporation, ESA contract92BOOOOO60, April 1992.

2E. Lutz, M. Werner, and A. Jahn. Satellite Systems for Per-sonal and Broadband Communications. Springer, Berlin, Ger-many, 2000.

3Olivier L. de Weck and Darren D. Chang. ArchitectureTrade Methodology for LEO Personal Communication Systems.In Proceedings of the 20th AIAA International CommunicationsSatellite Systems Conference, Montreal, Quebec, May 12-152002. AIAA-2002-1866.

4C.E. Fossa. An overview of the Iridium low earth orbit(LEO) satellite system. In Proceedings of IEEE 1998 NationalAerospace and Electronics Conference 1998; (A99-17228 03-01)pp.152-159.

5Cary C. Gumbert. Assessing the Future Growth Potentialof Mobile Satellite Systems Using a Cost per Billable MinuteMetric. Master’s Thesis, MIT, Department of Aeronautics andAstronautics, 1996.

13 of 14

American Institute of Aeronautics and Astronautics

AIAA-2003-6317

6Michael D. Violet. The Development and Application of aCost per Minute Metric for the Evaluation of Mobile SatelliteSystems in a Limited-Growth Voice Communications Market.Master’s Thesis, MIT, Department of Aeronautics and Astro-nautics, 1995.

7C. C. Gumbert, M. D. Violet, and D. E. Hastings. Cost perBillable Minute Metric for Comparing Satellite Systems. Journalof Spacecraft and Rockets, 34(6), November-December 1997.

8Graeme B. Shaw. The Generalized Information NetworkAnalysis Methodology for Distributed Satellite Systems. PhDthesis, MIT, Department of Aeronautics and Astronautics, 1999.

9Cyrus Jilla. A Multiobjective, Multidisciplinary Design Op-timization for the Conceptual Design of Distributed SatelliteSystems. PhD thesis, MIT, Department of Aeronautics and As-tronautics, May 2002.

10Tatsuki Kashitani. Development and Applications of anAnalysis Methodology for Satellite Broadband Network Archi-tectures. In Proceedings of the 20th AIAA International Com-munications Satellite Systems Conference, Montreal, Quebec,May 12-15 2002. AIAA-2002-2019.

11Joseph H. Saleh. Weaving Time into System Architecture:New Perspectives on Flexibility, Spacecraft Design Lifetime,and On-orbit Servicing. PhD thesis, MIT, Department of Aero-nautics and Astronautics, 1999.

12Elisabeth S. Lamassoure. A Framework to Account forFlexibility in Modeling the Value of On-orbit Servicing for SpaceSystems. Master’s thesis, MIT, Department of Aeronautics andAstronautics, May 2001.

13David W. Miller, Raymond J. Sedwick, and Kate Hartman.Evolutionary Growth of Mission Capability Using DistributedSatellite Sparse Apertures: Application to NASA’s Soil Mois-ture MISSION (EX-4). Internal Memorandum of the Space Sys-tems Laboratory, MIT, 2001.

14Jeremy Singer. Space based tracking radar will have hur-dles. Space News, April 2003.

15Natalia Ramirez. Valuing Flexibility in Infrastructure De-velopments: the Bogota Water Supply Extension Plan. Master’sthesis, MIT, Technology and Policy Program, May 2002.

16H. Takeuchi, M. Sugimoto, H. Nakamura, T. Yutani, M.Ida, S. Jitsukawa, T. Kondo, S. Matsuda, H. Matsui, T. E.Shannon, R. A. Jameson, F. W. Wiffen, J. Rathke, C. Piaszczyk,S. Zinkle, A. Moslang, K. Ehrlich, F. Cozzani, H. Klein, J-M.Lagniel, R. Ferdinand, E. Daum, M. Martone, I. S. Ciattaglia,and V. Chernov. Staged Deployment of the International Fu-sion Materials Irradiation Facility (IFMIF). In Proceedings ofthe 18th International Atomic Energy Agency Fusion EnergyConference, Sorrento, Italy, October 4-10 2000. IAEA-CN-77-FTP2/03.

17Ralph E. Steuer. Multiple Criteria Optimization: Theory,Computation, and Application. John Wiley & Sons, New York,1986.

18W.S. Adams and T. J. Lang. A Comparison of Satel-lite Constellations for Continuous Global Coverage. In MissionDesign and Implementation of Satellite Constellations, No.1,Space Technology Proceedings, pp. 51-62, ESA/ESOC, KluwerPublishers, Darmstadt, Germany, October 1998

19Uriel Scialom. Optimization of Satellite Constellation Re-configuration. S.M. Thesis, Massachusetts Institute of Technol-ogy, August 2003

20Mathieu Chaize. Enhancing the Economics of Satellite Con-stellations via Staged Deployment and Orbital Reconfiguration.S.M. Thesis, Massachusetts Institute of Technology, June 2003

21John Hull. Options, Futures and Other Derivatives Secu-rities. Prenctice Hall, Englewood Cliffs, NJ, 2nd edition, 1989.

14 of 14

American Institute of Aeronautics and Astronautics