
Satellite Network Topology Explained: Star, Mesh, and Hybrid VSAT Architectures
Engineering guide to satellite network topology covering star hub-and-spoke, mesh peer-to-peer, and hybrid VSAT architectures, with design trade-offs for GEO, HTS, and LEO networks.
Introduction
The topology of a satellite network—how terminals, hubs, and satellites are interconnected—fundamentally shapes the network's latency, throughput, scalability, cost, and resilience. Choosing the wrong topology for a given application can mean the difference between a responsive enterprise WAN and one plagued by double-hop delays, or between a cost-effective broadcast distribution and an over-engineered mesh that no budget can sustain.
Satellite network topology is distinct from terrestrial networking topology because every link passes through a spacecraft 36,000 km away (for GEO) or through a fast-moving constellation (for LEO). This physical constraint makes topology selection a first-order engineering decision rather than a secondary configuration choice. The three foundational topologies—star, mesh, and hybrid—each address different traffic patterns, site counts, and service requirements.
This article provides an engineering-level treatment of satellite network topology, building on the fundamentals covered in VSAT Network Architecture. We examine how each topology works at the protocol and system level, quantify the latency and scaling trade-offs, and provide a decision framework for selecting the right architecture for modern GEO, HTS, and LEO deployments.
What Is Satellite Network Topology
Satellite network topology defines the logical communication paths between nodes in a satellite network—which stations can communicate with which, and how traffic is routed between them. It determines the number of satellite hops a packet must traverse, the role of central infrastructure, and the signaling protocols required to establish and maintain connections.
It is important to distinguish between physical topology (the actual RF links between antennas and satellites) and logical topology (the data flow paths as seen by applications and routing protocols). A network may have a single physical satellite providing transponder capacity, but the logical topology—star, mesh, or hybrid—is determined by how the ground segment equipment and protocols organize that capacity.
Topology is closely tied to the access protocol used on the satellite link. Star topologies typically employ centralized access schemes such as DVB-S2 on the outbound (hub-to-remote) and MF-TDMA or SCPC on the inbound (remote-to-hub). Mesh topologies require distributed access protocols like DAMA (Demand Assigned Multiple Access) that allow any terminal to establish a direct link with any other terminal. The access protocol determines bandwidth efficiency, latency characteristics, and the complexity of terminal equipment.
The topology also affects network management complexity, fault domains, and upgrade paths. A star topology centralizes intelligence and control at the hub, simplifying management but creating a single point of failure. A mesh topology distributes control across terminals, improving resilience but increasing per-terminal complexity and cost.
Star Topology: Hub-and-Spoke Architecture
The star topology (also called hub-and-spoke) is the most widely deployed satellite network architecture. A central hub station manages all communications, and every remote terminal communicates exclusively through the hub. No direct remote-to-remote communication exists—all traffic passes through the hub, even when the source and destination are both remote terminals.
How Star Topology Works
In a star network, the hub transmits a continuous outbound carrier (typically DVB-S2 or DVB-S2X) that all remote terminals receive. This carrier is a TDM (Time Division Multiplexed) stream containing addressed packets for each remote. On the inbound (return) path, remote terminals transmit to the hub using shared-capacity schemes—most commonly MF-TDMA (Multi-Frequency Time Division Multiple Access), where the hub assigns time slots and frequencies to each remote based on demand.
The hub performs all routing decisions. When Remote A sends data to Remote B, the traffic follows this path: Remote A → satellite (uplink) → hub (downlink) → hub processing and routing → hub (uplink) → satellite → Remote B (downlink). This creates a double hop through the satellite.
Latency Analysis
For a GEO satellite at 35,786 km altitude, the one-way propagation delay is approximately 270 ms (assuming an average slant range). A single hop (remote-to-hub or hub-to-remote) takes approximately 540 ms round-trip time (RTT). Remote-to-remote communication through the hub requires a double hop: approximately 1,080 ms RTT. This double-hop latency is the star topology's most significant engineering limitation.
For applications where all traffic flows between remotes and a central data center co-located with the hub, the single-hop latency (~540 ms RTT) applies—making star topology efficient for centralized architectures like branch office connectivity, point-of-sale, and SCADA/telemetry backhaul.
Scalability and Cost
Star topology scales efficiently with site count. Adding a new remote terminal requires only provisioning the terminal and configuring it on the hub—no changes to existing remotes are needed. The hub's bandwidth management algorithms handle capacity allocation dynamically. Networks of hundreds to thousands of remotes are common with star topology.
The cost structure favors star networks: remote terminals are simple (receive DVB-S2, transmit MF-TDMA), requiring only modest processing capability. The hub concentrates the expensive equipment—high-power transmitters, large antennas, and sophisticated network management systems—which is shared across all remotes. This makes the per-site cost low at the expense of higher hub infrastructure investment.
The hub's ground segment architecture and the adaptive coding and modulation capabilities of the outbound carrier are critical to star network performance—they determine the aggregate throughput available to all remotes and the efficiency with which that capacity is used under varying link conditions.
Limitations
- Double-hop latency for remote-to-remote traffic (~1,080 ms RTT over GEO).
- Hub as single point of failure — hub outage affects all remotes.
- Hub bandwidth bottleneck — all traffic must pass through the hub, which can become a throughput constraint as the network grows.
- Inefficient for peer-to-peer traffic patterns — if remotes primarily communicate with each other rather than with the hub, bandwidth is consumed twice per transaction.
Mesh Topology: Peer-to-Peer Communication
A mesh topology enables direct communication between any pair of terminals without routing through a central hub. Each terminal can both originate and terminate traffic to/from any other terminal in the network, creating single-hop paths between sites.
How Mesh Topology Works
In a full mesh network, every terminal has the capability to establish a direct carrier to any other terminal. When Terminal A needs to communicate with Terminal B, it requests a direct channel allocation, establishes a carrier on an assigned frequency/time slot, and transmits directly. Terminal B receives and demodulates the carrier. The traffic path is: Terminal A → satellite (uplink) → Terminal B (downlink)—a single hop.
Mesh networks typically use DAMA (Demand Assigned Multiple Access) protocols to manage channel allocation. A network control system (which may be a dedicated management station or distributed across terminals) maintains a signaling channel for connection requests. When a terminal needs to communicate with another, it sends a setup request on the signaling channel, receives a channel assignment (frequency, bandwidth, time slot), establishes the carrier, transmits data, and releases the channel when done.
The DAMA protocol is essential because a full mesh of N terminals would theoretically require N(N-1)/2 permanent links—which is impractical for even modest network sizes. DAMA allows channels to be established on demand, sharing the total satellite capacity among active connections.
Latency Analysis
The single-hop path gives mesh topology a significant latency advantage over star for terminal-to-terminal communication. Over GEO, the RTT for mesh traffic is approximately 540 ms—half the double-hop latency of star topology. For latency-sensitive applications like VoIP, video conferencing, and interactive data between remote sites, this 540 ms difference is operationally meaningful.
However, the DAMA channel setup process adds a call setup delay of typically 500 ms–2 seconds before the first data packet can flow. For bursty, short-lived connections, this setup overhead can negate the single-hop advantage. Mesh topology is most beneficial for sustained connections where the setup delay is amortized over a longer data transfer, as analyzed in Satellite Latency Comparison.
Scalability and Cost
Mesh topology has inherent scaling limitations. Each terminal must be capable of transmitting to and receiving from any other terminal, requiring more sophisticated (and expensive) modem equipment—typically SCPC-capable transceivers with DAMA functionality. The terminal cost is significantly higher than in a star network.
The practical limit for full mesh networks is approximately 20–30 sites. Beyond this, the signaling overhead for DAMA channel management, the number of potential connections (N(N-1)/2 grows quadratically), and the per-terminal equipment cost become prohibitive. For a 30-site mesh, there are 435 potential connections to manage.
The satellite bandwidth utilization in mesh networks can be less efficient than star networks because DAMA channel allocation involves guard bands and overhead for each connection, and bandwidth cannot be statistically multiplexed as aggressively as in a hub-controlled MF-TDMA scheme.
Limitations
- High per-terminal cost — each terminal needs SCPC/DAMA-capable equipment.
- Quadratic scaling — connection complexity grows as N(N-1)/2.
- DAMA setup delay — 0.5–2 seconds before data flows on a new connection.
- Less efficient bandwidth utilization — guard bands and per-connection overhead reduce spectral efficiency.
- Practical site limit ~20–30 — beyond this, the economics and management complexity favor star or hybrid.
Hybrid Topology
A hybrid topology combines star and mesh architectures within a single network, assigning each traffic type to the topology best suited for it. This approach captures the scalability and cost efficiency of star for bulk traffic while providing the low-latency single-hop paths of mesh for latency-sensitive applications.
Architecture Design
In a typical hybrid network, a hub station provides star-mode connectivity for the majority of traffic—internet access, file transfers, software updates, and centralized application traffic. Simultaneously, a subset of terminals (or all terminals with dual-mode capability) can establish mesh connections for latency-critical traffic—VoIP calls, video conferences, and real-time control sessions between remote sites.
The terminal equipment in a hybrid network must support both operating modes: DVB-S2 reception and MF-TDMA transmission for star operation, plus SCPC/DAMA for mesh operation. Modern VSAT platforms from major manufacturers (Hughes, Viasat, ST Engineering iDirect, Comtech) offer hybrid-capable modems that can dynamically switch between or simultaneously operate in both modes.
Traffic Steering
The hybrid topology's intelligence lies in its traffic steering logic—the rules that determine which traffic flows through the hub (star path) and which flows directly between terminals (mesh path). Steering decisions are typically based on:
- Application type — VoIP and video conferencing via mesh; web browsing and email via star.
- Destination — traffic to the internet or central data center via star; traffic to another remote site via mesh.
- QoS class — high-priority, latency-sensitive traffic via mesh; best-effort traffic via star, following QoS over satellite principles.
- Bandwidth availability — mesh channels allocated on demand; if mesh capacity is exhausted, overflow falls back to star.
Use Cases
Hybrid topology is the preferred architecture for enterprise networks where remote sites need both centralized connectivity (to headquarters and internet) and inter-site communication. Common deployments include:
- Energy and mining — Field sites communicate with headquarters via star, but safety and operational voice/video between sites uses mesh for lower latency.
- Government and military — Centralized data flows via star, tactical communications between deployed units via mesh.
- Maritime fleet operations — Shore-to-ship via star, ship-to-ship coordination via mesh.
- Telecom backhaul — Aggregated internet traffic via star to gateway, inter-exchange carrier traffic via mesh.
Topology in Modern HTS Networks
High-Throughput Satellite (HTS) systems with spot-beam architectures add a new dimension to topology design. Unlike traditional wide-beam satellites where all terminals share a single beam footprint, HTS satellites divide their coverage into dozens or hundreds of narrow spot beams, each served by a gateway ground station.
Gateway Distribution
In an HTS system, the star topology operates at two levels. At the beam level, terminals within a spot beam communicate through the gateway that serves that beam—a conventional star arrangement. At the system level, multiple gateways connect to a terrestrial backbone network that routes traffic between beams. A terminal in Beam A communicating with a terminal in Beam B must traverse: Terminal A → satellite (Beam A uplink) → Gateway A (downlink) → terrestrial backbone → Gateway B → satellite (Beam B uplink) → Terminal B (downlink).
This cross-beam routing can introduce additional latency beyond the simple double-hop model, depending on the terrestrial distance between gateways and the satellite's beam interconnection architecture. Some HTS satellites support on-board switching that routes traffic between beams within the satellite payload, avoiding the need for ground-based cross-connect—but this requires more complex and expensive satellite ground segment and payload design.
Star-Within-a-Beam
Within each spot beam, the topology is typically a conventional star with the beam's gateway acting as the hub. The gateway manages bandwidth allocation, ACM adaptation, and traffic routing for all terminals in its beam. This means each spot beam operates as a semi-independent star network, with the gateway infrastructure scaled to the aggregate demand within that beam.
Mesh Over HTS
Implementing mesh topology over HTS is more challenging than over traditional wide-beam satellites. For two terminals to communicate directly via mesh, they must either be in the same spot beam (using the beam's capacity for the direct link) or the satellite must support beam-to-beam connectivity. Most current HTS systems favor star topology within beams, with cross-beam traffic routed through gateways and the terrestrial network.
Topology in LEO Constellations
Low Earth Orbit (LEO) constellations such as Starlink, OneWeb, and Telesat Lightspeed introduce fundamentally different topology considerations compared to GEO systems. The non-stationary nature of LEO satellites means that the physical topology is constantly changing as satellites move across the sky.
Dynamic Gateway Connectivity
In a LEO constellation, a user terminal connects to whichever satellite is currently overhead—and that satellite changes every few minutes as the constellation orbits. Each satellite may connect to different gateway ground stations depending on its position, and beam handover occurs frequently as satellites enter and leave the terminal's field of view.
From a topology perspective, the user terminal maintains a star-like relationship with the constellation—it connects to one satellite at a time and routes traffic through that satellite to a gateway. But the "hub" (gateway) changes dynamically, and the constellation's ground network must seamlessly route traffic regardless of which gateway is currently serving each terminal.
Inter-Satellite Links
The most significant topology innovation in LEO constellations is the inter-satellite link (ISL)—laser or RF connections between satellites in the constellation. ISLs create a mesh network in space, allowing data to be routed from satellite to satellite without returning to the ground. This enables:
- Reduced ground infrastructure — traffic can traverse the constellation via ISLs and descend at a gateway closest to the destination, rather than requiring a gateway within the footprint of the user's serving satellite.
- Lower end-to-end latency — for long-distance routes, the speed of light in vacuum (ISLs) is faster than light in fiber (terrestrial), giving LEO+ISL paths a latency advantage for intercontinental traffic.
- Resilience — multiple ISL paths provide redundancy if individual links or satellites fail.
The combination of dynamic satellite-to-ground links and satellite-to-satellite mesh creates a hybrid multi-orbit topology that is fundamentally more complex than traditional GEO networks. Routing algorithms must account for the constantly changing constellation geometry, variable ISL link quality, and latency constraints that shift as the constellation moves.
Constellation-Level Mesh
At the constellation level, the ISL network forms a structured mesh—typically with each satellite maintaining four ISL connections: two intra-plane (to the satellites ahead and behind in the same orbital plane) and two inter-plane (to satellites in adjacent orbital planes). This creates a grid-like mesh topology that moves with the constellation, providing predictable (if time-varying) routing paths.
The routing challenge is significant: the constellation topology changes continuously, link distances and latencies vary as satellites move relative to each other, and the routing tables must be updated in real time. Most constellation operators use centralized or semi-centralized routing computation, where ground-based systems calculate optimal routes based on predicted constellation geometry and distribute routing tables to satellites.
Advantages and Trade-offs
The following table summarizes the key engineering trade-offs between star, mesh, and hybrid topologies:
| Parameter | Star | Mesh | Hybrid |
|---|---|---|---|
| Remote-to-hub latency (GEO) | ~540 ms RTT (single hop) | N/A (no hub) | ~540 ms RTT (star path) |
| Remote-to-remote latency (GEO) | ~1,080 ms RTT (double hop) | ~540 ms RTT (single hop) | ~540 ms (mesh path) or ~1,080 ms (star path) |
| Terminal cost | Low (DVB-S2 Rx + MF-TDMA Tx) | High (SCPC/DAMA transceiver) | Medium-High (dual-mode modem) |
| Hub infrastructure | Required (high cost, shared) | Minimal (signaling/NMS only) | Required (shared with mesh overlay) |
| Scalability | Hundreds to thousands of sites | ~20–30 sites practical limit | Star scale + mesh subset |
| Bandwidth efficiency | High (statistical multiplexing) | Moderate (DAMA overhead) | High (star) + moderate (mesh) |
| Network management | Centralized, simpler | Distributed, more complex | Centralized with mesh extensions |
| Single point of failure | Hub | None (distributed) | Hub (for star traffic) |
| Best traffic pattern | Centralized (remotes to hub) | Peer-to-peer (remote-to-remote) | Mixed centralized + peer-to-peer |
Engineering Considerations
Selecting the right satellite network topology requires evaluating several engineering factors against the application requirements. The following decision framework helps guide the selection process.
Traffic Matrix Analysis
The most important input to topology selection is the traffic matrix—the pattern of who communicates with whom, how much bandwidth they need, and what latency they can tolerate. If 80%+ of traffic flows between remote sites and a central location (headquarters, data center, internet gateway), star topology is the clear choice. If a significant portion of traffic flows between remote sites (peer-to-peer), mesh or hybrid becomes necessary.
Site Count
For networks with fewer than 10 sites where most traffic is inter-site, mesh topology may be cost-effective despite the higher per-terminal cost—the total network cost is still manageable, and the latency benefit is valuable. For 10–30 sites with mixed traffic, hybrid topology provides the best balance. For 30+ sites, star topology (possibly with hybrid extensions for selected sites) is almost always the most practical choice.
Application Profile
Latency-sensitive applications (VoIP, video conferencing, real-time control) benefit significantly from single-hop mesh paths. If these applications represent a critical service requirement between remote sites, mesh or hybrid topology is indicated. Throughput-intensive, latency-tolerant applications (file transfer, email, web browsing, streaming) work well over star topology's double-hop paths.
Budget Constraints
Star topology has the lowest per-site cost and the most favorable scaling economics. If the budget is constrained and the traffic pattern is primarily centralized, star is the most cost-effective choice. Mesh and hybrid topologies require higher per-terminal investment and more complex network management, which increases both CAPEX and OPEX.
Future Growth
Consider how the network will evolve. Star topology accommodates growth most easily—adding sites requires minimal changes to the existing network. Mesh topology becomes increasingly impractical as site count grows. Hybrid topology provides a growth path: start with star for scalability, add mesh capability to specific sites as peer-to-peer requirements emerge.
Frequently Asked Questions
What is the most common satellite network topology? Star (hub-and-spoke) topology is by far the most common satellite network architecture. It is used in the vast majority of commercial VSAT networks because it offers the best balance of per-site cost, scalability, and management simplicity. The centralized hub architecture enables efficient bandwidth management through statistical multiplexing and supports networks ranging from tens to thousands of remote terminals. Most major VSAT platform vendors—Hughes, Viasat, ST Engineering iDirect, Comtech—design their systems primarily around star topology.
Why does star topology have double-hop latency? In a star topology, the hub routes all traffic—including traffic between two remote terminals. When Remote A sends data to Remote B, the data must travel from Remote A up to the satellite (first uplink), down to the hub (first downlink), be processed and re-routed by the hub, then travel back up to the satellite (second uplink) and down to Remote B (second downlink). This double transit through the satellite creates two hops, each adding approximately 270 ms one-way propagation delay for GEO satellites, resulting in a total round-trip time of approximately 1,080 ms. Traffic from a remote to the hub itself requires only a single hop (~540 ms RTT).
When should I choose mesh over star topology? Mesh topology is the right choice when the majority of traffic flows between remote sites (not to a central hub), latency between sites is critical (VoIP, video, real-time control), the network has fewer than 20–30 sites, and the budget can accommodate the higher per-terminal cost of SCPC/DAMA-capable equipment. Typical mesh deployments include inter-office voice/video networks, military tactical communications, and energy sector operational networks where field sites coordinate directly with each other.
What is DAMA and why is it important for mesh networks? DAMA (Demand Assigned Multiple Access) is a protocol that dynamically allocates satellite bandwidth to connections on demand. It is essential for mesh networks because a permanent circuit between every pair of terminals (N(N-1)/2 circuits for N terminals) would waste enormous bandwidth—most circuits would be idle most of the time. DAMA solves this by establishing connections only when needed: a terminal requests a channel, the DAMA controller assigns available bandwidth, the connection is used, and the bandwidth is released for other connections when done. This enables mesh connectivity with reasonable bandwidth efficiency.
How does hybrid topology reduce latency? Hybrid topology reduces latency selectively by routing latency-sensitive traffic (VoIP, video, interactive applications) through single-hop mesh paths (~540 ms RTT over GEO) while sending bulk and latency-tolerant traffic through the star path via the hub (~1,080 ms RTT for remote-to-remote). The terminal's traffic steering logic classifies each flow and directs it to the appropriate path based on application type, QoS marking, or destination. This gives the network the best of both worlds: star scalability and efficiency for the majority of traffic, mesh latency for the applications that need it.
Can LEO constellations use traditional star or mesh topologies? LEO constellations operate with a fundamentally different topology model. At the user level, the terminal maintains a star-like connection to the constellation—connecting to one overhead satellite that routes traffic to a ground gateway. However, the rapidly changing satellite geometry means the "hub" (gateway) changes continuously. At the constellation level, inter-satellite laser links create a mesh network in space, routing traffic between satellites without touching the ground. This creates a dynamic, multi-layer topology that is more complex than traditional GEO star or mesh architectures and requires sophisticated routing algorithms to manage.
What is the maximum number of sites for a mesh satellite network? The practical limit for full mesh satellite networks is approximately 20–30 sites. This limit is driven by the quadratic growth in potential connections (N(N-1)/2), the cost of SCPC/DAMA-capable terminal equipment at each site, the DAMA signaling overhead for managing channel setup and teardown, and the satellite bandwidth required to support multiple simultaneous point-to-point connections. Beyond 30 sites, the economics and management complexity strongly favor star or hybrid architectures. Some hybrid networks extend mesh capability to a subset of sites while keeping the broader network in star mode.
How do HTS spot beams affect network topology? HTS spot beams add a layer of complexity to network topology. Within each spot beam, the topology is typically star—terminals communicate through the gateway that serves their beam. Cross-beam communication (between terminals in different spot beams) requires traffic to be routed through the respective gateways and their terrestrial interconnection, adding latency beyond the simple single-hop model. Some HTS satellites feature on-board switching that can route traffic between beams within the spacecraft, reducing the need for ground-based cross-connect. Mesh topology within a single spot beam is possible but uncommon; most HTS networks operate in star mode with cross-beam routing handled at the gateway/backbone level.
Key Takeaways
- Star topology dominates commercial VSAT networks — its low per-site cost, straightforward scalability to thousands of remotes, and centralized management make it the default choice for most satellite deployments.
- Mesh topology halves remote-to-remote latency — the single-hop path (~540 ms RTT over GEO) versus star's double hop (~1,080 ms RTT) is critical for VoIP, video, and real-time applications between remote sites, but the quadratic scaling and higher terminal cost limit mesh to approximately 20–30 sites.
- Hybrid topology captures both advantages — by routing latency-sensitive traffic via mesh and bulk traffic via star, hybrid architectures provide the scalability of star with the latency benefits of mesh for critical applications.
- HTS spot beams create hierarchical topologies — each beam operates as a star sub-network, with cross-beam routing adding an additional layer of latency and complexity beyond traditional single-beam architectures.
- LEO constellations introduce dynamic, multi-layer topology — inter-satellite laser links create a mesh in space, while the constantly changing satellite geometry requires dynamic routing algorithms fundamentally different from static GEO topologies.
- Traffic matrix drives topology selection — the pattern of who communicates with whom, the latency sensitivity of applications, the number of sites, and the available budget are the primary inputs to the topology decision.
Related Articles
- VSAT Network Architecture — Foundational guide to VSAT network design and hub-spoke architectures
- Satellite Ground Segment Architecture — Hub and gateway infrastructure engineering
- Satellite Terminal Architecture — Terminal components, RF chain, and modem design
- Satellite Latency Comparison — Latency analysis across GEO, MEO, and LEO orbits
- HTS Spot Beams and Beamforming Explained — Spot-beam architecture and capacity planning
- Hybrid Satellite Network Multi-Orbit — Multi-orbit network design and integration
- QoS Over Satellite Traffic Shaping — Traffic classification and prioritization over satellite
- Adaptive Coding and Modulation — ACM for dynamic link optimization
Author
Categories
More Posts

Adaptive Coding and Modulation (ACM) Explained: How Satellite Networks Maintain Link Quality
Engineering guide to adaptive coding and modulation in satellite systems covering signal quality measurement, MODCOD selection algorithms, DVB-S2/S2X ACM capabilities, rain fade response, and ACM design for HTS and LEO networks.

DVB-S2X Explained: How Modern Satellite Networks Improve Spectral Efficiency
Engineering guide to DVB-S2X covering finer MODCODs, efficiency gains over DVB-S2, roll-off improvements, HTS and backhaul applications, and deployment trade-offs.

Satellite Communication Basics: Architecture, Frequency Bands, and How It Works
Learn satellite communication basics including architecture, frequency bands, uplink, downlink, GEO, LEO, and real-world engineering applications.
Newsletter
Join the community
Subscribe to our newsletter for the latest news and updates