Advertising Packet
Hubble's Terrestrial Network advertising packet follows Bluetooth® Low Energy (BLE) specifications for secure, efficient transmission of small data payloads.
Packet Structure
The Bluetooth standard advertising packet is composed of three main components:
- Header: Establishes the type of packet and transmission requirements.
- Advertising Address: A 48-bit address as per BLE standards.
- Advertising Payload: A standard Service Data container that includes Hubble protocol fields and customer data, formatted and size-limited depending on transmission requirements.
Header Details
The packet header includes a key field, the Protocol Data Unit (PDU) Type, which defines the packet size and determines whether communication will be unidirectional or bidirectional.
Hubble’s Terrestrial Network currently supports any BLE advertising PDU type that includes the Hubble 16-bit Service UUID (0xFCA6). Our scanning gateways filter on Service UUID, not PDU type. Common configurations include::
- ADV_NONCONN_IND: Non-connectable, recommended for broadcast-only devices. Lowest power usage.
- ADV_IND: Connectable, for devices that need to accept BLE connections alongside Hubble. Add your own service UUID to the advertisement so your app can identify devices for connection.
Advertising Address
A 48-bit address as per BLE standards. We recommend a Non-Resolvable Private Address (NRPA) because it is:
- Generated randomly.
- Cannot be resolved back to a real identity.
- Changes frequently.
- Does not require any keys to generate or interpret.
Advertising Payload
Hubble’s Terrestrial Network follows the standard Bluetooth Advertising Data (AD) structure: [Length] [AD Type] [AD Data…]. Within this structure, Hubble defines its own Service Data field that contains Hubble-specific protocol information along with up to 13 bytes of optional custom application data.
To construct the full Advertising Payload, use the Advertisement Retrieval function from the Hubble Terrestrial Network SDK in combination with standard Bluetooth specifications:
- Bluetooth specification: Include the Hubble 16-bit Service UUID in the Complete List of 16-bit Servuice UUIDs (bits 0-31)
- Bluetooth specification: Define a Service Data - 16-bit UUID container for Hubble (bits 32-63)
- Hubble SDK: Generate the Service Data contents (bits 64-143)
- (Optional) Hubble SDK: Append a custom encrypted payload within the Service Data (bits 144-247)
The bit allocation in the example assumes that Hubble is the only service being advertised in the payload.
Standard Bluetooth Service UUID list
This AD structure advertises the Hubble service among other possible services.
| Bits | Endianness | Purpose | Requirement | Example Data |
|---|---|---|---|---|
| 0-7 | Little | AD Structure Length | Configurable | 0x03 |
| 8-15 | Little | AD Type: Complete List of 16-bit Service UUIDs | Configurable | 0x03 |
| 16-31 | Little | Hubble 16-bit Service UUID | Mandatory | 0xFCA6 |
Standard Bluetooth Service Data container (for Hubble)
| Bits | Endianness | Purpose | Requirement | Example Data |
|---|---|---|---|---|
| 32-39 | Little | AD Structure Length: Service Data | Configurable | 13-26 |
| 40-47 | Little | AD Type: Service Data | Mandatory | 0x16 |
| 48-63 | Little | Hubble 16-bit Service UUID | Mandatory | 0xFCA6 |
Why the Service UUID appears twice: The Hubble 16-bit Service UUID (0xFCA6) is listed once in the Service-UUID AD structure and again within the Service Data AD structure, following the Bluetooth specification.
Hubble-specific fields (inside Service Data)
These fields are defined by Hubble and encoded within the Service Data value when a packet is request through the SDK.
| Bits | Endianness | Purpose | Requirement | Example Data |
|---|---|---|---|---|
| 64-69 | Big | Hubble Terrestrial Network Protocol Version | Provided by SDK | 0 - 63 |
| 70-79 | Big | Sequence Number (SeqNo) | Provided by SDK | 0 - 1023 |
| 80-111 | Big | Ephemeral Device Identifier (EID) | Provided by SDK | 32 bits |
| 112-143 | Big | Authentication Tag | Provided by SDK | 32 bits |
Custom Payload (application-defined)
This field carries encrypted customer data generated at the application layer. Its content and length are defined by the customer implementation. Set the custom payload using the data parameter in the Advertisement Retrieval function in the Terrestrial Network SDK.
| Bits | Endianness | Purpose | Requirement | Example Data |
|---|---|---|---|---|
| 144-247 | Big | Customer Application Payload (encrypted) | Configurable | Up to 13 bytes |
FAQs
- Is the Flags AD Type required? No, it is not strictly required for non-connectable/non-scannable devices. The AD Type for Hubble's 16-bit Service UUID included in the advertising payload is sufficient to connect to Hubble Terrestrial Network. Your application may additionally use Flags AD Type (0x01) if desired.