The NTN ecosystem has reached a useful turning point. On the gain side, 3GPP standardisation is replacing proprietary silos with a common framework, unmodified handsets and eRedCap devices are opening consumer and IoT volume, mobile network operator demand is becoming real, and regenerative payloads are moving more of the gNB into orbit.
That creates a credible path from niche satellite connectivity to scalable, standards-based service delivery.
The pain side is just as important. Payload SWaP and power budgets now collide directly with 3GPP processing demand. Doppler, delay and fast handover challenge assumptions inherited from terrestrial networks. Integration risk can remain hidden until late in the programme, and no single architecture fits every use case or orbit.
This is where the commercial promise of NTN meets the physical limits of the spacecraft.
That tension is the starting point for the business question in this paper: how much capacity can be sold with confidence once the intended NTN service is translated into onboard processing, power draw and thermal load?
The business case for a direct-to-device or IoT constellation is built on five service assumptions: coverage, subscriber capacity, bandwidth per user, latency tolerance and availability.
Those numbers are the business case. They anchor the revenue model, the pricing, and the commitments made to boards, co-investors and early customers. Each of them is also a claim on the electrical power the satellite can generate and the heat it can dissipate.
In a regenerative 5G NR NTN payload, some or all the radio access network processing that would otherwise stay on the ground moves onto the satellite. That processing consumes power and generates heat that must be radiated away, and both draw against a fixed platform allocation.
So, the question that shapes how much service a constellation can sell: how much power and cooling does the intended service demand? Adding processing or thermal capacity is a manageable correction early on. Once the platform architecture is committed, the same change becomes far harder and far more expensive.
The options that remain sit on the service side, and they get pulled after capital is spent and after commercial promises have been made against the original figures.
Why capacity becomes a power problem
A satellite in low Earth orbit generates a limited amount of power, set by the size and efficiency of its solar arrays. Part of that keeps the spacecraft alive. What remains is shared across the RF payload, beamforming and signal processing, onboard network processing, and the other mission functions competing for the same supply.
Every function that consumes power also adds heat, and once the satellite reaches its thermal limit, output has to be reduced. Deliverable service is bounded twice: once by available power, and again by the thermal limit on how hard and how long the payload can run.
The headline capacity figure is only real if the payload can sustain the traffic profile, concurrency and availability assumptions behind it within those limits. If the business case assumes a load the payload can only support for short periods, the capacity model and the spacecraft design are describing two different services.
Why orbit closes off the easy fixes
A terrestrial operator responds to a capacity shortfall by adding power, cooling, or another site. None of those options exist in orbit. The envelope is fixed at launch, so beamforming architecture must fit inside it too.
Beamforming architecture adds another claim on the same envelope. More flexible digital architectures support finer steering, dynamic coverage and more sophisticated capacity allocation, but that flexibility carries a processing and power cost. Analog and hybrid approaches reduce the digital processing burden at the expense of some of that flexibility.
The commercial point is that beamforming capability and network processing are not independent promises. Both must fit inside the same spacecraft envelope.
What changes when the numbers do not fit
The processing and power demand is often established late, and not through carelessness.
The detailed load can only be computed once the onboard architecture and functional split are chosen, while the capacity figures were committed earlier to close funding.
When the real demand lands after those commitments, four options remain, and each one moves a number the business case depends on:
- Fewer beams mean fewer cells per satellite, so coverage is broader and fewer markets are served at once.
- Less bandwidth per beam lowers the rate each user gets and weakens the broadband proposition, though it may still hold up for narrowband IoT.
- Fewer concurrent users mean less traffic carried per region, with congestion or admission limits becoming more likely as demand approaches the design ceiling.
- Lower availability moves service commitments down a level, away from the high-reliability figures broadband was priced on.
In practice these options are pulled in combination, and every combination reduces revenue-generating capacity. They are reductions in what can be sold, applied after the budget is committed.
Chosen deliberately, a phased capability roadmap is a sound commercial position.
Starting with IoT and adding broadband capacity levels or beams over time aligns the business case, the pricing and the platform from the start. The problem is only the version discovered late. When adopted deliberately from the outset, the roadmap aligns the business case, pricing and platform choice from the start. When discovered only at qualification, it becomes a forced reduction of promises already made to fit a service into hardware that cannot support it.
The satellite ends up serving the same beams and the same capacity levels either way. What differs is what was promised against them. A roadmap chosen up front was always the plan. A roadmap forced at qualification means the broadband capacity, the coverage or the availability figures already shown to the board and to customers no longer hold at the level they were priced on.
The Gatehouse Satcom perspective
Gatehouse Satcom works at this boundary: translating a target 5G NTN service into the processing behaviour the payload must sustain.
The mapping is specific to each programme. The same service definition can produce materially different processing loads depending on the onboard architecture, the functional split and the software implementation. Each programme needs its own estimate. Numbers from a previous build rarely transfer to a new one.
We always ask: for a given beam configuration, bandwidth, traffic profile and user concurrency, what processing load does the network create at average and at peak conditions, and does that load fit the spacecraft’s power and thermal envelope?
That question is only worth asking before the platform is decided. Ask it after the hardware is chosen and all it can do is explain why you are stuck.
When the selected COTS hardware is not yet understood to a sufficient confidence level, this estimate should feed a focused Proof of Concept and risk analysis stage. The purpose is not to delay the programme, but to test the critical assumptions early: whether the hardware can sustain the required processing load, power draw, thermal behaviour and performance margins. That evidence creates a clear go/no-go basis before the platform choice becomes difficult to reverse.
Estimate before you commit
The payload power and thermal envelope set a ceiling on the capacity you can sell, and that ceiling should be understood before you commit to a platform or promise a number to anyone.
Run the processing and power estimate before platform selection, and before any commercial commitment built on capacity figures. Where a phased roadmap is the right answer, choose it deliberately at the start.
The estimate does not get more accurate by waiting. Delay it and it arrives after the platform is frozen, when the only thing left to adjust is the service you have already sold.
