Every NTN service starts as an idea and has to end as something that works in orbit. Between those two points is a journey, and we have spent 25 years learning where it runs smoothly and where it gets difficult. This piece walks through that journey the way we take customers through it, in three phases, with a close look at one decision in each phase that tends to catch programmes out.
A design can be fully 3GPP standards-compliant and still produce a service that underperforms in the field, because the standard defines what the system must do, not whether your particular satellite, over your particular coverage area, will do it well. That gap is where the work lives, and it concentrates in a few predictable places.
Gatehouse Satcom is an active member of the 3GPP delegation that writes the NTN standards the industry now deploys against. Our software runs in orbit today, and we completed a first commercial link between a satellite carrying our payload software and a standardised device on the ground. Our customers range from established satellite operators to startups building new services, many of them first movers in this market.
That experience shaped how we work.
One way to approach this is through three phases: Analyze, Validate, Operate.
- Analyze settles what the service can do before any money goes into hardware.
- Validate proves it on real equipment while the answers can still change the plan.
- Operate carries it through launch and into live service. Each phase exists to settle a specific class of decision while that decision can still be changed, and the order matters, because the room to act narrows at every step toward launch.
Not every customer needs all three from us. Some arrive with feasibility already done and need validation. Others have validated and need help reaching live operation. The phases describe the whole path, but we join it wherever you are on it.
Phase 1 – Analyze
Analyze primarily answers one question before any money goes into hardware: will the service do what the business case needs it to do, across its whole coverage area and not just under ideal conditions?
This phase is short relative to what follows, and it carries the decisions that cannot be reversed. A satellite’s fundamental signal-delivering capability is set when it is designed and fixed when it launches. The work here is to get those numbers right while they are still adjustable, and to size them against the worst case, not the best.
Calculating link budget feasibility with varying signal conditions
A satellite beam covers a wide area, and conditions across that area are not equal. A device near the centre of the beam has a short, strong path to the satellite. A device at the edge has a longer, weaker one. The spread between them is wide.
For an NB-IoT service from a small satellite at roughly 600 km in S-band, the per-device link budget shifts substantially across the beam. In this example, near the centre (best case), the downlink can carry around 35 to 50 kb/s and the uplink around 1.5 to 3 kb/s per device. At the edge (worst case), the same system delivers closer to 13 to 20 kb/s downlink and 0.6 to 1.5 kb/s uplink per device. The centre case and the edge case describe the same satellite on the same pass. The difference decides whether the service meets its targets across the footprint or only directly beneath the satellite.
So the real choice in Analyze is how to dimension the system. Dimension for the worst case and the service holds across the footprint, at higher cost. Dimension for the best case and the beam edge becomes the weak point of the service. The optimistic version reads as acceptable in a feasibility document and reveals itself only in orbit, by which point the capability is fixed and cannot be raised. Settling this in Analyze separates a pilot that scales from one that holds up only in favourable conditions.
Phase 2 – Validate
Analyze produces numbers on paper. Validate tests whether the system behaves the way the paper predicts, while there is still time and budget to respond to the answer.
The phase recreates the conditions of orbit in a lab, with real hardware, software, and devices. A lab is not space, and we treat it as a close approximation rather than a substitute. It is close enough to surface whether the feasibility assumptions hold. A problem found here is inexpensive to correct. The same problem found after launch may not be correctable at all. Two results carry the most weight for the decision to proceed, which is why this phase has two deep dives.
Holding the link across a full satellite pass
A satellite pass runs from horizon to horizon over several minutes. The satellite rises, passes overhead, and sets. Its angle to a device on the ground changes throughout, and link strength changes with it: strongest when the satellite is overhead, weakest near the horizon at the start and end of the pass.
The result an operator needs is whether the measured link clears the service’s minimum requirement at every point in the pass, including the weakest. A link that stays above the requirement at its worst point confirms the feasibility numbers and gives real evidence the service will perform. A link that drops below at the edges identifies a problem in the lab, where there is still time to fix it. Either outcome is useful, and both are far better learned before launch than after.
Serving enough devices at once
The second result concerns capacity. A satellite with sufficient power can run several parallel data channels rather than one, serving more devices simultaneously. There are efficient and wasteful ways to add that capacity, and the choice depends on having the onboard power to support it. Adding channels without the power to feed them can reduce service rather than increase it.
The question Validate settles is not whether the satellite can carry a signal, but whether it can serve the number of devices the business depends on at the quality those customers expect. Confirming that with real components, before launch, is what makes the answer worth having.
Phase 3 – Operate
Operate begins at launch, the one boundary a programme cannot walk back. Before it, the system is adjustable. After commissioning, the satellite serves real traffic in real conditions, and the distinction between what is fixed and what is tunable becomes concrete.
The fixed elements were decided in Analyze and committed at launch: the satellite’s power, its hardware, the area its beam covers. What remains adjustable is how that fixed capability gets spent across the devices in view. However, that tuning works only within the boundaries the earlier phases set.
Spending a fixed resource between reach and capacity
The clearest tunable decision in orbit is how to divide the satellite’s airtime between serving many devices and reaching difficult ones.
Devices in good conditions cost little airtime, so the satellite can serve many of them at once. Devices in poor conditions, at the beam edge, under cover, or with weak antennas, cost more, because reaching them reliably means repeating their transmissions, and each repetition consumes airtime that could have served another device.
The result is a direct trade-off. Spend a slice of airtime on strong, central devices and it might serve around ten of them. Spend the same slice admitting difficult edge devices, each needing its signal repeated several times, and it might serve closer to four. The same resource, divided two ways, with more than a twofold difference in how many devices get served.
An operator sets where that line falls, based on the density and type of devices the service is built for, and can move it dynamically: favouring reach over one region, capacity over another, adjusted across the life of the service. Even the satellite’s software can be updated in orbit when needed. The boundaries that tuning works within, though, were all fixed before launch. The room to manoeuvre in Operate is as wide as the decisions in Analyze and Validate left it.
The journey is not the destination
Our software is standards-compliant, proven in orbit, and capable whether it runs on the satellite or on the ground. But software alone does not carry an operator from an idea to a service customers rely on.
The journey does. A feasibility analysis sized against the worst case. A validation phase that turns assumptions into evidence while there is still time to act. A launch that arrives with the service boundaries already settled.
The journey is the method. The destination is a validated service with a short time to market, performing across the whole footprint and serving the devices the business depends on. Getting there sooner, with the risk already retired, is the value of running the phases in order.
Wherever you are on that path, we can join it. For teams starting fresh, the Analyze phase is a natural entry point: a structured feasibility study that turns a business case into concrete link-budget, coverage, and capacity numbers in weeks, not months. For teams further along, we pick up at validation or live operation. Book a meeting, and we will start from where you are.
