Ground Station Central Aggregator Responsibilities
Responsibilities, services, and data normalization expectations for the central aggregator server.
1. Central Aggregator Responsibilities
The central user-facing application must be backed by a real backend platform, not only a frontend.
1.1 Node coordination
The central server should:
- register antenna nodes
- track node online or offline state
- push configuration to nodes
- request mode changes
- select preferred source streams for downstream routing and operator display
- decode the chosen source stream centrally unless the deployment explicitly enables edge pre-decode
- collect health and metrics
Node outputs may be raw IQ samples, binary telemetry frames, typed JSON events, or metrics/status streams depending on node configuration. The central server normalizes those outputs and decides which stream is preferred for operator display.
1.2 Telemetry normalization
The central server should turn selected node outputs into consistent mission contracts such as:
- mission timeline events
- vehicle telemetry samples
- signal health metrics
- antenna and beam status
- capture or replay metadata
1.3 State and mission services
The central server should own:
- mission countdown and state
- mission metadata and launch profile
- operator audit trail
- replay sessions
- configuration history
1.4 Why this middle layer matters
Without the central layer, the frontend would need to understand SDR node details, beam math, protocol variants, and low-level health models. That would make the UI fragile and couple it directly to hardware choices.
Source selection is a routing decision at the stream level. The central server should pick the winner before decode; it can still promote one source, demote another, or switch streams without re-decoding raw RF on the server. Edge pre-decode remains an opt-in deployment choice, not the default for all candidates.
The node is not told which stream the central server prefers; it only emits the formats it has been configured to publish.
2. Control Plane and Data Plane
The design should preserve control-plane and data-plane separation across the full system.
2.1 Control plane
The control plane includes:
- radio configuration
- beam mode and pointing requests
- tracking mode changes
- frame and protocol selection
- node start, stop, arm, standby, or record commands
- calibration requests
Control-plane messages are low-rate, stateful, and auditable.
2.2 Data plane
The data plane includes:
- decoded telemetry
- encoded binary frames
- signal metrics
- node health telemetry
- event logs
- optional IQ snapshots or reduced captures
Data-plane flows are continuous, time-tagged, and fan out to multiple consumers.
2.3 Transport split
Recommended transport use:
| Flow | Recommended transport |
|---|---|
| Node control | HTTPS or gRPC |
| Node to central telemetry and metrics | WebSocket, ZeroMQ bridge, or reliable event transport |
| Central to frontend live updates | WebSocket |
| High-rate binary frames or captures | UDP, TCP, or object storage ingestion depending on retention need |
2.4 TM over IP policy
All node-to-central and central-to-client communications should run over IP networks.
Policy rules:
- telemetry transport, control commands, and status all use IP-based protocols
- no dependency on direct serial point-to-point in the production data path
- serial hardware interfaces can exist inside the node only, hidden behind IP-facing node services
- all packets and messages must be time-tagged and traceable across node and central hops
Next: See Shared APIs & Contracts for detailed endpoint and data contract specifications.