From Custom Bluetooth Broadcasts to Mesh: What Multihop Networking Requires

Suppose you already have a Bluetooth broadcast-control system: a controller sends “turn on,” nearby lamps receive it, and the lights come on. You own the devices and application, and the protocol is simple.

Now you want more coverage. The controller cannot reach the bedroom, so a hallway lamp forwards its message. The first implementation seems obvious: receive a packet, recognize the protocol and broadcast it again.

With two hallway lamps, complications begin. Both forward the message, copies arrive along different paths, and neighbors can send those copies back. The questions become: have I seen this message, should I relay it, have I executed it, and does the originator know the result?

Part one explained the relationship between custom Mesh, SIG Mesh and Xiaomi Mesh. This article examines what must be added to an existing custom Bluetooth broadcast protocol to support real multihop operation.

The controller–relay–lamp network below is a design example, not a measurement of a particular product. We will examine reliability before deciding whether maintaining our own Mesh is worthwhile.

Step 1: give each message an identity that survives forwarding

In single-hop control, developers naturally focus on command fields: which byte represents power and which represents brightness. With relays, message identity becomes equally important.

Controller A sends one request. Relays B and C both forward it, so lamp D may receive two copies. D must recognize them as copies of the same transmission.

A relay must not turn the message into a new application command originating from itself. Otherwise the destination cannot identify duplicates by the original message. The immediate radio transmitter may change, while the protocol preserves the original source and message identity.

Information	Question it answers
Network or security-domain identifier	Which system does this belong to? The identifier alone does not establish trust
Original source and destination	Who initiated it, and is it addressed to a device or group?
Message sequence and necessary generation information	Is this a new transport message or a previously seen copy?
Forwarding budget	How many more relay operations are permitted?
Application request identifier	Do multiple transmissions belong to the same business operation?
Operation, parameters and authentication	What is requested, is it trustworthy, and has it been altered?

This is a list of responsibilities, not a ready-to-use packet format. Field placement, size and authentication coverage must be designed together with addressing, key management and fragmentation.

A duplicate packet in the network and a fresh transmission retrying the same application operation are not necessarily the same thing. This distinction determines whether a retried command gets executed twice.

Step 2: make forwarding a bounded action

A forwarding budget limits propagation: each relay reduces it, and no further relay is permitted once it is exhausted. It bounds travel even when the topology contains loops.

But it does not determine how often an individual node forwards a message. If B has already relayed A’s packet and later receives it from C, forwarding again adds unnecessary traffic. A recent-message cache can suppress a second forwarding procedure for the same identity.

That does not mean “discard every duplicate everywhere.” The network layer may suppress repeated propagation, while the application still needs to return a saved result for a retried request. One global “already seen” flag cannot replace both responsibilities.

Cache retention and capacity have costs. Short retention can admit late copies as new messages. Long retention uses more memory and complicates identity reuse. Estimate them from message rate, propagation lifetime and retry windows, then validate under load.

Reception order matters too. Perform the necessary format, network-membership and authentication checks before admitting a message into trusted processing state. A forged message should not reserve an entry that causes the genuine command to be rejected as a duplicate.

The Bluetooth SIG Mesh primer describes standard relaying and TTL. A custom forwarding budget can address similar problems without having the same field semantics. Its numerical values should not automatically be equated with SIG Mesh TTL.

Step 3: decide who relays and when

Many devices may receive a packet; that does not mean all should relay immediately. If they receive together and transmit together, the extra copies can increase collisions rather than improve delivery.

Relay eligibility, transmission timing, bounded retransmission and queue limits need to be considered together. Controlled random delays can reduce synchronized contention, while limits on transmissions per message prevent queues growing indefinitely.

Longer random delays are not always better: they add response time that accumulates over hops. More repetitions are not always more reliable either; in a congested network they can further crowd out useful traffic. “Enable every lamp as a relay” and “double retries whenever packets are lost” are poor universal defaults. Placement, power and workload matter.

Power is particularly important. Continuous scanning and forwarding consume energy. A battery switch able to send its own button event is not automatically suitable as a permanent relay.

SIG Mesh Low Power and Friend mechanisms divide these responsibilities: a Friend temporarily stores messages so the low-power node need not listen continuously. A custom solution that delivers commands to sleeping devices needs receive windows, buffering or another coordination scheme. Merely listing “battery support” is insufficient.

Step 4: define the layer at which success occurs

This deserves discussion before packet design. When a controller hands a packet to a Bluetooth module and receives “transmission complete,” that describes the module’s operation. It does not prove the bedroom lamp received the command, much less that it illuminated.

Even a destination response needs a defined meaning: received, accepted, executed, or physically observed? A relay-output controller can report that it set its output. Without current sensing or other feedback, it cannot know whether the load actually worked. The interface must reflect what the device can observe.

Nor should every intermediate relay report success on behalf of the final destination. That only confirms arrival at an intermediate hop. Operations needing final-state confirmation require a defined end-to-end response correlated with the request.

Acknowledging everything creates another issue: group control. One command switches off a group of lamps; immediate replies from every lamp, relayed back through the network, can exceed the original downlink traffic. The SIG primer also notes that acknowledged messaging works well for individual destinations but scales poorly to large groups.

Policies can vary by operation: individually acknowledge important configuration, use bounded repetition for ordinary group control and query states over time, or define aggregation and timeouts when a complete result is required. Be explicit about the guarantee. If state reconciliation is omitted, the interface must not claim that every device executed successfully.

Step 5: retries must not turn a lamp on and then off again

Imagine the lamp executes a command but its response is lost. The controller times out and retries. If the command is “toggle,” executing twice restores the original state. The user may see a flash followed by darkness.

“Set power to on” usually avoids that particular problem. For target-state operations, preserving the same effect across repeated execution is valuable.

But not all operations are safe to repeat. “Move the motor one step,” “decrement once” and “start a timer” may have duplicate side effects. They need request identities, result records and recovery policies.

Transport sequences and application request IDs can perform separate duties: a new transmission follows the security rules for message identity, while the application recognizes the previous operation and returns its result rather than repeating it.

A subtler failure remains. First the user requests 30% brightness, then changes it to 80%. A late retry of the first command arrives last, restoring 30%. Both commands individually set a target state and tolerate repetition, yet the state has regressed.

Ordering and validity must therefore be handled, for example through versions within a control stream, request expiry, or cancellation of old retries by newer operations. Multiple controllers also require an overwrite policy.

Repeatability alone does not guarantee correctness. Nor should a device promise absolute exactly-once execution if power can fail after acting but before saving the result.

Step 6: restarting must not reset security

Anyone able to receive nearby broadcasts may record a valid command and transmit it later. Encryption alone does not completely address this: an unmodified, previously valid ciphertext can still be resubmitted at the wrong time.

Short-term duplicate caches and replay-protection state are therefore different. Clearing a cache to save RAM must not automatically reauthorize old commands.

Both sender and receiver matter. How does a restarted sender avoid unsafe reuse of security-related sequence numbers or nonces? How does a receiver avoid accepting old messages after forgetting its security state? What changes during a factory reset, reprovisioning or rekeying?

For authenticated-encryption algorithms requiring nonce uniqueness under a key, a RAM-only counter starting at zero on every boot is not enough. Multiple senders sharing a key must also avoid nonce collisions. Construction must follow the algorithm and a mature protocol’s requirements.

RFC 5116 discusses authenticated encryption and nonce usage, and explicitly separates its interface from complete anti-replay and access-control services. Saying “we use AES” can obscure that distinction.

Persistence adds flash-write frequency, power-loss consistency and recovery concerns. One engineering approach reserves a range of counter values using a persisted boundary. But its implementation still needs evidence that interrupted writes cannot cause rollback or reuse; ordinary reboot testing is insufficient.

Key lifecycle also belongs in the initial design: securely adding devices, removing lost or resold devices, and revoking their authority. Deleting a device row from an application does not revoke keys stored inside the device.

Step 7: establish small messages before fragmentation and updates

Switch commands are short, so prototypes often ignore size. Bulk configuration, long properties and firmware transfer expose another set of questions.

How are messages fragmented and reassembled? How is each fragment identified? What happens when one is missing, how long are buffers retained, and how many reassemblies may run simultaneously?

Do not equate theoretical BLE advertising, extended-advertising or SDK capacity with usable application payload. Headers, security fields, bearer choice and device support all constrain it.

Fragmentation multiplies traffic: one business operation becomes several radio packets, each potentially relayed. Poor retry policy can let a small configuration workload crowd out normal control.

I would first establish short commands, state reporting and recovery. Firmware updates need separate design for transport, traffic control, signature verification and failure recovery. Moving data over Mesh does not itself provide a dependable OTA system.

How to test beyond a working demonstration

Start with a small network that exposes failure paths rather than chasing a large node count. These are proposed tests, not measured results.

Scenario	What to observe
One command arrives through two relays	Whether copies are bounded and execution is duplicated
Response lost after execution	Whether retries repeat side effects or return the known result
New command arrives before an old retry	Whether late requests overwrite newer state
A relay loses power or is moved	Continued operation with an alternative path; honest failure without one
Simultaneous reporting and group responses	Latency, failure rate, transmissions and queue pressure
Sender and receiver lose power at critical points	Recovery of sequences, nonces, request records and replay protection
A device is removed or reprovisioned	Whether old keys, packets or bindings permit unintended operations

Define measurement endpoints: application submission to radio transmission, or to the destination’s execution report? Without a sensor observing the actual load, the latter must not be called physical light-response time.

Track slow-tail latency, timeouts, duplicate executions and transmission counts, not only averages. When reporting median and P95, include sample size and failures separately. Excluding every timeout and showing only successful samples produces misleadingly good numbers.

Record placement, power, Wi-Fi interference, scan settings and traffic rates too. Otherwise results collected on different days may not be comparable.

Then decide how much to build yourself

Forwarding a broadcast once may take a few lines. A maintainable network needs coordinated rules for identities, addresses, bounded relaying, duplicates, responses, application retries, security state, recovery and diagnostics.

That does not require every product to reimplement SIG Mesh. A focused application, fully controlled devices and a substantial installed base may justify a custom solution. Know which capabilities you omit and whether those omissions fit the product.

If the reasoning is merely “our broadcast protocol is simple, so relaying should be simple,” estimate the lifecycle costs while still prototyping. A mature vendor solution or standard stack may leave more time for device functionality and gateway behavior.

For our Matter gateway, product behavior, state mapping and error handling are especially valuable areas to own. The amount of wireless networking we implement ourselves should depend on sustained validation and maintenance, not only whether the first prototype works.

Next we return to SIG Mesh: what happens between discovering a new device, completing Provisioning and successfully switching it? Network keys, application keys, model bindings and publication/subscription will provide concrete counterparts to these design problems.

If you already operate a proprietary broadcast system, start with why relaying is needed, which devices have continuous power and which failures are unacceptable. Get in touch to discuss your scenario.