Bluetooth Mesh Architecture: Managed Flooding, Provisioning, Friend Nodes and Security

Most engineers meet Bluetooth mesh as a promise that sounds almost too convenient: hundreds of cheap radios, no gateway, no routing tables, and messages that somehow find their way across a building. The reality is stranger and more interesting. Bluetooth mesh does not route at all in its original form. It floods, then uses a handful of carefully designed brakes to keep the flood from drowning the very radio channel it depends on.

That design choice explains almost everything else: why a battery sensor needs a “friend” to hold its mail, why every packet is encrypted twice, and why the 2023 Mesh 1.1 update bolted a real path-based forwarding option onto the side of the original architecture. If you are sizing a lighting, asset-tracking or building-automation network in 2026, understanding those trade-offs is the difference between a network that scales and one that collapses at 200 nodes.

You will leave with a working mental model of the stack, the arithmetic of airtime and sequence numbers, and a checklist for provisioning and key management.

What this covers: the layered architecture, managed flooding and its limits, the provisioning protocol, friendship between low power nodes and friend nodes, Mesh 1.1 directed forwarding, the key hierarchy, failure modes, and deployment guidance.

Context and Background

Bluetooth mesh was adopted by the Bluetooth Special Interest Group (SIG) in July 2017 as a many-to-many topology that runs on top of ordinary Bluetooth Low Energy (BLE) radios. It is not a new radio. It reuses the BLE advertising channels and a Generic Attribute Profile (GATT) proxy path, which means any phone or chip with a modern BLE stack can participate. Mesh 1.1, announced by the SIG on 19 September 2023, added features such as directed forwarding, remote provisioning and device firmware update. Those additions are verified against the SIG’s own feature enhancements summary.

The incumbents tell you what mesh was competing against. Zigbee, which we cover in our complete Zigbee protocol guide, builds an IEEE 802.15.4 network with coordinators, routers and end devices, and it routes unicast traffic with a reactive, AODV-style algorithm. Thread, covered in our OpenThread border router and Matter architecture article, carries IPv6 over 6LoWPAN with a distributed routing protocol and leader election. Both build routes. Bluetooth mesh deliberately does not.

The reason is the phone. Bluetooth mesh was designed so that a smartphone with no special radio could talk to a lighting installation. Smartphones speak BLE, they do not speak 802.15.4, and they would have to speak mesh without being part of a routing protocol. A flooding design lets a phone inject one advertisement or one GATT write and trust the network to do the rest.

Commercial lighting is the anchor market. A luminaire already has mains power, so it can relay all day, and the group-addressed “turn these 40 lights on” command maps perfectly onto flooding, because every receiver is a destination anyway. Asset tracking, building automation and industrial sensing grew from that base, and each stretches the original assumptions in a different direction.

Two caveats are worth stating early. First, this article describes the specifications as published by the SIG and treats numeric limits as spec values unless marked otherwise. Second, any airtime, battery or channel-load figures are worked from stated assumptions and are illustrative, not benchmarks. Real networks add retries, interference and vendor stack behaviour that no formula captures.

The Bluetooth Mesh Reference Architecture

Direct answer: Bluetooth mesh is a layered, flooding-based many-to-many network built on BLE advertising. Nodes publish messages to addresses, relay nodes rebroadcast them under a time-to-live limit, a message cache suppresses duplicates, and every packet is protected by two keys: a network key and an application key.

Figure 1: The Bluetooth mesh stack. The bearer carries advertising or GATT frames, the network layer handles relaying and network encryption, the transport layer segments and acknowledges, and models define application behaviour.

The figure shows the stack from the bottom up. A mesh node is only as capable as its weakest layer, so it is worth walking through each in turn and noting what each one does that the others cannot.

Bearer and network layer: advertising, relay and the 29-byte packet

Two bearers exist. The advertising bearer sends mesh packets inside standard BLE advertising data, using dedicated advertising data types for mesh messages, mesh beacons and provisioning (PB-ADV). The GATT bearer lets a device that cannot advertise mesh PDUs, such as a phone, tunnel them over a connection to a proxy node.

A legacy BLE advertising packet carries at most 31 bytes of advertising data. Subtract the two-byte AD header and a mesh network PDU can be at most 29 bytes. That figure is derived from the packet limits, and it shapes everything above it. Those 29 bytes hold a one-byte IVI/NID field, a one-byte CTL/TTL field, a three-byte sequence number, two-byte source and destination addresses, up to 16 bytes of transport PDU and a 4- or 8-byte network message integrity check (NetMIC).

The network layer does four jobs. It encrypts and authenticates the PDU with the network key material. It obfuscates the header fields so a passive observer cannot trivially track a node by its sequence number. It decides whether to relay. And it checks whether the destination address matches the node or one of its subscriptions.

Relaying is controlled by the TTL field. The values, as documented by Silicon Labs, are: 0 means the message is never relayed, 1 means it can be received but not forwarded, 2 to 126 is relayable, and 127 is a special value meaning the sender did not specify one. A relay forwards only if the received TTL is at least 2 and decrements it each hop.

Transport, access and models

The lower transport layer handles segmentation and reassembly. An unsegmented message fits in one network PDU, which leaves roughly 11 bytes of access payload once the opcode and the 4-byte transport MIC are accounted for. Longer messages are split into segments of 12 bytes each, up to 32 segments, giving a theoretical ceiling of 384 bytes including the transport MIC. These are Mesh Profile 1.0 values from my reading of the specification, and I recommend checking them against the current Mesh Protocol document before relying on them in a design.

Segmented messages are acknowledged. The sender retransmits unacknowledged segments on a timer that scales with TTL, which matters because a segmented message across five hops can take hundreds of milliseconds to complete. Unsegmented messages are fire and forget unless the model above adds its own acknowledgement.

The access layer defines how application data is formatted and which key protects it. A model, the unit of application behaviour, defines states, messages and behaviours. Generic OnOff, Light Lightness and Sensor are well-known examples, and the Foundation models (Configuration Server and Health Server) are mandatory on every node because they allow remote management.

Addressing: unicast, group and virtual

Addresses are 16 bits. Unicast addresses identify one element of one node, and are assigned during provisioning. Group addresses identify a set of subscribers and are the workhorse of lighting control. Virtual addresses are derived from a 128-bit label UUID and are useful for large, loosely coordinated groups. Four fixed group addresses (all-proxies, all-friends, all-relays and all-nodes) round out the space.

This addressing model is why flooding is an honest fit. A “send to group” message must reach many nodes regardless, so no per-destination route exists to compute. The cost shows up when you send to a single far-away unicast destination: the whole relay population still retransmits it.

Managed flooding: how a flood is kept under control

The SIG calls the scheme managed flooding, and the word “managed” is doing real work. Six mechanisms cooperate, shown in Figure 2.

Figure 2: Managed flooding. A relay checks the message cache, drops duplicates, decrements TTL and retransmits a limited number of times with randomised delays.

First, the message cache records recently seen network PDUs, so a relay that hears the same packet from three neighbours rebroadcasts it once. Second, the TTL bounds the hop count, so a message in a 6-hop-diameter network cannot circulate forever. Third, relay is optional: only nodes with the relay feature enabled retransmit, so a designer can thin the relay population. Fourth, network transmit and relay retransmit states control how many times, and how far apart, each node repeats a packet. Fifth, heartbeat messages let nodes advertise their presence and hop distance, allowing a configurator to measure the topology. Sixth, friend nodes shield battery devices from the flood entirely.

The retransmit parameters are specific. Per the Silicon Labs documentation, the retransmit count is a 3-bit field from 0 (one transmission) to 7 (one plus seven retransmissions), and the interval is a 5-bit field giving (value + 1) x 10 ms, so 10 ms to 320 ms. Advertising on the three primary channels, with these retransmissions, is the only way a mesh packet gets heard. Nothing is acknowledged at the network layer.

Deeper Analysis: Airtime, Provisioning and Friendship

The arithmetic of a flood

Managed flooding is cheap per hop and expensive in aggregate. A legacy advertising PDU carries 6 bytes of advertiser address plus up to 31 bytes of data, framed by a 1-byte preamble, 4-byte access address, 2-byte header and 3-byte CRC. That totals 47 bytes, or 376 microseconds at 1 Mbit/s on one channel. That number is derived from the packet format, not measured.

Suppose a single collision domain, meaning every node hears every other, which is the worst case. A message sent by one node with R active relays, each repeating C times, produces about (R + 1) x C transmissions, because the message cache ensures each relay rebroadcasts a given message only once per reception event.

Take a hypothetical 100-node network where 40 nodes relay, the network transmit count is 3, and sensors publish every 10 seconds. That is 10 messages per second across the network. Transmissions per second are 10 x 41 x 3 = 1,230. At 376 microseconds each, one advertising channel is busy for 462 ms of every second, or 46 percent. Collisions at that load are severe, because BLE advertising has no listen-before-talk, only a small random delay.

Now thin the relays to 12 and drop the count to 2. Transmissions fall to 10 x 13 x 2 = 260 per second, or about 9.8 percent channel load. The message still gets across because a connected 12-relay backbone with overlapping coverage is enough. The lesson is the counter-intuitive one: more relays reduce reliability past a threshold, because the redundancy meant to protect delivery generates the collisions that destroy it.

Scenario (illustrative)	Relays	Tx count	Tx/s at 10 msg/s	Single-channel load
Every mains node relays	40	3	1,230	about 46%
Thinned backbone	12	2	260	about 9.8%
Sparse backbone, single send	12	1	130	about 4.9%

Assumptions: single collision domain, 376 microsecond packets, one channel counted, no retries, no non-mesh BLE traffic. Real deployments are multi-domain and loads are partly spatially reused, so treat these as an upper bound for intuition.

Provisioning: turning a stranger into a member

A new device is an unprovisioned device. It advertises a Universally Unique Identifier (UUID) in an unprovisioned device beacon. BLE mesh provisioning is the process by which a provisioner, typically a phone app or a commissioning tool, authenticates it, hands it keys and assigns an address. Figure 3 shows the exchange.

Figure 3: The provisioning protocol. Invite, capabilities, start, public key exchange, authentication, random exchange, confirmation and finally the encrypted provisioning data containing the network key.

The provisioner sends an Invite and the device answers with Capabilities: how many elements it has, which algorithms and public key types it supports, and which out-of-band (OOB) authentication methods it can do. The provisioner picks one in Start. Both sides then exchange public keys for an elliptic-curve Diffie-Hellman (ECDH) key agreement on the P-256 curve, which gives a shared secret nobody listening to the advertisements can compute.

Authentication is where the security properties are decided. In the no-OOB method, nothing proves the device identity, so a man in the middle during provisioning is undetected. Static OOB uses a pre-shared value, for example one printed on a label or sent through a manufacturing database. Output OOB makes the device display or signal a random value, by blinking an LED a number of times or showing digits, which the user types into the provisioner. Input OOB works the other way around. The spec defines these behaviours, including blink, beep, vibrate, numeric and alphanumeric variants.

Both sides then exchange random numbers and confirmation values built with an AES-CMAC, defined in RFC 4493, proving each knows the same authentication value. A session key derived from the ECDH secret protects the final Provisioning Data PDU, which delivers the network key, its index, flags for key refresh and IV update, the current IV Index, and the unicast address of the device’s primary element.

A provisioned node also receives a unique device key, known only to itself and the provisioner. The device key is used to secure configuration messages, so even another administrator holding the network and application keys cannot reconfigure the node unless they also hold its device key.

The provisioning bearer matters operationally. PB-ADV runs over advertising and is what you use to provision from a phone in range. PB-GATT uses a GATT connection and is common where the phone must connect to the device. Mesh 1.1 added remote provisioning, which lets the provisioner reach an unprovisioned device across one or more mesh hops, and certificate-based provisioning, which uses X.509 certificates to authenticate a device’s public key and UUID. The SIG describes the latter as enabling out-of-sight and bulk provisioning. Mesh 1.1 also introduced a new authentication algorithm identified as BTM_ECDH_P256_HMAC_SHA256_AES_CCM, according to the SIG summary.

Friendship: letting a coin cell sleep

A node that listens continuously burns milliamps. A node on a CR2032 cannot afford that. The mesh solution is the friend node low power node relationship, and it exists because flooding and sleeping are fundamentally incompatible: a sleeping radio will miss the flood.

Figure 4: Friendship establishment and polling. The friend node stores messages addressed to its low power node and delivers them when the node wakes and polls.

A Low Power Node (LPN) broadcasts a Friend Request containing criteria it cares about: how much queue it needs, what receive window it can tolerate, and how it weights signal strength against receive-window length. Nearby friend-capable nodes answer with a Friend Offer reporting their queue size, subscription list size, receive window and measured RSSI. The LPN chooses the best offer, and confirms by polling that friend.

From then on, the friend node stores messages addressed to the LPN’s unicast address and to any group addresses the LPN subscribed to, using a subscription list the LPN maintains by message. When the LPN wakes, it sends a Friend Poll. The friend responds after a receive delay, and sets a “more data” flag so the LPN keeps polling until the queue is empty. A one-bit Friend Sequence Number lets the friend tell a new poll from a retransmission, so a lost response is not silently discarded. A poll timeout tells the friend how long to wait before assuming the LPN is gone and freeing its queue.

The radio-on time is brief. In an illustrative budget, assume 2 microamps sleep current and 10 ms of active radio per poll at 8 mA, which is 0.08 mA-seconds per poll. Polling every 10 seconds averages 0.008 mA, add 0.002 mA sleep, and a nominal 220 mAh coin cell lasts roughly 22,000 hours, or 2.5 years. Polling every second averages 0.082 mA and drops the life to about 112 days. These are assumptions for illustration, not measurements of any chip.

Friend nodes carry a cost too. Every LPN consumes queue memory on its friend, and the friend must be reachable in one hop. A friend can serve several LPNs, but queue size and subscription list size cap that, and a friend that reboots loses its queues, dropping every message waiting for sleeping nodes.

The GATT proxy: how phones join the flood

A phone cannot reliably transmit raw mesh advertisements on every platform, so the spec defines the proxy node. A proxy accepts a GATT connection, receives mesh PDUs written to a characteristic by the phone, and rebroadcasts them onto the advertising bearer. In the other direction it forwards mesh traffic it hears to the phone as GATT notifications.

An unfiltered proxy would forward everything, which wastes the phone’s radio and battery. The proxy therefore supports filters: the client configures an accept list or reject list of destination addresses, and the proxy forwards only matching traffic. A well-behaved phone app sets an accept list for its own unicast address and the groups it controls.

Proxy discovery is a privacy concern. In Mesh 1.0 a proxy advertises a Network ID derived from the network key, so anyone scanning learns that a particular network is nearby, and can correlate its proxies across visits. Mesh 1.1 adds the on-demand private GATT proxy, where the proxy stays quiet until a phone sends a Solicitation PDU, then advertises with a private network identity. According to the SIG, a valid solicitation requires knowledge of a network key, which makes proxies harder for an attacker to find.

Directed forwarding: a path-based option in Mesh 1.1

Managed flooding scales poorly with node count and traffic density, and the 46 percent worked example above is the reason. Mesh 1.1 therefore introduces directed forwarding, which the SIG describes as a second multi-hop delivery method alongside managed flooding. Paths are created automatically when needed and checked at intervals, and only nodes that move a message toward its destination relay it.

The mechanism, as I understand it from the specification, works like reactive routing in other mesh systems. When a source has traffic for a destination and no path, it floods a path discovery request. Nodes that hear it record the reverse route. The destination, or a node acting for it, answers, and the reply travels back along the recorded route and installs forwarding entries. A path has a lifetime and is refreshed or expires, and the specification defines echo messages to validate a path. I am describing the shape of the procedure from memory of the Mesh Protocol 1.1 text, so verify message names and timers there before implementing.

The practical consequences are what matter for design. Directed forwarding reduces radio transmissions per unicast message from roughly the full relay population to roughly the path length. A 6-hop path costs about 6 transmissions per attempt instead of dozens, which both saves energy and frees airtime. The price is state: forwarding tables consume memory, discovery adds latency on the first message, and mobility or a failed relay forces rediscovery.

Directed forwarding is not a replacement. Group-addressed control, such as lighting scenes, still suits flooding because the destination set is large and routes would be wasteful. A sensible mixed deployment uses flooding for groups and directed forwarding for unicast telemetry from many sensors to a gateway, which is the traffic pattern that kills pure flooding.

The rest of Mesh 1.1 that matters in the field

Several other 1.1 features address operational pain, and they all appear in the SIG summary. Subnet bridging lets an intermediate bridge node pass traffic between two subnets without either side knowing the other’s network key. Device firmware update (DFU) distributes images across the mesh, with parameters to control pacing and size so transfers run in the background, plus multicast and scheduled application of updates. The transfer rides a binary large object mechanism in the model specifications, which I am labelling as my recollection because the SIG summary page does not name it.

The opcodes aggregator bundles a sequence of access messages into a single aggregated message and returns a single status response. All bundled opcodes must be handled by the same server model, so this is a tool for configuring one model quickly, not a general batch interface. Large composition data models let a complex device expose its composition in portions using an offset, which matters for gateways with many elements, such as DALI bridges.

Bluetooth Mesh Security

Security is the area where Bluetooth mesh is stronger than most low-power rivals, and also the area where operational mistakes are most common. The design is a layered key hierarchy, and the layering is the point.

Three key types, two encryption layers

A network key (NetKey) is shared by all nodes in a subnet. From it, the stack derives, using the k2 function, an encryption key, a privacy key and the NID that identifies which network a PDU belongs to. All traffic is encrypted and authenticated at the network layer with AES-CCM, specified in NIST SP 800-38C, using 128-bit keys. The NetMIC is 32 or 64 bits, matching the data the Silicon Labs page lists.

An application key (AppKey) is bound to a model and shared only by nodes that should understand that application’s messages. Application data is encrypted again at the upper transport layer with a key from the AppKey, so a relay that holds the NetKey and happily forwards your lighting traffic cannot read it unless it also holds the AppKey. A 6-bit application identifier, derived from the AppKey with k4, tells a receiver which key to try.

The device key (DevKey) is unique per node and is derived during provisioning. It protects configuration traffic between the provisioner and the node. It is what allows a node to be reprovisioned or reconfigured without trusting other network members.

The consequence is a separation of duties. A relay-only node in a hallway can forward every packet, yet read none of the application payloads. A compromised light bulb exposes the NetKey, which lets an attacker inject network-layer traffic and observe addressing, but it does not expose a door-lock AppKey the bulb never held. Good designs exploit this by giving security-critical models their own AppKeys and keeping them off low-trust devices.

Obfuscation, IV Index and replay protection

The network layer obfuscates the CTL, TTL, sequence number and source address by XOR-ing them with a value derived from the privacy key and a sample of the encrypted payload. This hides the sequence number from casual sniffing but is explicitly obfuscation, not encryption. An attacker holding the NetKey can undo it, and it does not stop traffic analysis based on timing and packet size.

Replay protection uses the pair of IV Index and sequence number. The sequence number is 24 bits, so a node can send 16,777,216 messages before exhausting it. A 32-bit IV Index extends that space. A receiver keeps a replay protection list (RPL) with the highest IV Index and sequence number seen from each source address, and rejects anything at or below it. The Silicon Labs documentation reports a default RPL of 32 entries in its implementation, which is a vendor choice, not a spec constant. A node that falls off the RPL because it is full will have messages dropped, which is a real operational failure in networks larger than the list.

The sequence budget is easy to compute. A node publishing once per 10 seconds uses 0.1 messages a second, so 16.7 million sequence numbers last about 5.3 years. At one message a second the budget is about 194 days. At ten a second it is only about 19 days. A node must therefore take part in the IV Update procedure well before exhaustion. The spec requires a minimum time between IV Index transitions, which I recall as 96 hours, so a network that publishes aggressively can reach exhaustion faster than it can legally rotate. Treat that figure as something to verify against the Mesh Protocol text, and design publish rates accordingly.

Key refresh and removing a node

Bluetooth mesh has no single “revoke” message. To remove a compromised node you must make its keys worthless, which means running the key refresh procedure over the remaining nodes. It proceeds in phases: the configurator distributes new keys while old ones still work, switches nodes to transmit with the new keys, then revokes the old ones. Nodes that miss the update, such as a sleeping LPN, can be left behind, which is why the procedure has timeouts and a recovery path.

Two operational points follow. Key refresh costs real airtime and takes real time in a large network, since every node needs a configuration message. And a removed node that holds only the old NetKey is dead weight, but if you are sloppy and leave the old AppKey bound on its peers, the removal is incomplete. Refresh the AppKeys as well as the NetKey for anything sensitive.

Where the real risks sit

Cryptographic primitives are standard, so most real issues come from configuration rather than from AES. The no-OOB provisioning method offers no protection against an active attacker present at provisioning time. Static OOB values shared across a product line collapse if one leaks. Device keys stored on a phone are only as safe as the phone. Sequence numbers must persist across reboots, or a restarted node reuses old numbers and gets rejected by neighbours.

Privacy was also a gap in 1.0: static beacons and static proxy identities allowed tracking. The SIG added private beacons in 1.1, which encrypt beacon data with a private beacon key and a random number so static information is not exposed. If your threat model includes tracking people through their devices, that feature is worth requiring from your silicon vendor, since support varies by stack.

Trade-offs, Gotchas, and What Goes Wrong

The broadcast storm is a design problem, not a tuning problem. As the worked numbers show, load grows with relays times transmissions times message rate. Teams that enable relay on every mains node and publish sensor data at one-second intervals discover this when reliability falls as they add devices. The fix is architectural: thin the relays, lower publish rates, use group aggregation, and consider directed forwarding for unicast telemetry.

Latency is not bounded. Managed flooding gives you no per-message deadline. Random backoff, retransmissions and segmentation acknowledgements produce a latency distribution with a long tail. Mesh suits lighting and monitoring well, and suits closed-loop control poorly. If an actuator must respond within a deadline, put the control loop on the device.

Throughput is small and shared. A 29-byte PDU carrying about 11 bytes of application payload is not a data pipe. Segmented transfers of a few hundred bytes already occupy the neighbourhood for many transmissions. Firmware updates over mesh are possible in 1.1 but slow, so budget hours or days for a large fleet, not minutes.

Friendship has sharp edges. A friend that reboots loses queues. An LPN with a poll timeout shorter than its real wake interval loses its friendship silently. Too many LPNs on one friend exhaust queue memory, and the oldest messages are dropped. Latency to an LPN is bounded below by its poll interval, so a battery door sensor cannot be commanded instantly.

Interoperability is real but partial. The SIG qualification process ensures a baseline, but vendors implement optional features, buffer sizes and relay behaviour differently. Directed forwarding and DFU are newer, so mixed-vendor 1.1 networks deserve a pilot before rollout. Check qualified product listings, not marketing pages.

Coexistence with Wi-Fi and BLE connections matters. Advertising on three channels shares the 2.4 GHz band with 20 MHz Wi-Fi channels, and the mesh scanner often runs near-continuously on mains nodes. If a node also maintains a GATT connection to a phone, the controller schedules both, and mesh reception can suffer.

Localisation is not a mesh strength. Teams sometimes try to use mesh nodes as location anchors. Mesh was not designed for it, and newer Bluetooth features such as channel sounding exist for ranging. We compare these approaches in our UWB real-time location systems versus BLE channel sounding analysis.

Practical Recommendations

Start by classifying your traffic, because the architecture follows from it. If most messages are group commands to many nodes at modest rates, as in lighting, managed flooding is the right tool and you should focus on relay thinning. If most messages are unicast telemetry converging on a gateway, plan for directed forwarding, or accept that you may be better served by a routed protocol such as Thread.

Plan the relay backbone deliberately. A reasonable starting point is to enable relay on mains-powered nodes only where they provide coverage overlap, aim for each node to hear several relays, and measure with heartbeat hop counts before adding more. Keep TTL close to the real network diameter plus a small margin, since a large default wastes airtime on messages that should have died.

Treat power architecture as a first-class decision. Place battery nodes as LPNs, make sure each is within one hop of at least one reliable friend, and size poll intervals against real latency needs. Provision two friends where the LPN count justifies it, and test the behaviour when a friend reboots.

Make security an operational process, not a feature. Use certificate-based or OOB provisioning for anything sensitive, give security models separate AppKeys, store keys and sequence numbers in protected persistent memory, and rehearse key refresh before you need it.

Classify traffic: group commands, unicast telemetry or both.
Enable relay selectively and verify with heartbeat hop data.
Set TTL and publish rates from measured diameter and the airtime budget.
Use LPNs for battery devices and test friend reboot recovery.
Separate AppKeys for sensitive models; require OOB or certificate provisioning.
Persist sequence numbers and plan IV update timing.
Pilot mixed-vendor Mesh 1.1 features before fleet rollout.

Frequently Asked Questions

What is Bluetooth mesh and how does it differ from regular Bluetooth?

Bluetooth mesh is a many-to-many networking layer built on BLE radios. Regular Bluetooth Low Energy usually forms point-to-point connections between a central and a peripheral. Mesh instead broadcasts small packets on advertising channels, and relay nodes rebroadcast them so messages cross multiple hops. It does not replace BLE, it uses it, which is why phones can interact with a mesh through a GATT proxy node.

Does Bluetooth mesh use routing?

Not in its original form. Mesh 1.0 uses managed flooding: relays rebroadcast messages, a message cache suppresses duplicates, and a time-to-live field bounds the hops. Mesh 1.1, announced by the SIG in September 2023, adds directed forwarding as a second delivery method, where paths are created on demand and only nodes along the path relay. Both methods can coexist in one network.

What is the difference between a friend node and a low power node?

A low power node is a battery device that sleeps most of the time and cannot listen continuously. A friend node is a mains-powered node that stores messages addressed to the low power node and delivers them when it wakes and sends a poll. The pairing is established by a request and offer exchange, and the friend caches traffic until the poll timeout expires or the friendship ends.

How does BLE mesh provisioning work?

A provisioner sends an invitation to an unprovisioned device, which replies with its capabilities. They perform an ECDH key exchange on the P-256 curve, authenticate using a chosen out-of-band method, and exchange confirmation values. The provisioner then sends the network key, IV Index and a unicast address, encrypted with a session key. The device also receives a unique device key for later configuration.

Is Bluetooth mesh secure?

The cryptography is sound: AES-CCM with 128-bit keys, separate network and application layers, and per-device keys. Weaknesses are operational. No-OOB provisioning is unauthenticated, shared static values can leak, and removing a compromised node requires a key refresh. Mesh 1.1 improves privacy with private beacons and private proxy advertising. Security depends on how provisioning and key management are done, not on the protocol alone.

How many nodes can a Bluetooth mesh network support?

The address space allows tens of thousands of unicast addresses, so addressing is not the limit. Airtime is. A dense network with many relays and frequent publishing saturates the advertising channels long before addresses run out. Practical size depends on topology, relay count, message rate and TTL. Real deployments vary widely, and I have not cited a vendor benchmark, so test your own layout.

Bluetooth Mesh Architecture: Managed Flooding, Provisioning, Friend Nodes and Security (2026)