What is 3GPP NTN?
3GPP NTN comprises specifications that adapt cellular standards for satellite links, allowing standard cellular chipsets to connect via spacecraft. It covers two main tracks: NB-IoT and LTE-M for low-power devices, and 5G NR for handsets and broadband applications. The adaptations primarily address the challenges introduced by satellite links, including long propagation delays, significant Doppler shifts, and cells that move across the ground as the spacecraft travels.
The five releases, at a glance
| Release | Frozen | Payload model | What it added |
|---|---|---|---|
| Rel-17 | March 2022 | Transparent (bent-pipe) only | First normative NTN; NR-NTN and IoT-NTN; bands n255, n256; GNSS mandatory |
| Rel-18 | 2024 | Transparent | Band n254; Ka-band n510/n511/n512; TN to NTN mobility, conditional handover, IoT power saving |
| Rel-19 | December 2025 | Regenerative permitted | Full base station on satellite, inter-satellite links over Xn, store-and-forward, uplink capacity gains, RedCap for NTN |
| Rel-20 | Stage 2 targeted Sept 2026, Stage 3 March 2027 | Both | Studying GNSS-resilient operation; voice over NB-IoT NTN including GEO |
| Rel-21 | 6G specs expected from ~2029 | Both | NTN native to 6G rather than retrofitted |
Release 17: the baseline
Rel-17 was functionally frozen in March 2022 and is the first 3GPP release containing normative, certifiable specifications for satellite access. 3GPP draped the standard over the mobile satellite service allocations, which is why operators could offer NTN service without launching anything new.
It assumed a transparent payload. The satellite is a mirror: it receives, shifts frequency, amplifies and retransmits, while the base station stays on the ground. This kept the spacecraft simple and let operators launch standards-based service on satellites they already had in orbit.
Split into two tracks. IoT-NTN adapts NB-IoT and LTE-M for sensors, trackers and messaging. NR-NTN adapts 5G NR for handsets and broadband. They are different chipsets, different power budgets and different networks. Nearly every live commercial NTN service today is on the IoT-NTN side.
GNSS mandatory in the terminal. Because a LEO satellite moves at kilometres per second, the terminal pre-compensates its own uplink timing and frequency using its GNSS position plus the satellite’s broadcast ephemeris. Rel-17 also brought the satellite channel models, an extended random-access procedure sized for satellite propagation delay, and support across LEO, MEO and GEO orbits plus high-altitude platforms.
The bands introduced here are the ones most live services use: n255 (uplink 1626.5 to 1660.5 MHz, downlink 1525 to 1559 MHz) and n256 (uplink 1980 to 2010 MHz, downlink 2170 to 2200 MHz), both frequency-division duplex.
Release 18: further band
It added n254 (terminal transmit 1610 to 1626.5 MHz, satellite transmit 2483.5 to 2500 MHz), the allocation associated with Globalstar’s spectrum. It extended NTN into FR2 Ka-band with n510, n511 and n512, all sharing a 17.7 to 20.2 GHz downlink against uplinks spanning 27.5 to 30.0 GHz, aimed at VSAT terminals on aircraft and vessels rather than handhelds. Alongside that came genuinely useful protocol work: neighbour-cell information exchanged across the terrestrial and satellite domains, conditional handover, uplink coverage improvements, network-based location verification, and power saving for IoT devices living in discontinuous coverage.
Release 19: the network moves into orbit
Rel-19 was frozen in December 2025 and is the most architecturally significant release since the first.
Regenerative payloads. The satellite may now carry a complete base station rather than acting as a repeater, with inter-satellite links. Traffic can be routed between satellites in orbit instead of dropping to a gateway at every hop.
Store-and-forward. All or part of the core network functions can sit on the satellite alongside the base station, so an IoT service keeps working even when the feeder link to the ground is unavailable. For anyone building genuinely global small-data services, this quietly removes the coverage holes that bent-pipe designs always had over oceans and poles.
Capacity and device-class work. The release improves uplink capacity in FR1-NTN using overlaid repetitions with orthogonal cover codes, adds half-duplex frequency-division duplex support, and brings uplink capacity enhancements and time-division operation to NB-IoT NTN. It also extends multicast and broadcast services to NTN with service-area signalling, and takes early steps toward reducing the GNSS dependency.
What feature is in firmware and what is in silicon
This table describes the potential to integrate it into an exisitng prodcut via firmaware update, or redesign of the h=ardware is required.
| Capability | Reachable by firmware? | Why |
|---|---|---|
| Band coverage (n255, n256, n254, Ka, Ku) | No | Front end, filters, power amplifier, antenna |
| Power class | No | Amplifier and thermal design |
| FR2 (Ka or Ku) operation | No | An entirely different radio |
| Half-duplex versus full-duplex FDD | No in general | Transceiver architecture |
| RedCap or eRedCap device class | No | Bandwidth and receive-chain capability |
| Store-and-forward behaviour | Yes | Scheduling and protocol logic |
| Extended timers, HARQ process count | Yes | Baseband firmware |
| Conditional handover, TN to NTN mobility | Yes | Radio resource control procedures |
| Multicast and broadcast reception | Usually | Protocol, given sufficient receive capability |
| GNSS-independent initial access | Partly | A procedure change, but search and correlation capability may bound it |
Bands, power class and duplex mode are decided here and cannot be patched later. Photo by ed br on Pexels.
Release 20 and the road to 6G
Rel-20 is the bridge release, and two of its work items matter to device architecture.
The first is resilience when GNSS is not trustworthy. Rel-20 assesses the impact of not relying on GNSS for initial access and connected-mode procedures, with a decision following a one-year study. Given that GNSS jamming and spoofing are routine in several regions, and given that an NTN terminal cannot attach at all without a valid fix, this is the single most consequential open item for anyone shipping into contested environments.
The second is voice over NB-IoT NTN, including over geostationary satellites, which requires confronting both the latency and the weak link budget head-on.
Rel-20’s schedule to freeze in mid-2027. Rel-21 then carries the first normative 6G specifications, with the protocol freeze not expected before 2029 and initial 6G specifications landing around the end of that year. The important design point is not the dates but the intent: in 6G, NTN is meant to be native rather than an adaptation layer bolted onto a terrestrial standard.
Frequently asked questions
What did Release 17 standardise for NTN?
Release 17, frozen in March 2022, delivered the first normative support for satellite access. It supports transparent bent-pipe payloads, defines the NR-NTN and IoT-NTN tracks, and introduces the n255 and n256 frequency bands. The release covers LEO, MEO, and GEO satellite orbits as well as high-altitude platforms, extends the random-access procedure to account for satellite propagation delays, and requires the terminal to have a GNSS receiver.
What is the difference between NB-IoT NTN and NR-NTN?
NB-IoT NTN targets sensors, trackers, and messaging applications, providing data rates of up to tens of kilobits per second over a 180 kHz carrier, with a focus on multi-year battery life. NR-NTN targets handsets and broadband applications, offering megabit-class data rates over much wider carriers while maintaining phone-class power consumption. The two tracks use different chipsets and network architectures. In commercial deployments today, most operational NTN services are on the NB-IoT side.
What is the difference between a transparent and a regenerative payload?
A transparent payload simply relays the signal: it receives, frequency-shifts, amplifies, and retransmits it, with all base-station intelligence remaining on the ground. A regenerative payload, by contrast, demodulates and processes the signal on board, effectively placing a base station in orbit and enabling capabilities such as routing between satellites. Release 17 supported transparent payloads only, while Release 19 introduced support for regenerative operation.
Does a 3GPP NTN device need GNSS?
Under Release 17, yes. The terminal uses its GNSS position together with broadcast satellite ephemeris to pre-compensate uplink timing and frequency before transmission. As a result, a valid GNSS fix is required for initial access. Release 19 takes early steps toward reducing this dependency, while Release 20 is studying operation when GNSS is unavailable or degraded. The GNSS requirement should therefore be treated as a Release 17 requirement with a limited shelf life, rather than a permanent characteristic of NTN.
Will 6G include NTN natively?
That is the stated intent. Release 21 is expected to carry the first normative 6G specifications, with the protocol freeze not expected before 2029 and initial specifications emerging around the end of that year. Rather than adapting a terrestrial standard for satellite access afterwards, 6G is intended to incorporate non-terrestrial access as a native part of the architecture from the outset.