SATCOM Index Logo
SATCOM INDEX
  • Basics
  • Providers
  • Comparison
  • Guides
  • Tools
LogoSATCOM Index
VSAT Network Architecture: Star, Mesh & Hybrid Topology
Published 2026/02/25 · Updated 2026/08/26

VSAT Network Architecture: Star, Mesh & Hybrid Topology

See how VSAT networks separate terminals, gateways, NCC/NMC control and satellite payloads, then compare star, mesh, hybrid and point-to-point traffic paths.

What changed: Rebuilt the page around terminal, gateway, NCC, NMC, payload, and service-edge roles; corrected DVB-S2/S2X, MF-TDMA, DAMA, continuous-carrier, and GEO hop terminology; removed unsupported equipment, bandwidth, scale, deployment, and availability ranges; and aligned the examples with 2026 DVB-RCS2 specifications.

A VSAT network is not defined by one universal dish size, one orbit, or one hub design. Its architecture is the set of physical and logical paths connecting a remote terminal, a satellite payload, one or more gateways, network control and management functions, and the service endpoint.

Many commercial systems use a transparent satellite and a gateway-anchored star path, but that is only one design. Current ETSI DVB-RCS2 system specifications also describe transparent mesh overlays, regenerative mesh, and non-geostationary reference architectures. The informative ITU-R Report S.2278 separately discusses star, mesh, hybrid, and point-to-point VSAT topologies.

This guide focuses on the architecture inside a VSAT service: what each function does, how user and control traffic flow, and which assumptions must be verified before selecting equipment or capacity.

Detailed Topology Comparison | End-to-End Architecture | Terminal Reference

VSAT Architecture at a Glance

A simplified interactive IP path is:

User LAN | router / firewall | remote terminal modem (RCST) | IF/RF chain + antenna | satellite payload | gateway RF + baseband | service edge / private WAN / internet

Control and management form parallel paths:

NMC policy and configuration | v NCC logon, timing, signalling, and capacity assignment | v remote terminal control and status

In a compact deployment, the gateway, Network Control Centre (NCC), Network Management Centre (NMC), service edge, and operations staff may be co-located and collectively called the hub. In a larger network they may be separate systems, separate sites, or geographically redundant. A Network Operations Centre is an operational organization or location; it is not automatically the RF gateway carrying user traffic.

The Six Functional Building Blocks

1. Remote terminal

The remote terminal provides the interface between the user network and the satellite air interface. A conventional terminal contains:

  • an indoor modem or integrated terminal for framing, coding, modulation, access control, and network interfaces;
  • an outdoor transmit chain, such as an upconverter and power amplifier or BUC;
  • a receive chain, such as an LNB or separate low-noise and downconversion stages;
  • an antenna, feed, polarization components, cabling or waveguide, and mounting or stabilization system;
  • local router, firewall, power, grounding, and monitoring interfaces as required by the service.

The required antenna, power, pointing, tracking, and environmental specifications come from the link budget, operator access plan, mobility case, licensing conditions, and installation design. Fixed generic ranges for dish diameter, BUC watts, or pointing accuracy are not architecture rules.

The modem does more than convert Ethernet to RF. Depending on the platform, it may handle encapsulation, QoS classification, return-capacity requests, timing recovery, logon, power control, adaptive coding and modulation, encryption or tunnelling, and telemetry. Do not assume every function is implemented in every terminal.

2. Satellite payload

The payload supplies radio connectivity between coverage areas. Two broad payload models must be separated:

  • A transparent payload filters, amplifies, switches, or frequency-translates signals without terminating the full user protocol stack. User-plane routing commonly occurs on the ground, but a transparent mesh overlay can still be possible when beam connectivity and terminal capabilities support it.
  • A regenerative payload demodulates and regenerates the signal onboard and may switch or route traffic before retransmission. This can support single-hop connectivity between user beams without a ground gateway transit in the user plane.

Neither model is limited to one orbit. GSO and NGSO systems can use different combinations of transparent processing, digital channelization, onboard regeneration, feeder links, and beam switching. Record the actual payload and beam path instead of using “GEO,” “HTS,” or “bent pipe” as a complete architecture description.

3. Gateway and feeder link

The gateway terminates the feeder-side radio path. Its functions can include:

  • large-antenna and RF transmit/receive chains;
  • forward-link modulation and return-link demodulation;
  • timing distribution and reference generation;
  • connection to baseband, control, management, and terrestrial networks;
  • redundancy switching, calibration, spectrum monitoring, and interference response.

A network can have one or many gateways. Multiple gateways do not automatically provide resilience: they may share a feeder beam, satellite payload, control plane, power source, terrestrial backhaul, or software state.

4. Network Control Centre

The NCC controls access to shared satellite resources. In a DVB-RCS2 example, it participates in terminal logon, forward-link signalling, synchronization, terminal burst time plans, return-capacity assignment, waveform control, and other control-plane functions defined by the implemented profile.

The NCC is not synonymous with the internet gateway. A direct mesh user path may still rely on centralized NCC signalling and scheduling. Likewise, a star network may distribute control functions across several systems.

5. Network Management Centre

The NMC manages configuration and operational state rather than carrying every user packet. Functions can include:

  • terminal inventory and software/configuration management;
  • service profiles and SLA parameters;
  • fault, alarm, performance, and security-event collection;
  • topology, gateway, beam, and capacity visibility;
  • maintenance workflows and audit records.

ETSI TS 101 545-1 V1.4.1 distinguishes the NMC's overall management role from the NCC's return-link control and signalling role. A product may combine their interfaces, but the logical responsibilities remain useful for design and troubleshooting.

6. Service edge and terrestrial network

After the satellite gateway, traffic may pass through routing, firewall, NAT, VPN, QoS, DNS, content delivery, acceleration, private WAN, cloud interconnect, or internet transit functions. These functions are part of the end-to-end service even when they are not part of the satellite air interface.

Measure gateway-to-application performance separately. A healthy RF link can still deliver poor service because of terrestrial congestion, routing, DNS, security inspection, application delay, or an incorrectly sized service edge.

Forward Link, Return Link, and Control Plane

Terminology must be defined from a stated viewpoint. In many interactive satellite systems:

  • Forward link means gateway or feeder toward the remote terminal.
  • Return link means remote terminal toward the gateway or receiving station.
  • Control plane carries logon, synchronization, resource assignment, and other signalling.
  • Management plane carries configuration, status, alarms, and operational management.
  • User plane carries subscriber or application traffic.

“Uplink” and “downlink” describe RF direction relative to the satellite, not service direction. One forward satellite hop contains a gateway uplink and a remote downlink; one return hop contains a remote uplink and a gateway downlink.

Do Not Mix Waveform, Access, and Allocation

The architecture is often misread because several different concepts are grouped under “protocol.”

ConceptQuestion it answersExample
Framing, coding, and modulationHow are bits represented and protected on the carrier?DVB-S2/S2X or a DVB-RCS2 return waveform
Multiple accessHow do multiple terminals share time, frequency, codes, or contention opportunities?MF-TDMA or random access
Capacity assignmentWho grants resources, for how long, and from which requests or policy?DAMA, persistent assignment, or unsolicited assignment
Carrier allocationIs capacity burst-based, shared, or continuously assigned?Timeslot bursts or a continuous carrier
Logical topologyWhere does user traffic transit?Star, mesh, hybrid, or point-to-point

DVB-S2/S2X defines framing, coding, and modulation behavior; it does not by itself allocate bandwidth to remote terminals. In a DVB-RCS2 system, MAC and control functions coordinate the interactive service. ETSI EN 301 545-2 V1.5.1 specifies the lower-layer models and return-link operation.

MF-TDMA describes a shared time-and-frequency grid. DAMA describes demand-related assignment behavior. They are related in many systems but are not synonyms. A continuous single-carrier allocation is a different operating pattern, not the same category of mechanism as a capacity-request policy.

SCPC commonly labels a single-carrier-per-channel or per-circuit allocation, often operated continuously. Product terminology varies, so an engineering specification should still state the waveform, occupied bandwidth, persistence, assignment method, and sharing behavior rather than relying on the acronym alone.

The 2026 ETSI TR 101 545-4 V1.2.1 explains that DVB-S2/S2X waveforms can be used on the return link in burst modes and in persistent or non-persistent continuous modes. This is one standards-based architecture, not evidence that every VSAT vendor implements the same modes.

Star, Mesh, Hybrid, and Point-to-Point

Topology describes the user-plane traffic path. It does not, by itself, identify the waveform, orbit, payload processing, scheduling method, or number of sites.

TopologyUser-plane pathControl can remain centralized?Primary design check
StarRemote traffic transits a gateway or hubYesGateway capacity, shared fault domains, and two-hop remote-to-remote paths
MeshSupported remote pairs use a direct satellite pathYesPeer link budgets, receive capability, beam connectivity, and resource control
HybridPolicy selects star or mesh by flow or site pairYesCorrect steering, consistent security/QoS, and failure behavior
Point-to-pointTwo endpoints use a dedicated or logically isolated pathPossiblyLink budget, capacity commitment, control ownership, and protection

A mesh does not require a permanent carrier for every mathematical pair of terminals. Its practical scale depends on simultaneous demand, scheduler and signalling limits, link budgets, terminal capabilities, beam connectivity, spectrum, and product implementation. There is no defensible universal “20 to 30 terminal” cutoff.

For traffic matrices, pair-count calculations, failure domains, and a fuller selection method, use the satellite network topology guide rather than duplicating those decisions here.

Count GEO Satellite Hops Correctly

RFC 2488 Section 2 defines one satellite hop as one ground-station-to-satellite-to-ground-station route. It reports 239.6 ms for an ideal GEO hop and 279.0 ms near the edge of coverage. These are one-way propagation values, not complete service latency.

Using those documented bounds:

PathOne-way satellite hopsPropagation floor, one wayPropagation floor, RTT
Remote to gateway in a star1239.6–279.0 ms479.2–558.0 ms
Remote A to Remote B through a ground gateway2479.2–558.0 ms958.4–1,116.0 ms
Remote A to Remote B over a supported direct mesh path1239.6–279.0 ms479.2–558.0 ms

The two-hop values are simple multiples:

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

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

Real RTT also includes scheduling, serialization, modem and payload processing, queueing, terrestrial routing, security functions, application processing, and path asymmetry. Do not present 480–600 ms as a universal measured GEO service RTT. See the satellite latency guide for the physical and operational boundaries.

Trace a Star-Path Transaction

For a remote user accessing a service behind the gateway, a simplified return-direction packet flow is:

  1. The user device sends an IP packet to the local router and remote terminal.
  2. The modem classifies and encapsulates the packet according to the platform.
  3. The terminal transmits in an assigned or permitted return resource.
  4. The satellite payload relays or processes the signal according to its payload design.
  5. The gateway receives and demodulates the return carrier.
  6. The service edge routes the packet toward the private network, cloud, or internet destination.

The response follows the forward path:

  1. The service edge sends the response to the forward-link system.
  2. The hub or gateway schedules and encapsulates it into the appropriate forward carrier.
  3. The satellite payload delivers the signal toward the serving beam.
  4. The remote terminal demodulates and decapsulates it.
  5. The local router delivers the packet to the user.

This flow is an architectural example. A regenerative payload, direct mesh path, multi-gateway network, onboard routing system, or NGSO handover can change the sequence.

Size the Architecture From Requirements

Equipment cannot be selected from an industry “typical range” alone. Record the following before choosing a terminal or hub configuration:

For a fixed GEO site, the GEO look-angle calculator can screen pointing direction, elevation, and idealized horizon visibility during early planning. Final siting still requires an obstruction survey, polarization setup, operator approval, and commissioning measurements.

  1. Traffic matrix: source, destination, busy-hour rate, burstiness, directionality, and traffic class.
  2. Path definition: star, direct mesh, gateway diversity, terrestrial handoff, and application endpoint.
  3. Satellite path: orbit, satellite hops, payload type, beams, feeder links, handovers, and any inter-satellite links.
  4. Link budgets: EIRP, G/T, carrier bandwidth, interference, polarization, propagation, availability objective, and margins.
  5. Access plan: forward and return waveforms, capacity requests, assignment categories, contention, continuous carriers, and admission limits.
  6. QoS and security: classification, queueing, encryption, tunnelling, addressing, isolation, and lawful or regulatory requirements.
  7. Operations: terminal provisioning, telemetry, alarms, software lifecycle, spectrum monitoring, and escalation ownership.
  8. Resilience: every shared dependency, switchover method, state replication, recovery time, and tested failure scenario.
  9. Authorization: operator access approval, spectrum licence, equipment conformity, installation acceptance, and applicable national rules.

EIRP Calculation | Link Budget Calculation | Network Management

Performance and Acceleration

High propagation delay and a large bandwidth-delay product can affect transport performance even when the RF link has adequate capacity. RFC 2488 discusses standard TCP mechanisms for satellite channels. RFC 3135 surveys Performance Enhancing Proxies (PEPs), including satellite VSAT examples, and also discusses architectural consequences.

A PEP is not a universal cure or a topology requirement. Validate:

  • which protocols and traffic classes it can handle;
  • whether it preserves required end-to-end semantics;
  • interaction with encryption, tunnelling, security policy, and troubleshooting;
  • failover and state synchronization;
  • behavior under loss, reordering, changing capacity, and asymmetric paths;
  • measured application performance rather than only link-layer throughput.

Caching, compression, QoS, local breakouts, and application changes may help particular workloads, but each must be tested against the real service path.

Resilience and Acceptance Tests

Do not convert a desired availability percentage directly into a generic hardware recipe. The result depends on propagation statistics, service area, restoration design, maintenance time, power, backhaul, spares, satellite diversity, and common failure modes.

Before service acceptance, test:

  • terminal acquisition, logon, timing, and recovery after interruption;
  • forward and return throughput separately at busy and quiet periods;
  • latency by path, including remote-to-gateway and remote-to-remote;
  • packet loss, jitter, QoS enforcement, and queue behavior;
  • uplink power control and ACM behavior within authorized limits;
  • gateway, backhaul, power, baseband, and control-plane failover;
  • alarm delivery, telemetry accuracy, time synchronization, and audit trails;
  • software rollback and terminal configuration recovery;
  • application behavior with and without acceleration;
  • operator and regulatory acceptance measurements.

Label every measured result with the terminal, beam, gateway, carrier, traffic load, timestamp, weather state, test endpoint, and software version. Otherwise, a number cannot be reliably reproduced or compared.

Common Architecture Mistakes

  1. Treating “hub” as one indivisible box. Separate gateway RF, baseband, NCC, NMC, service edge, operations, and terrestrial backhaul.
  2. Calling DVB-S2/S2X a bandwidth-allocation protocol. It specifies framing, coding, and modulation behavior; resource assignment is a separate function.
  3. Using MF-TDMA, DAMA, and SCPC as interchangeable labels. They answer different access, assignment, and carrier-allocation questions.
  4. Assuming mesh has distributed control. Direct user traffic can still depend on centralized scheduling and management.
  5. Assuming transparent payload means star only. Transparent mesh overlays exist when payload connectivity and terminal capabilities support them.
  6. Calling an uplink or downlink one satellite hop. A hop is the complete ground-satellite-ground route.
  7. Using advertised equipment ranges as a design. Link budget, access plan, authorization, and environmental requirements determine the terminal.
  8. Claiming redundancy from component count alone. Verify shared feeder beams, power, sites, backhaul, state, software, and control dependencies.

Frequently Asked Questions

Does every VSAT network use GEO?

No. GEO is common in traditional VSAT services, but VSAT architecture is not an orbit definition. Current DVB-RCS2 reference material includes NGSO considerations. State orbit, payload, beam, gateway, and routing behavior separately.

Is the hub the same as the NOC?

Not necessarily. “Hub” often groups gateway and baseband functions. The NOC is the operational organization or facility. The NCC and NMC are logical control and management roles. They can be co-located, distributed, or operated from different sites.

Is DVB-S2X only for the forward link?

No. Forward-link DVB-S2/S2X is a common interactive architecture, but current DVB-RCS2 specifications also support DVB-S2/S2X-based return operation in specified burst and continuous modes. Product support and the deployed profile must still be verified.

Is mesh always faster than star?

For remote-to-remote traffic, a supported direct mesh path can remove one ground-gateway satellite transit and therefore one satellite hop in each direction. It does not automatically improve gateway-bound traffic, and processing, scheduling, congestion, terrestrial routing, and application behavior still affect performance.

How many terminals can a mesh network support?

There is no universal site-count limit. Capacity, simultaneous connections, signalling, scheduling, beam connectivity, terminal receive capability, link budgets, spectrum, and vendor implementation determine the practical limit.

Key Takeaways

  • VSAT architecture separates remote terminal, satellite payload, gateway, NCC, NMC, and service-edge roles.
  • Star, mesh, hybrid, and point-to-point describe traffic paths, not orbit or waveform.
  • DVB-S2/S2X, MF-TDMA, DAMA, and continuous carriers describe different layers of the system.
  • Transparent payloads can support more than star, while regenerative payloads can provide onboard switching or routing.
  • GEO delay must be reported as a propagation floor with an explicit hop count, not as a universal service RTT.
  • Equipment, availability, and redundancy must be derived from the specific link, traffic, operator, and regulatory requirements.

Related Articles

  • Satellite Network Topology — Detailed star, mesh, and hybrid selection using traffic matrices and failure domains
  • Satellite Link Budget Calculation — Reproducible EIRP, path-loss, G/T, C/N, and margin workflow
  • Satellite EIRP Explained — Directional transmit power and reference-plane calculations
  • Satellite Latency: GEO vs MEO vs LEO — Propagation floors and measured-service boundaries
  • Ground Segment — Gateway, teleport, control, and terrestrial integration
  • VSAT Terminals — Indoor and outdoor terminal components
  • Network Management — Monitoring, control, alarms, and operational workflows

Primary technical references

Use these official standards libraries to verify terminology, specifications, and current revisions. Product-specific details should also be confirmed with the relevant operator or manufacturer.

  • ITU-R Report S.2278: Use of very small aperture terminals (VSATs)Sections 2 to 4: characteristics, topologies, control, power control, and ACM · Accessed 2026-08-26
  • ETSI TS 101 545-1 V1.4.1: DVB-RCS2 overview and system-level specificationClauses 4 and 5: system definition, reference architectures, roles, and feature profile · Accessed 2026-08-26
  • ETSI EN 301 545-2 V1.5.1: DVB-RCS2 lower layers for satelliteClauses 4 to 7: reference models, forward link, return link, and access · Accessed 2026-08-26
  • ETSI TR 101 545-4 V1.2.1: DVB-RCS2 implementation guidelinesClause 4 reference models and Clause 11.4.4 DVB-S2X return-link operation · Accessed 2026-08-26
  • IETF RFC 2488: Enhancing TCP Over Satellite ChannelsSection 2: satellite-hop definition, GEO propagation, and additional delay terms · Accessed 2026-08-26
  • IETF RFC 3135: Performance Enhancing ProxiesSections 2 to 5, including satellite VSAT examples and architectural implications · Accessed 2026-08-26
All Posts

Author

avatar for SatCom Index
SatCom Index

Organizational byline for SATCOM Index technical content. A named technical reviewer appears separately only when identity, scope, and permission are verified.

Editorial policyTechnical reviewMethodologyCorrections

Categories

  • Technical Reference
VSAT Architecture at a GlanceThe Six Functional Building Blocks1. Remote terminal2. Satellite payload3. Gateway and feeder link4. Network Control Centre5. Network Management Centre6. Service edge and terrestrial networkForward Link, Return Link, and Control PlaneDo Not Mix Waveform, Access, and AllocationStar, Mesh, Hybrid, and Point-to-PointCount GEO Satellite Hops CorrectlyTrace a Star-Path TransactionSize the Architecture From RequirementsPerformance and AccelerationResilience and Acceptance TestsCommon Architecture MistakesFrequently Asked QuestionsDoes every VSAT network use GEO?Is the hub the same as the NOC?Is DVB-S2X only for the forward link?Is mesh always faster than star?How many terminals can a mesh network support?Key TakeawaysRelated Articles

More Posts

End-to-End Architecture
Architecture

End-to-End Architecture

Complete overview of satellite communication system architecture from space segment to user terminals.

avatar for SatCom Index
SatCom Index
2026/02/09
Satellite Glossary: A-F
Glossary

Satellite Glossary: A-F

Satellite communication terminology and definitions from A to F.

avatar for SatCom Index
SatCom Index
2026/02/17
Ku Band vs Ka Band Satellite | Technical Comparison and Deployment Tradeoffs
Technical Reference

Ku Band vs Ka Band Satellite | Technical Comparison and Deployment Tradeoffs

Ku band (12–18 GHz) vs Ka band (26.5–40 GHz): rain attenuation is 5–10× higher on Ka, plus tradeoffs in bandwidth, terminal size, and VSAT.

avatar for SatCom Index
SatCom Index
2026/02/24
SATCOM Index Logo
SATCOM INDEX

An independent technical knowledge base for international satellite communication systems.

ArticlesGlossarySolutionsGEO Look Angle ToolAboutContactEditorial PolicyTechnical ReviewCorrections PolicyMethodologyPrivacy PolicyCookie PolicyTerms of Service
© 2026 SATCOM Index. All rights reserved.•An unofficial technical community. Not affiliated with any satellite operator.
v1.1.1