BLE Mesh Transport

Summary: Bluetooth Low Energy as a mesh carrier, phone bridge relay, and WiFi downgrade path. Fills the gap between LoRa (long range, very low throughput) and WiFi (high throughput, needs infrastructure).

Status: Research complete — 4-phase roadmap drafted. Implementation not started.

Motivation

Styrene’s transport stack currently covers:

TransportRangeThroughputInfrastructure
WiFi (802.11s + BATMAN-adv)~50m indoorMbpsMesh routers or direct
LoRa (via RNode)1-15 km150-2400 bpsNone
TCP/IP (internet)GlobalMbps-GbpsInternet access

BLE fills the middle ground:

TransportRangeThroughputInfrastructure
BLE 5.0~100m outdoor, ~30m indoor~125 KB/s (1 Mbps PHY)None

More importantly, BLE enables phone bridge — using a smartphone as a relay between the Reticulum mesh and the wider network, without requiring the phone to run a full RNS transport node.

Phone Bridge Architecture

[Fleet Device]  ←— BLE GATT —→  [Phone]  ←— TCP/IP —→  [Internet / Hub]
   styrened                    Relay App                rns.styrene.io:4242

The phone acts as a transparent bridge: BLE on one side, TCP on the other. The phone doesn’t need to understand RNS — it just shuttles bytes between a BLE GATT characteristic and a TCP socket.

Implementation Sketch

Fleet device side: bless GATT daemon advertising a Styrene service UUID. styrened’s transport layer connects to this as a serial-like interface.

Phone side: Flutter (or native) app that:

  1. Scans for Styrene BLE service UUID
  2. Connects and subscribes to GATT notifications
  3. Opens TCP connection to configured RNS transport node
  4. Relays bytes bidirectionally

Hardware Matrix

DeviceBLE VersionNotes
Raspberry Pi 4BLE 5.0Built-in, well-supported
Raspberry Pi Zero 2WBLE 5.0Built-in, constrained RAM
nRF52840 USB dongleBLE 5.0Dedicated, excellent range
ESP32-S3BLE 5.0Companion MCU option
Most smartphonesBLE 5.0+Bridge relay

Power Characteristics

BLE is designed for power-constrained devices:

ModeCurrent DrawDuration
Advertising~15 mAContinuous
Connected (idle)~5 mABetween packets
Transmitting~15-20 mAPer packet burst
Deep sleep~1-5 µABetween connections

Compare to WiFi: ~100-300 mA continuous. BLE is 10-50x more power efficient for intermittent messaging.

4-Phase Roadmap

Phase 1: Phone Bridge

Basic relay app + bless GATT daemon on fleet device. Prove bytes flow from styrened through BLE through phone to internet.

Phase 2: BLEInterface for RNS

Native BLEInterface class in Reticulum‘s interface hierarchy, alongside TCPInterface, UDPInterface, AutoInterface. Uses BLE as a serial-like transport for RNS packets.

Phase 3: Adaptive Transport

styrened automatically discovers and uses BLE when WiFi is unavailable. Transport selection: WiFi preferred → BLE fallback → LoRa last resort.

Phase 4: BLE Mesh Backbone

Multiple BLE devices forming a mesh (BLE Mesh or custom relay protocol). Extends range beyond single-hop BLE.

BLE vs BATMAN-adv

BLE mesh and BATMAN-adv solve different problems:

AspectBLE MeshBATMAN-adv
Range per hop~30-100m~50-200m (WiFi)
Throughput~125 KB/sMbps
PowerµW-mW100+ mW
InfrastructureNoneWiFi radios
Use casePhone bridge, low-power sensorsFleet backbone

They complement each other. BATMAN-adv is the primary mesh; BLE is for constrained scenarios.

Open Questions

  1. Phase 1 implementation — bless GATT daemon + Flutter relay app (vs native Android/iOS)
  2. nRF52840 USB dongle — evaluation for Pi hardware (dedicated BLE radio, frees onboard WiFi)
  3. BLEInterface class design — how to integrate with RNS transport hierarchy
  4. Android BLE background limits — phone bridge needs to survive Android’s aggressive background task killing
  5. Encryption — BLE link encryption vs. relying on RNS E2E encryption (RNS encryption is sufficient; BLE encryption is optional defense-in-depth)

References

Graph

Backlinks