Satellite Network Topology: Star, Mesh, and Hybrid

Satellite network topology describes the logical path that user traffic follows between terminals, gateways, onboard processors, inter-satellite links, and terrestrial networks. The practical choices are commonly called star, mesh, and hybrid, but those labels do not by themselves specify the waveform, access method, orbit, beam layout, or failure protection.

For a centralized traffic pattern, star usually sends a remote-to-gateway packet over one satellite hop. The same star network sends remote-to-remote traffic through the gateway over two satellite hops. A mesh-capable path can carry that remote-to-remote packet in one hop if the terminals, satellite payload, beam connectivity, resource control, and link budgets all support it. Hybrid topology applies different paths to different traffic classes or site pairs.

The correct choice comes from a measured traffic matrix and an end-to-end path design, not a universal site-count threshold.

VSAT Network Architecture | Ground Segment | Satellite Latency

Star vs Mesh vs Hybrid: Fast Comparison

This is a functional comparison, not a promise about cost or scale. Product architecture, licensing, beam plan, redundancy, and service model determine the actual result.

Separate the Five Architecture Layers

Topology reviews fail when several independent design choices are collapsed into one label.

1. Logical service topology

This is the user-visible path:

• Star: remote traffic is anchored at a hub or gateway.
• Mesh: supported terminal pairs can exchange traffic without an intermediate ground hub transit.
• Hybrid: both paths exist, and policy selects between them.

2. Waveform and access method

DVB-S2/S2X, MF-TDMA, TDMA, SCPC, and demand assignment describe physical-layer or resource-access behavior. They do not uniquely determine the logical topology. A centrally scheduled return link can serve a star network, while a mesh overlay can also use centralized signaling and dynamic resource assignment.

The current ETSI DVB-RCS2 system specification covers transparent star, transparent mesh overlay, regenerative mesh, and NGSO reference architectures within one system family. Therefore, identifying a carrier as DVB-S2X or MF-TDMA is not enough to identify its end-to-end topology.

3. Satellite payload

• A transparent payload forwards or frequency-translates the signal without terminating the user-layer traffic. Hub routing normally occurs on the ground. A transparent mesh overlay is still possible when the payload connects the required beams and terminals can receive the peer waveform.
• A regenerative payload demodulates/decodes and regenerates traffic, and may switch or route at layer 2 or 3 onboard. It can create a single-hop path between beams without a ground gateway transit.

ETSI Clause 4.1 explicitly separates those two reference architectures. “Mesh” does not automatically mean onboard routing, and “transparent” does not automatically prohibit every single-hop mesh arrangement.

4. Beam and gateway topology

Record the user beam, feeder beam, serving gateway, gateway-to-core path, and any beam-to-beam connectivity. A spot-beam satellite may use ground switching, a digital transparent processor, a regenerative onboard processor, or a combination. The phrase HTS network does not reveal which path is used.

5. Orbit and routing topology

GEO, MEO, and LEO describe orbital regimes, not logical service topology. An NGSO system may use transparent or regenerative payloads, one satellite or multiple satellites per path, inter-satellite links (ISLs), and changing user/gateway associations. Document those layers separately.

Count Satellite Hops Correctly

In this guide, one satellite hop means one ground-station-to-satellite-to-ground-station route. This matches the definition in IETF RFC 2488 Section 2.

Star: remote to gateway

Remote A -> satellite -> gateway
             one satellite hop

If the application endpoint or terrestrial handoff is at that gateway, the satellite part of the path is one hop.

Star: remote to remote through the gateway

Remote A -> satellite -> gateway -> satellite -> Remote B
             hop 1                    hop 2

The packet crosses two satellite hops in one direction. A request and reply cross four satellite hops in total.

Direct mesh: remote to remote

Remote A -> satellite -> Remote B
             one satellite hop

This path is valid only when the two terminal links close, compatible resources are assigned, the payload connects the relevant coverage, and Remote B can receive the transmitted waveform.

Do not count the uplink and downlink of one ground-satellite-ground route as two “hops.” They are two radio legs within one satellite hop.

GEO Propagation Example

RFC 2488 reports 239.6 ms for an ideal GEO ground-satellite-ground hop and 279.0 ms near the edge of coverage. These are one-way propagation values for one satellite hop, not complete application latency.

Using those documented boundaries:

The two-hop values are simple multiples:

two-hop one-way floor = 2 x one-hop one-way floor
                       = 479.2 to 558.0 ms

two-hop RTT floor     = 2 x two-hop one-way floor
                       = 958.4 to 1,116.0 ms

Real measurements also include serialization, framing, scheduling, modem processing, gateway processing, queueing, terrestrial backhaul, application processing, and possibly acceleration or tunneling. Slant range can differ for each station. Use the detailed satellite latency calculation when comparing a measured service to these propagation floors.

Star Topology

In a logical star, the hub or gateway anchors user traffic, control, or both. A common interactive design has a shared forward carrier from the hub and scheduled return capacity from remotes, but the exact waveform and access method are implementation choices.

Where star is a strong fit

• Most traffic terminates at a central data center, internet gateway, cloud on-ramp, or network service edge.
• Security inspection, WAN acceleration, policy, logging, and addressing are intentionally centralized.
• Shared forward/return capacity can statistically multiplex bursty demand across many sites.
• Operational teams want one controlled service insertion and troubleshooting point.

What must be budgeted

• Aggregate forward and return demand by time interval, not only contracted peak rates.
• Gateway-to-core capacity and queueing, which can be the bottleneck even when the satellite carrier is not full.
• Two satellite hops for remote-to-remote traffic.
• Common dependencies: teleport, antenna/RF chain, baseband cluster, scheduler, authentication, power, terrestrial backhaul, DNS, and management plane.

A star has a central functional dependency, but it is not automatically a single physical point of failure. Redundant antennas, geographically diverse gateways, clustered baseband systems, dual backhaul, and tested state replication can protect it. Conversely, two gateways are not meaningful redundancy if they share the same power, feeder beam, control plane, or terrestrial path.

Mesh Topology

Mesh means that supported endpoints can use a single satellite hop rather than transiting a ground hub in the user plane. It does not require every terminal to maintain a permanent carrier to every other terminal.

Transparent mesh overlay

In the ETSI DVB-RCS2 transparent reference architecture, mesh-overlay terminals can support both the conventional star/double-hop path and a single-hop mesh path. ETSI notes that these terminals are more complex and include additional demodulation capability for applicable peer waveforms.

The control and management plane may remain centralized. Logical peer-to-peer user traffic does not imply distributed resource control.

Regenerative mesh

A regenerative payload can demodulate, switch or route, and regenerate the downlink onboard. In the ETSI reference model, regenerative mesh terminals receive a single-hop path while management and network-control functions remain defined separately.

Pair count is not a site limit

For N sites, an undirected full-mesh graph has:

possible site pairs = N(N - 1) / 2

Thirty sites therefore have 30 x 29 / 2 = 435 possible pairs. That number does not mean 435 permanent carriers, and it does not create a universal 20- or 30-site mesh limit. Dynamic resource assignment, partial mesh policies, traffic concentration, simultaneous-session count, terminal receive capability, control-plane scale, and link budgets determine practical scale.

Mesh acceptance conditions

• The complete uplink and downlink close at the required MODCOD and availability, including source EIRP, satellite receive G/T, payload/transponder behavior, satellite downlink EIRP, and destination G/T.
• Beam and payload connectivity support the source/destination pair.
• The receiving terminal supports the peer waveform, frequency plan, polarization, timing, and spectrum sense.
• Dynamic assignment delay, teardown behavior, and idle-time policy meet the application requirement using product test data.
• Encryption, authentication, lawful intercept, monitoring, and QoS still work when traffic bypasses the central user-plane gateway.
• A star fallback path is defined if the direct resource, peer receiver, or mesh-control function is unavailable.

There is no defensible generic DAMA setup delay. Measure it on the selected platform under the intended resource state and include it in first-packet latency.

Hybrid Topology

A hybrid network keeps a star path and enables a direct or regenerated mesh path for selected site pairs or traffic classes. The design goal is not “mesh for all real-time traffic.” It is to move only the flows whose latency or capacity benefit exceeds the additional terminal, spectrum, control, and operations cost.

Possible steering keys include:

• source and destination site;
• application or DSCP class;
• SLA and maximum path delay;
• direct-path availability and link margin;
• beam/payload compatibility;
• security service-chain requirement; and
• star-path congestion or maintenance state.

Define what happens to an existing flow when the preferred path disappears. Reordering, asymmetric routing, NAT state, encryption tunnels, TCP sessions, QoS counters, and monitoring can all behave differently during a path change. A hybrid topology is complete only when its failback behavior is tested.

Worked Traffic-Matrix Example

Consider a GEO enterprise network with these declared busy-hour traffic shares:

Use satellite-hop units per delivered bit as a screening metric:

weighted hops = sum(traffic share x satellite hops)

Candidate A: all-star

weighted hops = 0.85 x 1 + 0.10 x 2 + 0.05 x 2
              = 1.15 satellite-hop units per delivered bit

Central traffic uses one hop; all inter-site traffic uses two.

Candidate B: selective hybrid

Route only the 5% operations-voice class over a supported direct mesh path:

weighted hops = 0.85 x 1 + 0.10 x 2 + 0.05 x 1
              = 1.10 satellite-hop units per delivered bit

The screening metric falls by:

(1.15 - 1.10) / 1.15 = 4.35%

The larger benefit is latency for the selected voice flows: their GEO propagation floor changes from the two-hop range to the one-hop range in the earlier table. This example does not prove a 4.35% bandwidth saving. Forward and return carriers can occupy different spectrum, MODCODs can differ by site, frequency reuse can separate beams, and signaling/guard overhead must be counted. It only identifies where a detailed carrier plan and link budget should focus.

The decision is therefore conditional: select hybrid only if the three voice sites close the direct links, first-packet setup meets the voice requirement, security remains valid, and the measured benefit justifies the overlay.

HTS and Multi-Beam Networks

Do not assume “one star per spot beam.” Draw the actual route for each service pair:

user terminal
  -> user beam
  -> transparent or regenerative payload
  -> feeder beam / gateway, another user beam, or ISL
  -> terrestrial PoP or destination terminal

ETSI's transparent reference architecture allows digital transparent processing to provide multi-beam connectivity. Its regenerative reference architecture allows onboard layer-2 or layer-3 switching. Those two implementations can produce different hop counts and gateway dependencies with the same spot-beam coverage map.

For each beam pair, verify:

• whether connectivity is bent-pipe, digitally cross-connected, or regenerated;
• whether traffic must descend to a gateway before entering another beam;
• which gateway and terrestrial route are selected;
• whether feeder-link diversity changes the path during a fade; and
• whether capacity is isolated per beam or pooled by the scheduler.

See HTS Spot Beams and Beamforming for coverage and reuse concepts. A beam diagram alone is not a logical topology diagram.

NGSO Constellations and ISLs

NGSO systems add time to the topology model. The serving satellite, serving gateway, visible links, and end-to-end route can change while a session is active.

ETSI's NGSO reference scenario allows a connection between ground entities to use one satellite or multiple satellites connected by ISLs, and notes that a terminal is served by different satellites over time. ESA's ROUTLEO project treats frequent topology changes and link/node failures as routing requirements. These sources support a dynamic model, not a claim that every constellation has the same number or pattern of ISLs.

Model at least four separate graphs:

1. terminal-to-satellite user links;
2. satellite-to-gateway feeder links;
3. satellite-to-satellite links, if present; and
4. gateway/PoP-to-terrestrial-destination paths.

ISLs do not automatically reduce latency or gateway count. The result depends on link availability, route length, onboard switching, ground-station placement, terrestrial backhaul, queueing, and handover policy. ESA's HydRON architecture is one documented example that combines optical ISLs, onboard optical routing, optical ground stations, and terrestrial-network integration; it should not be generalized into a fixed architecture for all LEO systems.

For acceptance, test steady-state latency, handover interruption, packet loss, reordering, route asymmetry, gateway diversity, and recovery from one planned link/node failure.

Topology Decision Worksheet

1. Build the traffic matrix

For every important source/destination pair, record busy-hour mean, 95th percentile, burst size, directionality, session duration, multicast behavior, and growth forecast. Separate central, inter-site, internet, cloud, and management traffic.

2. Set path-specific latency objectives

State one-way delay, RTT, jitter, first-packet delay, and interruption tolerance separately. Do not use one generic “satellite latency” target. Map each objective to a route and hop count.

3. Close every relevant link

A hub downlink closing to a small remote does not prove that another small remote can transmit a carrier that the peer can receive. Calculate the direct uplink/downlink combination, rain condition, interference, availability, and required MODCOD using the satellite link budget guide.

4. Account for capacity by resource pool

Separate forward carrier, return channels, direct mesh allocations, feeder links, gateway backhaul, beam reuse, control/signaling, guard bands, and failover reserve. Do not convert the weighted-hop screening metric directly into MHz.

5. Map fault domains

List satellite/payload, beam, gateway, antenna/RF, baseband, scheduler/NCC, management, authentication, power, fiber/backhaul, cloud on-ramp, and peer-terminal dependencies. Mark which ones are shared by nominal and backup paths.

6. Verify service insertion

Show where encryption, firewalling, acceleration, QoS, lawful intercept, logging, DNS, and address translation occur on each path. Direct mesh traffic may bypass functions that existed at the star gateway.

7. Run a controlled pilot

Measure representative central and inter-site flows in clear sky and fade conditions. Exercise resource exhaustion, gateway failover, mesh setup/teardown, path fallback, and restoration. Acceptance evidence should include route traces, modem counters, scheduler state, spectrum evidence, application metrics, and timestamps.

Common Design Errors

Frequently Asked Questions

What is satellite network topology?

It is the logical arrangement of user-traffic paths and the network functions that select, control, and protect those paths. Star sends traffic through a hub/gateway, mesh permits supported direct terminal paths, and hybrid uses both.

Why can star remote-to-remote traffic take two satellite hops?

Remote A first sends the packet through the satellite to the hub. After routing, the hub sends it through the satellite again to Remote B. That is two ground-satellite-ground routes in one direction.

Does mesh always halve latency?

It halves the GEO satellite propagation component for a remote-to-remote path when a two-hop star route is replaced by a one-hop direct route. Total latency also includes setup, scheduling, processing, queueing, and terrestrial segments, so measured improvement must be tested.

Does mesh require distributed control?

No. User-plane traffic can be direct while network control, resource assignment, and management remain centralized. The ETSI DVB-RCS2 reference architectures retain defined NCC/NMC roles.

Is there a maximum number of mesh terminals?

There is no universal limit. The practical boundary depends on simultaneous demand, partial/full mesh policy, link budgets, terminal receivers, resource pools, signaling implementation, operations, and the selected platform's tested limits.

Is DAMA the same as mesh?

No. Demand assignment is a resource-allocation method. It can support dynamic mesh connections, but dynamic scheduling is also used in hub-based return channels. Topology describes the traffic path; DAMA describes how capacity is assigned.

Is an HTS spot beam a star topology?

Not by itself. Spot beam describes coverage and frequency reuse. The payload and gateway design determine whether traffic is bent-pipe to a gateway, cross-connected between beams, switched onboard, or routed by another path.

Do ISLs make an NGSO constellation a mesh service?

ISLs create connections within the space segment, but the user service may still be gateway-anchored. Classify the user, feeder, ISL, and terrestrial graphs separately before labeling the end-to-end service.

Key Takeaways

• Count a ground-satellite-ground route as one satellite hop.
• Separate logical topology from waveform/access, payload, beam/gateway, and orbit.
• Use a traffic matrix and path-specific SLA instead of site-count rules.
• Verify the link budget and receive capability of every proposed direct mesh path.
• Treat N(N-1)/2 as possible pairs, not permanent carriers or a hard scale limit.
• Design and test user, control, management, security, and failover paths together.
• For HTS and NGSO systems, model the actual payload, gateway, ISL, and terrestrial route rather than inferring topology from the orbit or coverage map.

Related guides: VSAT Network Architecture · Ground Segment · Satellite Terminal Architecture · Satellite Latency · HTS Spot Beams · QoS Over Satellite