NTN Overview

Non-Terrestrial Network (NTN) connectivity lets a Particle device stay reachable in places where cellular coverage simply does not exist. This guide explains what NTN is, how Particle delivers it through the M635e and the Skylo satellite network, what it can and cannot do, how the demo behaves out of the box, and how to troubleshoot the most common issues. By the end you should know whether NTN fits your product and how to get a device publishing from the field.

1. Introduction to NTN and IoT

Non-Terrestrial Network (NTN) communication is connectivity that reaches a device through satellites rather than through ground-based cell towers. "NTN" is an umbrella term that covers several different technologies and services with very different capabilities.

The NTN landscape

Three terms come up constantly, and they are not interchangeable:

• IoT-NTN: NB-IoT and eMTC (LTE-M) adapted to run over satellite, standardized in 3GPP Release 17. It is a deliberately minimal, low-power, low-data-rate profile built for sensors, trackers, and remote monitors that need years of battery life and send only small amounts of data.
• NR-NTN: 5G New Radio over satellite, also introduced in Release 17. It targets handsets and higher-bandwidth use cases such as satellite voice, messaging, and broadband-adjacent data, at much higher throughput and power than IoT-NTN.
• D2D / D2C (direct-to-device / direct-to-cell): a service category rather than a single standard. These services let devices, often unmodified consumer phones, connect straight to satellites. A given D2C service may be built on NR-NTN, on LTE waveforms reusing a carrier's spectrum, or on proprietary technology. Starlink Direct to Cell and AST SpaceMobile are examples.

What this guide covers

This guide covers Particle's implementation of IoT-NTN: NB-IoT over Skylo using the M635e. The device's terrestrial path is LTE Cat M1 (LTE-M), and its satellite path is NB-IoT NTN over Skylo's network.

How this compares to NR-NTN and direct-to-cell

It is easy to look at the M635e, file it next to Starlink-style direct-to-cell service, and assume it is simply a slower version of the same thing. It is not. It is a different standard profile, device class, radio path, and workload. The table below sets Particle's IoT-NTN service beside NR-NTN and direct-to-cell so you can see where the differences actually are.

Dimension	Particle IoT-NTN (M635e over Skylo)	NR-NTN (5G over satellite)	Direct-to-cell (D2C) phone services
Intended device and use case	Purpose-built low-power IoT: sensors, trackers, and remote monitors sending sparse telemetry and heartbeats	5G handsets and terminals: satellite voice, messaging, and broadband-adjacent data	Unmodified consumer smartphones: emergency messaging, SMS, and increasingly voice and data
Underlying standard	3GPP Release 17 NB-IoT NTN	3GPP Release 17 NR-NTN (5G New Radio), evolving in later releases	A service category rather than a single standard; may use NR-NTN, LTE waveforms over carrier spectrum, or proprietary methods
Chipset and hardware	An NB-IoT NTN capable, Skylo-certified modem (for example Sony ALT1250, Qualcomm 212S or 9205S, Nordic nRF9151, or MediaTek MT6825), plus an NTN antenna and GNSS	A 5G NR NTN capable modem in a handset or terminal, usually with the device's built-in antenna	The phone's existing modem and antenna; no special hardware for the user
Spectrum, antenna, and certification	Licensed MSS spectrum (L-band); a dedicated NTN antenna; chipset, module, and device certified through Skylo's program	Sub-3 GHz FR1 NTN bands today, with higher bands added in later releases; device antenna; certified per network	Reuses a mobile carrier's terrestrial spectrum; the phone's built-in antenna; certification handled between the operator and phone makers
Data profile	Tiny payloads and low throughput (NB-IoT class, roughly tens of kbps); infrequent messages. Particle's service caps NTN traffic at 256 bytes and one message per 30 seconds	Higher throughput; for handhelds on the order of tens of Mbps down and hundreds of kbps up	Higher and growing; messaging first, with data and voice being phased in
Latency and delivery	Higher latency; asynchronous, delay-tolerant delivery	Depends on orbit, lower on LEO; targets interactive handset use such as voice and messaging	Lower latency where LEO constellations are used; aims for near-real-time phone use
Power consumption	Very low; designed for multi-year battery life	Higher; handset-class 5G radios	Normal smartphone power; the phone transmits harder to reach the satellite
Mobility and coverage	Best for stationary or slow-moving assets; coverage where Skylo operates	Mobile handsets and terminals; coverage emerging	Built for mobile handsets; coverage expanding by provider and country
Network and operator availability	Skylo's NTN service via Particle; commercially live in North America and Europe and expanding	Emerging; limited commercial deployments as of 2026, often via mobile-operator and satellite partnerships	Carrier-tied: for example Starlink Direct to Cell with T-Mobile (live), AST SpaceMobile with AT&T and Verizon (deploying)
Example supported devices	Purpose-built NTN devices and modules such as the Particle M635e	Emerging 5G NTN handsets and terminals	Specific recent smartphone models per provider (around 60 models for Starlink Direct to Cell as of 2026)

What NTN support requires

NTN support is a hardware and certification matter, not just a firmware feature. Reaching a satellite network takes more than a device having a cellular modem:

• The chipset must implement the specific NTN standard in use. For Particle's service that is NB-IoT NTN, and the modem must also support the satellite operator's frequency bands (Skylo uses licensed MSS spectrum in L-band).
• The module, antenna, firmware, SIM or eSIM profile, and complete device may all need to be certified for the satellite provider. Skylo, for example, runs a formal certification program that covers chipsets, modules, and finished devices.

Because of this, NTN capability is tied to specific certified modems and modules rather than being something any cellular device can do, and different NTN standards and services support different chips and device classes. The M635e uses a Skylo-certified NB-IoT NTN modem, which is what lets it attach to Skylo's network.

Where NTN fits your product

NTN is about coverage, not speed. Particle's IoT-NTN service extends asset tracking and monitoring to remote places where cellular coverage does not reach: deserts, large agricultural land, mountain ranges, and disaster zones where terrestrial infrastructure is absent or has gone down. If a deployment has gaps where devices currently go dark, NTN is how you close them.

The right way to think about it is sparse telemetry and device heartbeats, not continuous streaming. Typical fits include:

• Environmental monitoring (weather, water level, soil, air quality) at sites with no cellular service.
• Remote asset tracking across regions and borders, including the coverage gaps between terrestrial networks where a tracker would otherwise go silent.
• Agricultural sensors spread across land far larger than any single cell can cover.
• Critical-infrastructure heartbeats and resilience links that keep reporting when terrestrial networks fail.

When to reach for NTN

NTN is not a drop-in replacement for LTE. It is engineered for small, infrequent messages and for resilience in remote locations, not for high-throughput, always-on connectivity.

Good fits: periodic telemetry, status heartbeats, alerts, and last-resort fallback when cellular is unavailable.

Poor fits: firmware delivery over satellite, video or image upload, real-time control loops, chatty protocols, and any workload that assumes a constant high-bandwidth link.

Design for NTN as the resilient, low-rate path, and let cellular carry the heavy traffic where it is available.

A note on terminology

For the rest of this guide, "NTN" is shorthand for Particle's IoT-NTN service over Skylo. The capabilities, limits, and behaviors described from here on are specific to that service. Do not assume they apply to NR-NTN or to direct-to-cell services, which can differ substantially.

2. How it Works

Particle NTN keeps the developer experience inside the Particle ecosystem while the transport underneath travels through space. The end-to-end path looks like this:

Particle device (M635e) ➔ 3GPP Release 17 satellite network (via Skylo) ➔ ground station and core network ➔ Particle Cloud

Here is what happens at each hop:

1. The device. The M635e is an M-SoM with NTN support. It runs Device OS and carries an eSIM provisioned with both an LTE profile and an NTN profile, so a single module can operate on cellular, on satellite, or switch between them. Release 17 NTN requires the device to know its own position before it can attach to the satellite network. The M635e acquires this location either during the final step of setup or via a GPS fix from its internal GNSS radio, and uses it to attach. (The M635e NTN blueprint currently uses only the fixed coordinates set during setup for NTN attachment.)
2. The satellite. Release 17 IoT-NTN uses a transparent, or "bent-pipe," architecture. The satellite acts as a relay in the sky rather than a full base station in orbit. It receives the device's uplink and passes it down to the ground. Because Release 17 reuses the 3GPP cellular air interface and adds NTN-specific features such as GNSS-based timing advance and Doppler pre-compensation, module vendors can build NB-IoT NTN support into cellular-class silicon, provided that silicon supports the operator's satellite bands and is certified for the network. The M635e uses a Skylo-certified NB-IoT NTN modem.
3. The ground station and core. The real network intelligence lives on the ground. The Skylo network terminates the radio link, runs the base station and core functions, and hands the data off toward its destination.
4. The Particle Cloud. From there, the message lands in the Particle Cloud exactly like any other event. Your integrations, webhooks, and the Particle Console see NTN events the same way they see cellular events.

Seamless inside the Particle ecosystem

Despite the orbital routing, you do not write satellite-specific application code. The blueprint exposes a single publish abstraction that routes a message to the LTE or NTN stack based on the device's current operating mode, and it centralizes rate limiting, payload sizing, retries, and logging in one place. You publish, the Particle Cloud receives, and the Console shows the event. The orbital mechanics stay below your application.

In a real deployment the M635e typically runs in a hybrid pattern: LTE as the primary path, with NTN as the fallback when LTE fails to deliver. The device monitors publish success, and if no successful LTE publish occurs within a configured timeout (15 minutes by default), it switches the eSIM to the NTN profile, attaches to the satellite network, and continues publishing. It periodically retries LTE and returns to cellular once it is available again.

3. NTN Capability and Restrictions

The limits in this section are specific to Particle's IoT-NTN service over Skylo, and they come from the physics of the satellite link and from shared bandwidth. Other NTN services, such as NR-NTN or direct-to-cell, can behave differently. It helps to design for these constraints from the start.

Constrained pub/sub

Message payloads must be small, and the chatty, multi-round-trip handshakes typical of general-purpose messaging protocols are streamlined for the satellite path.

• The NTN payload limit is 256 bytes per message. Pack your data tightly. Prefer compact binary or fixed-field encodings over verbose JSON, and send only what the cloud cannot infer on its own.
• Expand abbreviated data in the cloud with Logic. A device can publish short, abbreviated field names to stay within the 256-byte limit, and a Logic function can expand them into full, readable keys before the data is passed to an external service. The Logic-to-webhook path is not bound by the on-device event size limit, so this keeps the satellite payload small without constraining what your downstream services receive.
• Publishes, subscribes, and vitals all travel over the same constrained path and are all rate limited on NTN.

Budget every byte

Treat 256 bytes as a hard design constraint, not a target. A well-packed status message (location, a few sensor readings, a battery figure, a status code) fits comfortably. A pretty-printed JSON object usually does not.

Constrained vitals only

Device vitals (the diagnostic data Particle devices normally report) are stripped down or sent less frequently over NTN to conserve bandwidth and battery. Expect a reduced vitals picture compared to a cellular device, and configure vitals timing deliberately rather than assuming the cellular cadence.

Latency

NTN latency is higher than standard cellular, and communication is asynchronous by nature.

• Satellite acquisition can take significantly longer than an LTE attach. The first connection after boot is the slowest part, and the blueprint's diagnostic output shows where the device is in that process.
• The NTN path enforces a minimum spacing of 1 message every 30 seconds. This is a rate limit, not a latency figure, but it shapes how you design reporting: NTN is for periodic messages, not bursts.
• Treat delivery as eventual rather than real-time. Do not build logic that blocks on an immediate round trip or assumes a reply within milliseconds.

Asynchronous by design

A successful NTN publish means the device handed the message off, not that it has already arrived and been acknowledged end to end. Design application logic around eventual delivery, and avoid tight request-and-response patterns over the satellite path.

4. Demo Behavior, Sandboxes, and Rate Limits

Default behavior and first-boot messages

The M635e NTN blueprint ships in an NTN-only, NTN-first configuration so that satellite behavior is demonstrated immediately. After you deploy the application and the device boots:

1. The device initializes its modem, loads its configuration, and resets its internal state machine and watchdog.
2. It acquires a location (fixed coordinates captured during setup, or a GNSS fix).
3. It begins searching for NTN satellites and attaches to the network.
4. It connects to the Particle Cloud and begins publishing.

The system LED is overridden to signal NTN acquisition status, and verbose debug logs stream over USB serial the whole time. Open a serial monitor (for example particle serial monitor) to watch them. Expect a startup banner with the full runtime configuration, the current operating mode, signal metrics, satellite acquisition progress, connection state transitions, publish results with success and failure counters, and timing estimates for retry and fallback windows. The diagnostic output is designed so you can understand what the modem is doing even when a satellite connection has not yet succeeded.

This demo is intentionally always-on

The blueprint is a connectivity and placement evaluation tool. Power management, deep sleep, and low-power modem operation are deliberately excluded so that system behavior stays fully visible. A production design would add those back.

Sandbox and rate limits

Two different kinds of limits apply to NTN, and it helps to keep them separate. The first kind is a property of the satellite path itself and applies to all NTN traffic regardless of your account tier. The blueprint's publish layer enforces these:

• Per-message spacing: a minimum of 1 message every 30 seconds on NTN. The publish layer enforces this, so messages you attempt to send faster are spaced out or dropped rather than transmitted back to back.
• Payload ceiling: 256 bytes per message, enforced in the same layer.
• Vitals: rate limited alongside your application messages, so frequent vitals will consume the same budget your telemetry uses.

The second kind of limit is separate: the per-hour and per-day message allowances tied to your Particle account tier and product plan. The NTN sandbox and plan limits have not been finalized yet, so for now treat the transport limits above as the constraints to design around. Once the account limits are set, they will be documented and reflected in the Particle Console.

During testing, the per-message spacing is what you will notice first. It is why a test loop that publishes aggressively will quickly look stalled, even on a paid plan, so pace your test firmware to the NTN minimum.

Pace your testing

A device firing publishes in a tight loop will hit the rate limiter almost immediately and appear to stop sending. This is expected. Space your test publishes to at least the NTN minimum and you will see steady delivery instead.

5. Troubleshooting Guide

NTN activation and Skylo profile

If the device never reaches the satellite network, start with provisioning.

• Confirm the device was set up through https://setup.particle.io, which installs the correct Device OS (6.4.2 or later), the blueprint firmware, and the eSIM profiles, including the NTN profile provisioned for satellite roaming on the Skylo network. If you are unsure the device was fully provisioned, run it through setup again.
• A device can have profiles installed but not yet activated. Verify in the diagnostic output that the eSIM successfully switched to the NTN profile during the attach sequence.

Antenna placement and location

This is the single most common cause of NTN failures. A satellite link needs a clear, unobstructed line of sight to the sky.

• Use an antenna rated for the NTN band, separate from the LTE-M antenna.
• Place the antenna outdoors, with a clear, unobstructed view of the sky. Buildings, roofs and overhangs, dense foliage, metal enclosures, and coated or metallized glass all block or attenuate the signal enough to prevent attach.
• Orientation matters. The blueprint is built to be a placement evaluation tool: it outputs signal and satellite-acquisition information over the serial connection, so use USB serial debugging to compare placements empirically and move the antenna while watching the output rather than guessing.

Line of sight is not optional

NTN will not work from inside a building, a vehicle cabin, or under heavy tree cover. If acquisition keeps failing, move the antenna to a clear outdoor sky view before changing anything else. Most "it won't connect" reports are placement, not configuration.

A missing or invalid location is the other frequent attach blocker, because Release 17 NTN requires the device to know its own position before it can attach. If acquisition stalls with no location fix, provide a location in one of two ways: set a fixed location manually in the blueprint configuration, or run the device through the setup tool again to set its location. If you are relying on GPS rather than a fixed location, make sure the GNSS receiver has its own clear view of the sky to obtain a fix.

Quota overages

If a device was publishing and then goes quiet, suspect the rate limiter before assuming a hardware fault.

• Check the publish accounting in the USB serial debug output. The blueprint reports publish attempts, successes, and failure causes, which will show messages being spaced out or rejected by the limiter.
• Confirm your firmware is not attempting to publish faster than 1 message every 30 seconds, and that vitals timing is not consuming the budget.
• Review your account and product message limits in the Particle Console to confirm the device has not hit a sandbox or plan ceiling.

Missing messages

If the device reports a successful publish but the event does not appear in the Particle Console, work through these in order:

• Confirm the publish actually went out over NTN and was not queued, spaced by the rate limiter, or dropped for exceeding 256 bytes. A queued or rate-limited message is not the same as a delivered one.
• Remember that NTN delivery is asynchronous. Allow time for the message to traverse the satellite path and the ground network before concluding it is lost.
• Check that you are looking at the right scope in the Console: the correct product and device, and event-name filters that are not hiding the event.
• Verify the device's location is valid and its clock is reasonable, since a bad location can prevent a clean attach in the first place.
• Confirm you are looking for a publish (an event the device sends) rather than expecting a subscribe to have been delivered, since both are rate limited and behave differently.

6. Developer Resources and Blueprints

Ready to put a device in the field? Start from the official M635e NTN blueprint, which includes the demo application, the USB serial debug output described above, and configuration for NTN-only, LTE-only, and hybrid LTE-with-NTN-fallback operation.

• M635e NTN blueprint (hardware and software): https://github.com/particle-iot/blueprint-m635e-ntn
• Deploy it to a device: open the blueprint from https://blueprints.particle.io/ and choose "Use this blueprint," then "Deploy to my device."
• Set up your M635e and install eSIM profiles: https://setup.particle.io

Start with the blueprint as a diagnostic tool

Even if your end product is a low-power hybrid device, flash the default NTN-first blueprint first and use its USB serial debug output to validate antenna placement and confirm satellite attach at your site. Once you have a reliable connection, move on to your own power-managed application.