DOCSEARCHbyAlgolia
Submit Docs

Hubble Network Platform Documentation

website·Indexed 34 days ago

https://hubble.com/docs

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.

Tokens
66.5K
Snippets
158
Records
494
Agent score
66%

What's inside Hubble Network

  1. Overview of Hubble Scanner functionality

    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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

    PhaseGoalPrimary ToolTiming
    Coverage ValidationEvaluate network coverage without updating devicesNetwork ExplorerDay 1
    Technical ValidationConfirm network connectivity via dev board firmwareDash Quick Start, GitHub RepoWeek 1
    Network ValidationMeasure live performance with real-world hardwareCustom HardwareWeeks 2–3
    Platform ValidationConfirm backend ingestion via API/webhooksREST API + WebhooksWeek 4
    Ramp in ProductionRoll out connectivity across production devicesDashboard + Cloud APIPost go/no-go

  6. 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.

  7. 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.

  8. Understand the Hubble Terrestrial Network Advertising Packet structure

    Hubble's Terrestrial Network uses Bluetooth Low Energy (BLE) advertising packets. The packet consists of three main components:

    1. Header: Defines the PDU Type (packet size and communication direction).
    2. Advertising Address: A 48-bit address. Hubble recommends using a Non-Resolvable Private Address (NRPA) for privacy and security.
    3. Advertising Payload: A standard BLE Advertising Data (AD) structure containing the Hubble Service UUID and Service Data.

  9. Understand Hubble Network end-to-end data security

    Hubble Network ensures data security from device broadcast to cloud storage using the following mechanisms:

    • Device Anonymity: Achieved via KBKDF (Key-Based Key Derivation Function) and secure on-device key management.
    • Transmission Encryption: Each transmission uses AES (Advanced Encryption Standard) counter mode.
    • Integrity & Authenticity: CMAC (Cipher-based Message Authentication Code) provides message authentication. The backend validates sequence numbers to prevent replay attacks.
    • Cloud Security: Data at rest is encrypted and protected by authentication-based access control.

  10. Hubble Network Data Flow Overview

    The Hubble Network operates as an IoT connectivity platform where tracked devices transmit encrypted payloads via BLE (Bluetooth Low Energy) advertisements. These advertisements are detected by a global network of scanning gateways (consisting of over 100 million scanners), which then forward the packets to the backend for processing.

  11. Manage Hubble Network Organization types

    Hubble provides three organization environments based on the development stage:

    1. Sandbox: The default free environment for initial device activation. It is limited to packets captured locally via the Hubble Connect mobile app (phone acts as the gateway).
    2. Production Org: The live environment with full access to the global network (100M+ scanning gateways) for deployed devices.
    3. Staging Org: A siloed environment for testing hardware revisions or integrations. It has the same Live Network access as Production but uses a separate Org ID, separate user access, and separate API credentials.

  12. Manage Bluetooth beacon production with an ODM

    When using an Outsourced Design Manufacturer (ODM) to produce Bluetooth beacons with Hubble firmware, device ownership is determined by the device key (a unique identifier). To ensure devices are registered to the correct organization, provisioning should happen at the factory. This is critical because many firmware images do not support post-production key writes and it integrates better with existing factory flashing toolchains.