Two things with similar names
“Bluetooth mesh” gets used for two different things.
- Bluetooth Mesh, with a capital M, is a specification from the Bluetooth SIG. It defines how lights, switches, sensors, and similar devices join a network through provisioning, share network and application keys, and relay messages by managed flooding or directed forwarding. How Bluetooth Mesh works covers it in detail.
- A phone mesh over BLE is something an app builds for itself. Phones running the same app find each other over Bluetooth Low Energy, exchange data over ordinary BLE connections, and forward messages for each other according to rules the app defines.
Both use the same radio. They differ in who defines the protocol, which devices take part, and what the phone is allowed to do.
How phones take part in Bluetooth Mesh
The Bluetooth SIG’s FAQ gives smartphone developers two options. If the operating system’s APIs let an app meet the mesh specification’s requirements for advertising packets, the app should use the advertising bearer, which the SIG calls the preferred bearer in all cases. Where that is not possible, the app can use the proxy protocol, which runs over standard BLE GAP and GATT APIs and talks to the network through a node with the proxy feature.
On iOS, the second route is the only one. Apple’s Core Bluetooth documentation says an app’s advertising data supports only two keys, the local name and service UUIDs. Nordic Semiconductor’s nRF Mesh library for iOS states that implementing the advertising bearer on iOS is not possible because of API limitations, so it uses the GATT proxy protocol and needs a node with the proxy feature to relay its messages into the network.
On Android, the public builder for advertising data offers a fixed set of fields: service UUIDs, service data, manufacturer data, solicitation UUIDs, transport discovery data, the device name, and the transmit power level. Nordic’s Android library provisions a node by connecting to it and exchanges mesh traffic through GATT writes and notifications, with proxy filter support.
In both of Nordic’s libraries, the phone works as a provisioner and controller that reaches the network through a connection to a node, and the SIG’s primer notes that a proxy client must be provisioned like any other device. The phone is a member of the mesh, but the lights, switches, and relay nodes form it and carry its traffic.
How a phone mesh over BLE works
An app that builds its own mesh uses the BLE features both platforms expose to apps. One phone advertises a service UUID the app has chosen and runs a GATT server; another scans for that UUID, connects as a central, and exchanges data through characteristics. BLE centrals and peripherals explains those roles.
Everything above that is the app’s own design: how devices are identified, how a message is addressed, when a phone forwards it, how far it may travel, how duplicates are dropped, and how content is encrypted. No provisioning step, network key, or proxy node from the SIG specification is involved, and no special hardware is needed beyond the phone’s Bluetooth radio.
Offline Protocol is one example. Its FAQ says the SDK runs its own application protocol over BLE between devices running the SDK, with its own routing, MLS encryption, and identity, so it works on ordinary phones with no mesh-profile hardware, and that Bluetooth SIG Mesh devices form a separate network.
Side by side
| Bluetooth Mesh | Phone mesh over BLE | |
|---|---|---|
| Defined by | Bluetooth SIG specification | The app or SDK |
| Typical devices | Lights, switches, sensors, building systems | Phones and other devices running the same app |
| Joining | Provisioning by a Provisioner | The app’s own discovery and identity |
| Relaying | Relay nodes over the advertising bearer | Phones forwarding over BLE connections, by the app’s rules |
| Security | Network, application, and device keys | Whatever the app implements, ideally end-to-end encryption |
| Phone’s role | Usually provisioner or proxy client | Full participant and relay |
| Interoperability | Products that implement the specification | Only devices running the same protocol |
Which one fits
Bluetooth Mesh fits fixed infrastructure: lighting, sensors, and building control, where products from different vendors need to work together and a phone is mainly a commissioning and control tool. The SIG recommends building on a qualified SDK from a mesh solution provider.
A phone mesh fits when the phones themselves are the network, such as people messaging nearby with no signal. Can phones form a mesh network without internet? looks at what that takes. The trade-off is that only devices running the same protocol can join.