End-to-End Satellite System Architecture

This page is a system-boundary map: it follows traffic from an application at the remote site, across the satellite access network, to a terrestrial application or private network. Its purpose is to identify interfaces, ownership, and measurement points—not to prescribe one vendor design.

An end-to-end design must describe more than the radio path. It must also separate user traffic from access-control signalling and operational management, then show where security, routing, service policy, and fault responsibility change hands.

The exact implementation depends on the payload, orbit, topology, waveform, access method, service contract, and regulatory environment. The architecture below is therefore a reference model to adapt through an interface control document for the actual network.

Scope note: Organization fact check updated 26 August 2026 against the primary references below. This is not a named expert approval. Topology, payload, waveform, security, regulatory, and service-demarcation details must be confirmed for the actual network.

• Application and customer network — endpoints, LAN, security policy, and customer edge
• User terminal — service demarcation, modem/baseband, RF chain, antenna, and mobility functions where applicable
• Space segment — transparent or regenerative payload, beams, and orbit-dependent connectivity
• Gateway and service edge — gateway RF/baseband plus the handoff to routed terrestrial services
• Control and management — access control, resource assignment, configuration, telemetry, alarms, and service assurance

Reference Paths and Logical Planes

A typical user-plane path is: application endpoint → customer LAN or security edge → satellite terminal → uplink → satellite payload → downlink → gateway → terrestrial service edge → destination network or application. A mesh or regenerative system can use a different path, so the diagram for a real deployment must show every satellite and terrestrial hop instead of assuming a star network.

The forward link and return link describe traffic direction relative to the terminal; uplink and downlink describe the direction of a particular radio transmission. These terms are not interchangeable. A two-way service may also use different carriers, gateways, beams, or access methods in the two directions.

Keep three logical planes visible. The user plane carries customer traffic. The control plane handles functions such as terminal logon, synchronization, signalling, and resource assignment. The management plane handles configuration, inventory, telemetry, alarms, service-level policy, and reporting. The functions may share equipment, but their roles and failure effects should remain explicit.

Space-Segment Boundary

The space-segment boundary starts at the satellite receive antenna and ends at the satellite transmit antenna for the communications path. What happens between those points depends on payload design; “the satellite relays the signal” is not a sufficient interface description.

• Transparent payload — transfers the received radio channel toward an output beam using payload-specific filtering, frequency conversion, amplification, switching, or digital transparent processing. It does not terminate the full user service merely because it processes the waveform.
• Regenerative payload — may demodulate, decode, route, switch, or regenerate selected protocol layers onboard. The ground architecture must state which functions move into the spacecraft and how control, addressing, and fault isolation change.
• Beam connectivity — defines which terminal and gateway coverage areas can communicate at a given time. Frequency reuse, feeder links, beam switching, and gateway diversity are design inputs, not universal features.

Orbit-Dependent Functions

• A geostationary access path can keep a stable serving-spacecraft geometry, while a non-geostationary system can require satellite, beam, gateway, or route handover. Tracking and handover responsibilities must be assigned to the terminal, network control system, payload, or a combination of them.
• Inter-satellite links are an architecture option, not a defining requirement for every non-geostationary system. Traffic may exit through a visible gateway, traverse one or more onboard links, or use a hybrid path defined by the operator.
• Orbit classification alone does not specify application latency, capacity, availability, or routing. Those results depend on the actual path, scheduler, link adaptation, queuing, terrestrial route, and service policy.

Gateway, Service Edge, and Operations

“Ground segment” is too broad to serve as a single handoff. Separate the gateway radio site, gateway baseband, traffic or service gateway, network control, network management, terrestrial carrier, and customer or application network—even if several functions are housed at one teleport.

ETSI’s DVB-RCS2 reference architecture distinguishes user-plane gateway functions from Network Control Centre (NCC) and Network Management Centre (NMC) functions. That distinction is useful beyond one waveform family because it prevents a traffic outage, access-control fault, and management visibility loss from being treated as the same event.

• Gateway RF and baseband — terminates the feeder or service radio link at defined RF, intermediate-frequency, waveform, and frame reference points.
• Traffic gateway or service edge — maps satellite-side subscriber traffic to routing, security, addressing, QoS, private-network, cloud, or internet services. Record the exact demarcation and who owns it.
• NCC or equivalent control function — coordinates the access procedures, timing, signalling, and resource assignment required by the selected system.
• NMC, NOC, and service assurance — manage configuration, inventory, alarms, performance, and service policy. Spacecraft telemetry, tracking, and command is a separate operator responsibility unless the system documentation explicitly combines it.

Terminal and Customer-Site Boundary

At the remote site, distinguish the customer’s application and LAN from the satellite service demarcation. Otherwise a local switching, DNS, security, power, or cabling fault can be misclassified as a satellite-link fault.

The terminal implementation is service-specific. Fixed, transportable, land-mobile, maritime, and aeronautical terminals can assign pointing, acquisition, blockage detection, and mobility control differently, so an interface inventory is more reliable than a generic equipment-size template.

• Customer edge — application endpoints, local routing, firewall or encryption functions, and the agreed service handoff.
• Modem and baseband — translate between customer traffic and the waveform, framing, coding, access, and control procedures selected for the network.
• RF chain and antenna — establish transmit and receive reference planes, frequency conversion, gain and loss budgets, polarization, pointing, and emissions constraints.
• Mobility and installation functions — may include position, heading, blockage, tracking, handover, radome, and platform-integration interfaces. Include only those present in the actual terminal.

Terrestrial Network and Service Functions

The satellite access network is only one portion of the application path. The architecture must continue through terrestrial backhaul, routing domains, security boundaries, DNS or other dependencies, cloud or data-centre ingress, and the destination application.

Optional middleboxes deserve explicit treatment. A performance-enhancing proxy (PEP), for example, can be placed at different layers and may alter transparency or end-to-end semantics. RFC 3135 treats those consequences as design considerations; a PEP should not be drawn as a harmless generic accelerator.

• Routing and addressing — document route ownership, address translation, private-network or internet breakout, return-path symmetry requirements, and failover behaviour.
• Security — identify encryption endpoints, firewall policy, identity, key management, logging, and any device that must inspect or transform traffic.
• Service policy — define classification, QoS, shaping, admission, scheduler, and service-level enforcement at their actual reference points.
• Observability — correlate terminal, gateway, control, management, terrestrial, and application measurements using synchronized time and a common service identifier.

Packet Walk: Remote LAN to Application

1. An application creates a packet. The customer LAN supplies addressing, local routing, and security policy before the packet reaches the contracted service demarcation.
2. The terminal classifies the traffic and maps it into the configured satellite service. Its modem/baseband and RF chain create the assigned transmission; control-plane state determines whether and when the terminal may transmit.
3. The payload transfers or regenerates the signal according to its design and connects it toward the selected destination beam, gateway, terminal, or onboard route.
4. At the gateway, RF and baseband functions recover the satellite-side traffic. The service edge then applies the documented routing, security, QoS, and subscriber policy before the terrestrial handoff.
5. Terrestrial carriers and application infrastructure carry the packet to the destination. End-to-end monitoring must include this portion; a healthy satellite link does not prove that the application path is healthy.
6. The response follows the configured return path, which need not mirror every device or resource in the forward direction. Acceptance tests therefore name both directional paths and their measurement endpoints.

Architecture Definition and Acceptance Checklist

Create a system context diagram plus an interface control document. For every boundary, record the protocol or waveform, physical or logical reference point, addressing and security assumptions, capacity or timing dependency, configuration owner, monitoring source, alarm route, and change authority.

Build an ownership matrix for the customer, terminal installer, satellite network operator, payload or constellation operator, teleport, terrestrial carrier, managed-service provider, cloud or application team, and regulator. One company may hold several roles, but the responsibilities still need separate names.

Define acceptance tests at the customer handoff, terminal, radio link, gateway service edge, terrestrial handoff, and application. State whether a metric is one-way, round-trip, user-plane, control-plane, or management-plane and which traffic, load, weather, mobility, and failover conditions apply.

Finally, map failure domains and degraded modes: local site, terminal, beam or payload, gateway, control system, management visibility, terrestrial backhaul, security dependency, and application. The recovery design should identify detection, decision, switchover, rollback, and evidence ownership.

What “End to End” Must Prove

An end-to-end architecture is complete only when each user, control, and management path has defined endpoints; every interface has an owner; every service objective has a measurement point; and every important failure has a detection and recovery responsibility.

The reference model intentionally avoids universal antenna sizes, orbit latency promises, capacity figures, and vendor examples. Those values belong in the deployment design and must be supported by the selected operator, equipment, link budget, regulatory authorization, terrestrial route, and acceptance conditions.