Patent ID: 12202627

DETAILED DESCRIPTION

The following detailed description of certain embodiments presents various descriptions of specific embodiments of the invention. However, the invention can be embodied in a multitude of different ways as defined and covered by the claims. In this description, reference is made to the drawings where like reference numerals may indicate identical or functionally similar elements.

Unless defined otherwise, all terms used herein have the same meaning as are commonly understood by one of skill in the art to which this invention belongs. All patents, patent applications and publications referred to throughout the disclosure herein are incorporated by reference in their entirety. In the event that there is a plurality of definitions for a term herein, those in this section prevail. When the terms “one”, “a” or “an” are used in the disclosure, they mean “at least one” or “one or more”, unless otherwise indicated.

Definitions

“Small satellites” or “smallsats” can refer to satellites of low mass and size, usually under 500 kilogram (kg) of mass.

“Impulse” can refer to the integral of a force over the time interval for which the force acts.

“Delta-V” parameter can measure the impulse per unit of spacecraft mass that is needed to perform a maneuver such as launch from, or land on a planet or moon, or perform an in-space orbital maneuver.

“Specific impulse” or “ISP” can refer to a measure of how efficiently a rocket or satellite uses its propellant. ISP can be calculated in variety of ways, resulting in expressions of ISP with different units. In one respect, ISP can refer to how much energy is generated by a spacecraft per pound of fuel. ISP can range from approximately 200 seconds for simple chemical engines to approximately 450 seconds for cryogenic ones and up to approximately 1500 seconds for electric engines.

“Inert mass” of a spacecraft can refer to the total mass of the spacecraft minus the mass of propellant and the mass of payload.

The problems with existing space transportation systems, as identified above, can be addressed by a distributed space transportation network, where satellites of any size can be launched to a convenient location (e.g., to LEO). From there, a network of space tugs and depots can transport satellites to their final destination. The network's space tugs and depots can be refueled and kept stocked with resources, such as replenishment fuel, spare parts, and robotic capabilities to refuel space tugs and perform maintenance, repairs and refueling, without the need for launching these supplies and services from the earth for every mission.

In order for a distributed space transportation network to ensure that the in-space actors are well-coordinated and well-managed, the network will necessarily involve both a hardware layer and software layer (or application layer). The hardware layer comprises physical elements of the network, including, e.g., in-orbit space tugs, propellant depots, and satellites, as well as earth-based launch vehicles and ground stations. The software layer serves as the manager and operator of the network. It serves as a portal for in-space service requests received from satellites or other entities. Further, it positions, generates paths for, and schedules hardware elements to meet network requests, while minimizing certain objective functions. For example, a customer (e.g., a person or entity interested in deploying a satellite for a mission) interacts with the distributed space network, aiming to transfer a payload from one point to another. This request is added to a set of requests which the network must deal with. The software layer positions the objects in space, generates paths for them, and schedules the hardware elements to meet the network requests and to fulfill the objective functions. This optimization and coordination at the application layer leads to lowered cost, lowered response time, fuel efficiency, and more. These aspects will be described in further detail below.

Example Mission

FIG.1illustrates an example mission accomplished using the disclosed distributed space transportation network. Space tugs10can be optimally placed in space in relation to where they are anticipated or planned to rendezvous and dock with a customer satellite12. The customer satellite12can be a single satellite of any size or a cluster of satellites. The customer satellite12arrives at a convenient location (e.g., a LEO) by any launch method, for example using any of the methods described above. The space tug10can rendezvous and dock with the customer satellite12and propel the customer satellite12to its final destination orbit (e.g., a geostationary orbit). Once the customer satellite12, arrives at its destination orbit, the space tug10can return to a parking orbit or rendezvous with a depot satellite14in order to refuel or acquire repair or maintenance services.

The space tugs10, customer satellites12and depot satellites14can be considered nodes in the space distribution network, where each node can include inherent and current specification, such as max load capacity, max fuel capacity, rendezvous adaptors and interfaces, type of propulsion and various parameters related to response time of a node. The nodes' specifications along with other parameters can be used to generate and execute a mission profile, where one or more space tugs10and satellite depots14can meet, dock and subsequently deliver a customer satellite12to its final destination.

Methods

FIG.2illustrates a method20of operation of a distributed space transportation network according to an embodiment. A network of space tugs10and satellite depots14are optimally positioned in space, for example, in parking orbits, and await the arrival of customer satellites12. Space tugs10can have chemical or electrical propulsion capabilities and be able to rendezvous and dock with a customer satellite12. Customer satellite12can refer to a satellite or a cluster of satellites that may be destined for a single final destination orbit, or may be destined for various different final destinations. The customer satellite12can arrive at its initial space location via any launch method and request a transfer to a final destination orbit. In other embodiments, the receipt of transfer request from a satellite12and/or optimal placement of the space tugs10and satellite depots14can occur before arrival of a customer satellite to its initial space destination. In other words, a space transportation network and its nodes can be optimally configured based on expected arrival of its customer satellites12and their respective final destinations. In another embodiment, the space transportation network and its nodes can be optimally configured after receipt of a set of orbit transfer requests from a customer satellite12. A set of space tugs10are optimally selected from a pool of space tugs. The selection is optimized for parameters, such as fuel consumption, time of flight or other metrics, as may be requested from a customer satellite12. As an example, a customer satellite may need priority delivery to a destination orbit, in which case space tugs10with chemical propulsion capability may be assigned to that customer satellite12(chemical propulsion space transportation can deliver in shorter time, albeit at substantially more cost, compared to electrical propulsion techniques).

Along with selection of space tugs10, a mission profile can be generated, which can include the orbital maneuvers for selected space tugs10to meet and dock with the customer satellite12and transport it to its final destination. The mission profile can also include other items, such as hand-off of customer satellite12between two or more space tugs10, and potential rendezvous with depot satellites14. After the mission profile is generated, the selected space tugs10and depot satellites14execute the mission profile, by for example, performing the orbital maneuvers therein, meeting the customer satellite12, attaching to it and delivering it to its final destination. In some embodiments, the mission profile also optionally includes payload hosting, where space tugs10can provide power, communication systems and/or other services and resources to the customer satellite12for a period of time or for the docking duration.

Software and Hardware Layers

FIG.3illustrates a distributed space transportation network (DSTN)30and its components according to an embodiment. In one respect, the DSTN30includes a software layer32and a hardware layer40. The software layer32can manage the DSTN30and its operations. In one embodiment, the software layer32can include a physics layer34, a maneuver layer36and an assignment layer38.

The physics layer34functions to model and predict future behavior of the hardware elements in space. In various embodiments, the behavior may include trajectories, communications, available power, and/or any other suitable future behavior to be predicted. In some embodiments, the physics layer functions to estimate a trajectory of a spacecraft in time and output the spacecraft's physical parameters, such as position and velocity at a particular time in the future. In some embodiments, the physics layer functions to predict what will happen to a spacecraft in orbit. This is necessary because all objects and nodes (e.g., satellites, space tugs, depots, and final destinations) are moving in relation to one another in terms of relative position, and there are costs associated with moving between these different points which must be calculated. Therefore, the physics layer is necessary to predict the future behavior of hardware elements. In some embodiments, the physics layer can predict, e.g., trajectories of the hardware elements, communications between hardware elements, available power, and more. In some embodiments, identifying the location of spacecraft in particular is important. In some embodiments, the physics layer functions to identify whether a given spacecraft has battery power, can be communicated with, has the autonomy to complete a given task, and/or any other suitable information. The physics layer does not merely employ a selection algorithm; rather, it functions to properly and accurately model the behavior of objects in space.

The maneuver layer36functions to compute paths between points in space. In some embodiments, the maneuver layer outputs a set of maneuvers which a spacecraft can utilize to travel from a departure position to a destination position in space. In some embodiments, this includes, e.g., determining not just how the orbit is going to change over time, but also how to move a spacecraft from one orbit to another orbit. In some embodiments, the maneuver layer takes cost of movements into account.

The assignment layer38functions to optimally choose space assets in the hardware layer40to transport a customer satellite12from its initial arrival point in space to its final destination in space. This enables the optimization of routing of multiple orbit transfer requests and objective functions. For example, if there are multiple existing transfer requests involving multiple orbits, the assignment layer may operate to optimize the requests based on, e.g., total cost of network, minimizing fuel cost, total space time, total resources spent in a certain timeframe, minimizing the amount of fuel spent over a period of time (e.g., 6 months), and/or any other suitable optimization parameters. In some embodiments, the assignment layer takes into account different hardware elements in different orbits for a given point in time, identifies destinations, identifies assets, performs the assignment of each different asset to each different customer, and generates mission profile(s) which can then be executed on hardware elements.

The hardware layer40can include the space tugs10, the satellite depots14and other spacecraft which may be launched from the earth for various purposes, such as refueling and restocking the satellite depots14.

FIG.4illustrates an example operation of the physics layer34. In some embodiments, the physics layer34is used to propagate the trajectory of spacecraft over time. In one embodiment, the physics layer34receives input data, i.e., received data that can be used to estimate the trajectory of a spacecraft. The input data can include, e.g., the spacecraft's current state, including its position and velocity. The input data can come from the spacecraft and its communication facilities, or by observation from earth or another spacecraft, or by other means.

Next, the physics layer34can receive a propagation time parameter, indicating how far in time the spacecraft's trajectory should be estimated. For example, the spacecraft's trajectory may need to be estimated one or two months in advance.

Next, the physics layer34executes a propagation algorithm that, given input data and propagation time, estimates the spacecraft's future trajectory, taking into account phenomena, such as, e.g., gravity effects (from the earth and/or other celestial bodies), solar radiation effects, solar wind effects, atmospheric effects (e.g., drag and lift) and other factors that might affect a spacecraft's trajectory. Next, the physics layer34outputs the propagated trajectory and flight parameters of the spacecraft. In one embodiment, this includes an estimation of position and velocity and other flight parameters of the spacecraft at a future time (e.g., at the propagation time). In other embodiments, the physics layer34can output an algorithm, that in turn, can output flight parameters of a spacecraft at any time in the future (with an upper bound, such as propagation time).

The physics layer34can be used to propagate the trajectory of any spacecraft in the DSTN30. For example, the physics layer34can propagate the trajectory of customer satellites12, space tugs10and satellite depots14. The propagated trajectories can be used for rendezvous and docking purposes and to arrange for different nodes in the DSTN30to meet in space. In one embodiment, the physics layer34can be executed by other components of software layer32, in order to obtain parameters for their operations.

FIG.5illustrates an example operation of the maneuver layer36. The maneuver layer functions to compute paths in space. In some embodiments, the maneuver layer36can be used to determine potential paths between nodes in space, or paths between positions in space and to determine which paths are optimal given the operational parameters of the DSTN30and/or the customer satellites12. The maneuver layer36can also determine and output various parameters associated with the paths, such as transfer time and delta-V. In one embodiment, the maneuver layer36can determine optimal paths between nodes of the DSTN30. For example, from a space tug10to another space tug10, or from a space tug10to a satellite depot14, or more commonly, from a space tug10to a customer satellite12. Additionally, the maneuver layer can determine paths from a node in the DSTN30, to and from a position in space. For example, the maneuver layer36, can determine an optimal path from a rendezvous position of a space tug10and customer satellite12to a final destination of the customer satellite12.

The maneuver layer36receives input data including data on a node of interest of the DSTN30. For example, the maneuver layer36can obtain data on a current state of a space tug10, including its position, velocity, propulsion capabilities and other specifications, such as data on thrusters, boosters, re-ignitable stages, power to weight ratio, or other efficiency measures. In one embodiment, the maneuver layer36can also receive data on customer satellites12, such as desired cost to final orbit, within which an operator of the customer satellite12may like to request a transport. For some satellite operators, the time is of essence, and they would like their satellites delivered to their destinations as soon as possible. For these customer satellites12, the maneuver layer36can determine paths that optimize for fastest delivery and response time (RT). Other operators might want a transport within certain cost parameters. The maneuver layer36can determine a set of orbital maneuvers to rendezvous a space tug10to a customer satellite12and deliver it to its final destination, and output the optimum or near-optimum set of orbital maneuvers based on the operator's desired cost parameters.

After receiving input data, the maneuver layer36can recall and execute the physics layer34to determine a rendezvous position. For example, if a space tug10is to rendezvous with a customer satellite12, attach to it and transport it to its destination, the maneuver layer36can execute the physics layer34to determine the estimated position, velocity and other flight parameters of the customer satellite12. Next, the maneuver layer36can generate a set of orbital maneuvers that if executed can rendezvous the space tug10and the customer satellite12. Next, the maneuver layer36can use one or more desired parameters to choose an optimum or near-optimum set of orbital maneuvers that can rendezvous the space tug10and the customer satellite12. Desired parameters can be any parameters of interest to the operator of the DSTN30or the operator of the customer satellite12. In one embodiment, the optimization parameter of interest can be cost to final orbit, which can take into account, various costs that may be associated with transporting a customer satellite12to its final destination. These costs can include cost of fuel to the operator of the DSTN30, a marginal cost of repairs, depreciation, and/or other cost parameters. In another embodiment, the optimization parameter of interest for maneuver layer36can be time to destination parameter. In another embodiment, the optimization parameter can be a parameter combining both cost and time to destination parameters.

In some embodiments, the maneuver layer incorporates one or more penalty layers, which add a factor that takes into account how much cost the object (e.g., satellite) will be generating over time. This can determine, for example, how quick the maneuvers will be that allow the overall cost to be the lowest possible within the scenario.

FIG.6illustrates an example method44, which the maneuver layer36can use between steps37and39to generate an optimum or near-optimum set of orbital maneuvers given one or more optimization parameters. For ease of description, we assume the method44is applied to determine an optimum set of maneuvers to move a space tug10to a customer satellite12, however, the described methods can be used to determine optimum or near-optimum set of orbital maneuvers for any two nodes within the DSTN30and/or between a node in the DSTN30and a position in space. For example, the described methods of the maneuver layer36can be used to determine optimum or near-optimum orbital maneuvers to transport a docked space tug10and customer satellite12from LEO to the final destination of the customer satellite12in geosynchronous equatorial orbit (GEO).

At step37, a set of orbital maneuvers is generated. The orbital maneuvers can include impulsive, or continuous maneuvers and can depend on the specifications of the underlying DSTN30nodes. For example, some maneuvers may include chemical propulsion, while others include electrical propulsion maneuvers or a combination of the two. The set of orbital maneuvers generated at step37can be used to construct an array of orbital maneuvers (AOM). In the example of space tug10to customer satellite12, the AOM includes sets of maneuvers to be applied to the space tug10to rendezvous with the customer satellite12.

Next, an objective function for each set of maneuvers in the AOM can generate a delta parameter (DP) indicating the difference between an objective target orbit and delivered final orbit. The DP values can be added to the AOM. The objective function can be for example a cost function based on actual cost and/or time to destination parameter. Next, an optimization algorithm produces a new AOM based on previous values of AOM and its DP values until one or more objective parameters, such as cost or time to destination are met. If the objective parameters are not met, the method44repeats the previous steps from step37, until the objective parameters are met. At step39, a set of optimal or near-optimal orbital maneuvers are generated. In one embodiment, the near optimal orbital maneuvers are the pareto-dominant values for total transfer time and delta-V.

FIG.7illustrates an example operation of the assignment layer38. The assignment layer functions to enable routing optimization for multiple orbit transfer requests and objective functions. For example, it may not be that just one object may need to move from one particular orbit to another particular orbit, but instead that there are multiple transfer requests involving multiple satellites, which may involve multiple space tugs. The assignment layer optimizes these components to meet different objective functions, e.g., optimizing for the total cost of the entire network, minimizing the total fuel cost that is spent, minimizing the total time, minimizing the total amount of resources that are expended within a certain timeframe, using the least amount of fuel over a given timeframe (e.g., the next 6 months), optimizing for lowering the total time, and/or any other suitable objective function related to routing of these different elements. In some embodiments, at a general level, the assignment layer functions to identify all of the relevant assets present within a received configuration, and perform the assignment of each different asset to each different customer, generate a mission profile, and then send those mission profiles to the hardware elements where they are executed. In some embodiments, the assignment layer determines the cost for the life cycle of the mission from each node to the final destination. This can include, e.g., the cost from one particular space tug or satellite, to its destination, to its depot, etc. In some embodiments, the assignment layer utilizes a selection algorithm to output assignments and mission profiles and execute them, such as, e.g., a traveling salesman problem algorithm, auction algorithm, or any other suitable selection algorithm.

In some embodiments, the assignment layer38is used to select one or more space tugs10and generate a mission profile for rendezvousing with a customer satellite12and transporting it to a desired destination. In one embodiment, the assignment layer38receives the initial configuration data of the DSTN30. The configuration data can include, the available space tugs, depot satellites and their respective current status data (such as position and velocity). The configuration data can also include hardware layer40data, such as initial dry mass, ISP, fuel state and other specifications of the components of the hardware layer40. The specification data of the hardware components40can include, power to weight ratio and efficiency data, capabilities and compatibility data (e.g., data on the type of docking adaptors and interfaces, data on ability to provide payload hosting).

In one embodiment, the assignment layer38can also receive data on available or upcoming launches from the earth, from which it can offer an optimal launch and space transportation itinerary to a customer satellite12. Such data can include, launch schedule (launch date), timing and target orbit data, expected orbit, cost data, capacity data, payload compatibility data and other data that can be used to estimate the in-space behavior and/or performance of a launch vehicle in relation to a customer satellite12.

Next, the assignment layer38can receive a set of orbital transfer requests (OTRs). The OTRs can be from the customer satellite12or from the output of the maneuver layer36. The OTRs can include a departure position in space (such as the initial launch position of a customer satellite12and a destination position in space (such as the final desired destination of a customer satellite12). Additionally, the assignment layer38can receive secondary data, such as requested time to destination for a customer satellite12, and potential value loss per unit of time. Potential value loss per unit of time can be a parameter in optimization algorithms described herein to minimize or reduce value loss due to delay in reaching target destination for a customer satellite12.

Next, the assignment layer38can determine costs from each network node to the customer satellite12and from there to destination position of the customer satellite12. The maneuver layer36can be used to determine a cost function associated with an OTR from a node or an asset (such as a space tug10) to a customer satellite12and from there to final destination of that satellite. In one embodiment, the cost associated with an OTR can be augmented with the value loss per unit of time to a customer satellite operator, incurred during transfer to final destination time. If the customer's satellite can function in transit using the hosting capabilities of the space tugs10, then the value loss is accordingly reduced to account for hosting.

Next, a selection algorithm can be chosen to find an optimum selection of space tugs and an associated mission profile. In one embodiment, an auction algorithm can be used to find a tug assignment and set of OTRs that minimizes the cost functions. When a set of space tugs10(and/or depot satellites14, if applicable) are chosen, the mission profile can be executed to deliver the customer satellite12to its final destination.

Initial Build-Up of the DSTN30

In one embodiment, the DSTN30can include a plurality of in-space assets, such as space tugs10and satellite depots14, in order to provide coverage of the earth's orbital space to customer satellites12. One method to launch and build up the initial plurality of the space assets in the DSTN30is to leverage the demand for small satellite launches. As described earlier, the increasing demand for smallsat launches and scheduling differences between the operators, translate to an increase in availability of launches with excess capacity. This excess capacity can initially be used to launch the initial space assets of the DSTN30and to provide supplies and replacements to the DSTN30. In another embodiment, launch space can be purchased and offered at cost to smallsat operators to utilize the excess capacity for launching the assets of the DSTN30. Using this approach, the assets of the DSTN30can reach space for nearly free or at very low cost.

Advantages of the Disclosed Systems and Methods

The disclosed embodiments of space transportation networks make space transportation cheaper and quicker.

In spacecraft technology, the amount of fuel required to accelerate a given mass increases exponentially with respect to the change in velocity to be imparted (delta-V), and the efficiency of the spacecraft's engines (ISP).
fuel_mass=payload_mass*e{circumflex over ( )}(dV/ISP)

In one respect, Delta-v is the “cost” to transport a spacecraft between different points in space. The ISP is how much energy is generated by each pound of fuel. It can range from ˜200 seconds for simple chemical engines, to 450 seconds for cryogenic ones, and up to 1500 seconds for electric engines. Different engines are suited for different applications. Electric engines are efficient & low thrust, so they are used in non-time-critical missions. Chemical engines are high thrust, so they are used in launch and altitude control. Ideally, the max payload would be dictated by the maximum fuel-mass and the delta-V to be delivered, but engines, fuel-tanks, and avionics subtract from the potential payload_mass. This “inert-mass” is related to the liftoff-mass by the inert-mass ratio (s). Values range from 0.05 (5% of the liftoff-mass is inert) for launch-vehicles, to ˜0.4 for electric propulsion systems.

To achieve delta-v beyond what each individual vehicle's base mass would allow, we turn to staging. Staging is distributing the desired change in velocity over multiple vehicles, one stacked on top of the other; lower stages boosting upper stages to a given staging velocity. An important rocket metric to understand this is the ratio of lift-off mass (G) to final payload_mass (P).FIG.8is a graph that illustrates this ratio for a given (s) and (ISP).

For direct-to-destination approach to space access and transportation, launch-vehicle designers would optimize each stage (engine type, fuel capacity, etc.) to minimize the G/P to a given orbit. For geostationary transfer orbits (largest launch market), this led to using high-performance cryogenic core-stages aided by many solid boosters. By varying the number of boosters on lift-off, single vehicles would service many payloads, always leveraging the same core design, and enjoying a relatively low (efficient) G/P. However, today's space industry requirements demand a different approach.

Instead of building families of vehicles and creating many variations to tailor performance for particular missions, launch companies can utilize a one size fits all approach to space-transportation, with one or two vehicle variations at most. Leveraging mass-production techniques and commonality between stages, the launch companies can abandon lowering G/P as a design metric, and can instead focus their designs toward lower complexity and marginal cost. In one respect, they can give up on physical “efficiency” for actual cost per kg.

At the same time, launch companies are also interested in reusability. Instead of discarding rockets after flight, they can sacrifice some payload for fuel and landing back to earth after a successful launch. On the other hand, this approach will decrease bulk cost to LEO, but will have an exponentially negative effect on payload to GTO. For example, fully reusable 2-stage launch-vehicles will only be ˜½ as efficient at direct transfers to GTO versus previous generations of rockets (for every 10 lbs. delivered to LEO, they will only deliver 2 lbs. to GTO (vs 5 lbs. before)).

Consequently, launching direct to final destination includes the inherent limitation outlined above. The disclosed embodiments of a distributed space transportation network solve these issues. In-space reusable rockets (stages that stay in-orbit and perform multiple transfers to high-energy orbits) perform in-space transportation. The space tugs10of the DSTN30are effectively “de-facto” staging, without the penalty of having to launch from the earth for every transfer request. These tugs will more efficiently perform GTO insertions, using cheaper fuel brought to LEO in the process.

There is also a number of other challenges that the disclosed embodiments help to solve. As described earlier, the average satellite is getting smaller (˜150 kg), but in contrast, the cheapest rockets are becoming larger (˜100.000 kg). Options for affordable, practical, and scalable launches of the increasingly small-satellites are limited, and demand for launches to far-off destinations (geostationary transfer, moon orbit, etc.) is only increasing. Rides on reusable vehicles will be relatively infrequent. With launch representing only a fraction of a large satellite's cost, it is unlikely launch companies will see much of an increase in cadence as they drop prices, and their rockets being larger than all current payloads, they will be flying with even more unused capacity (40% or more).

Reusable launch vehicles will also be twice less efficient at directing inserting satellites to far-off destinations due to the exponential stacking of various performance penalties (namely, those related to cost and reuse instead of efficiency). LEO small-satellite operators will soon need to deploy hundreds of satellites, and will likely turn to price per-kg as the main differentiator between providers. They could leverage large rockets' unused capacity and lower cost, but constellation satellites deployed on them would need to be able to spread out after launch to be effective. Furthermore, adding onboard propulsion to enable this would not be as straight-forward as one would think. For example, existing chemical propulsion systems for smallsats are bulky and usually have low ISP, limiting the overall delta-V capacity and subtracting from the available payload volume (though they can be quick to transfer). Electric-propulsion on the other hand, would enable high delta-v maneuvers, but would also place massive power burdens on satellites. Electric propulsion thrusters are also fairly expensive (approximately $100k to $500k for reliable ones), and it can take months for them to transfer a payload to final destination (months that might cost a satellite operator substantial lost revenue.

Riding on custom-sized small-rockets would destroy the unit economics of constellations, as smaller rockets are almost an order of magnitude less efficient than larger ones (on price per kilogram). So, unless this is addressed, they'll only be used for a fraction of all missions (demonstrators/early deployment/military satellites and the like). This lack of efficiency also means that direct missions on small rockets beyond low-earth orbit are highly unlikely, as their performance decreases to near zero very quickly.

Dedicated space-tugs, which are co-riders on launch would find themselves grappling with the same trade-offs that smallsats w/propulsion face. Those include, for example, long transfer times, high cost, limited payload_mass and volume transport capability, and low power. For some tugs, such as electric tugs, this would mean a duplication of engineering efforts and development and duplication of substantial cost. Upper-stage based tugs would need more propellant to lug their large inert mass around, which would make them inefficient, rare, and difficult to justify developing.

The disclosed embodiments of distributed space transportation networks, address these issues by enabling any satellite to launch on any launch-vehicle, regardless of what initial orbit that rocket is going to (beyond some commonly accepted standard orbits). This would allow launch-providers to compete on an even playing-field, where they can optimize their operations for parameters such as their response time, cost per kilogram, scalability, and ease of use.

Since the space assets of the DSTN30can act as in-space stages that do not need the extra fuel to land back on earth and they be reused in space, they can deliver payloads to far-off destinations with twice as much efficiency of reusable upper-stages. The DSTN30can also provide services to spread satellites across many different planes for constellations, and at the price of fuel cost to LEO. This can enable effective single-satellite replacements on rideshares, and dedicated multi-manifest missions.

FIG.9illustrates the performance cost of reusable upper-stages, relative to the use-and-dispose rocket launches. The DSTN30achieves higher efficiencies of use-and-dispose and reusable upper-stages and can be superior to both these space transportation methods.

In another respect, the DSTN30decouples spacecrafts from propulsion-related tradeoffs and both the marginal and non-recurring expenses that are associated with them. In one embodiment, utilizing the DSTN30would be 30 times quicker than electric propulsion, and 10 times cheaper than onboard chemical propulsion (assuming in-orbit fuel cost of $5,000/kg).

The DSTN30can allow small rockets to become economically feasible and practical because they can launch to LEO and using the DSTN30can be launched to far-off destination, that without the benefit of the disclosed embodiments would have required a large rocket launch. As an example, satellite operators do not need a 10-ton rocket to carry their satellites to GEO, but rather they can use a 3 ton rocket to LEO and use the space tugs10to insert into GEO.

Furthermore, utilizing the DSTN30can justify the duplication of efforts through in-space reuse. In the electric-tug case, the DSTN30allows approximately 6 times more reuses, as chemical tugs can bring them quickly to a satellite depot14. For upper-stage tugs, in-space refueling (as opposed to returning to earth) would make them highly capable direct GEO insertion tugs, as they could use their large propellant capacities, without having to expend their fuel reserve on launches from the earth.