3GPP Scout · Newsroom · October 2026
A $200 million round, a $1.6 billion valuation, and two comparison pages aimed squarely at NB-IoT over satellite. Some of Hubble’s claims about the 3GPP side hold up. Some are out of date, one is plainly wrong, and two are contradicted by Hubble’s own developer documentation. Meanwhile, the contest that decides how far this goes is happening at the FCC, not in a 3GPP meeting room.
The 60-second version
Hubble’s pitch is simple: the Bluetooth Low Energy radio already on a tracker or sensor can reach a satellite with a firmware update. No cellular modem, no SIM, no carrier contract. The company says it has six satellites in orbit, plans 60 by 2030, and counts more than 500,000 active devices. On the ground, it listens through roughly 100 million phones running partner apps such as Life360 and Tile.
Hubble’s developer documentation is admirably specific about the satellite link. A device transmits during a pass window of three to five minutes, gets at least one such window per day, and the message usually reaches the customer within six hours. The payload is small:
“Hubble’s Satellite Network lets a standard Bluetooth® Low Energy (BLE) device transmit up to 13 bytes of data from almost anywhere outdoors…” (Hubble developer documentation, Satellite Network Transmission Guidance)
That is a legitimate product for a pallet, a cow, or a soil probe. The question is how fairly Hubble describes the alternative.
Hubble publishes two comparison pages that set its approach against “3GPP NTN,” meaning NB-IoT and LTE-M over satellite. We took each technical claim about the 3GPP side and checked it against the specifications.
This is exactly how the standard works. The device does the satellite math, and it needs a GNSS fix to do it:
“The UE shall have valid GNSS position as well as the ephemeris and common TA before connecting to an NTN cell.… The UE computes the frequency Doppler shift of the service link, and pre-compensates for it in the uplink transmissions, by considering UE position and the ephemeris.” (TS 36.300 v19.2.0 §23.21.2.2)
“A UE indicating support for any ue-Category-NB and ntn-Connectivity-EPC-r17 is assumed to have GNSS location capability.” (TS 36.306 v19.3.0 §4.3.38.1)
Fair point to Hubble. A GNSS receiver comes with the territory for satellite NB-IoT, and that is real cost and real battery.
None of the satellite bands defined for NB-IoT are below 1 GHz. Bands 255 and 256 are L-band and S-band:
“For satellite access (NTN), NB-IoT is designed to operate in the E-UTRA operating bands 249, 252, 253, 254, 255 and 256 which are defined in Table 5.2-1 in [74].” (TS 36.508 v19.2.0 §8.1.3.1; reference [74] is TS 36.102)
| Band | Device transmits (uplink) | Device receives (downlink) |
|---|---|---|
| 256 | 1980 to 2010 MHz | 2170 to 2200 MHz |
| 255 | 1626.5 to 1660.5 MHz | 1525 to 1559 MHz |
| 254 | 1610 to 1626.5 MHz | 2483.5 to 2500 MHz |
| 253 | 1668 to 1675 MHz | 1518 to 1525 MHz |
| 252 | 2000 to 2020 MHz | 2180 to 2200 MHz |
Source: TS 36.521-4 v19.2.0 §5.2. Band 249 (1616 to 1626.5 MHz, TDD, NB-IoT only) is also listed there.
This matters because Hubble builds an antenna-size argument on it. A quarter-wave antenna is about 4.7 cm at 1.6 GHz and about 3.1 cm at 2.4 GHz. That is a real difference for an ear tag, but it is an L-band penalty, not a sub-GHz one. The two LTE bands named on the page do not help the argument either: Band 23 sits at 2 GHz (the same airwaves as satellite Band 252), and Band 26 is a terrestrial 800 MHz band, not a satellite band.
Class 3 (23 dBm) is the default, but it is not the only option. Every NB-IoT satellite band also defines a 20 dBm class, the same power Hubble needs from a Bluetooth chip to reach orbit:
Table 6.2B.1-1 (UE Power Class): bands 249, 252, 253, 254, 255 and 256 each list Class 3 at 23 dBm and Class 5 at 20 dBm. Bands 255 and 256 add Class 2 at 26 dBm and Class 1 at 31 dBm. “The default power class… for an operating band is Power Class 3 unless otherwise stated.” (TS 36.102 v19.4.0 §6.2B.1, Table 6.2B.1-1)
Hubble’s stronger battery argument is about session length, not peak power: a Bluetooth burst lasts milliseconds, while a cellular session involves synchronization and signalling that runs for seconds. Hubble makes that point itself. The specifications do not settle the comparison. It depends on the chipset, the traffic, and the power-saving configuration, and it is worth measuring rather than asserting.
Release 18 and Release 19 are already in the specifications. The Release 19 edition of the LTE overview spec includes store-and-forward operation for satellite IoT, which is the 3GPP version of “your message arrives when a satellite can reach the ground”:
“Store and forward satellite operation is supported as described in TS 23.401 [17]. Store and forward mode provides communication service to the UE when the serving satellite has a discontinuous connection to the ground network and such connection is not available when the satellite is interacting with the UE.” (TS 36.300 v19.2.0 §4.12)
The higher power classes above also arrived after Release 17. Release 20 work (IoT NTN Phase 4) is under way now. Its objectives, as quoted in a Qualcomm contribution to RAN1#125, are to support voice calls over NB-IoT through geostationary satellites and to “study and if feasible, specify UE transmit power higher than PC1 (e.g. up to 37dBm)” (R1-2604688). RAN4 has since agreed names and nominal powers for two new classes, PC 0.5 at 34 dBm and PC 0.1 at 37 dBm, according to a CATT recap of the agreed way forward (R4-2606474). The 34 dBm class was judged feasible for handheld and non-handheld devices. The 37 dBm work focuses on non-handheld devices such as automotive. Neither set of requirements is final.
Hubble is right that there is no carrier certification layer. But its regulatory documentation is clear that the satellite mode needs a new FCC grant for each device design:
“If your device already holds an FCC ID for standard Bluetooth, that certification does not cover Satellite Network operation… You’ll need a new Part 15 certification for the Satellite Network-enabled configuration before commercial deployment, though your existing Bluetooth certification (and any chipset-level certification from your vendor) can typically be reused as supporting documentation rather than starting from zero.” (Hubble developer documentation, Satellite Network Regulatory Compliance)
So the honest version is “no carrier approval, but a new FCC grant per product,” and Hubble says devices on supported chipsets running its reference firmware typically pass without hardware changes. That is lighter than cellular certification. It is not the same as “already certified.”
Hubble includes the caveat, to its credit. Its chip compatibility page explains how big it is:
“Satellite transmission requires at least +20 dBm transmit power. Most Bluetooth SoCs top out well below that, so you need one of: A power amplifier (PA) or front-end module (FEM) on your board. An SoC with a +20 dBm integrated PA…” (Hubble developer documentation, Chip Compatibility)
For many existing products, “no new hardware” really means a board revision. For new designs that pick a supported chip, the bill-of-materials story holds up better.
The comparison page says 20 to 50 bytes. The developer documentation quoted above says up to 13 bytes on the satellite path. Engineers sizing a payload should use the documentation.
Hubble says this plainly, and it is the most important line on either page. If a device ever needs a command, a configuration change, an acknowledgment, or a firmware update over satellite, Hubble cannot do it today. Satellite NB-IoT can.
Hubble quotes $8 to $15 or more for an NTN module and $1 to $3 or more per device per month. Those are market numbers, not standards facts, and they move with volume and contracts. Get quotes.
Searching about 19,800 recent meeting contributions from the radio and architecture working groups turns up nothing that mentions Hubble or Bluetooth-to-satellite. 3GPP is not reacting to Hubble by name. Several tracks still land close to Hubble’s territory.
Delay-tolerant delivery is now a 3GPP feature. Store and forward started as a requirement written for exactly the kind of device Hubble serves:
“To expand the market of delay-tolerant IoT devices, store and forward operations are necessary to be developed to sustain the user plane data during the feeder link disconnection between the satellite and the terrestrial gateway.” (TR 22.865 v19.2.0 §5.3.1)
Cheaper satellite IoT is being proposed for 6G. For next week’s RAN1#126-bis meeting, ETRI proposes that 6G satellite IoT devices use a bandwidth of 3 MHz or less, support half-duplex FDD, and treat “GNSS-less operation as the baseline operation mode for IoT devices without a GNSS receiver.” It also asks for coverage enhancements so the system works with CubeSat-class satellites (R1-2608089, Proposal 19). That is a proposal from one research institute, not an agreement, but it targets the same costs Hubble attacks: the GNSS receiver and the expensive satellite.
The ultra-cheap tag has its own 3GPP track, on the ground. Ambient IoT targets devices that run on harvested energy. The Release 19 device is described this way in the Release 20 work item:
“~1 µW peak power consumption, has energy storage… neither R2D nor D2R amplification in the device. The device’s D2R transmission is backscattered on a carrier wave provided externally.” (Rel-20 Ambient IoT work item, as quoted in R1-2607103)
Release 20 adds an active device with a maximum transmit power of 5 dBm, in licensed spectrum, with readers “deployed on the same sites as existing outdoor NR macro BSs” (same source). It is the 3GPP answer to “a tag on every pallet,” but it needs a reader nearby. It does not reach orbit.
On power and capability, the paths are diverging. Hubble is going down: smaller payloads, simpler devices, one-way links. Release 20 is going up: 34 and 37 dBm classes and voice calls over a satellite IoT link. Both can be right for different devices.
In August the FCC opened a rulemaking, ET Docket 26-169, titled “Unleashing Unlicensed Spectrum for Direct-to-Device.” It proposes adding satellite uplink allocations in the 2400 to 2483.5 MHz and 5725 to 5850 MHz unlicensed bands, on a non-interference basis, and only asks questions about satellite downlinks. Hubble is the precedent:
“Hubble Network, Inc. (Hubble) was granted a satellite license to receive signals from 100 milliwatt (20 dBm) terrestrial devices operating in the 2482.710675-2483.424 MHz portion of the 2400-2483.5 MHz band with technical parameters consistent with part 15 Bluetooth Low Energy device operations.… This waiver was granted for infrequent use from a single United States location.” (FCC 26-51, Notice of Proposed Rulemaking, para. 17)
Today Hubble needs a waiver. If the proposal is adopted, any company could build a satellite service on the same bands as Wi-Fi and Bluetooth without buying spectrum. For carriers and licensed satellite operators, that is a cheaper competitor that never touches the spectrum they paid for.
The heavy hitters showed up before the vote. In the last two weeks of July, while the notice was still a public draft, SpaceX, WISPA, the amateur radio group ARRL, Ligado, NextNav, and a joint team from Broadcom, Intel, and Cisco all filed notices of meetings with FCC staff. CTIA, the US wireless carriers’ association, sent a letter on August 4. Since the notice was adopted, the LoRa Alliance, the meter maker Zenner, and AST SpaceMobile (after a September 28 meeting with Chairman Carr) have filed, along with individual commenters. Hubble itself has not filed.
The fixed-wireless trade group WISPA was the most public critic of the draft, which said satellite uplinks would not raise interference risk:
“This tentative conclusion is unsupported and lacks any tangible study.” (WISPA filing on the draft notice, as reported by Light Reading)
The adopted text softened that line into a question. It now reads that the Commission “believe[s], and seek[s] comment on whether,” the change could be small enough not to increase harmful interference (FCC 26-51, para. 14). That is the question the formal record has to answer. Comments are due November 9 and replies December 7, which is when carriers, chipmakers, and satellite operators put full positions on the record.
A detail worth noticing: the downlink of NB-IoT satellite Band 254 starts at 2483.5 MHz, exactly where the 2.4 GHz unlicensed band ends (TS 36.521-4 §5.2). Hubble’s licensed slice stops at 2483.424 MHz, 76 kHz below that edge. Anyone filing on coexistence will be looking closely at that boundary.
Check our work, or check the next claim yourself
Every 3GPP quote above came from 3GPP Scout, which searches the full text of every TS and TR across Rel-15 through Rel-20 plus recent meeting contributions, and answers follow-ups with clause-level citations. Ask it to compare satellite IoT power classes across releases, or to show what was proposed at next week’s meetings.
How we made this: we read Hubble’s two public comparison pages and its developer documentation on October 5, 2026, took each technical claim about 3GPP satellite IoT, and checked it against the specification text and meeting contributions indexed in 3GPP Scout. Spec versions are cited next to each quote. Regulatory details come from the FCC’s notice and its public filing system. We have no commercial relationship with Hubble or any satellite operator.
3GPP Scout is not affiliated with or endorsed by 3GPP, Hubble Network, or the FCC. Questions: [email protected]