Hubble Network Platform Documentation
website·Indexed 34 days ago
https://docs.hubble.com/Developer documentation for the Hubble Network, an IoT connectivity platform utilizing Bluetooth Low Energy (BLE) chips and a combined satellite and terrestrial gateway network. Includes guides for the Device SDK, Hubble CLI, cloud integration via OpenAPI, and security protocols for BLE advertisement encryption and EID rotation.
What's inside Hubble Network
- A Hubble scanner is a device with BLE scanning capabilities and internet access that performs three primary tasks: scanning for Hubble BLE advertisements (passive scanning), packaging the data with a timestamp and location, and delivering that data to the Hubble backend. The scanner does not connect to or interact with Hubble devices; it only listens for advertisements.
Overview of Satellite Network Regulatory Compliance in North America
Devices using the Hubble Satellite Network protocol for commercial deployment in the United States, Canada, and Mexico must obtain regulatory certification before commercial launch. This is the responsibility of the device manufacturer or operator (the 'responsible party'), not Hubble.
Note: The Hubble Terrestrial Network protocol uses standard Bluetooth® Low Energy (BLE) specifications and does not require this specific re-certification.
Overview of the Hubble Pilot Framework validation phases
Before ramping up production, the Hubble Network rollout follows four validation phases to ensure coverage, connectivity, and backend integration. This framework is optimized for asset tracking and micro-telemetry use cases.
Phase Goal Primary Tool Timing Coverage Validation Evaluate network coverage without updating devices Network Explorer Day 1 Technical Validation Confirm network connectivity via dev board firmware Dash Quick Start, GitHub Repo Week 1 Network Validation Measure live performance with real-world hardware Custom Hardware Weeks 2–3 Platform Validation Confirm backend ingestion via API/webhooks REST API + Webhooks Week 4 Ramp in Production Roll out connectivity across production devices Dashboard + Cloud API Post go/no-go Overview of Hubble Connect mobile app
Hubble Connect is a mobile application that converts a mobile device into a scanning gateway on the Terrestrial Network. It is used for device testing and closed-loop connectivity within the Sandbox environment. The app is required to retrieve data in Sandbox.Overview of the Hubble Terrestrial Network
The Hubble Terrestrial Network is a global infrastructure powered by Bluetooth® Low Energy (BLE) scanning gateways. It is designed to capture device broadcasts across diverse environments, including major cities, highways, ports, and rural regions.Overview of Hubble Satellite Network capabilities
Hubble's Satellite Network allows standard BLE devices to transmit up to 13 bytes of data from outdoor locations without gateways, cellular, or Wi-Fi. It uses the existing 2.4 GHz BLE radio. The network is designed for stationary or region-locked outdoor devices sending small, infrequent updates (e.g., asset tracking, environmental sensors). It is not suitable for real-time reporting, high-frequency data, large payloads, or indoor use.Overview of Hubble Network Encryption Concepts
The Hubble Network uses several cryptographic techniques to ensure confidentiality, integrity, and authenticity for BLE transmissions from anonymous devices:
- AES Encryption: Supports AES-256 (recommended) and AES-128 symmetric encryption.
- CMAC (Cipher-based Message Authentication Code): Used to generate a MAC to ensure data integrity and authenticity.
- KBKDF (Key-Based Key Derivation Function): Derives keys from a master key using a label, context, and counter, utilizing CMAC as the pseudorandom function (PRF) per NIST 800-108.
- Nonce Generation: A unique nonce is generated for every encryption operation via KBKDF (using the label "Nonce" and the current sequence number) to ensure the same plaintext produces different ciphertexts.
Understand Hubble Device SDK power consumption
The Hubble Device SDK leverages the standard Bluetooth stack for beaconing and does not introduce additional power draw when generating advertising packets. Power optimization is the responsibility of the developer at the application level for the chosen chip.Understand the Hubble Terrestrial Network data flow
The Hubble Terrestrial Network enables global data transmission for IoT devices using Bluetooth® Low Energy (BLE). The process follows these steps:
- Device Beaconing: A device broadcasts short BLE advertisements containing an encrypted payload.
- Gateway Detection: A network of scanning gateways (smartphones or dedicated hardware) detects the advertisement when the device is within range.
- Metadata Attachment: The gateway appends its own location, signal strength, and location accuracy metadata to the record.
- Backend Processing: The gateway forwards the packet to the Hubble backend, creating a timestamped detection event.
- Delivery: The decrypted packet, including the custom payload, location, and timestamp, is delivered to the customer application via API or Webhook.
Note: Detection is probabilistic. The frequency of captures depends on scanner density, signal strength, device beaconing behavior, and platform-specific scanning schedules.
Hubble CLI Command Groups Overview
Commands in the Hubble CLI are organized into three primary groups:ble(local Bluetooth scanning and decryption),org(Hubble Cloud management, registration, and data retrieval), andsat(Satellite reception via Pluto SDR).Visualize custom sensor data in the Hubble Dashboard
Hubble provides 13 bytes of customizable data in the BLE advertisement payload. To visualize this data in the Hubble Dashboard (Packet History and Sensor Widget), you must encode the payload using a specific type-value index. When a known type ID is detected, the dashboard automatically decodes the payload inline and plots time-series data for recognized types.Understand Hubble Network end-to-end data security
Hubble Network implements a multi-layered security model to ensure data integrity and anonymity from the device to the cloud:
- Device Anonymity: Devices remain anonymous using Key-Based Key Derivation Function (KBKDF) and secure on-device key management.
- Transmission Encryption: Every packet is encrypted using AES (Advanced Encryption Standard) in counter mode. Message integrity is ensured via CMAC (Cipher-based Message Authentication Code).
- Replay Protection: The Hubble backend validates message sequence numbers to prevent replay attacks.
- Cloud Security: Data is encrypted at rest in the Hubble Cloud and protected by authentication-based access control.
- Double Envelope Encryption: Users can implement an additional layer of proprietary encryption at the payload creation stage. If this is used, the private data remains encrypted even after the Hubble Cloud decrypts the network layer, ensuring the data is never visible to the Hubble Network.