The calculation was never the hard part

Satellite network planning resists better calculators because the real difficulty lives in the coupling between constraints, not in any single computation.

Serana · June 22, 2026

Ask a satellite operator a simple-sounding question. Can we put this new customer on that beam? On the surface it is a link budget, a few minutes of arithmetic any engineer can do. In practice it is nothing of the kind.

To answer it honestly you have to know how much of the beam is already committed, and to whom, and under what service guarantees. You have to know what the link will do when it rains, not on an average day but on the worst day the contract has to survive. You have to know whether the capacity you would draw down is needed elsewhere, whether the gateway and routing can carry it, and whether the power you would draw to close your own link is power the rest of the beam is counting on, because reaching for it pushes your neighbours toward interference and saturation. Your fit changes theirs. Change the margin on this link and you have quietly changed the capacity picture, the routing, and the risk of breaching an SLA two customers over. The calculation was never the hard part. The hard part is that none of these things holds still while you work on the others.

Five constraints around a central question, connected to each other in a web — Every constraint on the beam is coupled to the others. Changing one changes the picture for all of them.

This is what the industry's tooling consistently underestimates. There are excellent tools for sizing a link, modelling a beam, and optimising a constellation. Each is a calculator for one slice of the problem, and each is good at its slice. But an operator does not run a slice. They run a system in which every slice is coupled to the others, and the decisions that matter live in the coupling, not in any single calculation. A planner's real skill has never been doing the math. It has been knowing which constraints actually bind in a given situation, how they trade against each other, and where a clean local answer creates a mess somewhere global.

Four isolated tools on the left versus four connected nodes on the right — Individual tools each handle one slice well. The operator's real burden is reconciling answers across all of them at once.

That is why faster calculators have not made planning meaningfully easier. You can hand an engineer a perfect link budget tool, a perfect capacity tool, and a perfect interference tool, and the burden that remains (holding all of it in one head, reconciling the answers, deciding what gives) is the burden that actually costs days.

So the rational response is to not look. The safest way to run a network this tightly coupled is to leave what works alone: hold conservative margins, keep the power plan untouched, and change a setting only when an interference complaint forces the issue. It is a sensible instinct, and an expensive one. A network run defensively leaves capacity, and revenue, on the table, and drifts further from its best configuration with every shift in demand and weather.

Horizontal capacity bar showing committed capacity, a wide conservative buffer, and unused headroom — Conservative margins protect service guarantees but leave usable capacity stranded. The dashed region represents revenue the network could be earning.

Consider the customer and the beam once more, made concrete. The bandwidth is there, so a naive check says yes. But the carrier that customer needs would push the transponder outside its linear operating range, and the power that costs would break the availability guarantee on two customers already on the beam. The real answer is not yes or no. It is that power, not bandwidth, is the binding constraint, that the fit is possible if the new customer accepts slightly lower availability or if another is moved to a neighbouring beam, and that an engineer can see exactly why. That last part is not a nicety. In a mission-critical operation, an answer you cannot interrogate is a liability however fast it arrives, because no operator will stake a customer's service on a recommendation they cannot check.

Two gauges showing bandwidth with room to spare and power pushed past its limit — The same transponder can have plenty of bandwidth while power is already past the backoff threshold. Seeing both dimensions together reveals the real constraint.

Frame planning this way and the horizon shifts. Once a system can reason across the whole coupled problem and show its work, answering a planner's question is only the first rung. The same capability can watch the network continuously, see where capacity is about to tighten, and propose the move before anyone has to ask, until the questions arrive already answered. That is the direction the industry is travelling, from manual planning toward connectivity that plans, optimises, and eventually heals itself.

Four ascending rungs from Answer through Watch and Propose to Heal — Each rung builds on the last. A system that can answer a planning question can also monitor for emerging constraints, propose moves proactively, and eventually act on them autonomously.

The calculation was never the hard part. Reasoning across the system, and being trusted while you do it, always was.

This is the problem we built Serana to solve. Ask it a planning question in plain language and it reasons across the coupled system the way a senior planner would, grounding every step in real propagation, payload, and fleet models and the current state of your network, then returning an answer in seconds with its working laid out for an engineer to verify. Not a faster calculator, but a system that holds the whole problem at once and shows you why its answer is the answer. If this is the work you do, we would like to talk.