Satellite Capacity and Ground Segment Software: When the Beam Plan Still Lives in a Spreadsheet

Why the beam plan spreadsheet stops working

The spreadsheet was correct once. It had a tab per satellite, rows for carriers, occupied bandwidth in MHz, a column for the customer holding each slot, and a note about guard bands. One capacity planner maintained it and knew where the fudges were. Then the fleet added high throughput payloads with dozens of spot beams instead of a handful of wide transponders, maritime customers started roaming across beams mid voyage, the modem population fragmented across three hub vendors, and adaptive coding turned every carrier's throughput into a weather dependent variable rather than a fixed number.

Now the same spreadsheet is consulted before every quote and trusted by nobody. Sales asks whether there is capacity on a beam for a new maritime account. The planner opens the tab, sees space, and quotes. Engineering later discovers the beam is power limited rather than bandwidth limited at that elevation, so the extra carrier does not close at the committed information rate the contract already promised. Somebody eats the difference, usually by allocating more space segment than was sold.

The consequence in this business is asymmetric and that is what makes it worth solving. Oversell and you degrade customers who paid for a committed rate, on an asset with a service level agreement and a competitor one phone call away. Undersell and you leave transponder capacity dark, which is the most expensive idle inventory in commercial technology. The spreadsheet cannot tell you which side of that line you are on, because it stores bandwidth and your business runs on delivered throughput under conditions.

Problem 1: you sell MHz and the customer buys Mbps

A transponder segment is bandwidth. A service level agreement is a committed information rate in megabits. The conversion between them is a modulation and coding decision that changes with the terminal's antenna size, its position in the beam, the rain margin you designed for, and whether adaptive coding is stepping down right now because of weather over the gateway.

So one number in the spreadsheet is doing two jobs badly. Capacity planners handle this with a rule of thumb efficiency figure per band and service type, applied uniformly, which is roughly right in the middle of the beam and materially wrong at the edges. Edge of coverage is exactly where the maritime and aero customers spend their time.

What a custom build does: hold both, and hold the relationship between them explicitly. Inventory is bandwidth and power, per beam, with the operator's own EIRP and G over T contours loaded rather than assumed. A sold service is a committed rate against a terminal type at a location or a route. The system computes the required bandwidth from the modulation and coding scheme that closes at your design availability, so the answer to whether a beam can take another customer accounts for whether that beam is power limited before it is bandwidth limited. Planners already know how to do this arithmetic. The point of the build is that it stops being done once at sale and starts being maintained continuously as the population changes.

Problem 2: every service change means a link budget recomputed by hand

A customer wants to move a vessel to a different service plan. An aero operator adds fifteen tails. A government account changes terminal type mid contract. Each of those is a link budget, computed in a spreadsheet by an RF engineer, in a format that engineer designed, with assumptions in cells nobody else can find. The engineer is a bottleneck for the commercial team, and the record of what was assumed disappears the moment the file is emailed.

Integrasys and the hub vendors provide tooling around carrier monitoring and commissioning, and that tooling is genuinely good at what it targets. What it does not do is act as your commercial system of record, where a link budget is attached to a contract line, versioned, and re run automatically when the underlying beam plan or terminal population changes.

What a custom build does: make the link budget an object rather than a file. Inputs come from the operator's own assumption set: antenna sizes, terminal EIRP and G over T by model, pointing loss allowance, rain model and availability target per region, hub characteristics per vendor. Output is stored against the service, with the modulation and coding scheme, the required bandwidth and the margin. When a beam plan changes or a terminal is swapped, everything downstream recalculates and the exceptions surface as a queue. The RF engineer stops being a ticket queue for routine changes and starts reviewing the ones that actually need judgement, which is where their time was always worth more.

Problem 3: roaming terminals make utilisation and billing disagree

A vessel leaves Rotterdam on a beam over the North Sea, crosses into a second beam, transits to a third for the Atlantic leg, and spends four days in a region served from a different gateway entirely. Your billing says the customer bought a committed rate on a global plan. Your capacity utilisation reporting says four beams each carried some fraction of that service for some fraction of the month. Neither number reconciles to the other, and when a customer disputes an availability credit you cannot show what they actually received and where.

Aero is the same problem at higher speed and with more handovers per hour. Land mobile adds terminals that cross beams unpredictably. Any inventory model that assigns a service to a beam as a static attribute is wrong for the entire mobility segment, which is the part of this market that is growing.

What a custom build does: model beam occupancy as a time series per terminal, fed from the hub and the network management system rather than assumed from the contract. Then utilisation per beam is computed from where terminals actually were, and the customer's committed rate is checked against what was deliverable in each beam they visited. That gives you three things the spreadsheet never could: honest utilisation for capacity planning, defensible evidence for service level disputes, and the ability to price mobility contracts on observed beam usage rather than on a worst case allocation you hold permanently.

Problem 4: the NOC sees a fault, the commercial team sees a contract

An outage happens. The NOC works it as an engineering event: which carrier, which hub, which terminals. The account manager finds out when the customer calls. Afterwards, computing the service credit means somebody joins an outage log to a contract by hand, and the two records were never designed to be joined.

The same disconnect runs the other way. Interference on a carrier is detected by monitoring, and identifying whose service it affects requires knowing the current assignment, which lives in the spreadsheet that is slightly stale. Carrier identification helps you find the source. It does not tell you who is owed an apology.

What a custom build does: put the contract and the carrier in the same data model, so an event on a carrier immediately resolves to the affected services, the customers behind them and the availability terms in each agreement. Credits are computed from the outage record rather than negotiated from memory. Customer facing reporting is generated from the same source, which matters more than it sounds: maritime and government customers increasingly ask for monthly availability evidence, and producing that manually costs a person several days a month for reports nobody reads unless something went wrong, at which point they are read very carefully indeed.

What a satellite capacity build costs and how long it takes

From Digital Heroes delivery experience, a first release covering capacity inventory with power and bandwidth held separately, contract linked reservations, and link budget computation against your own assumption set runs $90,000 to $200,000 and ships in 14 to 20 weeks. A full ground segment platform adding hub and network management integration, roaming beam occupancy tracking, utilisation reconciled to billing, outage and credit handling, and customer reporting runs $250,000 to $600,000 phased over 9 to 15 months.

What drives cost up specifically in this domain: the number of hub vendors, because iDirect, Newtec and Comtech platforms expose different data in different shapes and each is its own integration. Fleet complexity, since a wide beam GEO payload and a multi beam high throughput payload with gateway diversity are different inventory models. Mobility, which adds the time series occupancy layer and roughly doubles the reporting work. Non geostationary capacity if you carry it, because the beam is moving as well as the terminal. And the state of your own contour data, which is the quiet one: if EIRP and G over T contours only exist as PDFs from the manufacturer, someone has to turn them into usable data before anything computes.

What keeps cost down: starting with one payload and one hub platform, and leaving mobility for phase two if fixed services are the bulk of your revenue today.

When Kratos, iDirect, Integrasys or Amphinicy is the right call

Buy where the product owns the layer. Kratos has deep ground system and signal monitoring capability and you are not going to rebuild it. Integrasys is strong on carrier monitoring, commissioning and interference detection. ST Engineering iDirect is your hub platform and its management tooling is the authority on what the network is doing. Amphinicy builds serious ground segment software. If your gap is monitoring, commissioning or signal quality, buy, and integrate.

Our position on when to build: when two or more of these are true. Your commercial inventory and your engineering reality are held in different places and disagree. You sell committed rates against terminals that move between beams. Link budget recalculation is a human bottleneck for routine commercial changes. Utilisation reporting cannot be reconciled to billing without manual work. Or you carry capacity from multiple payloads and wholesale suppliers on differing commercial constructs.

The tipping point is that vendor tooling models the network and your problem is the join between the network and the contracts. Nobody sells that join because it is made of your beam plan, your assumption set and your commercial terms. That is the definition of a custom build, and it is also why it holds its value: the join does not go stale when you change hub vendors.

How to choose a developer for ground segment software

Ask them to model capacity on a whiteboard before you sign anything. A developer who understands this domain will draw payload, beam with power and bandwidth held separately, carrier, terminal, service with a committed rate, and a time dimension on the occupancy, and will ask about edge of coverage. Someone who draws capacity as a single number per beam has built a resource booking system and will discover satellite physics on your budget.

Ask how they would handle a terminal that changes beam mid month. If the answer is that the service is assigned to a beam, they have not worked in mobility and half your growth segment is unmodelled.

Ask what they have integrated by name. Hub platforms, network management systems, monitoring feeds and billing are four distinct integrations with four different data shapes, and a developer who has done ground segment work will ask which hub versions you run before quoting rather than after.

Ask who owns the code, the repository and the infrastructure, and settle it in writing before kickoff. At Digital Heroes the client owns it from the first commit. A useful first step: take one live maritime contract and ask a developer to explain how they would prove, from your data, what that vessel actually received in each beam it crossed last month. If they can describe the data path, they understand the problem.