Satellite IoT: NB-IoT NTN vs LoRa Satellite vs Direct-to-Device Selection Guide

Satellite IoT: NB-IoT NTN vs LoRa Satellite vs Direct-to-Device Selection Guide

Satellite IoT: NB-IoT NTN vs LoRa Satellite vs Direct-to-Device Selection Guide

A pump station in the middle of nowhere, a shipping container mid-ocean, a cattle tag on a 40,000-hectare ranch: none of them has a cellular tower within reach, and for years the only way to hear from them was a proprietary satellite modem with a proprietary bill. That is changing because satellite IoT is converging on the same 3GPP standard that already runs your terrestrial NB-IoT fleet. But “satellite IoT” is no longer one thing. It now means at least three architecturally different options, and picking the wrong one costs you either battery life, latency, coverage or lock-in.

This guide compares the three families engineers actually face in 2026: standards-based NB-IoT over non-terrestrial networks (NTN), LoRa-based satellite links, and direct-to-device (D2D) services that reuse cellular-class handsets and modules. We work through orbit geometry, a worked link budget, pass scheduling, payload limits, power and a decision matrix, and we flag what is verified versus what is vendor positioning.

What this covers: the 3GPP NTN releases, the orbit trade-offs, the commercial landscape and its status, a reproducible link-budget and energy calculation, failure modes, and a selection checklist for remote asset monitoring.

Context and Background

Terrestrial low-power wide-area networks (LPWAN) cover a large share of where people live, but not where much of the world’s industrial assets sit. Pipelines, power lines, mining sites, ocean freight, agricultural land and remote infrastructure routinely fall outside coverage. The older answer was a dedicated satellite IoT provider with its own radio, its own ground segment and its own contract. Those systems worked, but each device was tied to one operator’s silicon and one operator’s roadmap.

The shift now underway is standardisation. 3GPP, the body that defines LTE and 5G, added non-terrestrial network support in stages. According to the 3GPP overview of NTN, Release 17 was the first release with normative NTN requirements for NR, and it also adapted NB-IoT and eMTC (LTE-M) to satellite access by reusing the NR NTN design where possible. Release 18 added IoT NTN enhancements, and Release 19 extends the work to regenerative payloads and store-and-forward operation for IoT. You can read the primary description on the 3GPP NTN overview page.

For an industrial buyer this matters for one reason: a standards-based satellite link means the module, the SIM or eSIM provisioning model and the core network integration look like the cellular fleet you already run. If you are still choosing between terrestrial technologies, start with our comparison of LoRaWAN vs NB-IoT vs LTE-M for industrial IoT, then return here for the places where terrestrial coverage ends.

The commercial landscape also moved. SpaceX acquired Swarm in 2021, and Swarm stopped selling new IoT devices in 2023 while keeping existing customers supported, per Via Satellite. Skylo operates a service over geosynchronous satellites using the NB-IoT protocol. Iridium announced NTN Direct, a 3GPP-based NB-IoT service from its L-band LEO constellation. Sateliot and Myriota are both building LEO NB-IoT networks based on Release 17. Consolidation among the big players is also reshaping the field; for the bigger strategic picture see our analysis of Amazon, Globalstar and Project Kuiper.

One caution runs through the whole article. Vendor announcements describe plans, pilots and early-adopter programmes as readily as live services. Where we could not verify that something is in general commercial operation as of October 2026, we say so.

Three Families of Satellite IoT, Defined Precisely

The short answer: NB-IoT NTN is the standards-based option when you want cellular-style modules and carrier integration; LoRa satellite is the lowest-cost, lowest-power option for tiny, delay-tolerant payloads; direct-to-device is the option when the same hardware must fall back between terrestrial and satellite coverage. The right choice follows from payload size, latency tolerance, battery budget and how much operator lock-in you can accept.

NB-IoT NTN: the 3GPP way

NB-IoT uses a 180 kHz carrier. Skylo’s documentation states its service uses the NB-IoT protocol, with a 180 kHz narrowband, single-tone uplink at 3.75 kHz, an application MTU of 256 bytes, and Release 17 as the baseline for certified chipsets and modules. It also describes propagation delays of roughly 500 to 600 ms and path loss in the range of 180 to 200 dB, which is the GEO regime. See Skylo’s knowledge base for the primary text.

The critical engineering change versus terrestrial NB-IoT is that the device must be GNSS-capable. In Release 17 the NB-IoT and eMTC NTN design assumes the device uses a GNSS fix to pre-compensate timing and frequency offset before it transmits; the 3GPP overview notes that simultaneous GNSS and NTN operation is not assumed, so the device must take a fix, then switch to the satellite radio. Release 19 includes a study of GNSS-independent operation precisely because this requirement is expensive for battery-powered devices.

LoRa satellite: spread-spectrum, store-and-forward

LoRa satellite networks treat the satellite as a very high gateway. The Semtech LR1121 transceiver supports LoRaWAN on sub-GHz bands, 2.4 GHz LoRa, and the 2.1 GHz S-band for direct communication with orbiting satellites, according to a Hackster report on the chip. A vendor quote in the same report refers to long-range frequency hopping spread spectrum (LR-FHSS), which is the modulation variant built to survive many devices transmitting into one satellite footprint. Lacuna Space has been the best known operator offering LoRaWAN over satellites, announced with Semtech in January 2022. We could not verify Lacuna’s operating status in 2026 from primary sources during this run, so treat it as a lineage to check, not a given. For the underlying protocol mechanics see our LoRaWAN protocol technical guide.

Direct-to-device: the same radio on both networks

Direct-to-device (D2D) describes a satellite service that talks to an ordinary terrestrial radio, without a special satellite terminal. For IoT this is the hybrid pattern: one module that uses cellular when it can and satellite when it cannot. Myriota’s July 2026 announcement is a clear example. It added cellular connectivity to its HyperPulse 5G NTN service and its AssetHawk tracker, and states that HyperPulse routes each message over cellular or satellite depending on availability and configuration, with hybrid plans starting at USD 0.99 per device per month, per Myriota. That is a vendor price for a vendor plan; we do not generalise it.

Why the distinction matters

All three move bytes from a battery device to a satellite. They differ in who owns the spectrum (licensed L-band or S-band versus licensed-exempt ISM), who owns the protocol (3GPP versus a LoRa Alliance profile versus a proprietary air interface), and what the device must do before it transmits (take a GNSS fix, wait for a pass, or simply transmit). Those three questions determine nearly every number in the rest of this guide.

Regardless of family, the end-to-end path has the same five stages: the device and its sensor, the space segment, a ground gateway or earth station, the core or network server, and your application. The standards-based options differ mainly in the middle: an NB-IoT NTN service plugs the satellite into a 3GPP core, while a LoRa satellite service delivers uplinks to a LoRaWAN network server.

Satellite IoT reference architecture showing device, satellite, gateway, core network and application

Figure 1: End-to-end satellite IoT path. The same device-to-application chain applies to NB-IoT NTN, LoRa satellite and hybrid direct-to-device services; only the air interface and the core differ.

Figure 1 shows a transparent (bent-pipe) payload, the Release 17 assumption: the satellite relays the radio signal and the base station function sits on the ground. Release 19 introduces regenerative payloads and store-and-forward operation for IoT, where a full eNB can run on the satellite itself. That matters because on a LEO satellite with no ground station in view, a bent-pipe design simply cannot deliver your message until a gateway is visible, whereas store-and-forward can hold it.

Orbit Geometry Decides Most of Your Constraints

Orbit choice sets latency, link budget, pass behaviour and constellation size before you ever pick a modem. The two orbits that matter for IoT are LEO and GEO. The 3GPP overview gives the reference ranges: LEO at roughly 500 to 2,000 km, MEO at roughly 8,000 to 20,000 km and GEO at about 35,786 km, with GEO propagation delay reaching a few hundred milliseconds against under 1 ms in terrestrial networks. Release 17 focused on transparent-payload LEO and GEO scenarios.

GEO: always there, always far

A geostationary satellite sits above one longitude and appears fixed in the sky, so a device with a clear view of the satellite can send at any time. That is the Skylo model: no pass scheduling, immediate access, and a design that suits devices which must report on demand. The cost is distance. Free-space path loss (FSPL) in dB is 32.45 + 20 log10(d in km) + 20 log10(f in MHz). For a slant range of 38,000 km at 1.6 GHz that is about 188 dB, consistent with the 180 to 200 dB range Skylo cites. At 2 GHz it is about 190 dB. Round-trip delay is dominated by the long hops: Skylo quotes about 500 to 600 ms.

GEO coverage also thins toward the poles, and obstructions matter more because the satellite sits at a fixed, sometimes low, elevation angle. A device in a valley or a canyon at high latitude may see no GEO satellite at all.

LEO: close, fast and intermittent

A LEO satellite at 600 km altitude has an orbital period of roughly 96.7 minutes (computed from Kepler’s third law with Earth’s gravitational parameter). It crosses the sky in minutes, and a device sees it for a limited window per pass. FSPL is far lower: at a slant range of 1,000 km and 1.6 GHz it is about 156.5 dB, roughly 31 dB better than GEO at the same frequency. That 31 dB is the entire reason LEO NB-IoT can work with a small antenna and a power-limited transmitter.

The price is pass management, Doppler shift and constellation size. A single LEO satellite gives sparse coverage; practical latency depends on how many satellites you have and on whether a ground station is in view. Iridium argues in its Deutsche Telekom announcement that LEO offers better look angles and lower latency than geostationary systems, and that its L-band constellation provides truly global coverage, while stating that commercial launch of NTN Direct is planned for 2026 following integration and testing and a roaming agreement. We did not find confirmation that it is in general service as of today.

Doppler and timing: why the standard needs GNSS

On a LEO pass the relative velocity of the satellite creates Doppler shift measured in tens of kilohertz at L-band, and the round-trip time changes continuously. NB-IoT is designed around a 180 kHz carrier and, for the single-tone uplink, 3.75 kHz subcarrier spacing, so frequency errors of that magnitude would destroy the uplink. Release 17 therefore requires the device to compute its own timing advance and pre-compensate frequency from its GNSS position plus satellite ephemeris broadcast by the network. The 3GPP overview describes this for NR as a common timing advance broadcast per cell combined with a UE-computed term. Applied to NB-IoT, it means a cold-start device needs a valid fix before its first uplink.

Orbit comparison for satellite IoT showing GEO and LEO link and delay characteristics

Figure 2: How orbit changes the satellite IoT link. GEO offers continuous access at high path loss and delay; LEO offers lower loss but intermittent visibility and Doppler.

Figure 2 summarises the consequence. Pick GEO when always-available access and a simple device schedule matter more than latency and battery; pick LEO when battery and antenna size matter and the application tolerates waiting for a pass.

A link budget answers a simple question: will the receiver hear the device? The numbers below are an illustrative calculation, not measurements from any operator. They use standard formulas and assumed values to show how the pieces trade against one another.

Assume a handheld-class transmitter at 23 dBm (200 mW), a 0 dBi antenna, a slant range of 1,000 km at 1.6 GHz, and FSPL of 156.5 dB. Assume a satellite receive antenna gain of 20 dBi (assumed), implementation and polarisation losses totalling 4 dB (assumed), and a satellite receiver noise temperature giving a system noise of about 500 K (assumed). The received power is 23 + 0 + 20 – 156.5 – 4 = -117.5 dBm.

Thermal noise power in a bandwidth B is -174 dBm/Hz + 10 log10(B) + noise figure. For a 3.75 kHz single-tone bandwidth, 10 log10(3750) is 35.7 dB. With a 500 K noise temperature, the noise figure relative to 290 K is 10 log10(500/290), about 2.4 dB. Noise power is -174 + 35.7 + 2.4 = -135.9 dBm. The signal-to-noise ratio is therefore -117.5 – (-135.9) = 18.4 dB, a healthy margin in this idealised case. If the same 3.75 kHz tone were sent at 15 kHz bandwidth, noise rises by 6 dB, which is why narrowing the bandwidth is the first lever.

The same device to GEO

Move to GEO: FSPL becomes about 188 dB at 1.6 GHz, which is 31.6 dB worse. With the same assumed antenna gain, the SNR falls to about -13 dB. The receiver cannot decode that at single-transmission energy. This is where repetition earns its place: repeating the same transmission N times and combining adds roughly 10 log10(N) dB of gain, so 32 repetitions buy about 15 dB. A larger satellite antenna is the other lever (GEO satellites typically carry large reflectors; the exact gain is operator specific and unverified here). The result: GEO links trade time on air, and therefore battery, for reach. The Skylo statement that NIDD (non-IP data delivery) reduces transmission sizes by 20 to 40 percent is one way to claw time back, since fewer bytes means fewer repetitions of fewer symbols.

What the budget teaches

Three practical lessons follow. First, on GEO, every byte you remove from the payload is battery you keep. Second, on LEO, the budget is comfortable enough that the limiting factor becomes visibility, not power. Third, a device with a poor antenna (a metal enclosure, an antenna pressed against a body or a vehicle roof gap) can lose 10 dB or more without any change in the satellite, which can turn a LEO design into a no-go. Always test the real enclosure under open sky. Do not rely on a datasheet number.

Link budget walk-through showing transmit power, path loss, receiver gain and margin for satellite IoT uplink

Figure 3: Anatomy of a satellite IoT uplink budget. Transmit power plus gains minus path loss and losses gives received power; compare it with noise power to get margin.

Pass Scheduling, Payloads and Duty Cycle

Visibility windows on LEO

A satellite at 600 km altitude is above the horizon for at most roughly 10 to 15 minutes on an overhead pass. With a realistic 10 degree elevation mask and a pass that does not go overhead, usable windows are shorter, often a few minutes. These are geometric approximations; real windows depend on latitude, inclination and constellation. A constellation with, say, a few dozen satellites in several planes may still leave gaps of tens of minutes at some latitudes, which is why vendors with small constellations describe their service as delay tolerant. Sateliot, by its own reports, had launched six satellites by March 2025 towards a planned constellation of over 100, so coverage continuity is a function of its ramp-up, not a given.

For your design this means a message sent at an arbitrary time may wait. Plan your application for store-and-forward semantics: the device buffers, the network confirms, and your cloud layer treats telemetry as eventually consistent. If an alarm absolutely cannot wait, GEO (or a hybrid fallback to cellular) is the safer design.

Payload size and framing

Skylo’s stated MTU is 256 bytes. That is large compared with some proprietary satellite messaging but small compared with a typical JSON telemetry payload. A temperature, pressure, battery voltage, GNSS position and a timestamp can fit in 20 to 30 bytes if you encode it in a compact binary format such as CBOR or a custom struct. The same data as verbose JSON can run 300 bytes and exceed the MTU. For LoRa satellite, payloads are smaller still; LoRaWAN application payloads are limited by data rate and regional parameters, so treat tens of bytes as the planning figure and consult your operator’s actual limit.

Duty cycle and regulatory constraints

LoRa operates in licence-exempt bands (868 MHz in Europe, 915 MHz in the US) with duty-cycle or dwell-time rules; in Europe sub-band duty cycles are often 1 percent or 10 percent, depending on sub-band. A satellite message sent from the 868 MHz band is bound by the same ground rules, which limits how often the device can try to hit a pass. Licensed-spectrum services like NB-IoT NTN do not carry that duty-cycle limit, but the operator will impose its own fair-use or message-count limits in the plan. Always check both.

Power, Cost and the Selection Matrix

An illustrative energy budget per message

The numbers below are assumptions chosen to show the method, not module datasheet values. Suppose an NB-IoT NTN device must get a GNSS fix before each satellite transmission, as Release 17 assumes. Assume a cold or warm fix costs 100 mW for 30 s, which is 3 J. Assume the satellite uplink with repetitions keeps the module at an average 500 mW for 20 s, which is 10 J, and listening for the acknowledgement adds 2 J. Total: about 15 J per message, or 0.0042 Wh.

A pack of two lithium primary cells with roughly 9 Wh usable (assumed) would then deliver about 2,100 messages if nothing else drained it. At four messages per day, that is around 18 months, before counting sleep current and self-discharge. Cut the fix cost by reusing the last position for a stationary asset and the figure improves by 20 percent; double the repetition count for a poor antenna and it drops by a similar fraction. The lesson is structural: in satellite IoT, the cost of one message is dominated by pre-transmit work and time on air, not by sleep current. Skylo notes that its service supports power-saving mode (PSM) and extended discontinuous reception (eDRX), which govern the sleep side; the transmit side is governed by your payload size and your antenna.

For LoRa satellite, time on air for a short frame is small and there is no GNSS-before-transmit requirement in the protocol itself, although many trackers carry GNSS for their own purpose. That is the structural advantage of the LoRa path for tiny payloads: lower per-message energy. Its disadvantages are the absence of a 3GPP core integration, the dependence on a single operator’s gateway network and the smaller payload.

Cost models without invented prices

We deliberately do not quote a price table, because satellite IoT pricing is negotiated, bundled with hardware, and changes quickly. The only public figure we verified is Myriota’s statement that its hybrid HyperPulse data plans start at USD 0.99 per device per month. That is a starting price for a particular plan, and it says nothing on message limits, which you must ask about.

What you can do is structure the comparison. Ask every vendor for five numbers: the monthly fee per device, included messages, the price of overage, the module cost and certification cost, and the minimum commitment. Then compute the cost per delivered message at your real reporting rate. A flat plan that looks cheap at one message a day can look expensive at twenty, and per-message plans behave the opposite way.

The decision matrix

Decision flow for choosing NB-IoT NTN, LoRa satellite or hybrid direct-to-device satellite IoT

Figure 4: A selection flow for satellite IoT. Start with latency and payload, then check terrestrial coverage and ecosystem lock-in.

The table below summarises how the three families compare on the dimensions that usually decide a project. Qualitative ratings are our engineering judgement based on the mechanisms above, not benchmark results.

Dimension NB-IoT NTN (GEO, such as Skylo) NB-IoT NTN (LEO, such as Iridium NTN Direct, Sateliot, Myriota) LoRa satellite Hybrid direct-to-device
Standard 3GPP Release 17 3GPP Release 17 LoRa / LoRaWAN, LR-FHSS 3GPP, cellular plus NTN
Access pattern Continuous Pass or constellation dependent Pass dependent, store-and-forward Cellular first, satellite fallback
Latency Roughly 500 to 600 ms propagation (Skylo) Low propagation, wait time dominates Minutes to hours Seconds on cellular, variable on satellite
Path loss Roughly 180 to 200 dB (Skylo) Far lower than GEO Lower than GEO, sub-GHz or S-band Depends on mode
Needs GNSS before TX Yes (Release 17 assumption) Yes Not by protocol Yes on satellite mode
Payload 256 byte MTU (Skylo) Operator specific Tens of bytes Operator specific
Energy per message Highest Medium Lowest Medium
Lock-in risk Lower with certified modules Medium, roaming still maturing Higher, small ecosystem Medium
Best fit On-demand alerts, mobile assets in covered regions Global tracking, delay tolerant Tiny sensors, very low cost Assets that move in and out of cellular

The matrix suggests a few rules of thumb. If an alert must arrive within seconds and the device can tolerate a higher energy cost, favour GEO NB-IoT NTN. If you track assets that cross oceans and can wait, favour LEO. If the sensor is tiny, the payload is a single reading and cost per device dominates, LoRa satellite deserves a serious look. If the asset moves between regions with cellular coverage and regions without, the hybrid pattern avoids paying satellite airtime when a tower is available.

Verified status snapshot

Provider Verified fact Status caveat
Skylo GEO satellites, NB-IoT, Release 17 certified chipsets and modules, 256 byte MTU; coverage in the US, Canada, Europe, Australia, New Zealand and Japan listed; over 1 million connected devices stated as of October 2024 Figures are from the vendor’s own page; coverage list may have changed
Murata Type 1SC-NTN module (LBAD0XX1SC) supports Rel-17 NTN with Skylo certification required Hardware specs not verified here
Iridium NTN Direct is a 3GPP-based NB-IoT D2D service on L-band LEO; Deutsche Telekom integration announced September 2025; Vodafone IoT partnership announced Commercial launch planned for 2026; general availability not verified
Sateliot LEO 5G NB-IoT NTN constellation, plan of over 100 satellites, six launched by March 2025, Series B closed Commercial service status not verified
Myriota HyperPulse NB-IoT NTN built on Viasat geostationary L-band leasing at launch, hybrid cellular plus satellite announced July 2026, coverage in seven named countries Marketing claims; constellation details not verified
Swarm (SpaceX) Acquired 2021; stopped selling new devices in 2023; existing M138 customers supported Current status not verified
Lacuna Space LoRaWAN over satellites announced with Semtech in 2022 2026 status not verified

Trade-offs, Gotchas, and What Goes Wrong

The GNSS dependency is a hidden battery tax. Release 17 NB-IoT NTN assumes a GNSS-capable device, and simultaneous GNSS and NTN operation is not assumed. A device that is indoors, under canopy or in a steel enclosure will fail to get a fix and therefore cannot transmit. Test fix time, not just uplink success. Release 19’s study of GNSS-independent operation signals the problem is recognised, but it is a study, not a deployed feature.

Coverage maps are not link margins. A coverage polygon on a vendor map assumes a certain antenna and clear sky. A real device with a small, enclosed antenna sees a smaller footprint. Insist on a field trial at your worst site, at your worst time of day, with your enclosure.

Roaming and certification add calendar time. The Iridium and Deutsche Telekom announcement states that the parties will complete integration and testing, then sign a roaming agreement to support full commercial service. Carrier agreements, SIM provisioning and module certification (Skylo requires device certification for commercial service) can add months. Budget for it.

Bent-pipe LEO needs a ground station in view. In Release 17’s transparent-payload model, a LEO satellite cannot deliver traffic until it sees a gateway. Operators mitigate this with more gateways or with store-and-forward onboard, which Release 19 begins to standardise. Ask which one your operator uses.

Duty-cycle and fair-use limits bite at scale. A fleet of 10,000 devices all reporting at the top of the hour will collide at the satellite; LR-FHSS was designed to tolerate many devices, but your plan or the regulator may still cap transmissions. Randomise reporting times.

Single-vendor risk is real. The Swarm story shows how a platform can stop selling devices while continuing to support existing ones. Prefer standards-based modules where the cost of switching operator is a SIM and a roaming profile, not a hardware redesign. For related connectivity-risk thinking in remote infrastructure, see our piece on remote experimentation architecture, which faces similar latency and intermittency constraints.

Security is not free. Satellite links add a ground segment and often a third-party operator between your device and your cloud. Terminate encryption end to end at your own application where possible, not only at the operator’s gateway, and verify what the operator logs and stores. We did not verify any operator’s security architecture for this article.

Practical Recommendations

Start from the application, not from the technology. Write down the maximum acceptable delay, the payload bytes per message, the reporting rate, the battery life target and the geography. Those five numbers eliminate most options before you read a datasheet.

If you need near-real-time alerts anywhere in covered regions and can afford the energy, evaluate GEO NB-IoT NTN with certified modules first, because there is no pass scheduling to design around. If you track assets globally and can tolerate gaps, evaluate LEO NB-IoT NTN offerings and ask each operator for the actual revisit statistics at your latitude. If you have tiny sensors in a region with an operator whose network you can verify, evaluate LoRa satellite for the lowest per-message energy. If your assets move through terrestrial coverage most of the time, a hybrid module that prefers cellular will usually save money.

Prototype early. A satellite link that closes on a link-budget spreadsheet can fail on a roof, on a truck or in a field.

Checklist before you commit:

  • Define the maximum acceptable latency and the real payload size in bytes, after compact encoding.
  • Confirm the operator is in general commercial service in your geography today, in writing.
  • Ask for the GNSS acquisition assumptions, expected time to first fix and the module’s behaviour without a fix.
  • Run a field trial with the production enclosure and antenna at the worst-case site.
  • Compute cost per delivered message at your real reporting rate, including overage and certification.
  • Plan store-and-forward handling in the cloud, with idempotent ingestion and device-side timestamps.
  • Prefer standards-based modules and keep an exit path to a second operator.
  • Terminate security end to end and review what the operator retains.

Frequently Asked Questions

What is satellite IoT?

Satellite IoT connects low-power sensors and trackers to the internet through satellites when no terrestrial network is available. Devices send small messages, such as position or a sensor reading, to a satellite, which relays them to a ground gateway and on to your application. The air interface may be a 3GPP standard like NB-IoT over NTN, a LoRa-based link, or a proprietary protocol, and the orbit may be GEO or LEO.

What is NB-IoT NTN?

NB-IoT NTN is the adaptation of the narrowband IoT standard to satellite access, defined in 3GPP Release 17 and enhanced in Release 18. It keeps the 180 kHz NB-IoT carrier but adds satellite-specific features: GNSS-assisted timing and frequency pre-compensation, handling of long delay, and support for transparent LEO and GEO payloads. The benefit is that standard-based modules and core networks can be reused across terrestrial and satellite coverage.

Is LoRa satellite better than NB-IoT NTN?

Neither wins universally. LoRa satellite typically uses less energy per tiny message and does not require a GNSS fix before transmitting by protocol, but its ecosystem is smaller, payloads are tiny and delivery is delay tolerant. NB-IoT NTN offers standards-based modules, larger payloads (Skylo states a 256 byte MTU) and carrier integration, at higher energy per message. Choose based on payload, latency, battery target and acceptable lock-in.

Do I need a special antenna for satellite IoT?

Often not a dish, but antenna quality matters more than most designs expect. The NTN link budget is tight, especially to GEO where Skylo cites 180 to 200 dB of path loss, so a poorly placed or enclosed antenna can lose 10 dB or more. Use a antenna rated for the operator’s band, keep a clear view of the sky, and validate with the production enclosure in a field trial rather than relying on a datasheet.

How much does satellite IoT cost?

Prices vary by operator, plan and volume, and are often negotiated, so we do not publish a table. One verified public data point is Myriota’s July 2026 statement that its hybrid data plans start at USD 0.99 per device per month. Compare vendors by monthly fee, included messages, overage rates, module and certification cost, and minimum commitment, then compute cost per delivered message at your real reporting rate.

Is direct-to-device the same as direct-to-cell?

They overlap but are not identical. Direct-to-device describes satellite service reaching standard terrestrial radios, including IoT modules, without a dedicated satellite terminal. Direct-to-cell is the term SpaceX uses for its Starlink service for cellular handsets. For IoT, the practical question is whether your module supports the operator’s NTN bands and has been certified for their network. We could not verify the status of Starlink-based IoT service for this article.

Further Reading

Internal:

External primary sources:

By Riju — about

Comments

No comments yet. Why don’t you start the discussion?

Leave a Reply

Your email address will not be published. Required fields are marked *