The 3GPP Non-Terrestrial Networks (NTN) Revolution: Why Satellite IoT Is Finally Standardizing

A sensor node in remote out-of-cellular coverage area.

The 75% Problem

Roughly three-quarters of the Earth’s landmass has no terrestrial cellular coverage, and if you include oceans, the connected surface of our planet is closer to a rounding error than a global network. For two decades, the IoT industry has quietly tolerated this fact. Smart metering, fleet tracking, pipeline monitoring, environmental sensing, entire categories of applications have been designed around the assumption that most devices, most of the time, will be unreachable.

That assumption is about to break. Not because a single company launched the biggest constellation, or because a chipset vendor shipped a magical new radio, but because something far less glamorous finally happened: the standards bodies caught up.

This is the story of how closed, proprietary satellite IoT systems quietly died, how 3GPP Release 17 turned NB-IoT into a satellite protocol without requiring IoT developers to care about orbital mechanics, and how a single Nordic Semiconductor module running Zephyr RTOS now collapses this entire stack onto a chip the size of a fingernail.

The Swarm Obituary: A Cautionary Tale

In July 2021, SpaceX acquired Swarm Technologies for $524 million. Swarm had built something genuinely impressive: a 150-satellite VHF constellation of 0.25U SpaceBEE picosatellites, an ingenious low-power modem called the Tile, and a service plan starting at $5 per device per month. For a brief window, Swarm was the answer to every maker, agritech startup, and environmental monitoring project that had ever been stuck outside cellular coverage.

Then, almost exactly two years later, the entire platform was effectively dead.

• July 2023: New device sales halted.
• September 2024: End-of-life notice issued to existing customers.
• March 2025: The commercial service was officially discontinued; the swarm.space domain now forwards to SpaceX's Direct-to-Cell marketing page.

Customers — many of whom had designed Swarm Tiles into products with ten-year lifecycles — were given no automatic migration path. They were told, bluntly, that hardware replacement and software rework were their problem. Forest-fire detection startups, illegal-logging monitors, remote livestock trackers: every one of them had to re-architect.

Swarm wasn’t a bad product. It was a business model problem dressed up as a technology problem. And that distinction matters enormously.

Why Proprietary Satellite IoT Cannot Survive

Swarm’s trajectory isn’t an outlier — it’s the expected outcome for any closed-loop satellite IoT platform. Four structural forces converge against these systems:

1. Single points of failure at the constellation level. LEO satellites deorbit. A proprietary constellation has to continually re-launch replacement satellites to maintain service. If the parent company pivots, gets acquired, or simply runs out of runway, the spectrum licenses may survive but the service evaporates. Your devices become very expensive plastic.

2. Vertical lock-in. Proprietary systems tie hardware, modem firmware, spectrum, ground infrastructure, and billing to one vendor. That’s excellent margin for the vendor and terrible leverage for the customer. There is no secondary market, no dual-sourcing, no RFQ process.

3. No ecosystem economics. Cellular economics work because every bit of R&D — RF front-ends, protocol stacks, certification infrastructure, test equipment — is amortized across billions of devices. A 150-satellite constellation with “hundreds of customers in 15 countries,” as Swarm described itself, can never match that curve. Custom silicon is expensive. Custom silicon for a niche market is ruinous.

4. Regulatory fragility. Swarm itself famously launched its first four satellites without FCC authorization and was fined $900,000. That’s a footnote in history books now, but it’s a preview of the kind of friction that individual operators face relative to industry-wide standards bodies with established regulatory relationships.

Every generation of satellite connectivity has learned this the hard way. Iridium’s original bankruptcy. Globalstar’s slow decline. Orbcomm’s pivots. The pattern is ruthless: proprietary satellite systems survive just long enough for the standards to catch up and eat them.

And this time, the standards are here.

Proprietary and standardized NTN comparison

3GPP Release 17: Standardizing the Sky

In March 2022, 3GPP functionally froze Release 17 — the first 3GPP release to contain normative (i.e., binding, certifiable) specifications for satellite access. Two parallel tracks were defined:

• NR-NTN: 5G New Radio adapted for satellite, aimed largely at direct-to-handset voice, messaging, and broadband-adjacent services.
• IoT-NTN: NB-IoT and LTE-M adapted for satellite, aimed at the massive, low-power, delay-tolerant IoT market.

The distinction matters. IoT-NTN is not a watered-down NR-NTN; it is a deliberately minimal adaptation of NB-IoT and LTE-M, scoped specifically for devices that need years of battery life, tiny bandwidth, and deep coverage — the exact profile Swarm was chasing, but now expressed as an open, multi-vendor standard.

Release 17 assumes a transparent (“bent-pipe”) payload architecture: the satellite is essentially a relay, and the full eNB/gNB intelligence lives on the ground. This was a smart early choice — it means legacy core networks and existing cellular infrastructure can be reused with modest changes — and it’s the architecture Release 18 and 19 are now extending (with regenerative payloads, store-and-forward operation, and coverage above 10 GHz in Release 19).

But the genuinely interesting engineering happened at the air interface, because the gap between “a cell tower 5 km away” and “a satellite 600 km up moving at 7.5 km/s” cannot be bridged without real protocol work.

The Technical Gymnastics of NB-IoT over Satellite

Four physical realities make satellites fundamentally different from terrestrial radio access:

1. Propagation delay. A LEO satellite introduces a round-trip delay of roughly 10–25 ms. A GEO satellite pushes this to around 540 ms round-trip. NB-IoT was originally designed around terrestrial timing assumptions, where propagation is effectively instantaneous. Release 17 had to extend the timing advance range by orders of magnitude and re-time every scheduling relationship that previously assumed sub-millisecond latency.

2. Doppler shift. A LEO satellite moving at 7.5 km/s imposes carrier frequency shifts of tens of kilohertz — comparable to, or larger than, the entire NB-IoT narrowband channel width. Without compensation, the uplink would simply miss the receiver’s filter.

3. Wide beam footprints. A single LEO beam can cover hundreds of kilometers on the ground. Devices within that beam experience wildly different delays and Doppler shifts at the same moment. There is no single value the network can broadcast to correct all users uniformly.

4. Discontinuous coverage. Unlike a cell tower, a LEO satellite is overhead for only a few minutes at a time. NB-IoT needed to gracefully handle “there is no network right now, come back in 47 minutes.”

Release 17 solves these with a set of mechanisms that are elegant once you understand the constraints:

Massive propagation delay → Solved with extended timing advance, where the UE pre-compensates its transmit timing using its own GNSS fix and SIB31 ephemeris data.

Large Doppler shift → Addressed by UE-side frequency pre-compensation using GNSS position and satellite orbital data, eliminating the need for per-user network correction.

Long round-trip breaks HARQ → Handled by disabling or restructuring HARQ feedback loops and relying on blind retransmissions instead of ACK/NACK turn-arounds.

Discontinuous coverage → Managed through defined UE behavior for sleep, re-acquisition, and operation within sched3uled satellite pass windows.

Ephemeris distribution → Enabled via SIB31, which broadcasts satellite orbital parameters over the air.

Two things deserve emphasis here:

• GNSS is mandatory on the UE. Release 17 IoT-NTN devices are assumed to have a GNSS receiver and to use it to pre-compute their own delay and Doppler corrections. This shifts complexity from the network to the device, but it also means the network architecture stays clean and standard.
• Your application layer never sees any of this. Every mechanism described above lives in modem firmware and silicon. From the application’s point of view, you are still opening a UDP socket over NB-IoT. The satellite is invisible. That is the whole point.

Time (frequency) compensation on LEO satellites and modern NTN technology

The nRF9151: A Standard Incarnate in Silicon

Standards are nothing without silicon that implements them at commercial scale. This is where Nordic Semiconductor’s nRF9151 enters the story.

The nRF9151 is a System-in-Package (SiP) that is physically 20% smaller than its predecessor (nRF9160), drops the Power Class 5 (20 dBm) output option alongside the existing Class 3 (23 dBm), and — critically — integrates the modem firmware, GNSS receiver, Arm Cortex-M33 application core, TrustZone-based security, and 1 MB flash / 256 KB RAM onto a single module that can sit directly on a sensor’s PCB.

The interesting part isn’t the footprint. It’s the mode matrix:

• LTE-M (terrestrial)
• NB-IoT (terrestrial)
• NB-IoT NTN (satellite, 3GPP Release 17 compliant)
• DECT NR+
• GNSS

One RF front-end, one modem, one firmware stack. The same silicon that connects your asset tracker to a cell tower in Frankfurt connects it to a Sateliot LEO 5G IoT satellite over the Atlantic, with no developer intervention and no code change. The device is told, essentially, “use whatever network is available” — and whether that network is a tower or a satellite becomes an infrastructure concern, not a product concern.

Nordic has now publicly demonstrated the nRF9151 on multiple standards-compliant NTN networks:

• Sateliot (LEO 5G IoT constellation, October 2025)
• OQ Technology (LEO, December 2025)
• Skylo (GEO satellite IoT service)
• Myriota HyperPulse (3GPP 5G NTN, certified November 2025)

This is the tell. A single commercially available module, running one firmware image, is being certified across multiple independent satellite operators. That is exactly what standardization is supposed to produce — and exactly what no proprietary system ever could.

nRF9151 SiP

Zephyr RTOS: The Connective Tissue

Hardware standardization is necessary but not sufficient. The second half of the story is software, and here the open-source world has quietly done something that the cellular industry struggled with for years: it built a single, credible, vendor-neutral RTOS for constrained IoT devices.

Zephyr RTOS — a Linux Foundation project — has, over the last several years, become the de facto embedded operating system for the cellular IoT space. Nordic Semiconductor has been the single largest contributor to Zephyr, responsible for roughly a quarter of all commits, and Nordic’s entire nRF Connect SDK is built on a downstream fork of Zephyr.

What this means in practice:

• The same build system (west, CMake, Kconfig, DeviceTree) that describes a Bluetooth LE peripheral describes an NB-IoT NTN sensor.
• Zephyr’s networking stack (IPv4/IPv6, UDP, TCP, CoAP, LwM2M, MQTT, DTLS via Mbed TLS) sits unchanged above the modem’s LTE/NTN interface. The socket API doesn’t know it’s talking to a satellite.
• MCUboot provides a standard secure bootloader and a standard over-the-air update mechanism — the same one you’d use on a terrestrial device. This matters enormously for satellite deployments, where physical service visits are either impractical or prohibitively expensive.
• Trusted Firmware-M and Arm TrustZone provide a non-vendor-specific security foundation. Your device identity, keys, and attestation aren’t tied to a single satellite operator’s infrastructure.

Put simply: a developer building an NTN-capable asset tracker in 2026 writes essentially the same Zephyr application they would have written for a terrestrial LTE-M tracker in 2022. The modem handles timing advance, Doppler pre-compensation, ephemeris tracking, and the mode switch between terrestrial and non-terrestrial networks. Zephyr handles everything from the socket upward. The application itself handles sensor reading, power management, and business logic.

That is the quiet revolution. Not a new satellite, not a new modem, but the collapse of “satellite IoT” as a distinct category.

What Builders Should Actually Take Away

Strip out the acronyms and the implication for anyone building a connected product in the next three years is surprisingly concrete:

• Stop designing around coverage maps. The question “will my device work in the Sahara / mid-Pacific / Patagonian steppe?” has the same answer it has for a smartphone: “yes, eventually, with some caveats about data rate and latency.” If your product’s coverage assumptions were written before 2024, revisit them.
• Go with standardized satellite stacks for new designs. The Swarm episode is not going to be the last one. If you are picking a satellite IoT platform in 2026 and it is not 3GPP-compliant, you are making a bet against standardization that the entire history of cellular suggests you may lose.
• Design for dual-mode by default. The right architectural assumption is that your device sometimes sees a terrestrial network and sometimes sees a satellite, and you don’t know which in advance. Release 17 was designed with exactly this assumption.
• Budget for GNSS and pre-compensation. NB-IoT NTN devices must have a GNSS receiver. That changes your power budget, your antenna planning, and your time-to-first-fix assumptions. Modules like the nRF9151 integrate this, but it’s a constraint to be aware of.
• Treat data rate realistically. NB-IoT NTN is perhaps 20–60 kbps downlink in ideal conditions, with LEO one-way latencies around 20–40 ms and GEO around 270 ms. This is a telemetry technology, not a streaming technology. Designs that respect this will thrive; designs that try to pretend otherwise will suffer.

The Horizon: Release 18, 19, and Beyond

Release 17 is the floor, not the ceiling. 3GPP has already frozen Release 18 (which adds NTN coverage enhancements, mobility procedures between terrestrial and non-terrestrial networks, and work toward higher-frequency Ka-band deployment) and Release 19 (which introduces NB-IoT/eMTC NTN in 5G core, Store-and-Forward satellite operation for truly delay-tolerant IoT without a live feeder link, RedCap over NTN, and early work on regenerative payloads where the gNB runs on the satellite itself).

Release 20 will bundle 5G-Advanced NTN features with early 6G studies, and Release 21 is expected to deliver the first normative 6G specifications — with NTN integrated from the start rather than bolted on late.

The strategic takeaway is not that satellite IoT is coming. It’s that the industry has chosen its architecture, and that architecture looks a lot like cellular: standardized, multi-vendor, interoperable, certified, boring. For builders, this is the best possible outcome. “Boring” is what you want under a product that ships millions of units and stays in the field for a decade.

The era of the eulogy for proprietary satellite IoT hasn’t ended. Swarm was the first, not the last. But for the first time, there is a credible, open, standards-based alternative underneath the obituaries — and a single chip running an open-source RTOS is enough to access it.

That is the part worth paying attention to.

References

On the 3GPP NTN Standards

• 3GPP, Release 17 Overview — Official summary of the release that first standardized NTN.
• 3GPP, Non-Terrestrial Networks (NTN) Overview — Consolidated view of IoT-NTN work items across Releases 17, 18, and 19.
• Ericsson Technology Review, Promising new 3GPP technology for satellite communication — Primary-source technical explanation of Release 17 NTN from a lead contributor.
• Ericsson Technology Review, Satellite direct to device: 4G or 3GPP NTN? — Side-by-side of NR-NTN vs. IoT-NTN design choices.
• FirstNet Authority, 3GPP completes Release 19, while progress begins on 6G work — Well-organized summary of post-Release-17 NTN trajectory.

On the Swarm Shutdown

• TechCrunch, SpaceX’s Swarm Technologies is halting new device sales — Original July 2023 report.
• Wikipedia, Swarm Technologies — Consolidated timeline covering the illegal 2018 launch, FCC fine, SpaceX acquisition, and March 2025 service termination.
• Hackster, Death of a Satellite Swarm — Developer-perspective retrospective by Alasdair Allan.

On the nRF9151 and Carrier Certifications

• Nordic Semiconductor, nRF9151 product page — Official module specifications.
• Nordic Semiconductor, Direct NTN LEO satellite connectivity with OQ Technology — December 2025 demonstration announcement.
• Gatehouse Satcom, LEO Satellite IoT Breakthrough with Sateliot — October 2025 Sateliot / Nordic / Gatehouse announcement.
• Myriota, Nordic nRF9151 Certified for HyperPulse 5G NTN Network — November 2025 certification announcement.
• CNX Software, nRF9151 SMA DK development kit overview — Independent write-up of the development kit.

On Zephyr RTOS and the nRF Connect SDK

• Zephyr Project, Official project homepage — Upstream RTOS.
• Nordic Semiconductor, Nordic Semiconductor and the Zephyr Project — Nordic’s contribution history and SDK architecture.
• Byte Lab, From nRF5 SDK to nRF Connect SDK: Why Nordic Chose Zephyr — Independent practitioner’s view of the platform transition.

Hands-On / Practical

• Monogoto, Connecting the Nordic nRF9151 to Skylo NTN — Step-by-step walkthrough with actual AT commands.