PAGE CONTENTS
Objectives
The first objective of ORQOS is to develop an innovative software platform encompassing the functionalities of the Network Operations Center (NOC). This software platform is responsible for the orchestration of satellite telecommunication networks, through the scheduling of RF beams and optical links, as well as through the engineering of traffic across the constellation.
The second objective of ORQOS is to strengthen the existing Aerospacelab Mission Control Software (MCS) to ensure that it can operate at constellation scale. This objective implies the development of new operations automation features, the improvement of the observability capabilities, as well as an overhaul of the flight dynamics modules currently in use.
A third objective of ORQOS is to integrate the different components of this Telecom Ground Segment, by building a bridge between the MCS and the NOC, as well as by prototyping the interfaces between the NOC and third-party ground segment software.
Benefits
Compared to standard network orchestration solutions, often sold as standalone software that customers must integrate into their Ground Segment, ORQOS is designed as an integrated stack from the start: the Mission Control Software and the Network Operations Center are built, tested and validated together. For constellations that use Aerospacelab platforms and payload units, the integration can go even deeper: the interfaces to the Space Segment can be implemented and tested as part of the same Ground Segment development activities.
The main advantage of this integrated approach is that orchestration decisions draw on actual platform and payload telemetry, rather than network state alone, enabling predictive, policy-aware planning that anticipates inventory changes, planned outages, and constellation dynamics ahead of time.
Second, this integration also gives customers a single point of accountability across the mission, rather than assembling integrations across several vendors.
Another key strength of ORQOS is its design flexibility: both the NOC and MCS are built around a mission-agnostic core, with multiple extension points, both in the MCS and in the NOC.
Finally, ORQOS is a 100% European Telecom Ground Segment offering, which matters to institutional and defense customers who need sovereign control over critical infrastructure.
Features
The main ORQOS NOC features are the following:
• Beam and link assignment: RF beam, feeder link, and optical inter-satellite link assignment, ensuring desired coverage, efficient gateway connections, and inter-satellite connectivity.
• Traffic engineering: efficient end-to-end path computation across the constellation, enforcing QoS targets and rebalancing paths as links come and go.
• Inventory management: continuous tracking of constellation topology, payload inventory, and traffic state, establishing the NOC as the network side’s authoritative source.
• Spectrum management: frequency band allocation, keeping usage within the operator’s ITU filing and coordination agreements.
• Northbound and Southbound APIs: interfaces with third-party network software and element management systems, keeping mission-specific concerns at the NOC’s periphery.
On the MCS side, the main features brought by ORQOS are:
• Automation: automated operations workflows, enabling operators to design, plan, and supervise fleet-level execution.
• Observability: dashboards, alerts, and telemetry aggregation, enabling mission specialists to monitor constellation state at all times.
• Flight dynamics: automated orbit determination and manoeuvre planning at scale, keeping critical activities under human-in-the-loop supervision.
Finally, a dedicated MCS-NOC interface keeps both systems synchronised: platform changes reach the NOC, and the MCS can fetch NOC telemetry relevant to platform operations.
Challenges
On the NOC side, the first key challenge is performance: choosing paths and planning links among 500 satellites while satisfying the mission constraints requires nontrivial optimisation work. The second key challenge is building a realistic end-to-end testbed for the platform.
On the MCS side, the first key challenge is linked to scale: turning the MCS into a constellation-ready platform capable of commanding up to 500 satellite platforms requires an overhaul of several major components. The second key challenge is the transition to a mostly automated operations management approach while guaranteeing a high level of reliability.
System Architecture
ORQOS’s architecture spans two distinct products built to operate together: the Network Operations Center (NOC) and the Mission Control Software (MCS).
The NOC is split into three services:
1. The engine, the system’s simulation and decision-making core. It holds an in-memory model of the constellation and computes beam, feeder, and traffic-engineering schedules.
2. The backend, responsible for mission configuration, data persistence, and external interfaces (a Northbound Interface for high-level applications and a Southbound Interface for telecom payloads and gateway equipment).
3. The frontend, a web interface allowing operators to monitor the constellation and configure the mission.
The MCS follows the same layered principle, split into three classes of components:
1. The core backend, a set of mission-agnostic microservices providing data management, processing, and automation APIs common to every mission.
2. Extension backends, mission-specific services handling specialised orchestration for a mission or group of missions.
3. Gatekeepers, the only path exposed to the outside world, enforcing security and actor-specific access.
Across both systems, external interfaces run over REST, while internal, event-driven exchanges run over an asynchronous messaging bus (Kafka or RabbitMQ), letting components process, retry, and scale independently.
Plan
ORQOS runs over two years: a Definition Phase, ending in Q3 2026 with a first Mid-Term Review, followed by a Technology Phase with the Final Review in Q2 2028. The project plan foresees three intermediate review gates to derisk the Technology Phase: the PDR confirms the preliminary design, a second Mid-Term review validates the NOC and MCS developments at TRL4, a Test Readiness Review confirms that both systems are ready for an end-to-end software-in-the-loop validation.
During each phase and sub-phase, the development process follows an agile methodology with short sprints, continuous integration and software demonstration at each gate.
Current Status
ORQOS has recently completed the Definition Phase, and is subsequently moving from the study stage to the initial implementation stage.
During the Definition Phase, a dedicated team was formed to conduct product and technology research, design the software, and refine its use cases and requirements.
Now that the Technology Phase is underway, the next objective is to demonstrate a basic but realistic prototype for the Preliminary Design Review.
