Hubble vs LTE NTN: Two Paths to Satellite IoT
Your BLE asset tracker already has a $2.50 Nordic chip on the board. Hubble Network says that same chip can talk to a satellite. Meanwhile, 3GPP just standardized NTN, and a new wave of modem modules promises “real” cellular-grade satellite connectivity for IoT. One path adds $0 to your connectivity BOM. The other adds $15–40. One is uplink-only. The other gives you bidirectional comms and a standards-body pedigree. The catch? Neither decision is obvious, and picking wrong means a redesign that costs you two quarters and a funding round.
This article gives you the numbers to make that call. We’ll walk through architecture, BOM cost, power budget, data capabilities, and integration complexity, then hand you a decision framework you can adapt to your own use case. Think of it as pencil math you can bring to your next design review.
Smart Satellite vs. Smart Device: Where the Complexity Lives
The fundamental difference between Hubble Network and 3GPP LTE NTN isn’t frequency band or modulation scheme. It’s where the hard problem gets solved.
Hubble Network pushes complexity into space. Your device runs a standard BLE stack and transmits advertising packets at 2.4 GHz. Hubble’s proprietary LEO satellites carry high-sensitivity receivers that decode those packets from orbit, a feat that requires extraordinary signal processing on the satellite side. Your firmware engineer writes the same BLE advertising code they’d write for a beacon. No NTN stack, no Doppler pre-compensation, no timing advance. The satellite does the heavy lifting.
3GPP LTE NTN (specifically NB-IoT NTN and LTE-M NTN, defined in 3GPP Release 17) pushes complexity into the device. The satellite acts as a bent-pipe relay or a regenerative node running a standard 3GPP air interface. Your device’s modem must handle NTN-specific challenges: Doppler pre-compensation for LEO satellite velocities (~7.5 km/s), extended timing advance for the ~600 km round trip, and adapted HARQ (Hybrid Automatic Repeat Request) procedures. Chipsets like Nordic’s nRF9151, Qualcomm’s 212S/216S, and modules from Quectel and others absorb this complexity into the modem firmware, but it’s still happening on your board, drawing power from your battery.
Both approaches are reaching commercial availability in roughly the same window. The question isn’t which will exist. It’s which belongs in your product.
BOM Cost: The $13–40 Gap That Compounds at Scale
Let’s run the numbers. Here’s a representative connectivity BOM at 10k quantity:
┌───────────────────────┬──────────────┬──────────────┐
│ Component │ BLE (Hubble) │ NTN (3GPP) │
├───────────────────────┼──────────────┼──────────────┤
│ Connectivity SoC │ $1.50–3.00 │ $8.00–15.00 │
│ Module (if used) │ N/A or $4–6 │ $15.00–40.00 │
│ SIM / eSIM │ None │ $1.00–3.00 │
│ Antenna │ $0.20–0.80 │ $1.50–5.00 │
│ Matching / SAW filter │ $0.10–0.30 │ $0.50–2.00 │
├───────────────────────┼──────────────┼──────────────┤
│ Connectivity BOM │ ~$2–4 │ ~$15–45 │
│ (typical estimate) │ │ │
└───────────────────────┴──────────────┴──────────────┘
Prices: estimated qty 10k, subject to vendor/volumeAt 100k units, that per-unit delta of $13–40 becomes $1.3M–$4M in connectivity BOM alone. That’s real money for a hardware startup.
The antenna story deserves a closer look. BLE operates at 2.4 GHz, where a $0.30 chip antenna on a 10mm ground plane works fine. NTN operates at sub-GHz bands (Band 255/256 for NB-IoT NTN, or LTE Bands 23/26), where wavelengths are longer, antennas are physically larger, and you likely need a tuned patch or helical design plus a SAW filter to meet out-of-band emissions requirements. For space-constrained designs like livestock ear tags or pallet trackers, this antenna penalty is significant.
There’s another cost advantage that doesn’t show up in the table: if your design already includes a BLE SoC for on-device sensor communication (talking to a BLE temperature sensor, accelerometer, or gateway), Hubble’s satellite connectivity adds zero silicon cost. You’re reusing the radio you already had. That’s a powerful story for unit economics.
Power Budget: Why Duty Cycle Matters More Than Tx Power
The headline specs suggest an enormous power gap: BLE transmits at +8 dBm (~10 mA), while NTN uplink runs at +23 dBm Class 3 (~200–300 mA). That’s a 20–30x difference in transmit current. But raw Tx power doesn’t tell the full story. Session duration and duty cycle do.
Here’s a worked example for a common IoT scenario:
Scenario: 1 message/hour, 20-byte payload, CR2477 coin cell (1000 mAh)
┌──────────────────────┬──────────────┬──────────────────┐
│ Parameter │ BLE (Hubble) │ NTN (NB-IoT) │
├──────────────────────┼──────────────┼──────────────────┤
│ Tx Power │ +8 dBm │ +23 dBm │
│ Tx Current │ ~10 mA │ ~200–300 mA │
│ Tx Duration/session │ ~5–15 ms │ ~2–5 sec │
│ Energy per session │ ~0.05–0.15 mJ│ ~400–1,500 mJ │
│ Sleep current │ ~1–2 µA │ ~2–5 µA (PSM) │
├──────────────────────┼──────────────┼──────────────────┤
│ Est. battery life │ 3–5+ years │ ~1–2 years │
└──────────────────────┴──────────────┴──────────────────┘
* BLE: multiple advertising bursts for Hubble coding gain
** NTN: includes sync/attach/transmit/detach cycle in PSMSession overhead is the key differentiator. A BLE advertising packet is a microseconds-to-low-milliseconds burst. Even with the repeated transmissions Hubble requires for coding gain (the satellite reconstructs your message from multiple overheard advertising events), total active radio time per message is measured in milliseconds. An NTN session, even using Power Saving Mode (PSM) or extended Discontinuous Reception (eDRX), involves a synchronization, attach, transmit, and detach cycle that runs for seconds of active radio time at 20–30x the current draw.
The honest nuance: this math tips dramatically in BLE’s favor for infrequent, small payloads. As message frequency increases or payloads grow, BLE needs more repetition passes (each requiring a satellite overhead window), while NTN’s session overhead amortizes across larger data transfers. If you’re sending 500 bytes every 10 minutes, the calculus changes. But for the canonical IoT pattern, small telemetry and infrequent uplinks, BLE wins on power by an order of magnitude.
Newer NTN SoCs like Nordic’s nRF9151 series have improved PSM sleep currents significantly (low single-digit µA), narrowing the standby gap. But the transmit-session energy gap remains structural.
Uplink-Only vs. Bidirectional: The Biggest Functional Fork
This is the single decision that may make your choice for you.
Hubble Network is uplink-only today. Your device transmits sensor data to the Hubble constellation, which delivers it to the Hubble cloud. There is no downlink path. No acknowledgment. No delivery confirmation. No remote commands. No over-the-air (OTA) firmware updates via satellite.
3GPP LTE NTN supports full bidirectional communication. The device can receive downlink messages, acknowledge receipt, accept remote configuration changes, and, bandwidth permitting, receive FOTA updates. The 3GPP HARQ mechanism provides delivery confirmation baked into the protocol.
This isn’t a flaw in Hubble’s design. It’s a deliberate trade-off. By eliminating the downlink, Hubble avoids requiring a receiver on the device, avoids scheduling complexity, and keeps the device firmware trivially simple.
For many IoT use cases, uplink-only is perfectly adequate:
- Asset tracking: GPS coordinates transmitted hourly. You don’t need to talk back to the pallet.
- Environmental monitoring: Temperature, humidity, soil moisture readings. The sensor has nothing to hear.
- Livestock monitoring: Location and activity data from cattle ear tags.
For other use cases, bidirectional is non-negotiable:
- Remote device configuration: Changing reporting intervals or geofence parameters without a truck roll.
- Regulatory compliance: Maritime AIS relay or similar protocols requiring acknowledgment.
- Command-and-control: Actuating a remote valve, triggering an alert mode, or confirming a critical event.
If your product requires any satellite downlink, 3GPP NTN is your path. Full stop.
Getting to a Working Prototype: Integration Complexity
The BLE/Hubble path is remarkably short for teams with BLE experience. You register your device with Hubble’s platform, format your payload into Hubble’s BLE advertising packet structure, and transmit. Your firmware engineer likely already knows the Nordic SoftDevice or Zephyr BLE stack. No cellular modem AT commands, no SIM provisioning, no carrier relationships. RF design at 2.4 GHz is well-characterized, and reference designs abound. Prototype to working satellite uplink: days to weeks.
The 3GPP NTN path is more involved. You need NTN modem firmware expertise (AT command interface, network registration, PSM/eDRX configuration), SIM or eSIM provisioning through a carrier or satellite operator (e.g., via Skylo, OQ Technology, or MNO roaming agreements), and potentially PTCRB or GCF certification depending on your target market. RF design at sub-GHz NTN bands requires more careful antenna matching network design, especially in small form factors where ground plane size matters. Prototype to certified product: months.
For a team of firmware engineers who’ve lived in BLE-land, and that describes a large share of IoT startups, the Hubble path eliminates an entire domain of unfamiliar complexity.
A Pencil-Math Decision Framework
Here’s a simple weighted checklist. Score each criterion for your use case, and the answer usually becomes clear:
┌─────────────────────────────┬────────────┬────────────┐
│ Criterion │ Favors BLE │ Favors NTN │
│ │ (Hubble) │ (3GPP) │
├─────────────────────────────┼────────────┼────────────┤
│ Unit cost sensitivity │ ★★★ │ │
│ Bidirectional comms needed │ │ ★★★ │
│ Payload < 50 bytes │ ★★ │ │
│ Payload > 200 bytes │ │ ★★ │
│ Messages < 1x/hour │ ★★★ │ │
│ Messages > 1x/minute │ │ ★★ │
│ Team has BLE experience │ ★★ │ │
│ Team has cellular experience│ │ ★★ │
│ Existing BLE SoC in design │ ★★★ │ │
│ Carrier-grade reliability │ │ ★★ │
│ Need OTA/remote config │ │ ★★★ │
│ Certification timeline tight│ ★★ │ │
│ Volume > 50k units │ ★★★ │ │
│ Multi-vendor sourcing req. │ │ ★★ │
└─────────────────────────────┴────────────┴────────────┘Persona A: “Asset tracker startup. 100k units/year. GPS + temp uplink once per hour. BLE SoC already on board for gateway pairing. Team of three firmware engineers, all BLE-native.” → Hubble wins. The $2–4 connectivity BOM at 100k units saves $1M+ annually versus NTN, and uplink-only is fine.
Persona B: “Industrial valve monitor. 5k units. Needs remote configuration and delivery acknowledgment. Operating in regulated pipeline infrastructure.” → 3GPP NTN wins. Bidirectional comms and standards-based reliability outweigh the higher BOM.
Hedging Your Bets: Ecosystem and Roadmap Realities
Hubble Network is a single-vendor constellation. Your satellite connectivity depends on one company’s satellites, ground stations, and cloud platform. Their roadmap reportedly includes downlink capability and expanded coverage, but timelines are TBD. The upside: they can iterate without waiting for 3GPP standards-body consensus cycles.
3GPP NTN is backed by a multi-vendor ecosystem with multiple chipset vendors, multiple satellite operators, and multiple carriers. Release 18 and 19 promise further IoT NTN enhancements (reduced device complexity, improved power efficiency, expanded band support). The downside: standards-body timelines are slow, and carrier integration adds commercial complexity.
The two paths aren’t mutually exclusive. A design that includes a BLE SoC (for local sensor communication and Hubble satellite heartbeat) alongside an NTN modem (for critical bidirectional sessions) uses BLE as the low-cost, low-power default and NTN as the high-capability fallback. The BOM increase over NTN-only is modest. You’re adding a $2 BLE chip, not a $25 modem.
Making the Right Architecture Call
The “right” answer isn’t about which technology is technically superior. It’s about which constraints dominate your product.
If your product is high-volume, cost-sensitive, uplink-dominant, and your team already lives in BLE firmware: Hubble’s commodity-silicon approach is compelling and nearly impossible to beat on unit economics. A $2 connectivity BOM with multi-year coin-cell battery life is a product-defining advantage.
If your product requires bidirectional satellite communication, standards-based interoperability, or carrier-grade delivery guarantees: 3GPP NTN is the more capable path, and the higher BOM is the cost of capabilities you genuinely need.
Either way, make the decision with your BOM spreadsheet open, not a marketing slide deck. The numbers don’t lie, and now you have them.
Hubble Network connects standard BLE chips to satellite — no custom hardware, no cellular modem costs. See how it works →