Mobile-to-IoT Connection Topology: Direct vs Cloud vs Hybrid

Connection Mode

Direct BLE active

Scenario

Device distance from phone 4 m

Command rate 1.0 /s

Cloud network quality (loss) 3%

Live Telemetry

Round-trip latency

— ms

Delivery success

100%

Commands sent

Commands lost

How it works

A mobile app can reach an IoT device three ways, and the article's own architecture section names all three: Direct (App → Device over Bluetooth Low Energy), Cloud-based (App → Cloud → Device), and Hybrid — pick whichever is faster right now.

Direct BLE reliability uses a log-distance path-loss model to turn distance into a delivered-packet probability:

RSSI(d) = TxPower − 10·n·log10(d / d0)
P_deliver(d) = clamp(1 − (d / R_ble)^3, 0.02, 0.99)

where R_ble ≈ 12 m is the practical BLE range from the article. Latency stays low (connection-interval sized, ~15–35 ms) but delivery collapses fast once distance passes R_ble — the classic BLE cliff.

Cloud relay latency is the sum of two independent network hops, each with its own base delay and jitter, and is distance-independent because the phone always reaches its own gateway/WiFi first:

RTT_cloud = (uplink_base + jitter₁) + (broker_process) + (downlink_base + jitter₂)
P_deliver = 1 − loss_rate (from the network-quality slider)

Auto Hybrid picks Direct whenever distance is safely inside BLE range (d < 0.8·R_ble) and falls back to Cloud otherwise, paying a one-time hand-off penalty on the command right after a switch — mirroring how a real hybrid stack renegotiates a session when it changes transport.

Move the distance slider past ~10 m in Direct mode and watch delivery success fall off a cliff while latency barely moves; switch to Cloud and see the opposite — flat, high, distance-independent latency and success. Auto Hybrid tracks whichever curve is currently better.

Phone (mobile app) IoT device Cloud relay

⚠ Couldn't load the 3D engineThree.js failed to load from the CDN. Check your connection and reload.