3GPP Release 17 NTN Explained: What Non-Terrestrial Networks Mean for IoT Devices
Your NB-IoT fleet works great, right up until it doesn’t. A shipping container crosses into open ocean. A soil sensor sits 200 km from the nearest cell tower. A pipeline monitor in northern Canada goes dark for weeks. You know the data is there. You just can’t get to it.
About 85% of Earth’s surface has zero terrestrial cellular coverage. It’s the reason your TAM has a ceiling, your telemetry has holes, and your engineering team keeps fielding requests for some kind of satellite backup link. The workaround, until recently, has been bolting on a proprietary satellite modem: a different protocol, a different chipset, a different subscription, a different headache.
3GPP Release 17 changed that. It formally added Non-Terrestrial Network (NTN) support to NB-IoT and eMTC, making satellite connectivity a native part of the cellular IoT stack. One air interface. One ecosystem. One modem (eventually).
This piece breaks down what Rel-17 NTN actually specifies, what it changes at the hardware level, what it costs on the BOM, and what it still can’t do.
What NTN Means Inside the 3GPP Architecture
Non-Terrestrial Networks, in 3GPP terms, refers to satellites (LEO, MEO, or GEO) and high-altitude platform stations (HAPS) acting as nodes in the cellular network. They’re not a separate system. They’re base stations in the sky.
Rel-17’s scope is specific: NTN support for NB-IoT and eMTC (LTE-M). The architecture is “transparent payload,” meaning the satellite is a bent-pipe relay. It receives the uplink signal from the device, shifts it in frequency, and forwards it to a ground gateway. The ground gateway connects to the core network. The satellite doesn’t process the signal; it just passes it along.
IoT Device ─── radio link ──▶ LEO Satellite (bent-pipe relay)
(NB-IoT/eMTC + GNSS) │
feeder link
│
▼
Ground Gateway
│
Core NetworkBecause NTN reuses the 3GPP air interface, chipset and module vendors can add satellite support to existing cellular silicon. That’s what makes ecosystem convergence possible, and it’s what makes the BOM conversation interesting rather than terrifying.
The Coverage Gaps NTN Actually Fills
The economics haven’t supported satellite IoT until now. Here’s what changes.
Geographic gaps are the big one. Oceans, deserts, vast agricultural land, polar regions, developing countries where terrestrial rollout doesn’t pencil out. If you’re tracking shipping containers across the Pacific, monitoring cattle on a 500,000-acre ranch, or reading utility meters scattered across rural sub-Saharan Africa, terrestrial NB-IoT simply isn’t available.
Resilience is the second angle. When terrestrial infrastructure goes down (natural disasters, conflict), satellite links keep working. Think emergency response sensors or critical infrastructure monitoring.
Cross-border continuity matters for logistics. A tracker that works on European NB-IoT, goes silent over the Atlantic, and reconnects on US LTE-M is a headache. NTN fills that mid-ocean gap.
But let’s be honest about the limits. NTN won’t replace terrestrial coverage in cities or dense suburbs. Throughput is NB-IoT class: maybe 20 to 60 kbps downlink. Latency is higher: roughly 20 to 40 ms one-way for LEO, around 270 ms for GEO. And unless the constellation is large enough, coverage can be intermittent; a LEO satellite passes overhead for a few minutes, then you wait for the next one. NTN is for sparse, delay-tolerant telemetry, not broadband.
What Changed Under the Hood in Rel-17
The engineering problems satellites introduce are real, and Rel-17 had to solve several of them at the protocol level.
Timing advance and Doppler pre-compensation. A terrestrial cell tower might be 10 km away. A LEO satellite is 600 km up, moving at 7.5 km/s. The propagation delay is 5 to 12 ms round-trip (versus microseconds for terrestrial), and the Doppler shift on the carrier frequency is significant. Rel-17 requires the device to use its own GNSS-derived position, combined with satellite orbital data, to pre-compensate for both. The device calculates where the satellite is, how far away it is, and how fast it’s moving. It then adjusts its transmit timing and frequency before sending. Of all the Rel-17 protocol changes, this one demanded the most new engineering.
HARQ modification. In terrestrial NB-IoT, the Hybrid Automatic Repeat Request feedback loop is fast: transmit, get an ACK or NACK, retransmit if needed. With satellite RTT, that loop is too slow. Rel-17 disables or modifies HARQ for NTN, relying instead on blind repetitions and other reliability mechanisms.
Satellite ephemeris broadcast and discontinuous coverage round out the major changes. The network sends orbital parameters (via SIB31) so the device can autonomously compute satellite position and velocity; without this, pre-compensation is impossible. Rel-17 also defines how devices should sleep, wake, search for satellites, and re-acquire the network when a LEO satellite comes back into view after a coverage gap.
Key Rel-17 NTN Protocol Adaptations (NB-IoT):
1. GNSS-based timing pre-compensation
Device calculates propagation delay from its position + satellite ephemeris
2. Doppler pre-compensation
Device adjusts Tx frequency using GNSS + ephemeris data
3. HARQ disabled / modified
Repetitions used instead of ACK/NACK loops
4. Satellite ephemeris broadcast (SIB31)
Orbital parameters delivered to devices over the air
5. Discontinuous coverage handling
Defined sleep/wake and re-acquisition behaviorMost of this complexity lives in the modem firmware and chipset. Your application layer doesn’t have to worry about Doppler math.
BOM Impact: What Actually Changes on the Device
Chipset and module. NTN support is a silicon and firmware feature. First-generation NTN-capable chipsets are sampling now, and several module vendors have announced NTN-ready products. In many cases, next-gen modules will support both terrestrial and NTN modes on the same die. You won’t need a separate satellite modem. But you do need to select an NTN-capable module SKU, which currently carries a modest price premium over terrestrial-only parts.
GNSS receiver: the primary BOM addition. Rel-17 NTN requires the device to know its own position. If your device already has GNSS (asset trackers, fleet devices, anything with location as a feature), you’re covered. If it doesn’t, you’re adding a GNSS receiver, GNSS antenna, board space, and power draw. Think of a static agricultural sensor or a utility meter that never had a reason to know where it was. That’s real cost and real complexity.
Antenna considerations. NB-IoT NTN operates in cellular bands (some deployments use S-band around 2 GHz, others reuse terrestrial spectrum depending on the operator). The catch: a terrestrial device antenna is typically optimized for horizontal or omnidirectional patterns. A satellite link needs sky-facing gain. Your antenna design may need adjustment, especially if the device is mounted in an enclosure that shields upward radiation. A separate GNSS antenna is also required if one isn’t already present. For teams exploring how Bluetooth-based IoT devices handle similar challenges with antenna design and transmission to non-terrestrial receivers, the Hubble transmission guidance documentation offers useful context.
Power budget. GNSS acquisition draws current. Satellite link budgets (longer path = higher Tx power or more repetitions) eat into battery life. This isn’t necessarily a BOM cost increase, but it’s a system design issue. You might need a bigger battery, or you might need to redesign your duty cycle.
Component │ Terrestrial Only │ NTN-Capable
──────────────────┼──────────────────────┼─────────────────────
Cellular Modem │ NB-IoT/LTE-M module │ NTN-capable SKU
│ │ (modest premium)
GNSS Receiver │ Optional │ Required (+ antenna)
Cellular Antenna │ Omni / PCB trace │ May need sky-facing
│ │ optimization
GNSS Antenna │ Only if tracker │ Yes (required)
Battery / Power │ Baseline │ Potentially larger
│ │ or re-evaluated
Est. BOM Delta │ --- │ Low-to-moderateThe bottom line: if your device already has GNSS, the delta is small, a module premium and maybe an antenna tweak. If your device has no GNSS today, you’re adding a component, an antenna, and power overhead. That’s a real ROI conversation: does satellite coverage for this device justify the cost?
What Rel-17 Doesn’t Solve (Yet)
Rel-17 is the foundation. It proves the architecture works. But it leaves meaningful gaps.
Continuous coverage isn’t guaranteed. It depends entirely on how many satellites the operator has in orbit. Early deployments will have windows of connectivity, not always-on links.
Store-and-forward, where a device transmits to a satellite that stores the data and delivers it later when in range of a ground station, is a Rel-18 study item. For low-Earth-orbit constellations with limited ground station coverage, this matters a lot.
Power efficiency improvements and regenerative payloads (on-board processing on the satellite, so it’s no longer just a bent pipe) are Rel-18 and Rel-19 topics. So is better roaming and inter-operator handover for NTN.
Think of Rel-17 as the proving ground. It’s enough to build on, but the ecosystem will look substantially different by Rel-19. Decision-makers should factor that trajectory into their timelines. If you’re interested in how IoT connectivity is evolving across both terrestrial and satellite paths, the Hubble Network satellite documentation provides a complementary perspective on non-terrestrial approaches.
Act Now or Wait?
Here’s a simple framework.
Act now if your use case is actively blocked by coverage gaps today, your device already includes GNSS, and you’re designing hardware for a 2025 or 2026 launch. Selecting an NTN-capable module now costs you a small premium and buys you satellite readiness without a redesign later.
Watch and plan if your current deployments are terrestrial-sufficient, your device has no GNSS, or your cost sensitivity makes even a few dollars of BOM increase prohibitive. But start factoring NTN into your 2 to 3 year product roadmap. The standard is ratified. Chipsets are sampling. Constellations are going up.
The question isn’t whether 3GPP NTN will matter for IoT. The question is whether the coverage gap you’re living with today is painful enough to justify moving now, or whether you can afford to wait for the ecosystem to mature through Rel-18 and beyond.
Hubble Network enables Bluetooth IoT devices to connect directly to satellites—no GNSS, no NTN module, no hardware redesign required. See how it works →