Case Study: Designing a Global IoT Constellation from Scratch

"Design is where the trade study stops being a table and starts being a commitment."

Executive Summary

In the first case study we audited a constellation that exists. Here we do the harder thing: we design one on paper. A startup wants to connect low-power sensors — shipping containers, weather buoys, pipeline monitors, wildlife trackers — anywhere on Earth, continuously. That is a constellation problem, and unlike the imaging case, its sizing turns on a single design variable we get to choose: the altitude. We will run a real trade study across candidate altitudes, watch the required fleet size swing by a factor of three, choose a shell on grounds that include sustainability, arrange the satellites into orbital planes, plan the launch campaign, and — because §33.6 insists — write the disposal plan before we launch. The point is not the specific number of satellites; it is the method, the same one you will run on your own mission in the capstone.

Skills applied

• Turning a mission objective into requirements and a driving design variable (§33.4–33.5; Chapter 29).
• Running a coverage-geometry trade study across altitudes and reading the fleet-size sensitivity (§33.5).
• Choosing an orbit under a sustainability constraint, not just a performance one (§33.6; Chapter 9).
• Sizing a launch campaign and a capital budget from the fleet (§33.4; Chapter 30).
• Writing a credible end-of-life disposal plan as a design requirement (§33.6; Chapter 35).

Background

The requirement

Our customer's objective is one sentence: "Provide continuous, global, low-rate connectivity to low-power ground sensors, at minimum cost, disposed of responsibly." Flow it down into requirements we can design against (Chapter 29):

• Coverage: continuous — at least one satellite in view of every point on Earth (including high latitudes) at all times.
• Elevation: users are cheap, non-tracking terminals, so demand a minimum elevation of $\varepsilon = 20^\circ$ (enough to clear obstructions without needing the satellite near the zenith).
• Data: low rate (sensor telemetry, not video), so capacity is not the driver — unlike Starlink, our fleet is sized by coverage, which makes the geometry of §33.5 the whole story.
• Cost: minimize the number of satellites and launches.
• Sustainability: the constellation must dispose of itself within the emerging 5-year post-mission rule (§33.6).

The tension is already visible: "minimize satellites" pushes us high (each satellite sees more), while "dispose within 5 years" pushes us low (only low orbits self-clean). The trade study is where we resolve it.

Phase 1: The driving variable — altitude

Because our fleet is coverage-limited, the number of satellites follows directly from the §33.5 geometry, and the input we control is altitude $h$. Recall: $$\sin\eta = \frac{R_E}{R_E + h}\cos\varepsilon, \qquad \lambda = 90^\circ - \varepsilon - \eta, \qquad f = \frac{1-\cos\lambda}{2}, \qquad N_{\min} \gtrsim \frac{1}{f}.$$ Higher $h$ makes each satellite's footprint fraction $f$ larger, so $N_{\min}$ falls. Altitude is the driving requirement of this design — the one variable to which the whole thing is most sensitive. So we compute the fleet floor at three candidate altitudes.

Phase 2: The trade study

Evaluate the geometry at $\varepsilon = 20^\circ$ for $h = 550$, $800$, and $1{,}200\ \text{km}$. (Each row is one run of the §33.5 relations; the arithmetic is the same as the chapter's worked example.)

Read the table as the §33.6 dilemma in three rows. The $1{,}200\ \text{km}$ shell is the cheapest to build — only $\sim 43$ satellites for coverage — but a dead satellite there lingers for centuries, a debris legacy that violates our sustainability requirement outright and can only be met by adding propulsion to every satellite to force a deorbit. The $550\ \text{km}$ shell needs three times as many satellites, but it disposes of itself: residual atmospheric drag (Chapter 12) re-enters a dead satellite within the 5-year rule with no propulsion at all.

Strategy first. The naive optimum ("fewest satellites") picks $1{,}200\ \text{km}$. But a trade study scores against all weighted criteria, not one. Weight sustainability and per-satellite simplicity heavily — our satellites are tiny and cheap, so tripling their count hurts less than bolting a propulsion system onto every one and owing the orbit a century-long debt — and the decision flips to the low shell.

Phase 3: The design decision and the fleet

Choose $h = 550\ \text{km}$. It self-disposes within the rule without propulsion (simpler, cheaper, more reliable satellites), and as a bonus delivers low latency (§33.5) that widens the service's future market. We accept $\sim 3\times$ the satellite count as the price of a responsible, propulsion-free design.

Inclination. "Global, including high latitudes" rules out a mid-inclination shell — a $53^\circ$ orbit never overflies the poles (Chapter 9). We choose a near-polar inclination, $i \approx 87^\circ$, so the constellation reaches all latitudes (the choice Iridium and OneWeb made for the same reason).

Fleet size. The coverage floor is $N_{\min} \approx 129$, but that assumes footprints tile the sphere perfectly and every satellite is healthy. A real design carries margin for imperfect tiling, for guaranteed no-gap coverage as satellites and Earth rotate, and for in-orbit failures. A factor of roughly two is typical, giving a design fleet of about $$N_{\text{design}} \approx 2 \times 129 \approx 260 \ \text{satellites.}$$ Arrange them in a Walker-style pattern (§33.5) of, say, 12 orbital planes of 22 satellites each = 264, evenly phased. (A real design would refine this with a streets-of-coverage or Walker optimizer; our factor of two gets us to the right size to plan a program around.)

🔧 Engineering Reality: The factor of two is not a fudge — it is the gap between the idealized coverage floor and a guaranteed one, plus operational spares. A constellation that has exactly $N_{\min}$ healthy satellites, perfectly placed, has zero margin: the first failure opens a coverage gap. Real operators fly on-orbit spares in each plane so a failure is covered immediately, before a replacement launches. Margin at the constellation level is the same idea as mass margin at the vehicle level (Chapter 29): reserve held against the certainty that something will go wrong.

Phase 4: The launch campaign and the budget

Now cost the program, in order-of-magnitude terms (all figures Tier 3, illustrative — the goal is the method and the ratios, not a bankable quote).

Launches. Our satellites are small (say $\sim 20\ \text{kg}$ each — microsatellites, larger than a CubeSat to hold the polar-capable radio and antenna). A dedicated launch is warranted here rather than rideshare, because we need a specific orbit ($550\ \text{km}$, $87^\circ$) and rideshare would not deliver it (§33.4). Suppose a medium launcher places $\sim 44$ of our satellites per flight into one plane pair. Then $$\text{launches} = \frac{264}{44} = 6 \ \text{flights.}$$ At an illustrative $\$50\ \text{M}$ per dedicated launch, that is $6 \times \$50\ \text{M} = \$300\ \text{M}$ of launch cost.

Satellites. At an illustrative mass-produced cost of $\$0.5\ \text{M}$ each, the fleet is $264 \times \$0.5\ \text{M} = \$132\ \text{M}$.

Order-of-magnitude capital cost: $\sim \$430\ \text{M}$ to deploy, plus ground stations and operations. Notice where the money is: launch dominates, which is exactly why the choice between rideshare and dedicated launch (§33.4), and any future drop in launch price (theme 5), moves this program's viability more than any subsystem decision. The driving requirement — altitude — set the fleet size, which set the launch campaign, which set the cost. The whole chain of Chapter 29 is visible in one page.

Phase 5: The disposal plan and sanity checks

Disposal plan (a requirement, not an afterthought — §33.6). Because we chose $550\ \text{km}$, the primary disposal mechanism is free: at end of life (or at failure) a satellite is left to atmospheric drag, which re-enters it within the 5-year rule with no propellant required. We add two design measures: passivation — vent the battery and any pressurised gas at end of life so a dead satellite cannot explode into fragments (Chapter 35) — and design for demise, keeping the satellite small and low-melting-point so it burns up completely on re-entry, leaving no debris on the ground. Our sustainability requirement is met by the orbit choice itself, which is the cleanest possible way to meet it.

Sanity checks.

1. Fleet vs floor. $264$ design satellites against a $129$ coverage floor is the factor of two we intended — consistent, not a slip.
2. Comparison to reality. Iridium provides global (including polar) coverage with $66$ satellites at $\sim 780\ \text{km}$ and a lower elevation mask; our larger number is consistent with our lower altitude and higher elevation requirement, both of which shrink the footprint and demand more satellites. The design sits in the right neighbourhood as a real polar constellation.
3. Every knob. Lower altitude → more satellites but self-cleaning; higher elevation mask → more satellites; near-polar inclination → global reach at the cost of equatorial over-coverage. All point the physically sensible way.

The design closes: a coverage requirement produced a fleet size, the fleet produced a launch campaign and a budget, and the orbit we chose satisfies the sustainability requirement for free. That is a mission design (Chapter 29) in miniature, for the newest kind of mission this book describes.

Discussion Questions

1. Our trade study picked the altitude that needed more satellites. Reconstruct the argument: what did the low shell buy that justified tripling the fleet, and under what different weighting would you have chosen $1{,}200\ \text{km}$ instead?
2. We sized the fleet by coverage because the data rate is low. How would the sizing logic change if this were a broadband constellation, and why does that push the real number far above the coverage floor?
3. We chose a dedicated launch over rideshare. State the specific requirement that forced that choice, and the cost consequence.
4. The disposal plan relied on the orbit doing the work for free. Argue why "choose an orbit that disposes of itself" is a more robust sustainability strategy than "add propulsion to force a deorbit."

Your Turn: Extensions

• Option A (design). Re-run the trade study for a lower elevation mask, $\varepsilon = 10^\circ$ (cheaper terminals that can see closer to the horizon). Recompute $N_{\min}$ at $550\ \text{km}$ and decide whether the smaller fleet is worth the worse link geometry.
• Option B (computation). Extend astrotools/constellation.py with design_fleet(alt_km, min_elev_deg, margin) that returns the design fleet size (floor × margin, rounded up). Reproduce the $\sim 260$ result for $(550, 20, 2.0)$. (Do not run it; hand-trace and add # Expected output:.)
• Option C (your mission). If your MDR track could be served by a constellation (Track A most obviously), run this whole method for it: pick an altitude by trade study, size the fleet, estimate the launches, and write the one-paragraph disposal plan into your MDR.

Key Takeaways

1. Constellation design turns on altitude. It is the driving variable: raising it shrinks the fleet (fewer, bigger footprints) but lengthens how long dead satellites persist. The trade study makes that sensitivity explicit.
2. Sustainability is a design input, not a cleanup. Choosing a self-decaying $550\ \text{km}$ shell met the disposal requirement for free — a better strategy than bolting propulsion onto every satellite.
3. The fleet drives everything downstream. Coverage floor → design fleet (× ~2 margin) → launch campaign → capital cost, with launch dominating. This is the Chapter 29 chain, applied to many satellites at once.
4. The method is universal. The specific numbers are illustrative; the sequence — requirements → driving variable → trade study → sized fleet → launch plan → disposal — is exactly the mission design you will defend in the capstone.