Non-Terrestrial Networks (NTN) Interview Prep
Non-Terrestrial Networks (NTN) interview prep — satellite 5G (GEO/MEO/LEO/HAPS), 3GPP NR-NTN and IoT-NTN, transparent vs regenerative payload, delay, Doppler, GNSS pre-compensation.
Quick answer
Non-Terrestrial Networks (NTN) are the 3GPP framework for delivering 5G connectivity through satellite and aerial access nodes — geostationary (GEO, ~35,786 km), medium-Earth-orbit (MEO), and low-Earth-orbit (LEO, a few hundred km) satellites, plus High-Altitude Platform Stations (HAPS).
NTN questions test whether a candidate can reason about a radio system when the textbook latency and Doppler assumptions no longer hold.
Editorial review
Written by
CompoundLearn editorial team
Wireless / RF / hardware engineering
Reviewed by
CompoundLearn editorial team
Wireless / RF / hardware engineering
Last reviewed
Built from curated topic maps, editorial validation, and subject-matter review so the page stays aligned with the interview intent and the current content pipeline.
Key points
- NTN integrates satellite and aerial access (GEO, MEO, LEO, HAPS) into the 3GPP 5G system; 3GPP defined it normatively in Release 17 as NR-NTN (broadband NR) and IoT-NTN (NB-IoT and eMTC/LTE-M).
- Transparent (bent-pipe) payload: the satellite is an RF relay and the gNB is on the ground. Regenerative payload: on-board processing puts gNB functions on the satellite. Release 17 standardized transparent only; regenerative is Release 18/19 work.
- Propagation delay is the headline PHY/MAC challenge: ~240–270 ms one-way end-to-end (UE-to-gateway via the satellite) for GEO (round-trip on the order of 540 ms for a transparent path), ~20–40 ms one-way for LEO, against the sub-millisecond round trips terrestrial NR assumed.
- The UE is assumed to have GNSS and pre-compensates the predictable delay and Doppler from its own position plus satellite ephemeris — applying a timing offset to PRACH and a frequency offset for Doppler — so random access and uplink timing close.
- Terrestrial RACH and timing-advance ranges do not work unchanged: NTN extends the timing-advance range and signals a common timing advance plus ephemeris so the UE can derive hundreds of milliseconds of advance.
- Mobility is satellite-driven for LEO (beams and cells sweep over a stationary UE), introducing Earth-fixed vs Earth-moving beams and feeder-link switchover — a different regime from terrestrial UE-driven handover.
- Release 19 extends NTN with store-and-forward operation, IoT-NTN connected to the 5G core, RedCap over NTN, regenerative-payload support, and coverage above 10 GHz.
What it is
Non-Terrestrial Networks (NTN) are the 3GPP framework for delivering 5G connectivity through satellite and aerial access nodes — geostationary (GEO, ~35,786 km), medium-Earth-orbit (MEO), and low-Earth-orbit (LEO, a few hundred km) satellites, plus High-Altitude Platform Stations (HAPS). 3GPP introduced NTN normatively in Release 17, after the study work captured in TR 38.811 (Study on NR to support NTN) and the solutions in TR 38.821. Release 17 defines two tracks: NR-NTN, which adapts the 5G NR broadband air interface, and IoT-NTN, which adapts the LTE-based NB-IoT and eMTC (LTE-M) technologies for low-rate, battery-constrained devices. The defining idea is reuse: the same core, and largely the same protocol stack, extended so the air interface tolerates a space or airborne segment. The hard engineering sits at the PHY and MAC. Large propagation delay (on the order of 240–270 ms one-way end-to-end UE-to-gateway for GEO, ~20–40 ms for LEO), large and time-varying Doppler, a tight link budget over long slant ranges, beam management across wide footprints, and satellite-driven mobility all violate assumptions baked into terrestrial NR. Release 17 assumes a transparent (bent-pipe) payload — the satellite is an RF relay and the gNB lives on the ground — and assumes the UE has GNSS so it can pre-compensate the predictable delay and Doppler. Releases 18 and 19 extend the framework toward regenerative payloads, store-and-forward operation, and broader device classes.
Why interviewers ask
NTN questions test whether a candidate can reason about a radio system when the textbook latency and Doppler assumptions no longer hold. Many engineers know terrestrial NR initial access (see /topics/nr-initial-access-ssb-rach) cold but freeze when the round trip jumps to hundreds of milliseconds, because the answer is not memorized — it requires reasoning about why the random-access procedure, HARQ timing, and timing advance break and what the standard does about it. The topic is also a systems-integration probe: NTN forces you to connect orbital mechanics (delay and Doppler that depend on altitude and geometry), GNSS-assisted pre-compensation, link-budget math over long slant ranges (see /topics/link-budget), and the architectural choice between transparent and regenerative payloads. Interviewers for modem, RAN, and satellite-systems roles use NTN to separate candidates who can recite "5G from space" from those who can quantify the problem and name the mechanism that solves it. Strong candidates anchor each NTN feature to a concrete constraint — why GNSS is assumed, why the timing-advance range had to grow, why LEO mobility is satellite-driven, why store-and-forward needs a regenerative payload — and connect it back to the terrestrial baseline (see /topics/3gpp-release-19) it diverges from. The signal is whether you can reason about a known system pushed into an unfamiliar physical regime.
Common mistakes
The most common mistake is underestimating the magnitude of the delay and Doppler. Saying "satellites add some latency" misses that GEO is on the order of 240–270 ms one-way end-to-end (UE-to-gateway) — a round trip near 540 ms for a transparent path — which is hundreds of times the budget terrestrial NR assumed; a candidate who cannot put a number on it has not engaged with the actual problem. A second mistake is assuming the terrestrial random-access and timing procedures work unchanged: terrestrial RACH timing windows and timing-advance ranges cannot represent hundreds of milliseconds, so NTN extends the timing-advance range and relies on UE-side pre-compensation using GNSS and broadcast ephemeris. Forgetting that the UE is assumed to have GNSS — and that this is what makes pre-compensation possible — is a frequent gap. A third mistake is conflating transparent and regenerative payloads: candidates describe "the gNB on the satellite" as if it were the Release 17 baseline, when Release 17 standardized only the transparent (bent-pipe) architecture and regenerative payloads are later work. A fourth is treating NTN as one monolithic feature rather than distinguishing NR-NTN from IoT-NTN, and GEO from LEO timing and mobility. A fifth is describing NTN mobility as ordinary handover; for LEO it is satellite-driven, with Earth-fixed vs Earth-moving beams and feeder-link switchover rather than a moving UE. Finally, candidates sometimes pull in IEEE or O-RAN framing — NTN is a 3GPP NR/IoT construct and should be paired with the right standards body.
Frequently asked questions
- What is a Non-Terrestrial Network (NTN) in 5G?
- An NTN integrates satellite or aerial access nodes — geostationary (GEO), medium-Earth-orbit (MEO), and low-Earth-orbit (LEO) satellites, plus High-Altitude Platform Stations (HAPS) — into the 3GPP 5G system so that the same NR or IoT air interface works through a space or airborne segment. 3GPP introduced NTN normatively in Release 17, defining NR-NTN (for broadband NR UEs) and IoT-NTN (NB-IoT and eMTC/LTE-M adaptations for low-rate, battery-constrained devices). The goal is coverage continuity: serving aircraft, ships, remote terrain, and IoT sensors where terrestrial cells do not reach, using the same core and largely the same protocol stack.
- What is the difference between a transparent and a regenerative payload?
- A transparent (bent-pipe) payload performs only RF functions on board — frequency conversion, filtering, and amplification — so the gNB lives entirely on the ground and the satellite is an analog relay between the UE and a ground gateway. A regenerative payload adds on-board processing (demodulation/decoding, switching/routing, and re-encoding/modulation), so all or part of the gNB runs on the satellite itself. Release 17 standardized only the transparent architecture. Regenerative payloads are part of the Release 18/19 work, and they are the enabler for store-and-forward operation, where the satellite can serve a UE and carry data even when the feeder link to the gateway is temporarily unavailable.
- How large is the propagation delay in NTN, and why does it matter?
- It depends on orbit. A GEO satellite at ~35,786 km gives a one-way end-to-end delay — UE up to the satellite and on to the ground gateway — on the order of 240–270 ms (round-trip on the order of 540 ms for a transparent path including the feeder link); the UE-to-satellite service-link hop alone is about half that, ~120–135 ms. LEO at a few hundred km is far lower, roughly 20–40 ms one-way end-to-end, but the delay changes continuously as the satellite moves. These figures dwarf the sub-millisecond round trips terrestrial NR was designed around, so timers, the random-access procedure, HARQ round-trip assumptions, and timing advance all have to be re-scoped. Terrestrial timing-advance ranges and RACH timing windows simply cannot accommodate hundreds of milliseconds without explicit NTN adaptations.
- How does a UE handle Doppler shift and timing in NTN?
- In Release 17 the UE is assumed to have a GNSS receiver. Using its own position plus broadcast satellite ephemeris, the UE computes the predictable component of the delay and Doppler and pre-compensates before transmitting — applying a timing offset to its initial PRACH and a frequency offset to counter Doppler. The network signals a common timing advance and ephemeris/feeder-link parameters so the UE can derive the full timing advance. This UE-side pre-compensation is what lets the random-access and uplink timing procedures close despite delays and Doppler that would otherwise break terrestrial assumptions; the residual error left after pre-compensation is what the network still has to absorb.
- What is IoT-NTN and how does it differ from NR-NTN?
- IoT-NTN is the adaptation of the LTE-based low-power IoT technologies — NB-IoT and eMTC (LTE-M) — to operate through satellites, targeting battery life measured in years, narrow bandwidth, and deep coverage for sensors and trackers. NR-NTN is the adaptation of the 5G NR broadband air interface for higher-rate UEs (and handsets in lower bands). Both were introduced in Release 17. They share the underlying NTN problems — large delay, Doppler, GNSS-assisted pre-compensation, link budget — but differ in air interface, target data rates, and device complexity. Release 19 extends IoT-NTN, including connection to the 5G core and store-and-forward operation for delay-tolerant IoT.
- What NTN enhancements came in Release 18 and Release 19?
- Release 18 added mobility and coverage improvements and continued the move beyond the transparent-only baseline. Release 19 introduces regenerative-payload support (gNB functions on board), store-and-forward operation so an IoT UE can be served even without a live feeder link, IoT-NTN connected to the 5G core, RedCap over NTN, and coverage in bands above 10 GHz. Across releases the recurring themes are: extending from bent-pipe to on-board processing, hardening mobility for fast-moving LEO beams and feeder-link switchover, and broadening the device classes (from NB-IoT/eMTC and full NR up through RedCap) that can use the space segment.
- How does NTN handle mobility when LEO satellites move so fast?
- In a LEO constellation the satellite — and therefore the serving beam and cell — sweeps over a fixed UE in seconds to minutes, so handovers are driven by satellite motion rather than UE motion. NTN distinguishes Earth-fixed beams (steered to keep a cell footprint stationary for a while) from Earth-moving beams (the footprint tracks the satellite). The network also has to manage feeder-link switchover, handing the gateway connection from one satellite or gateway to another without dropping the service link. This is a different mobility regime from terrestrial NR handover (see /topics/nr-handover-and-mobility), where the UE moves between mostly static cells.
Related topics
Siblings
Practice
Essential AI-Native Skills for Non-Terrestrial Networks (NTN)
Modern engineering work increasingly uses AI tools for design and code review, debugging, documentation, test and testbench generation, and workflow automation. The goal is not to let AI replace engineering judgment — it is to move faster while keeping verification discipline.
- Use AI to explain unfamiliar code, logs, waveforms, datasheets, or test failures.
- Break large problems into small, reviewable steps you can verify independently.
- Ask AI for hypotheses, then validate them against tests, measurements, simulations, or lab data.
- Version-control your analysis scripts, testbenches, and configs — keep changes small and reviewable.
- Document your assumptions, design tradeoffs, and debugging decisions.
- Verify AI output before trusting it: run the checks that fit the domain — unit tests, linters, simulations, or bench/lab measurements.
- Review AI output for correctness, edge cases, and real-world consequences.
Non-Terrestrial Networks (NTN) — coming to the question bank
The adaptive practice engine is already live for core wireless, RF, and ML systems. Non-Terrestrial Networks (NTN) isn't covered in the question bank yet — get notified when it's added.