SES and the Systems Engineering Challenge of Multi-Orbit Operations

SES operates approximately 70 satellites. That number alone is not remarkable. What is remarkable is that those satellites occupy two orbital regimes that differ in altitude by a factor of roughly fifteen, operate under different physics, use different beam-forming architectures, and were designed and built by different contractors in different decades. Getting a maritime customer to see that fleet as a single broadband service is not a marketing problem. It is a systems engineering problem.

This profile examines how SES approaches that problem — not from a financial or commercial angle, but from the perspective of requirements management, system-of-systems architecture, and the operational complexity of running a multi-orbit network as a unified product.

The Two Networks That Must Become One

SES’s GEO fleet operates at approximately 35,786 km altitude. Latency is high — typically 550 to 600 ms round-trip — but coverage footprints are continental, beam capacity is well understood, and the operational playbook has been refined over decades. These are largely fixed or steerable beams, with frequency plans and interference coordination models that the industry mastered in the 1990s.

O3b mPOWER is something different. The Medium Earth Orbit constellation operates at roughly 8,000 km, cutting round-trip latency to 150 ms or below. The mPOWER generation adds fully software-defined payloads with on-orbit reconfigurable beams — up to 5,000 beams across the constellation, steerable in real time. Beam capacity, coverage geometry, and interference coordination are dynamic problems, not static configuration problems.

These are not two versions of the same system. They are two different systems that SES sells as a single managed service called mPOWER-enabled connectivity or, more recently, under the multi-orbit positioning of their “Space as a Service” strategy. That commercial framing hides an enormous technical integration burden.

The System-of-Systems Problem

A multi-orbit network managed as a single service forces SES to operate at multiple levels of abstraction simultaneously.

At the top level, customer service requirements are orbit-agnostic. A cruise line buying broadband connectivity wants a guaranteed throughput envelope, a maximum acceptable latency, and a service availability commitment expressed as a percentage. That customer does not care which orbital regime is serving them at any given moment. The service-level agreement (SLA) is the system boundary.

Below that, SES must decompose those SLAs into requirements that are orbit-specific. The latency requirement is achievable via MEO or GEO, but with entirely different budgets. A 200 ms latency target is trivially achievable with O3b mPOWER. It is physically impossible to meet with GEO. That means the requirements decomposition is not just a matter of allocating performance — it is a matter of knowing which architecture segments can bear which requirements, and routing that decomposition accordingly.

This is classic system-of-systems (SoS) engineering, with a complication: the constituent systems were not designed to be integrated. The GEO fleet predates the O3b acquisition (SES acquired O3b Networks in 2016). The interface definitions, operational concepts, and ground system architectures were developed independently. The integration work is retroactive, which is almost always harder than designing for integration from the start.

Ground System Architecture as the Integration Seam

The ground network — teleports, gateway earth stations, network operations centers, and the software that ties them together — is where the two orbital regimes actually meet. It is also where the requirements complexity is highest.

A GEO gateway is designed for a static link budget. You know the satellite location, you know the beam center, and you design the earth station to close that link under defined atmospheric conditions. The equipment choices, antenna sizing, and frequency coordination are all derived from requirements that change slowly, if at all.

An O3b mPOWER gateway faces a different set of requirements entirely. The constellation moves. Beams are reassigned dynamically. The gateway must track multiple satellites simultaneously using electronically steered or mechanically steered antennas, hand off traffic between satellites as they traverse the sky, and coordinate with a beam management system that is making reconfiguration decisions in near real time. The ground system requirements that flow down from “support an O3b mPOWER service node” are fundamentally dynamic, and the verification evidence for those requirements is not a static link budget calculation — it is a set of performance bounds demonstrated across operational scenarios.

SES has built a new generation of gateway infrastructure to support mPOWER, including ground systems in multiple geographic locations designed around the MEO operational concept. But those gateways must coexist with — and in some cases share infrastructure with — the GEO teleport network. The interface between those two infrastructure layers is a requirements boundary that has to be explicitly managed. What does the GEO network guarantee to the MEO network in terms of backhaul capacity? How is traffic prioritized when congestion occurs? What are the failure modes, and which system-level requirements govern graceful degradation?

These are not rhetorical questions. They are the kinds of interface control document (ICD) problems that systems engineers live in.

Requirements Across Generational Technology

Fleet generational diversity makes the requirements management challenge chronic rather than acute. SES operates satellites built across roughly three decades. The older GEO satellites have fixed transponder capacity measured in conventional bandwidth units — MHz of C-band or Ku-band spectrum. The requirements language used to specify, verify, and operate those satellites is analog-era vocabulary: EIRP, G/T, transponder bandwidth, saturated power.

The mPOWER satellites are specified differently. Their capacity is expressed in terms of reconfigurable beam throughput, software-defined power allocation, and digital processing resources. A requirement for a mPOWER satellite might concern how quickly beam assignments can be reconfigured, or what the throughput floor is per beam under specified loading conditions — concepts that simply do not map to the legacy GEO requirement taxonomy.

This means that a single requirements management system, if SES attempts to use one, must support two incompatible ontologies simultaneously. The alternative — separate requirement databases for GEO and MEO — makes the integration-level requirements harder to manage, because the links between a customer SLA and the satellite-level specifications that support it have to be traced across a gap in the data model.

This is a real operational problem. When a customer reports a service degradation, the operations team must diagnose whether the issue originates in the GEO segment, the MEO segment, or the ground network integration layer. That diagnostic process is only tractable if the requirements traceability is intact — if you can walk from the service-level performance commitment down through the architecture to the specific satellite and ground system behaviors that are supposed to support it.

Operational Continuity Across Orbits

One of the more interesting systems engineering challenges SES faces is defining what “continuous service” means in a multi-orbit context.

For a GEO-only operator, service continuity is primarily about weather margin and spacecraft anomaly response. The satellite does not move relative to the customer terminal. Continuity requirements are defined in terms of link margin, redundancy, and switchover time.

For a MEO-only operator, continuity involves satellite handover — as one satellite sets below a minimum elevation angle, traffic is handed off to the next satellite rising. This is understood and managed; it is analogous to cellular handover, with defined requirements for handover latency, packet loss during transition, and the minimum satellite visibility geometry that triggers a handover event.

For a multi-orbit operator offering a unified service, continuity gets more complex. SES can, in principle, route a customer terminal via MEO under normal conditions and fall back to GEO if the MEO constellation has a coverage gap or capacity constraint. That “intelligent routing” capability requires real-time awareness of both network states, a policy engine that applies service-level rules, and terminal hardware capable of operating on both frequency bands and both link geometries. Each of those elements has requirements, and those requirements have to be traceable back to the original SLA commitment.

Defining the requirements for that fallback behavior is harder than it sounds. What latency should the customer expect during a GEO fallback period? How is that documented in the SLA? Who owns the verification? How is the failure mode that triggered the fallback categorized for availability accounting?

These are requirements architecture questions as much as they are engineering questions.

What the Industry Is Watching

SES is not the only operator attempting a multi-orbit strategy. Intelsat, Eutelsat (following the OneWeb merger), and Telesat all have similar ambitions. But SES is the furthest along in having a commercially operational, multi-orbit, managed service built on two distinct constellation architectures.

The systems engineering decisions SES makes — and the operational experience they accumulate — will inform how the next generation of operators designs their requirements frameworks. If unified service delivery across orbital regimes is genuinely tractable, it will require new tools, new requirement taxonomies, and new approaches to traceability that bridge the gap between legacy satellite operational concepts and software-defined constellation management.

The satellite industry is watching not because SES is unique in wanting to solve this problem, but because they are unique in being far enough along that the problem is real and operational rather than theoretical. The failures will be instructive. So will the solutions.

Honest Assessment

SES’s multi-orbit strategy is technically credible in a way that many operator announcements are not. They own both constellations. They operate the ground infrastructure. They have actual customers with actual service agreements spanning both orbital regimes. The systems engineering challenge is real but it is not speculative.

The genuine difficulty is organizational as much as technical. GEO operations and MEO operations evolved as separate disciplines within SES, with separate tools, separate teams, and separate operational cultures. Integrating those into a coherent system-of-systems engineering function requires not just better tooling but a shared requirements language, shared traceability models, and shared definitions of what “compliant” looks like across two architectures that were never designed to interoperate.

That integration work is the hardest kind — it has no clean finish line, it accumulates debt when skipped, and it is invisible to customers until something goes wrong. For a satellite operator selling multi-year managed service contracts, the cost of getting it wrong is not a software patch. It is an availability breach on a maritime or government SLA backed by contractual penalties.

SES has the assets, the customer base, and the technical staff to solve this. Whether their requirements management and systems engineering practices are mature enough to support a genuinely integrated multi-orbit architecture is the question the industry is watching.