Bluetooth Mesh Directed Forwarding: Validate Path State Before Reducing Flooding

Directed forwarding is useful only when the required path exists, its address scope matches the traffic and failures produce a controlled recovery. Enabling a feature flag or seeing one PATH_REQUEST does not establish that a usable directed path has been installed.

Applicability: historical Bluetooth Mesh Protocol 1.1, focusing on dynamically discovered, non-fixed paths to a unicast destination. This is a protocol-level qualification procedure, not a claim that any particular SDK implements the feature. Pin the shipping stack, enabled roles and configuration before execution. The topology and tests are hypothetical.

1. Qualify roles before reducing managed flooding

Inventory the proposed Path Origin, Path Target and intermediate Directed Relay nodes. Record subnet membership, supported functionality, enabled Directed Control state and the available discovery/forwarding resources.

Section 3.6.8 distinguishes directed forwarding from ordinary managed flooding. A node that can relay ordinary mesh traffic is not automatically a Directed Relay participating in the selected path.

Keep a working, measured baseline before changing the deployment policy. Do not disable useful ordinary relay coverage merely because a configurator accepted a directed-forwarding setting. First demonstrate which traffic uses directed security credentials and which forwarding entries support it.

Separate direct participants from dependent nodes served through Directed Friend, Directed Proxy or bridging functionality. The simple fixture here uses direct participants only; dependent address ranges require their own qualification.

2. Distinguish discovery state from forwarding state

PATH_REQUEST propagation creates temporary Discovery Table information. PATH_REPLY processing establishes or updates Forwarding Table entries along the selected path. The specification explicitly says that receiving PATH_REQUEST does not itself update the Forwarding Table.

Capture both tables where the implementation exposes them. Record subnet, origin, destination, forwarding number, path lifetime and bearer direction fields. A discovery entry can be evidence that the search began while the forwarding path still does not exist.

The forwarding number distinguishes initialization generations and newly initialized paths under its defined wrap-aware comparison. Discovery of additional lanes for an existing path uses that path’s same forwarding number; it does not allocate a distinct number per lane. This field is separate from the network sequence number and replay protection. Do not compare it as an unlimited monotonically increasing integer.

Use a hypothetical path O → R1 → R2 → T. Seeing the request at T does not prove the reply returned through R2 and R1 or that O installed the corresponding path. Require state and message evidence at the origin before marking the route ready.

3. Match the path to the actual traffic

Forwarding Table matching uses source and destination address ranges, including declared secondary elements and any supported dependents. A path to one product’s primary element is not a blanket promise for arbitrary addresses elsewhere in the network.

For a two-way application exchange, inspect Backward_Path_Validated rather than assuming a forward path implies the same directed reverse path. PATH_CONFIRMATION participates in validating the backward direction under the specified procedure.

Probe both directions with permitted application traffic. Record whether each message uses directed or managed-flooding credentials. Successful delivery alone can hide a fallback path and therefore cannot establish that the intended directed route carried the response.

Keep group and virtual destinations outside the first unicast fixture. They add target membership and readiness details that cannot be inferred from a successful one-target test.

4. Observe path validation rather than assuming instant repair

With the applicable echo timer configured, the Path Origin sends PATH_ECHO_REQUEST to validate the path. A matching response is accepted only while the corresponding reply-timeout timer is running. A late response must not revive an already failed validation silently.

The reply path is itself qualified: section 3.6.8.2.6 uses managed-flooding credentials for PATH_ECHO_REPLY when the backward path has not been validated, and directed credentials when it has. Thus, an echo success does not always demonstrate directed forwarding in both directions.

If the reply timeout expires, validation fails. The corresponding Forwarding Table entry is deleted and the Forwarding Table Update Identifier changes. For the Path Origin State Machine in Path Validation, failure transitions to Path Discovery and starts a new initialization procedure.

That is a defined recovery sequence, not a zero-loss or fixed-time promise. Detection depends on configured validation timing, and rediscovery depends on remaining topology and resource availability. Report the actual outage interval and application consequences.

5. Bound rediscovery and idle-path behavior

Section 4.4.7.2 defines discovery, in-use, validation, monitoring and retry-wait states. A failed discovery enters Path Discovery Retry Wait. When its timer expires, observed traffic demand determines whether discovery is needed again or the state machine can finish.

Preserve those states in diagnostics rather than replacing them with an unbounded application loop that repeatedly forces path discovery. Multiple applications sharing a destination should not create competing repair controllers.

Non-fixed path state has a lifetime and monitoring behavior. Fixed paths are separately configured and are outside this recovery fixture. Do not apply dynamic-entry deletion and refresh assumptions to fixed entries without inspecting their rules.

Use the Forwarding Table Update Identifier to detect a changing table during management reads. A paged snapshot assembled across updates may combine different path generations. Repeat or reconcile it before drawing conclusions about a broken hop.

6. Run a broken-hop acceptance experiment

1. Record the established O → R1 → R2 → T path, relevant tables and application delivery baseline.
2. Remove R2 or interrupt its link through an authorized lab method. Preserve O, R1 and T state so this remains a path-loss test rather than a whole-network restart.
3. Observe application gaps, echo request, reply-timeout outcome, entry deletion and new discovery attempt.
4. If an alternate route exists, verify its new forwarding evidence and the first valid application result. Do not infer recovery from a successful configuration read alone.
5. If no route exists, verify bounded retry-wait behavior and an explicit unavailable state.
6. Restore the original node and verify recovery without duplicate application actions or stale-path readiness.

Repeat with the backward direction unavailable, discovery resources exhausted, a delayed old reply and a quiet application that no longer needs the path. These cases exercise different transitions and should not all be labeled “RF timeout.”

Compare directed operation with the baseline using equivalent workload, topology and message deadlines. Include discovery, echo and repair traffic in the comparison. Fewer data-forwarding nodes during a healthy period does not by itself establish lower total energy or better resilience.

Acceptance requires a supported implementation, explainable path state and measured recovery behavior within product requirements. Preserve the configuration and traces that show when directed forwarding was actually usable and how the product behaved while it was not.