Non-Terrestrial Networks (NTN) Architecture Explained

Non-terrestrial networks (NTN) use satellites or airborne platforms as part of a communications network, extending service beyond the reach of conventional cell sites. Network engineers, device makers, and teams planning connectivity for remote or moving assets need to understand how an NTN fits with terrestrial mobile systems. This guide explains the architecture, the trade-offs between payload designs and orbits, and how to assess whether a satellite or high-altitude link suits an application.

Why Non-Terrestrial Networks Are Being Discussed

Mobile connectivity is usually built around ground-based radio sites connected to an operator’s core. That model works well where sites and backhaul can be deployed, but becomes expensive or impractical across oceans, remote terrain, aircraft routes, and disaster areas. A satellite or high-altitude platform can cover a wide region from above, or relay traffic between a remote site and the rest of the network.

The interest is not just consumer satellite messaging. Mobile operators and infrastructure providers are exploring NTN for direct device connectivity, satellite backhaul, emergency restoration, and IoT coverage. These are different services with different terminals and performance expectations. The 3GPP introduction to non-terrestrial networks describes the satellite and high-altitude platform models and how their links relate to a mobile network.

What Is a Non-Terrestrial Network?

An NTN is a network, or part of one, that uses a platform in the air or space to carry communications. The platform may be a satellite in a geostationary, medium, or low Earth orbit, or a high-altitude platform such as an aircraft or balloon. It may act as a radio relay, host some base-station functions, or connect a remote terrestrial network to an operator’s infrastructure.

“Non-terrestrial” describes where part of the network operates, not a single radio technology or service. Some NTN deployments use 3GPP cellular radio standards and integrate with a mobile core; others use satellite systems with different terminals and network designs. A phone connecting directly to a satellite, a satellite serving a ground gateway, and a satellite providing backhaul to a local cell site are all distinct architectures.

This distinction matters when comparing NTN with a conventional cellular network architecture. A terrestrial network depends on nearby radio sites and transport; an NTN adds a space or aerial segment but still needs endpoints, gateways, routing, spectrum coordination, and operations.

The Problem NTN Solves

Ground networks need physical sites, power, and a path to the core. In remote regions, the cost of building and maintaining those components may exceed the expected demand. Ships, aircraft, and field operations also move through areas without continuous cellular coverage. After a storm or other disruption, terrestrial fiber or towers may be unavailable even when responders need communications.

NTN can extend coverage over large areas without placing a conventional cell site at every location. It can provide a direct link to a suitably equipped terminal, carry traffic from a remote gateway, or provide a temporary or backup path. A satellite link can also connect isolated terrestrial networks that have no practical fiber or microwave route.

The trade-off is that distance, movement, and limited spectrum shape performance. NTN is not a universal replacement for terrestrial networks: where ground coverage is dense, a nearby cell site will generally provide a shorter path and higher capacity per area. The value of NTN is reach, resilience, or a particular coverage model, not an automatic improvement in speed or cost.

How NTN Architecture Works

A useful starting point is to trace the user data path:

device or local cell
  -> service link
  -> satellite or high-altitude platform
  -> feeder link
  -> NTN gateway
  -> mobile core or public data network
  -> application

The service link, sometimes called the user link, connects a user device or a terrestrial relay to the platform. The feeder link connects the platform to a ground gateway. A deployment may also use inter-satellite or inter-aerial links to move traffic between platforms before it reaches a gateway. The route and the location of radio processing depend on the payload architecture.

Transparent and regenerative payloads

A transparent payload, also called bent-pipe, filters, amplifies, and frequency-converts the radio signal, then relays it onward. It does not decode and route the traffic as a base station. In a cellular design, the gateway can host the base-station functions, with the satellite acting more like a remote radio head.

A regenerative payload processes the radio signal on board. It can include base-station functions and may switch or route traffic before sending it over a feeder link or an inter-satellite link. That can change where functions run and how the network is engineered, but it adds processing and operational requirements to the platform.

These are broad design patterns rather than universal product specifications. The 3GPP study on solutions for NR to support non-terrestrial networks, Technical Report 38.821, documents radio and architecture considerations; it is a study report, not a guarantee that every NTN uses one particular implementation.

Integration with a mobile network

For cellular-based NTN, the radio access and mobile core remain important parts of the end-to-end system. The terminal registers with a network, control functions establish connectivity, and user traffic travels toward a data network. A satellite can extend the radio access path or serve as backhaul for a terrestrial base station. The 3GPP 5G system overview describes the wider relationship between user equipment, radio access, and the 5G Core.

This integration does not mean all services behave like a nearby terrestrial cell. Operators must account for longer propagation time, radio scheduling, mobility, gateway selection, and service continuity. The network may need to predict platform position and adjust timing and beam management as the satellite moves.

Platforms, Orbits, and Key Components

The platform and orbit influence coverage, delay, motion, and the complexity of handovers:

• Geostationary orbit (GEO): The satellite appears nearly fixed relative to a point on Earth and can cover a broad region. Its large altitude produces a longer path and higher propagation delay, which can constrain interactive applications.
• Medium Earth orbit (MEO): MEO satellites sit between GEO and LEO in altitude and orbital period. Their coverage and delay depend on the constellation design, and the user terminal still needs to track changing satellites.
• Low Earth orbit (LEO): LEO satellites are closer to Earth, so a link can have less propagation delay than GEO. They move quickly relative to a ground user, requiring frequent beam, satellite, or gateway transitions to maintain service.
• High-altitude platforms (HAPS): Aircraft or other platforms operate in the atmosphere rather than orbit. They can provide a regional service, but coverage, persistence, backhaul, and operating conditions depend on the platform.

Other components include the user equipment or relay terminal, satellite or aerial radio payload, gateway, service and feeder links, and the operator’s core and management systems. A terminal intended for handheld use has different antenna and power limits from a fixed very small aperture terminal (VSAT) with a larger antenna. Device compatibility therefore depends on the radio bands, antenna design, supported standards, and service provider—not just whether a product advertises satellite connectivity.

Real-World NTN Use Cases

• Coverage extension: Direct-to-device or fixed terminals can provide connectivity in areas without terrestrial service, if the device and service support the required link.
• Backhaul: A satellite can connect a remote cell site, community network, or temporary deployment to a core or internet gateway.
• Transport: Ships, aircraft, and remote vehicles can use satellite systems where continuous ground coverage is unavailable. The application must tolerate the delay and handovers of the chosen service.
• Emergency response and resilience: An independent path can help restore communications after ground infrastructure fails, although power, gateway access, and congestion still matter.
• Remote sensing and IoT: Sensors may send small periodic messages from locations that are difficult to reach with cellular or terrestrial LPWAN. For low-volume device networks, compare the constraints with LPWAN technologies such as NB-IoT and LoRaWAN.

Evaluating and Testing an NTN Service

Start with the application requirement rather than the satellite label. Confirm where service is available, which terminal and radio bands are supported, whether the device connects directly or through a gateway, and whether the plan permits the intended use. For moving terminals, ask how handovers and temporary loss of visibility are handled. For a critical system, define what happens when the link is unavailable and whether a terrestrial or local fallback is needed.

Measure the service at the application endpoint. A basic test can show round-trip time and throughput to a server you control; it does not measure satellite capacity or guarantee service quality elsewhere:

# On an authorized test server:
iperf3 -s

# From a terminal connected through the NTN service:
ping -c 10 "$TEST_HOST"
iperf3 -c "$TEST_HOST" -t 30

Repeat measurements at different times and locations, and record packet loss and interruptions as well as average speed. Some networks block ping, so a missing ping response alone does not prove that the service is down. Check an application-level endpoint or the provider’s diagnostics. Avoid benchmarking against an endpoint you do not control or have permission to test.

For planning, record latency, throughput, availability, power use, data limits, installation constraints, roaming or regional restrictions, and service cost. An IoT sensor that reports occasionally can tolerate a different service profile from a remote-control application. Separate normal performance from outage behavior and test recovery before relying on the link operationally.

Common Misconceptions

• “Every satellite service is 5G NTN.” Some systems integrate with 3GPP cellular networks; others use their own radio and terminal ecosystem.
• “A satellite connection is always faster than cellular.” Satellite coverage may reach farther, but propagation delay, capacity sharing, spectrum, terminal, and route affect performance.
• “A satellite can connect to any phone.” Direct connectivity requires compatible hardware, supported spectrum, an available service, and regulatory approval for the location.
• “Coverage from space means uninterrupted service.” Moving satellites, obstructions, weather effects at some frequencies, gateway availability, and network load can interrupt or degrade a path.
• “NTN removes the need for ground infrastructure.” Gateways, core networks, power, spectrum coordination, terminals, and operational systems remain part of the service.

Related Articles

• Cellular network architecture explained for the terrestrial radio, transport, and core layers.
• 6G network technology explained for future mobile-network goals and the distinction between research and deployed capabilities.
• LPWAN technologies explained for low-power telemetry options and their connectivity trade-offs.

Changelog

• Initial publication.

Last updated: 2026-11-02