Massive IoT Satellite Connectivity

It depends on the chipset. The satellite specification came into the cellular standards in 2022, but it takes some time for this to shake through to the chipset manufacturers.

If your chipset predates the 3GPP’s NTN extensions in Release 17, it won’t work for satellite connectivity.

If/when it comes to migrating an existing LTE-M / NB-IoT device, it’s important to note that NTN NB‑IoT does not support TCP/IP; instead, it relies on UDP/IP or Non‑IP Data Delivery (NIDD), both of which have much lower overhead and suit the small‑packet, delay‑tolerant nature of satellite links. If your existing device uses TCP, you’ll need to refactor your firmware to bundle data into UDP or NIDD messages, manage acknowledgments at the application layer, and optimize for intermittent connectivity and longer round‑trip times.

As with any technology, particularly when it’s new, there are a few considerations to take into account when determining if this will work for your massive IoT application. This isn’t an exhaustive list, but gives you a starting point for discovery.

• Antenna and form factor: Cellular IoT devices don’t need a clear view of the sky, but in order to access NTN services, you absolutely do. Further, if your connectivity partner is Viasat (and just now, they have the most advanced proposition), you will also need to consider the look angle, because the satellite is in a fixed position overhead (called “geostationary” orbit), and your antenna needs to have clear line of sight to the satellite. This means that sometimes you will need a separate piece of hardware – one which combines the chipset and antenna in a form factor suitable for permanent outdoor installation – in order to achieve that.
• Coverage: Viasat’s live beams today cover North America, Australia, New Zealand, Brazil and parts of Europe, but global rollout is gradual. It’s important to check the service availability, and capability, in your specific region.
• Cost and session sizing: Beyond about 50 KB per month, standard NTN tariffs can become costly. This isn’t the technology for you if you need to transmit gateway data or complex, multi-sensor readings. Equally, the minimum session size at the moment is 50 bytes, which for some applications is far more than is needed, and there may be more cost-effective proprietary solutions. Talk to us to get impartial, expert advice on this topic.
• Network congestion: At the moment, these services are new, and there’s very little network traffic. However, once more devices come online, there’s a shared network congestion risk when traffic is heavy, which can impact throughput and connection reliability.
• Firmware and data mode: NTN profiles mandate reduced data rates and larger minimum packet sizes. Your application firmware must bundle and buffer messages accordingly, and handle longer latency.
• Transport protocol adaptation: NTN NB‑IoT does not support TCP/IP; instead, it relies on UDP/IP or Non‑IP Data Delivery (NIDD), both of which have much lower overhead and suit the small‑packet, delay‑tolerant nature of satellite links. If you’re migrating an existing LTE‑M/NB‑IoT device (which often uses TCP), you’ll need to refactor your firmware to bundle data into UDP or NIDD messages, manage acknowledgments at the application layer, and optimize for intermittent connectivity and long round‑trip times.

No, you shouldn’t expect the same speed and responsiveness as terrestrial NB‑IoT.

Under Skylo’s current NTN NB‑IoT implementation, the link is constrained to roughly 1-2 Kbps peak throughput in both uplink and downlink, versus the tens or hundreds of Kbps you’d see over terrestrial NB‑IoT. This is deliberately optimized for frequent, small‑packet exchanges. It also limits maximum transport block sizes to around 256 bytes (compared to ~1.5 kB on land), so your firmware must buffer data into these smaller chunks to maximize efficiency.

Round‑trip latencies jump into the tens of seconds, or even minutes if your MVNO batches frames, whereas terrestrial NB‑IoT typically sees 1–10 s delays.

On top of that, NTN links share satellite spot‑beam capacity with other users (so you can hit congestion during peak loads), carry steep per‑kB costs once you exceed ~50 kB/month, and require firmware tweaks for larger minimum packet sizes and longer sleep‑wake cycles. All of these factors mean that NTN NB‑IoT is best suited for very infrequent, small payload telemetry rather than anything resembling cellular performance.