IoT NTN — NB-IoT & eMTC over Satellite
The parallel Rel-17 track — NB-IoT and eMTC adapted for satellite for low-power wide-area IoT — and how IoT NTN differs from NR-NTN in delay tolerance, GNSS and procedures.
Not every satellite device is a smartphone. Alongside NR-NTN, Rel-17 delivered a second, parallel track: IoT NTN, which takes the two LTE-based low-power IoT radios — NB-IoT and eMTC (LTE-M) — and adapts them to work over satellite. The target is low-power wide-area, delay-tolerant machine traffic: asset trackers on shipping containers, soil sensors in a field, buoys at sea, meters in places no cell tower will ever reach. The study behind it is captured in TR 36.763, it is built on the LTE / 36-series air interface, and — unlike NR-NTN — it typically runs over EPS/EPC rather than the 5G Core. This page is IoT-NTN: what it shares with NR-NTN, where it deliberately differs, and why it earns a separate track.
Introduction
IoT-NTN is the 3GPP work that lets the two established cellular-IoT radios — NB-IoT and eMTC (LTE-M) — run over a satellite instead of a terrestrial eNB. Both radios were designed in the LTE era for massive machine-type communication (mMTC): tiny payloads, deep-coverage penetration, and battery lives measured in years. IoT-NTN keeps that design intact and simply changes the access node from a tower to a spacecraft, so the same low-cost, frugal modules keep working far outside terrestrial coverage.
It sits in the device lifecycle at exactly the same point terrestrial NB-IoT/eMTC does — attach, occasional small-data transfer, then back to deep sleep — but across a link that can add hundreds of milliseconds of delay and tens of kHz of Doppler. The study item is TR 36.763; the normative work landed in Rel-17 on the LTE (36-series) air interface and, in most deployments, on the EPS/EPC core the two radios already used on the ground.
It matters because coverage, not throughput, is the binding constraint for the mMTC market. A container tag mid-ocean or a pipeline sensor in the desert has no tower to reach; a delay-tolerant, repetition-heavy narrowband radio rides a satellite comfortably, where a full NR modem would be overkill on power, cost, and complexity.
On this page
Why IoT-NTN is needed
In plain words: think of a postcard versus a video call. A video call needs a fat, low-latency pipe and constant attention; a postcard just has to arrive eventually. IoT-NTN devices are postcard senders — they mail a few bytes now and then and can wait for delivery — so they can use a tiny, cheap, extremely power-thrifty radio and still reach across a satellite link that would choke a "video-call" modem.
Concretely, three needs drive the whole design. First, coverage everywhere: mMTC assets live where terrestrial coverage does not — oceans, deserts, farmland, remote infrastructure — so the network must reach them from space. Second, battery life measured in years: these devices are unattended and often unpowered, so the radio must sleep aggressively and wake only to send a handful of bytes. Third, cost: they ship in the millions, so reusing existing NB-IoT/eMTC chipsets, the LTE air interface, and the EPC ecosystem is far cheaper than porting everything to NR. Satellite fills the coverage gap; the low-power LTE radios keep the devices cheap and long-lived.
A satellite access mode for the LTE-based NB-IoT and eMTC radios, so delay-tolerant machine devices can attach and send small data from outside terrestrial coverage.
mMTC use cases are coverage- and battery-bound, not throughput-bound. A frugal, repetition-heavy narrowband radio over satellite matches that job far better than a full NR modem.
Reuse the NB-IoT/eMTC air interface and EPC, and borrow NR-NTN's delay/Doppler toolkit — GNSS pre-compensation, ephemeris broadcast, scheduling offsets and scaled timers.
NB-IoT and eMTC, lifted to orbit
NB-IoT and eMTC are the two cellular IoT radios 3GPP standardised in the LTE era. NB-IoT is an ultra-narrowband, extremely low-power radio for tiny amounts of data and years of battery life; eMTC (marketed as LTE-M) is a slightly richer LTE-based machine radio with more bandwidth and mobility. IoT-NTN is the work item that lets both operate through a satellite instead of a terrestrial eNB, so the same cheap, frugal devices keep working far outside terrestrial coverage.
A Rel-17 adaptation of the LTE-based NB-IoT and eMTC air interfaces for satellite access, studied in TR 36.763. It reuses the 36-series (LTE) radio, not the NR 38-series.
Massive-IoT use cases — tracking, agriculture, maritime, remote sensing — need coverage and battery life far more than throughput. Satellite fills the coverage holes; the low-power radios keep the devices cheap and long-lived.
It borrows NR-NTN's toolkit for beating delay and Doppler, but keeps the LTE numerology, the LTE SIB structure, and the EPS/EPC that NB-IoT and eMTC already used on the ground.
One line to remember: IoT-NTN = NB-IoT / eMTC over satellite, on the LTE air interface and EPC — the low-power, delay-tolerant cousin of NR-NTN.
The physical channels underneath
Both radios keep their LTE-era channel sets unchanged over satellite — that is the whole point of reuse. NB-IoT carries its downlink on NPBCH (broadcast), NPDCCH (control) and NPDSCH (shared data), and its uplink on NPUSCH (with formats F1 for data and F2 for HARQ/ACK signalling) and NPRACH (random access). Downlink uses a single 15 kHz subcarrier spacing inside the 180 kHz carrier; the uplink can be single-tone at a 3.75 kHz or 15 kHz tone spacing, or multi-tone (3, 6 or 12 tones at 15 kHz). eMTC keeps the standard LTE 15 kHz numerology but confines a transmission to a 1.08 MHz narrowband (6 PRBs), hopping between narrowbands within a wider LTE carrier. Neither adds an NR-style flexible numerology — IoT-NTN inherits LTE timing wholesale.
Where IoT-NTN differs from NR-NTN
The shared physics hides real design differences. IoT-NTN is aimed at a different job, sits on a different core, and uses a very different radio underneath. The table makes the contrast concrete.
| Dimension | NR-NTN | IoT-NTN (NB-IoT / eMTC) |
|---|---|---|
| Target | Broadband and handset direct access | Massive, low-rate, delay-tolerant IoT |
| Core network | SA 5G Core (5GC) | EPS / EPC |
| Air interface | NR (38-series) | LTE (36-series) |
| Platform emphasis | LEO/MEO/GEO; handheld in FR1, VSAT in FR2 | Often GEO (delay-tolerant); LEO also supported |
| Bandwidth | Wide NR carriers | NB-IoT: 180 kHz narrowband; eMTC: ~1.08 MHz |
| HARQ processes | Up to 32 (see ntn-harq) | NB-IoT: only 2 |
| Coverage / repetition | Beam-based, moderate repetition | Heavy repetition / coverage enhancement |
| Power saving | DRX; enhanced in later releases | Extreme — PSM and eDRX for years of battery |
A few NB-IoT specifics are worth spelling out because they explain the whole design. NB-IoT lives in a single 180 kHz narrowband. Its uplink can be single-tone (as little as a 3.75 kHz or 15 kHz tone) or multi-tone, trading rate for reach and device simplicity. It leans on heavy repetition for coverage enhancement — sending the same content many times so it decodes deep inside a building or across a satellite link. It is half-duplex (never transmitting and receiving at once), runs at much lower data rates than NR, and — the number interviewers love — has only 2 HARQ processes, against NR's up to 32. eMTC is a little richer (roughly 1.08 MHz, higher rates, better mobility) but shares the same low-power, coverage-first philosophy.
The HARQ contrast: with only 2 HARQ processes and a long RTT, NB-IoT can have very few transmissions "in flight" — which is fine, because IoT traffic is sparse and delay-tolerant. The NTN timer/offset scaling keeps those two processes from stalling on the long link.
Coverage enhancement and power saving, quantified
Two mechanisms carry most of the weight. Coverage enhancement uses repetition: eMTC defines CE Mode A (light repetition) and CE Mode B (deep coverage, up to hundreds or thousands of repetitions), while NB-IoT organises access into coverage-enhancement levels, each with its own NPRACH resource, so a device in a worse link budget automatically picks a more-repeated preamble. Repetition trades throughput for reach — exactly the right trade over a lossy satellite link. Power saving uses two features: PSM (Power Saving Mode), where the UE stays registered but becomes unreachable and shuts down almost completely between transfers, and eDRX (extended DRX), which stretches the paging cycle so the device wakes to listen only rarely. Together they are what turn "years of battery" from a slogan into a spec.
TN ↔ NTN: the NB-IoT/eMTC device is the same radio on the ground and in orbit — same channels, same PSM/eDRX, same EPC. Going to NTN adds three things and changes nothing else: GNSS becomes mandatory (for UE pre-compensation of TA and Doppler), new NTN system information appears (satellite ephemeris + common-TA in LTE SIBs, the analogue of NR SIB19), and timers/scheduling offsets are scaled to absorb the round-trip delay. A terrestrial NB-IoT device works unmodified except for those NTN additions.
Why a separate track at all
You might ask why 3GPP didn't just let NR-NTN cover everything. The answer is that IoT devices optimise for the opposite things. A soil sensor or a container tag needs years of battery from a small cell and needs to be heard from places with terrible link budgets — it does not need throughput. The NB-IoT/eMTC design — narrowband, half-duplex, repetition-heavy, delay-tolerant, with deep sleep modes — fits that job far better than a full NR modem, which is bigger, hungrier and built for capacity the IoT device will never use.
A deliberately minimal radio: little bandwidth, few HARQ processes, heavy repetition, and aggressive sleep (PSM/eDRX).
Battery life and coverage dominate over speed for massive IoT. A frugal, delay-tolerant radio matches that, and matches the long, stable delay of GEO especially well.
Reusing the LTE-based NB-IoT/eMTC design over satellite lets existing chipsets, cores (EPC) and ecosystems extend to space with minimal change — cheaper than porting everything to NR.
This is also why GEO is such a natural fit: IoT traffic tolerates the ~half-second GEO round trip without complaint, and a GEO satellite gives a fixed, always-there coverage footprint that a sleepy sensor can wake into on a schedule. LEO is supported too, but the delay-tolerant nature of NB-IoT is what makes GEO IoT so comfortable.
How IoT-NTN keeps evolving
The separate track keeps getting its own enhancements. Rel-18 extends IoT-NTN alongside NR-NTN — improving mobility and service continuity, handling discontinuous coverage (so a device in a sparse constellation can predict when a satellite is overhead and sleep through the gaps), and relaxing the GNSS burden so the receiver spends less energy re-acquiring position. Rel-19 and beyond continue in the same direction: better power efficiency, store-and-forward operation that suits an intermittently-visible satellite, and steps toward regenerative (on-board) processing. The theme never changes — squeeze more coverage and more battery life out of a deliberately minimal radio. The broader release arc is traced in ntn-evolution.
The IoT-NTN picture
Put together, the end-to-end path is simple: a frugal IoT device pre-compensates using GNSS, talks through a GEO or LEO satellite to a ground gateway, and lands on an EPC rather than a 5GC.
⚠ Common pitfalls / gotchas
- No GNSS fix, no uplink. IoT-NTN makes GNSS effectively mandatory — if the device cannot get a position (or the fix is stale beyond the ephemeris validity), it cannot pre-compensate TA/Doppler and its transmissions will land outside the receiver's window.
- Confusing the two radios. NB-IoT is 180 kHz, single-/multi-tone, half-duplex, 2 HARQ processes; eMTC is ~1.08 MHz with higher rates and better mobility. They are separate designs under one "IoT-NTN" umbrella.
- Expecting throughput. Heavy repetition buys coverage by spending data rate. Sizing an IoT-NTN link like a broadband link is the wrong mental model — it is delay-tolerant small data by design.
- Forgetting the core is EPC, not 5GC. IoT-NTN generally rides EPS/EPC, so 5GC-specific NTN behaviour (and the
AMFlocation verification of NR-NTN) does not map across one-to-one. - Timers not scaled. Reusing terrestrial NB-IoT/eMTC timer values over a long RTT stalls the (few) HARQ processes and RACH; NTN scaling and scheduling offsets exist precisely to prevent that.
Summary
IoT-NTN is the low-power cousin of NR-NTN: the LTE-based NB-IoT and eMTC radios (36-series, TR 36.763) taken over satellite, usually on EPS/EPC. It shares the satellite physics — long delay, large Doppler — and therefore reuses NR-NTN's toolkit wholesale: GNSS-based UE pre-compensation of timing and frequency, ephemeris and common-TA broadcast in LTE SIBs (the analogue of NR SIB19), and scheduling offsets with scaled timers to absorb the round trip.
Where it diverges is by design: a deliberately minimal radio — narrowband, half-duplex, repetition-heavy for coverage enhancement (eMTC CE Mode A/B, NB-IoT CE levels), only 2 HARQ processes in NB-IoT, and deep sleep via PSM and eDRX — optimised for years of battery and reachability in terrible link budgets rather than for speed. That is exactly why it earns a separate track, and why GEO suits it so well: delay-tolerant traffic rides the half-second round trip happily under a fixed coverage footprint. Rel-18 and beyond keep sharpening the same edges — mobility, discontinuous coverage, and a lighter GNSS burden.
Q. How does IoT-NTN differ from NR-NTN in target, core and radio?
A. Target: massive, low-rate, delay-tolerant IoT versus broadband/handset. Core: EPS/EPC versus the 5G Core. Radio: the LTE-based NB-IoT/eMTC (36-series) air interface versus NR (38-series). Same satellite physics, very different device and network around it.
Q. Does IoT-NTN still need GNSS and pre-compensation?
A. Yes. It faces the same long delay and large Doppler as NR-NTN, so the device uses its GNSS position plus broadcast satellite ephemeris and a common-TA term (in LTE SIBs, analogous to NR SIB19) to pre-compensate timing and frequency, and applies scheduling offsets and timer scaling to absorb the round-trip delay. In practice GNSS is effectively mandatory in an IoT-NTN device.
Q. Why is NB-IoT well-suited to GEO IoT, and how many HARQ processes does it have?
A. NB-IoT is delay-tolerant, narrowband and extremely low-power, so it happily rides GEO's ~half-second round trip and fixed coverage footprint while sleeping between rare transmissions. It has only 2 HARQ processes, versus up to 32 in NR — fine for sparse IoT traffic.
Where IoT-NTN connects
You have seen the low-power cousin of NR-NTN: same delay and Doppler, different radio and core. Step back to the big picture, drill into the timing pre-compensation it shares with NR, or look ahead to how both tracks evolve.